03 Slides GL 2010-Site

Cycle de vie dun logicielIlhem Boussad [email protected] des Sciences et de la Technologie Houari Boumediene Licence 3 Acadmique http://sites.google.com/site/ilhemboussaid

20 novembre 2010

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

1 / 60

Cycle de vie

Plan

1

Cycle de vieProcessus de dveloppement tapes du cycle de vie Forte cohsion Forte cohsion Cycle de vie en cascade Cycle de vie en V Prototypage Cycle de vie en spirale Cycle itratif et incrmental

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

2 / 60

Cycle de vie

Processus de dveloppement

Processus de dveloppement : cest quoi ?Le dveloppement et lvolution dun logiciel doit tre vu comme un processus. Processus : Ensemble dactivits coordonnes et rgules, en partie ordonnes, dont le but est de crer un produit. Processus de dveloppement Lordre et la manire denchaner les tapes dun dveloppement Un processus dcrit 2 choses importantes :Les activits (tapes) (QUOI ?) Lenchainement des activits (QUAND ?)

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

3 / 60

Cycle de vie

Processus de dveloppement

Processus de dveloppement : Pourquoi ?Un logiciel dvelopper est un problme trs complexe rsoudre. Pour apprhender la complexit de dveloppement du logiciel, il faut arriver : rendre les choses simples. sparer les problmes qui peuvent ltre an de les rsoudre de manire presque indpendante. Diviser pour mieux rgner.

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

4 / 60

Cycle de vie

tapes du cycle de vie

ActivitLes activits dun processus sont souvent dcrites en termes de : Entres de lactivit (matire premire) Sorties de lactivit (rsultat) Intervenants et rles (qui ?) Description de lactivit (quoi - quel est le problme traiter ?) Standards, guides, best practices appliquer (comment ?)

Activit Quoi Comment

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

5 / 60

Cycle de vie


Activits : les classiques Activits: les

classiques

Les Activitscourantes et problmes traits : activits courantes et problmes traits:

Quest-ce que le logiciel doit faire? Comment sassurer quil le fait? Comment sassurer quon dveloppe le bon logiciel?

Spcifier

Le logiciel fait-il ce quil doit faire? Dveloppe t on le bon logiciel?

Valider

Comment organiser le logiciel pour quil fasse ce quil doit faire? Quelles choix techniques faut-il faire pour que le logiciel fasse ce quil doit faire? Comment sassurer que le logiciel est organis et construit de manire faire ce quil doit faire?

Concevoir

Le logiciel est-il organis et construit de manire faire ce quil doit faire?

Intgrer

Comment traduit-on cette organisation en code source?ESISAR

Coder

Tester unitairementLe code source est-il bien crit?51

GENIE LOGICIEL - E.CHENU

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

6 / 60

Cycle de vie


Faisabilit (pourquoi ?)

Questions Pourquoi dvelopper le logiciel ? Y a-t-il de meilleures alternatives ? Comment procder pour faire ce dveloppement ? Y a-t-il un march pour le logiciel ? Quels moyens faut-il mettre en oeuvre ? A-t-on le budget, le personnel, le matriel ncessaires ?

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

7 / 60

Cycle de vie


Faisabilit (pourquoi ?)Activit Description Entres Sorties tude pralable Etudier la faisabilit du projet, ses contraintes techniques (cot, temps, qualit) et les alternatives possibles Problme rsoudre, objectifs atteindre OUI(la dcision est prise de raliser le logiciel) ou NON(le projet est abandonn)

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

8 / 60

Cycle de vie


Spcification (quoi ?)Activit Description Spcier Dcrire ce que doit faire le logiciel (comportement en boitenoire). Dcrire comment vrier en boite-noire que le logiciel fait bien ce qui est exig. Client qui a une ide de ce quil veut. Exigences, dsir, besoins. . . concernant le systme permettant de rsoudre le problme. Cahier des charges du logiciel (ou spcication du logiciel). Des procdures de validation. Version provisoire des manuels dutilisation et dexploitation du logiciel

Entres

Sorties

Une spcication peut suivre de nombreux formalismes : cas dutilisation, modles UML, exigences, ... Les procdures de validation peuvent tre des procdures manuelles ou des tests.I. BOUSSAID (USTHB) Cycle de vie 20 novembre 2010 9 / 60

