Dudas sobre las auditorías en CMMI

Una auditoría, según el glosario de CMMI, es una revisión objetiva de un producto o conjunto de productos de trabajo contra criterios establecidos. En ocasiones se confunde la existencia de auditorías como parte de las prácticas de CM con la forma de realizar el aseguramiento de calidad en PPQA.

Un lector hace algún tiempo envió este comentario: 

"Tengo cierta confusión con las auditorías de PPQA y de CM. Si en PPQA defino auditorías para cada Área de Proceso, incluyendo CM, ¿deberé definir otras de CM también? ¿Cuál sería la diferencia? He pensado que tal vez las auditorías de CM se refieren a líneas base, y en este sentido están bien diferenciadas de la de PPQA. Entonces, si antes de hacer una línea base realizamos una auditoría de CM, ¿cubriríamos SG3 de CM? Por último, las revisiones se refieren a producto y a proceso. ¿Se consideran como producto los entregables resultantes de realizar los procesos de calidad definidos?"

Plan de gestión de la configuración

El plan de gestión de la configuración constituye un elemento clave para establecer y garantizar la integridad del producto durante el proceso de desarrollo. Es considerado como parte de las actividades que se cubren en el área de proceso de Configuration Management (CM), en particular para el cumplimiento de las prácticas genéricas asociadas. 

Cambios a requisitos y control de cambios

El modelo CMMI establece prácticas para control de cambios en dos áreas de proceso: REQM y CM. En la primera la SP 1.3 gestiona los cambios a requisitos durante el proyecto, mientras que en la segunda la SG2 contiene prácticas para registrar y controlar los cambios a los componentes bajo gestión de la configuración.


Estas prácticas son complementarias y para efectos del modelo se separan para analizarlas con propósitos diferentes. La organización puede determinar un mecanismo de control que le permita cumplir con ambas perspectivas.

Resumen de Gestión de la configuración en CMMI v1.3

El área de proceso de Configuration Management (CM) corresponde al nivel 2 en la representación por etapas y está ubicada dentro de la categoría de proceso de Soporte para la representación continua. Tiene como propósito establecer y mantener la integridad de los productos de trabajo utilizando la identificación de la configuración, el control de configuración, el registro del estado de configuración y las auditorías de configuración.


En general CM cubre el control de los productos de trabajo a través de las actividades de la disciplina de gestión de la configuración reflejadas en las diferentes metas específicas. 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.

Cambios en la estructura del modelo

Con la versión 1.3 del modelo CMMI, en todas las constelaciones, se realizaron cambios en cuanto a la forma en que se agrupan las áreas de proceso y los elementos que la integran. En su mayoría son cambios que permiten mejor consistencia entre los modelos y simplificar ciertos elementos. 


Estructura y representaciones 
En la presentación de los componentes de las áreas de proceso, en el capítulo 2, y en la visión de conjunto, del capítulo 3, se presentan y definen componentes que pueden ser inconsistentes con lo que se define en el glosario. Estos elementos fueron revisados y ajustados para evitar esas inconsistencias. Se reestructuraron las definiciones, “Typical work product” ahora será “Example work product” al igual que “Typical supplier deliverable” que en CMMI ACQ será “Example supplier deliverable”. 


La descripción de las representaciones, “Staged” y “Continuous”, fueron revisadas para disminuir el énfasis en las diferencias y la importancia de la representación en el modelo. No se hará preferencia de una u otra, solamente es una forma de organizar las áreas de proceso que no tiene impacto en el resultado para la organización. 

En el caso de las categorías de proceso fueron renombradas y las áreas de proceso relocalizadas: 

• En CMMI ACQ la categoría de Adquisición ahora será Ingeniería de adquisición y se relocalizan las áreas de proceso AM (Agreement Management) y SSAD (Solicitation & Supplier Agreement Development) en la categoría de Gestión de proyectos. 
• En CMMI DEV el área de proceso REQM (Requirements Management) se ubica ahora en la categoría de Gestión de proyectos. 
• En CMMI SVC la categoría de Gestión de proyectos cambia por Gestión de proyectos y trabajo. 

Elementos y componentes
Las ampliaciones asociadas con disciplinas, como ingeniería de: sistemas, software y hardware, serán eliminadas para evitar confusión. De igual forma las referencias a áreas de proceso han sido revisadas para facilitar el uso de la información que se desea buscar. 


