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. ;-)

No hay comentarios:

Publicar un comentario

CMMI v2, cinco puntos para entender la nueva versión del modelo

El mes de marzo del 2018 fue el lanzamiento de la versión 2.0 del modelo CMMI (Capability Maturity Model for Integration) por el CMMI Ins...