La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

© 2005-2006 Jean-Paul Rigault 05/05/2014 08:42 1 Introduction au Génie logiciel Jean-Paul Rigault École polytechnique de luniversité de Nice Département.

Présentations similaires


Présentation au sujet: "© 2005-2006 Jean-Paul Rigault 05/05/2014 08:42 1 Introduction au Génie logiciel Jean-Paul Rigault École polytechnique de luniversité de Nice Département."— Transcription de la présentation:

1 © Jean-Paul Rigault 05/05/ :42 1 Introduction au Génie logiciel Jean-Paul Rigault École polytechnique de luniversité de Nice Département de sciences informatiques

2 © Jean-Paul Rigault 05/05/ :422 Plan Quelques histoires horrifiques Problématique du génie logiciel Méthodologies de développement

3 © Jean-Paul Rigault 05/05/ :42 3 Introduction au Génie logiciel Quelques histoires horrifiques

4 © Jean-Paul Rigault 05/05/ :424 Quelques histoires horrifiques Pour commencer 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, theyd tell you to reinstall the engine. Lavis dun expert There are no significant bugs in our released software that any significant number of users want fixed. Bill Gates, interview à lhebdomadaire allemand Focus, n° 43, 23 octobre1995, pages

5 © Jean-Paul Rigault 05/05/ :425 Quelques histoires horrifiques Contenu Le premier « bug » Quelques bugs célèbres Tests de non-régression Établissement des spécifications Tests dintégration Langages de programmation Interface homme-machine Complexité Informatisation inutile ? Pourquoi le logiciel est-il sujet aux bugs ?

6 © Jean-Paul Rigault 05/05/ :426 Quelques histoires horrifiques Le premier « bug » En 1947, un « calculateur programmable » Mark II de luniversité de Harvard sarrête brutalement. Un papillon mort avait provoqué un court-circuit Ce « bug » nétait pas de nature logicielle Il relève en partie de la légende…

7 © Jean-Paul Rigault 05/05/ :427 Quelques bugs célèbres Tests de non-régression (1) Lorsque l'on modifie le code, on doit effectuer deux sortes de tests L'une pour vérifier que la modification fait effectivement ce qu'on attendait 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

8 © Jean-Paul Rigault 05/05/ :428 Quelques bugs célèbres Tests de non-régression (2) À la suite dune modification, les tests de non- régression ne sont pas toujours effectués, car on na pas le temps 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 Une preuve de nonchalance ou, pire, darrogance … Lune des causes de bug les plus fréquentes

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

10 © Jean-Paul Rigault 05/05/ :4210 Quelques bugs célèbres Tests de non régression (4) Apollo 11, premier alunissage du module lunaire (1969) (suite) Déconnexion dun module supplémentaire non indispensable et dont le mise au point laissait à désirer. Les sorties de ce module (le sinus et le cosinus dun angle) sont lues comme 0, ce qui provoque des messages dalarme 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

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

12 © Jean-Paul Rigault 05/05/ :4212 Quelques bugs célèbres Tests de non-régression(6) Système de contrôle des départs, British Airways, aéroport de Londres Heathrow (2001) Perturbation de lenregistrement 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

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

14 © Jean-Paul Rigault 05/05/ :4214 Quelques bugs célèbres Tests de non-régression (8) Premier vol dAriane 5 (1996) (suite 1) Une erreur de conversion (overflow) 64 bits 16 bits dans un module (IRS) chargé destimer laccélération et la vitesse provoque une exception Ada pour laquelle il nest prévue aucun « handler » Le système interprète les données de lexception comme des données normales (aberrantes évidemment)

15 © Jean-Paul Rigault 05/05/ :4215 Quelques bugs célèbres Tests de non-régression (9) Premier vol dAriane 5 (1996) (suite 2) Le module qui a levé lexception avait tourné de manière satisfaisante pendant 10 ans sur Ariane 4 On savait quil ny a pas doverflow avec Ariane 4 Mais la dynamique dAriane 5 est différente ! Une simple simulation aurait révélé le problème… Comble dironie, 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 : lexception a donc simplement été levée deux fois !

