Lnea Base

Una lnea base es un concepto de gestin de configuracin del SW que nos ayuda a
controlar los cambios sin impedir los cambios justificados. El cual es un punto de
referencia en el desarrollo de SW.

ELEMENTOS DE CONFIGURACION DE SW
Un elemento de la configuracin de SW es la informacin creada como parte del proceso
de ingeniera un ECS es un documento, un conjunto completo de casos de prueba o un
componente de un programa
PROCESO DE LA GESTION DE LA CONFIGURACION DEL SW
La GCS es un elemento importante de la garanta de calidad es responsable de controlar
los cambios. Sin embargo tambin se debe identificar los ECS individuales

1.- Identificacin los elementos de configuracin

1. Identificar y organizar los objetos como bsicos y compuestos (coleccin de bsicos y
compuestos)
2. Identificar al objeto con un nombre que lo identifique unvocamente.
3. Identificar las relaciones entre los objetos.
4. Documentarlos con grficos o notaciones.
2.- Control de versiones
1. Combina procedimientos y herramientas para gestionar las versiones de los objetos de
configuracin creados durante el proceso de ingeniera de software.

2. Cada versin del software es una coleccin de ECS y cada versin puede estar
compuesta de diferentes variantes.
3. A cada componente se le asigna una tupla de atributos, lista de caractersticas que
definen si se ha de utilizar el componente cuando se va a construir una determinada
versin del software. Es decir debe contener como atributos Nmero especfico de la
versin y una cadena de variables lgicas (indicadores)

Grafo de evolucin simple

Las revisiones sucesivas de un componente dan lugar a una simple secuencia lineal.

Esta forma de evolucin no presenta problemas desde el punto de vista de organizacin

del repositorio. Las versiones se pueden designar simplemente mediante nmeros
correlativos.
Variantes
Cuando hay variantes, es decir, cuando existen simultneamente varias versiones del
componente, el grafo de evolucin ya no es una secuencia lineal, sino que adopta la forma
de un rbol. Si queremos seguir numerando las versiones se necesitar ahora una
numeracin a dos niveles. El primer nmero designa la variante (lnea de evolucin), y el
segundo la versin particular (revisin) a lo largo de dicha variante.

La terminologa usada para referirse a los elementos del grafo es la propia de un rbol:

TRONCO (trunk): Es la variante principal, p.ej. 1.1-1.2...

CABEZA (head): Es la ltima versin del tronco, p.ej. 1.4
RAMAS (branches): Son las variantes secundarias, p.ej: 2.1..., 3.1...
DELTA (delta): Es el cambio de una revisin respecto a la anterior. El nombre delta
puede aplicarse a varios conceptos. Ejemplo, Delta 3.2 puede representar:
o El paso de una versin a otra, es decir, un arco del grafo: (3.1 3.2)
o Los cambios (diferencias) entre una versin y otra: (3.2 - 3.1)
o La versin resultante, en s misma: (3.2)

Propagacin de cambios
Cuando se tienen variantes que se desarrollan en paralelo suele ser necesario aplicar un
mismo cambio a varias variantes. Podemos empezar por realizar el cambio en una rama y
luego propagarlo a las otras.

Hay herramientas concretas que permiten automatizar la propagacin del cambio. Se

denominan Diff-Merge. Usando una notacin matemtica ("-" para la diferencia entre
versiones y "+" para la aplicacin de un cambio) podramos escribir:
2.4 = 2.3 + (1.5 - 1.4)
3.3 = 3.2 + (1.5 - 1.4)
La nueva versin se obtiene a partir de otras tres. Esta accin se denomina mezcla de tres
vas (three-way merge).
Fusin de variantes
En determinados momentos puede dejar de ser necesario mantener una rama
independiente. En este caso se puede fundir con otra (MERGE), y el rbol de evolucin
pasa a ser un grafo convencional.

Para fundir variantes se puede operar de forma similar a la propagacin de cambios,

aplicando a una rama los cambios independientes hechos en la otra. Por ejemplo:
4.1 = 2.3 + (3.2 - 2.2), o bien
4.1 = 3.2 + (2.3 - 2.2)
Tambin se pueden combinar manualmente o mediante alguna herramienta las dos
versiones finales para crear la nueva versin comn. Esta accin se denomina mezcla de
dos vas (two-way merge).
Tcnicas de almacenamiento
En la mayora de los casos las distintas versiones tienen en comn gran parte de su
contenido. Almacenar cada versin completa por separado desaprovecha bastantes
recursos, en comparacin con la posibilidad de almacenar cada fragmento de informacin
distinto slo una vez aunque aparezca repetido en diferentes versiones. Existen distintas

tcnicas para organizar el almacenamiento combinado del conjunto de versiones de una

manera eficiente. Se apoyan en herramientas del tipo diff o diff-merge.

Deltas directos: Se almacena completa la primera versin, y luego los cambios

mnimos necesarios para reconstruir cada nueva versin a partir de la anterior.

Ventajas: Es sencillo de implementar y resulta bastante intuitivo.

Inconvenientes: Es ms costoso recuperar las ltimas versiones (lo ms frecuente)
que las primeras (menos frecuente).

Deltas inversos (RCS): Se almacena completa la ltima versin del tronco y los
cambios necesarios para reconstruir cada versin anterior a partir de la siguiente.
En las ramas se mantiene el uso de deltas directos.

Ventajas: Es menos costoso recuperar las ltimas versiones que las primeras, pero
slo
en
el
tronco
o
rama
principal.
Inconvenientes: En las otras ramas es ms costoso recuperar las ltimas versiones
que si se aplicaran slo deltas directos.

3.- El proceso del Control de cambios

