1. La gestión de la configuración del software es importante para controlar los cambios en el software a lo largo de su ciclo de vida y maximizar la productividad. 2. Se identifican los elementos de configuración, como el código fuente y la documentación, y se controlan los cambios realizados mediante líneas base y versiones. 3. Las herramientas de control de versiones ayudan a crear, identificar y almacenar nuevas versiones de los elementos de configuración para facilitar el desarrollo del software.

1. Wilson Tineo
Ledwin R. Valdez C.
Francisco Cáceres

2.  Archivos perdidos: “se que lo escribí, pero no
se dónde lo puse ...”
 Referencias perdidas: “solía funcionar, pero
usa librerías que ya no están ...”
 Sobrescribir el código de otro:
desarrolladores que hacen distintos cambios
en el mismo código sobrescribiendo su
trabajo mutuamente.
 No hay botón deshacer: los nuevos cambios
son peores, pero no se puede volver atrás ...

3.  ¿Qué versión tiene el cliente? ¿A cuál
corresponde el error?
 La versión actual del código se sobrescribe
por una anterior.
 Una actualización crítica se descarta de la
versión final.
 Se hacen cambios a una versión incorrecta del
código.
 Reaparecen errores ya corregidos.
 No se logra determinar qué versiones de
archivos van en una entrega.

4. Gestión de la Configuración del Software
 Actividad constante aplicada durante todo el
proceso de ingeniería de software para
identificar, organizar y controlar las
modificaciones que sufre el software.

5. SCM Software Configuration
Management
 “Es el conjunto total de actividades utilizadas
para administrar el contenido de un producto
de software desde el principio hasta el final
del proceso de desarrollo.” “Es la disciplina de
administrar y controlar los cambios en la
evolución de los sistemas de software”

6. Preguntas en el GCS:
-¿Cómo identificar las muchas versiones de un
programa y su documentación
eficientemente?
-¿Cómo controlar la organización de cambios
antes y después de la distribución?
-¿Quién es el responsable de aprobar y asignar
prioridades a los cambios?
-¿Cómo garantizar que los cambios se han
hecho eficientemente?
-¿Qué mecanismos se usan para avisar a otros
de los cambios realizados?

7.  En términos muy generales, la Gestión de
Configuración del Software (GCS) se puede
definir como una disciplina cuya misión es
controlar la evolución de un sistema software.

8.  Según Babich, “El arte de coordinar el
desarrollo de software para minimizar la
confusión, se denomina Gestión de
Configuración. La Gestión de Configuración
es el arte de identificar, organizar y controlar
las modificaciones que sufre el software que
construye un equipo de programación. El
objetivo es maximizar la productividad
minimizando los errores.”

9. ¿Qué papel juega la Gestión de Configuración
dentro de un Proyecto de Desarrollo de Software?
El éxito de un proyecto depende de la correcta
ejecución de 4 tipos de funciones:
Gestión del Proyecto: incluye
fundamentalmente la Estimación, Planificación y
Seguimiento del proyecto, y la Organización,
Dirección y Gestión de Recursos Humanos.
Desarrollo Técnico: Actividades de Ingeniería
del Software a lo largo de todo el ciclo de vida del
producto (Análisis, Diseño, Codificación).
En resumen, la Gestión de Configuración es una
disciplina de control, dentro del proyecto.

10. - Establecer y mantener la integridad de los
productos generados durante un proyecto de
desarrollo de software y a lo largo de todo el
ciclo de vida del producto.
- Evaluar y controlar los cambios sobre ellos,
es decir, controlar la evolución del sistema
software.
- Facilitar la visibilidad sobre el producto.

11.  Para conseguir estos objetivos, la Gestión de
Configuración plantea la realización de
ciertas actividades. La definición estándar de
Gestión de Configuración del Software, tal y
como aparece en el estándar de IEEE, incluye
las siguientes actividades:

12. - Identificación de la Configuración:
Consiste en identificar la estructura del
producto, sus componentes y el tipo de
estos, y en hacerlos únicos y accesibles de
alguna forma.
- Control de Cambios en la
Configuración: Consiste en controlar las
versiones y entregas de un producto y los
cambios que se producen en él a lo largo del
ciclo de vida.

