Control de cambios

Control de cambios

Control de cambios en la configuración. Es la actividad de Gestión de Configuración más importante y su objetivo es proporcionar un mecanismo riguroso para controlar los cambios, partiendo de la base de que los cambios se van a producir. Normalmente combina procedimientos humanos y el uso de herramientas automáticas.

Tipos de cambio

Se pueden considerar fundamentalmente dos tipos de cambios:

• Corrección de un defecto: Los clientes tienden a clasificar todos los cambios en esta categoría.
• Mejora del sistema: Los programadores, sin embargo, los suelen clasificar aquí.

Para solucionar el problema de determinar realmente de qué tipo es un cambio es importante la trazabilidad de los requisitos. Por lo general se establecen varios niveles de control de cambios:

• Control de cambios informal: Antes de que el Elemento de Configuración del Software pase a formar parte de una línea base, aquel que haya desarrollado el Elemento de Configuración del Software podrá realizar cualquier cambio justificado sobre él.
• Control de cambios al nivel del proyecto o semi-formal: Una vez que el Elemento de Configuración del Software pasa la revisión técnica formal y se convierte en una línea base, para que el encargado del desarrollo pueda realizar un cambio debe recibir la aprobación de:
• El director del proyecto, si es un cambio local
• El Comité de Control de Cambios, si el cambio tiene algún impacto sobre otros Elementos de Configuración del Software
• Control de cambios formal: Se suele adoptar una vez que se empieza a comercializar el producto, cuando se transfieren los ECS a la Biblioteca Maestra. Todo cambio deberá ser aprobado por el Comité de Control de Cambios.

Es necesario establecer de forma precisa, al comienzo de cada proyecto, cuál será el proceso de gestión de cambios que se va a utilizar. Para ello, será necesario definir:

• Políticas a nivel organizativo que promuevan las actividades de control de cambios.
• Los estándares que se van a adoptar y a los que será necesario ajustarse.
• Los procedimientos que se van a utilizar para poner en práctica las políticas de Gestión de Configuración.

Las políticas de Gestión de Configuración deben reflejar la filosofía y las metas de la organización en cuanto a las actividades de Gestión de Configuración. Mientras que el objetivo de las políticas es definir el ‘por qué’ de la Gestión de Configuración, deben establecer un marco para definir el ‘qué’, el ‘cuándo’, el ‘cómo’ y el ‘quién’:

• Las responsabilidades.
• El contenido de las líneas base.
• Los tipos de cambios que se van a controlar.
• Las funciones del Comité de Control de Cambios.
• El flujo de documentación entre el solicitante de un cambio y el Comité de Control de Cambios.
• Los criterios para la valoración de las solicitudes de cambio, tanto de tipo técnico como de gestión.

Proceso de control de cambios

No hay ningún estándar para el control informal o interno de los cambios, aunque sí hay algunas recomendaciones (IEEE STD 1042 Guide to Software Configuration Management). En cuanto al control de cambios formal, se puede estructurar de muchas formas. Vamos a ver cuáles son las etapas típicas de un proceso formal, es decir, el proceso que habría que seguir para hacer un cambio sobre una línea base:

• Iniciación del Cambio: se presenta una solicitud de cambio, que puede venir provocada por un problema que se ha detectado o por un cambio en los requisitos.
• Clasificación y registro de la solicitud de cambio.
• Aprobación o rechazo inicial de la solicitud de cambio. De ello suele ser responsable el Comité de Control de Cambios.
• Evaluación de la solicitud de cambio, si ha sido aprobada, para calcular el esfuerzo técnico, los posibles efectos secundarios, el impacto global sobre otras funciones del sistema y el coste estimado del cambio. Como resultado se obtiene un Informe de Cambio.
• Se presenta el Informe de Cambio al Comité de Control de Cambios. Si se considera que el cambio es beneficioso se genera una Orden de Cambio (también llamada Orden de Cambio de Ingeniería), que describe el cambio a realizar, las restricciones que se deben respetar y los criterios de revisión y de auditoría. Esta Orden de Cambio es asignada a alguno de los ingenieros de software para que se encargue de llevarlo a cabo. En este momento, el objeto a cambiar se da de baja en la Biblioteca de Soporte al Proyecto.
• Se realiza el cambio, entrando en un proceso de seguimiento y control.
• Una vez finalizado el cambio, se certifica, mediante una revisión, que se ha efectuado correctamente el cambio y con ello se ha corregido el problema detectado o bien se han satisfecho los requisitos modificados. El objeto se devuelve a la Biblioteca de Soporte al Proyecto.
• Se notifica el resultado al originador del cambio.

Al definir este proceso, será también necesario:

• Definir los mecanismos para solicitar cambios sobre los Elementos de Configuración.
• Definir los mecanismos para analizar y evaluar el impacto de las solicitudes de cambio.
• Definir los mecanismos para aprobar o rechazar las solicitudes de cambio.
• Definir los mecanismos para controlar la realización de los cambios aprobados.

Los procesos de alta y baja de la Biblioteca del Proyecto implementan dos elementos importantes del Control de Cambios: el control de acceso y el control de sincronización:

• El Control de Acceso se refiere a los derechos que tienen los diferentes miembros del equipo de desarrollo para acceder y modificar ECS concretos. Así, por ejemplo, hay que controlar el acceso del ingeniero de software que da de baja el ECS de la Biblioteca de Proyecto para realizar un cambio aprobado por una Orden de Cambio.
• El Control de Sincronización ayuda a asegurar que los cambios en paralelo, realizados por equipos o personas diferentes, no se sobrescriben. Así, cuando un ECS se da de baja de la Biblioteca de Soporte, el Control de Sincronización bloquea el objeto para que no se puedan hacer más actualizaciones sobre él hasta que se haya reemplazado con una nueva versión. El almacén de una herramienta de control de versiones se puede considerar como la Biblioteca de Soporte o de Proyecto. Estas herramientas ofrecen también de forma automática el control de acceso y control de sincronización.

