Gestión de la

Configuración y
Gestión de cambio en el
Desarrollo de Software

Exposición dirigida para el curso de Ingeniería de Software, a

cargo del profesor Azabache Asmat, Javier Alejandro

Grupo 1
 Integrantes

• Alagon Vicente, Ronald Aldair

• Caman Gutierrez, Kevin Gabriel
• Navarro Yarleque, Jairo Marcelo
• Quispe Cancho, Diego Alejandro
Contenidos

1/ Introducción
2/ Elementos de configuración
3/ Línea de Referencia
4/Repositorio de GSC
5/ Gestión de la configuración del Software
6/ El depósito de Elementos de la Configuración de Software
7/ El Proceso de GCS
8/ Preguntas planteadas bajo el estudio de la GCS
9/ Identificación de objetos en la Configuración del Software
10/ Control de la versión
11/ Control del cambio
12/ Auditoría de la configuración
13/ Informe de estado
14/ Ejemplo
1/ Introducción (1/3)
● El desarrollo de Software Implica que haya cambios que se tiene que llevar a cabo.
○ Una serie de cambios descontrolados pueden desembocar en un caos que comprometería la calidad del
software.

Gestión de la Configuración del SW (GCS)

● También conocida como Administración de Es una disciplina dentro del campo de la Ingeniería de Software que se
Configuración del Software. ocupa de la identificación, control, seguimiento y gestión de los
● Coordina el desarrollo de SW para minimizar la elementos que componen un sistema de software a lo largo de su ciclo de
confusión entre los miembros del equipo de SW. vida.
● Situaciones que aumentan la confusión:
○ Los cambios no se analizan antes que se realicen
○ No se registran los cambios antes que se CAMBIO
Modificaciones planificadas que se realizan en los
implementen.
○ No se informan a quienes tienen la necesidad de elementos de un sistema, proyecto o proceso.

hacerlo.
○ No se controlan para mejorar la calidad y reducir ¿Hay un ¿Ayudarán a
el error. historial de solucionar el
versiones? problema?
1/ Introducción (2/3)

● La GCS es una actividad sombrilla que se aplica a lo largo de todo el proceso de software.

Objetivos del GCS Contenido

susceptible al
● Identificar los productos de trabajo que puedan cambio : código
fuente, contenido
cambiar. recursos multimedia.
● Definir los mecanismos para administrar distintas
versiones de los productos de trabajo y controlar los
cambios. Sistema de
Gestión de
● Garantizar que el cambio se implementó de manera
Revisiones de Versión, Sistema
adecuada. código, pruebas de Gestión de
● Auditar los cambios e informar a todo el personal de automatizadas. actualizaciones
SW que pueda estar interesado en el cambio.

Auditorías
periódicas,
comunicar el
cambio.
1/ Introducción (3/3)

Construcción de un SW Primera ley de la Ingeniería de Sistemas establece :

“Sin importar en que momento del ciclo de vida del sistema nos
Los cambios son inevitables encontremos, el sistema cambiará y el deseo de cambiarlo persistirá a lo
largo de todo el ciclo de vida”.

Principales fuentes

Nuevas necesidades Nuevos negocios o Reorganización, Restricciones

del cliente condiciones crecimiento, presupuestarias o
comerciales reducción de planificación
2/ Elemento de Configuración(1/1)

● Información que se crea como parte del proceso de Ingeniería de Software

Que se considera un ECS

● Un ECS es todo o parte de un producto de trabajo: ● Código fuente

● Documentación del Sw
○ Una sola sección de una gran especificación, un ● Configuración de la BD
caso de pruebas de un paquete de pruebas. ● Planes de prueba
○ Un documento, un paquete de casos de prueba o ● Archivos binarios , etc

un componente de programa.

Las herramientas de SW son ECS

● Versiones específicas de editores, compiladores ,

navegadores.
● Frameworks de desarrollo de sw y otras
herramientas automatizadas.
3/ Linea de Referencia (1/2)

● “Es una especificación o producto que se revisó formalmente… que sirve como base para un mayor desarrollo y
que solo puede cambiar a través de procedimientos de control formal” IEEE Std.90

ECS a LR
Proceso sistemático y
● Una Línea de Referencia (RF) se marca al entregar colaborativo donde los
uno o más elementos de configuración (EC) miembros del equipo revisan y
aprobadas tras una Revisión Técnica. evalúan un conjunto de
artefactos o documentos.

Ejemplo de los pasos para declarar un modelo de diseño como LR

1. Los elementos de un modelo de diseño se documentaron y

