Implementación y Control de la Gestión de Configuración de Software (SCM)

Plan de Gestión de la Configuración de Software (SCM)

1. Introducción y Fundamentos

1.1. Objetivos

El objetivo de este documento es definir los miembros y las actividades de la gestión de configuración, así como los pasos que se deben seguir para la evaluación y aceptación de los cambios. Se establecen los responsables de la Autoridad de Control de Cambios (ACC), sus funciones, el método de nombrado y la estructura de los informes del estado de configuración.

1.2. Alcance

El alcance de este documento es establecer la función de la gestión de configuración para el proyecto.

1.3. Estructura del Documento

El contenido de este documento se divide en tres apartados principales:

• Gestión de Configuración Software: Describe los responsables de la gestión de configuración, sus tareas, las herramientas, el entorno y la infraestructura utilizados.
• Programa de Configuración Software: Compuesto por los métodos de identificación de los elementos software, las líneas base del proyecto, los pasos para la evaluación y aceptación de los cambios, los miembros responsables de la autoridad de control de cambios, la política para las copias de seguridad y la generación de informes y auditorías.
• Hitos: Puntos relevantes en el desarrollo del proyecto.

1.4. Definiciones, Acrónimos y Abreviaciones

Se resaltan los siguientes conceptos importantes, junto a sus acrónimos y abreviaciones:

• Elemento de Configuración Software (ECS, Configuration Item): Cada elemento que se ha de controlar y gestionar.
• Línea Base Software: Conjunto de ECS formalmente diseñados y fijados en un instante específico durante el ciclo de vida del software.
• Autoridad de Control de Cambios (ACC, Change Control Board – CCB): Grupo de personas encargadas de decidir la realización de un cambio y de evaluar su implementación.

2. Organización y Responsabilidades (Gestión de SCM)

Se describen las responsabilidades y los responsables para la realización de las actividades de gestión de configuración dentro del proyecto.

2.1. Estructura Organizacional

Se especifican las estructuras organizacionales, tanto técnicas como de gestión de proyecto, que participarán en la implementación de actividades de SCM. Se debe identificar:

• Todas las líneas de trabajo que participen o sean responsables de actividades de SCM.
• El cometido de estas líneas de trabajo dentro del proyecto.
• Relaciones entre estas líneas de trabajo.

2.2. Responsabilidades del Representante de Gestión de Configuración (SCMR)

El SCMR (Software Configuration Management Representative) debe proveer la infraestructura y el entorno de configuración para el proyecto. Debe asegurar que todos los integrantes del grupo entiendan y puedan ejecutar las actividades de SCM que el Plan les asigna, así como garantizar que estas sean llevadas a cabo. Seguir la línea base, controlando las versiones y cambios de ella, son tareas correspondientes a él. Debe definir y construir el Ambiente Controlado e informar al resto del equipo sobre la manera de usarlo. El SCMR es un apoyo importante para las decisiones que debe tomar el CCB, debiendo formar parte de este si lo cree necesario.

Otras actividades que conciernen al SCMR son:

• Identificar los elementos de configuración, estableciendo así la línea base del proyecto.
• Fijar una política de nomenclatura de los elementos de configuración para facilitar la identificación y ubicación de estos en el proyecto.
• Llevar a cabo el control de la configuración, estableciendo estándares y procedimientos a seguir con respecto a los cambios para permitir un control de los mismos.
• Proveer de reportes de estado de la configuración mediante el seguimiento del historial de las revisiones y liberaciones.
• Realizar auditorías de la línea base del software para verificar que el Sistema en desarrollo es consistente y la línea base está bien definida.

2.3. Políticas, Directivas y Procedimientos Aplicables

Se especifican restricciones de políticas o procedimientos externos al Plan. Para cada una se debe detallar el impacto y efecto sobre el Plan.

3. Actividades de SCM

Esta sección identifica todas las actividades y tareas que se requieren para el manejo de la configuración del sistema. Estas deben ser tanto actividades técnicas como de gestión de SCM, así como las actividades generales del proyecto que tengan implicancia sobre el manejo de configuración.

