Je le répète : je n'ai pas dit qu'il ne fallait pas faire de modélisation mais qu'elle était souvent très mal faite.
Ce qui arrive trop souvent c'est qu'on te pond un cahier des charges long comme le bras parceque le client a des visions grandioses et veut un logiciel génial tout en ne sachant pas exactement ce qu'il veut en fait.
Tu prends donc des analystes et tu les enfermes dans une pièce pour qu'ils te pondent la modélisation qui va bien. Ils y passent donc du temps, se chamaillent, trouvent que le schéma est pas si joli, recommencent, enculent les mouches pour savoir des trucs dont on se fout royalement, font des réunions, des réunions, et encore des réunions (très important les réunions). Au final tu viens d'éclater le planning imparti à la modélisation et le logiciel n'existe même pas.
Tu mets donc tes développeurs au boulot et la tu te rends compte que l'expert C++ qu'une SSII t'as refilé est un mec qui a vient d'avoir sa maitrise de chimie, qu'il a eu un mois de formation dans sa SSII comme seule experience de l'informatique, qu'il peine à pondre un printf, alors tu penses bien que tes machins UML pour lui c'est des blagues de carambars.
Bref une fois que tu as réussi à faire coder tout ca, tu te retrouves avec un truc qui a explosé les délais, qui ne correspond pas a ce que veux le client (qui a changé d'avis 50 fois depuis le début du projet) qui couvre 10% des fonctions dont on aurait vraiment besoin et que personne ne veut et ne peut utiliser.
Bref, passer trop de temps sur la modélisation, c'est un moyen excellent de rater un projet.
Ca ne veut pas dire qu'il ne faut pas faire de modélisation, attention, mais juste qu'il ne faut pas trop sacraliser la chose.
[^] # Re: probablement
Posté par Aza . En réponse à la dépêche Documentation française sur MDA. Évalué à 10.
Ce qui arrive trop souvent c'est qu'on te pond un cahier des charges long comme le bras parceque le client a des visions grandioses et veut un logiciel génial tout en ne sachant pas exactement ce qu'il veut en fait.
Tu prends donc des analystes et tu les enfermes dans une pièce pour qu'ils te pondent la modélisation qui va bien. Ils y passent donc du temps, se chamaillent, trouvent que le schéma est pas si joli, recommencent, enculent les mouches pour savoir des trucs dont on se fout royalement, font des réunions, des réunions, et encore des réunions (très important les réunions). Au final tu viens d'éclater le planning imparti à la modélisation et le logiciel n'existe même pas.
Tu mets donc tes développeurs au boulot et la tu te rends compte que l'expert C++ qu'une SSII t'as refilé est un mec qui a vient d'avoir sa maitrise de chimie, qu'il a eu un mois de formation dans sa SSII comme seule experience de l'informatique, qu'il peine à pondre un printf, alors tu penses bien que tes machins UML pour lui c'est des blagues de carambars.
Bref une fois que tu as réussi à faire coder tout ca, tu te retrouves avec un truc qui a explosé les délais, qui ne correspond pas a ce que veux le client (qui a changé d'avis 50 fois depuis le début du projet) qui couvre 10% des fonctions dont on aurait vraiment besoin et que personne ne veut et ne peut utiliser.
Bref, passer trop de temps sur la modélisation, c'est un moyen excellent de rater un projet.
Ca ne veut pas dire qu'il ne faut pas faire de modélisation, attention, mais juste qu'il ne faut pas trop sacraliser la chose.