Tema 1.

Gestión de Configuraciones
Software

1. Introducción
2. Conceptos Básicos
3. Proceso de Gestión de
Configuraciones
4. CASE para la GCS
5. Conclusiones

Escuela Superior Ingeniería Informática  Ingeniería del Software II

OBJETIVOS
 Comprender la importancia de la Gestión de Configuración
(GCS, CM – Configuration Management)

 Comprender las actividades clave de la Gestión de

Configuración

 Comprender el porqué de la integración del Control de

Cambios y del Control de Versiones

 Comprender la diferencia entre el Control de Cambios y el

Control de Versiones

 Discutir el uso de herramientas CASE para soporte de la GC

2 Escuela Superior Ingeniería Informática  Ingeniería del Software II  Tema 1. Gestión de Configuración Software
1.1 Introducción
 Escenarios:

 Actualización simultánea

 Notificaciones limitadas

 Múltiples versiones

3 Escuela Superior Ingeniería Informática  Ingeniería del Software II  Tema 1. Gestión de Configuración Software
Def. CONFIGURACIÓN (ISO/IEC/IEEE 24765-2010)

1. Las características de un sistema informático o componente

informático que incluyen su cantidad, naturaleza e interconexión de
las partes de las que está compuesto.
2. La disposición de un sistema o red definidos por su naturaleza,
cantidad y principales características de sus unidades funcionales.
3. Los requisitos, diseños e implementaciones que definen una versión
particular de un sistema o un componente del mismo.
4. La manera en que el hardware y software de un Sistema de
procesamiento de la información se organiza e interconecta.

En el contexto de la gestión de la configuración, nos referimos al

conjunto de las características funcionales y físicas tanto software
como hardware especificadas en la documentación técnica o
alcanzadas por un producto.

4 Escuela Superior Ingeniería Informática  Ingeniería del Software II  Tema 1. Gestión de Configuración Software
1.1 Introducción
 Gestión de la Configuración (Configuration Management)
ISO/IEC/ IEEE 24765-2010:
 Disciplina que aplica dirección y vigilancia administrativa para:
 Identificar y documentar las características físicas y funcionales de un
elemento de configuración software
 Controlar los cambios a dichas características
 Registrar e informar sobre el procesamiento de los cambios y del
estado de la implementación
 Verificar la conformidad con los requisitos especificados
 Actividades técnicas y organizacionales que comprenden
identificación de la configuración, control, registro de estado y
auditoría

5 Escuela Superior Ingeniería Informática  Ingeniería del Software II  Tema 1. Gestión de Configuración Software
1.1 Introducción
 Por qué:
 La naturaleza de:
 Productos software: diferentes componentes con múltiples
versiones y ejecutándose sobre diferentes plataformas hardware y
software
 Proyectos software: todo es susceptible al cambio
 Equipos de desarrollo: entornos distribuidos de desarrollo
 Elevada complejidad de los sistemas software
 Elevada demanda de software
 Ley de Musa: 900% de aumento de la demanda por década
 Ley de Boehm: 200% de aumento de los costes por década
 … pero sólo tenemos un 35% de aumento de la productividad
 Naturaleza cambiante del software:
 Ley de Lehman del cambio continuo: cualquier sistema software
sufrirá continuamente cambios porque el uso del sistema sugerirá
funcionalidad adicional
6 Escuela Superior Ingeniería Informática  Ingeniería del Software II  Tema 1. Gestión de Configuración Software
1.1 Introducción
 Cómo puede ayudarnos la Gestión de la Configuración:
 A gestionar un sistema bien, ya que hemos de saber cómo está
construido.

 A saber qué tenemos después de un cambio, pues tenemos que

saber qué teníamos antes del cambio.

 Para encontrar y resolver un problema tenemos que saber en

detalle qué configuración era.

 Es finalmente, una actividad de Garantía de Calidad aplicado

desde el inicio al mantenimiento.

