Plan du cours. IFT3902 : (Gestion de projet pour le) développement, (et la) maintenance des logiciels. Yann-Gaël Guéhéneuc

Transcription

1 IFT3902 : (Gestion de projet pour le) développement, (et la) maintenance des logiciels Yann-Gaël Guéhéneuc Professeur adjoint guehene@iro.umontreal.ca, local 2345 (Cours tiré du cours du Pr. François Lustman) Département d informatique et de recherche opérationnelle Université de Montréal Yann- Gaël Guéhéneuc 2003 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 2/84 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 3/84 1

2 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 4/ 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 5/ Généralités (3/8) Cinq lois de l évolution des programmes Les cinq lois de Lehman, /84 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) 2

3 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) 7/ 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é ) 8/ 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) 9/84 3

4 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 futurschangement et limiter la corruption du programme) 10/ Généralités (8/8) Coûts de la maintenance 100% 90% 80% 80% 70% 60% 60% 40% 20% times 0% Début années 70 Début années 80 Fin années Début 80 années times times 6 times 10 times 11/84 Conception Code Programmation Tests Utilisation 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 12/84 4

5 6.2. Types de maintenance (1/3) 13/84 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 Modifications du logiciel entraînées par des changements ou ajouts dans les besoins 6.2. Types de maintenance (2/3) Catégorie oubliée Maintenance pour améliorer les performances 14/84 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% 55% 25% corrective adaptative perfective 15/84 Données de 1990, maintenance corrective : 21%, non-corrective : 79% 5

6 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 16/ 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 Choix d un cycle de maintenance Un point de vocabulaire 17/ Modèles de maintenance (2/17) Cycle de vie réel d un logiciel La maintenance est une activité récurrente Retrait maintenance maintenance maintenance maintenance 18/84 6

7 6.3. Modèles de maintenance (3/17) Cycle de vie de la maintenance Introduction Croissance Maturité Déclin Support Corrections Modifications Modifications xxxxxxxx Activité de maintenance la plus importante 19/ Modèles de maintenance (4/17) Modèles de cycle de maintenance Modèle de «maintenance urgente» Modèle detaute Modèle IEEE Modèle ISO 20/ 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é 21/84 7

8 6.3. Modèles de maintenance (6/17) Modèles de cycle de maintenance Modèle de Taute (1983, 1986) DC Opération Estimation Planification Acceptation Documentation Programmation 22/84 Test 6.3. Modèles de maintenance (7/17) Modèles de cycle de maintenance Modèle de Taute Simple Pratique Aspect cyclique Planification des versions 23/ Modèles de maintenance (8/17) Modèles de cycle de maintenance Modèle IEEE (1993) DC Classification Analyse Livraison Conception Acceptation Implantation 24/84 Tests 8

9 6.3. Modèles de maintenance (9/17) Modèles de cycle de maintenance Modèle IEEE Proche du modèle de Taute 25/ Modèles de maintenance (10/17) Modèles de cycle de maintenance Modèle ISO/IEC (1995) Implantation processus Analyse DC Implantation DC Revue maintenance Migration 26/84 Retrait du logiciel 6.3. Modèles de maintenance (11/17) Modèles de cycle de maintenance Modèle ISO/IEC Dans le cadre plus global des processus du cycle de vie des logiciels 27/84 9

10 6.3. Modèles de maintenance (12/17) Choix d un cycle de maintenance Facteurs de décision Sophistication de l organisation Moyens financiers 28/ Modèles de maintenance (13/17) Choix 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 29/ Modèles de maintenance (14/17) Choix 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 30/84 10

11 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 31/ Modèles de maintenance (16/17) 32/84 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 Designrecovery : Recouvrement des choix de conception et architecturaux Informations sur le domaine Informations extérieurs Déduction, analyses «floues» 6.3. Modèles de maintenance (17/17) 33/84 Un 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 11

12 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 34/ Gestion de la maintenance (1/11) Principales fonctions Structures administratives Prédiction de la maintenance Métriques de maintenance Problèmes de maintenance 35/ Gestion de la maintenance (2/11) 36/84 Principales fonctions Gestion supervision Modification du logiciel Gestion de la configuration Formation Aide à l usager Assistance technique Tests Assurance qualité 12

13 6.4. Gestion de la maintenance (3/11) 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) 37/ Gestion de la maintenance (4/11) 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 38/84 Produit B Produit C Tests Gestion de configuration 6.4. Gestion de la maintenance (5/11) 39/84 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 : E m = ACT Effort COCOMO intermédiaire : E m = ACT E nominal FA ACT : annualchange traffic FA : facteurs d ajustement COCOMO II : formule complexe prenant en compte la fraction du code qui est à changer 13

