Cours Gestion de projet

Transcription

1 Cours Gestion de projet Gestion de configuration Version Date Auteur V1.3 Septembre 2007 Pascal HEYER 1

2 La Gestion de configuration Ce document est publié sous la licence libre Creative Commons-BY-NC-SA BY : Paternité. Vous devez citer le nom de l'auteur original. NC : Pas d'utilisation Commerciale. Vous n'avez pas le droit d'utiliser cette création à des fins lucratives et commerciales. SA : Partage des Conditions Initiales à l'identique. Si vous modifiez, transformez ou adaptez cette création, vous n'avez le droit de distribuer la création qui en résulte que sous un contrat identique à celui-ci. En outre, à chaque réutilisation ou distribution, vous devez faire apparaître clairement aux autres les conditions contractuelles de mise à disposition de cette création. Chacune de ces conditions peut être levée si vous obtenez l'autorisation du titulaire des droits. 2

3 La Gestion de Configuration Logiciel (GCL) Plan Qu est ce que la GCL? Pourquoi la GCL? Les risques sans la GCL Terminologie de la GCL Objectifs de la GCL Démarche de mise en œuvre Les outils de la GCL Le marché de la GCL Les bénéfices de la GCL 3

4 Qu est-ce que la GCL? (FC) La gestion des configurations Logiciel (GCL) est un processus (organisation, compétences, procédures, méthodes et outils) qui vise à gérer : Les différentes versions des composantes d un système d information (programmes, documentation, matériels ) Le cycle de vie de ces composantes L assemblage de ces composantes dans le but de générer des configurations multiples Les changements appliqués à ces composantes (gestion des évolutions et des anomalies) 4

5 Pourquoi la GCL? La gestion de configurations est indispensable à la maîtrise de tout développement : Savoir retrouver à tout moment une version de dossier fonctionnel et son état dans le cycle d approbation. Gérer les versions des programmes sources et des exécutables générés Mettre en place des systèmes de verrous (checkin/checkout) pour éviter les collisions entre plusieurs développeurs Pouvoir évaluer les impacts d une demande de changement Pouvoir gérer les développements sur plusieurs sites (TMA, Offshore). Pouvoir gérer des projets parallèles qui portent sur des composants communs (fusion) Pouvoir retrouver instantanément les demandes de changement qui ont été réalisées dans un programme ainsi que les anomalies corrigées depuis la dernière version en production. 5

6 Pourquoi la GCL? La gestion de configuration est indispensable à la réalisation d un déploiement en environnement complexe : différentes versions de systèmes d exploitation différents modules applicatifs à installer pour gérer des périphériques hétérogènes entre les différents sites cohabitation de logiciels différents en fonction du profil du poste de l utilisateur versions des drivers incompatibles avec le système déployé 6

7 Exemple : Cas des progiciels Les éditeurs cherchent à faire fonctionner le même progiciel (i.e. le même code source) sur une variété de plates-formes aussi grande que possible : Gérer les dépendances hardware. Gérer les dépendances du système d'exploitation. Gérer les évolutions de l ensemble 7

8 3 cas classiques (1/3) PROBLÈME DU PARTAGE DES COMPOSANTS LES ERREURS DE P#1 PEUVENT BLOQUER P#2 ; LE RETARD ET LES ERREURS DE P#1 PEUVENT BLOQUER P#2 ; LE RETARD EST INÉLUCTABLE 8

9 3 cas classiques (2/3) PROBLÈME DE LA DOUBLE MAINTENANCE IL FAUT MINIMISER LES DUPLICATIONS CAR INÉVITABLEMENT LES COPIES MULTIPLES DIVERGENT ; L'AUGMENTATION DES COÛTS EST INÉLUCTABLE 9

10 3 cas classiques (3/3) PROBLÈME DES MISES A JOUR SIMULTANÉES POUR DONNER DU CONFORT A P#1 ET A P#2, ET ÉVITER LE PB#1, C A ÉTÉ DUPLIQUÉ, CE QUI NOUS RAMÈNE AU PB#1 GÉRER LE DILEMME!? 10

