INSTITUTO TECNOLGICO DE LEON

ING. SISTEMAS COMPUTACIONALES

Materia: GESTION DE PROYECTOS DE SOFTWARE

TEMA: CMMI (Capability Maturity Model Integration)

Nombre del Alumno(a):

EQUIPOS 6,7 Y 8

LEON, GUANAJUATO, 18 DE SEPTIEMBRE DEL 2013

OBJETIVO
Conocer las diversas caractersticas de diferentes tomas de decisiones ante lo que el control dentro de un proyecto o ramas afines pueden requerir dependiendo del contexto en medida del avance y cumplimiento de diversas tareas en tiempo y forma especificadas dentro del mdulo o proyecto en s.

INTRODUCCION
El CMMI es un enfoque de mejora de procesos que provee a las organizaciones de los elementos esenciales para un proceso efectivo. El CMMI es el Modelo de Madurez de Capacidades Integrado. Fue desarrollado por el SEI (Software Institute). Mide la madurez del desarrollo del software en una escala del

CMMI (Capability Maturity Model Integration /Modelo integrado de capacidad y Madurez)

DEFINICION: Capability Maturity Model Integration (Modelo de Capacidad y Madurez Integrado), es un enfoque de mejora de procesos que provee a las organizaciones de los elementos esenciales para un proceso efectivo. El marco de madurez de los procesos parte de la premisa de gestin: La calidad de un producto o de un sistema es en su mayor parte consecuencia de la calidad de los procesos empleados en su desarrollo y mantenimiento. Desarrollado por el SEI (Instituto de Ingeniera del Software), fundado por el Departamento de Defensa Americano y la Universidad Carnegie Mellon. EVOLUCIN: CMM contiene los elementos esenciales de la efectividad de los procesos desarrollados. Estos elementos fueron desarrollados por Deming, Crosby, Juran y Humphrey. Despus de la creacin del Software Engineering Institute la U.S. Air Force en 1991 recopil las mejores prcticas de desarrollo de software y cre el Capability Maturity Model for Software (SW-CMM).

HISTORIA: 1984 El Congreso del Gobierno Americano aprob la creacin de un organismo de investigacin para el desarrollo de modelos de mejora para los problemas en el desarrollo de los sistemas de software, y evaluar la capacidad de respuesta y fiabilidad de las compaas que suministran software al Departamento de Defensa. 1985 SEI empieza a trabajar en un marco de madurez de procesos que permita evaluar a las empresas productoras de software. La investigacin evoluciona hacia el Modelo de Madurez de las Capacidades (CMM).

1991 En agosto SEI publica la versin 1.0 del Modelo de Madurez de las Capacidades para el Software (SWCMM, Capability Maturity Model for Software).

1993 SEI publica la versin 1.1 de SW-CMM 1997 Publicacin de la versin 1.2 2000 SW-CMM fue integrado y relevado por el nuevo modelo CMMI.

DIMENCIONES CRTICAS Las dimensiones crticas de una empresa son: la gente, los procedimientos y mtodos, y las herramientas y equipo. Los procesos son los encargados de unir tales dimensiones con el propsito de alcanzar los objetivos del negocio. El enfoque en los procesos ayuda a construir una plataforma de mejora continua, ya que se est de acuerdo en que la gente y la tecnologa cambian y son slo los procesos los que transcienden en el tiempo, adaptndose a nuevas personas y tecnologas.

REPRESENTACION

El CMMI tiene dos representaciones: 1. 2. Por Etapas (Staged) Continuo (Continuous)

Estas representaciones permiten a la organizacin perseguir diferentes objetivos de mejora.

REPRESENTACIN CONTNUA 1. 2. 3. 4. Administracin de Procesos Administracin de Proyectos Ingeniera Soporte

REPRESENTACIN POR ETAPAS 1. 2. 3. 4. Nivel de Madurez 2 Nivel de Madurez 3 Nivel de Madurez 4 Nivel de Madurez 5

REPRESENTACION POR ETAPAS: 1. Un nivel de madurez es una etapa evolutiva bien definida en el camino para convertirse en una organizacin madura. Cada nivel de madurez tiene una serie de reas de proceso y un objetivo genrico. Dado que los niveles de madurez superiores se fundamentan en los niveles inferiores, los niveles inferiores no pueden evitarse.

2. 3.

Niveles de Madurez (por Etapas) 1. 2. 3. 4. 5. Nivel 1 (Inicial): El proceso es impredecible, es reactivo y pobremente controlado. Nivel 2 (Administrado): El proceso es reactivo y se caracteriza por su aplicacin a proyectos. Nivel 3 (Definido): El proceso es proactivo y se ve a nivel de la organizacin. Nivel 4 (Administrado Cuantitativamente): El proceso es medido y controlado. Nivel 5 (Optimizado): El proceso se enfoca en la mejora continua.

Niveles de Madurez (Continuo) 1. 2. Nivel 0 (incompleto): El proceso no se ejecuta o se hace parcialmente. Nivel 1 (Ejecutado): El proceso se ejecuta y se producen productos basados en productos de entrada identificados. Nivel 2 (Administrado): El proceso es reactivo y se caracteriza por su aplicacin a proyectos. Nivel 3 (Definido): El proceso es proactivo y se ve a nivel de la organizacin. Nivel 4 (Administrado Cuantitativamente): El proceso es medido y controlado. Nivel 5 (Optimizado): El proceso se enfoca en la mejora continua.

3. 4. 5. 6.

REAS DE PROCESO
Un rea de proceso (PA) es un grupo de prcticas relacionadas que colectivamente ayudan a alcanzar un conjunto de metas. Cada rea de proceso reside en un nivel de madurez.

1. 2. 3. 1. 1. 1. 2. 3. 4. 5. 1. 1. 1. 1. 2. 1. 2. 1. 2. 1. 2.

CAR. Causal Analysis and Resolution CM. Configuration Management DAR. Decision Analysis and Resolution IPM. Integrated Project Management + IPPD MA. Measurement and Analysis OID. Organizational Innovation and Deployment OPD. Organizational Process Definition + IPPD OPP. Organizational Process Performance OPF. Organizational Process Focus OT. Organizational Training PI. Product Integration PP. Project Planning PPQA. Process and Product Quality Assurance PMC. Project Monitoring and Control QPM. Quantitative Project Management RD. Requirements Develpment REQM. Requirements Management RSKM. Risk Management SAM. Supplier Agreement Management TS. Technical Solution VAL. Validation

3.

VER. Verification

1.

Administracin de Procesos Administracin de Proyectos Ingeniera Soporte

Nivel 2 Nivel 3 Nivel 4 Nivel 5

1. 1. 1.

OBJETIVOS ESPECFICOS
Un objetivo especfico (SG), son las metas de un rea de proceso, muestra la capacidad tcnica del proceso.

CMMI POR ETAPAS REAS DE PROCESO DE NIVEL 2

Objetivos y Prcticas Genricas GG 2 Institucionalizar un proceso administrado El proceso es institucionalizado como un proceso administrado (Administrado) 1. Requirements Management (REQM) 2. Project Planning (PP) 3. Project Monitoring and Control (PMC) 4. Supplier Agreement Management (SAM) 5. Measurement and Analysis (M&A) 6. Process and Product Quality Assurance 7. (PPQA) 8. Configuration Management (CM)

GP 2.1 Establecer una poltica organizacional Establecer y mantener una poltica organizacional para la planeacin y desempeo del proceso. GP 2.2 Planear el proceso Establecer y mantener el plan para llevar a cabo el proceso. GP 2.3 Proveer recursos Proveer los recursos adecuados para llevar a cabo el proceso, desarrollo de productos de trabajo y prestacin de servicios del proceso.

GP 2.4 Asignar responsabilidades

Asignar responsabilidad y autoridad para llevar a cabo los procesos, desarrollo de productos de trabajo y prestacin de servicios del proceso. GP 2.5 Capacitar a la gente Capacitar a la gente para llevar a cabo o apoyar el proceso tanto como sea necesario. GP 2.6 Administrar la configuracin Asignar un lugar para los productos de trabajo y proceso bajo un nivel de control apropiado. GP 2.7 Identificar e involucrar a los stakeholders relevantes Identificar e involucrar a los stakeholders relevantes del proceso segn lo planeado. GP 2.8 Monitorear y controlar el proceso Monitorear y controlar el proceso contra el plan para llevar a cabo el proceso y hacer acciones correctivas apropiadas. GP 2.9 Evaluar objetivamente la adherencia Evaluar objetivamente la adherencia al proceso contra la descripcin de ste proceso, estndares y procedimientos y abordar los no cumplimientos. GP 2.10 Revisar el status con direccin Revisar las actividades, status y resultados del proceso con direccin y resolver errores.

Nivel 3 (Definido)
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Requirements Development (RD) Technical Solution (TS) Product Integration (PI) Verification (VER) Validation (VAL) Organization Process Focus (OPF) Organization Process Definition (OPD) Organizational Training (OT) Integrated Project Management for IPPD (IPPD) Risk Management (RSKM) Integrated Teaming (IT) Decision Analysis and Resolution (DAR) Organizational Environment for Integration (OEI)

Nivel 4 (Administrado Cuantitativamente)

1. 2. Organizational Process Performance (OPP) Quantitative Project Management (QPM)

Nivel 5 (Optimizado)
1. 2. Organizational Innovation and Deployment (OID) Causal Analysis and Resolution (CAR)

CMMI CONTINUO Administracin de Procesos

1. 2. 3. 4. 5. Organization Process Focus (OPF) Organization Process Definition (OPD) Organizational Training (OT) Organizational Process Performance (OPP) Organizational Innovation and Deployment (OID)

6.

Administracin de Proyectos
1. 2. 3. 4. 5. 6. 7. 8. 9. Project Planning (PP) Project Monitoring and Control (PMC) Supplier Agreement Management (SAM) Integrated Project Management for IPPD (IPPD) Risk Management (RSKM) Integrated Teaming (IT) Integrated Supplier Management (IPM) Quantitative Project Management (QPM)

Ingeniera
1. 2. 3. 4. 5. 6. Requirements Management (REQM) Requirements Development (RD) Technical Solution (TS) Product Integration (PI) Verification (VER) Validation (VAL)

Cul Seleccionar? Continuo

Nos centramos en los problemas, mitigacin de riesgos y en lo que le interesa a los objetivos de la organizacin. Permite la comparacin entre reas de proceso. Permite una comparacin contra el modelo ISO 15504.

Por Etapas
Provee una secuencia de las mejoras desde la administracin bsica hasta niveles de alta madurez. Permite a la comparacin entre organizaciones por los niveles de madurez. Provee un solo indicador que permite la comparacin entre organizaciones.

REQM
Propsito El propsito de Administracin de Requerimientos (REQM) es administrar los requerimientos de los productos del proyecto y componentes del producto e identificar inconsistencias entre requerimientos y planes del proyecto y productos de trabajo Objetivos y Prcticas Especficas SG 1 Administracin de Requerimientos El proyecto mantiene una actualizacin de los requerimientos aprobados a lo largo de la vida del proyecto de la siguiente manera: 1. 2. 3. 4. Administrar los cambios en los requerimientos Mantener relacionados los requerimientos, el plan del proyecto y los productos de trabajo Identificar inconsistencias Tomar acciones correctivas

SP 1.1 Obtener un entendimiento de los requerimientos Desarrollar un entendimiento con el proveedor de requerimientos sobre el significado de los requerimientos. Subprcticas: 1. 2. 3. 4. Establecer un criterio para distinguir los proveedores de requerimientos Establecer criterios para evaluar y aceptar los requerimientos Analizar que los criterios establecidos se cumplan Llegar a un entendimiento con el proveedor de requerimientos y todos los participantes del proyecto para que todos se comprometan

Productos de Trabajo Tpicos: 1. 2. 3. 4. Lista de criterios para distinguir a los proveedores de requerimientos apropiados Criterios para evaluar y aceptar los requerimientos Resultado del anlisis de criterios Una lista de requerimientos

SP 1.2 Obtener un compromiso con los requerimientos Obtener un compromiso con los requerimientos por parte de los participantes del proyecto. Subprcticas: 1. 2. Evaluar el impacto de los requerimientos segn los compromisos Negociar y registrar los compromisos

Productos de Trabajo Tpicos: 1. 2. Evaluaciones en el impacto de requerimientos Documentar compromisos y cambios de los requerimientos

SP 1.3 Administrar cambios en los requerimientos Administrar los cambios y evolucin de los requerimientos durante el proyecto. Subprcticas: 1. Documentar todos los requerimientos y sus cambios que se han dado o generado durante el proyecto Mantener un historial de los cambios de requerimientos y su justificacin Evaluar el impacto de los cambios en los requerimientos desde el punto de vista de los integrantes relevantes Hacer que los requerimientos y los cambios sean datos disponibles en el proyecto

2. 3.

4.

Productos de Trabajo Tpicos: 1. 2. 3. Status de requerimientos Base de datos de requerimientos Base de datos de decisin de los requerimientos

SP 1.4 Mantener un rastreo bidireccional de los requerimientos Mantener una rastreabilidad bidireccional entre los requerimientos, el plan de proyecto y los productos de trabajo.

Subprcticas: 1. Establecer la rastreabilidad de requerimientos para asegurar que la fuente de los niveles inferiores de los requerimientos fueron documentados Mantener la rastreabilidad desde los requerimientos principales hasta los derivados as como para la localizacin de funciones, objetos, personas, procesos y productos de trabajo Generar la matriz de rastreo de requerimientos

2.

3.

Productos de Trabajo Tpicos: 1. 2. Matriz de trazabilidad de requerimientos Sistema de seguimiento de requerimientos

SP 1.5 Identificar inconsistencias entre el proyecto y los requerimientos Encuentra inconsistencias entre los requerimientos planes del proyecto y productos de trabajo. Subprcticas: 1. Revisar el plan de proyecto, actividades y productos de trabajo para rastrear inconsistencia en los requerimientos y los cambios hechos. Identificar la fuente de la inconsistencia y la justificacin Identificar los cambios que deben hacerse a los planes de trabajo y los productos resultantes de cambios en los requerimientos de la lnea base Iniciar acciones correctivas

2. 3.

4.

Productos de Trabajo Tpicos: 1. 2. Documentacin de inconsistencias incluyendo fuentes, condiciones y relaciones Acciones correctivas

PPQA (PROCESS AND PRODUCT QUALITY ASSURANCE)

Propsito
El propsito de Aseguramiento de Calidad en Procesos y Productos (PPQA) es proporcionar el personal y administracin con objetivo de asociar los procesos y productos de trabajo. Es una de las ocho reas de proceso presentes en todas las constelaciones de CMMI (adquisicin, servicios y desarrollo). Es un rea del proceso de soporte, de nivel de madurez. En algunas ocasiones la PPQA dentro de CMMi es el estmulo a las iniciativas de mejora de proceso como identificar los productos no conformes, defectos, y utilizando anlisis casual y resolucin (CAR) identificar las actividades que ocasionaron estos defectos

Objetivos y Prcticas Especficas

1. 2. SG 1 Evaluar objetivamente los procesos y productos de trabajo La adherencia a los procesos, productos de trabajo y servicios son aplicables a la descripcin de procesos, estndares y procedimientos y son evaluados objetivamente. La objetividad de las evoluciones en el PPQA es fundamental para el xito del proyecto. La objetividad se logra mediante la independencia y la utilizacin de criterios. Una combinacin de mtodos que proporcionan evaluaciones versus los criterios de los que no estn involucrados en la produccin es de uso frecuente

3. 4.

Aspectos involucrados:
1. Evaluar objetivamente los procesos realizados, productos de trabajo, y servicios contra las descripciones de procesos, normas y procedimientos. Identificar y documentar las cuestiones de incumplimiento. Proporcionar comentarios de los resultados de las actividades de aseguramiento de la calidad al personal y directores del proyecto. Asegurar que las cuestiones de falta de cumplimiento se aborden

2. 3.

4.

Evaluar objetivamente los procesos

1. La objetividad en las evaluaciones de aseguramiento de la calidad es fundamental para el xito del proyecto. Una descripcin de la garanta de la calidad de la cadena de presentacin de informes y cmo se garantiza la objetividad debe ser definido.

Subprcticas:
1. Promover un medio ambiente (creado como parte de la gestin del proyecto) que fomenta la participacin de los trabajadores en la identificacin y presentacin de informes relacionados con la calidad Establecer y mantener claramente los criterios para las evaluaciones Utilice los criterios establecidos para evaluar los procesos realizados para la adhesin al proceso con las descripciones, normas y procedimientos Identificar cada incumplimiento detectado durante la evaluacin Identificar las lecciones aprendidas que puedan mejorar los procesos para los futuros productos y servicios

