CAPÍTULO

ADMINISTRACIÓN
CONFIGURACIÓN DEL SOFTWARE
DE LA
22
CONCEPTOS uando se construye software de computadoras, el cambio es inevitable. Y el cambio

C
CLAVE

administración de contenido . 517 aumenta el nivel de confusión cuando los miembros de un equipo de software trabajan
auditoría de configuración . . 514 en un proyecto. La confusión surge cuando los cambios no se analizan antes de que se
líneas de referencia . . . . . . . 504 realicen, cuando no se registran antes de que se implanten, si no se reportan a quienes tienen
control de cambio . . . . . . . . 511 necesidad de conocerlos o si no se controlan en forma que mejore la calidad y se reduzca el
control de versión . . . . . . . . 510 error. Babich [Bab86] analiza esto cuando afirma:
identificación. . . . . . . . . . . . 509
El arte de coordinar el desarrollo de software para minimizar [...] la confusión se llama administración
ítems de configuración de la configuración, que es el arte de identificar, organizar y controlar las modificaciones que se hacen
de software (ICS) . . . . . . . . 505
al software que construirá un equipo de programación. La meta es maximizar la productividad al
objeto de configuración . . . . 505
minimizar los errores.
objetos de configuración
de webapps . . . . . . . . . . . . 517 La administración de la configuración del software (ACS) es una actividad sombrilla que se
proceso ACS . . . . . . . . . . . . 508 aplica a lo largo del proceso de software. Puesto que el cambio puede ocurrir en cualquier mo-
reporte de estado . . . . . . . . 615 mento, se desarrollan actividades ACS para 1) identificar el cambio, 2) controlar el cambio, 3)
repositorio . . . . . . . . . . . . . 506 garantizar que el cambio se implementó de manera adecuada y 4) reportar los cambios a otros
webapps . . . . . . . . . . . . . . 515 que puedan estar interesados.
Es importante hacer una distinción clara entre el apoyo al software y la administración de la
configuración del software. El apoyo es un conjunto de actividades de ingeniería de software
que ocurren después de que éste se entregó al cliente y de que se puso en operación. La admi-
nistración de la configuración del software es un conjunto de actividades de rastreo y control
que inicia cuando comienza un proyecto de ingeniería de software y sólo termina cuando el
software se retira de la operación.

UNA
MIRADA ¿Qué es? Cuando se construye software de ga se demora. Por dicha razón, la gestión del cambio es
RÁPIDA
computadora, ocurren cambios. Y puesto que parte esencial de la administración de la calidad.
ocurren, es necesario administrarlos de manera ¿Cuáles son los pasos? Puesto que muchos productos de
efectiva. La administración de la configuración trabajo se realizan cuando el software se construye, cada
del software (ACS), también llamada gestión del cambio, uno debe identificarse de manera única. Una vez logrado,
es un conjunto de actividades diseñadas para administrar pueden establecerse mecanismos para control de versión y
el cambio mediante la identificación de los productos de de cambio. Para garantizar que la calidad se mantiene
trabajo que es probable que cambien, el establecimiento conforme se realizan cambios, audite el proceso; y para
de relaciones entre ellos, la definición de mecanismos para asegurarse que quienes deben conocerlos estén informa-
administrar diferentes versiones de dichos productos de dos acerca de los cambios, realice reportes.
trabajo y el control de los cambios impuestos, así como la ¿Cuál es el producto final? Un Plan de Administración
auditoría y reporte de los cambios realizados. de la Configuración del Software define la estrategia del
proyecto para la gestión del cambio. Además, cuando se
¿Quién lo hace? Todos los involucrados en el proceso de
invoca ACS formal, el proceso de control de cambio pro-
software se relacionan en cierta medida con la gestión del
duce solicitudes de cambio de software, reportes y órdenes
cambio, pero en ocasiones se crean posiciones de apoyo
de cambio de ingeniería.
especializadas para administrar el proceso ACS.
¿Cómo me aseguro de que lo hice bien? Cuando
¿Por qué es importante? Si no se controla el cambio, todo producto de trabajo pueda explicarse, rastrearse y
éste lo controla a uno. Y eso nunca es bueno. Es muy fácil controlarse; cuando todo cambio pueda rastrearse y ana-
que un torrente de cambios descontrolados convierta en lizarse; cuando todos los que deben saber acerca de un
caos un proyecto de software bien estructurado. Como cambio están informados, entonces la gestión del cambio
consecuencia, la calidad del software se reduce y la entre- se hizo correctamente.

