Gestión de configuraciones

1. Gestión de configuraciones

2. Objetivos • Explicar la importancia de la gestión de la gestión de la configuración (CM) • Describir las actividades CM clave a saber, planificación de CM, gestión de cambio, gestión de versiones y construcción de sistemas. • Discutir el uso de las herramientas CASE para soportar los procesos de gestión de la configuración

3. Contenidos • Planificación de la gestión de la configuración • Gestión del cambio • Gestión de versiones y entregas • Construcción de sistemas • Herramientas CASE para la gestión de la configuración

4. Gestión de la configuración • se crean nuevas versiones de sistemas software según van cambiando: • Para diferentes sistemas operativos de máquinas; • Que ofrecen diferente funcionalidad; • Hechos a medida para los requerimientos de un usuario particular. • La gestión de la configuración se ocupa de gestionar sistemas de software en evolución: • El cambio del sistema es una actividad de equipo; • La CM pretende controlar los costes y esfuerzos implicados en realizar cambios en un sistema

5. Gestión de la configuración • Implica el desarrollo y aplicación de procedimientos y estándares para gestionar un producto de software en evolución. • La CM puede verse como parte de un proceso de gestión de calidad más general. • Cuando se entregan al gestor de la configuración, los sistemas de software a veces son llamados «líneas base» ya que son un punto de partida para un posterior desarrollo.

6. Familias de sistemas Versión de escritorio Versión HP Versión Windows XP Versión de servidor Sistema inicial Versión PC Versión Linux Versión Sun

7. Estándares CM • La CM debería estar siempre basada en un conjunto de estándares que se aplican dentro de una organización. • Los estándares deberían definir como se identifican los elementos, cómo se controlan los cambios y cómo se gestionan las nuevas versiones. • Los estándares pueden estar basados en estándares externos de la CM (P.Ej.: estándar IEEE para CM) • Algunos estándares existentes están basados en modelos de proceso de cascada – se necesitan nuevos estándares de gestión de configuraciones para el desarrollo evolutivo.

8. Desarrollo y pruebas concurrentes • Se acuerda una hora (pongamos las 14:00) para la entrega de los componentes del sistema. • Se construye una nueva versión de un sistema a partir de estos componentes compilándolos y vinculándolos. • Esta nueva versión es entregada para su prueba utilizando pruebas predefinidas. • Los defectos descubiertos durante las pruebas son documentadas y devueltas a los desarrolladores del sistema.

9. Construcción frecuente del sistema • Es más fácil encontrar problemas que provienen de las interacciones de los componentes en una etapa temprana del proceso. • Esto fomenta las pruebas minuciosas de la unidad – los desarrolladores se encuentran bajo la presión de no «romper la construcción». • Se requiere un proceso de gestión del cambio estricto para seguir la pista a los problemas que han sido descubiertos y reparados.

10. Planificación de la gestión de la configuración • Todos los productos del proceso de software podrían tener que ser gestionados: • Especificaciones; • Diseños; • Programas; • Datos de pruebas; • Manuales de usuario. • Pueden generarse miles de documentos separados para un gran sistema de software complejo.

11. Planificación de la Gestión de configuraciones • Define los tipos de documentos a gestionar y el esquema de nombramiento de los documentos. • Define quien se responsabiliza de los procedimientos de gestión de configuraciones y creación de líneas base. • Define las políticas para el control de cambios y la gestión de versiones. • Define los registros de gestión de configuraciones que deben mantenerse.

12. Planificación de la Gestión de configuraciones • Describe las herramientas que deberían utilizarse para ayudar en el proceso de gestión de configuraciones y cualquier limitación en su uso. • Define el proceso de utilización de herramientas. • Define la base de datos de gestión de configuraciones utilizado para registrar la información de la configuración. • Podría incluir información como la gestión de configuraciones del software externo, audición de procesos, etc.

13. Identificación de elementos de la configuración • Los proyectos largos típicamente producen miles de documentos que tienen que ser identificados de forma única. • Algunos de estos documentos deben mantenerse durante toda la vida del software. • El esquema de asignación de nombres de documentos debería definirse de forma que los documentos relacionados tengan nombres relacionados. • Un esquema jerárquico con nombres de múltiples niveles es probablemente el enfoque más flexible. • PCL-TOOLS/EDIT/FORMS/DISPLAY/AST-INTERFACE/CODE

14. Jerarquía de la configuración

