La méthode de développement rapide d'applications, dite méthode RAD (Rapid Application Development), est la première méthode de développement de logiciels où le cycle de développement est en rupture fondamentale par rapport celui des méthodes antérieures dites « en cascade ». Ce nouveau cycle qualifié d'itératif, d'incrémental et d'adaptatif, se retrouvera ensuite dans toutes les méthodes dites « agiles » publiées par la suite.

Aujourd’hui, la qualité et la 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élai court. C’est à cela que répond le RAD.

Les principales catégories de raisons du développement lent sont les suivantes :

• Reprise : refonte de plusieurs fois certaines activités de développement pour corriger les problèmes. Pour éviter la reprise, il faut s’assurer de connaître toutes les spécifications et contraintes globales de conception avant de débuter la construction. Plusieurs méthodes permettent de garantir des résultats de qualité.
• Fluctuation des spécifications : changement des spécifications durant le projet. Plus un changement survient tard dans un projet, plus il est coûteux. La plupart des projets de développement d’applications connaissent des fluctuations dans leurs spécifications. Les utilisateurs ne sont pas toujours sûr de ce qu’ils veulent au début du projet ; de plus, un environnement très dynamique peut aussi provoquer des changement avant la fin du projet Ignorer les changements importants aux spécifications ne peut que produire une application qui ne répond pas aux besoins des utilisateurs. Pour éviter l’extension du calendrier tout en satisfaisant les exigences des utilisateurs, un développeur doit anticiper les changements et les incorporer au processus de développement.
• Outils et techniques : l’emploi d’une outil ou d’une technique inadéquat pour un projet donné peut réduire la qualité du produit final et augmenter la durée de développement. Par exemple, le développement des systèmes de temps réel (en langage assembleur ou en C) ne demande pas les mêmes techniques et les mêmes outils que le développement des applications de gestions.

L’approche de développement séquentiel ou classique reste la façon la plus rapide de développer des applications lorsque l’incertitude quant aux spécifications et la faisabilité est faible. Mais lorsque la technologie est neuve ou que les spécifications ne peuvent être toutes définies entièrement, il faut réorganiser les techniques et, éventuellement, une approche de développement qui ne sera plus séquentielle. L’approche RAD s'applique bien dans le cadre de petites applications de gestion, n'ayant pas de cycle de vie d'une trop longue durée.

La méthode RAD, après deux courtes phases de formalisation structurée de l'expression des besoins (Cadrage) et de définition globale de l'architecture technique (DESIGN), inclut dans sa phase principale (Contruction) la réalisation, la validation immédiate et les tests d'une application en mode itératif-incrémental-adaptatif. L'objectif de la méthode, qui implique activement l'utilisateur final dans un principe de “validation permanente”, est d'obtenir un applicatif en adéquation avec les réels besoins.

SWAT (Skilled With Advanced Tools) → Désignation d'une équipe de travail non hiérarchisée ou chaque intervenant est compétent sur l'ensemble des aspects d'un projet, outre sa spécialisation sur l'un de ceux-ci.

James Martin a développé l'approche RAD au cours des années 1980, à IBM, en se basant sur les idées de Brian Gallagher, Alex Balchin, Barry Boehm et Scott Shultz. Il l'a formalisée en la publiant en 1991. Des compléments et des actualisations sont introduits à partir de 1994, notamment par Jean-Pierre Vickoff pour l'aspect francophone (processus RAD2 publié par le Gartner Group) et Jennifer Stapleton en Grande-Bretagne (processus DSDM).

L’apport de J. Martin avec la méthode RAD fut de formaliser techniquement le premier postulat « agile », à savoir que pour qu'une prédiction de projet puisse se réaliser à tous les coups, il fallait que certains aspects du pilotage soient fixes et que d’autres soient variables. Il proposa des techniques de priorisation pour gérer les deux principales variantes possibles de ces situations (délais fixe ou budget fixe). Les notions additionnelles de visibilité, de risque et de fiabilité (ou de qualité) comme variables de planification stratégique d’un projet furent introduites plus tard.

La méthode RAD implique :

• Un cycle de développement sécurisant et court fondé sur un phasage simple : Cadrage, Design, Construction et l’absolu respect d’une dimension temporelle (90 jours optimum, 120 jours maximum).
• Une architecture de communication engageant des groupes de travail de structure et de composition variable selon les besoins des phases et respectant un mode opératoire précis structuré en trois étapes : pré-session, session, post-session.
• Des méthodes, techniques et outils permettant de définir et d’appliquer des choix portant sur quatre natures d'objectifs potentiellement contradictoires : budget, délais, qualité technique, qualité fonctionnelle et visibilité.
• Une architecture de conception s’appuyant sur les techniques de l'objet et particulièrement sur celles qui permettent une conception «en vue de modifications».
• Une architecture de réalisation qui impose, pour garantir la qualité technique, des normes minimales, des revues de projet, des jalons zéro-défaut et qui recommande, pour garantir la qualité fonctionnelle, le prototypage actif et les focus de visibilité.

