Le RAD (Rapid Application Development)

Quels outils pour quelle mthode ?

Conue la fin des annes 80 par James Martin et associs, la mthodologie RAD (Rapid Application
Development) a beaucoup fait parler delle, essentiellement au travers des outils qui sy rfrent.
Quel est le rapport entre la premire et les seconds ?
Six ans aprs lintroduction du terme, quel bilan peut-on en tirer ?
La mthode est-elle dpasse ?
Les outils tiennent-ils leurs promesses ?

La mthodologie
La mthode a t dcrite pour la premire fois par James Martin en 1991. Bien quelle ait pu avoir
volu depuis, cest cet imposant ouvrage (plus de 750 pages) qui nous servira de rfrence pour la
suite. Remarquons demble que le livre ne dcrit pas seulement une mthode, mais surtout une
mthodologie, cest--dire une rflexion sur ou autour dune mthode ou dun ensemble de mthodes. En
particulier, louvrage dcrit ce que devrait tre la mthode idale de dveloppement rapide.

Une mthode RAD devrait, daprs son auteur, apporter trois avantages comptitifs lentreprise :
une rapidit de dveloppement (cette caractristique donne son nom la mthode) ;
un faible cot de dveloppement ;
une application de grande qualit.
Ce dernier aspect est souvent nglig par les vulgarisateurs de la mthode, y compris souvent par les
fournisseurs des outils qui sen rclament, au profit de la rapidit du dveloppement.

Le constat de dpart concerne les carences des mthodes actuelles : les applications sont trs longues
dvelopper. Lorsquelles arrivent lutilisateur final, elles ne correspondent plus au besoin, car nous
vivons dans un monde o tout sacclre, et les besoins se modifient au mme rythme. De plus,
lutilisateur final est peu impliqu dans la dfinition des besoins, sans parler de la conception de
lapplication.
Pour pallier ces inconvnients, pas de recette miracle. Mais un nombre restreint dides-forces.

Les principes
Les principes du RAD sont simples et ils dcoulent du bon sens. Sil y a quelque chose de
rvolutionnaire dans la mthode, cest leur formalisation.

Voici les principes de base :

Tout dabord, le dveloppement devrait tre effectu par de petites quipes, exprimentes et
ayant reu toute la formation ncessaire.
Le dveloppement doit seffectuer en faisant appel une mthodologie formalise.
Une quipe de dveloppement RAD doit disposer doutils puissants qui automatisent le
dveloppement dans sa globalit, tant en ce qui concerne les tapes du dveloppement que
lenchanement de ces tapes.
Lquipe de dveloppement doit tre correctement gre, par un encadrement encourageant la
rutilisation des composants, et attentif aux aspects humains du management de projet.
Enfin, les utilisateurs finaux devraient simpliquer dans le processus de dveloppement.

Extrait de La Lettre de lADELI N27 - Avril 1997 1

 La mthode RAD est donc fonde sur quatre ingrdients de base :
Les outils : de conception, de prototypage, de gnration de code, disposant dun langage de haut
niveau (L4G), ces outils tant fdrs par un rfrentiel et constituant un atelier puissant.
Les personnes : elles doivent tre comptentes, exprimentes, correctement formes aux
techniques et aux outils utiliss, et, cela ira mieux en le disant, ...motives ! Lauteur revient
souvent sur cet aspect fondamental, et un chapitre entier y est consacr. Ce qui est tout aussi
essentiel, cest que lutilisateur final soit directement impliqu dans chaque phase du projet.
Le management : une gestion du projet, en particulier en ce qui concerne les aspects humains,
est essentielle. Le pire ennemi du RAD, cest la bureaucratie, dit James Martin. Combien de
projets na-t-on pas vu driver ou stagner, ensabls par une bureaucratie toujours plus lourde ?
La mthodologie : Rien ne se fera sans une mthodologie, la fois bien formalise et souple.
Lauteur recommande que la mthode soit consigne, non sur un document qui remplirait la
moiti dune armoire, mais dans un hyperdocument que chacun pourrait parcourir rapidement
et de faon non linaire en fonction de ses besoins et de son rle sur le projet. Ce document doit
tre adapt dun projet lautre, toujours affin, et consultable par tous. Seul un document
lectronique disponible sur un rseau peut convenir.

Les quatre phases

Un projet RAD se dcoupe en quatre phases :
1. Phase de dfinition des besoins. Elle se matrialise par des sessions de travail appeles
JRP (Joint Requirements Planning ou dfinition conjointe des besoins).
2. Phase de conception utilisateur (user design). Elle se caractrise par les sessions JAD
(Joint Application Development ou dveloppement conjoint dapplication), qui est un des signes
distinctifs du RAD.
3. Phase de construction, mlant les spcifications dtailles et le codage.
4. Phase de finalisation et mise en place (en anglais : cutover).