501

22Pressman(501-525).indd 501 19/1/10 17:12:05

 502 PAR T E T R ES AD MINIST RACIÓN DE LA CALIDAD

Una meta principal de la ingeniería de software es mejorar la facilidad con la que los cam-
bios pueden acomodarse y reducir la cantidad de esfuerzo empleado cuando deban realizarse
cambios. En este capítulo se estudian las actividades específicas que permiten administrar
el cambio.

22. 1 ADMINISTRACIÓN DE LA CONFIGURACIÓN DEL SOFTWARE

La salida del proceso de software es información que puede dividirse en tres categorías amplias:
1) programas de cómputo (tanto en el nivel de fuente como en formatos ejecutables), 2) produc-
tos de trabajo que describen los programas de cómputo (dirigidos a varios participantes) y 3)
datos o contenido (incluidos dentro del programa o externos a él). Los ítems que comprenden
toda la información producida como parte del proceso de software se llaman colectivamente
configuración del software.
Conforme avanza el trabajo de ingeniería de software, se crea una jerarquía de ítems de con-
Cita: figuración del software (ICS): un elemento de información nominado que puede ser tan pequeño
como un solo diagrama UML o tan grande como el documento de diseño completo. Si cada ICS
“No hay nada permanente,
excepto el cambio.” simplemente conduce a otros ICS, dará como resultado poca confusión. Por desgracia, en el
proceso entra otra variable: el cambio, que puede ocurrir en cualquier momento, por cualquier
Heráclito, 500 a.C.
razón. De hecho, la Primera Ley de la Ingeniería de Sistemas [Ber80] establece: “Sin importar
dónde se esté en el ciclo de vida del sistema, el sistema cambiará, y el deseo por cambiar per-
sistirá a lo largo del ciclo de vida.”
¿Cuál es el origen de estos cambios? La respuesta a esta pregunta es tan variada como los
mismos cambios. Sin embargo, existen cuatro fuentes fundamentales de cambio:

• Nuevas condiciones empresariales o de mercado dictan los cambios en los requeri-

mientos del producto o en las reglas empresariales.

• Nuevas necesidades de los accionistas demandan modificación a los datos producidos

? ¿Cuál es el origen de
los cambios que se por los sistemas de información, a la funcionalidad que entregan los productos o a los
solicitan para el servicios que ofrece un sistema basado en computadora.
software?
• La reorganización o crecimiento/reducción de la empresa produce cambios en las prio-
ridades proyectadas o en la estructura del equipo de ingeniería de software.

• Restricciones presupuestales o de calendario causan una redefinición del sistema o del

producto.

La administración de la configuración del software es un conjunto de actividades que se de-

sarrollaron para administrar el cambio a lo largo del ciclo de vida del software de computadora.
La ACS puede verse como una actividad que garantiza la calidad del software y que se aplica a
lo largo del proceso de software. En las siguientes secciones se describen las principales tareas
ACS y los conceptos importantes que pueden ayudar a gestionar el cambio.

22.1.1 Un escenario ACS1