7 Escuela Superior Ingeniería Informática  Ingeniería del Software II  Unit 1. Software Configuration Management
1.2 GCS: Conceptos Básicos
 Elemento de Configuración (EC, Configuration Item) [IEEE24765]: un
conjunto HW, SW o ambos que es identificado por la GC (CM) y tratado
como una entidad individual en el proceso de GC
 ECs considerados en la GCS son:
Plan de proyecto de software.
Especificación del sistema Manuales de operación e instalación.
Especificación de requisitos SW Programa ejecutable.
Especificación de diseño Descripción de la BD
Listados del código fuente Manual de usuario
Especificación de las pruebas Documentos de mantenimiento.
Sistema Operativo Estándares y procedimientos de IS

 Generalmente, también se sitúa bajo GCS las herramientas, ¿Por qué?

 Un EC tiene un nombre, unos atributos y está conectado a otros
objetos mediante relaciones
Especificación del diseño Modelo de Datos
(Diseño de datos, diseño de módulos, diseño de interfaces, etc.)
Componente N
Especificación de la prueba Código fuente

8 Escuela Superior Ingeniería Informática  Ingeniería del Software II  Tema 1. Gestión de Configuración Software
 “Producing software from a
specification is like walking
1.2 GCS: Conceptos Básicos on water - it's easier if it's
frozen.”
 Configuración [IEEE24765]: - Barry Boehm -
 El conjunto de las características funcionales y físicas tanto software como
hardware especificadas en la documentación técnica o alcanzadas por un
producto.
 Configuración de Referencia (Baseline / línea base):
 Especificación o producto que se ha revisado formalmente y sobre el 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.

 Objetivo:
 reducir la vulnerabilidad de un proyecto frente a cambios no controlados
fijando y controlando formalmente el cambio de diferentes EC clave en los
puntos críticos del ciclo de vida de desarrollo

 identificar el conjunto de componentes software y hardware que componen

una versión específica de un sistema
9 Escuela Superior Ingeniería Informática  Ingeniería del Software II  Tema 1. Gestión de Configuración Software
1.2 GCS: Conceptos Básicos
 Configuración de Referencia:
 Usualmente establecida al final de una fase del ciclo de vida, ¿por qué?

System specification
Requirements specification Requirements Baseline
Design specification Design Baseline
Source code
Acceptance Test Product Baseline
Deployed system Operational Baseline

 “Poner como referencia" acto de colocar un EC aprobado bajo control de

cambios formal

 EC de referencia: versión de ECs formalmente aprobado, independientemente

del medio, formalmente diseñado y fijado en un momento específico durante el
ciclo de vida del EC

10 Escuela Superior Ingeniería Informática  Ingeniería del Software II  Tema 1. Gestión de Configuración Software
1.2 GCS: Conceptos Básicos
 Repositorio del proyecto: registra toda la información relevante
relacionada con la configuración:
 información de los EC y sus relaciones de dependencia,
 información de las solicitudes de cambio y de su estado,
 información sobre los procesos de revisión y auditoría
Modificada
EC
Repositorio
Creada Aprobada del proyecto
Revisiones
Tareas de EC técnicas EC Commit
ingeniería del formales
software Almacenada
EC
Extraída
Controles GCS EC Check-out

 Las Tareas de IS producen EC. Una vez aprobado y revisado se coloca en

la base de datos del proyecto (repositorio).
 Para hacer una modificación de un EC se obtiene una copia (siguiendo la
línea punteada).
11 Escuela Superior Ingeniería Informática  Ingeniería del Software II  Tema 1. Gestión de Configuración Software
1.2 GCS: Conceptos Básicos
 Versión:
 Un producto software operativo que difiere de productos similares
en términos de capacidad, requisitos ambientales y configuración
 Una instancia identificable de un fichero específico o distribución
de un Sistema completo
 Cada cambio sufrido por un EC produce una nueva versión del mismo
 Identificación:
 Número de versión
 Conjunto de variables lógicas: language =C#, platform = W10, date = October
