Quelques scénarios catastrophe qui illustrent la nécessité de recourir à l’ALM, l’Agilité, l’industrialisation des processus …

Voici donc le résultat de ses réflexions:

Dans les années 1990, à l’occasion de la rénovation de navires de la marine royale britannique, des planches furent détachées du plancher de certains navires. Il apparut que les solives (pièces de charpente qui s’appuient sur les poutres et qui servent à fixer en dessus les planches du plancher, en dessous, les lattes du plafond) étaient des vestiges de navires fabriqués au début des années 1800. Sur chacune de ces pièces préfabriquées, des notes furent trouvées telles que ci-dessous:

1. les initiales de l’artisan qui était responsable ou avait réalisé la pièce
2. un identifiant unique pour la pièce
3. une liste des numéros des pièces qui s’interfaçaient avec la pièce concernée
4. des notes encore non déchiffrées que les historiens pensent être “un langage mystique de communication entre différents groupes de personnes”

L’histoire continue. Les pièces étaient fabriquées et envoyées au navire pour être assemblées. Si une pièce présentait un défaut, elle était renvoyée à l’artisan responsable de la pièce pour résoudre le problème.

Les listes de numéros de pièces à interfacer constituaient une aide pour contrôler les interfaces entre les pièces et ainsi toute modification apportée à une pièce. Le contrôle des changements était donc visiblement déjà effectif à cette époque…

On peut émettre l’hypothèse que les “notes mystiques” concernaient soit la manière d’interfacer la pièce avec les autres soit les défauts constatés sur la pièce.

Donc en 1800, des systèmes manuels étaient utilisés pour garantir que si un travailleur introduisait un défaut, c’est lui qui le corrigerait et non le premier venu disponible pour tenter de corriger le problème.

Ils disposaient aussi d’une structure complète d’analyse ou une liste des items de configuration qui montrait les relations entre les pièces fabriquées pour le navire. Cela permettait de garantir la consistance et de contrôler les changements sur le produit en cours de développement.

Tout cela a aidé Nelson car comme le soulignent les historiens, ses navires étaient plus fiables que les navires français. Ce qui suggère que les systèmes de Gestion des Changements restaient opérationnels dans les phases de maintenance (pièces en réserve, etc.).

La fiabilité des navires de Nelson n’est pas à démontrer. Pour l’illustrer, voici un résumé de la bataille de Trafalgar :

Le 21 octobre 1805, au large du cap Trafalgar, les vaisseaux de Nelson et Collingwood mirent la marine impériale française en déroute. Par cette victoire décisive, l’Angleterre a conquis la maîtrise absolue de la mer. A lui seul, ce résultat devait contrebalancer les plus éclatants succès de Napoléon sur le continent et lui arracher la victoire finale. La suprématie ainsi gagnée sur les mers par l’Angleterre dura un siècle, jusqu’à la première guerre mondiale.

Lieu : Au large du cap Trafalgar, dans le sud de l’Espagne.

Durée : 4 heures : la bataille, démarrée à 11h50, est gagnée à 16h00.

Forces en présence :

• Flotte anglaise 27 vaisseaux
• Flotte franco-espagnole 33 vaisseaux

Pertes :

• Anglais aucun vaisseau capturé ni détruit
  1 600 hommes hors de combat
• Français et Espagnols 17 vaisseaux capturés
  4 500 Français et 2 450 Espagnols tués
  20 000 prisonniers.

Certes cette victoire n’est pas uniquement dûe à la fiabilité des navires, la majeure partie de ce succès revient en effet à la stratégie employée par Nelson. Mais gageons qu’elle y a contribué. De même, dans le monde du logiciel, la GCL constitue un support clef sur l’ensemble du cycle de vie du logiciel mais ne substitue en rien à la gestion de projet et à la conception.
Ce petit récit met en évidence les 4 fonctions de la GCL:

La Gestion de Configuration est une discipline qui applique une gestion technique et administrative ainsi que de la surveillance pour :

1. Identifier et documenter les caractéristiques fonctionnelles et techniques des Items de Configuration
2. Auditer les items de Configuration pour vérifier qu’ils sont conformes aux spécifications, aux documents de contrôle d’interface et autres expressions de besoins contractuelles
3. Contrôler les Changement apportés aux Items de Configuration et leurs documentations relatives
4. Enregistrer et rapporter les informations requises pour gérer les Items de Configuration efficacement, incluant le statut des changement proposés et le statut d’implémentation des changements approuvés (IEEE 610.12-1990)

Il illustre aussi les bénéfices que l’on en retire

• la traçabilité des modifications apportées au système et l’historique des modifications
• la garantie de disposer des bonnes versions de fichier, rangées dans le répertoire ad hoc lors des phases d’assemblage
• la capacité d’affecter les corrections de bugs aux bonnes personnes (dans notre exemple, l’artisan qui a créé la pièce)
• des outils d’analyse d’impact d’un changement pour la maintenance
• disposer d’applications maintenables plus facilement et donc plus fiables

Fin du cours d’histoire…