revisaron.
2. Se encontraron y corrigieron errores.
3. Una vez todas las partes del modelo se han revisado,
corregido y aprobado, el modelo de diseño se convierte en
una línea de referencia.
3/ Linea de Referencia (2/2)

Repositorio GCS
Modificado

ECS

Adaptado
Tareas de la Revisiones
Ingeniería ECS ECS
Técnicas Líneas de Referencia:
de Software ● Especificación del SIstema
● Requerimiento de
Software
Almacenado ● Especificación de Diseño
● Código Fuente
ECS ● Planes/ Procedimiento/
Controles GCS
Datos de prueba
● Sistema operativo
Extraido

ECS
4/ Repositorio de GCS(1/2)

● Inicialmente la gestión de los ECS era ineficiente, por que se almacenaban sin soporte informatizado ( Papel o en la
mente de los programadores).

Que problemas generaba esta situación:

● Dificultad para encontrar EC cuando se necesitaba.

● Complejidad en determinar cuales ECs cambiaban, cuándo y por quien
● Describir relaciones detalladas y complejas entre los ítems de
configuración era virtualmente imposible.

Creación del concepto de Repositorio de GCS

● Actualmente, los ECS se mantienen en una base de datos

Rastreo hacia adelante
del proyecto, o en un repositorio GSC.
Rastrear todos los productos de trabajo que resulten
● Que podemos encontrar en el repositorio de GSC:
de una especificación de requisitos determinada.
○ Las versiones del SW.
Rastreo hacia atrás
○ Los requisitos SW (Rastreo de requisitos).
Identificar qué requisito genera algún producto de
○ Información adicional de cuándo por qué y quién realiza
trabajo.
los cambios ( Ensayos de auditoría).
4/ Repositorio de GCS(2/2)

Contenido del Repositorio de GCS

Casos de uso
Modelo de análisis Código fuente
Diagrama basados en Código de objetos
Reglas empresariales escenario Instrucciones de
Funciones empresariales Diagramas orientados a flujo Contenido de construcción del sistema
Estructura de organización Diagrama de comportamiento Construcción
Arquitectura de Información Modelo de diseño
Diagrama arquitectónicos Casos prueba
Diagrama de interfaz Guiones de prueba
Contenido Diagramas de componentes Resultados de prueba
Estimaciones del Proyecto
Empresarial Métrica técnica Métrica de calidad
Calendario del proyecto
Requerimientos ACS Contenido de Contenido V y
Peticiones de modelo V
cambio
Reportes de
cambio Plan de proyecto
Requerimientos SQA Plan ACS / SQA
Reportes de proyecto/ Especificaciones del sistema
reportes de auditoría Especificaciones de requerimientos
Métrica del proyecto Documento de diseño
Contenido de Documentos
Gestión del Plan de y procedimiento de pruebas
Proyecto Documentos de apoyo
Manual de Usuario
5/ Gestión de la Configuración de Software (1/1)

• ECS Elementos de la configuración de

Software : es un documento, un conjunto
completo de casos de prueba o un
componente de un programa dado (p. ej.,
una función de C++).
• Se organizan como objetos de
configuración tienen un nombre, atributo
y está <<conectado>> a otros objetos
mediante relaciones.
 6/ El depósito de Elementos de la
Configuración de Software (1/4)
Un ECS es un conjunto de mecanismos y estructuras de datos que permiten al equipo de software
manejar el cambio en forma eficaz e impulsa las siguientes funciones:

• La integridad de datos
• El compartir información
• La integración de herramientas
• La integración de datos
• El fortalecimiento de la metodología
• Estandarización de los documentos
6/ El depósito de Elementos de la
Configuración de Software (2/4)

• El depósito en cuestión ofrece dos tipos de servicios:

servicios generales y servicios específicos del entorno.
Ambos tipos de servicios están diseñados para integrarse
con las funciones de gestión de procesos y proporcionar una
interfaz con otras herramientas de ingeniería de software.
Además, el depósito es capaz de almacenar datos
sofisticados, como textos, gráficos, video y audio.
6/ El depósito de Elementos de la
Configuración de Software (3/4)

Características de la GCS

• Versiones: Debe ser capaz de guardar todas las versiones y permitir a los desarrolladores regresar a versiones anteriores tanto en pruebas como en
depuración.

• Gestión del seguimiento de la dependencia y del cambio: Gestiona una amplia variedad de relaciones entre entidades y procesos empresariales, entre las
partes de un diseño de aplicación, entre componentes de diseño y otros productos de trabajo, etc.
6/ El depósito de Elementos de la
Configuración de Software (4/4)

