Saltar la navegación

2.5.- Gestión del cambio.

Caso práctico

Mujer de pelo corto y chaqueta negra mirando de frente.

Para gestionar el control de versiones de forma centralizada, Ada va a supervisar los cambios de versión que el equipo de Juan y de María están efectuando de forma independiente. Ada va a realizar una gestión del cambio centralizada y organizada.

Esquema donde se aprecian las diferentes partes que establece el control de cambios. Nos encontramos con los cuadrados verdes que indican diferentes estados en los que se encuentra el control de cambios. Partimos de “Esperando desarrollo”, Si se inicia el desarrollo, pasamos a “En Desarrollo” si hay anulación, salimos del control de cambios. En el estado “En desarrollo”, podemos pasar a “En revisión” o anular el desarrollo y pasar al estado anterior, no habiendo cambio. Si se termina el desarrollo, pasamos a “En revisión”, si se acepta la revisión, pasamos a “Esperando integración” o si se rechaza,vovemosa “En desarrollo”. Una vez revisado un cambio, se pasa a “Esperando integración”, que si acepta el cambio, lo pasa a “En integración” y de ahí se a “Completado”  el cambio. Si en algún paso, ser rechaza los cambios, volvemos “En Desarrollo”.

Las herramientas de control de versiones no garantizan un desarrollo razonable, si cualquier componente del equipo de desarrollo de una aplicación puede realizar cambios e integrarlos en el repositorio sin ningún tipo de control. Para garantizar que siempre disponemos de una línea base para continuar el desarrollo, es necesario aplicar controles al desarrollo e integración de los cambios. El control de cambios es un mecanismo que sirve para la evaluación y aprobación de los cambios hechos a los elementos de configuración del software.

Pueden establecerse distintos tipos de control:

  1. Control individual, antes de aprobarse un nuevo elemento.

    Cuando un elemento de la configuración está bajo control individual, el programador responsable cambia la documentación cuando se requiere. El cambio se puede registrar de manera informal, pero no genera ningún documento formal.

  2. Control de gestión u organizado, conduce a la aprobación de un nuevo elemento.

    Implica un procedimiento de revisión y aprobación para cada cambio propuesto en la configuración. Como en el control individual, el control a nivel de proyecto ocurre durante el proceso de desarrollo pero es usado después de que haya sido aprobado un elemento de la configuración software. El cambio es registrado formalmente y es visible para la gestión.

  3. Control formal, se realiza durante el mantenimiento.

    Ocurre durante la fase de mantenimiento del ciclo de vida software. El impacto de cada tarea de mantenimiento se evalúa por un Comité de Control de Cambios, el cuál aprueba la modificaciones de la configuración software.

Autoevaluación

Pregunta

¿Cuál de las siguientes no es una tarea básica de la Gestión de Configuraciones del Software?

Respuestas

Control de cambios.

Generación de informes.

Auditorías de configuraciones.

Gestión del repositorio.

Retroalimentación