Dans le processus de travail ALM, les demandes sont résolues par des tâches et des activités réalisées.
Le schéma et les packages ALM permettent de disposer d'un processus prêt à l'emploi pour utiliser Rational ClearQuest et effectuer le suivi du travail de votre équipe sur une édition du produit. ALM utilise des rôles, des types d'enregistrement et des modèles de transition d'état définis pour vous aider à gérer le processus de développement du logiciel, de la soumission des exigences au développement, en passant par la gestion de la sous-version et le test.
Le processus ALM type se déroule comme suit :
- Une partie prenante soumet une demande relative à un projet de logiciel. La partie prenante peut être un développeur, un testeur, un rédacteur, un formateur, un responsable de produit, un responsable de l'assistance à la clientèle, un membre de l'équipe de projet ou un utilisateur du produit.
Une demande peut initier un changement dans le projet du logiciel. Une demande peut être un incident, une demande d'extension (RFE) ou une tâche.
- L'équipe de triage révise la demande et décide de l'accepter ou non. Si la demande est acceptée, l'administrateur du triage crée une ou plusieurs tâches (une par projet) décrivant à un niveau élevé le travail requis pour répondre à la demande.
- Le responsable du développement de chaque projet révise la tâche et évalue le travail nécessaire à sa mise en oeuvre. Le responsable du développement active ensuite la tâche, puis crée les activités nécessaires à sa réalisation, telles que :
- activité Dev
- activité Test
- activité Doc Assess
Le responsable du développement affecte l'activité Dev à un développeur.
- Le responsable du test révise la tâche et l'activité Test, puis affecte l'activité à un testeur. Le responsable de la documentation révise la tâche et l'activité Doc Assess, puis affecte l'activité à un rédacteur.
- Le développeur travaille sur l'activité Dev et apporte les changements nécessaires aux fichiers. Le développeur fait ensuite passer l'activité Dev à l'état Completed.
- L'ingénieur d'édition crée un enregistrement de version de référence qui sélectionne la dernière activité terminée et les changements associés.
- L'ingénieur d'édition conçoit le projet à l'aide de la nouvelle version de référence créée.
L'ingénieur d'édition crée un enregistrement de sous-version qui identifie la version de référence utilisée et indique si la sous-version a réussi ou échoué.
- Le testeur installe la sous-version, puis la teste. Lorsque la sous-version passe correctement les tests, le testeur fait passer l'activité Test à l'état Completed.
- Le rédacteur évalue l'impact de la tâche sur la documentation et apporte les changements nécessaires. Le rédacteur fait ensuite passer l'activité Doc Assess à l'état Completed.
- Le responsable du test révise la tâche, constate que les activités nécessaires ont été réalisées, puis fait passer la tâche à l'état Completed. Le responsable du test peut sinon créer d'autres activités ou d'autres commentaires sur des activités existantes, si davantage de travail doit être effectué.
- La partie prenante qui a soumis la demande la révise et constate qu'une ou plusieurs tâches associées ont été réalisées. La partie prenante peut ouvrir la tâche et réviser la résolution. A partir du formulaire d'enregistrement de tâche, la partie prenante peut ouvrir les activités associées et réviser les détails des travaux de développement, de documentation et de test effectués pour réaliser la tâche. Si tous les éléments paraissent satisfaisants, la partie prenante accepte la demande, et la fait passer à l'état Completed. Sinon, la partie prenante peut rejeter la demande et apporter un commentaire sur la tâche. Le responsable du test est informé des instructions relatives au travail supplémentaire par e-mail.