16 © Jean-Paul Rigault 05/05/ :4216 Quelques bugs célèbres Tests de non-régression (10) Premier vol dAriane 5 (1996) (suite 3) 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

17 © Jean-Paul Rigault 05/05/ :4217 Quelques bugs célèbres Établissement des spécifications(1) Les spécifications décrivent les aspects fonctionnels et non-fonctionnels du système Ce que le système doit faire et sous quelles contraintes Pas comment il doit le faire Activité très délicate Changement de formalisme Prise en compte complète des scénarios dutilisation, des effets de lenvironnement, 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

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

19 © Jean-Paul Rigault 05/05/ :4219 Quelques bugs célèbres Établissement des spécifications(3) Boeing 767 dUA en approche à Denver (1983) 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 ; lavion traversait alors une tempête et il y faisait très froid, doù le givrage Oubli des lois physiques lors des spécifications Pas de prise en compte de la température extérieure

20 © Jean-Paul Rigault 05/05/ :4220 Quelques bugs célèbres Établissement des spécifications(4) Appareil de radio-thérapie Therac-25, USA et Canada (1986) Lappareil permettait deux niveaux dirradiation, lun faible, lautre 100 fois plus puissant. Le second nécessitait linterposition dun 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 : lopérateur commence avec la dose maximale et le bouclier, puis saperçoit quil doit en fait administrer la faible dose. Il réinitialise lappareil, le bouclier se retire avant que la source ne réduise sa puissance.

21 © Jean-Paul Rigault 05/05/ :4221 Quelques bugs célèbres Établissement des spécifications(5) Appareil de radio-thérapie Therac-25, USA et Canada (1986) (suite) Spécification dun 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 Les précédents modèles (et en particulier le Thérac-20) disposaient dune sécurité mécanique qui empêchait ladministration de la forte dose en absence de bouclier Bug très difficile à mettre en évidence Caractère aléatoire, dépendant des scénarios Les concepteurs avaient du mal à y croire

22 © Jean-Paul Rigault 05/05/ :4222 Quelques bugs célèbres Établissement des spécifications(6) Missile Patriot, guerre du Golfe (1991) Défaut dinterception dun missile Scud irakien 28 morts, 100 blessés Une erreur darrondi dans le calcul du temps saccumulait, faussant la précision de linterception 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 darrondi 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

23 © Jean-Paul Rigault 05/05/ :4223 Quelques bugs célèbres Établissement des spécifications(7) Missile Patriot, guerre du Golfe (1991) (suite 2) Spécification incomplète et fonctionnement hors normes En temps normal, le système devait être rebooté tous les jours, mais ce mode de fonctionnement nétait quimplicite dans le cahier des charges. Lors de laccident, il tournait depuis 5 jours daffilé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 na été déployée que trop tard (le lendemain !)

24 © Jean-Paul Rigault 05/05/ :4224 Quelques bugs célèbres Établissement des spécifications(8) Observation de la couche dozone ( ) Les satellites de la NASA détectent des taux très bas dozone dans certaines régions et le logiciel considère quil sagit derreurs La reconnaissance de la réalité de ces taux ne sera affirmée quen 1986, suite à des études britanniques Défaut de spécification face à un phénomène inconnu

25 © Jean-Paul Rigault 05/05/ :4225 Quelques bugs célèbres Tests dintégration(1) Tests unitaires Vérifier qu'une entité individuelle (classe, module, composant) se comporte correctement Tests d'intégration 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) Vérifier qu'une modification n'a aucun effet négatif sur le fontionnement global du système

26 © Jean-Paul Rigault 05/05/ :4226 Quelques bugs célèbres Tests dintégration(2) Mars Climate Orbiter (1999) Mise en orbite ratée ; écrasement sur Mars Échec de la mission (125 M$) 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 ! Mauvaise communication entre deux contractants (Lockheed et Jet Propulsion Laboratory) Tests dintégration défaillants Management défaillant

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

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

29 © Jean-Paul Rigault 05/05/ :4229 Quelques bugs célèbres Langages de programmation(2) Réseau de téléphone longue distance dAT&T (1990) 9 heures dinterruption de service Mauvais placement dune instruction break en C La syntaxe concrète importe ! Défaut de test La duplication des commutateurs na encore servi à rien, puisque les secondaires exécutaient le même programme que les primaires