• Seguimiento de requisitos: Ofrece la habilidad de seguir todos los componentes y entregables de diseño y construcción que resulten de requisitos.

• Gestión de la configuración: Facilita la conversación del rastro de una serie de configuraciones (hitos).

• Rutas de auditoría: Establece información adicional acerca de cuándo, por qué y por quién se hicieron los cambios.
7/ El Proceso de GCS (1/1)

• Otras responsabilidades es la de la identificación de:

● Es un elemento importante de la garantía de la calidad ■ ECSs individuales y de las distintas versiones del software.
del software. ■ Auditorías de la configuración del software para asegurar que se
● Su responsabilidad principal es la del control de desarrollen adecuadamente.
cambios. ■ Generación de informes sobre todos los cambios realizados en la
configuración.
8/ Preguntas planteadas bajo el estudio de la
GCS (1/1)

• ¿Cómo identifica y gestiona una organización la documentación

de forma que se puedan introducir cambios eficientemente?
• ¿Cómo controla la organización los cambios antes y después de que el software sea distribuido al cliente?
• ¿Quién tiene la responsabilidad de aprobar y de asignar prioridades a los cambios?
• ¿Cómo podemos garantizar que los cambios de han llevado a cabo adecuadamente?
• ¿Qué mecanismo se usa para avisar a otros de los cambios realizados?

Estas cuestiones nos llevan a la definición de cinco tareas de GCS: Identificación,

control de versiones, control de cambios, auditorías de configuración y generación de
informes.
9/ Identificación de objetos en la
Configuración del Software (1/1)

• Para controlar y gestionar los elementos de configuración se tiene

que identificar cada uno de forma única y luego organizarlos
mediante un enfoque orientado a objetos.
• Se pueden identificar dos tipos de objetos:
■ Objetos básicos: Un objeto básico es una “unidad de texto”
creado por un ingeniero de software durante el análisis, diseño o
codificación o pruebas.
■ Objetos compuestos: Un objeto compuesto es una colección de
objetos básicos y de otros objetos compuestos.
10/ Control de la versión (1/4)

El control de versiones es un sistema que registra

cambios realizados en un conjunto de archivos a lo También ayuda a realizar un seguimiento de las modificaciones
largo del tiempo. Su propósito principal es permitir que realizadas, revertir a versiones anteriores si es necesario y
múltiples personas trabajen en un proyecto coordinar el trabajo entre diferentes miembros del equipo.
simultáneamente.
10/ Control de la versión (2/4)

Hay tres tipos principales de control de versiones:

Sistemas de Control de Versiones Local (VCS): En estos sistemas, la base de datos con el historial de
versiones está en la máquina local del usuario. Ejemplos incluyen Git, Mercurial y SVN (Subversion).

Un sistema de control de versiones centralizado (SCV): Es un tipo de sistema de

control de versiones en el que existe un único repositorio central que almacena
todas las versiones de archivos y el historial de cambios.
10/ Control de la versión (3/4)

Hay tres tipos principales de control de versiones:

Sistemas de Control de Versiones Distribuido (DVCS): En estos sistemas, los repositorios (almacenamiento de versiones) están
distribuidos entre los usuarios, lo que permite un trabajo más flexible y descentralizado. Git es uno de los DVCS más populares.
 10/ Control de la versión (4/4)

Grafo de evolución

Un "grafo de evolución" o "grafo de versiones" se refiere a una representación gráfica de cómo un sistema o proyecto ha evolucionado a lo largo del tiempo.

En el grafo de evolución podemos identificar:

• Una representación de las diferentes versiones.
• Cada nodo del grafo es un objeto compuesto.
• Cada versión del software es una colección de ECSs (código fuente, documentos, datos).
• Cada versión puede estar compuesta de diferentes variantes.
11/ Control del cambio (1/4)

Control de Cambios

El control de cambios se erige como un proceso clave dentro de

la gestión de cambios, focalizado en la implementación y
seguimiento meticuloso de las modificaciones autorizadas.
Desde la identificación y evaluación de cambios hasta su
aprobación y posterior control, este enfoque proporciona un
marco sólido para gestionar la evolución del software.
11/ Control del cambio (2/4)

Según James Bach el control de cambio en un contexto

moderno es vital debido a :
• Puede reparar un gran fallo o habilitar excelentes
capacidades nuevas.
• Combina los procedimientos humanos y las
herramientas automáticas para proporcionar un
mecanismo para el control del cambio.

• En el contexto de ITIL, el control de cambios se refiere a un