14 6.4. Gestion de la maintenance (6/11) Métriques de maintenance Justification Besoins minimaux : permettre les prédictions Besoins ambitieux : connaître sa performance et l améliorer 40/ Gestion de la maintenance (7/11) Mé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é 41/ Gestion de la maintenance (8/11) Mé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 42/84 14

15 6.4. Gestion de la maintenance (9/11) Mé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 43/ Gestion de la maintenance (10/11) Mé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 44/ Gestion de la maintenance (11/11) 45/84 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

16 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 46/ Maintenabilité (1/10) Définition Prédiction de la maintenabilité Pratiques recommandées 47/ Maintenabilité (2/10) Dé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 48/84 16

17 6.5. Maintenabilité (3/10) Dé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 49/ Maintenabilité (4/10) 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 50/ Maintenabilité (5/10) 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 51/84 17

18 6.5. Maintenabilité (6/10) Pratiques recommandées : des pratiques saines du génie logiciel 52/84 Difficultés Domaine du logiciel : quoi, implantation du logiciel : comment Niveau concret (implantation), abstrait (conception, architecture) Structures formelles (implantation), informelles (compréhension humaine) 6.5. Maintenabilité (7/10) 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» 53/ Maintenabilité (8/10) 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 54/84 18

19 6.5. Maintenabilité (9/10) 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 55/ Maintenabilité (10/10) 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! 56/84 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 57/84 19

20 6.6. Ré-ingénierie (1/18) Systèmes hérités (legacy systems) Définition Catégories de ré-ingénierie Conclusions 58/ Ré-ingénierie (2/18) 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 59/ Ré-ingénierie (3/18) 60/84 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 20

21 6.6. Ré-ingénierie (4/18) 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 61/ Ré-ingénierie (5/18) 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 62/ Ré-ingénierie (6/18) Définition Construire une nouvelle implantation d un logiciel à partir de la version existante 63/84 21

22 6.6. Ré-ingénierie (7/18) 64/84 Définition Reconstitution de l architecture (rétro-ingénierie) Tiré du modèle du fer à cheval (Muller, Katzman et Wood) Système hérité Représentation niveau architecture Représentation niveau conception Représentation niveau implantation Transformation de l architecture Nouveau système Développement basé sur une nouvelle architecture 6.6. Ré-ingénierie (8/18) Caté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 65/ Ré-ingénierie (9/18) Catégories de ré-ingénierie Ré-ingénierie du code Cas le plus fréquent de ré-ingénierie 66/84 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 22

23 6.6. Ré-ingénierie (10/18) 67/84 Caté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 semiautomatiquement 6.6. Ré-ingénierie (11/18) Catégories de ré-ingénierie Ré-ingénierie des données Justifications Incompréhension Mauvaise architecture Implantation périmée 68/ Ré-ingénierie (12/18) Caté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é 69/84 23

24 6.6. Ré-ingénierie (13/18) Caté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é 70/ Ré-ingénierie (14/18) Caté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 71/ Ré-ingénierie (15/18) 72/84 Caté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 Visualisation Métrique de cohésion, couplage Furetage 24

25 6.6. Ré-ingénierie (16/18) Caté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) 73/ Ré-ingénierie (17/18) Caté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) 74/ Ré-ingénierie (18/18) Conclusions 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 75/84 25

26 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 76/ Conclusion (1/8) Maintenance Activité la plus importante en ressources consommées de l informatique Activité mal aimée Activité médiocrement connue 77/ Conclusion (2/8) 78/84 Dé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 26

27 6.7. Conclusion (3/8) 79/84 Défis de la maintenance Techniques Rétro-conception Idiomes de programmation» Relation entre classes Diagrammes» Classes» Séquences» Patrons de conception Patrons d architecture 6.7. Conclusion (4/8) Dé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! 80/ Conclusion (5/8) 81/84 Défis de la maintenance Techniques Analyses des programmes Analyse ou description Modèles globaux ou locaux Simulation oucontrôle Vérification ou réfutation Style déclaratif ou opérationnel Statique ou dynamique Correct ou incorrect Rapide ouprécise 27

28 6.7. Conclusion (6/8) Dé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(?) 82/ Conclusion (7/8) Améliorations Maintenabilité Ré-utilisation Composants Aspects Logiciels libres / à code source ouvert (?) 83/ Conclusion (8/8) 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) 84/84 28