Tâche: Création d'un processus de contrôle des changements
Cette tâche explique comment créer un processus de contrôle des changements.
Disciplines: Gestion de la configuration et des changements
Objet

Un processus de contrôle des changements standard et documenté permet de s'assurer que les changements sont effectués de façon cohérente et que les parties prenantes concernées sont informées de l'état du produit, des modifications apportées, ainsi que du coût et de l'impact sur le planning de ces modifications.

Relations
Etapes
Etablir le processus de demande de changement
Objet :  Les procédures de contrôle des changements permettent de s'assurer que les changements proposés pour le système sont évalués et appliqués de manière cohérente et contrôlée. 
Sous-étapes
Guides d'utilisation de l'outil
Plus d'informations : Concept : Gestion des demandes de changement 

Une procédure classique de gestion des demandes de changement est illustrée dans le diagramme d'activités ci-dessous. (Cliquez n'importe où dans le diagramme pour obtenir une description complète du Concept : Gestion des demandes de changement)

Exemples de tâches de gestion des demandes de changement Haut de la page

Concepts : Gestion des demandes de changement Flux de processus de demande de changement entre l'émetteur, le comité de contrôle des changements, un travailleur désigné et un testeur.

Remplir le formulaire de demande de changement 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.). Ceci doit inclure 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 Produit : Demandes de changement.

