CM Instrucciones 10PGCONF 1.0

MAS TE R E N I NGE NI E RÍ A DE SO FTWARE
UNIVERSIDAD POLITÉCNICA DE CATALUNYA
PROYECTO FINAL DE MÁSTER – MRF FRAMEWORK
Plan de Gestión de la
Configuración
Instrucciones
Versión 1.0 ● 30 SEP 2008

Máster en Ingeniería de Software INSTRUCCIONES PLAN DE GESTIÓN DE LA
CONFIGURACIÓN
Proyecto Final de Máster – MRF Framework Versión 1.0 | 30-SEP -2008
Tabla de Contenidos
Introducción........................................................................................................... 1
Uso del Plan de Gestión de la Configuración........................................................1
Sección 1 Estrategia de Gestión de la Configuración.........................................2
1.1 Organización......................................................................................2
1.2 Definición de Roles............................................................................2
1.3 Políticas, Directivas y Procedimientos...............................................2
1.4 Herramientas, Entorno e Infraestructura............................................3
1.5 Calendario.......................................................................................... 3
Sección 2 Actividades de Gestión de la Configuración.......................................3
2.1 Identificación de la Configuración......................................................3

2.1.1 Ítems de Configuración ..........3
2.1.2 Convención de Nomenclatura de Ítems de Configuración. 4
2.1.3 Librerías Controladas ..........4
2.2 Control de Configuración...................................................................4
2.3 Rendición de Cuenta y Reporte del Estado de la Configuración.......5
2.4 Auditorías y Revisiones de Configuración..........................................5
2.5 Control de Interfaces..........................................................................6
2.6 Control de Proveedores.....................................................................7
Sección 3 Glosario.............................................................................................. 7
Sección 4 Control de Cambios...........................................................................8
Sección 5 Anexos............................................................................................... 8
CM-Instrucciones-10PGCONF-1.0 Página i
CONFIGURACIÓN
Introducción
La gestión de la configuración es uno de los componentes de éxito de los proyectos TIC. Sin una
gestión de la configuración efectiva, la integridad de los ítems de configuración del proyecto y la
capacidad de reportar el estado y configuración de aquellos ítems se pone en peligro.
El plan de gestión de la configuración incluido en el framework MRF permite establecer un

método consistente para identificar y controlar formalmente los ítems de configuración del
proyecto. Los ítems de configuración del proyecto incluyen elementos de hardware y software,
así como también información de gestión del proyecto como planes y presupuesto. La gestión de
la configuración es una función integral de la provisión de proyectos TIC porque facilita la
protección de los ítems de configuración y comunica los cambios que se han hecho sobre ellos.
Una gestión de la configuración, planificada y ejecutada de manera efectiva, contribuye a la
producción de productos TIC de alta calidad evitando el retrabajo. Esto aumenta el valor de los
activos informáticos y ahorra costes, contribuyendo a la entrega de proyectos que satisfacen los
costes, calendarios, calidad y requerimientos establecidos.
Un plan de gestión de la configuración sirve como una herramienta medular de planificación que
describe los esfuerzos de planificación para implementar y ejecutar la gestión de la configuración
a lo largo del ciclo de vida del proyecto. Provee visibilidad y control del producto referente a su
desempeño, funcionalidad y atributos físicos. La gestión de la configuración establece y
mantiene la integridad de los ítems de configuración del proyecto. La gestión de la configuración
facilita una gestión ordenada de información de las líneas base que necesitan ser controladas,
así como los cambios que a éstas se efectúan.
Uso del Plan de Gestión de la Configuración

Visión
Dentro del MRF framework, el plan de gestión de la configuración es un artefacto clave en la fase
de planificación del proyecto.
El plan de gestión de la configuración debe ser utilizado para planificar y ejecutar las actividades
de identificación y control de ítems de configuración de proyectos.
El plan de gestión de la configuración es ejecutado a lo largo de la vida del proyecto para

controlar ítems de configuración específicos con una concentración en el progreso ordenado de
líneas base de desarrollo con respecto a líneas base establecidas. El plan de gestión de la
configuración debe ser desarrollado en coordinación con el equipo de proyecto y GPIs, y
mantenerse accesible a ellos. Además, todos los cronogramas y actividades planificadas, roles y
responsabilidades requeridos para la ejecución del plan de gestión de la configuración deben ser
integrados al plan de gestión del proyecto.
CM-Instrucciones-10PGCONF-1.0 Página 1
CONFIGURACIÓN
Para obtener los mejores resultados en la ejecución del plan de gestión de la configuración, este
debe ser actualizado cuando se produzcan cambios y ser evaluado periódicamente respecto a
su efectividad.
Aplicabilidad
El plan de gestión de la configuración debe ser desarrollado para cualquier proyecto clasificado
como grande y mediano.
Gobierno y Alcance
El gerente de proyecto es responsable de asegurar que el plan de gestión de la configuración