15. Base de datos de configuraciones • Toda la información de la CM debería mantenerse en una base de datos de configuraciones. • Esto debería permitir responder a las consultas sobre configuraciones: • ¿Quién posee una versión particular del sistema? • ¿Qué plataforma se requiere para esa versión? • ¿Qué versiones se ven afectadas por un cambio en el componente X? • ¿Cuántos fallos declarados existen en la versión T? • Las bases de datos de la CM debería estar vinculada preferiblemente al software que se está gestionando.

16. Implementación de bases de datos de la CM • Debe ser parte de un entorno integrado para apoyar el desarrollo del software. • La base de datos de la CM y los documentos gestionados se mantienen todos en el mismo sistema • Las herramientas CASE deben estar integradas con éste para que haya una estrecha relación entre las herramientas CASE y las herramientas de la CM. • Más comúnmente la base de datos de la CM se mantiene separada ya que resulta más barato y flexible.

17. Gestión del cambio • Los sistemas de software están sujetos a continuas peticiones de cambio: • De los usuarios; • De los desarrolladores; • De las exigencias del mercado. • La gestión del cambio se ocupa de seguir la pista de estos cambios y asegurar que son implementados de la forma más rentable.

18. El proceso de la gestión del cambio Solicitar cambios completando un formulario de solicitud de cambios Analizar la solicitud de cambios If cambio es válido then Evaluar cómo implementar el cambio Evaluar los costos del cambio Remitir la petición a la oficina de control de cambios if cambio es aceptado then repeat Hacer cambios al software Remitir el software cambiado para aprobar la calidad until Calidad del software sea adecuada Crear una nueva versión del sistema else Rechazar petición de cambios else Rechazar petición de cambios

19. Formulario de petición de cambios • La definición de un formulario de petición de cambios es parte del proceso de planificación de la CM. • Este formulario registra el cambio propuesto, el solicitante del cambio, la razón por la cual se sugiere el cambio y la urgencia del mismo (urgencia proveniente del solicitante del cambio) • También registra la evaluación del cambio, el análisis de impacto, el coste del cambio y recomendaciones (del personal de mantenimiento del sistema).

20. Formulario de petición de cambios Formulario de petición de cambios Proyecto Número: 23/02 : Proteus/PCL-T ools Solicitante del cambio : Fecha: 1/12/02 I. Sommerville Cambio solicitado:: Cuando un componente se seleccione de una estructura, desplegar El nombre del archivo donde se almacena. G. Dean Fecha de análisis: Analizador del cambio: 10/12/02 Display-Icon.Select, Display-Icon.Display Componentes afectados: Componentes asociados: FileT able Relativamente fácil de implementar puesto que se dispone de Evaluación del cambio: Una tabla de los nombres de los archivos. Requiere el diseño e implementación de un Campo de despliegue. No se requieren cambios en los componentes asociados Baja Prioridad del cambio Implementación del cambio: 0,5 días Esfuerzo estimado: 15/12/02 Fecha de decisión del CCB: Fecha para CCB: 1/2/03 Aceptar cambio. Cambio a implementar en versión 2.1 Decisión del CCB Implementador del cambio Fecha de cambio: Fecha de remisión para AQ: Decisión de QA: Fecha de remisión a CM: Comentarios

21. Herramientas de seguimiento de cambios • Un problema importante en la gestión del cambio es seguir la pista del estatus de cambios. • Las herramientas de seguimiento del cambio llevan un registro de cada petición de cambio y automáticamente aseguran que las peticiones de cambio sean enviadas a las personas correctas en el momento correcto. • Estas herramientas están integradas con sistemas e-mail para permitir la distribución electrónica de distribución de peticiones de cambio.

22. Consejo de control de cambios • Los cambios deberían ser revisados por un grupo externo que decida si éstos son rentables o no desde un punto de vista estratégico y organizacional y no desde un punto de vista técnico. • Debería ser independiente del responsable del proyecto para el sistema. El grupo a veces es llamado Consejo de control de cambios (CCB) • El CCB debería incluir representantes del personal del cliente y el contratista.

23. Historial de derivación • Se trata de un registro de los cambios aplicados a un documento o un componente del código. • Debería registrar, en resumen, el cambio realizado, la lógica del cambio, quién realizó el cambio y cuándo se implementó el mismo. • Esto debería incluirse como un comentario en el código. Si se utiliza un estilo de prólogo estándar para el historial de derivación, las herramientas pueden procesarlo automáticamente.

24. Información de cabecera del componente

25. Gestión de versiones y entregas • Consiste en Inventar un esquema de identificación para las versiones de un sistema. • Planificar cuando debe producirse una nueva versión del sistema • Asegurar que los procedimientos y herramientas de gestión de versiones se aplican de manera apropiada. • Planificar y distribuir las nuevas entregas del sistema.

