Génie Logiciel. Ecole d Ingénieurs de l Etat de Vaud - 15 septembre 2006 Eric Lefrançois

Transcription

1 Génie Logiciel Ecole d Ingénieurs de l Etat de Vaud - 15 septembre 2006 Eric Lefrançois

2 ELS - 7 décembre Entete.fm

3 Génie logiciel - i - Contenu 1 EN PRÉLIMINAIRE LES OBJECTIFS DU COURS PRINCIPALES RÉFÉRENCES BIBLIOGRAPHIQUES 2 2 LA PROBLÉMATIQUE 5 Les petits logiciels 6 Les gros logiciels 7 Quelques définitions clés LA CRISE DU LOGICIEL DES ANNÉES 70 9 Panique à bord du bateau logiciel 10 Car le logiciel est une tâche complexe.. 10 Car l évolution est trop rapide.. 11 Car au delà des mythes, la réalité.. 11 Naissance du génie logiciel 13 Définition du génie logiciel LES QUALITÉS REQUISES D UN LOGICIEL 14 Qualités externes significatives 15 Correction 15 Fiabilité 15 Robustesse 15 Performance 15 Ergonomie 15 Qualités internes significatives 16 Qualités du processus de développement AUTOPSIE DE QUELQUES CATASTROPHES : La perte de Mariner I (1) 17 Mars Climate Orbiter ($125M) 17 Autres échecs retentissants 18 3 MODÉLISATION LA MODÉLISATION D UN SYSTÈME INFORMATIQUE DE L IMPORTANCE DE LA MODÉLISATION 21 Les systèmes orientés données 21 Les systèmes orientés traitements 21

4 Génie logiciel - ii - Les systèmes orientés comportement 21 Les principales approches 22 Approche traditionnelle 22 Approche Base de données 22 Approche orientée objet 23 Petit historique des modèles utilisés 23 Systèmes orientés données 23 Systèmes orientés traitements 24 Systèmes orientés comportement 24 Modélisation Orientée Objet 24 4 CYCLES DE VIE ET MÉTHODE UP LES DIFFÉRENTES PHASES DU CYCLE DE VIE: ANALYSE ET CONCEPTION LE CYCLE DE VIE EN CASCADE (WATERFALL) LE CYCLE EN V ET LE MODÈLE EN SPIRALE LE MODÈLE INCRÉMENTAL ITÉRATIF MISE EN OEUVRE: LA MÉTHODE UP (PROCESSUS UNIFIÉ) APPROCHE ORIENTÉE OBJET 33 Analyse orientée objet 33 Conception orientée objet 33 Un exemple: le jeu de dés 34 Définition des cas d utilisation 34 Modélisation du domaine 35 Définition des diagrammes d interaction 35 Définition des diagrammes de classe de conception 36 Quelques mots sur UML CYCLE DE VIE DE LA MÉTHODE UP 38 Initialisation (Inception) 39 Elaboration 39 Construction 39 Transition 40 Terminologie UP: disciplines, activités & artefacts 40 Disciplines et phases UP 40 5 PHASE D INITIALISATION LES PRODUITS GÉNÉRÉS PAR LA PHASE D INITIALISATION A ÉVITER PENDANT LA PHASE D INITIALISATION 46 6 PHASE D ÉLABORATION ET ANALYSE DES BESOINS 47 Besoins fonctionnels et non-fonctionnels 49 Les difficultés rencontrées lors de la spécification 51 Quelques techniques utilisées lors de la spécification 52 Spécification formelle et informelle 52 Spécification semi-formelle et UML 53 7 MODÈLE DES CAS D UTILISATION SA PLACE DANS LA MÉTHODE UP 56 Un développement guidé par les cas d utilisation 56 Quand doit-on rédiger des cas d utilisation? 56

5 Génie logiciel - iii QUELQUES DÉFINITIONS PRÉALABLES 57 Acteur 57 Scénario 57 Un cas d utilisation 57 Un diagramme de cas d utilisation DESCRIPTION D UN CAS D UTILISATION 59 La philosophie de la «boîte noire» 59 Rédaction d un cas d utilisation: quel niveau de détail? 59 Description détaillée d un cas d utilisation 60 La préface 61 La liste des parties prenantes et des intérêts 61 Préconditions et postconditions 61 Le scénario principal (succès) 62 Extensions: les scénarios alternatifs 62 Spécifications particulières 63 Présentation: la variante «Rebecca Wirfs-Brock» DÉFINIR LE MODÈLE DES CAS D UTILISATION, DÉMARCHE GÉNÉRALE 65 En préliminaire: qu est-ce qu un bon cas d utilisation? 66 Cas d utilisation de base et sous-cas d utilisation 66 La stratégie de l analyste 67 La démarche 69 Délimiter les frontières du système à développer 70 Un diagramme de contexte 70 Représentation des acteurs dans un diagramme de cas d utilisation 71 Identifier les acteurs principaux et les acteurs auxiliaires 72 Les acteurs principaux 73 Les acteurs auxiliaires (ou «acteurs secondaires») 73 Les acteurs externes 73 Identifier les cas d utilisation UML: RELATIONS ENTRE CAS D UTILISATION 74 Relation include 74 Relation «genéralise» 76 Représentation d un «SOIT-SOIT» 76 En dehors du «SOIT-SOIT» 76 La spécialisation s applique également aux acteurs! 77 Relation extends QUELQUES RECOMMANDATIONS 82 Rédaction des étapes 82 Oublier les interfaces utilisateurs LE NIVEAU DE DÉTAIL QUAND EST-CE QUE L ON A TERMINÉ? COMPLÉMENTS DE SPÉCIFICATIONS 85 Le Glossaire (Glossary) 85 La Vision (Vision) 85 Les spécifications supplémentaires ANNEXE: PRÉSENTATION DÉTAILLÉE DU CAS D UTILISATION «VENTE» 86 8 MODÉLISATION DE DOMAINE 93 La modélisation du monde réel 94 Qu en est-il des mondes irréels? 94 Le Modèle du domaine et la méthode UP 94

