Introduction au Génie logiciel Jean-Paul Rigault École polytechnique

Скачать презентацию Introduction au Génie logiciel Jean-Paul Rigault École polytechnique

8ed1f74242d8ae351ca0b67f45658dc3.ppt

Количество слайдов: 136

Introduction au Génie logiciel Jean-Paul Rigault École polytechnique de l’université de Nice Département de sciences informatiques Email: jpr@polytech. unice. fr 16/03/2018 11: 02 © 2005 -2006 Jean-Paul Rigault 1

Quelques histoires horrifiques Pour commencer n Une plaisanterie (? ) anonyme If the automobile industry had developed like the software industry, we would all be driving $25 cars that get 1, 000 miles per gallon. Yeah, and if cars were like software, they would crash twice a day for no reason, and when you call service, they’d tell you to reinstall the engine. n L’avis d’un expert There are no significant bugs in our released software that any significant number of users want fixed. Bill Gates, interview à l’hebdomadaire allemand Focus, n° 43, 23 octobre 1995, pages 206 -212 http: //www. cantrip. org/nobugs. html 16/03/2018 11: 02 © 2005 -2006 Jean-Paul Rigault 4

Quelques histoires horrifiques Contenu n n Le premier « bug » Quelques bugs célèbres n n n n Tests de non-régression Établissement des spécifications Tests d’intégration Langages de programmation Interface homme-machine Complexité Informatisation inutile ? Pourquoi le logiciel est-il sujet aux bugs ? 16/03/2018 11: 02 © 2005 -2006 Jean-Paul Rigault 5

Quelques histoires horrifiques Le premier « bug » n En 1947, un « calculateur programmable » Mark II de l’université de Harvard s’arrête brutalement. n n Un papillon mort avait provoqué un court-circuit Ce « bug » n’était pas de nature logicielle n Il relève en partie de la légende… 16/03/2018 11: 02 © 2005 -2006 Jean-Paul Rigault 6

Quelques bugs célèbres Tests de non-régression n (1) Lorsque l'on modifie le code, on doit effectuer deux sortes de tests n L'une pour vérifier que la modification fait effectivement ce qu'on attendait n nouvelle fonctionnalité correction d'un bug… L'autre pour vérifier que la modification n'a pas mis en péril tout ce qui marchait avant et qui doit continuer à marcher : ce sont les tests de non-régression 16/03/2018 11: 02 © 2005 -2006 Jean-Paul Rigault 7

Quelques bugs célèbres Tests de non-régression n À la suite d’une modification, les tests de nonrégression ne sont pas toujours effectués, car n on n’a pas le temps n n n La modification a été effectuée à la dernière minute Le marché, les clients font pression… on pense (on est même sûr !) que la modification est locale et sans conséquence sur le reste du système n n (2) Une preuve de nonchalance ou, pire, d’arrogance … L’une des causes de bug les plus fréquentes 16/03/2018 11: 02 © 2005 -2006 Jean-Paul Rigault 8

Quelques bugs célèbres Tests de non régression n (3) Apollo 11, premier alunissage du module lunaire (1969) n Données absurdes et alarmes logicielles intempestives lors de l’alunissage (calcul de la trajectoire) n Amstrong atterrit manuellement, sans aucune marge de sécurité 16/03/2018 11: 02 © 2005 -2006 Jean-Paul Rigault 9

Quelques bugs célèbres Tests de non régression n (4) Apollo 11, premier alunissage du module lunaire (1969) (suite) n n n Déconnexion d’un module supplémentaire non indispensable et dont le mise au point laissait à désirer. Les sorties de ce module (le sinus et le cosinus d’un angle) sont lues comme 0, ce qui provoque des messages d’alarme de mise au point, délicats à interpréter (il y avait 19 secondes pour le faire !) Modification de dernière minute Absence de test de non-régression 16/03/2018 11: 02 © 2005 -2006 Jean-Paul Rigault 10

Quelques bugs célèbres Tests de non régression n (5) Système de téléphone des USA (1991) n n n Perturbation des communications à Los Angeles, San Franciso, Washington, Baltimore… Des millions d’abonnés mécontents Trois (3 !) lignes de code modifiées sur plusieurs millions, pas la peine de tester, n’est-ce pas ? D’autant plus que la première phase de test avait duré 13 semaines et que le client n’est pas disposé à attendre une seconde fois… Absence de test de non-régression Pression du client, du marché… 16/03/2018 11: 02 © 2005 -2006 Jean-Paul Rigault 11

Quelques bugs célèbres Tests de non-régression n (6) Système de contrôle des départs, British Airways, aéroport de Londres Heathrow (2001) n n n Perturbation de l’enregistrement des passagers et de la gestion des bagages Nombreux vols annulés ou retardés, au Royaume Uni, en Europe et dans le monde entier ; retour à la normale après une semaine Fuite de mémoire catastrophique et envahissante Absence de test de non-régression Programmation de bas niveau du système 16/03/2018 11: 02 © 2005 -2006 Jean-Paul Rigault 12

Quelques bugs célèbres Tests de non-régression n (7) Premier vol d’Ariane 5 (1996) n Auto-destruction après 40 s de vol car le lanceur quitte sa trajectoire nominale n Perte du lanceur et de sa charge utile n Retard du programme n Doute sur la fiabilité d'Ariane 16/03/2018 11: 02 © 2005 -2006 Jean-Paul Rigault 13

Quelques bugs célèbres Tests de non-régression n (8) Premier vol d’Ariane 5 (1996) (suite 1) n Une erreur de conversion (overflow) 64 bits 16 bits dans un module (IRS) chargé d’estimer l’accélération et la vitesse provoque une exception Ada pour laquelle il n’est prévue aucun « handler » n Le système interprète les données de l’exception comme des données normales (aberrantes évidemment) 16/03/2018 11: 02 © 2005 -2006 Jean-Paul Rigault 14

Quelques bugs célèbres Tests de non-régression n (9) Premier vol d’Ariane 5 (1996) (suite 2) n Le module qui a levé l’exception avait tourné de manière satisfaisante pendant 10 ans sur Ariane 4 n n n On savait qu’il n’y a pas d’overflow avec Ariane 4 Mais la dynamique d’Ariane 5 est différente ! Une simple simulation aurait révélé le problème… Comble d’ironie, le module en question était inutile à cette phase du vol ! Enfin le système IRS était doublé, mais les deux calculateurs exécutaient le même programme : l’exception a donc simplement été levée deux fois ! 16/03/2018 11: 02 © 2005 -2006 Jean-Paul Rigault 15

