© 2005-2006 Jean-Paul Rigault
11/04/23 04:00 1
Introduction au Génie logiciel
Jean-Paul RigaultÉcole polytechnique de l’université de Nice
Département de sciences informatiquesEmail: [email protected]
© 2005-2006 Jean-Paul Rigault
11/04/23 04:00 2
Plan
Quelques histoires horrifiques Problématique du génie logiciel Méthodologies de développement
© 2005-2006 Jean-Paul Rigault
11/04/23 04:00 3
Introduction au Génie logiciel
Quelques histoires horrifiques
© 2005-2006 Jean-Paul Rigault
11/04/23 04:00 4
Quelques histoires horrifiquesPour commencer
Une plaisanterie (?) anonymeIf 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.
L ’avis d’un expertThere 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 octobre1995, pages 206-212
http://www.cantrip.org/nobugs.html
© 2005-2006 Jean-Paul Rigault
11/04/23 04:00 5
Quelques histoires horrifiquesContenu
Le premier « bug » Quelques bugs célèbres
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 ?
© 2005-2006 Jean-Paul Rigault
11/04/23 04:00 6
Quelques histoires horrifiques Le premier « bug »
En 1947, un « calculateur programmable » Mark II de l’université de Harvard s’arrê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…
© 2005-2006 Jean-Paul Rigault
11/04/23 04:00 7
Quelques bugs célèbresTests 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
© 2005-2006 Jean-Paul Rigault
11/04/23 04:00 8
Quelques bugs célèbresTests de non-régression (2)
À la suite d’une modification, les tests de non-régression ne sont pas toujours effectués, car
on n’a 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, d’arrogance … L ’une des causes de bug les plus fréquentes
© 2005-2006 Jean-Paul Rigault
11/04/23 04:00 9
Quelques bugs célèbresTests de non régression (3)
Apollo 11, premier alunissage du module lunaire (1969)
Données absurdes et alarmes logicielles intempestives lors de l’alunissage (calcul de la trajectoire)
Amstrong atterrit manuellement, sans aucune marge de sécurité
© 2005-2006 Jean-Paul Rigault
11/04/23 04:00 10
Quelques bugs célèbresTests de non régression (4)
Apollo 11, premier alunissage du module lunaire (1969) (suite)
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
© 2005-2006 Jean-Paul Rigault
11/04/23 04:00 11
Quelques bugs célèbresTests 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 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é…
© 2005-2006 Jean-Paul Rigault
11/04/23 04:00 12
Quelques bugs célèbresTests de non-régression (6)
Système de contrôle des départs, British Airways, aéroport de Londres Heathrow (2001)
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
© 2005-2006 Jean-Paul Rigault
11/04/23 04:00 13
Quelques bugs célèbresTests de non-régression (7)
Premier vol d’Ariane 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
© 2005-2006 Jean-Paul Rigault
11/04/23 04:00 14
Quelques bugs célèbresTests de non-régression (8)
Premier vol d’Ariane 5 (1996) (suite 1)
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 »
Le système interprète les données de l’exception comme des données normales (aberrantes évidemment)
© 2005-2006 Jean-Paul Rigault
11/04/23 04:00 15
Quelques bugs célèbresTests de non-régression (9)
Premier vol d’Ariane 5 (1996) (suite 2) Le module qui a levé l’exception avait tourné de
manière satisfaisante pendant 10 ans sur Ariane 4 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 !
© 2005-2006 Jean-Paul Rigault
11/04/23 04:00 16
Quelques bugs célèbresTests de non-régression (10)
Premier vol d’Ariane 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
© 2005-2006 Jean-Paul Rigault
11/04/23 04:00 17
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 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
© 2005-2006 Jean-Paul Rigault
11/04/23 04:00 18
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 d’une grandeur ; le calculateur du lanceur a essayé de corriger une situation qui ne nécessitait aucune correction
Passage délicat d’un formalisme à un autre
© 2005-2006 Jean-Paul Rigault
11/04/23 04:00 19
Quelques bugs célèbresÉtablissement des spécifications (3)
Boeing 767 d’UA 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 ; 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 Pas de prise en compte de la température extérieure
© 2005-2006 Jean-Paul Rigault
11/04/23 04:00 20
Quelques bugs célèbresÉtablissement des spécifications (4)
Appareil de radio-thérapie Therac-25, USA et Canada (1986)
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.
© 2005-2006 Jean-Paul Rigault
11/04/23 04:00 21
Quelques bugs célèbresÉtablissement des spécifications (5)
Appareil de radio-thérapie Therac-25, USA et Canada (1986) (suite)
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
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 Caractère aléatoire, dépendant des scénarios Les concepteurs avaient du mal à y croire
© 2005-2006 Jean-Paul Rigault
11/04/23 04:00 22
Quelques bugs célèbresÉtablissement des spécifications (6)
Missile Patriot, guerre du Golfe (1991) Défaut d’interception d’un missile
Scud irakien 28 morts, 100 blessés Une erreur d’arrondi dans le calcul
du temps s’accumulait, faussant la précision de l’interception
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
© 2005-2006 Jean-Paul Rigault
11/04/23 04:00 23
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 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 !)
© 2005-2006 Jean-Paul Rigault
11/04/23 04:00 24
Quelques bugs célèbresÉtablissement des spécifications (8)
Observation de la couche d’ozone (1979-1980)
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
© 2005-2006 Jean-Paul Rigault
11/04/23 04:00 25
Quelques bugs célèbresTests d’inté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
© 2005-2006 Jean-Paul Rigault
11/04/23 04:00 26
Quelques bugs célèbresTests d’inté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 d’intégration défaillants Management défaillant
© 2005-2006 Jean-Paul Rigault
11/04/23 04:00 27
Quelques bugs célèbresTests d’intégration (3)
Mars Polar Lander (1999) É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
© 2005-2006 Jean-Paul Rigault
11/04/23 04:00 28
Quelques bugs célèbresLangages 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
© 2005-2006 Jean-Paul Rigault
11/04/23 04:00 29
Quelques bugs célèbresLangages de programmation (2)
Réseau de téléphone longue distance d’AT&T (1990)
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
© 2005-2006 Jean-Paul Rigault
11/04/23 04:00 30
Quelques bugs célèbresLangages 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équenceDO5I = 1.5
C’est une affectation ! L’instruction correcte (une boucle pour I variant de 1 à 5) aurait du être
DO5I = 1,5
ou plutôtDO 5 I = 1, 5
© 2005-2006 Jean-Paul Rigault
11/04/23 04:00 31
Quelques bugs célèbresLangages de programmation (4)
Du danger de certaines syntaxes concrètes : l’exemple 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.
© 2005-2006 Jean-Paul Rigault
11/04/23 04:00 32
Quelques bugs célèbresLangages de programmation (5)
« Buffer Overflow » (1998) 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é
© 2005-2006 Jean-Paul Rigault
11/04/23 04:00 33
Quelques bugs célèbresInterface 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
© 2005-2006 Jean-Paul Rigault
11/04/23 04:00 34
Quelques bugs célèbresInterface homme-machine (2)
USS Vincennes, Golfe Persique (1988) La frégate USS Vincennes abat un
Airbus civil d’Iran Air en le prenant pour un avion de combat hostile
290 morts 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.
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 n’est pas une excuse recevable pour un système militaire !
© 2005-2006 Jean-Paul Rigault
11/04/23 04:00 35
Quelques bugs célèbresInterface 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 l’arrêt des machines !
Validation des données Couverture de test ?
© 2005-2006 Jean-Paul Rigault
11/04/23 04:00 36
Quelques bugs célèbresComplexité (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 l’informatique etc.
© 2005-2006 Jean-Paul Rigault
11/04/23 04:00 37
Quelques bugs célèbresComplexité (2)
Informatisation du « dispatching » des ambulances à Londres (1992)
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
© 2005-2006 Jean-Paul Rigault
11/04/23 04:00 38
Quelques bugs célèbresComplexité (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
© 2005-2006 Jean-Paul Rigault
11/04/23 04:00 39
Quelques bugs célèbresComplexité (4)
Système de manipulation automatique des bagages de l’aéroport de Denver (1993-1995)
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
© 2005-2006 Jean-Paul Rigault
11/04/23 04:00 40
Quelques bugs célèbresComplexité (5)
Système de manipulation automatique des bagages de l’aéroport de Denver (1993-1995) (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 qu’ils détruisaient…
© 2005-2006 Jean-Paul Rigault
11/04/23 04:00 41
Quelques bugs célèbresComplexité (6)
Système de manipulation automatique des bagages de l’aéroport de Denver (1993-1995) (suite 2)
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$
Dette de 1 M$ par jour pour Denver 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 Gestion de projet
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 42
Quelques bugs célèbresInformatisation inutile ? (1)
Certains échecs informatiques sont d’autant plus cuisants que l’informatisation n’était pas vraiment indispensable
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
Complexité, système « pharaonique » Mauvaise gestion Application sans référence antérieure
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 43
Quelques bugs célèbresInformatisation 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é
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 44
Quelques bugs célèbresInformatisation inutile ? (3)
Automatisation des usines de General Motors (1980-1985)
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 !
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 45
Pourquoi le logiciel est-il sujet aux bugs ?Il n’y 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 s’est couché sur le flanc…
1500 morts environ Estonia Ferry (1994)
Mauvaise fermeture de la porte
800 morts
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 46
Pourquoi le logiciel est-il sujet aux bugs ?Il n’y a pas que le logiciel… (2)
Le pont de Tacoma (1940) (Tacoma Narrows Bridge)
Instabilité dynamique sous l’effet des rafales de vent (de l’ordre de 68 km/h)
Oscillations de torsion et résonance, suivis de rupture
Aucune victime ! Voisinage de la résidence
de Ronald Reagan (1981-1988)
Interférence entre les systèmes de défense d’Air Force One et portes de garage automatiques
Le clip !
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 47
Pourquoi le logiciel est-il sujet aux bugs ?Une remarque… fondamentale
En matière de bug logiciel, l’erreur est toujours d’origine humaine
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 48
Pourquoi le logiciel est-il sujet aux bugs ?La nature du logiciel (1)
Invisible, abstrait, discontinu Le plus souvent, c’est l’effet 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…
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 49
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 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 McWha, responsable du projet Boeing 777No!
(What part of this don’t you understand?)Affiche (« Outil de gestion ») du projet logiciel du
B777
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 50
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 d’offres
d’emploi pour les informaticiens ? Le problème de la formation des informaticiens
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 51
Quelques histoires horrifiquesPour conclure (provisoirement) ces histoires
Avatars des projets de logiciel du gouvernement US en 1979 : en valeur (M$) pour une valeur totale de 6,8 M$
abandonnés ou remodelés; 1,3
opérationnels après modifications; 0,2
livrés mais jamais utilisés; 3,2
opérationnels en l'état; 0,1
payés mais jamais livrés; 2
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 52
Introduction au Génie logiciel
Problématique du génie logiciel
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 53
Problématique du génie logicielPour 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
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 54
Problématique du génie logicielPlan
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
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 55
Le génie logiciel (1)
Terme (Software Engineering) introduit en 1968 Conférence de l’OTAN à Garmish Parten Kirchen La « crise du logiciel » (déjà !)
Ensemble de méthodologies de méthodes de techniques d ’outils
pour produire, utiliser et maintenir du logiciel de qualité industrielle
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 56
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é »
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 57
Le génie logiciel (3)
Comme toute discipline d’ingénierie, le génie logiciel n’est 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
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 58
Le coût des développements de logicielNature 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
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 59
Le coût des développements de logicielCoûts par phases de développement
D ’après Boehm
Type de systèmePourcentage des coûts par phase
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
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 60
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
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 61
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 d’outils dans toutes les phases
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 62
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
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 63
Buts et moyens du génie logiciel
Moyens du génie logiciel (3)
L ’importance de la modélisation Modéliser est habituel dans les disciplines de l’ingénierie
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ées-objets (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 ! Quand on modélise, on ne code pas. Et certains pensent
toujours que la seule vérité est dans le code !
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 64
É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
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 65
Évaluation de la qualité du logicielNormes ISO 9000
Normes générales et internationales de qualité
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 !
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 66
Évaluation de la qualité du logicielCapability Maturity Model Integration
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)
Première publication en 1986 Spécifique au logiciel (CMM)
Révisé en 2002 Étendu à l’ingénierie des systèmes (CMMI)
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 67
Évaluation de la qualité du logicielCMMI : niveaux de maturité (1)
Amélioration continue du processusOptimizing
Processus mesuré (instrumenté) et contrôléQuantitatively Managed
Processus défini au niveau de l’organisation 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 l’escalier au milieu !
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 68
Évaluation de la qualité du logicielCMMI : niveaux de maturité (2)
Évaluation du CMMI Enquête d’avril 2002 à août 2004, publiée en
septembre 2004 424 é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
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 69
Évaluation de la qualité du logicielCMMI : 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)
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 70
Introduction au Génie logiciel
Méthodologies de développement
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 71
Méthodologies de développementContenu
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
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 72
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
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 73
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)
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 74
Méthode, méthodologie et cycle de vieActivité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 d’un point de vue extérieur
Ce qu’il doit faire Pas comment il le fait
Spécifications fonctionnelles et non-fonctionnelles Doit rester accessible au client (contrat)
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 75
Méthode, méthodologie et cycle de vieActivité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 d’implémentation, de déploiement… Interface Conditions d’exploitation Conditionnement Aspects juridiques Aspects financiers…
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 76
Méthode, méthodologie et cycle de vieActivités lors du processus (3)
Conception Traduction des spécifications en termes d’artefacts 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 d’intégration Test de la composition de plusieurs modules (sous-systèmes)
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 77
Méthode, méthodologie et cycle de vieActivités lors du processus (4)
Validation Test du système final par rapport aux spécifications
Recette 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
Orthogonale à toutes ces activités Gestion du temps, des coûts, des équipes Gestion des relations avec les clients…
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 78
Exemples de méthodologiesCycle 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 despécification
Utilisation(test)Codage
Recette etdistribution
Satisfait ?non
oui
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 79
Exemples de méthodologiesDéveloppement en cascade (waterfall) (1)
Analyse des besoins
Spécification
Conception
Codage
Test
Validation
Recette
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 80
Exemples de méthodologiesDéveloppement en cascade (waterfall) (2)
DoD2167a : méthodologie du département de la défense des USA(le langage de développement est Ada)
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 81
Exemples de méthodologiesDé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
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 82
Exemples de méthodologiesDé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 d’approbation 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 l’intégration du client le prototypage la réutilisation la traçabilité…
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 83
Exemples de méthodologiesDé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 ! L ’utilisation du processus en cascade est
(maintenant) reconnu comme une des sources majeures des échecs de projets logiciels
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 84
Exemples de méthodologiesDéveloppement en cascade (waterfall) (6)
Étude de M. Thomas (2001) : 1027 projets, 13 % de succès (130) !
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 85
Exemples de méthodologiesDéveloppement en cascade (waterfall) (7)
Étude de M. Thomas (2001) : 1027 projets, 13 % de succès ! (suite)
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 86
Exemples de méthodologiesDéveloppement en cascade (waterfall) (8)
Étude de J. Johnson (2002)
Plusieurs milliers de projets
Méthodologie en cascade
Taux réel d ’utilisation dans le produit final des fonctionnalités spécifiées
toujours 7%
souvent13%
parfois16%
rarement19%
jamais45%
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 87
Exemples de méthodologiesDéveloppement en spirale (1)
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 88
Exemples de méthodologiesDéveloppement en spirale (2)
Processus itératif Orienté prototypage
Place importante des tests de l’analyse de risque
Facilite la réutilisation l’intégration du client l’évolution des spécifications
À la base de tous les processus « agiles »
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 89
Exemples de méthodologiesProcessus modernes « orientés objets » (1)
Le paradigme objet favorise la réutilisation le développement incrémental (et donc itératif)
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) par réduction de la distance entre le domaine de
l’application et sa représentation informatique
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 90
Exemples de méthodologiesProcessus modernes « orientés objets » (2)
Analyse dedomaine
Analyse OO
Conception OO
Codage et tests
Expression des besoinsIntégration, validation,
maintenance,management,
etc.
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 91
Exemples de méthodologiesProcessus 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
d ’une 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 d’une application particulière
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 92
Exemples de méthodologiesProcessus modernes « orientés objets » (4)
Méthodologies lourdes 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 Itérations courtes et « productives » Importance des tests Importance du rôle des individus Exemples : Unified Process (UP), eXtreme Programming,
Scrum
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 93
D’UML au RUPUn peu d’histoire
Nombreusesméthodesd’ACOO(50+)
Coad-Yourdon
Shlaer-Mellor
Fusion
etc.
1991 1992 1993 1994 1995 1996 1997 1998 … 2004
Booch (Rose)Conception, codage
Rumbaugh (OMT)Analyse OO, données
Jacobson (OOSE)Expression des besoins
UML
0.8UML
0.9
Rational
UML
1.0
UML
1.1
OMG request
UMLconsortium
UML
1.2
UML
1.3
UML
2.0
OMG
OMG vote
UML
1.4
UML
1.5
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 94
D’UML au RUPQu’est-ce qu’UML ?
UML is a language for
Visualizing Specifying Constructing Documenting
the artifacts of a software-intensive
system
Syntaxe et sémantique GraphiqueArchitecture et comportementGénération de codeDescriptions graphiques et textuelles
On ne décrit pas l’univers tout entier…
Le logiciel joue un rôle majeur
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 95
D’UML au RUPQu’est-ce qu’un modèle UML ? (1)
Un ensemble d ’éléments de modélisation…
Organisés en sous-modèles
selon le niveau de détail (d’abstraction)
selon le point de vue Certains de ces
éléments et sous-modèles sont visualisés dans des diagrammes
StateDiagramsUse Case
DiagramsUse CaseDiagramsUse CaseDiagrams
ScenarioDiagramsScenarioDiagramsCollaborationDiagrams
StateDiagramsStateDiagramsComponentDiagrams
ComponentDiagramsComponentDiagramsDeployment
Diagrams
StateDiagramsStateDiagramsObjectDiagrams
ScenarioDiagramsScenarioDiagramsStatechartDiagrams
Use CaseDiagramsUse CaseDiagramsSequenceDiagrams
StateDiagramsClassDiagrams
ActivityDiagrams
ModelElements
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 96
D’UML au RUPQu’est-ce qu’un 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
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 97
D’UML au RUPQu’est-ce qu’un modèle UML ? (3)
ModelElement
Diagram
“chose”
Use Case
Class
Interface
Collaboration
Active Class
Component
Node
Relation
Realization
DependencyAssociationGeneralization
Class
Use Case
Collaboration
Deployment
Object
Sequence
State-Transition
ComponentActivity
Structure
Comportement
OrganisationAnnotation
InteractionState Machine
PackageNote
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 98
Diagrammes
dynamiques
D’UML au RUPQu’est-ce qu’un modèle UML ? (4)
Diagramme de classes
(Diagramme d’objets)
Diagramme de cas d’utilisation
Diagramme de séquence
Diagramme de collaboration
Diagramme d’états
Daigramme d’activité
Diagramme de composants
Diagramme de déploiement
Diagrammes statiques
Diagrammes statiques (d’implémentation)
Diagrammes d’interaction
Diagrammes d’états-transitions
Diagrammes d’UML 1.x
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 99
D’UML au RUPDiverses modes d’utilisation d’UML
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 !
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 100
D’UML au RUPDiverses cibles d’utilisation d’UML
Point de vue conceptuel Modélisation d’entités du monde applicatif Analyse de domaine
Point de vue de spécification logicielle Abstraction d’entités du monde réel Composants logiciels Analyse OO
Point de vue d’implémentation logicielle Artefacts et composants pour une technologie
particulière (Java, C++, BD…) Conception OO
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 101
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 d’utilisation (use-case driven) centré sur l’architecture (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
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 102
Rational Unified Process (RUP)Itératif et incrémental (1)
Quatre phases majeures
InceptionInception ÉlaborationÉlaboration ConstructionConstruction TransitionTransition
temps
Quoi ?Pour qui ?Combien ?
Étude de marchéOpportunitééconomique
Analyse desbesoins
Modélisationdu domaine
Développement
du produitGestion des
changements
Transfert versles utilisateurs
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 103
Rational Unified Process (RUP)Itératif et incrémental (2)
Itération préliminaire
Itération d'architecture
Itération d'architecture
Itération dedéveloppement
Itération dedéveloppement
Itération dedéveloppement
Itération detransition
Itération detransition
Inception
Élaboration
Construction
Transition
Maquette
Prototype d'architecture
Prototype d'architecture
Prototype de développement
Prototype de développement
Version bêta
Version bêta
Distribution
Chaque phase est composée d’itérations, chaque itération se concluant par un produit ou un prototype
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 104
Rational Unified Process (RUP)Itératif et incrémental (3)
Elaboration Construction TransitionInception
Phases
Requirements Capture
Analysis & Design
ImplementationTest
ManagementEnvironmentDeployment
Process Components
Supporting Components
Iterations
preliminaryiteration(s)
iter.#1
iter.#2
iter.#n
iter.#n+1
iter.#n+2
iter.#m
iter.#m+1
Organizationalong content
Organization along time
Un processus à deux dimensions
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 105
Rational Unified Process (RUP)Centré sur l'architecture
Threads et processusConcurrence et synchronisationVue de processus
Threads et processusConcurrence et synchronisationVue de processus
Vue d’implémentationComposants, fichiers,
versions…Gestion de
configuration
Vue d’implémentationComposants, fichiers,
versions…Gestion de
configuration
Vue de conceptionVocabulaire du système et/ou de sa solution
Besoins fonctionnels
Vue de conceptionVocabulaire du système et/ou de sa solution
Besoins fonctionnels
Support hardwareDistribution, installation
Vue de déploiement
Support hardwareDistribution, installation
Vue de déploiement
Vue des cas d’utilisationServices pour les utilisateursVue des cas d’utilisation
Services pour les utilisateurs
4 + 1 vues d'architecture
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 106
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
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 107
Rational Unified Process (RUP)Dirigé par les cas d'utilisation (2)
Capturer, définirclarifier les
cas d’utilisation
Analyse
Réaliser lescas d’utilisation
Conceptionet codage
Test
Cas d’utilisation
Vérifier lescas d’utilisation
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 108
Rational Unified Process (RUP)Dirigé par les cas d'utilisation (3)
Use CaseModel
AnalysisModel
DesignModel
TestModel
DeploymentModel
ImplementationModel
specified by
realized bydistributed by
implemented by
verified by
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 109
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élisationpar cas
d'utilisation
Client
Besoins
Accord sur le modèle de cas
Questions/réponses
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 110
Rational Unified Process (RUP) Rôles et flots : définition des besoins
Find Use Casesand Actors
Describe theUse-Case Model
Review theUse-Case Model
Use-Case-ModelArchitect
Use-CaseSpecifier
RequirementsReviewer
Architect
Structure theUse-Case Model
Capture aCommon
Vocabulary
Describe aUse Case
Prioritize Use Cases
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 111
Rational Unified Process (RUP) Rôles et flots : analyse et conception
Architect
Use-CaseDesigner
Designer
DesignReviewer
Architectural Analysis
Review theDesign
Review theAnalysis
Review theArchitecture
Object DesignObject Analysis
Use-Case DesignUse-Case Analysis
Architectural Design Describe Concurrency Describe Distribution
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 112
Rational Unified Process (RUP) Rôles et flots : implémentation
IntegrateSystem
Architect
System Integrator
Implementer
Code Reviewer
ImplementClasses
PerformUnit Test
Define the Organizationof Subsystems
IntegrateSubsystem
Review Code
Fix a Defect
Plan SystemIntegration
Plan SubsystemIntegration
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 113
Rational Unified Process (RUP) Rôles et flots : test
Design Test
ImplementTest
Test Designer
IntegrationTester
System Tester
EvaluateTest
Execute IntegrationTest
Execute SystemTest
Designer
Design Test Classesand Packages
ImplementerImplement Test Components
and Subsystems
PlanTest
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 114
Méthodologies agiles
Motivation 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…)
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 115
Méthodologies agilesThe 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.
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 116
Méthodologies agilesThe Agile Manifesto : principes agiles
Our highest priority is to satisfy the customerthrough early and continuous deliveryof 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.
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 117
Méthodologies agilesAgile Unified Process (UP) (1)
Déclinaison agile du RUP Reprend les caractéristiques du RUP
4 phases, deux dimensions Dirigé par les cas d’utilisation 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 l’implémentation Modélisation légère Incompatibilité totale avec un processus waterfall
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 118
Méthodologies agilesAgile Unified Process (UP) (2)
Propriétés des itérations Itérations courtes (1 à 4 semaines) fixées à l’avance 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
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 119
Méthodologies agilesAgile Unified Process (UP) (3)
Utilisation d’UML UML est utilisé en mode esquisse
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
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 120
Méthodologies agilesAgile 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 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
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 121
Méthodologies agilesAgile Unified Process (UP) (5)
Contenu typique des quatre phases
InceptionInception
FinalitéOpportunitéEstimations
ÉlaborationÉlaboration
Implémentationitérative du noyau à hautrisque et/ou àhaute valeur
(10-20% des UC)
ConstructionConstruction
Implémentationitérative
du reste des fonctionnalités
TransitionTransition
-tests,déploiement
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 122
Méthodologies agilesAgile Unified Process (UP) (6)
Disciplines de UP 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…)
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 123
Méthodologies agilesExtreme 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 D ’où l’importance des tests continuels !
Normes de codage strictes Programmation à deux (pair programming)…
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 124
Méthodologies agilesScrum
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 !
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 125
Estimation des coûts de développementModèle cocomo ii (1)
Estimation du coût en hommesmois à partir de la taille du projet
H résultat (hommesxmois)S taille du projetA une constantemi facteurs multiplicatifs
wi facteurs d’échelle
i
i
w
SAmH
01,001,1
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 126
Estimation des coûts de développementModè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 l’information associée aux entrées-sorties et aux fichiers utilisés
Disponible assez tôt dans le développement
Facteurs d’échelle wi (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)
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 127
Estimation des coûts de développementModèle cocomo ii (3)
Facteurs multiplicatifs mi (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
d ’exé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 l’application 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
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 128
Estimation des coûts de développementModèle cocomo ii (4)
Problèmes délicats Unité hommesmois 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 ?
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 129
Introduction au Génie logiciel
Références
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 130
Bugs logiciels
Les moteurs de recherche comme Google permettent de trouver rapidement des informations sur les bugs cités.
Ci-après, quelques points d’entrée… Listes de fiascos
http://www.cs.tau.ac.il/~nachumd/verify/horror.html http://www5.in.tum.de/~huckle/bugse.html
Ariane 5 http://www.ima.umn.edu/~arnold/disasters/ariane5rep.html http://archive.eiffel.com/doc/manuals/technology/contract/a
riane/page.html
http://www.irisa.fr/pampa/EPEE/Ariane5-comments.html
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 131
Ouvrages et articles généraux
Interview de Bill GatesFocus Magazine, n° 43, octobre 1995
http://www.cantrip.org/nobugs.html No Silver Bullet
Fred Brooks http://www.virtualschool.edu/mon/SoftwareEngineering/Broo
ksNoSilverBullet.html
The Mythical Man-Month (20th anniversary edition)Fred Brooks, Addison-Wesley, 1995
Les avatars du logicielLauren Ruth Wiener, Addison-Wesley, 1994
Anti-PatternsWilliam H. Brown et al., Wiley, 1998
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 132
L ’échec du waterfall
IT Projects Sink or SwimM. Thomas, Computer Bulletin, British Computer Society, January 2000
ROI, It’s Your JobJim Johnson, XP 2002, Sardinia, Italy, 2002(ROI = Return On Investment)
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 133
Monographies sur le génie logiciel
Software Engineering (7th Edition)Ian Sommerville, Addison-Wesley, 2004
A Discipline for Software EngineeringWatts 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 IIBarry W. Boehm, Prentice Hall, 2000)
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 134
UML, le RUP, et Agile UP
UML Distilled (3rd Edition)Martin Fowler, Addison-Wesley, 2004
UML 2 et les design patterns (3e édition)Craig Larman, Pearson Education, 2005
The Unified Software Development ProcessIvar 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 RUPPer Kroll, Philippe Kruchten, Addison-Wesley, 2003
Agile and Iterative Development: A Manager's GuideCraig Larman, Addison-Wesley, 2003
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 135
Méthodologies agiles
Manifeste agile http://agilemanifesto.org http://agilealliance.com
EXtreme Programming http://www.extremeprogramming.org eXtreme Programming eXplained
Kent Beck, Addison-Wesley, 2000 eXtreme Programming Installed
Ron Jeffries et al., Addison-Wesley, 2001 Scrum
Agile Project Management with ScrumKen Schwaber, Microsoft Press, 2004
http://www.controlchaos.com
© 2005-2006 Jean-Paul Rigault
11/04/23 04:01 136
Introduction au Génie logiciel
Fin…
Top Related