© 2005-2006 jean-paul rigault 05/05/2014 08:42 1 introduction au génie logiciel jean-paul rigault...

© 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]


11/04/23 04:00 2

Plan

Quelques histoires horrifiques Problématique du génie logiciel Méthodologies de développement


11/04/23 04:00 3


Quelques histoires horrifiques


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


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 ?


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…


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


11/04/23 04:00 8


À 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


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é


11/04/23 04:00 10


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


11/04/23 04:00 11


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é…


11/04/23 04:00 12


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


11/04/23 04:00 13


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


11/04/23 04:00 14


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)


11/04/23 04:00 15


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 !


11/04/23 04:00 16


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


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


11/04/23 04:00 18


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


11/04/23 04:00 19


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


11/04/23 04:00 20


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.


11/04/23 04:00 21


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


11/04/23 04:00 22


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


11/04/23 04:00 23


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 !)


11/04/23 04:00 24


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


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


11/04/23 04:00 26


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


11/04/23 04:00 27


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


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


11/04/23 04:00 29


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


11/04/23 04:00 30


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


11/04/23 04:00 31


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.


11/04/23 04:00 32


« 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é


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


11/04/23 04:00 34


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 !


11/04/23 04:00 35


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 ?


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.


11/04/23 04:00 37


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


11/04/23 04:00 38


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


11/04/23 04:00 39


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


11/04/23 04:00 40


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…


11/04/23 04:00 41


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


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


11/04/23 04:01 43


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é


11/04/23 04:01 44


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 !


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


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 !


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


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…


11/04/23 04:01 49


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


11/04/23 04:01 50


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


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


11/04/23 04:01 52


Problématique du génie logiciel


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


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


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


11/04/23 04:01 56


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é »


11/04/23 04:01 57


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


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


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


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


11/04/23 04:01 61


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


11/04/23 04:01 62



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


11/04/23 04:01 63



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 !


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


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 !


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)


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 !


11/04/23 04:01 68


É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


11/04/23 04:01 69


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)


11/04/23 04:01 70


Méthodologies de développement


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


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


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)


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)


11/04/23 04:01 75


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…


11/04/23 04:01 76


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)


11/04/23 04:01 77


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…


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


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


11/04/23 04:01 80


DoD2167a : méthodologie du département de la défense des USA(le langage de développement est Ada)


11/04/23 04:01 81


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


11/04/23 04:01 82


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é…


11/04/23 04:01 83


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


11/04/23 04:01 84


Étude de M. Thomas (2001) : 1027 projets, 13 % de succès (130) !


11/04/23 04:01 85


Étude de M. Thomas (2001) : 1027 projets, 13 % de succès ! (suite)


11/04/23 04:01 86


É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%


11/04/23 04:01 87

Exemples de méthodologiesDéveloppement en spirale (1)


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 »


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


11/04/23 04:01 90


Analyse dedomaine

Analyse OO

Conception OO

Codage et tests

Expression des besoinsIntégration, validation,

maintenance,management,

etc.


11/04/23 04:01 91


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


11/04/23 04:01 92


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


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


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


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


11/04/23 04:01 96


ModelElement

Diagram

“chose”

Relation

Abstractions, objets de 1ère classe

Relie les choses entre elles

Visualise des choses et leurs relations


11/04/23 04:01 97


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


11/04/23 04:01 98

Diagrammes

dynamiques


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


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 !


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


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


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


11/04/23 04:01 103


Itération préliminaire

Itération d'architecture

Itération d'architecture

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


11/04/23 04:01 104


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


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


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


11/04/23 04:01 107


Capturer, définirclarifier les

cas d’utilisation

Analyse

Réaliser lescas d’utilisation

Conceptionet codage

Test

Cas d’utilisation

Vérifier lescas d’utilisation


11/04/23 04:01 108


Use CaseModel

AnalysisModel

DesignModel

TestModel

DeploymentModel

ImplementationModel

specified by

realized bydistributed by

implemented by

verified by


11/04/23 04:01 109


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


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


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


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


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


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…)


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.


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.


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


11/04/23 04:01 118


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


11/04/23 04:01 119


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


11/04/23 04:01 120


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


11/04/23 04:01 121


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


11/04/23 04:01 122


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…)


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)…


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 !


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


11/04/23 04:01 126


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)


11/04/23 04:01 127


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


11/04/23 04:01 128


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 ?


11/04/23 04:01 129


Références


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


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


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)


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)


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


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


11/04/23 04:01 136


Fin…

© 2005-2006 jean-paul rigault 05/05/2014 08:42 1 introduction au génie logiciel jean-paul rigault...

Documents