1. |
Instituto Politécnico Nacional
Unidad Profesional Interdisciplinaria en
Ingeniería, Ciencias Sociales y
Administrativas
Gestión de la configuración del software
Fuentes Aguilar Hugo
Galindo González Adrián
García Martínez Marco Antonio
Martínez Alonso Jair Israel
Coordinador: García Martínez Marco Antonio
Jueves 19 de Marzo del año 2014

2. Índice
Propósito de la Gestión de Configuración de Software
Roles en el SCM
Algunas terminologías
Configuration item
Versión
Variante
Baseline
Directorios SCM
Revisión
Liberación
Herramientas para la gestión de configuración de software
Conclusión
Fuentes:

3. Introducción
Con el transcurso de la evolución de los sistemas informáticos, se ha encontrado que
cada vez estos se vuelven más complejos y cambiantes con el paso del tiempo,
obligando a quienes se ven involucrados en el desarrollo de dichos sistemas a seguir
una estructuración organizacional que permite el avance ágil de dichos desarrollo que
no solo brinda calidad sino también tiene un alto impacto en la tasa de errores
producidos, a lo largo de este documento, encontraremos las bases que orientarán al
alumno hacia una mejor comprensión y acercamiento a la gestión de configuración de
software un proceso que hoy en día en cualquier proyecto de desarrollo de software se
encuentra implícito.

4. Propósito de la Gestión de Configuración de Software
Constantemente se presentan problemas al desarrollar un software debido a la
complejidad que este puede llegar a obtener, encontrarse frente a un software que se
encuentra en constante cambio junto a un gran equipo de trabajo puede ser uno de
ellos, así también como las diferentes versiones que pueden encontrarse en dicho
software lo cual representa que podremos encontrar desde una versión de software
que corre en una máquina específica hasta en un diferente sistema operativa, por ello
surge la necesidad de tener coordinación y orden, la necesidad de la gestión de
configuración de software que es capaz de manejar software que evoluciona
constantemente y mantener control de los costos involucrados en este.
El propósito principal de la gestión de configuración de software es planear,
organizar, controlar y coordinar la identificación, almacenamiento y cambio del
software a través de su desarrollo, integración y transferencia. Podemos decir que
para cada proyecto se deberá establecer un SCM (Software Configuration
Management). El SCM se encarga de asegurar en grandes rasgos lo siguiente:
● Los elementos del software puedan ser identificados.
● Que el software es construido en módulos de componentes.
● Que cada componente del software sea accesible y se encuentre disponible.
● Que los componentes del sistema nunca se pierdan, por cualquier
circunstancia.
● Que cada cambio en el software sea documentado y aprobado.
● Que ningún cambio sea perdido.
● Que siempre exista la posibilidad de regresar a una versión previa.
● Que se almacena un historial de cambios, para así poder descubrir ¿Que?,
¿Quien?, ¿Como? y ¿Cuando? se ha realizado dicho cambio.
Dentro del SCM existen diferentes roles a cubrir y el administrador de proyecto es el
responsable de organizar la SCM, este requiere una precisa identificación de cada
elemento del sistema, el control, su estatus y el monitoreo del progreso, así como
también la capacidad de definir los diferentes roles que son ejercidos en el SCM

5. El SCM tiene un gran impacto sobre la calidad ya que esta es primordial para un
eficiente desarrollo y mantenimiento, ya que asegura que el software nunca tendra
ningun tipo de percance, por lo general una mala configuración de software representa
amenazas que pueden llegar a retrasar o incluso congelar un proyecto.
Roles en el SCM
Administrador de Configuración
Es el responsable de identificar todos los “Configuration items”, él es el encargado de
definir los procesos para desarrollo y releases.
Miembro de control de cambios
Es el responsable de aprobar o reprobar cambios sugeridos.
Desarrollador
Es el encargado de ejecutar cambios que han sido aprobados y también las
actividades normales de desarrollo. El desarrollador revisa los cambios y resuelve
conflictos.
Auditor
Responsable de la selección y evaluación de avances para el release final y
asegurarse de la consistencia y que el software se encuentre completo para dicho
release
Entonces formalmente como ha sido definido en ANSI/IEEE Std 610.12­1990, es la
disciplina de aplicar direción técnica y administrativas para:
● Identificar y documentar las características funcionales y físicas de los
elementos de configuración.
● Controlar cambios en esas características.
● Mantener un historial de cambios en procesos e implementaciones

