Introduction au Génie logiciel

Introduction au Génie logiciel
Jean-Paul Rigault École polytechnique de l’université de Nice Département de sciences informatiques 30/03/ :42

Plan Quelques histoires horrifiques Problématique du génie logiciel
Méthodologies de développement 30/03/ :42

Quelques histoires horrifiques 30/03/ :42

Quelques histoires horrifiques Pour commencer
Une plaisanterie (?) anonyme If the automobile industry had developed like the software industry, we would all be driving $25 cars that get 1,000 miles per gallon. Yeah, and if cars were like software, they would crash twice a day for no reason, and when you call service, they’d tell you to reinstall the engine. L’avis d’un expert There are no significant bugs in our released software that any significant number of users want fixed. Bill Gates, interview à l’hebdomadaire allemand Focus, n° 43, 23 octobre1995, pages 30/03/ :42

Quelques histoires horrifiques Contenu
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 ? 30/03/ :42

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… 30/03/ :42

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

À 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 30/03/ :42

Quelques bugs célèbres Tests de non régression (3)
Apollo 11, premier alunissage du module lunaire (1969) Données absurdes et alarmes logicielles intempestives lors de l’alunissage (calcul de la trajectoire) Amstrong atterrit manuellement, sans aucune marge de sécurité 30/03/ :42

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 30/03/ :42

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é… 30/03/ :42

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 30/03/ :42

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 30/03/ :42

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) 30/03/ :42

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 ! 30/03/ :42

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 30/03/ :42

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 30/03/ :42

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 30/03/ :42

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 30/03/ :42

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. 30/03/ :42

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 30/03/ :42

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 30/03/ :42

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 !) 30/03/ :42

Observation de la couche d’ozone ( ) 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 30/03/ :42

Quelques bugs célèbres Tests 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 30/03/ :42

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 30/03/ :42

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 30/03/ :42

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

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 30/03/ :42

Sonde Mariner I, mission vers Vénus (1962) Le bug suivant, trouvé dans le code Fortran de Mariner I, ne semble pas avoir eu de conséquence DO5I = 1.5 C’est une affectation ! L’instruction correcte (une boucle pour I variant de 1 à 5) aurait du être DO5I = 1,5 ou plutôt DO 5 I = 1, 5 30/03/ :42

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. 30/03/ :42

« 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é 30/03/ :42

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

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 ! 30/03/ :42

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 ? 30/03/ :42

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

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 30/03/ :42

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 30/03/ :42

Système de manipulation automatique des bagages de l’aéroport de Denver ( ) Système « pharaonique » 4000 véhicules (telecars), 3 terminaux, plus de 30 km de circuit, 300 ordinateurs 193 M$ (12 % du coût total) Toutes les compagnies devaient être desservies 30/03/ :42

Système de manipulation automatique des bagages de l’aéroport de Denver ( ) (suite 1) Chaos total lors des tests Bagages détruits (même « mâchés » !) Crashes, collisions, détérioration des rails… Blocage des telecars par les bagages qu’ils détruisaient… 30/03/ :42

Système de manipulation automatique des bagages de l’aéroport de Denver ( ) (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 30/03/ :42

Quelques bugs célèbres Informatisation 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 30/03/ :42

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é 30/03/ :42

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

Pourquoi le logiciel est-il sujet aux bugs
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 30/03/ :42

Pourquoi le logiciel est-il sujet aux bugs
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 ( ) Interférence entre les systèmes de défense d’Air Force One et portes de garage automatiques Le clip ! 30/03/ :42

Pourquoi le logiciel est-il sujet aux bugs ? Une remarque… fondamentale
En matière de bug logiciel, l’erreur est toujours d’origine humaine 30/03/ :42

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… 30/03/ :42

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 777 No! (What part of this don’t you understand?) Affiche (« Outil de gestion ») du projet logiciel du B777 30/03/ :42

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 30/03/ :42

Quelques histoires horrifiques Pour conclure (provisoirement) ces histoires
30/03/ :42

Problématique du génie logiciel 30/03/ :42

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

Problématique du génie logiciel Plan
Le génie logiciel : origine et définition Le coût des développements de logiciel Buts et moyens du génie logiciel Évaluation de la qualité du logiciel 30/03/ :42

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 30/03/ :42

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é » 30/03/ :42

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 30/03/ :42

Le coût des développements de logiciel Nature des coûts
Peu de capitaux nécessaires Frais de personnel très élevés Hauts salaires Frais de formation Coûts de développement variables selon les applications Pour les systèmes à longue durée de vie, coûts de maintenance élevés 30/03/ :42

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

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 30/03/ :42

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 30/03/ :42

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 30/03/ :42

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 ! 30/03/ :42

É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 30/03/ :42

Évaluation de la qualité du logiciel Normes 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 ! 30/03/ :42

Évaluation de la qualité du logiciel Capability 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) 30/03/ :42

