Temario1. Introducción1.1 Importancia de la administración de proyectos de software: Crisis del software.(TB),1.2 certificaciones (MS ), PMB y software(projet u otros) (Todo en resumen)1.3 El reto de la administración de los proyectos del software: que es un proyecto, y como se dirige un proyecto, tipos deproyectos(TB y PMB)2. Componentes Clave del Desarrollo del Software2.0 Modelo dinámico (TB).2.1 Planeación(TB)2.2 Como organizar por procesos: Dirección, Gerencias: calidad,administración(y operación) y procesos (MS)2.3 Grupos de procesos de planificación (PMB)2.4 Modelos actuales de para administración de proyectos(PMB)2.5 Áreas de conocimiento(PMB)2.6 Planes estratégicos, comunicación, riesgos, económicos,etc(MS)3. Administración de los Recursos Humanos3.1 Clasificación(TB)3.2 Gestión de recursos humanos(PMB)3.3 Roles (MS)4. Producción y Desarrollo del Software4.0 clasificación de producción y desarrollo y explicación(TB)4.1 Ciclo vida del proyecto(TB) (PMB)4.2 Procesos básicos necesarios a verificar(MS)5. Aseguramiento de la CalidadQue es calidad y tipos de calidad, ISO y CertificacionesPracticas para evaluar (MS)Planificación aseguramiento y control (PMB)6. Pruebas del Sistema Planes de pruebas y riesgos7. Control y Planeación Como seguir el modelo8. Un Caso de Estudio

Crisis del SoftwareCrisis del Software

HistoriaHistoriaSíntomasSíntomasFactores de InfluenciaFactores de InfluenciaPosibles CausasPosibles Causas

HistoriaHistoria

El término “crisis del software” se acuñó en El término “crisis del software” se acuñó en 1968, en la primera conferencia 1968, en la primera conferencia organizada por la organizada por la OTAN sobre desarrollo sobre desarrollo de software y con él se etiquetaron los de software y con él se etiquetaron los problemas que surgían en el desarrollo de problemas que surgían en el desarrollo de sistemas de software. sistemas de software.

En la misma conferencia se utilizó por En la misma conferencia se utilizó por primera vez el término "ingeniería del primera vez el término "ingeniería del software" para describir el conjunto de software" para describir el conjunto de conocimientos que existían en aquel conocimientos que existían en aquel estado inicial. estado inicial.

Algunas referencias útiles para comprender cuáles Algunas referencias útiles para comprender cuáles eran los conocimientos estables para el desarrollo eran los conocimientos estables para el desarrollo de software en 1968 son:de software en 1968 son:

En 1962 se publicó el primer algoritmo para En 1962 se publicó el primer algoritmo para búsquedas binarias. búsquedas binarias.

C.Böhm y G. Jacopini publicaron en 1966 el C.Böhm y G. Jacopini publicaron en 1966 el documento que creaba una fundación para la documento que creaba una fundación para la eliminación de "GoTo" y la creación de la eliminación de "GoTo" y la creación de la programación estructurada.programación estructurada.

En 1968 los programadores se debatían entre el En 1968 los programadores se debatían entre el uso de la sentencia GoTo, y la nueva idea de uso de la sentencia GoTo, y la nueva idea de programación estructurada; ese era el caldo de programación estructurada; ese era el caldo de cultivo en el que Edsger Dijkstra escribió su cultivo en el que Edsger Dijkstra escribió su famosa carta "GoTo Statement Considered famosa carta "GoTo Statement Considered Harmful" en 1968. Harmful" en 1968.

La primera publicación sobre programación La primera publicación sobre programación estructurada no vio la luz hasta 1974, publicada estructurada no vio la luz hasta 1974, publicada por Larry Constantine, Glenford Myers y Wayne por Larry Constantine, Glenford Myers y Wayne Stevens.Stevens.

El primer libro sobre métrica de software fue El primer libro sobre métrica de software fue publicado en 1977 por Tom Gilb. publicado en 1977 por Tom Gilb.

El primer libro sobre análisis de requisitos El primer libro sobre análisis de requisitos apareció en 1979. apareció en 1979.

