Méthode

b L'objêt, Merise

._ {

i - '

J

Votre responsabilitest engagéeStéphane Lipski

- ,.,:l

' f t iâ : + ._ _ , , :

-e*

'-*,W's't{dt

l

'* -.rr'. -{l.iii"'

^o{^#

Et Ie RADJean-Pierre Vickoff

An 2OOO

Sous-traitance

en questlonAndré Bors

Euro

bascule choisirRomain Hugot

N" 173 - avril 199!

Ont collaboré à cenuméro :

> Olivier te Gendre

> Jean-Pierre Vickoff

p André Bors

> Romain Hugot

> Stéphane Lipski

> François Scherpereel

> Edward Younker

' D. Tunick Morello

' Carrie R. Smith

p B. Hohmann

(gGartnerGroup I Bouhot & Le Gendre-

l P r o d u i t s & S e r v i c e s

Méthode

tæb!@Ë, Meriseet le RAD

Conodien et Fronçois,

consulto nt e n architecture

de sgstème et en intégra'

tion technologique, outeur

de plusieurs ouvrages dont

RAD et Reengineering. JPV

s'est specialisé, en

Amérique du Nord,

dans le développement

sous controintes,

d'applicotions de

di ff ére nci oti o n stratég iq u e.

l l faut s'en convaincre, Merise ne survivra pas à l'objet.

Pour les développements comme dans beaucoup d'autres domaines,

I 'heure est au pragmatisme ! C'est ce que permet notamment l 'ut i l isat ion

conjointe du Rapid Appl icat ion Development (RAD), du Capabi l i ty

Matur i ty Model (CMM) et de l 'Unif ied Model ing Language (UML).

Object i fs : tenir les cotts et les délais avec un périmètre var iable,

beaucoup de qual i té et de performance.

,__,",., offiffi le bon, nalf etoptimiste, , eu spécialement pour corollaire d'assu-

,t'' I'objet pense tout régler. Mais sa i rer le succès des développements infor-

, pureté peut l'égarer dans les pires , matiques.'', :.r errements. Merise, la brute, allie : Certes, on est loin des grands chantiers

la souplesse de I'intégrisme à la perfor- : et, pour des raisons historiques et éco-

mance d'une économie d'état. Le RAD, , nomiques, la production des informati-

t ruan<J pragmatique et et Ïcace, se sert : c iens français se l imite, de plus en

des deux autres pour réussir son projet ; plus, au paramétrage de progiciels pour

en bousculant I'organisation et ses grands : les applications opérationnelles clas-

principes. Personne n'est parfait I : siques et au développement spéciiique

Quancl on analyse les principaux maga- ; pour le stratégique de difTérenciation.

zines professionnels, il s'avère rapide- ; Ce type d'application qui permet à I'en-

ment que l 'espace consacré à la , t repr ise d'accroître sa compéti t iv i té, se

rnéthot lc cst prochc- de zéro. Pourtant, réal ise généralerncnt sous contraintes,

la mu l t ip l i ca t ion dc la v i tesse des maté- , ce qu i requ ie r t d 'au tan t p lus de

riels et la nrise à clisposition d'Ateliers , méthodc qu'il faut savoir adapter celle-

de Génie Logicic l "v isuels" n 'ont pas : c i aux spécit ic i tés du projet.

La product iondes informat ic iensfrançais se l imi te, de Plusen plus, au paramétrage

de progic ie ls pour les

appl icat ionsopérat ionnel les c lassiques

et au développementspéci f ique pour le

stratégique dedi f férenciat ion.

L'lnformatique Professionnelle

t ç g l l - r l ç l r ç Y I L ^ v l l

De l \r ler ise au RAD

Côté rné thodc c l 'a i l l cu rs . la pa t r ie de

Descartcs tre ntanque pas tl 'atout. Voici '

près dr- r ' ingt ans naissait en eft 'ct la

prcrrt iè ' rc version de Mcrise'" , un out i l

nréthodolo-sique dintensionné pour les :

d é v e l o p p e n r e t t t s d e l ' é p o q u e . D i x '

années plus tard. avec I 'appari t ion de la

micro et cles réseaux, il tallut reconsi- :

dérer la recette et ltri intégrer, sous le

nonr <Je Mer ise 2 , la no t ion de f lux I

(DFD'"; que lcs américains ut i l isaient I

d e p u i s l ' a u b e d c I ' i n f o r m a t i q u e . i

Prolongcttrent dc I'cxception nationale I

vers I 'objet, en 1994, Merise 3 (OO)' :

s'engouffre dans un trou noir nommé

UMLr') , et le développeur français se

réveille sans comprendre pourquoi ses

prat iques viennent de disparaître du

paysage des métl-rodes et, pour être plus

précis, des techniqucs de modélisation.

S imul tanérncn l . l cs en t repr ises sou-

mises à des prcssions f inancières et

concurrentiellcs filrtes souhaitent que

les app l ica t io t ts so ien t réa l i sées en

quetques semaines ou quelques mois,

et non plus en années-homme (Boehm,

Brooks, Martin, Vickoff).

Confronté à ce type d'exigence, au

début des années 90 en Amérique du

nord, James Martin imagina le RADro),

méthode qu'il aurait pu nommer PRAG-

MATIQUE5). Dc fait, le RAD nécessite

une partàite osrnose entre les hommes,

les outils et I'organisation. Dès le début

du projet, le RAD met en scène une

équipc réduite (SWATiur), cotr tposée

d ' u n p e r s o n n e l h o m o g è n e d e t Y P e

concepteur-développeur. travaillant sur

une solutitln validée ell permanence par

I 'ut i l isatcur réel .

Des principes inconnus des intbrmati-

ciens classiques s'imposent alors : péri-

mètre var iable, délai et bud-qet l lxes'

L ' i n v e r s e e s t , e n r e v a n c h e , P l u s

répant lu : pér imètre f ixe, budget et

délai variables. Très sérieusement' au-

delà de la simple maîtrise des deux élé-

ments basiques que sont le temPs et

I'argent, il s'agit en fait, concrètement,

de la réussite ou de l'échec du projet'

De nouveaux axes de conduite de pro-

jet (connus mais rarement prat iqués)

deviennent indispensables à I'optimisa-

tion du projet RAD : coûts (target cos-

t ing) , dé la is ( t ime box ing) , qua l i té

technique (code and project reviews),

qualité fonctionnelle (prototyping and

user's reviews) ou visibilité générale et

, contrôle du projet (Focus). Ces axes

: dynamisent et rythment l 'équipe, le

. projet, et au-delà l'entrePrise'i

i Euit . r la concrét isat ion du

; r isque

' Compa.er une méthode de conduite de

i projet classique avec les principes du

: RRO, sous I 'angle de la gest ion du

, risque projet (délais, qualité' etc')' peut

, ê t r e é d i f i a n t P o u r u n c a r t é s i e n '

: L'approche classique tente de réduire

: les r isques par une démarche spéci-

besoins

Le RAD nécessi te

une parfa i te osmose entre

les hommes, les out i ls et

I 'organisat ion.

Des p r i nc iPes i nconnus

des informat ic iensclassiques s ' imPosent

alors : pér imètre var iable '

déla i et budget f ixes.

1 - Merise : méthode descriPtivedes organisat ions (basée sur la

systémique). Mer ise léPare les

données des t ra i ternents et

consacre ta distinction Parfaitedes niveaux de Préoc<uqations(conceptue! , organisat ion,logique et Phçique).

2 - DFD: Data FIow Design

3 - UML : lJni f ied Model ingLanguage (notat ion uni f iée de

modélisation obiet).

4 - Rapid ApPlication DeveloP'men t : mé thode axée su r l a

communicat ion et la val idat ionperma nente pa r l' uti lisateu r rée l'

5 - Pragmat isme : do. t r ine qui

acco rde l a P rem iè re P lace à

I'action, à la Pratique ; qui consi'

dère Ia valeur Prat ique commecritère de la vérité.

6 - SWAT : Skilled With Advanced

Tools (des Professionnels formés

dotés des outils ,es Plus Perfor'mants).

7 - Effet tunnel : Période durant

laquel le l 'u t i l isdteur ne vot t Passon a11lication en cours de déve'

loppement.

CYCLES DE CONDUITE DE PROJET COMPARES

. MERISE (ou 5DM5) : Approche totalement systémique, 'par la structure" (top-down)'

lnconvénients : validation en cascade, rigidiié, manque d'adaptation et éloignement des

détaillés des utilisateurs (effet tunnel(')).

. DSDM : Approche 'par les besoins" (bottom-up) totalement incrémentielle et itérative'

lnconvénients : risques d'incohérences, de redondances et de déstructuration des programmes par de

trop fréquentes modifications.. RAD :Approche par la structure avec validation en cascade (pour maintenir la cohérence systémique)

lors du premier tiers du proiet. Puil approche par les besoins avec construction-validation de type

itérati{-incrémentiel (pour aszurer la coniormité dà I'application au détail des exigences de I'utilisateur)'

- "---lIIiII

n" 173 avr i l ' 1999

- . $po ., .- ' ' - ' . .*, , . . , . .* . : .- . . . . : r:{rsgr-t':' i.':i

Déve loppement

Le RAD s'appuie,sur la compétence de

l'équipe SWAT engagéedans des pratiques

permanentes orientéesvers la "performance" et

la "validation".

Le RAD d i s t i ngue

les mé thodes de condu i t ede projet qui lu i sont

propres et les techniquesde modé l i sa t i on d ' une

appl icat ion pour

lesquel les i l veut êtreopportuniste.

8 - Techniques de conception :

structu rati on. mod ul a r îté, e nca p'

sulation, dissimulation, héritage,polymorphisme, etc,

9 - Notations et modèles: UML,

E nti té-Rel ati on, M e r i se (m odèl es),DFD. SASD, etc.

l0 - Cycle de vie (du développe'

ment) : empirique, rlassique

Merisien (cycle de vie), en castade

comme SDMS, totalement itératif

tel DSDM. ou mixte comme leRAD Ie pre(onise.

| | - Méthode de Conduite deProjet : <ycle de vie + techniques

de communication, de conceptionet de réalisation .

12 - uodèle : ce oui doit servird'objet pour faire ou reprodutre.

Représentà t ion sy nthetique etsouve n t g r a ph iq ue'pe r m etta nt d e

rèduire la comolexitè d'une réa-lité représentant tout ou partie

d' un système d' info rm at ion-

fique et déterrniniste dont les coûts pré- :

vent i fs (analysc, détect ion' suivi et cor- '

rectif ) ne sont Pas négligeables. :Toujours pragrnltiquc. le RAD s'aPpuie. à

I'inverse, sur la compétcnce de l'équipe :

SWAT engagée dans des pratiques per- :

manentes orientées vers la "perfomlance" '

et la "valitJation". tr but est d'éviter natu- i

rellement la concrétisation du risque- En :

terme de conduitc de projet' le change- i

ment le plus imporlânt induit par ces pra- i

tiques est certainement la planification :

d'un engagement simultané de I'ensemble i

des ressources de conception-réalisirtion :

dès le début du projet. .En fait, paradoxalement, les techniques :

perrnettant d'améliorer la performance :

cle l'équipe s'avèrent être les principaux ,

facteurs de réduction du risque.

Méthode et modél isat ion

En fait, le RAD distingue les méthodes

de condu i te de Pro je t qu i lu i son t

propres et les techniques de modélisa-

tion d'une application pour lesquelles il

veut être opportuniste- En informa-

tique et plus particulièrement en déve-

loppement d'applications, la notion de

"méthode" recouvre généra lement

deux aspects aussi différents que dan-

gereusement imbr iqués e t souvent

confondus : la conduite de projet et la

modé l isa t ion de I 'app l i ca t ion . Cet te

un ic i té de te rme pour couvr i r deux

concepts tbndamentalentent dist incts

ouvre la porte à tous les erretnents.

Aussi. I ' infbrmaticien devrait-il distin-

guer dans son vocabulaire : les tech-

niques de conception('), les notations et

modèles('), le cycle de vie du dévelop-

pement(' ') et les méthodes de conduite

de projet(").Voyons I 'expression graphique de la

modél isat ion(") . L ' informatic ien qui

recule devant le tout objet pour de mul-

tiples raisons, mais qui doit modéliser

une architecture événementiel le est

confronté à un problème majeur. Les

, traitements merisiens ne I'aident pas et

i le modèle de flux (voir figure l), parti-

: culièrement efficace pour représenter

i des structures séquentielles de traite-

' ment (les flux d'informations transitant

, d" tuppott en support au fil des modifi-

i cations), s'avère inadéquat pour repré-

senter une architecture appl icat ive

composée de modules interagissant

avec une information unique, dont les

états évoluent en cours de traitement

(voir figure 2).

De plus, le modèle de

nant impérativement

flux doit mainte-

s'interfacer avec

FTGURE 1 - STRUCTURE CLASSIQUE - SÉQUENTIELLE

f;..*"", t-l -- "---'--- * g9\

----[t"t@g'' -1-

:..{r @I

Traitement 3 I

À=- I ,f-_qqussJ-1<.-i Traitement 4 |

L' lnformatique Professionnelle

- . ' ' " - . ' . , . . .

Jean-P ier re V icko f fI rglf:ryerise et te nao I

FIGURE 2 . STRUCTURE RELATIONNELLE . ÉVÈruEN,lENTIELLE

Traitement 1 Traitement 2

Traitement 3 Traitement 4

Traitement 5

le modèle relationnel de données. Cen'était pas prévu à son origine et celaalourdit sa mise en ceuvre. Des outilsc l a s s i q u e s c o m m e A M C * D e s i g n o r(merisien à la base) ou SilverRun (flux,ent i té-relat ion) faci l i tent cette étape.D'autres produits, issus du monde deI'Objet, fbnt aussi leur apparition bienque leurs formal ismes et leurs butssoient quelque peu ditférents.

L'archi tecture condit ionne laméthode

L 'homme de l 'A r t se do i t d 'ê t re unpragmatique : i l ne peut y avoir dedivergence entre le modèle qui repré-sente une vision simplifiée du système(afin d'en réduire la complexité) et laréal i té de I 'appl icat ion projetée. Demême, les avancées technologiques,I'interface graphique et l 'événementielinrposent sans appel la continuité par-faite de la chaîne de conception-réali-sation. Dans cette optique de réalismeperformant, le moclèle de f lux et lesmodèles Merisiens répondent difficile_ment à une représentation convenabledes nouveaux systèmes d'information.Une réponse consiste en fait à isoler les_groupcs de clonnées ayant des compor_tel.nents identiques et à leur associer ladescription des traitements s,y rappor_tant. Le nrodètc ainsi obtenu est statique

n" 173 avr i l 1999

: et ne peut, à lui seul, représenter la réa-I lité d'un système d'intbrmation. Aussi,: un modèle plus dynamique le complètei et précise les acteurs et les événements, interagissant avec ces groupes d'infor-, mation par Ie biais de messages (Booch,i guOO, Jacobson, Mul ler, Rumbaugh,: Vauquier, Warren, ...). Ainsi se présente: I'Objet au néophyte.

, Un" évolut ion des rôles et: des responsabi l i tésI En ce qui concerne la modél isat ion,i sans prôner immédiatement l 'usage de: I'Objet er d'UML pour rous, il est trèsi ut i le d 'en ut i l iser certains pr incipes(")I qui permettent au document représenta-I tif de I'architecture applicative de cor-! respondre à la réalité à mettre en æuvre.i Pour I' informaticien, cetre modélisationi implique la compréhension et I'usage des, techniques de conception préalablementi c i tées. I l lu i faut, de plus, accepter le: p r i n c i p e d u p r o f i l u n i q u e d e t y p e: concepteur-développeur pour réal iser: avec succès des développements gra-I phiques qui, pour des raisons techniques, et économiques, fusionnent la concep-, tion détaillée, la réalisation et les tests en: une seule étape : lc prototypage actitl lo)., Pour la Maîtrise d'Ouvrage, cette moclé-, lisation est I'expression du besoin dans: un tbrmal isme qu'el le partage avec la

Le modèle de f lux etles modèles Mer is iensrépondent d i f f i c i lementà une représentat ionconvenable des nouveauxsystèmes d ' informat ion.

ll faut accepter leprincipe du profi l uniquede type concepteur-développeur,

13 - IJML ne fait appel qu'à cinqconcepts (les objetg les rnessages,,es c/ariet I'héritage et le poly-morphisme) pour expr imer demanière uniforme I'analyse, laconception et la réalisation.14 - Prototypage actif: état inter-médiaire de I'application en coursde développement-

' 'IJ{S*l}+fr n i . r a . l ' ' e E .

Déve loppem

RAD : LES TECHNIQUES DE LEVEE DU RISQUE

. Validation permanente : intervention systématique et planifiée de I'utilisateur réel dans la valida-tion de sa future application qu'il s'approprie.

. Jalons Zéro-Défaut: étape planifiée de la réalisation otr I'application est garantie validée techni-quement et fonctionnellement.

. Focus : exercice planifié de visibilité et de validation visant à faire reconnaître I'avancement du pro-jet et la qualité de l'application par le plus grand nombre d'acreurs impliqués dans le projet.

r Etat de livraison permanente : conservation de l'état stable de l'application après un Focus, per-mettant son exécution, pour présentation impromptue, validation, ou livraison partielle.

. Livraison en fonctionnalités réduites : application partiellement achevée, mais ayant aneint par uneplanification adaptée (souvent par thème), un niveau d'utilisation possible, par des utilisateursconscients des limites d'un produit à l'élaboration duquel ils ont participé. L'architecture de réali-sation qui regroupe ces techniques est décrite en figure 3.

I

Cet te évolut ion des rô less 'accompagne

d 'une red i s t r i bu t i ondes responsab i l i t é s .

Le modèle globalpeut être décomposé

par regroupement d,entitésayant un lien de

dépendance (obiets-métier)et inclure les dépendances

inter-fon(tions etinter-données.

| 5 - La dynamique applicativefocal ise une syner g ie d' évol utions

(fo n cti on na I i té, o rg a n i sa ti o n,co m mu n i(ati o n, tech no I og i e) -

1 6 - IJse case (cas d,utit isation) :actt o n s c t rco nst anciées desâcteurs sur les objets du Sl.

I 7 - MoonRàker est destiné auxetudiants et ses objectifs ambi-

treux et désinteressés sontdétaillés sur le site ww.RAD.fr.

Maîtrise d'(Euvre de son intbrmatique

IHenry, Monkam-Daverat 1995] .Pour I'util isateur, ces évolutions offrentla possibi l i té de déterminer les fonc-t ions et leurs pr ior i tés. El les lui per-met ten t d ' imposer une "dynamiquea p p l i c a t i v e { " } " . C e t t e p r é r o g a t i v econdu i t l ' u t i l i sa teur à p r iv i lég ie r desformes de modé l isa t ion s imp l i f iéespour formaliser précisément sa visiondes tâches et des scénarios opération-nels qu' i l met en æuvre (use caser"))

[Jacobson 19931.Cette évolution des rôles s'accompagned'une redistribution des responsabilitéset s 'avère la pr incipale réponse auxproblèmes que rencontrent les projetsactuels.Pour leur part, les cadres et les gestion- inaires doivent comprendre I'importance ,vi tale du SI pour I 'organisat ion. I ls doi-vent s'impliquer totalement dans la par-t ie qu i s 'app l ique à leur donra ine e ts u i v r e l e s é v o l u t i o n s d e s d o m a i n e sadjacents. Cette exigence impose decomprendre une tbrme sinrpl i l iée demodélisation des processus. La plupartd e s o r g a n i s a t i o n s s o n t a u j o u r d ' h u iconfrontées i\ un environnement mou-vant. Dans ces condit ions, I 'adaptat ionet donc la survic clépendent dc la capa-ci té à réagir v i te aux changemcnts etdonc à faire évoluer le systènte d'intbr-mation rapidenrent.

Vers une modél isat ionpragmatique

En s'appuyant sur la réal i té de cetrereprésentation"universelle", I' informa-t ic ien peut réal iser la transi t ion natu-relle clu monde théorique, c'est-à-direle rnodèle, au monde réel. c'est-à-direI'application. Une forme de modélisa-tion pragmatique peut prendre I'aspectd'une simple hiérarchie de fonct ionsdont la transposition directe dar,s I'ap-plication se f-ait sous la forme de menuset d'objets permettant des choix et dessélections. Le modèle global peut êtredécomposé par regroupement d'entitésayant un lien de dépendance (objets-mét ie r ) e t inc lu re les dépendancesinter-fonctions et inter-données. Cetteprésentat ion faci l i te la "pr ior isat ion"des modules à réaliser, en fonction deleur valeur ajoutée et de leurs interdé-p e n d a n c e s f o n c t i o n n e l l e s o u t e c h -n i q u c s . A i n s i , d a n s l e p r o j e tMoonRaker que je condu is i l c tue l le -m e n t . l e p r e m i e r m o d u l e ( i n t i t u l é"Prior i té") v ise à déf inir cette "pr ior i -

sation" des travaux à réaliser(").

Du mode projet au RADDans un au t re re_e is t re , i l fau t com-prendre que la perfornrance de déve-klppernent est int imement l iée à I 'envi-ronncment organisat ionnel. technolo-g i q u e e t h u m a i n . C e t t e c o n s t a t a t i o n

L' lnformatioue Professionnelle

Jean-Pierre Vickoff

peut sembler banale mais elle expliquemalheureusement bien des contre-per-formances attribuées sans discernementaux projets eux-mêrnes. Confrontées àun besoin crucial et ponctuel, af ln tJeréduire I 'ef fet de leurs carences, lesorganisations réinventent le blitz sousla forme du "mode projet". Ce principed'action libère la créativité, l 'énergie etles ressources indispensables pour res-pecter une forte contrainte de temps.Disposer en permanence d'un environ-nement de travail suffisamment perfor-mant pour réaliser tous les projets dansles meilleures conditions est âussi unesérieuse possibilité à envisager pour lefutur immédiat.En ce qui concerne les développementsinformatiques, les conditions de cette

exigence furent définies en 1993 au seindu SEI{") par Paulk dans son "CapabilityMaturity Model" traduit par le CRIM"')en "Modèle d'évolut ion cles capacitéslogiciel les". CMM ol l ' re unc strLrctured'évaluat ion et d 'anrél iorat ion normal i-sée décrivant les élémcnts "clés" d'unprocessus de développement lo_eicielef f icace. I l est modulaire et dist inguecinq niveaux de maturité pour permettreà I'organisation de se situer et de fixerson objectif d'anrélioration progressive.Chaque niveau du CMM comporte plu-sieurs secteurs "clés" dans lesquels lamise en æuvre de pratiques "clés" per-met d'atteindre les objectifs du secteur"clé". Les 5 niveaux de matur i té duCMM sont les suivants : initial, repro-ductible, défini, maîtrisé, optimisé.

CMM offre une structured'évaluation etd'améliorat ion normalisée.

l8 - SEI : Software Engineeringlnstitut.

19 - CRIM: Centre de Recherches! nformatiques de Montréal.

FIGURE 3 . ARCHITECTURE DE REALISATION b

CONTRÔIC

Publ icat ion des normes

QUAL|TÉ TTcHMQUEPlani f icat ion FOCUS

Plani f icat ion Jalon ZD

Prise en compte j étape Revue de code (croisée)des remarques

I -tr^^r*t t. IQUAL|TÉ rorucTtoNNELrE

VISIBITITÉ

étape Vér i f icat ion ut i l isateur

*-_1tafe lntegration modules

F()CUS

PROTOTYPAGE

étape Vérif ication personnelle

n" 173 avr i l 1999

i Etat de l iv ra ison permanente (n)

HtSToRtQUE DES pRtNCtpES DE MODÉL|SAT|ON

En 1983, Merise (Colletti, Rochfeld, Tardieu, ...), méthode française qui sépare les donnees des trai-tements, est présentée à une profession d'empiristes. En 1989. le modèle de flux nord-américain DFD,basé sur les communications entre processut est introduit dans Merise 2 (Cohen, tspinasse,Hekenroth, Letouchg Morejon, Nanci. panet, Tabourieç ...). pragmatiquement américain, le DFDpermet I'expression simultanée de l'ensemble des préoccupations (acteur, flux, process, données) etpermet ainsi d'éviter les "aller-retour" de validation entre modèles. En i994, une tentative detransition de Merise 3 à I'objet échoue dans I'indifférence générale. Parallèlement, depuis 1991, lesthéoriciens de I'objet fusionnent leurs approchet et aujourd'hui, imposent uML (Langage deModélisation Unifié) aux avant-gardistes de la méthode.

Le développementd'applications est encadré

par un processus'qualité', formel, précis,

simple, sécurisé et ouvert.

UML permetune furmalisation de

I'expression des besoinset une standardisation

de la conception.

20 - lJn projet considéré comme'petit" selon les critères du RADengage une ou deux ressources

expérimentées pour une durée de3O à 90 jours. un projet ,.intermè-

diaire" engage une équipe(SWAT. Skill With Advanced Toots)

de 4 à 6 (oncepteurs-dévelop-peurs pour une durée de 60 à

1 20 jours. Les grands ptojetsutilisent des techniques de

parallélisation durant la phase deDES/GN et de sé riallsation durant

/a pâase de CONSTftUCT|ON. LaplanifîGtion des Focus est a!ors

dépendànte du nombre d.équipeset du style de projet.

S'appuyant sur la rigueur du CMM, leRAD évolue alors vers une deuxièmegénération de la méthode. Le dévelop-pement d'applications est encadré parun processus "qualité", formel, précis,simple, sécurisé et ouvert (voir figure 3).Il est d'autre part obligatoirement ins-trumenté par des AGL performants.RAD2 comprend plusieurs éléments.l. Une structure de développement sécu-risant un cycle court basé sur un phasagesimple : Cadrage, Design, Constructionet I'absolu respect d'une dimension tem-porel le (90 jours oprimum, 120 joursmaximum) [Martin l99l l.2. Des méthodes, techniques et outilspermettant de définir et d'appliquer descho ix por tan t sur quat re s t ra tég iesconflictuelles : budger, délais. fiabilité(qual i té technique), v is ibi l i té (qual i téfonctionnelle) [Vickoff I 998].3. Une architecture de communicationrespectant un mode opératoire précisstructuré en trois étapes : pré-session,session, posr-session IMucchiel l i 1987,Vickoff 19961.4. Une architecture de conception s'âp-puyant sur les rechniclues de I 'objet etpar t i cu l iè ren)cn t sur cc l l cs pcrnrc t tan tune conccpt ion "en vue de rnodi l lca- ,t ions" [McCarry 1997]. ,5 . U n e a r c h i t e c r u r c t l c r é a l i s a t i o n :imposant pour la qual i té tcchnique des ,normes rnininralcs. dcs rcvues dc pro-jet , des jalons zéro-dél 'arr l ct rcconl-mandant por.rr la qtral i té fbnct ionnel le .le p ro to lyprsc i t c t i l ' c l I c ' s Focus t l c ,

I v is ibi l i té (voir f igure 3) [McConnel l: 1996, Vickoff 19981.

:i R A D , C M M , U M L e t . . .i beaucoup de soup lessei [æs trois premiers points définissent lesi principes de la méthode RAD relle que, James Martin l'avait conçue dès la fin desi années 80. Ces principes fondamentaux, sont susceptibles de s'appliquer à tous les, projets informatiques quels que soientr leun types et leurs tailles(2.). En AmériqueI du Nord (Bell, Abbor, Hydro-euébec),: comme en France (Se i ta , Soc ié téi Générale), Ies missions de développe-, ment d'appl icat ions menées selon ces: concepts ont été conclues avec succès: alors que la pluparr des projets conven-: tionnels dérivaient hors des attentes des, utilisateurs.. Le nnO oprimise ainsi la conduire des

' prujers et la comntunication des inrerve-, nants. CMM formalise et encadre l'évolu-' tion de I'or-uanisation. UML permet unei formalisation de l'expression tles besoins, et une standardisation de la conception., L'aboutissement de ces trois .ou.unts .1"

pensées complénrcntaircs consacre uncproeression signiflcative rlc l 'état clc I' irrtet balise le futur cles développelltents souscontrairrtes de qualité et de perlbmrance.Néannroins, en ntatière cle mc<thode, lesens du pragnlat isme et de l 'évolut iondoit toujours I'ernporter sur le do_erne. Lavraie nréthode est un guide nilturellenrentadaptablc et non un moule dans lequcl lapcrt inence er I 'ef l lcaci té disparl issent.

L' lnformat ioue Professionnel le

l ean-P ier re V icko f f

Cette souplesse n'exclut pas le respcct dec()ncepts Structurels fbrtsi.ï)rrns tous les cas, les méthodes du tirturti.li ronl s'irrscrire d;lns un couranf tJc pcn-scic où le sens cle I'adaptation sera le tirc-teur prépondérant. II faut des nréth<xJes"ir la carte" pour du spécifique exrrême(jusqu'au mode Kleenex).;\ l ' instar des personnages du western"l.c bon, la brute et le truand" parodiésper le début de cet arr ic le, Merise nesurvivra pas à I'Objet. Espérons que lesrcsponsables intbrmatiques des enrre-

pr ises françaises prendront les déci-sions qui s ' inrposent car le nronde esten nrarche au rythme d'un changementrap idc c t con t inue l . L 'a l te rna t ive es tsinrple : s'adapte'r ou décliner.

Jean-Pierre Vickoff

www.RAD.fr

Pour err stt t 'oir l lus : Bouhot & Le Gendre

publiem pntchuinenrcnt u,t Rapporr de Conseil

intitulé "Le Reengineering dn Développement

d'Applicutions" dont Jean-Pierre Vickoff est

I'ttuttur.

ll faut des méthodes..à lacarte" pour du spécifiqueextrême $usqu'au modeKleenex).

_l

I

S

S

t

S

t

J

Revue d auteurl, l'lntormàtigue prote$,o^neile accue,[e der opiôioh, qui n.engageôt pa, la rèdà(!ion

QUELQUES CONSEtLS

Conseil 1 : pour obtenir des applications réellementdans chaque projet un volet communication confiéinstrumenté.

approuvées par leurs utilisateurl introduisezà des spécialistes de l'entretien de groupe

Cqnseil 2 : pour obtenir la performance dans vos développements spécifiqueq conseillez auxinformaticiens le pragmatisme en lieu et place du conceptuellement parfait.Conseil 3 : formez à la méthode RAD une petite équipe de concepteurs sachant développer et appli-quez son processus formel et l'ensemble de ses techniques lors de votre prochain projet.

BIBLIOGRAPHIE

[Boehm (8.). Bose (P.)1, A Cotlaborative Spiral Software process Model, USC, l9g4[Martin (James)1, Rapid Applicarion Development, Macmillan, 199,l.[Mc Carty (J.)1, 54 Règles d'or pour un grand logiciel, Microsoft press, 1997.[Mc Connell (S.)],Stratégie de développement rapide, Microsoft press, 1996.iMucchiell i (R.)1, l ' tnterview de groups ESI 1987.lMuller (P. A.)1, Modélisation Objet avec UML, Ëyrollel 1997.INanci (D.), Espinasse (8.)], Ingénierie de systèmes avec Merisg vers une deuxième génération, Sybet 1 993.[Paulkl The Capability Maturity Model : Guidelines for lmproving the Sofrware Procest SEl, 1995.[Rumbaugh (J.)1, OMT Modélisation et conception orientées objet, Prentice Hall (Masson), 1 996.{Vickoff (Jean-Piene)1, RAD - Développement Rapide d'Applicationl Macmillan, ,l996

{Vickoff (Jean-Pierre)1, Reengineering du développement d'applicationq Rapport de Conseil Bouhot &Le Gendre. 1999lYourdon (E.)1, Modern StructuredAnalysis, Englewood Cliffs, 19g9.USC - Universig of Southern California

n" 173 avr i l 1999

, t