Comprendre le modèle de développement rapide d'applications

Publié: 2022-09-11

Comprendre le modèle de développement rapide d'applications

Le développement rapide d'applications, ou RAD, est une méthode de développement logiciel qui met l'accent sur l'étape de planification et de prototype pour obtenir un retour rapide des utilisateurs. Par rapport aux méthodes plus conventionnelles de développement de logiciels, qui incluent la conception préliminaire et la mise en œuvre ultérieure, RAD met l'accent sur plus de flexibilité. Des cycles constants d'entrées d'utilisateurs et des améliorations incrémentielles rapides aident à obtenir de meilleurs résultats à la fin de la journée.

Dans les années 1990, James Martin a défini le développement rapide d'applications comme une alternative aux procédures conventionnelles en cascade. La méthode traditionnelle en cascade est une excellente solution pour l'industrie de la construction et de nombreux autres domaines où les modifications de l'étendue des travaux sont rares et coûteuses. Il est assez improbable que vous passiez à la construction d'un ferry à mi-chemin de la construction d'un pont si vous aviez déjà commencé la construction du pont.

L'évolution des logiciels permet une plus grande adaptabilité. Une gamme plus large d'approches peut être utilisée pour résoudre la même difficulté commerciale, et des modifications peuvent être apportées à moindre coût. Par conséquent, les entreprises sacrifient une conception et une planification précises au profit d'un processus itératif utilisant des essais et des erreurs. De plus, lorsque les consommateurs constatent une amélioration, ils sont plus enclins à faire des critiques constructives.

Le développement rapide d'applications est-il la bonne approche pour mon projet ?

Comme nous l'avons expliqué précédemment, RAD ne fonctionne pas dans des contextes inflexibles. Elle ne s'applique pas dans les situations suivantes :

  • Il est nécessaire d'avoir une connaissance préalable à la fois des contraintes financières et des échéanciers.
  • Soit vous n'avez pas un accès cohérent aux utilisateurs, soit ils ne sont pas motivés à consacrer leur temps et leurs efforts au projet.
  • De par son ampleur, le projet fait appel à la participation d'un nombre important de personnes, souvent appelées parties prenantes.

Ces restrictions s'appliquent souvent aux grandes entreprises et organisations gérées par le gouvernement. D'un autre côté, certains aspects du processus de développement rapide d'applications s'appliquent même dans ces situations. Par exemple, les projets avec un prix fixe peuvent allouer des fonds pour l'étape du prototype et un certain nombre de révisions. Si vous avez les utilisateurs appropriés à bord, vous pourrez peut-être restreindre la portée du prototype aux parties les moins claires.

D'autre part, un cadre de développement d'applications rapide fonctionne très bien pour les petites et moyennes organisations et les projets départementaux. C'est aussi longtemps que les utilisateurs professionnels possèdent l'argent et ont la volonté d'atteindre le résultat. Ceci est une excellente illustration des nombreuses applications métier (LOB). Une expression générique fait référence à des logiciels qui automatisent et exploitent plus efficacement certains aspects d'une entreprise.

De même, RAD est une approche efficace lors du développement de sites Web. Ce sont souvent des projets modestes avec un groupe restreint d'acteurs, mais il est essentiel de les inclure très tôt car le design est un sujet très controversé, et tout le monde aura son mot à dire !

Phases et méthodologie

L'étape de planification chronophage est remplacée par la phase de prototype moins coûteuse dans le cadre de l'approche de développement rapide d'applications. Plus précisément, le modèle RAD suggère de séparer le processus en quatre étapes :

Planification des besoins

Les utilisateurs et l'équipe du projet travailleront ensemble durant cette phase pour déterminer les objectifs du futur système. Le succès de l'entreprise est la principale préoccupation. Les normes ne sont pas très strictes. La capacité de les modifier ou de les adapter alors que le prototype est encore en cours de développement est essentielle.

Conception utilisateur

La technique de développement rapide d'applications se différencie du modèle traditionnel en cascade en mettant l'accent sur la conception de l'utilisateur comme élément fondamental du processus. A ce stade, la première chose que font les développeurs est de travailler sur un prototype. L'objectif est de montrer rapidement et à moindre coût quelque chose au client, tout ce qui doit être démontré. Ce n'est pas un facteur décisif si le prototype ne peut satisfaire qu'à certains des critères ou ne peut gérer qu'un sous-ensemble des situations possibles. Il est permis de prendre des raccourcis en matière de codage.

Une fois le prototype terminé, il est présenté aux utilisateurs pour commentaires. L'équipe recueille le maximum de contributions et, à ce stade, les critères essentiels sont susceptibles de modifications inévitables. Quelque chose qui avait du sens lorsqu'il était écrit peut prendre une apparence différente lorsqu'il est mis en pratique. Lorsque les développeurs ont cette entrée, ils reviennent au processus de prototype et continuent jusqu'à ce que les consommateurs soient satisfaits du résultat final.

