©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 1 Gestión de configuraciones.

Presentación del tema: "©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 1 Gestión de configuraciones."— Transcripción de la presentación:

1 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 1 Gestión de configuraciones

2 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 2 Objetivos l Explicar la importancia de la gestión de la gestión de la configuración (CM) l Describir las actividades CM clave a saber, planificación de CM, gestión de cambio, gestión de versiones y construcción de sistemas. l Discutir el uso de las herramientas CASE para soportar los procesos de gestión de la configuración

3 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 3 Contenidos l Planificación de la gestión de la configuración l Gestión del cambio l Gestión de versiones y entregas l Construcción de sistemas l Herramientas CASE para la gestión de la configuración

4 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 4 l 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. l 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 Gestión de la configuración

5 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 5 Gestión de la configuración l Implica el desarrollo y aplicación de procedimientos y estándares para gestionar un producto de software en evolución. l La CM puede verse como parte de un proceso de gestión de calidad más general. l 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 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 6 Familias de sistemas Versión de servidor Versión Linux Versión PC Sistema inicial Versión de escritorio Versión Windows XP Versión HP Versión Sun

7 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 7 Estándares CM l La CM debería estar siempre basada en un conjunto de estándares que se aplican dentro de una organización. l 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. l Los estándares pueden estar basados en estándares externos de la CM (P.Ej.: estándar IEEE para CM) l 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 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 8 Desarrollo y pruebas concurrentes l Se acuerda una hora (pongamos las 14:00) para la entrega de los componentes del sistema. l Se construye una nueva versión de un sistema a partir de estos componentes compilándolos y vinculándolos. l Esta nueva versión es entregada para su prueba utilizando pruebas predefinidas. l Los defectos descubiertos durante las pruebas son documentadas y devueltas a los desarrolladores del sistema.

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

10 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 10 l Todos los productos del proceso de software podrían tener que ser gestionados: Especificaciones; Diseños; Programas; Datos de pruebas; Manuales de usuario. l Pueden generarse miles de documentos separados para un gran sistema de software complejo. Planificación de la gestión de la configuración

11 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 11 l Define los tipos de documentos a gestionar y el esquema de nombramiento de los documentos. l Define quien se responsabiliza de los procedimientos de gestión de configuraciones y creación de líneas base. l Define las políticas para el control de cambios y la gestión de versiones. l Define los registros de gestión de configuraciones que deben mantenerse. Planificación de la Gestión de configuraciones

12 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 12 Planificación de la Gestión de configuraciones l Describe las herramientas que deberían utilizarse para ayudar en el proceso de gestión de configuraciones y cualquier limitación en su uso. l Define el proceso de utilización de herramientas. l Define la base de datos de gestión de configuraciones utilizado para registrar la información de la configuración. l Podría incluir información como la gestión de configuraciones del software externo, audición de procesos, etc.

13 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 13 l Los proyectos largos típicamente producen miles de documentos que tienen que ser identificados de forma única. l Algunos de estos documentos deben mantenerse durante toda la vida del software. l El esquema de asignación de nombres de documentos debería definirse de forma que los documentos relacionados tengan nombres relacionados. l 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 Identificación de elementos de la configuración

14 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 14 Jerarquía de la configuración

15 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 15 l Toda la información de la CM debería mantenerse en una base de datos de configuraciones. l 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? l Las bases de datos de la CM debería estar vinculada preferiblemente al software que se está gestionando. Base de datos de configuraciones

16 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 16 Implementación de bases de datos de la CM l 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 l 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. l Más comúnmente la base de datos de la CM se mantiene separada ya que resulta más barato y flexible.

17 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 17 l Los sistemas de software están sujetos a continuas peticiones de cambio: De los usuarios; De los desarrolladores; De las exigencias del mercado. l 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. Gestión del cambio

