Curso Introduction to CMMI DEV

Dirigido a los interesados en aprender sobre el modelo y en particular para los que requieren aplicarlo en sus organizaciones. 

Es una condición para ser miembro de un equipo de evaluación y es la base para tomar otros cursos ofrecidos por el CMMI Institute.  

Durante el curso aprenderá conceptos sobre mejora de procesos así como entender la estructura del modelo, identificar la información y describer las diferentes áreas de proceso. 

Más dinámico, mejor diseño y presentación, mayor interacción y tiempo para aclarar dudas 

• 12 módulos 
• 9 ejercicios 
• Caso de estudio 

Ofrecido por Carlos J. Pérez Escobar Instructor certificado por el CMMI Institute bajo el patrocinio de PROQUA SL

10 prácticas poco efectivas y la solución en CMMI

Foto: Erik Moeller

¿Cómo un proyecto llega a tener un año de retraso? Un día a la vez. (Frederick Brooks, Jr.) 

CMMI es un modelo de prácticas que ayudan al desarrollo de un producto de mejor calidad y al crecimiento del negocio. Considerar su aplicación en la organización implica cambios de hábitos y costumbres que resultan en grandes beneficios, pero que muchas veces deben romper paradigmas muy arraigados dentro del personal.

Andrew Oliver en un artículo publicado por InfoWorld "10 practices of highly ineffective software developers" relaciona las diez prácticas que utilizan los programadores por malos hábitos o presiones del gerente de proyecto y que provocan malos resultados. Esas malas prácticas pueden ser corregidas con las lecciones aprendidas y mejores prácticas establecidas en CMMI y obtener resultados efectivos.

Resumen de Desarrollo del sistema de servicio en CMMI SVC v1.3

Sdepares

El área de proceso de Service System Development (SSD) es adicional para el modelo CMMI SVC y corresponde al nivel 3 de madurez en la representación por etapas y está ubicada en la categoría de procesos de Establecimiento y prestación del servicio para la representación continua.  Su propósito es analizar, diseñar, desarrollar, integrar, verificar y validar el sistema de servicio, incluyendo los componentes del sistema de servicio, para satisfacer los acuerdos de servicios existentes o previstos.


Esta área de proceso se considera adicional porque se ofrece como una alternativa para el desarrollo del sistema de servicio integrando diferentes prácticas en una única área de proceso.  De forma alternativa se pueden utilizar las áreas de proceso de ingeniería del modelo CMMI DEV para los que están familiarizados con este enfoque. 


Considera tanto el desarrollo de sistemas de servicio nuevos o de los cambios a los sistemas existentes. Como sistema de servicio considera la combinación de los componentes del sistema; procesos, productos, personas, consumibles, clientes u otros recursos que permiten ofrecer un valor en respuesta a las necesidades de los interesados. 


En términos generales las metas específicas consideran la recolección, coordinación, análisis, validación y asignación de los requisitos de los interesados para el sistema de servicios. La evaluación y selección de alternativas de solución, el diseño, construcción, integración y documentación del sistema de servicio que cumple esos requisitos. Finalmente el sistema de servicio es verificado y validado para confirmar que satisface los requisitos y que cubrirá las expectativas de uso del cliente y usuarios durante la prestación del servicio.

Agile, cuestión de principios más que técnica

"Agile Adoption Equals Mental Shift", un artículo de Peter DeYoe en su blog, plantea la necesidad de cambio de modelos mentales para la ejecución de los proyectos y el entendimiento del valor real para el negocio cuando se intenta adoptar los principios Agile para el desarrollo de software. Más que enfocarse en las técnicas o métodos, lo importante es entender y aplicar los principios que guían el desarrollo de software bajo este paradigma.
La adopción de las prácticas y el cambio de cultura requiere que el negocio sea capaz de entender la dinámica de este tipo de proyectos y adaptarse a ella. No basta con crear equipos motivados, integrados y autodirigidos, bajo el enfoque de SCRUM si la organización sigue esperando un presupuesto global del proyecto que integre todas las necesidades iniciales, agreguen o no valor al producto. 