Évaluation de la qualité du logiciel CMMI : niveaux de maturité (1)
Amélioration continue du processus Optimizing 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 ! 30/03/ :42

É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 30/03/ :42

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) 30/03/ :42

Méthodologies de développement 30/03/ :42

Méthodologies de développement Contenu
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 30/03/ :42

Méthode, méthodologie et cycle de vie (1)
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 30/03/ :42

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) 30/03/ :42

Méthode, méthodologie et cycle de vie Activités lors du processus (1)
Définition des besoins (Requirements) Expression des besoins dans le langage du client Spécifications Traduction des besoins dans un langage plus informatique Description du système 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) 30/03/ :42

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… 30/03/ :42

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) 30/03/ :42

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… 30/03/ :42

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

Exemples de méthodologies Développement en cascade (waterfall) (1)
Analyse des besoins Spécification Conception Codage Test Validation Recette 30/03/ :42

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

Cycle en V (!) Variante du waterfall Distingue deux branches Production de code Tests Place en regard les activités liées Analyse des besoins Recette Spécification Validation Conception Test Codage 30/03/ :42

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é… 30/03/ :42

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 30/03/ :42

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

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

É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 30/03/ :42

Exemples de méthodologies Développement en spirale (1)
30/03/ :42

Exemples de méthodologies Dé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 » 30/03/ :42

Exemples de méthodologies Processus modernes « orientés objets » (1)
Le paradigme objet favorise la réutilisation le développement incrémental (et donc itératif) et donc 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 30/03/ :42

Analyse de domaine Intégration, validation, maintenance, management, etc. Expression des besoins Analyse OO Conception OO Codage et tests 30/03/ :42

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 30/03/ :42

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 30/03/ :42

D’UML au RUP Un peu d’histoire
1.0 1.1 OMG request UML consortium OMG OMG vote Nombreuses méthodes d’ACOO (50+) Coad-Yourdon Shlaer-Mellor Fusion etc. Booch (Rose) Conception, codage Rumbaugh (OMT) Analyse OO, données Jacobson (OOSE) Expression des besoins U M L 0.8 0.9 Rational U M L 1.2 U M L 1.3 U M L 1.4 U M L 1.5 U M L 2.0 1991 1992 1993 1994 1995 1996 1997 1998 … 2004 30/03/ :42

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

D’UML au RUP Qu’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 State Diagrams Use Case Scenario Collaboration Component Deployment Object Statechart Sequence Class Activity Model Elements 30/03/ :42

“chose” Abstractions, objets de 1ère classe Conceptually UML is composed of 3 main types of modelling elements or building blocks.. We will see most of them in much more detail in the following of the training. The first modelling element type are the “things”. Here we use the term of “thing” to avoid words such as “object” or “component” which have a precise meaning in UML.. They are the main elements of UML diagrams, they can be divided into structural (classifiers), behavioural, organisational and annotational things. Structural "things” The "nouns" of the model USE CASE, CLASS, COLLABORATION, COMPONENT , NODE, ACTIVE CLASS , INTERFACE Behavioural "things” The "verbs" of the model INTERACTION, STATE MACHINE Organisational (grouping) "things” PACKAGE Annotational "things” NOTE Second, relationships are connections among things. The last type of modelling elements are the diagrams that group connected/related model elements represented in a graphical form. ModelElement Relation Relie les choses entre elles Diagram Visualise des choses et leurs relations 30/03/ :42

Class Interface Collaboration Active Class Component Node Structure “chose” Use Case Interaction Comportement This tree represents all the model elements existing in UML 1.x; we will see most of them during these 3 days. State Machine Organisation Package Annotation Note ModelElement Dependency Association Relation Generalization Realization Class Object Use Case Diagram Sequence Collaboration State-Transition Activity Component Deployment 30/03/ :42

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 As we have seen the modelling activity requires to provide several views of the same product, in our case a software system. UML provides mainly four of types of views a sort of functional view (UC) a view of the software architecture (classes & objects), a view of the behaviour of the system (how the control goes) and a realisation view of physical (hardware) components. These views are represented in different sorts of diagrams. UML offers the notations and semantics for nine types of diagrams. Each type of diagram captures a different perspective of the underlying model of the system, with different degrees of abstraction. For any of the diagram types, multiple diagrams of that type may exist. These diagrams are categorised here into interaction, static, dynamic, etc. diagrams. In blue on the slide are the static diagrams, the other are dynamic ones, UC diagrams are in between (both static and dynamic). Class diagrams describe classes and their relationships. Use-case diagrams show the interface between the system and the outside world. Interaction (sequence and collaboration) diagrams show the behaviour of systems in terms of how objects interact with each other. State and activity diagrams show how systems behave “internally”. Component and deployment diagrams show how the various components of a system are arranged logically and physically. During the rest of this training we will detail each of these 9 sorts of diagrams, starting with UC and ending with deployment diagrams. Diagrammes d’interaction Diagrammes dynamiques Diagrammes d’états-transitions Diagrammes statiques (d’implémentation) Diagrammes d’UML 1.x 30/03/ :42