Cycle de vie


Spcification - Bonnes pratiquesUne bonne dnition des exigences est capitale et contribue la russite du projet en : permettant dobtenir un accord explicite entre les dveloppeurs, les clients et les utilisateurs sur le travail raliser et les critres dacceptation du systme nal, fournissant une base solide pour lestimation des ressources ncessaires (temps, cot, quipement, qualications des dveloppeurs,. . . ), vitant les incomprhensions et les omissions.

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

10 / 60

Cycle de vie


Spcification - Difficults

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

11 / 60

Cycle de vie



Les besoins du client sont imprcis et changeants, 2 pratiques direntes du gnie logiciel sopposent sur la manire de traiter ce problme :Faut-il faire un eort pour prciser et ger le besoin du client en dbut de projet ? Faut-il dvelopper de manire tre tolrant aux imprcisions et aux changements de besoins ?

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

12 / 60

Cycle de vie



Les erreurs dans les exigences sont plus frquentes que celles de conception et dimplmentation. Elles sont galement les plus diciles et les plus coteuses corriger a posteriori.Il est donc important de les reprer le plus rapidement possible.

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

13 / 60

Cycle de vie


Spcification - Cahier de chargesPlan type :

Le cahier des charges est un document recensant les spcications/exigences. Il rsulte de lanalyse et est contractuel entre le client et lentreprise informatique qui va raliser le logiciel. Il doit donc tre valid par les deux. Qualits attendues : non ambigu, complet, vriable, cohrent, mo-

diable, traable, utilisable durant la maintenance, indpendant des solutions (voir notamment la norme IEEE 830). 1. introduction : prsentation gnrale, motivations, dnitions des termes 2. contexte : environnement matriel et humain, acteurs et utilisateurs, interaction avec dautres systmes et logiciels, existant 3. spcications fonctionnelles : grandes fonctionnalits du systme, acteurs et autres systmes quelles impliquent 4. spcications non fonctionnelles, contraintes : charte graphique matriel : marques, RAM, dbit de connexion Internet... interfaage : protocoles de communication, formats de chiers, etc., pour linteraction avec des matriels, logiciels, systmes dexploitation... performances : temps rel... scurit : sauvegardes, condentialit, ... charge supporter : volume des donnes, nombre dutilisateurs simultans, ... comportement en cas de panne... 5. priorits relatives des spcications, versions prvoir, dlais 6. volutions prvoir 7. annexes Couramment, les points 2 6 sont prsents en deux temps, de faon gnrale puis de faon dtaille, donnant alors lieu deux parties organises essentiellement de la mme faon. Une (norme IEEE 830 :1993) exigence gnrale se dcline alors en plusieurs exigences dtailles.I. BOUSSAID (USTHB) Cycle de vie 20 novembre 2010 14 / 60

Cycle de vie


Spcification - Cahier de chargesQualits requises dans un cahier de charges : Bon niveau de gnralit Formulation adquate des besoins ? Problme bien dcrit tre prcis, non ambigu malgr lusage dun langage naturel (= mathmatique) tre complet (pas domission involontaire) tre cohrent (pas dinfrence de fonctionnalits) tre vriable : critres de validation dnis. valuer la faisabilit des besoins ? faire ventuellement une maquette, une simulation tre modiable : facilit exprimer un changement ou ajout de besoins

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

15 / 60

Cycle de vie


Spcification - Cahier de chargesRdaction dun cahier des charges : norme IEEE 830 (1998) pour la rdaction des spcications ; organisation : numrotation, tableaux, schmas, exemples. . . (ce nest pas un roman !) ; diagrammes UML : en particulier des cas dutilisation pour prsenter les fonctionnalits et les acteurs quelles impliquent ; autres schmas : crans types, diagramme de dploiement UML... scnarios (dinteraction) : illustration des cas dutilisation complexes par un exemple dinteraction le ralisant ; spcier les acteurs impliqus et lenchanement des interactions sur un exemple (ventuellement par un diagramme de squence UML), ainsi que le traitement des erreurs et les ventuelles prconditions et postconditions ;

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

16 / 60

Cycle de vie


