Visión general del proceso de trabajo ALM

En el proceso de trabajo ALM, las tareas y las actividades completadas resuelven las solicitudes.

Los paquetes y el esquema ALM (gestión del ciclo vital de la aplicación) proporcionan un proceso listo para usar gracias al cual se puede utilizar Rational ClearQuest para realizar el seguimiento del trabajo del equipo en un release del producto. ALM utiliza modelos de transición de estados, tipos de registro y roles definidos para ayudarle a gestionar el proceso de desarrollo de software desde el envío de requisitos hasta el desarrollo, la gestión de compilaciones y la prueba.

El proceso ALM básico es el siguiente:

  1. Un interesado envía una solicitud con respecto a un proyecto de software. El interesado puede ser un desarrollador, verificador, grabador, formador, gestor de productos, representante del soporte al cliente, otro miembro del equipo del proyecto o usuario del producto. Una solicitud puede iniciar un cambio en el proyecto de software. Una solicitud puede ser un defecto, una solicitud de mejora (RFE) o una tarea.
  2. El equipo clasificador revisa la solicitud y decide si se debe aceptar o no. Si aceptan la solicitud, el administrador de clasificación crea una o varias tareas (una por proyecto) en las que se proporciona una descripción a alto nivel sobre el trabajo necesario para satisfacer la solicitud.
  3. El Jefe de desarrollo de cada proyecto revisa la tarea, evalúa el trabajo necesario para implementarla y, a continuación, activa la tarea y crea tres actividades asociadas a la misma:
    • Actividad de desarrollo
    • Actividad de prueba
    • Actividad de evaluación de documentos

    El Jefe de desarrollo asigna la actividad de desarrollo a un desarrollador.

  4. El verificador principal revisa la tarea y la actividad de prueba y, a continuación, asigna la actividad de prueba a un verificador. El jefe de documentación revisa la tarea y la actividad de evaluación de documentos y, a continuación, asigna la actividad de evaluación de documentos a un grabador.
  5. El desarrollador trabaja en la actividad de desarrollo y realiza los cambios necesarios en los archivos. A continuación, el desarrollador cambia la actividad de desarrollo al estado de completada.
  6. El ingeniero de release crea un nuevo registro de línea base que selecciona la actividad que se acaba de completar y el conjunto de cambios asociado.
  7. El ingeniero de release compila el proyecto utilizando la línea base recién creada. A continuación, crea un registro de compilación que identifica la línea base utilizada e indica si la compilación ha sido satisfactoria o ha dado error.
  8. El verificador instala y prueba la compilación. Cuando la compilación pasa todas las pruebas satisfactoriamente, el verificador cambia la actividad de prueba al estado Completed.
  9. El grabador evalúa el impacto de la tarea en la documentación y realiza todos los cambios necesarios. A continuación, cambia la actividad de evaluación de documentos al estado Completed.
  10. El verificador principal revisa la tarea, observa que se hayan completado todas las tareas y cambia la tarea al estado Completed. Si no, crea actividades adicionales o comentarios sobre actividades existentes, en caso de que quede trabajo pendiente por realizar.
  11. El interesado que ha enviado la solicitud, la revisa y comprueba si se han completado una o varias tareas asociadas. Puede abrir la tarea y revisar la resolución. En el formulario de registro de tareas, el interesado puede abrir las actividades asociadas y revisar los detalles sobre el trabajo de desarrollo, documentación y prueba realizado para completar la tarea. Si todo parece correcto, el interesado acepta la solicitud y la cambia al estado Completed. En caso contrario, puede no aceptar la solicitud y comentar la tarea, enviando una notificación al verificador principal por correo electrónico con instrucciones para el trabajo adicional.

Comentarios