Objet
  • L'objet de cette activité est de déterminer si la demande de changement (CR) doit être acceptée ou marquée pour rejet. Pour les CR acceptées, cette activité évalue la priorité, l'effort nécessaire, le planning, etc. afin de déterminer si le changement sera effectué dans le cadre de la version actuelle.
Rôle :  Responsable du contrôle des changements 
Fréquence :  Une fois qu'un élément de configuration a été référencé et entré dans le système de gestion de la configuration, toute demande de changement de cet élément doit passer par le processus officiel de gestion des demandes de changement. 
Etapes
Artefacts d'entrée :    Artefacts de sortie :   
Guides d'utilisation de l'outil :   

Détails sur l'enchaînement d'activités :   

Programmer une réunion pour revue par le CCB Haut de la page

Le Comité de contrôle des changements (CCB) est chargé de superviser les processus de changement. Il est composé de représentants de toutes les parties concernées, y compris les clients, les développeurs et les utilisateurs. Pour un petit projet, une seule personne, par exemple le chef de projet ou l'architecte logiciel, peut jouer ce rôle. Dans le cadre du Rational Unified Process, ce rôle est rempli par le Responsable du contrôle des changements.

Ce comité est chargé de revoir les demandes de changement soumises. Il commence par revoir le contenu de la demande de changement afin de se prononcer sur sa validité. Si la CR est valide, il s'agit ensuite de déterminer si elle entre dans le cadre de la version actuelle, en fonction de critères de priorité, de planification, de ressources, de niveau d'effort, de risque, de gravité, et de tout autre critère déterminé par le groupe. Une réunion de ce type est généralement organisée une fois par semaine. Toutefois, si le nombre de CR est important, ou lorsque la fin du cycle de développement approche, le rythme peut devenir quotidien. 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 membres peuvent également être conviés "selon les besoins".

Extraire les demandes de changement pour revue Haut de la page

Le formulaire de demande de changement est un artefact soumis de manière formelle, utilisé pour effectuer le suivi de toutes les demandes (nouvelles fonctionnalités, demandes d'amélioration, défauts, nouvelles exigences, etc.) et des 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 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. Un exemple de formulaire de demande de changement est fourni dans Artefact : Demandes de changement.

Revoir les demandes de changement soumises Haut de la pagee

L'objet de cette activité est de revoir les demandes de changement soumises. Cet état peut faire suite à 1) la soumission d'une nouvelle CR, 2) la mise à jour d'une CR existante CR ou 3) l'analyse d'une CR différée sur un cycle de développement ultérieur. La CR est placée dans la file d'attente des CR à revoir par le CCB. Aucun propriétaire n'est affecté suite à cette action.

Le CCB commence par revoir le contenu de la demande de changement afin de se prononcer sur sa validité. Si la CR est valide, il s'agit ensuite de déterminer si elle entre dans le cadre de la version actuelle, en fonction de critères de priorité, de planification, de ressources, de niveau d'effort, de risque, de gravité, et de tout autre critère déterminé par le groupe.

Si la CR est valide, mais "hors champ" pour la version actuelle, son état passe à Différé, ce qui signifie qu'elle sera réexaminée lors des versions ultérieures. Une version cible peut être affectée pour indiquer la date approximative à laquelle la CR pourra être de nouveau soumise, réintégrant ainsi la file d'attente des CR à revoir par le CCB.

Si une CR semble être identique à une autre CR qui a déjà été soumise, elle doit être transmise au responsable du CCB ou au membre de l'équipe désigné pour résoudre ce problème. Lorsque l'état d'une CR passe à Doublon, le numéro de la CR qui semble identique est enregistré (sous l'onglet Attachments dans ClearQuest). Un demandeur doit toujours effectuer une recherche de doublons dans la base de données des CR avant de soumettre une CR. Cela évite un certain nombre d'étapes du processus de revue et permet donc un gain de temps considérable. La personne qui a soumis la CR en double doit être ajoutée à la liste de notification de la CR d'origine pour toutes les questions concernant la résolution.

Parfois, le CCB ou la personne désignée peut conclure que la CR n'est pas valide ou que le demandeur doit fournir davantage d'informations. Si elle est déjà affectée (Ouverte), la CR est supprimée de la file d'attente de résolution et sera réexaminée ultérieurement. Un membre du CCB est chargé de confirmer cette décision. Aucune action n'est nécessaire de la part du demandeur sauf si cela est explicitement indiqué (auquel cas l'état de la CR passe à Plus d'informations. La CR sera alors réexaminée au sein du CCB, à la lumière des nouvelles informations soumises. Si le CCB maintient le caractère non valide de la CR, celle-ci est fermée et le demandeur en est informé.

Si une CR est considérée comme "hors champ" pour la version en cours, son état reste Ouvert, en attente de résolution. Elle est marquée pour résolution avant une certaine date cible. Elle est placée dans la "file d'attente d'affectation". Les membres du Comité sont seuls habilités à ouvrir une CR qui se trouve dans la file d'attente de résolution. Si une CR de priorité 2 ou supérieure est mise en évidence, il convient d'en aviser immédiatement le QE ou le chef de projet. A ce stade, une réunion extraordinaire du CCB peut être décidée, ou une personne habilitée peut ouvrir la CR en question immédiatement.

La CR ouverte est alors sous la responsabilité du chef de projet, qui devra affecter les tâches nécessaires en fonction du type de CR et mettre à jour le planning le cas échéant.

Les différents états applicables à une demande de changement sont répertoriés dans Concepts : Gestion des demandes de changement



RUP (Rational Unified Process)   2003.06.15