Tema 2. Gestión de Configuraciones Software.

1. Introducción
2. Proceso de Gestión de Configuraciones
3. Planificación de la GCS
4. Construcción del sistema
5. CASE para la GCS

1
Tema 2. Gestión de Configuraciones Software

2.1 Introducción.

En cualquier tecnicismo se detecta una necesidad de

“Gestión de la Configuración”.
Todo sistema mínimamente complejo necesita ser
adaptado, mantenido.
A veces se compra el mismo producto muchas veces a
través de departamentos independientes.
Conceptos erróneos populares:
CM agrega cantidades enormes de documentación.
CM sirve para guardar archivos sobre las aplicaciones en
el disco duro.
CM solo se aplica durante el desarrollo.
CM es lo mismo que control de cambios (o control de
versiones).
2

1
Tema 2. Gestión de Configuraciones Software
2.1 Introducción

Definiciones:
CM involucra la recolección y mantenimiento de datos
acerca del hardware y software de los sistemas informáticos
que están usándose [Simon & Dennis].
CM incluye un conjunto de técnicas para ayudar a definir,
comunicar y controlar la evolución de un producto o sistema
a través de su desarrollo, implementación y fases de
mantenimiento [Sweetman].
CM, un concepto importante en la Edad de la Información, es
un conjunto de controles sistemáticos para mantener la
información actualizada y correcta [Morris].
CM identifica en detalle la configuración total actual en
cualquier momento del ciclo de vida del sistema al que se
aplica, junto con cualquier cambio o mejora realizada o en
curso de implementación. Proporciona trazabilidad de
cambios a lo largo del ciclo de vida de cada sistema y de
sistemas asociados o grupos de sistemas. Por tanto, permite
la reconstrucción retrospectiva de un sistema cuando sea
3 necesario [BS 6488].
Tema 2. Gestión de Configuraciones Software

2.1 Introducción

El término configuración denota todas las partes de un sistema

informático: hardware, aplicaciones, SS.OO., desarrollos propios,
manuales o ayuda, comunicaciones, periféricos, etc.

Modelo Espacial de una Configuración

Debería estar basado en estándares:
IEEE 828-1983: ciclo de vida en cascada
En ocasiones visto como parte del proceso de gestión de calidad:
Achieving CMMI Level 2 in the Configuration Management Process
Area Using IBM Rational Software Solutions
4

2
Tema 2. Gestión de Configuraciones Software
2.1 Introducción

El producto final de un sistema de CM efectiva debería tener

conocimiento del estado de todos los componentes en cualquier
momento.
Siempre habrá que actualizar hardware, comprar,
reemplazar, modernizar comunicaciones, añadir
software, actualizarlo, etc, etc.
Sin planificación se pueden cometer muchos errores. La
plantilla de soporte debe poder obtener un ‘snap shot’ de
componentes de la configuración.
− En muchos sistemas los técnicos operan bajo tensión nerviosa causada
por la incapacidad de saber si un cambio funcionará o provocará un
desastre.
La gestión de configuraciones es una actividad de autoprotección.
Como el cambio se puede producir en cualquier
momento, las actividades de CM servirán para:
− Identificar el cambio.
− Controlar el cambio.
− Procedimientos de auditoria
5 − Informes de estado
Tema 2. Gestión de Configuraciones Software

2.2 Proceso de Gestión de Configuraciones

Software
Elementos de configuración software (ECS)
Información creada como parte del proceso de ingeniería del
software:
Programas (código fuente o ejecutables).
Documentos (técnicos o de usuario que describen los
programas).
Datos (contenidos en el programa o externos).
El número de ECS crece rápidamente, y además se puede producir
cambio en cualquier momento.
Cuatro fuentes fundamentales de cambio:
Nuevos requisitos
Nuevas necesidades del cliente
Reorganización del comercio
Restricciones presupuestarias.
CM es una actividad de garantía de calidad, aplicada en todas las
fases del proceso de ingeniería del software.
6

