Supposons que, dans une entreprise, il ait été jugé que tel besoin doit être satisfait par un petit développement informatique, et que le programme ait reçu son précieux code projet (j’ai déjà causé de cette odyssée), par exemple VER78 (VEntes/Rapport/78ème programme développé pour ce domaine).
Les « specs »
Concrètement, dans une entreprise organisée, on écrit d’abord des spécifications (« Ce logiciel doit faire telle chose. ») et ensuite un ou des développeur(s) programme(nt).
Le processus peut être plus compliqué : expression de besoins formelle ; réunions d’arbitrage ; spécifications écrites par un key user, ou un consultant interne, ou externe, ou dossier géré de A à Z par un technico-fonctionnel solitaire ; développement en waterfall ou extreme programming ; dossiers de mise en production, d’exploitation... Mais en gros on se résume à : spécification / programme.
Pour le programme lui-même, son code, ses objets... pas de problème, le développeur sait où les trouver et déposer, il est naturellement assez ordonné[1]. De plus, en cas de négligence, la sanction est immédiate : ça ne compile plus. Les outils de gestions de version permettent également suivi et centralisation. Un programme est donc rarement perdu.
Les spécifications ne sont pas soumises à la même rigueur. Souvent, elles se matérialisent en tant que fichiers Word, dont l’éclosion s’effectue en un endroit souvent non public (disque dur personnel, clé USB, répertoire réseau privé...).
Dans les cas les plus défavorables, seul le développeur s’intéresse au code du programme, et la rédaction intervient avant l’étape d’attribution du nom VER78. Le document peut donc ne comporter qu’un titre (« Spécifications commissions sous-traitants.doc »), pas forcément explicite (« Spf comms sst TEST v7.doc »), et se trouver à peu près n’importe où sur l’intranet local…
Un cauchemar pour le petit pion de SSII qui débarque sans idée des nomenclatures et habitudes locales. C’est encore plus drôle quand les gens ne sont pas d’accord sur l’endroit où les documents doivent être déposés ; dans ce cas les chances de posséder plusieurs exemplaires des spécifications évoluant en parallèle est réel.
De l’unicité du code
J’ai donné l’exemple de VER78, sans parler d’un pépin courant : pourquoi VER79 et pas VER80 ? Qu’est-ce qui garantit que VER78 ne va pas être utilisé par quelqu’un d’autre pour un projet différent ?
Qu’on utilise un numéro (comme VER78) ou un code plus littéraire (du genre de « Nabuchodonosor »), le problème se pose rapidement (dès que l’équipe dépasse une personne — et même) : ne pas se retrouver avec deux programmes de même nom. C’est tout bête, mais dans une phase de foisonnement (installation d’un système) impliquant pléthore de consultants et développeurs, le danger est réel.
En informatique théorique, le cas est connu, il suffit de « poser un verrou » sur un numéro. Sous Oracle, on parlerait de « séquence » (à part pour le problème de non-continuité des numéros). En clair, une référence unique où se trouvent ces numéros, et qui garantit un minimum que deux personnes ne peuvent pas utiliser deux noms de programme en même temps. Mais c’est la théorie, où les programmes suivent toujours les procédures ; les humains font ce qu’ils veulent et sont faillibles.
Un collègue m’a parlé d’une technique primitive mais efficace : le classeur papier unique (le truc plat en plastique ou carton avec des anneaux métalliques et des feuilles dedans, pas un fichier Excel !). Le chef de projet ou le développeur qui a besoin de « tirer un numéro » pour nommer une brique logicielle va dans le classeur, regarde le dernier numéro ou nom utilisé, rajoute le sien, et est certain que personne ne créera le même au même moment. Inconvénient : à l’heure des bases de données réparties sur plusieurs sites, et de la sous-traitance massive aux antipodes, un classeur ne voyage ni par email ni par intranet.
Le dérivé de l’ère numérique est évident : un simple fichier Excel sur un intranet public. Encore faut-il savoir où il est sur la jungle de l’intranet réseau (a priori simple, parfois non, voir plus loin). De plus, les classeurs Excel ont le don de scissiparité, et les managers sont vite enclins à en créer d’autres pour le pilotage[2]. Le fichier unique « bête liste des programmes maison » tend très vite à évoluer en outil de mesure de la progression de projets.
La technique la plus efficace à ma connaissance est simplissime : puisque chaque développement implique la génération d’au moins un document (spécifications), autant utiliser cette base documentaire comme base pour la génération du nom du logiciel. On peut effectuer une recherche sur tous les documents intitulés VER*, trouver le dernier (VER77), pour décider de créer le VER78 — mais créer ce document n’est pas instantané, et il vaut mieux que ce code existe avant la moindre action (pour la cohérence des noms des objets à développer, pour les imputations du temps passé à écrire chaque spécification…).
Plus sûrement, utiliser les répertoires (du genre « R:\Développements\Ventes\Rapports\VER78\ »). Un répertoire se crée en deux secondes, le code VER78 est réservé même si aucun document n’a été généré, et le collègue dans l’autre bâtiment, dix secondes plus tard, avec besoin équivalent, créera son VER79.
Archi-simple. Beaucoup trop pour certains.
une réaction
1 De vincent - 05/02/2008, 17:25
Le fichier Excel c'est ce l'on faisait dans ma précédente boîte au début :
Il y avait une colonne par champ pour créer la ref du document : genre le site géographique, le type de doc, le nom du projet, etc... + un numéro incrémenté de ligne en ligne.
Ca parrait pratique: on a un fichier à ouvrir pour connaître le prochain numéro de doc, ensuite on a juste à ouvrir le fichier pour connaître les docs existant.
Sauf que : Il n'y avait pas la localisation physique du doc, nous étions et le fichier Excel était volumineux.
D'où ça rame à mort pour les deux sites qui n'ont pas le fichier en local. Et dès qu'un pékin ouvre le fichier, il faut attendre qu'il referme le fichier pour avoir le droit de l'éditer car le premier ouvrant le fichier le verrouille en écriture par défaut.
Solution : un intranet, avec une base de donnée qui attribue le numéro. Mais là, ça a coûté beaucoup plus cher à mettre en place.
Et surtout, ça n'a jamais garanti que les docs étaient utils et non du pissage verbeux pour faire plaisir aux auditeurs ISO9001.