1

ndice
Introduccin ......................................................................................................................................... 3
Captulo I: Ciclo de vida del Software .............................................................................................. 4
1.1.Evolucin del Software ............................................................................................................ 5
1.2.Ciclo de Vida y Modelos de Desarrollo ................................................................................... 5
1.2.1. Concepto de Ciclo de Vida ......................................................................................... 6
1.2.2. Procesos de Ciclo de Vida .......................................................................................... 6
1.2.2.1.Procesos Principales ............................................................................................ 6
1.2.2.2.Procesos de Soporte ............................................................................................ 7
1.2.2.3.Procesos generales .............................................................................................. 7
1.2.3. Modelos de Desarrollo ............................................................................................... 8
1.2.3.1.Modelos Tradicionales ........................................................................................ 8
1.2.3.1.1. Modelo de Ciclo de Vida Clsico (o en Cascada) .................................... 8
1.2.3.1.2. Prototipado evolutivo ......................................................................... 11
1.2.3.2.Modelos Alternativos ........................................................................................ 15
1.2.3.2.1. Modelos en Espiral ............................................................................. 15
Captulo II: Gestin de Configuracin del Software ..................................................................... 17
2.1.La Configuracin del Software ............................................................................................... 17
2.2.Lnea base y Elementos de Configuracin del software(ECS) ............................................... 18
2.2.1. Lnea base .................................................................................................................... 18
2.2.2. Elementos de Configuracin ....................................................................................... 19
Captulo 3: El Proceso de G.C.S ...................................................................................................... 21
3.1 Identificacin de Objetos en La Configuracin de Software .................................................. 21
3.2.Control de Versiones ............................................................................................................... 22
3.3.Control de Cambios ................................................................................................................ 23
3.4.Auditorias de Configuraciones ................................................................................................ 25
3.5.Informes de Estado .................................................................................................................. 26
Conclusiones ...................................................................................................................................... 28
Referencias Bibliogrficas ................................................................................................................ 29

2
ndice de Figuras
Figura 1:Procesos de Ciclo de Vida ............................................................................................ 6
Figura 2: Procesos de Adaptacin ............................................................................................... 8
Figura 3: Ciclo de Vida Clsico .................................................................................................... 9
Figura 4: Modelo de Prototipado Evolutivo .............................................................................. 12
Figura 5: Ciclo de Vida Espiral ................................................................................................. 16
Figura 6: Lneas Base de la Configuracin de Software ........................................................... 18
Figura 7: Lneas Base en el Ciclo de Vida Tradicional ............................................................. 19
Figura 8: Grafo de Evolucin ..................................................................................................... 23
Figura 9: Proceso de Control de Cambio .................................................................................. 25
Figura 10: Flujo de Informacin ................................................................................................ 27
















3
Gestin de Configuracin de Software (GCS/SCM)
Introduccin
La Gestin de Configuracin de Software (GCS) es una de las actividades claves para que una
organizacin de desarrollo pueda alcanzar el Nivel de Maduracin 2 establecido por el Software
Engineering Institute.

Desafortunadamente, la necesidad de implementar estas actividades surge como consecuencia de la
aparicin de problemas en la calidad de los productos ya desarrollados o en etapas avanzadas
desarrollo, o por dificultades para mantener el ritmo de produccin, puesto que en estas
circunstancias, el personal asignado a tareas de desarrollo debe tambin atender pedidos de
mantenimiento o mejoramiento de productos finalizados.

Otro factor que contribuye a detectar esta necesidad, es la aparicin gradual de programadores,
analistas o especialistas, pertenecientes a los grupos de desarrollo, que, con el tiempo, se van
convirtiendo en insustituibles, pues, ante la falta de una documentacin completa y coherente, son
los nicos que se encuentran en capacidad de implementar cambios en los productos entregados o en
etapa avanzada de implementacin.

Estas dificultades se corrigen mediante la adopcin de las tcnicas de Gestin de Configuracin que
se encuentran ampliamente desarrolladas en los libros de texto relacionados con la Ingeniera de
Software, pero en ninguno de ellos es posible encontrar una explicacin de cmo aplicarlas en
productos en proceso de desarrollo o que ya han sido entregados a los clientes.

En tal sentido, el objetivo del presente trabajo es introducir al lector en la problemtica de los
modelos de ciclo de vida de productos software ms utilizados y en las actividades relacionadas con
la Gestin de Configuracin; avanzando luego en una propuesta para obtener los Elementos de
Configuracin de Software (ECS) esenciales que permitan incorporar a los productos en desarrollo o
desarrollados a las tcnicas de GCS tradicionales implementadas en la Organizacin.









4
Captulo I: Evolucin y Ciclo de Vida del Software
La Ingeniera de Software (IS) est constituida por tres componentes fundamentales que posibilitan
una eficiente gestin del proceso de desarrollo y suministran, a los que trabajan en esta rama de la
ingeniera, las bases para construir de forma eficiente software de alta calidad, ellos son:

o Los Mtodos.
o Las Herramientas.
o Los Procedimientos

Los Mtodos de IS indican como se debe construir el software tcnicamente, abarcando una
amplia variedad de tareas que incluyen, entre otras, la planificacin y estimacin de proyectos
software, el anlisis de requisitos del sistema y del propio software, el diseo de estructuras de
datos, la arquitectura de programas, la codificacin, el programa de pruebas, y tambin las
previsiones de mantenimiento.

Las Herramientas de IS proveen el apoyo a los Mtodos y constituyen un soporte al desarrollo. Estas
herramientas pueden ser manuales, semiautomticas o totalmente automatizadas. La tendencia
actual es que este apoyo sea llevado a cabo por herramientas informticas que, integrando cada uno
de los Mtodos mencionados anteriormente, brinden una solucin integral al problema del desarrollo
del software.
Estas son las herramientas CASE (Computer Aided Sofware Engineering) que se puede traducir
como Ingeniera de Software Asistida por Computadora. Existen en el mercado diferentes
herramientas de este tipo que permiten automatizar parte o todo el proceso de desarrollo.

