Discussion :

[Christophe Genolini]

Bonjour,

J'ai un logiciel dans la tête. Je travaille avec un collaborateur et nous le développons. Le projet intéresse d'autres personnes. Il me faut donc expliquer ce qu'on est en train de faire. Il me faut l'expliquer "globalement" (objectif du logiciel) mais aussi "localement" (dans tel sous-sous-menu, il y aura un bouton qui fera ca) et informatiquement (nous stockons les données sous tel et tel format, telle fonction fait ca et ca).

Quand j'étais étudiant, pour décrire un logiciel, on utilisait un machin appelé "l'analyse descendante". Maintenant c'est obsolète. D'ou ma question :
Comment faire pour expliquer tout ca a un nouvel arrivant ? Quel type de document faut-il lui donner ? Peut-on trouver des exemples (ou des tutoriaux) sur le web ?

Christophe

[nnovic]

Quand j'étais étudiant, pour décrire un logiciel, on utilisait un machin appelé "l'analyse descendante". Maintenant c'est obsolète.

Hello,

Je réagis à cet extrait de ton message. Les moyens de représenter et de détailler ton projet son plus différents aujourd'hui, mais le principe directeur est globalement le même: tu pars de l'idée général du projet, et petit à petit tu entre dans les détails. Il y a plusieurs méthodologie, mais le mieux c'est encore que tu utilises l'approche avec laquelle tu te sens le plus à l'aise.

Dans un premier temps il faudrait que tu apportes, dans les grandes lignes, les réponses aux questions essentielles: un projet qui fait quoi, pour qui, avec quelle approche du problème, etc...
Ex: - "une calculatrice destinée aux professionnels du bâtiment mais où l'on peut utiliser les unités pifométriques"
- "un logiciel pour le grand public qui déclenche une alerte lorsque le patron arrive"

Partant de là, je te conseille de lister en vrac toutes tes idées, dans l'ordre dans lequel elles te viennent. Un outil de mind-mapping pourrais t'être utile à ce moment-là.

Ensuite, tu pourras faire le tri dans tes idées en séparant:
- le fonctionnel ("il faut une fonction sauvegarde", "le logiciel doit se lancer tout seul au démarrage du PC", "plusieurs utilisateurs travaillent en même temps", ...)
- le technique ("la sauvegarde se fera dans une base de données", "il faut paramétrer un service dans Windows", "architecture client-serveur", ...)
- le design ("menu Fichier>Sauver + icône dans la barre de raccourcis", "un icône dans la barre de notification indique que le service s'exécute", "une fenêtre donne la liste des utilisateurs qui travaillent déjà sur le même fichier", ...)

Dans un premier temps, concentre-toi sur les idées qui te viennent naturellement. Ensuite, il faudra compléter ces informations en explicitant les parties qui te semblent évidentes, mais qui ne le seront peut-être pas pour une personne qui n'est pas dans ta tête. Ex: "Mais tu ne m'as jamais dit que le logiciel devait être en espagnol !! - Mais c'était pourtant évident !!"

[DonQuiche]

Bonjour.

Pour une communication informelle je te recommande un mélange de cas utilisateurs (l'utilisateur a tel problème, le logiciel peut le résoudre pour lui de telle façon) et quelques esquisses d'UI pour donner une idée du logiciel.

Selon le public tu devras choisir de te placer à un plus haut niveau (valeur créée) ou plus bas niveau (vous cliquez sur ce bouton, puis sur celui-là, et voilà).

[Christophe Genolini]

Merci pour vos conseils.
Est-ce que vous auriez des exemples "réels" de tels documents (éventuellement in English) ?

[DonQuiche]

Cas d'utilisation informel pour usage interne :

Réponse à une discussion :
* L'utilisateur souhaite ajouter un message à une discussion.
* Il clique sur le bouton "répondre à la discussion". Il est alors dirigé vers une nouvelle page avec un cadre pour le texte du message, quelques contrôles de mise en en forme (gras, italique, taille police), un bouton d'envoi, un bouton de prévisualisation.

Pour l'esquisse d'UI, je t'invite à chercher "ui sketch". Souvent une telle esquisse suffit à donner au programmeur toute l'info dont il a besoin et à l'occuper pendant plusieurs jours ou semaines.

Enfin ne cherche pas à constituer une documentation trop importante. Crée-la au fur et à mesure des besoins et de la répartition des tâches. Veille simplement à ce que le nouveau venu sache bien sur quoi il travaille et pour qui. Pars du principe que les besoins changeront, qu'en cas de doute ton programmeur viendra te demander, qu'il est doué d'intelligence, et que ton code source constitue déjà une documentation.

[Laurent 1973]

L'Agilité est un mode d'organisation d'équipe informatique qui se développe bien (voir https://fr.wikipedia.org/wiki/M%C3%A9thode_agile).

Inspiré de cette mouvance, tu peux essayer de décrire ton projet sous la forme d'ensemble de petits cas d'utilisation (Use case ou User story) simples et précis.
Voilà un exemple: https://www.mountaingoatsoftware.com...acklog/example
Avec une règle: ne pas se censurer et mettre toute tes idées, même les plus folles.
Ensuite, il est bon de les prioriser pour mettre en avant les fonctionnalités indispensables du "nice to have"
=> Autre site intéressant pour créer une User Strory: http://blog.palo-it.com/2014/02/11/r...nes-pratiques/

Dans ce type de description, tu commences toujours par identifier pour quel utilisateur cette fonctionnalité est nécessaire.
Cela permet aussi de placer les différents intervenant dans le bon contexte.
Et tu précises toujours le but de la fonctionnalité.

C'est justement le plus important dans la formalisation d'une demande: bien décrire le but de ton projet.
le "comment" ce ne doit pas être ton problème, l'important pour toi à décrire c'est "pourquoi".
Donc, à aucun moment tu ne dois parler de choix technologique autrement qu'en exposant des contraintes (ex: ce doit fonctionner sur Mac, les utilisateurs sont nuls en informatique, ce doit fonction 24h/24 7j/7, ...)
Et c'est l'équipe informatique, qui en fonction de ces contraintes et des principaux besoins, doivent faire le choix technologique.