IFT3902 : (Gestion de projet pour le) développement, (et la) maintenance des logiciels Yann-Gaël Guéhéneuc Professeur adjoint guehene@iro.umontreal.ca, local 2345 Département d informatique et de recherche opérationnelle Université de Montréal Yann-Gaël Guéhéneuc 2007
Plan du cours 1. Introduction 2. Notion de projet logiciel 3. Organisation du développement 4. Planification du développement 5. Contrôle du développement 6. Organisation de la maintenance 2/25
6. Organisation de la maintenance 1. Généralités 2. Types de maintenance 3. Modèles de maintenance 4. Gestion de la maintenance 5. Maintenabilité 6. Ré-ingénierie 7. Conclusion 3/25
6.1. Généralités (1/8) Définition La maintenance est l ensemble des activités effectuées pour modifier un logiciel après sa mise en opérations «La plupart des logiciels sont immortels» Nicholas Zvegintzov 4/25
6.1. Généralités (1 bis /8) Saviez-vous que 85% des programmes de gestion d affaires mondiaux sont en COBOL 90 000 développeurs COBOL existent (encore) aux États-Unis d Amérique 200 milliards de lignes de code COBOL tournent (encore) dans le monde 35% du développement de nouvelles applications d affaires est en COBOL 59% des systèmes d information du Ministère de la «Defence» des États-Unis d Amérique sont en COBOL 5/25
6.1. Généralités (2/8) Justifications Correction d erreurs (boucle sans fin) Adaptation aux besoins des usagers Améliorations (implantation, architecture, performances) Changement de l environnement technique Changement de l environnement «affaires» Modernisation 6/25
6.1. Généralités (3/8) Cinq lois de l évolution des programmes Les cinq lois de Lehman, 1985 Loi du changement continuel Un programme utilisé dans un environnement du monde réel doit nécessairement changer sinon il deviendra progressivement de moins en moins utile dans cet environnement (De plus, un programme introduit dans un environnement change celui-ci, cf. l «effet d observation») 7/25
6.1. Généralités (4/8) Cinq lois de l évolution des programmes Loi de la complexité croissante Lorsqu un programme change, sa structure tend à devenir plus complexe. Des ressources additionnelles doivent être consacrées à maintenir et à préserver sa structure (Plus un programme est modifié, plus sa structure originelle est corrompue : il faut limiter le nombre de personnes travaillant sur un programme) 8/25
6.1. Généralités (5/8) Cinq lois de l évolution des programmes Loi de l évolution des grands programmes L évolution des grands programmes est un processus auto-régulateur. Les attributs comme la taille, le temps entre versions et le nombre d erreurs signalées sont approximativement invariants pour chaque version du programme (Tout le monde aime la stabilité ) 9/25
6.1. Généralités (6/8) Cinq lois de l évolution des programmes Loi de la stabilité organisationnelle Pendant la vie d un programme, son taux de développement est approximativement constant et indépendant des ressources qui y sont consacrées (Rappelez-vous également du mythe de la personne mois) 10/25
6.1. Généralités (7/8) Cinq lois de l évolution des programmes Loi de la conservation de la familiarité Pendant la vie d un programme, l incrément de changement dans chaque version est approximativement constant (C est pourquoi il faut mettre en place des mécanismes pour prendre en compte au plus tôt les futurs changement et limiter la corruption du programme) 11/25
6.1. Généralités (8/8) Coûts de la maintenance 100% 90% 80% 80% 70% 60% 60% 40% 20% 40-1000 times 0% Début années 70 Début années 80 Fin années 80 Début années 90 15-40 times 30-70 times 6 times 10 times Conception Code Programmation Tests Utilisation 12/25
6. Organisation de la maintenance 1. Généralités 2. Types de maintenance 3. Modèles de maintenance 4. Gestion de la maintenance 5. Maintenabilité 6. Ré-ingénierie 7. Conclusion 13/25
6.2. Types de maintenance (1/3) Définitions traditionnelles Maintenance corrective Réparation des erreurs découvertes pendant l utilisation du logiciel Maintenance adaptative Modifications du logiciel entraînées par des changements dans l environnement technique Maintenance perfective Modifications du logiciel entraînées par des changements ou ajouts dans les besoins 14/25
6.2. Types de maintenance (2/3) Catégorie oubliée Maintenance pour améliorer les performances Catégorie nouvelle Migration (legacy systems) Refonte totale du logiciel par des moyens automatiques ou semi-automatiques en raison de sa vétusté 15/25
6.2. Types de maintenance (3/3) Répartition de l effort de maintenance (types traditionnels) Répartition de l'effort de maintenance (données de 1980) 20% 55% 25% corrective adaptative perfective Données de 1990, maintenance corrective : 21%, non-corrective : 79% 16/25
6. Organisation de la maintenance 1. Généralités 2. Types de maintenance 3. Modèles de maintenance 4. Gestion de la maintenance 5. Maintenabilité 6. Ré-ingénierie 7. Conclusion 17/25
6.3. Modèles de maintenance (1/17) Cycle de vie réel d un logiciel Cycle de vie de la maintenance Modèles de cycle de maintenance Un point de vocabulaire 18/25
6.3. Modèles de maintenance (2/17) Cycle de vie réel d un logiciel La maintenance est une activité récurrente Retrait maintenance maintenance maintenance maintenance 19/25
6.3. Modèles de maintenance (3/17) Cycle de vie de la maintenance Introduction Croissance Maturité Déclin Support Corrections Modifications Modifications xxxxxxxx Activité de maintenance la plus importante 20/25
6.3. Modèles de maintenance (4/17) Modèles de cycle de maintenance Modèle de «maintenance urgente» Modèle IEEE D autres modèles existent : Taute, ISO 21/25
6.3. Modèles de maintenance (5/17) Modèles de cycle de maintenance Modèle de «maintenance urgente» Travail fait aussi vite que possible Peu ou pas documenté Pas de respect des règles et des normes Demande de changement (DC) Analyse du code source Modification du code source Livraison du logiciel modifié 22/25
6.3. Modèles de maintenance(5 bis /17) 23/25
6.3. Modèles de maintenance (8/17) Modèles de cycle de maintenance Modèle IEEE (1993) DC Classification Analyse Livraison Conception Acceptation Implantation Tests 24/25
6.3. Modèles de maintenance (15/17) Un point de vocabulaire Terminologie IEEE pour la ré-ingénierie et la rétro-conception (1990) Software maintenance : maintenance Forward engineering : développement 25/25
6.3. Modèles de maintenance (16/17) Un point de vocabulaire Reverse engineering : rétro-conception Identification des composants d un programme Classes, modules, fonctionnalités Représentation sous une forme plus abstraite Code source, UML, Wright Design recovery : recouvrement des choix de conception et architecturaux Informations sur le domaine Informations extérieurs Déduction, analyses «floues» 26/25
6.3. Modèles de maintenance (17/17) Un point de vocabulaire Restructuring : restructuration Transformation d une représentation à une autre au même niveau d abstraction Refactorings : re-factorisation Redocumentation : re-documentation Le résultat est pour les personnes Reengineering : ré-ingénierie Examen d un programme pour en obtenir une nouvelle représentation et son implantation 27/25