6.
Estándar ANSI/IEEE Std 610.12-1990
Ricardo Guzmán (2012) menciona lo siguiente:
El estándar IEEE 828 define la información mínima requerida para llevar un
Plan de Gestión de la Configuración del Software
Administración GCS (¿Quien?)
Identifica las responsabilidades y autoriza llevar a cabo las actividades
planeadas
Matriz de responsabilidades
Organización Responsabilidades Políticas, directivas y procedimientos
aplicables.Impacto y efecto
Actividades GCS (¿Qué?)
Identifica toda actividad para ser realizada en la aplicación del proyecto
Son 6 las actividades definidas por el estándar
● Identificación de la configuración (Referenciar, identificar y Biblioteca)
● Elementos de la configuración
● Identificadores Únicos
● Biblioteca de la configuración
● Control de configuración (Control de cambio y versiones)
● Requerimientos
● Evaluación
● Aprobación o Desaprobación
● Implementación
Seguimiento de estatus y revisiones (Reportes)
● Definir EC para su seguimiento
● Tipo de reporte y frecuencia
● Cantidad de información extraída, almacenada, procesada y reportada.
● Cantidad de accesos a usuarios de reportes

7.
Auditoría de configuración (Revisiones)
● Objetivo
● Elementos de Control
● Calendario
● Procedimiento
● Participantes
● Documentación
● Criterios
Control de interfaces (Control de Interactividad con elementos externos
e internos)
● Naturaleza de la interfaz
● Organización involucrada
● Cantidad de código, documentación y datos en interfaz deben ser
controlados
● Cantidad en control de interfaz están aprobados y liberados en una línea
base específica
Control de proveedores / arrendadores (Control sobre derechos de
autor)
● Software Subcontratado
● Software Adquirido
Cronograma GCS(¿Cuándo?)
● Identifica la coordinación requerida de las actividades de GCS con el
resto de las actividades en el proyecto
● Secuencia
● Dependencia
● Hitos y eventos
● Fechas Absolutas y relativas
● Fechas Inicio y conclusión

8.
Recursos GCS(¿Cómo?)
● Identifica las herramientas y fuentes físicas y humanas necesarias para
la ejecución del Plan
● Herramientas de software
● Técnicas
● Equipo
● Personal
● Entrenamiento
Mantenimiento del plan GCS
● Identifica como el Plan será conservado durante sus efectos
● Responsable para monitorear el Plan Frecuencia de actualizaciones
realizadas
● Cantidad de modificaciones para el Plan a evaluar y aprobar
● Cantidad de modificaciones para el Plan a realizar y publicar
Algunas terminologías
Para el entendimiento de todo lo referente a la configuración de software
introduciremos el significado de ciertas terminologías, que si bien no son tecnicismos
muy complejos, si pueden inferirse definiciones erróneas de las mismas.
Además trataremos éstos ejemplos de terminologías están regidos por el estándar
IEEE.
Configuration item
Iniciaremos definiendo “Configuration item”; puede ser un agregado de hardware,
software o ambos. Se le establece a la gestión de la configuración y su rol es de
entidad única en el proceso de gestión de la configuración. También puede ser un
agregado de otros CIs (Configuration items) estructurados por jerarquías.

9.
Selección de CIs:
➔ Requirement Analysis Document (RAD)
➔ System Design Document (SDD)
➔ Object Design Document (ODD)
➔ Unit tests
➔ Source code
➔ Input data and data bases
➔ Test data
➔ Support software (parte del producto)
En la parte del software no sólo se trata de segmentos de código de programa, sino
también de todo tipo de documentos que conlleve desarrollo, estos pueden ser:
● Todo tipo de archivos de código
● Controladores para pruebas
● Documentos de análisis o diseño
● Manuales desarrollador o usuario
● Configuraciones del sistema (Versión del compilador usado).
Incluso en algunos sistemas, también se incluye “configuration item” del hardware
(CPU, frecuencia de velocidad de buses).
Los encargados de definir los “Configuration Item” son los Managers de configuración
(Configuration Managers en Inglés).
Para identificar CIs:
Se tiene identificador en cada CI (SCM06). Él mismo contiene nombre , tipo y
versiones atribuidas del CI. Se debe asegurar que todos los identificadores son
únicos.