2. 3.

4. 5.

Evaluar objetivamente los procesos

1. Productos de Trabajo Tpicos: 1. 2. 3. Reportes de evaluacin Reportes de no conformidades Acciones correctivas

Evaluar objetivamente los productos y servicios de trabajo

1. Evaluar objetivamente los productos y servicios de trabajo contra la descripcin de los procesos aplicables, estndares y procedimientos

Sub-prcticas:
1. Seleccionar los productos de trabajo a ser evaluados, basados sobre criterios de muestreo documentados si se utiliza el muestreo Establecer y mantener claramente los criterios para la evaluacin de los productos de trabajo Usar los criterios establecidos durante las evaluaciones de productos de trabajo Evaluar los productos de trabajo antes de que se entregan al cliente Evaluar determinados productos en los hitos durante el desarrollo Revisar el progreso o evaluaciones incrementales de los productos de trabajo y servicios contra las descripciones de proceso, normas y procedimientos Identificar cada caso de no conformidad durante las evaluaciones Identificar las lecciones aprendidas para mejorar procesos para productos o servicios futuros

2. 3. 4. 5. 6.

7. 8.

Productos de trabajos tpicos

2. 3. 4. Reportes de evaluacin Reportes de no conformidades Acciones correctivas

SG 2 Proporcionar conocimientos objetivamente

Problemas de inconformidad son objetivamente rastreadas y comunicadas, de forma que una resolucin es asegurada.

SP 2.1 Comunicar y asegurar la solucin de no conformidades de los criterios

Esto debe comunicarse a staff y encargados. Los problemas de inconformidad son aquellos identificados en evaluaciones que reflejan la falta de adherencia a estndares aplicables. Cuando los problemas de inconformidad no pueden resolverse localmente, utilizar los mecanismos de ascendencia para asegurar el nivel apropiado de control.

Sub-prcticas:
1. 2. 3. Resolver cada inconformidad con los miembros apropiados del staff cuando sea posible Documentar la no conformidad de criterios cuando no se pueden resolver Escalar las no conformidades de criterios que no pueden ser resueltos con los miembros apropiados del equipo hacia niveles de administracin apropiados para actuar en caso de no cumplimientos de criterios Analizar el no cumplimiento de criterios para ver alguna tendencia de calidad que se pueda identificar y dirigir Asegurarse que los involucrados relevantes son consientes de los resultados de las evaluaciones de tendencias de calidad oportunamente Hacer revisiones peridicas de los no cumplimientos de criterios y tendencias con la administracin para actuar en el caso de no cumplimento de criterios Dar seguimiento a los no cumplimientos de criterios y su resolucin

4. 5. 6. 7.

Productos de trabajos tpicos

1. 2. 3. Reportes de acciones correctivas Reportes de evaluacin Tendencias de calidad (Quality trends)

SP 2.2 Establecer Registros

Establecer y mantener registros de las Actividades de aseguramiento de calidad (AAC)

Sub-prcticas:
1. 2. Registrar el proceso y actividades de aseguramiento de calidad con suficiente detalle de tal manera que los estatus y resultados se muestren. Revisar el status y el historial de las actividades de aseguramiento de calidad tanto como sea necesario

Productos de trabajos tpicos

1. 2. 3. 4. Evaluacin inicial Reportes de aseguramiento de calidad Reportes de status de acciones correctivas Reportes de tendencias de calidad

PP (Planificacin del Proyecto)

Planificacin del Proyecto (PP) establece los objetivos del proyecto y el curso se espera que el proyecto dado a tomar con el fin de satisfacer sus objetivos. Esta actividad incluye la planificacin de alcance y seleccin del SDLC adecuado para cumplir con los objetivos fijados. Estimando tambin forma una parte vital del proceso de planificacin con el fin de que los recursos adecuados (incluyendo humanos) pueden ser programados en el momento adecuado en el ciclo de vida de los proyectos. Este proceso es un requisito previo para la Vigilancia y Control de Proyectos (PMC) que comprueba el progreso proyectos en contra de su plan general. El rea de Gestin de Proyectos en Proceso de Madurez Nivel 2 Propsito El propsito de Planificacin del Proyecto (PP) es establecer y mantener planes que definen las actividades del proyecto. El rea de proceso Planificacin del Proyecto consiste en lo siguiente: 1. 2. 3. 4. Desarrollar el plan del proyecto La interaccin con las partes interesadas debidamente Conseguir el compromiso con el plan de Mantener el plan

La planificacin comienza con los requisitos que definen el producto y el proyecto. Planificacin incluye la estimacin de los atributos de los productos de trabajo y tareas, la determinacin de los recursos necesarios, la negociacin de compromisos, la produccin de un horario, y la identificacin y el anlisis de riesgos del proyecto. Iterar a travs de estas actividades puede ser necesario para establecer el plan de proyecto. El plan del proyecto es la base para la realizacin y el control de las actividades de proyectos que aborden los compromisos con el cliente proyectos. El plan del proyecto por lo general tendr que ser revisadas a medida que avanza el proyecto para hacer frente a los cambios en los requisitos y compromisos, estimaciones inexactas, acciones correctivas y cambios en el proceso. Las prcticas especficas que describen la planificacin y re planificacin figuran en esta rea de proceso. El plan del proyecto se utiliza el trmino en todas las prcticas genricas y especficas en esta rea de proceso para hacer referencia al plan general para el control del proyecto. reas de proceso relacionadas Consulte los Requisitos Desarrollo rea de proceso para obtener ms informacin sobre el desarrollo de los requisitos que definen el producto y los componentes del producto. Del producto y requisitos de los componentes del producto y los cambios en los requisitos sirven de base para la planificacin y re planificacin. Consulte el rea de proceso de Gestin de Requisitos para obtener ms informacin acerca de cmo administrar los requisitos necesarios para la planificacin y re planificacin. Consulte el rea de proceso de Gestin de Riesgo para ms informacin sobre cmo identificar y la gestin de riesgos. Refirase al rea de proceso Solucin

Tcnica para obtener ms informacin acerca de la transformacin de las necesidades en productos y soluciones de componentes de productos.

Prcticas especficas por meta SG 1 Establecer Estimaciones Las estimaciones de los parmetros de planificacin del proyecto se establecen y mantienen. Parmetros de planificacin del proyecto incluye toda la informacin que necesita el proyecto para llevar a cabo la necesaria planificacin, organizacin, dotacin de personal, direccin, coordinacin, elaboracin de informes y presupuestos. Las estimaciones de los parmetros de planificacin deben tener una base slida para infundir confianza en que los planes basados en estas estimaciones son capaces de apoyar los objetivos del proyecto. Los factores que normalmente se consideran al calcular estos parmetros son los siguientes: 1. Requisitos del proyecto, incluidos los requisitos de los productos, los requisitos impuestos por la organizacin, los requisitos impuestos por el cliente, y otros requisitos que afectan al proyecto Alcance del proyecto Tareas identificadas y productos de trabajo Enfoque tcnico Modelo de ciclo de vida del proyecto seleccionado (por ejemplo, cascada, incremental o espiral) Los atributos de los productos de trabajo y tareas (por ejemplo, el tamao o la complejidad) Programar Modelos o datos histricos para la conversin de los atributos de los productos de trabajo y tareas en las horas de trabajo y costo Metodologa (por ejemplo, modelos, datos, algoritmos) que se utiliza para determinar el material necesario, las habilidades, las horas de trabajo y costo

2. 3. 4. 5. 6. 7. 8. 9.

Se requiere documentacin de los fundamentos de estimacin y los datos de apoyo para que los interesados revisin y compromiso con el plan y para el mantenimiento del plan a medida que avanza proyecto.

SP 1.1 Estimar el alcance del proyecto de Establecer una estructura de desglose de trabajo de nivel superior (WBS) para estimar el alcance del proyecto. La EDT evoluciona con el proyecto. Inicialmente un PEP de nivel superior puede servir para estructurar la estimacin inicial. El desarrollo de una EDT divide el proyecto en su conjunto en un conjunto interconectado de componentes manejables. Por lo general, la WBS es una estructura orientada producto que proporciona un esquema para identificar y organizar las unidades lgicas de trabajo a cargo de la gestin, que se denominan los paquetes de trabajo. La EDT proporciona una referencia y un mecanismo de organizacin para la asignacin de esfuerzo, la programacin y la

