GESTION des CONFIGURATIONS LOGICIELLES Définition et Principes

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

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 Essentiellement les équipes de support (« hot line ») et d’exploitation Les utilisateurs

PROBLÈME DE LA DOUBLE MAINTENANCE 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

LES ERREURS DE P#1 PEUVENT BLOQUER P#2 ; LE RETARD EST INÉLUCTABLE 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

PROBLÈME DES MISES A JOUR SIMULTANÉES 3 CAS CLASSIQUES (3/3) PROBLÈME DES MISES A JOUR SIMULTANÉES Copie #1 de C dans l'environnement de P#1 Programmeur #1 Environnement de travail de P#1 SYSTÈME A à 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 !?

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

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

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 noires dont il est souvent difficile de cerner les contours

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

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

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 BON NIVEAU DE MATURITÉ DE L'ORGANISATION DE DÉVELOPPEMENT c’est un jeu collectif qui implique la coopération de nombreux acteurs

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 »