11 Sans GCL : Les risques Perdre des versions d éléments logiciels ou documentaires (conflits entre plusieurs concepteurs, retour arrière) Perdre le contrôle du contenu des composants (changement, anomalie) et de leur statut (en cours, validé, KO) Le projet ne peut pas restaurer un état stable antérieur de son livrable. Le besoin peut pourtant s en faire sentir : La dernière mise en production n est pas satisfaisante L utilisateur souhaite faire marche arrière pour des raisons organisationnelles Le projet veut comprendre l évolution d un composant, comparer des versions successives (par exemple pour corriger le composant ou faire une analyse d impact) Qualité, coûts, délais 11

12 Terminologie de la GCL FC Un produit de travail correspond à tout objet créé par le projet (documentation, composant logiciel, paramètres, etc.) Un élément géré en configuration est un document, un composant logiciel (ex. programme), un jeu de données ou tout autre élément dont il faut suivre et conserver les versions. Une version d un élément reflète un changement subi par l élément. Une configuration est un assemblage de versions d éléments. Une version du projet désigne ce que le projet développe et doit livrer. C est un assemblage cohérent de versions d éléments. Cela recouvre un ensemble de documents et de composants logiciels éventuellement transverses à plusieurs applications logicielles. La gestion de configuration est donc la gestion des versions du projet. Un changement et une anomalie, sont respectivement une évolution des exigences et un besoin de correction d une version projet. Ces événements impactent la gestion de configuration puisqu ils impliquent la création de versions nouvelles. Une référence est une version du Livrable qui est livrable à l utilisateur. 12

13 Les 5 niveaux de maturité de CMMi permettent une amélioration continue par étapes (rappel) Niveau Libellé Secteur 5 Processus en amélioration continue 4 Processus Géré quantitativement 3 Processus Défini (standardisé) Gestion et déploiement des innovations au niveau organisation (OID) Prevention de défault (analyses Causales) (CAR) Performance du processus de l'organization (OPP) Gestion de projet Quantitative (QPM) Développement des exigences (RD) Conception de la solution technique (TS) Intégration des Produits (PI) Verification (VER) Validation (VAL) Focalisation processus de l'organisation (OPF) Definition du processus de l'organisation (OPD) Plan de formation de l' organisation (OT) Gestion intégrée de Projet (IPM) Gestion des Risques (RSKM) Equipes Integrée (IT) Gestion intégrée des fournisseurs (ISM) Prise de décision et Resolution (DAR) Environnement organisationnel pour l' Integration (OEI) Qualité Productivité 2 Processus Géré : Gestion de projet efficace 1 Gestion des exigences (REQM) Planification de projet (PP) Suivi et supervisionde projet (PMC) Gestion contractuelle de fournisseur (SAM) Mesures et Analyses (M&A) Assurance de la Qualité du processus et des Produits (PPQA) Gestion de Configuration (CM) Risque Retravaillage 13

14 Les objectifs de la GCL selon le CMMi N2 Etablir et assurer l intégrité des produits issus du projet tout au long du cycle de vie du logiciel : 1. les activités de gestion de configuration sont planifiées 2. les produits du travail logiciel sélectionnés sont identifiés, contrôlés et disponibles. 3. les changements apportés aux produits logiciels de travail logiciel identifiés sont contrôlés 4. les groupes et les personnes concernés sont informés de l'état et du contenu des référentiels logiciel. 14

15 Objectifs 1 : les principes (CMMi N2) Les activités de gestion de configuration sont organisées et planifiées 1. un plan de Gestion de Configuration Logiciel (GCL) est préparé pour chaque projet logiciel conformément à une procédure documentée 2. un plan GCL documenté et approuvé est utilisé comme base pour réaliser les activités GCL 15

16 Objectifs 2 : les principes (CMMi N2) Les produits du travail logiciel sont identifiés, contrôlés et disponibles. 3. les produits de travail à placer sous gestion de configuration sont identifiés (interne et livrables, documentaires, logiciels, outils de soutien) 4. un système de bibliothèque de gestion de configurations est établi comme dépôt pour stocker les référentiels logiciel 5. les produits sont créés à partir de la bibliothèque de référentiels logiciel et leur lancement est contrôlé conformément à une procédure documentée 16

