Vous êtes sur la page 1sur 7

Les systmes informatiques deviennent de plus en plus complexes.

Certains projets mettent en uvre plusieurs dizaines de personnes et peuvent durer plusieurs annes. Si les cots de dveloppement sont levs, les cots de maintenance sont de trois quatre fois lev. Les enjeux financiers et les risques sont dans ces cas considra!les. "our limiter ces cots, il est ncessaire de disposer des mt#odes, des tec#niques et des outils qui font du dveloppement une activit d$in%nierie de m&me titre que le %nie civil, %nie mcanique ou industrie d$lectronique. C$est le %nie lo%iciel. ' (uels sont les facteurs qui ont contri!u la naissance du %nie lo%iciel ) ' (uelles sont les critres qui doivent &tre assures par le *L pour la fa!rication d$un lo%iciel ) ' (uels sont les principes du %nie lo%iciel ) ' (uels sont les diffrentes classes du lo%iciel ) ' (uels sont les diffrents types de processus de dveloppement et quels sont ses avanta%es et ses inconvnients ) ' (uelles sont les mt#odes de conception des S+ ) ' (uels sont les outils de %nie lo%iciel ) ' (uels sont les mt#odes de spcification des !esoins ) ' Comment tester un pro%ramme ) ' (uel est le r,le de la maintenance dans le processus de dveloppement d$un lo%iciel et quels sont les diffrents types de maintenance ) ' Comment %rer un projet ) ' (uel est l$avenir du %nie lo%iciel )

-vant d$a!order l$#istorique du %nie lo%iciel, essayons tout d$a!ord de dfinir le concept %nie lo%iciel. .n effet, le %nie lo%iciel est une science de l$in%nieur dont la finalit est la fa!rication de systmes informatiss. *nralement complexe, ils prennent en c#ar%e des pans entiers de traitement de l$information ncessaire au !on fonctionnement de nos industries, des administrations, des communications, de notre dfense, etc. .t pour rsumer, de tout notre systme socio'conomique. /n systme informatis est un ensem!le d$ordinateurs d$ori%ine et de puissance diverse relis entre eux par des rseaux locaux 0intra entreprise1 et des rseaux distants 0inter entreprise1, des prip#riques trs divers qui re2oivent et restituent de l$information dans leur environnement. 3n distin%ue dans un tel systme 4 ' /ne partie matrielle 0ordinateurs, terminaux, modems, commutateurs, capteurs, etc1 dont le r,le est de fournir la puissance !rute de traitement et de relier le systme au monde extrieur ' /ne partie lo%icielle qui assure les fonctions lo%iques ncessaires aux diffrents traitements et au stoc5a%e de l$information. Ces lo%iciels sont de trois types 4 6es lo%iciels constructeurs qui sont trs dpendants du matriel 6es pro%iciels dvelopps par les diteurs de lo%iciel qui sont des !o7tes noire %nralement paramtra!les assurant telles ou telles fonctions prcises. Le %nie lo%iciel se proccupe des procds de fa!rication de lo%iciel de fa2on que 4 s$assurer

Ce qui est fa!riqu par le ma7tre d$uvre rpond correctement aux !esoins de celui qui les a formul 0ca#ier de la c#ar%e1. Les cots et les dlais de ralisation restent dans les limites fixes au dpart. Le contrat de service sera effectivement respect 0performance, sret de fonctionnement, scurit1. Lors de l$exploitation future du lo%iciel Le *L est apparu dans les annes 89 pour rpondre la : crise du logiciel. Cette crise est apparue lorsque l$on a pris conscience que le cot du lo%iciel dpassait le cot du matriel. -ujourd$#ui il le dpasse trs lar%ement. /n autre sympt,me de cette crise se situe dans la non qualit des systmes produits. Les risques #umains et conomiques sont importants, comme l$illustrent les quelques exemples cl!res suivants 4 mission ;.</S 4 passa%e =99.999 5m au lieu de =.999 5m cause du remplacement d>une vir%ule par un point, avion C?8 de @c6onnell 6ou%las livr avec un dpassement de =99 millions de A ... 0?B calculateurs #tro%nes et C lan%a%es de pro%rammation diffrents1, non reconnaissance de l>.D3C.E dans la %uerre des @alouines 4 .xocet non rpertori comme missile ennemi 4 FF morts, non diffrenciation entre avion civil et avion militaire 4 %uerre du *olfe G -ir!us iranien a!attu 4 HF9 morts, mauvais pilote automatique de la commande d$une !om!e au co!alt en milieu #ospitalier 4 C morts, La solution ima%ine pour rpondre cette crise t l$industrialisation de la production du lo%iciel 4 or%anisation des procds de production 0cycle de vie, mt#odes, notations, outils1, des quipes de dveloppement, plan qualit ri%oureux, etc. @al%r tout le *L reste aujourd$#ui moins avanc et moins !ien codifi que d$autres :sciences de l$in%nieur$, comme le %nie civil qui construit des routes et des ponts, ou le %nie c#imique. /ne des raisons est la nature m&me du lo%iciel 4 ' le lo%iciel est un o!jet immatriel 0pendant son dveloppement1, trs malla!le au sens de facile modifier, ' ses caractristiques attendues sont difficiles fi%er 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 p#nomnes d$usure dont on conna7t les lois mais d$erreurs #umaines, in#rentes l$activit de dveloppement, ' le lo%iciel ne s$use pas, il devient o!solte 0par rapport aux concurrents, par rapport au contexte tec#nique, par rapport aux autres lo%iciels, ...1, Cependant, %rIce au *L des pro%rs ont t raliss. @ais la complexit des systmes ne cesse de s$accro7tre. .xemple 4 Compilateur C 4 ?9 J- 0JommeKannes1, H9 L9 MLS 0milliers de li%nes source1 S*N6 03racle, 6NH1 4 L99 =99 JQuelles sont les critres qui doivent tre assures par le GL pour la fabrication des logiciels? Le *L se proccupe des procds de fabrication des logiciels de fa2on s$assurer que les O critres suivants soient satisfaits. P Le systme qui est fa!riqu rpond aux besoins des utilisateurs