Ahora en el modelo CMMI DEV la información sobre las metas y prácticas genéricas se describe únicamente al inicio de la parte 2, como se presenta en CMMI ACQ y CMMI SVC. Se integran conceptos, definiciones y ejemplos relacionados con productos y servicios, así como proveedores y acuerdos. 


En general el glosario fue revisado y eliminadas las inconsistencias, en algunos casos fueron homologados con definiciones del estándar ISO y mejorada la claridad de las definiciones. 


En resumen, son pequeñas modificaciones que facilitan el uso del modelo y la interpretación adecuada de sus diferentes componentes.

Sobre el tipo y contenido de las líneas base

En días recientes publiqué un artículo sobre las líneas base para el control de la configuración. Un colega me hizo llegar la siguiente pregunta, que reproduzco completamente.


"Acerca de las líneas base, comentas que formalmente se establecen cuatro, si bien esas líneas base están a su vez relacionadas entre sí, es decir, existe una correspondencia entre líneas base funcionales, de definición, de desarrollo y de producto. En proyectos de desarrollo que siguen metodologías clásicas es más o menos habitual recibir las peticiones de cambio al final de los desarrollos, durante la fase de pruebas del producto, lo que afectaría a todas las líneas base, teniendo, por ejemplo que la línea base 1 Funcional corresponde con la línea base 3 de desarrollo, y tras la petición de cambio la línea base 2 Funcional corresponde con la línea base 4 de desarrollo, una relación entre las diferentes líneas base. 


Comentas que cada organización o proyecto determina el contenido y tipo de líneas base. ¿Sería válido establecer líneas base globales del proyecto definidas como un conjunto completo de entregables del proyecto, y que las líneas base cambien siempre debido a una petición de cambio (bien interna o bien del cliente) y que se lleve por control de configuración las versiones de los diferentes productos (Plan de Proyecto, Planificación, Análisis Funcional, Matrices de trazabilidad, software, manuales,....) que incluye cada línea base? "


Líneas base y control de configuración
Sobre este punto es conveniente puntualizar algunas cuestiones en principio para poder aclarar el planteamiento. Cuando menciono que son “líneas bases formales” es porque en cualquier literatura sobre el tema es muy común encontrar la referencia a ellas, pero no implica que el modelo o la práctica obligue a cubrir el número y contenido de las líneas base que se plantearon. 


Por otra parte se pueden implementar diferentes niveles de control según las necesidades del proyecto u organización. En ciertos componentes es necesario un control y gestión de la configuración que cumpla con todos los elementos definidos por CM, que sería un nivel alto de control, y por otro lado podemos tener componentes donde es suficiente conocer su ubicación y la última versión aprobada con un nivel más bajo de control asociado con documentos y productos del proceso (Planes, registros, acuerdos, matrices y demás). Esto se puede encontrar explicado en las notas que acompañan a la práctica genérica 2.6 en el modelo CMMI, al inicio de la parte II. 


Definición de las líneas base
El sentido de definir una línea base es más con el objetivo de permitir la comunicación adecuada entre los grupos que participan en un proyecto, de manera que si esa línea base se modifica sea fácil identificar la afectación que pueden tener los grupos que están haciendo uso de ellas. 


Por poner un ejemplo, cuando un arquitecto realiza los planos de una construcción y son aprobados, el maestro albañil toma esos planos para comenzar el trabajo. Durante la obra considera adecuado que se requiere modificar una pared para crear un ventanal, primero debe revisar con el arquitecto la cuestión estructural para decidir el impacto que puede tener en la construcción y la afectación que puede tener con instalaciones eléctricas, hidráulicas o de seguridad que él no visualiza al querer dejar el espacio para la ventana. En este caso los resultados se deben reflejar nuevamente en los planos y permitir que todos estén informados de esas adecuaciones. En este caso el plano y los documentos asociados es una línea base, y quizás la siguiente pueda ser la obra ya terminada.


Las líneas base deben funcionar en el mismo sentido y tener sentido para el proyecto y los grupos que participan. Si tengo un ciclo de cascada y un solo equipo de trabajo que contribuye a la solución, posiblemente la línea base de producto sea suficiente para garantizar mantenimientos posteriores. Pero si en ese mismo ciclo de vida tengo grupos independientes, tal vez el escenario cambia y necesite definir líneas base que permitan entregar los elementos que el otro grupo requiere. Por así decirlo, la documentación de análisis para el diseño, los resultados del diseño para el desarrollo y los productos del desarrollo para probar y liberar el producto, marcarían las líneas base que se necesitan. 