17 Objectifs 3 : les principes (CMMi N2) Les changements apportés aux produits logiciels identifiés sont contrôlés : 6. les demandes de changement ainsi que les rapports de problème pour les articles/unités de configuration sont déclenchés, enregistrés, passés en revues, approuvés et soumis à un suivi conformément à une procédure documentée 7. les changements apportés aux référentiels sont contrôlés conformément à une procédure documentée 17

18 Objectifs 4 : les principes (CMMi N2) Les groupes et les personnes concernés sont informés de l état et du contenu des référentiels logiciels : 8. l état des articles/unités de configuration est enregistré conformément à une procédure documentée 9. des rapports standards documentant les activités CGL ainsi que le contenu du référentiel logiciel sont élaborés et rendus disponibles aux personnes et aux groupes concernés. 10. les audits des référentiels logiciel sont effectués conformément à une procédure documentée 18

19 Les acteurs de la gestion de configuration Le Responsable de la Gestion de configuration Conçoit, organise et met en œuvre la gestion de configuration Contrôle les configurations Le Chef de projet Responsable de la fabrication des versions Prise en compte des anomalies et des changements L équipe projet Modification et création des composants 19

20 Institutionnalisation de GCL (CMMi N2) Engagement de réalisation : une directive écrite de l organisation existe et et suivie Capacité de réalisation : un comité autorisé à gérer les référentiels du projet existe ou est créé. un groupe responsable de la coordination et de la mise en œuvre CGL pour le projet (groupe CGL) existe. des ressources et un financement suffisants sont fournis pour les activités CGL. le groupe CGL a reçu une formation adéquate. le groupe de développement est formé pour réaliser ses activités CGL. Mesures : des mesures sont effectuées et utilisées pour déterminer le statut de ces activités (coût et planning) Vérification : ces activités sont revues de façon périodique par la direction, le chef de projet et le groupe AQL (revues et audits ). 20

21 Démarche de mise en œuvre de la GCL En 2 phases : Développement de la GCL préparation, élaboration, construction, transition Conduire les activités de GCL pour toutes les activités de développement et de maintenance 21

22 Phase 1 : Développement de la GCL Préparation Elaboration Construction Transition 22

23 Phase 1 : Développement de la GCL Le Responsable GCL réalise : 1. Spécification des besoins Définition de la configuration Définition des exigences, niveaux de services en termes de GCL 23

24 Définition de la configuration Ensemble cohérent de composants permettant, à un instant donné, d éditer une version fonctionnelle complète du système. C'est la garantie de l'intégrité du système. La granularité de la configuration est un paramètre économique. Valeur du produit (et de ses constituants), nature du risque, etc. Les éléments «à risque» doivent être répertoriés C'est une forme de contrat d'assurance dont le montant est fonction des risques afférents à un projet bien déterminé. LES DIFFICULTÉS DE LA DEFINITION Nombre d'objets à gérerdépend de la granularité et du type de nomenclature Variété des objets et des supports d'archivage et de stockage (SGBDR) Caractéristiques du logiciel Dépendances fonctionnelles, canaux cachés, etc. Durée de vie des équipements, des outils,... Organisation du développement (+ ou - normalisé) Les acquisitions en logiciel et matériel : ce sont des boîtes noires dont il est souvent difficile de cerner les contours 24

25 Définition des exigences Qualité de la GCL Cohérence Complétude Auditabilité Des différentes versions (référentiels) Disponibilité Sécurité (protection) Traçabilité Des différents éléments de configuration composants les versions PENDANT TOUT LE CYCLE DE VIE Développement Maintenance 25

26 Définition des exigences Qualité de la GCL Les composants doivent être : Disponibles Protégés La traçabilité des modifications assurée PENDANT TOUT LE CYCLE DE VIE Développement Maintenance 26

27 Phase 1 : Développement de la GCL Le Responsable GCL réalise : 2. Définition du processus de Gestion des configurations Logiciel à partir des besoins 27

28 Processus de gestion de configuration Les différents environnements Outils de GCL Environnements physiques Etape Production Environ. De production (utilisateurs) Recette Environ. De Recette (client) Développement Environ. de développement (IT) 28