responsabilidad y se utiliza como marco fundamental para planificar, organizar y controlar el trabajo realizado en el proyecto. Algunos proyectos utilizan el trmino PEP contrato para referirse a la parte de la EDT puesto bajo contrato (posiblemente toda la WBS). No todos los proyectos tienen una EDT contrato (por ejemplo, el desarrollo financiado internamente). Productos de trabajo tpicos: 1. 2. 3. Descripciones de tareas Trabaja descripciones de los paquetes PEP

SP 1.2 Establecer estimaciones de trabajo y los atributos de la tarea Establecer y mantener las estimaciones de los atributos de los productos de trabajo y tareas. Tamao es la entrada principal para muchos modelos utilizados para estimar el esfuerzo, costo y horario. . Los modelos tambin pueden basarse en insumos tales como conectividad, complejidad y estructura de los ejemplos de los tipos de productos de trabajo para los que se hicieron estimaciones de tamao son las siguientes: 1. 2. 3. Productos entregables y el trabajo no entregable Los documentos y archivos Hardware, firmware y software operativo y de apoyo

Ejemplos de medidas de tamao son las siguientes: 1. Nmero de funciones 2. Los puntos de funcin 3. Lneas de cdigo fuente 4. Nmero de clases y objetos 5. Nmero de los requisitos 6. El nmero y la complejidad de interfaces 7. Nmero de pginas 8. Nmero de entradas y salidas 9. Nmero de elementos de riesgo tcnico 10. Volumen de datos 11. Nmero de puertas lgicas para circuitos integrados 12. Cantidad de piezas (por ejemplo, tarjetas de circuitos impresos, componentes y piezas mecnicas) 13. Limitaciones fsicas (por ejemplo, peso y volumen) Las estimaciones debern ser coherentes con los requisitos del proyecto para determinar el esfuerzo de los proyectos, el costo y horario. A nivel relativo de dificultad o complejidad se debe asignar para cada atributo de tamao. Productos de trabajo tpicos 1. 2. 3. 4. Enfoque tcnico El tamao y la complejidad de las tareas y productos de trabajo Modelos de estimacin Estimaciones de atributos

SP 1.3 Definicin del ciclo de vida del proyecto Definir las fases del ciclo de vida del proyecto en el que se alcance el esfuerzo de planificacin. La determinacin de los proyectos a las fases del ciclo de vida proporciona por perodos previstos de evaluacin y toma de decisiones. Estos se definen normalmente para apoyar los puntos de decisin lgica en la que se hicieron importantes compromisos en materia de recursos y el informe tcnico. Estos puntos proporcionan actos programados en el que se pueden hacer correcciones y determinaciones del alcance y costo del curso futuro del proyecto. Las fases del ciclo de vida del proyecto se deben definir en funcin del alcance de las necesidades, las estimaciones de los recursos del proyecto, y la naturaleza del proyecto. Los proyectos ms grandes pueden contener varias fases, como la exploracin de concepto, desarrollo, produccin, operaciones y disposicin. Dentro de estas fases, puede ser necesario subfases. Una fase de desarrollo puede incluir subfases como el anlisis de requerimientos, diseo, fabricacin, integracin y verificacin. La determinacin de las fases del proyecto tpicamente incluye la seleccin y el refinamiento de uno o ms modelos de desarrollo para abordar las interdependencias y la secuenciacin apropiada de las actividades en las fases. Dependiendo de la estrategia para el desarrollo, puede haber fases intermedias para la creacin de prototipos, incrementos de la capacidad o ciclos modelo espiral. Comprender el ciclo de vida del proyecto es crucial para determinar el alcance de la labor de planificacin y el momento de la planificacin inicial, as como el calendario y los criterios (hitos crticos) para la re planificacin. Productos de trabajo tpicos: 1. Fases del ciclo de vida del proyecto SP 1.4 Determinar estimaciones de esfuerzo y el coste Estimado del esfuerzo del proyecto y el costo de los productos de trabajo y tareas basadas en lgica de estimacin. Las estimaciones de esfuerzo y los costes se basan generalmente en los resultados del anlisis con modelos o datos histricos aplicados a la medida, las actividades y otros parmetros de planificacin. La confianza en estas estimaciones se basa en el fundamento para el modelo seleccionado y la naturaleza de los datos. Puede haber ocasiones en las que los datos histricos disponibles, no se aplican, por ejemplo, cuando los esfuerzos no tienen precedentes o cuando el tipo de tarea no se ajusta a los modelos disponibles. Un esfuerzo sin precedentes (hasta cierto punto) si un producto o componente similar no se ha construido. Un esfuerzo tambin puede ser sin precedentes si el grupo de desarrollo nunca ha construido un producto o componente. Esfuerzos sin precedentes son ms riesgosos, requieren ms investigaciones para desarrollar bases razonables de estimacin, y requieren ms gestin de reservas. La singularidad del proyecto debe ser documentada cuando se utilizan estos modelos para asegurar un entendimiento comn de las suposiciones hechas en las etapas iniciales de planificacin. Productos de trabajo tpicos: 1. Justificacin Estimacin 2. Estimaciones de esfuerzo del proyecto 3. Estimaciones de los costos del proyecto SG 2 Desarrollar un plan de proyecto de Un plan de proyecto se establece y se mantiene como base de la gestin del proyecto. Un plan de proyecto es un documento formal, aprobado utilizado para gestionar y controlar la ejecucin del

proyecto. Se basa en los requisitos del proyecto y las estimaciones establecidas. El plan del proyecto debe tener en cuenta todas las fases del ciclo de vida del proyecto. La planificacin del proyecto debe asegurarse de que todos los planes que afectan al proyecto son consistentes con el plan general del proyecto. SP 2.1 Establecer el presupuesto y horario Establecer y mantener el presupuesto de los proyectos y la programacin. El presupuesto de los proyectos y el programa se basan en las estimaciones desarrolladas y garantizar que la asignacin presupuestaria, la complejidad de la tarea y las dependencias entre tareas se abordan adecuadamente. event-driven , horarios de recursos limitados han demostrado ser eficaces en el tratamiento de los riesgos del proyecto. La identificacin de los logros que se manifestaron antes del inicio del evento proporciona cierta flexibilidad en el momento del evento, un entendimiento comn de lo que se esperaba, una mejor visin de la situacin del proyecto y un estatus ms preciso de las tareas de los proyectos. Productos de trabajo tpicos: 1. Project programa 2. Horario dependencias 3. Presupuesto del proyecto

SP 2.2 Identificar los riesgos del proyecto Identificar y analizar los riesgos del proyecto. Refirase al rea de proceso de Gestin de Riesgo para ms informacin acerca de las actividades de gestin de riesgos. Consulte los riesgos del proyecto Monitor de la prctica concreta en el seguimiento del proyecto y rea de proceso de control para obtener ms informacin acerca de las actividades de control de riesgos. Los riesgos se identifican o descubiertos y analizados para apoyar la planificacin del proyecto. Esta prctica especfica debe extenderse a todos los planes que afectan al proyecto para garantizar que la interconexin adecuada tiene lugar entre todas las partes interesadas sobre los riesgos identificados. Proyecto de identificacin de riesgos y el anlisis de la planificacin general incluyen lo siguiente: 1. 2. 3. Identificacin de los riesgos El anlisis de los riesgos para determinar el impacto, la probabilidad de ocurrencia y el marco temporal en el que los problemas tienden a ocurrir Priorizar los riesgos

Productos de trabajo tpicos 1. Los riesgos identificados 2. Impactos de riesgo y probabilidad de ocurrencia 3. Prioridades de Riesgo

