Valores de registro

Puede utilizar valores del sistema para tipos de registro que le ayuden a gestionar, categorizar y aplicar políticas de seguridad a los procesos de trabajo.
Los siguientes tipos de valores del sistema son para gestionar proyectos y trabajo:

Los registros ALMSecurityPolicy están asociados con una categoría y también están asociados con proyectos, ya que se crean proyectos que hacen referencia a la categoría. Para equipos que realicen desarrollo de componentes, pueden existir varios componentes, cada uno de los cuales con sus propias categorías y releases, como parte de una o más ofertas. En este caso, una relación de uno a uno entre una categoría y una SecurityPolicy puede hacer que algunos registros no sean visibles a las personas que necesitan verlos. Para evitar problemas de visibilidad, una SecurityPolicy debe incluir un grupo de usuarios ClearQuest grande como su referencia ratl_context_groups o debe tener un grupo de usuarios para cada componente con todos los grupos de usuarios a los que hace referencia la SecurityPolicy que serían compartidos por todos los equipos de desarrollo que trabajan en los componentes. También existen ventajas de rendimiento si se mantiene un conjunto de grupos más pequeños en lugar de utilizar un grupo grande (o si se establece SecurityPolicy en el grupo Everyone) y se organizan los grupos y los registros SecurityPolicy mediante la estructura de los componentes.

Ejemplo de desarrollo de componentes

Cada parte versionada del nuevo trabajo de desarrollo puede ser un Proyecto con una Categoría que especifique el componente y un Release que especifique la versión de esa Categoría.

Un cliente encuentra un problema en un producto importante producido por el equipo de desarrollo. Este Producto (denominado Oferta) incluye varios Componentes y cada uno de ellos ha sido desarrollado por equipos distintos. Cuando el cliente ve el problema, considera que la Oferta tiene el problema en lugar de los Componentes de la Oferta. Cuando el jefe del equipo sigue el proceso de clasificación de una Solicitud para esa Oferta y revisa la Solicitud, tendrá en cuenta lo siguiente:
  • El problema se encuentra en un Componente que se incluye en la Oferta y es necesario arreglarlo ahí y no en la Oferta que es posible que no sea más que una colección de Componentes y es posible que no tenga nada de código propio, excepto lo que se proporciona en el Componente que incluye.
  • Es necesario que la Oferta incluya la nueva versión del Componente una vez que se haya arreglado y que se proporcione una nueva versión de esa Oferta a como mínimo el cliente que ha descubierto el problema y posiblemente a todos los demás clientes.
El equipo clasificador crea dos registros ALMTask asociados con la ALMRequest entrada para el Proyecto para una Categoría y Release determinados (por ejemplo, Categoría='OfferingA' y Release = '1.0'):
  • ALMTask con Categoría de proyecto='OfferingA' y Release = '1.1'
  • ALMTask con Categoría de proyecto= 'ComponentZ' y Release= '3.4'
En primer lugar el equipo clasificador ha revisado el registro ALMBaseline para Categoría de proyecto='OfferingA' y Release = '1.0' porque estos valores son lo que la ALMRequest ha identificado como FoundInProject y pueden ver que el Release de 'ComponentZ' que se lista en el campo ComposedOfBaselines de ALMBaseline es Release = '3.3'.

Se crean actividades para la ALMTask para 'ComponentZ' y la solución se desarrolla, documenta y prueba. Se crea un registro ALMBaseline cuando se crea la línea base real para Categoría de proyecto = 'ComponentZ' y Release = '3.4' y se crea una segunda ALMBaseline para Categoría de proyecto = 'OfferingA' y Release = '1.1' y ese registro ALMBaseline tiene un valor ComposedOfBaselines (otro registro de línea base) que tiene una Categoría de proyecto = 'ComponentZ' y Release = '3.4'.

Se crea un BTBuild para la ALMBaseline cuya Categoría de proyecto = 'OfferingA' y Release = '1.1'. Los verificadores pueden ver que se muestra un BTBuild en la columna Build y la columna Composite.Build de la actividad 'Dev' visualizada en el control de formulario de actividad de la tarea cuya Categoría de proyecto = 'OfferingA' y Release = '1.1'. Pueden ver que existe como mínimo el ID de compilación generado a partir de la línea base compuesta y en el conjunto de resultados de la consulta pueden ver el nombre de esa compilación. Los verificadores de componentes y los verificadores de ofertas pueden ver que hay una compilación basada en la línea base compuesta.

En el registro de línea base compuesta se lista el componente en el campo ComposedOfBaselines.


Comentarios