30 © Jean-Paul Rigault 05/05/ :4230 Quelques bugs célèbres Langages de programmation(3) Sonde Mariner I, mission vers Vénus (1962) Le bug suivant, trouvé dans le code Fortran de Mariner I, ne semble pas avoir eu de conséquence DO5I = 1.5 Cest une affectation ! Linstruction correcte (une boucle pour I variant de 1 à 5) aurait du être DO5I = 1,5 ou plutôt DO 5 I = 1, 5

31 © Jean-Paul Rigault 05/05/ :4231 Quelques bugs célèbres Langages de programmation(4) Du danger de certaines syntaxes concrètes : lexemple de C 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.

32 © Jean-Paul Rigault 05/05/ :4232 Quelques bugs célèbres Langages de programmation(5) « Buffer Overflow » (1998) Envoi de longs courriers provoquant le débordement dun buffer non protégé Une des voies dattaques des systèmes sur lInternet Modèle de mémoire linéaire et sans contrôle des langages comme C Sérieux problème de sécurité

33 © Jean-Paul Rigault 05/05/ :4233 Quelques bugs célèbres Interface homme-machine(1) Quelques propriétés souhaitables d'une bonne IHM 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

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

35 © Jean-Paul Rigault 05/05/ :4235 Quelques bugs célèbres Interface homme-machine(3) USS Yorktown (1998) Perte de propulsion pendant plusieurs heures 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 larrêt des machines ! Validation des données Couverture de test ?

36 © Jean-Paul Rigault 05/05/ :4236 Quelques bugs célèbres Complexité(1) De nombreuses échecs informatiques sont simplement dus à la complexité du système, en général associée à des facteurs comme 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 linformatique etc.

37 © Jean-Paul Rigault 05/05/ :4237 Quelques bugs célèbres Complexité(2) Informatisation du « dispatching » des ambulances à Londres (1992) Cartes informatisées, gestion des appels, envoi des ambulances Pertes dappels, attentes lors des appels (jusquà 30 min), retards dambulance (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

38 © Jean-Paul Rigault 05/05/ :4238 Quelques bugs célèbres Complexité(3) Informatisation du « dispatching » des ambulances à Londres (1992) (suite) Gestion de projet discutable Tests insuffisants et irréalistes Hypothèses irréalistes 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) Interface homme-machine médiocre 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

39 © Jean-Paul Rigault 05/05/ :4239 Quelques bugs célèbres Complexité(4) Système de manipulation automatique des bagages de laéroport de Denver ( ) Système « pharaonique » 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

40 © Jean-Paul Rigault 05/05/ :4240 Quelques bugs célèbres Complexité(5) Système de manipulation automatique des bagages de laéroport de Denver ( ) (suite 1) Chaos total lors des tests Bagages détruits (même « mâchés » !) Crashes, collisions, détérioration des rails… Blocage des telecars par les bagages quils détruisaient…

41 © Jean-Paul Rigault 05/05/ :4241 Quelques bugs célèbres Complexité(6) Système de manipulation automatique des bagages de laéroport de Denver ( ) (suite 2) Retard douverture de laéroport de plus de 16 mois Le système (bien réduit) nest 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 laéroport est passé de 1,7 G$ à 4,5 G$ Dette de 1 M$ par jour pour Denver Denver est laéroport des USA où les taxes sont les plus élevées ! Taille et complexité du projet, pas de référence préalable Gestion de projet

42 © Jean-Paul Rigault 05/05/ :4242 Quelques bugs célèbres Informatisation inutile ?(1) Certains échecs informatiques sont dautant plus cuisants que linformatisation nétait pas vraiment indispensable Effet de mode Mauvaise appréciation des systèmes concurrents Foi en linformatique et ses « retombées » positives Ce syndrome saccompagne souvent dun des aspects suivants Complexité, système « pharaonique » Mauvaise gestion Application sans référence antérieure

43 © Jean-Paul Rigault 05/05/ :4243 Quelques bugs célèbres Informatisation inutile ?(2) Informatisation des commandes de « ferries », état de Washington (1990) 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é

