Desarrollo de la capacidad, el reto para las empresas

Una de las formas más exitosas para mejorar los resultados y superar a la competencia en las organizaciones es el desarrollo de sus capacidades.

Los resultados del negocio están relacionados con el desarrollo de su potencial a nivel de personas, proyectos y procesos. El equilibrio entre ellos permite mejorar la productividad, incrementar la calidad y reducir los costos en tanto se mantiene la satisfacción del cliente y la ventaja competitiva para la empresa.

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?"

Métricas, lo que no se debe hacer

En relación con la definición y análisis de las métricas se puede caer en errores que pueden ser costosos para la organización y conducir a malas decisiones con implicaciones desastrosas para el negocio. 

Stephen Mann en un artículo titulado "Where IT Metrics Go Wrong: 13 Issues To Avoid" presenta algunos errores comunes que se presentan en el diseño e implementación de las métricas en una Organización. 

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.

Herramientas de apoyo a requisitos

El modelo CMMI no establece como condición el uso de herramientas específicas para la implementación de las prácticas en las áreas de proceso. Aunque la herramienta no hace el proceso, es útil apoyarse en ellas para facilitar las tareas que se requieren. En particular las áreas de proceso de REQM y RD se benefician mucho si el proceso se refuerza con alguna herramienta.
IRQA es una herramienta desarrollada por Visure que permite identificar, analizar y gestionar los requisitos. Una solución completa e integral para el proceso de definición y gestión de requisitos.

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.