2.

DIFFERENTS MODELES DE CYCLE

DE VIE

2.1. INTRODUCTION ............................................................................................ 1

2.1.1 Notion de cycle de vie ......................................................................... 1
2.1.2 Justification du cycle de vie ............................................................... 1
2.2. LES DIFFERENTES PHASES DU CYCLE DE VIE................................... 2
2.2.1 Dfinition des Objectifs....................................................................... 2
2.2.2 Dfinition des Besoins......................................................................... 2
2.2.3 Dfinition du Produit........................................................................... 2
2.2.4 Planification et gestion de projet ......................................................... 3
2.2.5 Conception globale.............................................................................. 3
2.2.6 Codage et tests unitaires ...................................................................... 3
2.2.7 Intgration ........................................................................................... 3
2.2.8 Qualification........................................................................................ 4
2.2.9 Maintenance ........................................................................................ 4
2.2.10 Dure de cycle de vie.......................................................................... 4
2.2.11 Facteurs d'instabilit............................................................................ 4
2.2.12 Les tches d'un projet logiciel par activits et par phases ................... 5
2.3. CYCLE DE VIE DES LOGICIELS EN CASCADE ET EN V.......................... 6
2.3.1 Modle en cascade............................................................................... 6
2.3.2 Modle en V ........................................................................................ 7
2.3.3 Analyse de ces modles de cycle de vie.............................................. 8
2.3.4 Conclusion........................................................................................... 8
2.4. MAQUETTAGE, PROTOTYPAGE .............................................................. 9
2.4.1 Prototypage rapide ou maquettage .................................................... 10
2.4.2 Prototype exprimental...................................................................... 10
2.4.3 Prototype volutif .............................................................................. 11
2.5. DEVELOPPEMENT INCREMENTAL ...................................................... 11
2.6. MODELE EN SPIRALE (BOEHM)............................................................. 13
2.6.1 Conditions d'application.................................................................... 13
2.7. METHODE MERISE (TARDIEU) .............................................................. 14
2.8. MODELE DE CYCLE DE VIE ORIENTE OBJETS ................................ 15
2.9. RAPID AIDED DESIGN ............................................................................... 16
2.10. REFERENCES ............................................................................................. 17
 2 DIFFERENTS MODELES DE
CYCLES DE VIE

2. DIFFERENTS MODELES DE CYCLES DE VIE .................................................... 1

2.1. INTRODUCTION............................................................................................. 1
2.1.1 Notion de cycle de vie ......................................................................... 1
2.1.2 Justification du cycle de vie ............................................................... 1
2.2. LES DIFFERENTES PHASES DU CYCLE DE VIE ................................... 2
2.2.1 Dfinition des Objectifs....................................................................... 2
2.2.2 Dfinition des Besoins......................................................................... 2
2.2.3 Dfinition du Produit........................................................................... 3
2.2.4 Planification et gestion de projet ......................................................... 3
2.2.5 Conception globale.............................................................................. 3
2.2.6 Codage et tests unitaires ...................................................................... 3
2.2.7 Intgration ........................................................................................... 4
2.2.8 Qualification........................................................................................ 4
2.2.9 Maintenance ........................................................................................ 4
2.2.10 Dure de cycle de vie .......................................................................... 4
2.2.11 Facteurs d'instabilit............................................................................ 4
2.2.12 Rcapitulation : Les tches d'un projet logiciel par activits et par
phases 6
2.3. CYCLE DE VIE DES LOGICIELS EN CASCADE ET EN V................... 7
2.3.1 Modle en cascade............................................................................... 7
2.3.2 Modle en V ........................................................................................ 8
2.3.3 Analyse de ces modles de cycle de vie.............................................. 9
2.3.4 Conclusion........................................................................................... 9
2.4. MAQUETTAGE, PROTOTYPAGE ............................................................ 10
2.4.1 Prototypage rapide ou maquettage .................................................... 11
2.4.2 Prototype exprimental...................................................................... 11
2.4.3 Prototype volutif .............................................................................. 12
2.5. DEVELOPPEMENT INCREMENTAL....................................................... 12
2.6. MODELE EN SPIRALE (BOEHM 1988) .................................................... 14
2.6.1 La dmarche:........................................................................................... 14
2.6.2 Analyse des risques................................................................................. 15
2.6.3 Conditions d'application.......................................................................... 15
2.7. RAD :"RAPID APPLICATION DEVELOPMENT " ................................ 16
2.8. METHODE MERISE (TARDIEU 1978)...................................................... 17
2.9. MODELE DE CYCLE DE VIE ORIENTE OBJETS........................................ 19
2.10 20
. MODELE DE CYCLE DE VIE ORIENTE REUTILISATION DE
COMPOSANTS ............................................................................................................ 20
2.10. REFERENCES .................................................................................................... 21

