Artefact :
|
![]() |
Demande de changement sont utilisées pour la documentation et le suivi des demandes de changement du produit. Ceci permet d'archiver les décisions et garantit, pour autant qu'un processus d'évaluation adéquat soit en vigueur, une analyse de l'impact du changement demandé. |
---|---|
Rôle : | Responsable du contrôle des changements |
Caractère facultatif/Occurrence: | Obligatoire. Survient autant de fois que requis. |
Modèles et rapports : |
|
Exemples : |
|
Représentation UML : | Sans objet. |
Informations supplémentaires : |
Entrée d'activités : | Sortie d'activités : |
La nécessité de changements est inhérente au développement d'un système logiciel et accompagne son évolution depuis sa création initiale et au cours de son utilisation et de sa maintenance ultérieure pour son opération quotidienne au sein d'un environnement dynamique. Demande de changement sont aussi connues sous d'autres noms et abréviations comme CR (Change Request - Demande de changement), défauts, bogues, incidents, demandes d'améliorations. Le recensement et la gestion appropriés de ces demandes permet d'appliquer les changements de manière contrôlée et de pouvoir prédire leurs conséquences sur le système. Les formats d'importation des Demande de changement peuvent être les suivants :
Demandes d'améliorations. Elles sont utilisées par diverses parties pour réclamer des fonctionnalités futures qu'elles souhaitent voir intégrer dans le produit. Ce type de demande d'intervenant capture et formule des besoins propres à ces parties prenantes.
Défauts. Ce sont des comptes-rendus d'anomalies ou d'échecs dans un outil de travail livré. Les défauts couvrent les omissions et les imperfections détectées lors des phases précoces de son cycle de vie, ou des symptômes de défaillances (échecs) devant être isolées et corrigées dans le logiciel. Ils peuvent aussi rapporter des déviations par rapport aux comportements qu'il est raisonnable d'attendre du logiciel (par exemple, problèmes de convivialité).
L'objet d'un défaut est de communiquer les détails d'un problème pour permettre une action corrective, sa résolution et son suivi. Les demandes de changement sont utilisées par les personnes suivantes :
Projet :
Numéro de la demande de changement :
Type de demande de changement : (Problème ou amélioration)
Titre :
Date de soumission :
Initiateur :
Priorité de la demande de changement :
Description du problème actuel :
Défaillance critique :
Nuisance :
Amélioration :
Nouvelle exigence :
Conditions sous lesquelles le problème a été observé :
Environnement actuel : matériel
Système d'exploitation
Compilateur
Source du problème actuel :
Impact du problème actuel en termes de coût/économies :
Description du changement proposé :
Estimation du coût d'implémentation du changement proposé :
Action :
Approuvée :
Rejetée :
Différée :
Description du changement proposé :
Eléments de configuration affectés :
Catégorie :
Correction d'erreur :
Amélioration :
Nouvelle fonctionnalité :
Autre :
Estimation du coût d'implémentation du changement proposé :
Implémenteur :
Délai d'implémentation du changement :
Analyse :
Implémentation:
Test :
Documentation :
Nombre de lignes de code affectées :
Méthodes de test :
Inspection
Analyse
Démonstration
Test :
Plates-formes de test :
Scénarios de test :
Changements approuvés et acceptés :
Les attributs suivants peuvent aider à fonder une décision concernant une soumission de demande de changement :
Ampleur du changement
- Quel volume de travail existant devra être modifié ?
- Quel volume de travail devra être ajouté ?
Alternatives
- Existe-t-il d'autres alternatives ?
Complexité
- Le changement proposé est-il facile à mettre en oeuvre ?
- Quelles sont les ramifications possibles de ce changement ?
Gravité
- Quel est l'impact du rejet de cette demande ?
- Des travaux ou des données seront-ils perdus ?
- S'agit-il d'une demande d'amélioration ?
- S'agit-il d'un inconvénient mineur ?
Calendrier
- Pour quand le changement est-il requis ?
- Est-ce réalisable ?
Impact
- Quelles seront les conséquences de l'implémentation du changement ?
- Quelles seront les conséquences de la non implémentation du changement ?
Coût
- Quel sont les coûts ou économies découlant de l'application de ce changement ?
Relation avec d'autres changements
- Ce changement dépend-il ou sera-t-il supplanté ou invalidé par d'autres ?
Test
- Des tests particuliers doivent-ils être exécutés pour vérifier le succès du changement ?
Les pratiques de gestion des changements sont souvent institutionnalisées ou définies de bonne heure dans le cycle de vie du projet. Les demandes de changement, en tant que partie intégrante du processus de changement, peuvent être soulevées à n'importe quel moment du cycle du projet.
La source principale de détection de défauts provient des résultats des tests d'intégration, des tests système et des tests de performance. Cependant, ils peuvent émerger à n'importe quel point du cycle de développement du logiciel et comprennent aussi l'identification de cas d'utilisation, de scénarios de test et de documentation incomplets ou omis.
Tous les membres de l'équipe de projet doivent pouvoir présenter une Demande de changement. Cependant, ces demandes doivent être examinées et approuvées afin de déterminer les travaux de résolution requis en accord avec le contexte du projet logiciel. Lorsque les rapports sont formels ou l'équipe nombreuse, l'approbation est généralement délivrée par le supérieur hiérarchique de la personne présentant la demande de changement. Dans de nombreux cas, l'arbitrage final est du ressort d'un panel de révision des demandes, tel qu'un comité de contrôle des changements (CCB).
Le rôle Responsable du contrôle des changements est responsable de l'intégrité de la Demande de changement et doit s'assurer que :
Alors que le rôle Responsable du contrôle des changements est généralement responsable de la gestion de ces demandes, dans le cas de demandes d'amélioration, le rôle Responsable du contrôle des changements collabore habituellement avec les rôles Analyste système et Architecte afin d'évaluer le changement.
Les champs et données nécessaires pour identifier de manière précise les défauts, les décrire et les suivre, varient et dépendent des normes, principes et système de contrôle mis en oeuvre.
Il est généralement plus efficace de stocker ces demandes dans une base de données ou dans un système de gestion des demandes de changement afin de faciliter leur gestion (par exemple, tri par ordre de priorité, suivi de leur affectation et état d'achèvement, etc). S'il s'agit d'un petit projet, l'utilisation d'un tableur peut être suffisante.
Dans ce genre de projet, une simple liste suffit à gérer les défauts (sous votre tableur de prédilection, par exemple) avec une colonne distincte pour chaque attribut requis pour le suivi de la demande de changement. Cette méthodologie n'est envisageable que pour les petits systèmes : la multiplication des parties prenantes et des défauts entraînera nécessairement l'utilisation d'un système de suivi des défauts plus souple.
RUP (Rational Unified Process)
|