CNAM - Nancy 2003

Jacques Lonchamp

PREMIERE PARTIE Dfinitions gnrales, principes, processus.

1. Dfinition et objectifs du gnie logiciel (GL)

1.1. Dfinition Domaine des sciences de lingnieur dont la finalit est la conception, la fabrication et la maintenance de systmes logiciels complexes, srs et de qualit (Software Engineering en anglais). Aujourdhui les conomies de tous les pays dvelopps sont dpendantes des systmes logiciels. Le GL se dfinit souvent par opposition la programmation, cest dire la production dun programme par un individu unique, considre comme facile. Dans le cas du GL il sagit de la fabrication collective dun systme complexe, concrtise par un ensemble de documents de conception, de programmes et de jeux de tests avec souvent de multiples versions ( multi-person construction of multi-version software ), et considre comme difficile. 1.2. Objectifs la rgle du CQFD Le GL se proccupe des procds de fabrication des logiciels de faon sassurer que les 4 critres suivants soient satisfaits. Le systme qui est fabriqu rpond aux besoins des utilisateurs (correction fonctionnelle). La qualit correspond au contrat de service initial. La qualit du logiciel est une notion multiforme qui recouvre : la validit : aptitude d'un logiciel raliser exactement les tches dfinies par sa spcification, la fiabilit : aptitude d'un logiciel assurer de manire continue le service attendu, la robustesse : aptitude d'un logiciel fonctionner mme dans des conditions anormales, lextensibilit : facilit d'adaptation d'un logiciel aux changements de spcification, la rutilisabilit : aptitude d'un logiciel tre rutilis en tout ou partie, la compatibilit : aptitude des logiciels pouvoir tre combins les uns aux autres, lefficacit : aptitude d'un logiciel bien utiliser les ressources matrielles telles la mmoire, la puissance de lU.C., etc. la portabilit : facilit tre port sur de nouveaux environnements matriels et/ou logiciels, la traabilit : capacit identifier et/ou suivre un lment du cahier des charges li un composant d'un logiciel, la vrifiabilit : facilit de prparation des procdures de recette et de certification, lintgrit : aptitude d'un logiciel protger ses diffrents composants conte des accs ou des modifications non autoriss, la facilit d'utilisation, dentretien, etc. Les cots restent dans les limites prvues au dpart. Les dlais restent dans les limites prvues au dpart. Rgle du CQFD : Cot Qualit Fonctionnalits Dlai.

Ces qualits sont parfois contradictoires (chic et pas cher !). Il faut les pondrer selon les circonstances (logiciel critique / logiciel grand public). Il faut aussi distinguer les systmes sur mesure et les produits logiciels de grande diffusion. 1.3. Ltat des lieux Le GL est apparu dans les annes 70 pour rpondre la crise du logiciel. Cette crise est apparue lorsque lon a pris conscience que le cot du logiciel dpassait le cot du matriel. Aujourdhui il le dpasse trs largement.
Cot logiciel vs matriel 100%

La crise du logiciel

50%

50

60

70

80

90

2000

Figure 1.1 La crise du logiciel

Un autre symptme de cette crise se situe dans la non qualit des systmes produits. Les risques humains et conomiques sont importants, comme lillustrent les quelques exemples clbres suivants : arrt de Transpac pour 7.000 entreprises et 1.000.000 d'abonns : surcharge du rseau, TAURUS, un projet d'informatisation de la bourse londonienne : dfinitivement abandonn aprs 4 annes de travail et 100 millions de de pertes, mission VENUS : passage 500.000 km au lieu de 5.000 km cause du remplacement d'une virgule par un point, avion F16 dclar sur le dos au passage de l'quateur : non prise en compte du rfrentiel hmisphre sud, avion C17 de McDonnell Douglas livr avec un dpassement de 500 millions de $ ... (19 calculateurs htrognes et 6 langages de programmation diffrents), faux dpart de la premire navette Colombus : manque de synchro entre calculateurs assurant la redondance (un dlai modifi de 50ms 80 ms entranant une chance sur 67 dannulation par erreur de la procdure de tir), non reconnaissance de l'EXOCET dans la guerre des Malouines : Exocet non rpertori comme missile ennemi : 88 morts, non diffrenciation entre avion civil et avion militaire : guerre du Golfe - Airbus iranien abattu : 280 morts, mauvais pilote automatique de la commande dune bombe au cobalt en milieu hospitalier : 6 morts, chec dAriane 501 (cf. exercice 1.1 ci -dessous). D'aprs le cabinet de conseil en technologies de l'information Standish Group International, les pannes causes par des problmes de logiciel ont cot l'an dernier aux entreprises du monde entier environ 175 milliards de dollars, soit deux fois plus au moins qu'il y a 2 ans (Le Monde 23/10/01).

