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 :   

Objet Haut de la page

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 :

  • Les analystes utilisent les demandes de changement afin de définir les altérations importantes aux exigences globales, spécialement dans le cas de demandes d'améliorations.
  • Les Responsables utilisent les demandes de changement pour gérer et contrôler l'affectation des tâches .
  • Les Testeurs utilisent les demandes de changement pour décrire des échecs (défauts), omissions et problèmes de qualité détectés lors des tests du logiciel.
  • Les implémenteurs utilisent les demandes de changement découlant de défauts pour analyser les échecs et déterminer les défauts sous-jacents ou les causes de l'échec pour les corriger.
  • L'../workers/wk_tstanl.htm -- This hyperlink in not present in this generated websiteAnalyste de test utilise les demandes de changement pour planifier les tests requis afin de vérifier la résolution des problèmes et pour évaluer l'effort à investir dans des tests, en analysant les données de défauts signalés pour y détecter des tendances en termes de la qualité et du processus d'ingénierie du logiciel.

Bref aperçu Haut de la page

Exemple de formulaire de demande de changement

  1. Identification

  • 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 :
  1. Problème actuel

  • 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 :
  1. Changement proposé (Emetteur)

  • Description du changement proposé :
  • Estimation du coût d'implémentation du changement proposé :
  1. Changement proposé (Equipe de revue des changements)

  • 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 :
  1. Résolution

  • 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 :
  1. Evaluation

  • Méthodes de test :
  • Inspection
  • Analyse
  • Démonstration
  • Test :
  • Plates-formes de test :
  • Scénarios de test :
  1. Verdict de l'équipe de revue des changements

  • Changements approuvés et acceptés :

Propriétés Haut de la page

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 ?

Calendrier Haut de la page

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.

Responsabilité Haut de la page

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 :

  • Toutes les informations visant à identifier et à décrire le changement, y compris les hypothèses et le contexte ayant conduit à la découverte de ce besoin, ont été fournies avec le niveau de détail et de précision adéquats.
  • La demande est unique en ce qu'elle ne constitue pas une nouvelle occurrence d'un changement identifié auparavant.

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.

Personnalisation Haut de la page

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