9 Gestin De La Configuracin Del Software (Gcsiscm)*

Cuando se construye software de computadora, los cambios son inevitables. Adems, los cambios aumentan el grado de confusin entre los ingenieros del software que estn trabajando en el proyecto. La confusin surge cuando no se han analizado los cambios antes de realizarlos, no se han registrado antes de implementarlos, no se les han comunicado a aquellas personas que necesitan saberlo o no se han controlado de manera que mejoren la calidad y reduzcan los errores. La meta es maximizar la productividad minimizando los errores. La gestin de configuracin del software (GCS) es una actividad de autoproteccin que se aplica durante el proceso del software. Como el cambio se puede producir en cualquier momento, las actividades de GCS sirven para: Identificar el cambio. Controlar el cambio. Garantizar que el cambio se implementa adecuadamente. Informar del cambio a todos aquellos que puedan estar interesados.

El mantenimiento es un conjunto de actividades de ingeniera del software que se producen despus de que el software se haya entregado al cliente y est en funcionamiento.A medida que progresa el proceso del software, el nmero de elementos de configuracin del software (ECSs) crece rpidamente. La gestin de configuracin del software es un conjunto de actividades de seguimiento y control que comienzan cuando se inicia el proyecto de ingeniera del software y termina slo cuando el software queda fuera de la circulacin.

9.1 Gestin de la configuracin del software

El resultado del proceso de ingeniera del software es una informacin que se puede dividir en tres amplias categoras: Programas de computadora (tanto en forma de cdigo fuente como ejecutable), Documentos que describen los programas de computadora (tanto tcnicos como de usuario) Datos (contenidos en el programa o externos a l).

Los elementos que componen toda la informacin producida como parte del proceso de ingeniera del software se denominan colectivamente configuracin del software. Una especificacin del sistema produce un plan del proyecto del software y una especificacin de requisitos del software (as como otros documentos relativos al hardware).

9.1.1. Lneas 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. Un producto de trabajo de la ingeniera del software se convierte en una lnea base, solamente despus de haber sido revisado y aprobado. 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. 9.1.2. Elementos de configuracin del software Se puede considerar un ECS como una seccin individual de una gran especificacin o cada caso de prueba de un gran conjunto de pruebas. En realidad, los ECSs se organizan como objetos de configuracin que han de ser catalogados en la base de datos del proyecto con un nombre nico. Un objeto de configuracin tiene un nombre y unos atributos y est conectado a otros objetos mediante relaciones.

9.2 El proceso de GCS

La gestin de configuracin del software es un elemento importante de garanta de calidad del software. Su responsabilidad principal es el control de cambios. Sin embargo, la GCS tambin es responsable de la identificacin de ECSs individuales y de las distintas versiones del software, de las auditoras de la configuracin del software para asegurar que se desarrollan adecuadamente y de la generacin de informes sobre todos los cambios realizados en la configuracin.

9.3 IDENTIFICACION DE OBJETOS EN LA CONFIGURACION 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 2 tipos de objetos: objetos basicos y objetos compuestos. Objeto basico es una unidad de texto creado por un ingeniero de software durante el analisis, diseo, codificacion o pruebas. Por ejemplo, un objeto bsico podra ser una seccin de una especificacin de requisitos, un listado fuente de un mdulo o un conjunto de casos prueba que se usan para ejercitar el cdigo. Objeto compuesto Un objeto compuesto es una coleccin de objetos bsicos y de otros objetos compuestos. Cada objeto tiene un conjunto de caractersticas distintas que le identifican de forma nica: un nombre, una descripcin, una lista de recursos y una realizacin. El nombre del objeto es una cadena de caracteres que identifica al objeto sin ambigedad. La descripcin del objeto es una lista de elementos de datos que identifican: el tipo de ECS (por ejemplo: documento, programa, datos) que est representado por el objeto; un identificador del proyecto; la informacin de la versin y/o el cambio

Los recursos son entidades que proporciona, procesa referencia o son, de alguna otra forma, requeridas por el objeto. Por ejemplo, los tipos de datos, las funciones especficas e incluso los nombres de las variables pueden ser considerados recursos de objetos. Un objeto puede estar identificado como <parte-de> un objeto compuesto. La relacin <parte-de> define una jerarqua de objetos. Por ejemplo, utilizando esta sencilla notacin
Diagrama E-R 1.4 <parte-de> modelo de datos; Modelo de datos <parte-de> especificacin de diseo;

En muchos casos, los objetos estn interrelacionados entre ramas de la jerarqua de objetos. Por ejemplo, el modelo de datos est interrelacionado con los diagramas de flujo de datos (suponiendo que se usa el anlisis estructurado) y tambin est interrelacionado con un conjunto de casos de prueba para una clase particular de equivalencia.