El término fue usado para referirse a los rápidos El término fue usado para referirse a los rápidos incrementos de la tecnología en la incrementos de la tecnología en la computación y y la complejidad de los problemas a los cuales la complejidad de los problemas a los cuales pudieran enfrentarse. En efecto, se refiere a la pudieran enfrentarse. En efecto, se refiere a la dificultad de escribir correcta, entendible y dificultad de escribir correcta, entendible y verificablemente los lenguajes de programación. verificablemente los lenguajes de programación. Las raíces de la crisis del software son complejas Las raíces de la crisis del software son complejas y variables.y variables.

Uno de los principales problemas en el desarrollo Uno de los principales problemas en el desarrollo de software de hoy, es que muchos proyectos de software de hoy, es que muchos proyectos empiezan la programación tan pronto se definen empiezan la programación tan pronto se definen y concentran mucho de su esfuerzo en la y concentran mucho de su esfuerzo en la escritura de código.escritura de código.

Últimamente el desarrollo de software se a Últimamente el desarrollo de software se a ralentizado. El estudio de este fenómeno es ralentizado. El estudio de este fenómeno es importante porque la existencia de software importante porque la existencia de software científico libre facilita que cualquier laboratorio científico libre facilita que cualquier laboratorio del mundo pueda desarrollar ciencia libre usando del mundo pueda desarrollar ciencia libre usando este software como herramienta de trabajo.este software como herramienta de trabajo.

SINTOMASSINTOMAS

Algunos Algunos ““síntomassíntomas”” que indican que que indican que el software se encuentra en un el software se encuentra en un periodo de crisis son:periodo de crisis son:

Baja Calidad del Software. Baja Calidad del Software. Tiempo y Presupuesto Excedido. Tiempo y Presupuesto Excedido. Confiabilidad Cuestionable. Confiabilidad Cuestionable. Altos Requerimientos de Personal Altos Requerimientos de Personal

para desarrollo y mantenimiento. para desarrollo y mantenimiento.

Para poder llevar el estado del proceso de Para poder llevar el estado del proceso de software como un estado de crisis, los software como un estado de crisis, los críticos han destacado ciertas críticos han destacado ciertas características que han permitido esta características que han permitido esta postura del software respecto a otras postura del software respecto a otras etapas de su corta historia. Algunos de etapas de su corta historia. Algunos de esos factores son:esos factores son:

Aumento del poder computacional. Aumento del poder computacional. Reducción del costo del hardware. Reducción del costo del hardware. Rápida obsolescencia de hardware y Rápida obsolescencia de hardware y

software. software.

FACTORES DE INFLUENCIAFACTORES DE INFLUENCIA

Aceptación de la computarización en las Aceptación de la computarización en las empresas. empresas.

Incremento en el número de usuarios de Incremento en el número de usuarios de los sistemas de software. los sistemas de software.

Tipo de usuario no homogéneo aun en Tipo de usuario no homogéneo aun en sistemas hechos a la medida. sistemas hechos a la medida.

Personal desarrollado y mantenimiento Personal desarrollado y mantenimiento diferente. diferente.

La magnitud del proyecto impacta en: La magnitud del proyecto impacta en: Tiempo costo y número de desarrolladoresTiempo costo y número de desarrolladores

Control administrativo y detalles técnicos Control administrativo y detalles técnicos Aumento en el conocimiento del problema. Aumento en el conocimiento del problema. Cambios en el entorno: Cambios en el entorno:

Tecnológicos (Internet, redes, ERP, CRM, Tecnológicos (Internet, redes, ERP, CRM, SCM). SCM).

Económicos (crisis económicas, Económicos (crisis económicas, globalización, etcétera). globalización, etcétera).

Sociales (nuevas necesidades, costumbres Sociales (nuevas necesidades, costumbres nuevas, etcétera).nuevas, etcétera).

POSIBLES CAUSAS DE LA CRISIS DEL SOFTWAREPOSIBLES CAUSAS DE LA CRISIS DEL SOFTWARE

Hay varias razones que pueden ser propuestas Hay varias razones que pueden ser propuestas como causa de la crisis. No son mutuamente como causa de la crisis. No son mutuamente excluyentes; de hecho, es posible que la excluyentes; de hecho, es posible que la verdadera causa sea una mezcla de todas ellas. verdadera causa sea una mezcla de todas ellas. Sin embargo, todas tienen en común que son Sin embargo, todas tienen en común que son causadas por el método de valorar los avances causadas por el método de valorar los avances científicos y el mecanismo actual de financiación científicos y el mecanismo actual de financiación de la actividad científica. Las causas de la crisis de la actividad científica. Las causas de la crisis del software fueron vinculadas a la complejidad del software fueron vinculadas a la complejidad en general del proceso de software y a la relativa en general del proceso de software y a la relativa inmadurez de la ingeniería de software como una inmadurez de la ingeniería de software como una profesión. La crisis se manifestó a sí misma en profesión. La crisis se manifestó a sí misma en varias maneras:varias maneras:

Proyectos gestionados con un sobre-Proyectos gestionados con un sobre-presupuesto. presupuesto.

Proyectos gestionados con sobre tiempo. Proyectos gestionados con sobre tiempo. Software de baja calidad. Software de baja calidad. El software a menudo no satisfacía los El software a menudo no satisfacía los

requerimientos deseados. requerimientos deseados. Los proyectos fueron inmanejables, con un Los proyectos fueron inmanejables, con un

código difícil de mantener. código difícil de mantener.

La crisis del software fue dirigida por la La crisis del software fue dirigida por la implementación de varios procesos y implementación de varios procesos y metodologías.metodologías.

1.2 Reto Admi..MOPROSOFT11.2 Reto Admi..MOPROSOFT1

El propósito de este documento es El propósito de este documento es presentar un Modelo de Procesos presentar un Modelo de Procesos para la Industria de Software para la Industria de Software (MoProSoft) en México que fomente (MoProSoft) en México que fomente la estandarización de su operación a la estandarización de su operación a través de la incorporación de las través de la incorporación de las mejores prácticas en gestión e mejores prácticas en gestión e ingeniería de software. ingeniería de software.

MOPROSOFT2MOPROSOFT2

La adopción del modelo permitirá La adopción del modelo permitirá elevar la capacidad de las elevar la capacidad de las organizaciones para ofrecer servicios organizaciones para ofrecer servicios con calidad y alcanzar niveles con calidad y alcanzar niveles internacionales de competitividadinternacionales de competitividad

PMBOOK1PMBOOK1

Los Fundamentos de la Dirección de Los Fundamentos de la Dirección de Proyectos constituyen la suma de Proyectos constituyen la suma de conocimientos en la profesión de conocimientos en la profesión de dirección de proyectos. Al igual que dirección de proyectos. Al igual que en otras profesiones, como la en otras profesiones, como la abogacía, la medicina o las ciencias abogacía, la medicina o las ciencias económicas, los conocimientos económicas, los conocimientos residen en los practicantes y residen en los practicantes y académicos que los aplican y losacadémicos que los aplican y los

PMBOOK2PMBOOK2

desarrollan. Los Fundamentdesarrollan. Los Fundamentos os de la de la Dirección de Proyectos completos Dirección de Proyectos completos incluyen prácticas tradicionales incluyen prácticas tradicionales comprobadas y ampliamente comprobadas y ampliamente utilizadas, así como prácticas utilizadas, así como prácticas innovadoras que están emergiendo innovadoras que están emergiendo en la profesión, incluyendo material en la profesión, incluyendo material publicado y no publicado. publicado y no publicado.

PMBOOK3PMBOOK3

Como consecuencia, los Como consecuencia, los Fundamentos de la Dirección de Fundamentos de la Dirección de Proyectos están en constante Proyectos están en constante evolución. evolución.

Proyecto PMProyecto PM

Un proyecto es un esfuerzo temporal Un proyecto es un esfuerzo temporal que se lleva a cabo para crear un que se lleva a cabo para crear un producto, servicio o resultado único producto, servicio o resultado único

Temporal significa que cada proyecto tiene un Temporal significa que cada proyecto tiene un comienzo definido y un final definido. El final se comienzo definido y un final definido. El final se alcanza cuando se han logrado los objetivos del alcanza cuando se han logrado los objetivos del proyecto o cuando queda claro que los objetivos proyecto o cuando queda claro que los objetivos del proyecto no serán o no podrán ser del proyecto no serán o no podrán ser alcanzados, o cuando la necesidad del proyecto alcanzados, o cuando la necesidad del proyecto

ya no exista y el proyecto sea canceladoya no exista y el proyecto sea cancelado. .

Proy2Proy2