Quelques bugs célèbres Tests de non-régression n (10) Premier vol d’Ariane 5 (1996) (suite 3) n n Absence de test de non-régression Mauvaise appréciation du rôle et des limites du logiciel Gestion de projet défectueuse Culture de programmation pas assez défensive 16/03/2018 11: 02 © 2005 -2006 Jean-Paul Rigault 16

Quelques bugs célèbres Établissement des spécifications n Les spécifications décrivent les aspects fonctionnels et non-fonctionnels du système n n n (1) Ce que le système doit faire et sous quelles contraintes Pas comment il doit le faire Activité très délicate n n Changement de formalisme Prise en compte complète des scénarios d’utilisation, des effets de l’environnement, etc. The client usually does not know what questions must be answered, and he has almost never thought of the problem up the detail necessary for specification. Fred Brooks, No Silver Bullet, Information Processing, 1986 16/03/2018 11: 02 © 2005 -2006 Jean-Paul Rigault 17

Quelques bugs célèbres Établissement des spécifications n (2) Sonde Mariner I, mission vers Vénus (1962) n Destruction commandée après 290 s n Perte de la sonde (800 M$) n Erreur lors de la transcription des équations du vol qui étaient écrites à la main : il manquait une « barre » indiquant la moyenne d’une grandeur ; le calculateur du lanceur a essayé de corriger une situation qui ne nécessitait aucune correction n Passage délicat d’un formalisme à un autre 16/03/2018 11: 02 © 2005 -2006 Jean-Paul Rigault 18

Quelques bugs célèbres Établissement des spécifications n (3) Boeing 767 d’UA en approche à Denver (1983) n n Arrêt des deux réacteurs par suite de givrage 14 minutes de vol plané Pour diminuer la consommation de carburant, le système ralentissait les moteurs au maximum ; l’avion traversait alors une tempête et il y faisait très froid, d’où le givrage Oubli des lois physiques lors des spécifications n Pas de prise en compte de la température extérieure 16/03/2018 11: 02 © 2005 -2006 Jean-Paul Rigault 19

Quelques bugs célèbres Établissement des spécifications n (4) Appareil de radio-thérapie Therac-25, USA et Canada (1986) n n L’appareil permettait deux niveaux d’irradiation, l’un faible, l’autre 100 fois plus puissant. Le second nécessitait l’interposition d’un bouclier de tungstène entre le patient et la source. Plusieurs patients furent irradiés à la puissance maximale sans bouclier Six accidents, plusieurs morts Course critique entre activités parallèles : l’opérateur commence avec la dose maximale et le bouclier, puis s’aperçoit qu’il doit en fait administrer la faible dose. Il réinitialise l’appareil, le bouclier se retire avant que la source ne réduise sa puissance. 16/03/2018 11: 02 © 2005 -2006 Jean-Paul Rigault 20

Quelques bugs célèbres Établissement des spécifications n (5) Appareil de radio-thérapie Therac-25, USA et Canada (1986) (suite) n n n Spécification d’un système parallèle Problème de réutilisation : le bug était déjà dans le code réutilisé du Therac-20, mais… Abandon des règles de sécurité usuelles n n Les précédents modèles (et en particulier le Thérac-20) disposaient d’une sécurité mécanique qui empêchait l’administration de la forte dose en absence de bouclier Bug très difficile à mettre en évidence n n Caractère aléatoire, dépendant des scénarios Les concepteurs avaient du mal à y croire 16/03/2018 11: 02 © 2005 -2006 Jean-Paul Rigault 21

Quelques bugs célèbres Établissement des spécifications n (6) Missile Patriot, guerre du Golfe (1991) n Défaut d’interception d’un missile Scud irakien n 28 morts, 100 blessés n Une erreur d’arrondi dans le calcul du temps s’accumulait, faussant la précision de l’interception n n le temps était stocké en 1/10 s pour obtenir la durée, on devait multiplier par 0. 1 malheureusement, 0. 1 ne peut être stocké exactement (calcul en virgule fixe sur 24 bits) donc erreur d’arrondi qui au bout de 100 heures est de 0. 34 s à la vitesse du Scud (1676 m/s), cela représente plus de 500 m 16/03/2018 11: 02 © 2005 -2006 Jean-Paul Rigault 22

Quelques bugs célèbres Établissement des spécifications n (7) Missile Patriot, guerre du Golfe (1991) (suite 2) n Spécification incomplète et fonctionnement hors normes n n n En temps normal, le système devait être rebooté tous les jours, mais ce mode de fonctionnement n’était qu’implicite dans le cahier des charges. Lors de l’accident, il tournait depuis 5 jours d’affilée. Le bug était connu depuis le début de la guerre et déjà corrigé chez le constructeur. Mais considérée non critique, la mise à jour n’a été déployée que trop tard (le lendemain !) 16/03/2018 11: 02 © 2005 -2006 Jean-Paul Rigault 23

Quelques bugs célèbres Établissement des spécifications n (8) Observation de la couche d’ozone (1979 -1980) n n n Les satellites de la NASA détectent des taux très bas d’ozone dans certaines régions et le logiciel considère qu’il s’agit d’erreurs La reconnaissance de la réalité de ces taux ne sera affirmée qu’en 1986, suite à des études britanniques Défaut de spécification face à un phénomène inconnu 16/03/2018 11: 02 © 2005 -2006 Jean-Paul Rigault 24

Quelques bugs célèbres Tests d’intégration n Tests unitaires n n Vérifier qu'une entité individuelle (classe, module, composant) se comporte correctement Tests d'intégration n (1) Vérifier que l'assemblage d'entités (classes, modules, composants) se comporte correctement Phase essentielle avant la recette du système Tests de non-régression (déjà mentionnés) n Vérifier qu'une modification n'a aucun effet négatif sur le fontionnement global du système 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 25

Quelques bugs célèbres Tests d’intégration Mars Climate Orbiter (1999) n Mise en orbite ratée ; écrasement sur Mars n Échec de la mission (125 M$) n La poussée de la fusée était évaluée en unités anglaises dans un module et transmise à un autre module qui attendait des unités métriques ! n Mauvaise communication entre deux contractants (Lockheed et Jet Propulsion Laboratory) n Tests d’intégration défaillants n Management défaillant © 2005 -2006 Jean-Paul Rigault 16/03/2018 11: 03 (2) n 26

Quelques bugs célèbres Tests d’intégration n (3) Mars Polar Lander (1999) n n n n Écrasement sur Mars au lieu d’un atterissage en douceur Échec de la mission (194 M$) Un module déployait les jambes pour l’atterrissage, l’autre détectait les secousses (censées marquer la fin de l’atterrissage) et coupait les moteurs. Le déploiement des pieds dans l’atmosphère martienne a secoué le vaisseau bien avant d’atteindre la surface… Mauvaise communication entre deux modules Lois physiques délaissées ? Langages de programmation inadaptés (unités et quantités physiques) Tests d’intégration défaillants Management défaillant 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 27

