Produit: Demande de changement
Ces artefacts sont utilisés pour documenter et effectuer un suivi des demandes de changement sur le 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é.
Objet
  • Formulation et suivi des changements et incidents
Description
Bref aperçu

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
  • Compilateur de système d'exploitation :
  • Source du problème actuel :
  • Impact du problème actuel en termes de coût/économies :
  1. Changement proposé (émetteur)

  • Description du changement proposé :
  • Estimation du coût d'implémentation du changement proposé :
  1. Changement proposé (équipe 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
  • Plateformes de test
  • Cas de test
  1. Décision de l'équipe de revue des changements

  • Changements approuvés et acceptés
Description principale

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. Les demandes de changement permettent d'archiver les décisions et garantissent, pour autant qu'un processus d'évaluation adéquat soit en vigueur, une analyse de leur impact.

Les demandes de changement sont aussi connues sous d'autres noms ; par exemple, bogues, incidents, demandes d'amélioration. Le recensement et la gestion appropriés de ces demandes permet d'appliquer les changements de manière contrôlée et ainsi de prévoir leurs conséquences sur le système. Exemples de types d'importation de demande de changement :

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 :

  • L'Ensemble de rôles : Analystes utilise les demandes de changement pour définir les changements significatifs apportés aux exigences de haut niveau, ainsi que pour déterminer les exigences, en particulier à partir des demandes de changement identifiées comme demandes d'amélioration.
  • L'Ensemble de rôles : Responsables utilise les demandes de changement pour gérer et contrôler l'affectation du travail.
  • L'Ensemble de rôles : Testeurs utilise les demandes de changement pour décrire des défaillances (incidents), des omissions et des problèmes de qualité détectés lors des tests du logiciel.
  • L'Ensemble de rôles : Développeurs utilise les demandes de changement relatives aux incidents pour analyser les défaillances et repérer les erreurs ou causes sous-jacentes afin de répondre à une demande de changement.
  • Le Rôle : Analyste de test utilise les demandes de changement pour planifier les tests qui vérifieront les demandes de changement traitées et pour évaluer l'effort de test en analysant les ensembles d'incidents afin de mesurer les tendances en termes de qualité du logiciel et du processus d'ingénierie logicielle.
Propriétés
Facultatif
PlanifiéYes
Personnalisation
Options de représentation

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 de leur état d'achèvement). S'il s'agit d'un petit projet, l'utilisation d'un tableur peut être suffisante.

Dans le cas des petits projets, vous pouvez gérer les incidents à l'aide d'une simple liste. Vous pouvez également utiliser une feuille de calcul comportant une colonne distincte pour chaque attribut de la demande de changement. Ce fonctionnement n'est envisageable que dans le cas de systèmes de taille limitée. La multiplication des parties prenantes et des incidents entraînera nécessairement l'utilisation d'un système de suivi des incidents plus souple.



Plus d'informations