6 Génie logiciel - iv - Le Modèle du Domaine et UML CARACTÉRISTIQUES ESSENTIELLES DE LA MODÉLISATION DE DOMAINE 95 Le modèle du domaine est une abstraction 96 Le modèle du domaine est une représentations visuelle du monde réel CONSEILS HEURISTIQUE: COMMENT IDENTIFIER LES CLASSES CONCEPTUELLES 99 Analyse linguistique 99 Patterns d analyse 100 L expérience HEURISTIQUE: LISTE DES ASSOCIATIONS COURANTES ETUDE DE CAS, LE SYSTÈME POS XP & LES MÉTHODES AGILES UN PETIT HISTORIQUE QUELQUES PRINCIPES FONDAMENTAUX DU «SOFTWARE MANIFESTO» DE «Individuals and interaction over processes and tools» 105 «Working software over comprehensive documentation» 106 «Responding to change over following a plan» MÉTHODES AGILES: PRINCIPES CLEF SUR QUELS TYPES DE PROJETS UTILISER UNE MÉTHODE AGILE? UP EST-ELLE AGILE? 109 Principes & fondements de UP en comparaison avec XP 110 UP est piloté par les cas d utilisation 110 Itératif et incrémental 111 UP est centré sur l architecture XP (EXTREME PROGRAMMING) VALEURS DE XP 113 La communication pour une meilleure visibilité 113 La simplicité comme garantie de productivité 113 Le feedback pour réduire le risque 114 Le courage de prendre les bonnes décisions LES PRATIQUES ESSENTIELLES DE XP 114 Les 12 pratiques de XP 115 P1: Développement piloté par les tests 115 Tests de recette (tests fonctionnels) 115 Tests de recette et spécifications XP 116 Tests unitaires 116 Références 116 P2: Le «Planning game» - Planification itérative 117 User stories (scénarios) 118 Stricte répartition des tâches 118 Un jeu en 3 phases 119 Stand-up meetings 120 Vélocité, contrôle de l efficacité et suivi du projet 120 P3: Client sur le site 121 P4: Programmation en binôme 121 P5: Intégration continue 122

7 Génie logiciel - v - P6: Refactoring: remaniement de code 122 P7: Courtes itérations de livraison 124 P8: Conception simple 124 P9: Utiliser la métaphore 125 P10: Responsabilité collective du code 125 P11: Conventions de codage 125 P12:Rythme durable: assurer le bien-être des développeurs XP: ORGANISATION DE L ÉQUIPE DE DÉVELOPPEMENT 126 Responsabilités des rôles XP 126 Le programmeur 127 Droits du programmeur XP 127 Le client 128 Droits du client 128 Le testeur 128 Le tracker 129 Le manager 129 Le coach 129 Combinaison des rôles XP QUELQUES MÉTHODES AGILES RÉFÉRENCES SUR XP ANNEXE 1 - DIAGRAMMES DE CLASSES - UML OBJETS, ATTRIBUTS & CLASSES 131 Représentation graphique 132 Nom de la classe 133 Attributs 133 Visibilité de l attribut 133 Le type d un attribut 133 La propriété d un attribut 134 La valeur par défaut 134 Opérations 135 Visibilité d une opération 135 Liste des paramètres 135 Requêtes et modificateurs 136 Accesseurs et mutateurs 136 La propriété d une opération CONCEPT D'ASSOCIATION 136 Représentation graphique 137 Rôle des objets 137 Multiplicité d'une association 138 Convention pour le nom d'une association 139 Navigabilité des associations 139 Propriétés des associations 141 Classes d association 142 Arité d'une association 142 Associations ternaires 143 Multiplicité des associations ternaires au sens Merise et UML 144 Les relations ternaires sont rarement utilisées 147 Agrégations et compositions 149 Retour sur la notion d attribut 150 Retour sur la notion d association 150 Les associations simples 150 Les associations de type composition 151

8 Génie logiciel - vi - Les agrégations 152 Hiérarchie Attribut > Composition > Agrégation > Association simple GÉNÉRALISATION - SPÉCIALISATION 154 Représentation symbolique de la relation GEN-SPEC 155 Un petit rappel: les notions de type 156 La spécialisation et son principe, types et soustypes 156 La règle de substitution 157 GEN-SPEC et héritage 158 Représentation des classes abstraites LES CONTRAINTES ANNEXE 2 - DIAGRAMMES D ACTIVITÉS NOTATION DE BASE PARTITION - COULOIRS D ACTIVITÉS SIGNAUX ANNEXE 3 - DIAGRAMMES DE SÉQUENCE NOTATION DE BASE POUR DÉCRIRE UN SCÉNARIO OBJETS ACTIFS ET OBJETS PASSIFS OBJETS TEMPORAIRES MESSAGES SYNCHRONES ET ASYNCHRONES CONDITIONS ET ITÉRATIONS ANNEXE 4 - MVC & MODÈLE OBSERVATEUR EN PRÉLIMINAIRE: LES MODÈLES DE CONCEPTION LE MODÈLE MVC 180 Le «M» comme «Modèle» 183 Le «V» comme «Vue» 183 Couplage Vue-Modèle: Le modèle «Observateur» 185 Le principe de séparation Modèle-Vue 185 Principe du modèle Observateur 186 Diagramme de classes 188 L interface Observateur 188 La classe Observable 189 Diagramme de séquence 189 «C» comme contrôleur LE MODÈLE OBSERVATEUR 190 API Java et le modèle Observateur 190 API Observer 191 API Observable 191 Le modèles des listeners MVC ET LE PATTERN «COUCHES» 192

9 Support de cours En préliminaire 1 En préliminaire 1.1 LES OBJECTIFS DU COURS Les objectifs du cours sont principalement les suivants: Acquérir la capacité de créer des logiciels correctement conçus, robustes et maintenables en utilisant des technologies objets avec des langages tels que C#, Java, C++, etc. Introduire l étudiant à l analyse et à la conception objet, en basant le discours sur la notation UML, les modèles de conception (patterns) et le processus unifié (UP - Unified Process). L accent sera placé sur l apprentissage des concepts fondamentaux. Cela va donc bien au delà d un simple apprentissage du langage UML, qui n est après tout qu une simple notation. En particulier: Du point de vue de analyse: acquérir les connaissances permettant de mener à bien l étape d analyse des besoins avec la spécification des cas d utilisation. Du point de vue de conception: connaître et savoir appliquer des modèles de conception (design patterns) qui aideront à établir quelles responsabilités confier à