Temporal no necesariamente significa de corta Temporal no necesariamente significa de corta duración; muchos proyectos duran varios años. En duración; muchos proyectos duran varios años. En cada caso, sin embargo, la duración de un proyecto cada caso, sin embargo, la duración de un proyecto es limitada. Los proyectos no son esfuerzos es limitada. Los proyectos no son esfuerzos continuos. La mayoría de los proyectos se continuos. La mayoría de los proyectos se emprenden para obtener un resultado duradero. emprenden para obtener un resultado duradero. Por ejemplo, un proyecto para erigir un monumento Por ejemplo, un proyecto para erigir un monumento nacional creará un resultado que se espera que nacional creará un resultado que se espera que perdure durante siglos. Con frecuencia, los perdure durante siglos. Con frecuencia, los proyectos también pueden tener impactos sociales, proyectos también pueden tener impactos sociales, económicos y ambientales, intencionales o no, que económicos y ambientales, intencionales o no, que perduran mucho más que los propios proyectos. perduran mucho más que los propios proyectos.

Producto del proyectoProducto del proyecto

resultados. Los proyectos pueden crear: resultados. Los proyectos pueden crear: • • Un producto o artículo producido, que es Un producto o artículo producido, que es

cuantificable, y que puede ser un elemento cuantificable, y que puede ser un elemento terminado o un componente terminado o un componente

• • La capacidad de prestar un servicio como, por La capacidad de prestar un servicio como, por ejemplo, las funciones del negocio que respaldan la ejemplo, las funciones del negocio que respaldan la producción o la distribución producción o la distribución

• • Un resultado como, por ejemplo, salidas o Un resultado como, por ejemplo, salidas o documentos. Por ejemplo, de un proyecto de documentos. Por ejemplo, de un proyecto de investigación se obtienen conocimientos que pueden investigación se obtienen conocimientos que pueden usarse para determinar si existe o no una tendencia usarse para determinar si existe o no una tendencia o si un nuevo proceso beneficiará a la sociedad. o si un nuevo proceso beneficiará a la sociedad.

Producto…Producto…

La singularidad es una característica La singularidad es una característica importante de los productos entregables de importante de los productos entregables de un proyecto. Por ejemplo, se han construido un proyecto. Por ejemplo, se han construido muchos miles de edificios de oficinas, pero muchos miles de edificios de oficinas, pero cada edificio individual es único: diferente cada edificio individual es único: diferente propietario, diferente diseño, diferente propietario, diferente diseño, diferente ubicación, diferente contratista, etc. La ubicación, diferente contratista, etc. La presencia de elementos repetitivos no presencia de elementos repetitivos no cambia la condición fundamental de único cambia la condición fundamental de único del trabajo de un proyecto. del trabajo de un proyecto.

Elaboración GradualElaboración Gradual

La elaboración gradual es una característica de La elaboración gradual es una característica de los proyectos que acompaña a los conceptos de los proyectos que acompaña a los conceptos de temporal y único. “Elaboración gradual” significa temporal y único. “Elaboración gradual” significa desarrollar en pasos e ir aumentando mediante desarrollar en pasos e ir aumentando mediante incrementosincrementos11. Por ejemplo, el alcance de un . Por ejemplo, el alcance de un proyecto se define de forma general al comienzo proyecto se define de forma general al comienzo del proyecto, y se hace más explícito y detallado del proyecto, y se hace más explícito y detallado a medida que el equipo del proyecto desarrolla a medida que el equipo del proyecto desarrolla un mejor y más completo entendimiento de los un mejor y más completo entendimiento de los objetivos y de los productos entregables. objetivos y de los productos entregables.

La elaboración gradual de las especificaciones de La elaboración gradual de las especificaciones de un proyecto debe ser coordinada cuidadosamente un proyecto debe ser coordinada cuidadosamente con la definición adecuada del alcance del con la definición adecuada del alcance del proyecto, particularmente si el proyecto se proyecto, particularmente si el proyecto se ejecuta en virtud de un contrato. Una vez definido ejecuta en virtud de un contrato. Una vez definido correctamente, el alcance del proyecto —el correctamente, el alcance del proyecto —el trabajo a realizar— deberá controlarse a medida trabajo a realizar— deberá controlarse a medida que se elaboran gradualmente las que se elaboran gradualmente las especificaciones del proyecto y del producto. La especificaciones del proyecto y del producto. La relación entre el alcance del producto y el relación entre el alcance del producto y el alcance del proyecto se trata más adelante, en la alcance del proyecto se trata más adelante, en la introducción del Capítulo 5. introducción del Capítulo 5.