SP 2.3 del Plan de Gestin de Datos Plan para la gestin de datos del proyecto. Adicin IPPD Cuando se forman los equipos integrados, los datos del proyecto incluye datos desarrollados y utilizados exclusivamente dentro de un equipo en particular, as como datos de aplicacin a travs de lmites de equipo integrado, si hay varios equipos integrados. Los datos son los diferentes tipos de documentacin necesarios para apoyar un programa en todas sus reas (por ejemplo, administracin, ingeniera, gestin de configuracin, finanzas, logstica, calidad, seguridad, produccin y adquisiciones). Los datos pueden adoptar cualquier forma (por ejemplo, informes, manuales, cuadernos, cartas, dibujos, especificaciones, archivos y correspondencia). Los datos pueden existir en cualquier tipo de soporte (por ejemplo, impreso o dibujado en diversos materiales, fotografas, electrnicos o multimedia). Los datos se pueden suministrar (por ejemplo, los artculos identificados por unos programas de necesidades de datos del contrato) o los datos pueden ser entregable (por ejemplo, datos informales, estudios comerciales y de anlisis, actas de reuniones internas, documentacin interna de revisin de diseo, lecciones aprendidas y elementos de accin) . La distribucin puede tomar muchas formas, incluyendo la transmisin electrnica. Los requisitos de datos para el proyecto deben establecerse tanto para los elementos de datos que se crear y su contenido y forma, a partir de un conjunto comn o estndar de los datos necesarios. Contenido y formato de los requisitos uniformes para los elementos de datos facilitan la comprensin del contenido de los datos y ayudan a la gestin coherente de los recursos de datos. La razn para la recogida de cada documento debe ser clara. Esta labor incluye el anlisis y la verificacin de los resultados del proyecto y no deliberables, contratos y solicitudes de datos sin contrato, y los datos suministrados por el cliente. A menudo, los datos se recogen con una comprensin clara de cmo se va a utilizar. De datos es costoso y se debe recoger slo cuando sea necesario. Productos de trabajo tpicos: 1. Plan de gestin de datos 2. Lista maestra de los datos gestionados 3. Contenido y el formato de datos Descripcin 4. Datos de las listas de requisitos para compradores como para proveedores 5. Requisitos de privacidad 6. Los requisitos de seguridad 7. Los procedimientos de seguridad 8. Mecanismo de recuperacin de datos, la reproduccin y distribucin 9. Calendario para la coleccin de datos del proyecto 10. Ficha de datos del proyecto a cobrar SP 2.4 del Plan de Recursos del Proyecto Plan de los recursos necesarios para llevar a cabo el proyecto. Adems IPPD Cuando se forman los equipos integrados, la planificacin de los recursos del proyecto debe considerar la dotacin de personal de los equipos integrados. Definicin de los recursos del proyecto (mano de obra, maquinaria / equipos, materiales y mtodos) y las cantidades necesarias para llevar a cabo las actividades del proyecto se basa en las estimaciones iniciales y proporciona informacin adicional que puede ser aplicado para expandir la EDT utilizado para gestionar el proyecto. La EDT de alto nivel desarrollado anteriormente como mecanismo de estimacin es normalmente ampliado por la

descomposicin de los niveles ms altos en paquetes que representan unidades de trabajo singulares que se pueden asignar por separado, realizacin, seguimiento y trabajo. Esta subdivisin se hace para distribuir la responsabilidad de gestin y ofrecer un mejor control de la gestin. Cada paquete de trabajo o producto del trabajo en el PEP debe asignar un identificador nico (por ejemplo, nmero) para permitir el seguimiento. A PEP puede estar basado en las necesidades, actividades, productos de trabajo, o una combinacin de estos elementos. Un diccionario que describe el trabajo de cada paquete de trabajo en el PEP debe acompaar a la estructura de desglose del trabajo. Productos de trabajo tpicos: 1. EDT paquetes de trabajo 2. Diccionario tarea EDT 3. Necesidades de personal basados en el tamao y alcance del proyecto 4. Las instalaciones crticas / lista de equipos 5. Definiciones y diagramas de procesos / flujos de trabajo 6. Lista de requisitos de administracin del programa

Plan de SP 2.5 para el conocimiento necesario y habilidades Para planificar los conocimientos y habilidades necesarias para llevar a cabo el proyecto. Refirase al rea de proceso de entrenamiento organizacional para obtener ms informacin acerca de los conocimientos y la informacin de las habilidades para ser incorporados en el plan del proyecto. Entrega de conocimientos a los proyectos involucra tanto la formacin del personal del proyecto y la adquisicin de conocimientos de fuentes externas. Necesidades de personal dependen de los conocimientos y habilidades disponibles para apoyar la ejecucin del proyecto. Productos de trabajo tpicos: 1. Inventario de las necesidades de cualificacin 2. Dotacin de personal y nuevos planes de alquiler 3. Bases de datos (por ejemplo, las habilidades y de formacin) SP 2.6 Plan de Participacin de los grupos de inters Plan de la participacin de los grupos de inters identificados. Adicin IPPD Cuando se forman los equipos integrados, participacin de los interesados debe ser planificado a nivel de equipo integrado. Las partes interesadas se identifican a partir de todas las fases del ciclo de vida del proyecto, identificando el tipo de personas y funciones necesidad de la representacin en el proyecto y describir su importancia y el grado de interaccin de las actividades de proyectos especficos. Una matriz de dos dimensiones con las partes interesadas a lo largo de un eje y actividades del proyecto a lo largo del otro eje es un formato conveniente para llevar a cabo esta identificacin. Relevancia de la parte interesada a la actividad en una fase del proyecto en particular y la cantidad de interaccin esperada se muestra en la interseccin de la fase de eje de actividad del proyecto y el eje de las partes interesadas. Para las entradas de los interesados para ser til, la seleccin cuidadosa de los interesados pertinentes es necesario. Para cada una de las principales actividades, identificar a los actores que se ven afectados por la actividad y aquellos que tienen la experiencia que se necesitan para llevar a cabo la actividad. Esta lista de las partes interesadas probablemente cambiar a medida que el proyecto se mueve a travs de las fases del ciclo de vida del proyecto. Es importante, sin

embargo, para garantizar que las partes interesadas en las ltimas fases del ciclo de vida tienen entrada temprana a las necesidades y decisiones de diseo que les afectan. Algunos ejemplos del tipo de material que se debe incluir en un plan para la interaccin de las partes interesadas se incluyen los siguientes: 1. 2. 3. 4. 5. 6. 7. Lista de todos los interesados Justificacin de la participacin de los interesados Roles y responsabilidades de las partes interesadas en relacin con el proyecto, por la fase del ciclo de vida del proyecto Las relaciones entre las partes interesadas Importancia relativa de las partes interesadas para el xito del proyecto, por el ciclo de vida del proyecto de fase Recursos (por ejemplo, capacitacin, materiales, tiempo y financiacin) necesarios para garantizar la interaccin interesados Calendario para la eliminacin progresiva de la interaccin de las partes interesadas

Llevar a cabo esta prctica especfica se basa en la informacin compartida o intercambiada con el anterior Plan de conocimientos necesarios y las habilidades prcticas especficas. Productos de trabajo tpicos: 1. Plan de participacin de los interesados SP 2.7 Establecer el plan de proyecto Establecer y mantener el contenido general del plan del proyecto. Un plan documentado que se ocupa de todos los elementos pertinentes de planificacin es necesaria para lograr el entendimiento mutuo, el compromiso y el desempeo de los individuos, grupos y organizaciones que se deben ejecutar o apoyar los planes. El plan generado para el proyecto define todos los aspectos del esfuerzo, la vinculacin entre s de manera lgica: consideraciones del ciclo de vida del proyecto, las tareas tcnicas y de gestin, presupuestos y cronogramas, hitos, gestin de datos, identificacin de riesgos, los recursos y las aptitudes requeridas, y la identificacin de las partes interesadas y interaccin. Descripciones de infraestructura incluyen la responsabilidad y las relaciones de autoridad del personal del proyecto, la gestin y las organizaciones de apoyo. Para Ingeniera Software Para el software, el documento de planificacin se conoce como una de las siguientes veces: 1. 2. 3. Plan de desarrollo de Software Plan de proyecto de software Plan de Software

En Ingeniera de Hardware Para el hardware, el documento de planificacin se conoce como un plan de desarrollo de hardware a menudo. . Actividades de desarrollo en preparacin para la produccin pueden ser incluidas en el plan de desarrollo de hardware o definidas en un plan de produccin separada ejemplos de planes que se han utilizado en el Departamento de Defensa de EE.UU. comunidad son los siguientes:

1.

2.

3. 4.

5.

Plan Director por eventos Planan integrado que documenta los logros significativos con pasa / no pasa los criterios para ambos elementos tcnicos y de negocio del proyecto y que los lazos cada logro para un evento clave programa. Integrado Maestro Schedulean integrada y en red calendario de mltiples capas de las tareas del programa necesarios para completar el esfuerzo de trabajo documentado en un Plan Maestro Integrado relacionada. Ingeniera Plana plan de gestin de sistemas que detalla el esfuerzo tcnico integral de todo el proyecto. Ingeniera programacin basada en eventos Sistemas Maestro Schedulean que contiene una recopilacin de los logros tcnicos clave, cada uno con criterios medibles, que requiere la terminacin exitosa de pasar los eventos identificados. Programacin orientada a tareas de ingeniera de sistemas Schedulea detallada detallada en funcin del tiempo, que asocia las fechas e hitos con el Programa de Maestra de Ingeniera de Sistemas.