10 Support de cours En préliminaire tel ou tel objet, à établir de quelle manière les objets vont intéragir. Du point de vue de méthode: introduire l étudiant à une méthode, une marche à suivre, pouvant être mise en oeuvre par une équipe de développeurs dans le cadre de la réalisation d un logiciel. Il s agira notamment de la méthode dite processus unifié (UP - Unified Process), l archétype de la démarche incrémentale itérative. Bien que cette méthode ne soit pas la panacée et soit bien loin d être reconnue comme «la méthode», - d autres approches seront présentées comme les méthodes dites «agiles» dont la plus fameuse: XP (extrême Programming) -, elle constitue une référence et un cadre intéressant pour introduire les concepts fondamentaux qui - une fois maîtrisés - peuvent être appliqués dans d autres démarches. Remarquons que le fait d être passé maître dans la manipulation d un marteau ne fait pas de nous un bon architecte: la connaissance et la pratique d un langage de programmation ne suffit pas.. En bref, les objectifs du cours peuvent être résumés comme suit: appliquer des principes et des modèles de conception pour créer de meilleures conceptions objet mener à bien un certain nombre d activités fondamentales comme l analyse et la conception, dans le cadre d une démarche basée sur le processus unifié, pris à titre d exemple. mettre en oeuvre les diagrammes de modélisation les plus courants en utilisant la notation UML 1.2 PRINCIPALES RÉFÉRENCES BIBLIOGRAPHIQUES Ce cours s appuie sur des ouvrages consacrés au Génie Logiciel ou encore à UML. Citons la source principale pour laquelle nous exprimons toute notre reconnaissance Craig Larman «Applying UML and patterns» - Second edition - Prentice Hall nd Edition - Une version française existe depuis peu. Mais aussi: R. Martin; Agile Software Development, Principles, Patterns, and Practices. Prentice Hall 2002 A. Cockburn; Writing Effective Use Cases. Addison Wesley, 2000 (ISBN: ). M. Fowler and K. Scott; UML Distilled: A Brief Guide to the Standard Object Modeling Language. Addison Wesley 2002, 2nd Edition. I. Jacobson, G. Booch, and J. Rumbaugh; Unified Software Development Pro-

11 Support de cours En préliminaire cess. Addison Wesley 1999 Ce cours s appuie également sur d autres cours données dans diverses écoles d ingénieurs: Cours Génie Logiciel - Pierre Melier - HES-EIVD. Cours Génie Logiciel - Michel Vinckenbosch - HES-EIG Cours Génie Logiciel - Ecole Polytechnique de Montreal

12 Support de cours En préliminaire

13 Support de cours La problématique 2 La problématique Quelques devinettes.. Pour vous mettre sur la voie, voici une première série de devinettes. Y a-t-il une différence entre: Construire une cabane au fond du jardin; Construire le bâtiment de l EIVD? Quel projet coûte le plus cher? Quel projet est le plus long à réaliser? Quel projet nécessite le plus de personnes pour sa réalisation? Dans quel projet la phase de construction est-elle proportionnellement la plus longue (par rapport à la durée complète du projet)?

14 Support de cours La problématique Une deuxième série.. Le bâtiment de l EIVD a été construit aux environs de À cette époque, il correspondait aux besoins de l école. Peut-on dire que ce bâtiment correspond encore à nos besoins d aujourd hui? Le bâtiment n est pas modulaire; Les normes de l époque ne conviennent plus. La taille des bâtiments a une grande importance sur leur réalisation. Est-ce la même chose en informatique? Cette petite introduction nous a permis de mettre en évidence l importance considérable que peut prendre la taille même du logiciel à développer. Aussi, nous allons examiner de plus près ce qui distingue un «petit logiciel» d un «gros logiciel».. Les petits logiciels Le cahier des charges est petit, facile à comprendre et même parfois transmis oralement. La conception du programme se fait souvent mentalement sans documentation. Le coût du logiciel est faible ou négligeable. Le choix des technologies (système d exploitation, environnement de développement, choix des machines, etc. ) est opéré par le développeur. Le développement est réalisé personne et dure peu de temps, parfois quelques semaines, au plus quelques mois, d ailleurs aucune estimation préalable du temps de développement n est faite le cas échéant. Le logiciel est rarement documenté, son usage est facile. Le logiciel sera déployé une ou deux fois, par le développeur lui-même. La maintenance du logiciel cesse de facto lorsque le développeur cesse de le supporter (départ de la société, changement d affectation, etc.). Cela entraîne souvent la mort du logiciel. Toutes les conditions pour le succès du développement sont donc réunies!

15 Support de cours La problématique Les gros logiciels Le cahier des charges est volumineux. Il est même parfois: difficile à comprendre; mal écrit, le client n a pas une idée très claire du résultat final, il y manque beaucoup d informations; écrit par des personnes qui ne connaissent pas grand chose à l informatique. En général les développeurs ne connaissent pas ou peu le métier où s applique le logiciel. La conception du programme est un vrai casse-tête, pleine d embûches, à cause des incertitudes sur le cahier des charges et de la taille du programme à réaliser. Le coût du logiciel est énorme. Le choix des technologies est périlleux: il faut tenir compte des besoins du client; la durée de vie des technologies doit être plus grande que la durée de vie du logiciel; le choix des technologies peut entraîner des débats passionnés, source de conflits. Le développement se fait par une équipe, parfois assez grande, il peut durer des années. Une estimation préalable du temps de développement est importante pour pouvoir estimer les coûts du logiciel. L équipe de développement devrait pouvoir respecter les délais de développements estimés, c est un défi. Le logiciel doit être parfaitement documenté. Cette documentation doit être livrée en même temps que le logiciel, il faut donc développer simultanément le logiciel et sa documentation. Le logiciel n est pas déployé par l équipe de développement: il est peut-être livré sur CD et diffusé en grand nombre; il est peut-être livré à très petite échelle, mais son installation est compliquée. Des personnes spécialement formées sont chargées du déploiement. La maintenance du logiciel est gérée par un contrat, renouvelé souvent d année en année. Le logiciel doit survivre à l équipe de développement Toutes les conditions pour l échec du développement sont réunies.