_ Combina procedimientos humanos y herramientas.
_ Elementos del control de cambios:
_ Peticin del cambio

_ Autoridad de control de cambios (ACC)

_ Orden de Ingeniera de cambios (OCI)
_ Procesos de alta y baja de objetos (control de acceso y sincronizacin)
_ Nivel del cambio: informal (antes de la lnea de base), a nivel del proyecto
(cambio local) o formal (cuando el software est en los clientes)
PROCESOS FORMAL DE CONTROL DE CAMBIO

Control de cambio

4.- Auditoras de Configuracin

Es una actividad independiente que es llevada a cabo por el grupo de garanta de calidad y
tiene como objetivo asegurar que se ha hecho, revisado, implementado y comunicado
correctamente el cambio, de acuerdo a los estndares
Actividades de la Auditora de la Configuracin
Esta funcin a veces se considera fuera de la Gestin de Configuracin y dentro de la
Garanta de Calidad. Tambin tiene relacin con las actividades de Validacin y
Verificacin. En realidad es un punto de interseccin entre todas ellas. Es la actividad de
GCS ms costosa. Requiere de personal experimentado, y con un gran conocimiento del
proceso de desarrollo. Sin embargo, debe ser realizada por personal ajeno al equipo de
desarrollo tcnico para mantener la objetividad de la auditora.
Se pueden diferenciar tres tipos de actividades:

Revisiones de fase: Se realizan al finalizar cada fase del desarrollo y su objetivo es

examinar los productos de dicha fase. Las revisiones propias de la Gestin de
configuracin son aquellas en las que se establecern las lneas base. El objetivo de
esta revisin es descubrir problemas, no comprobar que todo est bien. Hay que
ser capaz de desenmascarar los problemas ocultos y sutiles, no slo los que son
obvios. Revisiones tcnicas formales: es una reunin con determinadas premisas
que se centra en la correccin tcnica del ECS que ha sido modificado, evaluando
su consistencia con otros ECS, las omisiones o efectos secundarios
Revisiones de cambios: Se realizan para comprobar que los cambios aprobados
sobre una lnea base se han realizado correctamente.
Auditoras: Se realizan al final del proceso de desarrollo de software y su objetivo
es examinar el producto en su conjunto.

En cuanto a las auditoras, se suelen distinguir dos tipos de auditoras de configuracin:

Auditora Funcional: Cuyo objetivo es comprobar que se han completado todos los
tests necesarios para el Elemento de Configuracin auditado, y que, teniendo en
cuenta los resultados obtenidos en los tests, se puede afirmar que el Elemento de
Configuracin satisface los requisitos que se impusieron sobre l.
Auditora Fsica: Cuyo objetivo es verificar la adecuacin, completitud y precisin
de la documentacin que constituye las lneas base de diseo y de producto. Se
trata de asegurar que representa el software que se ha codificado y probado. Tras
la auditora fsica se establece la lnea base de Producto. Tiene lugar
inmediatamente despus de haberse superado la auditora Funcional.

Y an se puede considerar un tercer tipo de auditora:

Revisin Formal de Certificacin: Cuyo objetivo es certificar que el Elemento de

Configuracin del Software se comporta correctamente una vez que ste se
encuentra en su entorno operativo.

Revisiones de la Auditora de la Configuracin

Las revisiones se deben realizar de forma continua, durante todo el proceso de desarrollo,
y no slo al finalizar ste, cuando los problemas ya no tienen solucin.
La tarea de revisin implica tres tipos de funciones:

Verificar que la configuracin actual del software se corresponde con lo que era en
fases anteriores. Debe haber correspondencia y trazabilidad entre los elementos
de configuracin que aparecen en una lnea base y los que aparecen en la lnea
base que la preceden y que la siguen. La verificacin se realiza con respecto a la
lnea base precedente.
Validar que la configuracin actual del software satisface la funcin que se
esperaba del producto en cada hito del proceso de desarrollo. La validacin se
realiza con respecto a los requisitos del sistema.
Valorar si una determinada lnea base, teniendo en cuenta los resultados de la
verificacin y validacin, y otro tipo de comprobaciones, se debe considerar
aceptable o no.

El papel que juegan las revisiones en el proceso de Gestin de Configuracin es el

siguiente:

Los productos generados durante el proceso de desarrollo se agrupan, al llegar

determinados hitos, en una lnea base pendiente de aprobacin.
Tiene lugar la revisin de fase.
Si en la revisin se encuentran deficiencias en los ECS que componen la lnea base,
se generan los correspondientes Informes de Problemas, o Informes de
Discrepancias, y se entregan al CCC, el cual recomienda ciertos Cambios sobre la
Configuracin.
Una vez implementados los cambios propuestos, se pasa a una nueva revisin de
cambios en la que se comprueba si los cambios se han implementado
correctamente.
Si en la revisin no se encuentra ninguna deficiencia, se declara aceptable la
lnea base pendiente de aprobacin. Si el CCC est de acuerdo con la resolucin
de los revisores, la lnea base se aprueba

5.- Generacin de informes de estado de configuracin (IEC)

Bsicamente se encarga de producir los informes para todos los cambios y cosas que se le
hagan al software por cada uno de los desarrolladores, as todos estn al tanto de lo que
se va haciendo, de esta forma se evita el sndrome de la mando izquierda que ignora lo
que hizo la derecha y un desarrollador va a cambiar lo que otro ya hizo.
documenta (contabiliza):
Qu pas?
Quin lo hizo?
Cundo pas?
Qu ms se vio afectado?
En cada paso del proceso formal del control de cambios.
Su objetivo es el de mejorar la comunicacin entre todas las personas involucradas en el
proyecto.
El flujo de informacin del proceso de GIEC se puede apreciar en la siguiente figura: