Bonjour    
 
Actuellement étudiant en alternance, j'aurais besoin de vos lumières.
 
Dans le cadres des mes études en informatique, j'ai réalisé pour ma société un logiciel pour la qualité
 
Le développement n'étant pas tout le travail, je souhait que l'entreprise garde une trace du développement de l'application pour quand je ne serais plus là.
 
Mon problème est que je ne sais pas ce qu'il est nécessaire de faire comme doc ?
Cahier de recette
Doc technique
…
 
Je viens de faire ma doc utilisateurs, ça c'est bon (je pense)
 
Je voudrais faire une doc technique pour la partie logiciel mais je ne sais pas ce qu'il faut mettre dedans et comment la structurer.  
 
Tout ce que je veux (c'est déjà pas mal) c'est :
1) quel sont les docs à faire avant et après un dev
2) ce que l'on trouve dedans
3) et si possible des exemple
 
Je me doute que ce sont des docs confidentiels, propre à chaque société, mais Je ne compte rien diffuser, je chercher juste à faire un boulot correct, seulement je manque d'outils.
 
Pouvez vous si il vous plait m'aider?  
 
ps: j'ai fait une recherche de topic mais je n'ai pas trouver.
ps: je ne suis pas sur d'être dans la bonne section.
 
Amicalement  

à mon sens, t'as deux docs à pondre : une doc fonctionnelle, qui décrit les besoins et le périmètre de ton appli. et une doc technique qui décrit comment tu as fait.
 
attarde-toi surtout sur la première, qui doit être sans faille. la seconde, mise à part si t'as développé en ASM avec des optimisation de malade, n'importe quel développeur muni d'une GUI pas trop naze s'en sortira même sans doc technique.
 
en gros, la première doc c'est "bon, alors on doit mettre des choux dans des boîtes à oeufs. pour ce faire, il faut lyophiliser les choux pour qu'il tienne."
 
et la seconde "pour lyophiliser un choux des cultures maréchaires de châlon, il faut le placer dans une cloche à vide de modèle RX935, et le surgeler à l'aide d'un réfrigérateur Z98SF, avant finalement de l'emballer sous vide avec du plasique C603".

Bonjour, loin de constituer un document de la premiere classe qu'evoque MagicBuzz, ce fichier nommé README constitu normalement une section nommé "usage" et stipule les commande d'usage à l'appel du programme
README

moué ca va pas etre facil.

Moi, on me demande comem docs :  
- le DSL (dossier des spécifications logicielles) : c'est la spec qui précise entre autres, la mission du soft et comment il y répond (qq écrans)...
- le DCP (dossier de conception préliminaire) ou le DCD (dossier de conception détaillée) : là, c'est technique. Suivant la taille du soft, on va faire le premier doc ou le second. Moi, c'est plutôt le second. Faut décrire l'architecture du soft, les classes, le MCD et le MLD si y'a une BD, l'intéraction entre les classes, ...
- le DTV (dossier de test et de validation) : faut décrire le plan de test et le résultat des tests
- le MEX (manuel d'exploitation) : comment installer et paramétrer le bousin. Ca décrit les pannes et les procédures d'arrêt/remise en marche.
- le MUT (manuel utilisateur) : comme son nom l'indique.

Tiens, je viens de mettre en ligne le plan type d'un DSL : http://chris-jav.servhome.org/Plan_DSL.pdf
Bon, je préviens, c'est assez bavard comme doc

alut
 
moi pour tout ce qui est technique j'utilise doxygen, c free et c pas mal foutue, ca genere du tex, du html etc etc c super simple d'emploi (ajout de balise dans ton code) et ca fait tout tout seul ou presque

Je voulais l'utiliser, mais y'a juste un pb : l'appli que je développe doit finir en GPL à terme : comem c'était prévu depuis le débout, j'ai tout développé en EN. Le pb, c'est que le client veut toutes les docs en FR....

Dis au client d'aller se faire enculer  

 
ben tiens, et moi, dans la seconde qui suit, je vais pointer au chômage....