2015
 Orientada al cambio: Conjunto de cambios aplicados en secuencia

 Release (lanzamiento/distribución):
 Una versión entregada de una aplicación que puede incluir todo o
parte de una aplicación
 Una versión software que se distribuye a una comunidad más amplia
 ¿número de versiones > número de releases?
12 Escuela Superior Ingeniería Informática  Ingeniería del Software II  Tema 1. Gestión de Configuración Software
1.3 Proceso de GCS
Cualquier estudio de GCS
plantea las preguntas: Tareas de la GCS
 ¿Cómo identifica y gestiona  Identificación
una organización las versiones  Control de Versiones
existentes de un programa?
 Control de Cambios
 ¿Cómo se controlan los
 Generación de Informes
cambios antes y después de
distribuir al cliente?  Auditorías de Configuración
 ¿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?

13 Escuela Superior Ingeniería Informática  Ingeniería del Software II  Tema 1. Gestión de Configuración Software
1.3 Proceso de GCS: Identificación
 Es un prerrequisito para el resto de actividades de la GCS

 La Identificación implica tres tareas:

 Selección: Identifica los EC que serán controlados
 Designación: Establece su esquema de nombrado y/o numerado de
los EC sujetos al proceso de GCS
 Descripción: documentar las características de cada EC

 Selección:
 No todo EC debe estar bajo GCS:
 Demasiados: gasto administrativo, tiempo y coste de desarrollo
incrementado
 Pocos: dificultad en gestionar los cambios así como pérdida de visibilidad
 Determinar Criterios de Selección: criticidad, reutilización,
interacción con otros EC, EC complejo, utilizado por diferentes
grupos, etc.
14 Escuela Superior Ingeniería Informática  Ingeniería del Software II  Tema 1. Gestión de Configuración Software
1.3 Proceso de GCS: Identificación
 Selección:
 Seleccionar los EC y determinar las relaciones entre ellos
 EC básico: ej. unidad de texto.
 EC compuesto: colección de EC básicos o compuestos
 Establecer relaciones jerárquicas y de dependencia entre ECs:

Sistema «trace» «trace»

Use-Case Realization
Use Case Use-Case Realization
- Design
- Analysis
Sub-Sistema Sub-Sistema
«trace»
«trace»
EC compuesto White-box test

X
Black-box test
Test Case
EC EC

15 Escuela Superior Ingeniería Informática  Ingeniería del Software II  Tema 1. Gestión de Configuración Software
1.3 Proceso de GCS: Identificación
 Designación
 Determinar esquema de nombrado y/o numerado para
identificar cada EC de forma única:
 Debe permitir el almacenamiento, la recuperación, el seguimiento y la
distribución
 Método de identificación: puede incluir convenciones de nombre,
número de versión y letras, así como el nombre del proyecto o
sistema, su posición dentro de la jerarquía y el tipo de EC
 Ejemplo: ICUP_AltaU_REQ_UC7_1.0
 Otros Atributos
 Nombre (cadena)
 Descripción (tipo, id de proyecto, versión y/o cambio)
 Recursos (entidades requeridas por el objeto)
 Realización (referencia al objeto)
 Debe considerar la relación entre los objetos identificados:
 Grafo de dependencias construcción automática del sistema
 Debe tener en cuenta que los EC cambian:
 Grafo de evolución: historia de los cambios de un objeto
16 Escuela Superior Ingeniería Informática  Ingeniería del Software II  Tema 1. Gestión de Configuración Software
1.3 Proceso de GCS: Control de Versiones
 Procedimientos y herramientas para gestionar las diferentes versiones del EC
que se crean durante el proceso de desarrollo
 Establecimiento y mantenimiento de la versión de referencia e identificación y
control de los cambios a la versión de referencia que hacen posible retornar
a una versión de referencia previa
Modificada
EC
Repositorio
Creada Aprobada del proyecto
Revisiones
Tareas de EC técnicas EC Commit
ingeniería del formales
software Almacenadas
EC
Extraída
Controles GCS EC Check-out

 Mecanismos a implementar en el repositorio:

 Control de acceso

 Control de sincronización

