Managing the development of large software systems

✒ Enzo SandrĂ© · 📆 24/01/2023 · đŸ’Ÿ Histoire de l'informatique · 🧼 MĂ©thodes de dĂ©veloppement

đŸ€– A l’origine de la mĂ©thode Waterfall et de ses descendants, dont le cĂ©lĂšbre cycle en V, on trouve un homme : Winston Walker Royce. Peu aprĂšs la confĂ©rence de Garmisch-Partenkirchen de 1968, il produisit une mĂ©thode rĂ©volutionnaire afin “d’utiliser au mieux les ressources en programmeurs”. Le vocabulaire annonce la couleur : le dĂ©veloppeur doit se tayloriser.

🔃 Son idĂ©e repose sur l’ajout d’étapes prĂ©cĂ©dant la boucle analyse/programmation, qui suffit aux petits projets. Il s’agit des phases de spĂ©cification, analyse, architecture et autres analyses plus ou moins dĂ©taillĂ©es. Rendons cependant justice Ă  Royce, qui avait bien compris que les Ă©tapes de programmation et de tests allaient lever de nombreux problĂšmes, nĂ©cessitant de remonter de nombreuses Ă©tapes en arriĂšre dans les phases de spĂ©cification. Son erreur a Ă©tĂ© de sous-estimer la frĂ©quence de ces retours : il pensait que la majoritĂ© des problĂšmes seraient dĂ©tectĂ©s dans l’étape suivant immĂ©diatement celle qui les a causĂ©s.

💣 La seconde erreur de Royce est de croire en la linĂ©aritĂ© de la relation entre la taille d’un problĂšme et l’importance des changement qu’il occasionnera. Tout son argumentaire repose sur ce mythe : si un problĂšme est petit, il n’occasionnera que de petits changements et la majoritĂ© du travail rĂ©alisĂ© avant sa dĂ©tection sera conservĂ©. Il est donc rentable de tout spĂ©cifier par raffinements successifs jusqu’à rendre la tĂąche du programmeur triviale. Avec le recul, nous savons qu’un petit problĂšme d’implĂ©mentation peut invalider des centaines d’heures de conception sur plusieurs Ă©tapes.

📚 La troisiĂšme erreur de Royce est de croire que la documentation remplace la collaboration. Il prĂŽne une mĂ©diation universelle des diffĂ©rents mĂ©tiers Ă  l’oeuvre sur un logiciel par le document papier. Il y voit deux avantages : trouver les responsables des erreurs et spĂ©cialiser les tĂąches. Si un acteur rĂ©dige une documentation en amont, il est possible de diviser le travail en aval grĂące Ă  une photocopieuse. Chacun a son exemplaire de documentation, son silo et ses tĂąches spĂ©cialisĂ©es Ă  effectuer. Il illustre en Ă©voquant les tests “rĂ©alisables par des acteurs moins coĂ»teux que les programmeurs”. De plus, vu que chacun est forcĂ© de dĂ©crire son avancement sur une documentation, il est facile de remonter Ă  la source, donc de blĂąmer.

🧠 Il est difficile de jeter la pierre Ă  Royce, car les Ă©tudes venues invalider ses prĂ©jugĂ©s n’étaient pas sorties. Il aurait cependant pu faire preuve de plus de prudence avant d’appliquer au dĂ©veloppement de logiciels tous les lieux communs de son Ă©poque. Le leçon, pour nous, est justement lĂ . Appliquons-nous benoĂźtement la derniĂšre mĂ©thode dans l’air du temps, ou bien avons-nous des preuves empiriques ?

SOURCE

Royce, Winston. “Managing the development of large software systems: concepts and techniques.” International Conference on Software Engineering (1987).

Enzo Sandré