RAD

RAD

Rapid Application Development

dimanche 28 décembre 2003

RAD (Rapid Application Development) est une méthode de conduite de projet permettant de développer rapidement des applications de qualité.

Aujourd’hui, qualité et réactivité font partie des objectifs généraux de beaucoup d’entreprises. Cela entraîne un certain nombre de projets, qui tout en apportant satisfaction aux utilisateurs, doivent être menés dans un délais court. C’est à cela que répond la méthode RAD.

Les principes de RAD

Les fondements méthodologiques de la méthode RAD peuvent être exprimés à travers dix principes.

1.Confier l’expression des besoins aux utilisateurs

Même si l’on veut aller vite, il est nécessaire de déterminer ce que l’on attend du futur système avant de commencer à le construire. Cela permet gagner du temps en évitant les retours en arrière. L’originalité de RAD est de confier la responsabilité et la description de ces attentes aux utilisateurs.

2.Organiser l’expression des besoins

RAD reconnaît que les besoins ne sont pas donnés, qu’il ne suffit pas de les recueillir ou d’observer un fonctionnement existant. Les exprimer requiert un travail de distanciation et d’imagination de la part des utilisateurs. La méthode les aide, sans leur demander un apprentissage spécifique. RAD permet par ailleurs de gérer la diversité des points de vue, car les besoins exprimés peuvent être multiples et contradictoires.

3. Introduire une dimension temporelle dans l’expression des besoins

II est souvent difficile, voire périlleux, d’arrêter l’expression des besoins au terme d’un délai réduit. RAD permet d’affiner progressivement les besoins, par une organisation adéquate, suffisamment souple pour prendre en compte des modifications. La méthode prévoit des garde-fous pour éviter le « syndrome de Pénélope » : défaire la nuit ce qui a été fait le jour...

4. Ajuster les besoins

RAD propose un renversement dans la définition du périmètre de l’application. Classiquement, le recensement des fonctions du futur système permet de déterminer la charge de réalisation. RAD offre une perspective inverse : on limite volontairement la durée du développement et on ajuste le contenu de l’application. Cela conduit les utilisateurs à faire des choix. Ils se centrent sur les fonctions essentielles. D’autres, jugées secondaires, sont réduites, abandonnées ou différées.

5. Raccourcir les circuits de décision

Sans décision, l’avancement du projet est fictif. L’expérience montre que les décisions se prennent difficilement dans les projets qui mettent en jeu de nombreux utilisateurs. Ceci pénalise la durée de projet. C’est pourquoi RAD organise le projet de façon à y intégrer les décideurs. Les modalités de conception et développement sont adaptées à des décisions rapides.

6. Structurer les problèmes selon la structure de décision

Pour aller vite, il faut pouvoir partager le travail. Le découpage du domaine se base en grande partie sur la structure de décision de l’entreprise. Chaque élément du domaine relève d’un décideur pertinent qui participe au projet.

7.Utiliser des techniques existantes

RAD ne mise pas sur l’invention d’une technique « miracle ». La réussite réside dans l’assemblage de différentes techniques utilisées de façon judicieuse.

RAD s’appuie sur quatre techniques spécifiques :
  JRP [IBM, 1984] : cette technique est une aide à l’expression des besoins par les utilisateurs ;
  JAD [IBM, 1984] : cette technique organise le processus de conception de façon à y faire participer les utilisateurs ;
  Time-box [Dupont, 1989] : cette technique limite la durée de la réalisation à une enveloppe-temps maximale ;
  Pilotage RAD : cette technique permet de placer le projet sous contrôle, pour en garder la maîtrise.

La méthode structure par ailleurs l’utilisation du prototypage.

Enfin, deux techniques complémentaires, l’estimation des charges et l’organisation de la réutilisabilité, favorisent la réussite d’un projet RAD.

8. Travailler en session participative

Le travail en session participative est un mode de travail collectif, intense et limité dans le temps. Il réunit utilisateurs et informaticiens. Cela permet aux utilisateurs de faire une coupure dans leur activité opérationnelle, pour prendre des décisions à moyen terme. Par ailleurs, cela favorise la constitution d’une équipe et accompagne la recherche de consensus.

9. Anticiper

Si l’on veut aller vite, tout en conservant le principe du travail en groupe, il est nécessaire d’organiser rigoureusement les travaux préparatoires aux sessions. Toute réunion doit être préparée. La charge de préparation est répartie entre différents acteurs. Cela permet d’engager chaque participant et d’alléger le poids du travail en groupe.

10. Utiliser des outils performants

Les outils allègent le travail. L’outil de prototypage s’accompagne en général d’une aide à la conception et d’un référentiel, facilitant la documentation et la réutilisation.

Le cycle de RAD

La méthode RAD propose de remplacer le cycle de vie classique par un autre découpage temporel. Le déroulement est d’abord linéaire, puis il suit le modèle de la spirale. Les étapes sont au nombre de cinq :

1.Initialisation,
2.Expression des besoins,
3.Conception,
4.Construction,
5.Mise en œuvre.

