Referencia Rpida de CMMI para Desarrollo

Disclaimer The author have taken care in the preparation of this text, but make no expressed or implied warranty of any kind and assume no responsibility for error or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein. This text is based on a non-SEI-sanctioned translation of CMMI for Development PA and GG Quick Reference 2010 by Carnegie Mellon University that was prepared by David Arteaga. Neither Carnegie Mellon University nor the Software Engineering Institute have participated in the creation of this text or the translation upon which it is based and, accordingly, do not directly or indirectly endorse this publication; Accuracy and interpretation of this translation are the responsibility of DAVID ARTEAGA. ANY CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN "AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT. Capability Maturity Model, CMM, and CMMI are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University.

1 CMMI-DEV v1.3, 20100907

Referencia Rpida de CMMI para Desarrollo

Contenido
Introduccin..........................................................................................................................................3 Componentes bsicos del CMMI ........................................................................................................4 GESTIN DE REQUERIMIENTOS (REQM)..................................................................................5 PLANIFICACIN DE PROYECTO (PP).............................................................................................7 MONITORIZACIN Y CONTROL DE PROYECTO (PMC)..........................................................10 GESTIN DE CONFIGURACIN (CM) .........................................................................................12 MEDICIN Y ANLISIS (MA) ......................................................................................................14 ASEGURAMIENTO DE LA CALIDAD DE PROCESO Y PRODUCTO (PPQA)...........................15 ANLISIS DE DECISIN Y SOLUCIN (DAR) ........................................................................16 GESTIN DEL RIESGO (RSKM) ....................................................................................................17 GESTIN INTEGRADA DE PROYECTO (IPM) ............................................................................18 DESARROLLO DE REQUERIMIENTOS (RD) ...............................................................................19 SOLUCIN TCNICA (TS) .............................................................................................................20 INTEGRACIN DE PRODUCTO (PI) .............................................................................................21 VALIDACIN (VAL)..........................................................................................................................22 VERIFICACIN (VER)......................................................................................................................23 METAS GENRICAS.........................................................................................................................24 ACLARACIONES DE LA TRADUCCIN ........................................................................................25

2 CMMI-DEV v1.3, 20100907

Referencia Rpida de CMMI para Desarrollo

Introduccin
El CMMI es un marco de referencia para mejorar procesos en las organizaciones. La mayora de empresas en el mundo que usan el CMMI lo hacen para mejorar sus procesos de software, sin embargo, el CMMI puede usarse para mejorar procesos en otros contextos. Existen 3 modelos CMMI, cada uno para un contexto especfico que resumo a continuacin: 1. El CMMI para Desarrollo es un modelo para mejorar procesos de desarrollo y mantenimiento de productos y/o servicios. Por ejemplo, podemos usar el CMMI para Desarrollo para mejorar el proceso de desarrollo y mantenimiento de software de una organizacin o tambin para disear y construir sistemas de seguridad para edificios. 2. El CMMI para Adquisicin es un modelo para mejorar los procesos de relacionamiento con proveedores y por tanto mejorar las adquisiciones de productos y servicios. Por ejemplo, el rea de Tecnologa de Informacin de una institucin del estado o de un banco, que tiene mltiples proveedores importantes, puede usar el CMMI para Adquisicin para mejorar los procesos necesarios para interactuar con sus proveedores y de esta manera lograr un trabajo colaborativo que contribuya con el xito de sus proyectos. El CMMI para Adquisicin est dirigido a organizaciones que contratan proveedores y realizan adquisicin de productos y servicios. 3. El CMMI para Servicios es un modelo para mejorar procesos para gestionar y operar servicios. Por ejemplo, podemos usar el CMMI para Servicios para mejorar los procesos necesarios para entregar un servicio de software factory de calidad; o podemos usar el CMMI para Servicios para mejorar los procesos necesarios para entregar un servicio de Call Center de calidad; o podemos usar el CMMI para Servicios para mejorar los procesos necesarios para entregar servicios educativos de calidad o servicios de salud. Cuando este marco de referencia naci, se llamaba CMM para Software, razn por la cual hoy en da es un modelo usado mayoritariamente en la industria de software. Sin embargo, el CMMI ha evolucionado y ahora est diseado de tal modo que puede usarse en diversas industrias. Para usar apropiadamente el CMMI debemos interpretar en nuestro contexto, cul es el producto y/o servicio que estamos mejorando. Por ejemplo, si usamos el CMMI para Desarrollo para mejorar el proceso de desarrollo de software de una organizacin, el producto es el sistema de software o aplicativo de software que desarrollamos y entregaremos. El CMMI para Desarrollo dice: El CMMI para Desarrollo es un modelo de referencia que abarca actividades para desarrollar tanto productos como servicios. Organizaciones de muchas industrias, incluyendo aeroespacial, banca, hardware de computadoras, software, defensa, manufactura de automviles y telecomunicaciones usan el CMMI para Desarrollo. El CMMI para Desarrollo contiene prcticas que abarcan la gestin de proyectos, la gestin de procesos, la ingeniera de sistemas, ingeniera de hardware, ingeniera de software y otros procesos de soporte usados en el desarrollo y mantenimiento. Use el juicio profesional y sentido comn para interpretar el modelo en su organizacin. Es decir, aun cuando las reas de proceso descritas en este modelo describen comportamientos considerados mejores prcticas para la mayora de usuarios, las reas de proceso y prcticas deben interpretarse usando un conocimiento exhaustivo del CMMI para Desarrollo, las restricciones en su organizacin y su entorno de negocios. Para usar el CMMI debemos comprender e interpretar el modelo y tambin debemos aplicar una metodologa de mejora. Primero vamos a explicar algunos conceptos fundamentales de proceso y mejora de procesos. El concepto de proceso parece ser un concepto simple sin embargo muchas organizaciones no tienen claro el concepto completo de proceso y all radica la principal falla cuando se quiere trabajar con procesos.

3 CMMI-DEV v1.3, 20100907

Referencia Rpida de CMMI para Desarrollo

