rufo Pas me confondre avec Lycos! | Déjà, ça va dépendre de la taille du projet. Combien de ligne de code, le produit finale ? (en gros)
Parce que normalement, on a le doc de spéc générale, le dossier de conception puis le dossier de conception détaillée. Si le produit est "gros", on peut avoir des sous-dossiers de conception détaillée, un parti "partie" (ie "module" ).
Idéalement, faudrait un soft (ex Doors, même si c'est vieux maintenant) qui permet de définir les exigences de haut niveau, puis les lier aux exigences induites puis lier ces exigences induites aux TU, TI, tests de validation... Ca permet de sortie le cahier de test automatiquement et de voir la matrice de couverture des exigences et la matrice de couverture des tests.
Une autre solution qui se fait de plus en plus : méthode agile de dév piloté par les tests (test driven). Pour éviter les régressions mais aussi automatiser les TU, TI voir plus, tu code d'abord la classe qui va tester la classe qui remplit une "fonction". Ainsi, chaque soir, tu peux lancer les TU, TI et avoir le lendemain, le rapport indiquant le nb de tests OK/KO. Tu vois si t'as avancé ou reculé.
Mais rêve pas, la doc de conception, c'est chiant à faire et encore plus à lire Et plus tu vas vouloir la rendre "sympa", plus va falloir investir du temps pour faire des beaux schémas ergonomiques, accessibles à tous. Et ça, c'est pas donné à tous de savoir faire ça et ça prend beaucoup de temps. Si déjà la doc est faite est à jour, même si c'est pas cool à lire, au moins, elle aura le mérite d'être là.
Au passage, inclure une partie de la doc dans le code source (cf commentaires au format javadoc) ---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Planeta Calandreta : https://framalibre.org/content/planeta-calandreta
|