44 © Jean-Paul Rigault 05/05/ :4244 Quelques bugs célèbres Informatisation inutile ?(3) Automatisation des usines de General Motors ( ) 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 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 Informatisation inutile ou prématurée Mauvaise estimation de l'apport de l'informatisation : le but était ici de concurrencer les méthodes japonaises !

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

46 © Jean-Paul Rigault 05/05/ :4246 Pourquoi le logiciel est-il sujet aux bugs ? Il ny a pas que le logiciel…(2) Le pont de Tacoma (1940) (Tacoma Narrows Bridge) Instabilité dynamique sous leffet des rafales de vent (de lordre de 68 km/h) Oscillations de torsion et résonance, suivis de rupture Aucune victime ! Voisinage de la résidence de Ronald Reagan ( ) Interférence entre les systèmes de défense dAir Force One et portes de garage automatiques Le clip !

47 © Jean-Paul Rigault 05/05/ :4247 Pourquoi le logiciel est-il sujet aux bugs ? Une remarque… fondamentale En matière de bug logiciel, lerreur est toujours dorigine humaine

48 © Jean-Paul Rigault 05/05/ :4248 Pourquoi le logiciel est-il sujet aux bugs ? La nature du logiciel(1) Invisible, abstrait, discontinu Le plus souvent, cest leffet du logiciel qui est visible Tout logiciel est une abstraction de la réalité 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 Les ingénieurs logiciels ont souvent peu de connaissances de ces contraintes Exemples : optimisation des moteurs du B767 ; British Railways, les freins à disque, le logiciel et les feuilles mortes…

49 © Jean-Paul Rigault 05/05/ :4249 Pourquoi le logiciel est-il sujet aux bugs ? La nature du logiciel(2) Souple et donc malléable sans limite Modifications permanentes du cahier des charges, des spécifications… Extensions, nouvelles fonctionnalités Modifications hasardeuses Dans la plupart des domaine de lingénierie, il existe des lois naturelles qui limitent lexcroissance du cahier des charges. Mais ces lois ne sappliquent pas au logiciel. John McWha, responsable du projet Boeing 777 No! (What part of this dont you understand?) Affiche (« Outil de gestion ») du projet logiciel du B777

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

51 © Jean-Paul Rigault 05/05/ :4251 Quelques histoires horrifiques Pour conclure (provisoirement) ces histoires

52 © Jean-Paul Rigault 05/05/ :42 52 Introduction au Génie logiciel Problématique du génie logiciel

53 © Jean-Paul Rigault 05/05/ :4253 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

54 © Jean-Paul Rigault 05/05/ :4254 Problématique du génie logiciel Plan 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

55 © Jean-Paul Rigault 05/05/ :4255 Le génie logiciel (1) Terme (Software Engineering) introduit en 1968 Conférence de lOTAN à Garmish Parten Kirchen La « crise du logiciel » (déjà !) Ensemble de méthodologies de méthodes de techniques doutils pour produire, utiliser et maintenir du logiciel de qualité industrielle

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

57 © Jean-Paul Rigault 05/05/ :4257 Le génie logiciel (3) Comme toute discipline dingénierie, le génie logiciel nest pas purement technique Aspect humains Sélection, constitution, et gestion des équipes Formation des personnels Relation avec les clients prescripteurs Aspects financiers Estimation des coûts Suivi de projet Gestion budgétaire

58 © Jean-Paul Rigault 05/05/ :4258 Le coût des développements de logiciel Nature des coûts Peu de capitaux nécessaires Frais de personnel très élevés 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

59 © Jean-Paul Rigault 05/05/ :4259 Le coût des développements de logiciel Coûts par phases de développement Daprès Boehm Type de système Pourcentage des coûts par phase Analyse et conception Implémentation Test et Intégration Régulation et contrôle Aérospatiale Système dexploitation Calcul scientifique Gestion4428

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

61 © Jean-Paul Rigault 05/05/ :4261 Buts et moyens du génie logiciel Moyens du génie logiciel(1) Gestion rigoureuse du processus de développement 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) 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 doutils dans toutes les phases