Signalons brivement deux points essentiels :

tout dabord, ces quatre phases constituent un processus itratif. Le cutover
dbouche nouveau sur une nouvelle dfinition des besoins, tant que cela savre
ncessaire ;
dautre part, ces phases peuvent, dans une large mesure, tre paralllises.

Les JRP
Le principe de la dfinition conjointe des besoins , autrement dit JRP, est simple, mais pourra
sembler quelque peu rvolutionnaire certains : slectionnez les meilleurs lments, la fois chez le
matre duvre et chez le matre douvrage, et faites les plancher ensemble, dans une salle de runion
sans tlphone et le plus loin possible de toute source de distraction. Ces personnes doivent travailler
ensemble, dfinir ensemble les besoins du systme raliser.
Lorsque lauteur parle des personnes-cls, il ne sagit ni du management seul, ni des as de la
programmation , mais dune slection de lensemble des profils impliques dans le projet. Une de ces
personnes cls : l executive owner , en dautres termes celui qui paye pour avoir le produit final (ou
son reprsentant attitr). Il doit sengager fond dans le processus.
On sen doutait un peu, mais mieux vaut le rpter que de laisser planer le moindre doute : lanimateur
de ces groupes de travail doit tre un communicateur hors pair !

Les JAD
Lide derrire les JAD, qui constituent la substance de la phase de conception, est daugmenter la
productivit globale du dveloppement en runissant lors dune mme session les utilisateurs et les
concepteurs. Encore une fois, son efficacit repose sur deux facteurs cls :
le facteur humain : dynamique de groupe et suppression des barrires organisationnelles ;
loutillage : rfrentiel puissant et outils de prototypage rapide, les prototypes tant, bien sr,
rutilisables pour le dveloppement du produit final ;

2 Extrait de La Lettre de lADELI N27 - Avril 1997

 Les timebox
Dans la plupart des projets de dveloppement dapplication (si ce nest dans TOUS les projets), il y a
des glissements dans les dlais. Cela tient plusieurs causes. Mais on sait en particulier que 80% des
fonctionnalits sont ralises en 20% du temps, et que les 80% du temps restant sont pris par la
ralisation des 20% des fonctionnalits raliser. En fait, plus le dveloppement semble sapprocher de
la fin, moins on avance vite. Cela ressemble du polissage de pices. Plus on avance, plus labrasif doit
tre fin. Et plus labrasif est fin, moins on avance !

En RAD, la loi est dure, mais simple : le glissement est interdit !

Pour un habitu du dveloppement classique, cest une rvolution ! Comment peut-on interdire tout
glissement dans les dlais ? Et si je nai pas fini de dvelopper, comment faire ?

La solution, ici aussi, est simple. Plutt que dautoriser des glissements dans les dlais, on va tolrer un
glissement dans la ralisation : rduisez les fonctionnalits, mais quoi quil arrive, vous finirez temps.

Noublions pas que le RAD, et les outils qui sont supposs le supporter, encouragent le dveloppement
par affinements successifs. Pour reprendre lanalogie prcdente, si on na pas le temps dobtenir un
poli parfait, on va se contenter dune pice un peu rugueuse (ou mme, dans les cas pathologiques cette
fois, dune pice peine dgrossie). Mais on ne va pas se donner du temps pour polir encore et encore.

Un timebox sachve par une revue, qui dcidera sil faut ou non ritrer une deuxime boucle de la
spirale de dveloppement.
Le dveloppement itratif ne rend pas seulement le timeboxing possible. Il le rend ncessaire. Car le
danger des fonctionnalits rampantes (je raffine encore, encore et encore) menace de faire driver un
projet linfini.
Le management dun dveloppement de ce style est dlicat. Une petite quipe (deux personnes en
moyenne) va tre mise sous pression pendant une dure fixe (en gnral 60 jours). Les actions raliser
alors dans cette bote temporelle1 doivent tre correctement estimes.

Critique de la mthode
Outre les aspects outillage , abords plus loin, la mthode comporte un certain nombre de points
faibles.

Lauteur insiste sur la rutilisabilit. Or, pour quun composant soit rutilisable, il doit tre utilisable
dans des contextes diffrents par des applications diffrentes, ou par des modules diffrents. Ceci
implique soit une rflexion en amont de sa construction, soit une gnralisation de ce composant a
posteriori pour louvrir dautres utilisations que celle pour laquelle il a t conu.
Si les dlais sont trs courts, cest bien ce travail de fond qui sera le premier sacrifi. Si un dveloppeur
est pris par le temps, on ne voit pas quelle raison le pousserait chercher rendre un composant
rutilisable plus long terme, donc accomplir une tche dont il ne verra jamais les fruits.

