Concepts :
|
Activité | Description | Responsabilité |
---|---|---|
Soumettre CR | Toute partie prenante du projet peut soumettre une demande de changement (CR). La demande de changement est enregistrée dans le système de suivi des demandes de changement (par exemple Rational ClearQuest) et placée dans la file d'attente de revue du CCB, en mettant l'état de la demande de changement à Soumise. | Emetteur |
Revue de CR | La fonction de cette activité est de revoir les demandes de changement soumises. Une revue initiale du contenu de la demande de changement est effectuée dans la réunion de revue du CCB pour déterminer s'il s'agit d'une demande valide. Si c'est le cas, il s'agira alors de déterminer si le changement se situe dans la portée ou hors de la portée de la version ou des versions en cours, sur la base de la priorité, du planning, des ressources, du niveau d'effort, du risque, de la gravité et d'autres critères pertinents déterminés par le groupe. | CCB |
Confirmer doublon ou rejet | S'il est suspecté qu'une demande de changement est en double ou sera rejetée car incorrecte (par exemple, erreur de l'opérateur, non-reproductible, mauvais fonctionnement, etc.), un représentant du CCB sera affecté pour confirmer le doublon ou le rejet de la demande de changement et, si nécessaire, pour recueillir davantage d'informations de l'émetteur. | Délégué du CCB |
Mettre à jour la CR | Si davantage d'informations sont nécessaires (Plus d'informations) pour évaluer la demande de changement, ou si la demande de changement est rejetée à n'importe quel point du processus (c'est-à-dire confirmée comme Doublon, Rejetée, etc.), l'émetteur sera notifié et peut mettre à jour la demande de changement avec de nouvelles informations. La demande de changement mise à jour est alors soumise à nouveau à la liste d'attente de revue du CCB pour examen des nouvelles données. | Emetteur |
Affecter et planifier le travail | Une fois la demande de changement Ouverte, le chef de projet aura à affecter le travail au membre approprié de l'équipe - en fonction du type de demande (c'est-à-dire demande d'amélioration, défaut, changement dans la documentation, défaut de test, etc.) - et effectuer toutes mises à jour nécessaires au planning du projet. | Chef de projet |
Effectuer des changements | Le membre désigné de l'équipe effectue l'ensemble des activités définies dans la section appropriée du processus (c'est-à-dire exigences, analyse et conception, implémentation, production des supports d'aide à l'utilisateur, test de conception, etc.) pour effectuer les changements demandés. Ces activités comprendront toutes les activités normales de revue et de test individuel, tel que décrit dans les processus de développement normal. La demande de changement sera ensuite marquée comme Résolue. | Membre désigné de l'équipe |
Vérifier les changements dans la construction de test | Une fois les changements Résolus par le membre désigné de l'équipe (analyste, développeur, testeur, rédacteur de test, etc.), les changements seront dans une file d'attente de test pour être affectés à un testeur et Vérifiés dans la construction de test du produit. | Testeur |
Vérifier les changements dans la construction de test | Une fois les changements résolus Vérifiés dans la construction de test du produit, la demande de changement sera placée dans une file d'attente de version en vue d'être vérifiée dans une construction de version du produit, produire des notes de version, etc. et Clore la demande de changement. | Délégué du CCB (Intégrateur système) |
Le diagramme suivant montre des exemples d'états, avec les personnes à notifier, tout au long du cycle de vie d'une demande de changement(CR) [Cliquez sur les éléments du diagramme pour voir les descriptions] :
Exemples de descriptions d'états pour la gestion des demandes de changement (CRM) :
Etat | Définition | Contrôle d'accès |
---|---|---|
Soumise | Cet état se produit par suite de 1) une soumission d'une nouvelle demande de changement, 2) une mise à jour d'une demande de changement existante ou 3) une prise en compte d'une demande de changement différée pour un nouveau cycle de version. La demande de changement est placée dans la file d'attente de revue du CCB. Aucune désignation de propriétaire n'est effectuée par suite de cette action. | Tous les utilisateurs |
Différée | La demande de changement est considérée valide, mais "en dehors de la portée" de la version en cours. Les demandes de changement qui se trouvent dans l'état Différée seront conservées et prises en considération dans les prochaines versions. Une version cible peut être désignée pour indiquer le laps de temps dans lequel la demande de changement peut être Soumise pour rentrer à nouveau dans la file d'attente de revue du CCB. | Admin
Chef de projet |
Doublon | Une demande de changement qui se trouve dans cet état est considérée en double avec une autre demande de changement précédemment soumise. Les demandes de changement peuvent être placées dans cet état par l'administrateur de revue du CCB ou par le membre de l'équipe désigné pour la résoudre. Lorsque la demande de changement est placée dans l'état de Doublon, le numéro de demande de changement auquel elle vient en doublon sera enregistré (dans l'onglet Attachments de ClearQuest). Un émetteur doit initialement interroger la base de données de demandes de changement pour détecter les éventuels doublons, avant de soumettre soumettre sa CR. Ceci permettra d'éviter plusieurs étapes du processus de revue et par conséquent économiser beaucoup de temps. Les émetteurs de demandes de changement en double doivent être ajoutés à la liste de notification de la demande de changement originale, en vue des notifications ultérieures concernant la résolution. | Admin
Chef de projet Responsable QE Développement |
Rejetée | Une demande de changement dans cet état est considérée par la réunion de revue du CCB ou par le membre de l'équipe désigné comme une demande non valide ou nécessitant plus d'informations de l'émetteur. Si elle adéjà l'état (Ouverte), la demande de changement sera supprimée de la file d'attente de résolution et sera revue à nouveau. Une autorité qualifiée du CCB est désignée pour confirmer. Aucune action n'est demandée à l'émetteur, à moins que cela ne soit considéré nécessaire, auquel cas l'état de la demande de changement sera transformé en Plus d'informations. La demande de changement sera revue à nouveau au cours de la réunion de revue du CCB pour examiner toutes informations nouvelles. Si elle est confirmée comme non valide, la demande de changement est Fermée par le CCB et l'émetteur en aura notification. | Admin
Chef de projet Responsable du développement Responsable des tests |
Plus d'informations | Données insuffisantes pour confirmer la validité d'un état de Rejet ou de Doublon d'une demande de changement. Le propriétaire s'adressera automatiquement à l'émetteur pour lui demander de fournir plus de données. | Admin |
Ouverte | Une demande de changement dans cet état a été considérée "dans la portée" de la version en cours et se trouve dans l'attente de résolution. Elle a été inscrite pour être résolue avant d'atteindre un jalon cible à venir. Elle a été définie comme étant dans la "file d'attente d'affectation". Les membres de la réunion ont seuls l'autorité d'ouvrir une demande de changement dans la file d'attente de résolution. S'il se trouve une demande de changement de priorité deux ou supérieure, elle doit être immédiatement portée à l'attention du responsable QE ou du responsable du développement. A ce stade, ils peuvent convenir d'une réunion de revue urgente du CCB ou simplement d'ouvrir immédiatement la demande de changement dans la file d'attente de résolution. | Admin
Chef de projet Responsable du développement Service QE |
Affectation | Une demande de changement ouverte est de la responsabilité du chef de projet, qui devraaffecter le travail sur la base du type de demande de changement et mettre à jour le planning, si nécessaire. | Chef de projet |
Résolue | Signifie que la résolution de cette demande de changement est achevée et que celle-ci est à présent prête pour la vérification. Si l'émetteur est membre du service QE, le propriétaire devient automatiquement le membre QE émetteur ; sinon, il deviendra responsable QE, en vue d'une réaffectation manuelle. | Admin
Chef de projet Responsable du développement Responsable QE Service développement |
Test échoué | Une demande de changement qui échoue au test, que ce soit dans une construction de test ou une construction de version, sera placée dans cet état. Le propriétaire deviendra automatiquement le membre de l'équipe qui a résolu la demande de changement. | Admin
Service QE |
Vérifiée | Une demande de changement dans cet état a été Vérifiée dans une construction de test et se trouve prête à être intégrée à une version. | Admin
Service QE |
Fermée | La demande de changement n'a plus besoin d'aucune intervention. C'est l'état final pouvant être affecté à une demande de changement. Seul d'administrateur de revue du CCB a autorité pour fermer une demande de changement. Lorsqu'une demande de changement est Cfermée, l'émetteur recevra une notification par e-mail l'informant de la décision finale sur la demande de changement. Une demande de changement peut être Fermée : 1) après que sa résolution Vérifiée a été validée par une construction de version, 2) lorsque son état de Rejet a été confirmé, ou 3) lorsqu'il a été confirmé qu'il s'agit d'un Doublon d'une demande de changement existante. Dans ce dernier cas, l'émetteur sera informé du doublon et sera ajouté à la demande de changement existante pour les notifications ultérieures (voir les définitions des états "Rejet" et "Doublon" pour plus de détails). Si l'émetteur souhaite contester la fermeture, la demande de changement doit être mise à jour et Soumise à nouveau à la revue du CCB. | Admin |
Les 'indicateurs' d'état fournissent une base aux statistiques de reporting des demandes de changement (chronologique, distribution ou tendance).
Etats des demandes de changement dans le contexte du cube CM.
RUP (Rational Unified Process)
|