29 Processus de gestion de configuration Gestion des différents flux intégrant la gestion des changements Changement ou Anomalie 8 Production 6 1 Liste des versions Recette 5 Liste des composants 4 7 Demande de changement Anomalie 2 Développement Privé 3 Anomalie Demande de changement Backup 29

30 Processus de gestion de configuration Gestion du changement Les changements apportés aux composants sont contrôlés : les demandes de changement ainsi que les anomalies sont enregistrés, passés en revues, approuvés et soumis à un suivi les changements apportés aux référentiels sont contrôlés 30

31 Processus de gestion de configuration Gestion du Versionning 31

32 Phase 1 : Développement de la GCL Le Responsable GCL réalise : 3. Choix des outils de gestion de configuration logicielle et du média de livraison pour l application adressée (CVS, ClearCase, ligne spécialisée) 4. Développement des outils de livraisons des projets sur les environnements du Client 5. Développement d outils de contrôle et de suivi de la configuration (par exemple, outil de gestion de faits techniques : CQ+CC) 6. Mise en œuvre du système de gestion de configuration couvrant l ensemble du cycle de vie d un projet de l application adressée et construit sur des environnements indépendants :» environnement de référence» environnements de développement et d intégration multi-projet» environnements de maintenance» environnement de livraison Client 32

33 Phase 1 : Développement de la GCL (4/4) 7. Le cas échéant, la construction de la référence (reprise existant) 8. Mise en place du média de livraison principal et du média de secours 9. Mise en place de la stratégie de sauvegarde/restauration + tests 10.Finalisation du Plan de Gestion de Configuration logicielle intégrant les responsabilités, les moyens alloués, les procédures, les actions de surveillance et d audit. 11.Formation et information des équipes aux activités et responsabilités qui sont les leurs en matière de gestion de configuration. 33

34 Phase 1 : Les concepts de base Besoins Exigences qualité PGCL Identification Outils 34

35 BESOINS : Les 3 axes de la GCL Processus GCL Organisation Identification Contrôle Administration Audit Nature du produit Hardware Firmware Software Documentation Processus de développement et de maintenance Cycle de vie système et logiciel Acquisition progressive par paliers fonctionnels : N versions successives avec compatibilité ascendante des versions 35

36 Les exigences Qualité de la GCL Cohérence Complétude Auditabilité Des différentes versions (référentiels) Disponibilité Sécurité (protection) Traçabilité Des différents éléments de configuration composants les versions PENDANT TOUT LE CYCLE DE VIE Développement Maintenance 36

37 Le Plan de Gestion de Configuration Logiciel Précise les dispositions prises pour assurer la Gestion de Configuration en développement et en maintenance. Il peut s appuyer sur des standards ISO ou sur des procédures «société»). Le PGCL traite des points suivants : Organisation de la Gestion de Configuration : Définition des référentiels Définition des responsabilités Maîtrise des configurations : Transfert entre les environnements (dev, test) Contrôle des configurations : Mise sous contrôle Gestion des modifications Administration : État de référence Archivage Sauvegarde/restauration 37

38 L Organisation GCL Pour chaque projet nécessitant une GCL, il faut : Un Responsable GCL chargé de la mise en oeuvre de la GCL lors de la phase d Initialisation et de la conduite des actions GCL ainsi que du reporting selon dispositions décrites dans le PGCL. Pour les projets d évolution, un Comité de contrôles des changements est créé (comité de suivi/pilotage) autorisé à gérer les référentiels logiciels Le Chef de projet est responsable de la supervision des activités décrites dans le PGCL. A cette fin, il dispose d une charge de travail dédiée. Chaque membre du projet est responsable du respect des règles décrites dans le PGCL. Leur charge de travail a été estimée en prenant en compte des contraintes induites par ces règles. Le groupe AQL est chargé de la vérification des activités GCL ainsi que la Direction selon dispositions du PGCL. 38

