Développement rapide d'applications

de développement logiciel adaptatives et la méthode de développement rapide de James Martin . De manière générale, les approches RAD privilégient un processus adaptatif plutôt que la planification. Les prototypes sont souvent utilisés en complément, voire parfois à la place, des spécifications de conception.

Le développement rapide d' applications (RAD) est particulièrement adapté (mais pas exclusivement) au développement de logiciels axés sur les exigences d'interface utilisateur . Les outils de création d'interfaces graphiques sont souvent appelés outils de développement rapide d'applications. Parmi les autres approches de développement rapide, on trouve les modèles adaptatif , agile , en spirale et unifié .

Le développement rapide d'applications (RAD) est apparu en réponse aux processus en cascade , planifiés et structurés , développés dans les années 1970 et 1980, tels que la méthode SSADM ( Structured Systems Analysis and Design Method ). L'un des problèmes de ces méthodes réside dans leur fondement sur un modèle d'ingénierie traditionnel, utilisé pour concevoir et construire des ouvrages comme les ponts et les bâtiments. Or, le logiciel est un artefact fondamentalement différent. Il peut modifier le processus de résolution d'un problème. De ce fait, les connaissances acquises lors du développement lui-même peuvent enrichir les exigences et la conception de la solution. Les approches planifiées visent à définir les exigences, la solution et le plan de mise en œuvre, et leur processus décourage les modifications. Les approches RAD, quant à elles, reconnaissent que le développement logiciel est un processus à forte intensité de connaissances et proposent des processus flexibles permettant d'exploiter les connaissances acquises au cours du projet afin d'améliorer ou d'adapter la solution.

La première alternative RAD de ce type a été développée par Barry Boehm et était connue sous le nom de modèle en spirale . Boehm et d'autres approches RAD ultérieures ont mis l'accent sur le développement de prototypes, en complément ou à la place de spécifications de conception rigoureuses. Les prototypes présentaient plusieurs avantages par rapport aux spécifications traditionnelles :

Réduction des risques. Un prototype permet de tester dès le début du cycle de vie certaines des parties les plus complexes du système . Cela fournit des informations précieuses sur la faisabilité d'une conception et évite à l'équipe de s'engager dans des solutions trop complexes ou trop longues à mettre en œuvre. Cet avantage de détecter les problèmes plus tôt dans le cycle de vie est un atout majeur de l'approche RAD. Plus un problème est détecté tôt, moins il est coûteux à résoudre.
Les utilisateurs sont plus à l'aise avec l'utilisation et la réaction qu'avec la rédaction de spécifications. Dans le modèle en cascade, il était fréquent qu'un utilisateur valide un ensemble d'exigences, puis, face à un système implémenté, réalise soudainement qu'une conception donnée manquait de fonctionnalités essentielles ou était trop complexe. En général, la plupart des utilisateurs fournissent des retours beaucoup plus utiles lorsqu'ils peuvent expérimenter un prototype du système en fonctionnement plutôt que de définir abstraitement ce que ce système devrait être.
Les prototypes peuvent être utilisables et évoluer vers le produit final. Une approche utilisée dans certaines méthodes RAD consiste à construire le système sous forme d'une série de prototypes évoluant d'une fonctionnalité minimale à une fonctionnalité modérément utile, jusqu'au système final. Outre les deux avantages mentionnés précédemment, cette approche présente l'avantage de permettre aux utilisateurs d'accéder à des fonctionnalités métier utiles beaucoup plus tôt dans le processus.

S'appuyant sur les idées de Barry Boehm et d'autres, James Martin a développé l'approche de développement rapide d'applications (RAD) dans les années 1980 chez IBM , avant de la formaliser en publiant un ouvrage en 1991, * Rapid Application Development* . Cette publication a engendré une certaine confusion autour du terme RAD, même parmi les professionnels de l'informatique. Il est important de distinguer le RAD en tant qu'alternative générale au modèle en cascade et le RAD en tant que méthode spécifique créée par Martin. La méthode Martin était conçue pour les systèmes d'information métier à forte intensité de connaissances et d'interface utilisateur.

