Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Yann-Gaël Guéhéneuc © Yann-Gaël Guéhéneuc 2007 Département d’informatique et de

Yann-Gaël Guéhéneuc © Yann-Gaël Guéhéneuc 2007 Département d’informatique et de recherche opérationnelle Université de Montréal IFT3902 : (Gestion de projet pour le) développement, (et la) maintenance des logiciels Professeur adjoint guehene@iro.umontreal.ca, local 2345 2/25 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 3/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 4/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 5/25 6.1. Généralités (1bis/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 6/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 7/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 ») 8/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) 9/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é…) 10/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) 11/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) 12/25 60% 70% 80% 90% 0% 20% 40% 60% 80% 100% Début années 70 Début années 80 Fin années 80 Début années 90 6.1. Généralités (8/8) Coûts de la maintenance 10 times 6 times 15-40 times 30-70 times 40-1000 times Conception Code Programmation Tests Utilisation 13/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 14/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 15/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é 16/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% 25% 55% corrective adaptative perfective Données de 1990, maintenance corrective : 21%, non-corrective : 79% 17/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 18/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 19/25 6.3. Modèles de maintenance (2/17) Cycle de vie réel d’un logiciel – La maintenance est une activité récurrente maintenance maintenance maintenance maintenance Retrait 20/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 21/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… 22/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é 23/25 6.3. Modèles de maintenance(5bis/17) 24/25 6.3. Modèles de maintenance (8/17) Modèles de cycle de maintenance – Modèle IEEE (1993) DC Classification Analyse Conception Implantation Tests Acceptation Livraison 25/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 26/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 » 27/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 uploads/Management/ chapitre-6-2-organisation-de-la-maintenance-types-de-maintenance-et-modeles-de-maintenance.pdf