3.1. Identificación de Elementos de Configuración y Líneas Base

Para este proyecto, los elementos de configuración se corresponderán con los entregables definidos en el Modelo de Proceso, aunque no necesariamente todos los entregables deben ser elementos de configuración. La decisión de cuáles de los entregables serán elementos de configuración será tomada por el SCMR, quien deberá tomar en cuenta qué productos serán necesarios cuando se quiera recuperar una versión completa del sistema.

3.1.1. Elementos de Configuración a Controlar

A continuación, se presentan los elementos que se pondrán bajo la gestión de la configuración:

• Planes del Proyecto
• Requerimientos
• Diseño
• Código Fuente
• Herramientas
• Documentación del Sistema
• Procedimientos de Prueba
• Resultados de Prueba

Los tipos de documentos y sus acrónimos se muestran a continuación:

• DS – Especificaciones de Diseño
• TP – Planes de Pruebas
• HDS – Especificaciones de Diseño de Hardware
• RS – Especificación de Requisitos
• PP – Planes del Proyecto
• SC – Código Fuente

3.1.2. Establecimiento de Líneas Base

Se debe generar una línea base por iteración en cada Fase, de acuerdo a lo siguiente:

• Los eventos que dan origen a la línea base.
• Los elementos que serán controlados en la línea base.
• Los procedimientos usados para establecer y cambiar la línea base.
• La autorización requerida para aprobar cambios a los documentos de la línea base.

Al finalizar cada iteración se establecerá una línea base, en la cual todos los documentos, ejecutables y código fuente habrán sido identificados, probados y evaluados, y estarán a disposición de cambios, si así lo aprueba la autoridad de cambios. También se pueden establecer líneas base a lo largo del desarrollo en las cuales se incluirán cambios, los cuales por su importancia o por el grado en que afectan al proyecto, son elegidos para formar parte de una nueva línea base si así lo estima necesario la autoridad de cambios.

3.1.3. Estimación de Tiempo para Identificación

Con base al ERS (Especificación de Requisitos del Sistema) del proyecto, el CMO (Configuration Management Officer) determinó que el tiempo estimado para la identificación de los elementos tomará un total de 2 semanas a partir del día 20 de diciembre, sin contar los días festivos: 24, 25 y 31 de diciembre del 2010 y el día 1 de enero del 2011.

3.2. Control de Configuración (Gestión de Cambios)

En esta sección se detallan las actividades de solicitud, evaluación, aprobación e implementación de cambios a los elementos de la línea base. Los cambios apuntan tanto a la corrección como al mejoramiento. El procedimiento que se describe a continuación es el que se utilizará cada vez que se precise introducir un cambio al sistema. Se entiende por cambio al sistema las modificaciones que afecten a la línea base del sistema, como pueden ser:

• Cambios en los Requerimientos.
• Cambios en el Diseño.
• Cambios en la Arquitectura.
• Cambios en las herramientas de desarrollo.
• Cambios en la documentación del proyecto (agregar nuevos documentos o modificar la estructura de los existentes).

3.2.1. Solicitud de Cambios

Cuando se realiza la solicitud de un cambio, se actualiza el documento de “Solicitud de Cambio” para registrar esta solicitud. Se debe ingresar toda la información necesaria, detallada en el documento.

3.2.2. Evaluación de Cambios e Impacto

La evaluación del cambio involucra determinar qué es necesario hacer para implementarlo y la estimación de sus costos y plazos. Se realiza en dos pasos:

1. Planificación de la Evaluación del Cambio: Involucra:
   • Revisar la solicitud de cambio para entender su alcance. (Si es necesario, se discute con el originador para aclarar el alcance de lo propuesto y los motivos de la solicitud).
   • Determinar las personas del proyecto que deben realizar el análisis de evaluación del cambio e involucrarlas.
   • Desarrollar un Plan para la evaluación del cambio.
   • Si el cambio involucra al Cliente, obtener el acuerdo de este con el Plan.