La méthode RAD structure le cycle de vie du projet en 5 phases (dont 3 systématiques) :

1. L’initialisation prépare l’organisation, puis détermine le périmètre et le plan de communication.
2. Le cadrage définit un espace d’objectifs, de solutions et de moyens.
3. Le design modélise la solution et valide sa cohérence systémique.
4. La construction réalise en prototypage actif (validation permanente).
5. La finalisation est réduite à un contrôle final de qualité en site pilote.

Préparation de l’organisation et communication. Cette phase permet de définir le périmètre général du projet, de structurer le travail par thèmes, de sélectionner les acteurs pertinents et d’amorcer une dynamique de projet. Cette phase représente environ 6% du projet en charge.

Analyse et expression des exigences. La spécification des exigences est du ressort des utilisateurs. Ils expriment leurs besoins lors d’entretiens de groupe. Il est généralement prévu de 2 à 5 jours de sessions par commission (thème). Cette phase représente environ 9% du projet.

Conception et modélisation. Les utilisateurs sont également impliqués dans cette étape. Ils participent à l’affinage et à la validation des modèles organisationnels : flux, traitements, données. Ils valident également le premier niveau de prototype présentant l’ergonomie et la cinématique générale de l’application. Il est prévu entre 4 et 8 jours de sessions par commission. Cette phase représente environ 23% du projet. A partir de la phase de Design la parallélisation du travail est possible.

Réalisation, prototypage. Durant cette phase, l’équipe RAD (SWAT) doit construire l’application module par module. L’utilisateur participe toujours activement aux spécifications détaillées et à la validation des prototypes. Plusieurs sessions itératives sont nécessaires. Cette phase représente environ 50% du projet. A partir de la phase de Construction, à la parallélisation du travail peut s’ajouter la sérialisation.

Recette et déploiement. Des recettes partielles ayant été obtenues à l’étape précédente, il s’agit dans cette phase d’officialiser une livraison globale et de transférer le système en exploitation et maintenance. Cette phase représente environ 12% du projet.

Le Jalon ZD (Zéro Défaut) est une intégration de l'itération journalière validée techniquement et fonctionnellement. Le FOCUS (ou SHOW) est une présentation de l'itération de livraison venant de s'achever. Cette démonstration est effectuée par le ou les utilisateurs impliqués dans le prototypage à destination de l'ensemble des autres intervenants du projets. Pour pousser à l'extrême la qualité du code, ces étapes peuvent être remplacées par les pratiques XP d'ingénierie du logiciel.

La méthode, sans être liée aux outils, recommande l'utilisation d'outils de programmation à interface graphique (CASE), qui permettent d'obtenir rapidement des prototypes. A ce sujet, il ne faut pas confondre la méthode RAD (d'où sont issues les approches Agiles actuelles) qui recherche la qualité applicative fonctionnelle et technique avec les outils RAD, dont la production automatique de code est souvent qualifiée de “sale”.

• BLU AGE est un outil RAD permettant de transformer un modèle UML en application finale JAVA ou .Net.
• Powerbuilder
• Delphi (ainsi que le Visual Basic) est un outil RAD en ce sens qu'il permet assez facilement de créer des programmes à l'aide d'une interface graphique dotée de nombreux outils et de modules prêts à l'emploi.
• WinDev (ainsi que WebDev) est un outil RAD plus avancé car il permet à partir d'une analyse Merise ou UML de produire un applicatif final et opérationnel. WinDev Mobile permet lui de créer rapidement des applications pour les matériels mobiles.
• Authorware crée lui-aussi un applicatif final en dessinant un diagramme à l'aide d'icônes.
• JBuilder
• C++ Builder
• C# Builder
• Leonardi est un outil RAD adapté au développement des IHM.
• Limbas est un outil RAD 100% web (developpement et application cible) sous license GNU GPL 2 incluant notamment des fonctionnalités GED et Groupware.
• Visual Studio, autre outil RAD, permet de développer en visual basic, C++, C# entre autres. Edité par Microsoft.

Le prototypage est un processus de construction d’un modèle de système entièrement ou partiellement fonctionnel qui ressemble et agit le plus possible comme un véritable système. Le développement d’applications fait appel à deux genres courants de prototypes :

