2.

DIFFERENTS MODELES DE CYCLE DE VIE

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.1.

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

maintenance besoins planification codage intgration specification conception

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

Activits

Plans et Conception Programmation Intgration besoins et tests _____________________________________________________________________

Analyse des besoins Spcification et conception

Analyse de l'existant, besoins Prototypes, modles, risques Planification personnel et outils Tests de qualification Validation des besoins, Conception des outils de V. et V. Planification, contrats, ... Procdures Plan, standards, outils Ebauche manuel utilisateur Spcification, conception, modles, prototypes Planification du personnel, acquisition des outils Test d'intgration V. et V. des spcification et conception Mise jour conception Mise jour conception

Ralisation

Conception dtaille, codage, et tests unitaires Test unitaires V. et V. du code

Intgration des modules

Planification des tests Vrification et validation

Tests d'intgration et qualification

Gestion de projet Gestion des configurations Assurance qualit

Planification, suivi, contrats, ... Mise en uvre AQ. des besoins, de la conception

Planification, suivi, ... Mise en uvre AQ. du code

Planification, suivi, ... Mise en uvre AQ. produit

Documentation

Ebauche Manuel manuel utilisateur maintenance= dossier specification dossier conception

Manuel maintenance

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 DES BESOINS vrification SPECIFICATIONS FONCTIONNELLES vrification PLANIFICATION vrification
Changements dans l'expression des besoins

vrification

CONCEPTION vrification

IMPLEMENTATION tests unitaires

INTEGRATION tests

(Modle introduit ds 1966, formalis en 1970)

QUALIFICATION tests

dveloppement maintenance

EXPLOITATION

RETRAIT

Gnie logiciel

Anne-Marie Hugues 19/12/02

2-7

2.3.2 Modle en V

SPECIFICATIONS FONCTIONNELLES

QUALIFICATION

CONCEPTION GLOBALE

INTEGRATION

CONCEPTION DETAILLEE

TESTS UNITAIRES

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 prliminaire des besoins

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

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 identification Spcification de base

Conception et ralisation

1re 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 ciaprs.

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 en spirale d'aprs [Boehm 88] Modle

1. 2. 3. 4.

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; analyse des risques, valuation des alternatives partir de maquettage et/ou prototypage; dveloppement et vrification de la solution retenue, un modle classique (cascade ou en V) peut tre utilis ici ; 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.

Normes Qualit Manuel qualit

Gestion de projet Gestion de configurations Gestion de documentation Gestion de la qualit Gestion des risques

Analyse des besoins Analyse des besoins

Planification Analyse objets Conception Dveloppement Validation / vrification Livraison Rcolte

Mise disposition de composants Recueil des composants non excutables (documents) Recueil de composants excutables Code et jeux de tests

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