<=<=<=<=
Travaux préparatoires Preparation Work
L'idée The idea

Ca peut paraître évident, mais encore faut-il le dire: Avant de commencer, il faut déjà au moins une idée.

L'idée il faut la noter, pour ne pas l'oublier. Ca parait stupide, mais au fur et a mesure de l'avancée du travail préparatoire, l'idée initiale risque d'être obscurcie et de ne plus être visible. Se souvenir de l'idée initiale aide à rester sur le bon chemin.

There are some things that are obvious, but that need anyway to be expressed: Before starting you work, you at least need an idea.

That idea, you'll have to write it down to not forget it. This can looks stupid, but the more you will work, the more you increase the chances to derivate and arrive to something that is far from the original idea. If you keep the idea visible, you will increase the chances of staying on the right path.

Le cahier des charges The bible

Une idée, c'est bien, mais ça n'est qu'un point de départ.

Ensuite, il faut définir plus précisément cette idée. Il faudra énumérer les points importants qui doivent apparaître dans la proposition qui sera effectuée. Cette phase se fait généralement de façon incrémentale en posant des questions aux éventuelles personnes amenées à être concerner par le projet. Il faut demander aux utilisateurs, chercher si l'idée n'a pas déjà été implémenté par quelqu'un, s'il n'y a pas eu rapports ou de thèses concernant ce sujet, les avantages et inconvénients des réalisations déjà existantes... Toute cette recherche permet d'amasser une masse de documentation qui enrichira la vision que l'on a de l'idée. Cela permet aussi d'avoir une vue globale de ce que cela requiert au niveau de l'implémentation, au niveau de la complexité ou de la durée prévisible du développement.

C'est aussi la phase où l'on doit envisager les extensions potentielles de l'idée, ce qu'il faudrait faire pour favoriser l'évolution future du projet, mais aussi souligner ce qu'il ne faut pas faire si le n'on souhaite pas se refermer des portes et donc ainsi limiter la viabilité a long terme du projet.

Le cahier des charges doit aussi être fait comme s'il était destiné à quelqu'un d'autre, même si on le fait pour soit. Cela implique que l'on ne peut pas se permettre de laisser traîner des sous-entendus, ou rédiger le document comme si l'on savait déjà comment on allait effectuer l'implémentation. Cette façon de faire implique que le document est auto-suffisant, que toutes les références, annexes, documentations externes doivent faire partie intégrante du document. Cela assure le fait de pouvoir toujours comprendre l'intégralité du travail même des mois ou des années après. Le fait d'avoir expliqué l'idée en prologue permet en plus de permettre à d'éventuels lecteurs de comprendre rapidement le sujet du document. Cela évite d'avoir à expliquer pleins de détails que l'on avait pas jugé bon d'inclure.

Une très bonne idée sera d'avoir une version completement électronique du document, si possible dans des formats devenus standards (RTF, HTML, PDF, pas de DOC), qui pourra être placée dans un répertoire "documentation" dans l'arborescence du projet lors de l'implémentation, et qui sera donc archivée avec, et consultable par n'importe qui ayant à travailler sur le programme sans avoir a rechercher sur tout le réseau...

An idea, that's cool, but it's only a starting point.

The first thing to do after, is to refine that idea. You have to enumerate all the importants things that needs to appear in the proposition of design. This phase is generaly done incrementaly. You think about something, refer to the people that are concerned by the project, ask to the future users, look if the idea has not yet been implemented by someone else, look for thesis or documentation about the subject, the pros and cons of existing implementations, and so on... All that research phase helps getting a wider vision of the subject, and will help when you'll have to evaluate what it will cost during the implementation phase, from a complexity point of view as well as in the evaluation of the duration of the development.

During this phase of the design it is possible explore the future extensions of the basic idea. If you try right now to think about the future evolution of the project, you will be able to highlight the things that can been done during the implementation phase to keep the project open, and the things not to do because they will restrict the futur evolutions.

Finaly, this document must be done as if it was something you're doing for someone else. Even if you are the only person concerned by the subject. Mostyl ig you are the only person concerned by the subject ! If you do it as if it was for someone else, it implies that you will not be authorised to let "understatments" or "obvious supposition" here and there. You will not build a document based on the implementation idea you have, because you will need to put only objective facts. Another consequence is that the document need to includes all references, annexes, external documentation that were used to create the document. If this is done correctly, it means that you'll still be able to realise the implementation, month or year after, because all you need is in the document. And if the initial idea is explained at the very start of the document some eventual readers will understand easily the subject of the whole stuff: You will not be bothered every two minutes to explain something that you don't consider needs more explanation.

A very good idea will be to have an electronic version of the document that use only industry standard formats like HTML, RTF or PDF (no DOC files please) that will be stored in a "documentation" folder in the project tree. This way the documentation will be backuped with the project, and available anywhere by anyone working on the project, even in few years without having to play sherlock holmes in the storage room.

SOS !!!Contact...Informations...