Spcification - ExempleUn Guichet Automatique de Banque (GAB) ore les services suivants : Distribution dargent tout Porteur de carte de crdit, via un lecteur de carte et un distributeur de billets. Consultation de solde de compte, dpt en numraire et dpt de chques pour les clients porteurs dune carte de crdit de la banque. Un oprateur de maintenance se charge de la collecte des dpts dargent et de la recharge du distributeur.

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

17 / 60

Cycle de vie


Spcification - ExempleSystem Retirer de l'argent

Porteur de carte Consulter son solde

Dposer l'argent Client de la banque Recharger la caisse

Collecter dpt d'argent Oprateur de maintenance Maintenir l'tat oprationnel

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

18 / 60

Cycle de vie


Spcification - Exemple

Besoins dinterface Homme/Machine (IHM) Les dispositifs d entre/sortie la disposition du Porteur de carte doivent tre :Un lecteur de carte bancaire. Un clavier numrique (pour saisir son code), avec des touches "validation", "correction" et "annulation". Un cran pour lachage des messages du GAB. Des touches autour de lcran pour slectionner un montant de retrait parmi ceux qui sont proposs. Un distributeur de billets. Un distributeur de tickets.

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

19 / 60

Cycle de vie


Conception (comment ?)

Activit Description

Entres Sorties

Concevoir Organiser le logiciel an quil puisse satisfaire les exigences de la spcication. Faire les principaux choix techniques pour satisfaire les exigences de la spcication. Une spcication. Une description des dcisions de conception. Des procdures de tests qui permettent de vrier que les dcisions de conception sont correctement implmentes en code source et quelles contribuent satisfaire les exigences de la spcication.

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

20 / 60

Cycle de vie


Conception architecturaleDcomposer le systme en sous-systmes Dnir les interfaces, les liens entre les composants Rsultat : Une description de larchitecture du logiciel.

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

21 / 60

Cycle de vie


Conception dtailleDtailler le fonctionnement des composants Dnir quelques algorithmes, la reprsentation des donnes, ... des tests unitaires sont dnis pour sassurer que les composants raliss sont bien conformes leurs descriptions. Rsultat : pour chaque composant, le rsultat consiste enUn dossier de conception dtaille. Un dossier de tests unitaires. Un dossier de dnition dintgration logiciel.

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

22 / 60

Cycle de vie


Qualit dune conception

La composante la plus importante de la qualit dune conception est la maintenabilit.maximiser la cohsion lintrieur des composants minimiser le couplage entre ces composants

Les dgradations de la conception sont lies aux modications des spcications, Ces modications sont faire vite et par dautres que les concepteurs originauxa marche mais sans respect de la conception initiale corruption de la conception (avec eet ampli au fur et mesure)

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

23 / 60

Cycle de vie


Couplage/Cohsion

A RETENIR ABSOLUMENT Pour quun logiciel soit extensible et rutilisable, il faut quil soit dcoup en modulesfaiblement coupls et forte cohsion.

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

24 / 60

Cycle de vie


Couplage

CouplageUne entit (fonction, module, classe, package, composant) est couple une autre si elle dpend delle.

Couplage faibleDsigne une relation faible entre plusieurs entits (classes, composants), permettant une grande souplesse de programmation, de mise jour. Ainsi, chaque entit peut tre modie en limitant limpact du changement au reste de lapplication.

Couplage fortau contraire, tisse un lien puissant qui rend lapplication plus rigide toute modication de code.

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

25 / 60

Cycle de vie


Couplage fort

Couplage Fort

Mesurez limpact dune modification de ces modules

Module 1

Module 2

Module 3

Module 6

Module 4

Module 5

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

26 / 60

Cycle de vie


Couplage faibleCouplage FaibleMesurez limpact de modification dun des modules

Module 1

Module 2

Module 3

Module 6

Module 4

Module 5

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

27 / 60

Cycle de vie

Forte cohsion

Forte cohsion

Cohsion entre modules dans un composant, entre services dans un module :"qui se ressemble sassemble " Lide est de vrier que nous rassemblons bien dans une classe des mthodes cohrentes, qui visent raliser des objectifs similaires.

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

28 / 60

Cycle de vie

Forte cohsion

Cohsion - Mauvais exempleMauvais exemple : il serait mal venu dimplmenter une mthode "Acher()" ou "Tracer()" puisque lobjectif de cette classe est de reprsenter le modle dun compte en banque et non celui dune fentre graphique ou dun service de journalisation.

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