Agile y PMO, dos historias y un mismo final

Lehmann, Thomas

El uso de los enfoques Agile y PMO (Project Management Office) consideran diferentes perspectivas para la gestión y conducción de un proyecto. Hablan diferentes lenguajes pero al final deben llegar al mismo resultado. En ambos casos deben garantizar el cumplimiento de los objetivos del proyecto, desde enfoques diferentes. ¿Cómo manejar e integrar ambas perspectivas?

Asignación de requisitos a componentes

La SP 2.2 en RD establece la necesidad de asociar los componentes del producto con los requisitos que los definen. De manera que los componentes que se van derivando tienen un requisito asociado que los define. 


Por su parte en REQM, en la SP 1.4 se establece la trazabilidad bidireccional de los requisitos hacia las entidades que se obtienen. Lo cual constituye una herramienta fundamental en la evaluación de impacto de los cambios a requisitos. 


¿Cuál es el sentido de cada práctica, si aparentemente ambas llevan una relación de requisitos a componentes?

Características deseables de un requisito

Dentro de las prácticas de REQM en la SP1.1 se tiene que establecer cuáles son los requisitos que serán acordados. Para lograr esto además de que se tenga una fuente autorizada para definir los requisitos, éstos deben ser adecuadamente definidos. Cuando se implementa en conjunto con RD, en la SP 3.3, se puede revisar el cumplimiento de esas características como elemento para comprobar que los requisitos son necesarios y suficientes. 


Para facilitar la actividad se puede elaborar una lista de verificación con las características que se deben cumplir y considerarlas en la realización de la revisión de los requisitos. Los requisitos que no cumplan con estas condiciones deben ser redefinidos y ajustados antes de ser comprometidos para evitar problemas en el desarrollo del producto.

Resumen de Solución técnica en CMMI DEV v1.3

El área de proceso de Technical Solution (TS) corresponde al nivel 3 en la representación por etapas y está ubicada dentro de la categoría de proceso de Ingeniería para la representación continua. Tiene como propósito diseñar, desarrollar e implementar soluciones para los requerimientos. Las soluciones, los diseños y las implementaciones engloban productos, componentes de producto y procesos del ciclo de vida asociados al producto, de manera individual o en combinación, según sea apropiado.


TS es el centro del desarrollo y mantenimiento del producto, depende de los requerimientos definidos en RD para generar el producto y que se mantienen actualizados a través de REQM. Como parte de las prácticas definidas se desarrolla, de manera iterativa, las diferentes soluciones a los requerimientos del cliente, productos y componentes del producto. Esas soluciones son diseñadas y finalmente construidas para crear el producto o servicio y los procesos asociados durante todo el ciclo de vida.


Las metas definidas en TS interactúan en diferentes etapas del desarrollo y en diferentes instancias del producto y sus componentes. El establecimiento de soluciones, el desarrollo del diseño y la implementación del diseño se ejecutan de manera iterativa de acuerdo con las necesidades del desarrollo.


En la versión 1.3 del modelo no existen cambios significativos en cuanto a las metas y prácticas específicas para esta área de proceso. 


Establecer soluciones
SG1 Las soluciones de producto o de componentes de producto son seleccionadas a partir de soluciones alternativas.

• SP1.1 Desarrollar las soluciones alternativas y los criterios de selección.
• SP1.2 Seleccionar las soluciones de componentes de producto con base en los criterios de selección.

Desarrollar el diseño a las soluciones

SG2 Los diseños de producto o de los componentes de producto son desarrollados.

• SP2.1 Desarrollar un diseño para el producto o el componente de producto.
• SP2.2 Establecer y mantener un paquete de datos técnicos.
• SP2.3 Diseñar las interfaces de componentes de producto usando los criterios establecidos.
• SP2.4 Evaluar si los componentes de producto se deberían desarrollar, comprar o reutilizar en base a los criterios establecidos.

Implementar el diseño

SG3 Los componentes de producto y la documentación de soporte asociada son implementadas a partir de sus diseños.