sea desarrollado en conjunto con el plan de gestión del proyecto. El gerente de proyecto
asegurará su integración en la planificación general.
Sección 1 Estrategia de Gestión de la Configuración

1.1 Organización
Proveer y describir un diagrama que muestre como las actividades de la gestión de la
configuración serán integradas con las actividades del proyecto para identificar y controlar
formalmente los ítems de configuración del proyecto.
1.2 Definición de Roles

Completar la matriz de actividades de gestión de la configuración para cada rol del proyecto y/o
área funcional. La matriz completa, deberá reflejar por rol funcional la responsabilidad asignada
por actividades claves de gestión de la configuración y las habilidades requeridas asociadas.
Adicionalmente a los roles individuales, actividades y habilidades requeridas, identificar los

miembros del Comité de Control de Cambios y su nivel de autoridad para aprobar los cambios
propuestos. El Comité de Control de Cambios es un grupo de GPIs responsable de evaluar y
aprobar o desaprobar los cambios propuestos a los ítems de configuración y para asegurar la
implementación de los cambios aprobados. Se pueden especificar los múltiples niveles del
Comité de Control de Cambios dependiendo del grado de complejidad del producto y la línea
base involucrada. Cuando se utilizan múltiples niveles en el comité de control de cambios,
especificar cómo funcionan estos niveles en los cambios requeridos. Indicar los niveles de
autoridad y las actividades por las cuales son responsables.
1.3 Políticas, Directivas y Procedimientos

Proveer y describir las políticas, directivas y procedimientos que aplican al plan de gestión de la
configuración. Identificar cualquier restricción externa o requerimientos puestos en el plan por
políticas, directivas y procedimientos.
CONFIGURACIÓN
1.4 Herramientas, Entorno e Infraestructura

Especificar las herramientas, el entorno y la infraestructura requerida para la ejecución de las
actividades de gestión de la configuración del proyecto. Las herramientas pueden ser específicas
de gestión de la configuración o empotradas como ayudas a productos de uso general; pueden
ser recursos organizacionales estándar o ser adquiridas o construidas para el proyecto. Las
herramientas se utilizan para establecer la estructura de las librerías y el control de acceso;
desarrollo y control de la documentación; control de código; sistema de generación de líneas
base; comunicación y autorización; control y reporte de estado de cambios/problemas; archivo,
retención y recuperación de ítems controlados; procesos de planificación de la gestión de la
configuración.
1.5 Calendario
Proveer una referencia a la ubicación de la información de calendario de la gestión de la
configuración del proyecto, o especificar la información de calendario de gestión de la
configuración que establece la secuencia y coordinación de las actividades de gestión de la
configuración. Establecer la secuencia y dependencias entre todas las actividades de gestión de
la configuración y la relación de las actividades más importantes con los hitos mayores del
proyecto. Incluir los hitos principales del producto relacionados con actividades de gestión de la
configuración.
En los hitos de la gestión de la configuración, incluir el establecimiento de las líneas base de

configuración, implementación de procedimientos de control de cambios, y las fechas de inicio y
término de auditorías de la configuración planificadas.
Sección 2 Actividades de Gestión de la

Configuración
Las diferentes actividades requeridas por la gestión de la configuración se ejecutan a través de
un sinnúmero de mecanismos, incluyendo procesos y asignación de responsabilidades al
personal.
Algunos de los aspectos a ser gestionados incluyen:
 Asegurarse que en el plan de gestión del proyecto se haya contemplado recursos a un

nivel apropiado para estructurar la gestión de la configuración del proyecto (Personas y
tiempo);
 Delegación explícita de actividades de gestión de la configuración a líderes apropiados;
 Asignar un gerente de configuración dedicado a proyectos con necesidades de gestión

de la configuración complejas;
 Establecer el Comité de Control de Cambios (CCC) y establecer un procedimiento para

su gestión;
CONFIGURACIÓN
 Definir un esquema de versionamiento que satisfaga el ciclo de vida del proyecto;
 Crear una estructura organizacional intuitiva y de fácil uso para almacenar la información
del proyecto;
 Utilizar la trazabilidad para verificar la consistencia entre diferentes tipos de artefactos

(Ej: requerimientos y casos de prueba);
 Auditorías y revisiones;
2.1 Control de Revisiones