Construction

À ce stade, nous sommes pleinement conscients des exigences à respecter. Il est temps de terminer le développement et les tests du système afin de le préparer à une utilisation en production. Il n'y aura plus de raccourcis ; au lieu de cela, l'accent sera mis sur la qualité, l'évolutivité, la maintenabilité et d'autres facteurs. Cependant, même à ce stade tardif, les consommateurs continuent d'interagir en offrant des commentaires lorsque de nouvelles fonctionnalités sont introduites. À ce stade du processus itératif de développement d'une application rapide, il reste encore de la place pour des ajustements supplémentaires.

Selon l'outil que nous finirons par utiliser et les autres facteurs impliqués, le travail que nous avons effectué jusqu'à présent dans le processus de prototypage pourrait même ne pas être utilisable.

Basculement

Il s'agit de la dernière étape, qui comprend la formation des utilisateurs, les tests d'acceptabilité et la mise en œuvre du nouveau système.

Développement rapide d'applications Vs. Agile

Le nom "RAD" a été inventé dix ans avant la méthodologie de développement Agile, et en raison de sa méthodologie itérative, RAD est parfois désigné comme un "parent" d'Agile. D'un autre côté, ce n'est pas la situation. Agile est un point de vue philosophique qui englobe bien plus que le simple développement de logiciels, contrairement à RAD, qui est une technique de développement prescriptive.

Il est prudent de supposer que le développement rapide d'applications (RAD) fait partie de la même famille que d'autres approches de développement logiciel agiles, telles que Scrum, Kanban et bien d'autres.

Avantages et inconvénients du développement rapide d'applications

L'accent s'éloigne de la prévisibilité et se tourne vers l'adaptabilité en raison du RAD, ce qui a à la fois de bonnes et de mauvaises implications.

Avantages :

Frais et dangers réduits

Les utilisateurs ne peuvent visualiser les résultats de la méthode et faire des commentaires qu'une fois que le projet leur a été livré. Les ajustements inévitables qui doivent être faits à ce stade sont à la fois coûteux en temps et en argent. Le risque de devoir réécrire la moitié de la solution après son implémentation est considérablement réduit lors de l'utilisation du processus de développement rapide d'applications.

Qualité supérieure

Le programme final s'appliquera probablement mieux aux activités des utilisateurs s'ils participent activement au processus de prototypage. De plus, quel que soit le résultat, il sera à la hauteur de leurs attentes.

Désavantages:

Mauvaise conception

Lorsque vous poursuivez des besoins commerciaux particuliers et que vous prenez des raccourcis au stade du prototype, vous risquez d'aller trop loin. De ce fait, il en résulte une conception et une solution globale médiocres.

Incapacité à évoluer efficacement

Le paradigme RAD présuppose que l'équipe et les utilisateurs finaux collaborent en étroite collaboration. Le processus de prototype évoluera toujours à un rythme glacial une fois que l'équipe est trop grande ou qu'il y a un nombre excessif de parties prenantes. De plus, il devient difficile d'expliquer les changements fréquents de la portée du projet à toutes les parties. Par conséquent, on pense que RAD fonctionne mieux pour les groupes de taille moyenne ou petite.

Engagement des clients sur le back-end

La technique de développement rapide d'applications anticipe une quantité substantielle d'entrées d'utilisateurs tout au long de la durée de vie du projet. Selon les rapports, cela est particulièrement vrai pour les professionnels les plus qualifiés de l'industrie, qui se trouvent également être les personnes les plus occupées de l'organisation.

Incapacité à exercer un contrôle

Avant la fin de l'étape de prototype du projet, il n'est pas possible de prévoir avec précision la portée, le budget ou le calendrier du projet pour des raisons apparentes. Cependant, selon les résultats du processus de planification des exigences, vous serez toujours en mesure d'établir certaines attentes générales.

équipe de développement

Outils pour le développement rapide d'applications (RAD)

L'application de l'approche RAD repose principalement sur un prototypage rapide et une coopération étroite. Par conséquent, la sélection des outils appropriés pour aider ces efforts est de la plus haute importance. Pour notre chance, il existe une vaste sélection parmi laquelle choisir.

Conception et Prototypage

Les technologies de développement d'applications rapides telles que Figma et InVision permettent aux concepteurs visuels et aux professionnels de l'UX de construire rapidement ensemble et de partager des prototypes cliquables avec les utilisateurs finaux. Ceux-ci ont une conception complète afin que les développeurs puissent recueillir les commentaires des utilisateurs. Dès qu'une des itérations du prototype reçoit le feu vert, ils peuvent exporter le projet dans des formats réutilisables par les développeurs front-end. Ainsi, marquant sa transition vers la phase de construction. Bien que la création de sites Web soit de loin l'utilisation la plus courante de ces outils, le prototypage de l'expérience utilisateur d'applications ou de portails d'utilisateurs finaux plus complexes est une autre utilisation.

