Tarea: Establecer el proceso de control de cambios
En esta tarea se describe cómo crear un proceso de control de cambios.
Disciplinas: Configuración y Gestión de cambios
Objetivo

El objetivo de disponer de procesos de control de cambios estandarizados y documentados es el de garantizar que los cambios se han realizado en un proyecto de forma coherente y que se ha informado a los interesados del estado del producto, de los cambios efectuados en el mismo y del impacto de esos cambios en el coste y la planificación.

Relaciones
Pasos
Establecer el proceso de solicitud de cambio

En el siguiente diagrama de actividad se muestra un procedimiento típico para gestionar solicitudes de cambio. (Pulse en cualquier lugar del diagrama para obtener una descripción completa del Concepto: Gestión de solicitudes de cambio)

Tareas de ejemplo para gestionar CR parte superior de la página

Conceptos: Gestión de solicitudes de cambio Flujo de proceso de CR entre el emisor, el CCB, un trabajador asignado y un verificador.

Completar el formulario de solicitud de cambio parte superior de la página

El formulario de solicitud de cambio es un artefacto enviado formalmente que se utiliza para realizar el seguimiento de todas las solicitudes (incluidas las nuevas características, las solicitudes de mejora, los defectos, los requisitos modificados, etc.). Debe incluir la información de estado relacionada de todo el ciclo de vida del proyecto. El historial de cambios se mantendrá junto con la CR, incluidos todos los cambios de estado, y las fechas y los motivos de dicho cambio. Esta información estará disponible para las revisiones repetidas y para el cierre final. En Producto de trabajo: Solicitudes de cambio se incluye un formulario de solicitud de cambio de ejemplo.

Los estados típicos por los que puede pasar una solicitud de cambio se muestran en el siguiente diagrama de estado. (Pulse en cualquier lugar del diagrama para obtener una descripción completa del Concepto: Gestión de solicitudes de cambio)

Transiciones y estados de ejemplo para una solicitud de cambio parte superior de la página

Conceptos: Gestión de solicitudes de cambio Flujo de proceso para una nueva CR. Los estados posibles son Enviada, Pospuesta, Abierta, Rechazada, Asignada, Resuelta y Verificada.

Analizar la solicitud de cambio parte superior de la página

Una vez que se ha enviado una solicitud de cambio, ésta se analiza para garantizar que es válida y que el personal técnico y de gestión va a revisar la solicitud de cambio para valorar su validez. Las solicitudes de cambio deben revisarse en diversos niveles del equipo de desarrollo. Un jefe de equipo a menudo revisará y aprobará las solicitudes de cambio enviadas por cualquier miembro de su equipo. Sin embargo, si el ámbito de un cambio está fuera de la responsabilidad del equipo, éste se escalará para el siguiente nivel de revisión. Si el impacto del cambio abarca varios equipos de desarrollo, el comité de control de cambios revisará el cambio. En Rational Unified Process, el rol del gestor de control de cambios se utiliza para representar el rol del comité de control de cambios (CCB).

A veces, una avería detectada en el sistema puede deberse más a su utilización que al hecho de estar enlazada con la implementación del sistema. También podría ocurrir que el 'problema' ya se haya notificado y se está solucionando.

El resultado del paso de análisis puede ser aceptar la solicitud de cambio o rechazarla porque no es válida, está duplicada o está 'fuera del ámbito' de acuerdo con la visión o mandato del proyecto actual.

Valorar el coste de la solicitud de cambio parte superior de la página

Para los cambios válidos, el paso siguiente es valorar el coste del cambio en función del impacto que tiene sobre el sistema global y si se puede implementar fácilmente o no.

La información del paso de coste se proporciona al CCB para su valoración. El CCB revisa la solicitud de cambio y su impacto tanto desde el punto de vista estratégico y de organización como del punto de vista técnico. El CCB tiene que decidir si la solicitud de cambio puede justificarse económicamente.

Aplicar la solicitud de cambio parte superior de la página

Una vez que se ha aprobado una solicitud de cambio, el cambio puede aplicarse al software. A continuación, el software revisado se somete a comprobaciones de garantía de calidad para garantizar que el cambio se ha realizado de acuerdo con la prácticas adoptadas del proyecto y que no afecta negativamente a otros componentes del software existente.

Una vez efectuados los cambios, la nueva versión del software se verifica en una compilación de prueba del producto y luego se incorpora y se verifica en una versión de 'release' del software global.

Mantener el historial de cambios parte superior de la página

A medida que se realizan los cambios en el software, es importante que se mantenga un registro de todos los cambios.

