Rubriques

Définitions Haut de la page

Demande de changement (CR) - Un artefact formellement soumis, utilisé pour suivre toutes les demandes des intervenants (y compris les nouvelles fonctionnalités, les demandes d'amélioration, les défauts, les exigences modifiées, etc.) et les informations d'état associées, tout au long du cycle de vie du projet. Tout l'historique des changements est conservé avec la demande de changement, y compris tous les changements d'état (avec leur date respective) et le motif de chaque changement. Ces informations seront disponibles pour les revues et la validation finale.

Comité de contrôle des changements (ou de la configuration) (CCB) - Comité qui supervise le processus de changement et qui se compose de représentants de toutes les parties concernées, y compris les clients, les développeurs et les utilisateurs. Dans un petit projet, un seul membre de l'équipe, tel que le chef de projet ou l'architecte logiciel, peut jouer ce rôle. Dans le Rational Unified Process, ceci est indiqué dans le Rôle du responsable du contrôle des changements.

Réunion de revue du CCB - La fonction de cette réunion 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 pour déterminer s'il s'agit d'une demande valable. 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. Cette réunion se tient généralement une fois par semaine. Si le volume des demandes de changement s'accroît d'une manière importante, ou à l'approche de la fin d'un cycle de version, la réunion peut se tenir même quotidiennement. Les membres types de la réunion du CCB sont le responsable du test, le responsable du développement et un membre du service marketing. Des participants supplémentaires peuvent être considérés nécessaires par le membre selon les "besoins".

Formulaire de soumission d'une demande de changement - Ce formulaire est affiché lorsqu'une demande de changement est soumise pour la première fois. Seuls les champs que l'émetteur doit remplir sont affichés dans le formulaire.

Formulaire combiné de demande de changement - Ce formulaire est affiché lorsque vous revoyez une demande de changement qui a déjà été émise. Il comporte tous les champs nécessaires pour décrire la demande de changement.

Le schéma suivant du processus de demande de changement décrit les états et les statuts des demandes de changement à travers leur processus global, et ceux qui doivent être notifiés durant le cycle de vie d'une demande de changement.

Exemples d'activités de gestion des demandes de changement Haut de la  page

L'exemple suivant montre des exemples d'activités qu'un projet peut adopter pour gérer les demandes de changement (CR) tout au long de son cycle de vie (cliquez sur les éléments du diagramme pour voir leur description) :

CR fermée Test échoué Vérifier les changements dans la construction de la version CR fermée Confirmer doublon ou rejet Soumise Plus d'informations Mettre à jour CR Soumise Rejet Doublon Vérifiée Vérifier les changements dans la construction de test Test échoué Faire des changements Résolu Rejet Doublon Vérifier les changements dans la construction de test Affecté Affecter et planifier le travail Soumettre CR Affecter et planifier le travail Ouverte Revue de CR Différée Soumise Demande de changement Comité de contrôle des changements Soumettre CR Diagramme décrit dans le libellé ci-dessus.

Gestion des demandes de changement (CRM) - Description des activités du processus :

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)

Exemples d'états et de transitions d'une demande de changement Haut de la  page

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] :

Réunion de revue du CCB Plus d'informations Plus d'informations Mettre à jour CR Mettre à jour CR Confirmer doublon ou rejet Vérifier les changements dans la construction de la version Fermée Plus d'informations Vérifiée Doublon Rejet Réunion de revue du CCB Soumettre CR Soumise Test échoué Vérifier les changements dans la construction de test Résolue Faire des changements Ouverte Affecter et planifier le travail Affecté Différée Demande de changement Diagramme  décrit dans le libellé ci-dessus.

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).

Diagramme décrit dans le libellé ci-dessous.

Etats des demandes de changement dans le contexte du cube CM.



RUP (Rational Unified Process)   2003.06.15