Identificación de la configuración

Identificación de la configuración
Información sobre la plantilla
Identconf.jpg


Identificación de la configuración . Consiste en identificar y asignar nombres significativos y consistentes a todos y cada uno de los elementos que forman parte del producto software, en cada fase de su desarrollo, es decir, a cada uno de los Elementos de Configuración del Software.

Tareas de Identificación de la configuración

La tarea de Identificación engloba o puede englobar varias actividades:

  • Establecimiento de una jerarquía preliminar del producto software
  • Selección de los Elementos de Configuración
  • Definición de las relaciones en la configuración
  • Definición de un Esquema de Identificación
  • Definición y Establecimiento de líneas base.
  • Definición y Establecimiento de bibliotecas de software.

A continuación veremos en más detalle cada una de estas actividades.

Establecimiento de una jerarquía preliminar del producto software

Se trata de obtener una primera visión de la estructura y los elementos que tendrá el sistema software. Esta jerarquía facilitará la ejecución de otras actividades posteriores de GC, como la selección de los elementos de configuración o la asignación de números de identificación a los documentos. Se realizará, opcionalmente, en los primeros compases del proyecto.

Selección de los Elementos de Configuración

La selección de un número adecuado de ECS es muy importante. El tener demasiados puede provocar un número excesivamente elevado de especificaciones y documentos que al final resulta inmanejable. Sin embargo, el tener pocos ECS puede hacer que no se tenga la suficiente visibilidad sobre el producto.

Al seleccionar los ECS hay que tratar de separar en ECS distintos las funcionalidades distintas, para tratar de minimizar el impacto de los cambios. Si un ECS incluye funciones muy diversas es probable que aumente el número de veces que será necesario repetir el proceso de reconstrucción del elemento y liberación de una nueva versión.

Algunos criterios adicionales que se pueden utilizar para la selección de ECS son los siguientes:

  • Utilización múltiple: Número de elementos de su mismo nivel o niveles superiores que lo utilizan.
  • Criticidad: Gravedad del impacto de un fallo en dicho componente.
  • Número de personas implicadas en su mantenimiento.
  • Complejidad de su interfaz: Las interfaces de un EC con otros deberían ser simples. Hay que minimizar el acoplamiento entre ECs.
  • Singularidad del componente con respecto al resto.
  • Reutilización: Si el componente se va a diseñar especialmente para ser reutilizado.
  • Si se trata de elementos reutilizados.
  • Tipo de tecnología: Si el componente incorpora nuevas tecnologías no utilizadas en otros componentes.

En cualquiera de estos casos, el componente que se analiza tendrá más probabilidades de convertirse en un ECS, puesto que requerirá de una mayor atención.

Definición de relaciones en la configuración

Se puede considerar que los ECS son objetos, y están conectados con otros ECS mediante relaciones. Esta información ayudará al personal de GCS a comprender dónde se sitúa un elemento con respecto al resto. Hay que tener en cuenta que el personal de GCS suele ser externo al equipo de desarrollo y necesita este tipo de ayudas para poder asomarse a los productos y el proceso de desarrollo.

Algunas de las relaciones que puede ser interesante mantener son las siguientes:

  • Equivalencia: Por ejemplo, cuando un determinado ECS que es un programa está almacenado en tres lugares diferentes (un disco maestro, una copia de seguridad en cinta y el diskette del programador), pero todas las copias corresponden al mismo programa.
  • Composición: Por ejemplo, el ECS “especificación de diseño” estará compuesto de otros ECS, como el “modelo de datos” o el “diseño del módulo N”, para cada uno de los módulos que componen el producto software.
  • Dependencia: Cualquier otro tipo de relaciones entre ECS, fundamentalmente en la documentación, y sobre todo para facilitar la trazabilidad de los requisitos. Así, por ejemplo, el modelo de datos tiene dependencia con los DFDs.
  • Derivación: A partir de qué se ha originado algo. Por ejemplo, el código objeto del código fuente, o una determinada traza de ejecución de un determinado caso de prueba con un determinado programa ejecutable.
  • Sucesión: En la historia de cambios sobre un elemento desde una revisión a otra. Puede ser muy útil definir un Grafo de Evolución para cada ECS. Este grafo describe la historia de cambios de un objeto y su transición de unas versiones a otras.
  • Variante: Variación sobre un determinado elemento, con la misma funcionalidad, pero que, por ejemplo, funciona más rápido.