P La qualit correspond au contrat de service initial. La qualit du lo%iciel est une notion multiforme qui recouvre 4 G la validit 4 aptitude d>un lo%iciel raliser exactement les tIc#es dfinies par sa spcification, G la fiabilit 4 aptitude d>un lo%iciel assurer de manire continue le service attendu, G la robustesse : aptitude d>un lo%iciel fonctionner m&me dans des conditions anormales, G lextensibilit 4 facilit d>adaptation d>un lo%iciel aux c#an%ements de spcification, G la rutilisabilit 4 aptitude d>un lo%iciel &tre rutilis en tout ou partie, G la compatibilit 4 aptitude des lo%iciels pouvoir &tre com!ins les uns aux autres, G lefficacit 4 aptitude d>un lo%iciel !ien utiliser les ressources matrielles telles la mmoire, la puissance de l$/.C., etc. G la portabilit 4 facilit &tre port sur de nouveaux environnements matriels etKou lo%iciels, G la vrifiabilit 4 facilit de prparation des procdures de recette et de certification, G lintgrit 4 aptitude d>un lo%iciel prot%er ses diffrents composants contre des accs ou des modifications non autoriss, G la facilit d'utilisation, dentretien, etc. P Les cots restent dans les limites prvues au dpart. P Les dlais restent dans les limites prvues au dpart. T%le du Cot (ualit Uonctionnalits 6lai C(U6 4.

Ces qualits sont parfois contradictoires 0c#ic et pas c#er Q1. +l faut les pondrer selon les circonstances 0lo%iciel critique K lo%iciel %rand pu!lic1. +l faut aussi distin%uer les systmes sur mesure et les produits lo%iciels de %rande diffusion. Les principes fondamentaux du *L sont 4 "Sparation des problmes C$est une r%le de !ons sens qui consiste considrer sparment diffrents aspects d$un pro!lme afin d$en ma7triser la complexit. C$est un aspect de la strat%ie %nrale du R diviser pour r%ner S. !odularit : /n systme est modulaire s$il est compos de sous-systmes plus simples, ou modules. La modularit est une proprit importante de tous les procds et produits industriels. La modularit permet de considrer sparment le contenu du module et les relations entre modules 0ce qui rejoint l$ide de sparation des questions1. .lle facilite %alement la rutilisation de composants. /n !on dcoupa%e modulaire se caractrise par une forte cohsion interne des modules 0ex 4 fonctionnelle, temporelle, lo%ique, ...1 et un faible couplage entre les modules 0relations inter modulaires en nom!re limit et clairement dcrites1. Eoute l$volution des lan%a%es de pro%rammation vise rendre plus facile une pro%rammation modulaire, appele aujourd$#ui :pro%rammation par composants$. "bstraction L$a!straction consiste ne considrer que les aspects jugs importants d$un systme un moment donn, en faisant a!straction des autres aspects 0c$est encore un exemple de sparation des pro!lmes1.