La solution imagine pour rpondre cette crise t lindustrialisation de la production du logiciel : organisation des procds de production (cycle de vie, mthodes, notations, outils), des quipes de dveloppement, plan qualit rigoureux, etc. Malgr tout le GL reste aujourdhui moins avanc (formalis, mathmatique) et moins bien codifi que dautres sciences de lingnieur, comme le gnie civil qui construit des routes et des ponts, ou le gnie chimique. Une des raisons est la nature mme du logiciel : le logiciel est un objet immatriel (pendant son dveloppement), trs mallable au sens de facile modifier (cf. hardware/software ), ses caractristiques attendues sont difficiles figer au dpart et souvent remises en cause en cours de dveloppement, les dfaillances et erreurs ne proviennent ni de dfauts dans les matriaux ni de phnomnes dusure dont on connat les lois mais derreurs humaines, inhrentes lactivit de dveloppement, le logiciel ne suse pas, il devient obsolte (par rapport aux concurrents, par rapport au contexte technique, par rapport aux autres logiciels, ...), le dveloppement par assemblage de composants est encore balbutiant dans le domaine logiciel (beans, EJB, composants CORBA, ...). Cependant, grce au GL des progrs ont t raliss. Mais la complexit des systmes ne cesse de saccrotre. Exemple : Compilateur C : 10 HA (Homme/annes), 20 30 KLS (milliers de lignes source) Compilateur Ada : 120 150 HA Logiciel 2D/3D : 50 150 HA, >200KLS SGBD (Oracle, DB2) : 300 500 HA Navette spatiale : > 1000 HA, 2 200 KLS, 6 ans, langage HAL Les exigences varient selon le type des logiciels. Exemple : dfauts rsiduels Navette spatiale : - logiciels embarqus : 0,1 dfaut par KLS (1/10000 lignes) - logiciels au sol : 0,4 dfaut par KLS (1/2500) 1.4 Caractristiques Le GL est en forte relation avec presque tous les autres domaines de linformatique : langages de programmation (modularit, orientation objet, paralllisme, ...), bases de donnes (modlisation des donnes, de leur dynamique, ...), informatique thorique (automates, rseaux de Petri, types abstraits, ...), etc. Comme le gnie chimique utilise la chimie comme un outil pour rsoudre des problmes de production industrielle, le GL utilise linformatique comme un outil pour rsoudre des problmes de traitement de linformation. Le GL est aussi en relation avec dautres disciplines de lingnieur : ingnierie des systmes et gestion de projets, sret et fiabilit des systmes, etc. Les principales branches du GL couvrent : la conception, la validation/vrification, la gestion de projet et lassurance qualit, les aspects socio-conomiques.

Dans sa partie technique, le GL prsente un spectre trs large depuis des approches trs formelles (spcifications formelles, approches transformationnelles, preuves de programmes) jusqu' des dmarches absolument empiriques. Cette varit reflte la varit des types de systmes produire : gros systmes de gestion (systmes dinformation) ; le plus souvent des systmes transactionnels construits autour dune base de donne centrale ; systmes temps-rel, qui doivent rpondre des vnements dans des limites de temps prdfinies et strictes ; systmes distribus sur un rseau de machines (distribution des donnes et/ou des traitements), nouvelles architectures lies Internet ; systmes embarqus et systmes critiques, interfacs avec un systme contrler (ex: aronautique, centrales nuclaires, ... ). 1.5. Plan du cours Le GL est difficile enseigner car trs vaste, pas toujours trs prcis (beaucoup de discours gnraux), foisonnant dans les concepts et le vocabulaire, sensible aux effets de modes. Les aspects techniques ncessitent une bonne matrise des outils fondamentaux de linformatique (programmation, BD, systme/rseau, ...). Le discours peut sorganiser selon quatre niveaux : quelques principes gnraux, des techniques spcialises, qui sappuient sur ces principes (il en existe des dizaines), des mthodes, qui relient plusieurs techniques en un tout cohrent et organis (il en existe des centaines), des outils, qui supportent les mthodes (il en existe des milliers). Les plus complexes sont appels ateliers (ou environnements) de GL. Le cours commence par une courte partie sur les principes et sur leur traduction dans les modles de cycle de vie du logiciel. La partie la plus importante est consacre aux techniques (survol des principales techniques de spcification, de conception, de vrification). Une mthode est ensuite tudie (UML). On y retrouve certaines techniques voques prcdemment. Enfin, les questions lies la gestion du dveloppement des logiciels sont abordes brivement la fin du cours (aspects humains et conomiques).