10.
Un ejemplo estructurados de CIs:
Versión
Se le denomina versión a las publicación o re­publicación de un configuration item
relacionado con una completa compilación o recopilación del elemento.
Debido a lo mismo cada versión tiene su funcionalidad
Variante
El término le es acuñado a CIs que tienen casi la misma funcionalidad pero diferentes
aspectos como :
● Ambiente del hardware
● Protocolos de comunicación
● Lenguaje del usuario
Las variantes, también, pueden ser desarrolladas para detectar problemas de
software. Su Usabilidad es temporaria y serán eliminadas o descontinuadas una vez
arreglado el problema.

11. Baseline
Son CIs que se revisan y aprueban formalmente, y se les establece una rutina que se
implementara su futuro desarrollo. Solo se pueden cambiar con un control formal de
procedimientos de cambio.
Éste término sólo se usa para sistemas completos, a pesar de que cualquier CI
aprobado en un sistema puede ser llamado “Baseline”.
Directorios SCM
De estos directorios podemos discernir :
● Directorio del programador (Librería dinámica de IEEE); que sirve para
contener entidades de software modificadas o creadas ye indica que el
espacio de trabajo del programador sólo él lo controla.
● Directorio Maestro (Librería controlada de IEEE); que maneja baselines
actuales y los cambios hechos a ellas., su entrada es controlada y debe
autorizarse su cambio.
● Repositorio de software (librería estática de IEEE) : es el archivo para las
diferentes baselines que se liberan y son de uso general.
Revisión
Es la corrección de los errores ubicados en el diseño y código sin afectar la
funcionalidad documentada.
Liberación
Se dice de la distribución formal de alguna versión aprobada.

12. Actividades del SCM
La división de las actividades del se dividen de la siguiente forma:
http://www.inf.utfsm.cl/~visconti/iia431/Documentos/scm.pdf
Identificación de la configuración:
Consiste en identificar la estructura del producto, sus componentes y tipos, hacerlos
únicos y accesibles de alguna manera.
Esto se hace en dos actividades:
Identificación de los ítems de configuración.
Documentación.
La documentación deberá seguir un esquema de identificación adecuada y de esta
manera mantener la trazabilidad de los documentos. Dentro de estos se debe incluir,
historial de revisiones del mismo, quien la realizó, un resumen detallando los cambios
y quien los aprueba.
Nomenclatura de los ítems de configuración
Para la nomenclatura se utilizará la numeración de versiones, identificando con tres
dígitos, un ejemplo seria: V 1.2.3., donde el primer dígito (1) Indica la versión del
software, cambiando el segundo dígito, siempre que se agregue una función nueva(2)
y un tercer dígito cuando se incluyan nuevos fix o correcciones.

13.
Control de la configuración.
Diseñar un formulario de solicitud de cambio
Este formulario debe especificar los procedimientos para solicitar un baseline y la
información que debe ser documentada:
● Nombre (s) y version (s) del CI donde aparece el problema.
● Nombre y dirección del redactor
● Fecha de la petición
● Indicar la urgencia
● Indicar que se necesita cambiar
● Descripción del cambio solicitado
Evaluación de las solicitudes de cambio
Una vez que fue ingresada una nueva solicitud, se evalúa la prioridad asignada, el
análisis de impacto, verificando los recursos necesarios para la resolución de la
solicitud. Se estima según corresponda a un fix o una nueva funcionalidad, en qué
release se puede incluir, comunicando fecha estimada en la que el release estará
disponible.
Aprobación o Rechazo de los cambios.
Esta sección del SCMP describe la organización de la tarjeta de control de
configuración. (CCB)
La CCB:
● puede ser individual o grupal.
● Tiene múltiples niveles y estos son posibles dependiendo de la complejidad del
proyecto.
● para los proyectos pequeños un nivel de CCB es suficiente.

14. ● Esta sección del SCMP también indica el nivel de autoridad de la CCB y su
responsabilidad.
● En particular, el SCMP debe especificar cuando se invoca el CCB.
Implementando los cambios.
Esta sección del SCMP especifica las actividades de verificación y la implementación
de un cambio aprobado.
Una solicitud de cambio completo debe contener la siguiente información:
● La solicitud de cambio (s) original
● Los nombres y las versiones de los elementos de configuración afectados
● Fecha de verificación y responsable
● Identificador de la nueva versión
● lanzamiento o fecha de instalación y la parte responsable
Esta sección también debe especificar las actividades de:
● Archivamiento, completado las solicitudes de cambio
● Planificación y control de versiones
● ¿Cómo coordinar múltiples cambios?
● ¿Cómo añadir nuevos CIs a la configuración?
● ¿Cómo ofrecer una nueva baseline?
Informe de estado.
Esta sección del SCMP debe contener los siguientes factores.
● ¿Qué elementos han de ser objeto de informes de datos de referencia y los
cambios?
● ¿Qué tipos de informes contables de estado se generarán? ¿Cuál es su
frecuencia?
● ¿Cómo es la información que se recopile, almacene y reportado?