Ces idées ont été développées et perfectionnées par des pionniers du RAD tels que James Kerr et Richard Hunter, auteurs de l'ouvrage de référence sur le sujet, *Inside RAD* , qui relate le parcours d'un chef de projet RAD mettant en œuvre et affinant la méthodologie RAD en temps réel sur un projet concret. Ces praticiens, et d'autres comme eux, ont contribué à populariser le RAD comme alternative aux approches traditionnelles du cycle de vie des projets systèmes.

L'approche RAD a également mûri durant la période de fort intérêt pour la réingénierie des processus métier . L'idée de la réingénierie des processus métier consistait à repenser radicalement les processus clés tels que les ventes et le support client, en tenant compte des nouvelles possibilités offertes par les technologies de l'information. La méthode RAD constituait souvent un élément essentiel des programmes de réingénierie des processus métier de plus grande envergure. Son approche de prototypage rapide était un outil clé permettant aux utilisateurs et aux analystes de sortir des sentiers battus et d'envisager des solutions innovantes pour que la technologie puisse réinventer radicalement un processus métier fondamental.

Le confort de James Martin avec le RAD provenait en grande partie de la division d'ingénierie de l'information de Dupont et de son responsable, Scott Schultz, ainsi que de leurs relations respectives avec John Underwood, qui dirigeait une société de développement RAD sur mesure ayant été pionnière dans de nombreux projets RAD réussis en Australie et à Hong Kong.

Parmi les projets couronnés de succès, on peut citer ANZ Bank , Lendlease , BHP , Coca-Cola Amatil , Alcan , le Hong Kong Jockey Club et bien d'autres.

Ce succès a conduit Scott Shultz et James Martin à passer du temps en Australie avec John Underwood pour comprendre les méthodes et les détails expliquant le succès disproportionné de l'Australie dans la mise en œuvre de projets RAD essentiels à la mission.

L'approche de James Martin

Phases de l'approche RAD de James Martin

L'approche RAD de James Martin divise le processus en quatre phases distinctes :

Phase de planification des exigences – Cette phase combine des éléments des phases de planification et d'analyse du système du cycle de vie du développement logiciel (SDLC). Utilisateurs, gestionnaires et membres de l'équipe informatique discutent et s'accordent sur les besoins métiers , le périmètre du projet , les contraintes et les exigences du système. Elle se termine lorsque l'équipe s'accorde sur les points clés et obtient l'autorisation de la direction pour poursuivre.
Phase de conception utilisateur – Durant cette phase, les utilisateurs interagissent avec les analystes système et développent des modèles et des prototypes représentant l'ensemble des processus, entrées et sorties du système . Les groupes ou sous-groupes RAD utilisent généralement une combinaison de techniques de conception conjointe d'applications (JAD) et d'outils CASE pour traduire les besoins des utilisateurs en modèles fonctionnels. La conception utilisateur est un processus interactif continu qui permet aux utilisateurs de comprendre, de modifier et, finalement, d'approuver un modèle fonctionnel du système répondant à leurs besoins.
Phase de construction – se concentre sur le développement de programmes et d'applications, à l'instar du cycle de vie du développement logiciel (SDLC). En RAD, cependant, les utilisateurs continuent de participer et peuvent suggérer des modifications ou des améliorations au fur et à mesure du développement des écrans ou des rapports. Ses tâches comprennent la programmation et le développement d'applications, le codage , l'intégration unitaire et les tests système .
Phase de basculement – Elle correspond aux dernières tâches de la phase d'implémentation du cycle de vie du développement logiciel (SDLC), notamment la conversion des données, les tests, la migration vers le nouveau système et la formation des utilisateurs. Comparée aux méthodes traditionnelles, l'ensemble du processus est raccourci. Par conséquent, le nouveau système est construit, livré et mis en service beaucoup plus rapidement.

Avantages

Dans les environnements informatiques modernes, de nombreux systèmes sont désormais construits selon une approche de développement rapide d'applications (RAD) (pas nécessairement l'approche de James Martin). Outre la méthode de Martin, les méthodes agiles et le processus unifié rationnel (RUP) sont souvent utilisés pour le développement RAD.

Les avantages supposés du RAD comprennent :