Componentes bsicos del CMMI
Los componentes bsicos del CMMI son: rea de proceso, metas y prcticas. Prctica El CMMI es un modelo que sirve para mejorar procesos, nos dice las caractersticas que debe tener un proceso para que sea efectivo y eficiente. En el CMMI esas caractersticas se llaman prcticas. Las prcticas son lecciones aprendidas de la industria. Nos evitan problemas y riesgos. rea de Proceso El CMMI agrupa las prcticas en temas o dominios denominados reas de proceso. Un rea de proceso es un conjunto de buenas prcticas relacionadas con un tema en particular, dicho de otra forma, es un conjunto de prcticas relativas a un dominio especfico, por ejemplo planeamiento de proyecto, gestin del riesgo, validacin, entre otros. Las prcticas que pertenecen a un rea de proceso sirven para mejorar algn aspecto en particular de un conjunto de procesos relacionados con el rea de proceso. El CMMI para Desarrollo (en adelante CMMI-DEV) tiene 22 reas de proceso. Decimos que un rea de proceso se ha implementado, si todas las prcticas del rea de proceso se han implementado en nuestra organizacin. Cada rea de proceso tiene un nemotcnico, por ejemplo para Planificacin de Proyecto es PP, para Gestin de Requerimientos es REQM. Meta Dentro de un rea de proceso, las prcticas estn agrupadas en metas (en el modelo en ingls se llama goals que aqu se traducen como metas). Las metas son los objetivos a lograr para implementar exitosamente un rea de proceso. Las metas indican cul subconjunto de prcticas determinan una mejora significativa. Cada rea de proceso tiene metas genricas y metas especficas. Las metas especficas describen las caractersticas nicas que deben estar presentes para satisfacer un rea de proceso. Las metas especficas tienen prcticas especficas. Una meta genrica describe las caractersticas que deben estar presentes para institucionalizar los procesos que implementan un rea de proceso. Las metas genricas tienen prcticas genricas. En este texto, las prcticas genricas estn al final del documento. Cada rea de proceso tiene metas y prcticas especficas y genricas. Las metas y prcticas genricas tienen la misma denominacin en todas las reas de proceso y para evitar repetir el mismo texto en cada rea de proceso, se incluyen al final del presente documento. Por ejemplo, todas las reas de proceso del nivel de madurez 3 tienen la meta genrica GG3, lo que podemos graficar de la siguiente manera: Nivel de Madurez 3 reas de Proceso reas de Proceso que en la representacin escalonada estn en el Nivel de Madurez 2: PP, PMC, SAM, CM, MA, PPQA, SAM, REQM reas de Proceso que en la representacin escalonada estn en el Nivel de Madurez 3: RD, TS, PI, VER, VAL, OPD, OPF, OT, RSKM, IPM, DAR Meta Genrica y Prcticas Genricas para todas las reas de Proceso del Nivel de Madurez 3 GG2 Institucionalizar un Proceso Gestionado GP 2.1 Establecer una Poltica Organizacional GP 2.2 Planear el Proceso GP 2.3 Proporcionar Recursos GP 2.4 Asignar Responsabilidad GP 2.5 Capacitar Personas GP 2.6 Gestionar Configuraciones GP 2.7 Identificar e Involucrar Partes Interesadas Relevantes GP 2.8 Monitorizar y Controlar el Proceso GP 2.9 Evaluar Objetivamente Adherencia GP 2.10 Revisar Estado con Gerencia de Alto Nivel GG3 Institucionalizar un Proceso Definido GP 3.1 Establecer un Proceso Definido GP 3.2 Recolectar Informacin de Mejora
4 CMMI-DEV v1.3, 20100907

Referencia Rpida de CMMI para Desarrollo

GESTIN DE REQUERIMIENTOS (REQM)
Categora: Gestin de Proyectos Nivel de Madurez: 2 El propsito de Gestin de Requerimientos (REQM = Requirements Management) es gestionar requerimientos de los productos y componentes de producto del proyecto y asegurar alineamiento entre dichos requerimientos y los planes y productos de trabajo del proyecto. SG 1 Los requerimientos se gestionan y las inconsistencias con planes y productos de trabajo se identifican. SP 1.1 Desarrollar un entendimiento con quienes proporcionan requerimientos acerca del significado de los requerimientos. SP 1.2 Obtener compromiso con los requerimientos de los participantes del proyecto. SP 1.3 Gestionar cambios a los requerimientos conforme ellos evolucionan durante el proyecto. SP 1.4 Mantener trazabilidad bidireccional entre los requerimientos y productos de trabajo. SP 1.5 Asegurar que los planes y productos de trabajo del proyecto permanecen alineados con los requerimientos. Breve explicacin SP 1.1 Desarrollar un entendimiento con quienes proporcionan requerimientos acerca del significado de los requerimientos. 1. . 1.1. Establecer un criterio para designar los canales apropiados o fuentes oficiales de quienes recibir los requerimientos. Es decir, formalizar quienes son las personas designadas a proporcionar, explicar y aprobar los requerimientos, usualmente un usuario lder y un conjunto de usuarios. En el Scrum se designa al Product Owner quien es responsable de proporcionar y priorizar los requerimientos e identifica y representa a otras partes interesadas. 1.2. El equipo de trabajo que recibe los requerimientos realiza un anlisis de los requerimientos con quienes proporcionan los requerimientos de modo de asegurar que se logra un entendimiento compartido del significado de los requerimientos. Es decir, el equipo de trabajo debe aceptar los requerimientos luego de estar seguro que ha entendido los requerimientos de la misma forma como los usuarios lo entienden. Por ejemplo, discutir con los usuarios quienes aprobarn la implementacin de los requerimientos los escenarios, casos y valores principales que usarn para aceptar los requerimientos. 1.3. Existe un conjunto de requerimientos aprobado y vigente. Hay una lista aprobada y vigente de requerimientos priorizados. Hay especificaciones de requerimientos aprobadas y vigentes. 2. Los participantes del proyecto se comprometen a atender e implementar los requerimientos que reciben (al inicio del trabajo y los cambios a los requerimientos ya acordados), negociando y resolviendo previamente cmo afecta sus compromisos actuales. Esto implica que el equipo de trabajo se compromete con los requerimientos vigentes y aprobados y con los cambios resultantes en los planes, actividades y productos de trabajo del proyecto. 3. Identificar los cambios a los requerimientos acordados, analizar el cambio, evaluar el impacto, aceptar o rechazar cambios a los requerimientos y controlar el impacto de los cambios. Esto significa identificar el origen o fuente de cada requerimiento y documentar la justificacin del cambio. En el Scrum los cambios se introducen al inicio de cada iteracin y no estn permitidos durante una iteracin. Cada cambio tiene un identificador y se registra en la lista de requerimientos
5 CMMI-DEV v1.3, 20100907