16 Support de cours La problématique Posez-vous seulement la question. Dans quelle catégorie vous situez-vous lorsque vous développez un projet informatique: dans le cadre scolaire? dans le cadre professionnel? Maintenant, un petit exercice.. Combien coûte une ligne de code, sachant que: un bon développeur coûte Frs par année à son entreprise tout frais compris; il code en moyenne 20 lignes par jour; il est absent en moyenne 1/5 du temps (vacances, armée, maladie, etc.); il y a environ 250 jours ouvrables par année; Quelques définitions clés Voici quelques définitions clés du génie logiciel, sur lesquelles nous reviendrons, mais qu il est nécessaire d appréhender dors et déjà afin de lire plus aisément ce qui va suivre dans le cadre de cette introduction sur le génie logiciel. Spécification Activité consistant à décrire formellement ou semi-formellement le fonctionnement d un système. On doit répondre aux questions: que doit faire le système?, pourquoi? Conception Activité consistant à réfléchir, modéliser et décider comment le système va être implémenté. On doit répondre à la question: comment réaliser le système? Implémentation Activité consistant à coder le système Test Activité consistant à exécuter le système ou ses parties pour vérifier qu il fonctionne correctement ou pour découvrir ses anomalies Maintenance Le logiciel est en service chez le client. Cette activité comprend la correction d erreurs détectées par le client, mais aussi et surtout l ajout de nouvelles fonctionnalités ou encore l adaptation, la modification de fonctionnalités existentes.

17 Support de cours La problématique 2.1 LA CRISE DU LOGICIEL DES ANNÉES 70 Avec l accroissement de la complexité des logiciels (notamment de leur taille), le développement ne suit pas: il faudra 10 ans pour développer l OS 360 des IBM 360 Figure 1: Rapport du Congrès Américain en 1979 sur 487 projets Sources: US Gov. Accounting Report, (in B. Cox, OO Prog.) 19% Livré mais pas utilisé 29% 47% Abandonné ou repris Payé mais pas livré Utilisé après correction Utilisé tel que livré 2% 3% Figure 2: Un rapport américain de Standish Group International Projet non terminé 30% Projet terminé 70% Les projets analysés ont tous utilisé le modèle en cascade (waterfall) que l on présentera un peu plus loin dans le cours. 53% des projets ont dépassé le budget prévu initialement de 200%! Environ $81 milliards dépensés pour des projets abandonnés aux USA en 1995

18 Support de cours La problématique Panique à bord du bateau logiciel les logiciels réalisés ne correspondent souvent pas aux besoins des utilisateurs; les logiciels contiennent trop d'erreurs (qualité du logiciel insuffisante); les coûts du développement sont rarement prévisibles et sont généralement prohibitifs; la maintenance des logiciels est une tâche complexe et coûteuse; les délais de réalisation sont généralement dépassés; les logiciels sont rarement portables; les changements de besoin du client sont difficiles à intégrer dans le développement; la performance du système est souvent inacceptable; le système est difficilement réutilisable pour de futurs développements (ce qui permettrait de répartir les coûts de développement sur plusieurs projets) Et pourquoi donc? Car le logiciel est une tâche complexe.. Reconnaissons tout d abord que ça n est pas une tâche facile.. Une quantité de facteurs influent de manière négative. Taille et complexité du système à informatiser. Complexité attachée à l'environnement du système. Complexité de communication entre les futurs utilisateurs (diversité des points de vue) Complexité de communication entre les futurs utilisateurs d'une part et les développeurs d'autre part (vocabulaire technique et non-technique)

19 Support de cours La problématique Car l évolution est trop rapide.. Figure 3: Evolution du matériel et du logiciel Systèmes personnels Orienté-Objet Traitement par lots Distribution limitée Logiciel personnalisé Multi-utilisateurs Temps-réel Bases de données 2ème époque Systèmes distribués Systèmes embarqués Le coût du matériel baisse Les usagers deviennent exigents 3ème époque Systèmes experts Réseaux neuronnaux Calcul parallèle Internet 4ème époque 1ère époque Figure 4: Evolution des langages et des outils Outils CASE pour le développement intégré Epoque héroïque 0/1 (code machine) Assembleur Premiers langages évolués avec compilateurs Fortran, Cobol Puis structurés C, Pascal, Modula-2 Ada Langages orientés objet Smalltalk, C++ Java 3ème génération Normes de conception UML, CORBA Frameworks de développement WEB (Struts, Cocoon, EJB,..) Persistance (Hibernatus) 4ème génération 2ème génération 1ère génération Car au delà des mythes, la réalité.. Les mythes du côté usager Un énoncé général des objectifs est suffisant. On verra pour les détails plus tard!

20 Support de cours La problématique La réalité: Une définition insuffisante des besoins des usagers est une cause majeure de production d un logiciel de mauvaise qualité Les besoins du projet changent, mais on incorporera les modifications facilement parce que le logiciel est flexible! La réalité: Les coûts pour un changement du logiciel augmentent de manière dramatique dans les dernières phases du développement. Coût Figure 5: Le coût du changement X 1.5-6X 1X Définition Développement Maintenance Les mythes du côté développeur Une fois que le programme est écrit et qu il fonctionne, le travail du développeur est terminé! La réalité: 50% à 70% de l effort consacré à un programme se produit après la livraison à l usager. Tant qu un programme ne fonctionne pas, il n y a pas moyen d en mesurer la qualité! La réalité: les revues de logiciel peuvent être plus efficaces pour détecter les erreurs que les jeux de tests.

21 Support de cours La problématique Le succès d un projet tient essentiellement de la livraison d un programme fonctionnel! La réalité: Une configuration logicielle inclut toute la documentation, des données d entrée pour les tests, etc Les mythes du côté gestionnaire L entreprise possède des normes, le logiciel développé devrait être satisfaisant! La réalité: les standards sont-ils utilisés, appropriés et complets? Les ordinateurs et les outils logiciels que l entreprise possède sont suffisants La réalité: il faut plus que des outils pour réaliser du logiciel de qualité. Il faut aussi une bonne pratique. Si le projet prend du retard, il suffira d ajouter quelques programmeurs. La réalité: Le développement du logiciel n est pas une activité mécanique. Ajouter des programmeurs peut empirer la situation Naissance du génie logiciel 7 au 11 octobre 1968, conférence Garmish-Partenkirchen (sponsorisée par l OTAN) Le terme de «software engineering» est utilisé pour la première fois par les professeurs Bauer et Bolliet, dans un rapport de la conférence scientifique. La traduction française «génie logiciel» est plus tardive. Le langage Ada est une conséquence directe de cette crise. C est la réponse de Département de la Défense américaine à ce problème. Puis arrivent les premières méthodes: VDM (Vienna Development Method) date du début des années 70, le langage Z (Spécification formelle - Abrial) date de 1978.

