Les docs à faire apres avoir développé une application

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:)

Personne ne fait de doc ?

Eh bien pour commencer, il faut la doc de chaque classe et fonction (doc qui peut être générée à partir de commentaires avec les utilitaires comme Doxygen ou les commentaires XML de Microsoft). Cette doc doit expliquer ce que fait chaque fonction, à quoi elle sert, et non pas comment elle le fait (ça, seul le code source bien commenté est censé l'expliquer).
La doc peut également dire, pour chaque fonction, ce qui peut l'influencer (variables globales/fonctions utilisées, dont la modification aurait des répercussions sur la fonction décrite) ainsi que dans l'autre sens, les fonctions connues qui l'utilisent.

Cette doc technique sera indispensable à la maintenance.

Une doc sur les conventions employées peut être utile également (conventions de nommage, etc). Même si normalement, tu ne devrais pas avoir à écrire cette doc si tu suis des conventions imposées par l'entreprise: C'est l'entreprise qui doit fournir la doc en question.

La doc utilisateurs doit être sur deux niveaux: Utilisation générale (tuto, etc.) et explication détaillée de chaque fonction (ce que fait chaque option du menu, dans quelles circonstances elle est accessible, raccourcis clavier par défaut, etc.).

Nous faisons une doc pour:
- le manuel d'utilisation
- la procédure d'installation
- les procédures de maintenance (ex: comment contourner un bug du logiciel en attendant une maj de celui-ci, compactage de la base de données régulier, etc.)
- architecture du logiciel (quel fichier contient quelle fonction, description de la fonction et de ses paramètres)

J'oubliais, une doc de tous les formats de fichier utilisés, et une doc des schémas de base de données (avec une explication détaillée de chaque champ et à quoi il sert).

Hello,
Generalement, le type de doc à faire depend de l'entreprise meme si certaines s'en moquent completement et dautres, pas du tout ( certaines considerent que la doc a faire fait partie de la moitié de la durée du projet)

Generalement, je fais ( ou on me demande):
- Cahier des charges amelioré avec reponse à chaque besoin
- Architecture generale du soft ( composantes globales, lien, explication du fonctionnement)
- Architecture des parties les plus importante ( algo ou autres)
- Architecture des fichiers ( quelle fonction est dans quel fichier)..
- Doc utilisateur ( compliqué car faut se mettre au "niveau" de qqun qui ne connait pas le programme)
- Doc d'installation( machine, logiciel tiers, ...)
- Cahier de recette avec tests.

Pour finir car aussi important, mettre des commentaires dans le code car pour moi, c'est presque pus important que le reste car generalement, les docs sont mises de coté voire perdue, quand elles sont a jour ...


Les docs dependent aussi evidement de ton projet.
A+

Merci de vos reponse,

je vais essayer de me baser dessus pour faire quelque chose de bien, je sens que c'est pas gagné mais on verra bien (j'suis pas développer dans l'âme).



@ Scyrius -> le cahier de recette c'est quoi?

quelqu'un peut me montrer un exemple des docs citées ?

Bonjour,

Lorsque tu développe un logiciel, il est d'usage (en tout cas en SSII) de réaliser un document de conception, usant et abusant de l'UML (Unified Modelling Language) pour décrire de manière compréhensible et complète ton programme.

Pense à décrire les cas d'utilisation (qui fait quoi avec le programme), l'intéraction avec l'environnement et l'intégration avec d'autres programmes (diagrammes de composant et de déploiement).

Ensuite si tu développe dans un langage objet, plusieurs diagrammes de classes sont les bienvenus pour expliciter le corps de ton logiciel et les intéractions entre les classes. Ne détaille pas trop pour ne pas perdre le lecteur, soit synthétique.

Enfin, décrit le fonctionnement de ton programme à l'aide des diagrammes de séquence, d'état et d'activité. Choisis des processus clés et décris le déroulement du programme (nom des classes, fonctions appelées, arguments, valeurs clés, conditions, etc).

Tu peux utiliser Jude pour créer de l'UML facilement.

Bon courage!

EDIT: Oula que de réponses en 5 minutes 8O

va falloir que je ressorte mes cours d'UML

impossible de trouver des exemples de toutes les méthodes que vous me proposés.

En tout cas merci de vos réponses;)