SP 1.2 Obtener compromiso con los requerimientos de los participantes del proyecto. SP 1.3 Gestionar cambios a los requerimientos conforme ellos evolucionan durante el proyecto.

Referencia Rpida de CMMI para Desarrollo

SP 1.4 Mantener trazabilidad bidireccional entre los requerimientos y productos de trabajo. 4. . 4.1. Mantener trazabilidad (relacin en ambos sentidos) entre los requerimientos fuente (requerimientos a alto nivel) y los requerimientos detallados (requerimientos a ms bajo nivel) y viceversa. 4.2. Asegurar que todos los requerimientos han sido completamente resueltos. Por ejemplo para cada requerimiento hay un conjunto de casos de prueba que verifican y validan su implementacin; cada especificacin de requerimiento tiene una implementacin (componentes) identificable. 5. A lo largo del trabajo, por ejemplo con los cambios a los requerimientos, correccin de errores e identificacin de desviaciones del plan de trabajo, entre otros, revisar si los requerimientos vigentes permanecen alineados con los productos de trabajo. En caso contrario iniciar accin correctiva para corregir los productos de trabajo no sincronizados.

SP 1.5 Asegurar que los planes y productos de trabajo del proyecto permanecen alineados con los requerimientos.

6 CMMI-DEV v1.3, 20100907

Referencia Rpida de CMMI para Desarrollo

PLANIFICACIN DE PROYECTO (PP)
Categora: Gestin de Proyectos Nivel de Madurez: 2 El propsito de Planificacin de proyecto (PP = Project Planning) es establecer y mantener planes que definan las actividades del proyecto. SG 1 Establecer y mantener estimaciones de parmetros de planificacin de proyecto. SP 1.1 Establecer una estructura de divisin del trabajo (EDT) de alto nivel para estimar el alcance del proyecto. SP 1.2 Establecer y mantener estimaciones de atributos de productos de trabajo y tareas. SP 1.3 Definir las fases del ciclo de vida del proyecto sobre las cuales delimitar el esfuerzo de planificacin. SP 1.4 Estimar el esfuerzo y costo del proyecto para los productos de trabajo y tareas con base en una justificacin de estimacin. SG 2 Establecer y mantener un plan de proyecto como la base para gestionar el proyecto. SP 2.1 Establecer y mantener el presupuesto y cronograma del proyecto. SP 2.2 Identificar y analizar riesgos del proyecto. SP 2.3 Planificar la gestin de datos del proyecto. SP 2.4 Planificar los recursos para ejecutar el proyecto. SP 2.5 Planificar los conocimientos y habilidades necesarias para ejecutar el proyecto. SP 2.6 Planificar la involucracin de las partes interesadas identificadas. SP 2.7 Establecer y mantener el plan completo del proyecto. SG 3 Establecer y mantener los compromisos con el plan de proyecto. SP 3.1 Revisar todos los planes que afectan el proyecto para comprender los compromisos del proyecto. SP 3.2 Adaptar el plan de proyecto para conciliar recursos disponibles y estimados. SP 3.3 Obtener compromiso con las partes interesadas relevantes responsables de ejecutar y apoyar la ejecucin del plan. Breve explicacin SP 1.1 Establecer una estructura de divisin del trabajo (EDT) de alto nivel para estimar el alcance del proyecto. SP 1.2 Establecer y mantener estimaciones de atributos de productos de trabajo y tareas. 6. Describir el alcance del proyecto o trabajo, que incluya la lista de requerimientos a alto nivel, los productos de trabajo a producir y los grupos de actividades. 7. Para cada requerimiento o tarea, estimar el tamao o complejidad del trabajo a realizar o del producto de trabajo a producir. Por ejemplo, estimar la complejidad de cada requerimiento en un peso (2, 3, 4 etc.) en relacin a un requerimiento base (peso 2 equivalente a una complejidad simple). Por ejemplo, estimar la complejidad de un requerimiento en tamaos estndares (complejidad: simple, media, grande) en relacin a una descripcin de cada tamao estndar. Simple: una sola tabla, no ms de 10 campos, slo lectura, etc. Media: no ms de 3 tablas, lectura y/o escritura, entre 11 y 15 campos, etc. Por ejemplo, estimar la complejidad de una especificacin de caso de uso en puntos caso de uso 8. Describir el ciclo de vida a seguir, es decir, las fases, actividades de cada fase, hitos importantes, productos de trabajo (entregables) a producir identificando cules se entregan al cliente u otras partes interesadas.

SP 1.3 Definir las fases del ciclo de vida del proyecto sobre las cuales delimitar el esfuerzo de planificacin.

7 CMMI-DEV v1.3, 20100907

Referencia Rpida de CMMI para Desarrollo

SP 1.4 Estimar el esfuerzo y costo del proyecto para los productos de trabajo y tareas con base en una justificacin de estimacin. 9. En base al tamao o complejidad de cada requerimiento o actividad estimar el esfuerzo requerido para realizar dicho trabajo. Por ejemplo, en base a un ratio estndar de conversin de complejidad a esfuerzo. Es decir, asumiendo que una complejidad bsica (peso 2, tamao simple, 1 punto caso de uso, etc.) equivale a 20 horas de programacin y pruebas unitarias de un desarrollador estndar. o Desarrollador estndar es una definicin organizacional. Por ejemplo, alguien con 6 meses de experiencia en la organizacin y 2 aos de experiencia en la tecnologa. Por ejemplo, en base a datos histricos reales registrados. Es decir, analizando el esfuerzo real que ha tomado la programacin y pruebas unitarias de requerimientos de complejidad base (peso 2, tamao simple, etc.) obtener un valor representativo del esfuerzo real (por ejemplo el promedio). 10. . 10.1. Elaborar un cronograma de actividades para un perodo de tiempo de acuerdo al ciclo de vida a seguir. Por ejemplo una lista de actividades para un perodo de tiempo definido segn el ciclo de vida. 10.2. Definir un presupuesto para el trabajo o un lmite de horas de referencia para el costo. 11. Identificar los riesgos del proyecto y analizar cada riesgo segn sea apropiado. 12. . 12.1. Definir dnde residir toda la informacin del proyecto: documentos de gestin, documentos de ingeniera, cdigo fuente, herramientas, entre otros. 12.2. Definir medidas de seguridad para la informacin del proyecto. Por ejemplo definir quines tendrn acceso a la informacin del proyecto, qu tipo de acceso (lectura, escritura), quines tendrn acceso a los datos de prueba, entre otros. 12.3. Definir qu informacin ser enviada a cules partes interesadas de qu forma y con qu frecuencia. Por ejemplo: informes de estado de proyecto semanales a cliente. 12.4. Definir acciones sobre la informacin del proyecto al terminar el proyecto. Por ejemplo: qu informacin archivar y qu informacin destruir. 13. Identificar los recursos necesarios para el proyecto incluyendo recursos humanos, de proceso, herramientas, hardware, software, infraestructura fsica, infraestructura de comunicaciones, entre otros. 14. . 14.1. Definir el perfil necesario de los integrantes del equipo de trabajo incluyendo participantes como gerencia y usuarios o clientes para el xito del proyecto con base en los requerimientos del proyecto, la tecnologa a usar, el dominio de negocio y el contexto organizacional (por ejemplo procesos, estndares y tcnicas a usar). 14.2. Si las personas asignadas no tienen el perfil requerido
8 CMMI-DEV v1.3, 20100907