29 / 60

Cycle de vie

Forte cohsion

Implantation (comment ?)Activit Description Coder et tester crire le code source du logiciel. Tester le comportement du code source an de vrier quil ralise les responsabilits qui lui sont alloues. Spcication, conception. Code source. Tests unitaires. Documentation

Entres Sorties

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

30 / 60

Cycle de vie

Forte cohsion

IntgrationActivit Description Entres Sorties Intgrer Assembler le code source du logiciel (ventuellement partiellement) et drouler les tests dintgration. Conception, code source, tests dintgration (tests). Un rapport de test dintgration.

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

31 / 60

Cycle de vie

Forte cohsion

ValidationActivit Description Entres Sorties Valider Construire le logiciel complet excutable. Drouler les tests de validation sur le logiciel complet excutable. Logiciel complet excutable valider. Tests de validation. Rapport de tests de validation.

Qualication (ou recette), cest--dire la vrication de la conformit du logiciel aux spcications initiales.

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

32 / 60

Cycle de vie

Forte cohsion

Maintenance

Activits : maintenance corrective : correction des bugs maintenance adaptative : ajuster le logiciel Maintenance perfective, dextension : augmenter/amliorer les possibilits du logiciel Productions : logiciel corrig mises jour documents corrigs

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

33 / 60

Cycle de vie

Forte cohsion

Maintenance corrective

Corriger les erreurs : dfauts dutilit, dutilisabilit, de abilit...Identier la dfaillance, le fonctionnement Localiser la partie du code responsable

AttentionLa plupart des corrections introduisent de nouvelles erreurs Les cots de correction augmentent exponentiellement avec le dlai de dtection Corriger et estimer limpact dune modication

La maintenance corrective donne lieu de nouvelles livraisons (release)

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

34 / 60

Cycle de vie

Forte cohsion

Maintenance adaptative

Maintenance adaptative Ajuster le logiciel pour quil continue remplir son rle compte tenu du lvolution desEnvironnements dexcution Fonctions satisfaire Conditions dutilisation

Ex : changement de SGBD, de machine, de taux de TVA, an 2000, euro...

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

35 / 60

Cycle de vie

Forte cohsion

Maintenance perfective

Maintenance perfective, dextension Accrotre/amliorer les possibilits du logiciel Ex : les services oerts, linterface utilisateur, les performances... Donne lieu de nouvelles versions

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

36 / 60

Cycle de vie

Cycle de vie en cascade


Le modle en cascade (Waterfall model) est le plus classique des cycles de vie. Cycle de vie linaire sans aucune valuation entre le dbut du projet et la validation Le projet est dcoup en phases successives dans le temps A chaque phase correspond une activit principale bien prcise produisant un certain nombre de livrables Chaque phase ne peut remettre en cause que la phase prcdente

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

37 / 60

Cycle de vie


Cycle de vie en cascadeFaisabilit & cahier des charges

Spcification

Conception architecturale

Conception dtaille

Programmation

Intgration

Installation

Exploitation & maintenance

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

38 / 60

Cycle de vie


Cycle de vie en cascade - Inconvnients

Inconvnients Les vrais projets suivent rarement un dveloppement squentiel tablir tous les besoins au dbut dun projet est dicile Aucune validation intermdiaire (Aucune prparation des phases de vrication)Obligation de dnir la totalit des besoins au dpart augmentation des risques car validation tardive : remise en question coteuse des phases prcdentes

Sensibilit larrive de nouvelles exigences : refaire toutes les tapes Bien adapt lorsque les besoins sont clairement identis et stables

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

39 / 60

Cycle de vie


Cycle de vie en cascade - Inconvnients

Modle en cascadeSpcification Conception Code & Test Intgration Validation Maintenance

Spcification 100% Utilisable 0% Conception 100% Utilisable 0%

Code & Test 100% Utilisable 0% Intgration 100% Utilisable 0%

Validation 100% Utilisable 100%

Customer Feed-back starts

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

40 / 60

Cycle de vie

Cycle de vie en V

Cycle de vie en V