15. ● ¿Cómo es el acceso a los datos de estado de gestión de la configuración
controlada?
Auditorías y revisiones
Esta sección del SCMP identifica auditorías y revisiones para el proyecto.
Una auditoría determina para cada elemento de configuración si tiene las
características físicas y funcionales requeridas.
Una revisión es una herramienta de gestión para el establecimiento de una baseline.
Para cada auditoría o revisión el plan tiene que definir:
● Objetivo
● Los elementos de configuración que se examinan
● El calendario para el examen
● Los procedimientos para la realización del examen
● Los participantes por puesto de trabajo
● La documentación requerida
● Procedimiento para las deficiencias de grabación y cómo corregirlos
● Criterios para la aprobación
Herramientas para la gestión de configuración de software
La Gestión de la Configuración del Software (SCM) es un conjunto de actividades
diseñadas para identificar y definir los elementos en el sistema que probablemente
cambien, controlando el cambio de estos elementos a lo largo de su ciclo de vida,
estableciendo relaciones entre ellos, definiendo mecanismos para gestionar distintas
versiones de estos elementos, y auditando e informando de los cambios realizados.
Establecer y mantener la integridad de los productos de software a través del ciclo de
vida del proceso de software. Los requerimientos del sistema siempre cambian
durante su desarrollo y su uso, y se tienen que incorporar estos requerimientos en
nuevas versiones del sistema. ¿Por qué es importante? Los cambios incontrolados
aplicados a un proyecto de software lo llevan al fracaso.

16. Hay varias herramientas para la gestión de software como lo son:
RCV
Revision Control System o RCS es una implementación en software del control de
versiones que automatiza las tareas de guardar, recuperar, registrar, identificar y mezclar
versiones de archivos.
RCS es útil para archivos que son modificados frecuentemente, por ejemplo programas
informáticos, documentación, gráficos de procedimientos, monografías y cartas. RCS
también puede ser utilizado para manejar archivos binarios, pero con eficacia y eficiencia
reducidas.
RCS fue inicialmente desarrollado en la década de 1980 por Walter F. Tichy mientras
estaba en la Purdue University. Actualmente es parte del Proyecto GNU aunque es
mantenido por la Purdue University.
CVS
Concurrent Versions System o simplemente CVS, también conocido como Concurrent
Versioning System, es una aplicación informática que implementa un sistema de
control de versiones: mantiene el registro de todo el trabajo y los cambios en los
ficheros (código fuente principalmente) que forman un proyecto (de programa) y
permite que distintos desarrolladores (potencialmente situados a gran distancia)
colaboren. CVS se ha hecho popular en el mundo del software libre.
Características:
CVS utiliza una arquitectura cliente­servidor: un servidor guarda la(s) versión(es)
actual(es) del proyecto y su historial. Los clientes se conectan al servidor para sacar
una copia completa del proyecto. Esto se hace para que eventualmente puedan
trabajar con esa copia y más tarde ingresar sus cambios con comandos GNU.
Típicamente, cliente y servidor se conectan utilizando Internet, pero con el sistema
CVS el cliente y servidor pueden estar en la misma máquina. El sistema CVS tiene la
tarea de mantener el registro de la historia de las versiones del programa de un
proyecto solamente con desarrolladores locales. Originalmente, el servidor utiliza un
sistema operativo similar a Unix, aunque en la actualidad existen versiones de CVS

