10 Oct
Plan de gestion de la configuracion
2.1 Objetivos
El objetivo de este documento, es definir los miembros y actividades de la gestión de configuración, así como los pasos que hay que seguir para la evaluación y aceptación de los cambios, se establecen los responsables de la autoridad de cambios, como sus funciones, se muestra el método de nombrado y la estructura de los informes del estado de configuración.
2.2 AlcanceEl alcance de este documento es establecer la función de la gestión de configuración
2.3 Definiciones, acrónimos y abreviaciones Resaltamos 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 Borrad (CCB)): grupo de personas encargados de decidir la realización de un cambio y de evaluar su implementación.
2.4 Descripciones
El contenido de este documento se divide en 3 apartados: Gestión de Configuración Software, donde se describen los responsables de la gestión de configuración, sus tareas, así como las herramientas, el entorno e 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 que hay que seguir para la evaluación y aceptación de los cambios, los miembros responsables de la autoridad de control cambios, la política para las copias de seguridad y la generación de informes y auditorias. Hitos, punto relevante en el desarrollo del proyecto.
4.1.2 Líneas 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 cuáles 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.
4.3 Informe del estado de configuración 4.3.1 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 nos hemos creado para tal propósito, hemos elegido esta opción ya que gracias a este servidor, cada miembro en caso de que no sea disponible el acceso al repositorio, pueda acceder al servidor, con solo introducir el nombre de usuario y la clave, y así no depender de una máquina o en 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 valida 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.3.2 Informes y auditoria Generaremos tres tipos diferentes de informes:
En el primer informe se mostrará el estado actual de todas las solicitudes de cambio. Las solicitudes de cambio pueden estar en diferentes estados, a continuación enumeramos y describimos 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. Este informe se genera al final de cada semana
. En el segundo informe mostraremos el tiempo que permanecen cada solicitud de cambio en un determinado estado, así como cuantas solicitudes de cambio hay en cada estado y el tiempo medio
que han tardado las solicitud de cambio que han sido resueltas o cerradas hasta ese momento, desde que se emitieron. Este informe se generará al final de cada semana. En el tercer informe 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. La auditoria, se realizará en la actividad de pruebas.
#2
2. Gestión de SCM [Se describen las responsabilidades y responsables para la realización de las actividades de gestión de configuración dentro del proyecto.]
2.1. Organización [Se deben especificar las estructuras organizacionales tanto técnicas como de gestión de proyecto, las cuales 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 El SCMR debe proveer la infraestructura y el entorno de configuración para el proyecto. Debe preocuparse porque todos los integrantes del grupo entiendan y puedan ejecutar las actividades de SCM que el Plan les asigna, así como asegurar que éstas sean llevadas a cabo. Seguir la línea base, controlando las versiones y cambios de ella, son tareas correspondientes a el. 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 éste 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 éstos 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
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.1. Elementos de configuración 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 cuales de los entregables serán elementos de configuración será tomada por el SCMR, quién deberá tomar en cuenta qué productos serán necesarios cuando se quiera recuperar una versión completa del sistema. 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.
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. Control de configuración
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.2. Evaluación de cambios o Análisis de Impacto La evaluación del cambio involucra determinar qué es necesario hacer para implementar el cambio y la estimación de sus costos y plazos. Se realiza en 2 pasos
: 1. Planificación de la evaluación del cambio que 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 éste con el Plan.
2. Evaluar el cambio
Dependiendo de las características del cambio, la evaluación del cambio puede ser realizado por el Administrador o ser delegado 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
Se debe formar el “Comité de Control de Configuración” 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, Análisis, 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 [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. • Como la información será obtenida, guardada, procesada, y reportada. • Como 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 primer versión aprobada. • El estado de los cambios solicitados. • El estado de implementación de los cambios aprobados.]
3.4. Auditorias y revisiones de configuración
Se realizarán auditorias de la línea base antes de una liberación de ésta o de una actualización de la versión de un componente prioritario de ésta. Estas auditorias incluirán: • Objetivo: el objetivo de todas las auditorías es 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 mas elementos de configuración de mayor prioridad en la línea base. • Agenda de auditorías: antes de la liberación o actualización. • 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 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. 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 auditorias.]
5. 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.]
1. Mantenimiento del Plan de SCM [Esta sección debe contener:
• Quien es responsable de monitorear el Plan de SCM. • Con cuanta frecuencia se realizarán modificaciones al Plan. • Como serán evaluados y aprobados los cambios al Plan. • Como 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.]
#3
2 Organización 2.1
Sistema de Gestión de la Configuración SVN, el Sistema de control de versiones, es una herramienta que se utiliza para almacenar todas las versiones del software y dar seguimiento de los cambios y líneas de base del proyecto.
3.1 Estimación de tiempo para identificación de Elementos
Con base al ERS del proyecto, el CMO, determino que el tiempo estimado para la identificación delo elementos tomara un total de 2 semanas a partir del día 20 de diciembre, sin tomar los días festivos, 24, 25 y 31 de diciembre del 2010 y el día 1 de enero del 2011
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 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
1.1 Establecer un sistema de administración de configuración Para seleccionar el sistema que servirá como gestor de la configuración, se tomara en cuenta los siguientes puntos: • Que la versión del software no sea de prueba o de paga. • 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
Deja un comentario