39 Définition d une configuration Ensemble cohérent de composants permettant, à un instant donné, d éditer une version fonctionnelle complète du système. C'est la garantie de l'intégrité du système. La granularité de la configuration est un paramètre économique. Valeur du produit (et de ses constituants), nature du risque, etc. Les éléments «à risque» doivent être répertoriés C'est une forme de contrat d'assurance dont le montant est fonction des risques afférents à un projet bien déterminé. LES DIFFICULTÉS DE LA DEFINITION Nombre d'objets à gérerdépend de la granularité et du type de nomenclature Variété des objets et des supports d'archivage et de stockage (SGBDR) Caractéristiques du logiciel Dépendances fonctionnelles, canaux cachés, etc. Durée de vie des équipements, des outils,... Organisation du développement (+ ou - normalisé) Les acquisitions en logiciel et matériel : ce sont des boîtes noires dont il est souvent difficile de cerner les contours 39

40 Version et révision 40

41 Identification des éléments/composants Découpage fonctionnel Pb : Identification des fonctions transversales comme la sécurité, la disponibilité, les performances, Découpage selon les outils : Éditeurs (Source, binaires,...) Macrogénérateurs Éditeurs de liens, etc. Les outils imposent d'emblée certains regroupements mais peuvent fausser la logique du découpage fonctionnel Exemples de requêtes : Quels sont les éléments E qui utilisent C? Et les C qui ont servi à fabriquer E? Quel est le procédé de fabrication de C? Quelles sont les modifications M de E faites entre T1 et T2? les auteurs de M? 41

42 Constats : Maîtrise du changement LE CHANGEMENT EST INÉVITABLE Raisons internes générées par le système lui-même Raisons externes générées par l'environnement du système (par ex. les erreurs ou les évolutions) LE CHANGEMENT EST DESTABILISATEUR Délais de livraison Coûts de la réalisation Exactitude, cohérence et complétude du système La maîtrise du changement implique un contrôle strict des changements (anomalies, évolutions) : Évaluation des impacts du changement (estimation taille, efforts, coûts) Pilotage des changements (quels changement, pourquoi, qui les valide, qui les réalise, à partir de quoi et quand) 42

43 Maîtrise du changement Les changements apportés aux produits logiciels de travail logiciel identifiés sont contrôlés : 7. les demandes de changement ainsi que les rapports de problème pour les articles/unités de configuration sont déclenchés, enregistrés, passés en revues, approuvés et soumis à un suivi conformément à une procédure documentée 8. les changements apportés aux référentiels sont contrôlés conformément à une procédure documentée 43

44 Démarche de mise en œuvre de la GCL En 2 phases : Développement de la GCL préparation, élaboration, construction, transition Conduire les activités de GCL pour toutes les activités de développement et de maintenance 44

45 Phase 2 : Conduire les activités Pour chaque projet nécessitant une GCL, le Responsable GCL : Planifie et implémente la GCL pour la prestation selon Plan d Assurance Qualité de l application (création d un PGCL si nécessaire) Administre les environnements (accès, sécurité, sauvegardes, restaurations) Gère les configurations Logiciel selon le PGCL Création projet Vérification/Fabrication/Livraison Suivi version et liste des composants (bordereau de livraison, tableau de bord) Gère la documentation selon PGCL Rend compte périodiquement de ses activités au responsable de la prestation Prépare l auditabilité des activités GCL Mesure les activités GCL Participe aux différentes revues GCL (avec AQL notamment) 45

46 Phase 2 : Les concepts de base Administration Audit 46

47 Administration de la GCL Au minimum, 3 Environnements : Développement Tests Production Accès sécurisés (en fonction rôle) Flux entre les environnements contrôlés Sauvegardes et restaurations 47

48 Les actions : Audit de GCL Vérifier existence version validée du PGCL Analyser description du système GCL Accéder au système GCL du projet/patrimoine Comparer la documentation du système GCL et le système GCL Vérifier la traçabilité des changements (versions listes des exigences, des livrables, des changements, des évolutions, des anomalies, des incidents). Vérifier l accomplissement des actions planifiées et actions correctives Rendre compte (conclusions dans un rapport diffusé au CP) 48

