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