• SP3.1 Implementar los diseños de los componentes de producto.
• SP3.2 Desarrollar y mantener la documentación de uso final

Resumen de Integración del producto en CMMI DEV v1.3

El área de proceso de Product Integration (PI) corresponde al nivel 3 en la representación por etapas y está ubicada dentro de la categoría de proceso de Ingeniería para la representación continua. Tiene como propósito ensamblar el producto a partir de sus componentes, asegurar que el producto, una vez integrado, funciona correctamente (ej. posee la funcionalidad requerida y los atributos de calidad), y entregar el producto.


Aunque PI maneja como propósito el ensamblado de componentes y comprobación del funcionamiento del producto ensamblado antes de la entrega, eso solamente hace referencia a la meta específica 3 del área de proceso. Para cubrir las otras dos metas específicas se requiere definir y establecer la infraestructura para la integración del producto y gestionar las interfaces durante todo el ciclo de desarrollo del producto para garantizar, en el momento de la integración, que no se presenten problemas.


Por ello, aunque el resultado de PI es el producto integrado, para poder llegar hasta ahí es fundamental una efectiva gestión de las interfaces. Las interfaces se identifican como requerimientos en RD, se diseñan en TS y finalmente se gestionan para facilitar la integración en PI. 


En la versión 1.3 del modelo no existen cambios significativos en cuanto a las metas y prácticas específicas para esta área de proceso. En general se hace énfasis en el establecimiento de la estrategia de integración y se aclaran algunos términos que no eran bien interpretados.


Establecer la infraestructura para la integración
SG1 La preparación para la integración del producto es llevada a cabo.

• SP1.1 Establecer y mantener la estrategia de integración del producto.
• SP1.2 Establecer y mantener el entorno necesario para dar soporte a la integración de los componentes del producto.
• SP1.3 Establecer y mantener los procedimientos y los criterios para integración de los componentes del producto

Gestionar las interfaces entre componentes
SG2 Las interfaces del componente de producto, tanto internas como externas, son compatibles.

• SP2.1 Revisar las descripciones de la interfaz en cuanto a cobertura y completitud.
• SP2.2 Gestionar las definiciones, diseños y cambios de las interfaces internas y externas para los productos y los componentes de producto.

Ensamblar los componentes para liberar el producto
SG3 Los componentes de producto verificados son ensamblados y el producto integrado, verificado y validado es entregado.

• SP3.1 Confirmar, antes de ensamblar, que cada componente de producto requerido para ensamblar el producto ha sido identificado correctamente, funciona de acuerdo con su descripción y que las interfaces de componente de producto cumplen con las descripciones de la interfaz.
• SP3.2 Ensamblar los componentes de producto de acuerdo a los procedimientos y estrategia de integración del producto.
• SP3.3 Evaluar los componentes de producto ensamblados para compatibilidad de la interfaz.
• SP3.4 Empaquetar el producto o componente de producto ensamblado y entregarlo al cliente.

Resumen de Desarrollo de requisitos en CMMI DEV v1.3

El área de proceso de Requirements Development (RD) corresponde al nivel 3 en la representación por etapas y está ubicada dentro de la categoría de proceso de Ingeniería para la representación continua. Tiene como propósito producir y analizar los requisitos del cliente, del producto y de los componentes del producto.


Las prácticas definidas en esta área de proceso permiten determinar todos los requisitos del proyecto, ya sea para el desarrollo o mantenimiento. Parte de los requisitos del cliente que son derivados en requisitos del producto hasta refinarlos al nivel de requisitos de los componentes del producto, todo esto durante el ciclo de vida del producto. El proceso de obtención y refinamiento de los requisitos va estrechamente vinculado con el diseño del producto por lo que estas prácticas están relacionadas, de manera recursiva, con las establecidas en el área de proceso de Technical Solution (TS).