SP 2.1 Establecer y mantener el presupuesto y cronograma del proyecto.

SP 2.2 Identificar y analizar riesgos del proyecto. SP 2.3 Planificar la gestin de datos del proyecto.

SP 2.4 Planificar los recursos para ejecutar el proyecto.

SP 2.5 Planificar los conocimientos y habilidades necesarias para ejecutar el proyecto.

Referencia Rpida de CMMI para Desarrollo

entonces identificar y planificar la formacin necesaria. 15. El cronograma de actividades debe incluir quin es el responsable de cada actividad y quines deben participar en cada actividad. 16. Definir dnde residir la informacin de planificacin del proyecto. Por ejemplo en algn directorio o herramienta. 17. Revisar otros planes que pueden afectar el plan del proyecto, entre otros: 17.1. El plan del equipo de pruebas (testing). 17.2. El plan del revisor de aseguramiento de la calidad. 17.3. Planes de los usuarios y clientes que participan en el proyecto, asociados o no al proyecto. 17.4. Planes de quienes participan en el proyecto y no estn asignados a tiempo completo o durante todo el proyecto. 17.5. Planes del rea que administra la infraestructura donde se instalar el aplicativo para coordinar las entregas y pases a produccin. 17.6. Planes de capacitacin organizacional. 17.7. Vacaciones planificadas 18. . 18.1. Actualizar el plan por ejemplo el cronograma y los riesgos con una frecuencia definida para que refleje la realidad y avance real del proyecto. 18.2. Re-planificar el plan de actividades si cambia el contexto del proyecto, por ejemplo si hay cambios en el alcance, cambios en requerimientos especficos, desviaciones significativas del proyecto, entre otros. 19. . 19.1. Los participantes del proyecto deben asentir que el plan de trabajo es un plan realista y comprometerse de forma explcita a apoyarlo. 19.2. Definir mecanismos prcticos para comunicar oportunamente problemas o impedimentos. Por ejemplo: tener sistemticamente breves reuniones diarias.

SP 2.6 Planificar la involucracin de las partes interesadas identificadas. SP 2.7 Establecer y mantener el plan completo del proyecto. SP 3.1 Revisar todos los planes que afectan el proyecto para comprender los compromisos del proyecto.

SP 3.2 Adaptar el plan de proyecto para conciliar recursos disponibles y estimados.

SP 3.3 Obtener compromiso con las partes interesadas relevantes responsables de ejecutar y apoyar la ejecucin del plan.

9 CMMI-DEV v1.3, 20100907

Referencia Rpida de CMMI para Desarrollo

MONITORIZACIN Y CONTROL DE PROYECTO (PMC)
Categora: Gestin de Proyectos Nivel de Madurez: 2 El propsito de (PMC = Project Monitoring and Control) es proporcionar un entendimiento del avance del proyecto de modo que se puedan tomar acciones correctivas apropiadas cuando el desempeo del proyecto se desva significativamente del plan. SG 1 El desempeo y avance real del proyecto se monitoriza versus el plan del proyecto. SP 1.1 Monitorizar valores reales de parmetros de planificacin de proyecto versus el plan de proyecto. SP 1.2 Monitorizar compromisos versus aquellos identificados en el plan de proyecto. SP 1.3 Monitorizar riesgos versus aquellos identificados en el plan de proyecto. SP 1.4 Monitorizar la gestin de datos del proyecto versus el plan de proyecto. SP 1.5 Monitorizar la involucracin de las partes interesadas versus el plan de proyecto. SP 1.6 Revisar peridicamente el avance del proyecto, desempeo y problemas. SP 1.7 Revisar los logros del proyecto y resultados en hitos seleccionados del proyecto. SG 2 Las acciones correctivas se gestionan hasta su cierre cuando el desempeo o resultados del proyecto se desvan significativamente del plan. SP 2.1 Recolectar y analizar problemas y determinar acciones correctivas para resolverlos. SP 2.2 Tomar accin correctiva sobre problemas identificados. SP 2.3 Gestionar acciones correctivas hasta su cierre. Breve explicacin SP 1.1 Monitorizar valores reales de parmetros de planificacin de proyecto versus el plan de proyecto. 20. Monitorizar con una frecuencia establecida los valores reales de las estimaciones realizadas. Por ejemplo, monitorizar diariamente el sprint burndown o revisar semanalmente el cumplimiento del plazo y esfuerzo planificado de las actividades. 21. Monitorizar que las personas estn cumpliendo con sus responsabilidades. Por ejemplo, mantener sistemticamente breves reuniones diarias para identificar impedimentos o mantener sistemticamente breves reuniones informales con cada participante del equipo o mantener reuniones formales peridicas para revisar el trabajo de cada participante del proyecto. 22. Actualizar el estado y situacin de los riesgos identificados en la planificacin del proyecto. 23. . 23.1. Confirmar que toda la informacin del proyecto documentos de gestin, documentos de ingeniera, cdigo fuente, herramientas, entre otros. se estn guardando en el lugar previsto. 23.2. Confirmar que las medidas de seguridad establecidas para la informacin del proyecto - por ejemplo definir quines tendrn acceso a la informacin del proyecto, qu tipo de acceso (lectura, escritura), quines tendrn acceso a los datos de prueba, entre otros. estn en vigencia. 23.3. Confirmar que la informacin prevista se est enviando a las partes interesadas definidas. Por ejemplo: informe de estado de proyecto a clientes y gerencia. 23.4. Si se estn terminando fases o el proyecto, confirmar que
10 CMMI-DEV v1.3, 20100907