62 © Jean-Paul Rigault 05/05/ :4262 Buts et moyens du génie logiciel Moyens du génie logiciel(2) Pas de remède miracle (No Silver Bullet, Fred Brooks, 1986) Quelques pistes 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

63 © Jean-Paul Rigault 05/05/ :4263 Buts et moyens du génie logiciel Moyens du génie logiciel(3) Limportance de la modélisation Modéliser est habituel dans les disciplines de lingénierie Le logiciel a longtemps échappé à cela… Lapparition des techniques structurées ou de modélisation des données (années 1980), puis des méthodes orientées- objets (années 1990), enfin dUML (fin 1990) ont rendu à la modélisation sa juste place Lapproche MDA (Model-Driven Architecture) de lOMG tente de placer la modélisation au centre du processus Cest loin dêtre encore une pratique courante partout ! Quand on modélise, on ne code pas. Et certains pensent toujours que la seule vérité est dans le code !

64 © Jean-Paul Rigault 05/05/ :4264 Évaluation de la qualité du logiciel Il est difficile dévaluer directement la qualité du logiciel lui-même Utilisation de métriques ? 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 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

65 © Jean-Paul Rigault 05/05/ :4265 Évaluation de la qualité du logiciel Normes ISO 9000 Normes générales et internationales de qualité Familles de normes (9000 à 9004) selon lactivité de lentreprise (ou dun de ses départements) Procédure de certification et daccréditation Applicable aussi bien à la fabrication des boulons, des automobiles, ou même à la formation des ingénieurs ! De nature très bureaucratique !

66 © Jean-Paul Rigault 05/05/ :4266 Évaluation de la qualité du logiciel Capability Maturity Model Integration Analyse de la maturité des entreprises (ou dun de leurs départements) par rapport à lorganisation de leur processus de développement de logiciel Modèle établi par le Software Engineering Institute, université de Carnegie Mellon, Pittsburg (SEI-CMI) Première publication en 1986 Spécifique au logiciel (CMM) Révisé en 2002 Étendu à lingénierie des systèmes (CMMI)

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

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

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

70 © Jean-Paul Rigault 05/05/ :42 70 Introduction au Génie logiciel Méthodologies de développement

71 © Jean-Paul Rigault 05/05/ :4271 Méthodologies de développement Contenu Méthode, méthodologie et cycle de vie Exemples de méthodologies DUML au RUP Rational Unified Process (RUP) Méthodologies agiles Estimation des coûts de développement

72 © Jean-Paul Rigault 05/05/ :4272 Méthode, méthodologie et cycle de vie (1) Méthodologie 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… Cycle de vie, Processus de développement Synonymes de méthodologie Méthode Approche technique pour aborder une ou plusieurs phases ou activités

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

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

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

76 © Jean-Paul Rigault 05/05/ :4276 Méthode, méthodologie et cycle de vie Activités lors du processus(3) Conception Traduction des spécifications en termes dartefacts logiciels Peut être plus ou moins détaillée Codage Traduction de la conception en code Test unitaires Test de chaque module individuellement Généralement de la responsabilité du développeur du module Tests dintégration Test de la composition de plusieurs modules (sous- systèmes)

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

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

79 © Jean-Paul Rigault 05/05/ :4279 Exemples de méthodologies Développement en cascade (waterfall)(1) Analyse des besoins Spécification Conception Codage Test Validation Recette

80 © Jean-Paul Rigault 05/05/ :4280 Exemples de méthodologies Développement en cascade (waterfall)(2) DoD2167a : méthodologie du département de la défense des USA (le langage de développement est Ada)

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

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

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

84 © Jean-Paul Rigault 05/05/ :4284 Exemples de méthodologies Développement en cascade (waterfall)(6) Étude de M. Thomas (2001) : 1027 projets, 13 % de succès (130) !

85 © Jean-Paul Rigault 05/05/ :4285 Exemples de méthodologies Développement en cascade (waterfall)(7) Étude de M. Thomas (2001) : 1027 projets, 13 % de succès ! (suite)