22 Support de cours La problématique Définition du génie logiciel Définition 1: Le génie logiciel Discipline d ingénierie concernée par le problème pratique du développement de grands systèmes logiciels. Sommerville Ian «Le génie logiciel», Addison-Wesley France, 1992 Cette première définition met en avant la problématique liée à la taille du projet. La deuxième est un peu plus précise quant aux objectifs de cette discipline. Définition 2: Le génie logiciel Discipline pour spécifier, construire, distribuer et maintenir des logiciels, en assurant: la qualité (fiables, adaptés, conviviaux, évolutifs) des coûts contrôlés des délais garantis 2.2 LES QUALITÉS REQUISES D UN LOGICIEL La crise des années 70 nous, telle que nous l avons décrite, nous permet de préciser dans ses grandes lignes les objectifs du génie logiciel (reprise de la deuxième définition du génie logiciel). Définition 3: OBJECTIFS DU GÉNIE LOGICIEL Donner les moyens nécessaires à l équipe de développement pour que le système réalisé: respecte les coûts et les délais de développement; soit un produit de qualité. Dans cette définition, le mot-clé «qualité» - mot magique -, mérite à lui seul tout un développement.. On peut aborder le critère «qualité» selon 3 points de vue: la qualité externe (point de vue de l utilisateur) la qualité interne (point de vue du développement)

23 Support de cours La problématique la qualité du processus de développement Remarquons d emblée qu il y a une grande interdépendance entre ces trois points de vue Qualités externes significatives La correction, la fiabilité et la robustesse s adressent à l aspect fonctionnel du logiciel fourni au client. Correction Un logiciel «correct» satisfait à sa spécification (fonction attendue) de manière absolue. Fiabilité La fiabilité est une notion relative à l idée que s en fait l utilisateur même du logiciel. La fiabilité mesure le degré de confiance que l on peut avoir dans le fonctionnement du logiciel. Il marche aujourd hui, marchera-t il demain? Peut-on compter sur ce produit? Robustesse La «robustesse» dénote une aptitude à fonctionner correctement sous des conditions anormales, comme par exemple: Dans les cas non spécifiés par l'analyse des besoins: Ressource non disponible «fichier non-existant», etc. Valeur inattendue, p.ex: division par zéro, date=«29/2/2002» A l occasion de pannes du réseau ou de machines «serveur ne répond pas», etc. Le système doit alors pouvoir s adapter et continuer de fonctionner. Performance Qualité liée à l algorithmique (complexité polynomiale, exponentielle). Evaluation par mesure, analyse et simulation. Ergonomie Qualité liée à la facilité d utilisation.

24 Support de cours La problématique Se rattache principalement à l interface utilisateur mais dépend aussi de la performance et de la correction Qualités internes significatives Maintenabilité (~60% du coût) maintenance corrective: pour éliminer les erreurs maintenance adaptative: changement dans l environnement maintenance perfective: changement pour améliorer ses qualités Réparabilité Facilité avec laquelle le logiciel peut s'adapter à des corrections. Nécessite une bonne structure modulaire avec de bons interfaces, un langage adéquat. Evolutivité Facilité avec laquelle le logiciel peut s'adapter à des changements de spécification. Réutilisation A priori ou à posteriori. L idée étant de développer une étagère de composants. Portabilité Le produit est indépendant du genre d environnement Interopérabilité Capacité à intéragir avec d autres systèmes; qualité rare pour le logiciel mais courante dans d autres domaines; qualité visée par les démarches de normalisation Qualités du processus de développement Productivité et réutilisation Respect des délais Echange d informations Bonne documentation, accessible à tous

25 Support de cours La problématique 2.3 AUTOPSIE DE QUELQUES CATASTROPHES 1962: La perte de Mariner I (1) Pour quelques lignes de FORTRAN: DO 5 K = 1. 3 T(K) = W0 Z = 1.0/(X**2)*B1** E-4*B0**2 D(K) = 3.076E-2*2.0*(1.0/X*B0*B E-4* *(B0**2-X*B0*B1))/Z E(K) = H**2* *W0/SIN(W0)*Z H = D(K)-E(K) 5 CONTINUE La première ligne est fausse, elle aurait dû s écrire DO 5 K = 1, 3 Boucle avec K variant de 1 à 3 Au lieu de cela, le compilateur FORTRAN a compris DO 5K = 1.3 Boucle parcourue 1 fois avec K valant 1.3 Ainsi, la perte de Mariner est due à une erreur de programmation élémentaire. Cette erreur a mis en évidence la faiblesse de la syntaxe du langage FORTRAN Trop grande proximité entre l affectation est l instruction de boucle; Difficulté de lecture du programme. Le code fautif n avait pas été testé correctement. Mars Climate Orbiter ($125M) Le 23 septembre 1999 à 11h27, la NASA perd tout contact avec la sonde spatiale Mars Climate Orbiter. La sonde s est désintégrée dans l atmosphère de Mars en essayant de se mettre en orbite à une hauteur de 53 km au lieu des 193 km qui étaient planifiés. L origine de la panne est une erreur parfaitement stupide: Lockheed Martin Astronautics a utilisé les mesures anglo-saxonnes; Jet Propulsion Laboratory a utilisé le système métrique; Personne n a converti les données échangées (1 livre = 4.48 Newton). Erreur dans les processus de validation de la NASA Rapport de la NASA (2000) L erreur de navigation n a pas été détectée par la simulation informatique de la

26 Support de cours La problématique propulsion. L équipe opérationnelle de navigation n était pas assez informée de la manière dont la sonde était orientée dans l espace. Une dernière mise à feu des moteurs avant l arrivée de la sonde pour réorienter la sonde a été envisagée, mais pas réalisée pour diverses raisons. Le processus de validation des tâches interconnectées n était pas assez robuste à cause d un changement de stratégie de la NASA dans sa manière de réaliser les nouveaux projets. Certains canaux d information entre groupes d ingénieurs étaient trop informels. La petite équipe des missions de navigation était surchargée de demandes et n a pu être évaluée à temps par un groupe d experts. Le personnel n était pas assez entraîné à remplir les formulaires formels d anomalies. Le processus de vérification et de validation des interfaces techniques entre les groupes était inadéquat. Autres échecs retentissants En 1972, lors d'une expérience météorologique en France, 72 ballons contenant des instruments de mesure furent détruits à cause d'un défaut dans le logiciel. En 1981, le premier lancement de la navette spatiale a été retardé de deux jours à cause d'un problème logiciel. La navette a d'ailleurs été lancée sans que l'on ait localisé exactement le problème (mais les symptômes étaient bien délimités). Le développement du compilateur PL1 de Control Data n'a jamais abouti. L'explosion de la fusée Ariane 5, le 4 juin 1996, qui a coûté un demi milliard de dollars (non assuré!), est due à une faute logicielle d'un composant dont le fonctionnement n'était pas indispensable durant le vol.