17. en otros sistemas operativos, incluido Windows. Los clientes CVS pueden funcionar
en cualquiera de los sistemas operativos más difundidos.
Actualmente existen muchas versiones de CVS implantadas en los diferentes
sistemas operativos.
Perforce
Sistema de control de versiones comercial, propietario y centralizado desarrollado por
Perforce Software, Inc.
Funciona en modo cliente/servidor. El servidor gestiona una base de datos central que
contiene uno o más repositorios (depots) con versiones de los ficheros. Los clientes
importan los ficheros del repositorio a su taller de trabajo (workspace) para trabajar en
ellos, y posteriormente los devuelven modificados agrupados en listas de cambio. La
conexión se realiza mediante TCP usando protocolos propietarios de RPC y
streaming.
Es posible configurar un conjunto de servidores en cluster, establecer un par de
servidores trabajando en modo master/réplica, y bien configurar un broker que
establezca reglas direccionamiento al servidor adecuado para los clientes.
Para aquéllos sitios remotos donde el ancho de banda es una limitación, el proxy de
Perforce media entre los clientes y el servidor y almacena las revisiones de ficheros
frecuentemente transmitidas. De este modo se reduce la demanda de ancho de
banda en servidor y la red.
Características:
● El servidor mantiene la historia completa de los metadatos y de los ficheros
● En servidor mantiene la historia completa de la historia de revisiones de
ficheros ramificados, renombrados, movidos, copiados y borrados
● El cliente realiza la fusión de ficheros a tres bandas (three­way text file
merging), realiza seguimiento de fusiones y previene las revisiones mediante
detección de ancestro común
● El cliente hace presentaciones gráficas de diferencias, fusiones y herramientas
de reconciliación
● Se presenta una visión gráfica de históricos y ramificaciones

18. ● El interfaz administrativo funciona de modo gráfico
● Soporte para control distribuido de versiones
● Listas de cambio: los ficheros modificados pueden agruparse y manejarse
como unidades lógicas
● Modificaciones atómicas: al servidor hace que las listas de cambio se
actualicen de manera indivisible
● Aparcamiento: se puede almacenar temporalmente el trabajo en curso para
cambiar de tarea
● Soporte para ficheros ASCII, Unicode, binario, enlaces simbólicos, específicos
de Mac y UTF­16
● Soporta internacionalización y localización
● Expansión de palabras clave estilo RCS
● Compresión de ficheros para transmisión y almacenamiento
● Un servidor Unix o Windows soporta clientes en cualquier sistema operativo
● Disparadores de eventos en el servidor
● SDK para integración con sistemas externos
● Envío de alertas de cambios mediante RSS o email
● Replicación de ficheros y metadatos
● Gestor para implementación de políticas locales, restricción de comandos o
redirección a servidores alternativos
● Paso de ficheros a histórico para liberar espacio en disco

19. Conclusión
Durante el proceso de construcción de software, los cambios son inevitables.
Estos provocan confusión e incertidumbre, sobre todo cuando no se han analizado o
pronosticado correctamente. La finalidad de la gestión y configuración del software es
conocer la estructura de procesos y herramientas para aplicar dentro de la
construcción del software que nos ayudan a controlar los cambios. Es importante
considerar ciertas modificaciones que pueden ocurrirle al software dentro de todo
proceso de ingeniería para asegurar su control y calidad.Además el SCM nos ayuda a
darle mantenimiento al software pues se documenta todo cambio, todo proceso que
este realiza, ayudando a realizar un mantenimiento más fluido y más sencillo.

20. Fuentes:
Universidad de Zurich [Documento en línea] 2004, Pearson education [Zurich, Alemania] <>
https://docs.google.com/file/d/0B58NZe9A7DSaTnZUTVVmeHNJMzQ/edit [Consulta:
17­03­2014]
Guzman, R.. (2012). IEEE 828 Plan de Gestión de la Configuración de Software. Marzo 18
del año 2014, de Academia.edu Sitio web:
http://www.academia.edu/1742459/IEEE_828_Plan_de_Gestion_de_la_configuracion_de_S
oftware
ESA Board for Software Standardisation and Control (BSSC) [Documento en línea] Marzo
1995, European space agency [Paris, Francia] <>
https://docs.google.com/file/d/0B58NZe9A7DSaQUpZWVZnY0x5QU0/edit [Consulta:
17­03­2014]
No especificado. (2011). Gestión de configuración del software. No especificado, de No
especificado Sitio web:
http://www.slideshare.net/JohanPrevotR/gestion­de­la­configuracion­del­software­10471407
No especificado. (No especificado). Gestión de configuración del software. No especificado, de
No especificado Sitio web:
http://www.kybele.etsii.urjc.es/docencia/IS4/2013­2014/Material/IS4.11.12.Tema.VIII.Gesti%C3
%B3n%20Configuraci%C3%B3n.pdf