17 Escuela Superior Ingeniería Informática  Ingeniería del Software II  Tema 1. Gestión de Configuración Software
1.3 Proceso de GCS: Control de Versiones
 Control de sincronización:
 ¿Qué ocurre con la actualización simultánea? Ingeniero 1 e
Ingeniero 2 quieren usar/modificar req.txt
 Alternativa 1: Bloquear/liberar/robar

Req.
txt
Ingeniero 1 Internet

Servidor

Ingeniero 2
18 Escuela Superior Ingeniería Informática  Ingeniería del Software II  Tema 1. Gestión de Configuración Software
1.3 Proceso de GCS: Control de Versiones
 Control de sincronización:
 ¿Qué ocurre con la actualización simultánea? Ingeniero 1 e
Ingeniero 2 quieren usar/modificar req.txt
 Alternativa 2: Resolución de conflictos

Req.
txt
v1.0 Req.
txt
v1.0
v2.0
Ingeniero 1 Internet

Req.
Servidor
txt 1. Ingeniero 1 y 2 consiguen copia local de Req.txt
v1.0 2. Ingeniero 1 sube una versión modificada
3. Ingeniero 2 quiere subir su versión pero su versión local
Ingeniero 2 no coincide con la última versión en el servidor:
CONFLICTO: Resolver las diferencias
19 Escuela Superior Ingeniería Informática  Ingeniería del Software II  Tema 1. Gestión de Configuración Software
1.3 Proceso de GCS: Control de Versiones
 Características a ser soportadas por el repositorio:
 Versiones de ECs
 Versiones de producto o sistema:
<<Standard EXE>> OrderSystem
<<Standard EXE>> <<Standard EXE>>
OrderSystem V3.2 OrderSystem OrderSystem
V1.8 <<Standard EXE>> V1.8 V1.2
OrderSystem
V3.0

<<COM>>
<<COM>> VB
DAO OrderSystem
V1.7
<<COM>>
ComctlLib<<COM>>
ComctlLib
v1.0
<<COM>> V1.1
VBA <<COM>>
MSComDlg
<<COM>>
MSComDlg
V1.5
<<COM>> V1.0 <<COM>>
VBRUN OrderSystem
<<imports>> MSComDlg
V1.5 V1.2
<<COM>>
stdole Problema: Diferentes versiones del sistema se construyen desde
diferentes combinaciones de versiones de los componentes
20 Escuela Superior Ingeniería Informática  Ingeniería del Software II  Tema 1. Gestión de Configuración Software
1.3 Proceso de GCS: Control de Versiones
 Implementación del repositorio:
 Versiones de ECs
 Versiones de producto o sistema:
 Grafo de evolución
 Cada nodo es una versión de producto (colección de EC)

Facilitar la creación de Versiones Alternativas

 Cada rama (branch) es una desviación de la línea principal del desarrollo.

Facilitar la Construcción del Sistema

Branch

Facilitar el desarrollo en paralelo

1.1.2

1.0 1.1 1.2 1.3 Main Development Line

1.1.1.1 Branch
Branch 1.1.1
1.1.1.2
 Numeración de ramas:
 El número de versión de las líneas principales del desarrollo tiene sólo dos partes:
número mayor y menor (1.1, 1.2, etc.)
 El número de versión de las ramas tiene cuatro partes: las dos primeras
representan el punto principal en el que la rama nace y la tercera y cuarta
la rama y subramas (i.e., 1.1.1, 1.1.1.2, etc.)
 Bifurcación y Combinación (Branching y Merging ): necesarios en el
Sistema de Control de Versiones
21 Escuela Superior Ingeniería Informática  Ingeniería del Software II  Tema 1. Gestión de Configuración Software
1.3 Proceso de GCS: Control de Versiones
 Implementación del repositorio:
 Versiones de ECs
 Versiones de producto o sistema:
 Deltas: la diferencia en la versión previa y la nueva
 En lugar de guardar copias de todas las versiones en el repositorio, creamos