• Le prototype de découverte ou prototype rapide (maquette) : utilisé pour découvrir ou affiner les spécifications ou les paramètres de conception d’une application (phase d’analyse et parfois de conception).
  • Il est construit et utilisé lors des phases d’analyse des besoins et de spécifications fonctionnelles et permet la validation des spécifications par l'expérimentation (« Je saurai ce que je veux quand je le verrai ! »).
  • Il permet au client et au développeur de bien se mettre d'accord sur la nature du produit à réaliser et en particulier sur l'interface et les fonctionnalités. La notion de rapide est importante car cette phase conditionne tout la suite du cycle de vie et permet de raccourcir la durée des allers/retours client/développeur pendant la phase d'analyse des besoins.

GRAPHIQUE

• Le prototype expérimental : utilisé au niveau de la conception pour s'assurer de la faisabilité de parties critiques et valider des options de conception. Exemple : Prototype d'un analyseur syntaxique avec une grammaire réduite

GRAPHIQUE

• Ce prototype est en général jeté après développement. Il peut aussi être gardé, on parle alors de prototype évolutif.

• Le prototype évolutif : développé de façon itérative jusqu’à devenir le système final

La première version du prototype est l'embryon du produit final. Exemple : Développement d'un système expert GRAPHIQUE

Avec cette approche, il est très difficile de mettre en oeuvre des procédures de validation et de vérification. Cette méthode est à rapprocher du cycle de vie en spirale et du développement incrémental.

On utilise surtout les prototypes expérimentaux dans le cadre du développement itératif. D’ordinaire, on élabore un prototype simple auquel on ajoute des fonctionnalités au cours des phases ultérieures du développement.

L’approche de développement par prototypage est une approche fondée sur le raffinement itératif d’un prototype expérimental.

1. La phase de planification est la même que dans le processus de développement des applications séquentiel.
2. La phase d’analyse peut être réalisée avec les techniques classiques ou orientées objets à condition de compatibilité de celle de conception et de mise en oeuvre. Les modèles d’analyse peuvent être moins détaillés que ceux de l’approche classique (exigences non spécifiés).
3. La phase de conception fonctionnelle établit les paramètres de conception de haut niveau et l’environnement d’implantation.
4. La phase de l’analyse et de conception de prototypes définit des spécifications et la conception d’un prototype ou d’une version de prototype unique.
5. La phase des essai et d’évaluation des prototypes détermine si le prototype satisfait les objectifs de l’itération en cours et s’il faut ajouter d’autres itérations ce qui peut modifier le plan de développement ou, dans certains cas inhabituels, la conception fonctionnelle.
6. La phase d’implémentation supplémentaire permet d’implémenter les spécifications omises (opérations de sauvegarde, et de récupération, les mesures globales de sécurité du système, etc).

L’analyse planifie le restant des activités de conception et de la mise en œuvre en définissant une série de prototypes ou de modifications à ces prototypes. D’ordinaire, les spécifications sont divisées en sous-ensembles reposant sur les fonctions spécifiques (entrée des commandes, exécutions des commandes et achats, etc) et sur les limites architecturales de l’application (client-serveur, trois, tiers, etc)

Une fois la série des prototypes définie, la conception détaillée et l’implémentation se suivent de manière itérative. Chaque cycle commence par la définition des spécifications et la conception d’un prototype ou d’une version de prototype unique incluant les aspect d’analyse non terminés précédemment (les spécifications détaillées de l’interface d’utilisateur, par exemple)

On peut parfois omettre certaines spécifications de l’application pendant le cycle de développement des prototypes et les terminer après le cycle final (opérations de sauvegarde, et de récupération, les mesures globales de sécurité du système). Les spécifications qui ne font appel à aucun interface d’utilisateur et celle qui ont des répercussions sur l’ensemble du système sont d’habitude, de bonnes candidates à une mise en œuvre post-prototypage.

Le développement d’applications par prototypage est choisi si :

• Une partie des spécifications ne peut être entièrement définie indépendamment de la conception fonctionnelle ou détaillée.
• La faisabilité technique de certaines des fonctions de l’application est inconnue ou douteuse.
• Les outils de développement de prototypes sont assez puissants pour créer un système tout à fait fonctionnel.

Dans ces conditions le développement par prototypages est plus rapide que le développement classique. Mais lorsque les incertitudes sont trop importantes et les aspects de la conception fonctionnelle et de la faisabilité technique ne sont pas définies en majorité, d’autres techniques et approches peuvent être mieux adaptées.

Le développement d’applications par prototypage ne s’applique pas aux applications ou auxparties des applications qui sont:

• Non interactives : pas d’interactions avec les utilisateurs (génération automatique des commandes aux fournisseurs, traitement de paie,…).
• Complexe du point de vue interne : utilisent des algorithmes complexes (programme de planification des livraisons pour accélérer le temps d’exécution et réduire les coûts).
• Soumises à des exigences rigoureuses de performance ou de sécurité (génération de milliers de paiement électronique par heure).

Dans ces conditions le développement séquentiel classique fondé sur des modèles de conception structurés ou orientés objets est plus approprié.

L’exigence clé d’un bon outil de prototypage est la vitesse de développement. La possibilité de construire et d’examiner de nombreux prototypes est vitale pour obtenir les spécifications exactes et complètes des utilisateurs et pour déterminer la faisabilité technique par l’expérimentation.

Les bons outils de prototypage sont souples et puissante, ils utilisent une approche hautement interactive et d’autres techniques, comme :

• Le développement WYSIWYG des composants de l’interface d’utilisateur.
• La génération de programmes complets, de squelettes de programmes et de schémas de bases de données à partir de modèles graphiques ou de gabarits d’applications.
• Des possibilités perfectionnées de vérification d’erreurs et de débogage.

Le choix d’un outil de prototypage dépend de :

• Type du projet de développement (les applications de gestion utilisant des SGBD et le développement de sites Web ne vont pas utiliser le même outil de prototypage)
• Pertinence à l’environnement technique dans lequel l’application sera déployé (on ne peut pas utiliser comme outil de prototypage Access 2007 pour l’environnement de déploiement avec l’ordinateur central IBM supportant des milliers d’utilisateurs interactifs).
• Possibilité d’implémenter toutes les applications du système
• Capacité d’interfacer avec des logiciels développés avec d’autre outils (les outils sont de plus en plus compatibles actuellement – standards et normes)

Exemples des outils de prototypage :

• VB de Microsoft
• PowerBuilder
• Oracle Developer
• Oracle Designer
• Rational Rose

L’approche de développement en spirale est une approche de développement itératif où chaque itération peut inclure une combinaison d’étapes de planification, d’analyse, de conception et de mise en œuvre. Les principes de l’approche en spirale:

• Identifier les risques, leur affecter une priorité
• Développer des prototypes pour réduire les risques, en commençant par le plus grand risque
• Utiliser un modèle séquentiel classique pour implémenter chaque cycle de développement
• Contrôler :
  • si un cycle concernant un risque est achevé avec succès, évaluer le résultat du cycle, planifier le cycle suivant
  • si le risque est non résolu, interrompre le projet

Les caractéristiques principales du développement en spirale sont :

• Utilisation du prototypage
• Analyse (progressive) des risques

Risques technologiques :

• exigences démesurées par rapport à la technologie
• incompréhension des fondements de la technologie
• problèmes de performance
• dépendance en un produit soi-disant miracle
• changement de technologie en cours de route
• etc

Risques liés au processus :

• gestion projet mauvaise ou absente
• calendrier et budget irréalistes
• calendrier abandonné sous la pression des clients
• composants externes manquants
• tâches externes défaillantes
• insuffisance de données
• invalidité des besoins
• développement de fonctions inappropriées
• développement d'interfaces utilisateur inappropriées
• etc

Risques humains

• défaillance du personnel
• surestimation des compétences
• travailleur solitaire
• héroïsme
• manque de motivation
• etc

Étape 1. Phase de la panification initiale qui a pour but de recueillir juste assez d’information pour commencer le développement d’un prototype de départ. Les activités sont les suivantes :

• Une étude de faisabilité ;
• Un sondage des exigences de haut niveau des utilisateurs ;
• L’élaboration de solution d’implémentation ;
• Le choix d’une stratégie globale de conception et de mise en œuvre.

Remarque : Une différence fondamentale entre l’approche en spirale et celle par prototype est les détails des spécifications des utilisateurs et de la conception du logiciel. L’approche en spiral utilise moins de détail.

Étape 2. Phase de la réalisation d’un prototype et de la panification du prototype suivant. Pour chaque prototype le processus de développement suit un chemin séquentiel à travers l’analyse, la conception, la construction, les essais, l’intégration au composantes existante du prototype et la planification du prototype suivant. Déterminer les fonctions à implémenter dans chaque prototype est une décision importante basée sur :

• Les priorités des utilisateurs (obligatoire, nécessaire, souhatable) ;
• Les spécifications douteuses (prototypes précoce);
• La réutilisation de la fonction (prototypes précoce);
• Le risque lié à la mise en œuvre (prototypes précoce).