Yann-Gaël Guéhéneuc
Département d’informatique et de recherche opérationnelle
IFT3902 :
(Gestion de projet pour le) développement, (et la) maintenance des logiciels
Professeur adjoint
[email protected], local 2345
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
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
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
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
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 »)
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)
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é…)
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)
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)
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
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
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
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é
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
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
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
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
6.3. Modèles de maintenance (3/17)
Cycle de vie de la maintenance
Introduction Croissance Maturité Déclin
Support Corrections Modifications Modifications
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…
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é
6.3. Modèles de maintenance(5 bis /17)
6.3. Modèles de maintenance (8/17)
Modèles de cycle de maintenance
– Modèle IEEE
(1993)
DC Classification AnalyseConception
Acceptation Livraison
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
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
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