Consiste en la identificación, almacenamiento y gestión de los artefactos del proyecto y sus
revisiones a lo largo del ciclo de vida. El control de revisiones permite evitar cambios no
advertidos, determinar el estado del proyecto o sistema en cualquier momento, permitir la
compilación del proyecto, proveer soporte al control de cambios y prevenir la manipulación de los
artefactos.
Casi todos los aspectos de control de revisiones son soportados por la herramientas de gestión
de la configuración y los entornos de desarrollo actuales; es recomendable utilizar este tipo de
herramientas en los proyectos de desarrollo.
2.1 Identificación de la Configuración
2.1.1 Ítems de Configuración
Los ítems de configuración se clasifican en:
1. Ítems en evolución, tales como documentos, los que están sujetos a una o más revisiones y
nuevas liberaciones durante el ciclo de vida del software;
2. Ítems fuente, generalmente código fuente y archivos objeto utilizados para compilar una
aplicación de software para ambiente de producción, los cuales son generalmente
numerosos y cambian frecuentemente;
3. Ítems de soporte, como sistemas operativos y software base, de los cuales el proyecto
requiere ciertas versiones para su operación exitosa;
4. Ítems de archivo, tales como revisiones SQA las cuales generalmente sirvieron de soporte
para la toma de decisiones durante el ciclo de vida del software, son almacenadas
normalmente en formato electrónico para referencia futura;
Nota.- Para más detalle se incluye un anexo de ayuda para la clasificación de los ítems de
configuración.
Los métodos para la identificación única de instancias de cada ítem de configuración son
específicos de la clase de cada ítem. Los ítems en evolución se asignan identificadores únicos,
mientras que la identificación de ítems fuente es gestionada por la herramienta de gestión de
configuración seleccionada (o el entorno de desarrollo). Los ítems de soporte llevan su propia
identificación y numeración de versiones asignados por sus desarrolladores, mientras que los
ítems de archivo son identificados principalmente por el nombre y la fecha.
CONFIGURACIÓN
2.1.2 Convención de Nomenclatura de Ítems de Configuración
Identificación de ítems en evolución
Los ítems en evolución son de dos tipos: documentos, y archivos ejecutables o de soporte.
Documentos
Los ítems en evolución tipo documento se asignan identificadores únicos que permiten identificar
el proyecto y componente (si es aplicable) con el cual está asociado, junto con el nivel de
revisión actual. El identificador consiste de una a tres partes separadas por guión en el formato:
PROYECTO-ACRÓNIMO, ó, PROYECTO-ACRÓNIMO-COMPONENTE.
Los ítems en evolución que son ítems no específicos a un proyecto único, tales como políticas,
descripciones de procesos y guías, son identificados únicamente por su acrónimo, por ejemplo:
SPMP (Software Project Management Policy).
Los ítems en evolución que son específicos de un proyecto, pero no asociados con un
componente del proyecto, utilizan un identificador de dos partes: ACRÓNIMO_PROYECTO y
ACRÓNIMO derivado del tipo de artefacto. Por ejemplo, para identificar el plan de gestión de la
configuración del proyecto ACME, tenemos: ACME-SCMP.
Los ítems en evolución que son específicos de un proyecto y están asociados con un
componente específico, utilizan un identificador de tres partes: ACRÓNIMO_PROYECTO,
ACRÓNIMO_COMPONENTE, y, ACRÓNIMO derivado del tipo de artefacto. Por ejemplo, para
identificar el documento de especificación de requerimientos, del componente B2B (Business to
Business) del proyecto ACME, tenemos: ACME-B2B-SRD.
El nivel de versión de cada ítem se mantiene como un identificador separado. Esto permite que
el identificador principal sea utilizado como parte del nombre de archivo o URL para acceder a la
versión más actualizada sin necesidad de requerir cambios a todos los ítems referenciados. El
nivel de versión se mantiene como un identificador numérico con dos componentes:
Versión.Revisión. Ejemplo: 1.1; Versión 1, Revisión 1.
Número de versión
El número de versión cambia únicamente cuando la arquitectura principal del ítem ha cambiado,
o cuando el ítem es completamente reconstruido, con cambios internos sustanciales. En este
caso la versión 1.1 se convertirá en versión 2.0.
Número de revisión
El número de revisión cambia cuando el contenido ha cambiado, pero la estructura principal y el

flujo del ítem se mantiene igual. La secuencia normal de las revisiones es: 1.0, 1.1, 1.2, etc.
CONFIGURACIÓN
Archivos ejecutables y de soporte
Los ejecutables del software y los archivos de soporte son identificados generalmente por el
nombre y el número de versión, tales como “Main DB v1.1a"
La convención para los nombres para cada ítem de software en evolución es definida por el
equipo de desarrollo. El esquema de numeración de versiones consiste de tres componentes:
Versión.RevisiónActualización. Ej: 1.1a.
Número de versión
El número de versión cambia únicamente cuando la arquitectura principal del ítem de software
cambia, cuando migramos de un nivel de herramienta de desarrollo a otro, cuando una
aplicación es totalmente reconstruida, o cuando se producen cambios sustanciales en la GUI. En
este caso, la versión 1.1a se convierte en la versión 2.0
Número de revisión
El número de revisión es actualizado cuando se añade nuevas características, funcionalidad y

otro contenido, o estas han cambiado significativamente. Normalmente la arquitectura principal o
la GUI ha sido extendida o limitada de alguna manera. La razón más común de cambiar el
número de revisión es cuando añadimos un nuevo módulo u otra funcionalidad al ítem de
software. La secuencia normal de revisión es 1.0, 1.1, 1.2, etc.
Carácter de actualización
El carácter de actualización se incrementa cuando el único cambio al ítem de software es