3
Tema 2. Gestión de Configuraciones Software
2.2 Proceso de GCS
ECS
Los ECS objetivo de la CM son:
Especificación del sistema. Manuales de operación e instalación.
Plan de proyecto de software. Programa ejecutable.
Especificación de requisitos SW Descripción de la BD
Manual preliminar de usuario. Manual de usuario final.
Especificación de diseño. Documentos de mantenimiento.
Listados del código fuente. Estándares y procedimientos de
Especificación de las pruebas. ingeniería del software.
Generalmente, también se coloca bajo CM las herramientas de
software.
Un objeto de configuración tiene un nombre, unos atributos y está
conectado a otros objetos mediante relaciones
Modelo
Modelo de
de Datos
Datos
Especificación
Especificación del
del diseño
diseño
Componente
Componente NN
Especificación
Especificación de
de la
la prueba
prueba Especificación
Especificación del
del diseño
diseño
7
Tema 2. Gestión de Configuraciones Software

2.2 Proceso de GCS

Líneas base
Línea base [IEEE 610.12]: especificación o producto
que se ha revisado formalmente y sobre los que se ha
llegado a un acuerdo, y que de ahí en adelante sirve
como base para un desarrollo posterior y que puede
cambiarse solamente a través de procedimientos
formales de control de cambios.
Antes de que algo se convierta en línea base se puede
cambiar fácilmente, después habrá que seguir un
procedimiento y evaluar y verificar cada cambio.
Especificación de sistema
Especificación de requisitos
Especificación de diseño
Código fuente
Planes/procedimientos/datos de pureba
Sistema en funcionamiento
8

4
Tema 2. Gestión de Configuraciones Software
2.2 Proceso de GCS
Líneas base
Línea base = punto de referencia en el desarrollo del software.

Modificada
ECS
Base de datos
Aprobadas del proyecto
Tareas de Revisiones
ECS técnicas ECS
ingeniería del
software formales
Almacenadas
ECS
Extraídas
Controles CM ECS

Tareas de IS producen ECS, una vez aprobado y revisado se

coloca en la base de datos del proyecto (repositorio).
Para hacer una modificación de una línea base se obtiene una
copia (siguiendo la línea punteada).

9
Tema 2. Gestión de Configuraciones Software

2.2 Proceso de GCS

La actividad principal es el control de cambios, pero también tiene

que identificar versiones de software, auditar configuraciones y
generar informes.
Cualquier estudio de CM plantea las preguntas:
¿Cómo identifica y gestiona una organización las versiones
existentes de un programa?
¿Cómo se controlan los cambios antes y después de distribuir
al cliente?
¿Quién tiene la responsabilidad de aprobar y asignar
prioridades a los cambios?
¿Cómo garantizar la realización de los cambios?
¿Cómo avisamos a otros del cambio?
Nos llevan a cinco tareas:
•Identificación •Auditorias de Configuración
•Control de cambios •Generación de Informes
10 •Control de versiones

5
Tema 2. Gestión de Configuraciones Software
2.2 Proceso de GCS
Identificación de objetos
Orientación a objetos: objetos básicos y objetos compuestos.
Objeto básico = unidad de texto.
Objeto compuesto = colección de objetos básicos o
compuestos.
Cada objeto tiene un conjunto de características distintas que le
identifican de forma única:
Nombre (cadena).
Descripción (tipo, id de proyecto, versión y/o cambio).
Recursos (entidades requeridas por el objeto).
Realización (referencia al objeto).
La identificación también debe considerar la relación entre los
objetos identificados.
Puede utilizarse un grafo de dependencias para construir
automáticamente cualquier versión de un sistema.
El esquema de identificación debe tener en cuenta que los objetos
evolucionan.
Grafo de evolución: historia de los cambios de un objeto.
11
Tema 2. Gestión de Configuraciones Software

2.2 Proceso de GCS

Control de cambios
En el proceso de control de cambios:
Existe una autoridad de control de cambios (ACC) (persona
o grupo que toma decisiones).
OCI: orden de cambio de ingeniería. Describe cambio,
restricciones y criterios de revisión y auditoria.
“Alta” y “Baja” de objetos en la base de datos del proyecto
significa crear versiones. Implementan control de acceso y
control de sincronización.
Se puede caer en excesiva burocracia: utilización de varios
niveles de control.
− Hasta que un elemento se convierte en línea base se aplica un
control de cambios informal. El desarrollador puede realizar
cualquier cambio justificado.
− Una vez pasada una revisión técnica formal se crea la línea base:
control de cambios a nivel de proyecto. Para realizar un cambio se
requiere la aprobación del jefe de proyecto (impacto local) o la
ACC (impacto global).
− Cuando el software se distribuye, se establece un control de
12 cambios formal. Se ejecutan todos los pasos del proceso.