Quelques bugs célèbres Langages de programmation n La qualité des langages de programmation peut jouer un rôle dans l'apparition des bugs n Syntaxe (concrète) permissive n Mécanismes trop complexes, mal maitrisés n Bugs dans la chaîne de compilation n n (1) Les concepteurs de langages tentent de créer de nouveaux langages n plus sûrs n de niveau d'abstration plus élevés n sans perdre l'efficacité n en préservant la puissance d'expression Curieusement (? ), on trouve assez peu de grands bugs liés à cette dernière raison 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 28

Quelques bugs célèbres Langages de programmation n (2) Réseau de téléphone longue distance d’AT&T (1990) n n n 9 heures d’interruption de service Mauvais placement d’une instruction break en C La syntaxe concrète importe ! Défaut de test La duplication des commutateurs n’a encore servi à rien, puisque les secondaires exécutaient le même programme que les primaires 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 29

Quelques bugs célèbres Langages de programmation n (3) Sonde Mariner I, mission vers Vénus (1962) n Le bug suivant, trouvé dans le code Fortran de Mariner I, ne semble pas avoir eu de conséquence DO 5 I = 1. 5 C’est une affectation ! L’instruction correcte (une boucle pour I variant de 1 à 5) aurait du être DO 5 I = 1, 5 ou plutôt DO 5 I = 1, 5 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 30

Quelques bugs célèbres Langages de programmation n (4) Du danger de certaines syntaxes concrètes : l’exemple de C n n n Le terrible break déjà mentionné Le classique if (x = 0) … à la place de if (x == 0) … Le moins classique, mais piégeant t[i, j] = …; à la place de t[i][j] = …; Le redoutable if (x > 1, 5) … à la place de if (x > 1. 5) … etc. 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 31

Quelques bugs célèbres Langages de programmation n (5) « Buffer Overflow » (1998) n n Envoi de longs courriers provoquant le débordement d’un buffer non protégé Une des voies d’attaques des systèmes sur l’Internet Modèle de mémoire linéaire et sans contrôle des langages comme C Sérieux problème de sécurité 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 32

Quelques bugs célèbres Interface homme-machine n (1) Quelques propriétés souhaitables d'une bonne IHM n n n Présenter à l'opérateur l'information de manière claire et lisible Permettre les actions de l'opérateur de manière simple et non confuse Ne pas faire confiance à l'opérateur mais vérifier la pertinence de ses actions et ses entrées 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 33

Quelques bugs célèbres Interface homme-machine n (2) USS Vincennes, Golfe Persique (1988) n La frégate USS Vincennes abat un Airbus civil d’Iran Air en le prenant pour un avion de combat hostile n 290 morts n L’interface opérateur des radars Aegis de la frégate était complexe et confuse. Les opérateurs ont cru que l’avion était en descente vers le navire, alors qu’il montait. n Interface opérateur trop complexe n Avis des utilisateurs négligé ? n Entraînement et formation ? n Stress des opérateurs ? n n La frégate était engagée avec des unités de surface hostiles… Ce n’est pas une excuse recevable pour un système militaire ! 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 34

Quelques bugs célèbres Interface homme-machine n (3) USS Yorktown (1998) n Perte de propulsion pendant plusieurs heures n Un opérateur entre la valeur 0 dans le système de commande de la propulsion, ce qui provoque une division par 0, un dépassement de buffer, et finalement l’arrêt des machines ! n Validation des données n Couverture de test ? 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 35

Quelques bugs célèbres Complexité n (1) De nombreuses échecs informatiques sont simplement dus à la complexité du système, en général associée à des facteurs comme n n n Incompétence (totale ou partielle), arrogance… Mauvaise gestion de projet Application sans référence antérieure Volonté « pharaonique » : spécifications démentielles… Foi aveugle dans les possibilité de l’informatique etc. 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 36

Quelques bugs célèbres Complexité n (2) Informatisation du « dispatching » des ambulances à Londres (1992) n n Cartes informatisées, gestion des appels, envoi des ambulances Pertes d’appels, attentes lors des appels (jusqu’à 30 min), retards d’ambulance (jusqu’à 11 heures !), plusieurs ambulances envoyées au même endroit, fausses alarmes… Système arrêté au bout de 36 heures. Sans doute une vingtaine de morts 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 37

Quelques bugs célèbres Complexité n (3) Informatisation du « dispatching » des ambulances à Londres (1992) (suite) n Gestion de projet discutable n n Tests insuffisants et irréalistes Hypothèses irréalistes n n n Interface homme-machine médiocre n n n information quasi-parfaite de la part des appelants information parfaite du système (la carte de Londres, la liste des noms des rues étaient incomplets) Pas de possibilité de tracer les appels reçus, Pas de possibilité de vérifier que la réponse aux appels avait été adéquate Rôle et possibilités du logiciel mal appréciés 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 38

Quelques bugs célèbres Complexité n (4) Système de manipulation automatique des bagages de l’aéroport de Denver (19931995) n Système « pharaonique » n n n 4000 véhicules (telecars), 3 terminaux, plus de 30 km de circuit, 300 ordinateurs 193 M$ (12 % du coût total) Toutes les compagnies devaient être desservies 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 39

Quelques bugs célèbres Complexité n (5) Système de manipulation automatique des bagages de l’aéroport de Denver (19931995) (suite 1) n Chaos total lors des tests n n n Bagages détruits (même « mâchés » !) Crashes, collisions, détérioration des rails… Blocage des telecars par les bagages qu’ils détruisaient… 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 40

Quelques bugs célèbres Complexité n (6) Système de manipulation automatique des bagages de l’aéroport de Denver (1993 -1995) (suite 2) n n n Retard d’ouverture de l’aéroport de plus de 16 mois Le système (bien réduit) n’est utilisé que par une seule compagnie (UA), et encore uniquement pour les vols en partance. Pour les autres, on a du se rabattre sur un système plus classique A cause du retard et des solutions alternatives nécessaires, le coût total de l’aéroport est passé de 1, 7 G$ à 4, 5 G$ n n Dette de 1 M$ par jour pour Denver est l’aéroport des USA où les taxes sont les plus élevées ! Taille et complexité du projet, pas de référence préalable n Gestion de projet © 2005 -2006 Jean-Paul Rigault 16/03/2018 11: 03 n 41

