Aspects divers de la méthode

RAD : développement maîtrisé d'applications de qualité fonctionnellement approuvées par les utilisateurs
La méthode RAD est à l'origine du mouvement Agile. Certains de ses sous-ensembles sont condidérés comme des méthodes à part entière. C'est, par exemple, le cas de XP (eXtrem Programming) qui se limite aux best practices de développement.
Lire à ce sujet 01.NET : Méthodes Agiles, des approches modernes dérivées du RAD

" 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. "
Le RAD (est ou n'est pas)

Le RAD n'est pas du prototypage mais utilise cette technique. Le prototype n'est pas une maquette mais un état intermédiaire du développement.

Le RAD ne remplace pas la modélisation du système. Engager un développement en RAD sans respecter préalablement les principes d'une conduite moderne de l'évolution conduit à l'échec ou tout au mieux à ce qui se pratique aujourd'hui.

Ceux qui considèrent le RAD comme une absence de méthode, pensent le pratiquer sans appliquer de méthode ou ne le pratiquent pas, en fait.

Le RAD privilégie l'action à la justification fondamentale et fusionne un niveau de compétence à un état d'esprit.

Le RAD consacre l'aboutissement d'une maîtrise organisationnelle, méthodologique et technologique, il s'applique à toutes les tailles de projet.

Le RAD n'est pas un choix, mais une nécessité incontournable d'adaptation qui implique la communication dans la rigueur.



Le RAD et Merise en France

La France a été, durant ces quinze dernières années, une plate-forme de test pour Merise Le problème méthodologique français qui en résulte, se situe dans son incapacité à réagir à une évolution rapide. L'exemple est particulièrement marquant en ce qui concerne l'intégration technologique par rapport aux niveaux d'abstraction et le cycle de vie par rapport à la rigidité du cadre systémique.

La méthode Merise, structurante et lourde, fait face à des formes de développement qui lui sont incompatibles en terme de rentabilité. Les architectures modernes de systèmes d'information (SI) s'appuient sur la technologie pour adapter l'organisationnel dans une vision souple et mouvante.

La puissance d'expression des modèles merisiens reste néanmoins un des meilleurs moyens de représentation systémique de l'organisation. Les Nord Américains, qui ignorent Merise disposent depuis vingt ans de modèles nettement plus efficaces, les DFD (Gane et Sarson). C'est d'ailleurs l'apport de leurs principes qui constitue le principal de Merise 2. Ils intègrent les flux et les données aux principes de traitement. La puissance de cette approche permet de schématiser dans un même symbolisme les niveaux d'abstraction et une profondeur de décomposition presque illimitée. Des logiciels comme AMC*Designor, MEGA, Tramis et autres, combinent et adaptent maintenant les deux approches.

Jusqu'ici, les méthodes se distinguaient par leur approche monolithique des problèmes. On décomposait la structure (top down) ou l'on élaborait à partir des besoins (bottom up). Une méthode de conduite de l'évolution et le RAD réconcilient les deux tendances. La systémique s'applique à la conception haute (CADRAGE, DESIGN) et le prototypage à la spécification détaillée. L'organisation est donc appréhendée globalement par une approche qui garantit la cohérence systémique, et c'est à l'engagement de la phase de réalisation (CONSTRUCTION) que l'on basculera dans la conception détaillée et la réalisation conjointe pour garantir l'adéquation du produit aux exigences des utilisateurs.


Le RAD en réalisation

La spécification détaillée et la réalisation intègrent les fonctions de conception, de développement et de validation dans un processus permanent de collaboration avec l' utilisateur (figure 78). La mise au point et la validation s'effectuent sur des parties limitées du système qui peuvent être utilisées indépendamment. L'utilisateur devient réellement le concepteur de son application et le RAD l'acronyme de "Really Approved Development". Plusieurs itérations journalières sont possibles, et l'on réalise en concevant, tout en testant ce que l'on réalise.

Deux dangers menacent les pionniers du RAD : le mirage de la sophistication fonctionnelle illimitée et le "puits sans fond" inhérent à la richesse de l'interface Windows. James Martin nous propose des limites formelles : le "design to cost" et le "time-box". Ces garde-fous restreignent les fonctionnalités à l'enveloppe budgétaire disponible dans une limite précise de temps.

L'expérience du RAD en Amérique du Nord permet de considérer l'obtention de la Qualité Totale comme la troisième et la meilleure des possibilités : le client est satisfait sans que l'on ait épuisé les budgets et dépassé les délais.

Le grand art de l'intégrateur de technologies consiste à choisir les outils dont l'adéquation est optimale (customs-controls).

L'efficacité génère plus de fonctionnalités ou réduit le cycle de production.



Les Hommes du RAD

Le RAD modifie fondamentalement les rapports entre informaticiens et utilisateurs. Le partage des responsabilités entre la Maîtrise d'Oeuvre et la Maîtrise d'Ouvrage est formel et rigoureux. La transition de l'aspect intégration technologique à l'aspect humain est brutale. A travers le RAD, le BPR et la recherche d'amélioration continue de la qualité, l'engagement de l'utilisateur n'est pas neutre et débouche sur sa responsabilisation.

L'utilisateur devient concepteur, il détermine les fonctionnalités et impose la dynamique applicative. L'informaticien devient prototypeur, il maîtrise les outils de réalisation et représente une force de proposition technologique.

En agglomérant la conception et la réalisation, le RAD fusionne le travail de l'analyste et du programmeur.

Par ailleurs, les outils spécialisés nécessaires au développeur comme à l'utilisateur confèrent à ce nouveau métier une dimension technologique exceptionnelle. Contrairement aux apparences, jamais les développements n'ont été aussi complexes.



Le groupe RAD de Construction (SWAT TEAM)

La composition d'une équipe de développement RAD requiert une attention toute particulière en ce qui concerne la dynamique des relations interpersonnelles : Une seule personne peut démotiver un groupe. Du côté des informaticiens, les compétences techniques, si elles sont nécessaires, ne sont pas suffisantes pour assurer des relations interpersonnelles harmonieuses. La maîtrise de Visual Basic ou d'un AGL n'est pas en soi la connaissance universelle, et des personnes de grandes responsabilités ou de grande culture technique ou organisationnelle en sont totalement ignorantes.

Il ne faut pas surdimensionner l'équipe de développeurs en terme de compétences ou de diplômes si le projet s'étale sur plus de six mois. Cette tendance permise par la conjoncture actuelle conduit rapidement à l'insatisfaction et à la démotivation.

Contrairement à des idées reçues, les programmeurs excessivement compétents et techniques sont à éviter. Tout au moins lorsqu'ils s'attachent à mettre en œuvre l'intégralité de leur astucieux savoir. En effet, les langages de développement sous Windows disposent d'un nombre impressionnant de fonctions complexes. La diversité des solutions possibles est telle que la maintenance d'un module réalisé par un "top" développeur peut devenir presque inexploitable après son départ.

Les membres de l'équipe n'ayant pas l'expérience du RAD doivent bénéficier d'une formation théorique abordant les principes de conduite d'entretien, de modélisation directe et de prototypage actif.



Le RAD : objectifs, équipe et communications

Une équipe qui ne communique pas formellement dans un cadre déterminé et qui n'est pas parfaitement coordonnée, est inefficace et passe son temps à corriger ses propres erreurs. La mauvaise distribution des tâches, l'excès de parallélisme, la sous-estimation chronique du volume de travail détruira les meilleures bonnes volontés individuelles de même qu'une utilisation dogmatique de la méthodologie. Il faut donc s'attacher à rechercher le réalisme et non pas vouloir à tout prix faire "entrer" la planification dans les délais en la manipulant sans vergogne. Si l'on est confronté à un problème de ce genre, en RAD on révisera à la baisse les fonctionnalités : du projet, quitte à revenir sur cette décision si la réalité le permet ensuite.

La vrai clé de la productivité est le développeur de haut niveau qui sait intégrer la conception détaillée et la réalisation. Le principal outil du développeur de demain sera son carnet de chèques.

L'expérience et la disponibilité d'une bibliothèque de produits complémentaires (OCX, ADD-ON, ADD-IN, Active X), de modules réutilisables et de transactions de bases permettent une productivité plus de dix fois supérieure à celle d'un couple analyste et programmeur classique.

Jacques Printz confirme : "Le processus de développement dont le moteur est l'individu réel organisé en équipe, est le cadre incontournable dans lequel s'expriment outils et méthodes (et non l'inverse comme certains l'ont cru bien imprudemment). L'intégration joue désormais un rôle central autour duquel s'articulent les politiques d'acquisition et de réutilisation. Le processus de développement est intégré aux AGL ".

L'avenir du développement passe par une évolution des prestations où le sens du service, celui de la méthode, de l'économie et de l'innovation sont entremélés et fédérés.



www.RAD.fr ® © Jean-Pierre Vickoff