Gestion de projet Gestion de configuration

1. Gestion de projetGestion de configuration Laurent Berenguier – laurent.berenguier@gmail.com Patrick Reynoudt – patrick.reynoudt@gmail.com

2. Gestion de configuration • Un des Process Areas du CMMI niveau 2 • CM pour Configuration Management • Rappel : finalité du domaine de processus • Établir et maintenir l’intégrité des produits de sortie en utilisant • une identification de configuration, • un contrôle de configuration, • un registre des statuts de configuration • des audits de configuration

3. Les objectifs spécifiques • SG1 Établir des référentiels • Établir des référentiels des données de sortie • SP1.1 Identifier les articles de configuration : Identifier les articles de configuration, les composants et les produits associés qui seront gérés en configuration • SP1.2 Établir un système de gestion de configuration : Établir et maintenir un système de gestion de configuration et de gestion des changements pour contrôler les produits de sortie • SP1.3 Créer ou mettre à jour des référentiels : Créer ou mettre à jour des référentiels pour usage interne et pour livraison client • SG2 Suivre et contrôler des changements • Les changements aux produits de sortie gérés en configuration sont suivis et contrôlés • SP2.1 Suivre les demandes de changement : Suivre les demandes de changement aux articles de configuration (tenir un journal) • SP2.2 Contrôler les changements : Contrôler les changements aux articles de configuration (valider les demandes de changements via le circuit)

4. Les objectifs spécifiques • SG3 Établir l’intégrité • L’intégrité des référentiels est établie et maintenue • SP3.1 Établir des enregistrements de gestion de configuration : Établir et maintenir les enregistrements décrivant les articles de configuration • SP3.2 Mener des audits de configuration : Mener des audits de configuration pour maintenir l’intégrité des référentiels de configuration

5. Dysfonctionnements ? Quelques minutes de réflexion collective • Quelques sources classiques ? • Quelques cas de dysfonctionnement, impacts possibles ?

6. Dysfonctionnements • Quelques sources classiques : • Éléments gérés en configuration insuffisants (on n’a pas tout traité…) • Critères d’entrées / sorties en CM mal définis • Gestion de configuration limitée à ce que permet l’outil • Confiance aveugle en l’outil, mais outil pas maîtrisé, pas fiable, ou trop coûteux • Opération de merge hasardeuse • Nommage (identification des éléments projets) non homogène, non intègre • L’incident bête = l’écrasement de fichier (la GC ne l’empêche pas, elle en diminue l’impact) • Quelques cas de dysfonctionnement : • Mauvaise installation de version • Discuter de versions différentes • Coût d’upgrade des référentiels non maîtrisés • Impossibilité de retour arrière • Effets désastreux, coût décuplés : • On a laissé passer une opération hasardeuse dans la gestion de configuration • Perte de sources • Mélange de versions

7. Dysfonctionnements • Ce que l’on vient de voir : • Les dysfonctionnements de GC avérés ne provoquent des impacts qu’à retardement, de telle sorte que le coût soit bien plus important • De bonnes pratiques de gestion de configuration n’éradiquent pas l’erreur humaine qui reste toujours possible, cependant elle vise à en diminuer le coût d’impact • Par rapport au client, un dysfonctionnement de gestion de configuration = un dysfonctionnement dans nos processus métier ! • Comment faire pour éviter les dysfonctionnements ? …  Définir ce que l’on manipule en GC et les pratiques de GC !!!

8. Nature des éléments ? Quelques minutes de réflexion collective • Quelques natures des éléments gérés en configuration ?

9. Nature des éléments • Documentaire / produit ou process : • Spécifications, recueil d’exigences… • Dossier d’architecture, de conception, d’interfaces… • Diagrammes • Plans projets • Normes et procédures (tests, développement) • Publications • Fichiers logiciels (produits): • Codes sources • Procédures, scripts, • Scripts des base de données • Données de tests • Autres logiciels utilisés, bibliothèques de codes, tout composant de framework • Fichier de paramétrages (IHM, fonctions...) • Fichiers d’installation, de configuration (setup) • Environnements logiciels : • OS, compilateur (ou env. de développement), serveur d’application, SGBD…

10. Retour au CMMI • SG1 : Établir les référentiels • SP1.1 : Identifier les éléments gérés en configuration • Un document pivot : le plan de gestion de configuration (PGC) • Définition des éléments et des responsabilités par nature • Mission clairement définie de Responsable de Gestion de configuration (RGC) • SP1.2 : Établir un système de gestion de configuration • Activité manuelle (référence de nomenclature ou de gestion documentaire) ou automatisé (CVS, ClearCase, …) • Les opérations de base sont : réservation, libération, commentaire de version, retour sur l’historique, comparaisons et merge, identification d’un détenteur, validation de version (étiquetage) • SP1.3 : Créer ou figer des référentiels • Un référentiel est la vue interne et externe de la gestion de configuration • Pour une version applicative donnée, il regroupe l’ensemble des éléments composant, paramétrage, documentaire …

11. Et les pratiques génériques pour le CM

12. Quizz Vrai ou Faux ? • Mon application est simple, son référentiel n’est constitué que de l’exécutable • Ma gestion de configuration documentaire est conforme : elle est réalisée dans un système de gestion documentaire qui me garantit l’intégrité, la gestion des états et des historiques Faux : la documentation, les paramétrages éventuels et la plateforme logicielle sont intégrés au référentiel Faux : il faut lier les versions documentaires aux versions logicielles

13. Quizz Bien ou Pas bien ? • Cette nature d’élément n’est pas listée dans mon PGC, car techniquement il m’est impossible de lui appliquer une version : • Sur mon projet toute la documentation est versionnée et est liée aux versions logicielles • Ma release note n’est pas gérée en version Pas Bien : tout élément doit être identifié selon des règles de nommages définies au PGC Bien mais insuffisant : a priori, cela implique que la documentation projet n’est pas gérée en configuration Bien : la RN est gérée en configuration de fait puisqu’elle permet de tracer les historiques de versions !

14. En synthèse • En synthèse, la gestion de configuration avec CMMi : • Apporte du formalisme là où on en manque souvent fortement • Propose des extensions et une couverture plus large des risques liés à la GC • Doit être appliquée de manière obligatoire sur nos projets