27 Génie logiciel Modélisation 3 Modélisation Le développement de logiciels est une entreprise complexe. Notre mémoire à court terme étant fortement limitée, nous éprouvons le besoin naturel de modéliser pour simplifier et augmenter ainsi artificiellement notre capacité intellectuelle à résoudre les problèmes. Définition 4: les modèles Les modèles sont des abstractions de la réalité. Ce sont des représentations de la réalité qui n en gardent que l essentiel, jetant le superflu qui ne fait qu encombrer l esprit. Un modèle est une synthèse (ne garde que l essentiel); il sera donc souvent volontairement simplifié; Un modèle a toujours un objectif précis, celui de montrer un aspect particulier d un problème donné. Plusieurs modèles sont donc nécessaires pour représenter la totalité du système. Indirectement, la mise en oeuvre de modèles présente encore de nombreux avantages non dénués d intérêt: Un modèle est un outil de communication Outil de communication entre analystes, entre analystes et concepteurs, etc., un modèle peut également être utilisé pour communiquer avec les utilisateurs du sys-

28 Génie logiciel Modélisation tème (les clients), sous réserve que ces derniers soient des clients «avertis» et susceptibles de le comprendre: un prototype est souvent plus indiqué. Soulignons qu un modèle, pour être un outil valable de communication, doit alors s appuyer sur une sémantique indépendante du temps et des personnes. En d autres termes, il doit s agir d un modèle normalisé (comme peut l être UML). Un modèle est un outil de documentation La réalisation d un modèle obéissant à une norme de type UML génère par la même occasion une documentation structurée, et ceci automatiquement, sans aucun effort (Ouf!). Cette documentation sera utilisée pendant la maintenance du système, voire pendant la phase de test. 3.1 LA MODÉLISATION D UN SYSTÈME INFORMATIQUE Un seul modèle ne suffira pas pour décrire tout un système informatique. Un système peut être appréhendé suivant différents points de vue et notamment: le point de vue des données et de leur structuration, le point de vue des traitements et le point de vue dynamique. Différentes approches sont donc nécessaires pour assurer la bonne compréhension d un système. Le langage UML, par exemple [Voir paragraphe - Quelques mots sur UML - page 36], prévoit ainsi plusieurs types de modèles qui permettent chacun d éclairer ou tout du moins de mettre l accent sur un certain aspect du système. Fondamentalement, on peut citer trois grands types de modèles: 1. Le modèle fonctionnel Qui indique les traitement accomplis. P.E: diagrammes de flux de données, diagrammes d activités (UML) 2. Le modèle comportemental Qui indique quand et à quelle occasion ces traitements sont accomplis. P.E: diagrammes d états et de transition (UML) 3. Le modèle des données Qui indique ce sur quoi ces traitements agissent. P.E: diagrammes de classes (UML), diagrammes ER (Entité-Relation)

29 Génie logiciel Modélisation 3.2 DE L IMPORTANCE DE LA MODÉLISATION Si l approche Objet nous semble aujourd hui naturelle, il n en a pas toujours été ainsi. Un petit retour en arrière peut être instructif à plus d un titre. D un point de vue historique, remarquons que l on distingue en général 3 types de systèmes, suivant qu ils s apparentent plutôt aux données, aux traitements ou encore à la gestion des événements. Les systèmes orientés données Ces systèmes s appuient sur des structures d information complexes et fortement dépendantes. Il peut s agir par exemple de la base de données du services des eaux de la ville de Lausanne, du service de réservation d une compagnie d aviation, etc. Les systèmes orientés traitements Ces derniers reposent essentiellement sur la mise en oeuvre de traitements complexes. Le développement de tels systèmes est une entreprise délicate en raison de la complexité des algorithmes mis en jeu. Par contre ils ne présentent pas vraiment de difficulté du stricte point de vue du Génie Logiciel. Preuve en est qu ils sont souvent l oeuvre de scientifiques dont le background informatique a été dans bien des cas «appris sur le tas» - ce qui n enlève rien à la qualité du produit -. Citons à titre d exemple les logiciels de traitement de signal, de simulation discrète (files d attente), l intelligence artificielle, etc. Les systèmes orientés comportement Ces systèmes réagissent principalement aux événements externes auxquels il doivent apporter une réponse adéquate tenant compte de l état interne du systèmes. Citons par exemple: les systèmes embarqués, les automates à états finis, les interfaces Homme-Machine, etc. Ainsi, historiquement, le monde informatique s est quelque peu cloisonné pour donner naissance à différentes approches.