13. - Generación de Informes de Estado:
Consiste en informar acerca del estado de los
componentes de un producto y de las
solicitudes de cambio, recogiendo
estadísticas acerca de la evolución del
producto.
- Auditoría de la Configuración: Consiste
en validar la completitud de un producto y la
consistencia entre sus componentes,
asegurando que el producto es lo que el
usuario quiere.

15.  Los sistemas que automatizan la gestión de
configuración suelen incluir algunas
funciones adicionales, lo que nos lleva a
ampliar la definición estándar con las
siguientes actividades:
- Construcción: Consiste en gestionar la
compilación y enlazado de los distintos
componentes del producto software de una
forma lo más eficiente posible.

16. - Control del Trabajo en Equipo: Consiste en
controlar las interacciones que se producen entre
los múltiples desarrolladores de un producto,
sobre todo cuando deben compartir ciertos
componentes del producto.
- Control de Versiones: Consiste en mantener
un registro histórico de las diferentes versiones
por las que pasan los componentes de un
producto, que permita la recuperación de
cualquiera de ellas.
- Gestión de Problemas: Consiste en realizar
un seguimiento de la evolución de los problemas
que afectan al producto.

17. - Número elevado de componentes a
controlar: A medida que progresa el proceso de
desarrollo de Software el número de componentes
crece rápidamente.
- Pero el problema realmente surge porque
en el proceso toma parte otra variable: el
CAMBIO. Como dice la ley de la Ingeniería de
Sistemas de Bersoff,
“sin importar en qué momento del ciclo de vida
del sistema nos encontremos, sistema informático
cambiará, y el deseo de cambiarlo persistirá a lo
largo de todo el ciclo de vida”.

18. La Gestión de Configuración está también
fuertemente relacionada con el problema del
mantenimiento del software.
Sin una buena Gestión de Configuración, el
mantenimiento de un producto puede ser una
verdadera pesadilla.

19. Tiene también una gran influencia sobre otros
aspectos del desarrollo de software, como son:
-Las metodologías: Las actividades de
Gestión de Configuración deberán integrarse
con la metodología de desarrollo que utilice la
empresa. Su planificación dependerá de las
fases que establezca la metodología, los
productos que se generen, etc.

20. - El entorno de desarrollo de software:
cómo fuertemente integrada está la gestión de
configuraciones con el resto de las capacidades
del entorno de desarrollo, y qué tipo de
funciones de Gestión de Configuración permite.
- El modelo de proceso software: puesto que
afecta a la forma en que los desarrolladores
hacen su trabajo, imponiendo políticas y
procedimientos, y supervisando la forma en que
se realiza este trabajo. La Gestión de
Configuración desempeña un papel importante
a la hora de conseguir incrementar el nivel de
madurez del proceso software de una
organización.

21. - La calidad del producto software:
puesto que contribuye a mantener la
integridad del producto.
- La organización: puesto que por lo general
se suele implantar una solución global, que
afecta a toda la organización, y requiere del
establecimiento de nuevos roles y
responsabilidades que deberán integrarse en
la organización del proyecto.

22. Al conjunto de toda la información y productos
utilizados o producidos en un proyecto como
resultado del proceso de Ingeniería de Software
se le denomina CONFIGURACIÓN DEL
SOFTWARE.

23. A cada uno de los componentes de la
configuración del software se le va a llamar
ELEMENTO DE CONFIGURACIÓN DEL SOFTWARE
(ECS). El ECS es la unidad de trabajo para la
GCS.
El término CONFIGURACIÓN DEL SOFTWARE
designa, por tanto, el conjunto de todos los
elementos de configuración del software de un
proyecto.

24. Se pueden considerar como Elementos de
Configuración del Software los siguientes
componentes:
 1. La especificación del sistema.
 2. El plan del proyecto software.
 3. La especificación de requisitos software.
 4. Un prototipo, ejecutable o en papel.
 5. El diseño preliminar.
 6. El diseño detallado.
 7. El código fuente.
 8. Programas ejecutables, entre otros

25. Como ya hemos visto, uno de los objetivos
principales de la Gestión de Configuración va a
ser el de gestionar los cambios que se
producen en el sistema a lo largo de su ciclo de
vida.
Para controlar los cambios sin impedir los
cambios justificados se utiliza el concepto de
LÍNEA BASE o “BASELINE”.

