Consideraciones sobre el diseño de modelos de estado

Un modelo de estado eficaz debe tratar los problemas siguientes en la fase de diseño:

Sin solución

Debe asegurarse de que el modelo no contenga estados a los que se pueda realizar una transición de una solicitud de cambio y, a continuación, se pasen por alto. Por ejemplo, si el modelo tiene el estado Pospuesto, y no se ha asignado a nadie el proceso de los registros en este estado, es posible que algunas solicitudes de cambio no se notifiquen o arreglen nunca.

Las causas de este problema pueden ser sutiles. Es posible que se asignen tres ingenieros para el manejo de las solicitudes de cambio en el estado Abierto, siendo el valor del campo de componente rojo, verde y azul, respectivamente. Las solicitudes de cambio que tengan el valor de campo de componente amarillo o en blanco no se notifican.

Número de estados

Debe tener en cuenta los intercambios entre un modelo que tenga menos estados con más actividades de desarrollo y un modelo que tenga varios estados con menos actividades de desarrollo. Por ejemplo, si se lleva a cabo una actividad de verificación en varios puntos del ciclo de vida de una solicitud de cambio, es posible que desee un estado de verificación en lugar de incorporar actividades de verificación en otros estados. La agrupación de estas actividades en un estado simplifica que se pueda garantizar que dicha verificación se maneja correctamente. Pero al crear varios estados, el modelo es más difícil de manejar y mantener.

Registros duplicados

Gracias a la acción Duplicar, puede marcar un registro de un conjunto de registros duplicados como registro activo y marcar los demás como duplicados; los registros marcados como duplicados no se pueden modificar. Esta acción garantiza que un registro realiza el seguimiento de todo el trabajo de la solicitud de cambio. Esta acción utiliza campos incorporados; se puede añadir a un esquema por medio de la adición de los controles de Dependientes de duplicado y Base de duplicado a un formulario y por medio de la creación de acciones de duplicar y eliminar el duplicado. La acción de eliminar el duplicado devuelve el registro al estado que tenía antes de marcarlo como duplicado.

Esquemas predefinidos

Hay varios esquemas predefinidos disponibles que incorporan configuraciones o funciones específicas. Los puede utilizar como punto de partida para desarrollar un esquema, pero debe comparar detenidamente las funciones del esquema predefinido con sus requisitos.

Algunos puntos a tener en cuenta sobre estos esquemas predefinidos:

Desarrollo en paralelo

El diseño de un esquema que dé soporte al desarrollo en paralelo de varios productos (o variantes de productos) que compartan artefactos comunes representa un reto. El diseño debe anticipar y tener en cuenta situaciones como, por ejemplo, el modo de capturar y manejar información cuando se realiza el seguimiento de un defecto sobre el que se ha informado para artefactos compartidos que requieren arreglos para varios productos, y el modo de realizar el seguimiento del estado actual del defecto cuando se necesitan varias compilaciones (en planificaciones que pueden ser diferentes).

Se puede utilizar un único registro para realizar el seguimiento de los diferentes esfuerzos, pero es un planteamiento que no resulta eficaz.

Otro enfoque consiste en enviar varios registros para cada producto afectado, lo que permite realizar el seguimiento del estado de cada actividad de modo independiente. Si utiliza el mecanismo de guardar valores predeterminados en el primer registro entrado y usa Cargar en los registros siguientes, puede evitar que se duplique la entrada de datos en cada copia. (Esta posibilidad no está disponible para el Rational ClearQuest). El inconveniente es que los registros están aislados entre sí, lo que supone mayor esfuerzo en caso de que no se coordine el trabajo de los demás problemas relacionados.

Un planteamiento más eficaz consiste en utilizar una estructura jerárquica, en la que el registro padre califica el problema y los registros hijo se utilizan para realizar el seguimiento del problema para cada producto, variante o versión. El registro padre puede ser de un tipo diferente al de los registros hijo, o bien puede ser del mismo tipo. Algunos esquemas utilizan el mismo tipo de registro para los registros padre e hijo con el objeto de que toda la información se pueda contener en el hijo (reduciendo así la navegación entre padre e hijo). Otros esquemas utilizan un tipo de registro simple para implementar un tipo de recordatorio a fin de tratar el mismo problema en los demás productos, variantes o versiones afectados, así como para realizar el seguimiento del estado de los mismos.


Comentarios