Los siguientes ejemplos ilustran la elaboración Los siguientes ejemplos ilustran la elaboración gradual en dos áreas de aplicación diferentes. gradual en dos áreas de aplicación diferentes.

• • El desarrollo de una planta de procesamiento El desarrollo de una planta de procesamiento químico comienza con la ingeniería de proceso que químico comienza con la ingeniería de proceso que define las características del proceso. Estas define las características del proceso. Estas características se utilizan para diseñar las unidades características se utilizan para diseñar las unidades de procesamiento principales. Esta información se de procesamiento principales. Esta información se convierte en la base para el diseño de ingeniería, convierte en la base para el diseño de ingeniería, que define tanto el plano detallado de la planta que define tanto el plano detallado de la planta como las características mecánicas de las unidades como las características mecánicas de las unidades de proceso y las instalaciones auxiliares. Todo ello de proceso y las instalaciones auxiliares. Todo ello resulta en dibujos de diseño que se elaboran para resulta en dibujos de diseño que se elaboran para crear dibujos de fabricación y construcción. Durante crear dibujos de fabricación y construcción. Durante la construcción, se realizan las interpretaciones yla construcción, se realizan las interpretaciones y

adaptaciones que sean necesarias, que están adaptaciones que sean necesarias, que están sujetas a la aprobación correspondiente. Esta sujetas a la aprobación correspondiente. Esta elaboración adicional de los productos elaboración adicional de los productos entregables se refleja en dibujos que se realizan entregables se refleja en dibujos que se realizan sobre la marcha, y los ajustes operativos finales sobre la marcha, y los ajustes operativos finales se realizan durante la etapa de pruebas y se realizan durante la etapa de pruebas y rotación. rotación.

• • El producto de un proyecto de desarrollo El producto de un proyecto de desarrollo económico puede definirse inicialmente como: económico puede definirse inicialmente como: “Mejorar la calidad de vida de los residentes con “Mejorar la calidad de vida de los residentes con ingresos más bajos de la comunidad X”. A medida ingresos más bajos de la comunidad X”. A medida que el proyecto avanza, los productosque el proyecto avanza, los productos

pueden describirse más específicamente como, pueden describirse más específicamente como, por ejemplo: “Proporcionar acceso a agua y por ejemplo: “Proporcionar acceso a agua y comida a 500 residentes de bajos ingresos de la comida a 500 residentes de bajos ingresos de la comunidad X”. La siguiente etapa de elaboración comunidad X”. La siguiente etapa de elaboración gradual podría centrarse exclusivamente en gradual podría centrarse exclusivamente en mejorar la producción y comercialización agrícola, mejorar la producción y comercialización agrícola, considerando la provisión de agua como una considerando la provisión de agua como una segunda prioridad, a ser iniciada una vez que el segunda prioridad, a ser iniciada una vez que el componente agrícola esté en una etapa componente agrícola esté en una etapa avanzada. avanzada.

Forma de resolución: Divide y vencerás; De un Forma de resolución: Divide y vencerás; De un problema grande obtén varios problemas chicos.problema grande obtén varios problemas chicos.

Proceso MSProceso MS

Conjunto de prácticas relacionadas Conjunto de prácticas relacionadas entre si, llevadas a cabo a través de entre si, llevadas a cabo a través de roles y por elementos roles y por elementos automatizados, que utilizando automatizados, que utilizando recursos y a partir de insumosrecursos y a partir de insumos

producen un satisfactor de negocio producen un satisfactor de negocio para el cliente.para el cliente.

Modelo de Procesos MSModelo de Procesos MS Criterios:Criterios: 1. Generar una estructura de los procesos que 1. Generar una estructura de los procesos que

esté acorde con la estructura de las esté acorde con la estructura de las organizaciones de la industria de software (Alta organizaciones de la industria de software (Alta Dirección, Gestión y Operación).Dirección, Gestión y Operación).

2. Destacar el papel de la Alta Dirección en la 2. Destacar el papel de la Alta Dirección en la planificación estratégica, su revisión y mejora planificación estratégica, su revisión y mejora continua como el promotor del buen continua como el promotor del buen funcionamiento de la organización.funcionamiento de la organización.