Gracias a estas relaciones, si se lleva a cabo un cambio sobre un ECS, se podrá determinar fácilmente qué otros ECS pueden verse afectados.

Definición de un Esquema de Identificación

Es necesario establecer un Esquema de Identificación que permita etiquetar cada uno de los Elementos de Configuración del Software. Sea cual sea, el esquema de identificación utilizado debe proporcionar al menos la siguiente información:

  • Número o código del Elemento de Configuración del Software.
  • Nombre del ECS
  • Descripción del ECS
  • Autor/es del ECS
  • Fecha de creación
  • Identificación del proyecto al que pertenece el Elemento de Configuración del Software.
  • Identificación de la línea base a la que pertenece.
  • Identificación de la fase y subfase en la que se creó.
  • Tipo de Elemento de Configuración (documento, programa, elemento físico (cintas, discos, etc.),...).
  • Localización

Por otro lado, el esquema de identificación debe permitir diferenciar entre las diferentes versiones de un mismo Elemento de Configuración del Software, puesto que los Elementos de Configuración del Software van a evolucionar a lo largo del ciclo de vida. Toda esta información puede ir codificada y agrupada en un único código de identificación o puede ser referenciada como partes separadas.

Los datos de identificación se pueden mantener en una base de datos automatizada, lo que permitirá, por ejemplo, referenciar fácilmente todos los Elementos de Configuración del Software de una determinada versión. Las herramientas para gestión automática de la configuración suelen ofrecer facilidades de identificación para los diferentes componentes software del producto (librerías de programas), aunque muchas de ellas no soportan la identificación de otros tipos de Elementos de Configuración, como los documentos o dispositivos físicos.

Definición y Establecimiento de líneas base

Las líneas base se establecen en hitos previamente especificados a lo largo del proceso de desarrollo (“milestones”). Uno de los primeros pasos para poder efectuar la actividad de Identificación de la Configuración, por lo tanto, consiste en definir cuáles van a ser los hitos, dentro del proceso de desarrollo, en los que se va a establecer una línea base.

Aunque se pueden definir las líneas base con cualquier nivel de detalle, las líneas base más comunes son:

  • Línea Base Funcional, que se establece al finalizar la fase de análisis y especificación de los requisitos del sistema, y comprende todos aquellos documentos en los que se define el problema a resolver, los costes del proyecto, el plan de tiempos, y los diferentes requisitos funcionales, de interoperatividad y de interfaz del sistema.
  • Línea Base de Distribución o Asignación de funciones, que se establece al finalizar la fase de análisis y especificación de requisitos software, y comprende toda la documentación que gobernará el desarrollo de cada uno de los componentes software que se han identificado en la especificación del sistema, y la asignación o reparto de las diferentes funciones entre los distintos componentes del sistema
  • Línea Base de Diseño Preliminar, que se establece al finalizar la fase de diseño preliminar. Comprende todos aquellos documentos en los que se define la arquitectura del producto software, así como el Plan de Pruebas.
  • Línea Base de Diseño, que se establece al finalizar la fase de diseño detallado.

Comprende todos aquellos documentos que contienen el diseño detallado del software y el plan de implementación, y también la descripción de los casos de prueba.

  • Línea Base de Producto, que se establece al finalizar la fase de pruebas.

Comprende los programas creados y todos aquellos documentos que contienen la información relativa a las pruebas realizadas.

  • Línea Base de Operación, que se establece al finalizar la fase de implantación.

