Réalisation de documentations techniques

La documentation technique, incontournable des tâches de développement, fit partie des exercices que je refis souvent. Faite avant l’achèvement d’une version du développement, elle était encore à réécrire au fil de ses mutations. La seule explication étant que les habitudes passées de certains personnels engendrait en réaction, une vigilance accrue, un peu exagérée selon moi, sur ces phases de rédaction. La peur que le travail fourni reste sans commentaires était en effet bien réelle.

La documentation des modules consista dans sa forme définitive, en une feuille de route expliquant la stratégie globale suivie par les solutions d’extraction, d’un diagramme métier exposant entrées et sorties avancées par le module, d’un diagramme fonctionnel simple, d’un digramme fonctionnel détaillé et d’un diagramme physique.

4.2.7.1. Le diagramme métier

Entre dans la documentation technique quoiqu’il soit lui-même peu technique en vérité. C’est essentiellement un document de communication, largement orienté vers le commanditaire, le non spécialiste mais qui a pour valeur indispensable d’identifier les fonctionnalités portés par un développement.

30

4.2.7.2. Le diagramme fonctionnel et le diagramme fonctionnel détaillé4

De manière générale, c’est un document qui rend compte visuellement et très précisément des données d’un développement, en termes d’entrées et sorties, d’enchaînements de processus et de systèmes dépendants. Dépendance du développement par rapport à d’autres sections du projet et avec lesquelles il a parties liées

La particularité du diagramme fonctionnel simple est de proposer cette description à une échelle relativement générale tandis que le diagramme détaillé la porte jusqu’à identifier exactement et en cascades les processus en œuvre. Ainsi à tout moment, le travail de développement peut-il se lire en termes de contraintes (allégeances supérieures) implications et imbrications. De tels documents rendent possible les opérations de maintenance, de modification ou de remaniement du code, sans oubli d’une variable, d’une fonction, d’une bibliothèque, d’un processus.

4.2.7.3. Le diagramme en dépendances

Illustration 5 : Diagramme en dépendances du prototype d’extraction à la fin novembre 2011

Commentaire 1 : Le diagramme en dépendances rend compte de l’architecture sur laquelle repose le code créé. En prolongeant le digramme fonctionnel en amont, il fait l’inventaire des différentes bibliothèques, des

4

31

liens qu’elles ont les une aux autres et leur participation aux principales fonctions. Il répertorie bien les créations/extensions d’outils que les réutilisations de bibliothèques. Celles des packs, par exemple.

4.2.7.4. Le diagramme physique

Se présente comme un inventaire exhaustif des contenus des différentes bibliothèques créées par le développeur. Le diagramme liste les fonctions, les procédures, les constantes, les variables globales, les variables locales en terme de types clairement identifiés et exposés, de qualité d’entrées ou de sorties. Sa lecture prolonge le diagramme fonctionnel détaillé.

4.3. Tâches récurrentes

Si les lignes précédentes font état de mes principales missions, elles ne les résument pas toutes cependant. Ces dernières se répartissent encore entre tâches récurrentes croisant l’ensemble des missions évoquées précédemment et des tâches achevées prématurément.

4.3.1. Création de documents de communication

Une de mes tâches fut de procéder à la communication orale de ces différents travaux, lors de réunions-bilan avec le commanditaire et le chef de projet. Dans leurs phases intermédiaires et terminales: recherches en phase intermédiaire, collectes de données, cours accélérés sur le TAL. Les informations obtenues étaient communiquées non seulement aux responsables mais à l’ensemble du personnel qu'elles impactaient. Elles furent plus d’une fois l’occasion de revoir la pertinence de certaines demandes communiquées par le donneur d’ordres, M. Navellou. Ces réunions permirent par l’exposé vulgarisé qu’elles proposaient, d’appréhender le niveau de complexité des opérations engagées par le traitement d’une chaîne linguistique par exemple. Et par conséquent, d’évaluer le poids réel de l’investissement du projet en TAL. Mieux encore, de penser son échelonnement. Ce genre de résultats s’obtient notamment par l’inventaire chronologique des fonctionnalités5 et services requis par la réalisation d’une tâche. Une présentation succincte pose les contours de chacune de ces étapes accompagnées par la présentation de leur coût global, matériel et temporel. Ces documents ont pour effet de créer une conscience partagée suffisante entre des personnes venant d’horizons divers.

Un des enseignements reçus à l’université me servit particulièrement de fil rouge durant tout le stage effectué à N5. Il y existait en effet une forte tendance à entretenir les

5

32

mêmes discussions. Discussions au terme desquelles, croyais-je, chacun de nous nous étions entendus. Ces discussions ne m’impliquaient pas particulièrement face au donneur d’ordre. Elles avaient toujours les mêmes résultats. Ces décisions n’étant jamais consignées nulle part, celui dont les choix n’avaient pas prévalu y revenait toujours. Une de mes tâches consista donc à consigner ses décisions dans des documents de planification, ou bien des dans des dossiers de suivi : collection de mail, ou de documents proposant un début de formalisation qui prouvaient que la question avait été tranchée. L’écrit, en effet, n’ayant pas pour propriété de s’envoler. Ces discussions devinrent de moins en moins nombreuses. Elles ne se situèrent plus qu’au niveau de la direction, témoins qu’une entente sur les réalisations du projet Assurweb était encore à atteindre.

4.4. Missions avortées ou suspendues:

Les missions qui furent entamées et pour différentes raisons qui ne furent pas menées à terme ne furent pas moins consommatrices de temps que les autres. Elles furent elles aussi initiatrices d’enseignements.