Los Procedimientos de IS constituyen el vnculo de unin entre Mtodos y Herramientas, tienen por
objeto facilitar el desarrollo racional y oportuno del producto.
Definen el orden en que se deben aplicar los Mtodos, establecen los documentos e informes que se
requieren para asegurar un desarrollo preciso y una adecuada supervisin del avance del proyecto,
fijan, adems, los controles a aplicar sobre el producto tendientes a asegurar su calidad e integridad.

Puede afirmarse entonces que la IS est compuesta por una serie de pasos que comprenden los
Mtodos, las Herramientas y los Procedimientos mencionados.
Habitualmente estos pasos reciben el nombre de paradigmas de la Ingeniera de Software.
Existen actualmente distintos paradigmas que pueden adoptarse para guiar el proceso de desarrollo
de un producto software, no obstante, todos ellos se basan en tres paradigmas bsicos:

o Paradigma de Ciclo de Vida Clsico (o en cascada).
o Paradigma de Prototipos Evolutivos.
o Paradigma del Modelo en Espiral.

La seleccin del paradigma a utilizar en un proyecto de desarrollo de software est directamente
relacionada con la naturaleza del proyecto y de la aplicacin, los Mtodos y Herramientas a utilizar
y los controles e informes requeridos. [3]


5
1.1. Evolucin del Software

La necesidad de gestionar la configuracin surge del hecho de que el software evoluciona con el
tiempo:
Durante el desarrollo
El desarrollo del software siempre es progresivo, incluso en el ciclo de vida en cascada.
El desarrollo evolutivo consiste, precisamente, en una evolucin controlada (ciclo de vida
espiral, prototipos evolutivos).
Durante la explotacin
Durante la fase de mantenimiento se realizan modificaciones sucesivas del producto.
En todos los casos
Suele ser necesario recuperar versiones antiguas, aunque sea slo para consulta. Para ello
hace falta tener organizado el almacenamiento de versiones anteriores.

1.2. Ciclo de vida y Modelos de Desarrollo

Como se ha mencionado, no existe un nico paradigma o modelo de Ciclo de Vida que pueda
definir todas las fases por las que deba pasar un producto software y que se adapte a todas las
necesidades y problemas. [3]

Esto es as porque existe un amplio espectro de aplicaciones para las que deben desarrollarse
productos de diferente naturaleza.
El carcter de estas aplicaciones hace que cada una de ellas requiera solucin particulares y
especficas, an ms, puede suceder que dentro de un mismo tipo existen necesidades diferentes.
Por otra parte, los centros de desarrollo que debe implementarlas poseen, a su vez, estructuras
organizativas y modalidades de trabajo particulares.
Tambin forman parte de esta problemtica otros factores, entre los que pueden mencionarse:

o El tipo de cliente o usuarios para el que se desarrollar el Sistema.
o La volatilidad de requisitos.
o La aversin al riesgo del cliente y de la organizacin de desarrollo.
o El rea donde se utilizar la aplicacin.

Estos factores suelen combinarse, por lo que puede considerarse lgico pensar que exista la
necesidad de aplicar diferentes paradigmas para diferentes tipos de producto.

Por tal motivo, resulta indispensable realizar, previo al inicio de un proyecto de desarrollo, la
identificacin y anlisis de los diferentes modelos de ciclos de vida, adoptando aqul que ms se
ajuste a las necesidades del proyecto, del cliente y de la organizacin de desarrollo.

Cualquiera sea el modelo de ciclo de vida seleccionado, debe cumplir con los siguientes
requisitos:
o Determinar el orden en que deben llevarse a cabo las fases del proceso software.
o Establecer claramente los criterios de transicin de una fase a la siguiente. [3]

6
1.2.1. Concepto de ciclo de vida

Una aproximacin lgica a la adquisicin, el suministro, el desarrollo, la explotacin y el
mantenimiento del software [IEEE 1074]. [1]

Un marco de referencia que contiene los procesos, las actividades y las tareas involucradas en
el desarrollo, la explotacin y el mantenimiento de un producto de software, abarcando la
vida del sistema desde la definicin de los requisitos hasta la finalizacin de su uso [ISO
12207-1]. [1]

1.2.2. Procesos del ciclo de vida


Figura 1. Procesos del ciclo de vida [2]

1.2.2.1. Procesos Principales

Proceso de Adquisicin: Actividades y tareas que el comprador, cliente o usuario
realiza para adquirir un sistema o producto software.
Proceso de Suministro: Actividades y tareas que efecta el suministrador.
Proceso de Desarrollo: Tenemos como al anlisis de requisitos del sistema, diseo de
la arquitectura del sistema, anlisis de los requisitos del software, diseo de la
arquitectura del software, diseo detallado del software, codificacin y prueba del
software, integracin del software, prueba del software, integracin del sistema,
prueba del sistema, instalacin del software, soporte del proceso de aceptacin del
software.
Proceso de Explotacin: Incluye la explotacin del software y el soporte operativo a
los usuarios.
Proceso de Mantenimiento: Aparece cuando el software necesita modificaciones. El
objetivo es modificar el software existente manteniendo su consistencia.




7
1.2.2.2. Procesos de Soporte