corregir uno o más defectos, sin añadir ninguna nueva funcionalidad. Las actualizaciones
evolucionan 1.1a, 1.1b, etc. Esta actualización se sobrescribe cuando una revisión combinada,
que incluye arreglar defectos y añadir nuevas características, se lleva a cabo. En tal caso, se
incrementa el número de revisión y se descarta el carácter, es decir: 1.1b a 1.2.
Identificación de ítems fuente
Esto se maneja en base a la herramienta de gestión de la configuración utilizada, o de las

utilidades del entorno de desarrollo para versionamiento.
Identificación de ítems de soporte
Son identificados por su nombre y el número de versión necesario para soportar el entorno de
producción o desarrollo. Por ejemplo, si un editor se actualiza de la versión 2.1 a 2.2a, el rango
de versión del ítem de configuración será 2.1 – 2.2a. Esto es importante para la recuperación
posterior de la información archivada del proyecto; la documentación y los ítems fuente se
manejan mejor si conocemos las versiones compatibles de sus ítems de soporte.
CONFIGURACIÓN
Identificación de ítems de archivo
Los ítems de archivo son documentos misceláneos de soporte y registros de comunicaciones

que son almacenadas para referencias futuras. Estos ítems se almacenan según lo describan el
plan de gestión de la configuración. Cada ítem se identifica por el nombre de archivo y la fecha
de modificación. En el caso de que se tenga que mantener el mismo nombre en el subdirectorio
correspondiente, se añadirá un número secuencial para prevenir conflictos.
2.2 Ciclo de Vida de Artefactos Controlados y Líneas Base

2.2.1 Ciclo de Vida de Artefactos
El control de cambios supervisa la revisión de artefactos que han logrado cierto nivel de elaboración. Las
líneas base permiten que el control de cambios aseguren que la evolución de los artefactos
ocurra de manera definida, visible y controlada.
El ciclo de vida desde la concepción inicial de un artefacto hasta su liberación final se muestra a
continuación:
Inicio
Artefacto
Revisión y
aceptación Liberación y
(Línea base) Entrega
Etapa de Etapa Etapa
Borrador Aceptado Mantenimiento
Retiro
Artefacto
Cambios Informales
Cambios formales utilizando Cambios en
utilizando control de
control de cambios (CCC) mantenimiento
revisiones
Un artefacto comienza en una etapa de borrador. En la medida que el artefacto se desarrolla, los
cambios se realizan de manera informal y el trabajo progresa utilizando un control de revisiones.
Cuando el artefacto alcanza el nivel esperado de término, pasa por una revisión y aceptación.
Una vez aceptado, el artefacto se considera parte de una línea base y pasa a la etapa de
aceptado en la cual los cambios son controlados formalmente a través del Comité de Control de
Cambios (CCC).
No todos los artefactos son puestos explícitamente bajo control de cambios. El código fuente
está implícitamente bajo control de cambios porque los artefactos con los que se debe mantener
consistente están bajo control de cambios (requerimientos, especificaciones de diseño, etc).
Finalmente un artefacto una vez que el producto es entregado pasa a una etapa de
mantenimiento donde será gestionado conforme a los procesos que se establezcan.
CONFIGURACIÓN
Etapa de Borrador
En esta etapa los artefactos están sometidos a cambios frecuentes y rápidos antes de
estabilizarse. No es apropiado aplicar control de cambios a los artefactos en esta etapa. Sin
embargo, en el desarrollo vamos a comprometer una cantidad significativa de trabajo que
necesita algún nivel de identificación, almacenamiento robusto y coordinación a través del control
de revisiones. El control de revisiones provee soporte para guardar y recuperar versiones de los
artefactos del proyecto tales como documentos y código fuente sin estar sometidos al esfuerzo
burocrático del control formal de cambios.
El trabajo de ingeniería hará una determinación informal de cuando los artefactos deben ser
puestos bajo control de revisiones. Dado que no hay un control formal de cambios en esta etapa,
es la responsabilidad de cada desarrollador utilizar sentido común para almacenar las revisiones
de los artefactos a intervalos apropiados.
Etapa aceptado
Una vez que el desarrollo del artefacto ha terminado, el artefacto pasa a través de una revisión y
aceptación formal interna. Un artefacto aceptado forma parte de una línea base asignada. Los
cambios subsecuentes al artefacto se gestionan formalmente con el control de cambios a través
del CCC.
Etapa mantenimiento
Una vez que el proyecto de desarrollo ha terminado, la línea base asignada permite someter a
todos los artefactos a revisión y aceptación final previo a su liberación y entrega. Una vez que
hay la aceptación final y se cierra el proyecto, se estable la línea base del producto. Los cambios
posteriores que se presenten serán gestionados por un proyecto de mantenimiento.
2.2.2 Líneas Base
Definir líneas base apropiadas en puntos de control dentro del ciclo de vida del proyecto en
términos de:
 Eventos que crean una línea base;
 Ítems que serán controlados en la línea base;
 Procedimientos utilizados para establecer y modificar las líneas base;
 Autorización requerida para aprobar líneas base;