Gnie logiciel Anne-Marie Hugues 19/12/02 2-1

 2. DIFFERENTS MODELES DE
CYCLES DE VIE

2.1. INTRODUCTION

2.1.1 Notion de cycle de vie

C'est la description d'un processus couvrant les phases de:
- Cration d'un produit,
- Distribution sur un march,
- Disparition.
Le but de ce dcoupage est de
- Matriser les risques,
- Matriser au mieux les dlais et les cots,
- Obtenir une qualit conforme aux exigences.
On distingue deux types de cycle de vie
- Le cycle de vie des produits s'applique tous les types de produits, et peut tre
considr comme un outil de gestion.
- Le cycle de dveloppement des logiciels s'insre dans le prcdent, on l'appelle
souvent abusivement cycle de vie des logiciels

2.1.2 Justification du cycle de vie

Cycle de vie et assurance qualit sont fortement lis; il faudra donc en permanence
assurer:
la validation: sommes nous en train de faire le bon produit?
(Du latin "VALIDARE", dclarer valide)
la vrification: est ce que nous faisons le produit correctement
(Du latin "VERITAS ", la vrit)
La validation et la vrification sont en gnral garanties par la mise en place d'inspections
et de revues. L'inspection est une lecture critique d'un document (specification, conception,
code, plan d'intgration...); elle est destine amliorer la qualit d'un document.
De manire gnrale, l'inspection est faite par une quipe indpendante du projet
constitue par: un Modrateur, un Experts(s), Secrtaire , le client ventuellement un
banquier, un reprsentant du service qualit...
Pour qu'elle puisse tre profitable, une inspection doit donner lieu la rdaction de fiches
de dfauts avec une chelle de gravit et la dfinition des responsabilits concernant la
correction des dfauts.
Les inspections sont la base des dcisions prises en revues. Une revue est une runion
permettant de valider une des phases du cycle de vie.
On distingue
- les revues produits: tat d'un projet sous ses diffrents aspects: Techniques,
Financiers, Commerciaux, Calendrier, ...
- les revues techniques (celles qui nous intressent le plus dans le cadre de ce
cours): elles permettent de fournir au marketing et l'unit de dveloppement
une valuation des aspects techniques du projet et des cots de ralisation
- les runions de dcision: elles valident le passage la phase suivante et font
bien souvent suite l'une des deux prcdentes.

Gnie logiciel Anne-Marie Hugues 19/12/02 2-1

 Chaque objectif intermdiaire doit tre atteint:
Garantie de qualit
Exemple d'aprs Boehm
Logiciel de rservation arienne (Univac-United Airlines) dun cot de 56 millions de
dollars non utilisable par manque d'analyse des besoins et d'tude de faisabilit:
- 146 000 instructions par transaction,
- au lieu de 9 000 prvues.
Ceci aurait pu tre vit par des inspections et des revues intermdiaires.
Garantie d'efficacit
Il est plus facile de respecter un objectif court terme qu' moyen ou long terme
Tout ordre diffrent conduira un produit moins satisfaisant et beaucoup plus cher.
Les erreurs sont de plus en plus coteuses rparer lorsqu'elles sont dcouvertes tard dans le
cycle de vie: d'o le rle primordial des inspections. (cf. courbe des ratios)

400
Projets 74-80

IBM AS /400 (94)

300

200

100

0
besoins planification codage maintenance
specification conception intgration

2.2. LES DIFFERENTES PHASES DU CYCLE DE VIE

2.2.1 Dfinition des Objectifs

Le management tudie la stratgie et dcide de la ncessit de fabriquer ou acheter un
nouveau produit. On s'intresse aux produits contenant du logiciel.
C'est pendant cette phase qu'est dfini un schma directeur dans le cas de la cration ou de
la rnovation d'un systme d'information complet d'une entreprise prenant en compte la
stratgie de l'entreprise (voir mthode Merise).

2.2.2 Dfinition des Besoins

Un cahier des charges est tabli par le client aprs consultation des divers intervenants du
projet ( utilisateurs, encadrement...), un appel d'offres est ventuellement lanc.
Le cahier des charges dcrit, en langage naturel, les fonctionnalits attendues du produit
ainsi que les contraintes non fonctionnelles (temps de rponse, contraintes mmoire...). Dans
le cas de la refonte d'un systme complet on peut avoir un cahier des charges par sous
domaine.
Le produit intermdiaire obtenu l'issue de cette phase est le cahier des charges.
On peut dcrire le produit partir de diffrents scnarii d'utilisation (Use Case). Le
chapitre 4 reprend ces mthodes.

2-2 Anne-Marie Hugues 19/12/02 Gnie logiciel

2.2.3 Dfinition du Produit
Les spcifications prcises du produit sont dcrites ainsi que les contraintes de ralisation.
A l'issue de cette phase, les fournitures intermdiaires sont le dossier de spcifications
fonctionnelles et une premire version du manuel utilisateur.
On peut galement dsigner cette phase par le terme analyse des besoins. A l'issue de
cette phase, le client et le fournisseur sont d'accord sur le produit raliser et les contraintes
auxquelles il doit obir ainsi que sur la faon de l'utiliser et en particulier sur l'interface
utilisateur qu'il s'agisse d'une interface homme-machine ou d'une API.
Les produits intermdiaires l'issue de cette phase sont
- le dossier d'analyse comprenant les spcifications fonctionnelles et non
fonctionnelles du produit
- une bauche du manuel utilisateur
- une premire version du glossaire contenant les termes propres au projet
Il existe diffrentes mthodes et formalismes qui peuvent tre utiliss pendant cette phase,
ils seront vus au chapitre 4.

2.2.4 Planification et gestion de projet

Il est vident que le client comme le dveloppeur doivent tre d'accord sur les cots et la
dure du projet. La phase de planification permet de dcouper le projet en tches, de
dcrire leur enchanement dans le temps, d'affecter chacune une dure et un effort
calcul en homme*mois. Il est galement important de dfinir les normes qualit qui seront
appliques comme la mthode de conception choisie ou les rgles qui rgiront les tests. On
notera galement les dpendances extrieures (comme par exemple l'arrive d'une nouvelle
machine ou d'un nouveau logiciel) afin de mesurer les risques encourus. Cette phase est
traite en dtail dans le chapitre 3.
Les produits intermdiaires l'issue de cette phase sont
- le plan qualit,
- le plan projet destin aux dveloppeurs,
- une estimation des cots rels (utile pour le management)
- un devis destin au client prcisant le prix payer, les dlais et les fournitures.
- une liste des dpendances extrieures
En cas de ralisation du produit par un sous-traitant le dossier de spcifications
fonctionnelles ainsi que le plan projet et le plan qualit terminent cette phase et sont
contractuels.

2.2.5 Conception globale

Pendant cette phase l'architecture du logiciel est dfinie ainsi que les interfaces entre les
diffrents modules. On veillera tout particulirement rendre les diffrents constituants du
produits aussi indpendants que possible de manire faciliter la fois le dveloppement
parallle et la maintenance future. Nous reviendrons sur les diffrentes mthodes de
conception dans le chapitre 5 consacr ce problme.
A l'issue de cette phase les produits intermdiaires sont
- le dossier de conception
- le plan d'intgration
- les plans de tests
- le planning mis jour

2.2.6 Codage et tests unitaires

Chaque module est ensuite cod et test indpendamment des autres. Les mthodes de
tests sont dcrites dans le chapitre 7.

Gnie logiciel Anne-Marie Hugues 19/12/02 2-3

 A l'issue de cette phase les produits intermdiaires sont
- les modules cods et tests
- la documentation de chaque module
- les rsultats des tests unitaires.
- le planning mis jour

2.2.7 Intgration
Chaque module test est intgr avec les autres suivant le plan d'intgration et l'ensemble
est test conformment au plan de tests.
Les mthodes d'intgration seront vues dans le chapitre 7.
A l'issue de cette phase, les produits intermdiaires sont:
- le logiciel test
- les tests de rgression
- le manuel d'installation
- la version finale du manuel utilisateur

2.2.8 Qualification
Lorsque le logiciel est termin et les phases d'intgration matriel/logiciel acheves, le
produit est qualifi, c'est dire test en vraie grandeur dans des conditions normales
d'utilisation. Cette phase termine le dveloppement. A l'issue de cette phase le logiciel est prt
la mise en exploitation

2.2.9 Maintenance
Lorsque le produit a t accept, il passe en phase de maintenance jusqu' son retrait. C'est
pendant cette phase que tous les efforts de documentation faits pendant le dveloppement
seront particulirement apprcis de mme que la transparence de l'architecture et du code. Le
chapitre 8 est consacr la maintenance.

2.2.10 Dure de cycle de vie

La dure d'un cycle de vie est trs variable d'un projet l'autre.
Exemple 1 : SGBD RELATIONNEL
- Premier prototype: 5 7 ans
Investissement > 100 H x A
- Premier systme commercial: 3 4 ans
Investissement > 150 H x A
- Maintenance > 10 ans
10 15 H x A par an
- Relivraison tous les 6 mois /1an
Exemple 2: Langage ADA
- Dfinition et analyse des besoins: 3 ans
4 candidats retenus par le DOD
Premier compilateur prototype
- Compilateur industriel : 3 ans
Investissement > 50 H x A
- Maintenance : > 15 ans
Investissement 5 10 H x A par an
Relivraison tous les 1 2 ans.

2.2.11 Facteurs d'instabilit

2-4 Anne-Marie Hugues 19/12/02 Gnie logiciel

 Le modle de cycle de vie n'est pas une panace, malgr les prcautions prises, des
facteurs d'instabilit subsistent:
Facteurs externes: l'utilisateur volue, l'environnement volue
- Environnement modifi par le logiciel,
- Evolution de la lgislation,
- Evolution de la technologie,
- Evolution du march et de la concurrence.
Facteurs internes: l'quipe de dveloppement volue
- Individus membres de l'quipe,
- Qualification de ces individus,
- Organisation qui gre le projet.

Gnie logiciel Anne-Marie Hugues 19/12/02 2-5

2.2.12 Rcapitulation : Les tches d'un projet logiciel par activits et par
phases
d'aprs BOEHM, 81
Phases

Plans et Conception Programmation Intgration

Activits besoins et tests
_____________________________________________________________________

Analyse des Analyse

besoins de l'existant,
besoins

Spcification Prototypes, Spcification, Mise jour Mise jour

et conception modles, conception, conception conception
risques modles,
prototypes

Ralisation Planification Planification Conception Intgration

personnel et du personnel, dtaille, des modules
outils acquisition codage, et
des outils tests unitaires

Planification Tests de Test Test unitaires

des tests qualification d'intgration

Vrification Validation V. et V. des V. et V. Tests

et validation des besoins, spcification du code d'intgration
Conception et conception et qualification
des outils de
V. et V.

Gestion Planification, Planification, Planification, Planification,

de projet contrats, suivi, suivi, suivi, ...
... contrats, ... ...

Gestion des Procdures Mise en Mise en Mise en

configurations uvre uvre uvre

Assurance Plan, AQ. des AQ. du AQ. produit

qualit standards, besoins, code
outils de la con-
ception

Documentation Ebauche Ebauche Manuel Manuel

manuel manuel utilisateur maintenance
utilisateur maintenance=
dossier specification
dossier conception

2-6 Anne-Marie Hugues 19/12/02 Gnie logiciel

 2.3. CYCLE DE VIE DES LOGICIELS EN CASCADE ET EN V

2.3.1 Modle en cascade

ANALYSE Changements dans

l'expression des besoins
DES BESOINS
vrification vrification

SPECIFICATIONS
FONCTIONNELLES
vrification

PLANIFICATION

vrification

CONCEPTION

vrification

IMPLEMENTATION
tests unitaires

INTEGRATION
tests

(Modle introduit ds 1966, QUALIFICATION

formalis en 1970)
tests

dveloppement EXPLOITATION
maintenance

RETRAIT

Gnie logiciel Anne-Marie Hugues 19/12/02 2-7

2.3.2 Modle en V

SPECIFICATIONS QUALIFICATION
FONCTIONNELLES

CONCEPTION INTEGRATION
GLOBALE

TESTS
CONCEPTION
UNITAIRES
DETAILLEE

PROGRAMMATION

GESTION DES CONFIGURATIONS

GESTION DE PROJET

PLAN ASSURANCE QUALITE

2-8 Anne-Marie Hugues 19/12/02 Gnie logiciel

2.3.3 Analyse de ces modles de cycle de vie
La reprsentation en V tient d'avantage compte de la ralit, le processus de
dveloppement n'est pas rduit un enchanement de tches squentielles.
Elle montre que:
- c'est en phase de spcification que l'on se proccupe des procdures de
qualification
- c'est en phase de conception globale que l'on se proccupe des procdures
d'intgration
- c'est en phase de conception dtaille que l'on prpare les tests unitaires
Le modle de cycle de vie en V permet d'anticiper sur les phases ultrieures de
dveloppement du produit. En particulier le modle en V permet de commencer plus tt:
- Plan de tests de qualification,
- Plan d'valuation des performances,
Le modle en V comme celui en cascade conduisent commencer plus tt la
documentation utilisateur.
Les deux modles permettent de dvelopper paralllement diffrents modules lorsque la
phase de conception globale est valide
ANALYSE
DES BESOINS

SPECIFICATIONS
FONCTIONNELLES

CONCEPTION
GLOBALE

CONCEPTION
DETAILLEE
DES MODULES
EN PARALLELE

PROGRAMMATION
&
TESTS UNITAIRES
EN PARALLELE
PREASSEMBLAGE

INTEGRATION

2.3.4 Conclusion
Ces modles de dveloppement permettent de contrler les rtro-actions :
La vrification/validation par une critique constructive vite les retours arrire
Le cycle de vie met l'accent sur les phases amont par rapport la programmation:
Spcification,
Conception.
Toutefois, le modle prsent est parfois difficile appliquer rigoureusement

Gnie logiciel Anne-Marie Hugues 19/12/02 2-9

 - Il est quelquefois ncessaire de prendre en compte des changements importants
dans les spcifications dans une phase avance du projet
- La dure impose par le cycle de vie est parfois difficilement accepte pour
certains produits comptitifs (exemple : logiciels micros....)
Nanmoins sa mise en uvre totale ou partielle dfinie dans le plan qualit s'avre
indispensable.
Le modle en V ou en cascade reportent trop de choses l'tape programmation. En
particulier l'interface utilisateur napparatra que fort tard. Il n'y a pas assez de bornes
intermdiaires permettant de valider ce que sera la version finale du produit.

CODAGE

VALIDATION

TEST

MAINTENANCE
Pour disposer plus tt d'objets excutables ou instrumentables pour les dveloppeurs et
pour les utilisateurs, d'autres modles existent :
- Maquettage, prototypage
- Dveloppement incrmental
Des cycles de vie plus complets prennent en charge la totalit du dveloppement du
produit en tenant compte du cycle de dcision et de l'analyse de risques. Nous donnons
l'exemple du cycle de vie en spirale et de la mthode Merise.

2.4. MAQUETTAGE, PROTOTYPAGE

Dans une industrie de fabrication on distingue
- Maquette = Modle rduit de l'objet
- Prototype = Premier d'une srie
En dveloppement de logiciel, il n'y a pas de production en srie, mais on distingue :
- Maquette ou prototype rapide
- Prototype exprimental
- Prototype volutif

2-10 Anne-Marie Hugues 19/12/02 Gnie logiciel

2.4.1 Prototypage rapide ou maquettage
La maquette ou prototype rapide est utilise en amont du cycle de dveloppement :
Analyse des besoins,
Spcifications fonctionnelles.
Elle permet la validation des spcifications par exprimentation :
"Je saurai ce que je veux lorsque je le verrai!"
Elle permet au client et au dveloppeur de bien se mettre d'accord sur la nature du produit
raliser et en particulier sur l'interface et les fonctionnalits. La notion de rapide est importante car
cette phase conditionne tout la suite du cycle de vie et permet de raccourcir la dure des allers/retours
client/dveloppeur pendant la phase d'analyse des besoins.

Analyse Analyse
prliminaire des et slection de
besoins nouvelles fonctions
Etat non
satisfaisant
Construction
du prototype

Evaluation
exprimentation Etat
satisfaisant

Expression claire
des besoins rels

Spcifications
dfinitives

2.4.2 Prototype exprimental

Utilis au niveau de la conception pour :
- S'assurer de la faisabilit de parties critiques
- Valider des options de conception
Exemple : Prototype d'un analyseur syntaxique avec une grammaire rduite

Approfondissement
Spcification
initiale
Slection d'un
point ou d'une
caractristique
Construction
du prototype
Evaluation
Confirmation ou
affinement des
spcifications

Ce prototype est en gnral jet aprs dveloppement.

Il peut aussi tre gard, on parle alors de prototype volutif.

Gnie logiciel Anne-Marie Hugues 19/12/02 2-11

2.4.3 Prototype volutif
La premire version du prototype est l'embryon du produit final
On itre jusqu'au produit final

Exemple :
Dveloppement d'un systme expert

Etude pralable

Premire Spcification
identification de base

Conception et 1re
ralisation version

Evaluation

Mise en uvre
et utilisation
Corrections et
amliorations
Nouvelle version

Version finale

Avec cette approche, il est trs difficile de mettre en uvre des procdures de validation et de
vrification.
Cette mthode est rapprocher du cycle de vie en spirale et du dveloppement incrmental vu ci-
aprs.

2.5. DEVELOPPEMENT INCREMENTAL

Ce modle de cycle de vie prend en compte le fait qu'un logiciel peut tre construit tape par
tape. Le logiciel est spcifi et conu dans son ensemble. La ralisation se fait par incrments de
fonctionnalits. Chaque incrment est intgr l'ensemble des prcdents et chaque tape le produit
est test exploit et maintenu dans son ensemble. Ce cycle de vie permet de prendre en compte
l'analyse de risques et de faire accepter progressivement un logiciel par les utilisateurs plutt que de
faire un changement brutal des habitudes.
Exemples:
Un scheduler (ordonnanceur) ou un gestionnaire de fichiers peuvent constituer des incrments
d'un systme d'exploitation.

2-12 Anne-Marie Hugues 19/12/02 Gnie logiciel

 Dans un logiciel de contrle d'un sous-marin, le logiciel de navigation et le logiciel de contrle des
armes peuvent constituer deux incrments.

ANALYSE DES
BESOINS
vrification

SPECIFICATIONS
FONCTIONNELLES
ET PLANNING
vrification

CONCEPTION
GLOBALE

vrification

INCREMENT 1
INCREMENT 2

INCREMENT N
Conception dtaille
codage, tests unitaires,
intgration, livraison

EXPLOITATION

RETRAIT

Certains modles proposent de dvelopper les diffrents incrments en parallle mais ceci
peut tre dangereux car on ne profite plus de l'aspect incrmental mme si on acclre le
dveloppement.
Si le nombre d'incrments n'est pas assez important ce modle de cycle de vie perd de son
intrt et peut se rapprocher d'une approche par essai erreur dconseiller.

Gnie logiciel Anne-Marie Hugues 19/12/02 2-13

 2.6. MODLE EN SPIRALE (BOEHM 1988)
Propos par B. Boehm en 1988, ce modle de cycle de vie tient compte de la possibilit de
rvaluer les risques en cours de dveloppement, il emprunte au prototypage incrmental
mais lui adjoint une dimension relevant de la prise de dcision managriale et non purement
technique. Il couvre l'ensemble du cycle de dveloppement d'un produit.. Il met l'accent sur
l'activit d'analyse des risques : chaque cycle de la spirale se droule en quatre phases :

2.6.1 La dmarche:
Identifier les risques, leur affecter une priorit,
dvelopper une srie de prototypes pour identifier les risques en commenant
par le plus grand risque
utiliser un modle en V ou en cascade pour implmenter chaque cycle
si un cycle concernant un risque a t achev avec succs,
valuer le rsultat du cycle et planifier le cycle suivant
si un risque n'a pu tre rsolu, terminer le projet immdiatement
Mo
Modle en spirale d'aprs [Boehm 88]
1. dtermination des objectifs du cycle, des alternatives pour les atteindre et des contraintes ; partir des rsultats des c
prcdents , ou de l'analyse prliminaire des besoins;
2. analyse des risques, valuation des alternatives partir de maquettage et/ou prototypage;
3. dveloppement et vrification de la solution retenue, un modle classique (cascade ou en V) peut tre utilis ici ;
4. revue des rsultats et vrification du cycle suivant.

2-14 Anne-Marie Hugues 19/12/02 Gnie logiciel

2.6.2 Analyse des risques
La mise en uvre demande des comptences managriales et devrait tre limite aux
projets innovants cause de l'importance que ce modle accorde l'analyse des risques.
Citons, par exemple
risques humains:
dfaillance du personnel ; surestimation des comptences
travailleur solitaire, hroisme, manque de motivation
risques processus
pas de gestion de projet
calendrier et budget irralistes ;
calendrier abandonn sous la pression des clients
composants externes manquants ;
tches externes dfaillantes ;
insuffisance de donnes
validit des besoins ;
dveloppement de fonctions inappropries
dveloppement d'interfaces utilisateurs inappropries

risques technologiques
produit miracle, "plaqu or";
changement de technologie en cours de route
problmes de performance
exigences dmesures par rapport la technologie
incomprhension des fondements de la technologie

2.6.3 Conditions d'application

Le modle en spirale s'applique essentiellement en interne , lorsque les clients et les
fournisseurs font partie de la mme entreprise, si l'analyse de risque dmontre que le projet
doit tre continu, une quipe peut tre raffecte au projet. Alors que dans une relation
client-fournisseur ordinaire, il y a eu signature de contrat et donc l'effort doit tre estim
l'avance. Le modle en spirale ne peut donc s'appliquer. Ou bien il doit tre adapt en signant
des contrats partiels pour chaque itration.

Gnie logiciel Anne-Marie Hugues 19/12/02 2-15

 2.7. RAD :"RAPID APPLICATION DEVELOPMENT "
Ce modle de dveloppement tend raccourcir le cycle de vie voire le supprimer.
La phase de spcification/conception est remplace par une phase de prototypage mene
conjointement avec le client.
Cette approche est supporte par de nombreux outils RAD (qui signifie ici Rapid Aided
Design ); on peut citer (Delphi, les outils Natstar et plus gnralement la plupart des outils de
dveloppement graphiques gnrant des prototypes de fonctions, procdures, classes)
La phase de prototypage dbouche sur une interface valide par le client. L'outil gnre des
squelettes de fonctions , classes Le comportement de chaque objet de l'interface est ensuite
dcrit dans un langage appropri et ses fonctionnalits programmes.
De nombreuses entreprises ont employ ce type de dveloppement dans les annes 90 et
ont eu des soucis lors de la maintenance des applications ainsi dveloppes cause du
manque de conception inhrent la dmarche, en effet la conception est caque sur l'interface
ce qui n'est pas forcment une bonne ide.
Rcemment la mthode DSDM est apparue qui prend en compte ces remarques et structure
l'approche RAD.

La dmarche RAD DSDM

La mthode s'applique bien dans le cadre de petites applications de gestion, n'ayant pas de
cycle de vie d'une trop longue dure.

2-16 Anne-Marie Hugues 19/12/02 Gnie logiciel

 2.8. METHODE MERISE (TARDIEU 1978)
MERISE est une mthode de conception et de dveloppement dfinie et mise au point dans
sa premire version durant les annes 1978 et 1979, sous l'gide du Ministre de l'Industrie,
par un groupement form par les 6 SSII majeures et certaines grandes administrations
(Finances, Equipement, Dfense, ...).
MERISE constitue depuis le milieu des annes 80 un standard de fait dans le domaine des
systmes d'information de gestion en France et dans les pays francophones.
Cette mthode intgre la fois les aspects dcisionnels et techniques, elle s'apparente en
cela au modle en spirale mais procde plutt en cascade. Elle est utilise pour dvelopper
des systmes d'information complets et subit des mises jour frquentes. Plusieurs outils la
supportent (Mega, AMC Designor, Foundation...) Elle traite l'ensemble du cycle de vie d'un
systme d'information et adopte une approche systmique de l'entreprise. Elle tient compte
des 3 axes: cycle de dcision, cycle d'abstraction et cycle de vie.

CYCLE
DABSTRACTION

S.I. CHOISI

CYCLE DE
VIE

CYCLE DE
DECISION

Elle procde par tapes

Schma directeur: approche globale du problme prenant en compte la stratgie
tude pralable de chaque domaine
tude dtaille de chaque sous domaine
tude technique par projet
Ralisation par projet
Mise en uvre projet par projet
Exploitation de l'ensemble
Maintenance de l'ensemble

Gnie logiciel Anne-Marie Hugues 19/12/02 2-17

 BESOINS
SCHEMA DIRECTEUR

CAHIER DES CHARGES

CYCLE DE
DEVELOPPEMENT

SOLUTION
OPERATIONNELLE

CYCLE DEXPLOITATION
et MAINTENANCE

Comme dans le cycle de vie en spirale ou dans le modle incrmental on met en

exploitation les projets issus des diffrents domaines les uns aprs les autres jusqu' obtenir
un systme complet.
La mthode opre par une modlisation descendante des systmes et utilise une sparation
donnes / traitements /communication
Une version Merise objets est aujourd'hui propose
Le systme d'information est dcompos en diffrents niveaux
- conceptuel (description de l'activit: QUOI)
- organisationnel (QUI, OU, QUAND)
- physique (description des moyens, COMMENT, avec quelle ressource)
Ces trois niveaux s'appuient sur un certain nombre de modles, Modle de communication
Modles de donnes, Modles de traitements sur lesquels nous reviendrons aux moment des
spcifications fonctionnelles.
MERISE est en constante volution, en particulier MERISE intgre aujourd'hui les
concepts et techniques de l' approche objets.
Nous revenons sur les modles conceptuels de MERISE dans le chapitre 4.

2-18 Anne-Marie Hugues 19/12/02 Gnie logiciel

 2.9. MODELE DE CYCLE DE VIE ORIENTE OBJETS
Dans une approche oriente objets, la diffrence entre analyse et conception est peu
visible. On procde plutt par itrations et raffinements successifs.
Le modle en fontaine (Henderson) fait apparatre ce recouvrement des phases d'analyse et
conception. Les flches reprsentent les itrations l'intrieur d'une phase.

Gnie logiciel Anne-Marie Hugues 19/12/02 2-19

 2.10. MODELE DE CYCLE DE VIE ORIENTE REUTILISATION DE
COMPOSANTS
La volont de rutilisation du code induit des cycles de vie lgrement diffrents de ceux
vus jusqu'ici. Les objets dcrits dans un projet peuvent tre rutiliss dans un autre et sont
donc rcolts en fin de cycle de vie pour tre placs dans une bibliothque d'objets.
Il est important de consacrer une part non ngligeable du temps du projet grer la
rutilisation.

Gestion de Analyse
Analyse des besoins
des besoins Mise
Normes projet disposition de
Planification composants
Qualit Gestion de Recueil des
configurations Analyse objets composants
non
Gestion de Conception
excutables
Manuel documentation (documents)
Dveloppement
qualit Gestion de la Recueil de
qualit Validation / vrification composants
excutables
Gestion des Livraison
risques Code et jeux de
tests
Rcolte

2-20 Anne-Marie Hugues 19/12/02 Gnie logiciel

 2.10. RFRENCES

B. BOEHM
Software Engineering Economics
Prentice-Hall, 1981

Gnie logiciel Anne-Marie Hugues 19/12/02 2-21