26. Se puede definir una VERSIÓN como una
instancia de un elemento de configuración, en
un momento dado del proceso de desarrollo,
que es almacenada en un repositorio, y que
puede ser recuperada en cualquier momento
para su uso o modificación.
A las distintas versiones que aparecen en el
tiempo, según se va avanzando en el desarrollo
de un elemento, se les suele llamar también
REVISIONES.

27. Entre las distintas revisiones de un elemento de
configuración se pueden establecer relaciones
de sucesión temporal.
Una representación posible para las diferentes
revisiones de un elemento y sus relaciones de
sucesión es mediante un GRAFO DE EVOLUCIÓN
o grafo de revisión.

28.  La manera más fácil de crear una nueva
revisión de un ECS es realizar una
modificación sobre la revisión más reciente.
De esta manera las revisiones van formando
una cadena, a la que se suele llamar CADENA
DE REVISIÓN. Cada revisión en la cadena es
una actualización de, y viene a sustituir a la
revisión anterior. Normalmente se trabajará
sobre la última revisión de la cadena, que es
la más actual, aunque las anteriores también
deben ser accesibles.

29. Cada una de las revisiones de un ECS se debe
poder identificar de manera única, siendo
común utilizar un esquema numérico, donde
cada nueva versión recibe un número sucesivo.

30. La Gestión de Configuración debe permitir
también especificar y gestionar distintas
VARIANTES de los elementos de configuración.
Las variantes son versiones de un elemento de
configuración que coexisten en un
determinado momento y que se diferencian
entre sí en ciertas características.
Una variante no reemplaza a otra, como ocurre
con las revisiones.

32. Las variantes pueden ser temporales o
permanentes. Variante temporal es toda aquella
que se acabará mezclando con otra variante en
algún momento del desarrollo.
En ciertas ocasiones es necesario que varias
personas trabajen simultáneamente sobre la
misma versión de un objeto, y para que no
ocurran conflictos entre ellas, se crea una
variante distinta para cada persona, para que
puedan trabajar en paralelo.

33.  Una vez que todas ellas han acabado las
modificaciones, es necesario mezclar todas
las variantes para que la versión resultante
contenga todos los cambios realizados. Las
variantes temporales deben evitarse, y en
todo caso mezclarse lo antes posible, ya que
a medida que pasa el tiempo divergirán más
de la versión original y entre sí, y resultará
más difícil su fusión.

34. Por otro lado, las variantes permanentes
aparecen para dar respuesta a conjuntos
distintos de requisitos, y tampoco se llegarán a
mezclar entre sí. Podemos dividir este tipo de
variantes en dos categorías:
Variantes de requisitos de usuario:
Tenemos distintos usuarios con distintos
requisitos. El caso más típico es el idioma
usado por estos.
Variantes de plataforma: Debemos realizar
una variante por cada sistema operativo o
plataforma hardware sobre la que deseemos
que funcione nuestra aplicación.

35. Una posibilidad es almacenar únicamente la
última versión de cada uno de los ECS del
sistema, pero esto puede plantearnos
numerosos problemas.
Las herramientas de control de versiones o
gestión de revisiones nos ayudan a crear,
identificar y almacenar nuevas versiones, al
mismo tiempo que se mantienen las versiones
anteriores.

36. El modelo de trabajo sobre el que se basan la
mayoría de las herramientas de gestión de
revisión es el de la figura:

37. Las herramientas de control de versiones
utilizan maneras más eficientes para almacenar
las versiones, para disminuir la cantidad de
espacio requerido.
Normalmente estas herramientas no almacenan
físicamente todas las versiones, sino solamente
una de ellas, que puede ser la primera o la
última. Sin embargo, nos permiten recuperar
cualquier otra versión.

41.  1 Introducción (dos párrafos).
 2 Gestion de la configuracion:
 3 Aspectos organizacionales y legales.
 4 Organigrama y responsabilidades.
 5 Flujo de trabajo y procedimientos.
 6 Control de calidad.
 7 Descripción de actividades:
 8 Identificación de ítems.
 9 Gestión de cambios.
 10 Gestión de entregas.