Una línea base está conformada por diferentes ítems de configuración y se establecen en
diferentes puntos específicos del ciclo de vida del proyecto, normalmente hitos.
En el plan se debe identificar el evento/hito donde se define la línea base y los ítems de
configuración que la conforman. Las líneas base recomendadas son las siguientes:
CONFIGURACIÓN
Línea Base Evento/Hito Ítems de configuración
Línea Base Funcional
Línea base de planificación Fin de Fase de Planificación,  Business case y análisis de

iteración preliminar. impacto;
 Plan de gestión del proyecto y sus
anexos;
 Especificación preliminar de
requisitos:
Líneas Base de Instanciación
Línea base de Fin primera iteración de  Especificación de Requerimientos;

especificación de concepción.
requerimientos
Configuración durante el desarrollo
Línea base de diseño Última iteración de concepción  Diseño preliminar;

 Diseño detallado;
 Plan de pruebas: unitario,
integración, aceptación y sistema;
Línea base de construcción Al final de cada iteración  Especificación de casos de prueba;

 Especificación de procedimientos
de prueba;
 Código fuente;
 Documentación del código;
 Resultados de pruebas unitarias;
Línea base de integración y Al final de la última iteración de  Resultados de las pruebas de

pruebas construcción integración y sistema;
Línea Base de Producto
Línea base de aceptación y Al final de la fase de ejecución,  Software;

entrega última iteración de transición  Documentación del software;
 Descripción de la versión del
software;
2.3 Librerías Controladas

Se sugiere la estructura de librerías controladas bajo el siguiente esquema y descripción:
Librería de
Software
Librería en Repositorio de
Librería Principal
Producción Software
Librería de Librería de
Trabajo Soporte
CONFIGURACIÓN
2.3.1 Librería Principal
Responsable
Gerente de la Configuración (Puede ser rol dedicado o rol compartido).
Actividades
 Mantener actualizadas las líneas base establecidas durante el transcurso del proyecto;
Contenido
 Línea base de planificación;
 Línea base de especificación de requerimientos;
 Línea base de diseño;
 Línea base de construcción;
 Línea base de integración y pruebas;
 Línea base de aceptación y entrega;
Accesos
Rol Tipo de acceso
Gerente de Configuración  Leer;

 Escribir;
 Ejecutar;
 Eliminar;
Gerente de proyecto  Leer;

 Escribir;
 Ejecutar;
 Eliminar (con autorización del gerente de
configuración);
Desarrolladores  Leer;
 Ejecutar;
2.3.2 Librería de Trabajo
Responsable
Arquitecto de Software.
Actividades
 Check in y Check out de ítems pertenecientes a la biblioteca;
CONFIGURACIÓN
Contenido
 Código y documentación de los subsistemas, componentes, módulos;
 Documentación de las pruebas unitarias: procedimientos, datos y casos de prueba;
Accesos
Rol Tipo de acceso
Arquitecto de Software  Leer;

 Escribir;
 Ejecutar;
 Eliminar;
 Escribir;
 Ejecutar;
2.3.3 Librería de Soporte
Responsable
Arquitecto de Software.
Actividades
 Check in y Check out de los diferentes niveles de integración;
 Actualización de los ítems bajo autorización;
Contenido
 Código y documentación de los subsistemas, componentes y módulos aprobados;
 Los diferentes niveles de integración del código;
 Documentación de las pruebas de integración, sistema y aceptación: procedimientos y

casos de prueba, datos de prueba, análisis de resultados;
Accesos
Rol Tipo de acceso
Arquitecto de software  Leer;

 Escribir;
 Ejecutar;
 Eliminar;
 Escribir;
 Ejecutar;
CONFIGURACIÓN
Rol Tipo de acceso
Ingeniero de Pruebas  Leer;

 Ejecutar;
2.3.4 Repositorio de Software
Responsable
Gerente de la Configuración (Puede ser rol dedicado o rol compartido).
Actividades
 Mantener actualizadas la versión del software y su documentación actual;
 Incorporar las nuevas versiones aprobadas;
Contenido
 Versión del software liberado, incluyendo toda su documentación;
 Nuevas versiones de software;
 Sección con los componentes reusables del software;
Accesos
Rol Tipo de acceso
Gerente de Configuración  Leer;

 Escribir;
 Ejecutar;
 Eliminar;
 Ejecutar;
2.4 Almacenamiento de Ítems de Configuración

2.4.1 Ítems en Evolución
Luego de ser identificados, los ítems en evolución son almacenados en el subdirectorio