Les principaux états applicables à une demande de changement sont illustrés dans le diagramme suivant. (Cliquez n'importe où dans le diagramme pour obtenir une description complète du Concept : Gestion des demandes de changement)

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

Concepts : Gestion des demandes de changement Flux de processus pour une nouvelle demande de changement. Les états possibles sont : soumis, différé, ouvert, rejeté, affecté, résolu et vérifié.

Analyser la demande de changement haut de la page

Une fois soumise, la demande de changement est analysée pour s'assurer qu'elle est valide et que son opportunité fera l'objet d'une étude par le personnel technique et de management approprié. Les demandes de changement doivent être revues à différents niveaux au sein de l'équipe de développement. Généralement, le responsable de l'équipe se charge de revoir et d'approuver les demandes de changement soumises par les membres de son équipe. Toutefois, si l'ampleur de la demande de changement dépasse les responsabilités de l'équipe, elle est remontée au niveau supérieur. Enfin, si les répercussions du changement demandé concernent plusieurs équipes de développement, la demande est revue par le Comité de contrôle des changements. Dans le cadre du processus RUP (Rational Unified Process), le rôle de Responsable du contrôle des changements est utilisé pour représenter le rôle du Comité de contrôle des changements (CCB).

Certains dysfonctionnements du système sont davantage liés à une mauvaise utilisation qu'à un problème d'implémentation du système. Il peut également arriver qu'un problème ait déjà été signalé et soit en cours de traitement.

L'étape d'analyse s'achève soit par l'acceptation de la demande de changement, soit par un rejet si la demande est non valide, a déjà été formulée précédemment ou est "hors contexte" par rapport à la vision définie pour le projet.

Evaluer le coût d'une demande de changement haut de la page

Pour les demandes de changement valides, l'étape suivante consiste à évaluer le coût du changement en question, en fonction des répercussions qu'il aura sur l'ensemble du système et de sa facilité d'implémentation.

Les résultats de cette étape d'évaluation du coût sont transmis au CCB pour analyse. Ensuite, le CCB étudie la demande de changement et ses répercussions d'un point de vue stratégique et organisationnel, mais aussi technique. Le CCB doit déterminer si la demande de changement est justifiée sur le plan financier.

Appliquer la demande de changement haut de la page

Une fois que la demande de changement a été approuvée, elle peut être appliquée au logiciel. Le logiciel révisé subit alors des contrôles d'assurance qualité, afin de s'assurer que les changements ont été effectués conformément aux règles définies pour le projet, et qu'aucune conséquence néfaste sur le reste du logiciel ne se produira.

Une fois que les modifications ont été apportées, la nouvelle version du logiciel est vérifiée à l'aide d'une version de test du produit, puis incorporée et contrôlée dans une "version de diffusion" de l'ensemble du logiciel.

Gérer l'historique des changements haut de la page

Il est important de conserver une trace de tous les changements apportés au logiciel.

Une gestion efficace de l'historique des changements passe par la consignation des changements à la création de chaque composant logiciel, puis pour chaque demande de changement.

Vous trouverez ci-dessous un exemple des données de changement à consigner pour l'en-tête d'un composant :

Historique des changements

Motif du changement de date du modificateur de version

1.1 Bruce Bogtrotter 01.05.98 Tests CR n°232

1.2 Maria Mussolini 02.06.98. Exigences CR n°454

Etablir le tableau de contrôle des changements
Objet Nommer un Comité de contrôle des changements (CCB) qui approuvera les changements demandés concernant les éléments de configuration de référence. Cette équipe devra s'assurer que tous les changements proposés font l'objet d'une analyse technique appropriée, et sont documentés correctement à des fins de suivi et d'audit. 
Sous-étapes

Le CCB se réunit de façon régulière, mais aussi à la demande.

Les principales missions du CCB consistent à définir les références du produit, à analyser les demandes de changement, et à approuver, refuser ou différer l'implémentation de ces changements.

Sélectionner les membres haut de la page

Cette étape vise à constituer un CCB solide, composé de membres qui bénéficient de la reconnaissance de leurs homologues et qui justifient de suffisamment d'expérience pour identifier les demandes de changement coûteuses ou inappropriées. Le CCB doit compter des représentants de toutes les organisations et de toutes les parties prenantes concernées, par exemple :

  • Utilisateurs
  • Développeurs
  • Testeurs
  • Gestion de projets

Nommer le président du CCB haut de la page

Le Président du CCB doit impérativement être issu de l'équipe de gestion de projet. Il doit être capable de résoudre les conflits susceptibles de naître au sein de l'équipe, et d'appliquer les décisions du groupe.

Autant que possible, les décisions du CCB doivent être prises de manière consensuelle. La dynamique de groupe reflète l'aspect coopératif du projet de développement. Il incombe au Président du CCB d'encourager cet esprit de coopération, et de prendre des mesures unilatérales si le contexte l'exige.

Organiser des réunions pour évaluer les propositions de changement haut de la page

Le CCB doit se réunir de façon régulière, mais aussi selon les besoins, afin que les demandes de changement soient analysées et traitées dans des délais raisonnables. L'équipe de développement doit considérer ce groupe comme un arbitre fiable, capable de résoudre des problèmes qui auraient pu freiner l'avancement du projet.

Définir des protocoles de notification de révision des changements
Objet Les protocoles de notification de revue des changements permettent de s'assurer que les personnes appropriées sont informées de la soumission d'une demande de changement.
Déterminez qui doit réviser les différents produits. 
Guides d'utilisation de l'outil :  Définir les notifications de révision et de changement avec Rational ClearQuest

Cette étape se base sur la liste des produits à développer dans le cadre du projet.

Les membres de l'équipe doivent réviser les produits liés au produit afin de déterminer s'ils répondent aux normes de qualité définies pour le projet pour passer à l'étape de développement suivante. Si un produit ne répond pas à ces critères, il est retravaillé, modifié, puis réanalysé.

Pour que cette évaluation soit efficace, elle doit être effectuée par une équipe qui comprend la portée et l'impact des changements et des améliorations proposés. En outre, ces analyses doivent être "rentables" : les implémenteurs et les intégrateurs ne doivent pas perdre un temps précieux à corriger des défauts mineurs.

Doivent participer à cette analyse des représentants de tous les milieux concernés : conception du produit, destinataires et gestion. Ainsi, toutes les parties prenantes concernées par la qualité du produit peuvent statuer conjointement sur le passage du produit à l'étape de développement suivante.

Dans un contexte de travail en équipe, le projet est scindé en plusieurs activités. Des activités sont attribuées à des responsables pour implémentation et intégration. Par exemple, le système est divisé en sous-systèmes, puis en plusieurs packages. Les membres de l'équipe responsable de l'implémentation d'un package doivent s'assurer que les modifications sont revues par leurs homologues au sein du sous-système, mais aussi par les membres de tout autre sous-système concerné par ces changements.

Le principe de notification consiste à communiquer les changements proposés aux homologues, aux responsables d'équipe et aux destinataires, et de leur donner la possibilité de revoir et de commenter ces propositions.

Pour en savoir plus sur ce sujet, voir Concept : Gestion des demandes de changement.


 

Plus d'informations