Concept: Gestion des demandes de changement
La gestion des demandes de changement est un processus qui garantit l'utilisation de procédures et méthodes standardisées pour un traitement rapide et efficace de tous les changements, dans le but de minimiser l'impact des incidents relatifs à ces changements.
Relations
Description principale

Définitions

Demande de changement (CR) - Produit soumis formellement, utilisé pour toutes les demandes des parties prenantes y compris les nouvelles fonctions, les demandes d'amélioration, les défauts, les exigences modifiées et les informations relatives au statut dans tout le 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, par exemple le responsable 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 réviser les demandes de changement soumises. Une revue initiale du contenu de la demande de changement est effectuée lors de 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 l'édition ou des éditions en cours, en fonction 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 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 d'édition, la réunion peut se tenir même quotidiennement. On retrouve généralement au sein du comité CCB le responsable du test, le responsable du développement et un représentant du service Marketing. D'autres participants peuvent être appelés à la demande des membres 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. Le processus général de demandes de changement est décrit dans  Tâche : Etablir le processus de contrôle de changement.

Exemples de tâches de gestion de demandes de changement

L'exemple suivant montre les tâches qui pourraient être adoptées pour la gestion d'une demande de changement d'un projet (CR) à travers son cycle de vie (cliquer sur les éléments du schéma pour visualiser les descriptions) :

CR fermée Echec du test Vérifier les changements dans la construction d'édition CR fermée Confirmer doublon ou rejet Soumis Plus d'informations Mettre à jour la CR Soumis Rejet Doublon Vérifié Vérifier les changements dans la construction de test Echec du test Effectuer 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 Ouvert Réviser CR Différé Soumis Demande de changement Comité de contrôle des changements Soumettre CR Diagramme décrit dans la légende ci-dessus.

Descriptions d'un exemple de tâches du processus de demandes de changement :

Tâche Description Responsabilité
Soumettre une demande de changement Toute partie prenante du projet peut soumettre une demande de changement (CR). En lui attribuant le statut Soumis, 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. Emetteur
Revue de CR L'objet de cette tâche est d'effectuer une revue des 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 l'édition ou des éditions en cours, en fonction 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. Représentant du CCB
Mise à jour de 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 & planifier le travail Une fois la demande de changement Ouverte, le responsable 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. Responsable 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 & conception, implémentation, production des supports d'aide à l'utilisateur, test de conception pour effectuer les changements requis. Ces tâches comprendront toutes les tâches normales de revue et de test, tel que décrit dans les processus de développement normal. La demande de changement aura alors pour statut Résolu. 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 sont placés dans une file d'attente de test pour être affectés à un testeur et Vérifiés dans une construction de test du produit. Testeur
Vérifier les changements dans une construction d'édition Une fois que les changements résolus ont été Vérifiés dans une construction de test du produit, la demande de changement est placée dans une file d'attente d'édition pour être vérifiée dans une construction d'édition du produit, pour produire des notes sur l'édition etc. et Fermer la demande de changement. Représentant du CCB (Intégrateur système)

Exemples d'états et de transitions d'une demande de changement

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 la CR Mettre à jour la CR Confirmer doublon ou rejet Vérifier les changements dans la construction d'édition Fermé Plus d'informations Vérifié Doublon Rejet Réunion de revue du CCB Soumettre CR Soumis Echec du test Vérifier les changements dans la construction de test Résolu Effectuer des changements Ouvert Affecter et planifier le travail Affecté Différé Demande de changement Diagramme décrit dans la légende ci-dessus.

Exemples de descriptions d'états pour la gestion des demandes de changement (CRM) :

Etat Définition Contrôle d'accès
Soumis 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 d'édition. La demande de changement est placée dans la file d'attente de revue du CCB. Aucun propriétaire n'est affecté suite à cette action. Tous les utilisateurs
Différé La demande de changement est déterminée comme étant valide mais "hors de portée" pour l'édition actuelle ou les éditions actuelles. Les demandes de changement qui se trouvent dans l'état Différé seront conservées et prises en considération dans les prochaines éditions. Une édition cible peut être affectée pour indiquer le laps de temps dans lequel la demande de changement peut être Soumise pour intégrer de nouveau la file d'attente de revue du CCB. Admin

Responsable 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 d'é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

Responsable de projet

Responsable QE

Développement

Rejeté 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 a dé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, elle sera Fermée par le CCB et l'émetteur en aura notification. Admin

Responsable 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
Ouvert Une demande de changement ouverte a été déterminée comme étant "dans la portée" de l'édition actuelle et se trouve en 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

Responsable de projet

Responsable du développement

Service QE

Affecté Le responsable de projet est alors responsable de cette demande de changement Ouverte et devra affecter le travail en fonction du type de demande de changement et mettre à jour le planning le cas échéant. Responsable de projet
Résolu 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

Responsable de projet

Responsable du développement

Responsable QE

Service développement

Echec du test Une demande de changement qui échoue au test, que ce soit dans une construction de test ou une construction d'édition, 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é Une demande de changement dans cet état a été Vérifiée dans une construction de test et est prête pour être intégrée dans une édition. Admin

Service QE

Fermé 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 Fermé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 dans une construction d'édition, 2) lorsque l'état Rejeté a été confirmé ou 3) lorsqu'elle a été confirmée comme Doublon d'une demande de changement existante. Dans ce dernier cas, l'émetteur sera informé du doublon et sera ajouté à cette 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 de 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 la légende ci-dessus.

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