Productos de trabajo tpicos 1. Plan general del proyecto

SG 3 Obtener compromiso con el plan Compromisos con el plan del proyecto se han establecido y mantenido. Para ser eficaces, los planes requieren el compromiso de los responsables de la implementacin y el apoyo al plan. SP 3.1 Revisar los planes que afectan al proyecto De examinar todos los planes que afectan al proyecto para entender los compromisos del proyecto. Adicin IPPD Cuando se forman los equipos integrados, sus planes de trabajo integrados son algunos de los planes de revisin. Planes desarrollados en otras reas de proceso tpicamente contienen informacin similar para que las establecidas en el plan general del proyecto. Estos planes pueden ofrecer una orientacin detallada adicional y debe ser compatible con y apoyar el plan general del proyecto para indicar quin tiene la autoridad, responsabilidad, rendicin de cuentas y control. Todos los planes que afectan al proyecto deben ser revisados para asegurar un entendimiento comn del alcance, los objetivos, las funciones y las relaciones que se requieren para que el proyecto sea exitoso. Muchos de estos planes se describen en el Plan de la prctica genrica de procesos en cada una de las reas de proceso. Productos de trabajo tpicos: 1. Registro de las revisiones de los planes que afectan al proyecto SP 3.2 conciliar el trabajo y los niveles de recursos Reconciliar el plan del proyecto para reflejar los recursos disponibles y los estimados. Adicin IPPD Cuando se forman los equipos integrados, especial atencin se debe prestar a los compromisos de recursos en las circunstancias de los equipos integrados distribuidos y cuando las personas estn en varios equipos integrados en una o ms proyectos. Para establecer un proyecto que sea viable, obtener el compromiso de las partes interesadas y conciliar las diferencias entre las estimaciones y los

recursos disponibles. La reconciliacin se realiza generalmente mediante la reduccin o aplazamiento de los requisitos de desempeo tcnico, la negociacin de ms recursos, encontrar maneras de aumentar la productividad, la subcontratacin, el ajuste de la combinacin de aptitudes del personal, o la revisin de todos los planes que afectan al proyecto o los horarios. Productos de trabajo tpicos: 2. 3. 4. 5. 6. Mtodos revisados y parmetros de estimacin correspondientes (por ejemplo, mejores herramientas y el uso de componentes off-the-shelf) Presupuestos renegociados Calendarios revisados Lista de requisitos revisados Acuerdos renegociados interesados

SP 3.3 Obtener el compromiso del Plan Obtener el compromiso de las partes interesadas responsables de la ejecucin y el apoyo a la ejecucin del plan. Adicin IPPD Cuando se forman los equipos integrados, los planes del equipo integrados deben tener aceptacin por parte de los miembros del equipo, los equipos de interfaz, el proyecto y el proceso de propietarios de los procesos estndar que el equipo ha seleccionado para la aplicacin especfica. Obtencin compromiso implica la interaccin entre todas las partes interesadas internas y externas al proyecto. El individuo o grupo de hacer un compromiso deben tener confianza en que el trabajo se puede realizar dentro de los costos, el cronograma y el desempeo limitaciones. A menudo, un compromiso provisional es suficiente para permitir que el esfuerzo para comenzar y para permitir la investigacin que se realiza para aumentar la confianza en el nivel apropiado necesario para obtener un compromiso total. Productos de trabajo tpicos: 1. 2. Solicitudes documentadas de los compromisos Compromisos documentados

Prcticas genricas de Meta 1 GG alcanzar metas especficas El proceso apoya y permite el logro de las metas especficas del rea de proceso mediante la transformacin de los productos de trabajo de entrada identificables para producir productos de trabajo de salida identificables. GP 1.1 Realizar prcticas especficas Realizar las prcticas especficas del proceso de planificacin del proyecto para desarrollar los productos de trabajo y proporcionar servicios para lograr las metas especficas del rea de proceso. GG 2 Institucionalizar un proceso gestionado El proceso est institucionalizado como un proceso gestionado.

GP 2.1 Establecer una poltica organizacional Establecer y mantener una poltica de la organizacin para planificar y llevar a cabo el proceso de planificacin del proyecto. Elaboracin: Esta poltica establece las expectativas de la organizacin para la estimacin de los parmetros de planificacin, por lo que los compromisos internos y externos, y el desarrollo del plan de gestin del proyecto. GP 2.2 Plan de Proceso de Establecer y mantener el plan para realizar el proceso de planificacin del proyecto. Elaboracin: Consulte la Tabla 6.2 en la pgina 95 en las Metas genricas y prcticas genricas para obtener ms informacin acerca de la relacin entre la prctica genrica 2.2 y el rea de proceso de Planificacin de Proyectos. GP 2.3 Proporcionar recursos que proporcione recursos suficientes para llevar a cabo el proceso de planificacin del proyecto, el desarrollo de los productos de trabajo y proporcionar los servicios del proceso. Elaboracin: experiencia especial, el equipo y las instalaciones en la planificacin de proyectos que sean necesarios. Especial experiencia en la planificacin de proyectos puede incluir lo siguiente:

1. 2. 3.

Estimadores experimentados Programadores Los expertos tcnicos en las reas pertinentes (por ejemplo, el dominio y la tecnologa de productos)

Ejemplos de otros recursos proporcionados incluyen las siguientes herramientas: 1. Programas de hoja de clculo 2. Modelos de estimacin 3. Planificacin y programacin de paquetes de proyectos GP 2.4 Asignacin de Responsabilidad Asignar la responsabilidad y la autoridad para llevar a cabo el proceso, el desarrollo de los productos de trabajo y proporcionar los servicios del proceso de planificacin del proyecto. GP 2.5 Tren Gente tren Las personas que realizan o apoyan el proceso de planificacin de los proyectos, segn sea necesario. Elaboracin: Ejemplos de temas de capacitacin son los siguientes:

1. 2. 3. 4. 5. 6. 7.

Estimacin Presupuesto Negociacin Identificacin y anlisis de riesgos Gestin de datos Planificacin Programacin

GP 2.6 Administrar configuraciones Coloque los productos de trabajo designados del proceso de planificacin de proyectos con niveles apropiados de control. Elaboracin: Ejemplos de productos de trabajo puestos bajo control son los siguientes: 1. 2. 3. 4. Estructura de desglose del trabajo El plan del proyecto Plan de gestin de datos Plan de participacin de los interesados

GP 2.7 Identificar e involucrar a los actores relevantes Identificar e involucrar a los actores relevantes del proceso de planificacin del proyecto como estaba previsto. Elaboracin: Consulte la Tabla 6.2 en la pgina 95 en las Metas genricas y prcticas genricas para obtener ms informacin acerca de la relacin entre la prctica genrica 2.7 y el Stakeholder Plan de . Participacin de la prctica en el rea de proceso de Planificacin de Proyectos Ejemplos de actividades para la participacin de los interesados son las siguientes:

1. 2. 3. 4. 5.

El establecimiento de las estimaciones La revisin y resolucin de problemas en la integridad y exactitud de los riesgos del proyecto Revisin de los planes de gestin de datos El establecimiento de planes de proyecto Revisin de los planes del proyecto y resolver cuestiones en materia de trabajo y de los recursos

GP 2.8 Monitorear y controlar el proceso de supervisar y controlar el proceso de planificacin del proyecto con el plan para realizar el proceso y tomar las medidas correctivas apropiadas. Elaboracin: Ejemplos de medidas y productos de trabajo utilizados en la vigilancia y el control son las siguientes: 1. 2. 3. Nmero de revisiones del plan de Variacin de costo, horario, y el esfuerzo por revisin del plan Calendario para el desarrollo y mantenimiento de los planes del programa

GP 2.9 Evaluar objetivamente la adherencia Evaluar objetivamente la adherencia del proceso de planificacin del proyecto y su descripcin del proceso, las normas y los procedimientos, y la direccin de incumplimiento. Elaboracin: Ejemplos de actividades examinadas son las siguientes:

1. 2. 3.

