GESTION des CONFIGURATIONS LOGICIELLES

1. GESTION des CONFIGURATIONS LOGICIELLES Définition et Principes

2. GÉRER LE CHANGEMENT ET LES MODIFICATIONS (1/2) • Constat • 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 exemple les erreurs) • LE CHANGEMENT EST DESTABILISATEUR • Délais de livraison • Coûts de la réalisation • Cohérence et complétude du système • VARIÉTÉ DE POINTS DE VUES ÉVENTUELLEMENT CONTRADICTOIRES • Des individus et du rôle qu'ils jouent • Des organisations en présence • Des processus et/ou fonctions de l’entreprise (i.e. développement, intégration, maintenance, assurance qualité, ...) • Le problème • COMMENT GÉRER AU MIEUX LE CHANGEMENT (Contrat de service, évolution) • Mesurer l'impact des changements proposés (Estimation CQFD Coût/Qualité/Fonctionnalité /Délai) • COMMENT GÉRER LES INTERACTIONS ENTRE LES ACTEURS • Équilibre raisonnable entre : Communications informelles / Communications formelles

3. GÉRER LE CHANGEMENT ET LES MODIFICATIONS (2/2) • Nature des changements • Changements/modifications DANS LE TEMPS • Nouveaux besoins liés à la maintenance et au MCO (Maintien en condition opérationnel) • Évolution, adaptation du système à son environnement (organisation cible et plates-formes d’exploitation  nouvelles technologies) • Corrections suite à des rapports d’anomalies signalées par les utilisateurs • Acteurs concernés • Essentiellement la maîtrise d’œuvre : équipes de maintenance (mais sous contrôle de la maîtrise d’ouvrage qui décide ce qui doit être fait) • Processus clé : la MAINTENANCE • Changements/modifications DANS L’ESPACE • Distribution de nouvelles versions de logiciel • Très difficile dès que le parc des plates-formes à installer est important (cf. cas de la microinformatique)  Problème de la cartographie des applications et des corrections réellement installées • La cohabitation entre plusieurs versions est généralement inévitable, d’où problème très important de compatibilité des versions présentes à l’instant T • Acteurs concernés • Essentiellement les équipes de support (« hot line ») et d’exploitation • Les utilisateurs

4. 3 CAS CLASSIQUES (1/3) • PROBLÈME DE LA DOUBLE MAINTENANCE SYSTÈME A Modifications de C dans A à T3 Constituant C Copie #1 de C à T1 C SYSTÈME B Copie #2 de C à T2 IL FAUT MINIMISER LES DUPLICATIONS CAR, INÉVITABLEMENT, LES COPIES MULTIPLES DIVERGENT ; L'AUGMENTATION DU COUT EST INÉLUCTABLE

5. 3 CAS CLASSIQUES (2/3) • PROBLÈME DU PARTAGE DES DONNÉES DANGER Programmeur #1 LES PROGRAMMEURS P#1 ET P#2 TRAVAILLENT TOUS DEUX SUR LE MÊME CONSTITUANT C Programmeur #2 Constituant C LES ERREURS DE P#1 PEUVENT BLOQUER P#2 ; LE RETARD EST INÉLUCTABLE

6. 3 CAS CLASSIQUES (3/3) Copie #1 de C dans l'environnement de P#1 • PROBLÈME DES MISES A JOUR SIMULTANÉES Programmeur #1 SYSTÈME A Environnement de travail de P#1 à T4 à T1 Le "secrétaire" doit garder trace des copies multiples et synchroniser les mises à jour discipline + rigueur de développement. Copie #2 de C dans l'environnement de P#2 Programmeur #2 à T2 Environnement de travail de P#2 à T3 POUR DONNER DU CONFORT A P#1 ET A P#2, ET ÉVITER LE PB#2, C A ÉTÉ DUPLIQUÉ, CE QUI NOUS RAMÈNE AU PB#1  GÉRER LE DILEMME !?