18 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 18 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 aceptadothen repeat Hacer cambios al software Remitir el software cambiado para aprobar la calidad untilCalidad del software sea adecuada Crear una nueva versión del sistema else Rechazar petición de cambios else Rechazar petición de cambios El proceso de la gestión del cambio

19 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 19 l La definición de un formulario de petición de cambios es parte del proceso de planificación de la CM. l 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) l 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). Formulario de petición de cambios

20 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 20 Formulario de petición de cambios Proyecto :Proteus/PCL-Tools Número:23/02 Solicitante del cambio : I. Sommerville Fecha:1/12/02 Cambio solicitado:: Cuando un componente se seleccione de una estructura, desplegar El nombre del archivo donde se almacena. Analizador del cambio: G. DeanFecha de análisis: 10/12/02 Componentes afectados: Display-Icon.Select, Display-Icon.Display Componentes asociados:FileTable Evaluación del cambio: Relativamente fácil de implementar puesto que se dispone de 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 Prioridad del cambio Baja Implementación del cambio: Esfuerzo estimado: 0,5 días Fecha para CCB: 15/12/02Fecha de decisión del CCB: 1/2/03 Decisión del CCB Aceptar cambio. Cambio a implementar en versión 2.1 Implementador del cambioFecha de cambio: Fecha de remisión para AQ:Decisión de QA: Fecha de remisión a CM: Comentarios

21 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 21 l Un problema importante en la gestión del cambio es seguir la pista del estatus de cambios. l 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. l Estas herramientas están integradas con sistemas e-mail para permitir la distribución electrónica de distribución de peticiones de cambio. Herramientas de seguimiento de cambios

22 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 22 l 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. l Debería ser independiente del responsable del proyecto para el sistema. El grupo a veces es llamado Consejo de control de cambios (CCB) l El CCB debería incluir representantes del personal del cliente y el contratista. Consejo de control de cambios

23 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 23 l Se trata de un registro de los cambios aplicados a un documento o un componente del código. l 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. l 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. Historial de derivación

24 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 24 Información de cabecera del componente

25 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 25 l Consiste en Inventar un esquema de identificación para las versiones de un sistema. l Planificar cuando debe producirse una nueva versión del sistema l Asegurar que los procedimientos y herramientas de gestión de versiones se aplican de manera apropiada. l Planificar y distribuir las nuevas entregas del sistema. Gestión de versiones y entregas

26 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 26 l Versión Un instancia de un sistema que difiere de alguna manera de otras instancias. l Variante Una instancia de un sistema que es funcionalmente idéntica pero diferentes en su aspecto no-funcional l Entrega Una instancia de un sistema que se distribuye a los usuarios externos al equipo de desarrollo. Versiones/Variantes/Entregas

27 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 27 Identificación de versiones l Los procedimientos para la identificación de versiones deberían definir una forma no ambigua de identificar las versiones de componentes. l 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 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 28 l Esquema simple de asignación de nombres que utiliza una derivación lineal V1, V1.1, V1.2, V2.1, V2.2 etc. l La estructura corriente de derivación es un árbol o una red en lugar de una secuencia. l Los nombres no son significativos. l Un esquema de asignación de nombres jerárquico conduce a menos errores en la identificación de versiones. Numeración de las versiones

29 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 29 Estructura de derivación de versiones

30 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 30 l 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. l 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) l En la práctica, la versión también necesita un nombre asociado para una referencia fácil. Identificación basada en atributos

31 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 31 Consultas basadas en atributos l 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. l La consulta selecciona una versión dependiendo de los valores de atributos AC3D (lenguaje=Java, Plataforma = XP, fecha= Ene 2003).

32 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 32 Identificación orientada al cambio l Integra versiones y los cambios realizados para crear estas versiones. l Utilizada para sistemas en lugar de componentes. l Cada cambio propuesto tiene un conjunto de cambios que describe los cambios realizados para implementar el cambio. l 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 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 33 l Las entregas deben incorporar cambios forzados en el sistema por errores descubiertos por los usuarios y por cambios de hardware. l También deben incorporar nueva funcionalidad del sistema. l La planificación de la entrega se ocupa de cuándo emitir una versión del sistema como una entrega. Gestión de entregas