Los cambios que se requieran a los requisitos establecidos en RD son gestionados por REQM, por lo que RD, TS y REQM están estrechamente relacionados y operan de manera concurrente. La razón por la que REQM está en un nivel de madurez inferior a RD puede estar relacionado con el principio que establece que primero hay que establecer un control y orden en las actividades que se realizan, esto se logra con REQM, para después especializar la forma en que se realizan las actividades, en este caso las prácticas de RD.


RD establece en las primeras metas específicas la definición de los requisitos del cliente y los requisitos del producto y componentes. Con la meta tres complementa las dos anteriores para garantizar que todos los requisitos obtenidos son adecuadamente analizados y validados durante las diferentes etapas del desarrollo del producto. 


En la versión 1.3 del modelo no existen cambios significativos en cuanto a las metas y prácticas específicas para esta área de proceso.


Definir los requisitos del cliente

SG1 Las necesidades, expectativas, restricciones e interfaces de los interesados son recogidas y traducidas a requisitos del cliente.

• SP1.1 Obtener las necesidades, las expectativas, las restricciones, y las interfaces de los interesados para todas las fases del ciclo de vida del producto.
• SP1.2 Transformar las necesidades, las expectativas, las restricciones y las interfaces de las partes interesadas en requisitos del cliente.

Derivar los requisitos del producto y componentes del producto

SG2 Los requisitos del cliente son refinados y elaborados para desarrollar los requisitos del producto y de componentes del producto.

• SP2.1 Establecer y mantener los requisitos del producto y de componentes del producto, los cuáles están basados en los requisitos del cliente.
• SP2.2 Asignar los  requisitos  para cada componente del producto.
• SP2.3 Identificar los  requisitos  de la interfaz.

Analizar y validar los requisitos definidos

SG3 Los  requisitos son analizados y validados, y una definición de la funcionalidad requerida es desarrollada.

• SP3.1 Establecer y mantener los conceptos operativos y los escenarios asociados.
• SP3.2 Establecer y mantener una definición de la funcionalidad requerida y los atributos de calidad.
• SP3.3 Analizar los requisitos para asegurarse de que son necesarios y suficientes.
• SP3.4 Analizar los requisitos para equilibrar las necesidades y las restricciones de los interesados.
• SP3.5 Validar los requisitos para asegurar que el producto resultante se ejecutará según lo previsto en el entorno del usuario.

Resumen de Gestión de requisitos en CMMI v1.3

El área de proceso de Requirements Management (REQM) corresponde al nivel 2 en la representación por etapas y está ubicada dentro de la categoría de proceso de Gestión de proyectos para la representación continua. Tiene como propósito gestionar los requisitos de los productos y de los componentes del producto del proyecto, e identificar inconsistencias entre esos requisitos y los planes y productos de trabajo del proyecto.

Las prácticas de REQM son la base para la definición y ejecución de las actividades del proyecto y constituyen la entrada para PP. Básicamente aquí se garantiza que los requisitos  son válidos, tanto por el contenido como por la fuente de donde se originan, que están comprometidos y que si son modificados se realiza de manera controlada. Para poder determinar el impacto de los cambios es imprescindible contar con una traza de los  requisitos hacia las diferentes entidades del producto y a la inversa.

ROI en Inspecciones

David F. Rico en un artículo publicado en Noviembre del 2002 en la revista Software Tech News “How to Estimate ROI for Inspections, PSP, TSP, SW CMM, ISO 9000 and CMMI” ofrece, entre otros, un ejemplo muy concreto para obtener el retorno de inversión (ROI) en la aplicación de las inspecciones. 


En términos generales el ROI es el cálculo de los beneficios en términos económicos que se esperan obtener como resultado de la inversión de recursos y activos en una organización. Se utilizan dos ecuaciones que obtienen la tasa de Beneficios vs. Costos (B/C R), dividiendo los beneficios entre los costos y el %ROI que es la tasa de sustraer los Costos a los Beneficios antes de dividirlo entre los Costos. 


Costo de capacitación e implementación 
Se considera para el ejemplo un costo de capacitación de $410.00 por persona durante tres días y suponiendo un costo por persona de $100.00 por hora implicarías $2.400.00 adicional al costo del curso, sería $2,810.00 por persona. Considerando que sean cuatro personas las que toman el curso el total de capacitación serían $11,240.00. 