Un escenario operativo de administración del cambio (AC) típico involucra a un gerente de pro-
yecto que está a cargo de un grupo de software, a un gerente de configuración responsable de
los procedimientos y políticas AC, a los ingenieros de software encargados de desarrollar y
mantener el producto de software y al cliente que usa el producto. En el escenario, se supone
que el producto es pequeño y que involucra a alrededor de 15 000 líneas de código desarrollado
por un equipo de seis personas. (Observe que es posible que existan otros escenarios de equipos

1 Esta sección se extrajo de [Dar01]. El permiso especial para reproducir “Spectrum of functionality in CM System”,
de Susan Dart [Dar01], © 2001 de Carnegie Mellon University, se obtuvo del Software Engineering Institute.

22Pressman(501-525).indd 502 19/1/10 17:12:07

 C AP Í T UL O 22 ADMINIST RACIÓN DE LA CONFIG U RACIÓN DEL SOFT WARE 503

más pequeños o más grandes, pero, en esencia, hay temas genéricos que cada uno de estos
proyectos enfrenta con respecto a la AC).
En el nivel operativo, el escenario involucra varios roles y tareas. Para el gerente de proyecto,
? ¿Cuáles son las metas
de y las actividades la meta es garantizar que el producto se desarrolla dentro de cierto marco temporal. Por
realizadas por cada uno tanto, monitorea el progreso del desarrollo y reconoce y reacciona ante los problemas. Esto se
de los elementos hace mediante la generación y el análisis de reportes acerca del estado del sistema de software
constituyentes
y al realizar revisiones al sistema.
involucrados en la
administración del Las metas del gerente de configuración son garantizar que se sigan los procedimientos y
cambio? políticas para crear, cambiar y probar el código, así como hacer accesible la información acerca
del proyecto. Para implantar técnicas a fin de mantener el control sobre los cambios de código,
este gerente introduce mecanismos para: realizar peticiones oficiales de cambios, evaluarlos
(mediante un Consejo de Control de Cambios que sea responsable de aprobar los cambios al
sistema de software) y autorizarlos. El gerente elabora y difunde la lista de tareas para los inge-
nieros y básicamente crea el contexto del proyecto. Además, recopila estadísticas acerca de los
componentes que hay en el sistema de software, tales como la información que determina cuá-
les componentes del sistema son problemáticos.
PU Para los ingenieros de software, la meta es trabajar eficazmente. Esto significa que los inge-
NT
O nieros no deben interferir innecesariamente unos con otros en la creación y prueba del código
CLAVE y en la producción de productos operativos de apoyo. Pero, al mismo tiempo, deben intentar
Debe existir un mecanismo para comunicarse y coordinarse de manera eficiente. Específicamente, los ingenieros usan herra-
asegurar que los cambios
mientas que ayudan a construir un producto de software consistente. Se comunican y coordinan
simultáneos hechos al mismo
componente se rastreen, gestionen y al notificarse unos con otros las tareas requeridas y las tareas completadas. Los cambios se
ejecuten de manera adecuada. propagan a través del trabajo mutuo mediante fusión de archivos. Existen mecanismos para
garantizar que, para componentes que experimentan cambios simultáneos, hay alguna forma
de resolver los conflictos y la fusión de cambios. Se conserva una historia de la evolución de
todos los componentes del sistema, una bitácora con las razones de los cambios y un registro
de lo que realmente cambió. Los ingenieros tienen su propio espacio de trabajo para crear,
cambiar, poner a prueba e integrar código. En cierto punto, el código se convierte en una línea
de referencia desde la cual continúan mayores desarrollos y se realizan variantes para otras
máquinas objetivo.
El cliente usa el producto. Puesto que éste se encuentra bajo control AC, el cliente sigue pro-
cedimientos formales para solicitar cambios y para indicar errores en el producto.
De manera ideal, un sistema AC utilizado en este escenario debe apoyar todos estos roles y
tareas, es decir, los roles determinan la funcionalidad requerida de un sistema AC. El gerente de
proyecto ve la AC como un mecanismo de auditoría; el gerente de configuración la considera
un mecanismo de control, rastreo y generación de políticas; el ingeniero de software, como un
mecanismo de control de cambio, construcción y acceso; y el cliente la ve como un camino para
garantizar la calidad.

22.1.2 Elementos de un sistema de administración de la configuración

