Tema 8: Gestión de la Configuración

Transcripción

1 Proyectos Informáticos Tema 8: Gestión de la Configuración Contenidos Gestión de la configuración: identificación, versionado, control de los elementos de configuración y líneas base de un proyecto. Gestión y resolución de problemas y cambios tanto de la documentación, de los planes como del código y sus diferentes versiones y líneas base. 2

2 Nombre: Propósito: El propósito de este proceso es establecer y mantener la integridad de todos las salidas de los procesos o proyectos y hacer que estén disponibles a todos los afectados Resultados: Como resultado de la implementación del proceso: 1) Se desarrolla una estrategia de gestión de la configuración; 2) Se identifican, definen y fijan ( baseline ) todos los elementos generados por los procesos o proyectos; 3) Se controlan las modificaciones y entregas de los elementos; 4) Se hacen disponibles a los grupos afectados las modificaciones y entregas; 5) Se registran e informa del estado y de los cambios de los elementos de configuración; 6) Se asegura la completitud y consistencia de los elementos de configuración; 7) Se controla el almacenamiento, manipulación y entrega de los elementos de configuración. Salidas: Elementos de configuración Producto integrado Paquete de entrega Guía de almacenamiento y manipulación Librería, ficheros y sistema de gestión de la configuración Lista de construcción Informe de progreso Plan de gestión de configuración Mecanismo de comunicación Registro de control de cambios Historia de los cambios 3 4

3 El propósito de la gestión de la configuración es planificar, organizar, controlar y coordinar la identificación, almacenamiento, transferencia y cambios del software en todas las fases del desarrollo. Cada proyecto debe establecer un sistema de gestión de la configuración. Los siguientes elementos deben estar sometidos a la gestión de la configuración: documentación, código fuente, código ejecutable, ficheros, herramientas, software y datos de pruebas, etc. Todos los elementos del proyecto deben estar bajo gestión de la configuración: incluyendo planes, informes, etc. La gestión de la configuración debe asegurar que: Se pueden identificar los componentes del software; El software se construye a partir de un conjunto consistente de componentes; Los componentes de software están disponibles y son accesibles; Nunca se pierden los componentes de software (ej. después de un error en el medio físico de entrega, o un error del operador, etc); Se aprueba y documenta cada cambio al software; No se pierden los cambios (ej. Por cambios simultáneos); Siempre es posible ir a una versión anterior; Se mantiene una historia de los cambios, para poder ver quién hizo qué y 5 cuándo. Cada componente del diseño se debe identificar como un CI El identificador debe incluir un número o nombre relativo al propósito del CI. El identificador del CI debe ser único. El identificador de los documentos debe contener el número de la versión y revisión. El método de identificación de los elementos de configuración debe admitir la introducción de nuevos CIs sin requerir la modificación de los identificadores de los CIs ya existentes. Por cada entrega se debe entregar la lista de todos los elementos de configuración que lo componen La lista de CIs debe incluir la lista de problemas implementados, su estado, y la lista de cambios y su estado Cada entrega deberá ir acompañada por una Nota de Entrega. Como parte del método de identificación de la configuración, un módulo de código deberá tener una cabecera con, al menos: Identificador del CI (nombre, tipo, versión); Autor original Fecha de creación; Historia de los cambios (versión/fecha/autor/descripción) 6

4 Todos los documentos y medios de almacenamiento se deben de etiquetar con un formato estándar, con al menos los siguientes datos: Nombre del proyecto; Identificador del elemento de configuración (nombre, tipo, versión); fecha; Descripción del contenido. Como mínimo se deberán implementar las siguientes librerías para todos los componentes del software para asegurar la seguridad, integridad y el control del software (ej. documentación, código fuente y ejecutable, ficheros de pruebas, procedimientos de comandos, etc): Librería de desarrollo (o dinámica); Librería Máster (o controlada); Librería estática (o de Proyectos archivo) Informáticos 3er curso Escuela (que de Informática -no USC se deben modificar). 7 Librerías del proyecto: EQUIPO DE DESARROLLO LEER INTRODUCIR REEMPLAZAR BORRAR DESARROLLO Aprobación Modificación MAESTRO Entrega al cliente Copia de seguridad ARCHIVO GESTOR DE CONFIGURACIONES LEER INTRODUCIR REEMPLAZAR BORRAR 8