49 Les outils GCL / Fonctionnalités (1/2) Fonctionnalités : Gestion des versions Identification des objets Enregistrement des changements Gestion d éléments multi-systèmes (OS) Gestion des configurations Gestion dynamique des configurations Gestion des référentiels Gestion des espaces et contextes Espaces Contextes (statut) Protection des objets versus contexte et espace Gestion des fabrications Méthode de fabrication Dépendances Gestion des modifications Gestion des fiches de modification (fait technique) Procédure (lien processus GCL) Traçabilité 49

50 Les outils / Fonctionnalités (2/2) Fonctionnalités : Gestion du cycle de vie Procédures spécifiques à un projet, à un site Attributs associés aux objets Liens logiques entre objets Mécanisme de contrôle Verrous et permissions Reporting et audit Historisation et rapports Audit Gestion des livraisons Dossier de livraison Espace livraison Support de livraison Gestion des sauvegardes et archives Sauvegarde/restauration, Archive Sécurité et protection Développement multi-sites Interfaces (API) 50

51 Outils GCL du marché (1/2) Nom Editeur Eléments gérés Plates-formes Fonctionnalités Intégration à des outils tiers AllFusion Harvest Change Manager (CCC/Harvest ) Computer Associates Docs Code et Windows 98/NT/2000/XP AIX SUN HP-UX UNIX Linux MVS (check in/out) contrôle de version par élément et version globale gestion des changements développement parallèle/concurrentiel compilation automatique reporting graphique (java) interfaces de prog. et API interface Web Workflow Interfaces graphiques Intégration à la plupart des outils de développement standards via SCC (websphere, ) Endevor Computer Associates Code MVS contrôle de version par élément et version globale gestion des changements développement parallèle/concurrentiel compilation automatique reporting graphique interfaces de prog. et API interface Web modèles de Workflow Interfaces graphiques Aux environnements de développement Cobol 51

52 Outils GCL du marché (2/2) Nom Editeur Eléments gérés Plates-formes Fonctionnalités Intégration à des outils tiers Merant Dimensions PVCS) (ex Serena Docs et Code Windows 98/NT/2000/XP UNIX Linux HP-UX IBM AIX Solaris MVS gros systèmes contrôle de version par élément et version globale gestion des changements développement parallèle/concurrentiel compilation automatique reporting graphique interfaces de prog. et API interface Web modèles de Workflow Interfaces graphiques Intégration à la plupart des outils de développement standards via SCC et WebDAV CVS Open Source Docs et code Unix Linux Windows 98/NT/2000/XP contrôle de version par élément et version globale développement parallèle/concurrentiel configuration élaborée robuste Connexion aux outils externes (norme SCC) par librairie externe La plupart des outils de développement proposent des interfaces CVS SourceSafe Microsoft Docs et Windows contrôle de version par élément s'intègre facilement à code et version globale l'environnement Microsoft développement parallèle concurr. Reporting, interfaces de prog. et API Interfaces graphiques ClearCase IBM Rational Tout Connecteurs pour Mainframes conversion des référentiels depuis tous les autres outils existants s'interface aux principaux serveurs web contrôle de version par élément et version globale gestion des changements développement parallèle/concurrentiel compilation automatique s'intègre facilement aux autres outils du marché 52

53 Outils >?;) < ( = 5/ "# $%& ( '% ) * " A 3#6!#8'#A# +# B A5 <( $C& ( *.A ( 6!#1!#2 %#% 7 3@( )" )!". / # 0) 1! # (" # ( 4 56!#718' ( $% ) (& 9:; * 2 2 %$G; & ( '$& 2 ) ( ' 2 ))/) ) #( ) 2 $# ) &3 )3 5 %!$(&*. A 2 $ &6'8 / A$ &#D. 0$ *)& *!! / $5<A& / /B '$!&,< * *< =, %-%, <3 $ & %,5. 1F %#. 6 "H I 53

54 Le Marché de la Gestion de Configuration 54

55 Le Marché de la Gestion de Configuration 55

56 Les bénéfices de la GCL Fournit une approche disciplinée et documentée pour définir, organiser et maintenir les éléments applicatifs, Garantit l intégrité des applications, Assure que les versions précédentes de tout livrable contrôlé par configuration peuvent être restaurées et recréées, Assure que tous les changements ne sont réalisés que lorsque cela est requis et seulement par ceux autorisés. 56