Está en la página 1de 4

Apuntes

Curso: Calidad de Software (QA)

Clase 10: Administración de configuración de Software

APUNTES

EL PROCESO ACS

El proceso de Administración de la Configuración del Software define una serie de tareas que tienen cuatro
objetivos principales:

1) Identificar todos los ítems que de manera colectiva definen la configuración del Software.

2) Administrar los cambios a uno o más de estos ítems.

3) Facilitar la construcción de diferentes versiones de una aplicación.

4) Garantizar que la calidad del Software se conserva conforme la configuración evoluciona con el tiempo.

Un proceso que logra dichos objetivos no necesita ser burocrático o pesado, pero debe caracterizarse de forma
que permita a un equipo de Software desarrollar respuestas a un conjunto de preguntas complejas:

• ¿Cómo identifica un equipo de Software los elementos discretos de una configuración de Software?

• ¿Cómo gestiona una organización las muchas versiones existentes de un programa (y su documentación)
de manera que permita que el cambio se acomode eficientemente?

• ¿Cómo controla una organización los cambios antes y después de que el Software se libera a un cliente?

• ¿Quién tiene la responsabilidad de aprobar y clasificar los cambios solicitados?

• ¿Cómo puede garantizarse que los cambios se realizaron adecuadamente?

• ¿Qué mecanismo se usa para enterar a otros acerca de los cambios que se realizaron?

Estas preguntas conducen a la definición de las cinco tareas ACS (identificación, control de versión, control
de cambio, auditoría de la configuración y reporte) que se ilustran en la siguiente figura:

Pressman, R. (2010). Ilustración Capas del proceso ACS. [Fig. 2].

Control del Versión


Apuntes

El control de versión combina procedimientos y herramientas para administrar diferentes versiones de objetos
de configuración que se crean durante el proceso de Software. Un sistema de control de versión implementa o
se integra directamente con cuatro grandes capacidades:

1) Una base de datos de proyecto (repositorio) que almacena todos los objetos de configuración relevantes.

2) Una capacidad de administración de versión que almacena todas las versiones de un objeto de configuración
(o que permite la construcción de cualquier versión usando diferencias de las versiones pasadas).

3) Una facilidad para elaboración que le permite recopilar todos los objetos de configuración relevantes y
construir una versión específica del Software.

Además, los sistemas de control de versión y de control de cambio con frecuencia implementan una capacidad
de rastreador de conflictos (también llamado rastreador de errores) que permite al equipo registrar y rastrear el
estado de todos los conflictos sobresalientes asociados con cada objeto de configuración.

James Bach (1998), señaló:

El control del cambio es vital. Pero las fuerzas que lo hacen necesario también lo hacen desconcertante.
Nos preocupamos por el cambio porque una pequeña perturbación en el código puede crear una gran
falla en el producto. Pero también puede corregir un gran fallo o permitir maravillosas nuevas
capacidades. Nos preocupamos por el cambio porque un solo desarrollador granuja podría hundir el
proyecto, aunque en las mentes de dichos granujas se originan ideas brillantes y un abrumador proceso
de control del cambio podría efectivamente desalentarlos de hacer trabajo creativo.

Para un gran proyecto de Software, el cambio descontrolado conduce rápidamente al caos. Para tales proyectos,
el control del cambio combina procedimientos humanos y herramientas automatizadas a fin de proporcionar un
mecanismo para el control del cambio.

Una petición de cambio se envía y evalúa para valorar el mérito técnico, los potenciales efectos colaterales, el
impacto global sobre otros objetos de configuración y funciones del sistema, y el costo proyectado del cambio.

Los resultados de la evaluación se presentan como un reporte de cambio, que utiliza una autoridad de control
del cambio (ACC), es decir, una persona o un grupo que toma una decisión final acerca del estatus y la prioridad
del cambio. Por cada cambio aprobado se genera una orden de cambio de ingeniería (OCI). La OCI describe el
cambio que se va a realizar, las restricciones que deben respetarse y los criterios para revisar y auditar.

El objeto que se va a cambiar puede colocarse en un directorio que controlan exclusivamente los ingenieros de
Software que realizan el cambio. Un sistema de control de versión actualiza el archivo original una vez que se
realiza el cambio. Como alternativa, el objeto que se va a cambiar puede “sacarse” de la base de datos del
proyecto (repositorio), realizarse el cambio y aplicarse las actividades adecuadas de SQA. Luego, el objeto “entra”
a la base de datos y se usan mecanismos de control de versión adecuados para crear la siguiente versión del
Software.
Apuntes

Auditoría de configuración

La identificación, control de versión y control del cambio ayudan a conservar el orden en lo que de otro modo
sería una situación caótica y fluida. Sin embargo, incluso los más exitosos mecanismos de control rastrean un
cambio solo hasta que se genera una OCI.

¿Cómo puede un equipo de Software asegurarse de que el cambio se implementó adecuadamente? La respuesta
es doble:

1. Revisiones técnicas.

2. Auditoría a la configuración del Software.

La revisión técnica se enfoca en la exactitud técnica del objeto de configuración que se modificó. Los revisores
valoran el ICS para determinar la consistencia con otros ICS, así como omisiones o potenciales efectos colaterales.
Una revisión técnica debe realizarse para todos los cambios, salvo los más triviales.

Una auditoría de configuración del Software complementa la revisión técnica al valorar un objeto de
configuración acerca de las características que por lo general no se consideran durante la revisión.

La auditoría hace y responde las siguientes preguntas:

1. ¿Se realizó el cambio especificado en la OCI? ¿Se incorporó alguna modificación adicional?

2. ¿Se llevó a cabo una revisión técnica para valorar la exactitud técnica?

3. ¿Se siguió el proceso del Software y se aplicaron adecuadamente los estándares de ingeniería de
Software?

4. ¿El cambio se “resaltó” en el ICS? ¿Se especificaron la fecha del cambio y el autor del cambio? ¿Los
atributos del objeto de configuración reflejan el cambio?

5. ¿Se siguieron los procedimientos ACS para anotar, registrar y reportar el cambio?

6. ¿Los ICS relacionados se actualizaron adecuadamente?

En algunos casos, las preguntas de la auditoría se plantean como parte de una revisión técnica.

No obstante, cuando la ACS es una actividad formal, la auditoría de la configuración la realiza por separado el
grupo de aseguramiento de la calidad. Tales auditorías formales de la configuración también garantizan que los
ICS correctos (por versión) se incorporan en una construcción específica, y que toda la documentación se
actualizó y es consistente con la versión que se construyó.

El reporte del estado de la configuración (en ocasiones llamado contabilidad de estado) es una tarea ACS que
responde las siguientes preguntas:

• ¿Qué ocurrió?

• ¿Quién lo hizo?

• ¿Cuándo ocurrió?

• ¿Qué más se afectará?


Apuntes

La salida del Reporte de Estado puede colocarse en una base de datos en línea o en un sitio web, de modo que
los desarrolladores de Software o el personal de apoyo puedan acceder a la información del cambio mediante
categorías de palabras clave. Además, regularmente se genera un reporte REC y se tiene la intención de
mantener al tanto de los cambios importantes a los gerentes y profesionales.