Gestión de configuraciones

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 1

Gestión de configuraciones


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


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


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

Gestión de la configuración


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.


Familias de sistemas

Versión de servidor

Versión Linux

Versión PCSistema inicial

Versión de escritorio

Versión Windows XP

Versión HP

Versión Sun


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.


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.


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.


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.

Planificación de la gestión de la configuración


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.

Planificación de la Gestión de configuraciones


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.


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

Identificación de elementos de la configuración


Jerarquía de la configuración

PCL-TOOLS

EDIT

STRUCTURES

BIND

FORM

COMPILE MAKE-GEN

HELP

DISPLAY QUERY

AST-INTERFACEFORM-SPECS FORM-IO

CODEOBJECTS TESTS


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.

Base de datos de configuraciones


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.


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.

Gestión del cambio


Solicitar cambios completando un formulario de solicitud de cambiosAnalizar la solicitud de cambiosIf 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

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


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).

Formulario de petición de cambios




Proyecto: Proteus/PCL-Tools Número: 23/02Solicitante del cambio :I. Sommerville Fecha: 1/12/02Cambio solicitado:: Cuando un componente se seleccione de una estructura, desplegarEl nombre del archivo donde se almacena.

Analizador del cambio: G. Dean Fecha de análisis:10/12/02Componentes afectados:Display-Icon.Select, Display-Icon.Display

Componentes asociados:FileTable

Evaluación del cambio: Relativamente fácil de implementar puesto que se dispone deUna 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/02 Fecha de decisión del CCB:1/2/03Decisión del CCB Aceptar cambio. Cambio a implementar en versión 2.1Implementador del cambio Fecha de cambio:Fecha de remisión para AQ: Decisión de QA:Fecha de remisión a CM:Comentarios


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.

Herramientas de seguimiento 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.

Consejo de control de cambios


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.

Historial de derivación


Información de cabecera del componente


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.

Gestión de versiones y 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.

Versiones/Variantes/Entregas


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.


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.

Numeración de las versiones


Estructura de derivación de versiones

V1.0 V1.1 V1.2 V2.0 V2.1 V2.2

V1.1b V1.1.1

V1.1a


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.

Identificación basada en atributos


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).


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.


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.

Gestión de entregas


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.


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.

Problemas de entrega


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.


Estrategia de entrega de un sistema

Factor Descripción

Calidad técnica Si se reportan fallos que afecten a la forma en la que los clientes utilizan el sistema, es necesario emitir una versión para reparar el fallo. Sin embargo, los fallos menores del sistema se reparan mediante parches (a menudo distribuidos por internet) que se aplican a las entregas actuales del sistema

Cambios en la plataforma

Usted puede tener que crear nuevas entregas de una aplicación software cuando aparece una nueva versión del sistema operativo

Quinta ley de Lehman (véase capítulo 21)

Ésta sugiere que el incremento de la funcionalidad incluida en cada versión sea aproximadamente constante. Por lo tanto, si existe una versión del sistema con funcionalidades completamente nuevas, ésta debe seguirse de una entrega de reparación

Competencia Se necesita una nueva versión del sistema cuando está disponible el producto competidor.

Requerimientos de marketing

El departamento de marketing de una organización puede estar interesado en tener lista la entrega en una fecha particular.

Propuestas de cambios del cliente

Para sistemas personalizados, los clientes hacen un pago por un conjunto específico de cambios en el sistema y esperan a que el sistema se entregue tan pronto como estos cambios sean implementados.


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.


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»

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.

Problemas de construcción del sistema


¿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.

Problemas de construcción de sistemas



Constructor de

sistemas

Sistema de administració

n de versiones

Compiladores enlazador

Secuencia de comandos de construcción

Versiones de los componentes

del código fuente

Componentes del código

fuente

Sistema ejecutable


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.


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.


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.


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.


Versiones basadas en Delta

Versión1.0

Versión1.1

Versión1.2

Versión1.3

D1 D2 D3

Fecha de creación



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.


Dependencias entre componentes

comp

scan.o syn.o sem.o cgen.o

scan.o syn.o

defs.h

sem.o cgen.o


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.

Puntos clave


Puntos clave

Las entregas del sistema incluyen el código ejecutable, los datos, los archivos de configuración y documentación.

La construcción de un sistema implica el ensamblaje de componentes en un sistema.

Las herramientas CASE están disponibles para apoyar todas las actividades de gestión de la configuración.

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.

Gestión de configuraciones

Documents

Transcript of Gestión de configuraciones