Comprende los manuales de usuario, guías de operación y mantenimiento, manuales de formación, etc.

Una línea base se puede establecer de dos formas:

  • FÍSICAMENTE: Etiquetando cada Elemento de Configuración del Software y almacenándolos en un Archivo o Biblioteca de Proyecto.
  • LÓGICAMENTE: Publicando un documento de identificación de la configuración, que identifica el estado actual del producto en dicho punto del proceso de desarrollo.

En cualquier caso, al comienzo de cada nuevo proyecto se debería determinar de forma precisa:

  • cuál es el ciclo de vida a utilizar,
  • cuáles son sus fases,
  • cuáles son los productos de cada fase,
  • en qué puntos se van a establecer líneas base y
  • cuáles van a ser los Elementos de Configuración del Software que contenga cada línea base.

Definición y Establecimiento de bibliotecas de software

Una biblioteca de software es una colección controlada de software y/o documentación relacionada cuyo objetivo es ayudar en el desarrollo, uso o mantenimiento del sofware.

Se suelen establecer los siguientes tipos de bibliotecas de software o áreas:

  • Biblioteca de trabajo: Se establece al inicio del proyecto, y comprende el área de trabajo donde los analistas y diseñadores elaboran los documentos del proyecto y donde los programadores desarrollan el software, es decir, donde se realiza la codificación y pruebas unitarias. Una vez se han completado las revisiones o pruebas y el elemento de configuración en cuestión ha sido revisado y aprobado, se inicia la transferencia del ECS a la Biblioteca de Soporte al Proyecto. En esta biblioteca el control de cambios es informal.
  • Biblioteca de Integración. Es de esta biblioteca de donde se toman los ECS para su integración en ECS de nivel superior del sistema.
  • Biblioteca de Soporte al Proyecto: En esta biblioteca se almacenan los ECS aprobados y transferidos desde la Biblioteca de Trabajo o desde la Biblioteca de Integración. Cuando un elemento pasa a esta biblioteca, se encuentra sujeto a un control de cambios interno y semiformal.
  • Biblioteca de Producción: Está compuesta por la Biblioteca de trabajo, la de integración y la Biblioteca de Soporte al Proyecto.
  • Biblioteca maestra: Se usa para almacenar ECS liberados para su entrega al cliente o distribución en el mercado. Los elementos en la biblioteca maestra se encuentran sujetos a un control de cambios formal y estricto. En esta biblioteca se almacenan las Releases del sistema.
  • Repositorio de Software: Es la entidad en la que se archivan los ECS de un proyecto tras su cierre. Se transfieren a él desde la Biblioteca Maestra. Opcionalmente se puede identificar un segmento especial en el que se almacenarán los elementos reutilizables. Todo lo que se almacena en el repositorio debe estar adecuadamente identificado y catalogado, para facilitar su recuperación en caso de necesidad. Se supone que es un almacenamiento a largo plazo, por lo que puede ser de recuperación lenta (cinta). Es central y común a todos los proyectos, mientras que la biblioteca de Producción y la Maestra son individuales para cada proyecto.
  • Biblioteca de Backup: También debe estar adecuadamente identificada, aunque su contenido no está sujeto a Gestión de Configuración (las copias contenidas en ella no están catalogadas en los registros de Gestión de Configuración).

Fuentes

  • S.J. Ayer, F.S. Patrinostro, Software Configuration Management: Identification, Accounting, Control, and Management, McGraw-Hill, 1992
  • W. Babich, Software Configuration Management, Addison-Wesley, 1986
  • H.R. Berlack, Software Configuration Management, John Wiley & Sons, 1992
  • R. Pressman, Ingeniería del Software, 3ª edición, McGraw-Hill, 1993
  • European Space Agency, ESA Guide to Software Configuration Management, ESA Software Engineering Standards Issue 2, Febrero 1991