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)