Proceso de Documentacin: Registra la informacin producida por un proceso o
actividad del ciclo de vida.
Proceso de Gestin de la Configuracin: Aplica ciertos procedimientos
administrativos y tcnicos durante todo el ciclo de vida relacionados con la
configuracin del software y con las modificaciones y versiones de los documentos.
Proceso de Aseguramiento de la Calidad: Aporta confianza en que los procesos y los
productos software del ciclo de vida cumplen con los requisitos especificados y se
ajustan a los planes establecidos.
Proceso de Verificacin: Determina si los requisitos de un sistema o del software
estn completos y son correctos, y si los productos software de cada fase del ciclo de
vida cumplen los requisitos y condiciones impuestos en fases previas.
Proceso de Validacin: Sirve para determinar si el sistema o software final cumplen
con los requisitos previstos para su uso.
Proceso de Revisin Conjunta: Sirve para evaluar el estado del software y sus
productos en una actividad del ciclo de vida o una fase de un proyecto.
Proceso de Auditora: Permite determinar, en los hitos predeterminados, si se han
cumplido los requisitos, los planes y el contrato.
Proceso de Resolucin de Problemas: Permite analizar y eliminar los problemas
descubiertos durante el desarrollo, la explotacin, el mantenimiento u otro proceso.

1.2.2.3. Procesos Generales

Proceso de Gestin: Actividades y tareas genricas para gestionar los procesos.
Proceso de Infraestructura: Infraestructura necesaria para cualquier otro proceso.
Proceso de Mejora: Para controlar y mejorar los procesos.
Proceso de Formacin: Para proporcionar formacin y mantener al profesor formado.

8

Figura 2. Proceso de adaptacin [1]
1.2.3. Modelos de Desarrollo

1.2.3.1. Modelos Tradicionales

Estos modelos de evolucin del producto software son utilizados, en algunos casos,
desde los inicios de la Ingeniera del Software y se encuentran ampliamente
desarrollados en la bibliografa existente, no obstante, a los efectos del presente
trabajo, se describen aquellos de mayor utilizacin: El ciclo de vida Clsico o en
Cascada y el ciclo de vida de Prototipado Evolutivo.

1.2.3.1.1. Modelo de Ciclo de Vida Clsico (o en Cascada)

Es el paradigma ms antiguo y ampliamente difundido en la IS, fue
presentado por primera vez por Royce en 1970 y aplicado con xito para
estructurar y gestionar grandes proyectos de software en importantes
compaas de desarrollo. [5]

9
Puede ser visto como un modelo con forma de cascada de agua de varios
saltos, en la que cada salto representa cada una de las fases del ciclo de
vida.

La Figura 3. , permite visualizar la evolucin del producto software como
una secuencia ordenada de transiciones, de fase en fase, que evoluciona en
forma lineal, exige un enfoque sistemtico y secuencial del desarrollo del
producto software y contempla las siguientes fases:



Figura 3. Ciclo de Vida Clsico [4]

a. Ingeniera y Anlisis del Sistema Global

En esta fase se establecen los requisitos de todos los componentes del Sistema
Global, asignando un subconjunto de esos requisitos al componente Software,
determinando, asimismo, su factibilidad y superioridad con respecto a otros
productos alternativos. [3]

b. Anlisis de Requisitos de Software

Bsicamente se definen los requisitos funcionales y de rendimiento. [6]
En esta fase se profundiza el estudio de los Requisitos del Sistema Global en lo
que respecta al rea de Software en particular.
Esta tarea establece una relacin entre la asignacin del Software a nivel
Sistema y el diseo del Software. [3]

c. Diseo de Software

Representacin de la aplicacin que sirve de gua a la implementacin. [6]

10
Este proceso traduce la especificacin de requisitos (qu hacer) en una
representacin que logre la calidad requerida antes de proceder a la codificacin
(cmo hacerlo).
El objetivo de esta fase es desarrollar una representacin coherente y
organizada del producto software que satisfaga la especificacin de requisitos.
[3]
Desde el punto de vista de gestin, la etapa de diseo se puede considerar
dividida en dos subetapas:
Diseo Preliminar
Se centra en la transformacin de los requisitos en una descripcin de
alto nivel de diseo de cada uno de los componentes software,
incluyendo especificacin de datos, relaciones, restricciones y
definicin de interfaces internas y externas. [3]
Diseo Detallado
Se ocupa del refinamiento de la representacin arquitectnica que
conduce a la definicin detallada de estructuras de datos,
representaciones algortmicas, informacin de control e interfaces
particulares de cada componente software con el resto del Sistema. [3]

d. Codificacin

En esta fase se lleva a cabo la traduccin del diseo a un lenguaje de
programacin que pueda ser luego interpretado por la mquina.
Se pretende traducir el diseo en un cdigo fuente y cdigos de bases de datos
(si es de aplicacin).

El cdigo fuente, luego de ser procesado por un compilador, generar un cdigo
objeto, dependiente de la mquina, ms tarde, la salida de ese compilador es, a
su vez, traducido a cdigo de mquina.

El cdigo fuente debe estar acompaado de la documentacin correspondiente,
que constituye la manifestacin fsica del diseo de acuerdo a los estndares y
metodologas adoptados para el proyecto.
Para el caso que el Sistema est conformado por componentes Hardware y
Software, en esta fase se debe planificar y ejecutar la integracin de ambos
componentes. [3]

e. Pruebas

Es la validacin e integracin de software y sistemas. [6]

Esta fase constituye la revisin final de las especificaciones, el diseo y la
codificacin y puede ser considerada crtica para asegurar la calidad del
producto generado.

11
En ella se ejecutar el software con determinados datos de entrada (juegos de
ensayo), para observar los resultados que se producen y compararlos con los
que, tericamente y segn las especificaciones, el Sistema debera producir para
detectar posibles fallos. [3]

A la finalizacin de esta fase se obtienen los siguientes elementos:
Especificacin de las pruebas.
Informe resumen de pruebas.

f. Mantenimiento

Esta fase comprende las tareas de instalacin y operacin, soporte y remocin
del Sistema.

Una vez superada satisfactoriamente la fase de pruebas, el Sistema est listo a
ser instalado en la mquina objetivo.