42.  11 Auditorias: base de datos de la
configuración.
 12 Planificación temporal.
 13 Recursos: humanos, físicos y
herramientas.
 14 Mantenimiento y actualización del plan
(medidas).

48.  Angelica Antonio, Gestion de la Configuracion, D
 M. Ben-Menachem, Software Configuration Management Guidebook, McGraw-Hill
 Book Company, 1994
 Bryan, W., Chadbourne, C., Siegel, S., Software Configuration Management, IEEE
 Computer Society Press, 1980.
 Compton, Stephen B. Conner, Guy R., Configuration Management for Software; edited
 by Joan R. Callahan, New York : Van Nostrand Reinhold, 1994.
 Dart, S., Tool Configuration Assistant, Second International Software Configuration
 Management Workshop, ACM SIGSOFT Software Engineering Notes, Octubre 1989.
 Dart, S. and Feiler, P., Configuration Management in CASE Tools and Environments,
 Third International Workshop on Computer-Aided Software Engineering (CASE 89),
 IEEE Computer Society, Julio 1989.
 Dart, S. A., The Past, Present and Future of Configuration Management, Proceedings
 of the IFIP World Congress, Madrid, Spain, Septiembre 1992.
 Krane, Steven P. Modeling the Configuration Management process, University of
 Colorado, Boulder, Dept. of Computer Science, 1989.
 SEI Bridge, Configuration Management: State of the Art, Software Engineering
 Institute, Carnegie-Mellon University, Marzo 1990.
 Tichy, W., Design, Implementation and Evaluation of a Revision Control System, 6th
 International Conference on Software Engineering Tokyo, Septiembre 1982, pp. 58-67.

49.  [Babich, 86], W. Babich, Software Configuration Management, Addison-
Wesley,
 1986
 [Berlack, 92], H.R. Berlack, Software Configuration Management, John Wiley &
 Sons, 1992
 [Bersoff, 80a], E.H. Bersoff, V. Henderson, S. Siegel, Software Configuration
 Management: An Investment in Product Integrity, Prentice-Hall, 1980
 [Bersoff, 80b], E.H. Bersoff, V. Henderson, S. Siegel, Software Configuration
 Management: A Tutorial, IEEE Computer Society Press, 1980
 [Bersoff, 84], E.H. Bersoff, Elements of Software Configuration Management, IEEE
 Transactions on Software Engineering, Vol. SE-10, Nº 1, pp. 79-87, Enero,
1984
 [Bersoff, 91], E.H. Bersoff, A.M. Davis, Impacts of Life Cycle Models on Software
 Configuration Management, Communications of the ACM, Vol. 34, Nº 8, pp.
104-
 117, Agosto, 1991

50.  [Buckley, 95], F.J. Buckley, Implementing Configuration Management: hardware,
 Software, and Firmware, 2ª edición, IEEE Computer Society, 1995
 [Conde, 86], D. Conde, Bibliography on Version Control and Configuration
 Management, ACM SIGSOFT Software Engineering Notes, Vol. 11, Nº 3, pp.
81-84,
 Julio, 1986
 [Harvey, 86], K.E. Harvey, Summary of the SEI Workshop on Software
 Configuration Management, Technical Report CMU/SEI-86-TR-5, Software
 Engineering Institute, Carnegie Mellon University, Pittsburgh, Diciembre, 1986
 [Humphrey, 89], W.S. Humphrey, Managing the Software Process, SEI Series in
 Software Engineering, Addison Wesley, 1989
 [Pressman, 93], R. Pressman, Ingeniería del Software, 3ª edición, McGraw-Hill, 1993
 [Tichy, 88], W.F. Tichy, Tools for Software Configuration Management, Proceedings
 of the International Workshop on Software Version and Configuration
Control,
 pp. 1-20, Grassau, Alemania, Enero, 1988
 [Whitgift, 91], D. Whitgift, Methods and Tools for Software Configuration
 Management, John Wiley & Sons, 1991
 Ingenieri ade Software II, Pablo Sanchez Barreiro, DPTO. DE MATEMÁTICAS, ESTADÍSTICA
Y
 COMPUTACIÓN