Rad V35

Projet Système d’information
31 mai 2000
Centre associé du Haut Rhin
Projet RAD
- Association « Jeux pour Tous » -
Dossier rendu par :

FAHI Salwa
GROSJEAN Mikäel
INACIO Sivinia Professeur :
ROMARY Fabien M. Spaety
Le 31 mai 2000
Projet RAD
SOMMAIRE
INTRODUCTION ................................................................................. PAGE 3
METHODE RAD ................................................................................. PAGE 4
DSDM : UNE AUTRE METHODE DE DEVELOPPEMENT RAPIDE ............ PAGE 41
LA METHODE RAD FACE AUX AUTRES METHODES PLUS CLASSIQUES PAGE 45
CAS PRATIQUE .................................................................................. PAGE 49
CONCLUSION .................................................................................... PAGE 87
TABLE DES MATIERES ....................................................................... PAGE 88
GLOSSAIRE ....................................................................................... PAGE 90
BIBLIOGRAPHIE ................................................................................ PAGE 93
Projet Système d’information Sommaire

Page 2
Le 31 mai 2000
Projet RAD
INTRODUCTION
De nos jours, afin d’allier rapidité et efficacité dans les développements informatique,
il est nécessaire de mettre en œuvre une méthode. Les méthodes ont pour but de standardiser
les tâches de développement pour rendre l’application finale plus conforme aux besoins des
utilisateurs.
Les utilisateurs étant de plus en plus exigeants et conscients de leurs besoins, on ne
peut que constater que les méthodes dite traditionnel n’ont pas suivi cette évolution. C’est
pourquoi de nouvelles méthodes sont apparus, dont le RAD ( Rapid Application
Developpement ) proposé par James Martin au début des années 1990.
Cette méthode implique les utilisateurs à chaque étape du projet, en leur donnant des
responsabilités de production. Il en résulte une réduction des coûts de maintenance applicative
et corrective.
Tout au long de ce dossier nous essayerons de définir la démarche à suivre pour

développer un projet informatique avec la démarche RAD.
Cette étude s’articule autour de quatre chapitres. Le premier chapitre situe la méthode
RAD, justifie sont utilisation et en donne les grandes lignes. Le deuxième chapitre nous fait
découvrir le DSDM, une autre méthode de développement rapide. Ensuite nous verrons dans
le troisième chapitre la position du RAD face aux autres méthodes plus classiques. Enfin nous
terminerons par une illustration de la méthode sur un cas concret.
Projet Système d’information Introduction

Page 3
Le 31 mai 2000
Projet RAD
METHODE RAD
a. Définition
La méthode RAD a pour objectif principal d’améliorer la qualité des développements,

d'autre part, elle réduit les délais de production et facilite la maîtrise des coûts. C’est une
organisation du travail qui permet aux utilisateurs et aux informaticiens d'aborder
conjointement l'évolution d'une organisation à travers ses projets.
Elle représente une osmose et une synergie entre cinq éléments indissociables :
- la volonté d’une direction souple,
- la motivation des participants,
- la formation des participants,
- l’adaptation de la méthode au projet,
- la performance des AGL ( Ateliers de Génie Logiciel).
Globalement le RAD s’attache à :