6
Tema 2. Gestión de Configuraciones Software
2.2 Proceso de GCS
Control de cambios
Durante el desarrollo de software el cambio incontrolado lleva al
caos. Se reconoce la necesidad del cambio
El usuario suscribe la petición de cambio
El desarrollador la evalúa
Se genera un informe de cambios
ACC decide

La petición queda pendiente de actuación, se genera la OCI

Asignación personalizada de objetos de configuración Información al usuario
Petición de cambio denegada
“Dar de baja” objetos de configuración
Ejecución del cambio
Revisión del cambio (auditoría)
Los elementos de configuración que han cambiado son “dados de alta”
Establecimiento de una línea base para la prueba
Realización de actividades de SQA y de prueba
“Promoción” de los cambios para ser incluidos en la siguiente versión (revisión)
Reconstrucción de la versión adecuada del software
Revisión (auditoría) de los cambios en todos los ECS
Cambios incluidos en la nueva versión
Distribución de la nueva versión
13
Tema 2. Gestión de Configuraciones Software

2.2 Proceso de GCS

Control de Versiones
Especificar configuraciones alternativas del sistema software
mediante la selección de las versiones adecuadas
Identificación de componentes de una versión:
Número de versión
Conjunto de variables lógicas
− language =Java, platform = NT4, date = Jan 1999
Orientada al cambio
− Usada más para sistemas
− Conjunto de cambios aplicados en secuencia
Versión: instancia de un sistema que es funcionalmente distinta de
alguna manera de otras instancias del sistema
Diferencias: Version - Release
Variante: instancia de un sistema que es funcionalmente idéntica
pero no-funcionalmente distinta de otras instancias del sistema
Las variantes, en una determinada versión, se hace
seleccionando componentes en base a una tupla (selección)
de atributos.
14

7
Tema 2. Gestión de Configuraciones Software
2.2 Proceso de GCS
CV: Representación
Grafo de evolución
Cada nodo es una versión (colección de ECS).
Cada versión puede estar compuesta por diferentes
variantes.
1.3 1
1.0 1.2
1.1 2 3
4 5
1.1.1 2.0

Fondo de objetos
Componente = colección Variantes
de objetos en la misma Objeto
versión.

Componentes

15 Versiones
Tema 2. Gestión de Configuraciones Software

2.2 Proceso de GCS

Auditoria de la Configuración
Identificación, control de versiones y cambios ayudan a gestionar el
desarrollo, pero solo llegan hasta que se da la orden de cambio:
Asegurar implementación correcta del cambio: revisiones
técnicas formales y auditorias de configuración software.
Intenta responder a las siguientes preguntas:
¿Se ha realizado el cambio proyectado? ¿Se han realizado
modificaciones adicionales?
¿Se ha revisado el cambio para evaluar su corrección?
¿Se han seguido los estándares de IS?
¿Se han plasmado los cambios en el elemento de
configuración? ¿Se especificó la fecha y autor? ¿Reflejan los
cambios los atributos del objeto?
¿Se han seguido procedimientos de GCS para señalar el
cambio, registrarlo y divulgarlo?
¿Se han actualizado adecuadamente todos los elementos de
configuración relacionados?
Si la CM es formal, ésta auditoria está separada del grupo de
16 garantía de calidad

8
Tema 2. Gestión de Configuraciones Software
2.2 Proceso de GCS
Generación de informes
Responde a las siguientes preguntas:
¿Qué pasó?
¿Quién lo hizo?
¿Cuándo pasó?
¿Qué más se vio afectado?
Para su generación se genera el histórico del proceso de control de
cambios.
Cuando se crea una nueva identificación.
Cuando la ACC aprueba un cambio.
Los informes se almacenan en una base de datos para consulta y
se distribuyen regularmente.
Los informes ayudan a mejorar la comunicación:
Intentos de modificar en paralelo con intenciones diferentes y
conflictivas.
Desarrollos obsoletos.
Conocimiento del estado de los cambios para contrastar con
17 los fallos o efectos secundarios.
Tema 2. Gestión de Configuraciones Software