Deltas: reducimos la cantidad de espacio en disco duro

Delta hacia adelante

Delta hacia atrás

22 Escuela Superior Ingeniería Informática  Ingeniería del Software II  Tema 1. Gestión de Configuración Software
1.3 Proceso de GCS: Control de Versiones
 Construcción del Sistema:
 Construcción (build): versión operacional de un sistema que
incorpora un subconjunto de las capacidades que el producto final
proporcionará
 Actividad de Construcción del Sistema:
 Combinar las versiones correctas de los ECs, usando los datos de
configuración apropiados, en un programa ejecutable (compilación y
unión (linkage) )
 Actividad reiterada a lo largo del ciclo de vida para entregar aquella
construcción requerida por clientes, desarrolladores, testers, etc.
 Características exigibles:
 Repetible
 Reproducible
 Automatización:
 Herramientas automatizadas dirigidas por scripts (makefile)
 Herramientas de soporte y scripts bajo Gestión de Configuración
23 Escuela Superior Ingeniería Informática  Ingeniería del Software II  Tema 1. Gestión de Configuración Software
1.3 Proceso de GCS: Control de Cambios
 Identificar, documentar, aprobar o rechazar, y controlar los cambios a las versiones
de referencia del proyecto
 Tiene que ser realizado siempre que alguien haga una solicitud sobre una versión de referencia
 Conceptos:
 Solicitud de Cambio (Change request, CR): Petición realizada por un desarrollador,
miembro del equipo de Gestión de Calidad, un revisor, un usuario o un cliente y que debe
ser documentada:

Motivos:
• Mejoras en el diseño
• Defectos encontrados
• Cambios en la funcionalidad,
etc.

Otros nombres:
• Ticket
• Issue
• Work Item (Elemento de
Trabajo)

24 Escuela Superior Ingeniería Informática  Ingeniería del Software II  Tema 1. Gestión de Configuración Software
1.3 Proceso de GCS: Control de Cambios
 Integración Control de Cambios y Control de versiones:
 ¿Cuándo? En la implementación del cambio
 “Commit” y “Check-out” de ECs: Crear versiones de los EC
 ¿Por qué?

Modificada
EC
Repositorio
Creada Aprobadas del proyecto
Revisiones
Tareas de EC técnicas EC Commit
ingeniería del formales
software Almacenadas
EC
Extraídas
Controles GCS EC Check-out

25 Escuela Superior Ingeniería Informática  Ingeniería del Software II  Tema 1. Gestión de Configuración Software
1.3 Proceso de GCS: Control de Cambios
 Conceptos:
 Proceso de Control de Cambios: acciones realizadas para
identificar, documentar, revisar y autorizar cambios a un
software o documentación de producto en desarrollo
 Autoridad de Control de Cambios (ACC, Change Control
Board (CCB) ): persona o grupo de personas que toma las
decisiones
 Niveles de Control de Cambio: evitar excesiva burocracia
 Control de cambios informal: Hasta que un elemento es de
referencia el desarrollador puede realizar cualquier cambio justificado.
 Control de cambios a nivel de proyecto: Una vez pasada una
revisión técnica formal se crea la versión de refencia. Para realizar un
cambio se requiere la aprobación del jefe de proyecto (impacto local)
o la ACC (impacto global).
 Control de cambios formal: Cuando el software se distribuye. Se
ejecutan todos los pasos del proceso.

26 Escuela Superior Ingeniería Informática  Ingeniería del Software II  Tema 1. Gestión de Configuración Software
1.3 Proceso de GCS: Control de Cambios
 Proceso de Control de Cambios (CC) (ejemplo)
1. Iniciación del cambio:
 Se emite la Solicitud de Cambio cumplimentando el formulario de CR
2. Clasificación del cambio: determinar tipo de CR (change request)
 Gestor de Gestión de Configuración (GGC) evalúa la CR de acuerdo a su