Une meilleure qualité. En permettant aux utilisateurs d'interagir avec des prototypes évolutifs, les fonctionnalités métier d'un projet RAD sont souvent bien supérieures à celles obtenues avec un modèle en cascade. Le logiciel est plus convivial et a davantage de chances de se concentrer sur les problèmes métier essentiels aux utilisateurs finaux plutôt que sur les problèmes techniques qui intéressent les développeurs. Cependant, cela exclut d'autres catégories d'exigences généralement appelées exigences non fonctionnelles (également connues sous le nom de contraintes ou attributs de qualité), telles que la sécurité et la portabilité .
Maîtrise des risques. Bien que la plupart des écrits sur le développement rapide d'applications (RAD) mettent l'accent sur la rapidité et l'implication des utilisateurs, la gestion des risques est un élément essentiel d'une démarche RAD réussie. Il est important de rappeler que Boehm a initialement caractérisé le modèle en spirale comme une approche fondée sur les risques. Une approche RAD permet de se concentrer dès le début sur les principaux facteurs de risque et de s'y adapter en fonction des données empiriques recueillies au début du processus. Par exemple, la complexité du prototypage de certaines des parties les plus complexes du système.
Davantage de projets sont menés à bien dans les délais et les budgets impartis. En privilégiant le développement d'unités incrémentales, on réduit les risques d'échecs catastrophiques qui ont entravé les grands projets en cascade. Dans le modèle en cascade, il était fréquent de constater, après six mois ou plus d'analyse et de développement, la nécessité de repenser radicalement l'ensemble du système. Avec le RAD, ce type d'information peut être découvert et exploité plus tôt dans le processus.

Inconvénients

Les inconvénients supposés du RAD incluent :

Le risque d'une nouvelle approche. Pour la plupart des services informatiques, le RAD représentait une approche inédite qui exigeait des professionnels expérimentés qu'ils repensent leurs méthodes de travail. L'être humain est presque toujours réticent au changement et tout projet entrepris avec de nouveaux outils ou méthodes a plus de chances d'échouer dès la première tentative, ne serait-ce que parce que l'équipe a besoin d'apprendre.
Le manque d'importance accordée aux exigences non fonctionnelles , qui ne sont souvent pas visibles pour l'utilisateur final en fonctionnement normal.
Cela exige du temps et des ressources précieuses. Un point commun à presque toutes les approches RAD est l'interaction accrue entre utilisateurs et développeurs tout au long du cycle de vie du projet. Dans le modèle en cascade, les utilisateurs définissent les exigences puis se retirent progressivement, laissant les développeurs créer le système. En RAD, les utilisateurs sont impliqués dès le début et pendant la quasi-totalité du projet. Cela suppose que l'entreprise soit disposée à investir le temps d'experts du domaine applicatif. Le paradoxe est que plus l'expert est compétent, plus il maîtrise son domaine, plus il est sollicité pour la gestion opérationnelle et plus il peut être difficile de convaincre sa hiérarchie d'investir son temps. Sans un tel engagement, les projets RAD sont voués à l'échec.
Moins de contrôle. L'un des avantages du RAD est sa flexibilité et son adaptabilité. L'idéal est de pouvoir s'adapter rapidement aux problèmes comme aux opportunités. Il existe un compromis inévitable entre flexibilité et contrôle : plus de l'une signifie moins de l'autre. Si un projet (par exemple, un logiciel critique ) privilégie le contrôle à l'agilité, le RAD n'est pas approprié.
Conception médiocre. L'importance accordée aux prototypes peut parfois être excessive et aboutir à une méthodologie de type « bricolage et test », où les développeurs modifient constamment des composants individuels en ignorant les problèmes d'architecture système qui permettraient d'obtenir une meilleure conception globale. Cela peut s'avérer particulièrement problématique pour les méthodologies telles que celle de Martin, qui mettent fortement l'accent sur l'interface utilisateur du système.
Manque d'évolutivité. La méthode RAD s'adresse généralement aux petites et moyennes équipes de projet. Les autres problèmes mentionnés ci-dessus (moins de conception et de contrôle) présentent des défis particuliers lorsqu'on utilise une approche RAD pour des systèmes de très grande envergure.