86 © Jean-Paul Rigault 05/05/ :4286 Exemples de méthodologies Développement en cascade (waterfall)(8) Étude de J. Johnson (2002) Plusieurs milliers de projets Méthodologie en cascade Taux réel dutilisation dans le produit final des fonctionnalités spécifiées

87 © Jean-Paul Rigault 05/05/ :4287 Exemples de méthodologies Développement en spirale(1)

88 © Jean-Paul Rigault 05/05/ :4288 Exemples de méthodologies Développement en spirale(2) Processus itératif Orienté prototypage Place importante des tests de lanalyse de risque Facilite la réutilisation lintégration du client lévolution des spécifications À la base de tous les processus « agiles »

89 © Jean-Paul Rigault 05/05/ :4289 Exemples de méthodologies Processus modernes « orientés objets » (1) Le paradigme objet favorise la réutilisation le développement incrémental (et donc itératif) et donc linté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) par réduction de la distance entre le domaine de lapplication et sa représentation informatique

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

91 © Jean-Paul Rigault 05/05/ :4291 Exemples de méthodologies Processus modernes « orientés objets » (3) Analyse de domaine Fournit un modèle conceptuel des objets et de leurs relations pour un domaine applicatif particulier (modèle- métier) Expression des besoins Fournit les besoins fonctionnels et non fonctionnels dune application particulière Analyse orientée-objets 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 dune application particulière

92 © Jean-Paul Rigault 05/05/ :4292 Exemples de méthodologies Processus modernes « orientés objets » (4) Méthodologies lourdes Reposent sur une modélisation importante (utilisation dUML) Exemples : Rational Unified Process (RUP), Model-Driven Architecture (MDA) de lOMG Méthodologies agiles Modélisation et documentation limitées et légères Itérations courtes et « productives » Importance des tests Importance du rôle des individus Exemples : Unified Process (UP), eXtreme Programming, Scrum

93 © Jean-Paul Rigault 05/05/ :4293 DUML au RUP Un peu dhistoire Nombreuses méthodes dACOO (50+) Coad-Yourdon Shlaer-Mellor Fusion etc …2004 Booch (Rose) Conception, codage Rumbaugh (OMT) Analyse OO, données Jacobson (OOSE) Expression des besoins U M L 0.8 U M L 0.9 Rational U M L 1.0 U M L 1.1 OMG request UML consortium U M L 1.2 U M L 1.3 U M L 2.0 OMG OMG vote U M L 1.4 U M L 1.5

94 © Jean-Paul Rigault 05/05/ :4294 DUML au RUP Quest-ce quUML ? UML is a language for Visualizing Specifying Constructing Documenting the artifacts of a software-intensive system Syntaxe et sémantique Graphique Architecture et comportement Génération de code Descriptions graphiques et textuelles On ne décrit pas lunivers tout entier… Le logiciel joue un rôle majeur

95 © Jean-Paul Rigault 05/05/ :4295 DUML au RUP Quest-ce quun modèle UML ?(1) Un ensemble déléments de modélisation… Organisés en sous- modèles selon le niveau de détail (dabstraction) selon le point de vue Certains de ces éléments et sous- modèles sont visualisés dans des diagrammes State Diagrams Use Case Diagrams Use Case Diagrams Use Case Diagrams Scenario Diagrams Scenario Diagrams Collaboration Diagrams State Diagrams State Diagrams Component Diagrams Component Diagrams Component Diagrams Deployment Diagrams State Diagrams State Diagrams Object Diagrams Scenario Diagrams Scenario Diagrams Statechart Diagrams Use Case Diagrams Use Case Diagrams Sequence Diagrams State Diagrams Class Diagrams Activity Diagrams Model Elements

96 © Jean-Paul Rigault 05/05/ :4296 DUML au RUP Quest-ce quun modèle UML ?(2) ModelElement Diagram chose Relation Abstractions, objets de 1ère classe Relie les choses entre elles Visualise des choses et leurs relations

97 © Jean-Paul Rigault 05/05/ :4297 DUML au RUP Quest-ce quun modèle UML ?(3) ModelElement Diagram chose Use Case Class Interface Collaboration Active Class Component Node Relation Realization Dependency Association Generalization Class Use Case Collaboration Deployment Object Sequence State-Transition Component Activity Structure Comportement Organisation Annotation Interaction State Machine Package Note

