View
2
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/71
Plan du cours
1. Introduction2. Notion de projet logiciel3. Organisation du développement4. Planification du développement5. Contrôle du développement6. Organisation de la maintenance
3/71
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/71
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/71
6.1. Généralités (2/8)
n Justifications– Correction d’erreurs (boucle sans fin)– Adaptation aux besoins des usagers– Améliorations (code, conception,
performance)– Changement de l’environnement technique– Changement de l’environnement « affaires »– Modernisation
6/71
6.1. Généralités (3/8)
nCinq lois de l’évolution des programmes– 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 moins utile dans cet environnement
3
7/71
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
8/71
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 système
9/71
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 consacrées au développement des systèmes
4
10/71
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 système, l’incrément de changement dans chaque version est approximativement constant
11/71
6.1. Généralités (8/8)
nCoûts de maintenance
Partie des coûts du cycle de vie consacrés à la maintenance
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
12/71
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/71
6.2. Types de maintenance (1/3)
nDéfinitions traditionnelles– Maintenance corrective
• Réparation des erreurs découvertes pendant l’opération
– 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/71
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 système par des moyens
automatiques ou semi-automatiques en raison de sa vétusté
15/71
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/71
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/71
6.3. Modèles de maintenance (1/14)
nCycle de vie réel d’un logicielnCycle de vie de la maintenancenModèles de cycle de maintenancenChoix d’un cycle de maintenance
18/71
6.3. Modèles de maintenance (2/14)
nCycle de vie réel d’un logiciel– La maintenance est une activité récurrente
maintenance maintenance maintenance maintenance
Retrait
7
19/71
6.3. Modèles de maintenance (3/14)
nCycle de vie de la maintenance
Introduction Croissance Maturité Déclin
Support Corrections Modifications Modifications
xxxxxxxx Activité de maintenance la plus importante
20/71
6.3. Modèles de maintenance (4/14)
nModèles de cycle de maintenance– Modèle de « maintenance urgente »– Modèle de Taute– Modèle IEEE– Modèle ISO
21/71
6.3. Modèles de maintenance (5/14)
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 système modifié
8
22/71
6.3. Modèles de maintenance (6/14)
nModèles de cycle de maintenance– Modèle de Taute
(1983, 1986) DCEstimation
Planification
Programmation
Test
Documentation
Acceptation
Opération
23/71
6.3. Modèles de maintenance (7/14)
nModèles de cycle de maintenance– Modèle de Taute
• Simple• Pratique• Aspect cyclique• Planification des versions
24/71
6.3. Modèles de maintenance (8/14)
nModèles de cycle de maintenance– Modèle IEEE
(1993) DC Classification Analyse
Conception
Implantation
Tests
Acceptation
Livraison
9
25/71
6.3. Modèles de maintenance (9/14)
nModèles de cycle de maintenance– Modèle IEEE
• ???
26/71
6.3. Modèles de maintenance (10/14)
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/71
6.3. Modèles de maintenance (11/14)
nModèles de cycle de maintenance– Modèle ISO/IEC 12207
• ???
10
28/71
6.3. Modèles de maintenance (12/14)
nChoix d’un cycle de maintenance– Facteurs de décision
• Sophistication de l’organisation• Moyens financiers
29/71
6.3. Modèles de maintenance (13/14)
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/71
6.3. Modèles de maintenance (14/14)
nChoix d’un cycle de maintenance– Modèle de Taute
• Organisations de niveau 2 au moins du CMM
– Modèles IEEE et ISO• Organisations de niveau 3 au moins du CMM
11
31/71
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
32/71
6.4. Gestion de la maintenance (1/11)
n Principales fonctionsn Structures administrativesn Prédiction de la maintenancenMétriques de maintenancen Problèmes de maintenance
33/71
6.4. Gestion de la maintenance (2/11)
n Principales fonctions– Gestion–supervision– Modification du logiciel– Gestion de configuration– Formation– Liaison avec l’usager, aide à l’usager– Tests– Assurance qualité– Assistance technique
12
34/71
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)
35/71
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
36/71
6.4. Gestion de la maintenance (5/11)
n Prédiction de la maintenance– Quoi prédire
• Nombre annuel de demandes de changements• Quelles parties du système seront les plus
affectées• Coûts annuels de maintenance:
– COCOMO de base : Em = ACT × Effort
– COCOMO intermédiaire : Em = ACT × Enominal × FAACT : annual change trafficFA : facteurs d’ajustement
– COCOMO II : formule complexe prenant en compte la fraction du code qui est à changer
13
37/71
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
38/71
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 de système les plus affectées– Modules affectés par les changements,
– Nombre de fois qu’un “module” est affecté par un changement
39/71
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
14
40/71
6.4. Gestion de la maintenance (9/11)
nMétriques de maintenance– Connaître sa performance et l’améliorer
• Approche théorique : GQM• Suggestions pratiques
– Taille (déjà vu)
• Productivité– Effort consommé, répartition, moyennes
• Personnel
41/71
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
42/71
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
15
43/71
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
44/71
6.5. Maintenabilité (1/6)
nDéfinitionn Prédiction de la maintenabilitén Pratiques recommandées
45/71
6.5. Maintenabilité (2/6)
nDéfinition– La maintenabilité est la facilité avec
laquelle un logiciel peut être corrigé en cas d’erreurs, avec laquelle il peut être agrandi, modifié, pour satisfaire de nouveaux besoins
16
46/71
6.5. Maintenabilité (3/6)
nDéfinition– Rappel
• La maintenabilité est une des caractéristiques de la qualité du logiciel
– Sous facteurs de maintenabilité (IEEE)• Facilité de correction• Facilité d’expansion• Facilité de test
47/71
6.5. Maintenabilité (4/6)
n Prédiction de la maintenabilité– Hypothèse : la maintenabilité d’un
programme est reliée à sa complexité– Métriques semblant avoir un impact sur la
maintenabilité• Complexité cyclomatique ou autres• Taille• Métriques de couplage
– La valeur relative des métriques est significative
48/71
6.5. Maintenabilité (5/6)
n Pratiques recommandées– Saines pratiques de génie logiciel– Documentation– Commentaires significatifs et utiles– Définition et respect de normes (y compris
pour nommer les éléments de programmation)
– Présentation du code systématique
17
49/71
6.5. Maintenabilité (6/6)
n Pratiques recommandées– Penser aux changements potentiels lors de
la conception et de la programmation– Pratiquer la réutilisation autant que
possible– Maximiser cohésion, minimiser couplage– Penser, documenter, la traçabilité
– Liste non exhaustive !
50/71
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
51/71
6.6. Ré- ingénierie (1/17)
n Systèmes hérités (legacy systems)nDéfinitionnCatégories de ré-ingénierienConclusions
18
52/71
6.6. Ré- ingénierie (2/17)
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
53/71
6.6. Ré- ingénierie (3/17)
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.
Parfois, certaines règles d’affaires n’existent que dans le code
• Langage(s) de programmation anciens• Architecture conçue pour du matériel obsolète• Architecture (macro, micro) corrompue par les
changements successifs
54/71
6.6. Ré- ingénierie (4/17)
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
(processus changés). Systèmes plus modernes font l’essentiel du travail
– Remplacer par un système tout neuf• Considérations de coût
19
55/71
6.6. Ré- ingénierie (5/17)
n Systèmes hérités (legacy systems)– Transformer le système : ré-ingénierie
• Système toujours nécessaire• Spécifications connues de personne mais avec
des règles de fonctionnement indispensables, impossible de remplacer par un système neuf
• Devenu trop fragile pour être maintenu ou trop grandes difficultés de maintenance
56/71
6.6. Ré- ingénierie (6/17)
nDéfinition– Construire une nouvelle implantation d’un
logiciel à partir de la version existante
57/71
6.6. Ré- ingénierie (7/17)
nDéfinition– Modèle du fer à cheval (Muller, Katzman et
Wood)
Système hérité Nouveau système
Rec
onst
itut
ion
de l
’arc
hite
ctur
e(r
étro
-ingé
nier
ie)
Transformation de l’architecture Développem
ent basé sur une nouvelle architecture
Représentation niveau code
Représentation niveau fonction
Représentation niveau concept
20
58/71
6.6. Ré- ingénierie (8/17)
nCatégories de ré-ingénierie– Ré-ingénierie du code– Ré-ingénierie des données– Ré-ingénierie des fonctions– Ré-ingénierie de niveau architectural
59/71
6.6. Ré- ingénierie (9/17)
nCatégories de ré-ingénierie– Ré-ingénierie du code
• Le 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
– Possible automatiquement dans certains cas
60/71
6.6. Ré- ingénierie (10/17)
nCatégories de ré-ingénierie– Ré-ingénierie du code
• Translation du code– Justification : langage périmé, personnel compétent
introuvable, standardisation dans l’entreprise…– Conversion d’un langage de programmation à un autre
sans autre modification
– Peut être fait automatiquement ou semi-automatiquement ☺
21
61/71
6.6. Ré- ingénierie (11/17)
nCatégories de ré-ingénierie– Ré-ingénierie des données
• Justifications– Incompréhension– Mauvaise architecture
– Implantation périmée
62/71
6.6. Ré- ingénierie (12/17)
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 du schéma de la BD
» Conceptualisation des données» Existence d’outils permettant d’assister l’activité
63/71
6.6. Ré- ingénierie (13/17)
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 de l ’application
» Existence d’outils permettant d’assister l’activité
22
64/71
6.6. Ré- ingénierie (14/17)
nCatégories de ré-ingénierie– Ré-ingénierie des fonctions
• Réorganisation du logiciel : regroupement en un même module de choses 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
65/71
6.6. Ré- ingénierie (15/17)
nCatégories de ré-ingénierie– Ré-ingénierie des fonctions
• Justification– Simplification de l’architecture résultant en une
meilleure compréhension– Élimination de redondances
– Maintenance plus facile
• Aide limitée d’outils : visualisation, furetage L
66/71
6.6. Ré- ingénierie (16/17)
nCatégories de ré-ingénierie– Ré-ingénierie de niveau architectural
• Refonte de l’architecture générale du système (fonctions et –ou données)
• Justification– Conception mauvaise ou trop détériorée
– Conception périmée
– Nouveau paradigme (structuré, orienté -objet)
• Outils : traducteurs pour reconstituer l’architecture, outils de visualisation, générateurs de code ou de squelettes de code
23
67/71
6.6. Ré- ingénierie (17/17)
nConclusions– Activité de maintenance pas encore
complètement claire– Justification technique, économique,
d’affaires– Support informatique partiel, peu efficace ?– Solution de plus en plus souvent
considérée
68/71
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
69/71
6.7. Conclusion (1/3)
nMaintenance, activité la plus importante (ressources consommées) de l’informatiquen Activité mal aiméen Activité médiocrement connue
24
70/71
6.7. Conclusion (2/3)
n Espoirs d’amélioration de la maintenance– Approche objet– Maintenabilité– Ré-utilisation,– Architecture basée sur les composants
71/71
6.7. Conclusion (3/3)
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 / inconnue)
Recommended