La petite histoire d’une grande industrie

L’histoire du développement de logiciels est intimement liée à l’histoire de l’industrie informatique. Je vais donc présenter les deux à la fois.

La vieille époque

Le transistor a été inventé en 1948, et l’ordinateur sous sa forme actuelle existe depuis les années ’50. Ce n’est cependant que pendant les années ’60 que l’informatique commerciale est apparue, alors que le coût des ordinateurs a grandement diminué et que des langages de programmation comme Fortran et Cobol ont permis de produire des applications pour le milieu des affaires. À partir de ce moment, le rythme n’a cessé d’augmenter, tant au point de vue machine que logiciel.

Les années ’70 ont vu l’apparition des langages C, Pascal et Basic, de Unix, du circuit intégré, de Apple, Intel et Microsoft, et des premiers micro-ordinateurs. Le PC, le Mac et l’interface graphique ont suivi quelques années plus tard, et une révolution importante s’est produite: un individu pouvait désormais programmer avec un langage comme dBase ou Basic, sans aucune formation et avec un minimum de ressources, et produire un logiciel utile et immédiatement disponible. La qualité était souvent mauvaise, et les règles établies depuis les années ’60 ont été oubliées au profit de cette nouvelle vague d’outils de développement. L’avènement en masse de la réseautique a amplifié le problème, puisque les défauts d’un logiciel n’étaient plus isolés au seul ordinateur où il était exécuté.

Le développement de logiciels a été pendant longtemps entièrement libre de directives ou de contraintes, et il n’y avait aucune méthode pour analyser les besoins, produire une solution, ou même évaluer le succès. En 1968, une conférence de l’OTAN a introduit le terme « génie logiciel » et suggéré d’utiliser les méthodes rigoureuses et éprouvées du génie civil au chaos du développement de logiciels. L’idée était louable, mais une différence majeure existe: contrairement à la physique et aux mathématiques, l’informatique ne repose sur aucune loi et ne peut être vérifiée scientifiquement.

De la rigueur s.v.p.

Des méthodologies de développement sont apparues à différents moments durant la révolution informatique. Le modèle en cascade, inventé par la US Navy, est sans aucun doute le modèle qui a eu le plus d’influence, et cette influence peut encore être ressentie aujourd’hui. Le modèle est très strict: les étapes de concept, analyse, design, programmation et test doivent être exécutées dans l’ordre, et le retour en arrière n’est pas permis. La notion que le coût du changement augmente à mesure que le projet progresse est dérivée de ce modèle. L’emphase sur la documentation est très importante, et chaque étape doit être approuvée avant que l’étape suivante débute. Très bureaucratique, très lourd, mais un grand bond dans la bonne direction.

Le modèle en cascade a donné naissance à de nombreuses autres méthodologies: prototypage, modèle en spirale, implantation en étape, et même RAD (Rapid Application Development). Ces méthodologies sont des variations de l’original, où des possibilités de retour-arrière à différents points ont été ajoutées. Au milieu des années ’90, l’industrie informatique utilisait le terme RAD à toutes les sauces, et promettait des résultats fantastiques. Les fabricants de langages de programmation, dont Borland et Microsoft, ont lancé des produits de développement qui ont effectivement accéléré le processus de programmation, mais n’avaient rien à voir avec une méthodologie de travail. En fait, dans la grande majorité des cas, les outils contribuaient à diminuer la qualité.

D’autres modèles sont apparus et ont connu un succès limité, possiblement à cause de leur manque de flexibilité. L’analyse orientée-objet (basée sur la programmation orientée-objet) est apparue à la fin des années ‘80, et est encore utilisée aujourd’hui pour le développement de systèmes de grande taille. Rational Unified Process (processus basé sur UML) est le modèle de Rational Software, et requiert l’utilisation de logiciels spécifiques. La méthode P-Plus, de DMR (maintenant Fujitsu Consulting), qui a connue son heure de gloire dans les années ’80, commençait par la fin: le livre d’instructions du produit fini était écrit, puis présenté au client pour approbation; le développement du logiciel commençait ensuite.

Être agile

À travers toutes ces méthodes et tous ces modèles, de nombreuses bonnes idées sont apparues. Malheureusement, elles sont souvent mal utilisées, ou perdues au coeur de la rigueur et de la paperasse générée par le modèle. Un mouvement est apparu au milieu des années ’90 qui avait pour but de rendre le processus de développement plus efficace, en utilisant des concepts très simples et reconnus. Ce mouvement s’appelle Agile Modeling. Il n’est directement relié à aucune méthodologie, mais propose une série de recommandations, valeurs, et principes qui sont appliquées dans d’autres méthodes. C’est de là que Extreme Programming est né.

Extreme Programming, ou XP, est basé sur des principes très simples, mais souvent ignorés par l’industrie. Une des idées révolutionnaires est que le coût du changement n’est pas variable mais plutôt constant; XP accepte donc le changement comme une réalité et l’intègre dans le processus de développement. Aussi, la programmation en paire, où deux programmeurs travaillent ensemble sur le même ordinateur, permet d’augmenter la qualité à des niveaux encore jamais vus. Une autre idée consiste à mettre l’emphase sur la communication constante entre l’équipe de développement et le client, par le biais de boucles rapides développement-test-feedback. Certaines de ces idées ne sont pas nouvelles, mais elles sont assemblées dans XP pour former une méthodologie efficace et qui présente des résultats concrets, plutôt que des résultats sur papier.

Le prochain article présentera la Gestion du changement telle que proposée dans Extreme Programming.

Eric Lagacé