5 Se debe cumplir el procedimiento de gestión de los cambios cuando son necesarios para una entrega. Los problemas de software y las propuestas de cambios se deberán gestionar siguiendo procedimientos definidos Se debe guardar el estado de los elementos de la configuración regularmente. Cada proyecto deberá almacenar lo siguiente para realizar el estado de la configuración: La fecha y la versión/revisión de cada línea base; La fecha y el estado de cada problema de software, cada petición de cambio y cada cambio realizado; Un resumen descriptivo de cada elemento de configuración. Como mínimo una Nota de entrega debe registrar los fallos que se han reparado y los requisitos nuevos que se hayan incorporado. Para cada entrega, la documentación y el código deben ser consistentes. Se deben mantener entregas antiguas para su referencia. El código modificado se debe re-probar antes de su entrega. Todas las actividades de gestión de configuración se deben documentar en el Plan de Gestión de Configuración). Los procedimientos de gestión de configuración deben estar preparados ANTES del comienzo del desarrollo del software (que incluye código y documentación). 9 Versiones Autor Revisor Autor Revisor Resp.de aprobar 1.0 Evolución de las versiones de un documento (ejemplo) 10

6 11 Debe haber siempre copias de seguridad actualizadas de la librería Master y Archivo. Se deben establecer procedimientos de copias de seguridad regulares para las librerías de desarrollo también. Los medios físicos de almacenamiento se deben definir claramente EJ: Como medios físicos de almacenamiento para cada nivel de almacenamiento de los EC se podrán utilizar los siguientes: Medio Disco duro servidor Nivel Disco duro local (1) Disco Compacto (CD) Desarrollo RECOMENDADO ACEPTADO NO ACEPTADO Maestro ACEPTADO RECOMENDADO NO ACEPTADO Archivo ACEPTADO ACEPTADO RECOMENDADO (2) (1) Como carpeta compartida de acceso general (2) También podría estar disponible en papel. Ejemplo de Medios físicos de almacenamiento 12

7 Confidencialidad de los EC El responsable de un EC podrá asignarle un carácter confidencial, quedando así excluido de la obligatoriedad de ser controlado en el espacio general de almacenamiento. Los EC de carácter confidencial pueden ser registrados y mantenidos en un archivo exclusivo de acceso restringido según el grado de confidencialidad asignado.. Grado de confidencialidad Descripción Secreto o confidencial Grupo restringido de personas. Personal Una persona determinada. Interno Personal de la organización que lo genera. De proyecto Equipo de trabajo del proyecto. De libre distribución Sin restricciones de confidencialidad. 13 Ejemplo de grados de confidencialidad Ejemplo de Plan de gestión de la configuración: 1 INTRODUCCIÓN 1.1 Propósito 1.2 Ámbito 1.3 Abreviaturas y glosario 1.4 Referencias 2 GESTIÓN 3 IDENTIFICACIÓN DE LA CONFIGURACIÓN 4 CONTROL DE LA CONFIGURACIÓN 4.1 Control del código (y de la documentación) 4.2 Control de los medios físicos de entrega 4.3 Control de cambios 5 ESTADO DE LA CONFIGURACIÓN 6 HERRAMIENTAS, TÉCNICAS Y MÉTODOS PARA SCM 7 CONTROL DE PROVEEDORES 8 COLECCIÓN Y MANTENIMIENTO DE REGISTROS 14

