Configuración del trabajo

La configuración del trabajo permite que los gestores de proyectos definan un proceso recomendado para un proyecto en función del propio proyecto.
El registro de configuración del trabajo define las políticas de proceso del trabajo para un proyecto determinado, especificando el conjunto de actividades necesario para que se pueda completar dicho trabajo. Por ejemplo:
  • Un tipo de Solicitud puede que necesite uno o varios tipos especiales de Tarea.
  • Un tipo de tarea puede tener su propio conjunto de actividades.

El valor ALMWorkConfiguration especifica el tipo de trabajo que se realiza en un proyecto determinado y los roles que tienen permiso para realizar ese trabajo. Los tipos de paquete ALMWork de ALMRequest, ALMTask y ALMActivities utilizan los registros de configuración de trabajo del proyecto para controlar el tipo de registros trabajo que deben generar las acciones CreateTask y CreateActivity, además de varias selecciones de la lista de opciones para los campos de estos registros de trabajo. Los campos obligatorios son Project, SecurityPolicy, Record Type, ALMType y Roles. Los campos Primary Children Configs y Secondary Children Configs son opcionales.

El registro de proyecto hace referencia a un registro de configuración del trabajo, que a su vez hace referencia a un rol y a un tipo de trabajo.

Los registros de configuración del trabajo definen qué tipos de trabajo (ALMType) utiliza el proyecto. De esta forma, se pueden incluir instrucciones de proceso a un proyecto al controlar los tipos de trabajo realizado para resolver una solicitud o para completar una tarea.

Cada registro WorkConfiguration puede generar una lista de un conjunto de Primary Children configs y Secondary Children configs. Estas listas las utilizan las acciones CreateTask (en el registro ALMRequest) y CreateActivity (en el registroALMTask). La acción CreateTask o CreateActivity crea un conjunto de registros que se enumeran en Primary Children Configs la primera vez que se realiza una acción CreateTask/Activity. Las acciones CreateTask/Activity posteriores utilizan la lista Secondary children config para crear más registros.

Al utilizar estas configuraciones de Primary y Secondary children, debe especificar un conjunto de tareas a completar para cada tipo de solicitud y puede especificar también un conjunto de actividades a completar para cada tipo de tarea. Por ejemplo, puede crear una tarea para iniciar un proyecto. Esta tarea puede tener actividades como Definir roles, Buscar miembros del equipo y Definir iteraciones.

La base de datos de muestra de ALM para OpenUP ejemplifica cómo utilizar las configuraciones de trabajo para implementar el proceso OpenUP.

Ejemplo

El proyecto A tiene una solicitud del tipo Defecto. Se utiliza la configuración del trabajo para establecer una regla que estipula que, cuando se crea una solicitud del tipo Defect, se cree de forma predeterminada una tarea del tipo Defect. Se crean otras configuraciones de trabajo para este proyecto por cada tipo de actividad (Develop y Test) y se define otra configuración de trabajo para el registro de tarea de defecto. Esta configuración de trabajo crea una regla que estipula, cuando se crea una tarea del tipo Defect, que se cree de forma predeterminada una actividad del tipo Develop y una actividad del tipo Test.

El proyecto B también tiene una solicitud del tipo Defecto, y una configuración de trabajo con una regla para crear una tarea del tipo Defect. Sin embargo, la configuración de trabajo para el registro de la tarea es distinta. Para el proyecto B, la regla especifica que se deben crear actividades del tipo Design, Develop, Review y Test.

Existen conjuntos de tareas Primary y Secondary creados para las solicitudes y actividades de las tareas. El conjunto Primary se crea más frecuentemente y es el conjunto que se crea la primera vez que se genera una tarea para una solicitud o una actividad para una tarea.

El conjunto Secondary se crea la segunda vez que se selecciona Solicitud > CreateTask o Tarea > CreateActivity.

Puede que haya uno o varios roles para una configuración de trabajo El campo Rol se utiliza con las finalidades siguientes:
  • Los valores de Rol > Miembros y grupos se utilizan para determinar la lista de opciones para el campo Propietario.
  • EL valor Role > Primary > ratl_mastership se utiliza para establecer el valor predeterminado para el propietario y establecer la maestría de la actividad en estado Submitted si no existe un propietario predeterminado.
Las solicitudes se asocian a individuos, no a Roles. Por ejemplo, la persona que envía una solicitud también puede ser el propietario de dicha solicitud. Así, el campo Rol del registro WorkConfiguration de una solicitud no permite el establecimiento de un rol.

Comentarios