específico de la fase en la cual son elaborados. Una copia del ítem puede ser puesta en un
servidor web del proyecto. Si el nuevo ítem es una actualización o revisión de un ítem existente,
el ítem anterior es reemplazado en el servidor web, esto asegura que la versión más reciente de
cada artefacto entregable del proyecto esté disponible para todos los integrantes del equipo de
desarrollo.
CONFIGURACIÓN
Tanto la versión actualizada como todas las versiones previas de cada ítem en evolución son
almacenadas en la herramienta de gestión de la configuración. Los controles estándar check-
in/check-out previenen que más de una persona edite un ítem en evolución.
Cuando el ítem en evolución es aprobado y puesto bajo línea base, este es colocado en la
librería correspondiente.
2.4.2 Ítems Fuente
Los ítems fuente son creados generalmente por los desarrolladores y gestionados con la
herramienta de gestión de la configuración. La herramienta gestiona el almacenamiento,
identificación, versionamiento y operaciones de check-in/check-out.
Cuando el ítem fuente es aprobado y puesto bajo línea base, este es colocado en la librería
correspondiente.
2.4.3 Ítems de Soporte
El Gerente de Configuración registra cada ítem de soporte tal cual es recibido por el fabricante.
Una vez que el software ha sido apropiadamente instalado, el medio original utilizado, junto con
la información de licencia y clave de ser el caso, es colocado en un área de almacenamiento
físico seguro para facilitar su recuperación posterior en caso de ser necesario. Se recomienda
además tener una copia de los instaladores en un servidor de archivos.
Los ítems de soporte solo pueden ser actualizados en el ambiente de producción luego de que
ha sido aprobado por el CCC. Esto permite asegurar que la decisión de actualización que puede
impactar al software, sea evaluada adecuadamente.
2.4.4 Ítems de Archivo
Los ítems de archivo son almacenados en subdirectorios apropiados en el directorio del

proyecto. Es recomendable que esté en un servidor de archivos. El directorio puede ser dividido
en subdirectorios por tópico a discreción del Gerente de Configuración.
2.5 Control de Cambios

El proceso de control de cambios gestiona la solicitud, evaluación, aprobación y ejecución de
cambios surgidos (solicitudes de mejoras o reporte de defectos) identificados durante el
desarrollo y explotación del software. Cuando la solicitud de cambio afecta a un ítem bajo línea
base requerirá aprobación del CCC; caso contrario serán gestionadas por el gerente del proyecto
y el arquitecto de software.
Este proceso consta como anexo al framework.
CONFIGURACIÓN
2.5.1 Comité de Control de Cambios (CCC)

El Comité de Control de Cambios (CCC) es el responsable de procesar las solicitudes de cambio
que afectan a ítems bajo línea base. El CCC solicitará opiniones a los GPIs afectados por el
cambio y priorizará las decisiones basados en éstas opiniones.
La estructura y uso del CCC se realiza basados en el equilibrio de un nivel de control apropiado y
la minimización de burocracia.
El CCC estará conformado como mínimo por los siguientes miembros:
 Auspiciante ejecutivo del proyecto;
 Auspiciante técnico del proyecto;
 Gerente de proyecto;
 Arquitecto de Software;
 Representantes de los GPIs afectados por las solicitudes de cambio;
El propósito que persigue el CCC en el contexto de desarrollo de software es priorizar y

seleccionar las solicitudes de cambio a ser gestionadas en una iteración específica de desarrollo.
2.5.2 Solicitudes de Cambio vs. Defectos (No Conformidades)

Aún cuando los defectos reportados o los cambios que surgen para resolver una no conformidad
determinada no requieren aprobación del CCC, estos deben ser conocidos y priorizados por el
CCC. En caso de que no sean aprobados, el equipo técnico tiene la opción de apelar para su
priorización.
Triage
Para efectos del análisis de la solicitud de cambio, en consideración de que el cambio afectará el
calendario, los costes o las características funcionales a incluir en el alcance, y que se debe
priorizar la asignación de los escasos recursos; se aplica el concepto de triage para que los
cambios que parecen ser desesperadamente necesarios, de vida o muerte para el proyecto,
sean incluidos en la siguiente iteración. Algunas características no serán implementadas, o
algunos defectos de baja prioridad incluso no serán corregidos. Se prioriza los aspectos que son
críticos para el éxito del proyecto, dejando aquellos que son de baja prioridad o bien resultan
insalvables.
Paquete combo
El CCC puede agrupar pequeños cambios de modo que el equipo de desarrollo los resuelve en
paquete combo. Esto evita que el equipo de gestión y desarrollo se distraiga planificando y
resolviendo pequeños cambios. Así se agrupan las solicitudes de cambio aprobadas y agrupadas
en grupos en lugar de tratarlos uno a la vez.
CONFIGURACIÓN
Para cada librería identificada controlada, se debe aplicar los controles impuestos en las líneas
base de los ítems de configuración.
Las actividades de control de configuración piden, evalúan, aprueban o desaprueban, e