3. Considerar a la Gestión como proveedor de 3. Considerar a la Gestión como proveedor de recursos, procesos y proyectos, así como recursos, procesos y proyectos, así como responsable de vigilar el cumplimiento de losresponsable de vigilar el cumplimiento de los

objetivos estratégicos de la organización.objetivos estratégicos de la organización.

4. Considerar a la Operación como ejecutor de los 4. Considerar a la Operación como ejecutor de los proyectos de desarrollo yproyectos de desarrollo y

mantenimiento de software.mantenimiento de software. 5. Integrar de manera clara y consistente los 5. Integrar de manera clara y consistente los

elementos indispensables para la definición de elementos indispensables para la definición de procesos y relaciones entre ellos.procesos y relaciones entre ellos.

6. Integrar los elementos para la administración 6. Integrar los elementos para la administración de proyectos en un solo proceso.de proyectos en un solo proceso.

7. Integrar los elementos para la ingeniería de 7. Integrar los elementos para la ingeniería de productos de software en un solo marco que productos de software en un solo marco que incluya los procesos de soporte (verificación, incluya los procesos de soporte (verificación, validación, documentación y control de validación, documentación y control de configuración).configuración).

8. Destacar la importancia de la gestión de 8. Destacar la importancia de la gestión de recursos, en particular los que componen la base recursos, en particular los que componen la base de conocimiento de la organización tales como:de conocimiento de la organización tales como:

productos generados por proyectos, datos de los productos generados por proyectos, datos de los proyectos, incluyendo las mediciones, proyectos, incluyendo las mediciones, documentación de procesos y los datos documentación de procesos y los datos recaudados a partir de su uso y lecciones recaudados a partir de su uso y lecciones aprendidas.aprendidas.

9. Basar el modelo de procesos en ISO9000:2000 y 9. Basar el modelo de procesos en ISO9000:2000 y nivel 2 y 3 de CMM® V.1.1. Usar como marco nivel 2 y 3 de CMM® V.1.1. Usar como marco general ISO/IEC 15504 - Software Processgeneral ISO/IEC 15504 - Software Process

Assesment [3] e incorporar las mejores prácticas Assesment [3] e incorporar las mejores prácticas de otros modelos de referencia tales como PMBOK de otros modelos de referencia tales como PMBOK [4], SWEBOK [9] y otros más especializados.[4], SWEBOK [9] y otros más especializados.

Otras formas de trabajoOtras formas de trabajo

Método japonés:Método japonés: Pirámide. Arriba : directivosPirámide. Arriba : directivos Objetivos claros y precisos, visión y Objetivos claros y precisos, visión y

misión claras. Conseguir compromiso misión claras. Conseguir compromiso con empleados (accionistas)con empleados (accionistas)

Trabajan de por vida en una Trabajan de por vida en una empresa.empresa.

Cap. 2 Componentes clavesCap. 2 Componentes claves

Componentes clave.. En Componentes clave.. En subsistemassubsistemas

Componentes clave MSComponentes clave MS

El modelo que se propone está enfocado en El modelo que se propone está enfocado en procesos y considera los tres niveles básicos de la procesos y considera los tres niveles básicos de la estructura de una organización que son: la Altaestructura de una organización que son: la Alta

Dirección, Gestión y Operación. El modelo Dirección, Gestión y Operación. El modelo pretende apoyar a las organizaciones en la pretende apoyar a las organizaciones en la estandarización de sus prácticas, en la evaluación estandarización de sus prácticas, en la evaluación de su efectividad y en la integración de la mejora de su efectividad y en la integración de la mejora continuacontinua

Componente Clave: Componente Clave: Planeación2Planeación2

Requerimos varios planes:Requerimos varios planes: 1.Plan estratégico (inicial)1.Plan estratégico (inicial) 2. Plan de recursos2. Plan de recursos 3. Plan de riesgos 3. Plan de riesgos 4. Plan de comunicación…4. Plan de comunicación…

PMBOOKPMBOOK El plan de gestión del proyecto documenta el conjunto de salidas de los procesos de planificación del Grupo de Procesos de Planificación e incluye: El plan de gestión del proyecto documenta el conjunto de salidas de los procesos de planificación del Grupo de Procesos de Planificación e incluye:

• • Los procesos de dirección de proyectos seleccionados por el equipo de dirección del proyecto Los procesos de dirección de proyectos seleccionados por el equipo de dirección del proyecto

