Hello,
 
J'ai cherché rapidement, je n'ai pas trouvé de sujet qui pourraient répondre à ma problématique..
 
Voilà, j'arrive sur un projet déjà relativement agé (3-4 ans), et je constate qu'aucune doc de conception technique n'existe. La base du projet a été faite par un mutant de la programmation, donc c'est robuste, pas de soucis là-dessus. Le soucis, c'est qu'il y a pas mal de nouveaux qui sont lâchés là-dessus, et que niveau conception, c'est souvent 4 lignes de Word et 6 jours de debug à tout péter / refaire parce que pas pensé tel cas...
Pour l'instant, le seul 'pré-requis' que je demande, c'est à minima l'architecture des évolutions (quelles classes, quel algo / pattern prévu) pour avoir une idée de l'orientation prise par le dev. C'est fait sous forme d'UML simple quand le mec est motivé, sinon c'est bâclé.
 
Donc : je cherche à mettre en place un document de conception, relativement simple :
Si j'impose une usine à gaz, ça ne passera pas (SSII,  on doit pouvoir s'approprier le document rapidement cause turnover). Sans parler que je ne peux pas l'imposer, juste faire une proposition et la défendre pour qu'elle soit utilisée le plus souvent possible.
 
Est-ce que vous auriez des conseils à me donner là-dessus, comment emmener les gens à plus de conception pour leur en montrer l'intérêt ? A savoir que je peux pas aller au conflit, je n'ai pas le rôle de lead dev, ni autre (équipe d'une dizaine de personnes)...
 
Merci !
 
 
(si on peut éviter le passage : bouh pas bien le projet sans conception, ça doit être un beau merdier... Ça serait pas plus mal )

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)

Alors oui, j'ai effectivement oublié de donner des infos sur le projet : actuellement, on doit tourner autour de ~600k lignes de code, avec 6-7 dev).
Niveau doc, on a les specs générales, une pseudo-conception (historique) du projet et c'est à peu près tout. Par exemple, si je prend le module d'authentification utilisateur : j'ai zéro information sans aller taper dans le code.
 
Honnêtement, actuellement le projet n'a que peu de suivi. On fonctionne en tdd, mais j'ai l'impression que ce n'est pas très efficace dans notre cas (manque d'expérience, sans doutes).  
Comme je le disais, la plupart de la conception faite, c'est un document Word avec dedans trois noms de fonctions écrites, ce qu'elles feront, où elles vont se brancher et c'est à peu près tout. Du coup, 3 mois après on se dit 'merde, si on avait su on aurait pas fait comme ça' et doit refaire pas mal de code. D'où mon idée d'améliorer la conception, peut-être que je me trompe ?
 
Très, très peu de doc dans le code source, mais oui de ce côté là y a déjà un gros progrès c'est déjà ça.
 
Mais sinon ok, je craignais un peu l'affirmative mais, il n'y a pas de solution simple / rapide / pas chère / efficace à mettre en place..

Une métrique que tout chef de projet et dév devrait connaître : la conception, c'est environ 33% du temps nécessaire à obtenir le produit final.
Autre schéma que tout chef de projet et dév devrait connaître et garder en tête :  

 
Source : http://alconis.com/wp/2009/09/23/i [...] -logiciel/
 
On ne gagne jamais de temps en raccourcissant la phase de conception

Tu prêches un convaincu, d'où le post
 
Mais j'ai l'impression que c'est un sacré point noir des formations info aujourd'hui (mienne y compris) : ne pas assez insister sur la conception..

Pourtant, dans mon école d'ingé, on a fait du génie logiciel et on nous avait bien fait comprendre l'importance de la conception/modélisation. le pb, c'est que souvent, les dév très bons, sont très mauvais en doc car ça les gave... Pour bien faire, il ne faudrait pas que ça soit les mêmes qui font la conception et ceux qui codent. Là, ça oblige à être carré et ne pas omettre des infos importantes