Se considera que los recursos capacitados participan en un proyecto de 10,000 SLOC y que consideran en cada revisión 240 SLOC para 41,67 reuniones. Se suponen 17 horas por revisión, considerando la planificación, preparación, ejecución y seguimiento, se requieren 708.33 horas. Considerando el costo por persona de $100,000.00, el costo de revisión es de $70,833.00. 


El costo total, considerando el costo de capacitación y de implementación es de $82,073.00.  


Beneficios obtenidos 
Para el proyecto de 10,000 SLOC se estima, después de las inspecciones, un esfuerzo para mantenimiento de 11,806 horas. Mientras que para un proyecto similar sin inspecciones el esfuerzo se estima en 41,800 horas, lo que implica un ahorro de 29,994 horas para el caso de las inspecciones. Traducidas a los $100.00 por hora se convierten en ahorros por $2,999,400.00.  


Considerando la ecuación de B/C R ($2,999,400.00 / $82,073.00) se obtiene una tasa aproximada de 37:1 mientras que el %ROI ($2,999,400.00 - $82,073.00 / $82,073.00) *100 se obtiene 3,555%. 


El ejemplo puede ser muy claro para demostrar los beneficios que se obtiene. Se pueden hacer los cálculos con números de cada organización o jugar con otros valores, hay otros ejemplos que utilizan el ahorro que se obtiene por la corrección temprana de defectos. Estas son bases para obtener los números y poder demostrar la ventaja de aplicar estas técnicas de inmediato en la organización.

Proyectos de mantenimiento

El modelo CMMI DEV, según se establece en el prefacio, "es un modelo de madurez para la mejora de procesos de desarrollo de productos y servicios". Contiene mejores prácticas orientadas a las actividades de desarrollo y mantenimiento que cubren el ciclo de vida del producto desde su creación hasta la liberación y mantenimiento. Adicionalmente en el glosario establece que desarrollo incluye también las actividades de mantenimiento, por lo que las empresas pueden considerar las prácticas tanto para el desarrollo como el mantenimiento.

Aplicación de prácticas a proyectos de mantenimiento

En empresas dedicadas al desarrollo y comercialización de productos propios, típicamente sus proyectos son mayormente de mantenimiento correctivo o por mejoras. En este caso la aplicación de las prácticas de ingeniería, en el modelo CMMI, son cuestionadas por los ciclos que tienen para los proyectos, en general con un esfuerzo disponible de horas o días para ofrecer la solución.

Una posible alternativa es manejar los proyectos de mantenimiento por ciclos, tal vez un año o seis meses, donde se considere la planificación de recursos y mecanismos de seguimiento.

Lo ideal para estos proyectos es contar con una herramienta para seguimiento de órdenes de servicio o requerimientos de cambio. En la misma herramienta se puede documentar fácilmente lo que se hizo y así tener documentado todo el producto en un repositorio único. Para las actividades de PPQA lo mejor es definir periodos de revisión y elegir las órdenes que se tengan ya sean cerradas o activas, mayormente los hallazgos son lecciones aprendidas para las siguientes.

En el caso de las mejoras planeadas que pueden ser proyectos de más tiempo y mejor controlados se puede tener un esquema más amplio aunque muchas veces se reutilizan muchos de los artefactos porque los ambientes, productos y recursos muchas veces son los mismos.

CCB: Configuration Control Board o Change Control Board

En el modelo CMMI, en el área de proceso de Configuration Management (CM), se establece la existencia del CCB como parte de las prácticas y funciones para el control de los componentes de configuración. Este acrónimo que viene de Configuration Control Board o Change Control Board se refiere al Comité de control de la configuración o Comité de control de cambios.