98 © Jean-Paul Rigault 05/05/ :4298 Diagrammes dynamiques DUML au RUP Quest-ce quun modèle UML ?(4) Diagramme de classes (Diagramme dobjets) Diagramme de cas dutilisation Diagramme de séquence Diagramme de collaboration Diagramme détats Daigramme dactivité Diagramme de composants Diagramme de déploiement Diagrammes statiques Diagrammes statiques (dimplémentation) Diagrammes dinteraction Diagrammes détats-transitions Diagrammes dUML 1.x

99 © Jean-Paul Rigault 05/05/ :4299 DUML au RUP Diverses modes dutilisation dUML Mode esquisse (sketch) Informelle, incomplète Souvent manuelle (tableau) Mode plan (blue print) Diagrammes détaillés Production de documents Pro- et rétro-ingénierie Mode langage de programmation Spécification complète et exécutable Pas vraiment disponible actuellement !

100 © Jean-Paul Rigault 05/05/ :42100 DUML au RUP Diverses cibles dutilisation dUML Point de vue conceptuel Modélisation dentités du monde applicatif Analyse de domaine Point de vue de spécification logicielle Abstraction dentités du monde réel Composants logiciels Analyse OO Point de vue dimplémentation logicielle Artefacts et composants pour une technologie particulière (Java, C++, BD…) Conception OO

101 © Jean-Paul Rigault 05/05/ :42101 Rational Unified Process (RUP) UML se veut indépendant de toute méthodologie Cependant, il est mieux adapté à un processus (tel le RUP) dirigé par les cas dutilisation (use-case driven) centré sur larchitecture (architecture centric) itératif et incrémental Le RUP propose en outre 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

102 © Jean-Paul Rigault 05/05/ :42102 Rational Unified Process (RUP) Itératif et incrémental(1) Quatre phases majeures Inception Élaboration Construction Transition temps 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

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

104 © Jean-Paul Rigault 05/05/ :42104 Rational Unified Process (RUP) Itératif et incrémental(3) Un processus à deux dimensions

105 © Jean-Paul Rigault 05/05/ :42105 Rational Unified Process (RUP) Centré sur l'architecture Threads et processus Concurrence et synchronisation Vue de processus Threads et processus Concurrence et synchronisation Vue de processus Vue dimplémentation Composants, fichiers, versions… Gestion de configuration Vue dimplémentation Composants, fichiers, versions… Gestion de configuration Vue de conception Vocabulaire du système et/ou de sa solution Besoins fonctionnels Vue de conception Vocabulaire du système et/ou de sa solution Besoins fonctionnels Support hardware Distribution, installation Vue de déploiement Support hardware Distribution, installation Vue de déploiement Vue des cas dutilisation Services pour les utilisateurs Vue des cas dutilisation Services pour les utilisateurs vues d'architecture

106 © Jean-Paul Rigault 05/05/ :42106 Rational Unified Process (RUP) Dirigé par les cas d'utilisation(1) Base du développement tout entier 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 Délivrance d'un système limité à certains cas

107 © Jean-Paul Rigault 05/05/ :42107 Rational Unified Process (RUP) Dirigé par les cas d'utilisation(2) Capturer, définir clarifier les cas dutilisation Analyse Réaliser les cas dutilisation Conception et codage Test Cas dutilisation Vérifier les cas dutilisation

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

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

110 © Jean-Paul Rigault 05/05/ :42110 Rational Unified Process (RUP) Rôles et flots : définition des besoins

111 © Jean-Paul Rigault 05/05/ :42111 Rational Unified Process (RUP) Rôles et flots : analyse et conception

112 © Jean-Paul Rigault 05/05/ :42112 Rational Unified Process (RUP) Rôles et flots : implémentation

113 © Jean-Paul Rigault 05/05/ :42113 Rational Unified Process (RUP) Rôles et flots : test

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

115 © Jean-Paul Rigault 05/05/ :42115 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.

116 © Jean-Paul Rigault 05/05/ :42116 Méthodologies agiles The Agile Manifesto : principes agiles 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. 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.

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