El establecimiento de las estimaciones Desarrollar el plan del proyecto Obtencin de compromisos en el plan del proyecto

Ejemplos de productos de trabajo crtica incluyen los siguientes: 1. PEP 2. El plan del proyecto 3. Plan de gestin de datos 4. Plan de participacin de los interesados GP 2.10 Estado de revisin con la Gestin de Nivel Superior examinar las actividades, el estado y los resultados del proceso de planificacin del proyecto con la gestin de nivel superior y resolver problemas. GG 3 Institucionalizar un proceso definido El proceso est institucionalizado como un proceso definido. aspecto de este objetivo genrico aqu refleja su ubicacin en la representacin continua.

GP 3.1 Establecer un proceso definido Establecer y mantener la descripcin de un proceso de planificacin del proyecto definido. GP 3.2 Recopilar informacin Improvement Recoger productos de trabajo, medidas, resultados de medicin e informacin de mejora derivada de la planificacin y la realizacin del proceso de planificacin del proyecto para apoyar el uso futuro y la mejora de los procesos de las organizaciones y de los activos de proceso. Elaboracin: Ejemplos de productos de trabajo, medidas, resultados de medicin, y la mejora de informacin incluyen los siguientes:

1. 2. 3.

Estructura de la biblioteca de datos del proyecto Estimaciones de atributos de proyecto Impactos de riesgo y probabilidad de ocurrencia

GG 4 Institucionalizar un Proceso Gestionado cuantitativamente El proceso est institucionalizado como un proceso gestionado cuantitativamente. GP 4.1 Establecer objetivos cuantitativos para el proceso de establecer y mantener los objetivos cuantitativos para el proceso de planificacin del proyecto, que la calidad de la direccin y el rendimiento de los procesos, basados en las necesidades del cliente y los objetivos de negocio. GP 4.2 Estabilizar Subproceso Rendimiento Estabilizar el rendimiento de uno o ms subprocesos para determinar la capacidad del proceso de planificacin del proyecto para lograr la calidad y los objetivos cuantitativos fijados de rendimiento de proceso. GG 5 Institucionalizar un Proceso Optimizacin El proceso est institucionalizado como un proceso de optimizacin. GP 5.1 Asegrese de Mejora Continua de Procesos garantizar la mejora continua del proceso de planificacin del proyecto en el cumplimiento de los objetivos de negocio relevantes de la organizacin. GP 5.2 Corregir las causas de raz de los problemas de identificar y corregir las causas de los defectos y otros problemas en el proceso de planificacin del proyecto.

CM
Introduccin La facilidad de cambio en el software pone en riesgo la integridad de los productos. Cambios sin control, despliegue de componentes inconsistentes entre s, o la falta de disponibilidad del componente adecuado en una determinada etapa del ciclo de vida, pueden desestabilizar la calidad de mi aplicacin. Es de la sensibilidad al cambio presente en la disciplina de ingeniera de software que se desprenden las radicales diferencias que tiene esta actividad de la ingeniera con otras actividades de la industria. El dinamismo intrnseco del software genera la necesidad de contar con un framework para el control de cambios y estados de la configuracin, es desde esta necesidad que surge CM (Configuration Management). Paradjicamente, la naturaleza sensitiva al cambio presente en el software hace que la burocracia en los controles de cambio sea algo positivo dentro de este contexto. CM colabora con el proceso a travs de la implementacin de polticas de} tracking, seguridad, integracin y administracin de cambios.

Entropa vs Actividad de Cambio La entropa aumenta en el software en forma continua a menos que acciones de control sean aplicadas sobre los cambios. Los casos patolgicos de ejemplo son los legacy systems donde existen, en algunos casos, dcadas de cambios sin documentar por lo que debe interpretarse las reglas del negocio a Travs de ingeniera inversa sobre el cdigo.

Misin de CM 1. 2. 3. 4. Custodiar la integridad del producto Acompaar la actividad de cambio con actividades de control Gestionar los tipos de cambio permitidos a lo largo del ciclo de vida del producto. Brindar acceso al componente adecuado.

SEI: Las disciplinas y tcnicas de iniciacin, evaluacin y control de cambios sobre productos de software durante y despus del proceso de desarrollo. Cambios 1. Incrementando la complejidad del software. - Size Lneas de cdigo Nuevos Mdulos (Cambio de arquitectura) - Inclusin de componentes de terceras partes Controlar versiones de componentes por terceras partes. Grabar versiones que conforman el baseline del sistema de software

- Incrementando el nmero de plataformas sobre las cuales el sistema opera La organizacin de test se ve afectada. SCM tool debera ejecutarse en todas las plataformas que el producto corre 2. Incremento de la complejidad del entorno

- Team Size Incrementar el tamao del team significa aumentar la cantidad de lneas de comunicacin. Por Ejemplo: 2 personas = 1 lnea 3 personas = 3 lneas n personas = n* (n-1)/2 Acceso concurrente a los componentes aumenta. Complejidad en el merge de los cambios en paralelo. - Distribucin geogrfica del team Comunicacin ms compleja. Merge integracin se hace imposible sobre los niveles superiores de integracin. - Frecuencia de los Releases o cantidad de variantes Aumenta la cantidad de releases mantenidos al mismo tiempo. Los bug fixes son ms difciles de distribuir. Los arreglos sobre versiones existentes colisionan con mayor nmero de versiones funcionando. - Cambio en plataformas de SO y Hardware Muchas veces no atendido, las partes de la configuracin que no son software (como firmware y hardware) no son tenidas en cuenta como parte de la configuracin con la consecuente desatencin durante el mantenimiento. El SO, el hardware sobre el cual este funciona, como as tambin la versin de Firmware instalada en el Hardware son elementos de terceros que deben sr mantenidos bajo control de configuracin. 3. Seguimiento del cambio del ciclo de vida

A medida que se avanza a lo largo del ciclo de vida debo poder restringir que tipo de cambios puedo realizar sobre el software. ENTORNO CM Productos Los productos sujetos a control de configuracin son todos aquellos que, al ser afectados por un cambio, pudieran afectar la integridad de la aplicacin. Implementacin Procesos La necesidad de operar sobre diversos ambientes nos obliga a conservar, al menos, entornos de produccin y desarrollo por separado. La actividad de cambio en ambos entornos tendr diferente volatilidad y por ende, deber poder ser aislada. CM Procesos La integridad de los productos a lo largo de los entornos es gestionada a partir de las prcticas de CM que se describen a lo largo de esta presentacin.

MA (MEASUREMENT AND ANALYSIS)

SP 1.4 Especificar procedimiento de anlisis Especificar cmo los datos de medicin sern analizados y reportados. Subprcticas: 1. 2. 3. 4. 5. 6. Especificar y priorizar los anlisis que se llevarn a cabo y los reportes que sern preparados Seleccionar mtodos y herramientas de anlisis de datos apropiados Especificar procedimientos administrativos para analizar los datos y comunicar los resultados Revisar y actualizar el contenido y formato de anlisis y reporte Actualizar mediciones y objetivos de medicin cuando sea necesario Especificar criterios para evaluar la utilidad del resultado del anlisis y para evaluar cmo se llevar a cabo las actividades de medicin y anlisis

Productos de Trabajo Tpicos: 1. Procedimiento y especificacin de anlisis 2. Herramientas de anlisis de datos Objetivos y Prcticas Especficas SG 2 Proveer resultados de medicin Los resultados de las mediciones que se ocupan de las necesidades de informacin y objetivos son provistos. SP 2.1 Recolectar datos de medicin Obtener los datos de medicin especficos. Subprcticas: 1. Obtener los datos base para medicin 2. Generar datos derivados de medicin 3. Realizar chequeos de integridad de datos lo ms cercano posible a su fuente Productos de Trabajo Tpicos: 1. Conjunto de datos de medicin base y derivados 2. Resultados de pruebas de integridad de datos SP 2.2 Analizar datos de medicin Analizar e interpretar los datos de medicin.

Subprcticas: 1. Anlisis inicial, interpretacin de resultados, extraccin de conclusin preliminar

2. 3. 1.

Medicin y anlisis adicional tanto como sea necesario y preparar los resultados para su presentacin Revisar los resultados iniciales con los involucrados relevantes Refinar criterios para futuros anlisis