Il ny a pas de miracles. La rutilisabilit demande un investissement long terme. Elle doit tre gre.
Elle doit faire partie des objectifs de lquipe de dveloppement. moins que le dveloppement consiste
en un assemblage de composants prexistants, conus et dvelopps en dehors du contexte du RAD. Et
nous retombons alors dans la problmatique de la conception et de la ralisation par objets.

1Je ne sais pas sil existe un terme franais pour timebox . Si ce nest pas le cas, je me permets den suggrer un seul :
dlai-capsule.

Extrait de La Lettre de lADELI N27 - Avril 1997 3

Et les outils?
Aprs cette brve description de la mthodologie, on peut se poser une question : quels rapports peut-on
trouver avec les outils qui, tort ou raison, se rclament du RAD ? vrai dire, peu de choses.

Ceux que lon appelle habituellement les outils RAD ont en commun un certain nombre de
caractristiques :
ils sont le plus souvent orients objet , ou se prsentent comme tels ;
ils comportent un outil de construction dIHM, ou de gnration automatique de lIHM ;
le langage utilis pour la programmation est un langage de haut niveau, ou un langage dit de
quatrime gnration .

Les trois caractristiques prcdentes encouragent un cycle de dveloppement en spirale. La gestion des
liens logiques entre les objets de linterface graphique et les variables utilises dans la programmation
est entirement automatise. Loutil encourage un dialogue permanent avec lutilisateur final, grce aux
possibilits de maquettage et de prototypage.

Le maquettage et le prototypage
Les outils de dveloppement de nouvelle gnration sont, du point de vue du maquettage/prototypage,
bien plus puissants que tous ceux que lon pouvait trouver sur le march lorsque le livre de James
Martin est paru.

Si les outils RAD mritent leur qualificatif de RAD , cest bien sur cet aspect-l. Les outils
modernes permettent de construire quelques dessins dcrans en une heure.
De l construire linterface homme-machine en temps rel, en runissant informaticiens et utilisateurs
dans une mme salle pendant quelques jours, il ny a quun pas. Si les recommandations de James
Martin sont respectes, en particulier en ce qui concerne les aspects humains, ce pas peut tre franchi.

Lorientation objet
James Martin ne prconise pas lorientation objet dans son ouvrage2. Tout au long de la description de
la mthode est maintenue la sparation entre donnes et traitements, ce qui va bien entendu lencontre
de lapproche par objets (principe dencapsulation).
Par ailleurs, James Martin prcise que le RAD na de sens que par ce quil sinscrit dans un cadre
mthodologique plus large, constitu par lInformation Engineering (qui nest pas une mthode objet).
Cependant, lorientation objet est actuellement lapproche la plus prometteuse pour favoriser la
rutilisation.

Ce que serait un outil RAD idal

Lorsque James Martin parle doutils, il cite IEF, Cohesion et AD/Cycle (nous sommes en 1990). Il ne
sagit pas l doutils que lon qualifierait spontanment de RAD . Nanmoins, certains aspects du
RAD sont mieux traits par ces outils que par les outils RAD des annes 95. En particulier, ils sont
intgrs, ou tendent vers lintgration totale, autour dun rfrentiel puissant.

Quel serait alors le portrait de loutil RAD idal ? On peut tenter de lesquisser en faisant la liste des
fonctionnalits ncessaires la mise en uvre de la mthode:
rfrentiel puissant, prenant en compte la totalit du cycle de vie ;
ce rfrentiel permet un travail en quipe, souple, efficace, non bureaucratique ;
le rfrentiel doit tre facile utiliser, mme par des personnes y faisant rarement appel (directeur
de projet, consultants externes, utilisateur non informaticien) ;

2Le terme dobjet est effectivement utilis quelques reprises, mais dans le sens dobjets du rfrentiel. Le fait que le
rfrentiel soit orient objet nimplique en aucun cas que la conception de lapplication se fasse par objets. Par ailleurs,
James Martin est trs critique vis--vis des techniques objet.

4 Extrait de La Lettre de lADELI N27 - Avril 1997

 la gestion de projet devrait tre intgre loutil. Elle devrait prendre en compte la gestion du
temps, lenchanement des tapes, le paralllisme entre tapes, litration du cycle de
dveloppement, la communication entre individus ;
loutil devrait favoriser la rutilisation des composants.