2. Evaluar el Cambio: Dependiendo de las características del cambio, la evaluación puede ser realizada por el Administrador o ser delegada a otras personas del proyecto. Se debe determinar el impacto en:
   • Los productos técnicos.
   • Los Planes de proyecto.
   • Los acuerdos con el Cliente.
   • Los Riesgos del proyecto.

3.2.3. Aprobación o Desaprobación de Cambios (CCB)

Se debe formar el Comité de Control de Configuración (CCB) y determinar su autoridad para la aprobación de cambios. La composición de este comité puede variar según el tipo de cambio y las líneas de trabajo involucradas en él. Se sugieren como posibles integrantes:

• Administrador (obligatorio)
• Arquitecto (opcional)
• Analista (opcional)
• Implementador (opcional)
• SCM (obligatorio)
• Cliente (opcional)

Se define un comité de Control de Configuración de nivel superior, compuesto por el Gerente de proyecto, al cual se elevarán las solicitudes de cambios cuya aprobación o desaprobación no se pueda resolver por el primer comité.

3.2.4. Implementación de Cambios

Una vez realizada la evaluación del cambio, se decide en qué momento implementarlo. Esta etapa involucra los procesos necesarios para implementar la solicitud y monitorear el progreso del trabajo. Además, se especificará el momento de liberación del cambio, así como también los responsables de las actividades que involucra el cambio.

Recordando que nos basamos en un proceso de desarrollo incremental e iterativo, donde en cada iteración se realizan tareas de Análisis de Requerimientos, Diseño, Implementación y Verificación; se debe introducir el cambio en el área que lo originó y continuar con las actividades del ciclo (Requerimientos, Diseño, Implementación, Verificación) que impactarán los elementos de la línea base correspondientes a cada actividad.

3.3. Estado de la Configuración e Informes

Las actividades de control de estado son para reunir información y reportar el estado de los elementos de configuración. Se debe especificar lo siguiente:

• Qué elementos serán revisados de la línea base y por cambios a realizarse.
• Qué tipos de reportes de estado serán generados y con qué frecuencia.
• Cómo la información será obtenida, guardada, procesada y reportada.
• Cómo será controlado el acceso a los datos de estado. Si se utiliza una herramienta automática, deberá ser especificada su funcionalidad y modo de uso explícitamente o por referencia.

En los reportes de estado de los elementos de configuración se debe incluir como mínimo la siguiente información:

• Su primera versión aprobada.
• El estado de los cambios solicitados.
• El estado de implementación de los cambios aprobados.

3.3.1. Tipos de Informes Generados

Generaremos tres tipos diferentes de informes, todos generados al final de cada semana o iteración:

1. Primer Informe (Estado de Solicitudes): Mostrará el estado actual de todas las solicitudes de cambio. Las solicitudes de cambio pueden estar en diferentes estados, a continuación, se enumeran y describen los diferentes estados:
   • Sin Confirmar: Estado inicial cuando al evaluar un ECS en las pruebas, existe un bug.
   • Nueva: Un miembro del equipo emite una solicitud de cambio.
   • Asignado: La solicitud de cambio ha sido evaluada por la autoridad de cambios y ha sido asignada a quien corresponda para realizarse el cambio.
   • Resuelta: Se ha implementado el cambio.
   • Reabierto: No ha pasado la verificación de la autoridad de cambios.
   • Verificado: Ha pasado la verificación de la autoridad de cambios.
   • Cerrado: Se efectúa el cambio.
2. Segundo Informe (Tiempos y Frecuencias): Mostrará el tiempo que permanece cada solicitud de cambio en un determinado estado, así como cuántas solicitudes de cambio hay en cada estado y el tiempo medio que han tardado las solicitudes de cambio que han sido resueltas o cerradas hasta ese momento, desde que se emitieron.
3. Tercer Informe (Evolución Gráfica – Fin de Iteración): Se mostrará, en forma de gráfica, la evolución del estado de las solicitudes de cambio, desde la fecha inicial de la iteración hasta la fecha final de la iteración, incluyendo además estadísticas sobre tiempo medio que las solicitudes han permanecido en cada estado, tiempo medio en ser resueltas o cerradas, porcentaje de solicitudes que han sido cerradas, las que han tenido que ser reabiertas, o las que no se han asignado, etc. Este informe se realizará al final de la iteración.

