archivo

Archivos diarios: septiembre 16, 2011

Hay quiénes consideran que la gestión de la configuración es el área de proceso más compleja de conseguir en el nivel 2 de CMMI. Desde mi punto de vista no lo es (o al menos no está por encima de la complejidad de otras áreas de proceso), si bien, requiere de la existencia de un procedimiento, de las herramientas adecuadas y de disciplina, sobre todo, disciplina.

La existencia de este área de proceso es lógica, sobre todo si tenemos en cuenta que en este mismo nivel existe una gestión de requisitos en la que existe como objetivo además de su inventario y comprensión, una cierta trazabilidad de los mismos (digo cierta porque es necesario ajustarlo a las posibilidades del proyecto).

La gestión de la configuración consiste en definir y llevar a la práctica para cada uno de los artefactos de un proyecto de desarrollo de software una política que permita controlar sus versiones. Para un proyecto tiene importancia, la cual crece directamente proporcional con el tamaño del proyecto, pero todavía cobra más interés cuando nos encontramos dentro del ámbito de una organización que desarrolla diferentes productos software o para la que terceros realizan esta tarea.

Sin gestión de la configuración perderemos gran parte de control sobre el producto software que se desarrolla lo que te incrementa el riesgo de cautividad respecto al proveedor (o al equipo de desarrollo) que son los que disponen del conocimiento (y hasta cierto punto) del estado de los distintos artefactos generados en el proyecto, tanto software como documentales.

Por tanto, en este área de proceso es necesario identificar los elementos sobre los que se va a aplicar gestión de la configuración. Lo normal es que se aplique sobre cualquier entregable del proyecto, lo cual me hace insistir una vez más en la necesidad de seleccionar de manera adecuada los mismos antes de comenzar (ni más, ni menos, lo justo para las necesidades del proyecto y los recursos disponibles para su ejecución).

Una vez identificados hay que definir la política de versionado y seleccionar las herramientas que se van a utilizar como base para la gestión de la configuración (así como la organización que van a tener los artefactos en las mismas). Dentro de esa política se encuentra la definición de líneas base o lo que es lo mismo definir los momentos en que una versión de un artefacto se consolida (existirá previamente una recepción formal del mismo) y que tras su validación y aprobación, supone un punto de referencia para el desarrollo de una nueva versión del producto, la cual requerirá un nuevo capítulo de validación y aprobación formal.

Es cierto que hay momentos en lo que todo sale, hasta aquello que parecía que iba a ser imposible tenerlo en plazo se ha conseguido y además con un nivel de calidad bastante aceptable. También lo es que se trata de rachas que a veces duran más y otras menos.

Aplicando una metodología adecuada, con nuestro conocimiento y experiencia podemos hacer que el viento sople a nuestro favor, sin embargo, no todos los proyectos, ni todos los clientes son iguales y tampoco probablemente lo será el equipo de proyecto con el que tengas que trabajar, esto hace que se modifiquen ciertas variables que compliquen la consecución de una buena ejecución del proyecto.

Por este motivo es conveniente contrarrestar la euforia con prudencia porque determinadas decisiones que se toman en este estado pueden ser muy perjudiciales a futuro. Con euforia todo se ve más sencillo y puede hacer por ejemplo que negocies proyectos con una condiciones muy ventajosas para la otra parte, pero no para ti o para tu organización (algo que después sufrirán otros o tu mismo) o que dejes pasar determinadas oportunidades porque pienses que vendrá otra mejor.