Con el Sistema instalado, se inicia el perodo de operacin, donde se comienza
a realizar mantenimiento, el que se enfoca en los cambios que se producen
debido a la correccin de errores, a las adaptaciones requeridas por la evolucin
del entorno de software y a las modificaciones originadas en la variacin de
requisitos del cliente dirigidos a reforzar o ampliar las prestaciones del Sistema.
[3]

El proceso de mantenimiento vuelve a aplicar los pasos del ciclo de vida, pero
dentro de un contexto de software ya existente, de esta manera, se puede
considerar al proceso de mantenimiento como iteraciones del proceso de
desarrollo.
Este ciclo contina hasta el momento en que el Sistema es retirado de operacin
para ser reemplazado por un nuevo Sistema. [3]

1.2.3.1.2. Prototipado evolutivo

Cuando un cliente siente la necesidad de requerir el desarrollo de un
sistema para resolver un problema, habitualmente no posee una idea
demasiado detallada de esta necesidad, slo percibe que tiene un problema
que demanda una solucin.

Por otra parte, tambin suele suceder que el ingeniero de software que debe
atender a ese cliente, no siempre estar seguro de la viabilidad de la
solucin que tiene en mente para resolver el problema. [3]
Es en esta situacin donde el paradigma de Prototipado Evolutivo adquiere
gran valor, ya que permite a ambos realizar una aproximacin gradual a la
solucin ptima del problema.

12

Prototipo evolutivo: El prototipo inicial se refina progresivamente hasta
convertirse en versin final. [6]. En esta clase de prototipos se desarrolla un
modelo de trabajo del Sistema propuesto que debe ser fcilmente
modificable y ampliable, permitiendo a los usuarios contar con una
representacin fsica inmediata de las partes claves del Sistema antes de
arribar al producto definitivo. Una vez definidos todos los requisitos y
comprobada la viabilidad de la solucin propuesta, el prototipo
evolucionar hacia el Sistema final. En este modelo se deben implementar
en forma gradual aquellos requisitos y necesidades que vayan resultando
claramente interpretados.

De ellos, el modelo ms difundido es el de Prototipos Evolutivos que se
puede visualizar en la Figura 4., ya que implica economa de esfuerzos y la
posibilidad que el cliente cuente rpidamente con una modelo bsica que le
permita solucionar, aunque ms no sea, parte del problema. Por tal motivo,
es el que estudiaremos con detenimiento.

Figura 4. Modelo de Prototipado Evolutivo [3]

Este paradigma reconoce las siguientes fases que conforman el Ciclo de
Vida:

a. Anlisis preliminar y especificacin de requisitos

Al igual que en el modelo Clsico, en el de Prototipado Evolutivo el Ciclo de
Vida comienza con la especificacin de requisitos.

13
El cliente, junto con el Ingeniero de Software, identifica las necesidades,
formulan las soluciones potenciales y evalan la viabilidad de cada una de las
soluciones para seleccionar aquella que parezca ms eficiente a nivel de
Sistema.

Una vez establecidos los lmites de la futura aplicacin y considerando slo
aquellos Requisitos Globales del Sistema que se han individualizado
perfectamente, el Ingeniero de Software analizan con detalle y, junto con el
cliente, refinan aquellos requisitos que sern tratados mediante el software.

Tambin dejan claramente establecidas las funciones del hardware, del
software y de las interfaces, permitiendo, de esa manera, desarrollar la
arquitectura bsica del prototipo a implementar.

b. Diseo rpido del prototipo

Con la informacin recogida en la etapa anterior, el Ingeniero de Software
desarrolla una representacin coherente y organizada de aquellos aspectos del
sistema software que cumplen con las especificaciones de los requisitos que se
han podido recoger y refinar en total acuerdo con el cliente.

Dado que esta fase requiere la obtencin de un diseo rpido para ser
posteriormente implementado, las etapas de diseo de alto nivel y diseo
detallado vistas en el ciclo de vida tradicional, se funden en una sola etapa de
diseo.

En ella, se focaliza con la misma profundidad en las funciones y estructuras de
los componentes que conforman el sistema, como en la definicin detallada de
los flujos datos y control.
Tambin deben refinarse las representaciones algortmicas que se utilizan en
cada componente modular y las interfaces que requiere el prototipo a
desarrollar, simulando, de resultar necesario, la presencia de otros mdulos o
dispositivos que a esta altura del proyecto an no han sido desarrolladas o se
duda de su necesidad de implementacin.

Por tratarse de un prototipo evolutivo, debe prestarse especial atencin a la
interface hombre mquina, ya que, en la medida que el usuario se sienta
cmodo en la operacin del prototipo, ms disposicin y tiempo tendr para ir
madurando sus reales necesidades y descubriendo nuevos requisitos que no se
manifestaron en la definicin inicial.

c. Construccin e implantacin Pruebas

En el modelo de Construccin de Prototipos, en esta fase se unifican las fases
de Construccin y Pruebas del modelo Clsico.

14

En lo que respecta a construccin, al igual que en el modelo Clsico, en esta
fase se traduce el diseo a un lenguaje de programacin que pueda ser luego
interpretado por la computadora.
El cdigo fuente debe estar acompaado de la documentacin correspondiente
de acuerdo a los estndares y metodologas adoptados para el proyecto.

Para el caso que el prototipo est conformado por componentes Hardware y
Software, en esta fase tambin se debe planificar y ejecutar la integracin de
ambos componentes.

Esta fase contempla tambin la etapa de pruebas, que constituye la revisin
final de las especificaciones, el diseo y la codificacin.
Para las pruebas, se ejecutar el prototipo con datos de entrada prefijados para
comprobar si los resultados que el Sistema desarrollado produce son similares
a los que, tericamente y segn las especificaciones, el Sistema debera
producir detectando as posibles errores.

d. Evaluacin y refinamiento interactivo del prototipo