SP 1.2 Monitorizar compromisos versus aquellos identificados en el plan de proyecto.

SP 1.3 Monitorizar riesgos versus aquellos identificados en el plan de proyecto. SP 1.4 Monitorizar la gestin de datos del proyecto versus el plan de proyecto.

Referencia Rpida de CMMI para Desarrollo

se realizan las acciones previstas sobre la informacin del proyecto al terminar el proyecto. Por ejemplo: qu informacin archivar y qu informacin destruir. Mantener reuniones con los participantes del proyecto y asegurar que todos reciben las comunicaciones y estn informados sobre el estado del proyecto incluyendo los casos en los que algn participante no puede asistir a alguna reunin e incluyendo los riesgos y problemas. Mantener con una frecuencia definida reuniones con los participantes del proyecto para monitorizar el avance del proyecto, el desempeo del equipo de trabajo y los problemas, riesgos, impedimentos que afecten el trabajo. Estas reuniones pueden ser informales. Elaborar informacin que describa los logros del proyecto. Por ejemplo, elaborar el informe de estado del proyecto con el avance logrado, la posible desviacin en relacin a lo planificado y tomando en cuenta los cambios acordados en los compromisos (cambios de alcance, cambios a los requerimientos, entre otros). El contenido del estado del proyecto puede variar segn el momento del proyecto. Por ejemplo puede ser el sprint burndown y lista de problemas y riesgos durante una iteracin y el release burndown y lista de problemas y riesgos crticos al final de cada iteracin. Mantener una bitcora del proyecto que incluya todo tipo de evento o situacin frente al cual hay que tomar una decisin porque afecta los objetivos del proyecto. Registrar la informacin que requiera seguimiento o que debe quedar documentada para fines de aprendizaje para futuros proyectos. Por ejemplo: 27.1. Problemas que surgen durante el proyecto. Por ejemplo: enfermedad, accidentes, disponibilidad de recursos, problemas tcnicos, entre otros. 27.2. Riesgos que surgen durante el proyecto. 27.3. Actividades no planificadas y aceptadas por el equipo de trabajo, cliente y gerencia. 27.4. Dependencias con personas fuera del equipo de trabajo. 27.5. Errores que se identificas durante las actividades de verificacin y validacin. 27.6. Desviaciones significativas al avance del proyecto 27.7. Cambios al alcance definido del proyecto y/o a requerimientos acordados. Mantener cada tem de la bitcora con informacin actualizada y pertinente. Mantener el estado de cada tem de la bitcora asegurando que las acciones son efectivas y los tems se cierran. Un tem de la bitcora est en estado abierto o cerrado.

SP 1.5 Monitorizar la involucracin de las partes interesadas versus el plan de proyecto.

24.

SP 1.6 Revisar peridicamente el avance del proyecto, desempeo y problemas.

25.

SP 1.7 Revisar los logros del proyecto y resultados en hitos seleccionados del proyecto.

26.

SP 2.1 Recolectar y analizar problemas y determinar acciones correctivas para resolverlos.

27.

SP 2.2 Tomar accin correctiva sobre problemas identificados. SP 2.3 Gestionar acciones correctivas hasta su cierre.

28. 29.

11 CMMI-DEV v1.3, 20100907

Referencia Rpida de CMMI para Desarrollo

GESTIN DE CONFIGURACIN (CM)
Categora: Soporte Nivel de Madurez: 2 El propsito de Gestin de Configuracin (CM = Configuration Management) es establecer y mantener la integridad de productos de trabajo usando identificacin de configuracin, control de configuracin, contabilizar el estado de la configuracin y auditorias de configuracin. SG 1 Se establecen lneas base de entregables identificados de proceso. SP 1.1 Identificar elementos de configuracin, componentes y productos de trabajo relacionados a ser colocados bajo gestin de configuracin. SP 1.2 Establecer y mantener un sistema de gestin de configuracin y un sistema de gestin de cambios para controlar productos de trabajo. SP 1.3 Crear o liberar lneas base para uso interno y para entregar al cliente. SG 2 Realizar seguimiento y control a los cambios a los productos de trabajo bajo gestin de configuracin. SP 2.1 Realizar seguimiento a solicitudes de cambio de los elementos de configuracin. SP 2.2 Controlar cambios a los elementos de configuracin. SG 3 Establecer y mantener la integridad de las lneas base. SP 3.1 Establecer y mantener registros que describen los elementos de configuracin. SP 3.2 Realizar auditoras de configuracin para mantener la integridad de las lneas base de configuracin. Breve explicacin SP 1.1 Identificar elementos de configuracin, componentes y productos de trabajo relacionados a ser colocados bajo gestin de configuracin. 30. Elaborar la lista de los productos de trabajo que se producirn a lo largo del proyecto indicando quin ser el rol responsable de generar dicho producto de trabajo, si ser interno o se entregar a gerencia y/o al cliente y cmo se controlar dicho producto de trabajo: Dnde se almacenar. Si mantendr un historial de cambios dentro del documento Si se versionar o no Si ser parte de alguna lnea base o no 31. Definir la herramienta a usar para controla la documentacin, cdigo fuente y entregas al cliente. 32. Definir los entornos de trabajo: 32.1. Dnde se almacenar la documentacin de gestin del proyecto. 32.2. Dnde se almacenar la documentacin de gestin del proyecto. 32.3. Dnde se almacenar el cdigo fuente del proyecto y cmo se obtendr el cdigo fuente a ser modificado. 32.4. Cul ser el entorno de desarrollo de cada desarrollador. 32.5. Dnde se realizar la integracin y pruebas del aplicativo. 32.6. Dnde se realizarn las pruebas de aceptacin del aplicativo. 32.7. Dnde se instalar el aplicativo. 33. Enumerar y controlar las lneas base a generar del proyecto. 33.1. En cada entrega al cliente incluyendo la entrega final identificar el conjunto de tems que se estn entregando. Este conjunto de tems (o lnea base) debe estar identificado. El conjunto de tems suele incluir siempre cdigo a ser instalado y puede incluir tambin documentacin adicional como por ejemplo: manual de usuario, manual de instalacin, especificaciones de
12 CMMI-DEV v1.3, 20100907

