Tarea: Establecer políticas de gestión de la configuración (CM)
En esta tarea se describe cómo desarrollar políticas CM que incluyen prácticas de identificación de la configuración, prácticas de creación de líneas base, prácticas de archivado y requisitos de informe de la configuración.
Objetivo

El objetivo de esta tarea es establecer políticas de gestión de la configuración del proyecto que se utilizarán para supervisar y proteger los activos del proyecto, así como para aplicar las prácticas de desarrollo de software. Las políticas del proyecto deben mejorar la comunicación entre los miembros del equipo y minimizar los problemas que aparecen durante la integración de su trabajo. 

Relaciones
RolesPrincipal: Adicional: Asistencia:
EntradasObligatoria: Opcional: Externa:
  • Ninguno
Salidas
Pasos
Definir prácticas de identificación de la configuración
Objetivo:  Identificar y almacenar productos de trabajo en un repositorio seguro 
Guías de herramientas: Creación de líneas base utilizando Rational ClearCase 

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.

Seleccionar informes basados en solicitudes de cambio Ir a la parte superior de la página

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.

Definir la frecuencia de creación de informes Ir a la parte superior de la página

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


Propiedades
Varias apariciones
Condicionado por sucesos
Continuo
Opcional
Planeado
Se puede repetir
Más información