• • El nivel de implementación de cada proceso seleccionado El nivel de implementación de cada proceso seleccionado

• • Las descripciones de las herramientas y técnicas que se utilizarán para llevar a cabo esos procesos. Las descripciones de las herramientas y técnicas que se utilizarán para llevar a cabo esos procesos.

• • Cómo se utilizarán los procesos seleccionados para dirigir el proyecto específico, incluidas las dependencias y las interacciones entre esos Cómo se utilizarán los procesos seleccionados para dirigir el proyecto específico, incluidas las dependencias y las interacciones entre esos procesos, y las entradas y salidas esenciales. procesos, y las entradas y salidas esenciales.

• • Cómo se ejecutará el trabajo para alcanzar los objetivos del proyecto Cómo se ejecutará el trabajo para alcanzar los objetivos del proyecto

• • Cómo se supervisarán y controlarán los cambios Cómo se supervisarán y controlarán los cambios

• • Cómo se realizará la gestión de la configuración Cómo se realizará la gestión de la configuración

• • Cómo se actualizará y usará la integridad de las líneas base para la medición del rendimiento Cómo se actualizará y usará la integridad de las líneas base para la medición del rendimiento

• • La necesidad y las técnicas para la comunicación entre los interesados La necesidad y las técnicas para la comunicación entre los interesados

• • El ciclo de vida del proyecto seleccionado y, para los proyectos de múltiples fases, las fases del proyecto relacionadas El ciclo de vida del proyecto seleccionado y, para los proyectos de múltiples fases, las fases del proyecto relacionadas

• • Las revisiones clave de dirección acerca del contenido, la extensión y la oportunidad para facilitar la gestión de polémicas sin resolver y decisiones Las revisiones clave de dirección acerca del contenido, la extensión y la oportunidad para facilitar la gestión de polémicas sin resolver y decisiones pendientes pendientes

PMBOOKPMBOOK

planes subsidiarios y otros componentes. Cada uno de los planes subsidiarios y componentes se detallan en la medida planes subsidiarios y otros componentes. Cada uno de los planes subsidiarios y componentes se detallan en la medida en que lo exija el proyecto específico. Estos planes subsidiarios pueden incluir, entre otros: en que lo exija el proyecto específico. Estos planes subsidiarios pueden incluir, entre otros:

• • Plan de gestión del alcance del proyecto (Sección 5.1.3.1) Plan de gestión del alcance del proyecto (Sección 5.1.3.1) • • Plan de gestión del cronograma (introducción del Capítulo 6) Plan de gestión del cronograma (introducción del Capítulo 6) • • Plan de gestión de costes (introducción del Capítulo 7) Plan de gestión de costes (introducción del Capítulo 7) • • Plan de gestión de calidad (Sección 8.1.3.1). Plan de gestión de calidad (Sección 8.1.3.1). • • Plan de mejoras del proceso (Sección 8.1.3.4) Plan de mejoras del proceso (Sección 8.1.3.4) • • Plan de gestión de personal (Sección 9.1.3.3). Plan de gestión de personal (Sección 9.1.3.3). • • Plan de gestión de las comunicaciones (Sección 10.1.3.1) Plan de gestión de las comunicaciones (Sección 10.1.3.1) • • Plan de gestión de riesgos (Sección 11.1.3.1) Plan de gestión de riesgos (Sección 11.1.3.1) • • Plan de gestión de las adquisiciones (Sección 12.1.3.1). Plan de gestión de las adquisiciones (Sección 12.1.3.1). Estos otros componentes incluyen, entre otros: Estos otros componentes incluyen, entre otros: • • Lista de hitos (Sección 6.1.3.3). Lista de hitos (Sección 6.1.3.3). • • Calendario de recursos (Sección 6.3.3.4). Calendario de recursos (Sección 6.3.3.4). • • Línea base del cronograma (Sección 6.5.3.3). Línea base del cronograma (Sección 6.5.3.3). • • Línea base de coste (Sección 7.2.3.1). Línea base de coste (Sección 7.2.3.1). • • Línea base de calidad (Sección 8.1.3.5). Línea base de calidad (Sección 8.1.3.5). • • Registro de Riesgos (Sección 11.2.3.1). Registro de Riesgos (Sección 11.2.3.1).

Pag. 106 de PMBOOKPag. 106 de PMBOOK

Desarrollar plan PBDesarrollar plan PB