SP 1.2 Establecer y mantener un sistema de gestin de configuracin y un sistema de gestin de cambios para controlar productos de trabajo.

SP 1.3 Crear o liberar lneas base para uso interno y para entregar al cliente.

Referencia Rpida de CMMI para Desarrollo

requerimientos, plan de pruebas realizado, entre otros. 33.2. Cada vez que se aprueban las especificaciones de requerimientos identificar la versin vigente de las especificaciones aprobadas de requerimientos, comunicar al equipo de trabajo y controlar la forma en que se pueden realizar cambios a las especificaciones aprobadas de requerimientos. 33.3. Controlar las versiones que se prueban para asegurar que se entregan versiones probadas y resolver posibles conflictos que surgen cuando es necesario modificar cdigo que est siendo probado o cuando ms de un desarrollador debe modificar el mismo cdigo. Cada vez que se deba modificar un tem terminado y aprobado registrar en la bitcora del proyecto y/o en el historial de cambios del tem esta accin documentando el impacto de esta cambio en otros tems. Por ejemplo, si es necesario actualizar una especificacin de requerimientos evaluar si adems de actualizar la especificacin de requerimientos es necesario actualizar: el plan de trabajo o cronograma de actividades, otras especificaciones de requerimientos, cdigo fuente que ya se ha terminado, el diseo de la base de datos, entre otros. Por ejemplo, cada vez que se tiene que corregir cdigo por errores identificados en las pruebas, evaluar si adems de actualizar dicho cdigo fuente tambin debe modificarse otro cdigo fuente relacionado, o se debe actualizar la especificacin de requerimientos, el diseo del aplicativo o el plan de trabajo entre otros. Cada vez que se deba modificar un tem terminado y aprobado realizar el cambio de acuerdo al procedimiento establecido para controlar la integridad y versiones de los tems. Es decir, realizar el cambio con la herramienta que controla las versiones de los tems y/o actualizar la seccin historial de cambios del documento y/o documentar el cambio en el tem (por ejemplo en el cdigo fuente de acuerdo a los estndares de programacin). Mantener actualizada la bitcora del proyecto (con los controles de cambio), la seccin historial de cambios de cada tem (que tenga dicha seccin) y actualizar correctamente los campos que la herramienta de control de versiones solicita cuando se modifican tems controlados. Antes de liberar una entrega al cliente, el conjunto de tems a enviar debe ser revisado por alguien distinto a quien prepar la entrega asegurando que el conjunto de tems est identificado, se entregan las versiones correctas, no falta algn tem, las fechas y tamaos de los tems son apropiadas y se han realizado todas las verificaciones y/o validaciones definidas.

SP 2.1 Realizar seguimiento a solicitudes de cambio de los elementos de configuracin.

34.

SP 2.2 Controlar cambios a los elementos de configuracin.

35.

SP 3.1 Establecer y mantener registros que describen los elementos de configuracin.

36.

SP 3.2 Realizar auditoras de configuracin para mantener la integridad de las lneas base de configuracin.

37.

13 CMMI-DEV v1.3, 20100907

Referencia Rpida de CMMI para Desarrollo

MEDICIN Y ANLISIS (MA)
Categora: Soporte Nivel de Madurez: 2 El propsito de Medicin y Anlisis (MA = Measurement and Analysis) es desarrollar y sostener una capacidad de medicin usada para apoyar las necesidades de informacin para gestin. SG 1 Los objetivos y actividades de medicin estn alineadas con las necesidades y objetivos identificados de informacin. SP 1.1 Establecer y mantener objetivos de medicin derivados de las necesidades y objetivos identificados de informacin. SP 1.2 Especificar mediciones para resolver objetivos de medicin. SP 1.3 Especificar cmo los datos de medicin se obtienen y almacenan. SP 1.4 Especificar cmo los datos de medicin se analizan y comunican. SG 2 Proporcionar los resultados de medicin, que resuelven las necesidades y objetivos identificados de medicin. SP 2.1 Obtener datos de medicin especificados. SP 2.2 Analizar e interpretar datos de medicin. SP 2.3 Gestionar y almacenar datos de medicin, especificaciones de medicin y resultados de anlisis. SP 2.4 Comunicar los resultados de medicin y las actividades de anlisis a todas las partes interesadas relevantes.

14 CMMI-DEV v1.3, 20100907

Referencia Rpida de CMMI para Desarrollo

ASEGURAMIENTO DE LA CALIDAD DE PROCESO Y PRODUCTO (PPQA)
Categora: Soporte Nivel de Madurez: 2 El propsito del Aseguramiento de la Calidad de Proceso y Producto (PPQA = Process and Product Quality Assurance) es proporcionar al equipo y administracin visibilidad objetiva de los procesos y productos de trabajo asociados. SG 1 Evaluar objetivamente adherencia del proceso ejecutado y productos de trabajo asociados con las descripciones de proceso, estndares y procedimientos aplicables. SP 1.1 Evaluar objetivamente procesos ejecutados seleccionados versus descripciones de proceso, estndares y procedimientos aplicables. SP 1.2 Evaluar objetivamente productos de trabajo seleccionados versus descripciones de proceso, estndares y procedimientos aplicables. SG 2 A los problemas de no conformidad se les hace seguimiento objetivamente y se comunican y se asegura su solucin. SP 2.1 Comunicar problemas de calidad y asegurar la solucin de problemas de no conformidad con el equipo y gerentes. SP 2.2 Establecer y mantener registros de actividades de aseguramiento de la calidad.

15 CMMI-DEV v1.3, 20100907

Referencia Rpida de CMMI para Desarrollo

ANLISIS DE DECISIN Y SOLUCIN (DAR)
Categora: Soporte Nivel de Madurez: 3 El propsito de Anlisis de Decisin y Solucin (DAR = Decision Analysis and Resolution) es analizar posibles decisiones usando un proceso formal de evaluacin que evala alternativas identificadas versus un criterio establecido. SG 1 Las decisiones se basan en una evaluacin de alternativas usando un criterio establecido. SP 1.1 Establecer y mantener lineamientos para determinar cules problemas estn sujetos a un proceso formal de evaluacin. SP 1.2 Establecer y mantener un criterio para evaluar alternativas y el ranking relativo de estos criterios. SP 1.3 Identificar soluciones alternativas para resolver problemas. SP 1.4 Seleccionar mtodos de evaluacin. SP 1.5 Evaluar soluciones alternativas usando mtodos y criterios establecidos. SP 1.6 Seleccionar soluciones de las alternativas en base a un criterio de evaluacin.