8 Herramientas: Concurrent Versions System - CVS ( ClearCase/ClearQuest (IBM Rational) (www-306.ibm.com/software/awdtools/clearcase/) CM Sinergy (Telelogic) ( PVCS (Merant) ( SparcWorks/TeamWare (SUN) 15 Entregas e instalación: Al final de las actividades de entrega se firma la aceptación provisional y al final del periodo de garantía la aceptación final 16

9 Entregas e instalación: Building e instalación consiste en chequear las los entregables o las entregas, compilar los códigos fuentes, linkar los códigos objeto, y copiar los ficheros ejecutables resultantes en el entorno operacional para las pruebas de aceptación. Los entregables se deben listar en una Lista de elementos de configuración. Éstos pueden ser documentos, datos, hardware, software, medios de almacenamiento, etc. La primera actividad a la hora de la instalación es comparar los entregables reales con la lista de elementos de configuración. Esto se hace: Chequeando que se han entregado todos los dispositivos Chequeando que estos dispositivos contienen los ficheros necesarios. Después, se copia el software al entorno operacional, desde donde se vaya a build La Building del software consiste en compilar los fuentes, y crear finalmente los ejecutables. 17 Entregas e instalación: La fase de transferencia comienza con la build completa para el entorno operacional. Hay que chequear que todos los ficheros del sistema están presentes en la versión adecuada. Los procedimientos de construcción del software deben estar contenidos en el documento de transferencia (o en su defecto en el Manual de Usuario). Se deben proporcionar las herramientas para la build y los procedimientos de cómo usarlas. La facilidad de implementar cambios en las fases de entrega (garantía) y mantenimiento pueden depender de la posibilidad de construir (re-construir) builds parciales del sistema. Los procedimientos de instalación se deben documentar en el Manual de usuario. La instalación debe ayudarse lo más posible de procedimientos automatizados. Cualquier cambio al entorno existente debería ser mínimo y siempre debe estar bien definido. Siempre se debe pedir explícitamente al usuario cambios a ficheros del sistema (ej. Modificación del CONFIG.SYS de MS DOS). Se deben proporcionar procedimientos para la desisnstalación para poder recuperar la versión anterior del sistema y que pase al estado que tenía antes de la instalación. 18

10 Ejemplo de contenido de documento de transferencia o entrega: 1. Introducción 1.1 Propósito 1.2 Ámbito 1.3 Definiciones, acrónimos y abreviaturas 1.4 Referencias 2 Procedimientos de Build 2 3 Procedimientos de instalación 4 Lista de elementos de configuración 5 Resumen de pruebas de aceptación 6 Informes de problemas de software 7 Peticiones de cambios 19 Proceso de gestión de problemas Nombre: Proceso de gestión de problemas Propósito: El propósito de este proceso es para asegurar que todos los problemas son identificados, analizados, gestionados y controlados hasta su resolución. Resultados: Como resultado de la implementación del proceso: 1) Se define una estrategia para la gestión de problemas 2) Los problemas se identifican, registran y clasifican; 3) los problemas se analizan y evalúan para encontrar una solución aceptable; 4) se implementa la solución; 5) los problemas son controlados hasta su cierre; 6) el estado de todos los informes de problemas es conocido; Salidas: Resultados de análisis Oportunidad de mejora Requisitos de mantenimiento Registro de revisiones Trazas Plan/estrategia de entregas Estado/historia de problemas Informe de problema Control de cambios Petición de cambio Historia de los cambios Acciones correctoras Sistema de control de acciones correctoras 20

11 Proceso de gestión de problemas 21 Proceso de gestión de petición de cambios Nombre: Proceso de gestión de petición de cambios Propósito: El propósito de este proceso es para asegurar que todos los cambios son gestionados y controlados. Resultados: Como resultado de la implementación del proceso: 1) Se define una estrategia para la gestión de petición de cambios 2) Las peticiones de cambios se identifican y registran; 3) Se identifican las relaciones y dependencias con otras peticiones de cambio 4) se definen los criterios para la confirmación que un cambio se ha implementado; 5) se priorizan las peticiones de cambio y se estiman los recursos necesarios; 6) se aprueban los cambios en base a su prioridad y a los recursos necesarios estimados; 7) los cambios aprobados se implementan y son controlados hasta su cierre; 8) el estado de todos las peticiones de cambios es conocido; Salidas: Resultados de análisis Oportunidad de mejora Requisitos de mantenimiento Registro de revisiones Trazas Plan/estrategia de entregas Control de cambios Informe de problema Historia de los cambios Petición de cambio Acciones correctoras Sistema de control de acciones correctoras 22

12 Proceso de gestión de petición de cambios Pedir un cambio completando un formulario de petición de cambio Analizar la petición de cambio if cambio es válido then Evaluar cómo se debería implementar el cambio Evaluar el coste del cambio Enviar el cambo al change control board (CCB) if se acepta el cambiothen repeat haz los cambios al software enviar el software cambiado a aprobación de calidad until calidad del software es adecuada crear una nueva versión del sistema else rechazar la petición de cambio else rechazar la petición de cambio 23 Proceso de gestión de petición de cambios 24