Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Extrait de La Lettre de l’ADELI N°27 - Avril 1997 1 Le RAD (Rapid Application D

Extrait de La Lettre de l’ADELI N°27 - Avril 1997 1 Le RAD (Rapid Application Development) Quels outils pour quelle méthode ? Conçue à la fin des années 80 par James Martin et associés, la méthodologie RAD (Rapid Application Development) a beaucoup fait parler d’elle, essentiellement au travers des outils qui s’y réfèrent. Quel est le rapport entre la première et les seconds ? Six ans après l’introduction du terme, quel bilan peut-on en tirer ? La méthode est-elle dépassée ? Les outils tiennent-ils leurs promesses ? La méthodologie La méthode a été décrite pour la première fois par James Martin en 1991. Bien qu’elle ait pu avoir évolué depuis, c’est cet imposant ouvrage (plus de 750 pages) qui nous servira de référence pour la suite. Remarquons d’emblée que le livre ne décrit pas seulement une méthode, mais surtout une méthodologie, c’est-à-dire une réflexion sur ou autour d’une méthode ou d’un ensemble de méthodes. En particulier, l’ouvrage décrit ce que devrait être la méthode idéale de développement rapide. Une méthode RAD devrait, d’après son auteur, apporter trois avantages compétitifs à l’entreprise : • une rapidité de développement (cette caractéristique donne son nom à la méthode) ; • un faible coût de développement ; • une application de grande qualité. Ce dernier aspect est souvent négligé par les vulgarisateurs de la méthode, y compris souvent par les fournisseurs des outils qui s’en réclament, au profit de la rapidité du développement. Le constat de départ concerne les carences des méthodes actuelles : les applications sont très longues à développer. Lorsqu’elles arrivent à l’utilisateur final, elles ne correspondent plus au besoin, car nous vivons dans un monde où tout s’accélère, et les besoins se modifient au même rythme. De plus, l’utilisateur final est peu impliqué dans la définition des besoins, sans parler de la conception de l’application. Pour pallier ces inconvénients, pas de recette miracle. Mais un nombre restreint d’idées-forces. Les principes Les principes du RAD sont simples et ils découlent du bon sens. S’il y a quelque chose de révolutionnaire dans la méthode, c’est leur formalisation. Voici les principes de base : • Tout d’abord, le développement devrait être effectué par de petites équipes, expérimentées et ayant reçu toute la formation nécessaire. • Le développement doit s’effectuer en faisant appel à une méthodologie formalisée. • Une équipe de développement RAD doit disposer d’outils puissants qui automatisent le développement dans sa globalité, tant en ce qui concerne les étapes du développement que l’enchaînement de ces étapes. • L’équipe de développement doit être correctement gérée, par un encadrement encourageant la réutilisation des composants, et attentif aux aspects humains du management de projet. • Enfin, les utilisateurs finaux devraient s’impliquer dans le processus de développement. 2 Extrait de La Lettre de l’ADELI N°27 - Avril 1997 La méthode RAD est donc fondée sur quatre ingrédients de base : • Les outils : de conception, de prototypage, de génération de code, disposant d’un langage de haut niveau (L4G), ces outils étant fédérés par un référentiel et constituant un atelier puissant. • Les personnes : elles doivent être compétentes, expérimentées, correctement formées aux techniques et aux outils utilisés, et, cela ira mieux en le disant, ...motivées ! L’auteur revient souvent sur cet aspect fondamental, et un chapitre entier y est consacré. Ce qui est tout aussi essentiel, c’est que l’utilisateur final soit directement impliqué dans chaque phase du projet. • Le management : une gestion du projet, en particulier en ce qui concerne les aspects humains, est essentielle. Le pire ennemi du RAD, c’est la bureaucratie, dit James Martin. Combien de projets n’a-t-on pas vu dériver ou stagner, ensablés par une bureaucratie toujours plus lourde ? • La méthodologie : Rien ne se fera sans une méthodologie, à la fois bien formalisée et souple. L’auteur recommande que la méthode soit consignée, non sur un document qui remplirait la moitié d’une armoire, mais dans un « hyperdocument » que chacun pourrait parcourir rapidement et de façon non linéaire en fonction de ses besoins et de son rôle sur le projet. Ce document doit être adapté d’un projet à l’autre, toujours affiné, et consultable par tous. Seul un document électronique disponible sur un réseau peut convenir. Les quatre phases Un projet RAD se découpe en quatre phases : 1. Phase de définition des besoins. Elle se matérialise par des sessions de travail appelées JRP (Joint Requirements Planning ou définition conjointe des besoins). 2. Phase de « conception utilisateur » (user design). Elle se caractérise par les sessions JAD (Joint Application Development ou développement conjoint d’application), qui est un des signes distinctifs du RAD. 3. Phase de construction, mêlant les spécifications détaillées et le codage. 4. Phase de finalisation et mise en place (en anglais : cutover). Signalons brièvement deux points essentiels : ∗ tout d’abord, ces quatre phases constituent un processus itératif. Le « cutover » débouche à nouveau sur une nouvelle définition des besoins, tant que cela s’avère nécessaire ; ∗ d’autre part, ces phases peuvent, dans une large mesure, être parallélisées. Les JRP Le principe de la « définition conjointe des besoins », autrement dit JRP, est simple, mais pourra sembler quelque peu révolutionnaire à certains : sélectionnez les meilleurs éléments, à la fois chez le maître d’œuvre et chez le maître d’ouvrage, et faites les plancher ensemble, dans une salle de réunion sans téléphone et le plus loin possible de toute source de distraction. Ces personnes doivent travailler ensemble, définir ensemble les besoins du système à réaliser. Lorsque l’auteur parle des personnes-clés, il ne s’agit ni du management seul, ni des « as de la programmation », mais d’une sélection de l’ensemble des profils impliquées dans le projet. Une de ces personnes clés : l’« executive owner », en d’autres termes celui qui paye pour avoir le produit final (ou son représentant attitré). Il doit s’engager à fond dans le processus. On s’en doutait un peu, mais mieux vaut le répéter que de laisser planer le moindre doute : l’animateur de ces groupes de travail doit être un communicateur hors pair ! Les JAD L’idée derrière les JAD, qui constituent la substance de la phase de conception, est d’augmenter la productivité globale du développement en réunissant lors d’une même session les utilisateurs et les concepteurs. Encore une fois, son efficacité repose sur deux facteurs clés : • le facteur humain : dynamique de groupe et suppression des barrières organisationnelles ; • l’outillage : référentiel puissant et outils de prototypage rapide, les prototypes étant, bien sûr, réutilisables pour le développement du produit final ; Extrait de La Lettre de l’ADELI N°27 - Avril 1997 3 Les « timebox » Dans la plupart des projets de développement d’application (si ce n’est dans TOUS les projets), il y a des glissements dans les délais. Cela tient à plusieurs causes. Mais on sait en particulier que 80% des fonctionnalités sont réalisées en 20% du temps, et que les 80% du temps restant sont pris par la réalisation des 20% des fonctionnalités à réaliser. En fait, plus le développement semble s’approcher de la fin, moins on avance vite. Cela ressemble à du polissage de pièces. Plus on avance, plus l’abrasif doit être fin. Et plus l’abrasif est fin, moins on avance ! En RAD, la loi est dure, mais simple : le glissement est interdit ! Pour un habitué du développement classique, c’est une révolution ! Comment peut-on interdire tout glissement dans les délais ? Et si je n’ai pas fini de développer, comment faire ? La solution, ici aussi, est simple. Plutôt que d’autoriser des glissements dans les délais, on va tolérer un glissement dans la réalisation : réduisez les fonctionnalités, mais quoi qu’il arrive, vous finirez à temps. N’oublions pas que le RAD, et les outils qui sont supposés le supporter, encouragent le développement par affinements successifs. Pour reprendre l’analogie précédente, si on n’a pas le temps d’obtenir un poli parfait, on va se contenter d’une pièce un peu rugueuse (ou même, dans les cas pathologiques cette fois, d’une pièce à peine dégrossie). Mais on ne va pas se donner du temps pour polir encore et encore. Un timebox s’achève par une revue, qui décidera s’il faut ou non réitérer une deuxième boucle de la spirale de développement. Le développement itératif ne rend pas seulement le « timeboxing » possible. Il le rend nécessaire. Car le danger des « fonctionnalités rampantes » (je raffine encore, encore et encore) menace de faire dériver un projet à l’infini. Le management d’un développement de ce style est délicat. Une petite équipe (deux personnes en moyenne) va être mise sous pression pendant une durée fixée (en général 60 jours). Les actions à réaliser alors dans cette boîte temporelle1 doivent être correctement estimées. Critique de la méthode Outre les aspects « outillage », abordés plus loin, la méthode comporte un certain nombre de points faibles. L’auteur insiste sur la réutilisabilité. Or, pour qu’un composant soit réutilisable, il doit être utilisable dans des contextes différents par des applications différentes, ou par des modules différents. Ceci uploads/Ingenierie_Lourd/ correction-td2-bd.pdf