UNIDAD 1

GESTIÓN DE CONFIGURACIÓN DEL

SOFTWARE (GCS)
Ingenieria de software II
Ing. Silvia Eugenia Colque Nieves
Contenido:
1. Introducción. 3. El Proceso de gestión de configuración del
software
2. Gestión de configuración del software.
3.1 Identificación de objetos en la
2.1 Un escenario de Gestión de Configuración configuración del software
del Software
3.2 Control de Versiones.
2.2 Elementos de un sistema de administración
de la configuración 3.3 Control de Cambios.

2.3 Ítem de configuración 3.4 Auditoría de la Configuración.

2.4 Líneas de Referencia o Línea Base 3.5 Informe de estado.

2.5 El Repositorio 4. Plan de Gestión de Configuración del software

1. INTRODUCCION

Cuando se construye software de computadoras, el cambio

es inevitable.

El desarrollo del software implica que haya cambios que se

tienen que llevar a cabo.

El cambio aumenta el nivel de confusión cuando los

miembros de un equipo de software trabajan en un
proyecto.
1. Introducción

Situaciones que fomentan la confusión:

• Los cambios no se analizan antes de que se realicen.

• No se registran antes de que se implanten.

• No se reportan o informan a quienes tienen necesidad de conocerlos.

• No se controlan para mejorar la calidad y reducir el error.

Una serie de cambios descontrolados pueden convertirse en un caos

comprometiendo la calidad del SW
1. Introducción
La Primera ley de la Ingenieria de Sistemas indica:

“Sin importar donde se esté en el ciclo de vida del sistema, el sistema cambiará, y el deseo
por cambiar permanecerá a lo largo del ciclo de vida”

Origen de los cambios:

• Nuevas condiciones empresariales o de mercado que cambien los requisitos del producto o las reglas
empresariales.

• Modificación de los datos a producir, funcionalidad ofrecida o servicios ofrecidos por los sistemas
basados en computadoras.

• La reorganización o crecimiento/reducción de la empresa, produce cambios en las prioridades

proyectadas o en la estructura del equipo de ingeniería de software.

• Restricciones presupuestarias o de calendario causan una redefinición del sistema o del producto.
 2. GESTION DE CONFIGURACION DE SOFTWARE
(GCS)

También es conocida como Administración de la Configuración del

Software (ACS)

“El Arte de coordinar el desarrollo de software para minimizar la confusión,

se llama administración de la configuración, que es el arte de identificar,
organizar y controlar las modificaciones que se hacen al software que
construirá un equipo de programación.
La meta es maximizar la productividad al minimizar los errores”

La GCS puede verse como una actividad que garantiza la calidad del
software.
2. Gestión de Configuración del Software (GCS)

Es una actividad sombrilla que se aplica a lo largo del proceso de software.

Y su objetivo es:

• Identificar los productos de trabajo que pueden cambiar

• Definir mecanismos para administrar distintas versiones de los productos de trabajo y controlar
los cambios.

• Garantizar que el cambio se implementó de manera adecuada.

• Auditar los cambios e informar a todo el personal que pueda estar interesado en cada cambio.
2. Gestión de Configuración del Software (GCS)

Por tanto los elementos que componen toda la información producida

como parte del proceso de ingeniera de software se denominan
colectivamente “configuración del software”

Dado que la configuración del software es la única representación tangible

de un programa o sistema software, debe ser controlada para conservar su
exactitud, mantener la información actualizada y asegurar una información
clara y concisa.
2.1 Un escenario de Gestión de Configuración del
Software
Por ejemplo visualicemos un escenario de administración del
cambio (AC), típicamente involucra:

• Un gerente de proyecto; que esta a cargo de un grupo de

software

• Un gerente de configuración; responsable de los

procedimientos y políticas de AC.

• Los ingenieros de software; encargados de desarrollar y

mantener el producto software.

• El cliente; que usa el producto.

2.1 Un escenario de Gestión de Configuración del
Software
En el nivel operativo del desarrollo de un proyecto software, el escenario involucra varios roles y
tareas.