Les analystes commerciaux utilisent beaucoup plus souvent d'autres applications, comme Balsamiq. Ils se concentrent sur la création d'un prototype de l'expérience utilisateur à l'aide de wireframes. Ensuite, ils mettent en œuvre la conception finale plus tard. Ce sont d'excellentes options pour la modélisation préliminaire de systèmes plus étendus qui incluent une interaction utilisateur complexe.

Développement

La phase de développement de l'établissement d'une application prend souvent le plus de temps, est la plus coûteuse et se heurte à l'incertitude la plus importante. Ainsi, les plates-formes actuelles de développement rapide d'applications intègrent des architectures testées. Ce sont des composants prêts à l'emploi qui implémentent des fonctionnalités standard et des outils qui facilitent le développement rapide. Chacun d'entre eux vous permet de fournir des résultats plus rapidement. Que vous soyez dans la phase de prototypage du projet ou plus loin dans la phase de construction.

Des sociétés de conseil comme Gartner et Forrester développent constamment de nouvelles nomenclatures pour différencier chacune de ces plateformes. Comprenant souvent les éléments suivants : plates-formes d'application Low-Code/No-Code (LCAP), plates-formes d'application à haute productivité en tant que service (HPAPaaS) et plates-formes de développement multi-expériences. Ce sont tous des exemples de différents types de plates-formes d'application (MXDP) que vous pouvez utiliser. Cependant, au final, chacun d'entre eux peut être catégorisé en fonction de son lectorat visé.

Plates-formes Low Code/No Code

Le concept fondamental derrière ces plates-formes est de permettre aux utilisateurs professionnels sans expertise en codage (également appelés utilisateurs avancés ou développeurs citoyens) de fournir rapidement des applications fonctionnelles. Cette simplicité s'accompagne bien sûr d'un manque de flexibilité et de diverses restrictions. Dans un article récent, j'aborde ces limites et leurs aléas. Par conséquent, le marché cible de ces plates-formes est constitué soit de prototypages, soit de solutions élémentaires.Plateformes axées sur les développeurs

Ces plates-formes capitalisent sur la rapidité et l'enthousiasme du développement logiciel. Principalement via la fourniture d'API de niveau supérieur et la production de code. Par conséquent, les programmeurs n'ont plus besoin d'écrire à plusieurs reprises du code passe-partout et d'implémenter des fonctionnalités standard.

Embarcadero RAD Studio, anciennement Borland Delphi, est l'un des pionniers de l'industrie. Ils sont bien connus pour leur conception d'interface utilisateur visuelle. Borland Delphi était son nom de famille. Il existait avant l'avènement du Web et peut toujours être utilisé pour les applications sur les ordinateurs de bureau et les appareils mobiles.

Le Web est la cible principale des autres frameworks de développement rapide d'applications. Parce que c'est la méthode la plus courante pour communiquer avec les consommateurs finaux de nos jours. Par exemple, chez Jmix, nous nous efforçons de combiner la facilité et la rapidité des modèles de données visuels et de la conception d'interface avec l'efficacité de la technologie open source d'aujourd'hui. Cette stratégie augmente le rythme auquel vous créez des prototypes. Cependant, cela vous donne également la possibilité de développer votre prototype en une application d'entreprise complète dotée d'une structure à la fois stable et évolutive.

Conclusion

L'une des approches de développement qui adhère à l'état d'esprit agile est le développement rapide d'applications (RAD). La participation active des utilisateurs finaux et le développement de prototypes rapides et itératifs utilisant les contributions de ces utilisateurs sont deux principes fondamentaux de la méthodologie RAD. Après s'être assuré de la satisfaction des utilisateurs finaux, l'attention se tourne ensuite vers la fourniture de logiciels adaptés à la production.

La sélection du ou des outils appropriés est essentielle pour assurer un prototypage rapide. En conséquence, l'utilisation efficace de la méthodologie RAD au sein d'un projet donné. La bonne nouvelle est qu'il existe une sélection variée d'outils et de plates-formes à utiliser. Ceux-ci répondent à différents types d'applications, phases d'un projet et ensembles de compétences pour les équipes.

Même si RAD est une idée ancienne, elle connaît actuellement un renouveau. Ceci est le résultat direct des tendances actuelles de la transformation numérique et de la volonté d'accélérer la mise sur le marché. Lorsqu'elle est utilisée pour les types de projets appropriés et avec les types d'équipes appropriés, l'approche RAD peut permettre d'obtenir une plus grande satisfaction des clients avec moins de risques et en moins de temps.