Es en esta fase donde el cliente / usuario toma contacto con el prototipo para,
mediante su utilizacin, evaluar su utilidad con datos reales, aunque slo sea
en forma parcial, para resolver el problema.

Se produce aqu un proceso interactivo entre el cliente / usuario y el
desarrollador, en el cul, a partir de la experiencia en la utilizacin del
prototipo, se depuren conceptos, surjan nuevas ideas o se detecten fallos de
interpretacin en requisitos o alcances de determinados servicios que debe
prestar el futuro sistema.

e. Refinamiento de las especificaciones del prototipo

Con los elementos generados en la fase anterior, se realiza un refinamiento de
las especificaciones que servirn como base de una nueva fase de diseo
rpido, con el objeto de generar un nuevo prototipo que contemplar mayores
prestaciones que el anterior.

f. Producto de Ingeniera - Implantacin del Sistema final

Esta fase constituye la etapa final del desarrollo del modelo de prototipado
evolutivo.

Comprende las tareas de consolidacin tcnica del producto, pruebas y
revisiones finales, instalacin y operacin, debindose adoptar las previsiones
necesarias para actividades de soporte y remocin del Producto.

15

Esta fase se contina hasta el momento en que el Sistema es retirado de
operacin para ser reemplazado por un nuevo Sistema.
Los productos parciales de la fase b. y c. pasan a ser finales.

1.2.3.2. Modelos Alternativos

Existen al menos tres modelos de ciclo de vida que reciben el nombre de modelos
alternativos, ya que focalizan su atencin en aspectos diferentes a los de los modelos
tradicionales.

Entre ellos se destaca el modelo de ciclo de vida en espiral que, resultando similar al
modelo de prototipo evolutivo, incorpora en su desarrollo un factor sumamente
importante en el mundo actual, altamente competitivo y cambiante: el anlisis de
riesgo.

1.2.3.2.1. Modelo en Espiral

Como se ha mencionado, este modelo, de relativamente reciente
surgimiento (Bem 1986), incorpora mtodos de proceso que estn
influenciados por el control y gestin del riesgo para el anlisis y
estructuracin del proceso de desarrollo.
El modelo en espiral es bastante adecuado para la gestin de riesgos. [7]

Esta nueva filosofa se encuentra representada por ciclos de desarrollo
evolutivo e iterativo en forma de espiral, cuyo avance angular representa el
progreso del desarrollo, en tanto que el desplazamiento radial desde el
centro hacia fuera indica el incremento de los costos de desarrollo en forma
acumulativa.

La Figura 3. Permite visualizar grficamente el comportamiento de este
tipo de ciclo de vida, en ella se pueden distinguir en sus cuatro cuadrantes
las cuatro actividades principales del modelo:

Determinacin de Objetivos y Alternativas: Involucra la determinacin
de objetivos del proyecto, alternativas y restricciones, y, en etapas
posteriores, la valoracin de los resultados de las tareas de ingeniera
previas.
Anlisis de riesgo: Estas actividades permiten gestionar los riesgos
asociados al proceso de desarrollo. Se materializan en el anlisis de
alternativas e identificacin y resolucin de los riesgos que puedan
hacer fracasar el proyecto o sobrepasar el presupuesto o plazo fijado.
Producido el anlisis de riesgo, se toma la decisin de continuar o no
con el desarrollo.

16
Ingeniera: Abarca las actividades inherentes al desarrollo del producto
y comprende la construccin de los prototipos de nivel cada vez ms
refinados, a medida que se produce la evolucin del sistema, hasta llegar
al producto final.
Planificacin: Involucra todo lo atinente a las tareas de planificacin y
estimaciones del proyecto en las distintas etapas.

Figura 5. Ciclo de Vida Espiral [7]























17
Captulo II: Gestin de Configuracin de Software
2.1. La configuracin del software
El resultado del proceso de ingeniera del software es una informacin que se puede dividir tres
amplias categoras: [8]
1) Programas de computadora (tanto en forma de cdigo fuente como ejecutable).
2) Documentos que describen los programas (tanto tcnicos como de usuario).
3) Estructuras de datos (contenidas en el programa o externas a l).
Los elementos que componen toda la informacin producida como parte del proceso de
ingeniera del software se denominan colectivamente "configuracin del software". Dado que la
configuracin software es la nica representacin tangible de un programa o sistema software,
debe ser controlada para conservar su exactitud, mantener la informacin actualizada, y
asegurar una informacin clara y concisa conforme avanzamos paso tras paso en el proceso de
Ingeniera del Software. [8]
La causa de todas estas modificaciones se debe a que, a medida que pasa el tiempo, todo el
mundo sabe ms (sabe lo que necesita, cmo aproximarse mejor al problema y cmo hacerlo
ganando ms dinero). Este conocimiento adicional es la fuerza motriz de la mayora de los
cambios. [9]
El cambio se puede producir en cualquier momento y por cualquier razn. Por ejemplo, se
generan cambios en las revisiones, que nos llevan a la modificacin de los elementos de la
configuracin (ECSs); durante la fase de desarrollo, se pueden realizar adiciones en los
documentos ya producidos; las pruebas a menudo nos llevan a cambios que se propagan a travs
de la mayora de los ECSs. [9]
Sin embargo, hay cuatro fuentes fundamentales de cambios:
nuevos negocios o condiciones comerciales que dictan los cambios en los requisitos del
producto o en las normas comerciales; [8]
nuevas necesidades del cliente que demandan la modificacin de los datos producidos por
sistemas de informacin, funcionalidades entregadas por productos o servicios entregados
por un sistema basado en computadora; [8]
reorganizacin o crecimiento/reduccin del negocio que provoca cambios en las prioridades
del proyecto o en la estructura del equipo de ingeniera del software; [8]
restricciones presupuestarias o de planificacin que provocan una redefinicin del sistema o
producto. [8]
La gestin de configuraciones del software (GCS) es un conjunto de actividades desarrolladas
para gestionar los cambios a lo largo del ciclo de vida. La GCS es una actividad de garanta de
calidad de software que se aplica en todas las fases del proceso de ingeniera del software. [9]