34 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 34 Entregas del sistema l No es solo un conjunto de programas ejecutables. l 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 l Actualmente los sistemas se entregan en discos ópticos (CD o DVD) o como archivos de instalación descargable desde la red.

35 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 35 l 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. l 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. Problemas de entrega

36 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 36 Toma de decisiones de la entrega l La preparación y distribución de la entrega de un sistema es un proceso caro. l 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 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 37 Estrategia de entrega de un sistema

38 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 38 Creación de la entrega l La creación de la entrega implica recoger toda la documentación y archivos requeridos para crear una entrega del sistema. l 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. l 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 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 39 l Se trata del proceso de compilación y enlace de los componentes del software en un sistema ejecutable l Se construyen los diferentes sistemas desde diferentes combinaciones de componentes l Esto proceso actualmente es apoyado por herramientas automatizadas que son conducidas por «secuencias de comandos de construcción» Construcción del sistema

40 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 40 l ¿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. l ¿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. l ¿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. Problemas de construcción del sistema

41 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 41 l ¿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. l ¿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. l ¿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. Problemas de construcción de sistemas

42 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 42 Construcción del sistema Constructo r de sistemas Sistema de administración de versiones Compiladoresenlazador Secuencia de comandos de construcción Versiones de los componentes del código fuente Componentes del código fuente Sistema ejecutable

43 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 43 Herramientas CASE para gestión de configuraciones l Los procesos de CM están estandarizados e implican la aplicación de procedimientos predefinidos. l Deben gestionarse grandes cantidades de datos. l Entonces, el apoyo de herramientas CASE para la CM es esencial. l 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 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 44 Entorno de trabajo de la CM l 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. l 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 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 45 Herramientas de gestión del cambio l 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. l 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 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 46 Herramientas de gestión de versiones l Identificación de versiones y entregas Los sistemas asignan identificadores automáticamente cuando se remite una nueva versión al sistema. l Gestión de almacenamiento. El sistema almacena las diferencias entre versiones en lugar de almacenar todo el código de la versión. l Registro del historial del cambio Registra las razones para la creación de la versión. l Desarrollo independiente Sólo se comprobará una versión cada vez para su cambio. Trabajo paralelo en las diferentes versiones. l Apoyo al proyecto Puede gestionar grupos de archivos asociados con un proyecto en lugar de archivos independientes.

47 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 47 Versiones basadas en Delta Versión 1.0 Versión 1.1 Versión 1.2 Versión 1.3 D1 D2D3 Fecha de creación

48 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 48 Construcción del sistema l Construir un sistema grande es computacionalmente caro y puede llevar varias horas. l Pueden estar implicados cientos de archivos. l 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 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 49 Dependencias entre componentes

50 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 50 l La gestión de la configuración es la gestión del cambio del sistema en productos software. l Debería establecerse un esquema de asignación de nombres a documentos formal y deberían gestionarse los documentos en una base de datos. l La base de datos de la configuración debería registrar la información sobre los cambios y las peticiones de cambio. l Debería establecerse un esquema de identificación de versiones consistente utilizando números de versión, conjunto de atributos o de cambios. Puntos clave

51 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 29 Slide 51 Puntos clave l Las entregas del sistema incluyen el código ejecutable, los datos, los archivos de configuración y documentación. l La construcción de un sistema implica el ensamblaje de componentes en un sistema. l Las herramientas CASE están disponibles para apoyar todas las actividades de gestión de la configuración. l Las herramientas CASE pueden ser herramientas autónomas o sistemas integrados que integran apoyo para la gestión de versiones, la construcción de sistemas y la gestión del cambio.