principes techniques mthodes outils

Figure 1.2 Les 4 niveaux de discours

2. Les principes
Cette partie liste sept principes fondamentaux (proposs par Carlo Ghezzi): rigueur, sparation des problmes ( separation of concerns ), modularit, abstraction, anticipation du changement, gnricit, construction incrmentale. 2.1. Rigueur La production de logiciel est une activit crative, mais qui doit se conduire avec une certaine rigueur. Certains opposent parfois crativit et rigueur. Il ny a pas contradiction : par exemple, le rsultat d'une activit de cration pure peut tre valu rigoureusement, avec des critres prcis. Le niveau maximum de rigueur est la formalit, cest dire le cas o les descriptions et les validations sappuient sur des notations et lois mathmatiques. Il nest pas possible dtre formel tout le temps : il faut bien construire la premire description formelle partir de connaissances non formalises ! Mais dans certaines circonstances les techniques formelles sont utiles. 2.2. "Sparation des problmes" Cest une rgle de bons sens qui consiste considrer sparment diffrents aspects dun problme afin den matriser la complexit. Cest un aspect de la stratgie gnrale du diviser pour rgner . Elle prend une multitude de formes : sparation dans le temps (les diffrents aspects sont abords successivement), avec la notion de cycle de vie du logiciel que nous tudierons en dtail, sparation des qualits que lon cherche optimiser un stade donn (ex : assurer la correction avant de se proccuper de lefficacit), sparations des vues que lon peut avoir dun systme (ex : se concentrer sur laspect flots de donnes avant de considrer laspect ordonnancement des oprations ou flot de contrle), sparation du systme en parties (un noyau, des extensions, ), etc. Les mthodes aident organiser le travail en guidant dans la sparation et lordonnancement des questions traiter. 2.3. Modularit Un systme est modulaire sil est compos de sous-systmes plus simples, ou modules. La modularit est une proprit importante de tous les procds et produits industriels (cf. lindustrie automobile ou le produit et le procd sont trs structurs et modulaires).

La modularit permet de considrer sparment le contenu du module et les relations entre modules (ce qui rejoint lide de sparation des questions). Elle facilite galement la rutilisation de composants biens dlimits. Un bon dcoupage modulaire se caractrise par une forte cohsion interne des modules (ex : fonctionnelle, temporelle, logique, ...) et un faible couplage entre les modules (relations inter modulaires en nombre limit et clairement dcrites).

Fig. 2.1. La modularit

Toute lvolution des langages de programmation vise rendre plus facile une programmation modulaire, appele aujourdhui programmation par composants. 2.4. Abstraction Labstraction consiste ne considrer que les aspects jugs importants dun systme un moment donn, en faisant abstraction des autres aspects (cest encore un exemple de sparation des problmes). Une mme ralit peut souvent tre dcrite diffrents niveaux dabstraction. Par exemple, un circuit lectronique peut tre dcrit par un modle mathmatique trs abstrait (quation logique), ou par un assemblage de composants logiques qui font abstraction des dtails de ralisation (circuit logique), ou par un plan physique de composants rels au sein d'un circuit intgr. Labstraction permet une meilleure matrise de la complexit. 2.5. Anticipation du changement La caractristique essentielle du logiciel, par rapport dautres produits, est quil est presque toujours soumis des changements continuels (corrections d'imperfections et volutions en fonctions des besoins qui changent). Ceci requiert des efforts particuliers pour prvoir, faciliter et grer ces volutions invitables. Il faut par exemple : faire en sorte que les changements soient les plus localiss possibles (bonne modularit), tre capable de grer les multiples versions des modules et configurations des versions des modules, constituant des versions du produit complet. 2.6. Gnricit Il est parfois avantageux de remplacer la rsolution dun problme spcifique par la rsolution dun problme plus gnral. Cette solution gnrique (paramtrable ou adaptable) pourra tre rutilise plus facilement.