proceso específico diseñado para gestionar de manera efectiva y
eficiente los cambios en la infraestructura de TI, los servicios y
los sistemas de información.
• El objetivo principal es minimizar los riesgos asociados con los
cambios y garantizar que se implementen de manera controlada
y planificada.
11/ Control del cambio (3/4) Realización del cambio

Revisión de cambio (auditoría)

Alta de elementos de configuración que han

Reconocimiento de la necesidad de cambio cambiado

Solicitud de cambio por parte del usuario Establecimiento de una línea base para la prueba

Evaluación por parte del desarrollador

Realización de actividades de garantía de calidad
Petición pendiente de actuación y generación de la y de prueba
Generación de un informe de cambios
OCI (Orden de Cambio de Ingeniería).
Promoción de los cambios para la siguiente
Decisión de la autoridad de control de cambios Asignación personalizada a los objetos de versión
configuración
Reconstrucción de la versión adecuada del
Dado de baja de objetos de configuración software

Revisión (auditoría) de los cambios en todos los

elementos de configuración

Inclusión de cambios en la nueva versión

Petición de cambio denegada Distribución de la nueva versión

Información del usuario

Pressman Roger, Ingeniería de Software, VI Edición.

11/ Control del cambio (4/4)

Proceso de Gestion de cambios

ITIL Gestión de Servicios de TI

12/ Auditoria de la configuración (1/2)

• La Auditoría de Configuración se presenta como

un escrutinio minucioso que responde a una serie
de preguntas fundamentales. Desde la
verificación de la correcta implementación de
cambios especificados en la Orden de Cambio de
Ingeniería (OCI) hasta la evaluación de la
adopción de estándares de ingeniería del
software, cada aspecto se examina de manera
detallada.
12/ Auditoria de la configuración (2/2)
• ¿Se ha hecho el cambio especificado en la OCI?
• ¿Se han incorporado modificaciones adicionales?
• ¿Se ha llevado a cabo una revisión técnica formal para evaluar la
corrección técnica?
• ¿Se ha seguido el proceso del software y se han aplicado
adecuadamente los estándares de ingeniería del software?
• ¿Se han resaltado los cambios en el ECS?
• ¿Se han especificado la fecha del cambio y el autor?
• ¿Reflejan los cambios los atributos del objeto de Configuración?
• ¿Se han seguido procedimientos de GCS para señalar el cambio,
registrarlo y divulgarlo?
• ¿Se han actualizado adecuadamente todos los ECSs relacionados?
13/ Informe de estado (1/2)

La elaboración de informes de estado de la

configuración, a veces conocida como contabilidad de
estado, constituye una tarea esencial dentro de la
Gestión de Configuración del Software (GCS). Este
proceso responde de manera efectiva a preguntas
cruciales que guían el control y la comprensión del
estado actual de la configuración.

Este informe de estado se erige como una herramienta

valiosa para la toma de decisiones informadas, la
resolución de problemas y la comprensión completa de la
configuración del sistema. Proporciona una visión clara y
concisa de la evolución de la configuración, asegurando
una gestión efectiva y un control preciso de los cambios
implementados.
13/ Informe de estado (2/2)
• ¿Qué sucedió?
Describe de manera detallada los cambios y eventos relevantes que han
ocurrido en la configuración.
• ¿Quién lo hizo?
Identifica de manera clara y precisa a las personas o entidades
responsables de los cambios o acciones registradas en la configuración.
• ¿Cuándo ocurrió?
Establece las fechas y los momentos precisos en que se llevaron a cabo
los cambios, proporcionando un marco temporal para comprender la
evolución de la configuración.
• ¿Qué más se vio afectado?
Analiza de manera integral el impacto de los cambios, identificando
otros elementos o áreas que se vieron afectadas directa o
indirectamente.
14/ Ejemplo

En un proyecto de desarrollo de software, se identificó la necesidad de integrar un sistema de autenticación biométrica para mejorar
la seguridad del sistema. Después de recibir la solicitud del equipo de seguridad, se evaluaron los impactos técnicos y financieros,
determinando que la implementación de esta característica no sólo fortalecería la seguridad, sino que también mejoraría la
experiencia del usuario. Tras la aprobación del comité de cambios y del cliente, se procedió con la implementación del sistema
biométrico. Este cambio pasó por rigurosas pruebas unitarias e integradas antes de ser desplegado en el entorno de producción. Tras
su implementación, se validó con éxito y se actualizó la documentación del sistema. La gestión del cambio se cerró con un informe
detallado y una reunión para discutir lecciones aprendidas y posibles mejoras en los procesos futuros.
Gracias