Quelques bugs célèbres Informatisation inutile ? n Certains échecs informatiques sont d’autant plus cuisants que l’informatisation n’était pas vraiment indispensable n n (1) Effet de mode Mauvaise appréciation des systèmes concurrents Foi en l’informatique et ses « retombées » positives Ce syndrome s’accompagne souvent d’un des aspects suivants n n n Complexité, système « pharaonique » Mauvaise gestion Application sans référence antérieure 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 42

Quelques bugs célèbres Informatisation inutile ? n (2) Informatisation des commandes de « ferries » , état de Washington (1990) n n n Remplacement des commandes hydrauliques par des commandes informatisées Embarcadères défoncés, mise en route ou passage en marche arrière intempestifs… Retour au « vieux » système hydraulique Gestion de projet Pas de référence préalable Inutile ou prématuré 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 43

Quelques bugs célèbres Informatisation inutile ? n (3) Automatisation des usines de General Motors (19801985) n n Informatisation du transport des pièces (50 chariots téléguidés) et des 290 robots de soudure et de peinture Manque de fiabilité générale n n Les robots se démantibulent entre eux, abîment les voitures, projettent de la peinture… Le système doit très souvent être arrêté pour identifier et corriger les bugs Gestion de projet n Informatisation inutile ou prématurée n Mauvaise estimation de l'apport de l'informatisation : le but était ici de concurrencer les méthodes japonaises ! © 2005 -2006 Jean-Paul Rigault 16/03/2018 11: 03 44 n

Pourquoi le logiciel est-il sujet aux bugs ? Il n’y a pas que le logiciel… (1) n n Le Titanic (1912) n Réputé insubmersible ! n Les compartiments « étanches » n’étaient pas scellés en haut et le navire s’est couché sur le flanc… n 1500 morts environ Estonia Ferry (1994) n Mauvaise fermeture de la porte n 800 morts 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 45

Pourquoi le logiciel est-il sujet aux bugs ? Il n’y a pas que le logiciel… (2) n n Le pont de Tacoma (1940) Le clip ! (Tacoma Narrows Bridge) n Instabilité dynamique sous l’effet des rafales de vent (de l’ordre de 68 km/h) n Oscillations de torsion et résonance, suivis de rupture n Aucune victime ! Voisinage de la résidence de Ronald Reagan (1981 -1988) n Interférence entre les systèmes de défense d’Air Force One et portes de garage automatiques 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 46

Pourquoi le logiciel est-il sujet aux bugs ? La nature du logiciel (1) n Invisible, abstrait, discontinu n n Le plus souvent, c’est l’effet du logiciel qui est visible Tout logiciel est une abstraction de la réalité n n n Mais les artefacts informatiques ont leur vie propre, indépendante du réel Le logiciel ignore la continuité naturelle des phénomènes Libre des contraintes du sens commun et des lois de la physique n n Les ingénieurs logiciels ont souvent peu de connaissances de ces contraintes Exemples : optimisation des moteurs du B 767 ; British Railways, les freins à disque, le logiciel et les feuilles mortes… 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 48

Pourquoi le logiciel est-il sujet aux bugs ? La nature du logiciel (2) n Souple et donc malléable sans limite n n n Modifications permanentes du cahier des charges, des spécifications… Extensions, nouvelles fonctionnalités Modifications hasardeuses Dans la plupart des domaine de l’ingénierie, il existe des lois naturelles qui limitent l’excroissance du cahier des charges. Mais ces lois ne s’appliquent pas au logiciel. John Mc. Wha, responsable du projet Boeing 777 No! (What part of this don’t you understand? ) Affiche ( « Outil de gestion » ) du projet logiciel du B 777 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 49

Pourquoi le logiciel est-il sujet aux bugs ? La nature du logiciel (3) n La culture du logiciel n Appréciation du rôle et des limites du logiciel n n n Le logiciel ne se comporte pas comme le matériel électronique n n n Par les non-informaticiens Par les informaticiens eux-mêmes Exemple : la redondance Que penser des pitoyables annonces d’offres d’emploi pour les informaticiens ? Le problème de la formation des informaticiens 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 50

Problématique du génie logiciel Pour continuer The essence of a software entity is a construct of interlocking concepts: data sets, relationships among data items, algorithms, and invocations of functions. This essence is abstract in that such a conceptual construct is the same under many different representations. It is nonetheless highly precise and richly detailed. I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation. We still make syntax errors, to be sure; but they are fuzz compared with the conceptual errors in most systems. If this is true, building software will always be hard. There is inherently no silver bullet. Fred Brooks, No Silver Bullet, Information Processing 1986 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 53

Problématique du génie logiciel Plan n n Le génie logiciel : origine et définition Le coût des développements de logiciel Buts et moyens du génie logiciel Évaluation de la qualité du logiciel 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 54

Le génie logiciel n Terme (Software Engineering) introduit en 1968 n n n (1) Conférence de l’OTAN à Garmish Parten Kirchen La « crise du logiciel » (déjà !) Ensemble n n de méthodologies de méthodes de techniques d’outils pour produire, utiliser et maintenir du logiciel de qualité industrielle 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 55

Le génie logiciel n (2) Logiciel de qualité industrielle n Longue durée de vie n n Longue durée de développement, grandes équipes n n n Gestion des versions, maintenance Changement des spécifications « Time to market » Performances, fiabilité, sûreté élevées Interface utilisateur adéquate Prix « approprié » 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 56

Le génie logiciel n (3) Comme toute discipline d’ingénierie, le génie logiciel n’est pas purement technique n Aspect humains n n Sélection, constitution, et gestion des équipes Formation des personnels Relation avec les clients prescripteurs Aspects financiers n n n Estimation des coûts Suivi de projet Gestion budgétaire 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 57

Le coût des développements de logiciel Nature des coûts n n Peu de capitaux nécessaires Frais de personnel très élevés n n Hauts salaires Frais de formation Coûts de développement variables selon les applications Pour les systèmes à longue durée de vie, coûts de maintenance élevés 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 58

Le coût des développements de logiciel Coûts par phases de développement n D’après Boehm Pourcentage des coûts par phase Type de système Analyse et conception Implémentation Test et Intégration Régulation et contrôle 46 20 34 Aérospatiale 34 20 46 Système d’exploitation 33 17 50 Calcul scientifique 44 26 30 Gestion 44 28 28 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 59

Buts et moyens du génie logiciel Buts du génie logiciel n Augmenter la qualité du logiciel n n n Performance, fiabilité, sûreté Évolutivité, maintenabilité Augmenter la productivité des équipes de développements n n n Taille des équipes Durée de développement Coût 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 60