Mecanismo para solicitar cambios

El primer mecanismo que es necesario definir es el mecanismo para solicitar cambios sobre los Elementos de Configuración. El primer paso es definir el formulario que se debe utilizar para solicitar cambios. Este formulario de Solicitud de Cambio debe contener información suficiente para determinar:

• por qué se necesita el cambio (el elemento no funciona tal y como debe hacerlo, le falta alguna característica, etc.)
• qué hay que cambiar
• quién lo solicita
• descripción del problema lo suficientemente detallada como para que se pueda recomendar una solución.
• otros ECS que se pueden ver afectados por el cambio.
• otros cambios con los que está relacionado.
• aprobación del cambio.
• cómo se solucionó el problema, etc.

En cualquier caso, debe ser simple, y aceptado por las personas que lo tendrán que manejar. El formulario más común es el de Solicitud de Cambios. Sin embargo, casi siempre se utilizan formularios diferentes para solicitar una mejora y para informar de un problema o deficiencia detectado durante una auditoría, una prueba o el uso del sistema (y que posiblemente requerirá un cambio). A los formularios que se usan para informar de problemas se les suele llamar Informes de Incidencias o Informes de Problemas. Recogen información adicional sobre el incidente que ha desvelado la existencia de un problema:

• Fecha y hora en que ocurrió,
• descripción del incidente,
• efectos que ha producido,
• de qué forma se puede duplicar el incidente, si es que se ha podido duplicar,
• volcado de datos,
• referencia al tipo de prueba que se estaba efectuando.

Este Informe de Incidencia es analizado por los desarrolladores, y estos pueden recomendar alguna de las siguientes acciones:

• No requiere acción: Cuando lo que se describe en el informe de incidencia no es realmente una deficiencia. Esta situación suele ser debida a malentendidos acerca de la forma de funcionamiento del sistema. También se puede dar esta situación cuando ya se ha informado previamente de una incidencia similar, y se están tomando las acciones correctivas necesarias.
• Solicitud de Cambio: La implementación se corresponde con el diseño del sistema, pero una mejora en el diseño del sistema solucionaría el problema. Se genera entonces una Solicitud de Cambio, que se tratará por los cauces normales.
• Notificación de Cambio: Cuando la deficiencia que se describe en el informe de incidencia se debe a una mala implementación que debe ser corregida. Se informa entonces al CCC y se pasa a corregir la deficiencia.

Aparece, como vemos, un nuevo formulario, la Notificación de Cambio. Una Notificación de Cambio puede dar respuesta a varios Informes de Incidencias, cuando todos ellos corresponden al mismo problema. Para solicitar cambios en la documentación se pueden utilizar los formularios anteriores o un nuevo formulario al que se suele llamar Formulario de Seguimiento de la Documentación. La resolución de un Informe de Incidencia o de una solicitud de cambio.

Mecanismo para aprobar o rechazar las solicitudes de cambio

Algunos criterios que se pueden tener en cuenta para tomar la decisión de aprobar o rechazar las solicitudes de cambio son los siguientes:

• Valor del cambio para el proyecto/organización
• Retorno de la inversión
• Tamaño
• complejidad
• impacto sobre el rendimiento del producto (uso de memoria y CPU)
• recursos disponibles para efectuar el cambio (humanos y materiales)
• relación con otros cambios ya aprobados y en progreso
• tiempo estimado para completar el cambio
• relación con las políticas de la empresa (satisfacción del cliente, competitividad, etc.)
• existencia de alternativas, etc.

Seguimiento de los cambios. Gestión de Problemas

Una vez aprobado un cambio debido a un problema se debe realizar un seguimiento del mismo. A este proceso se le llama Gestión de Problemas. La Gestión de Problemas se considera una actividad complementaria a la de Control de Cambios, que consiste en gestionar la evolución de los problemas detectados sobre el software desarrollado, tanto aquellos que se detectan en la fase de pruebas como los informes de problemas que llegan del usuario. Conlleva tareas como:

• Admisión y registro de notificaciones de problemas (vía llamadas telefónicas, correo electrónico, herramienta específica)
• Asignación del problema a una persona responsable.
• Asociación de información al problema y mantenimiento de la misma en una Base de Datos de Problemas.
• Monitorización del estado del problema.
• Registro de actividades efectuadas para resolver un problema.
• Generación de informes acerca de los problemas.
• Resolución de interrogaciones sobre la Base de Datos de Problemas.
• Análisis estadísticos acerca de los problemas, como por ejemplo el estudio de correlaciones entre problemas y componentes.

Algunos de los datos que puede resultar interesante almacenar acerca de los problemas son:

• descripción,
• severidad,
• urgencia o prioridad
• causa del problema (omisiones en el análisis, error en la documentación de entrada, falta de experiencia,...)
• solución al problema
• módulos afectados,
• persona que lo notificó,
• persona responsable,
• fechas de notificación, resolución, etc.
• fase/etapa en la que se originó el problema
• fase/etapa en la que se detectó el problema

Fuentes

• S.J. Ayer, F.S. Patrinostro, Software Configuration Management: Identification, Accounting, Control, and Management, McGraw-Hill, 1992

• W. Babich, Software Configuration Management, Addison-Wesley, 1986

• H.R. Berlack, Software Configuration Management, John Wiley & Sons, 1992

• R. Pressman, Ingeniería del Software, 3ª edición, McGraw-Hill, 1993

• European Space Agency, ESA Guide to Software Configuration Management, ESA Software Engineering Standards Issue 2, Febrero 1991