Des approches modernes dérivées du RAD

Le développement rapide a contribué à l'émergence de démarches qui privilégient souplesse et adaptabilité.

Les systèmes d'information ont beau gagner en complexité, les temps de développement n'en sont pas pour autant extensibles. L'amélioration du processus de production logiciel tient un peu de la révolution permanente. Du moins, depuis les années 1980, quand l'émergence du RAD (Rapid Application Development) a marqué le début d'un renouveau méthodologique, bousculant les classiques modes de gestion du cycle de vie logiciel en cascade ou en V. Les anciennes pratiques ont ainsi dû s'effacer devant des approches plus adaptées aux nouvelles technologies, soucieuses de qualité et souvent rompues au traitement itératif. Certains fournisseurs ont développé ou acquis leur propre méthode et l'utilisent dans leurs activités de services. Citons IBM Global Service Method, Fujitsu Macroscope, Microsoft MSF, ou encore Unisys Quadcycle. D'autres méthodes, en revanche ­ parce que d'obédience universitaire ­ proposées dans le cadre d'organisations industrielles ou à la base d'offres commerciales de consulting, se sont ouvertes plus largement aux développeurs d'entreprise. Cette relative diversité méthodologique n'est pas surprenante, car l'idée d'une méthode universelle semble illusoire. Ainsi, si l'on souhaite simplement rationaliser et documenter le processus de développement de l'entreprise, l'approche EFQM, fondée sur les préceptes de la norme ISO 9001, est un bon point de départ. Si l'on désire se lancer dans une modélisation UML lourde, soigner l'architecture de ses projets, formaliser toutes les tâches, RUP, d'origine Rational (racheté par IBM), et ses milliers de page de documentation HTML s'avère alors appropriée. A l'inverse, si l'on doit conduire des projets très évolutifs, on peut s'intéresser à XP (Extreme Programming).

Développer de façon itérative et incrémentale

Les années 1990 ont vu s'affirmer deux lignées de méthodes ­ les unes dites ' unifiés ' (UP, RUP, EUP, 2TUP, etc.), et les autres ' agiles ' (XP, Crystal, ASD, Scrum, etc.). Néanmoins, certains des principes fondamentaux à la base de toutes ces méthodes trouvent leurs racines dans le RAD. Aussi s'accorde-t-on sur la nécessité de développer de façon itérative et incrémentale, de faire du développement à base de composants, d'établir une bonne communication entre les acteurs de l'équipe de développement, de gérer les exigences et les risques tout au long du projet, et de recourir fréquemment au test logiciel.Il est indéniable que les méthodes actuelles tendent à rendre artificielle la coupure entre processus de développement et démarche qualité. C'est notamment vrai pour les méthodes agiles, qui considèrent le test comme une discipline propre au processus de fabrication logicielle et préconisent d'y recourir de façon intensive dans toutes les itérations de développement. Ça l'est aussi pour les méthodes unifiées. En définitive, la ligne de partage entre méthodes unifiées et agiles est d'autant moins tranchée que l'on observe des velléités de rapprochement, voire d'hybridation. Ainsi, Rational avait tenté de marier la rigueur architecturale de RUP à la souplesse de XP, en complétant RUP par une extension XP.

Eric Cailbault (ASF) : ' ne pas appliquer bêtement RUP, mais l'adapter aux projets '

Pour moderniser son application de gestion de chantier, la société ASF (Autoroutes du sud de la France) s'est appuyée sur la méthode RUP. Le projet de développement Trafic demandait d'être conduit de façon rigoureuse : ASF faisait pour la première fois appel aux technologies .Net pour un projet critique, cette application étant utilisée 7 j/7, 24 h/24, par quelque cinq cents personnes réparties sur quarante sites. ' Nous avions déjà commencé à utiliser UML en passant au développement objet, explique Eric Cailbault. Nous nous basions alors sur une méthode de cycle en V. Mais, après une présentation de RUP, nous avions été séduits par cette démarche pleine de bon sens et son côté pratique. ' Pour autant, ASF n'entendait pas appliquer RUP de manière dogmatique. ' Il faut se l'approprier et l'adapter à son projet. ' Cela n'a pas empêché l'équipe de se lancer dans un investissement méthodologique de long terme. Ainsi, ' nous nous engagerons sûrement dans une mise en place itérative de RUP '. Le projet Trafic avait permis de valider la méthode. Il s'était conclu par une phase de bilan, lors de laquelle les pratiques mises en ?"uvre avaient été passées en revue. Et cela pour que l'équipe ASF puisse ' constituer un socle commun de pratiques RUP-ASF susceptibles d'être appliquées aux projets ultérieurs '. Quitte à ce que ce socle soit adapté au cas par cas, selon la taille et la nature des projets.

Point de vue : Olivier Lefebvre (AFD Technologies) : ' XP est adapté aux projets à risque '

' Au contraire des méthodes lourdes et statiques, XP prend en compte les modifications et fournit des éléments nécessaires à la gestion de la dynamique du projet. XP présente l'intérêt d'être ' orientée client '. Le client voit évoluer le produit, puisque des livrables sont fréquemment fournis. XP admet que l'on puisse se tromper. Le recueil d'actions réalisé avant la première itération a pour but de développer un premier prototype implémentant ni plus ni moins que les fonctions spécifiées par le client. Le code est testé à toutes les étapes, et les priorités peuvent, dans une certaine mesure, être changées en cours de route. Pour ce faire, XP préconise une programmation simple, produisant un code lisible, accessible par toute léquipe et aisément adaptable. '