Buts et moyens du génie logiciel Moyens du génie logiciel n Gestion rigoureuse du processus de développement n n Aspects techniques, humains, administratifs Définition de « bonnes pratiques » (best practices) Détection des erreurs le plus tôt possible Techniques de vérification et de validation (V&V) n n (1) Vérification : « Are we building the product right? » Validation : « Are we building the right product? » Prise en compte très tôt des impératifs de V&V Utilisation de méthodes et d’outils dans toutes les phases 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 61

Buts et moyens du génie logiciel Moyens du génie logiciel n n (2) Pas de remède miracle (No Silver Bullet, Fred Brooks, 1986) Quelques pistes n n n n Meilleurs langages Meilleur personnel Meilleurs outils Prototypage, Rapid Application Development (RAD), Joint Application Development (JAD) Réutilisation Ré-ingénierie, voire retro-ingénierie Modélisation, transformation de modèle 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 62

Buts et moyens du génie logiciel Moyens du génie logiciel n (3) L’importance de la modélisation n Modéliser est habituel dans les disciplines de l’ingénierie n n Le logiciel a longtemps échappé à cela… L’apparition des techniques structurées ou de modélisation des données (années 1980), puis des méthodes orientéesobjets (années 1990), enfin d’UML (fin 1990) ont rendu à la modélisation sa juste place L’approche MDA (Model-Driven Architecture) de l’OMG tente de placer la modélisation au centre du processus C’est loin d’être encore une pratique courante partout ! n Quand on modélise, on ne code pas. Et certains pensent toujours que la seule vérité est dans le code ! 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 63

Évaluation de la qualité du logiciel n Il est difficile d’évaluer directement la qualité du logiciel lui-même n Utilisation de métriques ? n n n Au niveau analyse, conception, architecture, code ? Nombreuses métriques différentes, nombreux débats… Il semble plus atteignable d’évaluer la qualité du processus de développement de logiciel n n n Normes ISO 9000 Capability Maturity Model Integration (CMMI) La qualité (administrative, bureaucratique…) du processus n'est pas une garantie absolue de la qualité du produit 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 64

Évaluation de la qualité du logiciel Normes ISO 9000 n Normes générales et internationales de qualité n n Familles de normes (9000 à 9004) selon l’activité de l’entreprise (ou d’un de ses départements) Procédure de certification et d’accréditation Applicable aussi bien à la fabrication des boulons, des automobiles, ou même à la formation des ingénieurs ! De nature très bureaucratique ! 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 65

Évaluation de la qualité du logiciel Capability Maturity Model Integration n n Analyse de la maturité des entreprises (ou d’un de leurs départements) par rapport à l’organisation de leur processus de développement de logiciel Modèle établi par le Software Engineering Institute, université de Carnegie Mellon, Pittsburg (SEI-CMI) n Première publication en 1986 n n Spécifique au logiciel (CMM) Révisé en 2002 n Étendu à l’ingénierie des systèmes (CMMI) 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 66

Évaluation de la qualité du logiciel CMMI : niveaux de maturité Amélioration continue du processus Optimizing Quantitatively Managed Processus mesuré (instrumenté) et contrôlé Processus défini au niveau de l’organisation et proactif. Mise en place de structures de contrôle Processus défini au niveau de chaque projet et réactif. Résultats répétables. Processus imprévisible, pauvrement contrôlé et réactif. Folklore tribal. (1) Defined Managed Initial On ne peut pas sauter une marche, ni prendre l’escalier au milieu ! 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 67

Évaluation de la qualité du logiciel CMMI : niveaux de maturité n (2) Évaluation du CMMI n Enquête d’avril 2002 à août 2004, publiée en septembre 2004 n n n 424 évaluations 385 organisations 206 entreprises 1704 projets 50, 6 % des entreprises non US Résultats n n 2/3 des entreprises au niveau 2 ou 3 mais quand même 1/4 au niveau 5 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 68

Évaluation de la qualité du logiciel CMMI : niveaux de maturité n Fin 1991 n Sur près de 200 entreprises (majoritairement US) n n n © 2005 -2006 Jean-Paul Rigault 81 % au niveau 1 12 % au niveau 2 7 % au niveau 3 0 aux niveaux 4 et 5 Sur 300 projets n 16/03/2018 11: 03 (3) 5 au niveau 5 (NASA) 69

Méthodologies de développement Contenu n n n Méthode, méthodologie et cycle de vie Exemples de méthodologies D’UML au RUP Rational Unified Process (RUP) Méthodologies agiles Estimation des coûts de développement 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 71

Méthode, méthodologie et cycle de vie (1) n Méthodologie n n n Cycle de vie, Processus de développement n n Identification et enchaînement des activités et phases du processus de développement Identification des pré- et post-conditions de chaque phase Définition des procédures de gestion et de mesure Gestion des équipes, des moyens, du budget… Synonymes de méthodologie Méthode n Approche technique pour aborder une ou plusieurs phases ou activités 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 72

Méthode, méthodologie et cycle de vie (2) n Exemples de méthodes n UML : un langage de modélisation n n Z : une méthode formelle n n Activités de spécification et conception Activité de spécification Exemples de méthodologies n n Cascade (waterfall) Développement en spirale, orienté-prototype… Model-Driven Architecture (MDA) ? Unified Process (UP), e. Xtreme Programming (XP) 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 73

Méthode, méthodologie et cycle de vie Activités lors du processus (1) n Définition des besoins (Requirements) n n Expression des besoins dans le langage du client Spécifications n n Traduction des besoins dans un langage plus informatique Description du système d’un point de vue extérieur n n Ce qu’il doit faire Pas comment il le fait Spécifications fonctionnelles et non-fonctionnelles Doit rester accessible au client (contrat) 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 74

Méthode, méthodologie et cycle de vie Activités lors du processus (2) n Spécifications (suite) n Spécifications fonctionnelles n n Les fonctions/services rendus par le système Spécifications non-fonctionnelles n n n n n Utilisabilité Fiabilité (reliability) Performance Supportabilité (maintenabilité) Conditions d’implémentation, de déploiement… Interface Conditions d’exploitation Conditionnement Aspects juridiques Aspects financiers… 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 75