/ne m&me ralit peut souvent &tre dcrite diffrents niveaux dabstraction. "ar exemple, un circuit lectronique peut &tre dcrit par un modle mat#matique trs a!strait 0quation lo%ique1, ou par un assem!la%e de composants lo%iques qui font a!straction des dtails de ralisation 0circuit lo%ique1, ou par un plan p#ysique de composants rels au sein d>un circuit int%r. L$a!straction permet une meilleure ma7trise de la complexit. Ces principes sont trs a!straits et ne sont pas utilisables directement. @ais ils font partie du voca!ulaire de !ase du %nie lo%iciel. Ces principes ont un impact rel sur !eaucoup d$aspects et constituent le type de connaissance le plus sta!le, dans un domaine oV les outils, les mt#odes et les tec#niques voluent trs vite. Comme pour toutes les fa!rications, il est important d$avoir un procd de fa!rication du lo%iciel !ien dfini et explicitement dcrit et document. #omment alors organiser la production dun logiciel ? Les modles de cycle de vie du lo%iciel dcrivent un niveau trs a!strait et idalis les diffrentes manires d$or%aniser la production. Les tapes, leur ordonnancement, et parfois les critres pour passer d$une tape une autre sont explicits 0critres de terminaison d$une tape ' revue de documents ', critres de c#oix de l$tape suivante, critres de dmarra%e d$une tape1. +l faut souli%ner la diffrence entre tapes 0dcoupa%e temporel1 et activits 0dcoupa%e selon la nature du travail1. +l y a des activits qui se droulent dans plusieurs tapes 0ex 4 la spcification, la validation et la vrification1, voire dans toutes les tapes 0ex 4 la documentation1. Tappelons aussi la diffrence entre vrification et validation 0N. Noe#m, 8C1 4 P vrification 4 are we building the product right ! 0R construisons nous le produit correctement ) S ' correction interne du lo%iciel, concerne les dveloppeurs1, P validation 4 are we building the right product ! 0R construisons nous le !on produit ) S ' adaptation vis vis des !esoins des utilisateurs, concerne les utilisateurs1. 3.2. Le modle en cascade (waterfall) Le modle en cascade dcrit #uit tapes fondamentales. @&me si on l$tend avec les possi!ilits de retour en arrire, idalement limites la seule p#ase qui prcde celle remise en cause le dveloppement reste fondamentalement linaire. "our des les petites applications La maintenance est coteuse

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 contr le qualit). !e 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 danal"se + plan de validation) modlisation du domaine, modlisation de lexistant (ventuellement), dfinition dun modle conceptuel (ou spcification conceptuelle), plan de validation. !onception (dossier de conception + plan de test global et par module) proposition de solution au probl#me spcifi dans lanal"se organisation de lapplication en modules et interface des modules (architecture du logiciel), description dtaille des modules avec les algorithmes essentiels (mod#le logique) structuration des donnes. "ro#rammation et tests unitaires (dossiers de programmation et codes sources) traduction dans un langage de programmation, tests avec les $eux dessais par module selon le plan de test. $nt#ration et tests de %ualification composition progressive des modules, tests des regroupements de modules, test en vraie grandeur du s"st#me complet selon le plan de test global (%alpha testing). $nstallation &ise en fonctionnement oprationnel che' les utilisateurs. (arfois restreint dans un premier temps ) des utilisateurs slectionns (%beta testing). &aintenance maintenance corrective (ou curative), maintenance adaptative, maintenance perfective.

' Acti(its trans(ersales ) tout le cycle de (ie spcification, documentation, validation et vrification, management.

Le modle en V est une autre fa2on de prsenter une dmarc#e qui reste linaire, mais qui fait mieux appara7tre les produits intermdiaires des niveaux dabstraction et de formalit diffrents et les procdures dacceptation "validation et vrification# de ces produits intermdiaires . Le ; est parcouru de %auc#e droite en suivant la forme de la lettre 4 les activits de construction prcdent les activits de validation et vrification. @ais l$acceptation estprpare ds la construction 0flc#es de %auc#e droite1. Cela permet de mieux approfondir la construction et de mieux planifier la :remonte$.

Le modle incrmental Uace aux drives !ureaucratiques de certains %ros dveloppements, et l$impossi!ilit de procder de manire aussi linaire, le modle incrmental a t propos dans les annes F9 0Ui%. L.C1. Le produit est dlivr en plusieurs fois, de manire incrmentale, c$est dire en le compltant au fur et mesure et en profitant de l$exprimentation oprationnelle des incrments prcdents. $haque incrment peut donner lieu % un cycle de vie classique plus ou moins complet& Les premiers incrments peuvent &tre des maquettes 0jeta!les s$il s$a%it juste de comprendre les !esoins des utilisateurs1 ou des prototypes 0rutilisa!les pour passer au proc#ain incrment en les compltant etKou en optimisant leur implantation1. Le risque de cette approc#e est celui de la remise en cause du noyau.