Definir prácticas de identificación de la configuración
La identificación de la configuración es un aspecto fundamental de la gestión de la configuración y el IEEE la define
como "un elemento de la gestión de la configuración, consistente en seleccionar los elementos de configuración de un
sistema y registrar sus características funcionales y físicas en la documentación técnica". En términos de gestión de
configuración de software, la identificación de la configuración significa poder encontrar e identificar de forma
rápida y sencilla la versión correcta de cualquier producto de trabajo del proyecto. El impacto negativo de tener un
sistema ineficaz de identificación de la configuración se mide en términos de tiempo perdido y calidad perdida.
Las etiquetas identifican versiones específicas de productos de trabajo. El conjunto de productos de trabajo que
constituyen una versión de un subsistema pueden identificarse, tanto colectiva como individualmente, mediante una
versión y una etiqueta concretas. Por tanto, las etiquetas son útiles a la hora de reutilizar o hacer referencia a
conjuntos originales de productos de trabajo con versión.
A continuación se sugiere un convenio de etiquetado de productos de trabajo a nivel de producto que puede utilizarse
para etiquetar vías de acceso y productos de trabajo en la estructura de directorios del producto.
<SYSTEM>[<A>]_[<SUBSYSTEM>]_[<A>]_[R|A|B]<X>[.<Y>.<Z>][.BL<#>]
<SYSTEM> Identifica el sistema
<A> Representa el acrónimo de tres letras (ACT). Se utiliza para los diversos tipos de productos de trabajo
empleados en la creación del sistema. Por ejemplo,
PLN
|
Planes de proyecto
|
REQ
|
Archivos de requisitos
|
USC
|
Casos de uso
|
MOD
|
Archivos de modelo
|
SRC
|
Archivos de código fuente
|
INT
|
Interfaces públicas
|
TST
|
Scripts de prueba y resultados
|
DOC
|
Documentación (usuario, notas del release)
|
BIN
|
Ejecutables
|
<SUBSYSTEM> Identifica cada subsistema
<A> Representa el acrónimo de tres letras para los diversos tipos de productos de trabajo utilizados en la
creación del subsistema. De acuerdo con la tabla anterior.
R|A|B
|
Representan el release, alfa o beta
|
<X>
|
Entero, representa un release principal (p.ej. 1)
|
<Y>
|
Entero (opcional), representa un release menor
|
<Z>
|
Entero (opcional), representa un release alternativo (parches, puertos, etc.)
|
BL
|
Representa el nivel base (un release interno)
|
#
|
Entero, para releases internos
|
A continuación se muestran algunos ejemplos:
T2K_R1.0
|
Release 1 del sistema Thorn 2000
|
T2K_GUI_R2.0.BL5
|
Release interno del sistema de la GUI previsto para entregar en el release 2
|
T2K_B1.1
|
Release beta 1.1 del sistema Thorn 2000
|
T2K_R2.0.BL16
|
Línea base interna #16 del sistema Thorn 2000 prevista para crear el release 2
|
T2K_R1.0.5
|
Release de mantenimiento de Thorn 2000
|
|
Definir prácticas de creación de líneas base
Una línea base proporciona un punto estable y una instantánea de los productos de trabajo del proyecto. El apartado Concepto: Creación de líneas base describe cuándo deben crearse las líneas base
durante el ciclo de vida del proyecto. Este paso proporciona información adicional sobre esta práctica.
Las líneas base identifican conjuntos fijos de versiones de archivos y directorios y se crean en objetivos determinados
del proyecto. Las líneas base pueden crearse para un subsistema o para todo el sistema. Las líneas base deben
identificarse de acuerdo con el esquema descrito en el paso anterior del proceso (definir el convenio de etiquetado de
productos de trabajo).
Una distinción que debe hacerse en el momento de crear una línea base es si se creará:
-
Una 'línea base de subsistema' con TODAS las versiones de los archivos y directorios que se han modificado en el
subsistema o subsistemas.
-
Una 'línea base de sistema' con una ÚNICA versión de todos los archivos y directorios de todos los subsistemas.
Como directriz general, para facilitar la gestión de releases se pueden crear líneas base de sistema en los objetivos
principales y menores, y líneas base de subsistema según sea necesario o a una frecuencia mayor. Como normal general,
se recomienda crear una línea base si se ha cambiado hasta un 30% de los elementos de un subsistema.
|
Definir prácticas de archivado
El objetivo de este paso es garantizar que se realiza una copia de seguridad del software del proyecto y de los activos
relacionados (documentos maestros), su catalogación y transferencia a sitios de almacenamiento designados. El archivado
resulta de utilidad en momentos de reutilización o desastre. Como tal, el archivado debe realizarse periódicamente y en
los objetivos principales y menores.
Las directrices de etiquetado descritas anteriormente en el paso del proceso 'Definir el convenios de etiquetado de
productos de trabajo' pueden utilizarse para crear etiquetas de archivado. Sin embargo, es posible que se necesite
información adicional sobre dónde debe almacenarse el soporte real. Por ejemplo:
NÚMERO DE SERIE
|
123456789
|
VOLUMEN
|
1 de 3
|
CAJA FUERTE
|
B5
|
FECHA DE ALMACENAMIENTO
|
21-junio-99
|
Toda la información relacionada con el producto debe mantenerse en una base de datos para facilitar su liberación y
reutilización.
|
Definir requisitos de informe de estado de la configuración
Objetivo
|
La actividad de cambio es un indicador potente del estado y de las tendencias del proyecto. El objetivo
de este paso del proceso es que el gestor de proyectos defina qué datos de cambio relacionados con el
producto deben notificarse, por quién y con qué frecuencia.
|
Subpasos:
|
Guías de herramientas:
|
El informe de estado de la configuración, si se utiliza, describe las diferentes
fuentes para crear informes de estado de la configuración.
Aquí debe seleccionar los informes que se han derivado de las solicitudes de cambio enviadas al proyecto. Existen varios informes
basados en solicitudes de cambio que resultan de utilidad.
En la categoría 'antigüedad', los informes podrían solicitarse en términos del número de solicitudes de cambio durante períodos de tiempo de una semana o un
mes en función de los siguientes criterios:
-
Enviado
-
Asignado
-
Resuelto
-
Prioridad
El listado de problemas por estado puede ayudar a determinar cuánto falta para que finalice el proyecto. Por ejemplo,
si el grueso de los problemas se ha resuelto. el final está más cerca que si el grueso de los problemas se encuentra en
estado de enviado.
En la categoría 'distribución', se podrían solicitar informes para responder a los siguientes tipos de preguntas:
-
¿Quién encuentra, qué tipo de defectos, en qué punto del proyecto?
-
¿A quién se asignan los problemas?
-
¿Cuántos problemas están abiertos para un determinado ingeniero?
-
¿Cuál es la gravedad de los defectos que se encuentran?
-
¿En qué lugar del proceso se originan los problemas (causa raíz)?
-
¿Cuándo se van a arreglar los problemas?
-
¿Cuántos defectos hay?
-
¿Cuál es la gravedad de estos defectos?
Estas métricas pueden ayudar a analizar la carga de trabajo, quién trabaja en los problemas más importantes y con qué
rapidez se están cerrando los problemas.
En la categoría 'tendencia', se podrían solicitar informes para responder a los siguientes tipos de preguntas:
-
¿Cuántos defectos están abiertos en este día, semana o mes?
-
¿Cuántos defectos se han cerrado en este día, semana o mes?
Estos datos son útiles para valorar los índices de reparación y pueden proporcionar indicaciones de la eficacia de la
ingeniería.
Asegúrese de que los informes se reciben con la frecuencia correcta para proporcionar información significativa para la
toma de decisiones. Los informes pueden solicitarse:
-
Diariamente: no es probable que los informes se necesiten con esta frecuencia
-
Semanalmente: informes de tendencia, distribución y recuento, informes de compilación
-
Mensualmente: informes de tendencia, distribución y recuento, informes de compilación
-
Por iteración: informes de tendencia, distribución y recuento, informes de compilación, descripciones de versión
-
Por fase: informes de tendencia, distribución y recuento, auditorías, informes de compilación, descripciones de
versión
-
Al final del proyecto: informes de tendencia, distribución y recuento, auditorías, informes de compilación,
descripciones de versión
|
|