Configuraciones 1 - Gestión de configuraciones

La gestión de configuraciones (CM) es el desarrollo y aplicación de estándares y procedimientos para gestionar un sistema software evolutivo.

Los requerimientos del sistema siempre cambian durante su desarrollo y su uso, y se tienen que incorporar estos requerimientos en nuevas versiones del sistema. Es necesario gestionar estos sistemas que evolucionan, porque es fácil perder la pista de los cambios que se han incorporado dentro de cada versión. 

Las versiones incorporan propuestas de cambios, correcciones de fallos y, adaptaciones para hardware y sistemas operativos diferentes. Pueden existir varias versiones en desarrollo y en uso al mismo tiempo. Si no se tienen unos procedimientos de gestión de configuraciones adecuados, se puede hacer un esfuerzo inútil modificando la versión errónea de un sistema, entregar una versión incorrecta a los clientes o perder la pista de dónde ha sido guardado el código fuente.

Los procedimientos de gestión de configuraciones definen cómo registrar y procesar los cambios propuestos al sistema, cómo relacionar éstos con los componentes del sistema y los métodos utilizados para identificar las diversas versiones del sistema. Las herramientas de gestión de configuraciones se utilizan para almacenar las versiones de los componentes del sistema, construir sistemas a partir de estos componentes y llevar el registro de entregas de las versiones del sistema a los clientes.

Algunas veces, la gestión de configuraciones es parte de un proceso general de gestión de la calidad del software, donde el mismo gestor comparte las responsabilidades de la gestión de la calidad y de la configuración. Los desarrolladores del software entregan éste al equipo de garantía de calidad, quienes son responsables de la comprobación de que el sistema es de calidad aceptable. Aquí comienza a ser un sistema controlado, lo que significa que los cambios en el sistema tienen que ser acordados y registrados antes de ser implementados, Algunas veces, los sistemas controlados se denominan «líneas base» puesto que son el punto de inicio para la evolución controlada.

Hay muchas razones por las que los sistemas existen en diversas configuraciones. Éstas se producen para diferentes computadoras, para diferentes sistemas operativos, para incorporar funciones específicas del cliente, etcétera. Los gestores de la configuración son responsables de llevar los registros de las diferencias entre las versiones del software, para asegurar que las nuevas versiones se deriven de forma controlada y para entregar las nuevas versiones a los clientes correctos en el momento justo.

Familias de sistemas

La definición y uso de gestión de configuraciones es esencial para la certificación de calidad ISO 9000 y para los estándares CMM y CMMI (Paulker af., 1995; Ahern et al, 2001; Peach, 1996). Un ejemplo de tal estándar es el IEEE 828-1998, que define un estándar para los planes de la gestión de configuraciones. Dentro de una organización, estos estándares se publican en un manual de gestión de configuraciones o como parte del manual de calidad. Los estándares externos se utilizan como base para estándares organizacionales detallados y se ajustan a un entorno específico.

En un proceso tradicional de desarrollo de software basado en el modelo en «cascada», el software se entrega al equipo de gestión de configuraciones después de que el desarrollo haya sido completado y se hayan probado los componentes de software. Luego este equipo tiene la responsabilidad de construir el sistema completo y gestionar las pruebas del sistema. Los fallos encontrados durante las pruebas del sistema se devuelven al equipo de desarrollo para su reparación. A continuación reparan el fallo y entregan una nueva versión del componente reparado al equipo de la garantía de calidad. Si la calidad es aceptable, éste pasa a ser la nueva línea base para el desarrollo del sistema. 

Este modelo, donde el equipo de garantía de calidad controla la integración del sistema y el proceso de pruebas, ha influenciado el desarrollo de estándares para la gestión de configuraciones. Muchos estándares de garantía de calidad suponen que se utiliza el modelo en cascada para el proceso del software en el desarrollo de sistemas (Bersoff y Davis, 1991). Esto significa que los estándares tienen que adaptarse a las aproximaciones modernas de desarrollo de software basadas en especificación y desarrollo incremental. Hass (Hass, 2003) discute alguna de estas adaptaciones para los procesos de desarrollo software tales como el desarrollo ágil.
Para ajustarse a este desarrollo incremental, algunas organizaciones han desarrollado un nuevo enfoque para gestionar las configuraciones que permite el desarrollo concurrente y las pruebas del sistema, Este enfoque se basa en la forma regular (a menudo diaria) de construcción del sistema completo a partir de sus componentes:

1. La organización que lleva a cabo el desarrollo fija una hora de entrega (por ejemplo, a las 14,00 horas) de los componentes del sistema. Si los desarrolladores tienen nuevas versiones de los componentes que están escribiendo, entonces deben entregarlos todos a esa hora. Los componentes podrían estar incompletos, pero deben ser capaces de proveer alguna funcionalidad básica que se pueda probar. 
2. Una nueva versión del sistema se construye a partir de estos componentes compilándolos y vinculándolos para formar un sistema completo. 
3. Entonces el sistema se entrega al equipo de pruebas, que lleva a cabo un conjunto predefinido de pruebas sobre el sistema. Al mismo tiempo, los desarrolladores siguen trabajando en sus componentes, agregando funcionalidades y reparando los fallos descubiertos en las pruebas previas. 
4. Los fallos encontrados durante las pruebas del sistema se documentan y se devuelven a los desarrolladores del sistema. Éstos reparan dichos fallos en una versión ulterior del componente.

La principal ventaja de utilizar construcciones diarias del software es que se incrementan las oportunidades de encontrar problemas que surgen a partir de las interacciones al inicio del proceso. Más aún, las construcciones diarias provocan las pruebas de las unidades de los componentes. Psicológicamente, los desarrolladores se ven presionados «para no derribar el edificio», es decir, para no entregar versiones de los componentes que provoquen un fallo en todo el sistema. Por lo tanto, son reticentes a entregar nuevas versiones de los componentes que no se hayan probado adecuadamente. Si se encuentran fallos en el software y éstas se abordan durante las pruebas de las unidades, se invierte menos tiempo en las pruebas del sistema.
La utilización exitosa de las construcciones diarias requiere procesos de gestión del cambio muy rigurosos para llevar un registro de los problemas encontrados y resueltos. También conduce a la gestión de un número muy grande de versiones del sistema y de los componentes. Por lo tanto, una buena gestión de configuraciones es esencial para que este enfoque tenga éxito.
La gestión de configuraciones en el desarrollo ágil y desarrollo rápido no pueden basarse en rígidos procedimientos y papeleo burocrático. Aunque éstos pueden ser necesarios para proyectos grandes o complejos, pueden ralentizar el proceso de desarrollo. Mantener registros cuidadosos es esencial para sistemas grandes y complejos desarrollados desde diferentes ubicaciones, pero innecesario en proyectos pequeños. En estos proyectos, todos los miembros del equipo trabajan juntos en la misma habitación, y la sobrecarga asociada a mantener los registros ralentiza el proceso de desarrollo. Sin embargo, esto no significa que, cuando se requiera un desarrollo rápido, la gestión de configuraciones deba ser totalmente abandonada. Los procesos ágiles utilizan herramientas simples de gestión de configuraciones, como un gestor de versiones y herramientas para la construcción del sistema, que incorporarán algo de control. Todos los miembros del equipo tienen que aprender a utilizar estas herramientas y asumir las disciplinas que ellas imponen.