merise, le rad et l'objet - le portail des chefs de projets · created date: 1/25/2013 6:16:37...
Post on 13-Sep-2018
216 Views
Preview:
TRANSCRIPT
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
top related