Gestion de projet Gestion de configuration Laurent Berenguier

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

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

Les objectifs spécifiques n SG 1 Établir des référentiels n n n Établir des référentiels des données de sortie SP 1. 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 SP 1. 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 SP 1. 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 SG 2 Suivre et contrôler des changements n n n Les changements aux produits de sortie gérés en configuration sont suivis et contrôlés SP 2. 1 Suivre les demandes de changement : Suivre les demandes de changement aux articles de configuration (tenir un journal) SP 2. 2 Contrôler les changements : Contrôler les changements aux articles de configuration (valider les demandes de changements via le circuit) 3

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

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

Dysfonctionnements n Quelques sources classiques : n n n n É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 : n n n n 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 6

Dysfonctionnements n Ce que l’on vient de voir : n n 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 !!! 7

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

Nature des éléments n Documentaire / produit ou process : n n n n Fichiers logiciels (produits): n n n n Spécifications, recueil d’exigences… Dossier d’architecture, de conception, d’interfaces… Diagrammes Plans projets Normes et procédures (tests, développement) Publications 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 : n OS, compilateur (ou env. de développement), serveur d’application, SGBD… 9

Retour au CMMI n SG 1 : Établir les référentiels n SP 1. 1 : Identifier les éléments gérés en configuration m m m n SP 1. 2 : Établir un système de gestion de configuration m m n 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) Activité manuelle (référence de nomenclature ou de gestion documentaire) ou automatisé (CVS, Clear. Case, …) 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) SP 1. 3 : Créer ou figer des référentiels m m 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 … 10

Et les pratiques génériques pour le CM GP 2. 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 GP 2. 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 GP 2. 3 Fournir les ressources GP 2. 4 Assigner les responsabilités GP 2. 5 Former les personnes 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 GP 2. 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…). GP 2. 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 GP 2. 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 GP 2. 9 Évaluer la conformité de manière objective GP 2. 10 Passer le statut en revue avec les responsables de niveau supérieur 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) 11

Quizz Vrai ou Faux ? n Mon application est simple, son référentiel n’est constitué que de l’exécutable Faux : la documentation, les paramétrages éventuels et la plateforme logicielle sont intégrés au référentiel n 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 : il faut lier les versions documentaires aux versions logicielles 12

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

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