Parmi les outils actuels, combien y en a-t-il qui permettent de rpondre oui tous ces critres ?
Chacun a son ide sur le sujet.

Personnellement, je me permets les remarques suivantes :

Seule lorientation objet permet dobtenir un niveau industriel de rutilisabilit. La rutilisation
par bibliothques de routines a montr ses limites. Quand la rutilisation par copier-
coller , elle nous mne droit la catastrophe organisationnelle. Cependant, noublions jamais
que la rutilisation doit rsulter dune volont stratgique, et quelle a un cot.
Le rfrentiel puissant et intelligent prconis par James Martin est introuvable sur la plupart
des outils de dveloppement rapide.
James Martin insiste sur les aspects humains du dveloppement. On ferme parfois les yeux sur
une vidence : aucun outil ne rglera les problmes humains. Mme si certains outils, ou
labsence de certains outils, ne peuvent que les envenimer.

Adquation des outils la mthode

Le tableau suivant rsume les diffrences entre les caractristiques du RAD, telles quelles sont dcrites
par James Martin, et la prise en compte de ces caractristiques en termes de fonctionnalits
correspondantes dans des outils RAD.

Aspects Mthode RAD Outils RAD Remarques

de James Martin
Personnes De trs bon niveau, trs Pas de prise en compte
motives, dynamiques ;
jouent un rle important
dans le projet
Rfrentiel Puissant et intelligent Disposent souvent dun Le rfrentiel est un
(fait appel des techniques rfrentiel, mais en gnral point cl pour
dintelligence artificielle) bien moins puissant que James Martin
celui prconis
Conception Entit-relation et Entit-relation parfois,
donnes / fonctionnelle ; sparation mais, de plus en plus
traitements donnes / traitements souvent, outils orients
objet
Outils Intgrs (I-CASE) prenant Rarement intgrs ;
en compte tous les aspects spcialiss sur une partie
du cycle
Cycle de vie 4 phases, elles-mmes Pas de rfrence au cycle de
dcomposes en tapes ; vie, mais la dmarche
dmarche itrative itrative est favorise
Gestion du Timeboxing (blocage des Pas de rfrence au temps
temps tapes dans le temps)
Rutilisation Importante, mais nest pas Possible Lorientation objet,
dcrite clairement souvent favorise par les
outils RAD permet
une rutilisation
effective
Construction Importante En gnral, trs bien prise Laspect le plus positif
de lIHM en compte des outils modernes

Extrait de La Lettre de lADELI N27 - Avril 1997 5

Conclusion
Les quipes dcrites par James Martin sappellent SWAT : Skilled With Advanced Tools. En franais :
comptentes et armes doutils de pointe. On parle souvent des outils RAD. Et si on parlait un peu plus
des personnes ?

De bons outils, nous ladmettons volontiers, sont indispensables. Rares, sans doute. Chers aussi, mais il
suffit dy mettre le prix pour les avoir. Le prix de six mois, un an de salaire par poste. Exorbitant ?

Ce qui est bien plus rare, cher, prcieux, cest une quipe de projet capable de sembarquer dans une
telle aventure. Ce qui est dune valeur inestimable, cest un chef de projet capable la fois de
communiquer son enthousiasme, danimer une quipe, de comprendre le besoin du client, et de secouer
sa propre organisation pour y puiser les ressources qui lui manquent.

Car le RAD, bien lire lauteur du livre du mme nom, cest avant tout une affaire de personnes et
dorganisation. La forme des bureaux et de la salle de runion y joue un rle aussi important que la
structure du rfrentiel. La motivation des dveloppeurs y joue un rle aussi primordial que le
gnrateur dinterface. Vouloir faire du RAD et ny voir que des outils, cest vouloir courir un 400
mtres cloche-pied ! s

Yves Constantinidis

Bibliographie
James Martin, Rapid Application Development, Macmillan, 1991
Le livre de rfrence en matire de RAD, par le pre de la mthode. En anglais

Jean Hugues, Bernard Leblanc, Chantal Morley

RAD, Une mthode pour dvelopper plus vite, InterEditions
Un ouvrage clair et concis. En franais

Bertrand Meyer, Object success; A managers guide to object orientation, its impact on the corporation
and its use for reengineering the software process, Prentice Hall
Ouvrage intressant pour ceux qui sintressent lorientation objet. Ne traite pas spcifiquement du
RAD. Accessible aux non-spcialistes. On y trouve en particulier une rflexion intressante sur la
rutilisation, et sur les aspects humains de la conduite de projet, en particulier dans le cas des
dveloppements par objets.

6 Extrait de La Lettre de lADELI N27 - Avril 1997