Bonjour,
 
J'aimerais savoir si il y'a une technique universelle pour préparer le développement d'un logiciel, décrire sont fonctionnement, son interface, etc...
Une démarche à suivre avec des étapes.
Alors oui il existe l'UML et tout ça, mais ce ne sont que des schémas qui permettent de décrire des parties du logiciel, pas une démarche en soi (un peu comme un dessin pour expliquer une idée).
Ou es-ce que coder à l'arrache avec son idée vague dans la tête est la seul solution viable ?
 
Merciii

Sacré sujet. Il y a bien DES méthodes (avec chacune ses avantages et inconvénients) pour concevoir un logiciel. Mais même en les suivant, tu n'as pas l'assurance d'obtenir le logiciel souhaité. Le cycle en V est le plus connu mais a un effet "tunnel" : tu vois les merdes au niveau utilisateur trop tard. En plus, si le logiciel est "gros", le client obtient les livrables plusieurs années après le début du projet.
C'est pour ça qu'on passe de plus en plus à des méthodes agiles avec un découpage du "gros" logiciel en lots plus petits sur lesquels on fait un mini-cycle en V. C'est mieux car on s'éloigne peut du chemin critique et de ce qui est demandé. Mais il faut être organisé en internet et chez le client pour gérer ce type de méthodo : c'est rarement le cas. En plus, certains logiciels sont difficiles à être découpés en lots car résultats en sortie non testables seuls.
 
Le plus gros problème vient du recueil du besoin auprès du client et de la compréhension de ce besoin par les différents intervenants qui n'ont pas forcément les mêmes objectifs en interne de l'entreprise réalisatrice.
 
Un schéma qui résume bien toute la problématique :  

 
Le top, c'est quand l'équipe qui recueille le besoin est la même que celle qui code et qu'elle connaît le contexte métier du client. Si en plus elle peut coder en étant sur place et avoir le client sous la main pour lever certains doutes, c'est le mieux. Perso, ça a été mon cas pour coder 2 logiciels : c'est super confortable.
 
Mais faire accoucher le client de ce qu'il a réellement besoin, c'est pas évident, surtout si la personne côté client ne fait pas partie des utilisateurs finaux. Or, c'est souvent un donneur d'ordre non utilisateur des principales fonction du logiciel qui va être l'interlocuteur de l'entreprise réalisatrice. Du coup, il va surtout blinder ce qui le concerne (souvent les fonctions de reporting). Du coup, ceux qui doivent utiliser au quotidien le logiciel auront souvent pleins de bugs ou de fonctions ne répondant pas au besoin ou mal. Un grand classique...
 
A titre indicatif, le temps nécessaire à spécifier le logiciel (recueil du besoin + écriture de la spéc + conception sur le papier) représente environ 1/3 du temps total du projet. Vouloir raccourcir cette phase est du suicide. Déjà que même en faisant bien attention dans cette phase, on n'est pas sûr de gagner à la sortie.
Donc une entreprise qui te dirait que pour économiser de l'argent, ils vont faire l'impasse sur certaines choses durant la phase de spécs/conception, tu fuis !
 
Si tu n'es pas de la partie (dév de logiciels) et que tu as un logiciel à faire réaliser, prends-toi un AMOA (assistance à maîtrise d'ouvrage) qui t'aidera a coucher sur le papier ton besoin et le spécifier. Il fera l'interface avec l'entreprise réalisatrice. Il te coûtera un peu d'argent (compter 350-400 € HT la journée) mais s'il fait bien son travail, il t'en fera économiser beaucoup par la suite en évitant que le projet dérape. On peut très facilement arriver à du simple au triple niveau budget juste parce que les spécs n'avaient pas été assez claires ou précises. Et dans ce cas, c'est soit le client qui paye, soit ça se finit au tribunal sans avoir l'assurance que l'entreprise réalisatrice devra prendre à sa charge le surcoût

"Ne vous inquiétez pas, nous allons utiliser une nouvelle méthode : ça s'appelle AGILE. Ca évite d'avoir à perdre du temps en analyse, car nous allons pouvoir commencer à travailler tout de suite sur le projet. Nous allons ensuite travailler en étroite collaboration, et nous ferons le point régulièrement avec vous pour affiner progressivement la proposition. Ca coûte moins cher au début, ça vous évite de réfléchir à ce que vous voulez, et c'est fun".

Bon sinon, la question du premier post est SUPER vague et il y a des dizaines de méthodes, plus ou moins viables selon le type et l'ampleur du projet.
Ca dépend aussi de si tu travailles pour toi même, pour un associé ou une tierce personne à qui tu rends service, ou pour un client qui va te péter les burnes au moindre détail oublié/pas comme il veut, et tout faire pour économiser à tes dépends.

Mais déjà
- Bien clarifier les modalités de travail et de facturation
- Recueillir et COMPRENDRE le besoin, avoir assez de recul pour être capable de dire au client quand ses idées sont foireuses. Le client n'est pas roi, le client est un abruti (un peu).
- Faire des maquettes d'interface, poser les règles de gestion, simuler des cas concrets
- Dans la mesure du possible, avoir l'avis des vrais utilisateurs du projet, pas juste d'un PM/AMOA propulsé là qui n'utilisera jamais le truc.
- Recommencer
- Encore

Et quand on se lance enfin :
- Utiliser des outils et des technos avec lesquels on est à l'aise et dans lesquels on a confiance. Si on veut faire joujou avec des trucs d'avant garde soit disant "dans 2 ans tout le monde utilisera ça, c'est le futur" bien réfléchir aux risques/avantages.

rooo putain, c'est tellement ça