Exemple : plutt que dcrire une identification spcifique un cran particulier, crire (ou rutiliser) un module gnrique dauthentification (saisie dune identification - ventuellement dans une liste - et ventuellement dun mot de passe). 2.7. Construction incrmentale Un procd incrmental atteint son but par tapes en sen approchant de plus en plus ; chaque rsultat est construit en tendant le prcdent. On peut par exemple raliser dabord un noyau des fonctions essentielles et ajouter progressivement les aspects plus secondaires. Ou encore, construire une srie de prototypes simulant plus ou moins compltement le systme envisag. 2.8. Conclusion Ces principes sont trs abstraits et ne sont pas utilisables directement. Mais ils font partie du vocabulaire de base du gnie logiciel. Ces principes ont un impact rel sur beaucoup daspects (on le verra dans la suite du cours) et constituent le type de connaissance le plus stable, dans un domaine o les outils, les mthodes et les techniques voluent trs vite.

3. Les processus (modles de cycle de vie)

3.1. Dfinitions Comme pour toutes les fabrications, il est important davoir un procd de fabrication du logiciel bien dfini et explicitement dcrit et document. En GL, il sagit dun type de fabrication un peu particulier : en un seul exemplaire, car la production en srie est triviale (recopie). Les modles de cycle de vie du logiciel dcrivent un niveau trs abstrait et idalis les diffrentes manires dorganiser la production. Les tapes, leur ordonnancement, et parfois les critres pour passer dune tape une autre sont explicits (critres de terminaison dune tape - revue de documents -, critres de choix de ltape suivante, critres de dmarrage dune tape). Il faut souligner la diffrence entre tapes (dcoupage temporel) et activits (dcoupage selon la nature du travail). Il y a des activits qui se droulent dans plusieurs tapes (ex : la spcification, la validation et la vrification), voire dans toutes les tapes (ex : la documentation). Rappelons aussi la diffrence entre vrification et validation (B. Boehm, 76) : vrification : are we building the product right ? ( construisons nous le produit correctement ? - correction interne du logiciel, concerne les dveloppeurs), validation : are we building the right product ( construisons nous le bon produit ? - adaptation vis vis des besoins des utilisateurs, concerne les utilisateurs). 3.2. Le modle en cascade (waterfall) Historiquement, la premire tentative pour mettre de la rigueur dans le dveloppement sauvage (coder et corriger ou code and fix) a consist distinguer une phase danalyse avant la phase dimplantation (sparation des questions).
Analyse Implantation Fig.3.1 Le modle primitif 2 phases

Trs vite, pendant les annes 70, on sest aperu quun plus grand nombre dtapes taient ncessaires pour organiser le dveloppement des applications complexes. Il faut en particulier distinguer lanalyse du quoi faire ? qui doit tre valide par rapport aux objectifs poursuivis et la conception du comment faire? qui doit tre vrifie pour sa cohrence et sa compltude. Le modle en cascade (Fig. 3.2) dcrit cette succession (plus ou moins dtaille) dtapes ; sont reprsentes ici huit tapes fondamentales. Mme si on ltend avec des possibilits de retour en arrire, idalement limites la seule phase qui prcde celle remise en cause (Fig. 3.3), le dveloppement reste fondamentalement linaire. En particulier, il se fonde sur lhypothse souvent irraliste que lon peut ds le dpart dfinir compltement et en dtail ce quon veut

raliser (requirements ou expressions des besoins). La pratique montre que cest rarement le cas. Mme si elle nest pas raliste, cette reprsentation trs simplifie a permis de dfinir des cadres conceptuels (dfinition des diffrentes phases - cf. Fig. 3.4) et terminologiques, largement accepts et normaliss par plusieurs organismes (ISO, AFNOR, IEEE, DOD pour les applications militaires aux USA, ESA, etc.). Ceci facilite la gestion et le suivi des projets.
Etude prliminaire Analyse des besoins Analyse du systme Conception du systme Programmation et tests unitaires Intgration et tests dintgration Installation

Feasibility study Requirements analysis and specification System analysis Design

Coding and unit testing Integration and system testing Delivery Maintenance
Fig.3.2 Le modle en cascade Analyse des besoins Analyse du systme

Exploitation et maintenance

Conception du systme Programmation et tests unitaires Fig.3.3 Le modle en cascade avec itrations (quelques tapes) Etude prliminaire ou tude de faisabilit ou planification : (rapport danalyse prliminaire ou schma directeur) dfinition globale du problme, diffrentes stratgies possibles avec avantages/inconvnients, ressources, cots, dlais.