Funciones y estructura del CCB El comité de control de cambios tiene la autoridad para aceptar o rechazar las propuestas de cambio a componentes de configuración. Como estos cambios tienen sentido controlarlos una vez que se crean las líneas base, el comité de control de cambios tiene la autoridad para gestionar las líneas base del producto y asegurar que los cambios son adecuadamente considerados y coordinados. De acuerdo con el tamaño de la organización, proyecto y complejidad del producto se pueden requerir diferentes niveles de control. En proyectos pequeños es una responsabilidad del líder o persona asignada en lugar de un grupo de personas. Pueden existir múltiples niveles de autoridad de acuerdo con la criticidad de los cambios, la naturaleza respecto al impacto en presupuesto y calendario o la etapa del ciclo de vida.

Composición del CCB La composición del comité varia dependiendo de los niveles de autoridad requeridos, siempre existe un representante de gestión de la configuración y los representantes de los involucrados al nivel que corresponda. El comité de control de cambios puede incluir como miembros al personal de:

• Desarrollo
• Aseguramiento de calidad
• Gestión de la configuración
• Pruebas y control de calidad
• Documentación
• Mantenimiento
• Liberación del producto
• Gerente de proyecto/programa
• Ingeniería de sistema o hardware
• Representantes del cliente
• Áreas administrativas: Comercial, financiero o ventas

Las actividades del comité de control de cambios están sujetas a revisiones de aseguramiento de calidad y auditorías a la configuración, para evaluar el cumplimiento de sus actividades.

Resumen de Integración del producto

El área de proceso de Product Integration (PI) corresponde al nivel 3 en la representación por etapas y está ubicada dentro de la categoría de proceso de Ingeniería para la representación continua. Tiene como propósito ensamblar el producto a partir de sus componentes, asegurar que el producto, una vez integrado, funciona correctamente, y entregar el producto. 

Aunque PI maneja como propósito el ensamblado de componentes y comprobación del funcionamiento del producto ensamblado antes de la entrega, eso solamente hace referencia a la meta específica 3 del área de proceso. Para cubrir las otras dos metas específicas se requiere definir y establecer la infraestructura para la integración del producto y gestionar las interfaces durante todo el ciclo de desarrollo del producto para garantizar, en el momento de la integración, que no se presenten problemas. Por ello, aunque el resultado de PI es el producto integrado, para poder llegar hasta ahí es fundamental una efectiva gestión de las interfaces. 

Las interfaces se identifican como requerimientos en RD, se diseñan en TS y finalmente se gestionan para facilitar la integración en PI. 

Establecer la infraestructura para la integración 
SG1 La preparación para la integración del producto es llevada a cabo.

• SP1.1 Determinar la secuencia de integración del componente de producto
• SP1.2 Establecer y mantener el entorno necesario para dar soporte a la integración de los componentes del producto.
• SP1.3 Establecer y mantener los procedimientos y los criterios para integración de los componentes del producto

Gestionar las interfaces entre componentes

SG2 Las interfaces del componente de producto, tanto internas como externas, son compatibles.

• SP2.1 Revisar las descripciones de la interfaz en cuanto a cobertura y completitud.
• SP2.2 Gestionar las definiciones, diseños y cambios de las interfaces internas y externas para los productos y los componentes de producto.

Ensamblar los componentes para liberar el producto

SG3 Los componentes de producto verificados son ensamblados, y el producto integrado es verificado y validado antes de ser entregado.

• SP3.1 Confirmar, antes de ensamblar, que cada componente de producto requerido para ensamblar el producto ha sido identificado correctamente, funciona de acuerdo con su descripción y que las interfaces de componente de producto cumplen con las descripciones de la interfaz.
• SP3.2 Ensamblar los componentes de producto de acuerdo a la secuencia de integración de producto y a los procedimientos disponibles.
• SP3.3 Evaluar los componentes de producto ensamblados para la compatibilidad de la interfaz.
• SP3.4 Empaquetar el producto o componente de producto ensamblado y entregar al cliente apropiado.

Resumen de Solución técnica