3.4. Auditorías y Revisiones de Configuración

Se realizarán auditorías de la línea base antes de una liberación de esta o de una actualización de la versión de un componente prioritario. Estas auditorías incluirán:

• Objetivo: Verificar que en un momento dado la línea base se compone de una colección consistente y bien definida de productos.
• Elementos de configuración bajo auditoría: Se elegirán uno o más elementos de configuración de mayor prioridad en la línea base.
• Agenda de auditorías: Antes de la liberación o actualización. La auditoría se realizará en la actividad de pruebas.
• Conducción: Las auditorías serán dirigidas por el SCMR.
• Participantes: SCMR y los autores de los elementos de configuración a auditar.
• Documentos Requeridos: Documentos de SCR (Solicitud de Cambio) y reportes de estado de la configuración generados.
• Reportes de Deficiencias y Acciones Correctivas: Determinadas por los participantes.
• Criterio de Aprobación: Lo determina el SCMR.

3.5. Control de Interfases

Las actividades de Control de Interfases controlan los cambios a los elementos de configuración del proyecto que modifican las interfases con elementos fuera del alcance del Plan. Este control será llevado por el SCMR como parte del control de la configuración.

4. Infraestructura, Recursos y Calendario

4.1. Sistema de Gestión de la Configuración y Herramientas

El SVN (Subversion), el Sistema de Control de Versiones, es una herramienta que se utiliza para almacenar todas las versiones del software y dar seguimiento a los cambios y líneas de base del proyecto.

4.1.1. Criterios de Selección del Sistema de Administración

Para seleccionar el sistema que servirá como gestor de la configuración, se tomaron en cuenta los siguientes puntos:

• Que la versión del software no sea de prueba o de pago.
• Permita administrar a los usuarios que tendrán acceso al sistema.
• Permita otorgar permisos a los usuarios que accederán al sistema.
• Que sea un sistema fácil de usar.
• Que no sea un plugin de un ambiente de desarrollo (IDE).
• Que se pueda utilizar en distintos sistemas operativos.
• Que permita solucionar los conflictos que surjan de una manera eficaz.

4.1.2. Plan de Seguridad y Actualización

El gestor de seguridad es el responsable de guardar el contenido del repositorio en un servidor Subversion, el cual se ha creado para tal propósito. Se ha elegido esta opción ya que, gracias a este servidor, cada miembro, en caso de que no esté disponible el acceso al repositorio, puede acceder al servidor con solo introducir el nombre de usuario y la clave, y así no depender de una máquina o de un miembro del equipo en particular.

Al final de cada semana, el gestor de seguridad realizará una copia del repositorio actual en su disco duro local, garantizando así una copia válida del contenido del repositorio en caso de que el servidor resulte dañado o se produzcan pérdidas de datos del repositorio por cualquier motivo.

4.2. Recursos

Identificación de las herramientas de software, técnicas, equipamiento, personal y capacitación necesaria para la implementación de las actividades de SCM.

4.3. Calendario

Se debe establecer la secuencia y coordinación de las actividades y eventos que afecten la implementación del Plan en un cronograma. Este debe incluir las actividades de SCM y especificar las dependencias entre estas actividades y los principales hitos en la planificación del proyecto. Los hitos de las actividades de SCM incluyen:

• Definición de la línea base.
• Implementación de Control de Cambios.
• Fechas de comienzo y fin de las auditorías.

5. Mantenimiento del Plan de SCM

Esta sección debe contener:

• Quién es responsable de monitorear el Plan de SCM.
• Con cuánta frecuencia se realizarán modificaciones al Plan.
• Cómo serán evaluados y aprobados los cambios al Plan.
• Cómo serán realizados y comunicados los cambios al Plan.

Este Plan deberá ser revisado al inicio de cada fase, modificado de acuerdo a lo necesario, aprobado y distribuido al equipo de proyecto.