Docs à faire apres avoir développé une appli
Fermé
budylove
Messages postés
70
Date d'inscription
vendredi 20 septembre 2002
Statut
Membre
Dernière intervention
5 janvier 2007
-
5 janv. 2007 à 09:03
sebsauvage Messages postés 32893 Date d'inscription mercredi 29 août 2001 Statut Modérateur Dernière intervention 21 octobre 2019 - 5 janv. 2007 à 10:49
sebsauvage Messages postés 32893 Date d'inscription mercredi 29 août 2001 Statut Modérateur Dernière intervention 21 octobre 2019 - 5 janv. 2007 à 10:49
A voir également:
- Docs à faire apres avoir développé une appli
- Comment desinstaller une appli sur pc - Guide
- Appli miroir - Guide
- Appli traduction photo - Guide
- Appli calculatrice - Télécharger - Calcul & Conversion
- Appli musique gratuite - Accueil - Audio
1 réponse
sebsauvage
Messages postés
32893
Date d'inscription
mercredi 29 août 2001
Statut
Modérateur
Dernière intervention
21 octobre 2019
15 659
5 janv. 2007 à 10:49
5 janv. 2007 à 10:49
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.