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.
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) :
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)
|
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
|
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).
Etats des demandes de changement dans le contexte du cube CM.
|