18
2.2. Lneas Base y Elementos de Configuracin del Software (ECS)

2.2.1. Lnea Base
Una lnea base es un concepto de gestin de configuracin del software que nos ayuda a
controlar los cambios sin impedir seriamente los cambios justificados. La IEEE
(Estndar IEEE 610.12-1990) define una lnea base como:
Una especificacin o producto que se ha revisado
formalmente y sobre los que se ha llegado a un acuerdo, y
que de ah en adelante sirve como base para un desarrollo
posterior y que puede cambiarse solamente a travs de
procedimientos formales de control de cambios.
Las lneas base de la Configuracin del software se muestran en la siguiente figura:

Figura 6. Lneas Base de la Configuracin de Software [9]
En el contexto de la ingeniera del software, definimos una lnea base como un punto de
referencia en el desarrollo del software que queda marcado por el envo de uno o ms
elementos de configuracin del software y la aprobacin del ECS obtenido mediante
una revisin tcnica formal.
Las Lneas Base pueden ser definidas con cualquier nivel de detalle, no obstante, las ms
difundidas son las que se indican en la siguiente [3] Figura 7. :

19

Figura 7. Lneas Base en un Ciclo de Vida Tradicional [3]

2.2.2. Elementos de configuracin de Software

Un elemento de configuracin del software (ECS) es la informacin creada como
parte del proceso de ingeniera del software. [9] Llevado al extremo, se puede considerar
un ECS como una seccin individual de una gran especificacin o cada caso de prueba
de un gran conjunto de pruebas. De forma ms realista, un ECS es un documento, un
conjunto completo de casos de prueba o un componente de un programa dado. [8]

Los siguientes ECS son el objeto de las tcnicas de gestin de configuraciones y forman
un conjunto de lneas base [3]:

Especificaciones del Sistema.
Estimaciones y Planes.
Especificacin de requisitos software.
Diseo arquitectnico.
Diseo detallado.
Prototipos generados.
Cdigo fuente.
Documentacin relacionada con la determinacin de los factores de riesgo y su
gestin a efectos de minimizar sus consecuencias.
Programas ejecutables y libreras asociadas.
Manuales del usuario, de operacin e instalacin.
Documentacin relacionada con cursos de formacin en el uso del producto.
Plan de pruebas.
Casos de Prueba y resultados obtenidos.
Estndares y procedimientos de Ingeniera de Software utilizados.
Informes de incidencia.
Pedidos de mantenimiento.
Ordenes de cambio.

20
Documentacin del Software y Hardware utilizados como herramientas de
desarrollo.
Diseo de bases de datos.
Bases de Datos.
Informacin del entorno de desarrollo y de implantacin.
Contenidos iniciales de las bases de datos.






































21
Captulo III: El proceso GCS
La GCS da respuesta a las siguientes cuestiones:
Cmo identifica y gestiona una organizacin las muchas versiones existentes de un
programa (y su documentacin) de forma que se puedan introducir cambios
eficientemente?
Cmo controla la organizacin los cambios antes y despus de que el software sea
distribuido al cliente?
Quin tiene la responsabilidad de aprobar y de asignar prioridades a los cambios?
Cmo podemos asegurar que los cambios se han llevado a cabo adecuadamente?
Qu mecanismos se usan para avisar a otros de los cambios realizados?
Estas cuestiones se resuelven en las cuatro tareas de las que consta la GCS:
1. Identificacin. Se trata de establecer estndares de documentacin y un esquema de
identificacin de documentos.
2. Control de cambios. Consiste en la evaluacin y registro de todos los cambios
que se hagan de la configuracin software.
3. Auditoras de configuraciones. Sirven, junto con las revisiones tcnicas formales
para garantizar que el cambio se ha implementado correctamente.
4. Generacin de informes.

3.1. Identificacin de Objetos en la Configuracin del Software

Para controlar y gestionar los elementos de configuracin, se debe identificar cada uno de
forma nica y luego organizarlos mediante un enfoque orientado a objetos.
Se pueden identificar dos tipos de objetos [CH089]: objetos bsicos y objetos compuestos.
Un objeto bsico es una unidad de texto creado por un ingeniero de software durante el
anlisis, diseo, codificacin o pruebas.
Un objeto compuesto es una coleccin de objetos bsicos y de otros objetos compuestos.

El esquema de identificacin de los objetos de software debe tener en cuenta
que los objetos evolucionan a lo largo del proceso de ingeniera del software.
Antes de que un objeto se convierta en una lnea base, puede cambiar varias
veces,. e incluso cuando ya es una lnea base, los cambios se presentan con
bastante frecuencia. Se puede crear un gafo de evolucin
El proceso de identificacin de la configuracin es el siguiente [9]:


22
La tarea de identificacin empieza con la definicin de los elementos
de la configuracin software representativos de los productos en cada lnea
base establecida.
El formato, los contenidos y los mecanismos de control para toda la
documentacin son
definidos para enlazar la informacin cuando la jerarqua de la
configuracin se despliega.
Se asignan identificadores apropiados a todos los programas, documentos y
perifricos,
usando un esquema numerado que proporciona informacin sobre el
elemento de la configuracin software.
Finalmente, la identificacin debe facilitar el control de cambios, para
acomodar actualizaciones y modificaciones.

3.2. Control de Versiones

La ingeniera de software recomienda realizar el desarrollo de manera disciplinada.
Las herramientas de control de versiones no garantizan un desarrollo razonable si
cualquier miembro del equipo puede realizar los cambios que quiera e integrarlos en el
repositorio sin ningn tipo de control.