16 CMMI-DEV v1.3, 20100907

Referencia Rpida de CMMI para Desarrollo

GESTIN DEL RIESGO (RSKM)
Categora: Gestin de Proyectos Nivel de Madurez: 3 El propsito de la Gestin del Riesgo (RSKM = Risk Management) es identificar problemas potenciales antes que sucedan de modo que las actividades de manejo de riesgos puedan ser planificadas e invocadas segn sea necesario a lo largo de la vida del producto o proyecto para mitigar impactos adversos en el logro de objetivos. SG 1 Llevar a cabo la preparacin para la gestin de riesgos. SP 1.1 Determinar fuentes y categoras de riesgo. SP 1.2 Definir parmetros usados para analizar y categorizar riesgos y para controlar el esfuerzo de gestin de riesgos. SP 1.3 Establecer y mantener la estrategia a ser usada para gestin de riesgos. SG 2 Los riesgos se identifican y analizan para determinar su importancia relativa. SP 2.1 Identificar y documentar riesgos. SP 2.2 Evaluar y categorizar cada riesgo identificado usando categoras y parmetros definidos de riesgo y determinar su prioridad relativa. SG 3 Los riesgos se manejan y mitigan segn sea apropiado para reducir impactos adversos en el logro de objetivos. SP 3.1 Desarrollar un plan de mitigacin de riesgo de acuerdo a la estrategia de gestin de riesgos. SP 3.2 Monitorizar el estado de cada riesgo peridicamente e implementar el plan de mitigacin de riesgo segn sea apropiado.

17 CMMI-DEV v1.3, 20100907

Referencia Rpida de CMMI para Desarrollo

GESTIN INTEGRADA DE PROYECTO (IPM)
Categora: Gestin de Proyectos Nivel de Madurez: 3 El propsito de la Gestin Integrada de Proyecto (IPM = Integrated Project Management) es establecer y gestionar el proyecto y la involucracin de las partes interesadas relevantes de acuerdo a un proceso integrado y definido que est adaptado a partir del conjunto de procesos estndares de la organizacin. SG 1 El proyecto se lleva a cabo usando un proceso definido adaptado a partir del conjunto de procesos estndares de la organizacin. SP 1.1 Establecer y mantener el proceso definido del proyecto desde el inicio del proyecto y a lo largo de la vida del proyecto. SP 1.2 Usar activos de proceso de la organizacin y el repositorio de medicin para las actividades de estimacin y planificacin de proyecto. SP 1.3 Establecer y mantener el entorno de trabajo del proyecto con base en los estndares del entorno de trabajo de la organizacin. SP 1.4 Integrar el plan de proyecto y otros planes que afectan al proyecto para describir el proceso definido del proyecto. SP 1.5 Gestionar el proyecto usando el plan del proyecto, otros planes que afectan al proyecto y el proceso definido del proyecto. SP 1.6 Establecer y mantener equipos. SP 1.7 Contribuir con experiencias relacionadas a proceso en los activos de proceso de la organizacin. SG 2 Realizar la coordinacin y colaboracin entre el proyecto y las partes interesadas relevantes. SP 2.1 Gestionar la involucracin de las partes interesadas en el proyecto. SP 2.2 Participar con las partes interesadas relevantes en identificar, negociar y realizar seguimiento a dependencias crticas. SP 2.3 Resolver problemas con las partes interesadas relevantes.

18 CMMI-DEV v1.3, 20100907

Referencia Rpida de CMMI para Desarrollo

DESARROLLO DE REQUERIMIENTOS (RD)
Categora: Ingeniera Nivel de Madurez: 3 El propsito de Desarrollo de Requerimientos (RD = Requirements Development) es capturar, analizar y establecer requerimientos de cliente, de producto y de componente de producto. SG 1 Las necesidades, expectativas, restricciones e interfases de las partes interesadas, se recolectan y transforman en requerimientos de cliente. SP 1.1 Capturar necesidades, expectativas, restricciones e interfases de las partes interesadas para todas las fases del ciclo de vida del producto. SP 1.2 Transformar las necesidades, expectativas, restricciones e interfases de las partes interesadas en requerimientos priorizados del cliente. SG 2 Los requerimientos de cliente se afinan y elaboran para desarrollar los requerimientos de producto y de componente de producto. SP 2.1 Establecer y mantener requerimientos de producto y de componente de producto, que estn basados en los requerimientos de cliente. SP 2.2 Asignar los requerimientos para cada componente de producto. SP 2.3 Identificar requerimientos de interfase. SG 3 Los requerimientos se analizan y validan. SP 3.1 Establecer y mantener conceptos operaciones y escenarios asociados. SP 3.2 Establecer y mantener una definicin de la funcionalidad y atributos de calidad requeridos. SP 3.3 Analizar requerimientos para asegurar que ellos son necesarios y suficientes. SP 3.4 Analizar requerimientos para balancear necesidades y restricciones de partes interesadas SP 3.5 Validar los requerimientos para asegurar que el producto resultante funcionar tal como se espera en el entorno del usuario.

19 CMMI-DEV v1.3, 20100907

Referencia Rpida de CMMI para Desarrollo

SOLUCIN TCNICA (TS)
Categora: Ingeniera Nivel de Madurez: 3 El propsito de Solucin Tcnica (TS = Technical Solution) es seleccionar, disear, desarrollar e implementar soluciones a los requerimientos. Las soluciones, diseos e implementaciones incluyen productos, componentes de producto y productos relacionados a los procesos del ciclo de vida ya sea individualmente o en combinacin segn como sea apropiado. SG 1 Producto y componente de producto se seleccionan a partir de soluciones alternativas. SP 1.1 Desarrollar soluciones alternativas y criterio de seleccin. SP 1.2 Seleccionar las soluciones de componente de producto con base en criterio de seleccin. SG 2 Los diseos de producto o de componente de producto se desarrollan. SP 2.1 Desarrollar un diseo para el producto o componente de producto. SP 2.2 Establecer y mantener un paquete tcnico de datos. SP 2.3 Disear interfases de componente de producto usando criterio establecido. SP 2.4 Evaluar si los componentes de producto deben desarrollarse, comprarse o reutilizarse con base en un criterio establecido. SG 3 Los componentes de producto y documentacin de soporte asociada se implementan a partir de sus diseos. SP 3.1 Implementar los diseos de los componentes de producto. SP 3.2 Desarrollar y mantener la documentacin de uso final.

