Une bonne documentation permet à votre organisation de continuer à comprendre et à gérer sa propre solution de données, même après le départ du développeur. Mais elle peut aussi freiner le développement si elle est mal utilisée.

Retour d’expérience

En 1996, lors d’un stage de fin d’études chez Philips, on m’a demandé d’arrêter de documenter selon la méthode SDM et de commencer à construire. Déjà à l’époque, il était clair qu’il faut impliquer le client le plus tôt possible, par exemple avec un prototype. Aujourd’hui, on appelle cela Agile.

Agile et proof of concept

• Agile : développer en courts sprints, avec la simplicité, la communication, les retours du client et la collaboration comme principes.
• Proof of concept (POC) : une première version pour vérifier si les souhaits et exigences sont réalisables, de l’esquisse ou de la maquette au prototype opérationnel.

Ce que nous documentons

• Architecture système : la conception et l’articulation des composants.
• Modèle de données et dictionnaire de données : quelles données existent et ce qu’elles signifient.
• Flux de données : de la source au rapport.
• Manuel d’exploitation : comment la solution est chargée, surveillée et modifiée.

Juste assez pour gérer vous-même, sans freiner le développement. Aucune documentation ? Alors tout commence par la rétro-ingénierie.

Tirer plus de vos données ?

Contactez-nous pour une première rencontre sans engagement.