Quels projets pour le RAD ?

Certaines questions reviennent régulièrement en conférence. Elles portent souvent sur la typologie de projet la plus propice au RAD. En fait, il n’y a pas de projet type pour le RAD. Il y a juste des organisations plus ou moins aptes à accepter les contraintes du RAD, pour ensuite pouvoir en apprécier les bénéfices. Il est possible d’appliquer le RAD sur un projet de dix ou quinze jours, comme sur un projet de trente années ou plus. Néanmoins, au-dessous d’un certain seuil de quelques dizaines de jours, seule une organisation disposant déjà de l’expertise et de l’environnement de travail RAD peut obtenir des bénéfices immédiats avec cette méthode. Le premier projet n’est pas en général le plus économique, compte tenu des investissements de tous ordres nécessaires pour créer un milieu propice à la performance RAD. Pour conclure comme M. de La Palice, c’est de l’incapacité de l’organisation à appliquer le RAD que découle l’impossibilité de réaliser un projet en RAD.

Prenons pour exemple pratique et réel une étude préalable. Elle démontrait qu’un projet classique évalué à 290 mois-homme pouvait être réalisé en 140 mois-homme si l’on adoptait une démarche RAD :

  • La planification classique démarrait avec deux analystes. Après six mois, huit analystes-programmeurs devaient intervenir et l’équipe devait encore augmenter par la suite pour atteindre douze personnes durant la phase de réalisation.
  • La planification RAD se basait sur l’engagement immédiat et constant d’une équipe RAD de cinq concepteurs-développeurs.
  • Comme aucun budget de projet n’avait été officiellement alloué, il était plus facile de commencer avec la solution classique. Et il me fut dit : puisque nous n’avons pas les moyens de faire du RAD, il faut employer la méthode classique. Je pleure avec vous, gestionnaires.

    Une vision globale du développement

    La méthodologie RAD organise une vision globale du développement d’applications et en englobe tous les composants :

  • la conduite de projet (logistique et pilotage) ;
  • la gestion des communications interpersonnelles ;
  • la composition et la coordination des équipes ;
  • les méthodes de conception ;
  • l’outillage logiciel ;
  • les techniques de réalisation ;
  • l’intégration technologique.
  • Cette envergure nécessite en premier lieu des ressources informatiques cohérentes avec les besoins de développements informatiques de l’entreprise.

    Contrairement aux idées répandues (on ne sait sur quelle base), le RAD recommande d’ancrer les développements fondamentaux sur un socle solide issue d’une planification globale de type plan directeur. Les premières étapes du RAD, y compris la phase d’analyse (Cadrage), sont d’ailleurs de type systémique (top-down). Au niveau de la conception (Design), on s’attache immédiatement à définir dans l’essentiel, une structuration des données qui offre ensuite le moindre effort de développement.

    Principales conditions d’échec

    Figure 1. — Facteurs d‘échec recensés - 1

    Figure 2. — Facteurs d‘échec recensés - 2 -

    En résumé, un échec de projet ou une dérive est moins l’échec des hommes que l’échec de l’organisation qui n’a pas su les diriger et les contrôler. Le retard de projet ou la non-conformité du projet est donc imputable avant tout à l’organisation. C’est l’échec des dirigeants à travers leurs actions ou leurs inactions.

    Absence et excès de méthode

    Paradoxalement, c’est aussi bien l’absence de méthode que son excès qui aboutit aux échecs. La plupart des débuts de catastrophe sur lesquels il m’a été donné d’intervenir avaient pour point commun la poursuite chimérique d’une perfection sur " papier " des livrables. Ces travaux semblaient indispensables au respect de la méthode alors que s’égrenait inexorablement la réserve de temps et d’argent allouée au projet.

    Il ne faut pas confondre la méthode et sa raison d’être. L’aboutissement doit être une application opérationnelle et non un stock de papier justificatif d’un effort, aussi louable soit-il.

    Actuellement, il est peu probable de réaliser un projet sous contraintes sans emprunter des raccourcis méthodologiques.

    Prendre un raccourci est le plus souvent synonyme de prendre un risque pour en réduire un autre. Pour qu’une prise de risque soit payante, il faut quelle soit calculée, donc que le nombre d’inconnues soit raisonnablement limité. Le plus classique est la réduction du nombre de niveaux d’abstraction, il en existe de nombreux autres mais il faudrait un livre pour les décrire et les sécuriser. Un raccourci n’est possible que lorsque la typologie du projet le permet, et sa contrepartie impose une plus forte implication de l’utilisateur dans la réduction du risque qu’il induit.

    Structurer pour réduire la complexité est aussi le meilleur moyen d’obtenir la puissance fonctionnelle en optimisant les coûts de conception et de réalisation. Il faudrait un livre entier pour tenter d’expliquer comment modéliser en pratique. L’architecture de la conception est donc primordiale. On ne le répétera jamais assez, un bon architecte maîtrise et met en œuvre des pratiques de conception comme l’exhaustivité globale, l’abstraction, la modularité, l’encapsulation, la généralisation, etc.


    www.RAD.fr ® © Jean-Pierre Vickoff