• Para el gerente del proyecto, la meta es garantizar que el producto se desarrolla dentro de
cierto marco temporal.

• Las metas del gerente de configuración son garantizar que se sigan los procedimientos y
políticas para crear, cambiar y probar el código, asi como hacer accesible la información acerca
del proyecto.

• Realizar peticiones de cambio

• Evaluar (mediante un consejo de control de cambios que sea responsable de aprobar los cambios al
sistema de software)

• Y autorizarlos
 2.1 Un escenario de Gestión de Configuración del
Software

• Para los ingenieros de software, la meta es trabajar eficazmente. Usan

herramientas que ayudan a construir un producto de software consistente, se
comunican y coordinan al notificarse unos con otros las tareas requeridas y las
tareas completadas.

• El cliente usa el producto. Puesto que este se encuentra bajo Administracion de

Cambio (AC), el cliente sigue procedimientos formales para solicitar cambios y
para indicar errores en el producto.
2.1 Un escenario de Gestión de Configuración del
Software

De manera ideal, un sistema AC utilizado en este escenario debe apoyar todos estos roles y
tareas, es decir, los roles determinan la funcionalidad requerida de un sistema AC.

El gerente de proyecto ve la AC como un mecanismo de auditoría; el gerente de

configuración la considera un mecanismo de control, rastreo y generación de políticas; el
ingeniero de software, como un mecanismo de control de cambio, construcción y acceso; y
el cliente la ve como un camino para garantizar la calidad.
 2.2 Elementos de un sistema de administración de la
configuración
Se identifica cuatro elementos importantes que deben existir cuando se desarrolla un
sistema de administración de la configuración:

• Elementos componentes: conjunto de herramientas acopladas dentro de

un sistema de administración de archivos (por ejemplo, base de datos)
que permite el acceso a cada ítem de configuración del software, así como
su gestión.

• Elementos de proceso: colección de acciones y tareas que definen un

enfoque efectivo de la gestión del cambio (y actividades relacionadas)
para todos los elementos constituyentes involucrados en la
administración, ingeniería y uso del software.
2.2 Elementos de un sistema de administración de la
configuración

• Elementos de construcción: conjunto de herramientas que automatizan la

construcción de software al asegurarse de que se ensambló el conjunto
adecuado de componentes validados (es decir, la versión correcta).

• Elementos humanos: conjunto de herramientas y características de proceso (que

abarcan otros elementos AC) utilizados por el equipo de software para
implementar GCS efectiva.
 2.3 Ítem de configuración

Los ítems que comprenden toda la información producida como

parte del proceso de software se llaman colectivamente
configuración del software.

Conforme avanza el trabajo de ingeniería de software, se crea una

jerarquía de ítems de configuración del software (ICS): un elemento
de información nominado que puede ser tan pequeño como un
solo diagrama UML o tan grande como el documento de diseño
completo. Si cada ICS simplemente conduce a otros ICS, dará
como resultado poca confusión.
 2.3 Ítem de configuración

• Información que se crea como parte del proceso de Ingeniería de software

• Un ICS es todo o parte de un producto de trabajo:

 Una sola sección de una gran especificación o como un caso de prueba en una gran suite de pruebas.

 Un documento, una suite de casos de prueba o un componente de programa.

• También las herramientas de SW son ICS:

 Versiones especificas de editores, compiladores, navegadores y otras herramientas automatizadas

2.3 Ítem de configuración
 2.4 Líneas de Referencia o Línea Base
El cambio es un hecho de vida en el desarrollo de software. Los clientes
quieren modificar los requerimientos. Los desarrolladores quieren cambiar
el enfoque técnico. Los gerentes quieren modificar la estrategia del
proyecto.

Una línea de referencia o llamada también línea base, es un concepto de

gestión de configuración del software que nos ayuda a controlar el cambio
sin impedir seriamente cambios justificados.

El IEEE define una línea base como: “Una especificación o producto que se
revisó formalmente y con el que se estuvo de acuerdo, que a partir de
entonces sirve como base para un mayor desarrollo y que puede cambiar
sólo a través de procedimientos de control de cambio formal.”
 2.4 Líneas de Referencia o Línea Base