7. GÉRER LES COMMUNICATIONS ENTRE LES ACTEURS 2 Personnes  1 Canal 3 Personnes  3 Canaux 4 Personnes  6 Canaux La Base de Données communes sert de régulateur aux communications formelles, au prix d'une certaine lourdeur : elle matérialise les protocoles d'échanges convenus entre les acteurs Il faut doser:- la communication formelle (complexité linéaire)- la communication informelle (complexité exponentielle) analyse de la situation concrète + bon sens

8. 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 Souche commune + procédés de fabrication pour A, B, C, ... Spécificités A Plate-forme A Plate-forme B Plate-forme C Evolutions Parc A Parc B Parc C

9. BUT DE LA GESTION DE CONFIGURATION • DÉFINITION D'UNE CONFIGURATION : • ENSEMBLE COHÉRENT DE COMPOSANTS PERMETTANT, A 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 GESTION DE CONFIGURATION • Nombre d'objets à gérer  Dépend de la granularité et du type de nomenclature • Variété des objets • Variété des supports d'archivage et de stockage. • Caractéristiques "molles" 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 noiresdont il est souvent difficile de cerner les contours

10. LES 3 AXES DE LA GESTION DE CONFIGURATION • Processus GC • Identification • Contrôle • Administration • Audit • Nature du produit • Hardware • Firmware • Software • Documentation • Processus de développement et MCO • Cycle de vie système et logiciel • Acquisition progressive par paliers fonctionnels  N versions successives avec compatibilité ascendante des versions

11. LE PROCESSUS GESTION DE CONFIGURATION (1/2) • ACTIVITÉS ET TACHES DU PROCESSUS GC • ENSEMBLE DES ACTIVITÉS, MANUELLES ET/OU AUTOMATISÉES, PERMETTANT DE : • définir les composants de la configuration et toutes leurs relations • suivre les évolutions dans le temps de la configuration • archiver les états livrés successifs • s'assurer que chacun des états livrés est cohérent et complet • LES 4 FONCTIONS PRINCIPALES : GESTION de CONFIGURATION IDENTIFICATION CONTROLE des MODIFICATIONS ADMINISTRATION AUDIT

12. LE PROCESSUS GESTION DE CONFIGURATION (2/2) • LE PROCESSUS SE TRADUIT PAR UN ENSEMBLE DE PROCÉDURES A SUIVRE (Workflow de la gestion de configuration) : • procédures automatiques qui s'appuient sur des outils : • au niveau du système d'exploitation : • Système de gestion de fichiers et bibliothécaire. • SGBD • Éditeurs de textes • Compilateurs, traducteurs de langages • Éditeurs de liens, relieurs. • Unix et/ou Windows : • SCCS, MAKE, RCS • Progiciels • Cf. outil ClearCase de RATIONAL • Dictionnaires de données et/ou référentiel • procédures manuelles • formation des équipes • discipline et rigueur individuelle, sens de l'équipe, sens du projet • LA BONNE MISE EN OEUVRE D'UNE GESTION DE CONFIGURATION NÉCESSITE UN BONNIVEAU DE MATURITÉDE L'ORGANISATION DE DÉVELOPPEMENT • c’est un jeu collectif qui implique la coopération de nombreux acteurs

13. STANDARDS - BIBLIOGRAPHIE - PRODUITS • La plus importante : NORME ANSI/IEEE 828-1990 et 1042-1987 (révisée en 1993) - Document très complet, indispensable à toute organisation de développement • Norme ISO/CEI 12207 Cycle de vie logiciel • Autres : • NORME AVIATION CIVILE RTCA DO 178 A • NORME SÉCURITÉ ISO • Bibliographie sommaire : • Software Configuration Management, W.A.Babich, Addison-Wesley • Implementing Configuration Management, F.J.Buckley, IEEE Press • Nombreux produits disponibles • En standard sous UNIX : Make files et SCCS • Nombreux « Freeware »