El control de versiones combina procedimientos y herramientas para gestionar las versiones
de los objetos de configuracin creados durante el proceso del software. Clemm [CLE89]
describe el control de versiones en el contexto de la GCS [8]:

La gestin de configuracin permite a un usuario especificar
configuraciones alternativas del sistema de software mediante la
seleccin de las versiones adecuadas. Esto se puede gestionar
asociando atributos a cada versin del software y permitiendo luego
especificar [y construir] una configuracin describiendo el conjunto de
atributos deseado.
Los atributos que se mencionan pueden ser tan sencillos como un nmero
especfico de versin asociado a cada objeto o tan complejos como una cadena de
variables lgicas (indicadores) que especifiquen tipos de cambios funcionales
aplicados al sistema. [8]

23

Figura 8. Grafo de Evolucin [8]
En la Figura 8., una representacin de las diferentes versiones de un sistema es el
grafo de evolucin mostrado, donde cada nodo del grafo es un objeto compuesto,
es decir, una versin completa del software. Cada versin del software es una
coleccin de ECSs (cdigo fuente, documentos, datos) y cada versin puede
estar compuesta de diferentes variantes.
3.3. Control de Cambios

El proceso de control de cambios puede ser considerado como la actividad ms trascendente
de la Gestin de Configuracin, ya que proporciona un mecanismo rgido para el control de
los cambios a realizar sobre un producto a lo largo de todo su Ciclo de Vida. [3]

La realidad del control de cambio en un contexto moderno de ingeniera de software ha sido
bien resumida por James Bach [BAC98] [8]:

El control de cambio es vital. Pero las fuerzas que lo hacen
necesario tambin lo hacen molesto. Nos preocupamos por el
cambio porque una diminuta perturbacin en el cdigo puede crear
un gran fallo en el producto. Pero tambin puede reparar un gran
fallo o habilitar excelentes capacidades nuevas. Nos preocupamos
por el cambio porque un desarrollador pcaro puede hacer fracasar
el proyecto; sin embargo las brillantes ideas nacidas en la mente de
estos pcaros, y un pesado proceso de control de cambio pueden
disuadirle de hacer un trabajo creativo.

Bach reconoce que nos enfrentamos a una situacin a equilibrar. Mucho control de cambio y
crearemos problemas. Poco, y crearemos otros problemas.
En un gran proyecto de ingeniera de software, el cambio incontrolado lleva rpidamente al
caos. [8]

Pueden establecerse tres distintos tipos de control [9]:

24
1) Control individual, antes de aprobarse un nuevo elemento.
2) Control de Gestin (u organizado), conduce a la aprobacin de un nuevo
elemento.
3) Control formal, se realiza durante el mantenimiento.

1. Control individual (o informal)

Cuando un elemento de la configuracin est bajo control individual, el
tcnico responsable cambia la documentacin como se requiere. Aunque
se mantiene un registro informal de revisiones, tales registros no se ponen
generalmente en el documento. El control individual se aplica durante las
etapas ms importantes del desarrollo del documento y se caracteriza por los
cambios frecuentes.

2. Control de gestin

Implica un procedimiento de revisin y aprobacin para cada cambio
propuesto en la configuracin. Como en el control individual, el control a
nivel de proyecto ocurre durante el proceso de desarrollo pero es usado
despus de que haya sido aprobado un elemento de la configuracin
software. Este nivel de control de cambios se caracteriza por tener
menos cambios que el control individual. Cada cambio es registrado
formalmente y es visible para la gestin.

3. Control de cambios formal

Ocurre durante la fase de mantenimiento del ciclo de vida software (el
producto ya est implantado). El impacto de cada tarea de mantenimiento se
evala por un Comit de Control de Cambios (CCC), el cual aprueba las
modificaciones de la configuracin software.

En un gran proyecto de desarrollo de software, el cambio incontrolado lleva
rpidamente al caos. El control de cambios combina los procedimientos humanos
y las herramientas automticas para proporcionar un mecanismo para el control de
cambio. El proceso de control de cambios est ilustrado esquemticamente en la
Figura 9.

25


Figura 9. Proceso de Control de Cambio [8]



3.4. Auditoria de la Configuracin

A efectos de dar consistencia a todas las tareas de Gestin de Configuracin mencionadas,
resulta necesario efectuar certificaciones de los cambios implementados en los diferentes
productos mediante la ejecucin de revisiones tcnicas formales.
Con este fin, el proceso de Gestin de Configuracin prev la ejecucin de diferentes
actividades de control de calidad denominadas Auditoras de Configuracin.
Las auditoras que se realizan habitualmente son tres [3]:

- Auditoria Funcional: Cuyo objetivo es comprobar que se han completado todas las
pruebas necesarias para el / los ECS auditados, y que, teniendo en cuenta los resultados
de los tests, se puede afirmar que el / los ECS satisfacen los requisitos que se impusieron
sobre l.

- Auditora fsica: Cuyo objetivo es verificar la adecuacin, integridad y precisin de los
elementos fsicos de documentacin que constituyen la Lnea Base.

- Revisin formal de certificacin: Cuyo objetivo es certificar que el / los ECS se
comportan correctamente en su entorno operativo.


26

Estas se centran en las siguientes cuestiones [9]:

1. Se ha hecho el cambio especificado en la orden de cambio de ingeniera (OCI)? Se han
incorporado modificaciones adicionales?
2. Se ha realizado una revisin tcnica formal para comprobar la correccin tcnica?
3. Se han seguido adecuadamente los estndares de ingeniera del software?
4. Se han marcado los cambios en el ECS? Se han especificado la fecha y el autor del
cambio? Refleja la identificacin del ECS los cambios?
5. Se han seguido los procedimientos del GCS para sealar el cambio, registrarlo y
divulgarlo?
6. Se han actualizado adecuadamente todos los ECS relacionados?

3.5. Informes de Estado