Antes de que un ítem de configuración del software se convierta en línea de referencia, los cambios pueden
realizarse rápida e informalmente. No obstante, una vez establecida la línea de referencia, pueden realizarse
cambios, pero debe aplicarse un procedimiento formal específico para evaluar y verificar cada uno de ellos.

En el contexto de la ingeniería de software, una línea de referencia es un hito en el desarrollo del software. Una
línea de referencia se marca al entregar uno o más ítems de configuración del software que se aprobaron como
consecuencia de una revisión técnica.

Ejemplo de los pasos para declarar un modelo de diseño como Línea de Referencia

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

2. Se encontraron y corrigieron errores.

3. Una vez que todas las partes del modelo se revisaron, corrigieron y luego aprobaron, el modelo de diseño se convierte en línea de
referencia.
2.4 Líneas de Referencia o Línea Base

REPOSITORIO

GCS
2.5 El Repositorio

Inicialmente la gestión de los ICS era ineficiente porque se almacenaban sin

soporte informatizado (papel o el mente de los programadores.

 Dificultad para encontrar un IC cuando se necesitaba

 Complejidad en determinar cuales ICS cambiaban, cuando y por quien.

 Describir relaciones detalladas y complejas entre los ítems de configuración era

virtualmente imposible..

• En la actualidad, los ICS se mantienen en una base de datos del proyecto o

repositorio.
2.5 El Repositorio

El repositorio GCS es el conjunto de mecanismos y estructuras de datos que permiten a un

equipo de software administrar el cambio en forma efectiva.

Proporciona las funciones obvias de un moderno sistema de administración de base de datos,

al asegurar integridad, posibilidad de compartir e integración de datos.

Además, el repositorio GCS proporciona un centro para la integración de herramientas de

software, es fundamental en el flujo del proceso de software y puede reforzar la estructura y el
formato uniforme para los productos que son resultado de la ingeniería de software.
2.5 El Repositorio

El repositorio cuenta con herramientas de apoyo a las siguientes características:

Versiones: El repositorio debe guardar todas las versiones del software para permitir la administración efectiva
de los productos liberados y, a los desarrolladores, regresar a versiones anteriores durante pruebas de
depuración.

Rastreo de dependencia y gestión del cambio: El repositorio administra una amplia variedad de relaciones
entre los elementos de datos almacenados en el.

Rastreo de requerimientos: El repositorio debe tener la capacidad de rastrear todos los productos de trabajo
que resulten de una especificación de requisitos determinada (rastreo hacia adelante)

También la capacidad de identificar que requisito genera algún producto de trabajo determinado (rastreo hacia
atrás)
2.5 El Repositorio

Administración de la configuración: Una instalación de administración de la configuración

sigue la pista a una serie de configuraciones que representa hitos de proyecto específicos o
liberaciones.

Ensayos de auditoria: Un ensayo de auditoría establece información adicional acerca de

cuándo, por qué y quién realiza los cambios.

Siempre que se modifique un elemento de diseño, se mostrara al desarrollador, (o a la

herramienta que se utilice), el inicio de la entrada de la información de para conocer el cambio
2.5 El Repositorio
 3. EL PROCESO DE GESTION DE CONFIGURACION
DEL SOFTWARE

El proceso de administración de la configuración del software define una

serie de tareas que tienen cuatro objetivos principales:

1) Identificar todos los ítems que de manera colectiva definen la

configuración del software.

2) Administrar los cambios a uno o más de estos ítems.

3) Facilitar la construcción de diferentes versiones de una aplicación y

4) Garantizar que la calidad del software se conserva conforme la

configuración evoluciona con el tiempo.
 3. El proceso de Gestión de Configuración de Software
Un proceso que logra dichos objetivos no necesita ser burocrático o pesado, pero debe caracterizarse de forma
que permita a un equipo de software desarrollar respuestas a un conjunto de preguntas complejas:

• ¿Cómo identifica un equipo de software los elementos discretos de una configuración de software?

• ¿Cómo gestiona una organización las muchas versiones existentes de un programa (y su documentación) de
manera que permita que el cambio se acomode eficientemente?

• ¿Cómo controla una organización los cambios antes y después de que el software se libera a un cliente?

• ¿Quién tiene la responsabilidad de aprobar y clasificar los cambios solicitados?

• ¿Cómo puede garantizarse que los cambios se realizaron adecuadamente?

• ¿Qué mecanismo se usa para enterar a otros acerca de los cambios que se realizaron?
3. El proceso de Gestión de Configuración de Software
Estas preguntas conducen a la definición de las cinco tareas GCS (identificación, control de versión, control
de cambio, auditoría de la configuración y reporte)
 3.1 Identificación de objetos en la Configuración del
Software
Se trata de establecer estándares de documentación y un esquema de
identificación de documentos.

Para controlar y administrar ítems de configuración del software, cada uno debe
nombrarse por separado y luego organizarse usando un enfoque orientado a
objetos. Es posible identificar dos tipos de objetos básicos y agregados.

Un objeto básico es una unidad de información que se crea durante el análisis, el

diseño, el código o la prueba (una sección de una especificación de requerimientos,
parte de un modelo de diseño, código fuente para un componente o una suite de
casos de prueba que se utilice para ejercitar el código) . Ejemplo: Componente n,
diagrama de Clases UML
3.1 Identificación de objetos en la Configuración del
Software
Un objeto agregado es una colección de objetos básicos y de otros objetos agregados, Ejemplo:
Especificaciones de diseño, Modelo de datos, modelo de arquitectura.

Características:

• Nombre : Cadena de Caracteres que identifican.

• Descripción: Lista de ítems de datos que identifican el tipo de ICS (Ejem. Elemento de modelo,
programa, datos) representado por el objeto, un identificador de proyecto e información de cambio y/o
versión.
• Lista de recursos: Entidades que se proporcionan, procesan, referencian o que de algún modo el objeto
las requiere, Ejem. Los tipos de datos, las funciones especificas o los nombres de variables pueden
considerarse como recursos del objeto.
• Realización: Es un puntero hacia la unidad de texto, para un objeto básico; y nulo para un objeto
agregado.
3.1 Identificación de objetos en la Configuración del
Software

La identificación del objeto de configuración también puede considerar las relaciones que existen entre los
objetos nominados. Ejemplo:

se puede crear una jerarquía de ICS

En muchos casos, los objetos se interrelacionan a través de ramas de la jerarquía de objetos. Representándose de
la siguiente manera:
3.1 Identificación de objetos en la Configuración del
Software

El esquema de identificación de objetos de software debe reconocer que los objetos

evolucionan a lo largo del proceso de software.

Antes de que un objeto se convierta en línea de referencia, puede cambiar muchas

veces, incluso después de establecer una línea base de referencia, los cambios
pueden ser bastante frecuentes.
 3.2 Control de Versión

La gestión de versiones es el proceso de hacer un seguimiento de las

diferentes versiones de los componentes de software o ítems de
configuración, y los sistemas de donde se usan dichos componentes.
También incluye asegurar que los cambios hechos a dichas versiones por
los diferentes desarrolladores no interfieran unos con otros.

El control de versión combina procedimientos y herramientas para

administrar diferentes versiones de objetos de configuración que se crean
durante el proceso de software.

Un sistema de control de versión implementa o se integra directamente

con cuatro grandes capacidades:
3.2 Control de Versión

1) Una base de Datos de proyecto que almacena todos los objetos de configuración relevantes

2) Una capacidad de administración de versión que almacena todas las versiones de un objeto de configuración (o que
permite la construcción de cualquier versión usando referencias de las versiones pasadas).

3) Una facilidad para elaboración que le permite recopilar todos los objetos de configuración relevantes y construir una
versión específica del software.