Productos de Trabajo Tpicos: 1. Resultados de anlisis y borrador de reporte SP 2.3 Almacenar datos y resultados Administrar y almacenar datos de medicin, especificacin de medicin y resultados de anlisis. Subprcticas: 1. Revisar los datos para asegurar su completitud, integridad y exactitud 2. Almacenar los datos de acuerdo a procedimiento de almacenamiento 3. Hacer que los contenidos almacenados estn disponibles solo para uso de un grupo o personal autorizado 4. Prevenir que la informacin almacenada sea usada inapropiadamente Productos de Trabajo Tpicos: 1. Inventario de datos almacenados SP 2.4 Comunicar resultados Reportar resultados de las actividades de medicin y anlisis a todos los involucrados relevantes. Subprcticas: 1. Mantener informados a los involucrados relevantes de los resultados de medicin en tiempo. 2. Ayudar a los involucrados relevantes a entender los resultados Productos de Trabajo Tpicos: 1. Entregables de reportes de resultados de anlisis 2. Informacin contextual o gua para interpretar los resultados del anlisis

PMC
Acciones correctivas que son administradas para entrar cuando el desempeo del proyecto o resultados se desvan significativamente del plan original. Desempeo actual y progreso del proyecto que son vigilados contra el plan del proyecto [PMC Sommerville]. Con las cuestiones de monitoreo constante que se realizan para medir el desempeo del desarrollo, se tienen por ende subdivisiones que permiten conocer con mayor dedicacin las diferentes partes que conforman al control o vigilancia del desarrollo.

De entre estas se encuentra la vigilancia:

~ del progreso con el calendario. ~ de costos y esfuerzo del proyecto segn lo planeado. ~ de atributos de los productos de trabajo y tareas. ~ de los recursos que han sido provedos y usados. ~ de los conocimientos y habilidades del personal del proyecto. Documentacin de las desviaciones significantes de los parmetros del proyecto.

Las salidas de este conjunto de cuestiones de vigilancia de progreso se encuentran:

Documentos de desempeo de proyecto. Documentos de desviaciones significantes.

Los compromisos en un mbito de control de procesos se refiere a las situaciones que ofrecen un posible contratiempo (positivo o negativo), siendo as se ponen en marca personal y son fuertemente vigilados, as el plan de proyecto puede o se asegura de que siga su rumbo sin problemas.

Regularmente se estn revisando estos compromisos (internos y externos). Al ser detectados, se identifican compromisos que no han sido cumplidos o implican mucho riesgo, se documentan progresivamente los resultados que arroje la revisin de estos factores.

Los documentos que abundan en este sector son los de revisin de compromisos. Como se estableca en objetivo primario, siempre se est comparando con el trayecto ideal del proyecto en cuanto al cumplimiento del cronograma refiere

Se revisa peridicamente la documentacin de los riesgos en el contexto y circunstancias del actual estado del proyecto. Se revisa informacin adicional disponible para incorporar cambios (tcticas). Comunicar el estado de los riesgos involucrados relevantes.

Documentos de monitoreo de riesgos entraran en este contexto.

En cuanto al proceso de desarrollo y antecesor de produccin se sabe que se tiene informacin de toda ndole dentro de los ordenadores, por ende, se vigila la administracin de datos contra la planificacin del proyecto.

Se revisa peridicamente las actividades de administracin de datos segn lo planeado. Se identifican y documentan las inconsistencias significantes y su impacto, los resultados obtenidos son igualmente documentados.

Los documentos que envuelven este fragmento son los de administracin de datos.

Dentro de los participantes del proyecto en contexto general tenemos el esfuerzo hombre/tiempo y las inversiones que se hacen en la idea del proyecto, de esta forma el monitoreo del involucramiento de los stakeholders relevantes contra la planificacin del proyecto entra en fase.

Revisando peridicamente el estado de su involucramiento, se identifican y documentan las desviaciones significantes y su impacto, redactando estos resultados de las revisiones de estado de involucramiento de los stakeholders.

Involucramiento de Stakeholders entra en vigor en este fragmento.

Conforme se van registrando este tipo de factores en lo que pareciera diferentes documentos, se pueden tomar a bitcoras que conforman en s lo que es el significado de PMC, siendo as de igual forma se realizan revisiones del progreso de la mano de los documentos anteriores, de forma peridica, as como el desempeo e inconsistencias que se pudiesen presentar.

Se comunica de manera regular el estado de las actividades designadas y productos de trabajo a los involucrados relevantes, se revisan los resultados de la recoleccin ty anlisis de mediciones para controlar el proyecto, identifican y documentan las inconsistencias relevantes y desviaciones del plan. Se documentan cambios a los requerimientos y problemas identificados en cualquier producto de trabajo y proceso, as como los resultados de las revisiones. Se verifican una vez ms los cambios a los requerimientos y reportes de problemas para el cierre.

La documentacin exhaustiva se llama resultados de las revisiones del proyecto.

Los checkpoints o hitos son bien conocidos en la estructura de cualquier proyecto, sobre todo si se manejan prototipos por fases dependiendo de la metodologa de desarrollo, se revisa entonces el cumplimiento y resultados del proyecto en este hito

Se hacen revisiones en los puntos significantes del calendario del proyecto, as se observan detalladamente las etapas cumplidas que se seleccionaron con involucrados relevantes. Con ello, se revisan los compromisos, plan, estado y riesgos del proyecto, identifican y documentan inconsistencias relevantes y su impacto. Documentan resultados de las revisiones, puntos de accin y decisiones. Verifican puntos de accin para el cierre.

Aqu entra el documento de resultado de revisiones de hito.

Punto clave en el control es la administracin de las acciones correctivas para el cierre.

Las acciones correctivas son administradas para el cierre cuando el desempeo del proyecto o los resultados de las desviaciones con significantes para el plan.

Se recolectan y analizan las inconsistencias para determinar las acciones correctivas necesarias para estas, reuniendo las inconsistencias para su anlisis. Analizando estas para determinar las acciones correctivas.

De aqu se extrae, una lista, ~ de acciones correctivas de las inconsistencias.

A lo dicho el hecho, se toman acciones correctivas para resolver estas cuestiones de la lista.

Determinando y documentando las acciones apropiadas necesarias para las inconsistencias, revisando y acordando con los involucrados relevantes las acciones que se han de tomar. Se negocian los cambios para compromisos internos y externos.

Se extrae un plan de acciones correctivas.

Las acciones correctivas a realizar son entonces administradas para el cierre, cuando el desempeo del proyecto o resultados de las desviaciones son significantes para el plan.

Vigilando las acciones correctivas para su terminacin, analizando resultados de las acciones correctivas para determinar su eficiencia. Determinar y documentar las acciones para corregir desviaciones del plan.

Se extrae el resultado de acciones correctivas.

CONCLUCIONES
CMMI es una forma de gestionar los procesos desarrollados con una forma de ir evaluando y monitoreando el desarrollo de dicho proyecto con un marco de inmadurez en el cual busca la facilidad de detectar errores, ver la evolucin, Para llevar a cabo el monitoreo de nivel de inmadurez se auxilian con reas de procesos las cuales residen en un nivel de madurez.. CMMI busca que colectivamente se llegue a alcanzar las metas y de una forma bien gestionada teniendo la oportunidad de identificar factores que en un momento dado se requieran nuevamente o se necesiten modificar o reparar.

BIBLIOGRAFIA:
1. Sinopsis de los modelos SW-CMM y CMMI Juan Palacio Abril 2006 http://www.navegapolis.net/files/articulos/sinopsis_cmm.pdf

1.

El Modelo CMMI(for Development) Monterrey, N.L. Mxico Noviembre 2008

2.

CMMI or development, version 1.2, CMMI Guidelines for process integration and product improvement. Chrissis Mary Beth, Konrad Mike, Shrum Sandy. Addison Wesley, 2007 Edf.

3.

"El Trovador" Pza. Antonio Beltrn Martnez, 1 Planta Sptima, Oficina A 50.002 Zaragoza Tels. 976 207 207 / 209 Fax: 976 207 210

[Project Management Institute, 2013] project Management institute, Inc. A Guide to the Project Management Body of Knowledge (PMBOguide- Fifth edition) project Management institute, 2013. ISBN 978-1-935589-67-9 (pbk. : alk. paper)

Sitios Web.

[cmmiconsultantnlog How to conduct Project Monitoring and Control (PMC) as per CMMI?, 2013] Pgina Web con URL: http://www.cmmiconsultantblog.com/cmmi-faqs/how-to-conduct-project-monitoring-andcontrol-pmc-as-per-cmmi/ consultado el da 17-Septiembre