A ce jour, le cycle en V reste le cycle de vie le plus utilis. Cest un cycle de vie orient test : A chaque activit crative (spcication, conception et codage) correspond une activit de vrication (validation, intgration, tests unitaires). Chaque phase en amont prpare la phase correspondante de vrication (la vrication est prise en compte au moment mme de la cration).

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

41 / 60

Cycle de vie

Cycle de vie en V

Cycle de vie en V

Faisabilit & cahier des charges

Installation & test systme

Spcification

Test dacceptation

Conception architecturale

Intgration & test dintgration

Conception dtaille

Test unitaire

Programmation

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

42 / 60

Cycle de vie

Cycle de vie en V

Avantages et inconvnientsAvantages La prparation des dernires phases (validation-vrication) par les premires (construction du logiciel), permet dviter dnoncer une proprit quil est impossible de vrier objectivement aprs la ralisation. Inconvnients Construit-on le bon logiciel ? Le logiciel est utilis trs (trop) tard.Il faut attendre longtemps pour savoir si on a construit le bon logiciel. Dicile dimpliquer les utilisateurs lorsque quun logiciel utilisable nest disponible qu la dernire phase

Idal quand les besoins sont bien connus, quand lanalyse et la conception sont claires

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

43 / 60

Cycle de vie

Cycle de vie en V

Documents et phasesphases documents cahier des charges du projet spcification conception gnrale conception dtaille listages tests unitaires test dintgration test de rception manuels dutilisation et dexploitation ? ? ? document partiellement labor pendant la phase ? document ventuellement complt pendant la phase ? ? avantprojet analyse conception gnrale conception dtaille implmentation tests unitaires intgration installation et test et test de dintgration rception

document labor entirement pendant la phase document en entre de la phase

I. BOUSSAID (USTHB)

Fig. 8 Documents et phases Cycle de vie

20 novembre 2010

44 / 60

Cycle de vie

Prototypage

Prototypage

Construit et utilis en phase danalyse (spcication)Discuter et interagir avec lutilisateur - Pour montrer aux clients les fonctions que lon veut mettre en oeuvre identier les besoins : Je saurai ce que je veux quand je le verrai ! Vrier des choix spciques dIHM

Construit et utilis en phase de conceptionsassurer de la faisabilit de parties critiques valider des options de conception Vrier lecacit relle dun algorithme

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

45 / 60

Cycle de vie

Prototypage

Prototypage volutif/jetable

(Prototype jetable) : squelette du logiciel qui nest cre que dans un but et dans une phase particulire du dveloppement Si gard, alors sappelle (prototype volutif)Premire version du prototype = embryon du produit nal On itre jusquau produit nal

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

46 / 60

Cycle de vie

Prototypage

Prototypage : Avantages/Inconvnients

Avantage :Les eorts consacrs au dveloppement dun prototype sont le plus souvent compenss par ceux gagns ne pas dvelopper de fonctions inutiles

Mais :Les dcisions rapides sont rarement de bonnes dcisions Le prototype volutif donne-t-il le produit demand ?

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

47 / 60

Cycle de vie

Cycle de vie en spirale


I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

48 / 60

Cycle de vie



Chaque cycle de la spirale se droule en quatre phases :1

dtermination, partir des rsultats des cycles prcdents, ou de lanalyse prliminaire des besoins, des objectifs du cycle, des alternatives pour les atteindre et des contraintes ; analyse des risques, valuation des alternatives et, ventuellement maquettage ; dveloppement et vrication de la solution retenue, un modle classique (cascade ou en V) peut tre utilis ici ; revue des rsultats et vrication du cycle suivant.

2

3

4

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

49 / 60

Cycle de vie


Spirale : Analyse des risquesRisques technologiques exigences dmesures par rapport la technologie lincomprehension des fondements de la technologie changement de technologie en cours de route ... Risques lis au processus gestion projet mauvaise ou absente calendrier et budget irralistes calendrier abandonn sous la pression des clients dveloppement de fonctions inappropries ... Risques humains dfaillance du personnel surestimation des comptences travailleur solitaire manque de motivationI. BOUSSAID (USTHB) Cycle de vie 20 novembre 2010 50 / 60

Cycle de vie

Cycle itratif et incrmental


I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

51 / 60

Cycle de vie


Cycle itratif et incrmentalSegmentation du travail Concentration sur les besoins et les risques Les itrations sont des prototypesExprimentation et validation des technologies Planication et valuation