En su exhaustivo artículo acerca de la administración de la configuración del software, Susan
Dart [Dar01] identifica cuatro elementos importantes que deben existir cuando se desarrolla un
sistema de administración de la configuración:

• Elementos componentes: conjunto de herramientas acopladas dentro de un sistema de

administración de archivos (por ejemplo, base de datos) que permite el acceso a cada
ítem de configuración del software, así como su gestión.

• Elementos de proceso: colección de acciones y tareas que definen un enfoque efectivo de

la gestión del cambio (y actividades relacionadas) para todos los elementos constitu-
yentes involucrados en la administración, ingeniería y uso del software.

22Pressman(501-525).indd 503 19/1/10 17:12:07

 504 PAR T E T R ES AD MINIST RACIÓN DE LA CALIDAD

• Elementos de construcción: conjunto de herramientas que automatizan la construcción

de software al asegurarse de que se ensambló el conjunto adecuado de componentes
validados (es decir, la versión correcta).

• Elementos humanos: conjunto de herramientas y características de proceso (que abarcan

otros elementos AC) utilizados por el equipo de software para implementar ACS efectiva.

Estos elementos (que se estudiarán con más detalle en secciones posteriores) no son mutua-
mente excluyentes. Por ejemplo, los elementos componentes trabajan en conjunción con los
elementos de construcción conforme evoluciona el proceso de software. Los elementos de pro-
ceso guían muchas actividades humanas que se relacionan con la ACS y, por tanto, también
pueden considerarse como elementos humanos.

22.1.3 Líneas de referencia

El cambio es un hecho de vida en el desarrollo de software. Los clientes quieren modificar los
CONSEJO requerimientos. Los desarrolladores quieren cambiar el enfoque técnico. Los gerentes quieren
La mayoría de los cambios de modificar la estrategia del proyecto. ¿Por qué todas estas modificaciones? La respuesta real-
software se justifican, así que no hay mente es muy simple. Conforme pasa el tiempo, todos los elementos constituyentes saben más
razón para quejarse por su presencia. (acerca de lo que necesitan, sobre qué enfoque sería mejor, cómo realizarlo y todavía obtener
En su lugar, asegúrese de que tiene
dinero). Este conocimiento adicional es la fuerza motora que hay detrás de la mayoría de los
los mecanismos para lidiar con ellos.
cambios y que conduce a un enunciado de hechos que es difícil de aceptar para muchos profe-
sionales de la ingeniería de software: ¡la mayoría de los cambios se justifican!
Una línea de referencia es un concepto de administración de la configuración del software que
le ayuda a controlar el cambio sin impedir seriamente cambios justificados. El IEEE (IEEE Std.
No. 610.12-1990) define una línea de referencia como:

Una especificación o producto que se revisó formalmente y con el que se estuvo de acuerdo, que a
partir de entonces sirve como base para un mayor desarrollo y que puede cambiar sólo a través de
procedimientos de control de cambio formal.

Antes de que un ítem de configuración del software se convierta en línea de referencia, los
cambios pueden realizarse rápida e informalmente. No obstante, una vez establecida la línea de
referencia, pueden realizarse cambios, pero debe aplicarse un procedimiento formal específico
para evaluar y verificar cada uno de ellos.
En el contexto de la ingeniería de software, una línea de referencia es un hito en el desarrollo
del software. Una línea de referencia se marca al entregar uno o más ítems de configuración del
software que se aprobaron como consecuencia de una revisión técnica (capítulo 15). Por ejemplo,
los elementos de un modelo de diseño se documentaron y revisaron. Se encontraron y corrigie-
ron errores. Una vez que todas las partes del modelo se revisaron, corrigieron y luego aprobaron,
el modelo de diseño se convierte en línea de referencia. Los cambios adicionales a la arquitectura
del programa (documentada en el modelo de diseño) pueden realizarse sólo después de que cada
uno se evalúa y aprueba. Aunque las líneas de referencia pueden definirse en cualquier nivel de
detalle, en la figura 22.1 se muestran las líneas de referencia de software más comunes.
En la figura 22.1 también se ilustra la progresión de eventos que conducen a una línea de
CONSEJO referencia. Las tareas de la ingeniería de software producen uno o más ICS. Después de revisar
Asegúrese de que la base de datos y aprobar los ICS, se colocan en una base de datos del proyecto (también llamada librería de pro-
del proyecto se mantenga en una yecto o repositorio de software, y que se estudia en la sección 22.2). Cuando un miembro de un
ubicación centralizada controlada. equipo de ingeniería de software quiere hacer una modificación a un ICS que se ha convertido
en línea de referencia, se copia de la base de datos del proyecto en el espacio de trabajo priva-
do del ingeniero. Sin embargo, este ICS extraído puede modificarse solamente si se siguen
controles ACS (que se estudian más adelante en este capítulo). Las flechas de la figura 22.1
ilustran la ruta de modificación de un ICS convertido en línea de referencia.