Analyse des besoins ou analyse pralable : (cahier des charges + plan qualit) qualits fonctionnelles attendues en termes des services offerts, qualits non fonctionnelles attendues : efficacit, sret, scurit, facilit dutilisation, portabilit, etc. qualits attendues du procd de dveloppement (ex : procdures de contrle qualit). Le cahier des charges peut inclure une partie destine aux clients (dfinition de ce que peuvent attendre les clients) et une partie destine aux concepteurs (spcification des besoins). Analyse du systme : (dossier danalyse + plan de validation) modlisation du domaine, modlisation de lexistant (ventuellement), dfinition dun modle conceptuel (ou spcification conceptuelle), plan de validation. Conception : (dossier de conception + plan de test global et par module) proposition de solution au problme spcifi dans lanalyse organisation de lapplication en modules et interface des modules (architecture du logiciel), description dtaille des modules avec les algorithmes essentiels (modle logique) structuration des donnes. Programmation et tests unitaires : (dossiers de programmation et codes sources) traduction dans un langage de programmation, tests avec les jeux dessais par module selon le plan de test. Intgration et tests de qualification : composition progressive des modules, tests des regroupements de modules, test en vraie grandeur du systme complet selon le plan de test global (alpha testing). Installation : Mise en fonctionnement oprationnel chez les utilisateurs. Parfois restreint dans un premier temps des utilisateurs slectionns (beta testing). Maintenance : maintenance corrective (ou curative), maintenance adaptative, maintenance perfective. + Activits transversales tout le cycle de vie : spcification, documentation, validation et vrification, management. Fig. 3.4 Un cadre conceptuel et terminologique

Des tudes ont t menes pour valuer le cot des diffrentes tapes du dveloppement:
Type de systme Gestion Scientifique Industriel Conception 44 44 46 Implantation 28 26 20 Test 28 30 34

Mais cest la maintenance qui cote le plus cher. 3.3. Le modle en V Le modle en V (Fig. 3.5) est une autre faon de prsenter une dmarche qui reste linaire, mais qui fait mieux apparatre les produits intermdiaires des niveaux

dabstraction et de formalit diffrents et les procdures dacceptation (validation et vrification) de ces produits intermdiaires. Le V est parcouru de gauche droite en suivant la forme de la lettre : les activits de construction prcdent les activits de validation et vrification. Mais lacceptation est prpare ds la construction (flches de gauche droite). Cela permet de mieux approfondir la construction et de mieux planifier la remonte. Chronologie
Orientation, faisabilit + Prparation de la .. Analyse des besoins analyse du systme Maintenance

validation
Tests d'acceptation systme

cahier des charges

vrification
Conception architecturale Tests d'intgration

spcifications architecturales Conception dtaille spcifications dtailles

vrification
Tests unitaires

logiciel

module

Codage Fig.3.5 Le modle en V

abstraction

3.3. Le modle incrmental Face aux drives bureaucratiques de certains gros dveloppements, et limpossibilit de procder de manire aussi linaire, le modle incrmental a t propos dans les annes 80 (Fig. 3.6). Le produit est dlivr en plusieurs fois, de manire incrmentale, cest dire en le compltant au fur et mesure et en profitant de lexprimentation oprationnelle des incrments prcdents. Chaque incrment peut donner lieu un cycle de vie classique plus ou moins complet. Les premiers incrments peuvent tre des maquettes (jetables sil sagit juste de comprendre les besoins des utilisateurs) ou des prototypes (rutilisables pour passer au prochain incrment en les compltant et/ou en optimisant leur implantation). Le risque de cette approche est celui de la remise en cause du noyau.

incrments dlivrs

Temps

Fig.3.6. Le modle incrmental

Le modle de Balzer associe dveloppement incrmental et utilisation de spcifications formalises, elles mme dveloppes de manire incrmentale et maintenues (Fig. 3.7).
Clients CdC Analyse Modification Adaptation Spcif. form.1 Spcif. form. n Gnration Maquette 1 Dveloppeurs In Fig. 3.7. Le modle de Balzer Out Maquette n Implmentation Maintenance Validation Spcifieurs

3.4. Le modle en spirale Enfin le modle en spirale, de Boehm (88), met laccent sur lvaluation des risques (Fig. 3.8). A chaque tape, aprs avoir dfini les objectifs et les alternatives, celles-ci sont values par diffrentes techniques (prototypage, simulation, ...), ltape est ralise et la suite est planifie. Le nombre de cycles est variable selon que le dveloppement est classique ou incrmental.