implementan cambios a las líneas base de ítems de configuración. Los cambios incluyen
corrección de errores, mejoras y evoluciones incrementales. El grado de formalidad necesaria
para los procesos de cambio depende de los ítems de configuración afectados y en el impacto
del cambio dentro de la estructura de la configuración.
Identificar los registros a ser utilizados para controlar y documentar esta secuencia de pasos
para cada cambio. Documentar explícitamente cualquier diferencia en el manejo del cambio
basado en el origen de la petición.
El control de configuración debe cubrir lo siguiente:
 Identificación y documentación de la necesidad de cambio;
 Análisis y evaluación del pedido de cambio;
 Aprobación o desaprobación del pedido;
 Verificación, implementación y liberación de cambios;
 Control de código fuente;
 Planificación de líneas base;
 Planificación de liberaciones;
2.3 Rendición de Cuenta y Reporte del Estado de la Configuración

Las actividades de rendición de cuenta y reporte del estado de la configuración registran y
reportan el estado de los ítems de configuración del proyecto. Esta sección debe resolver o
especificar lo siguiente:
 Información requerida a ser controlada y reportada en líneas base y cambios;
 Tipos de reporte de rendición de cuenta de estado a ser generada y su frecuencia;
 Información a ser recolectada, almacenada, procesada y reportada;
 Requerimientos de seguridad de los datos a ser controlados;
 Versión inicial aprobada de los ítem de configuración;
 Requerimientos de control de estado de las peticiones de cambio a los ítems de

configuración;
CONFIGURACIÓN
 Estado de implementación de cambios aprobados a los ítems de configuración;
 Documentación utilizada para certificar que los ítems de configuración del proyecto están
listos para liberar, revisión técnica o aprobación;
 Documentación de los registros de estado utilizados para indicar la liberación, revisión,

calendarios de aprobación y estado de los ítems de configuración.
2.4 Auditorías y Revisiones de Configuración

Identificar las auditorías y revisiones de configuración a llevarse a cabo en los ítems de
configuración del proyecto. Una auditoría de configuración se puede llevar a cabo en un ítem de
configuración previo a su liberación o después.
Las auditorías de configuración determinan en que grado el ítem de configuración actual refleja
las características físicas y funcionales requeridas. Las revisiones de configuración son
herramientas de gestión para establecer una línea base.
Como mínimo, se deben llevar a cabo las siguientes auditorías y revisiones:
 Auditoría a la configuración física, realizada previo a la liberación;
 Revisión a la configuración física, realizada previo a la liberación;
 Auditoría a la configuración funcional, realizada previo a la liberación;
 Revisión a la configuración funcional, realizada previo a la liberación;
Una auditoría a la configuración física se lleva a cabo para verificar que un ítem de configuración,
tal cual está, guarda conformidad con la documentación técnica que lo define. Una auditoría a la
configuración física típicamente realiza un inventario para analizar y asegurar que solo los
componentes de código, ficheros, datos de configuración y documentación pertinente están
contenidos en la configuración.
Una auditoría a la configuración funcional se lleva a cabo para verificar que el desarrollo de un
ítem de configuración ha sido terminado satisfactoriamente, que el ítem ha logrado el
desempeño y las características funcionales especificadas en los requerimientos, y que los
documentos operacionales y de soporte son completos y satisfactorios.
Para cada auditoría o revisión de configuración planificada, especificar:
 Propósito;
 Ítems de configuración bajo auditoría o revisión;
 Calendario de las tareas de auditoría o revisión;
 Procedimientos para llevar a cabo la auditoría o revisión;
CONFIGURACIÓN
 Participantes por título de de trabajo;
 Documentación requerida que debe estar disponible para el análisis o revisión, o para
soportar la auditoría o revisión;
 Procedimientos/requerimientos para registrar los resultados de auditorías;
 Criterios de aprobación y acciones específicas una vez aprobados.
2.5 Control de Interfaces

Las actividades de control de interfaces coordinan los cambios de los ítems de configuración del
proyecto con los cambios para interfacear ítems fuera del alcance del proyecto. Se debe
examinar de efectos potenciales de interfaces con hardware, software, firmware, datos,
interacción de usuario y documentación.
Identificar los ítems externos con los cuales los ítems de configuración del proyecto se
interfacearán. Para cada interfaz definir:
 Naturaleza de la interface;
 Organizaciones afectadas;
 Como será controlada la interfaz del ítem de configuración relevante;
 Como serán aprobados los documentos de control de interface y liberados en líneas

base específicas.
Identificar las responsabilidades y procedimientos para controlar las interfaces por parte del
comité de control de cambios.
2.6 Control de Proveedores

Definir las actividades para incorporar los ítems de configuración adquiridos y los ítems de
configuración sobre los cuales los proveedores tienen responsabilidad. Incluir las actividades
para la coordinación de cambios a estos ítems con las organizaciones apropiadas.
Describir los ítems de configuración sobre los cuales los proveedores tienen responsabilidad.
Incluir en la descripción:
 Que requerimientos de gestión de la configuración del proyecto serán parte del acuerdo