26. Versiones/Variantes/Entregas • Versión Un instancia de un sistema que difiere de alguna manera de otras instancias. • Variante Una instancia de un sistema que es funcionalmente idéntica pero diferentes en su aspecto no-funcional • Entrega Una instancia de un sistema que se distribuye a los usuarios externos al equipo de desarrollo.

27. Identificación de versiones • Los procedimientos para la identificación de versiones deberían definir una forma no ambigua de identificar las versiones de componentes. • Existen tres técnicas básicas para la identificación de componentes • Numeración de las versiones; • Identificación basada en atributos; • Identificación orientada al cambio.

28. Numeración de las versiones • Esquema simple de asignación de nombres que utiliza una derivación lineal • V1, V1.1, V1.2, V2.1, V2.2 etc. • La estructura corriente de derivación es un árbol o una red en lugar de una secuencia. • Los nombres no son significativos. • Un esquema de asignación de nombres jerárquico conduce a menos errores en la identificación de versiones.

29. Estructura de derivación de versiones

30. Identificación basada en atributos • Pueden asociarse los atributos con una versión con la combinación de atributos que identifican esa versión. • Ejemplos de atributos son Fecha, Creador, Lenguaje de Programación, Cliente, Estatus, etc. • Esto es más flexible que un esquema de asignación de nombres explícito para la recuperación de versiones; sin embargo, puede causar problemas con la exclusividad (tiene que escogerse el conjunto de atributos para que todas las versiones puedan identificarse de manera única) • En la práctica, la versión también necesita un nombre asociado para una referencia fácil.

31. Consultas basadas en atributos • Una importante ventaja de la identificación basada en atributos es que puede soportar consultas de forma que podemos encontrar «la versión más reciente en Java», etc. • La consulta selecciona una versión dependiendo de los valores de atributos • AC3D (lenguaje=Java, Plataforma = XP, fecha= Ene 2003).

32. Identificación orientada al cambio • Integra versiones y los cambios realizados para crear estas versiones. • Utilizada para sistemas en lugar de componentes. • Cada cambio propuesto tiene un conjunto de cambios que describe los cambios realizados para implementar el cambio. • Los conjuntos de cambios se aplican en secuencia de forma que, en principio, una versión del sistema que incorpora un conjunto arbitrario de cambios pueda ser creada.

33. Gestión de entregas • Las entregas deben incorporar cambios forzados en el sistema por errores descubiertos por los usuarios y por cambios de hardware. • También deben incorporar nueva funcionalidad del sistema. • La planificación de la entrega se ocupa de cuándo emitir una versión del sistema como una entrega.

34. Entregas del sistema • No es solo un conjunto de programas ejecutables. • También debería incluir: • Archivos de configuración que definan como se configura la entrega para una instalación particular; • Los archivos de datos que se necesitan para el funcionamiento del sistema; • Un programa de instalación para instalar el sistema en el hardware de destino; • Documentación electrónica y en papel; • Embalaje y publicidad asociados diseñados para esta entrega • Actualmente los sistemas se entregan en discos ópticos (CD o DVD) o como archivos de instalación descargable desde la red.

35. Problemas de entrega • El cliente puede no querer una nueva entre del sistema • Puede que estén contentos con sus sistemas actuales ya que la nueva versión puede proporcionar una funcionalidad no deseada. • La gestión de la entrega no debería suponer que todas las entregas previas hayan sido aceptadas. Todos los archivos requeridos para una entrega deberían volver a crearse cuando se instala una nueva entrega.

36. Toma de decisiones de la entrega • La preparación y distribución de la entrega de un sistema es un proceso caro. • Factores como la calidad técnica del sistema, la competitividad, los requerimientos de marketing y las peticiones de cambio del cliente deberían influir en la decisión de cuándo publicar una nueva entrega del sistema.

37. Estrategia de entrega de un sistema

38. Creación de la entrega • La creación de la entrega implica recoger toda la documentación y archivos requeridos para crear una entrega del sistema. • Deben escribirse las descripciones de la configuración ya que tienen que escribirse las diferentes secuencias de comandos del hardware y de la instalación. • Debe documentarse la entrega específica para registrar exactamente qué archivos se utilizaron para crearlo. Esto permite que sea posible recrearlo si es necesario.