22Pressman(501-525).indd 504 19/1/10 17:12:07

 C AP Í T UL O 22 ADMINIST RACIÓN DE LA CONFIG U RACIÓN DEL SOFT WARE 505

FIGURA 22.1
Modificado
ICS como línea de ICS
referencia y base
Base de datos del proyecto
de datos del
proyecto Aprobado
Tareas de Revisiones
la ingeniería ICS ICS
técnicas
de software

Almacenado

ICS

Extraído
Controles
ICS
ACS
LÍNEAS DE REFERENCIA:
Especificación del sistema
Requerimientos de software
Especificación de diseño
Código fuente
Planes/procedimientos/datos de prueba
Sistema operativo

22.1.4 Ítems de configuración del software

Ya se definió un ítem de configuración del software como la información que se crea como parte
del proceso de ingeniería de software. En última instancia, un ICS podría considerarse como una
sola sección de una gran especificación o como un caso de prueba en una gran suite de pruebas.
De manera más realista, un ICS es todo o parte de un producto de trabajo (por ejemplo, un do-
cumento, toda una suite de casos de prueba o un componente de programa nominado).
Además de los ICS que se derivan de los productos de trabajo de software, muchas organi-
zaciones de ingeniería de software también colocan las herramientas de software bajo control
de configuración, es decir, versiones específicas de editores, compiladores, navegadores y otras
herramientas automatizadas se “congelan” como parte de la configuración del software. Puesto
que dichas herramientas se usaron para producir documentación, código fuente y datos, deben
estar disponibles cuando tengan que realizarse cambios a la configuración del software. Aunque
los problemas son raros, es posible que una nueva versión de una herramienta (por ejemplo, un
compilador) pueda producir resultados diferentes que la versión original. Por esta razón, las
herramientas, como el software que ayudan a producir, pueden convertirse en líneas de refe-
rencia como parte de un proceso amplio de administración de la configuración.
En realidad, los ICS se organizan para formar objetos de configuración que puedan catalo-
garse con un solo nombre en la base de datos del proyecto. Un objeto de configuración tiene un
nombre y atributos, y está “conectado” con otros objetos mediante relaciones. En la figura 22.2,
los objetos de configuración DesignSpecification (especificación de diseño), DataModel (mo-
delo de datos), ComponentN (componente n), SourceCode (código fuente) y TestSpecifica-
tion (especificación de prueba) se definen cada uno por separado. Sin embargo, cada uno de los
objetos se relaciona con los demás, como se muestra mediante las flechas. Una flecha curva
indica una relación composicional, es decir, DataModel y ComponentN son parte del objeto
DesignSpecification. Una flecha con doble punta indica una interrelación. Si se realizara un
cambio al objeto SourceCode, las interrelaciones permiten determinar qué otros objetos (e ICS)
pueden resultar afectados.2

2 Esas relaciones se definen dentro de la base de datos. La estructura de la base de datos (repositorio) se estudia
con mayor detalle en la sección 22.2.

22Pressman(501-525).indd 505 19/1/10 17:12:08