Méthode, méthodologie et cycle de vie Activités lors du processus (3) n Conception n Codage n n Traduction de la conception en code Test unitaires n n n Traduction des spécifications en termes d’artefacts logiciels Peut être plus ou moins détaillée Test de chaque module individuellement Généralement de la responsabilité du développeur du module Tests d’intégration n Test de la composition de plusieurs modules (sous- 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 76

Méthode, méthodologie et cycle de vie Activités lors du processus (4) n Validation n n Recette n n Test du système final par rapport aux spécifications Acceptation du système final Peut être l’objet d’une procédure formelle et parfois officielle Gestion des changements, gestion de configuration Gestion de projet n n n Orthogonale à toutes ces activités Gestion du temps, des coûts, des équipes Gestion des relations avec les clients… 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 77

Exemples de méthodologies Cycle exploratoire n n Essais-erreurs Admissible tel quel pour n du prototypage n de très petits projets n n n développés par de très petites équipes avec de très petits enjeux Esquisse de spécification Cependant, retour en force dans les processus « agiles » n mais sous une forme beaucoup plus élaborée 16/03/2018 11: 03 Utilisation (test) Codage © 2005 -2006 Jean-Paul Rigault non Satisfait ? oui Recette et distribution 78

Exemples de méthodologies Développement en cascade (waterfall) (2) Do. D 2167 a : méthodologie du département de la défense des USA (le langage de développement est Ada) 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 80

Exemples de méthodologies Développement en cascade (waterfall) (3) n Cycle en V (!) n Variante du waterfall n Distingue deux branches n n n Production de code Tests Place en regard les activités liées 16/03/2018 11: 03 Analyse des besoins Recette Validation Spécification Test Conception Codage © 2005 -2006 Jean-Paul Rigault 81

Exemples de méthodologies Développement en cascade (waterfall) (4) n n Tentative « tayloriste » du développement de logiciel n Une idée « linéaire » du développement, non conforme à la pratique réelle Processus fondé sur des documents n Risque de documents artificiels n Délai d’approbation des documents 16/03/2018 11: 03 n n Erreurs détectées tardivement n On ne voit quelque chose « tourner » qu’à la fin n Les spécifications doivent être stables et correctes Ne facilite pas n l’intégration du client n le prototypage n la réutilisation n la traçabilité… © 2005 -2006 Jean-Paul Rigault 82

Exemples de méthodologies Développement en cascade (waterfall) (5) n Cependant, le processus en cascade est souvent apprécié des managers n n Générateur de pouvoir Facile à planifier n n Mais il est moins facile de respecter le plan ! L’utilisation du processus en cascade est (maintenant) reconnu comme une des sources majeures des échecs de projets logiciels 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 83

Exemples de méthodologies Développement en cascade (waterfall) (8) n Étude de J. Johnson (2002) n Plusieurs milliers de projets n Méthodologie en cascade n Taux réel d’utilisation dans le produit final des fonctionnalités spécifiées 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 86

Exemples de méthodologies Développement en spirale n Processus itératif n n n des tests de l’analyse de risque Facilite n n Orienté prototypage Place importante n n (2) la réutilisation l’intégration du client l’évolution des spécifications À la base de tous les processus « agiles » 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 88

Exemples de méthodologies Processus modernes « orientés objets » (1) n Le paradigme objet favorise n n la réutilisation le développement incrémental (et donc itératif) n n et donc l’intégration du client et aussi la gestion des changements de spécification un développement sans solution de continuité ( « seamless » , sans couture) la modélisation (avec UML) n par réduction de la distance entre le domaine de l’application et sa représentation informatique 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 89

Exemples de méthodologies Processus modernes « orientés objets » (2) Analyse de domaine Intégration, Expression des besoins validation, Analyse OO maintenance, management, Conception OO etc. Codage et tests 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 90

Exemples de méthodologies Processus modernes « orientés objets » (3) n Analyse de domaine n n Expression des besoins n n Fournit un modèle conceptuel des objets et de leurs relations pour un domaine applicatif particulier (modèlemétier) Fournit les besoins fonctionnels et non fonctionnels d’une application particulière Analyse orientée-objets n Fournit un modèle plus détaillé des objets-métiers, de leur relations, et de leurs opérations afin de réaliser les besoins d’une application particulière 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 91

Exemples de méthodologies Processus modernes « orientés objets » (4) n Méthodologies lourdes n n n Reposent sur une modélisation importante (utilisation d’UML) Exemples : Rational Unified Process (RUP), Model-Driven Architecture (MDA) de l’OMG Méthodologies agiles Modélisation et documentation limitées et légères n Itérations courtes et « productives » n Importance des tests n Importance du rôle des individus n Exemples : Unified Process (UP), e. Xtreme Programming, Scrum © 2005 -2006 Jean-Paul Rigault 16/03/2018 11: 03 n 92

D’UML au RUP Un peu d’histoire OMG request Coad-Yourdon Shlaer-Mellor Booch (Rose) Conception, codage Fusion etc. Rumbaugh (OMT) Analyse OO, données Nombreuses méthodes Jacobson (OOSE) d’ACOO Expression des besoins (50+) 1991 1992 16/03/2018 11: 03 1994 U M L 0. 8 U M L 0. 9 OMG vote U U U M M M L L L 1. 0 1. 1 1. 2 1. 3 1. 4 UML Rational consortium 1995 1996 1997 © 2005 -2006 Jean-Paul Rigault U M L 1. 5 U M L 2. 0 OMG 1998 … 2004 93

D’UML au RUP Qu’est-ce qu’UML ? UML is a language for n Visualizing n Specifying n Constructing n Documenting the artifacts of a software-intensive system 16/03/2018 11: 03 Syntaxe et sémantique Graphique Architecture et comportement Génération de code Descriptions graphiques et textuelles On ne décrit pas l’univers tout entier… Le logiciel joue un rôle majeur © 2005 -2006 Jean-Paul Rigault 94

D’UML au RUP Qu’est-ce qu’un modèle UML ? n n n (1) Un ensemble d’éléments State Use Case State de modélisation… Diagrams Use Case Class Diagrams Use Case Diagrams State Diagrams Organisés en sous. State Use Case Diagrams Object Use Case Diagrams modèles Sequence Diagrams n selon le niveau de détail (d’abstraction) State Scenario Diagrams Component Collaboration n selon le point de vue Diagrams Model Diagrams Elements Certains de ces éléments et sous. Component Scenario Deployment Diagrams modèles sont visualisés Statechart Diagrams Activity dans des diagrammes Diagrams 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 95

D’UML au RUP Qu’est-ce qu’un modèle UML ? (2) “chose” Abstractions, objets de 1ère classe Model. Element Relation Relie les choses entre elles Diagram Visualise des choses et leurs relations 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 96

D’UML au RUP Qu’est-ce qu’un modèle UML ? Class “chose” Structure Collaboration Comportement Model. Element Relation Diagram 16/03/2018 11: 03 Interface Use Case Interaction (3) Active Class Component Node State Machine Package Organisation Note Annotation Dependency Association Generalization Realization Class Object Use Case Sequence Collaboration State-Transition Activity Component Deployment © 2005 -2006 Jean-Paul Rigault 97

D’UML au RUP Qu’est-ce qu’un modèle UML ? Diagramme de classes (4) Diagrammes statiques (Diagramme d’objets) Diagramme de cas d’utilisation Diagramme de séquence Diagrammes d’interaction Diagramme de collaboration Diagrammes dynamiques Diagramme d’états Diagrammes d’états-transitions Daigramme d’activité Diagramme de composants Diagramme de déploiement Diagrammes statiques (d’implémentation) Diagrammes d’UML 1. x 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 98

D’UML au RUP Diverses modes d’utilisation d’UML n Mode esquisse (sketch) n n n Mode plan (blue print) n n Informelle, incomplète Souvent manuelle (tableau) Diagrammes détaillés Production de documents Pro- et rétro-ingénierie Mode langage de programmation n n Spécification complète et exécutable Pas vraiment disponible actuellement ! 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 99

D’UML au RUP Diverses cibles d’utilisation d’UML n Point de vue conceptuel n n n Point de vue de spécification logicielle n n Modélisation d’entités du monde applicatif Analyse de domaine Abstraction d’entités du monde réel Composants logiciels Analyse OO Point de vue d’implémentation logicielle n n Artefacts et composants pour une technologie particulière (Java, C++, BD…) Conception OO 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 100

Rational Unified Process (RUP) n n UML se veut indépendant de toute méthodologie Cependant, il est mieux adapté à un processus (tel le RUP) n n dirigé par les cas d’utilisation (use-case driven) centré sur l’architecture (architecture centric) itératif et incrémental Le RUP propose en outre n n des techniques de modélisation pour les différentes phases et activités une organisation des rôles et des flots lors du processus de développement 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 101

Rational Unified Process (RUP) Itératif et incrémental n (1) Quatre phases majeures temps Inception Élaboration Construction Transition Quoi ? Pour qui ? Combien ? Étude de marché Opportunité économique Analyse des besoins Modélisation du domaine Développement du produit Gestion des changements Transfert vers les utilisateurs 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 102

Rational Unified Process (RUP) Itératif et incrémental n (2) Chaque phase est composée d’itérations, chaque itération se concluant par un produit ou un prototype Inception Itération préliminaire Itération d'architecture Itération de développement Itération de transition 16/03/2018 11: 03 Maquette Prototype d'architecture Élaboration Prototype d'architecture Prototype de développement Construction Prototype de développement Version bêta Transition Distribution © 2005 -2006 Jean-Paul Rigault 103

Rational Unified Process (RUP) Centré sur l'architecture 4 + 1 vues d'architecture Vue de conception Vocabulaire du système et/ou de sa solution Besoins fonctionnels Threads et processus Concurrence et synchronisation Vue de processus 16/03/2018 11: 03 Vue d’implémentation Composants, fichiers, versions… Gestion de configuration Vue des cas d’utilisation Services pour les utilisateurs Support hardware Distribution, installation Vue de déploiement © 2005 -2006 Jean-Paul Rigault 105

Rational Unified Process (RUP) Dirigé par les cas d'utilisation n Base du développement tout entier n n n (1) Analyse des besoins Identification des classes Implémentation des classes Vérification/tests : les UC sont des cas de test Aide à la rédaction du manuel utilisateur Éléments de configuration du produit final n Délivrance d'un système limité à certains cas 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 106

Rational Unified Process (RUP) Dirigé par les cas d'utilisation Analyse Conception et codage (2) Test Cas d’utilisation Capturer, définir clarifier les cas d’utilisation 16/03/2018 11: 03 Réaliser les cas d’utilisation © 2005 -2006 Jean-Paul Rigault Vérifier les cas d’utilisation 107

Rational Unified Process (RUP) Dirigé par les cas d'utilisation Use Case Model specified by Analysis Model realized by Design Model (3) implemented by distributed by Deployment Model verified by Implementation Model Test Model 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 108

Rational Unified Process (RUP) Dirigé par les cas d'utilisation (4) Besoins Questions/réponses Client n n n Accord sur le modèle de cas Modélisation par cas d'utilisation Les cas d'utilisation font partie du contrat Le client est impliqué très tôt Garantie de prise en compte des besoins fonctionnels n Éviter la « dérive architecturale » 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 109

Méthodologies agiles n Motivation n n n Lutter contre la lourdeur improductive des processus de type waterfall Définir un processus plus adapté à l’approche par objets Intégrer le client dans la boucle de développement Éviter la modélisation lourde et envahissante Redonner de l’intérêt et de la « noblesse » au métier de programmeur Mouvement très militant (secte ? ) Économiquement très rentable (formations…) 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 114

Méthodologies agiles The Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 115

Méthodologies agiles The Agile Manifesto : principes agiles n n n Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 16/03/2018 11: 03 n n n Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. © 2005 -2006 Jean-Paul Rigault 116

Méthodologies agiles Agile Unified Process (UP) n n Déclinaison agile du RUP Reprend les caractéristiques du RUP n n (1) 4 phases, deux dimensions Dirigé par les cas d’utilisation Itératif, incrémental et évolutif Caractéristiques agiles n n Pas de plan détaillé du processus complet La spécification et la conception ne sont pas terminées avant l’implémentation Modélisation légère Incompatibilité totale avec un processus waterfall 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 117

Méthodologies agiles Agile Unified Process (UP) n (2) Propriétés des itérations n n Itérations courtes (1 à 4 semaines) fixées à l’avance Pas de glissement de dates n n n On retire des fonctionnalités si nécessaire Chaque itération produit non pas un prototype mais un sous -ensemble du produit final exécutable, testé, intégré Chaque itération comporte analyse des besoins, analyse et conception OO et tests 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 118

Méthodologies agiles Agile Unified Process (UP) n (3) Utilisation d’UML n UML est utilisé en mode esquisse n n n Tableau blanc, vidéo-projecteur Le but n’est pas de produire de la documentation mais d’améliorer la communication et la compréhension Notation « suffisamment bonne » mais pas rigoureuse Utilisation limitée aux cas qui en tirent avantage Modélisation en duo ou trio 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 119

Méthodologies agiles Agile Unified Process (UP) n (4) Autres « bonnes pratiques » n n n Traitement des questions très importantes ou très critiques dans les premières itérations Implication permanente des utilisateurs (évaluation, définition) Construction d’un noyau architectural cohérent dès les premières itérations Contrôle de qualité continuel (tests précoces, fréquents, réalistes) Gestion rigoureuse des spécifications Gestion des changement et gestion de configuration 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 120

Méthodologies agiles Agile Unified Process (UP) n (5) Contenu typique des quatre phases Inception Élaboration Construction Transition Finalité Opportunité Estimations Implémentation itérative du noyau à haut risque et/ou à haute valeur (10 -20% des UC) Implémentation itérative du reste des fonctionnalités b-tests, déploiement 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 121

Méthodologies agiles Agile Unified Process (UP) n (6) Disciplines de UP n n n n Modélisation métier Analyse des besoins (cas d’utilisation) Conception et implémentation OO Tests Déploiement Gestion de configuration et de changement Gestion de projet Gestion de l’environnement (choix d’outils, personnalisation de l’environnement…) 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 122

Méthodologies agiles Extreme Programming (XP) n Un processus très orienté vers les programmeurs n n n Développement par itérations courtes Tests (de non régression) systématiques Utilisation légère d'UML, conception simple Intégration continue Modification continue et structurée du code (refactoring) Propriété collective du code (collective ownership) n n Tout le source est modifiable par qui veut D’où l’importance des tests continuels ! Normes de codage strictes Programmation à deux (pair programming)… 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 123

Méthodologies agiles Scrum n n n Processus de management agile Peut se plaquer sur une processus technique agile (par exemple XP) Planification adaptative n Priorités modifiables n Gestion des changements Itérations courtes et productives (sprint) Réunion quotidienne n 15 minutes n debout ! 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 124

Estimation des coûts de développement Modèle cocomo ii n (1) Estimation du coût en hommes mois à partir de la taille du projet H S A mi wi 16/03/2018 11: 03 résultat (hommesxmois) taille du projet une constante facteurs multiplicatifs facteurs d’échelle © 2005 -2006 Jean-Paul Rigault 125

Estimation des coûts de développement Modèle cocomo ii n Estimation de la taille S n Kloc : kilo-lignes de code n n Évaluation selon modèle du SEI corrigé « Points de fonctions » n n Mesure des fonctionnalités de traitement de l’information associée aux entrées-sorties et aux fichiers utilisés Disponible assez tôt dans le développement 16/03/2018 11: 03 n (2) Facteurs d’échelle wi (5) n Expérience avec ce type de projet n Souplesse du développement n Résolution de risques (architecture) n Cohésion de l’équipe n Maturité du processus (CMMI) © 2005 -2006 Jean-Paul Rigault 126

Estimation des coûts de développement Modèle cocomo ii n Facteurs multiplicatifs mi (17) n Facteurs liés au produit n n n n n Facteurs liés à la plateforme n n n Contraintes de temps d’exécution Contraintes de mémoire Volatilité de la plate-forme 16/03/2018 11: 03 Facteurs liés au personnel n Fiabilité requise Taille de la Base de données Complexité Réutilisabilité requise Documentation requise n n n (3) Capacité de modéliser les besoins Capacité de programmation Expérience de l’application Expérience de la plateforme Expérience du langage et des outils Continuité du personnel Facteurs liés au projet n n © 2005 -2006 Jean-Paul Rigault Développement multi-site ? Contrainte de temps de développement 127

Estimation des coûts de développement Modèle cocomo ii n (4) Problèmes délicats n n Unité hommes mois discutable (voir Fred Brooks) Estimation du nombre de Kloc n n Dépend du langage Dépend du mode de production (e. g. , code généré ? ) Pas toujours disponible tôt Adaptation aux processus agiles ? 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 128

Bugs logiciels n n n Les moteurs de recherche comme Google permettent de trouver rapidement des informations sur les bugs cités. n Ci-après, quelques points d’entrée… Listes de fiascos n http: //www. cs. tau. ac. il/~nachumd/verify/horror. html n http: //www 5. in. tum. de/~huckle/bugse. html Ariane 5 n http: //www. ima. umn. edu/~arnold/disasters/ariane 5 rep. html n http: //archive. eiffel. com/doc/manuals/technology/contract/ariane/p age. html n http: //www. irisa. fr/pampa/EPEE/Ariane 5 -comments. html 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 130

Ouvrages et articles généraux n n n Interview de Bill Gates Focus Magazine, n° 43, octobre 1995 n http: //www. cantrip. org/nobugs. html No Silver Bullet Fred Brooks n http: //www. virtualschool. edu/mon/Software. Engineering/Brooks. No Silver. Bullet. html The Mythical Man-Month (20 th anniversary edition) Fred Brooks, Addison-Wesley, 1995 Les avatars du logiciel Lauren Ruth Wiener, Addison-Wesley, 1994 Anti-Patterns William H. Brown et al. , Wiley, 1998 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 131

L’échec du waterfall n n IT Projects Sink or Swim M. Thomas, Computer Bulletin, British Computer Society, January 2000 ROI, It’s Your Job Jim Johnson, XP 2002, Sardinia, Italy, 2002 (ROI = Return On Investment) 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 132

Monographies sur le génie logiciel n n n Software Engineering (7 th Edition) Ian Sommerville, Addison-Wesley, 2004 A Discipline for Software Engineering Watts S. Humphrey, Addison-Wesley, 1994 Object-Oriented Software Engineering: Using UML, Patterns and Java (Second Edition) Bernd Bruegge, Allen H. Dutoit, Prentice Hall, 2003 Metrics and Models in Software Quality Engineering (2 nd Edition) Stephen H. Kan, Addison-Wesley, 2002 Software Cost Estimation with Cocomo II Barry W. Boehm, Prentice Hall, 2000) 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 133

