Cours Génie Logiciel
Contents
1. Adapt aux projets de taille et de complexit moyenne La premi re branche correspond un mod le en cascade classique Toute description d un composant est accompagn e de d finitions de tests Avec les jeux de tests pr par s dans la premi re branche les tapes de la deuxi me branche peuvent tre mieux pr par es et planifi es La seconde branche correspond des tests effectifs effectu s sur des composants r alis s L int gration est ensuite r alis e jusqu l obtention du syst me logiciel final L avantage d un tel mod le est d viter d noncer une propri t qu il est impossible de v rifier objectivement une fois le logiciel r alis le cycle en V est le cycle qui a t normalis il est largement utilis notamment en informatique industrielle et t l coms I Boussa d USTHB Ann e Universitaire 2009 2010 T USTHB info USTHB info 3 3 Le cycle de vie en spirale 13 Faisabilite cahier des charge Conception or liminaire Conception Te FIGURE 3 2 Cycle de vie en V Id al quand les besoins sont bien connus quand l analyse et la conception sont claires 3 3 Le cycle de vie en spirale Pour corriger les travers de la d marche lin aire sont apparus des mod les dits en spirales propos par B Boehm en 1988 o les risques quels qu ils soient sont constamment trait s au travers de bouclages successifs2. chaque spire confirme et affine les spires pr c dentes en menant des activit s de m me nature successivement L analyse ou la conception ne sont plus effectu es dans une seule phase ou tape mais sont conduites en tant qu activit s qui se d roulent sur de multiples phases chaque tape apr s avoir d fini les objectifs et les alternatives celles ci sont valu es par diff rentes techniques prototypage simulation l tape est r alis e et la suite est planifi e Le nombre de cycles est variable selon que le d veloppement est classique ou incr mental Ce mod le met l accent sur l analyse des risques tels que les exigences d mesur es par rapport Boussa d USTHB Ann e Universitaire 2009 2010 USTHB info 4 USTHB info 3 3 Le cycle de vie en spirale 14 D termination des objectifs des ane Identification et alternatives des F r solution des contraintes Analyse des N risques TIQUE S Plan du concep F cycle de vie OMCe pl d taill e Plan du d veloppemen conception Flan des tests codification et de Validation et Ne v rification l int gration Tests PAUSE z i ondes i i ing unitaires Planification des Int gration mt phases suivantes Acceptation Spirales suppl n FIGURE 3 3 Cycle de vie en spirale la technologie la r utilisation de composants calendriers et budgets irr alistes la d faillan
3. difficile co teuse et souvent l origine de nouvelles erreurs Mais en pratique il est indispensable d adapter les logiciels car leurs environnements d utili sation changent et les besoins des utilisateurs voluent Il est rare qu on puisse r utiliser un logiciel existant ou un de ses composants pour confection ner un nouveau syst me m me si celui ci comporte des fonctions similaires Tous ces probl mes ont men l mergence d une discipline appel e le g nie logiciel Les outils de g nie logiciel et les environnements de programmation peuvent aider faire face ces probl mes condition qu ils soient eux m mes utilis s dans un cadre m thodologique bien d fini 1 2 Une solution le G nie Logiciel 1 2 1 D finitions G NIE LOGICIEL Le terme g nie logiciel en anglais software engineering d signe l ensemble des m thodes des techniques et outils concourant la production d un logiciel audel de la seule activit de programmation I Boussa d USTHB Ann e Universitaire 2009 2010 u USTHB info D us USTHB info 1 2 Une solution le G nie Logiciel 3 L art et la mani re de cr er un logiciel Le g nie logiciel est donc l art de sp cifier de concevoir de r aliser et de faire voluer avec des moyens et dans des d lais raisonnables des programmes des documentations et des pro c dures de qualit en vue d utiliser un ordinateur pour
4. pour pr senter les fonctionnalit s et les acteurs qu elles impliquent autres sch mas crans types diagramme de d ploiement UML sc narios d interaction illustration des cas d utilisation complexes par un exemple d inter action le r alisant sp cifier les acteurs impliqu s et l encha nement des interactions sur un exemple ventuellement par un diagramme de s quence UML ainsi que le traitement des erreurs et les ventuelles pr conditions et postconditions Outils pour la capture des besoins entretiens r guliers avec le client validations observations des futurs utilisateurs dans leur pratique actuelle sc narios d interaction exemples d crans prototypes technique du magicien d Oz premier jet du manuel des utilisateurs I Boussa d USTHB Ann e Universitaire 2009 2010 USTHB info USTHB info Bibliographie 1 BOEHM B W Software engineering economics Prentice Hall 1981 0 13 822122 7 2 BOOCH Grady Object Oriented Analysis and Design with applications 3rd Ed Addison Wesley 2007 3 YOURDON E et CONSTANTINE L Structured Design Yourdon Press Englewood Cliffs N J 1979 4 Marie Claude GAUDEL Pr cis de g nie logiciel Editions Dunod 5 Bertrand MEYER Conception et programmation orient es objet Editions Eyrolles 2000 6 I SOMMERVILLE et Franck VALL E Software Engineering 6th edition Addison Wesley 2001
5. solution le G nie Logiciel 4 Structuration fa on de d composer un logiciel utilisation d une m thode bottom up ou top down Abstraction m canisme qui permet de pr senter un contexte en exprimant les l ments per tinents et en omettant ceux qui ne le sont pas Modularit d composition d un logiciel en composants discrets Documentation gestion des documents incluant leur identification acquisition production stockage et distribution V rification d termination du respect des sp cifications tablies sur la base des besoins identifi s dans la phase pr c dente du cycle de vie I Boussa d USTHB Ann e wS EB Mana www USTHB info Sites des Sciences et de la Technologie N 1 En Algerie USTHB info Chapitre 2 CYCLE DE VIE DU LOGICIEL 2 1 D finition Cycle de vie ensemble des tapes de la r alisation de l nonc des besoins la maintenance ou au retrait du logiciel L origine de ce d coupage provient du constat que les erreurs ont un co t d autant plus lev qu elles sont d tect es tardivement dans le processus de r alisation Le cycle de vie permet de d tecter les erreurs au plus t t et ainsi de ma triser la qualit du produit les d lais de sa r alisation et les co ts associ s De fa on g n rale on peut dire que le cycle de vie du logiciel est la p riode de temps s talant du d but la fin du processus du logiciel Il
6. I Boussa d USTHB Ann e Universitaire 2009 2010
7. ans aucune valuation entre le d but du projet et la validation Le projet est d coup en phases successives dans le temps et chaque phase correspond une activit principale bien pr cise produisant un certain nombre de livrables On ne passe l tape suivante que si les r sultats de l tape pr c dente sont jug s satisfaisants L activit d une tape se r alise avec les r sultats fournis par l tape pr c dente ainsi chaque tape sert de contr le du travail effectu lors de l tape pr c dente Chaque phase ne peut remettre en cause que la phase pr c dente ce qui dans la pratique s av re insuffisant L laboration des sp cifications est une phase particuli rement critique les erreurs de sp ci fications sont g n ralement d tect es au moment des tests voire au moment de la livraison du logiciel l utilisateur Leur correction n cessite alors de reprendre toutes les phases du processus Ce mod le est mieux adapt aux petits projets ou ceux dont les sp cifications sont bien connues et fixes 3 2 Le cycle de vie en V D riv du mod le de la cascade le mod le en V du cycle de d veloppement montre non seulement l encha nement des phases successives mais aussi les relations logiques entre phases plus loign es Ce mod le fait appara tre le fait que le d but du processus de d veloppement conditionne ses derni res tapes
8. ant Est ce que cette correspondance est r sum e quelque part La complexit Les algorithmes utilis s pour impl menter le composant sont ils complexes L ADAPTABILIT Si l on doit maintenir une conception cette derni re doit tre facilement adaptable Bien s r il faut pour cela que les composants soient faiblement coupl s En plus de a la conception doit tre bien document e la documentation des composants doit tre facilement compr hensible et consistante avec l impl mentation cette derni re devant elle aussi tre crite de mani re lisible 2 6 Impl mentation Apr s la conception d taill e on peut passer la phase d impl mentation galement appel e phase de construction phase de r alisation ou phase de codage implementation phase construc tion phase coding phase Lors de cette phase la conception d taill e est traduite dans un langage de programmation 2 7 Test unitaire La phase d impl mentation est suivie de la phase de test test phase Durant cette phase les composants du logiciel sont valu s et int gr s et le logiciel lui m me est valu pour d terminer s il satisfait la sp cification labor e lors de la phase d analyse Cette phase est en g n ral subdivis e en plusieurs phases Lors des tests unitaires unit test on value chaque composant individuellement pour s assurer qu il est conforme la conception d taill e Si ce n
9. ar elle signifie que chaque unit ne repr sente qu une partie de la r solution du probl me Constantine et Yourdon 8 identifient en 1979 sept niveaux de coh sion pr sent es ci apr s du plus fort au plus faible La coh sion fonctionnelle la meilleure Le module assure une seule fonction Tous les l ments du composant contribuent atteindre un seul objectif si un l ment est supprim l objectif ne sera pas atteint Exemple M1 Calcul solution M2 imprime solution La coh sion s quentielle Dans se type de coh sion la sortie d un l ment est utilis e en entr e d un autre dans ce cas l ordre des actions est important Exemple Saisir Traiter Imprimer La coh sion de communication bonne Lorsque tous les l ments d un composant travaillent sur les m mes donn es Exemple M1 calculer et imprimer les r sultats La coh sion proc durale passable Dans ce cas les l ments d un composant constituent une seule s quence de contr le La coh sion temporelle m diocre On parle de coh sion temporelle quand dans un m me composant sont regroup s tous les l ments qui sont activ s au m me moment par exemple l initialisation d un programme ou encore en fin d ex cution La coh sion logique la moins mauvaise Tous les l ments d un composant effectuent des op rations semblables c
10. ce du personnel etc Ce mod le est utilis pour des projets dont les enjeux risques sont importants Chaque cycle de la spirale se d roule en quatre phases l Un cycle de la spirale commence par l laboration d objectifs tels que la performance la fonctionnalit etc on num re ensuite les diff rentes mani res de parvenir ces objectifs ainsi que les contraintes On value ensuite chaque alternative en fonction de l objectif L tape suivante consiste valuer les risques pour chaque activit comme l analyse d taill e le prototypage la simulation etc Apr s avoir valu le risque on choisit un mod le de d veloppement pour le syst me Par exemple si les principaux risques concernent l interface utilisateur le prototypage volutif pourrait s av rer un mod le de d veloppement appropri Le mod le de la cascade peut tre le plus appropri si le principal risque identifi concerne l int gration des sous syst mes il n est pas n cessaire d adopter un seul mod le chaque cycle de la spirale ou m me pour l ensemble d un syst me Le mod le de la spirale englobe tous les autres mod les La situation est ensuite r valu e pour d terminer si un d veloppement suppl mentaire est n cessaire auquel cas il faudrait planifier la prochaine tape on estime au cours d une proc dure de revue si on doit passer au prochain cycle de la spirale ou non Les principaux risq
11. ces et de la Technologie N 1 En Algerie USTHB info USTHB info Chapitre 1 INTRODUCTION 1 1 Analyse de l existant Crise du logiciel Le terme de G nie logiciel a t introduit la fin des ann es soixante lors d une conf rence tenue pour discuter de ce que l on appelait alors la crise du logiciel software crisis Le d veloppement de logiciel tait en crise Les co ts du mat riel chutaient alors que ceux du logiciel grimpaient en fl che Il fallait de nouvelles techniques et de nouvelles m thodes pour contr ler la complexit inh rente aux grands syst mes logiciels La crise du logiciel peut tout d abord se percevoir travers ces symptomes La qualit du logiciel livr est souvent d ficiente Le produit ne satisfait pas les besoins de l utilisateur il consomme plus de ressources que pr vu et il est l origine de pannes Les performances taient tr s souvent m diocres temps de r ponse trop lents Le non respect des d lais pr vus pour le d veloppement de logiciels satisfaisant leurs cahiers des charges Les co ts de d veloppement d un logiciel sont presque impossible pr voir et sont g n rale ment prohibitifs excessifs L invisibilit du logiciel ce qui veut dire qu on s aper oit souvent que le logiciel d velopp ne correspond pas la demande on ne peut l observer qu en l utilisant trop tard La maintenance du logiciel est
12. commence donc avec la proposition ou la d cision de d velopper un logiciel et se termine avec sa mise hors service 2 2 tapes du cycle de vie Il existe de nombreux mod les de cycle de vie les plus courants comportent les phases suivantes tude d opportunit par des conomistes en g n ral D finition et analyse des besoins sp cification par le commanditaire et des informaticiens laboration du cahier des charges et des tests de recette validation Conception architecturale et laboration des tests d int gration Conception d taill e et laboration des tests unitaires Codage production du code source Tests unitaires et d int gration Implantation chez le commanditaire essais avec les utilisateurs et validation Formation des utilisateurs utilisation maintenance volution Retrait Ces tapes ne doivent pas tre vues comme se succ dant les unes aux autres de fa on lin aire Il y a en g n ral toujours des retours sur les phases pr c dentes en particulier si les tests ne r ussissent pas ou si les besoins voluent 2 3 tude d opportunit ou tude pr alable Le d veloppement est pr c d d une tude d opportunit ou tude pr alable Cette phase a comme objectif de r pondre aux questions suivantes Pourquoi d velopper le logiciel D us I Boussa d USTHB Ann e eO FET f N www USTHB info Sites des Sciences et de la Techn
13. cro tre am liorer les possibilit s du logiciel Ex les services offerts l interface utilisateur les performances Donne lieu de nouvelles versions Une fois qu une version modifi e du logiciel a t d velopp e il faut bien entendu la distri buer De plus il est en g n ral n cessaire de fournir l exploitant du logiciel une assistance technique et un support de consultation En r sum on peut dire que la maintenance et le support du logiciel comprennent les t ches suivantes effectuer des d pannages pour des corrections mineures r appliquer le cycle de d veloppement pour des modifications plus importantes distribuer les mises jour fournir l assistance technique et un support de consultation maintenir un Journal des demandes d assistance et de support un moment donn on d cide de mettre le logiciel hors service Les t ches correspondantes sont accomplies durant la phase de retrait retirement phase et comprennent avertir les utilisateurs effectuer une exploitation en parall le du logiciel retirer et de son successeur arr ter le support du logiciel I Boussa d USTHB Ann e wS PEB Mana USTHB info Chapitre 3 Mod les de d veloppement d un logiciel 3 1 Le cycle de vie en Cascade waterfall model Le cycle de vie dit de la cascade date de 1970 il est l oeuvre de Royce Cycle de vie lin aire s
14. de la phase de conception n ralement d compos e en deux phases successives 1 conception g n rale conception globale conception pr liminaire ou conception architec turale preliminary design ou architectural design 2 Conception d taill e detailed design 2 5 1 Conception g n rale Si n cessaire il faut commencer par l bauche de plusieurs variantes de solutions et choisir celle qui offre le meilleur rapport entre co ts et avantages Il faut ensuite figer la solution retenue la d crire et la d tailler En particulier il faut d crire l architecture de la solution c est dire son organisation en entit s les interfaces de ces entit s et les interactions entre ces entit s Ce processus de structuration doit tre poursuivi jusqu ce que tous les l ments du document de sp cification ont t pris en compte Le r sultat de cette d marche est un document de conception g n rale Durant la phase de conception g n rale il faut galement pr parer la phase d int gration A cet effet il faut laborer un plan d int gration y compris un plan de test d int gration 2 5 2 Conception d taill e La conception d taill e affine la conception g n rale Elle commence par d composer les entit s d couvertes lors de la conception g n rale en entit s plus l mentaires Cette d composition doit tre poursuivie jusqu au niveau o les entit s sont faciles impl ment
15. des d fauts pour am liorer ses perfor mances ou autres caract ristiques pour adapter le logiciel un nouvel environnement ou pour r pondre des nouveaux besoins ou des besoins modifi s On peut donc distinguer entre la maintenance corrective la maintenance perfective et la maintenance adaptative Sauf pour des corrections mineures du genre d pannage la maintenance exige en fait que le cycle de d veloppement soit r appliqu en g n ral sous une forme simplifi e Maintenance corrective Corriger les erreurs d fauts d utilit d utilisabilit de fiabilit Identifier la d faillance le fonctionnement Localiser la partie du code responsable Corriger et estimer l impact d une modification Attention La plupart des corrections introduisent de nouvelles erreurs Les co ts de correction augmentent exponentiellement avec le d lai de d tection Corriger et estimer l impact d une modification La maintenance corrective donne lieu de nouvelles livraisons release Maintenance adaptative Ajuster le logiciel pour qu il continue remplir son r le compte tenu du l volution des Environnements d ex cution Fonctions satisfaire Conditions d utilisation Ex changement de SGBD de machine de taux de TVA an 2000 euro I Boussa d USTHB Ann e wS PEB Mana USTHB info 2 10 Maintenance 11 Maintenance perfective d extension Ac
16. e d attributs d crivant son tat et l tat du syst me est d crit de fa on d centralis par l tat de l ensemble La d composition fonctionnelle du haut vers le bas a t largement utilis e aussi bien dans de petits projets que dans de tr s grands et dans divers domaines d application La m thode orient e objet a eu un d veloppement plus r cent Elle encourage la production de syst mes divis s en composants ind pendants en interaction I Boussa d USTHB Ann e Universitaire 2009 2010 USTHB info Appendices USTHB Ann e Universitaire 2009 2010 USTHB info USTHB info USTHB info Annexe Cahier des charges Le cahier des charges est un document recensant les sp cifications exigences Il r sulte de l ana lyse et est contractuel entre le client et l entreprise informatique qui va r aliser le logiciel Il doit donc tre valid par les deux Qualit s attendues non ambigu complet v rifiable coh rent mo difiable tra able utilisable durant la maintenance ind pendant des solutions voir notamment la norme IEEE 830 Plan type 1 introduction pr sentation g n rale motivations d finitions des termes 2 contexte environnement mat riel et humain acteurs et utilisateurs interaction avec d autres syst mes et logiciels existant 3 sp cifications fonctionnelles grandes fonctionnalit s du syst me acteurs et autres sys t mes
17. er et tester c est dire correspondent des composants logiciels l mentaires Ce niveau d pend fortement du langage de programmation retenu pour l impl mentation Il faut ensuite d crire chaque composant logiciel en d tail son interface les algorithmes utilis s le traitement des erreurs ses performances etc L ensemble de ces descriptions constitue le document de conception d taill e Pendant la conception d taill e il faut galement pr parer la v rification des composants logiciels l mentaires qui fera l objet de la phase des tests unitaires Le r sultat est consign dans un document appel plan de tests unitaires Si n cessaire il faut de plus compl ter le plan d int gration car de nouvelles entit s ont pu tre introduites pendant la conception d taill e I Boussa d USTHB Ann e vS EB Mana Dag USTHB info 2 5 La conception du logiciel 8 2 5 3 Qualit d une conception La composante la plus importante de la qualit d une conception est la maintenabilit C est en maximisant la coh sion l int rieur des composants et en minimisant le couplage entre ces composants que l on parviendra une conception maintenable COH SION La coh sion d un composant permet de mesurer la qualit de sa structuration Un composant devrait impl menter une seule fonction logique ou une seule entit logique La coh sion est une caract ristique d sirable c
18. est constant dans le temps par opposition au pic pour sp cifications d taill es pour les mod les en cascade ou en V Risques la remise en cause du noyau de d part celle des incr ments pr c dents ou encore l impossibilit d int grer un nouvel incr ment 3 60 M thodes de conception Les m thodes d analyse et de conception fournissent des notations standards et des conseils pratiques qui permettent d aboutir des conceptions mais on fera toujours appel la cr ativit du concepteur Il existe diff rentes mani res pour classer ces m thodes dont La distinction composition d composition met en opposition d une part les m thodes ascen dantes qui consistent construire un logiciel par composition partir de modules existants et d autre part les m thodes descendantes qui d composent r cursivement le syst me jusqu arriver des modules programmables simplement la distinction fonctionnel dirig e par le traitement orient e objet Dans la strat gie fonc tionnelle un syst me est vu comme un ensemble d unit s en interaction ayant chacune une raisonnables fonction clairement d finie Les fonctions disposent d un tat local mais le syst me a un tat partag qui est centralis et accessible par l ensemble des fonctions Les strat gies orient es objet consid rent qu un syst me est un ensemble d objets interagis sants Chaque objet dispose d un ensembl
19. est d j fait il faut laborer pour chaque composant un jeu de donn es de tests Il faut ensuite ex cuter le composant avec ce jeu comparer les r sultats obtenus aux r sultats attendus et consigner le tout dans le document des tests unitaires S il s av re qu un composant comporte des erreurs il est renvoy son auteur qui devra diagnostiquer la cause de l erreur puis corriger le composant Le test unitaire de ce composant est alors reprendre 2 8 Int gration et test d int gration Apr s avoir effectu avec succ s les tests unitaires de tous les composants on peut proc der leur assemblage qui est effectu pendant la phase d int gration integration phase Pendant cette phase on v rifie galement la bonne facture des composants assembl s ce qu on appelle le test d int gration integration test On peut donc distinguer les actions suivantes construire par assemblage un composant partir de composants plus petits ex cuter les tests pour le composant assembl et enregistrer les r sultats comparer les r sultats obtenus aux r sultats attendus si le composant n est pas conforme engager la proc dure de modification I Boussa d USTHB Ann e wS PEB D us info USTHB info 2 9 Installation 10 si le composant est conforme r diger les comptes rendus du test d int gration et archiver sur support informatique les sources objets c
20. l final Ce sous ensemble est alors raffin incr mentalement et valu jusqu obtenir le produit final I Boussa d USTHB Ann e Universitaire 2009 2010 USTHB info D us USTHB info 3 5 Le mod le par incr ment 16 Deux type de prototypage 1 Jetable squelette du logiciel qui n est cr que dans un but et dans une phase particuli re du d veloppement 2 Evolutif conserv tout au long du cycle de d veloppment Il est am lior et compl t pour obtenir le logiciel final 3 5 Le mod le par incr ment Dans les mod les spirale en V ou en cascade un logiciel est d compos en composants d velopp s s par ment et int gr s la fin du processus Dans le mod le par incr ments seul un sous ensemble est d velopp la fois Dans un premier temps un logiciel noyau est d velopp puis successivement les incr ments sont d velopp s et int gr s Chaque incr ment est d velopp selon l un des mod les pr c dents Dans ce mod le les int grations sont progressives et il peut y avoir des livraisons et des mises en service apr s chaque int gration d incr ment Avantages chaque d veloppement est moins complexe les int grations sont progressives possibilit de livraisons et de mises en service apr s chaque incr ment meilleur lissage du temps et de l effort de d veloppement cause de la possibilit de recou vrement des diff rentes phases leffort
21. ne sp cification comporte les l ments suivants description de l environnement du logiciel sp cification fonctionnelle functional specification qui d finit toutes les fonctions que le logiciel doit offrir comportement en cas d erreurs c est dire dans les cas o le logiciel ne peut pas accomplir une fonction performances requises performance requirements par exemple temps de r ponse encom brement en m moire s curit de fonctionnement interfaces avec l utilisateur user interface en particulier le dialogue sur terminal la pr sen tation des crans la disposition des tats imprim s etc interfaces avec d autres logiciels interfaces avec le mat riel contraintes de r alisation telles que l environnement de d veloppement le langage de pro grammation utiliser les proc dures et normes suivre etc Il est judicieux de pr parer pendant la phase d analyse les proc dures qui seront mises en oeuvre pour v rifier que le logiciel une fois construit est conforme la sp cification que nous l appel lerons test de r ception acceptance test Durant la phase d analyse on produit galement une version provisoire des manuels d utilisation et d exploitation du logiciel POINTS CL S Pour les gros syst mes il est difficile de formuler une sp cification d finitive C est pourquoi on supposera que les besoins initiaux du syst me sont incom
22. ologie N 1 En Algerie D INTO Dag USTHB info 2 4 Analyse Sp cification 6 Comment proc der pour faire ce d veloppement Quels moyens faut il mettre en oeuvre Elle comprend la fois des aspects techniques et de gestion Parmi les t ches techniques group es sous le terme tude pr alable on peut citer Dresser un tat de l existant et faire une analyse de ses forces et faiblesses Identifier les id es ou besoins de l utilisateur Formuler des solutions potentielles Faire des tudes de faisabilit Planifier la transition entre l ancien logiciel et le nouveau s il y a lieu Affiner ou finaliser l nonc des besoins de l utilisateur 2 4 Analyse Sp cification Lors de la phase d analyse galement appel e phase de sp cification requirements phase ana lysis phase definition phase on analyse les besoins de l utilisateur ou du syst me englobant et on d finit ce que le logiciel devra faire Le r sultat de la phase d analyse est consign dans un document appel cahier des charges du logiciel ou sp cification du logiciel en anglais software requirements software specification ou requirements specification Il est essentiel qu une sp cification ne d finisse que les caract ristiques essentielles du logiciel pour laisser de la place aux d cisions de conception Ne pas faire de choix d impl mentation ce niveau U
23. omme par exemple module qui dite tous les types de transactions difficile modifier La coh sion occasionnelle la plus mauvaise Le d coupage en modules conduit ce qu une fonction se retrouve assur e par plusieurs modules Dans ce cas il n y a pas de relation entre les l ments du composant COUPLAGE Le couplage est relatif la coh sion C est une indication de la force d interconnexion des diff rents composants d un syst me En r gle g n rale des modules sont fortement coupl s lorsqu ils utilisent des variables partag es ou lorsqu ils changent des informations de contr le LA COMPR HENSIBILIT Pour modifier un composant dans une conception il faut que celui qui est responsable de cette modification comprenne l op ration effectu e par ce composant Cette compr hensibilit d pend d un certain nombre de caract ristiques I Boussa d USTHB Ann e wS PEB D us info Dag USTHB info 2 6 Impl mentation 9 La coh sion Le composant peut il tre compris sans que l on fasse r f rence d autres com posants D appellation Les noms utilis s dans le composant sont ils significatifs Des noms significatifs refl tent les noms des entit s du monde r el que l on mod lise La documentation Le composant est il document de mani re ce que l on puisse tablir une correspondance claire entre le monde r el et le compos
24. ompil s images ex cutables les jeux de tests et leurs r sultats 2 9 Installation Apr s avoir int gr le logiciel on peut l installer dans son environnement d exploitation ou dans un environnement qui simule cet environnement d exploitation et le tester pour s assurer qu il se comporte comme requis dans la sp cification labor e lors de la phase d analyse Cette phase s appelle la phase d installation installation phase ou installation and check out phase Les tests effectu s durant cette phase prennent des noms vari s selon leur nature On parle parfois de validation Si l on veut insister sur le fait que ces tests doivent pr parer la d cision du mandant d accepter ou non le logiciel on utilise les termes test d acceptance test de recette ou test de r ception acceptance test Enfin s il s agit de montrer le comporte ment et les performances du logiciel dans son environnement d exploitation r el le terme test d exploitation est d usage operational test 2 10 Maintenance Apr s l installation suit la phase d exploitation et de maintenance operation and maintenance phase Le logiciel est maintenant employ dans son environnement op rationnel son comporte ment est surveill et si n cessaire il est modifi Cette derni re activit s appelle la maintenance du logiciel software maintenance Il peut tre n cessaire de modifier le logiciel pour corriger
25. plets et inconsistants La d finition des besoins et la sp cification des besoins constituent des moyens de description diff rents niveaux de d tails s adressant diff rents lecteurs I Boussa d USTHB Ann e vS EB D us info USTHB info 2 5 La conception du logiciel 7 La d finition des besoins est un nonc en langue naturelle des services que le syst me est sens fournir l utilisateur Il doit tre crit de mani re tre compr hensible par les d cideurs c t client et c t contractant ainsi que par les utilisateurs et acheteurs potentiels du syst me La sp cification des besoins est un document structur qui nonce les services de mani re plus d taill e Ce document doit tre suffisamment pr cis pour servir de base contractuelle entre le client et le fournisseur du logiciel On peut utiliser des techniques de sp cification formelle pour r diger un tel document mais cela d pendra du bagage technique du client Il est difficile de d tecter les inconsistances ou l incompl tude d une sp cification lorsqu elle est d crite dans un langage naturel non structur On doit toujours imposer une structuration du langage lors de la d finition des besoins Les besoins changent in vitablement Le cahier des charges doit donc tre con u de mani re tre facilement modifiable 2 5 La conception du logiciel La phase d analyse est suivie
26. qu elles impliquent 4 sp cifications non fonctionnelles contraintes charte graphique mat riel marques RAM d bit de connexion Internet interfa age protocoles de communication formats de fichiers etc pour l interaction avec des mat riels logiciels syst mes d exploitation performances temps r el s curit sauvegardes confidentialit charge supporter volume des donn es nombre d utilisateurs simultan s comportement en cas de panne 5 priorit s relatives des sp cifications versions pr voir d lais 6 volutions pr voir 7 annexes Couramment les points 2 6 sont pr sent s en deux temps de fa on g n rale puis de fa on d taill e donnant alors lieu deux parties organis es essentiellement de la m me fa on Une exigence g n rale se d cline alors en plusieurs exigences d taill es A 1 Capture et analyse des besoins r daction R daction d un cahier des charges tre pr cis et organis s aider de notations et diagrammes standards des normes En particulier norme IEEE 830 1998 pour la r daction des sp cifications I Boussa d USTHB Ann e Universitaire 2009 2010 T USTHB info USTHB info A 1 Capture et analyse des besoins r daction 19 organisation num rotation tableaux sch mas exemples ce n est pas un roman diagrammes UML en particulier des cas d utilisation
27. quelle un logiciel se pr te une modification ou une extension des fonctions qui lui sont demand es La r utilisabilit C est l aptitude d un logiciel tre r utilis en tout ou en partie dans de nouvelles applications La compatibilit C est la facilit avec laquelle un logiciel peut tre combin avec d autres logiciels L efficacit On dit d un logiciel qu il est efficace s il utilise les ressources d une mani re optimale comme la m moire et les cycles machine La portabilit C est la facilit avec laquelle un logiciel peut tre transf r sous diff rents environnements mat riels et logiciels produit ind pendant du genre d environnement L int grit C est l aptitude d un logiciel prot ger son code et ses donn es contre des acc s non autoris La facilit d emploi Elle est li e la facilit d apprentissage d utilisation d interpr tation des erreurs et de rattrapage en cas d erreur d utilisation La maintenabilit Elle correspond au degr de facilit de la maintenance d un produit logiciel 1 2 3 Principes du G nie Logiciel Principes utilis s dans le G nie Logiciel G n ralisation regroupement d un ensemble de fonctionnalit s semblables en une fonction nalit param trable g n ricit h ritage I Boussa d USTHB Ann e Universitaire 2009 2010 D us USTHB info USTHB info 1 2 Une
28. r soudre certains probl mes Le mot g nie utilis en g n ral accompagn d un adjectif comme dans g nie civil g nie chi mique ou g nie atomique d signe d apr s le Petit Robert les connaissances et techniques de l ing nieur Ce terme est donc synonyme de science de l ing nieur engineering QU EST CE QU UN LOGICIEL Par logiciel on entend pas seulement l ensemble des programmes informatiques du code associ s une application ou un produit mais galement un certain nombre de documents se rapportant ces programmes et n cessaires leur installation utilisation d veloppement et maintenance sp cification sch mas conceptuels jeux de tests mode d emploi etc Pour les grands syst mes l effort n cessaire pour crire cette documentation est souvent aussi grand que l effort de d veloppement des programmes eux m mes 1 2 2 Qualit exig e d un logiciel S1 le g nie logiciel est l art de produire de bons logiciels il est par cons quent n cessaire de fixer les crit res de qualit d un logiciel La validit C est l aptitude d un produit logiciel remplir exactement ses fonctions d finies par le cahier des charges et les sp cifications La fiabilit ou robustesse C est l aptitude d un produit logiciel fonctionner dans des conditions anormales quelque soit l entr e par exemple L extensibilit C est la facilit avec la
29. sures Il n est pas n cessaire d adopter un seul mod le chaque cycle de la spirale ou m me pour l ensemble d un syst me Le mod le de la spirale englobe tous les autres mod les Le prototypage peut tre utilis dans une spirale pour r soudre le probl me de la sp cification des besoins puis il peut tre suivi d un d veloppement bas sur le mod le conventionnel de la cascade On peut utiliser la transformation formelle pour une partie du syst me haute s curit et une approche bas e sur la r utilisation pour l interface utilisateur 3 4 Le mod le par prototypage Il est quelquefois difficile de formuler une esquisse des besoins surtout lorsque l on conna t peu le domaine Dans ces cas l on ne peut pas esp rer de mani re r aliste d finir les besoins de mani re d finitive avant le d but du d veloppement du logiciel Un mod le de processus bas sur le prototypage se r v le alors plus appropri que le mod le classique de la cascade Le prototypage permet de contourner la difficult de la validation li e l impr cision des besoins et caract ristiques du syst me d velopper Cela veut dire que lorsqu il est difficile d tablir une sp cification d taill e on a recours au prototypage qui est consid r dans ce cas comme un mod le de d veloppement de logiciels Il s agit d crire une premi re sp cification et de r aliser un sous ensemble du produit logicie
30. ues et leurs rem des tels que d finis par Bo hm sont les suivants 1 d faillance de personnel embauche de haut niveau formation mutuelle leaders ad qua tion profil fonction 2 calendrier et budgets irr alistes estimation d taill e d veloppement incr mental r utili sation lagage des besoins 3 d veloppement de fonctions inappropri es revues d utilisateurs manuel d utilisation pr coce I Boussa d USTHB Ann e Universitaire 2009 2010 USTHB info USTHB info 3 4 Le mod le par prototypage 15 Sp cification R alisation Evaluation Acceptation z sch matique du prototype prototype du logiciel Utilisation du logiciel non oui Logiciel ad quat FIGURE 3 4 Le mod le par prototypage 4 d veloppement d interfaces utilisateurs inappropri es maquettage analyse des t ches 5 produit plaqu or analyse des co ts b n fices conception tenant compte des co ts 6 volatilit des besoins d veloppement incr mental de la partie la plus stable d abord masquage d information 7 probl mes de performances simulations mod lisations essais et mesures maquettage 8 exigences d mesur es par rapport la technologie analyses techniques de faisabilit ma quettage 9 t ches ou composants externes d faillants audit des sous traitants contrats revues ana lyse de compatibilit essais et me
31. www USTHB info Sites des Sciences et de la Technologie N 1 En Algerie D a USTHB info Cours G nie Logiciel Ilhem Boussa d 15 octobre 2009 USTHB inf www USTHB info Sites des Sciences et de la Technologie N 1 En Algerie Table des mati res 1 1 Analyse de l existant Crise du logicie 1 2 Une solution 2 CYCLE DE VIE DU LOGICIE 2 3 tude d opportunit ou tude pr alable 2 5 1 Conception g n rale 2 5 3 Qualit d une conception 2 10 Maintenance 3 Mod les de d veloppement d un logicie 3 1 Le cycle de vie en Cascade waterfall model 3 2 Le cycle de vie en V 3 4 Le mod le par prototypage 3 Le mod le par incr ment 3 60 M thodes de conceptio A Cahier des charge A l Capture et analyse des besoins r dactio de G nie Logiciel 12 5 Dhs di G nie ere 2 1 D finition sde sera strass ads 22 Etapes du cycle de vid 2 4 Analyse Sp cification 2 5 La conception du logiciel a a a a a a a a a 2 5 2 Conception d taill d 26 Impl mentation oaoa aa a a a a a 44 4 2 7 Test unitaire ee 2 9 TERRE O E E L LLL 3 3 Le cycle de vie en spiralg oa a a a a a a a a a a a a a USTHB info I Boussa d USTHB Ann e Universitaire 2009 2010 De u www USTHB info Sites des Scien
Download Pdf Manuals
Related Search