Dtermination des objectifs, des alternatives, des contraintes

Analyse des risques

Identification et rsolution des risques

srie de prototypes Plan du cycle de vie Plan du dveloppement Plan des tests et de l'intgration Planification des phases suivantes concept besoins

Conception dtaille

validation conception Validation et vrification Intgration Acceptation codification Tests unitaires Dveloppement, et vrification/validation

Spirales supplmentaires ventuellement (incrments)

Fig.3.8 Le modle en spirale

Les principaux risques et leurs remdes, tels que dfinis par Bohm, sont les suivants : dfaillance de personnel : embauches de haut niveau, formation mutuelle, leaders, adquation profil/fonction, ... calendrier et budgets irralistes : estimation dtaille, dveloppement incrmental, rutilisation, lagage des besoins, ... dveloppement de fonctions inappropries : revues dutilisateurs, manuel dutilisation prcoce, ... dveloppement dinterfaces utilisateurs inappropries : maquettage, analyse des tches, . produit plaqu or : analyse des cots/bnfices, conception tenant compte des cots, ... volatilit des besoins : dveloppement incrmental de la partie la plus stable dabord, masquage dinformation, ... problmes de performances : simulations, modlisations, essais et mesures, maquettage, exigences dmesures par rapport la technologie : analyses techniques de faisabilit, maquettage, ... tches ou composants externes dfaillants : audit des sous-traitants, contrats, revues, analyse de compatibilit, essais et mesures, ... 3.5. Les processus rels Il ny a pas de modle idal car tout dpend des circonstances. Le modle en cascade ou en V est risqu pour les dveloppements innovants car les spcifications et la conception risquent dtre inadquats et souvent remis en cause. Le modle incrmental est risqu car il ne donne pas beaucoup de visibilit sur le processus complet. Le modle de Balzer est risqu car il exige des spcialistes de trs haut niveau. Le modle en spirale est un canevas plus gnral qui inclut lvaluation des risques. Souvent, un mme projet peut mler diffrentes approches, comme le prototypage pour les sous-systmes haut risque et la cascade pour les sous systmes bien connus et faible risque. 3.6. Autres concepts lis aux processus 3.6.1. La r ingnierie des systmes Il sagit de retraiter ou de recycler des logiciels en fin de vie. Les vieux logiciels sont un capital fonctionnel qui peut tre de grande valeur par leur conception et leur architecture prouves. Le code source est adaptable aux nouvelles technologies : migration de chanes de traitements batch vers du transactionnel, fichiers bases de donnes, intgration de composants standards (progiciels), migration de transactionnel vers du client-serveur (down-sizing), migration du client-serveur vers des architectures 3 niveaux (ex : clients lgers sur le Web),

Il existe des outils (traducteurs de code source, fichiers BD, rorganisation de BD, etc.) 3.6.2. La normalisation des processus De nombreuses normes sont apparues dans les annes 90 pour valuer les processus en fonction de normes de qualit. Les socits sont certifies en fonction de leur respect de ces normes. a) le standard CMM du SEI (Software Engineering Institute du DoD - Department Of Defense des USA) : Le niveau de maturit du processus de dveloppement (CMM) se dcline en 5 niveaux de maturit pour les organisations qui dveloppent du logiciel : niveau 1 : initial. Processus chaotique, cest dire non disciplin et non prdictible. Cots, dlais, qualit non matriss. A traiter en priorit : gestion de projet, assurance qualit, gestion de configurations. niveau 2 : repeatable. Processus reproductible du point de vue de la gestion de projet, avec des estimations raisonnables en main doeuvre et en temps pour la classe de projets considre. Processus qui reste artisanal et trs li aux individus. Dlais fiables, mais qualit et cot variables. A traiter en priorit : mthodes et techniques danalyse et conception, revues par des pairs, formation, renforcement des contrles qualitatifs. niveau 3 : defined. Processus dfini aussi bien dans les aspects gestion de projet que dans les aspects ingnierie. Dlais et cots assez fiables. Qualit variable. Dfinition et suivi essentiellement de nature qualitative. A traiter en priorit : renforcement des contrles quantitatifs (analyse et mesures des produits et des processus). niveau 4 : managed. Processus gr, cest dire contrl et mesur. Qualit fiable. A traiter en priorit : gestion du changement (processus, technologies), prvention des dfauts. niveau 5 : optimizing. Processus en adaptation continue (CPI) : chaque projet est analys pour amliorer le processus et donc les cots, dlais et qualit. Le niveau dune organisation est valu par des questionnaires, des entretiens, et des examens de documents. b) les normes ISO 9000 (9003) et ISO SPICE (issue du CMM et de ISO 9000 et oriente vers le GL) attestent quune entreprise suit un processus orient qualit. Cela ne donne pas de garantie sur la qualit du produit lui mme. Une lecture plus stratgique de ces normes les lie une certaine volont de protectionnisme. En effet, peu dentreprises amricaines sont certifies ISO 9000 (ou ses drivs) et peu dentreprises europennes sont certifies CMM. 3.6.3. Les mtriques Pour lIEEE (Institute of Electrical and Electronical Engineers) , le GL est intimement li lide de mesure : le GL est lapplication au dveloppement, la mise en oeuvre et la maintenance du logiciel dune approche systmatique, discipline et mesurable ; en fait lapplication des mthodes de lingnieur au logiciel . La mesure est incontournable. Pour Harrington si tu ne peux pas le mesurer, tu ne peux pas le contrler ; si tu ne peux pas le contrler, tu ne peux pas le grer ; si tu ne peux pas le grer, tu ne peux pas lamliorer . Les mesures peuvent porter sur les processus et sur les produits.