39. Construcción del sistema • Se trata del proceso de compilación y enlace de los componentes del software en un sistema ejecutable • Se construyen los diferentes sistemas desde diferentes combinaciones de componentes • Esto proceso actualmente es apoyado por herramientas automatizadas que son conducidas por «secuencias de comandos de construcción»

40. Problemas de construcción del sistema • ¿Todos los componentes de un sistema se incluyen en las instrucciones de la construcción? • Cuando hay cientos de componentes creando un sistema, es más fácil perder uno. Normalmente esto debería ser detectado por el enlazador. • ¿La versión apropiada de cada componente se incluye en las instrucciones de la construcción? • Es un problema más importante. Un sistema construido con la versión errónea puede funcionar inicialmente pero fallar después de la entrega. • ¿Están disponibles todos los archivos de datos requeridos? • No se debería confiar en archivos de datos estándar. Los estándares varían de un lugar a otro.

41. Problemas de construcción de sistemas • ¿Son correctas las referencias del archivo de datos dentro de los componentes? • Los nombres empotrados absolutos en el código casi siempre causan problemas ya que las convenciones de asignación de nombres difieren de un lugar a otro. • ¿Se está construyendo el sistema para la plataforma correcta? • A veces se debe construir para una versión de un Sistema Operativo específico o una configuración hardware específica. • ¿Se especifican la versión correcta del compilador y otras herramientas de software? • Las diferentes versiones de compiladores pueden generar diferentes códigos y el componente compilado exhibirá diferentes comportamientos.

42. Construcción del sistema Sistema de administración de versiones Constructor de sistemas Compiladores enlazador Secuencia de comandos de construcción Versiones de los componentes del código fuente Componentes del código fuente Sistema ejecutable

43. Herramientas CASE para gestión de configuraciones • Los procesos de CM están estandarizados e implican la aplicación de procedimientos predefinidos. • Deben gestionarse grandes cantidades de datos. • Entonces, el apoyo de herramientas CASE para la CM es esencial. • Las herramientas CASE maduras para el apoyo a la gestión de la configuración están disponibles variando desde herramientas autónomos hasta bancos de trabajo de la CM.

44. Entorno de trabajo de la CM • Entornos de trabajo abiertos • Las herramientas para cada etapa en el proceso de la CM están integradas a través de procedimientos y secuencias de comandos organizacionales. • Entornos integrados • Proporcionan facilidades integradas de todo el proceso para la gestión de la configuración. Incluyen herramientas más estrechamente integradas por lo que su uso resulta más fácil.

45. Herramientas de gestión del cambio • La gestión del cambio es un proceso de procedimiento así que puede ser modelado e integrado con un sistema de gestión de versiones. • Herramientas de gestión de cambios • Editor de formularios para procesar los formularios de petición de cambios; • Sistema de flujo de datos para definir quién hace qué y automatizar la transferencia de datos; • Cambiar la base de datos que gestiona las proposiciones de cambio y está vinculado a un Sistema de gestión de versiones; • Sistema de informes de cambios que generan informes de cambios en el estatus de petición de cambios.

46. Herramientas de gestión de versiones • Identificación de versiones y entregas • Los sistemas asignan identificadores automáticamente cuando se remite una nueva versión al sistema. • Gestión de almacenamiento. • El sistema almacena las diferencias entre versiones en lugar de almacenar todo el código de la versión. • Registro del historial del cambio • Registra las razones para la creación de la versión. • Desarrollo independiente • Sólo se comprobará una versión cada vez para su cambio. Trabajo paralelo en las diferentes versiones. • Apoyo al proyecto • Puede gestionar grupos de archivos asociados con un proyecto en lugar de archivos independientes.

47. Versiones basadas en Delta V ersión V ersión V ersión V ersión 1.0 1.1 1.2 1.3 D1 D2 D3 Fecha de creación

48. Construcción del sistema • Construir un sistema grande es computacionalmente caro y puede llevar varias horas. • Pueden estar implicados cientos de archivos. • Las herramientas de construcción de un sistema deben proporcionar • Una dependencia del lenguaje de especificación o del intérprete asociado; • Selección de herramientas y apoyo a la instancia; • Compilación distribuida; • Gestión de los objetos derivados.

49. Dependencias entre componentes

50. Puntos clave • La gestión de la configuración es la gestión del cambio del sistema en productos software. • Debería establecerse un esquema de asignación de nombres a documentos formal y deberían gestionarse los documentos en una base de datos. • La base de datos de la configuración debería registrar la información sobre los cambios y las peticiones de cambio. • Debería establecerse un esquema de identificación de versiones consistente utilizando números de versión, conjunto de atributos o de cambios.