30 Génie logiciel Modélisation Les principales approches A l origine, deux approches se sont développées en parallèle, adaptées chacune au monde informatique qui leur avait donné naissance. Il s agit de l approche dite «traditionnelle» ou encore «procédurale» et de l approche des bases de données. Quelque part, on peut considérer que l approche objet a réconcilié les deux mondes. Approche traditionnelle S appuie sur deux principes fondamentaux: les données font partie de l'application; il existe un lien très étroit entre les données et les applications. Quand on veut changer les données, il faut aussi changer les applications (et vice versa). L approche est essentiellement «top-down» (décomposition fonctionnelle) et s appuie sur les langages procéduraux comme Pascal ou issus de Pascal. Approche Base de données Dans le monde des bases de données, on s appuie également sur deux principes: Avoir la possibilité de modifier la structure des données sans changer les programmes de l'application. Avoir la possibilité de modifier les programmes de l'application sans changer la structure des données. Dans ce contetxe, l'indépendance des données est donc un facteur primordial! Facturation Service à l a clientèle Système de gestion de base de données Base de données Administration du système Dès que l'importance de l'indépendance des données a été reconnue, on a été amené à faire beaucoup plus attention à la conception des données (d'où l approche modélisation par les données).

31 Génie logiciel Modélisation Approche orientée objet Cette approche est venue du besoin de: Construire des modèles plus proches du monde réel. Réutiliser des fragments de logiciels. Elle s appuie sur la nouvelle génération de langages qui apparaissent à la fin des années 1970 qui permettent l'encapsulation des données et des traitements dans un objet: ADA (1979), Simula et Smalltalk (1980) puis C++. Selon cette approche, un objet peut être caractérisé par trois attributs: données, fonctions et comportement. Ca n est donc pas incompatible avec les deux approches présentées plus haut, et tous les modèles utilisés dans ces dernières sont utilisables en objet (et sont d ailleurs utilisés partiellement). Mais ça n'est pas une approche top-down - ni l inverse d ailleurs! -. Le top-down est un bon moyen de représenter des choses que l'on maîtrise bien... Mais le top-down n'est pas un bon moyen pour développer, concevoir ou découvrir. Voici quelques applications susceptibles de bénéficier de ces techniques: Domaine des grands logiciels Télécommunications Contrôle de processus industriels Traitements répartis Systèmes temps réel (à venir..) Petit historique des modèles utilisés Le modèle était très attaché au type de système à développer. Systèmes orientés données Diagrammes Entités-Relations (ER) - Chen, Palmer, Mac Donald ( ) Pour l analyse Approche «à plat» Focalisée sur les propriétés statiques des données Formes Normales (FN) - Codd Pour la conception Conception focalisée sur la non redondance des informations

32 Génie logiciel Modélisation Systèmes orientés traitements Diagrammes de Flux de Données (DFD) - De Marco, Yourdon ( ) Pour l analyse Approche «top-down» Focalisée sur les aspects fonctionnels Diagrammes de Structure - Myers, Constantine, Yourdon (1974) Pour la conception Approche «top-down» Focalisée sur les modules S appuie sur les Diagrammes de Flux de Données (DFD) Systèmes orientés comportement Concernant les systèmes orientés comportement, la conception était très fortement dépendante du langage et des outils utilisés. Diagrammes de Flux de Contrôle (DFC) - Ward-Mellor, Hatley-Pirbai (1985, 87) Une analyse focalisée sur l'aspect comportemental Modélisation Orientée Objet Technique de Modélisation Objets (OMT) - Rumbaugh (1992) Analyse et Conception Orientée Objets (OOAD) - Booch( ) Diagrammes Entités-Actions (JSD Entity-Actions) - Jackson (1983) Analyse Orientée Objets et Conception Orientée Objets (OOA/OOD) - Shlaer-Mellor ( ) Analyse Orientée Objets et Conception Orientée Objets (OOA/OOD) - Coad-Youdon (1991) Classe & Relation - Desfray (1993) UML ( version 1) UP (2001)

33 Génie logiciel Cycles de vie et méthode UP 4 Cycles de vie et méthode UP Comme nous l avons mentionné dans les préliminaires du cours, nous nous attacherons à décrire une méthode de développement particulière, basée sur la technologie Ob jet et sur UML, qui porte le nom de méthode UP (comme «Unified Process»). Cette méthode décrit essentiellement la marche à suivre à l occasion de la réalisation d un logiciel. De manière plus générale, plutôt que de parler de «marche à suivre», on parle plutôt de cycle de vi», un concept qui donne le nom de ce chapitre. La méthode UP n est pas unique en son genre, mais elle a toutefois le mérite de bien poser certains concepts clé. Nous aurons également l occasion de présenter une autre méthode concurrente mais qui s en rapproche: l extrême Programming, qui s appuie également sur la modélisation objet. A la base de la méthode UP, un concept clé: le développement itératif, une approche qui découpe le développement en une série de mini-projets que l on appelle itérations. Définition 5: Itération Chaque itération aboutit à un système exécutable et testé.

34 Génie logiciel Cycles de vie et méthode UP Chaque itération comprend sa propre phase d analyse des besoins, de conception, d implémentation et de test. Figure 6: Développement incrémental itératif Itération i-1 Itération i Itération i+1 Analyse des besoins Conception Implémentation & test Intégration & test du système Analyse des besoins Conception Implémentation & test Intégration & test du système Analyse des besoins Conception Implémentation & test Intégration & test du système Système exécutable Système exécutable Système exécutable Du point de vue strictement historique, le concept même de développement itératif incrémental est l aboutissement d un concept qui portait à l origine le nom de processus en spirale (spiral development) ou encore processus évolutif (evolutionary process). A titre d exemple, à mi-chemin du développement d un projet, une itération de deux semaines pourrait se décomposer ainsi: le lundi consacré à la clarification et à la distribution des tâches dans le groupe, pendant qu une personne effectue le reverse-enginnering de l itération précédente (génération de diagrammes UML) le mardi consacré à la conception de diagrammes UML grossiers, conçus et dessinés au tableau en travaillant en «binôme» et enregistrés au moyen d une caméra numérique, à l écriture de fragments de pseudo-code, etc. les 8 derniers jours consacrés à l implémentation et le test d unités et d intégration dans le système, mais aussi à d autres activités comme par exemple des démonstrations aux différents partenaires ou encore la planification des prochaines itérations. Le modèle du développement itératif incrémental présente de nombreux avantages. Pour les apprécier à leur juste valeur, nous allons revenir en arrière en présentant la notion de cycle de vie et les différents modèles sur lesquels le génie logiciel s est appuyé depuis les années LES DIFFÉRENTES PHASES DU CYCLE DE VIE: ANALYSE ET

35 Génie logiciel Cycles de vie et méthode UP CONCEPTION Définition 6: Cycle de vie Le cycle de vie du logiciel modélise l enchaînement des différentes activités du processus technique de développement du logiciel. Tous les modèles différencient 3 grandes activités qui vont, selon le modèle, intéragir différemment. Ce sont: 1. L analyse: comprendre le problème, les besoins 2. La conception: trouver une architecture pour résoudre le problème 3. La réalisation: mettre en oeuvre, fabriquer Ces 3 activités ne sont pas la caractéristique des développements informatiques. Par exemple, pour fabriquer un modèle mécanique du système solaire il faut: 1. analyser le problème en observant que les planètes suivent des orbites; 2. concevoir en inventant un mécanisme qui déplace des sphères sur de telles orbites; 3. puis réaliser l assemblage des sphères, ressorts et engrenages. Toute méthode - et en particulier la méthode UP - propose une démarche et des notations pour aborder ces problèmes. La démarche (le cycle de vie) décrit quelles étapes élémentaires doivent être suivies, quelles questions doivent être soulevées et à quel moment, quels sont les «objets» qui doivent être mis en évidence, etc. La notation permet de présenter et formaliser des «objets» solution aux informaticiens et aux clients; il est donc souhaitable - voire indispensable- qu une notation soit compréhensible par des non-spécialistes. Analyse et conception Revenons encore un peu sur l analyse et la conception.. Définition 7: Analyse: le «QUOI» L analyse est une activité qui s attache en premier lieu à mener une investigation sur le problème et les besoins, plutôt qu à rechercher une solution. En gros, il s agit de répondre à la question: «Qu est-ce qu on désire et comment ce sera utilisé?» Le terme «analyse» est un peu flou. On lui préfère souvent les termes «analyse des besoins» ou encore «analyse des objets» (recherche menée sur les objets du domaine).

36 Génie logiciel Cycles de vie et méthode UP Définition 8: Conception: le «COMMENT» La conception est une activité qui s attache en premier lieu à définir une solution conceptuelle susceptible de répondre aux besoins issus de l analyse plutôt qu à définir une implémentation du problème. Notamment, il s agira par exemple de définir le schéma conceptuel de la base de données et l architecture des classes (au moyen d un diagramme UML). Encore une fois, le terme «conception» manque de précision. On lui préférera souvent «conception objet» ou encore «conception de la base de données». En résumé Do the right thing (analysis), and do the thing right (conception) 4.2 LE CYCLE DE VIE EN CASCADE (WATERFALL) Ce modèle est similaire à ce qui ce fait en architecture et construction des bâtiments, il est dû à Royce (1970). Chaque étape du processus de développement doit être terminée à une date précise avant que la suivante ne puisse débuter. En principe, chaque étape doit être contrôlée et vaidée avant de passer à l étape suivante. Des remous.. On admet toutefois - le développeur n est qu un être humain avec beaucoup de faiblesses

37 Génie logiciel Cycles de vie et méthode UP -, que la réalisation d une étape oblige les développeurs à à revenir sur l étape précédente pour y apporter des corrections, ce qui peut provoquer certains remous. Chaque étape produit un résultat: il peut s agir d une documentation, de formulaires, et bien entendu de bouts de programme. Figure 7: Le cycle de vie en cascade Spécification: document le plus formalisé possible Architecture du système & Conception détaillée: modules et interactions Code du logiciel (1ère version) 1ère version livrable Livraison et installation Mises à jour ultérieures Ce modèle a le mérite d être très simple. Les développeurs se sont inspirés des autres domaines de l ingénierie; il fallait bien commencer par quelque chose de connu.. Les avantages Il présente un développement très linéaire bien que des retours en arrière soient prévus lorsque des erreurs ou des manques sont détectés. Il permet de planifier aisément le développement. Par contre Ce modèle permet difficilement de gérer les changements en cours de projets. En effet, de tels changements impliquent des retours en arrière qui peuvent aller parfois jusqu à revoir la phase de spécification. Un erreur coûtera d autant plus cher qu elle sera découverte tardivement.

38 Génie logiciel Cycles de vie et méthode UP Mais surtout Dans ce modèle, la phase d analyse des besoins a une importance primordiale! L approche est monumentale, il faut élaborer des plans complets avant de commencer à construire. Ainsi, le client ne voit le système réalisé qu à la fin pour se rendre compte un peu tard que le produit ne correspondait pas à ses besoins LE CYCLE EN V ET LE MODÈLE EN SPIRALE Figure 8: Le diagramme en V Besoins Spécification Validation Pro. Spec. Conception Intégration Soft Arch. Codage Vérification Mod. Activité Code Doc Sans entrer dans les détails, le cycle en V puis le modèle en spirale correspondent à des évolutions du modèle en cascade. Le cycle en V introduit les notions de découpage modulaire et de validation - que l on distingue très nettement de la notion de vérification -. Définition 9: Validation et Vérification (Boehm 76) Validation: Am I building the right system? Vérification: Am I building the system right? En 1988, K. Boehm propose une amélioration du modèle en cascade, dans laquelle la gestion des risques fait partie du modèle, en cherchant à minimiser les risques encourus et en les analysant régulièrement. Il s agit du modèle en spirale.

39 Génie logiciel Cycles de vie et méthode UP Définition 10: Gestion des risques Par gestion des risques, on entend placer la priorité sur l analyse et le développement des éléments dont le développement présente des risques importants, comme par exemple: le client n est pas très au clair avec sa demande, l équipe n a pas d expérience sur ce type de développement, la technologie à utiliser est inconnue et peut réserver de mauvaises surprises, etc. Le modèle en spirale implique fréquemment le client/utilisateur. Il représente le développement comme une succession de cycles en cascade, où, à chaque itération le système est analysé, conçu, réalisé et testé un peu plus qu à l itération précédente. Figure 9: Le cycle en spirale Mais, tout comme avec le modèle Waterfall et le modèle en V, le client ne voit le système réalisé qu à la fin! 4.4 LE MODÈLE INCRÉMENTAL ITÉRATIF Ce modèle, présenté en début de chapitre, constitue l aboutissement du modèle en spirale. Il est aujourd hui utilisé par les méthodes dites «agiles» ou «semi-agiles»: UP (Unified Process);

40 Génie logiciel Cycles de vie et méthode UP XP (Extreme Programming). Figure 10: Le modèle incrémental itératif Planification initiale Vision Spécification Planification Conception Implémentation Évaluation Test Déploiement A la différence du modèle en spirale Chaque incrément donne lieu à un produit fini, exécutable, testé et intégré. On cherche à garder chaque incrément à taille humaine, en limitant le temps de réalisation et en limitant le nombre de fonctionnalités implémentées. Les avantages par rapport au modèle en spirale Le client peut valider en tout temps le système, il peut influencer son développement dans le bon sens. Le système correspond mieux aux besoins du client. Expérience souhaitée.. Au départ, il faut établit une vision de haut niveau qui permet d estimer les coûts et les temps de développement, cette opération demande beaucoup d expérience. Le développement en cascade est-il enterré? Si l équippe de développement bénéficie d une grande expérience dans le domaine et si le travail ne présente par ailleurs aucun risque (comme par exemple si le client sait très bien ce qu il veut), le modèle itératif incrémental demande plus de travail que le modèle en cascade. C est ainsi que pour des raisons d efficacité, il est encore possible de partir sur un modèle en cascade. Notons par ailleurs qu il faut encore souvent convaincre le client que ce modèle de développement est meilleur que le modèle en cascade.