Sur les produits, les mesures sont le plus souvent statiques (sans excution) ; on peut citer titre dexemples pour les approches objets (et parmi une profusion de mtriques) : le nombre et la complexit des mthodes pour implanter une classe, la profondeur de larbre dhritage, le nombre de couplages entre classes (appels de mthodes ou accs aux instances), le nombre de mthodes qui peuvent tre appeles en rponse lappel dune mthode, etc. Sur les processus on mesure : lavancement
100% version 2 version 1 0% t version 3

la stabilit (nombre de changements par priode)

nb changements cumul

ladaptabilit ou effort pour effectuer les changements qui doit diminuer

heures pour changements changements de conception changements dimplantation t

la qualit, via les mesures derreurs, etc.

EXERCICES
Exercice 1.1 A propos de la difficult de dvelopper des systmes complexes. Lire le communiqu officiel expliquant la dsintgration du premier exemplaire de la fuse Ariane 5, paru sur Internet. Analyser la cascade derreurs qui a t commise.

Communiqu de presse conjoint ESA-CNES Paris, le 19 juillet 1996

Rapport de la Commission d'enqute Ariane 501 Echec du vol Ariane 5Ol Prsident de la Commission: Professeur J.-L LIONS Avant-propos 1. Lchec 1. Description gnrale 2. Informations disponibles 3. Rcupration des dbris 4. Autres anomalies observes sans rapport avec laccident Analyse de lchec 1. Squence des vnements techniques 2. Commentaires du scnario de dfaillance 3. Procdures dessai et de qualification 4. Autres faiblesses ventuelles des systmes incrimins Conclusions 1. Rsultats de lenqute 2. Cause de laccident Recommandations

2.

3.

4.