severidad, importancia, impacto, coste, etc.
3. Evaluación o análisis del cambio:
 GGC determina el alcance del cambio: impacto en el producto, qué
cambios se deben hace y sobre qué ECs.
4. Disposición al cambio:
 Determinar si el cambio se llevará a cabo o no (generalmente, la ACC):
 Rechazada: informe al emisor de la CR explicando el porqué.
 Aprobada: enviada al equipo de desarrollo
5. Implementación del cambio:
 El equipo de desarrollo realiza el cambio y ejecuta las pruebas necesarias
6. Verificación del Cambio:
 Comprobar la corrección del cambio y registrar el cambio realizado
7. Control del Cambios de la Versión de Referencia
 La ACC determina si se crea una nueva release o se espera a tener cambios
adicionales.
27 Escuela Superior Ingeniería Informática  Ingeniería del Software II  Tema 1. Gestión de Configuración Software
C. Versiones + C. Cambios =
TRAZABILIDAD DEL FALLO

1. ¿Cómo se consigue con

Azure Devops?
2. ¿Qué beneficios tiene?

Escuela Superior Ingeniería Informática  Ingeniería del Software II 

1.3 Proceso de GCS: Generación Informes
 Objetivo: mantener a los involucrados en el proceso de desarrollo informados del
estado de la configuración y de su evolución
 Beneficios:
 Identificar problemas, localizar la fuente del problema y tomar acciones correctoras
 Determinar el progreso del proyecto
 Determinar el porqué durante el mantenimiento

 Registrar y comunicar la información necesaria para gestionar efectivamente los

ECs, incluyendo:
 Registro de documentación de configuración aprobada y números de identificación,
 El estado de los cambios propuestos,
 El estado de implementación de los cambios aprobados,
 El estado de las CR pendientes de aprobar, etc.

 Actividades:
 Definir los tipos de Informes de Estado de la Configuración (IEC) a generar
 Generar los IEC empleando el histórico del proceso de control de cambios
 Almacenar los IEC en el repositorio del proyecto
 Distribuir regularmente los IEC

29 Escuela Superior Ingeniería Informática  Ingeniería del Software II  Tema 1. Gestión de Configuración Software
1.3 Proceso de GCS: Generación Informes
 Requisitos de los Informes del Estado de la Configuración
 Frecuencia: Diario, semanal, mensual, por iteración, por fase, al final del
proyecto
 Categoría:
 Estado

 ¿Qué preguntas responde?

30 Escuela Superior Ingeniería Informática  Ingeniería del Software II  Tema 1. Gestión de Configuración Software
1.3 Proceso de GCS: Generación Informes
 Requisitos de los Informes del Estado de la Configuración
 Frecuencia: Diario, semanal, mensual, por iteración, por fase, al final del
proyecto
 Categoría:
 Tendencia

 ¿Qué preguntas responde?

31 Escuela Superior Ingeniería Informática  Ingeniería del Software II  Tema 1. Gestión de Configuración Software
1.3 Proceso de GCS: Generación Informes
 Actualmente la generación de informes puede ser realizada de
manera automática usando los paneles de control de las
herramientas:

32 Escuela Superior Ingeniería Informática  Ingeniería del Software II  Tema 1. Gestión de Configuración Software
1.3 Proceso de GCS: Auditoría
 Identificación, control de versiones y cambios ayudan a gestionar el
desarrollo, pero no aseguran la implementación correcta de los
cambios:
 Solución: Auditorías 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?

33 Escuela Superior Ingeniería Informática  Ingeniería del Software II  Tema 1. Gestión de Configuración Software
1.3 Proceso de GCS: Auditoría
 Tipos de Auditorías:
 Auditorías funcionales: determinar si el producto satisface los requisitos objetivo de la