118 © Jean-Paul Rigault 05/05/ :42118 Méthodologies agiles Agile Unified Process (UP)(2) Propriétés des itérations Itérations courtes (1 à 4 semaines) fixées à lavance Pas de glissement de dates 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

119 © Jean-Paul Rigault 05/05/ :42119 Méthodologies agiles Agile Unified Process (UP)(3) Utilisation dUML UML est utilisé en mode esquisse Tableau blanc, vidéo-projecteur Le but nest pas de produire de la documentation mais damé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

120 © Jean-Paul Rigault 05/05/ :42120 Méthodologies agiles Agile Unified Process (UP)(4) Autres « bonnes pratiques » Traitement des questions très importantes ou très critiques dans les premières itérations Implication permanente des utilisateurs (évaluation, définition) Construction dun 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

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

122 © Jean-Paul Rigault 05/05/ :42122 Méthodologies agiles Agile Unified Process (UP)(6) Disciplines de UP Modélisation métier Analyse des besoins (cas dutilisation) Conception et implémentation OO Tests Déploiement Gestion de configuration et de changement Gestion de projet Gestion de lenvironnement (choix doutils, personnalisation de lenvironnement…)

123 © Jean-Paul Rigault 05/05/ :42123 Méthodologies agiles Extreme Programming (XP) Un processus très orienté vers les programmeurs 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) Tout le source est modifiable par qui veut Doù limportance des tests continuels ! Normes de codage strictes Programmation à deux (pair programming)…

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

125 © Jean-Paul Rigault 05/05/ :42125 Estimation des coûts de développement Modèle cocomo ii(1) Estimation du coût en hommes mois à partir de la taille du projet H résultat (hommesxmois) S taille du projet A une constante m i facteurs multiplicatifs w i facteurs déchelle

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

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

128 © Jean-Paul Rigault 05/05/ :42128 Estimation des coûts de développement Modèle cocomo ii(4) Problèmes délicats Unité hommes mois discutable (voir Fred Brooks) Estimation du nombre de Kloc 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 ?

129 © Jean-Paul Rigault 05/05/ : Introduction au Génie logiciel Références

130 © Jean-Paul Rigault 05/05/ :42130 Bugs logiciels Les moteurs de recherche comme Google permettent de trouver rapidement des informations sur les bugs cités. Ci-après, quelques points dentrée… Listes de fiascos Ariane 5 age.html age.html

131 © Jean-Paul Rigault 05/05/ :42131 Ouvrages et articles généraux Interview de Bill Gates Focus Magazine, n° 43, octobre No Silver Bullet Fred Brooks SilverBullet.html SilverBullet.html The Mythical Man-Month (20th 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

132 © Jean-Paul Rigault 05/05/ :42132 Léchec du waterfall IT Projects Sink or Swim M. Thomas, Computer Bulletin, British Computer Society, January 2000 ROI, Its Your Job Jim Johnson, XP 2002, Sardinia, Italy, 2002 (ROI = Return On Investment)

133 © Jean-Paul Rigault 05/05/ :42133 Monographies sur le génie logiciel Software Engineering (7th 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 (2nd Edition) Stephen H. Kan, Addison-Wesley, 2002 Software Cost Estimation with Cocomo II Barry W. Boehm, Prentice Hall, 2000)

134 © Jean-Paul Rigault 05/05/ :42134 UML, le RUP, et Agile UP UML Distilled (3rd 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 (3rd 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

135 © Jean-Paul Rigault 05/05/ :42135 Méthodologies agiles Manifeste agile EXtreme Programming eXtreme Programming eXplained Kent Beck, Addison-Wesley, 2000 eXtreme Programming Installed Ron Jeffries et al., Addison-Wesley, 2001 Scrum Agile Project Management with Scrum Ken Schwaber, Microsoft Press, 2004

136 © Jean-Paul Rigault 05/05/ : Introduction au Génie logiciel Fin…


Télécharger ppt "© 2005-2006 Jean-Paul Rigault 05/05/2014 08:42 1 Introduction au Génie logiciel Jean-Paul Rigault École polytechnique de luniversité de Nice Département."

Présentations similaires


Annonces Google