IFT3902 : (Gestion de projet pour le) développement, (et ...

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 [email protected], 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


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


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


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


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


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


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


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



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


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


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



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


nCycle de vie réel d’un logiciel– La maintenance est une activité récurrente

maintenance maintenance maintenance maintenance

Retrait

7

19/84


nCycle de vie de la maintenance

Introduction Croissance Maturité Déclin

Support Corrections Modifications Modifications

xxxxxxxx Activité de maintenance la plus importante

20/84


nModèles de cycle de maintenance– Modèle de «maintenance urgente »– Modèle deTaute– Modèle IEEE– Modèle ISO

21/84


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


nModèles de cycle de maintenance– Modèle de Taute

(1983, 1986) DC

Estimation

Planification

Programmation

Test

Documentation

Acceptation

Opération

23/84


nModèles de cycle de maintenance– Modèle de Taute

• Simple• Pratique• Aspect cyclique• Planification des versions

24/84


nModèles de cycle de maintenance– Modèle IEEE

(1993) DC Classification Analyse

Conception

Implantation

Tests

Acceptation

Livraison

9

25/84


nModèles de cycle de maintenance– Modèle IEEE

• Proche du modèle de Taute

26/84


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


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


nChoix d’un cycle de maintenance– Facteurs de décision

• Sophistication de l’organisation• Moyens financiers

29/84


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


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


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


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


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



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


n Principales fonctions– Gestion–supervision– Modification du logiciel– Gestion de la configuration– Formation– Aide à l’usager– Assistance technique– Tests– Assurance qualité

13

37/84


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


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


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


nMétriques de maintenance– Justification

• Besoins minimaux : permettre les prédictions• Besoins ambitieux : connaître sa performance

et l’améliorer

41/84


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


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


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


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


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



47/84

6.5. Maintenabilité (1/10)

nDéfinitionn Prédiction de la maintenabilité

n Pratiques recommandées

48/84


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


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


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


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


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


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


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


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


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



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


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


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


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


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


nDéfinition– Construire une nouvelle implantation d’un

logiciel à partir de la version existante

22

64/84


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


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


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


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


nCatégories de ré-ingénierie– Ré-ingénierie des données

• Justifications– Incompréhension– Mauvaise architecture– Implantation périmée

69/84



• 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



• 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


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


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


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


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


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



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


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


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



• 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



• 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



• Translation, transformation de modèles– Sémantique

• Génération de code– Confiance– Performance– Maintenabilité

• Méthodologie Model -Driven Architecture(?)

83/84


n Améliorations– Maintenabilité– Ré-utilisation– Composants– Aspects

– Logiciels libres / à code source ouvert (?)

84/84


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)

IFT3902 : (Gestion de projet pour le) développement, (et ...

Documents

Transcript of IFT3902 : (Gestion de projet pour le) développement, (et ...