Esta actividad persigue como objetivo mantener actualizados de los cambios y su dinmica
a gestores y desarrolladores.
El logro de este objetivo es responsabilidad del SCC quien deber registrar toda la
informacin necesaria para gestionar eficientemente los cambios y generar los informes
correspondientes. [3]

La generacin de informes de estado de la configuracin desempea un papel vital en el
xito del proyecto de desarrollo de software. Cuando aparece involucrada mucha gente es
muy fcil que se d el sndrome de que la mano izquierda ignora lo que hace la mano
derecha. Puede que dos programadores intenten modificar el mismo ECS con intenciones
diferentes y conflictivas. Un equipo de ingeniera del software puede emplear meses de
esfuerzo en construir un software a partir de unas especificaciones de hardware obsoletas.
Puede que la persona que descubra los efectos secundarios senos de un cambio propuesto no
est enterada de que el cambio se est realizando. [8]

La generacin de informes de estado de la configuracin (GIEC) responde a las preguntas
[9]:

1. Qu pas?
2. Quin lo hizo?
3. Cundo pas?
4. Qu ms se vio afectado?

El flujo de informacin del proceso de GIEC se puede apreciar en la siguiente figura [9]:


27

Figura 10. Flujo de Informacin [9]

Esta actividad produce dos tipos de documentacin [3]:

Registros: Documentos o bases de datos donde se acumula informacin relacionada
con la Gestin de Configuracin de un determinado producto.
Informes: Formularios, generalmente prefijados, donde se vuelca informacin o datos
referidos a registros relacionados con la Gestin de Configuracin (Lneas Base,
Solicitudes de Cambio, ECS, Control de Versiones, etc.)













28
Conclusiones
Luego de estudiar los ltimos tres captulos se puede llegar a la conclusin que cualquiera
sea el ciclo de vida seleccionado para un producto software, para su perodo de
mantenimiento, se debe contar, al menos, con los ECS propuestos en cada uno de los ltimos
casos que son para todos los modelos iguales, modelos que estn expuestos en el Captulo I.

Este Ciclo de Vida considerado no tradicional tiende a ser ampliamente utilizado por la
gestin de riesgos que se implementa durante el proceso de desarrollo, los Elementos de
Configuracin de Software propuestos en el Captulo II, deben servir como gua al Jefe de
Proyecto para determinar qu productos intermedios son importantes para asegurar una
adecuada finalizacin de la fase de desarrollo y/o una apropiado transcurso de la fase de
mantenimiento. Esta situacin tiene sentido ya que, para todos los modelos, las necesidades
de informacin que plantea el perodo de mantenimiento es uniforme.

Durante el proceso de construccin de un software, los cambios son inevitables. Los cambios
provocan confusin e incertidumbre, sobre todo cuando no se han analizado o pronosticado
correctamente. La finalidad de la Gestin y configuracin del Software el conocer la
estructura de procesos y herramientas para aplicar dentro de la construccin del software que
nos ayudan a controlar los cambios. Es importante considerar ciertas modificaciones que
pueden ocurrirle al software dentro de todo el proceso de ingeniera para asegurar su control
y calidad.

La gestin de configuracin del software es una actividad de proteccin que se aplica a lo
largo de todo el proceso del software. La GCS identifica, controla, audita e informa de las
modificaciones que invariablemente se dan al desarrollar el software una vez que ha sido
distribuido a los clientes.

La configuracin del software est compuesta por un conjunto de objetos interrelacionados,
tambin denominados elementos de configuracin del software, que se producen como
resultado de alguna actividad de ingeniera del software. Adems de los documentos, los
programas y los datos, tambin se puede poner bajo control de configuracin el entorno de
desarrollo utilizado para crear el software.







29
Referencias Bibliogrficas
[1]. Universidad Rey Juan Carlos, Ingeniera del Software I, Gestin de Configuracin del Software.
[2]. Specifications in Software Engineering, I. Horebeek. y J. Lewi., Springer-Verlag, 1989
[3]. Lic. Claudio Jorge Rancn, Gestin de Configuracin de Productos Software en etapa de Desarrollo,
julio 2003.
[4]. Dr. Daniel Tapias, Proyectos de Desarrollo Software, Captulo 5, Escuela Politcnica Superior, 2013-14
[5]. Alejandra Virrueta Mndez, Investigacin Documental Metodologas de Desarrollo de
Software Instituto Tecnolgico Superior de Apatzingn, Apatzingn Michoacn Diciembre 2010.

[6]. Gonzalo Mndez, Proceso Software y Ciclo de Vida, Universidad Complutense de Madrid,
Facultad de Informtica, Dpto. de Ingeniera de Software e Inteligencia Artificial, 2008-2009.
[7]. Dr. Pedro Meja lvarez, Diseo, construccin y mantenimiento de sistemas de software
grandes, CINVESTAV-IPN, Mxico, Septiembre 2003.
[8]. Pressman, R. S. Ingeniera de Software. Un enfoque Prctico (5 Edicin). Espaa. McGrawHill.
[9]. Sr. D. Juan Antonio Buj PascuaL, Teniente Coronel Inspector del REA de Inspecciones
Industriales, Ministerio de Defensa ESPAA, Gestin de Configuracin durante el ciclo de vida
de un sistema, Jornada de Defensa Gestin de la Configuracin, AEC 4 de Octubre del 2012.
[10]. Fuertes Castro, J.L. Gestin de Configuracin de Software X Reunin de Responsables de
Sistemas de Informacin, (pg. 16). La Antigua, Guatemala. [Distribucin Web]:
http://www.histaintl.com/soluciones/configuracion/configuracion.php
[11]. Antonio, A. d. (s.f.). Gestin, de Configuracin de Software. Recuperado el 16 de Noviembre
de 2013 en: http://www.slideshare.net/JohanPrevotR/gestion-de-la-configuracion-del-software-
10471407