Les caractéristiques des étapes sont les suivantes :

  L’étape Initialisation : l’objectif est de sélectionner les acteurs pertinents, de structurer le travail en thèmes et d’amorcer une dynamique. Elle ne dépasse pas 15 jours.
  L’étape Expression des besoins : l’objectif est de mettre à jour ce qui sera utile aux utilisateurs. On utilise la technique du JRP qui organise le travail en session. La durée de cette étape est fonction du nombre d’utilisateurs concernés. Elle ne dépasse pas 30 jours.
  L’étape Conception : l’objectif est de concevoir une solution. Les techniques utilisées sont le JAD et le prototypage. L’étape ne dépasse pas 60 jours.
  L’étape Construction : il s’agit, fonction par fonction, de construire un système viable. Les techniques utilisées sont la time-box et le prototypage. Cette étape ne dépasse pas 120 jours.
  L’étape Mise en œuvre : des recettes partielles ont été faites à l’étape construction. Il s’agit ici d’officialiser une livraison globale, d’éventuellement l’optimiser, d’installer le nouveau système et de faire le bilan du projet.

L’objectif-délais de RAD porte principalement sur les quatre premières étapes : le but est d’obtenir un système en état de marche, dans un délai réduit et qui sera impérativement respecté.

Les acteurs d’un projet RAD

RAD propose une organisation du projet, basée sur une répartition précise du travail entre les différents acteurs. La responsabilité de chacun dépend du rôle qu’il joue. La méthode distingue cinq types de rôles : binôme chef de projet, utilisateur, expert RAD, prototypeur et propriétaire.

Le binôme chef de projet se compose d’un chef de projet utilisateur (CPU) et d’un chef de projet informatique (CPI). Chacun doit avoir autorité et légitimité dans l’entreprise.

Ce binôme intervient dès le démarrage et tout au long du projet. Selon les étapes, soit leur responsabilité s’exerce conjointement, soit l’un des deux est dominant. Ainsi, l’étape Expression des besoins est sous la responsabilité première du CPU, l’étape Construction est sous la responsabilité première du CPI.

L’utilisateur est un gestionnaire qui a une bonne connaissance du système de gestion et qui peut se prononcer sur son évolution. Il ne s’agit donc pas, en général, de l’utilisateur final, mais d’un utilisateur décideur. Les utilisateurs vont fonctionner en équipe : équipe JRP pour l’expression des besoins, équipe JAD pour la conception, équipe de construction et équipe de mise en œuvre.

L’expert RAD ne doit pas être confondu avec un chef de projet. Il assiste le binôme chef de projet. Il joue un triple rôle : préparer les sessions, animer les sessions et apporter un soutien méthodologique, notamment dans le pilotage RAD. Dans la préparation des sessions, il intervient auprès des utilisateurs non sur le fond mais sur la forme (documents, présentations ...). Lors de sessions, il favorise les travaux de groupe. Il est multiprojet, car il n’est pas engagé en permanence sur un seul projet.

Le rôle du prototypeur est un rôle qui évite la coupure traditionnelle entre concepteur et développeur. Il intervient à l’étape Conception et à l’étape Construction.

Le propriétaire finance le projet. C’est ce que l’on appelle parfois le directeur d’application.

Quand peut-on appliquer RAD

L’utilisateur de RAD commence par un diagnostic d’opportunité : peut-on mettre en œuvre la méthode ? Une analyse des caractéristiques du projet et de son contexte permet de bâtir un profil du projet. Ce profil aide à décider si l’on tirera profit de RAD, s’il faut l’adapter ou s’il faut lui préférer une approche.

Cinq critères permettent de situer le projet par rapport au champ d’application de la méthode : la stabilité de l’environnement du projet, l’existence d’un chef de projet utilisateur, le pouvoir de décision des utilisateurs, le nombre d’utilisateurs, la connaissance du système de gestion.

1. L’environnement du projet est stable si les domaines connexes à celui du projet présentent des zones de communication stabilisées. Si tel n’est pas le cas, le calendrier des étapes Expression des besoins et Conception est dépendant de celui des projets connexes. Il est alors utile de mettre sous pilotage RAD la conception des zones frontières. La méthode RAD peut être utilisée à l’étape Construction. Si l’environnement du projet est stable, RAD s’applique dès le début du projet.

2. La mobilisation des utilisateurs et le partage des responsabilités sont des points-clé de la méthode. Le dispositif organisationnel prévoit qu’un chef de projet utilisateur s’engage autant qu’un chef de projet informatique. Cet engagement est particulièrement nécessaire lors des deux premières étapes. Le projet peut être mené en RAD à partir de l’étape Conception, si le chef de projet utilisateur n’est que partiellement disponible.

3. Le pouvoir de décision des utilisateurs est particulièrement important dans les étapes Expression des besoins et Conception. Cette capacité permet de tirer profit des travaux préparatoires effectués par les utilisateurs ainsi que du travail en session. Si la délégation de pouvoir reste limitée, on utilise la méthode RAD à partir de la fin de la conception et pour l’étape Construction.

4. Le travail en session permet de gérer la diversité des points de vue. Les techniques JRP et JAD sont particulièrement utiles quand le groupe d’utilisateurs dépasse la demi-douzaine.

5. La connaissance du système de gestion par les utilisateurs est indispensable aux travaux préparatoires de l’étape Expression des besoins. Il peut arriver que les décideurs n’aient qu’une connaissance limitée du fonctionnement opérationnel. Il peut arriver également que les règles de gestion soient enfermées dans le système automatisé, de telle façon que les gestionnaires n’en ont plus connaissance. On identifie alors un rôle supplémentaire d’apporteur de connaissance. L’étape Expression des besoins est aménagée, une première session permettant l’explicitation et le transfert des connaissances.

Forum...

> RAD

27 décembre 2004 [Retour au début des forums]

qu’est-que le rad-cycle

Répondre à ce message