UML, le RUP, et Agile UP n n n UML Distilled (3 rd Edition) Martin Fowler, Addison-Wesley, 2004 UML 2 et les design patterns (3 e édition) Craig Larman, Pearson Education, 2005 The Unified Software Development Process Ivar Jacobson, Grady Booch, James Rumbaugh, Addison-Wesley, 1999 The Rational Unified Process: An Introduction (3 rd Edition) Philippe Kruchten, Addison-Wesley, 2003 The Rational Unified Process Made Easy: A Practitioner's Guide to RUP Per Kroll, Philippe Kruchten, Addison-Wesley, 2003 Agile and Iterative Development: A Manager's Guide Craig Larman, Addison-Wesley, 2003 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 134

Méthodologies agiles n n n Manifeste agile n http: //agilemanifesto. org n http: //agilealliance. com EXtreme Programming n http: //www. extremeprogramming. org n e. Xtreme Programming e. Xplained Kent Beck, Addison-Wesley, 2000 n e. Xtreme Programming Installed Ron Jeffries et al. , Addison-Wesley, 2001 Scrum n Agile Project Management with Scrum Ken Schwaber, Microsoft Press, 2004 n http: //www. controlchaos. com 16/03/2018 11: 03 © 2005 -2006 Jean-Paul Rigault 135