Además, los sistemas de control de versión y de control de cambio con frecuencia implementan una capacidad de
rastreador de conflictos (también llamado rastreador de errores) que permite al equipo registrar y rastrear el estado de
todos los conflictos sobresalientes asociados con cada objeto de configuración.
3.2 Control de Versión

Algunos sistemas de control de versión establecen un conjunto de cambio, una colección de todos los
cambios que se requieren para crear una versión específica del software.

Un conjunto de cambio “captura todos los cambios habidos en todos los archivos que hay en la
configuración, junto con la razón de los cambios y detalles de quién y cuándo hizo los cambios”.

Algunos conjuntos de cambio nominados pueden identificarse para una aplicación o sistema. Esto permite
construir una versión del software al especificar los conjuntos de cambios (por nombre) que deben
aplicarse a la configuración de referencia.

Para lograr esto, se aplica un enfoque de modelado de sistema.

3.2 Control de Versión

El modelo del sistema contiene:

1) Una plantilla que incluye una jerarquía de componente y un “orden de construcción” para los
componentes que describen cómo debe construirse el sistema.

2) Reglas de construcción y

3) Reglas de verificación.

Hoy en día existen diferentes tipos de software para la gestión de control de versiones. Están proliferando
nuevas formas de uso, como comunidades de desarrollo en línea, o el almacenaje de ficheros en la nube.

CVS : Concurrent Versions System, ( Sistema de Versiones concurrente) quizás uno de los más usados y
probablemente de los más antiguos que se usan hoy en día. Obsoleto.
3.3 Control de Cambios

Consiste en la evaluación y registro de todos los cambios que se hagan de la

configuración del software.

Es un mecanismo para la evaluación y aprobación de los cambios hechos a

elementos de la configuración de software durante el ciclo de vida.

El control de cambio debe ser un acto de equilibrio. Mucho control del

cambio creará problemas. Muy poco, crearan otros problemas.

Para un proyecto de software, el cambio descontrolado conduce rápidamente

al caos. Para tales proyectos , el control del cambio combina procedimientos
humanos y herramientas automatizadas a fin de proporcionar un mecanismo
para el control del cambio.
3.3 Control de Cambios

PROCESO DE
CONTROL DEL
1 CAMBIO FORMAL
3.3 Control de Cambios

Dichos mecanismos de control de versión, integrados dentro del proceso de control de cambio,
implementan dos importantes elementos de la gestión del cambio: control del acceso y control de la
sincronización.

El control del acceso determina qué ingenieros de software tienen la autoridad para acceder y
modificar un objeto de configuración particular.

El control de la sincronización ayuda a garantizar que cambios paralelos, realizados por dos personas
diferentes, no se sobrescriban mutuamente.
3.3 Control de Cambios

Todo el proceso de control de cambio puede parecer burocrático.

La mayoría de los desarrolladores de software que tienen mecanismos de control del cambio han creado
algunas capas de control para auxiliarse y evitar los problemas de cambio.

Antes de que un ICS se convierta en referencia, solo es necesario aplicar el control de cambio informal. El
desarrollador del objeto de configuración (ICS) en cuestión puede hacer cualquier cambio que sea
justificado por el proyecto y por los requerimientos técnicos, en tanto los cambios no afecten
requerimientos mas amplios del sistema que se encuentren fuera del ámbito de trabajo del desarrollador.

Una vez que el objeto experimenta revisión técnica y se aprueba, puede crearse una línea de referencia.
3.3 Control de Cambios

Cuando el ICS se convierte en referencia, se implementa un control de cambio en el nivel del proyecto.

Entonces, para hacer un cambio, el desarrollador debe obtener la aprobación del gerente del proyecto (si el cambio
es “local”) o del ACC (si el cambio afecta a otros ICS).

En algunos casos, la generación formal de peticiones de cambio, reportes de cambio y OCI se otorgan en conjunto.
Sin embargo, se realiza la valoración de cada cambio y todos los cambios se rastrean y revisan.

Cuando el producto de software se libera a los clientes, se instituye el control de cambio formal.

La autoridad de control de cambio juega un papel activo en la segunda y tercera capa del control.
3.3 Control de Cambios