Las líneas base tienen sentido para el proyecto y el desarrollo del producto
La decisión de las líneas base y contenido se pueden establecer al inicio del proyecto como parte del Plan de gestión de la configuración. Pueden ser modificadas y ajustadas en la medida que avanza el proyecto. Pero en cualquier caso se debe considerar la estructura de los equipos de trabajo y la comunicación que se requiere entre ellos, las fases y secuencia del ciclo de vida y que ayude a gestionar la evolución de los componentes. Si en algún momento sentimos que no son apropiadas o no es práctico ejecutarlas como se planteó, debemos hacer las modificaciones para permitir un uso adecuado. 


Sólo los proyectos y la organización determinan el tipo y contenido de las líneas base. El principio a tener en cuenta es, partiendo del concepto de línea base, primero debe ser aprobado el contenido de alguna manera para garantizar el resultado de las etapas posteriores, luego el contenido debe ser útil para las siguientes etapas y por eso tiene sentido controlarlo y finalmente cualquier cambio debe hacerse de manera controlada (el nivel de control lo determina el proyecto) de manera que no se afecten los grupos que están haciendo uso de ese contenido. 


Sobre la pregunta inicial es completamente adecuado si así funciona para el proyecto. Se puede tener un identificador de esa línea base con todas las versiones de los diferentes componentes que la integran y en caso de cambio ajustar el identificador de la línea base con las nuevas versiones de los componentes modificados. El tema puede dar para mucha discusión pero queda abierto por si aún no es claro, poder ampliarlo en trabajos posteriores. Al fin de cuentas esto nos sirve de línea base. ;-)

Líneas base

De acuerdo con el modelo CMMI una línea base es un conjunto de especificaciones o productos de trabajo que han sido formalmente revisadas y acordadas, que sirven como base para un desarrollo posterior y que sólo pueden ser modificadas por medio del procedimiento establecido de control de cambios. 
El área de proceso de CM establece como uno de sus objetivos principales el establecimiento y actualización de las líneas base del producto o productos de trabajo como una forma de crear bases estables para la evolución continua de los componentes de configuración. Las líneas base son incorporadas al sistema de gestión de la configuración en la medida que son desarrolladas y son elementos indispensables cuando se requiere interacción entre los individuos. Estas líneas base debe ser controladas y revisadas para mantener la integridad de sus elementos. 

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 Gestión de la configuración

El área de proceso de Configuration Management (CM) corresponde al nivel 2 en la representación por etapas y está ubicada dentro de la categoría de proceso de Soporte para la representación continua. Tiene como propósito establecer y mantener la integridad de los productos de trabajo utilizando la identificación de la configuración, el control de configuración, el registro del estado de configuración y las auditorías de configuración. En general CM cubre el control de los productos de trabajo a través de las actividades de la disciplina de gestión de la configuración reflejadas en las diferentes metas específicas.


Identificación de la configuración 
SG1 Las líneas base de los productos de trabajo identificados son establecidas.

• SP1.1 Identificar los elementos de configuración, los componentes y los productos de trabajo relacionados que serán puestos bajo gestión de configuración
• SP1.2 Establecer y mantener un sistema de gestión de configuración y de gestión del cambio para controlar los productos de trabajo
• SP1.3 Crear o liberar las líneas base para uso interno y para la entrega al cliente

Control de cambios a la configuración 
SG2 Los productos de trabajo bajo gestión de configuración son seguidos y controlados.

• SP2.1 Seguir las peticiones de cambio para los elementos de configuración
• SP2.2 Controlar los cambios a los elementos de configuración

Reporte de estado y auditoría de la configuración 
SG3 La integridad de las líneas base es establecida y mantenida

• SP3.1 Establecer y mantener los registros que describen los elementos de configuración
• SP3.2 Realizar auditorías de configuración para mantener la integridad de las líneas base de configuración

Auditorías a la gestión de la configuración

Las auditorías a la gestión de la configuración permiten confirmar que los registros de gestión de configuración y elementos de configuración son completos, consistentes y precisos. Son realizadas durante el ciclo de vida para demostrar que los planes, procesos y sistemas se están utilizando y son adecuados así como identificar oportunidades de mejora. En las auditorías se revisa que:

• ¿Las políticas y estándares del proceso son adecuadas para cumplir los objetivos de la organización?
• ¿Los planes y procedimientos de gestión de configuración son adecuados para cumplir con las políticas y estándares definidos?
• ¿El personal responsable de las actividades tiene acceso a los planes y procedimientos y están actualizados?
• ¿El personal ha recibido la formación requerida para realizar sus actividades?
• ¿El personal que realiza las actividades de gestión de la configuración cumple con las políticas, estándares y procedimientos definidos?
• ¿El ambiente e infraestructura para realizar las actividades de gestión de de configuración es adecuado?
• ¿Los componentes de configuración están adecuadamente controlados, versionados e integrados en las líneas base correspondientes?
• ¿Los hallazgos identificados en auditorías previas están siendo atendidos?

Las auditorías garantizan un mecanismo independiente para comprobar el cumplimiento de procesos y estándares aplicables en particular a la gestión de la configuración, además de verificar que el producto está listo para liberarse de acuerdo con los requisitos que lo definen. Este tipo de auditoría pueden ser integradas como parte de las revisiones a procesos y productos del área de procesos Process and Product Quality Assurance (PPQA). Referencia. Westfall, Linda. Software Configuration Management audits. www.westfallteam.com

Auditorías físicas a la configuración (PCA)

Son auditorías que permiten verificar que los elementos de configuración integrados cumplen con la especificación técnica que los define. Esto implica que todos los componentes requeridos están presentes, que corresponden con la versión correcta y con la información contenida en los reportes de estado de la línea base. Es una evaluación independiente para demostrar que el código es adecuadamente descrito en la documentación que se entrega y que tanto el código como la documentación están listos para la entrega. De igual forma contribuye a evaluar el cumplimiento de acuerdos legales y requisitos establecidos para el producto. Típicamente se realiza en conjunción con la auditoría funcional (FCA) o una vez que los hallazgos de la FCA han sido resueltos. En esencia la PCA revisa la información de los reportes de estado a la configuración para asegurar que los productos y la documentación asociada son adecuadamente integradas en la línea base antes de liberar el producto. Lista de elementos a verificar Puede considerar como base para la verificación:

• ¿Los hallazgos de FCA han sido resueltos adecuadamente?
• ¿Todos los componentes de configuración identificados están integrados en la línea base?
• ¿Todos los componentes de configuración cumplen con los estándares que los definen?
• ¿El producto ha sido integrado a partir de los componentes de configuración correctos de acuerdo con la especificación que los define?
• ¿La documentación que se entrega está completa?
• ¿El medio en el que se entrega el producto cumple con los requisitos especificados? ¿Está adecuadamente identificado y etiquetado el producto?
• ¿Los entregables cubren con la lista de entregables requeridos?
• ¿Se cumplen los requisitos para la licencia del producto por terceros?
• ¿Se cubren los requisitos de exportación del producto?

Al igual que en FCA, la revisión se hace sobre muestreo de los productos y documentación considerando los elementos más críticos o problemáticos en el pasado. Referencia. Westfall, Linda. Software Configuration Management audits. www.westfallteam.com

Auditorías funcionales a la configuración (FCA)

Son auditorías que permiten verificar que las funcionalidades que han sido probadas de un componente de configuración han cubierto los requisitos especificados en la línea base de documentación funcional y que la documentación para el apoyo y operación es completa y satisfactoria. Es una evaluación independiente que permite determinar que un producto y su documentación cumplen con los requisitos de funcionalidad, desempeño y calidad. 
Típicamente se realiza antes de las pruebas finales o de la liberación del producto. Básicamente permite demostrar que, con base en los resultados de las verificaciones y validaciones, el producto esta listo para ser entregado. 


Lista de elementos a verificar 
Puede considerar como base los siguientes cuestionamientos:

• ¿El código cumple con todos los requisitos documentados?
• ¿Puede ser rastreado el requisito hasta las pruebas que demuestran que está implantado?
• ¿Las pruebas han sido completas para cubrir la funcionalidad, interfaces y atributos de calidad requeridos?
• ¿Todas las fallas identificadas han sido resueltas, o en su caso adecuadamente identificado como renuncias o desviaciones?
• ¿La documentación es consistente con los requisitos y el producto final?
• ¿Los hallazgos de las revisiones entre colegas han sido adecuadamente considerados?
• ¿Las acciones correctivas identificadas en las auditorías han sido atendidas?

Básicamente la revisión se hace sobre muestreo de los productos y documentación considerando los elementos más críticos o problemáticos en el pasado. Por lo general esta auditoría antecede a la auditoría física a la configuración (PCA) Referencia. Westfall, Linda. Software Configuration Management audits. www.westfallteam.com

