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

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

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)

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

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

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

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 !!!

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

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…

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 …

Et les pratiques génériques pour le CM GP2.1 Établir une directive organisationnelle Une note d’organisation précisant que la gestion de configuration est obligatoire sur les projets et doit rester sous le contrôle du manager de projet GP2.2 Planifier le processus Les charges des activités de CM doivent être connues, identifiables et révisables. Elles doivent aussi être affectées et planifiées dans le temps GP2.3 Fournir les ressources Il s’agit d’identifier les ressources (humaines et logicielles) et d’assigner les responsabilités (via des entretiens de missions individuels avec des objectifs spécifiques liés à la gestion de configuration). La formation implique aussi que le turn-over soit pris en compte et que les procédures d’accueil intègrent la formation à la CM GP2.4 Assigner les responsabilités GP2.5 Former les personnes GP2.6 Gérer en configuration La gestion de configuration elle-même doit être traitée par les processus de gestion de configuration (plan de gestion de configuration, plan de gestion documentaire, outils divers…). GP2.7 Identifier et impliquer les parties prenantes concernées il s’agit de veiller à ce qu’en interne et en externe, chacun ait connaissance des activités et des processus liés à la gestion de configuration GP2.8 Suivre et contrôler le processus Le manager de projet doit avoir connaissance des activités de GC et les prévoir, il doit contrôler l’activité de GC GP2.9 Évaluer la conformité de manière objective Les processus, plans, pratiques doivent être approuvés au niveau des audits qualités (et pas seulement en interne) et ils doivent remonter vers les instances de management supérieures (DP, IA, Comités de surveillance) GP2.10 Passer le statut en revue avec les responsables de niveau supérieur

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

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 !

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