2 ANALYSE DE L'ECHEC 2.1. SQUENCE DES VNEMENTS TECHNIQUES De manire gnrale la chane de pilotage dAriane 5 repose sur un concept standard. L'attitude du lanceur et ses mouvements sont mesurs par un systme de rfrence inertielle (SRI) dont le calculateur interne calcule les angles et les vitesses sur la base dinformations provenant dune plate-forme inertielle composants lis, avec gyrolasers et acclromtres. Les donnes du SRI sont transmises via le bus de donnes, au calculateur embarqu (OBC) qui excute le programme de vol et qui commande les tuyres des tages dacclration poudre et du moteur cryotechnique Vulcain , par lintermdiaire de servovalves et de vrins hydrauliques. Pour amliorer la fiabilit, on a prvu une importante redondance au niveau des quipements. On compte deux SRI travaillant en parallle; ces systmes sont identiques tant sur le plan du matriel que sur celui du logiciel. Lun est actif et lautre est en mode "veille active" ; si lOBC dtecte que le SRI actif est en panne, il passe immdiatement sur lautre SRI condition que ce dernier fonctionne correctement. De mme on compte deux OBC et un certain nombre d'autres units de la chane de pilotage qui sont galement dupliques. La conception du SRI dAriane 5 est pratiquement la mme que celle d'un SRI qui est actuellement utilis bord dAriane 4, notamment pour ce qui est du logiciel. Sur la base de la documentation et des donnes exhaustives relatives lchec dAriane 501 qui ont t mises la disposition de la Commission, on a pu tablir la squence suivante d'vnements ainsi que leurs interdpendances et leurs origines, depuis la destruction du lanceur jusqu' la cause principale en remontant dans le temps. Le lanceur a commenc se dsintgrer environ HO + 39 secondes sous leffet de charges arodynamiques leves dues un angle dattaque de plus de 20 degrs qui a provoqu la sparation des tages dacclration poudre de ltage principal, vnement qui a dclench son tour le systme d'auto destruction du lanceur;

 Cet angle dattaque avait pour origine le braquage en bute des tuyres des moteurs propergols solides et du moteur principal Vulcain; le braquage des tuyres a t command par le logiciel du calculateur de bord (OBC) agissant sur la base des donnes transmises par le systme de rfrence inertielle actif (SRI2). A cet instant, une partie de ces donnes ne contenait pas des donnes du vol proprement dites mais affichait un profil de bit spcifique de la panne du calculateur du SRI2 qui a t interprt comme tant des donnes de vol ; la raison pour laquelle le SRI2 actif n'a pas transmis des donnes d'attitude correctes tient au fait que lunit avait dclar une panne due une exception logiciel; lOBC n'a pas pu basculer sur le SRI 1 de secours car cette unit avait dj cess de fonctionner durant le prcdent cycle de donnes (priode de 72 millisecondes) pour la mme raison que le SRI2; lexception logicielle interne du SRI sest produite pendant une conversion de donnes de reprsentation flottante 64 bits an valeurs entires 16 bits. Le nombre en reprsentation flottante qui a t converti avait une valeur qui tait suprieure ce que pouvait exprimer un nombre entier 16 bits. Il en est rsult une erreur d'oprande. Les instructions de conversion de donnes (en code Ada) n'taient pas protges contre le dclenchement d'une erreur d'oprande bien que d'autres conversions de variables comparables prsentes la mme place dans le code aient t protges; lerreur sest produite dans une partie du logiciel qui nassure que lalignement de la plate-forme inertielle composants lis. Ce module de logiciel calcule des rsultats significatifs avant le dcollage seulement. Ds que le lanceur dcolle, cette fonction n'est plus d'aucune utilit; La fonction d'alignement est active pendant 50 secondes aprs le dmarrage du mode vol des SRI qui se produit HO - 3 secondes pour Ariane 5. En consquence, lorsque le dcollage a eu lieu, cette fonction se poursuit pendant environ 40 secondes de vol. Cette squence est une exigence Ariane 4 mais n'est pas demand sur Ariane 5 ; Lerreur d'oprande s'est produite sous l'effet d'une valeur leve non prvue d'un rsultat de la fonction d'alignement interne appel BH (Biais Horizontal) et li la vitesse horizontale dtecte par la plate-forme. Le calcul de cette valeur sert dindicateur pour la prcision de l'alignement en fonction du temps; la valeur BH tait nettement plus leve que la valeur escompte car la premire partie de la trajectoire dAriane 5 diffre de celle dAriane 4, ce qui se traduit par des valeurs de vitesse horizontale considrablement suprieures. Les vnements internes du SRI qui ont conduit l'accident ont t reproduits par simulation. En outre, les deux SRI ont t rcuprs pendant l'enqute de la Commission et le contexte de laccident a t dtermin avec prcision partir de la lecture des mmoires. De plus, la Commission a examin le code logiciel qui sest avr correspondre au scnario de l'chec. Les rsultats de ces examens sont exposs dans le Rapport technique. On peut donc raisonnablement affirmer que la squence d'vnements ci-dessus traduit les causes techniques de lchec d'Ariane 501.

Exercice 1.2 A propos de la difficult de spcifier prcisment un besoin fonctionnel. La spcification de la rgle de notation un examen est la suivante : Lexamen est un ensemble de 20 questions rponses multiples. Chaque bonne rponse une question rapporte 1 point. Chaque mauvaise rponse fait perdre 1/3 de point. Chaque question sans rponse donne 0 point. Pensez vous que cette spcification est claire ? Pour le vrifier, calculez chacun la note des 3 tudiants suivants :
Duchnock Dutif Dudule rponses correctes 10 4 10 incorrectes 5 16 3 sans 5 4 doubles rponses

3 (1 juste, 1 fausse)

Recensez les rsultats possibles. Donnez une spcification plus prcise.