2. 2 Proceso de GCS
RUP
GESTIÓN DE CONFIGURACION GESTION DEL CAMBIO
Prácticas Identificación Configuracion: Proceso de Solicitud de Cambio
<SYSTEM>[<A>]_[<SUBSYSTEM>] Tabla de Solicitud de Cambio
_[<A>]_[R|A|B]<X>[.<Y>.<Z>][.BL<#>]
Protocolos de Notificación de la
Prácticas Línea Base: Sistema Revisión de Cambio
o Subsistema
Prácticas Almacenamiento
Requisitos de Informes Estado de
Configuración

Repositorios

Workspaces Estructura de Directorios

18

9
Tema 2. Gestión de Configuraciones Software
2.3 Planificación de la GCS

Comienza en fases tempranas del proyecto

Plan de GCS
Define los documentos o clases de documentos a gestionar y
un esquema de nombrado
Identificar y especificar los documentos de mantenimiento
Quien toma la responsabilidad de los procedimientos de
Gestión de Cambios y la creación de líneas base
Define las políticas de Control de Cambios y Gestión de
Versiones
Define los registros de gestión de cambios que tienen que ser
mantenidos
Descripción de las herramientas a utilizar
Definición de la base de datos de configuración

Plan GCS - RUP

19
Tema 2. Gestión de Configuraciones Software

2.4 Contrucción del Sistema

El proceso de compilación y lincage en un sist. Ejecutable

Diferentes sistemas se construyen desde diferentes combinaciones
de componentes
Herramientas automatizadas conducidas por scripts
Problemas:
¿Las intrucciones de construcción incluyen todos los
componentes?
¿Es la versión de componente apropiada?
¿Están todos los ficheros de datos disponibles?
¿Están las referencias a los fich. de datos dentro de los
componentes correcots?
¿Está el sistema siendo construido para la plataforma
correcta?
¿Es la versión apropiada del compilador y del resto de
herramientas?
20

10
Tema 2. Gestión de Configuraciones Software
2.4 Contrucción del Sistema

Representación del Sistema:

Sistemas representados para la construcción
especificando el nombre del fichero: Dependencias
Errores: pérdida de trazabilidad
Lenguaje de modelado de sistemas: representación
lógica más que física

Contructor
Contructorde
de Sistema
Sistemade
de Compiladores
Compiladores Ensambladores
Ensambladores
Sistema
Sistema VM
VM

Versiones
Versionesde
de
Script
Scriptde
de Cod.
Cod.Objeto
Objeto Sistema
Sistema
Cod.
Cod.Fuente
Fuente
Construcción
Construcción Componente
Componente Ejecutable
Ejecutable
Componente
Componente

21
Tema 2. Gestión de Configuraciones Software

2.5 CASE para la GCS

Soporte CASE:
Procesos estandarizados para la CM: procedimientos
predefinidos
Grandes volumenes de datos
Proceso de CM: procedural => modelado e integrado
Caracterísiticas herramientas de CM:
Editor de formularios: formularios de solicitud de cambios
Sistema Workflow: quién hace qué y automatizar la
transferencia de información
BD de Cambios: gestiona propuestas de cambios y enlazada al
sistema de VM
Caracterísiticas herramientas de VM:
Identificación de release y version
Gestión de almacenamiento
Registro del histórico de cambios
Desarrollo independiente
22 SOPORTE A LA EVOLUCIÓN

11
Tema 2. Gestión de Configuraciones Software
2.5 CASE para la GCS

Evaluación y selección de la herramienta:

Se debe crear un grupo de evaluación que:
− Desarrolle un plan de evaluación
− Debe ser pequeño pero representativo
− Debe tener un proceso integral: aseguramiento de calidad,
verificación y validación y prueba
Puede no encontrarse una herramienta que haga todo para
todos. El coste es siempre un factor importante
De vital importancia: grupo de evaluación tenga buen
conocimiento de los entornos organizacional y de proyecto
RUP: Dos herramientas
Rational ClearCase: artefactos de sistema y gestión de
proyectos
Rational ClearQuest: tareas, defectos y solicitudes para
mejoras y herramientas de seguimiento de progreso del
proyecto
23

12