Gestion des configurations logicielles
This presentation is the property of its rightful owner.
Sponsored Links
1 / 13

GESTION des CONFIGURATIONS LOGICIELLES PowerPoint PPT Presentation


  • 88 Views
  • Uploaded on
  • Presentation posted in: General

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)

Download Presentation

GESTION des CONFIGURATIONS LOGICIELLES

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Gestion des configurations logicielles

GESTION des CONFIGURATIONS LOGICIELLES

Définition et Principes


G rer le changement et les modifications 1 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


  • G rer le changement et les modifications 2 2

    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


    3 cas classiques 1 3

    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


    3 cas classiques 2 3

    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


    3 cas classiques 3 3

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


    G rer les communications entre les acteurs

    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

    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

    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


    Les 3 axes de la gestion de configuration

    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

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


    Standards bibliographie produits

    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 »


  • Login