Docs à faire apres avoir développé une appli
budylove
Messages postés
70
Date d'inscription
Statut
Membre
Dernière intervention
-
sebsauvage Messages postés 32893 Date d'inscription Statut Modérateur Dernière intervention -
sebsauvage Messages postés 32893 Date d'inscription Statut Modérateur Dernière intervention -
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.
Amicalement
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.
Amicalement
A voir également:
- Docs à faire apres avoir développé une appli
- Appli miroir - Guide
- Comment desinstaller une appli sur pc - Guide
- Appli horloge - Télécharger - Guide Android
- Appli word - Guide
- Appli traduction photo - Guide
1 réponse
Déjà, il y a la doc à faire pendant le dev: Est-ce que toutes des classes, méthodes et attributs sont documentés ?
(à quoi sert chaque méthode, que signifient les paramètres en entrée, les valeurs en sorties, quelles exceptions sont levées et dans quels cas, etc.)
Cette documentation doit être écrite dans le code source même.
Ensuite il existe des outils pour générer automatiquement la documentation à partir de ton code (Doxygen, Javadoc, etc.)
Concernant les autres documents:
Est-ce que ton entreprise a un service qualité ?
Ils ont peut-être déjà des modèles de documents, et une liste de documents obligatoires à fournir.
Dans le cas contraire, voici une liste (non exhaustive):
- définition des objectifs (plan projet)
- spécifications (use case, écrans, comportement attendu de l'appli, etc.)
- architecture (comment sont organisés les serveurs, quels sont les flux de données, etc.)
- documentation technique (doc du code autogénérée, graphe des classes, schémas, format des fichiers, schéma de la base de données...).
- doc d'implémentation (comment implémenter une nouvelle fonctionnalité, comment faire évoluer l'appli)
- éventuellement: résultats des tests unitaires et code coverage.
- plans de test et résultats des test
- plan de validation et recette (validation signée des utilisateurs comme quoi l'appli fait ce qu'ils veulent).
- plan de déploiement (planning: où installer, quand, par qui)
- guide d'installation (comment on installe techniquement l'application, qu'est-ce qui est nécessaire (logiciels, matériel, espace disque...))
- guide d'utilisation pour les utilisateurs finaux (comment on utilise l'application, les écrans, les boutons...)
- guide d'utilisation pour les opérateurs (système, dba, monitoring... quoi surveiller dans les logs).
- guide de process (comment remonter les différents problème, à qui, dans quelles conditions...)
- etc.
Selon l'ampleur du projet, certaines documentations peuvent ou non être pertinentes.
(à quoi sert chaque méthode, que signifient les paramètres en entrée, les valeurs en sorties, quelles exceptions sont levées et dans quels cas, etc.)
Cette documentation doit être écrite dans le code source même.
Ensuite il existe des outils pour générer automatiquement la documentation à partir de ton code (Doxygen, Javadoc, etc.)
Concernant les autres documents:
Est-ce que ton entreprise a un service qualité ?
Ils ont peut-être déjà des modèles de documents, et une liste de documents obligatoires à fournir.
Dans le cas contraire, voici une liste (non exhaustive):
- définition des objectifs (plan projet)
- spécifications (use case, écrans, comportement attendu de l'appli, etc.)
- architecture (comment sont organisés les serveurs, quels sont les flux de données, etc.)
- documentation technique (doc du code autogénérée, graphe des classes, schémas, format des fichiers, schéma de la base de données...).
- doc d'implémentation (comment implémenter une nouvelle fonctionnalité, comment faire évoluer l'appli)
- éventuellement: résultats des tests unitaires et code coverage.
- plans de test et résultats des test
- plan de validation et recette (validation signée des utilisateurs comme quoi l'appli fait ce qu'ils veulent).
- plan de déploiement (planning: où installer, quand, par qui)
- guide d'installation (comment on installe techniquement l'application, qu'est-ce qui est nécessaire (logiciels, matériel, espace disque...))
- guide d'utilisation pour les utilisateurs finaux (comment on utilise l'application, les écrans, les boutons...)
- guide d'utilisation pour les opérateurs (système, dba, monitoring... quoi surveiller dans les logs).
- guide de process (comment remonter les différents problème, à qui, dans quelles conditions...)
- etc.
Selon l'ampleur du projet, certaines documentations peuvent ou non être pertinentes.