versión de referencia
 ¿Cómo?

 Auditorías físicas: determinar si la versión de referencia del build (versión

operacional) es desplegable utilizando el repositorio
 ¿Cómo?

 Entradas a utilizar:
 Listado de Requisitos de la versión de  Instrucciones de construcción y herramientas
referencia  Información de configuración, estado y
 Resultados de las pruebas programación
 ECs y dispositivos hardware  Documentación de configuración
 Cuándo:
 Auditorias reiteradas después de la integración y el testeo del Software antes de
establecer la versión de referencia del producto
 Quién:
 Representante/s de gestión, de QA, el cliente, agencia externa
 Resultado: Informe de Hallazgos de la Auditoría de Configuración

34 Escuela Superior Ingeniería Informática  Ingeniería del Software II  Tema 1. Gestión de Configuración Software
1.3 Proceso de GCS: Auditoría
 Si nuestro proceso de GCS es formal, las Auditorías las realiza
un equipo independiente: Equipo de Garantía de Calidad

 Alternativas a las auditorías de configuración:

 Alfa testing: cuando el sistema tiene muchas funciones nuevas que
no se han probado previamente, el equipo de desarrollo busca
evaluar el éxito o el fracaso de las nuevas funciones.
 Beta testing: el equipo de desarrollo decide que se necesita algún
nivel de evaluación del cliente antes del lanzamiento final del
producto. El equipo de desarrollo busca (una gran cantidad de)
probadores beta para descubrir errores y fallos en el sistema.
 Test Readiness Reviews (TRR): para evaluar los resultados
preliminares de las pruebas para uno o más ECs.
 Market Readiness Reviews (MRR): la distribución está lista

35 Escuela Superior Ingeniería Informática  Ingeniería del Software II  Tema 1. Gestión de Configuración Software
1.4 Herramientas CASE para la GCS
 ¿Qué características debería soportar una  ¿Qué características soporta Azure
herramienta de GCS? DevOps?
 Gestión de versiones:
 versión del producto
 Gestión del cambio:
 automatizar los procedimientos de control
de cambios (flujos de trabajo)
 Seguimiento Problema:
 ¿Cómo y cuándo se arregló un
problema?¿cuánto tiempo llevó?, etc.
 Notificación al personal involucrado de
acuerdo a criterios como la gravedad o
impacto
 Gestión de promociones:
 Captura de información y creación de
caminos para saber lo que pasó o para
recrear un evento o un producto antes o
después de un evento en particular
 Construcción del Sistema
 Generación de Informes
 Auditorías de configuración
 Acceso y seguridad
 Personalización
 Acceso web

36 Escuela Superior Ingeniería Informática  Ingeniería del Software II  Tema 1. Gestión de Configuración Software
1.4 Conclusiones
 Beneficios:  ¿Qué actividades de GCS?
 Mejor servicio al cliente
 Se ofrece al cliente aquello que realmente
solicita
 Productividad del desarrollo mejorada
 Evita esfuerzos duplicados
 Seguridad mejorada
 Evita cambios no permitidos controlando
quién hizo qué
 Reducción de defectos
 Control de cada uno de los defectos
informados evitando que queden sin
tratar y que su realización sea de forma
adecuada
 Identificación y resolución de defectos
más rápida
 ¿Cómo hice eso?
 Asegura que el sistema correcto ha
sido construido
 Utilizamos las versiones correctas de
cada EC y de acuerdo a las
especificaciones
 Mayor reutilización del software

37 Escuela Superior Ingeniería Informática  Ingeniería del Software II  Tema 1. Gestión de Configuración Software
Referencias
 [IEEE24765] ISO/IEC/IEEE 24765-2010 Systems and software engineering
— Vocabulary
 ALEXIS LEON, Software Configuration Management Handbook, Second
Edition, Artech House, 2005
 JEZ HUMBLE AND DAVID FARLEY, Continuous Delivery: Reliable
Software Releases through Build, Test, and Deployment Automation,Wiley,
2012

38 Escuela Superior Ingeniería Informática  Ingeniería del Software II  Tema 1. Gestión de Configuración Software