Dependiendo del tamaño y carácter de un proyecto de software, la ACC puede componerse

de una persona (el gerente de proyecto) o de algunas personas (representantes de software,
hardware, ingeniería de base de datos, apoyo, mercadotecnia).

El papel de la ACC es adoptar una visión global, es decir, valorar el impacto del cambio más
allá del ICS en cuestión.

¿Cómo afectará el cambio al hardware? ¿Cómo lo hará en el desempeño? ¿Cómo modificará

la percepción de los clientes acerca del producto? ¿Cómo afectará la calidad y confiabilidad
del producto?
3.4 Auditoria de Configuración

La identificación, control de versión y control del cambio ayudan a conservar el

orden en lo que de otro modo sería una situación caótica y fluida. Sin embargo,
incluso los más exitosos mecanismos de control rastrean un cambio sólo hasta que
se genera una OCI.

¿Cómo puede un equipo de software asegurarse de que el cambio se implementó

adecuadamente?

1) revisiones técnicas y

2) auditoría a la configuración del software.

3.4 Auditoria de Configuración

La revisión técnica se enfoca en la exactitud técnica del objeto de configuración que se modificó.

Los revisores valoran el ICS para determinar la consistencia con otros ICS, así como omisiones o
potenciales efectos colaterales. Una revisión técnica debe realizarse para todos los cambios, salvo los
más triviales.

Una auditoría de configuración del software complementa la revisión técnica al valorar un objeto
de configuración acerca de las características que por lo general no se consideran durante la revisión.

La auditoría hace y responde las siguientes preguntas:

3.4 Auditoria de Configuración

1. ¿Se realizó el cambio especificado en la OCI? ¿Se incorporó alguna modificación adicional?

2. ¿Se llevó a cabo una revisión técnica para valorar la exactitud técnica?

3. ¿Se siguió el proceso del software y se aplicaron adecuadamente los estándares de ingeniería de
software?

4. El cambio se “resaltó” en el ICS? ¿Se especificaron la fecha del cambio y el autor del cambio? ¿Los
atributos del objeto de configuración reflejan el cambio?

5. ¿Se siguieron los procedimientos GCS para anotar, registrar y reportar el cambio?

6. ¿Los ICS relacionados se actualizaron adecuadamente?

3.5 Reporte de Estado

Llamado también Informe de Estado o Contabilidad de Estado.

Es una tarea de la GCS que responde a las siguientes preguntas:

1) ¿Qué ocurrió?

2) ¿Quién lo hizo?

3) ¿Cuándo ocurrió?

4) ¿Qué más se afectará?

3.5 Reporte de Estado

El flujo de información para el reporte de estado de configuración (REC) lo vemos en el PROCESO

DE CONTROL DEL CAMBIO FORMAL.

Entradas al REC:

• Una nueva identificación o actualización del ICS.

• Se aprueba un cambio, se hace una entrada al REC
• Auditoria de la Configuración

La salida del REC puede colocarse en una base de datos en línea o en un sitio web, de modo que
los desarrolladores de software o el personal de apoyo puedan acceder a la información del cambio
mediante categorías de palabras clave.
4. PLAN DE GESTION DE SOFTWARE

El plan de gestión de la configuración constituye un elemento clave

para establecer y garantizar la integridad del producto durante el
proceso de desarrollo. Es considerado como parte de las actividades
que se cubren en el área del proceso de Gestión del Configuración.

En algunos libros se propone una estructura general del plan de

gestión de la configuración. Donde se integra información para
garantizar la actividad en relación con la organización, recursos,
calendario de las actividades del proyecto y, en particular, para cubrir
las actividades propias de gestión de la configuración: identificación,
control, auditoría y reporte.
4. Plan de Gestión de Configuración

Este plan puede ser integrado con las actividades de planificación del proyecto o
bien ser considerado como una actividad independiente desarrollada por el grupo
o área responsable de la Gestión de Configuración del SW. Algunos elementos
pueden considerarse por única vez y otros se pueden estandarizar para todos.

Secciones del Plan de gestión de la configuración