o contrato con el proveedor;
 Como el vendedor será monitoreado en cuanto a conformidad;
 Que auditorías y revisiones de configuración se llevarán a cabo;
 Como serán probados, verificados, aceptados y unidos los ítems de configuración con
otros ítems de configuración del proyecto;
CONFIGURACIÓN
 Como serán manejados los ítems propietarios en cuanto a seguridad y trazabilidad de

propiedad (Ej: copyright);
 Como serán procesados los cambios, incluyendo la participación del proveedor.
Describir los ítems de configuración adquiridos. Incluir:
 Como se revisarán, probarán y colocarán bajo gestión de la configuración los ítems de

configuración;
 Como los cambios en los ítems de configuración serán gestionados;
 Cuando y como participará el proveedor en el proceso de gestión de la configuración.
Sección 3 Glosario
Definir todos los términos y acrónimos requeridos para interpretar el plan de gestión de la
configuración apropiadamente.
Sección 4 Control de Cambios

Identificar los cambios realizados al plan de gestión de las comunicaciones.
Sección 5 Anexos
Incluir cualquier anexo relevante.

CM Instrucciones 10PGCONF 1.0

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

CM Instrucciones 10PGCONF 1.0

Hochgeladen von

Copyright:

Verfügbare Formate

MAS TE R E N I NGE NI E RÍ A DE SO FTWARE

UNIVERSIDAD POLITÉCNICA DE CATALUNYA

PROYECTO FINAL DE MÁSTER – MRF FRAMEWORK

Versión 1.0 ● 30 SEP 2008

Uso del Plan de Gestión de la Configuración........................................................1

Sección 1 Estrategia de Gestión de la Configuración.........................................2

Sección 2 Actividades de Gestión de la Configuración.......................................3

2.1 Identificación de la Configuración......................................................3

Sección 4 Control de Cambios...........................................................................8

El plan de gestión de la configuración incluido en el framework MRF permite establecer un

Uso del Plan de Gestión de la Configuración

El plan de gestión de la configuración es ejecutado a lo largo de la vida del proyecto para

El gerente de proyecto es responsable de asegurar que el plan de gestión de la configuración

Sección 1 Estrategia de Gestión de la Configuración

1.2 Definición de Roles

Adicionalmente a los roles individuales, actividades y habilidades requeridas, identificar los

1.3 Políticas, Directivas y Procedimientos

1.4 Herramientas, Entorno e Infraestructura

En los hitos de la gestión de la configuración, incluir el establecimiento de las líneas base de

Sección 2 Actividades de Gestión de la

Algunos de los aspectos a ser gestionados incluyen:

 Asegurarse que en el plan de gestión del proyecto se haya contemplado recursos a un

 Delegación explícita de actividades de gestión de la configuración a líderes apropiados;

 Asignar un gerente de configuración dedicado a proyectos con necesidades de gestión

 Establecer el Comité de Control de Cambios (CCC) y establecer un procedimiento para

 Definir un esquema de versionamiento que satisfaga el ciclo de vida del proyecto;

 Utilizar la trazabilidad para verificar la consistencia entre diferentes tipos de artefactos

2.1 Control de Revisiones

2.1 Identificación de la Configuración

2.1.1 Ítems de Configuración

Los ítems de configuración se clasifican en:

2.1.2 Convención de Nomenclatura de Ítems de Configuración

Identificación de ítems en evolución

El número de revisión cambia cuando el contenido ha cambiado, pero la estructura principal y el

Archivos ejecutables y de soporte

El número de revisión es actualizado cuando se añade nuevas características, funcionalidad y

El carácter de actualización se incrementa cuando el único cambio al ítem de software es

Identificación de ítems fuente

Esto se maneja en base a la herramienta de gestión de la configuración utilizada, o de las

Identificación de ítems de soporte

Identificación de ítems de archivo

Los ítems de archivo son documentos misceláneos de soporte y registros de comunicaciones

2.2 Ciclo de Vida de Artefactos Controlados y Líneas Base

2.2.2 Líneas Base

 Eventos que crean una línea base;

 Ítems que serán controlados en la línea base;

 Procedimientos utilizados para establecer y modificar las líneas base;

 Autorización requerida para aprobar líneas base;

Línea Base Evento/Hito Ítems de configuración

Línea Base Funcional

Línea base de planificación Fin de Fase de Planificación,  Business case y análisis de

Líneas Base de Instanciación

Línea base de Fin primera iteración de  Especificación de Requerimientos;

Configuración durante el desarrollo

Línea base de diseño Última iteración de concepción  Diseño preliminar;

Línea base de construcción Al final de cada iteración  Especificación de casos de prueba;

Línea base de integración y Al final de la última iteración de  Resultados de las pruebas de

Línea Base de Producto

Línea base de aceptación y Al final de la fase de ejecución,  Software;

2.3 Librerías Controladas

2.3.1 Librería Principal

Gerente de la Configuración (Puede ser rol dedicado o rol compartido).

 Línea base de planificación;

 Línea base de especificación de requerimientos;