- régler les problèmes de communication,
- conceptualiser le travail des utilisateurs,
- prévoir les besoins actuels et futurs,
- préconiser des réponses (stratégiques, technologiques, organisationnelles),
- réaliser des applications totalement approuvées.
Cette méthode s’appuie énormément sur l’engagement total des utilisateurs.
Objectifs
Le RAD a pour objectif principal de réduire le projet en charge (gain d'argent) et en

délai (gain de temps). La deuxième ambition du RAD est l'objectif qualité. Le RAD garantit
le développement d’une application répondant parfaitement aux besoins de l'utilisateur, il en
résulte la réduction des coûts de maintenance applicative et corrective. Les autres objectifs du
RAD sont liés à l'engagement et à la satisfaction des utilisateurs. Le RAD permet et impose
naturellement une participation active et une motivation des futurs clients de l'application. Ce
point à lui seul justifierait l'utilité du RAD. Une application conçue par les utilisateurs et
réalisée sous leurs directives est conforme à leurs attentes et n'encourt pas le rejet.
Projet Système d’information Méthode RAD

Page 4
Le 31 mai 2000
Projet RAD
b. Les acteurs de la méthode RAD
Le facteur humain est un élément-clé du développement rapide d’application.
On distingue quatre groupes d’acteurs :

- les acteurs du pilotage : ce groupe comprend les deux chefs de projets (CPU, chef de
projet utilisateur et CPI, chef de projet informatique) et l’expert RAD. Leur rôle est de
s’assurer du bon déroulement du projet.
- les acteurs du contrôle : il s’agit du propriétaire de l’application ainsi que du comité
de pilotage. Ils guident le projet, sans toutefois le diriger contrairement aux acteurs du
pilotage.
- les acteurs du contenu : ce sont les utilisateurs directs ou indirects du futur système.
- les acteurs du système informatisé : il s’agit de tous les acteurs intervenants dans la
conception et la réalisation de l’application.
RAD : Les acteurs [HUG97]

Page 5
Le 31 mai 2000
Projet RAD
Les acteurs du pilotage
Ils sont responsables de l’aboutissement du projet. On peut considérer qu’ils correspondent au

maître d’œuvre.
Ils sont :
- le binôme chefs de projet : il est constitué du CPI et du CPU, respectivement le chef
de projet informatique et le chef de projet utilisateur. Suivant les étapes du projet, c’est
l’un ou l’autre qui est responsable de l’aboutissement des travaux.
- l’expert RAD : celui ci est extérieur au projet. Il assiste le binôme chefs de projet
dans la conduite du projet. C’est un conseiller méthodologique. Il apporte beaucoup
par son expérience. A l’étape Initialisation c’est à lui de décider si le projet peut être
mené avec la méthode RAD, le cas échéant il bâtit avec les chefs de projet une
variante adéquate. Il partage avec le binôme chefs de projet la responsabilité
d’aboutissement du projet. Il intervient tout au long des étapes du projet en tant
qu’arbitre. C’est à lui que revient le rôle de prévention des risques pouvant faire
déraper le projet (non respect du calendrier, changement intempestif des acteurs).
Les acteurs du contrôle
Ils sont responsables du lancement du projet et de ses grandes orientations. Ils correspondent
à la maîtrise d’ouvrage.
Ils sont :
- le propriétaire de l’application : il joue un rôle important car il est porteur de
l’objectif et des moyens du projet Il a la possibilité d’arrêter le projet à la fin de l’étape
« Expression des Besoins », si le retour sur investissement ne lui paraît pas
suffisamment élevé. Dans certaines entreprises américaines, on l’appelle le
« sponsor ». Il peut effectuer certaines validations officielles de fin d’étape, à la place
du comité de pilotage.
- le Comité de pilotage : il est utilisé dans les entreprises depuis de nombreuses
années. Dans un projet RAD son rôle est allégé, du fait de l’implication élevée des
utilisateurs. C’est une structure de décideurs qui fonctionne comme instance de
validation et d’appel. Elle a une fonction symbolique favorisant la reconnaissance du
projet dans l’entreprise. Le comité décide que le projet est accepté ou non en fin
d’étape d’Initialisation. Il reconnaît la validité du consensus obtenu au sein de l’équipe
JRP en fin d’expression des besoins. Il déclenche les travaux préparatoires de mise en
œuvre en fin de conception. Il officialise la décision de mettre en œuvre l’application à

Page 6
Le 31 mai 2000
Projet RAD
la fin de l’étape Construction. On peut noter que le propriétaire de l’application fait

également partie de ce comité.
Les acteurs du contenu
Ils ont la responsabilité de définir le contenu du futur système. Ce sont des utilisateurs réunis
en équipe ayant une mission propre.
Ils sont :
- l’équipe JRP : cette équipe rassemble des utilisateurs qui représentent chacun un
thème du domaine couvert par le projet. Ils sont responsables de l’expression des
besoins. Ils ont pouvoir de décision en ce qui concerne les évolutions de gestion et
d’organisation relatives à leur thème. Le propriétaire fait parfois partie de l’équipe
JRP.
- l’équipe JAD1 : ce sont les utilisateurs ayant pour la plupart d’entre eux participé à
l’expression des besoins, qui sont chargé de se prononcer sur les propositions du
binôme chefs de projet. Ils ont un pouvoir de décision notamment en session.
- l’équipe JAD2 : ce sont les utilisateurs qui valident la conception détaillée avant le
prototypage. Sa composition est proche de celle de l’équipe JAD1 .
- l’équipe de construction : elle décide des modifications à apporter aux prototypes
présentés au cours des sessions de présentation. Afin d’assurer la continuité des choix
faits à l’étape de construction, la composition de l’équipe de construction est proche
de celle de l’équipe JAD2.
- l’équipe de mise en œuvre : il s’agit de tous les utilisateurs mobilisés pour les
différentes tâches de la mise en œuvre, notamment la formation, l’organisation de
l’installation, la recette.
Les acteurs du système informatisé
Ils sont :
- l’équipe de prototypage : c’est une petite équipe de prototypeurs qui utilisent des
outils de développement rapide c’est à dire des ateliers de génie logiciel intégrés leur
permettant de récupérer les maquettes définies et validées au cours de la phase JAD2.
- le modélisateur peut intervenir auprès du chef de projet informatique, en dehors des
sessions, lors des phases JRP et JAD1.
- l’administrateur des référentiels a pour rôle, à l’étape conception de favoriser la
réutilisation des composants (modèles, entités conceptuelles, fonctions logiques) et
d’inciter aux respects des normes et standards d’entreprise.

Page 7
Le 31 mai 2000
Projet RAD
- l’ergonome qui peut intervenir à trois moments : lors de l’élaboration des maquettes,
lors des travaux de prototypage et lors des travaux d’intégration de la mise en œuvre.
La relation Rôle/Phase
La figure suivante résume les interventions de chaque type d’acteur selon le moment où l’on
se situe dans le projet.
[HUG97]
c. Démarche de la méthode RAD
Le déroulement d'un projet RAD comprend cinq étapes :

- Initialisation,
- Expression des besoins,
- Conception,
- Construction,
- Mise en œuvre.
Les libellés des étapes font référence à l'activité dominante de ces étapes, ce qui n'exclut
pas la possibilité de voir cette activité dans d'autres étapes. Par contre, la fin de chaque étape
est marquée par l'officialisation d'une décision (lancement du projet, accord sur les besoins,
accord sur la solution etc...).
De plus, chaque étape est caractérisée par un objectif, un responsable, une fourniture et
une durée acceptable. Une étapes peut comprendre différentes phases. Chaque phase étant
caractérisée par un objectif, des acteurs impliqués, des activités et la mise en œuvre de

Page 8
Le 31 mai 2000
Projet RAD
techniques. Ces techniques peuvent être spécifique à RAD (JRP, JAD etc ...), ou adaptées
pour RAD (technique de prototypages etc ...), ou utilisées couramment dans les projets
système d'information (technique de modélisation etc ...).
Une phase peut être découpée en trois temps :
[HUG97]
Les travaux de préparation consistent à rassembler des matériaux, élaborer une

solution ou développer un prototype, en vue d'une présentation à un groupe choisi.
La session est une séance de regroupement, durant laquelle des acteurs divers vont
travailler de façon intensive, sur la base du résultat des travaux de préparation, dans le but de
faire rapidement et ensemble des choix de conception et de développement solides.
Les travaux de conclusion consistent à prendre en compte le résultat de la session :

selon les cas, il s'agit de mettre en forme, de modifier ou d'effectuer des travaux
complémentaires.
Le déroulement d'un projet est ponctué à la fois par des sessions et par l'officialisation
des décisions. La structure détaillée du cycle RAD est la suivante :
[ HUG97]

Page 9
Le 31 mai 2000
Projet RAD
L'étape Initialisation
Elle a pour but de faire entrer ou non le projet dans un processus RAD. Pour cela, elle
détermine comment mettre en œuvre la méthode pour le projet, elle rassemble les ressources
informationnelles et humaines nécessaires tout au long du projet RAD.
Cette étape est pilotée par un chef de projet informatique (CPI) et un chef de projet
utilisateur (CPU) qui vont travailler en étroite collaboration tout au long du projet. Le CPU et
CPI constituent le binôme chefs de projet.
L'étape Initialisation doit être brève, elle ne doit pas dépasser deux semaines. En effet,
cette première étape donne le rythme au projet car un démarrage rapide est la première
manifestation d'un développement rapide. L’étape s’achève sur la production d’un dossier
d’initialisation.
Elle comprend deux phases :

- Diagnostic,
- Mobilisation.
L’étape d’initialisation [HUG97]

Page 10
Le 31 mai 2000
Projet RAD
La phase de diagnostic
Cette phase a pour but de formaliser les caractéristiques du projet. Elle se termine par
la décision de mener ou non le projet en RAD dès le début.
Les acteurs impliqués dans cette phases sont le binôme chefs de projet qui effectue les
travaux de préparation et la conclusion, l'expert RAD qui est sollicité pour la session et le
propriétaire qui lui participe à la conclusion.
Cette phase fait essentiellement appel à l'expérience et à la connaissance de l'expert

RAD. Elle ne requiert aucune technique spécifique.
Les travaux de préparation de la phase de diagnostic sont menés par le binôme chefs
de projet. Le rôle du binôme est de rassembler, dans une grille de description du projet, les
informations décrivant le projet et son contexte. Cette grille constitue la caractérisation
initiale du projet. Elle permet de dresser le profil du projet et de faire une première évaluation
des risques. Le CPU décrit le projet du point de vue gestionnaire. Il doit être capable de situer
les enjeux pour l'entreprise, d'expliquer les objectifs de gestions et d'organisations, d'identifier
les services qui utiliseront l'application, de repérer les utilisateurs qui pourront faire partie de
l'équipe du projet. Le CPI situe le projet du point de vue informatique. Il doit être capable de
positionner le futur système dans l'architecture applicative de l'entreprise en repérant les
domaines connexes, applications et progiciels avec lesquels il faut communiquer. Il prévoit
les interactions possibles avec d'autres projets en cours de développement.
La session a pour but d'analyser avec l'expert RAD si le projet peut effectivement être
mené dans un délai court avec le dispositif RAD complet ou s'il faut envisager une variante.
Pour situer le projet par rapport à la méthode RAD, l’expert examine les cinq critères
permettant d’établir le profil du projet.
1. Les domaines connexes au projet sont-ils stables ? Pour les domaines en cours de refonte,
est-ce que les points d’interface et les données partagées avec le projet, sont-ils déjà
stabilisés ? Il existe différents cas de figure à envisager.
- L’environnement du projet est suffisamment stable pour permettre un démarrage
immédiat en RAD.
- Le projet est différé jusqu’à stabilisation des interfaces. Il est possible d’utiliser la
technique de pilotage RAD dans le projet connexe pour mettre sous contrôle
l’avancement de la conception des zones frontières.
- Au lieu de différer le projet jusqu’à stabilisation des interfaces, celui-ci peut
commencer de façon classique pour se caler sur le calendrier des projets dont il est

Page 11
Le 31 mai 2000
Projet RAD
dépendant. Si l’on souhaite que la construction se fasse en RAD, le projet sera intégré
dans le cycle RAD en phase JAD2 de l’étape conception.
2. Est-ce que les deux chefs de projet vont pouvoir fonctionner comme un binôme ? Le chef
de projet utilisateur est-il suffisamment disponible, en particulier pour les premières
étapes ? L’engagement dans le projet est-il partagé de façon équilibrée par les deux chefs
de projet ? Se sentent-ils également responsables de l’objectif délai ? On peut distinguer
deux cas :
- Le chef de projet utilisateur est complètement disponible jusqu’à la fin de la
conception, c’est-à-dire pendant une période de deux à trois mois. Le projet peut
démarrer en RAD avec comme possibilité de changement du chef de projet utilisateur
en phase JAD2.
- Le chef de projet utilisateur n’a pas assez de disponibilité pour le projet ; soit le projet
est différé, soit on adopte une démarche classique pour ensuite rejoindre le cycle RAD
en phase JAD2.
3. Le pouvoir de décision des utilisateurs est-il nécessaire? Ont-ils le droit de modifier des
règles de gestion ou de s’engager sur une nouvelle organisation ? Comme la charge de
travail des utilisateurs travaillant sur un projet RAD est plus importante que celle d'un
projet classique, les utilisateurs ne peuvent être dépendants et disponibles à des décideurs
extérieurs au projet RAD. Par ailleurs, le travail en session participative n’a de raison
d’être que s’il débouche sur des décisions prises en commun. On a ainsi deux possibilités :
- Le projet peut être mené en RAD dès le début si le pouvoir de décision des
utilisateurs est suffisant par rapport au domaine du projet.
- Si les utilisateurs n'ont pas la disponibilité et un pourvoir de décision nécessaire, on
revient à une conception classique, quitte à faire la réalisation avec l’approche RAD.
4. Les utilisateurs identifiés comme participants sont-ils suffisamment nombreux ? RAD est
une méthode participative, qui organise le travail collectif pour augmenter son efficacité et
réduire les blocages. Si le nombre d’utilisateurs est faible (moins de quatre personnes), si
leurs points de vue sont proches, alors les techniques JRP et JAD doivent être utilisées de
façon allégée. Les sessions peuvent être réduites, de même que le degré d’isolement.
5. Les utilisateurs ont-ils une bonne connaissance des règles de gestion ? Une des clés de la
rapidité est la répartition du travail entre utilisateurs et informaticiens pour que cela
présente un intérêt, il faut cependant que les premiers soient suffisamment informés sur le
système de gestion touché par le projet. Sinon, il faut faire appel à d’autres intervenants
possédant les connaissances suffisantes : informaticien chargé de maintenir l’application

Page 12
Le 31 mai 2000
Projet RAD
existante, fournisseur du progiciel installé depuis plusieurs années, etc. Plusieurs cas sont
envisageables.
- La connaissance du système de gestion par les utilisateurs autorise une conception en

RAD.
- Un transfert de connaissance est fait entre les intervenants et les utilisateurs. On
ajoute un phase de transfert préalable à l'expression des besoins.
Le projet peut démarrer en RAD si l'analyse du projet démontre qu'il peut-être mené
rapidement et de façon participative.
Il est souvent utile de conforter la légitimité du projet dans l'entreprise en faisant

reconnaître officiellement un propriétaire (en général c'est le financeur du projet).
Après la session, les travaux de conclusion consistent à arrêter le choix de la méthode ou

de sa variante. Le binôme chefs de projet soumet au propriétaire la grille de description du
projet, ainsi qu'une proposition de plan de développement. La décision est alors officiellement
prise de lancer ou non le projet en RAD.
La phase de diagnostic [HUG97]

Page 13
Le 31 mai 2000
Projet RAD
La phase de mobilisation
La phase de mobilisation a pour but de constituer l’équipe de projet et d’établir les bases
de l’organisation du projet.
Plusieurs types d’acteurs sont impliqués dans la phase de mobilisation. Le binôme chefs
de projet et l’expert RAD effectuent les travaux de préparation et la conclusion. Ils réunissent
le propriétaire et l’équipe JRP pour la session.
Les techniques utilisées dans la phase de mobilisation sont des techniques classiques de
recueil d’information, telles que la conduite d’entretien et l’animation de réunion.
Les travaux de préparation de la phase consiste en l’étude du domaine à travers ses

différents thèmes, qui correspondent à des fonctions, des processus ou des points de vue
spécifiques. Ils associent à chaque thème le nom de l’utilisateur qui sera responsable de
l’expression des besoins. Un thème doit respecter trois critères:
unité fonctionnelle, unicité personnelle et homogénéité de charge. Il ne doit comporter qu’une
seule fonction. La maille de découpage du domaine étant large, chaque fonction pourra
ensuite être décomposée en plusieurs sous-fonctions. Il faut trouver une seule personne
susceptible de prendre en charge tout le thème. Même si elle s’appuie sur d’autres personnes,
celle qui est responsable du thème doit pouvoir l’exposer complètement et prendre des
décisions.
L’identification des thèmes conduit à dresser une liste nominative de l’équipe JRP. Elle
est remise au propriétaire pour qu’il les convie à la session. Celle-ci est une réunion publique
de lancement du projet.
La session permet de présenter aux participants les objectifs du projet et leur futur rôle.
Les chefs de projet, assistés de l’expert RAD, organisent la suite du déroulement du projet
afin de fournir en séance des informations concrètes et précises. Ceci évite les confusions et
les allers-retours ultérieurs. Pour cela, ils anticipent sur l’organisation de la future session
JRP: logistique, agenda, modalités de déroulement. Une date et un lieu de rendez-vous de la
session JRP sont arrêtés pour être proposés en session. L’ordre dans lequel chaque thème sera
traité est établi, ainsi que la durée attribuée à chaque thème. La forme de la présentation est
déterminée.
La grilles, les outils de représentation et les supports qui pourront être utilisés sont
préparés. Une liste de la documentation du projet est établie. Elle sera remise (références ou
documents) à chaque participant.

Page 14
Le 31 mai 2000
Projet RAD
L’ensemble des éléments résultant des travaux de préparation constitue le dossier

d’initialisation du projet.
La session permet à la fois d’informer et de créer une dynamique d’équipe. Elle dure
environ deux heures et se déroule de la façon suivante:
- Le projet est présenté, soit par le propriétaire, soit par le chef de projet utilisateur. Il
expose la finalité du projet. Il situe son importance pour l’entreprise. Il détaille ses
objectifs, limites et contraintes, enfin il évoque les perspectives d’avenir, les projets
complémentaires....
- La méthode est présentée par l’expert RAD: son objectif, ses principes, les règles du
jeu, les rôles et les étapes.
- Le chef de projet utilisateur prépare les participants à la session JRP.
La réunion comprend un échange avec les participants. Il s’agit de créer un esprit

d’équipe qui favorise une participation active et l’acceptation des contraintes du travail
collectif.
Les travaux de conclusion de la phase de mobilisation sont menés par le binôme chefs de
projet et l’expert RAD. Il s’agit de prendre en compte les échanges de la session. Cela
entraîne souvent quelques aménagements de l’étape suivante. On peut alors fixer
définitivement la logistique de la session JRP (date et lieu) et en arrêter les modalités de
déroulement (agenda).
La phase de mobilisation [HUG97]

Page 15
Le 31 mai 2000
Projet RAD
Les aménagements sont consignés dans le dossier d’initialisation du projet . Celui-ci est
alors présenté pour validation au comité de pilotage.
L’étape Expression des besoins
L’objectif de cette étape est d’obtenir l’expression des besoins par le biais de l'équipe
JRP. Il s'agit de définir les bases du futur système en termes de fonctions à remplir. Dans les
étapes suivantes les utilisateurs auront la possibilité de compléter leur expression.
C'est le chef de projet utilisateur qui pilote cette étape. En effet, les utilisateurs sont les
acteurs-clés de cette étape.
Sa durée dépend du nombre de fonction, mais en général elle est de l’ordre de quatre à six
semaines. En effet, il ne s’agit pas d’obtenir une description exhaustive des besoins car
l'expression est affinée par la suite.
L’étape s’achève sur la production d’un dossier d’expression des besoins, présenté par
thèmes. Ce document contient la description du système existant, les critiques et les demandes
d’évolution ou de fonctions nouvelles. Cependant il ne faut pas le considérer comme un
cahier des charges exhaustif, puisque l’expression des besoins se poursuit et s’affine dans les
étapes Conception et Construction. Ce dossier est validé par le comité de pilotage. C’est le
point de départ de l’étape Conception.
L’étape Expression des besoins commence dès la fin de la session de la phase de

mobilisation de l’étape précédente. Après cette réunion de lancement, les utilisateurs peuvent
commencer leurs travaux de recherche et formalisation des besoins. Le binôme chefs de projet
intervient, pour sa partie propre, et dans son rôle d’assistance, dès qu’il a conclu l’étape
Initialisation.
L’étape comprend une seule phase. Elle s’appuie de façon centrale sur la technique du
JRP (Joint Requirement Planning), planification participative des besoins.
La phase JRP
Cette étape repose principalement sur les utilisateurs faisant partie de l’équipe JRP. Pour
effectuer les travaux de préparation, ils sont ponctuellement assistés du binôme chefs de
projet ou de l’expert RAD. Quant au chef de projet informatique, il a des travaux de
préparation spécifiques.

Page 16
Le 31 mai 2000
Projet RAD
Ils participent tous à la session JRP. Le binôme chefs de projet, éventuellement assisté de
l’expert RAD, mène les travaux de conclusion. La charge qui incombe à chaque utilisateur
responsable d’un thème est, en général de cinq ou six jours, répartis en travaux de préparation
(3 jours), session (2 jours) et conclusion (0,5 jour).
Au cours de la phase JRP, on utilise des techniques classique tels le recueil de

l’information, la conduite d’entretien et de réunion, des techniques de modélisation, ainsi
qu’une technique RAD spécifique : le JRP.
Les travaux de préparation sont menés en majeure partie par les utilisateurs de l’équipe
JRP. Chacun est responsable de l’expression des besoins sur son thème. La qualité de ces
travaux est déterminante pour celle de la session JRP. Tout est mis en œuvre pour la réussite
de la session, car c’est un événement unique dans la vie du projet. Le binôme chefs de projet,
ainsi que l’expert RAD, suivent l’avancement de près, mais ils apportent également leur aide.
Il est préférable que chaque responsable soit rencontré au minimum deux fois avant la
session.
Les thèmes ont été définis de façon que la charge de travail propre à chaque utilisateur
soit de l’ordre de trois jours. Il peut arriver que l’utilisateur chargé d’un thème ait besoin de
consolider une connaissance répartie entre plusieurs personnes. Sa charge de travail est alors
un peu plus importante. Il peut organiser un mini-JRP, c’est-à-dire une réunion traitant des
différents sous-thèmes. La préparation est confiée à chacune des personnes devant être
consultées. Le responsable du thème fait la synthèse et la mise en forme des expressions
individuelles.
Le résultat des travaux de préparation fait l’objet d’un document, dont la forme a été
communiquée lors de la réunion de lancement. Le formalisme utilisé pour préparer les thèmes
a un double objectif : d’une part, il facilite la compréhension lors des présentations en session
; d’autre part, il accélère le travail de l’utilisateur, car il cadre sa recherche d’informations. Il
doit donc être simple et peu contraignant.
Certaines personnes conseillent l'utilisation :

- d’un modèle de contexte [PAN94], mettant en évidence les flux entrants et les flux
sortants, si on se place du point de vue du thème;
- pour chaque flux entrant, d’un schéma d’organisation, qui donne une vision
organisationnelle des traitements (services ou postes de travail concernés; documents
émis, reçus ou utilisés en référence; règles de choix, de décision, de déclenchement).

Page 17
Le 31 mai 2000
Projet RAD
Chaque utilisateur prépare un document qu’il remet au binôme chefs de projet. C’est la
base de sa présentation. Ce document doit être structuré de la façon suivante :
- la description de l’existant : elle comprend le modèle de contexte, avec la nature, le
volume et la fréquence de chaque flux. A chaque flux entrant, on attache un schéma
d’organisation, comprenant la description des traitements, avec les règles de gestion. Il
est accompagné d’un exemplaire de chaque document, émis, reçu ou utilisé en
référence. La description se termine sur un bilan de l’existant: points forts / points
faibles, dysfonctionnements, manques, sous-capacités, coûts....
- l’expression des besoins : elle reprend le modèle de contexte, pour y faire apparaître
d’éventuelles modifications dans les flux. De même, les schémas d’organisation sont
revus, pour mettre en évidence de nouvelles fonctions, des changements de support,
une demande d’automatisation. D’autres besoins peuvent être exprimés librement.
L’utilisateur prépare son intervention dans le cadre fixé lors de la réunion de lancement.
Il fait parvenir son document et ses supports dans la semaine qui précède la session, pour que
les animateurs JRP puissent anticiper son déroulement et soulever d’éventuels problèmes
d’incohérence, de conflits....
Les deux chefs de projet sont particulièrement attentifs à ces travaux, c'est pourquoi au
moins deux rencontres sont faites avec chaque utilisateur, afin de s’assurer que tout va bien.
L’expert RAD peut aussi faire partie de cette cellule.
Compte tenu du caractère collectif de ces travaux, l’utilisation d’outils de travail

coopératif (groupware) est à envisager. Les chefs de projet et l’expert RAD peuvent ainsi,
sans déplacement géographique, suivre l’avancement des travaux de l’utilisateur et dialoguer
avec lui.
Parallèlement à leurs activités d’assistance, les chefs de projet mènent leurs propres
travaux de préparation. Le CPI établit un bilan de l’application informatique existante: taille
de l’application (nombre de lignes de code, par exemple), nombre de transactions, volume des
fichiers et bases de données, importance de la maintenance, problèmes d’exploitation.... Il
identifie les contraintes informatiques qui s’imposent à la future application: architecture,
système d’exploitation.... Le CPU fait une recherche sur des systèmes équivalents, en
interrogeant d'autres entreprises ou des fournisseurs de progiciel. La connaissance de ce qui se
fait ailleurs et les fonctionnalités qui existent sur le marché, élargissent la perspective dans la
phase de conception. De plus, le binôme chefs de projet prépare dans tous ses détails
l’organisation de la session.

Page 18
Le 31 mai 2000
Projet RAD
La session JRP se déroule en résidentiel, c’est-à-dire dans un lieu isolé des lieux de
travail habituels des participants. Il y a plusieurs raisons à cet éloignement. On attend des
participants qu’ils se concentrent sur le projet pendant toute la durée de la session. Cet effort
est incompatible avec des sollicitations extérieures, en particulier celles qui proviennent du
travail quotidien. La session est intensive et la disponibilité de chacun doit être aménagée. La
participation active des utilisateurs fait partie des règles de base de la méthode RAD. Or, les
projets mettant en jeu des acteurs variés, butent fréquemment sur un obstacle: les objectifs et
attentes de ces acteurs ne sont pas convergents. Avec RAD, on mise sur la constitution d’un
groupe (l’équipe JRP) pour construire cette convergence. L’isolement temporaire des acteurs
favorise l’émergence d’un esprit de groupe orienté vers un objectif commun.
Un animateur, en général l'expert RAD, conduit la session JRP. Il a pour rôle de

surveiller les temps de parole, de recentrer vers l’objectif et de veiller à la participation de
tous. La session JRP est structurée en trois parties se terminant par un débat et un point de
consensus.
Les 3 parties d’une session JRP [HUG97]
En première partie, chaque participant expose le fonctionnement du système existant,

limité à son thème, dans le strict respect du temps imparti. Des compléments d’explication
peuvent être ensuite fournis lors du débat et ensuite on fait alors un point de consensus.
L’animateur s’assure que tous les participants partagent l’analyse proposée. La juxtaposition
des bilans partiels permet de construire un bilan global du fonctionnement du domaine. Ce
bilan est enregistré dans le compte rendu JRP.
En seconde partie, chaque participant expose ce qu’il attend du futur système sous l’angle
de son thème. La discussion qui suit doit rester limitée dans le temps. Toute question
soulevée, à laquelle on n’a pas apporté de réponse satisfaisante dans les cinq minutes, fait
l’objet d’une fiche problème, qui est confiée à un participant pour traitement après la session.
On fait alors un second point de consensus, en reformulant les besoins exprimés par chaque
utilisateur. On arrive ainsi à construire une première image des fonctions attendues pour
l’ensemble du domaine. L’animateur s’attache à dégager un consensus, d’une part sur une

Page 19
Le 31 mai 2000
Projet RAD
estimation de la rentabilité de chaque fonction, d’autre part sur le degré de priorité des
fonctions. Il encourage les utilisateurs à s’accorder sur une classification en trois groupes:
fonctions devant figurer dans la première version, fonctions pouvant figurer dans la première
version et fonctions à reporter dans la version suivante. Le résultat du consensus, ainsi que les
problèmes éventuels, sont enregistrés dans le compte rendu JRP.
En troisième partie, on rappelle les contraintes du projet, celles qui proviennent de

l’application, et celles qui sont liées à la conduite de projet RAD. Le CPI expose les exigences
de cohérence du système d’information de l’entreprise, les contraintes de l’architecture
informatique et réseau, et les impératifs de sécurité. Le CPU rappelle les contraintes coût /
délai du projet. Les investissements doivent s’inscrire dans les limites du budget. Par ailleurs,
les prochaines échéances du projet sont annoncées, à savoir :
- les dates limites pour le traitement des fiches problèmes,
- la date de la première session JAD, au cours de laquelle une solution est proposée et
discutée collectivement.
La session se termine par une évaluation du travail effectué. Chaque utilisateur remplit
une fiche d’évaluation JRP, qui permet au binôme chefs de projet de déceler d’éventuelles
réserves ou attentes, à traiter immédiatement ou à prendre en compte dans la session JAD. Le
compte rendu JRP est remis à chaque participant.
Les utilisateurs désignés traitent leurs fiches problèmes et les transmettent au binôme
chefs de projet. Un exemplaire est adressé à toute l’équipe JRP. Le binôme, assisté de l’expert
RAD, effectue la mise en forme de la description de l’existant qui sera utilisée à l’étape
Conception. Il s’agit:
- de dresser le dictionnaire des données,

- d’établir le dictionnaire des règles de gestion,
- de modéliser le domaine, en établissant les diagrammes de flux [PAN94], avec trois
niveaux de décomposition: modèle de contexte du domaine; modèle de flux conceptuel
global, faisant apparaître les processus; modèle de flux conceptuel par processus,
faisant apparaître les opérations conceptuelles.
On peut alors constituer un dossier d’expression des besoins. Celui-ci reprend, avec les
ajustements dus au traitement des fiches problèmes, le bilan de l’existant et l’expression des
besoins obtenue en session JRP, on y a ajouté les modèles de flux et les dictionnaires
(données et règles de gestion). Ce dossier est soumis pour validation officielle au comité de
pilotage.

Page 20
Le 31 mai 2000
Projet RAD
La phase JRP [HUG97]
L’étape Conception
L’étape Conception [HUG97]
Cette étape conduit à une description du futur système, afin qu’on puisse planifier les
cycles de construction des prototypes, chacun couvrant une liste de fonctions identifiées.
L’étape est pilotée successivement par le CPU et le CPI. Le chef de projet utilisateur est
responsable de la première phase (JAD1), car il s’agit de proposer une évolution du système
existant, en tant que système de gestion et système d'organisation. Le chef de projet
informatique est responsable de la seconde phase (JAD2),car elle prépare directement la
construction des prototypes.

Page 21
Le 31 mai 2000
Projet RAD
Sa durée dépend du nombre de fonctions, mais en général elle est de l’ordre de quatre à
douze semaines. La charge de chaque utilisateur identifié comme membre de l’équipe JAD est
de l’ordre de six jours.
L’étape s’achève par la production d’un dossier de conception, présenté par processus. Il
contient une description à deux niveaux du futur système. Celui-ci est d’abord modélisé à
travers ses flux et ses données. Le dossier contient ensuite une vision externe de l’application,
avec ses maquettes d’écran et d’état. La fourniture comprend également une planification de
l’étape suivante: combien de Prototypes va - t'on construire ? Comment les ordonnancer ?
Quel est le contenu de chaque Prototype ? Ce dossier est validé par le comité de pilotage.
C’est le guide de l’étape Construction sans toutefois être un cahier des charges de réalisation.
L’étape Conception commence après les travaux de conclusion de l’étape précédente.

Elle est organisée autour de l’utilisation en deux temps de la technique du JAD (Joint
Application Design), conception participative d’application.
L’étape comprend deux phases: la phase JADI donne une vue modélisée du futur système
d’information organisationnel. La phase JAD2 recense et décrit les fonctions du futur système
d’information informatisé.
La phase JAD1
Le but de cette phase est d'établir, en concertation avec les utilisateurs, le fonctionnement
conceptuel et organisationnel du futur système et d’effectuer les choix d’architecture
technique.
Le binôme chefs de projet et l’expert RAD effectuent les travaux de préparation et la

conclusion. Ils réunissent les utilisateurs formant l’équipe JAD1 pour la session.
Les techniques utilisées dans la phase JAD1 sont des techniques classiques de
modélisation ([COL84],[PAN94]) et conduite de réunion, ainsi qu’une technique spécifique
au RAD, le JAD, et des techniques complémentaires: la réutilisation et l’estimation des
charges.
Les travaux de préparation sont menés par le binôme chefs de projet et l’expert RAD.
Ils conduisent à une conception générale de l’application. On peut distinguer les travaux de
modélisation des données, des flux, de l'organisation, de l’architecture technique, et la
préparation de la session.

Page 22
Le 31 mai 2000
Projet RAD
La modélisation des données se fait à partir du dictionnaire des données et du dictionnaire

des règles de gestion. Il en résulte un modèle conceptuel de données.
La modélisation des flux se fait à partir de la description de l’existant. Celui-ci a été
modélisé au terme de la session JRP, avec trois niveaux de décomposition:
un modèle de contexte, représentant les échanges du domaine avec les acteurs externes et les
autres domaines; un modèle de flux conceptuel global, représentant la décomposition du
domaine en processus et l’enchaînement de ces processus; un modèle de flux conceptuel par
processus, décomposant chaque processus en opérations. Les travaux de préparation
permettent de faire évoluer ces modèles afin qu’ils répondent aux besoins exprimés.
La modélisation de l’organisation donne aux utilisateurs de l’équipe JAD1 une
représentation du fonctionnement futur. Trois types de modèles sont généralement utilisés :
- Un modèle de flux organisationnel représentant les flux entre les types de sites,
services ou postes; il prépare une éventuelle architecture technique répartie; la
description doit être suffisamment précise pour permettre à chaque membre de l’équipe
JAD1 de se repérer.
- Un modèle organisationnel des traitements qui a pour but de proposer des choix
d’informatisation et de répartition des traitements entre les acteurs.
- Un modèle organisationnel des données qui a pour but de faire apparaître les options
prises sur la localisation des données, les historisations et les autorisations, si le projet
est confronté à des choix de cette nature.
La question de localisation se pose lorsqu’on a plusieurs sites géographiques et que l’on

veut répartir les données afin de favoriser leur disponibilité, en réduisant les temps de
réponse et les coûts d’accès. Les utilisateurs doivent alors avoir une visibilité sur cette
répartition, car elle est en partie liée aux répartitions des responsabilités.
La question d’historisation se pose si l’application gère des séries importantes de données -
historiques de consommation - par exemple. Il faut faire des choix temporels (durée de
conservation), des choix d’accès (données disponibles immédiatement et données
accessibles par une procédure en temps différé), des choix de supports (microfiche, CD-
ROM) et des choix de personnes (responsable de l’archivage).
La question d’autorisation d’accès se pose pour les données sensibles (le chiffre d’affaires
avec un client) ou confidentielles (les données concernant le salarié).
La modélisation de l’architecture technique est placée sous la responsabilité du chef de

projet informatique. Le but est d’obtenir un schéma d’architecture matérielle (serveur, postes
clients, réseaux WAN et LAN) et logicielle. Si l’architecture technique existante ne peut
supporter le futur système, il faut déterminer une éventuelle mise à niveau. Dans le cas

Page 23
Le 31 mai 2000
Projet RAD
d’investissements potentiels importants, il faut proposer au moins deux scénarios au

propriétaire.
La préparation de la session comprend la détermination exacte des participants, la

logistique et l’agenda. L’équipe JAD1 est constituée sous la responsabilité du chef de projet
utilisateur. Il veille à une continuité avec l’équipe JRP: une partie au moins de cette équipe
participe aux travaux de conception. La logistique est prévue suffisamment tôt: date, lieu,
salle, transports... Les informations sont envoyées aux participants. On établit également le
document support, qui sera remis à chaque participant. Il est structuré selon le déroulement
prévisionnel de la session. L’ordre suivant est recommandé :
- Les choix techniques sont parfois lourds de conséquences financières. C’est pourquoi il
est utile de les présenter et d’en discuter en premier. Cela évite de s’engager dans des
options de conception incompatibles avec les contraintes budgétaires.
- Les choix d’organisation sont ensuite présentés, car ils permettent à chacun de se situer,
et situer son entité organisationnelle, dans l’ensemble des processus du domaine. Le
modèle des flux organisationnel se prête à ce type de présentation. La description des
traitements se fait au travers d’une vue organisationnelle, celle du modèle
organisationnel des traitements.
- Les choix de structuration de données sont exposés en dernier. Pour éviter un
vocabulaire technique, les données peuvent être présentées par le chef de projet
utilisateur.
L’ensemble des éléments déterminés lors des travaux de préparation constituent le dossier
de conception du projet. Ils permettent de faire une première évaluation de la charge de
travail.
La session JAD1 permet à la fois d’affiner la conception et de créer un consensus dans

l’équipe des utilisateurs. Comme la session JRP, elle se déroule dans un lieu résidentiel.
L’isolement favorise la disponibilité, la concentration et l’intensité des échanges. Il localise le
travail de conception dans le temps et l’espace. La session dure un ou deux jours selon le
champ couvert.
Les différents points de l’ordre du jour sont présentés soit par le chef de projet utilisateur,
soit par le chef de projet informatique. La session est conduite par un animateur, qui a pour
rôle principal l’animation des échanges et la recherche d’une convergence.
Comme dans la session JRP, un compte rendu des décisions est remis en fin de session.
D’éventuelles fiches problèmes sont établies, des responsables sont désignés. L’animateur

Page 24
Le 31 mai 2000
Projet RAD
organise le bilan de la session. Les membres de l’équipe JAD1 en remettent leur évaluation
écrite.
Les travaux de conclusion de la phase sont menés par le binôme chefs de projet et
l’expert RAD. Il s’agit de prendre en compte les décisions prises lors de la session,
d’actualiser les modèles et de revoir l’estimation des charges. Le résultat du traitement des
fiches problèmes est intégré. Le dossier de conception du projet , mis à jour, est présenté pour
validation officielle au comité de pilotage du projet, ou à défaut au propriétaire de
l’application.
La phase JAD1 [HUG97]
La phase JAD2
La phase JAD2 a pour but d’établir, en concertation avec les utilisateurs, la liste des
fonctions logiques, transactionnelles et batch, de construire un échantillon de maquettes et de
déterminer la répartition de ces fonctions dans la série des prototypes qui vont être développés
à l’étape suivante.
Outre la technique générale de conduite de réunion, on utilise la technique JAD

spécifique de RAD, ainsi que les techniques complémentaires: maquettage, réutilisation et
estimation des charges.
Les travaux de préparation sont menés par le binôme chefs de projet et l’expert RAD.
Un prototypeur confirmé de l’équipe de prototypage est mobilisé pour la construction des

Page 25
Le 31 mai 2000
Projet RAD
maquettes. Il s’agit d’élaborer une solution qui sera proposée en session. On peut distinguer
sept types de travaux: concevoir la base de données, modéliser les traitements au niveau
logique, établir le guidage fonctionnel (menu de l’application), faire une maquette des
fonctions logiques, décrire le noyau applicatif, décrire les fonctions logiques batch et préparer
la session.
Afin de faciliter le travail en session, il est conseillé de présenter le maquettage complet

d’une fonction logique qui joue le rôle de fonction de référence. Elle fera partie du premier
prototype de l’étape Construction. Pour avoir la couverture la plus large possible, on choisit
d’élaborer des maquettes pour celles des autres fonctions qui se différencient le plus de la
fonction de référence.
La description du noyau applicatif complète la description établie en phase JAD1. Pour

chaque tâche non interactive, on décrit les actions sur les données, les calculs, les contrôles
d’intégrité, les contrôles de sécurité....
Les fonctions logiques batch font l’objet d’une liste de programmes ou modules à écrire à
l’étape Construction. Dans la mesure du possible, on décompose les fonctions logiques en
fonctions élémentaires réutilisables.
La session doit être préparée: choix des participants, logistique, agenda. L’équipe JAD2
est constituée sous la responsabilité du chef de projet utilisateur, qui s’assure d’un relais avec
l’équipe JAD1 . Si le taux de renouvellement de l’équipe est important (entre 30 et 50%), le
binôme chefs de projet organise une réunion d’initialisation, analogue à la session de la phase
de mobilisation, pour présenter les résultats de JAD1 à la nouvelle équipe. Dans tous les cas,
le binôme chefs de projet rencontre, soit individuellement, soit collectivement, les nouveaux
participants.
La logistique doit être organisée suffisamment tôt: date, lieu, salle, transports Les
informations sont envoyées aux participants. Le déroulement et le contenu de la session
doivent être préparés.
L’ordre suivant peut être recommandé :
Première partie : conception
1. La présentation du guidage fonctionnel (menu de l’application) est suivie d’une

discussion qui peut conduire à des évolutions. On termine par un point de consensus.
2. Les principes et normes qui ont guidé la conception des maquettes sont exposés.
3. Les maquettes sont soumises aux utilisateurs par procédure ou par objet de gestion.
Après discussion, on les fait évoluer en temps réel en recherchant le point de consensus.
4. Les fonctions batch sont décrites. Elles sont éventuellement discutées jusqu’à accord

Page 26
Le 31 mai 2000
Projet RAD
entre les utilisateurs.

Deuxième partie : planification
1. On détermine le scénario d’installation de l’application.

2. On arrête le nombre de time-box.
3. On convient du contenu de chaque time-box.
La session JAD2 s’effectue, comme les précédentes sessions, en résidentiel. Elle se

déroule sur un ou deux jours selon la taille et la complexité de l’application. Elle est
structurée en deux parties.
La première partie est consacrée à consolider, modifier, affiner la solution proposée. Dans
la mesure du possible, les modifications sont effectuées en séance, de façon à clore la session
avec des maquettes acceptées par tous.
Dans une deuxième partie, on doit planifier le développement de l’application, c’est-à-

dire l’étape Construction. Celle-ci est soumise à deux règles d’organisation. Elle doit
s’effectuer dans un délai volontairement réduit : le maximum se situe entre 90 et 120 jours
(durée de la time-box). La taille de l’équipe de prototypeurs ne doit pas dépasser trois ou
quatre personnes, afin de minimiser la charge de coordination.
En ce qui concerne le scénario d’installation de l’application, il y a trois options de mise

en service: en bloc, incrémentale et évolutive.
L’installation « en bloc » correspond au démarrage de toute l’application en une seule

fois. Lorsque le projet est trop important pour être réalisé dans le délai maximum (120 jours)
avec une équipe réduite, on le découpe en plusieurs sous-projets qui sont menés en parallèle.
L’installation « incrémentale » consiste à découper l’application en plusieurs parties, qui

sont installées successivement. On se base sur le découpage fonctionnel, pour planifier les
développements successifs. Chaque développement est soumis à la contrainte de la time-box.
L’installation « évolutive » limite le projet à l’installation d’une version initiale de

l’application. Des projets ultérieurs auront pour objectif de développer de nouvelles versions
de l’application. Il faut s’accorder sur les fonctions qui figureront dans la version initiale.
Le projet peut donc se poursuivre avec une ou plusieurs équipes de prototypeurs en

parallèle. Pour chaque sous-projet, on planifie le travail de l’équipe dans le délai imparti, la
time-box.

Page 27
Le 31 mai 2000
Projet RAD
Les travaux de conclusion de la phase JAD2 sont menés par le binôme chefs de projet et
l’expert RAD. Il s’agit de prendre en compte les conclusions de la session qui n’auraient pas
pu l’être immédiatement. Le dossier de conception du projet est mis à jour; on y intègre les
éléments de traçabilité entre la description logique et les prototypes, ainsi que le planning de
prototypage. Le dossier est alors présenté pour validation officielle au comité de pilotage du
projet, ou, à défaut, au propriétaire de l’application .
La phase JAD2 [HUG97]
L’étape Construction
L’objectif de l’étape Construction est de développer l’application dans un délai limité

avec la participation régulière des utilisateurs. Sa durée est celle de la time-box, trois à quatre
mois au maximum. Les cycles sont courts, entre deux et trois semaines. Le chef de projet
informatique est responsable de cette étape. A la fin de cette étape, on doit avoir l’application
sous la forme d’un prototype complet et validé.
L’équipe de prototypage connaît à ce stade la plus grande pression. Les utilisateurs

composant l’équipe de construction doivent impérativement participer à toutes les sessions de
validation/évolution, de même que le binôme chefs de projet. L’expert RAD participe souvent
aux premières sessions.
L’étape Construction commence dès que le comité de pilotage a donné son feu vert sur le
dossier de conception tel qu’il résulte de la phase JAD2. Cette étape comprend autant de
phases qu’il y a de cycles de prototypage.
On appelle cycle 1 : le premier cycle, cycle n: le dernier cycle et cycle(i) un cycle

Page 28
Le 31 mai 2000
Projet RAD
intermédiaire. Nous allons les passer en revue.

La phase du cycle 1
Cette phase a pour but de construire le premier prototype prévu dans le planning arrêté en
JAD2. Les techniques utilisées dans la phase du cycle 1 sont des techniques RAD
complémentaires : le prototypage et la réutilisation.
La répartition des activités du cycle se présente ainsi
• travaux de préparation : 2 semaines

• session: 0,5 jour
• conclusion : 4,5 jours
Les travaux de préparation, menés principalement par les prototypeurs, occupent la plus
grande partie de la phase. Le but est de développer le premier prototype et de préparer sa
présentation en session. Les maquettes élaborées à l’étape précédente (Conception),
éventuellement modifiées par la session JAD2, sont réutilisées.
La session se déroule, en général, sur une demi-journée. Le déroulement est le suivant.
Pour chaque fonction logique, le chef de projet informatique fait le rapprochement avec
les modèles organisationnels de traitements. Ensuite, il passe la parole au prototypeur qui
présente le prototype. Les utilisateurs commentent au fil de l’eau chacune des fonctions
logiques. Le chef de projet informatique prend en note les remarques qui sont faites au fur et à
mesure. En fin de présentation d’une fonction logique, il fait une synthèse des remarques et
demandes. Il s’assure ensuite de la faisabilité et de la charge auprès du prototypeur.
Certaines décisions d’évolution sont prises en fin de session. En effet, le respect de la

time-box doit être la préoccupation de tous.
En fin de session, le chef de projet informatique fait une proposition globale d’évolution
du prototype. En cas de désaccord avec l’équipe d’utilisateurs, sur une demande représentant
une fonction nouvelle, dont le développement risque d’excéder l’enveloppe de la time-box,
c’est le propriétaire ou le comité de pilotage qui fait l’arbitre. C’est un des prototypeurs qui
est chargé de l’écriture du compte rendu; celui-ci est distribué en fin de séance. Il se présente
généralement par fonction logique.
Les travaux de conclusion ont pour but de mettre à jour, le cas échéant, les référentiels
modèles, dictionnaire de données, dictionnaire de règles. Si un point est soumis à l’arbitrage

Page 29
Le 31 mai 2000
Projet RAD
du comité de pilotage, celui-ci doit rendre sa réponse dans les quatre jours qui suivent la
session.
La phase du cycle 1 [HUG97]
La phase du cycle (i)
La durée, la structure et le contenu sont semblables à ceux du cycle 1. L’équipe de

construction reste la même. Il y a cependant deux différences :
- Les travaux de préparation comprennent les évolutions du logiciel décidées lors de la
session précédente,
- La session commence par la présentation des évolutions décidé lors du cycle précédent.
La phase du cycle (i) [HUG97]

Page 30
Le 31 mai 2000
Projet RAD
La phase du cycle n
C’est le dernier cycle. Les travaux de préparation incluent l’intégration des différents
prototypes. Les éventuelles évolutions décidées en session sont faites dans les travaux de
conclusion. L’application complète est présentée au comité de pilotage ou au propriétaire pour
acceptation provisoire.
La phase du cycle (n) [HUG97]
L’étape de Mise en oeuvre
Il s’agit d’installer l’application et l’environnement nécessaire à son utilisation. S'il y a

plusieurs sites analogues, l’installation se fera sur un site pilote.
Dans le cas d’une mise en œuvre évolutive, le but fixé en début de projet est d’obtenir
rapidement une version utilisable, de la mettre en œuvre et, après une période d’exploitation,
de tirer la leçon des expériences faites pour développer une nouvelle version. L’application
évolue ainsi en une succession de versions améliorées, qui suivent l’évolution des besoins de
l’entreprise.
Les deux chefs de projet utilisateur et informatique se partagent les responsabilités selon
la nature des travaux à mener. La durée de l’étape de mise en œuvre varie selon le contexte du
projet. Le but de l’étape est de fournir une application optimisée dans un environnement prêt à
l’accueillir. Cette étape comprend une seule phase de mise en œuvre. Elle suit de près la fin de
l’étape Construction. La plupart des activités sont celles d’une mise en œuvre classique

Page 31
Le 31 mai 2000
Projet RAD
La phase de mise en œuvre
Les acteurs impliqués sont l’équipe de mise en œuvre, le binôme chefs de projet et
l’équipe de prototypage. La préparation comprend différents types de travaux qui peuvent être
menés en parallèle.
- Optimiser les structures de données. Eliminer les données non utilisées, prendre en
compte le volume, regrouper les tables de faible volume, optimiser les requêtes, traiter
l’épuration des fichiers (périodicité, procédures), et de prévoir les sauvegardes
nécessaires lors de l’exploitation.
- Préparer la documentation utilisateur. La plus grande part est constituée d’une aide
en ligne à ajouter au logiciel développé. Elle est testée par un ou plusieurs utilisateurs
de l’équipe de construction. Le manuel d’exploitation, qui indique les consignes
d’exploitation, est élaboré selon la façon habituelle à l’entreprise.
- Préparer la migration. Dans un projet classique, il est recommandé de commencer ces
travaux le plus tôt possible, dès l’achèvement de la conception. Dans un projet RAD,
l’étude de la reprise des fichiers existants ou le développement de transactions
permettant une saisie de masse commence en même temps que l’étape Construction. Si
la migration implique une reprise importante, il est préférable de la mener comme un
projet à part, si possible en RAD pour ne pas repousser l’installation de l’application.
- Former les utilisateurs. On connaît l’importance de cette action pour le succès de
l’application. Dans un projet RAD, il est judicieux de s’appuyer sur les utilisateurs qui
ont participé à la conception et à la construction de l’application.
- Planifier l’installation. Le chef de projet utilisateur est responsable de la coordination
des actions d’installation. Elles doivent être planifiées en liaison étroite avec les
utilisateurs concernés.
- Préparer la recette. La préparation s’effectue de façon classique.
La session correspond à la recette sur site.
Les travaux de conclusion correspondent à un bilan de projet.

Page 32
Le 31 mai 2000
Projet RAD
La phase de mise en œuvre [HUG97]
d. Outils et techniques RAD
Les outils
C’est dans le domaine des outils que le RAD semble avoir eu le plus de succès.
Pratiquement tous les grands éditeurs de logiciels fournissent aujourd’hui des outils incluant
la fonction RAD. Pour cette raison, la liste ci-après n’est pas exhaustive. Néanmoins, il est
important de savoir que l’offre est continuellement étoffée par l’arrivée de nouveaux outils et
fournisseurs. Il est également intéressant de noter que l’offre RAD s’étend à de nouveaux
langages de programmation (par exemple : Java) et à de nouvelles plate-formes (par exemple :
Linux).
Les outils RAD nouvelle génération remplacent ceux, plus anciens, de type
prototypage rapide ou application «trompe l’oeil» qui ne traitaient que les modèles
fonctionnels de l’interfaçage des applications et non les données.
Les nouveaux outils sont intuitifs et visuels. La visualisation rapide des fenêtres à partir du
code est possible. Ils offrent également la possibilité de développer la partie interface et
l’application finale sans changer d’outils. Certains outils L4G se rapprochent par leurs
fonctionnalités de ceux des AGL.

Page 33
Le 31 mai 2000
Projet RAD
Editeurs Outil Caractéristiques

Sybase PowerBuilder L4G; l’outil DataWindows
Reporting contient un générateur
d’application rapide
Microsoft Visual Basic 6 L4G pour solutions client-
serveur réparties; disponible sur
Windows 9x, NT; fait partie de
la gamme des outils visuels de
Microsoft
Inprise/Borland Delphi 5 L4G orienté objets. Kylix est le
C++ Builder 5 premier outil de développement
Jbuilder 3.5 rapide d’Inprise pour linux.
Kylix
Computer Associates CA-OpenRoad L4G orienté objets; disponible
pour Windows 9x, NT,
OSF/Motif, DEC Windows et
SUN OpenLook; fonctionne
avec les serveurs CA-
OpenIngres, Oracle, SQL Server
Informix NewEra 2.0 L4G orienté objets; disponible
sur Unix et Windows; supporte
des constructions structurées
classiques
Oracle Developer/2000 L4G; disponible sur Windows
9x, NT et Unix; approche RAD,
IE et BPR
Netway SQL-Surfer Outil middleware; accès aux
bases de données par le Web;
supporte DB2, Informix, Oracle,
Sybase, SQL Server
Cosytec Chip V5 Programmation par contraintes;
plusieurs références dans
l’industrie du transport
PC Soft WinDev 5.5 AGL; installé sur plus de
100000 sites en France
IBM Visual Age Environnement de
développement pour Java sous
Windows et Linux

Page 34
Le 31 mai 2000
Projet RAD
Les techniques RAD
Certaines techniques sont indissociables de l’approche RAD. Elles sont attachées à une
partie du cycle RAD. Leur mise en œuvre accompagne obligatoirement celle de l’étape
correspondante. Elles sont au nombre de quatre :
- Technique d’expression des besoins JRP : elle est utilisée dans la phase d’expression
des besoins.
- Technique de conception JAD :

- elle est utilisé dans la phase de conception,
- l’équipe JAD1 est responsable des choix de conception,
- l’équipe JAD2 valide la conception détaillée.
- Technique de contrôle des délais time-box : elle fixe la durée de la phase de

construction du système.
- Technique de pilotage RAD

- utilisation d’un tableau de bord,
- suivi des délais de chaque étape et de la participation des utilisateurs.
La technique JRP
JRP signifie Joint Requirement Planning, soit définition participative des besoins. C’est
une technique proposée dans les années 80 par IBM, qui l’a notamment utilisée pour ses
propres besoins. IBM, dans sa description, présente la technique JRP de façon liée à la
technique JAD [IBM84]. Par contre, la méthode RAD distingue bien les deux techniques JRP
et JAD, mises en œuvre dans deux étapes différentes : expression des besoins et conception.
La technique JRP, utilisée par la méthode Rad, a pour objectif de donner un rôle actif à
l’utilisateur lors de l’étape expression des besoins, afin de réduire la durée de cette étape et
d’en augmenter la qualité. Les utilisateurs jouent alors le rôle central et, durant cette période,
leur rythme de travail sur le projet est rapide. Ils effectuent la collecte des informations
nécessaires à l’expression des besoins ; ensuite, réunis en session avec les informaticiens, ils
présentent leurs résultats qui sont confrontés, amendés, acceptés, pendant une période de
temps courte mais dense.

Page 35
Le 31 mai 2000
Projet RAD
La technique JAD
JAD signifie Joint Application Design, soit conception participative d’application.

L’objectif de JAD est d’augmenter la qualité de la conception. Celle-ci peut être évaluée selon
deux points de vue : la qualité du processus ou celle du résultat. JAD vise à obtenir un résultat
efficace et à rendre le processus efficient.
Un système d’information est dit efficace s’il améliore le fonctionnement de

l’entreprise. La technique JAD permet de concilier innovation et rigueur. On reproche parfois
à certains projets d’être restés proches du fonctionnement existant, d’avoir principalement
automatisé ce qui pouvait l’être. JAD favorise l’expression créative des utilisateurs. On leur
propose une ébauche de système d’information, qu’ils doivent façonner. Au cours de ce
travail de conception progressive, ils peuvent se représenter des possibilités de changement
dans la gestion et l’organisation du travail, cette ouverture contribue à la conception d’une
application qui soutient l’entreprise dans l’atteinte de ses objectifs. L’expression créative
s’accompagne de descriptions rigoureuses, grâce à l’utilisation d’un atelier de génie logiciel.
Les représentations obtenues sont stockées sous une forme directement utilisable à
l’étape suivante (modèles, structures de données, descriptions d’écrans...).
On dit que le processus est efficient si l’on a utilisé au mieux les moyens alloués au
projet. Plusieurs raisons expliquent que la technique JAD améliore l’efficience du projet. Tout
d’abord le délai de conception est réduit: les utilisateurs sont sollicités pendant une période
courte, mais intense, au terme de laquelle ils voient des résultats concrets. Ensuite, JAD
diminue les frottements provenant de points de vue divergents. Le travail simultané avec tous
les représentants évite des allers-retours entre concepteurs et utilisateurs divers. Par ailleurs,
les éventuels conflits trouvent plus facilement une issue, dans la mesure où la responsabilité
d’aboutir à une solution est partagée par tous les participants.
Enfin, JAD évite de produire une documentation sur papier, volumineuse et figée: les
résultats se présentent sous une forme qui permet leur utilisation immédiate et leur évolution.
On retrouve dans JAD des caractéristiques de la technique JRP :

- La participation des utilisateurs est au coeur de la technique: c’est de leur engagement
que naît une conception efficace.
- Le travail s’effectue en session, sur un ou plusieurs jours à temps complet.
- La session est planifiée de façon rigoureuse.
- La session est animée par une personne neutre par rapport aux enjeux de la conception.
- Le langage utilisé est celui du domaine, et non celui des technologies.
- Le travail s’appuie sur des outils automatisés.

Page 36
Le 31 mai 2000
Projet RAD
La technique de contrôle des délais : time-box
Le principe de la technique time-box est d’établir une enveloppe temps, de durée fixe et
limitée, qui ne doit être dépassée sous aucun prétexte. Les anglo-saxons utilisent le terme
deadline. Il arrive que des applications soient dans un état « presque terminée » pendant
plusieurs mois. Le but de la time-box est d’éviter ces glissements dont on ne maîtrise pas
l’ampleur.
La time-box peut être considérée comme un garde-fou dans le cas de développement par
prototypage. En effet, la relative facilité de développement conduit aussi bien utilisateurs
qu’informaticiens à ajouter sans arrêt de nouvelles fonctions, inspirées par la dernière version
du prototype. On perd ainsi le contrôle du développement. Au lieu de converger vers une
version stabilisée, on modifie sans cesse une application qui n’est jamais exploitable et dont
l’objectif est de plus en plus ambitieux. Les anglo-saxons parlent de «fonctionnalités
grimpantes », (creeping functionality).
L’idée de la time-box n’est pas d’éliminer la créativité, mais de la contenir dans des
limites compatibles avec la production d’un résultat.
La time-box est utilisée à l’étape Construction. L’enveloppe temps allouée est en

général comprise entre 60 et 120 jours. Le nombre de cycles varie entre trois et neuf, la durée
d’un cycle étant de l’ordre de deux à trois semaines. L’enveloppe temps peut être réduite, si le
projet est de faible ampleur. A l’inverse, certains systèmes sont trop importants pour pouvoir
être contenus, même en réduisant les fonctionnalités, dans une seule time-box. On les découpe
alors en sous-systèmes, quasi indépendants, qui sont chacun développés dans une time-box,
simultanément ou successivement. Le découpage en cycles de chaque time-box doit être
établi.
La technique de pilotage RAD
Tout projet doit être piloté, c’est-à-dire doté de moyens permettant de maîtriser son
déroulement et de guider son évolution vers l’objectif. En effet, il y a toujours une part
d’incertitude et d’aléas, les choses ne se passant jamais exactement comme prévu.
Dans un projet RAD, les engagements contractuels sont impératifs sans que l’on dispose
d’une marge confortable permettant de faire face aux incidents de parcours.
La technique de pilotage RAD est un ensemble de règles et de principes. Si l’univers

dans lequel se déroule le projet rend impossible la mise en oeuvre de ces règles et principes,
alors le projet ne peut plus être mené en RAD.

Page 37
Le 31 mai 2000
Projet RAD
Le pilotage RAD fonctionne de la façon suivante :

- le binôme chefs de projet, assisté par l’expert RAD, occupe la fonction de pilotage.
- les règles de base correspondent à ce que l’on appelle parfois le label RAD. Pour qu’un
projet puisse être labellisé RAD, il doit respecter de façon absolue les délais de chaque
étape, et la participation des utilisateurs, mise en œuvre à travers les techniques JAD,
JRP et les sessions de prototypage. Si ces deux conditions ne sont pas satisfaites tout au
long du projet, alors on ne peut plus considérer que le projet est mené en RAD.
e. Avantages et inconvénients de la méthode
Pour l’utilisateur :
Avantages
- L’utilisateur n’est plus le parent pauvre du projet informatique, mais il est placé au
premier rang. Il est partie intégrante de l’équipe de projet et participe à tous les stades
de l’élaboration du système. Il définit les besoins, les complète et les affine au fur et à
mesure de l’avancement du projet, et c’est lui qui décide si des modifications sont à
apporter au système.
- L’utilisateur est comptable du résultat final.
- L’utilisateur connaît mieux son système, car sa formation se fait en parallèle au
processus de développement auquel il participe.
- L’utilisateur peut travailler rapidement avec une partie du système. Ce système est
limité dans ses fonctions, mais est néanmoins doté des fonctions majeures.
- L’utilisateur reçoit dans un intervalle court et régulier (trois à six mois) les versions
complémentaires.
Inconvénients
- La classification des besoins par priorité et le choix entre délais et fonctionnalités n’est
pas toujours facile à faire. Elles impliquent de l’utilisateur un pouvoir de décision et
l’acceptation de compromis.
- L’implication dans un projet RAD nécessite de l’utilisateur une motivation forte et un
investissement personnel supplémentaire.
- La livraison d’une version allégée du système peut entraîner frustration et
insatisfaction chez l’utilisateur.
- Une application inachevée risque de le rester faute de nouvelles ressources (hommes,
argent, temps).

Page 38
Le 31 mai 2000
Projet RAD
Pour l’informaticien
Avantages
- L’informaticien-développeur est plus sûr du résultat final, car il l’aura réalisé avec son
client.
- L’implémentation du système lui est facilitée, car les prototypes sont testés tout au
long du cycle de développement.
- L’informaticien voit plus vite le fruit de son travail.
- L’informaticien s’enrichit par le contact permanent qu’il a avec son client et apprend à
mieux connaître le métier de ce dernier.
Inconvénients
- L’informaticien doit faire preuve de discipline dans la maîtrise du prototypage. Les

besoins prioritaires doivent être traités en premier, sinon les objectifs et les délais ne
pourront être atteints.
- L’informaticien doit accepter de passer du rôle de décideur à celui de conseiller.
Pour l’organisation
Avantages
- L’organisation dispose de systèmes et d’applications de bonne qualité tout en

maîtrisant les coûts et les délais.
- L’organisation dispose enfin de systèmes et d’applications qui répondent à ses
objectifs commerciaux.
- L’organisation dispose surtout de personnel mieux formé grâce à l’enrichissement que
procure le travail en commun.
- La communication entre gens de métiers différents est renforcée ce qui peut favoriser
un changement de culture d’entreprise.
- Les risques de projets sans fin et de gouffres financiers sont minimisés.

Page 39
Le 31 mai 2000
Projet RAD
Inconvénients
- Une documentation inexistante ou partielle peut compromettre la maintenance et

l’évolution future du système.
- Pour mettre en oeuvre le RAD et espérer des gains de productivité, un investissement
de départ important est nécessaire. Le personnel doit être formé et disposer de
matériels et d’outils performants.
- L’organisation doit disposer d’un cadre méthodologique adapté au RAD, faute de
quoi, du travail vite fait peut résulter un système mal fait.
- Le personnel des services opérationnels de l’organisation est impliqué dans les
projets RAD pour des périodes plus longues.

Page 40
Le 31 mai 2000
Projet RAD
DSDM : UNE AUTRE METHODE DE DEVELOPPEMENT RAPIDE

Avant d’être une méthode, DSDM (Dynamic System Development Method) est une
organisation à but non lucratif qui offre des conseils pour l'introduction du développement
rapide d'applications au sein d'une organisation. De plus, elle s'efforce de retransmettre les
connaissances de ces membres et de recycler les expériences pratiques de la méthode, surtout
en ce qui concerne l'estimation et la maintenance de systèmes construits avec la méthode.
La méthode DSDM représente la synthèse de l'expérience d'un nombre important de

fournisseurs et d'utilisateurs. Elle offre un canevas pour la réalisation et l'entretien de
systèmes informatiques de gestion par l'emploi d'une démarche de prototypage. La méthode
s'adresse à toutes les parties prenantes du système, aussi bien les utilisateurs, que les
responsables de projet, les responsables de la qualité et les réalisateurs.
Un principe fondamental de l'approche dynamique est le fait que rien n'est construit
parfaitement du premier coup, mais que 80% de la solution est réalisable en 20% du temps
qu'il prendra pour une solution complète.
a. Pourquoi cette méthode est-elle apparue ?
Dans la méthode dynamique le droit de revenir sur les étapes précédentes fait partie de
la démarche itérative. Par conséquent, l’étape en cours ne doit pas avancer au-delà du point
nécessaire pour démarrer l’étape suivante, car on peut y revenir dans une prochaine itération.
Le principe est que les besoins auront probablement évolué de toute façon, et donc des
dépenses supplémentaires auront été gaspillées.
Des applications réalisées selon la méthode dynamique visent les besoins actuels de
l’organisation. Or, l’approche traditionnelle a souvent tendance à préconiser une solution pour
toutes les possibilités.
Projet Système d’information DSDM : une autre méthode

Page 41 de développement rapide
Le 31 mai 2000
Projet RAD
b. Méthodologie de la DSDM
La DSDM couvre toutes les étapes de la réalisation d'un système informatique pour un
projet informatique qui doit être réalisé rapidement. La plupart des méthodes informatiques
n'adressent qu'une seule activité telle que l'analyse et la conception, ou le pilotage de projet.
La méthode dynamique prend en compte le cycle de vie entier d'un système informatique avec
les outils et les contrôles nécessaires pour assurer son succès.
Le cycle de vie de la réalisation basé sur une démarche de prototypage itérative et

incrémentale est associé avec les fournitures issues des activités de gestion et de suivi
technique. La méthode dynamique spécifie des catégories de prototypes et leur application la
plus efficace durant le projet.
Voici les grandes lignes du cycle de vie DSDM, décrit par le consortium DSDM. Il se
décompose en cinq phases comme on peut le voir sur le schéma ci-dessous :
• Etude de faisabilité (Feasability Study)

• Etude d’affaire (Business Study)
• Modèle d’itération fonctionnelle (Functionnal Model Itération)
• Itération de conception et de construction (Design and build iteration)
• Mise en place (Implementation)

Le 31 mai 2000
Projet RAD
Etude de faisabilité
Elle permet d’évaluer si l'approche RAD convient au projet et vérifie que certaines
conditions techniques et gestionnaires sont susceptibles d'être réunies.
L’étude de faisabilité peut durer quelques mois.
Etude d'affaires
Elle porte sur l'activité globale du projet et fournit une base technique pour tous les
travaux futurs. L'architecture du système est tracée dans les grandes lignes et les objectifs
d'entretien font l'objet d'un accord.
Comme pour l’étude de faisabilité, l'étude d'affaires est une phase courte, qui ne
dépasse pas un mois.
Modèle d’itération fonctionnelle
La majeure partie du travail de développement se trouve dans les deux phases

d'itération où des prototypes sont incrémentalement établis vers le système testé qui est placé
dans l'environnement utilisateur pendant la phase de mise en place. Tous les prototypes dans
DSDM sont destinés à être transformer pour devenir le système final et sont donc établis pour
être assez robustes pour l'usage opérationnel et pour répondre à toutes les exigences non
fonctionnelles appropriées, telles que l'exécution.
Itération de conception et de construction
Le but de cette phase est de s'assurer que les prototypes sont suffisamment bien
élaborés pour être utilisés dans l'environnement opérationnel.
Mise en place
Dans la mise en place, il s’agit de mettre le dernier incrément dans l'environnement

opérationnel et de former les utilisateurs. L'étape finale dans la mise en place est l’examen de
ce qui a été réalisé.
[dsdm.org]
La méthode dynamique contient une description des activités de management de projet

nécessaire pour maîtriser l'évolution rapide d'un système. Le principe du « timeboxing » est
l'une de ces approches, mais il en existe d'autres selon l'activité. Par exemple, la structure et

Le 31 mai 2000
Projet RAD
les rôles au sein de l'équipe doivent être adaptés à la démarche. Les équipes qui respectent la
méthode dynamique doivent recevoir des objectifs clairs et réalisables dans un « timebox ».
Toutes les fournitures sont associées à des critères de qualité pour s'assurer que les objectifs
seront atteints.
Les structures des équipes comprennent plusieurs rôles pour les utilisateurs. On attend
que certains utilisateurs s'intègrent dans l'équipe de développement afin de prendre des
décisions journalières de manière plus rapide et plus efficace. D'autres utilisateurs assument
les rôles de clients externes plus traditionnels. L'apport efficace du temps et de connaissances
de la part des utilisateurs est un des éléments clés de la méthode dynamique.
La méthode dynamique détaille l'approche préconisée pour la gestion de la

configuration technique. La gestion de la configuration est importante pour maîtriser l'état de
produits très évolutifs dans un projet conçu avec la méthode dynamique. Une approche
adaptée pour les tests et le contrôle de la qualité est aussi élaborée.
On ne retrouve pas dans la DSDM un mandat pour ce qui concerne les techniques
d'analyse, de conception et de programmation. En revanche, les techniques de l'analyse et de
la conception structurées, et l'analyse orientée objets sont dessinées. Il est vrai que certaines
organisations peuvent préférer utiliser leurs techniques habituelles dans le mesure du possible.
De telles techniques peuvent être évaluées par rapport aux spécificités de la méthode
dynamique à l'aide des critères spécifiés dans le guide DSDM.
La DSDM décrit également les conditions de développement idéal avec une « check-
list » pour aider une organisation dans l'évaluation et la spécification d'un tel environnement.
Parmi d'autres aspects traités en détail dans la méthode dynamique se trouvent :

- l'estimation des coûts et des durées,
- des paramètres pour évaluer le succès des projets,
- des recommandations pour la conduite de la sous-traitance.

Le 31 mai 2000
Projet RAD
LE RAD FACE AUX AUTRES METHODES PLUS CLASSIQUES

Parmi les autres méthodes, nous verrons d’abord la méthode Merise qui est la plus
utilisée par les entreprises françaises. Ensuite la méthode SSADM, très utilisée outre manche.
Enfin nous aborderons brièvement également les méthodes dite « objet ».
a. Méthode Merise
Préambule
Merise est né de la volonté du ministère de l'industrie française de créer en association

avec les sociétés de service une méthode d'analyse et de conception de systèmes
d'informations. Cette méthode à été définie à la fin des années 70.
De nombreuses sociétés de service, en France, utilisent encore cette méthode. Elle est
enseignée aux étudiants des universités d'informatique de gestion. Ce qui explique sans doute
son fort déploiement.
Principes
La méthode est orientée autour de trois niveaux, dit d'abstraction :

- le niveau conceptuel : préoccupations de gestion ( réponse à la question « quoi ? » )
- le niveau organisationnel : préoccupations d'organisation ( réponse au question « qui
? », «quand ? », « ou ? » )
- le niveau physique : préoccupations techniques ( réponse à la question « comment ? » )
Merise distingue les aspects statiques du système (données) et les aspects dynamiques
(traitements). Cette distinction permet une meilleure adaptation du système d'informations
lors de l'évolution des besoins. Les trois niveaux d'abstraction vu précédemment peuvent ainsi
se représenter comme suit:
Niveaux Modèles
Données Traitements
Conceptuel Conceptuel MCD Conceptuel MCT
Organisationnel Logique MLD Organisationnel MOT
Physique Physique MPD Opérationnel MPT
Projet Système d’information Le RAD face aux autres

Page 45 méthodes plus classiques
Le 31 mai 2000
Projet RAD
Description des niveaux
Niveau conceptuel ( « quoi ? »)
D'après [MET90], « Le Niveau conceptuel des données sert à décrire et structurer les
informations mémorisées dans l'entreprise en faisant abstraction de toute décision
d'automatisation ou de répartition ( sites, supports... ) ». Il utilise un formalisme de type
entité-relation. Le modèle conceptuel des données (MCD) se compose d'entités, repérées par
un identifiant unique. Chaque entité possède un certain nombre de propriétés.
Les entités sont reliées par des relations. Une relation peut relier deux ou plusieurs
entités. Des cardinalités sont associées aux relations. Elles sont définies selon trois états (
0,1,n ) le nombre d'occurrence ( minimum et maximum ) pouvant exister pour une occurrence
de l'entité.
Le modèle conceptuel des traitements ( MCT ) représente la dynamique du système.
La description fait abstraction de l'organisation. Elle utilise des notions :
- d'événements
- d'opérations ( actions )
- de synchronisation ( conditions de démarrage de l'opération )
A ce niveau du modèle, l'ensemble des traitements peuvent s'assimiler à des règles de gestion.
Niveau organisationnel ( « qui ?», « quand ?», « où ?» )
D’après [MET90], « Le modèle Organisationnel des Traitements ( MOT ) fournit une

description de qui fait quoi, quand et où ». Le MOT ne se soucie pas de l’environnement
matériel et logiciel utilisé.
On s’occupe ici de savoir quel est le degré d’automatisation ( manuel, automatique )
de nos opérations, ainsi que le délai de réponse ( différé ou immédiat ).
Le formalisme est le même que le MCT, seuls les niveaux de détails et de
préoccupations ont changé.
Le modèle logique des données ( MLD ) fait suite au MCD vu précédemment. Le

MLD est une représentation de la structure qui sera ensuite créée dans la base de données.
Des règles de transposition permettent très facilement de passer du MCD au MLD.
Pour cela ont utilisera soit le modèle réseau ( type CODASYL ), soit le modèle relationnel.

Le 31 mai 2000
Projet RAD
Niveau physique (« comment ? »)
Ce niveau représente de manière concrète la description du système d’information tel

qu’il sera définit lors de son implantation dans une base de données.
Le modèle physique des traitements ( MPT ) est le squelette des futurs programmes.
Il poursuit le travaille déjà effectué sur le MOT. Ce modèle tient compte des contraintes du
logiciel et du matériel utilisé.
Le modèle physique des données ( MPD ) est la continuité du MLD. Il tient compte
des particularités du SGBD utilisé.
Avis
Aujourd’hui Merise est une méthode très critiqué. Toutefois c’est encore la méthode la
plus utilisé en France. D’après Vickoff [VIC96], « La méthode Merise, structurante et lourde,
fait face à des formes de développement qui lui sont incompatibles en termes de rentabilité ».
Parmi les reproches des spécialistes, on retiendra que Merise permet difficilement de tenir les
délais. L’implication des utilisateurs est trop faible, d’où un décalage entre leurs besoins et les
réalisations. Faute de produit fini satisfaisant, il est nécessaire de reprendre les
développements et les analyses.
Néanmoins, quelques évolutions ont vu le jour, notamment un Merise orienté objet.
b. Méthode SSADM
Préambule
Abbréviation pour designer Structured Systems Analysis and Design Method. Il

s’agit d’une méthode fondée au Royaume-Uni, au début des années 80, dans le but
d’uniformiser le développement des systèmes d’informations.
Elle a été approuvé dans de nombreux projets, au Royaume-Uni.
Principe
Sans rentrer dans les détails, SSADM fournit trois vues différentes pour représenter les
données du système, leurs fonctions, leurs structures et leurs transformations dans temps.

Le 31 mai 2000
Projet RAD
- le diagramme des flux de données ( Data Flow Diagram – DFD ) offre une vue des
fonctions de gestion et des données sans indication de temps.
- la structure logique des données ( Logical Data Structure – LDS ) détermine à quel
moment chaque donnée est créée et modifiée dans le système. Pour s’assurer de la présence
des données lors de l’exécution d’une fonction, un lien est créé entre le DFD et la LDS.
- l’historique de vie des entités ( Entity Life History – ELH ) permet de voir si les
événements de gestion ont été compris et si toutes les règles de gestion ont été modélisées.
Toutes les données et fonctions non encore répertoriées sont repérées à ce moment là.
D’une manière général, SSADM est orienté dans un dialogue utilisateur-informaticien.

Cela permet entre autre de répondre au mieux au cahier des charges. Les utilisateurs
intervienne ainsi à diverses étapes du projet.
Avis
Nous n’avons pas approfondi notre étude sur SSADM. Toutefois ont peux faire
certaines analogies avec Merise.
Dans son utilisation, la méthode SSADM est trop lourde et complexe pour pouvoir
s’appliquer à des petits projets. Elle est plutôt réservée aux projets orienté sur du long terme.
De même les coûts seront plus important avec cette méthode.
Néanmoins SSADM assure une méthode de travail standardisée, et une implantation

non négligeable outre manche.
c. Méthodes objets
Ces méthodes sont nées d’une évolution dans les mentalités. Il est nul besoin ici
d’exposer tel ou tel méthode objet. En effet de nombreuses méthodes ont évolué vers l’objet (
Merise, SSADM ) ou ont tout simplement existé directement sous leur forme objet ( UML ).
Ces méthodes accompagnent le développement avec des langages styles C++, ou plus
récemment, Java. Elles permettent une réutilisation des objets créés, d’où un gain de
productivité.

Le 31 mai 2000
Projet RAD
CAS PRATIQUE
Afin de mieux comprendre la démarche RAD, nous avons détailler l’ensemble des
travaux à effectuer au cours des différentes étapes, en nous appuyant sur un cas concret.
a. Présentation
L’association « Jeux pour Tous » sollicite notre aide pour concevoir un outil informatique lui
permettant :
- de mieux connaître ses membres,
- d’organiser des rencontres entre joueurs,
- de répertorier les différents jeux que l’association possède.
Organisation de l’association
L’association est constituée d’environ 150 personnes payant une cotisation annuelle de
100 Frs.
L’association est gérée par un comité choisi parmi les adhérents et composé :
- d’un président,
- d’un trésorier,
- d’une secrétaire.
Inscription d’un nouvel adhérent
Lors de sa 1ère inscription, le nouvel adhérent remplit un formulaire numéroté (ce numéro
constitue le numéro d’adhérent) sur lequel sont portées les informations : nom, prénom, sexe,
adresse, date d’adhésion, profession. Cette dernière information permet, en cas de besoin, de
faire appel à des personnes compétentes pour aider l’association (plombier, électriciens,
informaticiens, comptables,…).
Acquisition d’un nouveau jeu
Occasionnellement l’association acquiert de nouveaux jeux. Ils sont référencés par la

secrétaire. On leur attribue un numéro et un nom. En cas de détérioration du jeu, celui-ci n’est
plus disponible.
Projet Système d’information Cas Pratique

Page 49
Le 31 mai 2000
Projet RAD
Gestion des joueurs
L’association possède un local dans lequel se trouve 10 tables. Chaque table peut
accueillir au maximum 6 joueurs. L’adhérent a la possibilité de réserver une table pour une
demi-journée. Il doit préciser le nombre des joueurs, leurs noms ainsi que le jeu qu’ils
désirent pratiquer. Il doit préciser si c’est un jeu personnel ou bien un jeu appartenant à
l’association. Dans ce dernier cas, il est tenu de le réserver.
Chaque jour de jeu la secrétaire édite le planning des réservations.
b. L’étape d’initialisation
Cette étape permet de déterminer les ressources humaines et informationnels nécessaires

au bon déroulement du projet.
Au cours de cette étape un certain nombre de documents doivent être fournis :

- la grille de description du projet
- la grille de synthèse du projet
- le compte rendu de la session de lancement
- le dossier d’initialisation.
GRILLE DE DESCRIPTION DU PROJET

Projet : Initialisation Date:
« Jeux Pour Tous » Diagnostic 24/11/99
CPU : DUPONT André CPI : MEYER Marc EXPERT RAD : HENRI Michèle
1- Domaine :
Gestion d'une association de jeux sur table
2- Objectifs :
Mieux connaître ses adhérents
Organiser des rencontres entre joueurs
Répertorier les différents jeux appartenant à l'association
3- Position par rapport au schéma directeur :

Suite à une subvention de la mairie, un budget de 100 Kf a été débloqué.
4- Enjeu du projet:
Rendre la gestion des joueurs et des jeux plus conviviale.
5- Domaines connexes :
Comptabilité
6- Utilisateurs :

Page 50
Le 31 mai 2000
Projet RAD
Thème Nom Disponibilité Motivation

Planning rencontres Marie MARELLE + ++
Planning rencontres Nicolle RADO + +
Achats jeux Albert BICHON = +
Adhérents Daniel MARTRE + -
7- Date de mise en œuvre

Début avril 2000
8- Motivation sur l'emploi du RAD

Projet à réaliser en 4 mois
Plusieurs vues utilisateurs à fédérer.

Page 51
Le 31 mai 2000
Projet RAD
Dossier d’initialisation
Sommaire :
Préambule
Description du projet
Organisation du projet
Engagement des différents acteurs
Préambule
Dans un souci de rapidité, d’organisation et de convivialité, l’association « Jeux Pour

Tous » a voulu informatiser sa gestion de jeux et joueurs. Après diagnostic, Mme HENRI
Michèle a donné son accord pour le label RAD.
Description du projet
1. Présentation du problème et objectifs
- amélioration de la gestion actuelle

- amélioration de la qualité de services
- maîtriser la gestion des jeux
- édition du planning des joueurs
2. Description du domaine à couvrir
- inscription d’un nouvel adhérent : saisies des informations concernant les nouveaux
adhérents
- acquisition d’un nouveau jeu : choix du jeu et saisie des infos
- gestion des réservations : vérification des disponibilités, édition d’un planning des
réservations
Aujourd’hui tous ces travaux sont manuels.

Page 52
Le 31 mai 2000
Projet RAD
Organisation du projet
1. Les participants
Propriétaire : Albert BICHON (Président de l’association)
Comité de pilotage :
Président : Albert BICHON (Président de l’association)
Membres :
Daniel Martre (Trésorier de l’association)
Marie Marelle (Secrétaire)
Nicole Rado (Secrétaire)
Utilisateurs JRP:
Marie Marelle (Secrétaire)
Chefs de projet :
Messieurs Dupont André et Meyer Marc
Expert RAD :
Madame Henri Michèle
2. Planning du projet
nov 99 déc 99 jan 00 fév 00 mar 00 avr 00

22 29 6 13 20 27 3 10 17 24 21 7 14 21 28 6 13 20 27 3 10
27 3 10 17 24 31 7 14 21 28 4 11 18 25 3 10 17 24 31 7 14
*1
*2
*3 *4
*5 *6 *7
*1 : session de lancement : 27/11/99

*2 : session JRP : 2/12/99
*3 : session JAD1 :3 et 4/01/00
*4 : session JAD2 :11/01/00
*5 : session de présentation 1 : 24/01/00

Page 53
Le 31 mai 2000
Projet RAD
3. Résultats attendus à la fin de chaque étapes :
Etape initialisation
- dossier d’initialisation
Etape expression des besoins

- dossier d’expression des besoins :
- description de l’existant
- description des besoins
- dictionnaire des données,
- dictionnaire des règles de gestion
- modèle conceptuel des flux
Etape conception
- dossier de conception générale,
- MCD, MCF, MOTA, MOD, MLD,…
- Maquettes, description du noyau applicatif, des fonctions batch.
Etape construction
- prototypes et dossiers mis à jour.
Etape mise en œuvre

- applicatif recetté,
- mise en œuvre de l’applicatif.
4. Modalités de suivi du projet :
Le suivi est réalisé en continu par les chefs de projet.

Au niveau du pilotage une fiche de suivi « flash » sera réalisée chaque mois et présentée au
propriétaire de l’application par les chefs de projet. Cette fiche sera transmise au comité de
pilotage.
Engagement des différents acteurs
Le président, Monsieur Albert BICHON, approuve l’utilisation du RAD. Il s’engage à

prendre les décisions concernant le projet et à aplanir les obstacles administratifs.

Page 54
Le 31 mai 2000
Projet RAD
Le comité de pilotage s’engage à effectuer les validations de fin d’étape et à prendre les
décisions qui n’ont pu être prises par le groupe de travail.
Le groupe utilisateurs s’engage à fournir le travail dans les délais prévus.
Les chefs de projet s’engagent à agir en étroite concertation. Le chef de projet utilisateur
sera plus particulièrement responsable de la coordination des travaux des utilisateurs, le chef
de projet informatique sera responsable de la coordination des travaux des informaticiens.
Compte rendu de la session de lancement
La session de lancement du projet « Jeux Pour Tous » s’est déroulée le 27/11/99 de 16h à 18h.
Etaient présents :
Mesdames, Marie Marelle (Secrétaire)
Henri Michèle (Expert RAD)
Messieurs, Albert BICHON (Président de l’association)
Dupont André (CPU)
Meyer Marc (CPI)
L’ordre du jour proposé était :

Point 1 : présentation du projet
Point 2 : présentation de la méthode
Point 3 : préparation de la session JRP
Point 4 : questions diverses
Point 5 : relevé de décisions
Le dossier d’initialisation dans sa première version a été remis à chaque participant en début
de session.
Point 1 : présentation du sujet

Albert BICHON a présidé la présentation. Les deux secrétaires soulignent le fait qu’elles
n’arriveront pas à prendre en charges tous les thèmes. De même, étant à mi-temps, elles
insistent pour avoir les mêmes horaires pendant la période d’expression des besoins.

Page 55
Le 31 mai 2000
Projet RAD
Point 2 : présentation de la méthode

Cette présentation a été faite par notre expert RAD, Henri Michèle. Les utilisateurs se
félicitent du choix de cette méthode. Seulement ils s’inquiètent sur la formation à ce nouvel
outil. Dupond André désire étendre la formation à tout le personnel. Sur ce point, Daniel
Martre indique qu’il n’a pas beaucoup d’argent à dépenser pour la formation.
Point 3 : préparation de la session JRP

Monsieur Dupont André propose que la session JRP se déroule les 2 et 3 décembre 1999.
L’ensemble des participants accepte cette date.
Point 4 : questions diverses

Monsieur BICHON s’interroge sur le matériel nécessaire à cette mise en place. Mesdames
Marelle et Rado s’interroge sur le déroulement de la migration des données existantes vers le
nouveau système.
Point 5 : relevé de décisions

Les acteurs/utilisateurs auront chacun à charge un thème.
C’est Meyer Marc, le CPI qui assurera lui mêmes les formations.
c. Expression des besoins
L’étape Expression des besoins est divisée en 3 thèmes : les adhérents, les jeux et les
réservations. Pour chacun d’entre eux, on a effectuée une description de l’existant.
Description de l’existant du thème « Adhérents »
Sommaire :
Diagramme de contexte
Organisation
Annexes

Page 56
Le 31 mai 2000
Projet RAD
Diagramme de Contexte :
Carte de membre
ADHERENT
ADHERENT Réinscription
Demande
Nouvel adhérent enregistré d’inscription
BUREAU
D’INSCRIPTION
Dossier d’inscription
Dossier d’inscription remplit + Cotisation
COMPTABILITE Cotisation
Volumétrie mensuelle :
- 2 nouvelles inscriptions
- 12 réinscriptions
- 2 nouvelles créations de carte de membre
- 12 mises à jour de cartes de membre
Organigramme :
Traitement Demande de dossier d’inscription : après avoir reçu une demande de dossier
d’inscription, la secrétaire fournit toujours un formulaire numéroté à remplir par le
demandeur.
Traitement Inscription : deux modes d’inscription sont possibles :

- soit c’est la première inscription. Dans ce cas là le formulaire doit être dument rempli et
accompagné de la cotisation de 100 Frs ( en chèque ou liquide).
- Soit c’est une réinscription et seule la cotisation est nécessaire.
Une nouvelle carte de membre est remise.

La cotisation est comptabilisé au niveau de la comptabilité de l’association par le trésorier.

Page 57
Le 31 mai 2000
Projet RAD
ADHERENT RESPONSABLE INSCRIPTION COMPTABILITE
Demande
dossier d'
inscription
TRAITEMENT DEMANDE INSCRIPTION
Remise du
formulaire
Formulaire et
Cotisation
OU
INSCRIPTION
Réinscrption et
cotisation
Comptabilisation
inscription
Carte de
membre
Annexes :
Document 1 : Formulaire d’inscription d’un nouvel adhérent

Page 58
Le 31 mai 2000
Projet RAD

Page 59
Le 31 mai 2000
Projet RAD
Description de l’existant du thème « Jeux »
Sommaire :
Organisation
Annexes
Nouveau jeu JEUX

Réponse : refus ou acceptation
ADHERENTS
Proposent des jeux CHOIX JEUX
Paiement jeu COMPTABILITE
- 5 jeux proposés
- 3 jeux refusés
- 2 jeux achetés
Organisation :
Traitement Choix Jeu : les adhérents proposent au travers d’une « boîte à idées » les
jeux qu’ils désirent voir acquérir par l’association.
Un petit comité composé du président, des secrétaires ainsi que du trésorier se

réunissent tous les mois et analysent les propositions. Toute décision est affichée au sein de
l’association dans le compte rendu de réunion, permettant ainsi aux adhérents de suivre
l’évolution de leur proposition.

Page 60
Le 31 mai 2000
Projet RAD
ADHERENT COMITE CHOIX JEU COMPTABILITE
Proposition
de jeu
TRAITEMENT CHOIX JEU
Achat refusé Achat accepté
Décision
Comptabilisation
achat jeu
Achat
du jeu
Dans le cas d’une décision d’un achat de jeu positive, on en réfère au trésorier qui sera
chargé de débloquer les fonds nécessaires.
Annexes :
Document 1 : Fiche de description d’un jeu

Page 61
Le 31 mai 2000
Projet RAD
Description de l’existant du thème « Planning »
Sommaire :
Organisation
Annexes

Page 62
Le 31 mai 2000
Projet RAD
Réservation JEUX
Réponse : Refus ou acceptation
ADHERENT
GESTIONNAIRE Réservation
Demande de réservation
PLANNING
Nouveau Planning TABLE DE JEU

PLANNING
- 50 demandes de réservations
- 50 jeux réservés
- 50 tables réservées
Organisation :
Traitement Réservation : après avoir reçu une demande de réservation, la secrétaire

accepte ou refuse la réservation. Dans le cas où celle-ci est acceptée, on réserve une table et
un jeu. Dans tous les cas, un planning hebdomadaire sera édité chaque semaine.

Page 63
Le 31 mai 2000
Projet RAD
ADHERENT GESTIONNAIRE PLANNING
Demande de
réservation
TRAITEMENT RESERVATION
Refus Acceptation TJRS
Refus
Edition du
planning
Confirmation Réservation
réservation table
Réservation
jeu
Annexes
Document 1 : Planning

Page 64
Le 31 mai 2000
Projet RAD

Page 65
Le 31 mai 2000
Projet RAD
Expression des Besoins du Thème «Adhérents»
Rédacteur : Daniel Martre
1. Connaître la date d’inscription d’un adhérent pour pouvoir gérer les rappels de cotisation
annuels.
2. Connaître le nombre d’adhérents ainsi que des informations complémentaires permettant
d’effectuer des statistiques alimentant les différents dossiers de demande de subventions.
3. Génération des écritures comptables automatique en fonction des achats de jeux et du
paiement des cotisations.
Expression des Besoins du Thème «Jeux»
Rédacteur : Albert BICHON
1. Connaître le nombre d’exemplaires que l’association possède d’un jeu.

2. Pouvoir prévenir des éventuels rachat de jeu en cas de détérioration ( connaître l’état d’un
jeu).
3. Connaître la moyenne d’âge des adhérents afin de prévoir les types de jeux à acheter.
Expression des Besoins du Thème «Planning »
Rédacteur : Marie Marelle et Nicole Rado
1. Faciliter les réservations de tables des adhérents.

2. Trouver un jeu par recherche et connaître sa disponibilité.
3. Connaître la disponibilité d’une table à tout moment.
4. Edition d’un planning automatique.

Page 66
Le 31 mai 2000
Projet RAD
Compte rendu de la session JRP
La session JRP s’est déroulée le 2 décembre 1999 à l ‘ATRIA de Belfort.
Etaient présents :
Mesdames, Marie Marelle (secrétariat)

Nicole Rado (secrétariat)
Henri Michelle (Expert RAD)
Messieurs, Albert BICHON (Direction)

Daniel Martre (Comptabilité)
André Dupont (Chef de projet)
Marc Meyer (Chef de projet)
Le programme de la session était :

08h30 : Ouverture de la session par Monsieur Dupont André
09h00 : Présentation de l’existant
09h00 « Adhérent » Présenté par M. Martre Daniel
09h20 Complément d’explication et point de consensus
09h30 « Achats jeux » Présenté par M. Albert BICHON
10h00 « Planning rencontres » Présentée par Mesdames Marie Marelle
et Nicole Rado.
10h30 Pause
11h00 « informatique » Présenté par M. Marc Meyer
11h30 synthèse de l’existant par M. Dupont André
11h45 Repas
13h30 Présentation des orientations générales en terme d’informatique et des

contraintes en terme d’information par M. Marc Meyer
14h00 Expression des besoins
14h00 « Adhérent » par M. Martre Daniel
14h30 Débat
14h45 Point de consensus
15h00 « Achats jeux » par M. Albert BICHON
15h30 Débat

Page 67
Le 31 mai 2000
Projet RAD

16h00 « Planning rencontres » par Mesdames Marie Marelle et Nicole
Rado.
17h00 Débat
17h30 synthèse des travaux par M. Dupont André
18h00 Evaluation de la session
18h30 Lecture et distribution de la session
19h00 Fin de la journée
Un exemplaire des documents de description et de bilan de l’existant a été distribué à chaque

participant.
Matin
Sujet n°1 : Ouverture de la session

A 8h30 Monsieur Dupont André ouvre la session. Il présente l’organisation de la journée et
rappelle les résultats attendus à la fin de la session. Aucune question n’étant posée, il donne la
parole à M. Martre Daniel.
Sujet n°2 : Existant de « Adhérent »

Monsieur Martre commence son exposé sur la description des « adhérents » à 9h00 et se
termine à 9h20. Madame Marie Marelle souligne le fait que certains documents existants sur
les adhérents ne sont pas complets. Il faudra actualiser et compléter ces informations sur le
nouveau système. Cette suggestion est approuvée par l’ensemble des personnes présentes.
Après le point de consensus, la parole est donnée à M. Albert BICHON.
Sujet n°3 : Existant de « Achats jeux »

Monsieur Albert BICHON commence son exposé sur la description des « achats jeux » à
9h30 et termine son exposé à 9h50. Peu de remarques particulières ont été faites si ce n’est
des précisions de détails à caractère purement informatif. Le point de consensus est réalisé
par M. André Dupont.
Sujet n°4 : Existant de « planning rencontres »

Exposé présentée par Mesdames Marie Marelle et Nicole Rado. Leur exposé commence à
10h00 et se termine à 10h20. Une critique a fait l’unanimité des participants, c’est la difficulté
d’établir un planning propre et définitif. En effet, les annulations de réservation de dernière
minute sont fréquentes. Après le consensus, une pause de 30 minutes est accordée aux
participants.

Page 68
Le 31 mai 2000
Projet RAD
Sujet n°5 : Existant de « informatique »

Monsieur Meyer Marc commence son exposé à 11h00 et le termine à 11h20. Le point
essentiel concerne la formation des deux secrétaires à l’environnement Windows. La parole a
été laissée également à l’expert RAD. Après le point de consensus, la parole est donnée à M.
Dupont André.
Sujet n°6 : Synthèse de l’existant

Synthèse effectuée par Monsieur Dupont André de 11h30 à 11h45. Après avoir exposé le
bilan global de la situation existante, il a répertorié les remarques et les souhaits des
participants. L’ensemble de sa synthèse a été approuvé par les présents. L’ensemble des sujets
prévus ayant été traité et plus personne ne demandant la parole, il est décidé d’aller déjeuner.
Après midi
Un exemplaire des documents d’expression des besoins a été distribué à chaque participant.
Sujet n°1 : Présentation de l’après-midi

A 13h30, Monsieur André Dupont présente l’expression des besoins. Aucune question n’étant
posée, il passe la parole à Monsieur Meyer Marc pour la présentation des orientations
informatiques et les contraintes du système d’information.
Sujet n°2 : Présentation des orientations générales en terme d’informatique et des contraintes
en terme de système d’information.
Monsieur Marc Meyer commence son intervention à 13h30 et termine à 14h00. Il commence
par présenter les orientations techniques. Le budget étant serré il est convenu que la part du
budget accordé au matériel informatique sera de 10 000 F soit 1524 Euro.
Il est important de préciser que l’application sera monoposte.
Ce sujet étant épuisé, la parole est donnée à Monsieur Martre Daniel.
Sujet n°3 : Expression des besoins « Adhérents »

Monsieur Martre Daniel commence son exposé à 14h00 et le termine à 14h30. Au cous du
débat qui suivi, les points suivant ont été traités :
- La volonté d’avoir un meilleur suivi sur le profil des adhérents.
- La possibilité d’éditer la carte de membre.
Après le point de consensus, la parole est donnée à M. Albert BICHON.
Sujet n°4 : Expression des besoins « Achats des jeux »

Page 69
Le 31 mai 2000
Projet RAD
Monsieur Albert BICHON commence son exposé à 15h00 et le termine à 15h30. Au cous du
débat qui suivi, les points suivant ont été traités :
- Possibilité de connaître la liste des jeux précédemment achetés. Ceci afin de connaître
ceux qui sont le plus souvent achetés ou le plus souvent remplacés parce que trop fragiles
ou trop utilisés.
- Possibilité d’éditer un état récapitulatif sur les sommes versées au cours de l’année dans
l’acquisition des nouveaux jeux. Cette état pourra être fourni au comptable.
Après le point de consensus, la parole est donnée à Mesdames Marie Marelle et Nicole Rado.
Sujet n°5 : Expression des besoins « planning des rencontres »

Mesdames Marie Marelle et Nicole Rado commencent leur exposé à 16h00 et le termine à
17h00. Au cous du débat qui suivi, les points suivant ont été traités :
- Possibilité d’éditer la planning afin de l’afficher à l’entrée de l’association.
- Possibilité de faire des statistiques sur l’utilisation des jeux.
- Possibilité d’afficher la liste des joueurs les plus assidus.
- Possibilité de faire des statistiques sur la fréquence d’utilisation des tables ainsi que sur les
jours d’ouverture.
Après le point de consensus, la parole est donnée à Monsieur Dupont André.
Sujet n°6 : Synthèse des travaux

Synthèse réalisée par Monsieur André Dupont de 17h30 à 18h00. Par de remarques
particulières au cours du débat.
Sujet n°7 : Evaluation de la session

Après avoir rempli les grilles d’évaluations, les présents ont participé à un tour de table sur le
déroulement de la session. Les idées fortes qui en émergent sont :
- La journée était trop chargée.
- Les animateurs ont reconnu avoir été un peu trop rapide lors des débats.
Après lecture et distribution du compte rendu de la session, plus personne ne demande la

parole. La session se termine à 19h00.

Page 70
Le 31 mai 2000
Projet RAD
d. Conception
Dossier de conception JAD1
Sommaire :
Préambule
Description de l’organisation
L’architecture technique
Dispositions de sécurité
- Disponibilité des données
- L'intégrité des données
Annexes
Annexe 1 : Modèle conceptuel des données
Annexe 2 : Modélisation de l’organisation
Annexe 3 : Modélisation de la base de donnée
Préambule :
L’étape Conception a démarré le 7 décembre 1999, elle s’est appuyée sur les informations
issues de l’existant ( dictionnaire des données, dictionnaire des règles de gestion et modèle
organisationnel de l’existant), et a pris en compte les besoins exprimés par les utilisateurs lors
de la session JRP du 2 décembre 1999.
Les objectifs du projet sont :

- simplifier la gestion des inscriptions des adhérents
- réduire le temps de réalisation du planning des rencontres entre joueurs
- Avoir une meilleure appréhension des coûts d'acquisition des jeux
La mise en œuvre du projet doit impérativement débuter le 3 avril 2000.

Ce document contient :
- la description de la future organisation,
- l'architecture technique envisagée,
- les dispositions de sécurité envisagées pour assurer :
- la sécurité des données et des accès,
- le fonctionnement en cas de panne.
Les annexes présentent le modèle conceptuel de données et le modèle organisationnel des
traitements. La prise en compte des besoins exprimés par les utilisateurs n'ayant pas eu
d'impact sur le modèle des flux.

Page 71
Le 31 mai 2000
Projet RAD
Description de l'organisation
Le modèle organisationnel des traitements présente 3 procédures :

- une procédure d'inscription des adhérents, qui prend en compte la saisie des adhérents,
ainsi que leur consultation.
- une procédure d'achats des jeux, qui permet de stocker dans la base les acquisitions de
nouveaux jeux.
- une procédure planning, qui permet l'édition hebdomadaire des réservations des tables de
jeu.
Ces différentes procédures sont détaillées en annexe.
L'architecture technique
L'architecture technique envisagée est la suivante :

- Un poste client : Celeron 466, 64 Mo SDRAM, disque dur 13 Go, écran 17''.
- système d'exploitation : Windows 98 seconde édition.
- Imprimante : Epson 740 sytlus color.
- Sauvegarde : Lecteur iomega Zip 250 Mo
- Antivirus : VirusScan for Windows
évaluation des coûts :

- poste client : 6500 F HT (990,91 euro)
- système d'exploitation : 700 HT (106,71 euro)
- imprimante : 1490 F HT (226,60 euro)
- Sauvegarde : 700 F HT (106,71 euro)
- Antivirus : 300 F HT (45,73 euro)
Disposition de sécurité
Disponibilité des données :
Afin de préserver l'intégralité des données, un processus de sauvegarde sur lecteur ZIP sera
mis en place après chaque journée de saisie.
On disposera d'un jeu de 7 cartouches hebdomadaires + 1 cartouche supplémentaire afin
d'assurer la sauvegarde mensuelle. Cette dernière sera stockée dans un lieu sûr.

Page 72
Le 31 mai 2000
Projet RAD
L'intégrité des données :
Afin d'éviter une éventuelle dégradation des données suite à un virus, le PC disposera d'un
antivirus activité au démarrage de la machine. Celui-ci sera mis à jour tous les mois lors de la
réception de la nouvelle version par une personne compétente.
Annexes
Modèle conceptuel des données
JEU Boite de jeu EXEMPLAIRE BOITE JEU

Code jeu Numéro boite de jeu Numéro d'exemplaire
correspond a comme 1,1 Code lecteur Code Barre
Nom jeu 1,n Libellé boite de jeu 1,n
1,n
Descriptif jeu Prix boite de jeu Date d'achat
Règle jeu 0,n 1,1
Age Mini joueurs
Nombre joueurs mini est utilisé au cours a pour
Nombre joueurs maxi
1,1
Plage horaire
0,n propose 0,n
Numéro Plage horaire
ETAT
est de Heure Début
Heure Début Code état
Heure fin 1,1 Libellé état
1,1
ADHERENT
0,n
0,n Numéro d'adhérent
Type de jeu Nom
a lieu Prénom a
Code Type Jeu Réservation 1,1 1,1
Libellé Type Jeu Date de naissance
Numéro de réservation 1,1 Date d'adhésion
1,1 Cotisation
est daté 1,1 0,n Rue 0,n
1,n réserve Ville
CP SEXE
Tél Code sexe
concerne Tél Prof Libellé sexe
0,n
1,1
0,n paticipe
0,n
DATE possède
AAAAMMJJ TABLE
Numéro de table
0,n
COMPETENCES
Code compétence
Libellé compétence

Page 73
Le 31 mai 2000
Projet RAD
Modélisation de l’organisation
ADHERENT RESPONSABLE INSCRIPTION COMPTABILITE
Demande
dossier d'
inscription
TRAITEMENT DEMANDE INSCRIPTION
Remise du
formulaire
Formulaire et
Cotisation
OU
INSCRIPTION
Réinscrption et
cotisation
Comptabilisation
inscription
Carte de
membre

Page 74
Le 31 mai 2000
Projet RAD
ADHERENT COMITE CHOIX JEU COMPTABILITE
Proposition
de jeu
TRAITEMENT CHOIX JEU
Achat refusé Achat accepté
Décision
Comptabilisation
achat jeu
Achat
du jeu
ADHERENT GESTIONNAIRE PLANNING
Demande de
réservation
TRAITEMENT RESERVATION
Refus Acceptation TJRS
Refus
Edition du
planning
Confirmation Réservation
réservation table
Réservation
jeu

Page 75
Le 31 mai 2000
Projet RAD
Modélisation de la base de données
CORRESPOND
CODE_JEU
NUMERO_BOITE_DE_JEU
EXEMPLAIRE_BOITE_JEU
JEU BOITE_DE_JEU NUMERO_D_EXEMPLAIRE
CODE_JEU NUMERO_BOI TE_DE_JEU NUMERO_BOITE_DE_JEU
CODE_TYPE_JEU LIBELLE_BOITE_DE_JEU CODE_ETAT
NOM_JEU PRIX_BOITE_DE_JEU CODE_LECTEUR_CODE_BA
DESCRIPTIF_JEU DATE_D_ACHAT
REGLE_JEU
AGE_MINI_JOUEURS
NOMBRE_JOUEURS_MINI
NOMBRE_JOUEURS_MAXI
PLAGE_HORAIRE ETAT
NUMERO_PLAGE_HORAIRE CODE_ETAT
HEURE_DEBUT LIBELLE_ETAT
HEURE_DEBUT
HEURE_FIN ADHERENT
NUMERO_D_ADHERENT
CODE_SEXE
CODE_COMPETENCE
TYPE_DE_JEU NUMERO_PLAGE_HORAIRE
RESERVATION NOM
CODE_TYPE_JEU PRENOM
LIBELLE_TYPE_JEU NUMERO_DE_RESERVATIO DATE_DE_NAISSANCE
NUMERO_DE_TABLE DATE_D_ADHESION
AAAAMMJJ COTISATION
NUMERO_D_EXEMPLAIRE RUE
NUMERO_PLAGE_HORAIRE VILLE
NUMERO_D_ADHERENT CP
TEL
TEL_PROF
TABLE PATICIPE
NUMERO_DE_TABLE NUMERO_D_ADHERENT
NUMERO_DE_RESERVATIO
COMPETENCES
CODE_COMPETENCE
LIBELLE_COMPETENCE
Compte rendu de la session JAD1
La session JAD1 s'est déroulé les 3 et 4 janvier à l'hôtel Mercure à Belfort.
Etaient présents :

Page 76
Le 31 mai 2000
Projet RAD
Messieurs, Albert Bichon (Direction)

Première journée :

1. Ouverture de la session par M. Dupont André
2. Architecture technique par M. Meyer Marc
3. Présentation de la procédure « inscription des adhérents » par M. Dupont André.
4. Présentation de la procédure « Achat des jeux » par M. Dupont André.
5. Présentation de la procédure « Planning » par M. Dupont André.
Deuxième journée:
6. Présentation des dispositions de sécurité par M. Meyer Marc.

7. Présentation des données par M. Meyer Marc.
8. Synthèse des travaux par M. Meyer Marc.
9. Evaluation de la session par M. Dupont André.
Première journée
Un exemplaire de la première version du dossier de conception a été distribué à

chaque participant.
Sujet n°1 : Ouverture de session

A 9h30, Monsieur Dupont André ouvre la session, il présente l'organisation de ces deux
journées et rappelle les résultats attendus à la fin de la session. Aucune question n'étant posée,
il donne la parole à Monsieur Meyer Marc pour le thème « architecture technique ».
Sujet n°2 : Architecture technique

Monsieur Meyer Marc commence son exposé sur l'architecture technique du projet « Jeux
pour tous » à 10h00 et le termine à 11h00.
Monsieur Bichon Albert s'inquiète de l'absence d'un onduleur sur le poste de travail. En effet,
en cas de coupure de courant, il peut par exemple y avoir une perte d'intégrité des données.
Monsieur Meyer Marc intervient en indiquant que la remarque est judicieuse mais qu'il ne
dispose pas d'un budget suffisant.
Le point de consensus est réalisé par Monsieur Dupont André. Après le point de consensus,
une pause de 15 minutes à lieu.

Page 77
Le 31 mai 2000
Projet RAD
Sujet n°3 : Présentation de la procédure « inscription des adhérents »

Monsieur Dupont André commence son exposé concernant la procédure "inscription des
adhérents" à 11h15 et le termine à 12h30.
Aucun amendement n'est demandé.
Le point de consensus est réalisé par Monsieur Meyer Marc. Après le point de consensus, la
pause repas commence à 12h35.
Sujet n°4 : Présentation de la procédure « achat des jeux »

Monsieur Dupont André commence son exposé concernant la procédure « achat des jeux » à
14h30 et le termine à 15h50.
Aucun amendement n'est demandé.
Le point de consensus est réalisé par Monsieur Meyer Marc. Après le point de consensus, une
pause de 15 minutes est accordé.
Sujet n°5 : Présentation de la procédure « planning »

Monsieur Dupont André commence son exposé concernant la procédure « planning » à 16h10
et le termine à 17h30.
Madame Marie Marelle demande s'il sera possible de saisir et d'éditer un planning
prévisionnel. En effet, il peut arriver qu'un membre souhaite s'inscrire plusieurs semaines à
l'avance. Monsieur Meyer Marc précise que cette option est déjà prévue.
Le point de consensus est réalisé par Monsieur Meyer Marc.
Une version provisoire du compte rendu de la première journée est distribuée à 18h00.
Deuxième journée
La deuxième journée commence à 9h00 et Monsieur Meyer Marc demande s'il y a des
remarques sur le projet de compte rendu. Aucune remarque n'étant faite, il présente le
programme de la deuxième journée et donne la parole à Monsieur Dupont André.
Sujet n°6 : Présentation des dispositions de sécurité.

Monsieur Meyer Marc commence son intervention à 9h30 et le termine à 10h00.
Madame Henri Michelle fait remarquer qu'il serait souhaitable d'équiper le poste de travail
avec Windows NT 4.0 workstation. En effet, il serait intéressant d'avoir une gestion plus fine
de chaque utilisateur du poste. De plus, NT est plus sécurisé. Monsieur Meyer Marc promet
d'en tenir compte.
Le point de consensus est réalisé par Monsieur Dupont André. Une pause café de 15 minutes
est accordé.

Page 78
Le 31 mai 2000
Projet RAD
Sujet n°7 : Présentation des données.

Monsieur Meyer Marc présente le modèle conceptuel de données de 10h15 et le termine à
12h00. Madame Nicole Rado souhaiterais qu'il soit possible d'exporter les données sous le
tableur Excel afin de pourvoir utiliser les fonctionnalités du tableur avec ses données. En
effet, Madame Rado souhaiterais réaliser des états non prévus actuellement dans le standard
du logiciel.
La pause repas commence à 12h00
Sujet n°8 : synthèse des travaux

Monsieur Dupont André commence la synthèse à 14h00 et la termine à 14h45.
Les amendements retenus sont :
- La mise en place de Windows NT workstation au profit de Windows 98. Il est admis
que le système de fichier NTFS de NT est plus performant que la FAT32 en cas de panne.
- Monsieur Meyer Marc propose un rendez-vous le 15 janvier avec Madame Rado sur
l'export des données afin d'approfondir le sujet.
Aucune fiche problème n'a été faite.
Sujet n°9 : Evaluation de la session

Après avoir rempli les grilles d'évaluation, un tour de table a été fait, les idées fortes qui en
émergent sont :
- Les participants se félicitent des interventions de chacun. Cependant, il est
regrettable que Daniel Martre n'ai pas participé, en particulier sur la procédure « achat jeux ».
- Les participants ont apprécier le fait que la session JAD1 se soit déroulé sur deux
jours. En effet, la session JRP qui s'est déroulé sur une journée était trop éprouvante.
- L'hôtellerie et les repas ont été très appréciés par l'ensemble des participants.
Après lecture et distribution du compte rendu de session, plus personne ne prend la parole. La
session se termine à 16h30

Page 79
Le 31 mai 2000
Projet RAD
Dossier de conception JAD2
Sommaire :
Préambule
Description de l'organisation (voir JAD1)
L'architecture technique (voir JAD1)
Dispositions de sécurité (voir JAD1)
- Disponibilité des données
- L'intégrité des données
Planification de la suite du projet
Annexes
Annexe 1 : Modèle conceptuel des données (voir JAD1)
Annexe 2 : Modélisation de l’organisation (voir JAD1)
Annexe 3 : Modélisation de la base de donnée (voir JAD1)
Annexe 4 : Guidage fonctionnel
Préambule :
Ce document vient enrichir le dossier de conception produit dans la phase précédente. Il

contient :
- la planification de l'étape de construction à suivre,
- les compléments aux annexes
Planification de la suite du projet :
3
6/03/00
2
20/02/00
1
18/01/00
Cycle 1 : présentation le 24 janvier 2000

fonction : Gestion des adhérents
Cycle 2 : présentation le 29 février 2000

fonction : Achat des jeux

Page 80
Le 31 mai 2000
Projet RAD
Cycle 3 : présentation le 13 mars 2000

fonction : Gestion du planning
Annexes :
Annexe 4 : Guidage fonctionnel
Compte rendu de la session JAD2
La session JAD2 s'est déroulé le 11 janvier à l'auberge Tisserand à Gommersdorf
Etaient présents :

Paul Proto (Prototypeur)

1. ouverture de la session par M. Dupont André.
2. présentation des principes et des normes par Monsieur Proto Paul.
3. guidage fonctionnel par Monsieur Meyer Marc.
4. présentation des scénarios de mise en oeuvre par Monsieur Meyer Marc.
5. synthèse des travaux par Monsieur Dupont André.
6. Evaluation de la session par Monsieur Dupont André.
Déroulement de la journée

Page 81
Le 31 mai 2000
Projet RAD
Un exemplaire de la deuxième version du dossier de conception a été distribué à chaque

participant.
Sujet n°1 : Ouverture de session

A 9h00, Monsieur Dupont André ouvre la session, il présente l'organisation de la journée et
rappelle les résultats attendus à la fin de la session. Aucune question n'étant posée, il donne la
parole à Monsieur Proto Paul pour le premier thème.
d. Construction
Cette partie est décomposée suivant les 3 cycles définis en phase JAD2. A chaque
cycle correspond un prototype qui sera présenté aux utilisateurs du futur système, qui
proposeront diverses améliorations.
Cycle 1 : gestion des adhérents

Page 82
Le 31 mai 2000
Projet RAD
La session de présentation du prototype issu du cycle 1 s’est déroulée le 24 janvier 2000 de 9h

à 12h dans la salle de jeu.
Etaient présents :

André Dupont (Chef de projet utilisateur)
Marc Meyer (Chef de projet informatique)
Paul Proto (prototypeur)

- ouverture de la session,
- présentation de la fonction « gestion des adhérents »
- synthèse de la session.
Sujet n°1 : ouverture de la session

A 9h, Monsieur Dupont André ouvre la session. Il présente l’organisation de la réunion et
rappelle les résultats attendus. Aucune question n’étant posée, il passe la parole à Monsieur
Meyer Marc.
Sujet n°2 : présentation de la fonction « gestion des adhérents » ( de 9h20 à 11h40 )

Monsieur Meyer Marc situe la fonction par rapport au modèle organisationnel de la
conception puis il passe la parole à Monsieur Proto Paul qui présente le prototype.

Page 83
Le 31 mai 2000
Projet RAD
Cycle 2 : gestion des jeux

Page 84
Le 31 mai 2000
Projet RAD
Cycle 3 : planning

Page 85
Le 31 mai 2000
Projet RAD

Page 86
Le 31 mai 2000
Projet RAD
Conclusion
Utiliser une méthode est nécessaire pour mener à bien un projet. Les méthodes
traditionnelles ont des imperfections au niveau des coûts de développement, des délais de
livraison et de la qualité du résultat final, ce à quoi le RAD répond par une démarche
appropriée.
Nous venons de voir dans cette étude, comment réaliser un projet avec la méthode
RAD. Bien que cette méthode résolve de nombreux problème de qualité, elle n’est pas
souvent utilisé. D’une part elle n’est pas enseigné dans les universités, ensuite peu d’ouvrage
lui son consacré. De plus la mise en œuvre du RAD dans des organisations habituées à
travailler à l’ancienne ne peut se faire sans changement culturel. En effet l’utilisateur doit
s’impliquer d’avantage dans le projet, il faut consacrer du temps et des ressources dans les
rapports et réunions et avoir dans son équipe un expert RAD. De nouveaux outils modernes
doivent être utilisés ainsi que de nouvelles techniques.
Le livre « RAD une méthode pour développer plus vite » [HUG97] est le seul ouvrage
qui décrit et met en application la méthode RAD d’une façon pratique. On peut y trouver les
modèles de document à fournir durant les différentes étapes.
Le livre « RAD » de Vickoff [VIC96] ouvre une nouvelle vision sur la méthode RAD.
Il soutient exclusivement l’environnement Windows.
Le livre « développement rapide d’applications » de Marcel Soberman [SOB96]
reprend les grandes lignes de la méthode et propose une étude de cas reposant sur la méthode
SADT.
Le RAD de James Martin a donné naissance à d’autres méthodes basées sur une
relation informaticien-utilisateur. Le RAD de Vickoff (RAD2) ainsi que le DSDM en sont des
exemples.
Cette étude nous a donné une autre approche de celle que l’on côtoie tous les jours au
sein de l’entreprise.
Projet Système d’information Conclusion

Page 87
Le 31 mai 2000
Projet RAD
Table des matières

INTRODUCTION ....................................................................................... PAGE 3
METHODE RAD ...................................................................................... PAGE 4

A. DEFINITION ......................................................................................... PAGE 4
OBJECTIF ............................................................................................ PAGE 4
B. LES ACTEURS DE LA METHODE RAD .................................................. PAGE 5
LES ACTEURS DU PILOTAGE ................................................................ PAGE 6
LES ACTEURS DU CONTROLE .............................................................. PAGE 6
LES ACTEURS DU CONTENU ................................................................ PAGE 7
LES ACTEURS DU SYSTEME INFORMATISE ........................................... PAGE 7
LA RELATION ROLE/PHASE ................................................................. PAGE 8
C. DEMARCHE DE LA METHODE RAD ....................................................... PAGE 8
L’ETAPE INITIALISATION ....................................................................PAGE 10
L’ETAPE EXPRESSION DES BESOINS ....................................................PAGE 16
L’ETAPE CONCEPTION ........................................................................PAGE 21
L’ETAPE CONSTRUCTION ...................................................................PAGE 28
L’ETAPE DE MISE EN OEUVRE .............................................................PAGE 31
D. OUTILS ET TECHNIQUES RAD ...............................................................PAGE 33
LES OUTILS .........................................................................................PAGE 33
LES TECHNIQUES RAD ........................................................................PAGE 35
E. AVANTAGES ET INCONVENIENTS DE LA METHODE ..............................PAGE 38
POUR L’UTILISATEUR ..........................................................................PAGE 38
POUR L’INFORMATICIEN ......................................................................PAGE 39
POUR L’ORGANISATION .......................................................................PAGE 39
DSDM : UNE AUTRE METHODE DE DEVELOPPEMENT RAPIDE ..................PAGE 41

A. POURQUOI CETTE METHODE EST-ELLE APPARUE ? ..............................PAGE 41
B. METHODOLOGIE DE LA DSDM ...........................................................PAGE 42
LA METHODE RAD FACE AUX AUTRES METHODES PLUS CLASSIQUES .....PAGE 45

A. METHODE MERISE ..............................................................................PAGE 45
PREAMBULE ........................................................................................PAGE 45
PRINCIPES ...........................................................................................PAGE 45
DESCRIPTION DES NIVEAUX ................................................................PAGE 46
AVIS ....................................................................................................PAGE 47
B. METHODE SSADM ............................................................................PAGE 47
PREAMBULE ........................................................................................PAGE 47
PRINCIPES ...........................................................................................PAGE 47
AVIS ....................................................................................................PAGE 48
C. METHODES OBJETS .............................................................................PAGE 48
Projet Système d’information Table des matières

Page 88
Le 31 mai 2000
Projet RAD
CAS PRATIQUE ........................................................................................PAGE 49

A. PRESENTATION .....................................................................................PAGE 49
B. L’ETAPE D’INITIALISATION .................................................................PAGE 50
C. EXPRESSION DES BESOINS ...................................................................PAGE 56
D. CONCEPTION .......................................................................................PAGE 71
E. CONSTRUCTION ...................................................................................PAGE 82
CONCLUSION ...........................................................................................PAGE 87
TABLE DES MATIERES .............................................................................PAGE 88
GLOSSAIRE ..............................................................................................PAGE 90
BIBLIOGRAPHIE .......................................................................................PAGE 93
Projet Système d’information Table des matières

Page 89
Le 31 mai 2000
Projet RAD
Glossaire
Administrateur du référentiel : Il a pour rôle à l’étape conception, de favoriser la
réutilisation des composants — modèles, entités conceptuelles, fonctions logiques,
composants logiciels... — et d’inciter au respect des normes et des standards de l’entreprise.
Binôme chef(s) de projet : Le binôme chef de projet informatique (CPI) et chef de projet
utilisateur (CPU) assurent la gestion du projet.
Comité de pilotage : Structure de décideurs qui fonctionne comme instance de validation et

d’appel.
Cycle de construction : L’étape construction est découpée en cycles de prototypage. On

appelle « cycle 1 » le premier cycle, « cycle n » le dernier cycle et « cycle (i) » les cycles
intermédiaires.
Diagnostic : Première phase de l’étape initialisation. Elle a pour but de formaliser les
caractéristiques du projet. Elle se termine par la décision de mener ou non le projet en RAD
dès le début.
Equipe de construction : Elle est composée d’utilisateurs et a pour but de valider chaque
cycle de prototypage.
Equipe de mise en œuvre : Elle est composée d’utilisateurs et a pour mission les tâches de
mise en œuvre.
Equipe de prototypage : Equipe de développeurs chargée de réaliser les différents prototypes

de l’application.
Equipe JAD1 : Elle est composée d’utilisateurs et a pour mission de se prononcer sur les
propositions du binôme chef(s) de projet.
Equipe JAD2 : Elle est composée d’utilisateurs et a pour but de valider la conception
détaillée, avant le prototypage.
Equipe JRP : Cette équipe rassemble des utilisateurs qui représentent chacun un thème du
domaine couvert par le projet.
Projet Système d’information Glossaire

Page 90
Le 31 mai 2000
Projet RAD
Ergonome : Il apporte son appui dans la phase JAD2 lors de l’élaboration des maquettes.
Etape Conception : Troisième étape d’un projet RAD. Elle conduit à une description du futur
système.
Etape Construction : Quatrième étape d’un projet RAD. Elle a pour objectif de développer
l’application.
Etape Expression des besoins : Deuxième étape d’un projet RAD, dont l’objectif est
d’obtenir de l’équipe JRP qu’elle exprime les besoins des utilisateurs.
Etape Initialisation : Première étape d’un projet RAD. Son objectif est de faire entrer le
projet dans un processus RAD : elle vise d’abord à déterminer comment mettre en œuvre la
méthode pour le projet, puis à rassembler les ressources informationnelles et humaines
nécessaires à l’expression des besoins.
Etape Mise en œuvre : Dernière étape d’un projet RAD. Il s’agit d’installer l’application et
l’environnement nécessaire à son utilisation.
Expert RAD : Il assiste le binôme chef de projet dans la conduite d’un projet RAD. Il joue un
rôle de conseiller méthodologique.
JAD (technique) : Joint Application Design, soit conception participative d’application. Cette
technique (proposée dans les années 80 par IBM) est utilisée dans des projets RAD en phase
de conception JAD1 et JAD2.
JAD1 : Première phase de l’étape Conception. Elle a pour but d’établir, en concertation avec
les utilisateurs, le fonctionnement conceptuel et organisationnel du futur système et
d’effectuer les choix d’architecture technique.
JAD2 : Deuxième phase de l’étape Conception. Elle a pour but d’établir, en concertation avec
les utilisateurs, la liste des fonctions logiques, transactionnelles et batch.
JRP (technique) : Joint Requirement Planning, soit définition participative des besoins. Cette
technique (proposée dans les années 80 par IBM) est utilisée dans des projets RAD lors de
l’expression des besoins.
JRP : Unique phase de l’étape Expression des besoins. Elle s’appuie de façon centrale sur la
technique du Joint Requirement Planning (JRP).

Page 91
Le 31 mai 2000
Projet RAD
Mobilisation : Deuxième phase de l’étape Initialisation. Elle a pour but de constituer l’équipe
de projet et d’établir les bases de l’organisation du projet.
Modélisateur : Concepteur apportant sont appui dans des tâches de modélisation lors des
sessions JRP et JAD.
Objet de gestion : Méthode qui propose une approche d’uniformisation des traitements de
gestion des données d’un système. Cette méthode peut être utilisée dans les étapes Conception
et Construction d’un projet en RAD.
Propriétaire : Propriétaire de la future application. Sa position hiérarchique doit lui permettre

d’engager le comité de pilotage sur ses choix.
Prototypage : Technique de production du logiciel basée sur la construction d’un prototype

qui s’enrichit au fil des cycles de l’étape Construction.
Prototypeur : Développeur utilisant des outils de développement rapide.
RAD ou Méthode RAD : Rapid Application Development, méthode de conduite de projet

proposée par James Martin, consultant américain.
Réutilisabilité : La réutilisation est un élément majeur de la conduite d’un projet en RAD car
elle permet de réduire la durée de plusieurs étapes. La réutilisabilité est une technique qui a
pour objet de favoriser la réutilisation.
Time-box : Le principe de la time-box est de fixer une enveloppe temps fixe et limitée, ne
devant être dépassée sous aucun prétexte. La time-box peut-être considérée comme un garde-
fou dans le cas de développement par prototypage.

Page 92
Le 31 mai 2000
Projet RAD
Bibliographie
[VIC96] Jean-Pierre Vickoff, RAD, Développement Rapide d’Application,
Simon & Schuster Macmillan, 1996
[SOB96] Marcel Soberman, Développement rapide d’application, Hermès, 1996
[HUG97] Jean Hugues, Bernard Leblanc, Chantal Morley, RAD, une méthode
pour développer plus vite, InterEditions/Masson, 1996
[IBM84] IBM overview Pamphlet JAD, Joint Application Design , White Plains,
1984
[PAN94] G. Panet et R. Letouche , Merise/2, Les éditions d’organisation, 1994
[COL86] A. Collongues, J. Hugues et B. Laroche, Merise – méthode de

conception, Dunod Informatique, 1986
[MET90] Henri Pierreval, Les méthodes d'analyse et de conception des systèmes

de production,Hermes, 1990
[GAU96] Marie-Claude Gaudel, Bruno Marre, Françoise Schlienger, Gilles

Bernot, Précis de génie logiciel, Masson,1996
Site internet
DSDM www.dsdm.org
RAD www.rad.fr
Personnes contactées
DSDM Ian Stokes, président de l’association DSDM en France
RAD Jean-Pierre Vickoff, auteur de [VIC96]
Projet Système d’information Bibliographie

Page 93

Rad V35

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rad V35

Transféré par

Droits d'auteur :

Formats disponibles

Projet Système d’information

Centre associé du Haut Rhin

Dossier rendu par :

INTRODUCTION ................................................................................. PAGE 3

METHODE RAD ................................................................................. PAGE 4

DSDM : UNE AUTRE METHODE DE DEVELOPPEMENT RAPIDE ............ PAGE 41

LA METHODE RAD FACE AUX AUTRES METHODES PLUS CLASSIQUES PAGE 45

CAS PRATIQUE .................................................................................. PAGE 49

CONCLUSION .................................................................................... PAGE 87

TABLE DES MATIERES ....................................................................... PAGE 88

GLOSSAIRE ....................................................................................... PAGE 90

BIBLIOGRAPHIE ................................................................................ PAGE 93

Projet Système d’information Sommaire

Tout au long de ce dossier nous essayerons de définir la démarche à suivre pour

Projet Système d’information Introduction

La méthode RAD a pour objectif principal d’améliorer la qualité des développements,

Globalement le RAD s’attache à :

Cette méthode s’appuie énormément sur l’engagement total des utilisateurs.

Le RAD a pour objectif principal de réduire le projet en charge (gain d'argent) et en

Projet Système d’information Méthode RAD

b. Les acteurs de la méthode RAD

Le facteur humain est un élément-clé du développement rapide d’application.

On distingue quatre groupes d’acteurs :

RAD : Les acteurs [HUG97]

Projet Système d’information Méthode RAD

Les acteurs du pilotage

Ils sont responsables de l’aboutissement du projet. On peut considérer qu’ils correspondent au

Les acteurs du contrôle

Projet Système d’information Méthode RAD

la fin de l’étape Construction. On peut noter que le propriétaire de l’application fait

Les acteurs du contenu

Les acteurs du système informatisé

Projet Système d’information Méthode RAD

c. Démarche de la méthode RAD

Le déroulement d'un projet RAD comprend cinq étapes :

Projet Système d’information Méthode RAD

Une phase peut être découpée en trois temps :

Les travaux de préparation consistent à rassembler des matériaux, élaborer une

Les travaux de conclusion consistent à prendre en compte le résultat de la session :

Projet Système d’information Méthode RAD

Elle comprend deux phases :

L’étape d’initialisation [HUG97]

Projet Système d’information Méthode RAD

Cette phase fait essentiellement appel à l'expérience et à la connaissance de l'expert

Projet Système d’information Méthode RAD

Projet Système d’information Méthode RAD

- La connaissance du système de gestion par les utilisateurs autorise une conception en

Il est souvent utile de conforter la légitimité du projet dans l'entreprise en faisant

Après la session, les travaux de conclusion consistent à arrêter le choix de la méthode ou

La phase de diagnostic [HUG97]

Projet Système d’information Méthode RAD

Les travaux de préparation de la phase consiste en l’étude du domaine à travers ses

Projet Système d’information Méthode RAD

L’ensemble des éléments résultant des travaux de préparation constitue le dossier

La réunion comprend un échange avec les participants. Il s’agit de créer un esprit

La phase de mobilisation [HUG97]

Projet Système d’information Méthode RAD

L’étape Expression des besoins

L’étape Expression des besoins commence dès la fin de la session de la phase de

Projet Système d’information Méthode RAD

Au cours de la phase JRP, on utilise des techniques classique tels le recueil de

Certaines personnes conseillent l'utilisation :

Projet Système d’information Méthode RAD