Concept: Gestion de la configuration et des demandes de changement
Ce concept présente la portée et le fonctionnement de la Gestion de la configuration et des demandes de changement.
Relations
Description principale

Les principaux aspects d'un système de gestion de configuration (CM) sont généralement les suivants :

  • Gestion des demandes de changement
  • Gestion de la configuration (CM)
  • Suivi des changements
  • Sélection de la version

Les systèmes CM peuvent aussi comprendre :

  • Fabrication du logiciel
  • Comptabilisation et mesure de l'état de la configuration

Le cube CM suivant, présentant les interdépendances réciproques, sert à représenter les principaux aspects d'un système CM.

Concepts : Gestion des demandes de changement Concepts : Gestion des demandes de changement Concepts : Gestion des demandes de changement Diagramme du cube CM présentant les relations entre la gestion des demandes de changement, les mesures et la gestion de la configuration



  1. Gestion des demandes de changement(CRM) - détermine l'infrastructure organisationnelle nécessaire pour évaluer le coût, le planning et l'impact du changement demandé sur le produit existant. La gestion des demandes de changement traite des travaux d'une équipe de revue des changements ou d'un comité de contrôle des changements.
  2. Comptabilisation (mesure) de l'état de la configuration - sert à décrire l'"état" du produit au cours de son développement, basé sur le type, le nombre, le taux et la gravité des incidents détectés et corrigés. La métrologie dérivée de cet aspect, à travers d'audits ou de données brutes, est utile pour déterminer l'état d'achèvement global du projet.
  3. Gestion de la configuration (CM) - décrit la structure du produit et identifie les éléments constitutifs de sa configuration qui sont traités comme des entités versionnables uniques dans le processus de gestion de la configuration. La CM comprend la définition des configurations, de la construction et de l'étiquetage, la collecte des produits versionnés en ensembles constitutifs et la maintenance de la traçabilité entre ces versions.
  4. Suivi des changements - décrit les actions effectuées sur les éléments, pour quelle raison et à quel moment. Il permet de suivre l'historique et les motifs des changements. Il est bien distinct de l'évaluation de l'impact des changements proposés, tel que décrit sous 'Gestion des demandes de changement'.
  5. Sélection de la version - le but d'une bonne 'sélection de la version' est de s'assurer que les versions correctes des éléments de la configuration sont sélectionnées pour les changements ou l'implémentation. La sélection de version repose sur une solide 'identification de la configuration'.
  6. Fabrication du logiciel - couvre les besoins d'automatisation des étapes de compilation, de test et de packaging du logiciel pour la distribution.

Le processus Rational Unified Process décrit un système CM exhaustif couvrant tous les aspects de la CM. Son objet est de permettre un processus CM efficace qui :

  • est intégré au processus de développement du logiciel.
  • aide à gérer l'évolution des produits de développement du logiciel.
  • permet aux développeurs d'effectuer les tâches relatives à la CM sans trop intervenir dans le processus de développement.

Un des objectifs du processus CM de Rational est d'encourager le contrôle de la version des produits enregistrés dans les outils de développement et de réduire la production inefficace de documentation papier.

Un autre objectif du processus CM de Rational est de s'assurer que le niveau de contrôle appliqué à chaque produit est basé sur le niveau de maturité de ce dernier. Au fur et à mesure de la maturation des produits, les demandes de changement sont validées par l'implémenteur, puis par l'intégrateur de sous-systèmes ou de système, puis par le gestionnaire de projet et finalement par le client.

Pour l'efficacité du processus, il est important de s'assurer que le poids bureaucratique associé au processus de la gestion des demandes de changement soit cohérent avec le niveau de maturité du produit.

Par exemple, durant les premières itérations, le processus de gestion des demandes de changement (CRM) peut être relativement informel. Durant les phases ultérieures du cycle de vie de développement, le processus CRM peut être plus strict pour s'assurer que les ressources nécessaires au test et à la documentation puissent traiter les changements et évaluer l'instabilité potentielle qu'un changement peut introduire. Un projet incapable d'adapter le niveau de contrôle durant le processus de développement ne sera pas efficace.