9.4 Control de Versiones El control de versiones combina procedimientos y herramientas para gestionar las versiones de los objetos de configuracin creados durante el proceso del software. La gestin de configuracin permite a un usuario especificar configuraciones alternativas del sistema de software medimte la seleccin de las versiones adecuadas. Esto se puede gestionar asociando atributos a cada versin del software y permitiendo luego especificar una configuracin describiendo el conjunto de atributos deseado. Los atributos que se mencionan pueden ser tansencillos como un nmero especfico de versin asociadoa cada objeto o tan complejos como una cadena de variables lgicas. Para construir la variante adecuada de una determinada versin de un programa, a cada componente se le asigna una tupla de atributos (una lista de caractersticas que definen si se ha de utilizar el componente cuando se va a construir una determinada versin del software). A cada variante se le asigna uno o ms atributos. Otra forma de establecer los conceptos de la relacin entre componentes, variantes y versiones (revisiones) es representarlas como unfondo de objetos. Un componente consta de una coleccin de objetos del mismo nivel de revisin. Una variante esuna coleccin diferente de objetos del mismo nivel derevisin y, por tanto, coexiste en paralelo con otras variantes. Una nueva versin se define cuando se realizan cambios significativos en uno o ms objetos.

9.5 CONTROL DE CAMBIOS La realidad del control de cunihio en un contexto moderno de ingeniera de software ha sido bien resumida por James Bach [BAC98] : El control de cambio es vital. Pero las fuerzas que lo hacen necesario tambien lo hacen molesto. Nos preocupamos por el cambio porque una diminuta perturbacion en el cdigo puede crear un gran fallo en el producto. Pero tambien 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 situacion 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. Para estos proyectos, el control de cambios combina los procedimientos humanos y las herramientas automticas para proporcionar un mecanismo para el control del cambio. Asi como se ilustra en la siguiente figura 9.5.

Autoridad de control de cambios (ACC) -una persona o grupo que toma la decisin final del estado y la prioridad del cambio. Para cada cambio aprobado se genera una orden de cambio de ingenierio(OCI). El objeto a cambiar es dado de baja de la base de datos del proyecto; se realiza el cambio y se aplican las adecuadas actividades de SQA. Antes de que un ECS se convierta en una lnea base, slo es necesario aplicar un control de cambios informal. Una vez que el objeto ha pasado la revisin tcnica formal y ha sido aprobado, se crea la lnea base. Una vez que el ECS se convierte en una lnea base, aparece el control de cambios a nivel de proyecto.

Ahora, para hacer un cambio, el encargado del desarrollo debe recibir la aprobacin del gestor del proyecto (si el cambio es local) o de la ACC si el cambio impacta en otros ECSs. Cuando se distribuye el producto de software a los clientes, se instituye el control de cambios formal. El procedimiento de control de cambios formal es el que aparece definido en la Figura 9.5. El flujo de control de acceso y de sincronizacin estn esquemticamente ilustrados en la Figura 9.6. La autoridad de control de cambios (ACC) desempea un papel activo en el segundo y tercer nivel de control. Dependiendo del tamao y de las caractersticas del proyecto de software, la ACC puede estar compuesta por una persona -el gestor del proyecto- o por varias personas (por ejemplo, representantes del software, del hardware, de la ingeniera de las bases de datos, del soporte o del departamento comercial, etc.). El papel de la ACC es el de tener una visin general, o sea, evaluar el impacto del cambio fuera del ECS en cuestin. Cmo impactar el cambio en el hardware? Cmo impactar en el rendimiento? Cmo alterar el cambio la percepcin del cliente sobre el producto? Cmo afectar el cambio a la calidad y a la fiabilidad?

9.6 Auditoria de la configuracin

Cmo podemos asegurar que el cambio se ha implementado correctamente? Revisiones tcnicas formales: se centran en la correccin tcnica del elemento de configuracin que ha sido modificado. Auditoras de configuracin del software: complementa la revisin tcnica formal al comprobar caractersticas que generalmente no tiene en cuenta la revisin.

9.7 Informes de estado

La generacin de informes de estado de la configuracin (a veces denominada contabilidad de estado) es una tarea de GCS que responde a las siguientes preguntas: Qu pas?, Quin lo hizo?, Cundo pas? y Qu ms se vio afectado?

Los informes de estado proporcionan informacin sobre cada cambio a aquellos que tienen que estar informados. El IEC ayuda a eliminar problemas como cuando una persona descubre los efectos secundarios senos de un cambio propuesto no est enterado de que el cambio se est realizando; mejorando as la comunicacin entre todas las personas involucradas.