Auditorías en el modelo CMMI

Una auditoría, según el glosario de CMMI, es una revisión objetiva de un producto o conjunto de productos de trabajo contra criterios establecidos. El uso del criterio le da objetividad a la actividad y es vital para el éxito de la revisión. Una auditoría proporciona el conocimiento de que lo que debiera ser controlado, según el criterio definido, lo está y puede ser ofrecido en su momento. 

En el modelo existe una práctica específica (SP 3.2) en el área de proceso de Gestión de la Configuración (Configuration Management) que establece la necesidad de ejecutar auditorías a la configuración para mantener la integridad de las líneas base de la configuración. Esta actividad confirma que las líneas base obtenidas y la documentación que las acompañada cumplen con los estándares o requisitos especificados, además de que es exacta y completa. El resultado debe ser adecuadamente documentado y controlado para garantizar el cierre o solución de las observaciones realizadas. 

Administración de la configuración

Administración de la configuración (Configuration management CM) es el conjunto de actividades relacionadas con la administración de la evolución de los productos durante todo su ciclo de vida. Para ello es necesario identificar, organizar y controlar las modificaciones al producto con el objetivo de maximizar la productividad a la vez que se minimizan los errores. Es el control que se tiene sobre cada uno de los componentes de configuración de un producto con el fin de que todos los cambios que se realicen a estos componentes, una vez que han sido aprobados, se hagan de forma controlada y que en todo momento se conozca cuál es la versión vigente de cada uno. Facilita la identificación e integración de los componentes de configuración que conforman los entregables del proyecto. Es el proceso de identificar la configuración del producto para controlar sistemáticamente los cambios a la misma y mantener su integridad a lo largo de todo el ciclo de vida del proyecto. Algunos problemas comunes que conllevan a la adopción de CM son:

• No se encuentra la última versión del código fuente
• Errores corregidos en versiones previas aparecen nuevamente
• No se conoce qué módulos comprende el sistema entregado al cliente
• La integración del sistema toma demasiado tiempo
• Los programadores están trabajando en una versión incorrecta del código
• Versiones incorrectas del código son probadas
• No existe seguimiento de los requerimientos, documentos y códigos

Las actividades que se requieren para implementar un proceso de CM incluyen: Identificación de la configuración: Identificar de forma unívoca la estructura del software y los elementos que lo forman y ponerlo a disposición del personal que lo requiera. El objetivo es tener la capacidad de identificar los componentes del software a lo largo de su ciclo de vida y facilitar su seguimiento. Actividades

1. Seleccionar los elementos que estarán bajo control de configuración
2. Establecer la estructura jerárquica del producto
3. Crear e identificar el esquema que refleja la estructura del producto
4. Identificar unívocamente cada uno de los componentes del producto
5. Definir las relaciones e interfaces entre los productos

Nota: Es importante almacenar y registrar toda la información del ambiente y las herramientas de apoyo utilizadas durante el ciclo de vida del software para asegurar que el mismo puede ser reproducido, en cualquier momento. Control del cambio a la configuración: Controlar los cambios y la liberación de los productos durante el ciclo de vida para establecer un mecanismo que asegure la creación de un producto de calidad. Actividades

1. Definir el proceso de cambio
2. Establecer las políticas y procedimientos de control de cambios
3. Mantenimiento de las líneas base
4. Incorporar los cambios
5. Desarrollar la forma de reportes de cambio
6. Controlar la liberación del producto

Reporte del estado de la configuración: Registrar y reportar los cambios a los componentes de configuración. Con ello se puede mantener un registro del estado de todos los elementos en una línea base, para posibilitar el seguimiento de todos los cambios a las líneas base durante el ciclo de vida. Actividades

1. Determinar el tipo de reporte requerido
2. Dar seguimiento al estado de los componentes de configuración
3. Dar seguimiento al estado de los cambios al sistema
4. Generar reportes de estado
5. Registrar y reportar las actividades de CM

Auditoría a la configuración: Verificar que el producto integrado satisface los requerimientos, estándares o acuerdos contractuales y que los componentes que se integran corresponden con las versiones vigentes. Verificar que todos los componentes han sido producidos, descritos e identificados correctamente y que todas las solicitudes de cambio han sido procesadas. Actividades

1. Definir el esquema y procedimientos de auditoría
2. Desarrollar auditorías en las líneas base establecidas
3. Generar los reportes de auditoría

M. en C. Carlos J. Pérez Escobar SEI Authorized CMMI Instructor