Discussion :

[Sylvanas]

On imagine, on développe, on débug, ça tourne, super je suis le meilleur !
Hein quoi ? Un dossier de programmation, pour quoi faire ?


Vous avez certainement été confrontés à cet épineux problème. Je dois avouer moi-même n'avoir jamais vu de dossier correctement ficelé. Tout au plus le source imprimé, mais c'est insuffisant pour permettre à un autre développeur de s'imprégner de la philosophie qui a amené à choisir telle ou telle solution plutôt qu'une autre et surtout mettre le doigt rapidement sur les fonctions/objets à modifier pour maintenir l'application.


J'aimerais donc connaître vos méthodes permettant de monter un dossier utile et complet.


Mes idées :

- Lister les références : sites webs, livres, etc...
- Démontrer pourquoi telle solution a été choisie pour répondre au cahier des charges
- Disséquez le programme en modules et montrer l'interconnexion des différentes parties (quelle est le meilleur moyen de représentation du fonctionnnement d'un programme ?)
- Commenter le code (mais ça tout le monde le fait, surtout lorsqu'on utilise des astuces pas très évidentes à comprendre au premier abord)
- Dans le cas d'une application orientée-objet... dont le fonctionnement est basé principalement sur des événements... ça part dans tous les sens !!! Je ne vois pas comment décrire ça .

Ce que je pense ne pas être adapté :

- Organigramme ? trop long et beaucoup trop grand, et personne n'imprime en A0
- Lister les fonctions, sous-fonctions et décrire leur fonctionnement ?
- Impression du source ? Je ne sais pas si c'est utile... protégeons la planète et ne gaspillons pas de papier

[Franck.H]

Si tu commentes ton code ok c'est super et meme indispensable mais si tu travail à plusieures personnes sur un même projet, le mieux est encore de commenter de sorte de pouvoir sortir une doc technique sur le code avec Doxygen !

[Neitsa]

Bonjour,

Est-ce qu'un langage de modélisation objet comme UML par exemple, ne répondrais pas à une grande partie de tes attentes Franck ?

[Franck.H]

Bonjour,

Est-ce qu'un langage de modélisation objet comme UML par exemple, ne répondrais pas à une grande partie de tes attentes Franck ?

Je programme pas en objet

[Neitsa]

Je suis vraiment désolé Franck, je voulais répondre à Sylvanas en fait

Mais il est vrai qu'UML est largement moins pratique pour les langages impératifs bien qu'il soit toujours possible techniquement de modéliser quelque chose.

Outre la très bonne remarque de Franck qui concernais l'utilisation de Doxygen, je crois qu'en couplant ce dernier avec des diagrammes UML on obtient une bonne vue générale concernant un logiciel.

[Caine]

Ta question concerne des développements personnels plus que professionnels, c'est bien ça?

Si tu as déjà travaillé en entreprise, reprends la même typologie de document (moins exhaustif)

1 Cahier des charges: Savoir l'objectif du logiciel. La plupart des choix de conception en découlent : Déploiement sur un seul système ou mutliplatform, base de donné, connectivité à internet...

2 Spécification: Deux écoles suivant s'il y a découpage en 2, soit détaillées direct, soit générale. Ici il est question du découpage en couches applicatives, en modules et fonctionnalités. On affine plus ou moins suivant l'usage.

3 Conception logicielle : Détaillée jusqu'à la fonction ou plus globale. Au minimum : Les modules, leurs interactions qui permettra de faire les analyses d'impact des modifications. Parfois des diagrammes de classe, de séquence et autres suivant le langage retenu.

4 Tests logiciels : Prévoir un plan de test, le détail des tests, une matrice de couverture du code ou des exigences de test. Pour un dev personnel, c'est souvent très (trop?) réduit. Bien sur en annexe ou dans un autre document: le résultat des tests pour chaque version.

Après ça peut différer suivant le temps, la motivation...

Dans mon dernier dev personnel, par manque de temps, je n'ai pris que des notes globales sur le projet. Mais quand j'aurais plus de temps, je vais écrire les documents à partir de mes notes.

[Tijee]

Bingo Caine a très bien répondu !

J'ajouterai que pour la spécification et la conception, et pour répondre à la question de l'UML, il y a la méthode Merise qui permet de modéliser une application si elle n'est pas orientée objet (et même si elle est orientée objet d'ailleurs, l'un n'empêche pas l'autre)...