La primera sección es la introducción con el resumen del plan, actividades,

audiencia y cómo usarlo de manera que el usuario tenga una comprensión clara del
mismo.
4. Plan de Gestión de Configuración

• Propósito, con las necesidades y la audiencia que se supone tiene el plan.

• Alcance, describe la aplicación del plan, limitaciones y suposiciones, resumen del proceso de
desarrollo de software y cómo las funciones y actividades de la Gestión del Software se integran en
el proyecto.

• Definiciones, presenta los términos clave utilizados en el documento.

• Referencias a documentos, estándares, procedimientos (internos y externos) utilizados en el plan.

Identifica dónde pueden encontrarse los documentos.
4. Plan de Gestión de Configuración

La segunda sección se relaciona con la organización del equipo de GCS y asignación de responsabilidades
a equipos e individuos.

• Estructura organizacional del equipo de GCS y cómo se integra en la estructura con respecto a otros
grupos como: equipo del proyecto, equipo de aseguramiento de calidad y alta gerencia, clientes, usuarios
y subcontratistas involucrados en actividades de Gestión de SW. Describe la composición del Comité de
control de cambios y los equipos de auditoria y revisión.

• Responsabilidades y obligaciones de los individuos involucrados en actividades de CM.

• Relación de actividades de GCS durante las diferentes fases del ciclo de vida.

• Descripción de las interacciones con otros grupos del proyecto como proveedores y subcontratistas.

• Responsabilidades de proveedores, subcontratistas y otras organizaciones con respecto a las funciones de

GCS.
4. Plan de Gestión de Configuración

La tercera sección es la que considera las actividades para la gestión de la configuración. Establece las
tareas y funciones requeridas para la gestión de la configuración de acuerdo con el alcance del plan. Describe
las actividades principales de Gestión de Software y cómo se realizan en el proyecto.

Identificación
Describe como identificar, nombrar y documentar las características físicas y funcionales de los componentes
de configuración. Una vez identificados los componentes son incorporados a un ambiente controlado.

1. Identificación de componentes de configuración, que serán controlados por las actividades de

GCS. Define una lista de los componentes de configuración del proyecto, que puede mostrar
en forma de estructura de árbol las interdependencias que existan.
4. Plan de Gestión de Configuración

2. Nombres de componentes de configuración. Especifica el sistema para identificación,

las convenciones de nombres, número de versiones y letras utilizadas para identificar
los componentes.

3. Adquisición de componentes de configuración. Describe cómo los componentes serán

almacenados, cómo serán controlados los accesos, detalles de las bibliotecas de
configuración y los procedimientos para registro de entrada y salida de componentes
desde la biblioteca.
4. Plan de Gestión de Configuración

Control

Describe los procesos para gestión de cambios como son: inicio, evaluación, implantación, revisión,
aprobación y establecimiento de los cambios.

1. Identificación de cambios. Describe cómo iniciar el cambio. Un cambio puede ser producto de
una falla o problema o como resultado de una mejora o característica nueva. Describe los
procedimientos a seguir para iniciar una solicitud de cambio o reporte de problema para
comenzar la actividad de control de cambios.

2. Evaluación de cambios. Describe cómo se realiza la evaluación de una solicitud de cambio.

Detalla cómo manejar el análisis y clasificación del problema, así como la preparación de la
persona que realiza la evaluación.
4. Plan de Gestión de Configuración

3. Administración de cambios. Describe cómo se procesa la solicitud de cambio. Establece

claramente el proceso para recepción de la solicitud, enviar a evaluación, reunir al comité de
control de cambios, procesar las solicitudes de cambio y demás.

4. Implantación de cambios. Describe cómo, una vez que los cambios son aprobados, seleccionar
al equipo de implantación, verificar y validar los cambios y enviarlos a la nueva línea base.

5. Comité de control de cambios. Describe cómo funciona el comité como grupo para la decisión
de aprobación o no de los cambios. Define quién tiene la autoridad en el comité y cómo se
solucionan los conflictos.
4. Plan de Gestión de Configuración

