View
3
Download
0
Category
Preview:
Citation preview
1
Département d’informatique et de recherche opérationnelle
Université de Montréal
Yann-Gaël Guéhéneuc
IFT3902 :(Gestion de projet pour le)
développement, (et la)maintenance des logiciels
Professeur adjointguehene@iro.umontreal.ca, local 2345
(Cours tiré du cours du Pr. François Lustman)
© Yann- Gaël Guéhéneuc 2003
2/84
Plan du cours
1. Introduction2. Notion de projet logiciel
3. Organisation du développement4. Planification du développement5. Contrôle du développement6. Organisation de la maintenance
3/84
6. Organisation de la maintenance
1. Généralités2. Types de maintenance3. Modèles de maintenance4. Gestion de la maintenance5. Maintenabilité6. Ré-ingénierie7. Conclusion
2
4/84
6.1. Généralités (1/8)
nDé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/84
6.1. Généralités (2/8)
n 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/84
6.1. Généralités (3/8)
nCinq 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 changecelui -ci)
3
7/84
6.1. Généralités (4/8)
nCinq 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/84
6.1. Généralités (5/8)
nCinq 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/84
6.1. Généralités (6/8)
nCinq 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)
4
10/84
6.1. Généralités (7/8)
nCinq 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/84
60%70%
80%90%
0 %
20%
40%
60%
80%
100%
Débutannées 70
Débutannées 80
Fin années80
Débutannées 90
6.1. Généralités (8/8)
nCoûts de la maintenance
10 times6 times
15-40 times
30-70 times
40-1000 times
Concept
ion Code
Progra
mmation Tests
Utilisatio
n
12/84
6. Organisation de la maintenance
1. Généralités2. Types de maintenance3. Modèles de maintenance4. Gestion de la maintenance5. Maintenabilité6. Ré-ingénierie7. Conclusion
5
13/84
6.2. Types de maintenance (1/3)
nDé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/84
6.2. Types de maintenance (2/3)
nCatégorie oubliée– Maintenance pour améliorer les
performances
nCatégorie nouvelle– Migration (legacy systems)– Refonte totale du logiciel par des moyens
automatiques ou semi-automatiques en raison de sa vétusté
15/84
6.2. Types de maintenance (3/3)
nRé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%
6
16/84
6. Organisation de la maintenance
1. Généralités2. Types de maintenance3. Modèles de maintenance4. Gestion de la maintenance5. Maintenabilité6. Ré-ingénierie7. Conclusion
17/84
6.3. Modèles de maintenance (1/17)
nCycle de vie réel d’un logicielnCycle de vie de la maintenance
nModèles de cycle de maintenancenChoix d’un cycle de maintenance
nUn point de vocabulaire
18/84
6.3. Modèles de maintenance (2/17)
nCycle de vie réel d’un logiciel– La maintenance est une activité récurrente
maintenance maintenance maintenance maintenance
Retrait
7
19/84
6.3. Modèles de maintenance (3/17)
nCycle de vie de la maintenance
Introduction Croissance Maturité Déclin
Support Corrections Modifications Modifications
xxxxxxxx Activité de maintenance la plus importante
20/84
6.3. Modèles de maintenance (4/17)
nModèles de cycle de maintenance– Modèle de «maintenance urgente »– Modèle deTaute– Modèle IEEE– Modèle ISO
21/84
6.3. Modèles de maintenance (5/17)
nModè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 dechangement
(DC)Analyse du code source
Modification du code source
Livraison du logiciel modifié
8
22/84
6.3. Modèles de maintenance (6/17)
nModèles de cycle de maintenance– Modèle de Taute
(1983, 1986) DC
Estimation
Planification
Programmation
Test
Documentation
Acceptation
Opération
23/84
6.3. Modèles de maintenance (7/17)
nModèles de cycle de maintenance– Modèle de Taute
• Simple• Pratique• Aspect cyclique• Planification des versions
24/84
6.3. Modèles de maintenance (8/17)
nModèles de cycle de maintenance– Modèle IEEE
(1993) DC Classification Analyse
Conception
Implantation
Tests
Acceptation
Livraison
9
25/84
6.3. Modèles de maintenance (9/17)
nModèles de cycle de maintenance– Modèle IEEE
• Proche du modèle de Taute
26/84
6.3. Modèles de maintenance (10/17)
nModèles de cycle de maintenance– Modèle ISO/IEC 12207
(1995) Implantation processus
Analyse DC
Implantation DC
Revue maintenance
Migration
Retrait du logiciel
27/84
6.3. Modèles de maintenance (11/17)
nModèles de cycle de maintenance– Modèle ISO/IEC 12207
• Dans le cadre plus global des processus du cycle de vie des logiciels
10
28/84
6.3. Modèles de maintenance (12/17)
nChoix d’un cycle de maintenance– Facteurs de décision
• Sophistication de l’organisation• Moyens financiers
29/84
6.3. Modèles de maintenance (13/17)
nChoix d’un cycle de maintenance– Modèle « maintenance urgente »
• En théorie : à ne pas prendre• En pratique : probable au niveau 1 du CMM• Acceptable au niveau 2 si le changement est
repris dans le cadre d’un modèle plus sophistiqué de maintenance
30/84
6.3. Modèles de maintenance (14/17)
nChoix d’un cycle de maintenance– Modèle deTaute
• Organisations de niveau 2 au moins du CMM
– Modèles IEEE et ISO• Organisations de niveau 3 au moins du CMM
11
31/84
6.3. Modèles de maintenance (15/17)
nUn point de vocabulaire– Terminologie IEEE pour la ré-ingénierie et la
rétro-conception (1990)
– Software maintenance : maintenance– Forward engineering : développement
32/84
6.3. Modèles de maintenance (16/17)
nUn 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 »
33/84
6.3. Modèles de maintenance (17/17)
nUn point de vocabulaire– Restructuring : restructuration
• Transformation d’une représentation à une autre au même niveau d’abstraction
– Refactorings
• 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
12
34/84
6. Organisation de la maintenance
1. Généralités2. Types de maintenance3. Modèles de maintenance4. Gestion de la maintenance5. Maintenabilité6. Ré-ingénierie7. Conclusion
35/84
6.4. Gestion de la maintenance (1/11)
n Principales fonctionsn Structures administratives
n Prédiction de la maintenancenMétriques de maintenancen Problèmes de maintenance
36/84
6.4. Gestion de la maintenance (2/11)
n Principales fonctions– Gestion–supervision– Modification du logiciel– Gestion de la configuration– Formation– Aide à l’usager– Assistance technique– Tests– Assurance qualité
13
37/84
6.4. Gestion de la maintenance (3/11)
n Structures administratives– Maintenance incluse dans le groupe de
développement• Les développeurs d’un produit en assurent la
maintenance
• Une équipe spécialisée assure la maintenance
– Maintenance assurée par une unité spécialisée (hors du groupe de développement)
38/84
6.4. Gestion de la maintenance (4/11)
n Structures administratives– Cas des petites organisations
• L’assurance qualité regroupe les tests et la gestion de configuration
Groupe de maintenance
Assurance qualitéFormation
Aide à l’usager
Produit A
Produit B
Produit C
Tests Gestion de configuration
39/84
6.4. Gestion de la maintenance (5/11)
n Prédiction de la maintenance– Quoi prédire
• Nombre annuel de demandes de changements• Parties du logiciel les plus affectées• Coûts annuels de maintenance
– COCOMO de base : Em = ACT × Effort– COCOMO intermédiaire : Em = ACT × Enominal × FA
ACT : annual change trafficFA : facteurs d’ajustement
– COCOMO II : formule complexe prenant en compte la fraction du code qui est à changer
14
40/84
6.4. Gestion de la maintenance (6/11)
nMétriques de maintenance– Justification
• Besoins minimaux : permettre les prédictions• Besoins ambitieux : connaître sa performance
et l’améliorer
41/84
6.4. Gestion de la maintenance (7/11)
nMétriques de maintenance– Besoins de prédiction
• Nombre annuel de demandes de changements– Enregistrer et compter les demandes
• Parties du logiciel les plus affectées– « Modules » affectés par les changements– Nombre de fois qu’un «module » est modifié
42/84
6.4. Gestion de la maintenance (8/11)
nMétriques de maintenance– Besoins de prédiction
• Coûts annuels de maintenance : éléments permettant de calculer ACT (COCOMO)
– Taille (KLOC) du logiciel changé– Nombre de lignes modifiées– Nombre de lignes ajoutées
15
43/84
6.4. Gestion de la maintenance (9/11)
nMétriques de maintenance– Connaître sa performance et l’améliorer
• Approche théorique : la méthode GQM(Goal / Question / Metric)
• Suggestions pratiques– Taille (déjà vu)
• Productivité– Effort consommé, répartition, moyennes
• Personnel
44/84
6.4. Gestion de la maintenance (10/11)
nMétriques de maintenance– Connaître sa performance et l’améliorer
• Catégories de maintenance– DCs par catégorie– Effort par catégorie
• Qualité– Causes des erreurs
45/84
6.4. Gestion de la maintenance (11/11)
n Problèmes de maintenance– Personnel inexpérimenté– Taux élevé de rotation de personnel– Difficultés d’évaluation du personnel– Mauvais moral du personnel– Arriéré de travail important– Priorités changeantes– Pas de processus de maintenance– Méthodes de tests pas adaptées
16
46/84
6. Organisation de la maintenance
1. Généralités2. Types de maintenance3. Modèles de maintenance4. Gestion de la maintenance5. Maintenabilité6. Ré-ingénierie7. Conclusion
47/84
6.5. Maintenabilité (1/10)
nDéfinitionn Prédiction de la maintenabilité
n Pratiques recommandées
48/84
6.5. Maintenabilité (2/10)
nDéfinition– La maintenabilité est la facilité avec laquelle
• un logiciel peut être corrigé en cas d’erreurs • il peut être modifié pour satisfaire de nouveaux
besoins
17
49/84
6.5. Maintenabilité (3/10)
nDéfinition– Rappel
• La maintenabilité est une des caractéristiques de la qualité du logiciel
– Sous caractéristiques de maintenabilité (IEEE)
• Facilité de correction• Facilité d’expansion• Facilité de test
50/84
6.5. Maintenabilité (4/10)
n Prédiction de la maintenabilité– Hypothèse : la maintenabilité d’un
programme est reliée à sa complexité
– Un logiciel passe entre 75% et 90% de sa vie en maintenance
– Un mainteneur passe entre 50% et 75% de son temps à lire, comprendre le logiciel
51/84
6.5. Maintenabilité (5/10)
n Prédiction de la maintenabilité– Métriques ayant un impact sur la
maintenabilité• Complexité cyclomatique ou autres• Taille
• Métriques de couplage, de cohésion
– La valeur relative des métriques est significative
18
52/84
6.5. Maintenabilité (6/10)
n Pratiques recommandées :des pratiques saines du génie logiciel
– Difficultés• Domaine du logiciel : quoi, implantation du
logiciel : comment• Niveau concret (implantation), abstrait
(conception, architecture)• Structures formelles (implantation), informelles
(compréhension humaine)
53/84
6.5. Maintenabilité (7/10)
n Pratiques recommandées– Documentation
• On ne le répétera jamais assez… ☺
– Commentaires significatifs et utiles• Expliquer ce que fait la classe, la méthode…• Expliquer les paramètres d’entrée et la sortie• Ne pas dire « voici une méthode qui retourne
un entier »
54/84
6.5. Maintenabilité (8/10)
n Pratiques recommandées– Définition et respect de normes (y compris
pour les noms des éléments du programme)• Chaque langage de programmation à ses règles• Règles propres à l’organisation
• Utiliser les idiomes de programmation
– Présentation du code systématique• Consistance• Automatique
19
55/84
6.5. Maintenabilité (9/10)
n Pratiques recommandées– Penser aux changements potentiels lors de
la conception et de la programmation• Dès l’architecture• Surtout pendant la conception détaillée
• Patrons de conception
– Utilisation des pré - / post-conditions– Maximiser cohésion, minimiser couplage
56/84
6.5. Maintenabilité (10/10)
n Pratiques recommandées– Pratiquer la réutilisation – Penser et documenter la traçabilité
• Relations entre besoins – architecture –conception détaillée – implantation
– Liste non exhaustive !
57/84
6. Organisation de la maintenance
1. Généralités2. Types de maintenance3. Modèles de maintenance4. Gestion de la maintenance5. Maintenabilité6. Ré-ingénierie7. Conclusion
20
58/84
6.6. Ré-ingénierie (1/18)
n Systèmes hérités (legacy systems)nDéfinition
nCatégories de ré-ingénierienConclusions
59/84
6.6. Ré-ingénierie (2/18)
n Systèmes hérités (legacy systems)– Caractéristiques existentielles
• Systèmes anciens, fonctionnant toujours et rendant des services importants (souvent critiques pour le fonctionnement de l’entreprise)
• Très grand nombre de changements• Différentes personnes ont travaillé sur ces
systèmes
60/84
6.6. Ré-ingénierie (3/18)
n Systèmes hérités (legacy systems)– Caractéristiques techniques
• Gros systèmes• Spécifications très incomplètes• Documentation périmée, absente, incomplète• Certaines règles d’affaires n’existent que dans
le code source• Langage(s) de programmation anciens• Implantation pour du matériel obsolète• Architecture corrompue par les changements
21
61/84
6.6. Ré-ingénierie (4/18)
n Systèmes hérités (legacy systems)– Continuer à le maintenir
• Système toujours utile et relativement stable
– Éliminer le système• Contribution limitée du système aux affaires
(les processus d’affaire ont changés)• Systèmes plus modernes fonctionnent
– Remplacer par un système tout neuf• Considérations des coûts
62/84
6.6. Ré-ingénierie (5/18)
n Systèmes hérités (legacy systems)– Transformer le système : ré-ingénierie
• Système toujours nécessaire• Système trop fragile pour être maintenu ou trop
difficile à maintenir• Spécifications connues de personne• Règles de fonctionnement indispensables et
impossible à remplacer par un système neuf
63/84
6.6. Ré-ingénierie (6/18)
nDéfinition– Construire une nouvelle implantation d’un
logiciel à partir de la version existante
22
64/84
6.6. Ré-ingénierie (7/18)
nDéfinition– Tiré du modèle du fer à cheval (Muller,
Katzman et Wood)
Système hérité Nouveau systèmeRec
onst
itutio
n de
l’ar
chite
ctur
e(r
étro
-ingé
nier
ie)
Transformation de l’architecture
Développem
ent basé sur une nouvelle architecture
Représentation niveau implantation
Représentation niveau conception
Représentation niveau architecture
65/84
6.6. Ré-ingénierie (8/18)
nCatégories de ré-ingénierie– Ré-ingénierie du code– Ré-ingénierie des données– Ré-ingénierie des fonctionnalités– Ré-ingénierie de l’architecture
66/84
6.6. Ré-ingénierie (9/18)
nCatégories de ré-ingénierie– Ré-ingénierie du code
• Cas le plus fréquent de ré-ingénierie
• Restructuration du code– Justification
» Code = spaghetti impossible à maintenir– Ne modifie pas l’architecture du système– Ne modifie pas la fonctionnalité des modules– Restructure le code et–ou les données de chaque
module pour le rendre plus facile à maintenir
23
67/84
6.6. Ré-ingénierie (10/18)
nCatégories de ré-ingénierie– Ré-ingénierie du code
• Translation du code– Justifications
» Langage périmé» Personnel compétent introuvable» Standardisation dans l’entreprise…
– Conversion d’un langage de programmation à un autre sans autres modifications
– Peut être fait automatiquement ou semi-automatiquement ☺
68/84
6.6. Ré-ingénierie (11/18)
nCatégories de ré-ingénierie– Ré-ingénierie des données
• Justifications– Incompréhension– Mauvaise architecture– Implantation périmée
69/84
6.6. Ré-ingénierie (12/18)
nCatégories de ré-ingénierie– Ré-ingénierie des données
• Démarches– Rétro-ingénierie des données
» Analyse du code source» Inventaire des fichiers ou analyse des schémas
des base de données» Conceptualisation des données» Existence d’outils permettant d’assister l’activité
24
70/84
6.6. Ré-ingénierie (13/18)
nCatégories de ré-ingénierie– Ré-ingénierie des données
• Démarches– Restructuration
» Locale : rationalisations au niveau des modules (noms, structures locales)
» Globale : re-définition de l’architecture des données de l’application, conversion des données
» Existence d’outils permettant d’assister l’activité
71/84
6.6. Ré-ingénierie (14/18)
nCatégories de ré-ingénierie– Ré-ingénierie des fonctionnalités
• Réorganisation du logiciel : regroupement en un même module de fonctionnalités relatives à un même concept
– Regroupement fonctionnel en un même module de toutes les parties relatives aux entrées–sorties
– Regroupement en un même module de tous les traitements relatifs à une même structure de données
– …
72/84
6.6. Ré-ingénierie (15/18)
nCatégories de ré-ingénierie– Ré-ingénierie des fonctionnalités
• Justification– Simplification de l’architecture pour une meilleure
compréhension– Élimination des redondances– Maintenance plus facile
• Aide limitée d’outils L– Visualisation– Métrique de cohésion, couplage
– Furetage
25
73/84
6.6. Ré-ingénierie (16/18)
nCatégories de ré-ingénierie– Ré-ingénierie de l’architecture
• Refonte de l’architecture générale du système (fonctions et–ou données)
74/84
6.6. Ré-ingénierie (17/18)
nCatégories de ré-ingénierie– Ré-ingénierie de l’architecture
• Justification– Architecture mauvaise ou trop détériorée– Architecture périmée– Nouveau paradigme (structuré, orienté-objet)
• Existence d’outils– Traducteurs pour reconstituer l’architecture– Visualisation– Générateurs de code (ou de squelettes de code)
75/84
6.6. Ré-ingénierie (18/18)
nConclusions– Activité de maintenance pas encore
complètement définie– Justifications techniques, économiques,
d’affaires… légales !– Support informatique partiel, peu efficace ?– Solution de plus en plus souvent considérée
26
76/84
6. Organisation de la maintenance
1. Généralités2. Types de maintenance3. Modèles de maintenance4. Gestion de la maintenance5. Maintenabilité6. Ré-ingénierie7. Conclusion
77/84
6.7. Conclusion (1/8)
nMaintenance– Activité la plus importante en ressources
consommées de l’informatique
n Activité mal aiméen Activité médiocrement connue
78/84
6.7. Conclusion (2/8)
nDéfis de la maintenance– Processus
• Pas de processus intégré au développement– Programmation extrême
• Pas de processus adapté aux différents types de maintenance et à leur importance
• Pas de processus adapté au nouveau fonctionnement des entreprises
– Sous-traitance– Consultation
27
79/84
6.7. Conclusion (3/8)
nDéfis de la maintenance– Techniques
• Rétro-conception– Idiomes de programmation
» Relation entre classes– Diagrammes
» Classes» Séquences» …
– Patrons de conception– Patrons d’architecture
80/84
6.7. Conclusion (4/8)
nDéfis de la maintenance– Techniques
• Analyses des programmes= Extraction d’information sur le comportement
– Le code est pauvre comparé à des modèles construits avec attention
– Modèles abstraits– Analyse des programmes peut « améliorer » les
modèles abstraits– Besoin de cohérence entre modèles et implantation !
81/84
6.7. Conclusion (5/8)
nDéfis de la maintenance– Techniques
• Analyses des programmes– Analyse ou description– Modèles globaux ou locaux– Simulation ou contrôle– Vérification ou réfutation– Style déclaratif ou opérationnel– Statique ou dynamique– Correct ou incorrect– Rapide ou précise
28
82/84
6.7. Conclusion (6/8)
nDéfis de la maintenance– Techniques
• Translation, transformation de modèles– Sémantique
• Génération de code– Confiance– Performance– Maintenabilité
• Méthodologie Model -Driven Architecture(?)
83/84
6.7. Conclusion (7/8)
n Améliorations– Maintenabilité– Ré-utilisation– Composants– Aspects
– Logiciels libres / à code source ouvert (?)
84/84
6.7. Conclusion (8/8)
n Inquiétudes– Nécessité de développement rapide et peu
coûteux– Nouveau domaine : maintenance
d’applications basées sur l’Internet (parce que peu connue)
Recommended