El área de proceso de Technical Solution (TS) corresponde al nivel 3 en la representación por etapas y está ubicada dentro de la categoría de proceso de Ingeniería para la representación continua. Tiene como propósito diseñar, desarrollar e implementar soluciones para los requerimientos. Las soluciones, los diseños y las implementaciones engloban productos, componentes de producto y procesos del ciclo de vida asociados al producto, de manera individual o en combinación, según sea apropiado. TS es el centro del desarrollo y mantenimiento del producto, depende de los requerimientos definidos en RD para generar el producto y que se mantienen actualizados a través de REQM. Como parte de las prácticas definidas se desarrolla, de manera iterativa, las diferentes soluciones a los requerimientos del cliente, productos y componentes del producto. Esas soluciones son diseñadas y finalmente construidas para crear el producto o servicio y los procesos asociados durante todo el ciclo de vida. Las metas definidas en TS interactúan en diferentes etapas del desarrollo y en diferentes instancias del producto y sus componentes. El establecimiento de soluciones, el desarrollo del diseño y la implementación del diseño se ejecutan de manera iterativa de acuerdo con las necesidades del desarrollo. Establecer soluciones SG1 Las soluciones de producto o de componentes de producto son seleccionadas a partir de soluciones alternativas.

• SP1.1 Desarrollar las soluciones alternativas y los criterios de selección.
• SP1.2 Seleccionar las soluciones de componentes de producto que mejor satisfacen los criterios establecidos.

Desarrollar el diseño a las soluciones

SG2 Los diseños de producto o de los componentes de producto son desarrollados.

• SP2.1 Desarrollar un diseño para el producto o el componente de producto.
• SP2.2 Establecer y mantener un paquete de datos técnicos.
• SP2.3 Diseñar las interfaces de componentes de producto usando los criterios establecidos.
• SP2.4 Evaluar si los componentes de producto se deberían desarrollar, comprar o reutilizar en base a los criterios establecidos.

Implementar el diseño

SG3 Los componentes de producto y la documentación de soporte asociada son implementadas a partir de sus diseños.

• SP3.1 Implementar los diseños de los componentes de producto.
• SP3.2 Desarrollar y mantener la documentación de uso final

Resumen de Gestión de requerimientos

El área de proceso de Requirements Management (REQM) corresponde al nivel 2 en la representación por etapas y está ubicada dentro de la categoría de proceso de Ingeniería para la representación continua. Tiene como propósito gestionar los requerimientos de los productos y de los componentes del producto del proyecto, e identificar inconsistencias entre esos requerimientos y los planes y productos de trabajo del proyecto. Las prácticas de REQM son la base para la definición y ejecución de las actividades del proyecto y constituyen la entrada para PP. Básicamente aquí se garantiza que los requerimientos son válidos, tanto por el contenido como por la fuente de donde se originan, que están comprometidos y que si son modificados se realiza de manera controlada. Para poder determinar el impacto de los cambios es imprescindible contar con una traza de los requerimientos hacia las diferentes entidades del producto y a la inversa. Cuando se presentan cambios a requerimientos, y es algo que sucederá en la gran mayoría de las ocasiones, pueden presentarse inconsistencias particularmente por problemas de comunicación dentro del equipo que desconoce los cambios que han sido aprobados. REQM debe identificar esas situaciones y tomar acciones correctivas para garantizar su solución. Gestionar los requerimientos SG1 Los requerimientos son gestionados y las inconsistencias con los planes y productos de trabajo del proyecto son identificadas.

• SP1.1 Desarrollar una comprensión del significado de los requerimientos con los proveedores de los requerimientos.
• SP1.2 Obtener el compromiso de los participantes de proyecto sobre los requerimientos.
• SP1.3 Gestionar los cambios a los requerimientos a medida que evolucionan durante el proyecto
• SP1.4 Mantener la trazabilidad bidireccional entre los requerimientos y los productos de trabajo
• SP1.5 Identificar las inconsistencias entre los planes del proyecto, los productos de trabajo y los requerimientos.

Actualización sobre cambios en la versión 1.3 de CMMI

Recientemente el SEI publicó internamente la versión draft de lo que será el CMMI v1.3. Revisando la documentación, además de los cambios que ya se habían anunciado, hay algunas modificaciones que destacan en una primera ojeada.