Une mini-cascade Les prototypes senroulent autour du noyau de larchitecture

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

52 / 60

Cycle de vie


PrincipesDveloppez de petits incrments fonctionnels livrs en courtes itrations " Un tiens vaut mieux que deux tu lauras. " Un incrment fonctionnel est un besoin du client. Pour chaque version dvelopper aprs la 1re version livre, il faut arbitrer entre :les demandes de correction, les demandes de modication et les nouvelles fonctionnalits dvelopper.Demande de correction Demande de modification Nouvelles fonctionnalits

Dfinir le contenu de litration

Contenu de litration

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

53 / 60

Cycle de vie


Dans quel ordre faut-il raliser les itrations ?

Pilotez le dveloppement par les priorits.Commencez par dvelopper les fonctionnalits les plus importantes pour le client et les plus risques.

Pilotez le dveloppement par les tests dacceptation.crivez des tests automatiss dacceptation. Utilisez ces tests pour mesurer lavancement du dveloppement Il ny a pas de meilleure mesure de lavancement que les fonctionnalits sexcutant conformment aux besoins du client. Une fonctionnalit sexcute conformment au besoin du client si elle russit ses tests dacceptation.

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

54 / 60

Cycle de vie


Pilotage par les risques

Pilotage par les risques

Dmarche itrative et incrmentale

17

Pierre-Alain Muller

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

55 / 60

Cycle de vie


AvantagesLe cycle de vie itratif est en phase avec la ralit permet la prise en compte de lvolution demande un pilotage continu bien adapt lapproche objet (et inversement) Les choix techniques (spcication, conception, codage) sont valids trs tt par test.Lenchainement des itrations permet de rgulirement vrier que lon construit bien le logiciel.

Le logiciel est utilis trs tt.Lenchainement des itrations permet aux utilisateurs de vrier rgulirement que lon construit le bon logiciel.

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

56 / 60

Cycle de vie


Principaux risques rcurrents

Intgration trop complexe Environnement non adapt Utilisateurs dfavorables Technologie complexe Lourdeur des activits manuelles Composants rutilisables inadapts

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

57 / 60

Cycle de vie


Cycle de vie en cascade vs. ItratifModle en cascadeSpcification Conception Code & Test Intgration Validation Maintenance

Spcification 100% Utilisable 0% Conception 100% Utilisable 0%

Code & Test 100% Utilisable 0% Intgration 100% Utilisable 0%

Validation 100% Utilisable 100%

Customer Feed-back starts

Modle itratif & incrmentalSpec. Design Code Intg. Valid. & Test Spec. Design Code Intg. Valid. & Test Spec. Design Code Intg. Valid. & Test Spec. Design Code Intg. Valid. & Test

Incrment #1Utilisable 30%




Customer Feedback starts

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

58 / 60

Cycle de vie


Cycle en V versus iter&inc Cycle de vie encascade vs. Itratif

ESISARI. BOUSSAID (USTHB)

GENIE LOGICIEL - E.CHENUCycle de vie 20 novembre 2010

8459 / 60

Cycle de vie


Cycle de vie en cascade vs. Itratif

Cycle en V versus iter&inc

ESISAR

GENIE LOGICIEL - E.CHENU

85

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

60 / 60

Cycle de vie


Chenu, Emmanuel Cours - Gnie Logiciel orient Objet, ESISAR Chenu, Emmanuel Cours - Gnie Logiciel pragmatique, ESISAR Marie-Claude Gaudel Prcis de gnie logiciel Editions Dunod Grard, Pierre Gnie Logiciel - Principes et Techniques, Bertrand Meyer Conception et programmation orientes objet Editions Eyrolles, 2000 Pierre-Alain Muller Dmarche itrative et incrmentale I. Sommerville et Franck Valle Software Engineering 6th edition, Addison-Wesley, 2001 Strohmeier, Alfred Cycle de vie du Logiciel, Laboratoire de Gnie Logiciel - Dpartement dInformatique. Ecole Polytechnique Fdrale de Lausanne

I. BOUSSAID (USTHB)

Cycle de vie

20 novembre 2010

60 / 60

03 Slides GL 2010-Site

Documents

Transcript of 03 Slides GL 2010-Site