Slt,
Voilà je pensais bien de demandé à quelqu'un de plus expérimenté que moi dans la création web de nous expliquer ce qu'est ce que l'on appelle plus particulièrement un "Cahier des Charges".
Quel en est son utilité?
Comment procédé pour créer un bon cahier de charge?
Tout un série de question auquelles moi et surement d'autres débutants ou novice en création web aimerions connaitre les réponses.
Quelqu'un aurait-il l'amabilité de nous aider a comprendre le principe du cahier des charges ?
Merci
Dark Angels
Un début ... mais l'importance du cahier des charges mériterait qu'on etoffe un peu tout ca.
Je pensais que ceux qui font/ont fait des écoles d'infos avait p-e des cours la dessus et pourraient nous faire partager.
Très vite :
Perso je fais un cahier des charges pour tous les sites que je réalise. Au début je faisais sans, en recrachant direct toutes les idées qui me venaient dans la tête. Et finallement c'est le meilleur moyen d'arriver à rien, et de devoir tout recommencer depuis le bédut ... parce qu'on a pas penser à un détail stupide avant... ou parce que c'est un bordel monstre et qu'on y retouve plus ses petits... cb de fois ca nous est arrivé hein ?
Moi je vois ca comme un story board pour un film. Une fois identifiés le but et la forme du site, on passe en revue les besoins (techniques, interface, etc.) et je met à plat toutes les pages dont je vais avoir besoin. Je les dessine meme. Ca me permet de voir les relations de chaque page entre elles, de penser et mettre en forme la structure de la bdd, de savoir de quel technique je vais avoir besoin (moteur de template ou non, ajax ou pas, etc.) de lister les classes d'objet que je vais mettre en oeuvre, etc.
Bref, je dois savoir ou je vais quand j eme met à coder pour de bon.
J'ai pris l'habitude d'utiliser des wikis. Ya un wiki tout simple, sans bdd (chuwiki) que j'installe pour chaque projet, et je me sers de ce wiki comme d'un cahier de brouillon. Je note tout en vrac au début, puis j'organise mon cahier des charges, ma structure bdd, etc.
Pour un cahier des charges, tu va déjà définir ton projet clairement (type de jeu, nombre d'utilisateurs, prévoir peut-être les niveaux de gestions de jeu (Dev/Modo/Mj/Admin/...), ...) Puis tous les concepts que tu souhaites intégrer en procédant par exemple par module, par page ou une autre façon qui est claire (Action combat, ramasser un objet, donner un objet, déposer un objet, tirer avec une arme, ...).
Quand tu es sûr et certain d'avoir mis tout ce qui est réellement important (grosses structure du jeu), tu peux passer par des détails plus techniques comme les tables, les relations entre les objets, ...
Finalement, quand tout est claire, tu codes.
Ton cahier des charges n'est et ne sera pas (en général) fixe. Certaines choses vont être rajoutées ou enlevées. Procède par étapes : Première version, j'implémente ça, ça et ça tout en pensant que je devrais ajouter dans la version trois ce truc là et cet autre truc mais mon jeu doit tourner dès la fin de la première version.
C'est très schématique. naholyr pourra t'en dire plus ;-)
Comme Loetheri le dit, je pense que nos cahiers des charges sont assez flexibles et pas forcément très complets. Pour Seelies par exemple, nous sommes dans une optique de développement
par incrément. C'est à dire faire plusieurs petits ajouts tout en gardant en tête que le jeu doit être jouable. J'ai récemment dû faire un listing des concepts présents dans la toute première version jouable de Seelies (minimaliste), nom de code Vermenthe, que voici :
Vermenthe - Mécanismes.
Ensuite, pour quelque chose d'un peu plus professionnel :
Dans le cadre de mes études à Supinfo, nous sommes tenus de participer à un projet de groupe qui mélange les différentes promos de l'école : PS1 (Prépa Supinfo 1), PS2 (Prépa Supinfo 2), IS1 (Ingé Supinfo 1) et IS2 (Ingé Supinfo 2), il n'y a en revanche pas de IS3 dans ces projets de groupe.
Chaque projet possède un cahier des charges fourni par l'entreprise qui propose ces projets à l'école, je ne sais donc pas trop si je peux le diffuser librement sur Internet (à vrai dire, ça m'étonnerait). Je vais par contre en écrire la structure, je pense qu'ils ne m'en voudront pas puisque c'est assez générique.
- Présentation générale de l’application
- Le contexte général
- Objectif du projet
- Contraintes techniques
- Présentation fonctionnelle de l’application
- Généralités
- Structure de la base de données
- Successions d’écrans
Le tout est bien sûr très détaillé.
Sephi-Chan