D’UML au RUP Diverses 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 ! 30/03/ :42

D’UML au RUP Diverses 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 30/03/ :42

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 30/03/ :42

Rational Unified Process (RUP) Itératif et incrémental (1)
Quatre phases majeures temps Inception Élaboration Construction Transition Quoi ? Pour qui ? Combien ? Étude de marché Opportunité économique Analyse des besoins Modélisation du domaine Développement du produit Gestion des changements Transfert vers les utilisateurs 30/03/ :42

Chaque phase est composée d’itérations, chaque itération se concluant par un produit ou un prototype Itération préliminaire Itération d'architecture Itération de développement Itération de transition Inception Élaboration Construction Transition Maquette Prototype d'architecture Prototype de développement Version bêta Distribution 30/03/ :42

Un processus à deux dimensions 30/03/ :42

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

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 30/03/ :42

Analyse Capturer, définir clarifier les cas d’utilisation Conception et codage Réaliser les cas d’utilisation Test Cas d’utilisation Vérifier les cas d’utilisation 30/03/ :42

Use Case Model specified by implemented by Analysis Model realized by distributed by verified by Design Model Deployment Model Implementation Model Test Model 30/03/ :42

Besoins Modélisation par cas d'utilisation Questions/réponses Accord sur le modèle de cas Client 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 » 30/03/ :42

Rational Unified Process (RUP) Rôles et flots : définition des besoins
30/03/ :42

Rational Unified Process (RUP) Rôles et flots : analyse et conception
30/03/ :42

Rational Unified Process (RUP) Rôles et flots : implémentation
30/03/ :42

Rational Unified Process (RUP) Rôles et flots : test
30/03/ :42

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…) 30/03/ :42

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

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

Méthodologies agiles Agile Unified Process (UP) (1)
Déclinaison agile du RUP Reprend les caractéristiques du RUP 4 phases, deux dimensions Dirigé par les cas 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 30/03/ :42

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 30/03/ :42

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 30/03/ :42

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 30/03/ :42

Contenu typique des quatre phases Inception Élaboration Construction Transition Finalité Opportunité Estimations Implémentation itérative du noyau à haut risque et/ou à haute valeur (10-20% des UC) Implémentation itérative du reste des fonctionnalités b-tests, déploiement 30/03/ :42

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…) 30/03/ :42

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

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

Estimation des coûts de développement Modèle cocomo ii (1)
Estimation du coût en hommesmois à partir de la taille du projet H résultat (hommesxmois) S taille du projet A une constante mi facteurs multiplicatifs wi facteurs d’échelle 30/03/ :42

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) 30/03/ :42

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 30/03/ :42

Problèmes délicats Unité hommesmois discutable (voir Fred Brooks) Estimation du nombre de Kloc Dépend du langage Dépend du mode de production (e.g., code généré ?) Pas toujours disponible tôt Adaptation aux processus agiles ? 30/03/ :42

Références 30/03/ :42

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 Ariane 5 30/03/ :42

Ouvrages et articles généraux
Interview de Bill Gates Focus Magazine, n° 43, octobre 1995 No Silver Bullet Fred Brooks The Mythical Man-Month (20th anniversary edition) Fred Brooks, Addison-Wesley, 1995 Les avatars du logiciel Lauren Ruth Wiener, Addison-Wesley, 1994 Anti-Patterns William H. Brown et al., Wiley, 1998 30/03/ :42

L’échec du waterfall IT Projects Sink or Swim M. Thomas, Computer Bulletin, British Computer Society, January 2000 ROI, It’s Your Job Jim Johnson, XP 2002, Sardinia, Italy, 2002 (ROI = Return On Investment) 30/03/ :42

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

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 Process Ivar Jacobson, Grady Booch, James Rumbaugh, Addison-Wesley, 1999 The Rational Unified Process: An Introduction (3rd Edition) Philippe Kruchten, Addison-Wesley, 2003 The Rational Unified Process Made Easy: A Practitioner's Guide to RUP Per Kroll, Philippe Kruchten, Addison-Wesley, 2003 Agile and Iterative Development: A Manager's Guide Craig Larman, Addison-Wesley, 2003 30/03/ :42

Méthodologies agiles Manifeste agile http://agilemanifesto.org
EXtreme Programming eXtreme Programming eXplained Kent Beck, Addison-Wesley, 2000 eXtreme Programming Installed Ron Jeffries et al., Addison-Wesley, 2001 Scrum Agile Project Management with Scrum Ken Schwaber, Microsoft Press, 2004 30/03/ :42

Fin… 30/03/ :42

Introduction au Génie logiciel

Présentations similaires

Présentation au sujet: "Introduction au Génie logiciel"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

Introduction au Génie logiciel

Présentations similaires

Présentation au sujet: "Introduction au Génie logiciel"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back