20 CMMI-DEV v1.3, 20100907

Referencia Rpida de CMMI para Desarrollo

INTEGRACIN DE PRODUCTO (PI)
Categora: Ingeniera Nivel de Madurez: 3 El propsito de la Integracin de Producto (PI) es ensamblar el producto a partir de los componentes de producto, asegurar que el producto, as integrado, se comporta apropiadamente (es decir, posee la funcionalidad y atributos de calidad requeridos) y entregar el producto. SG 1 Realizar la preparacin para integracin de producto. SP 1.1 Establecer y mantener una estrategia de integracin de producto. SP 1.2 Establecer y mantener el entorno necesario para apoyar la integracin de los componentes de producto. SP 1.3 Establecer y mantener procedimientos y criterio para la integracin de los componentes de producto. SG 2 Las interfases de componentes de producto, ambas interna y externa, son compatibles. SP 2.1 Revisar la cobertura y completitud de las descripciones de interfase. SP 2.2 Gestionar las definiciones de las interfases internas y externas, diseos y cambios a los productos y componentes de producto. SG 3 Componentes de producto verificados se ensamblan y el producto integrado, verificado y validado se entrega. SP 3.1 Confirmar, antes de ensamblar, que cada componente de producto, requerido para ensamblar el producto ha sido identificado apropiadamente, se comporta de acuerdo a su descripcin y que las interfases del componente de producto satisfacen las descripciones de la interfase. SP 3.2 Ensamblar los componentes de producto de acuerdo a la estrategia y procedimientos de integracin de producto. SP 3.3 Evaluar la compatibilidad de interfases de los componentes de producto ensamblados. SP 3.4 Empaquetar el producto o componente de producto ensamblado y entregarlo al cliente.

21 CMMI-DEV v1.3, 20100907

Referencia Rpida de CMMI para Desarrollo

VALIDACIN (VAL)
Categora: Ingeniera Nivel de Madurez: 3 El propsito de Validacin (VAL = Validation) es demostrar que un producto o componente de producto satisface su uso previsto cuando se instala en su entorno previsto. SG 1 Llevar a cabo la preparacin para la validacin. SP 1.1 Seleccionar productos y componentes de producto a ser validados y mtodos de validacin a ser usados. SP 1.2 Establecer y mantener el entorno necesario para soportar la validacin. SP 1.3 Establecer y mantener procedimientos y criterio para validacin. SG 2 El producto o componentes de producto se validan para asegurar que estn listos para su uso en su entorno de operacin previsto. SP 2.1 Realizar la validacin sobre productos y componentes de producto seleccionados. SP 2.2 Analizar resultados de actividades de validacin.

22 CMMI-DEV v1.3, 20100907

Referencia Rpida de CMMI para Desarrollo

VERIFICACIN (VER)
Categora: Ingeniera Nivel de Madurez: 3 El propsito de Verificacin (VER = Verification) es asegurar que productos de trabajo seleccionados satisfacen sus requerimientos especificados. SG 1 Llevar a cabo la preparacin para la verificacin. SP 1.1 Seleccionar productos de trabajo a ser verificados y mtodos de verificacin a ser usados. SP 1.2 Establecer y mantener el entorno necesario para soportar la verificacin. SP 1.3 Establecer y mantener procedimientos y criterio de verificacin para los productos de trabajo seleccionados. SG 2 Se realizan revisiones de pares sobre productos de trabajo seleccionados. SP 2.1 Prepararse para las revisiones de pares de productos de trabajo seleccionados. SP 2.2 Realizar revisiones de pares de productos de trabajo seleccionados e identificar problemas resultado de estas revisiones. SP 2.3 Analizar datos acerca de la preparacin, realizacin y resultados de las revisiones de pares. SG 3 Productos de trabajo seleccionados se verifican versus sus requerimientos especificados. SP 3.1 Realizar verificacin sobre productos de trabajo seleccionados. SP 3.2 Analizar resultados de todas las actividades de verificacin.

23 CMMI-DEV v1.3, 20100907

Referencia Rpida de CMMI para Desarrollo

METAS GENRICAS
GG 1 El proceso apoya las metas especficas del rea de proceso, transformando productos de trabajo identificables de entrada, en productos de trabajo identificables de salida. GP 1.1 Realizar las prcticas especficas del rea de proceso para desarrollar productos de trabajo y proporcionar servicios para lograr las metas especficas del rea de proceso. GG 2 El proceso est institucionalizado como un proceso gestionado. GP 2.1 Establecer y mantener una poltica organizacional para planificar y ejecutar el proceso. GP 2.2 Establecer y mantener el plan para ejecutar el proceso. GP 2.3 Proporcionar recursos adecuados para ejecutar el proceso, desarrollando los productos de trabajo y proporcionando los servicios del proceso. GP 2.4 Asignar responsabilidad y autoridad para ejecutar el proceso, desarrollando los productos de trabajo y proporcionando los servicios del proceso. GP 2.5 Capacitar, segn sea necesario, a las personas que ejecutan o apoyan el proceso. GP 2.6 Colocar productos de trabajo seleccionados del proceso, bajo niveles apropiados de control. GP 2.7 Identificar e involucrar a las partes interesadas relevantes del proceso segn est planificado. GP 2.8 Monitorizar y controlar el proceso versus el plan para ejecutar el proceso y tomar accin correctiva apropiada. GP 2.9 Evaluar objetivamente adherencia del proceso y de los productos de trabajo seleccionados versus la descripcin del proceso, estndares y procedimientos y resolver no conformidades. GP 2.10 Revisar las actividades, estado y resultados del proceso con gerencia de alto nivel y resolver problemas. GG 3 El proceso est institucionalizado como un proceso definido. GP 3.1 Establecer y mantener la descripcin de un proceso definido. GP 3.2 Recolectar experiencias relacionadas al proceso derivadas de la planificacin y ejecucin del proceso para apoyar el uso futuro y mejora de los procesos y activos de proceso de la organizacin.

24 CMMI-DEV v1.3, 20100907

Referencia Rpida de CMMI para Desarrollo

ACLARACIONES DE LA TRADUCCIN
goal = meta output(s) = resultado(s) performance = desempeo requirement = requerimiento stakeholders = partes interesadas training = capacitacin work product(s) = producto(s) de trabajo

25 CMMI-DEV v1.3, 20100907