Historique de la gestion de projet en informatique (1ère partie : 1960-1989)

La première méthode, "System Development Methodology" (SDM), date des années 60 et nous vient directement du secteur du bâtiment et des travaux publics (BTP) et de l’industrie. L’approche est simple : on commence par les fondations et on finit par le toit. Depuis, on a fait un peu de chemin…

Années 1960

Cette approche « BTP » est encore utilisée aujourd'hui sous l'appellation "Waterfall model" et "SDM/S". Cette méthode est classifiée dans la famille des méthodes dites "linéaires" (ou séquentielles). Le cycle de développement de la SDM est le Systems Development Life Cycle (SDLC) et il peut être considéré comme le plus ancien cadre d’exécution de projet. Et son adoption est liée à l’émergence des supercalculateurs au sein des grandes entreprises.
En 1968, dans le domaine des pratiques de développement, Edsger Dijkstra produit une lettre (« Go To Statement Considered Harmful ») qu’on peut considérer comme l’acte fondateur de la programmation structurée. Mais cette dernière doit beaucoup au travail de Corrado Böhm et Giuseppe Jacopini dans les années précédentes. Et son apparition est liée à l’émergence de langages riches en structures de contrôle comme ALGOL.

Années 1970

Durant ces années, le "Waterfall model" en Amérique du Nord et "SDM/S" (le plus souvent) en Europe dominent la décennie. Et, de nos jours, ces méthodes (ou des dérivés) sont encore utilisées.
Il faudra attendre la fin de la décennie pour que l’approche "linéaire" soit adaptée à l'informatique sous la forme des cycles en V (Barry Boehm en 1979) puis des cycles en spirale (encore Barry Boehm en 1986). Dans le cycle en V, on s'autorise à revenir en arrière (dans le cadre de certains processus).
Dans le cycle en spirale, on s'autorise à itérer un projet et à découper chaque itération en phases (on parle d'itérations longues : entre 6 et 24 mois chacune).
Barry W. Boehm, né en 1935, est un mathématicien diplômé de l’Université De Harvard (1957).
Il fut professeur émérite de génie logiciel de l'université de Californie du Sud. Il fut surtout le premier à identifier que le logiciel, et non le matériel, deviendrait le premier centre de coût des futurs systèmes informatiques. A ce sujet, il a développé le « COnstructive COst MOdel » (COCOMO), un modèle d’estimation des efforts pour le développement logiciel. Il défendait également l’idée que les développeurs ne sont pas des pièces interchangeables et que l’ajout de développeurs dans un projet en retard ne fera qu’augmenter ce retard. On peut également ajouter que son modèle itératif (en spirale) influencera la méthode "Extreme programming" du Mouvement Agile. Enfin, il est à créditer d’une évolution de la méthode de Delphes (méthode Delphi) qu’il baptisa « Wideband Delphi ».

Années 1980

En 1985, les français développent une nouvelle méthode linéaire orientée « document » (Merise) en rupture avec l’approche par processus. En 1986, les allemands et les suisses dérivent la méthode en V (« V-Modell » allemand, « HERMES » suisse).
Le principal évènement de la décennie est l’émergence des méthodes dites de seconde génération. Cette génération naît en 1987 avec la méthode dite "Objectory Process" (qui survivra sous sa variante "Unified Process"). Cette méthode a été conçue par des ingénieurs de la firme suédoise Ericsson.
Le déclencheur fut l’apparition des logiciels orientés objets. C’est une méthode générique, itérative et incrémentale qui complète la systémique des modèles UML.
"Objectory Process" ayant enfanté du « Unified Process » (UP), la génération a été prolifique : « Rational Unified Process » (RUP, Rational Software), « Enterprise Unified Process » (EUP), « Extreme Unified Process» (XUP, hybride UP et Extreme Programming), Agile Unified Process (AUP), « Two Tracks Unified Process » (2TUP, firme Valtech), « Essential Unified Process » (EssUP, Ivar Jacobson)…
Pour ceux qui penseraient que le « Unified Process » est éteint, ils vont être déçus : Ivar Jacobson, un ancien ingénieur d’Ericsson impliqué dans la conception du "Objectory Process" travaille aujourd'hui pour Microsoft afin d'intégrer son «Essential Unified Process » aux outils de travail collaboratifs de Microsoft.
Les principes du "Objectory Process" sont assez simples : le développement est guidé par les besoins des utilisateurs, piloté par les cas d’utilisation, centré sur l’architecture logicielle, itératif et incrémental. Une itération est la succession des étapes d’une activité et une nouvelle itération (après une démonstration du prototype aux utilisateurs, par exemple) reprend la spécification en la précisant ou la corrigeant. Les incréments sont définis par le projet et chaque incrément ajoute des fonctionnalités.
Le principal enjeu de l’approche est de respecter les interdépendances des incréments via les différentes itérations. Pour cela, on utilisera au mieux les technologies objets. Enfin, "Objectory Process" est, avant tout, une rupture avec le linéaire pour affronter un défi grandissant du développement : la diversité (et la complexité) des projets et des cultures d’entreprise. "Objectory Process" avait donc l’ambition d’être une réponse générique à ce défi.

(fin de la 1ère partie)