Una forma eficaz de mantener un historial de cambios es al principio de cada componente de software y dentro de las solicitudes de cambio.

Un ejemplo del tipo de datos de cambio que se deben mantener en una cabecera de componente podría ser el siguiente:

Historial de modificaciones

Versión Modificador Fecha Motivo del cambio

1.1 Bruce Bogtrotter 98.05.01 Intervalos de prueba CR#232

1.2 Maria Mussolini 98.06.02 Requisitos CR#454

Establecer el comité de control de cambios
Objetivo Establecer un 'comité de control de cambios (CCB)' que aprobará todos los cambios en los elementos de configuración de línea base. El objetivo del equipo es garantizar que todos los cambios propuestos se someten a revisión y a análisis técnicos apropiados, y que se documentan para fines de seguimiento y auditoría.  
Subpasos

El CCB se reúne periódicamente según sea necesario.

Las tareas básicas del CCB son declarar líneas base del producto y revisar los cambios en la línea base, y aprobar, no aprobar o diferir su implementación.

Seleccionar los miembros parte superior de la página

El objetivo de este paso es definir un CCB que esté formado por las 'personas adecuadas' con autoridad real entre sus iguales y con suficiente experiencia para prevenir propuestas de cambio desaconsejables o costosas. El CCB debe estar formado por representantes de todas las organizaciones o interesados afectados, como por ejemplo:

  • Usuarios
  • Desarrolladores
  • Grupo de pruebas
  • Gestión de proyectos

Nombrar el presidente del CCB parte superior de la página

El presidente del CCB debe pertenecer a la oficina de gestión de proyectos. El presidente debe ser capaz de resolver inequívocamente los conflictos dentro del equipo y de aplicar las decisiones del equipo sobre el proyecto.

Las decisiones del CCB deben alcanzarse por consenso siempre que sea posible. La dinámica de grupo refleja la naturaleza cooperativa del proyecto de desarrollo. El rol del presidente es fomentar esta visión cooperativa y llevar a cabo acciones unilaterales si es necesario.

Celebrar reuniones para valorar las propuestas de cambio parte superior de la página

El CCB debe reunirse periódicamente, y según sea necesario, para garantizar que las propuestas de cambio se revisan y se llevan a cabo puntualmente. El equipo de desarrollo debe ver este grupo como un organismo fiable para la resolución de los problemas que, de lo contrario, podrían poner el progreso del proyecto en un punto muerto.

Definir protocolos de notificación de revisión de cambios
Objetivo El objetivo de los protocolos de notificación de revisión de cambios es garantizar que se notifica a los miembros apropiados del personal el envío de las solicitudes de cambio.
Decida quién debe revisar los diferentes productos de trabajo. 
Guías de herramientas:  Definir notificaciones de cambio y revisión utilizando Rational ClearQuest

La entrada de este paso es la lista de productos de trabajo que deben desarrollarse durante el transcurso del proyecto.

Los miembros del personal deben revisar los productos de trabajo relacionados con el producto y decidir si cumplen los estándares de calidad definidos del proyecto para que puedan pasar a la siguiente fase de desarrollo. Si un producto no pasa una revisión, estará sujeto a rediseño, cambios y a una nueva revisión.

Para que una revisión sea 'efectiva' el producto debe ser valorado por las personas adecuadas que comprenden el alcance y el impacto de un cambio o mejora propuesto. Además, las revisiones deben ser 'rentables' de modo que el tiempo de los principales implementadores e integradores no se malgaste en detectar defectos de "bajo impacto".

Los miembros del personal que deben participar en una revisión son representantes de los roles de gestión, destinatario y productor del "producto". De esta manera, se garantiza que todas partes que tienen un interés creado en la calidad del producto puedan decidir si el producto puede avanzar al siguiente nivel de desarrollo.

En el entorno de equipo, el proyecto global se descompone en actividades. Las actividades se asignan a las personas responsables de la implementación e integración. Por ejemplo, el sistema global se divide en subsistemas y luego en paquetes individuales. Los miembros del equipo responsables de implementar un paquete deben asegurarse de que los cambios que han realizado son revisados por iguales del subsistema y por cualquier otra persona de otros subsistemas que pueda verse afectada por los cambios.

El principio de notificación de cambio y revisión es comunicar los cambios propuestos a iguales y jefes de equipo, así como a los destinatarios de los mismos, y brindarles la oportunidad de revisar y comentar las propuestas.

Encontrará más información sobre este tema en el apartado Concepto: Gestión de solicitudes de cambio.


 

Más información