Reporte de estado

Registro del estado de los componentes de configuración y reporte a las personas interesadas.

1. Identificación de necesidades de información. Describe los requerimientos de información del

proyecto. Qué se requiere, por quién, frecuencia de los reportes, principalmente

2. Mecanismo para obtener información. Describe cómo se obtiene la información. Es deseable

que la información se encuentre en una base de datos que es alimentada por la persona que
realiza la actividad y no por la que procesa la misma para generar el reporte.
4. Plan de Gestión de Configuración

3. Reporte, contenido y frecuencia. Describe los diferentes reportes que se generan, su frecuencia y
contenido de los reportes.

4. Acceso a los datos para reporte de estado. Describe cómo se puede acceder la información para
generar los reportes.

5. Método de difusión de la información de los reportes de estado. Describe cómo y a quién se le

distribuye la información de los reportes de estado.

6. Detalle de liberaciones. Detalla información sobre qué es lo que contienen las liberaciones, a
quién se libera y cuándo, en qué medio se realiza, problemas que se pueden presentar en las
liberaciones del producto y forma de corregirlos, instrucciones de instalación, entre otras.
4. Plan de Gestión de Configuración
Auditorías

Describe los tipos de auditorías que se realizan, el procedimiento que se utiliza, la frecuencia y autoridad para realizar las
auditorías.

1. Auditorías a realizar. Describe los diferentes tipos de auditorías que se van a realizar y cuándo serán realizadas.
Normalmente se consideran: auditorías físicas, auditorías funcionales, auditorías a subcontratistas y auditorías
externas.

2. Componentes de configuración a auditar.

3. Procedimientos de auditorías. Describe el procedimiento a utilizar en cada tipo de auditoría: quién la realiza,
documentos requeridos, cómo debe llevarse a cabo y el formato para reporte de auditoría.

4. Actividades de seguimiento a auditorías. Describe las actividades que se deben realizar posterior a la auditoría para la
solución de las no conformidades.
4. Plan de Gestión de Configuración
Otras secciones del plan consideran:

• Control de interfaces, donde se describe la coordinación de los cambios de componentes de

configuración con los cambios a los elementos de interfaz fuera del alcance del plan como los elementos
de hardware, paquetes, software de apoyo y demás. Debe identificar cada uno de los elementos externos,
la naturaleza de la interfaz, los grupos afectados, cómo serán controlados estos elementos y cómo serán
aprobados para formar parte de la línea base.

• Control de subcontratistas, que describe las actividades necesarias para incorporar los componentes
desarrollados fuera del ambiente del proyecto, en particular los componentes de proveedores. Describe
las funciones y actividades de gestión de la configuración que debe realizar el subcontratista,
mecanismos para asegurar que se cumplen, procedimiento para auditar los componentes entregados y
los componentes que se van a suministrar. Adicionalmente describe cómo serán recibidos, probados y
puestos bajo control de la configuración estos componentes y cómo se procesarán e implantarán las
solicitudes de cambio.
4. Plan de Gestión de Configuración
Finalmente el plan integra las actividades en relación con el proyecto y el ciclo de vida del producto que contiene:

• Calendario de GCS. Describe la secuencia de actividades, la relación e interdependencia con el ciclo de vida del
proyecto y las fechas críticas del proyecto. Identifica el ciclo de vida del proyecto, las diferentes fechas dónde se
establecerán las líneas base y el calendario de las diferentes auditorías.

• Recursos para GCS. Identifica las herramientas de software, técnicas, equipos, personal y capacitación requerida para la
implantación de las actividades de gestión de la configuración especificadas.

• Mantenimiento del plan. Describe las actividades requeridas para mantener el plan actualizado durante el ciclo de vida
del proyecto, el mecanismo para monitorizar y sincronizar con las actividades del proyecto y la persona responsable
de estas actividades.
4. Plan de Gestión de Configuración

La planificación de la Gestión de Configuración del Software, esta regulado en el:

Estandar IEEE 828

 Gracias!

Obtener más información en el Centro de introducción a PowerPoint