Quelle est la meilleure méthode informatique ? C'est celle qui a été créée pour résoudre spécifiquement votre problème. La méthode objet fonctionne bien lorsqu'on a affaire à des objets et uniquement des objets. Après, cela fonctionne avec des rustines, des pirouettes et surtout du chantage : "Vous êtes contre les méthodes ?" Cela sous entend :"Vous travaillez sans méthode, vous faites du n'importe quoi". Et bien non, c'est l'inverse, quand on a compris, on n'a pas besoin de méthode.
Merise va très bien pour de petits projets où l'on pourrait s'en passer facilement, au delà, c'est une usine à gaz. Avec Merise, on fait le travail en double, sur papier et en programmation. En général, les évolutions du projet ne sont faites qu'au niveau programmation. Au bout de quelques années, tout le travail sur papier est périmé.
Relisez la méthodologie Mérise, plein de termes nouveaux inutiles, plein de verbes à inventer autres "qu"appartient à " ou "dépend de" qui ne servent à rien, sans oublier les dates systématique si on veut s'y retrouver. J'ai même acheté une méthode Merise de 400 pages que j'ai jetée car illisible. Comment peut-on faire simple en 400 pages ?
En fait, les méthodes sont une canne pour ceux qui ont peu d'expérience. Après, il ne faut surtout ne plus s'en servir.
La méthodologie informatique, c'est utile et c'est comme l'instruction : c'est ce qui reste quand on a tout oublié. Pourquoi toutes les grosse entreprises informatiques n'utilisent pas de méthode, à l'exception de celles qui vendent la leur ? Pour aller plus vite en évitant de se trainer un boulet.
Le but des méthodes n'est pas seulement d'aider à la conception, mais bien souvent de se mettre d'accord sur une vision commune de ce qu'on fait.
UML (objet) ou Meurise sont en fait plus proches qu'on ne le pense, surtout au niveau du Diagramme de classes (UML) ou du MCD (Meurise).
Un problème courant des différents projets sur lesquels j'ai travaillé sont les homonymes, où les confusions de termes : un "mot" qui prend des sens différents selon les acteurs. Le pire, c'est lorsque les personnes pensent parler de la même chose alors que ce n'est pas le cas, celà donne des situations ou de graves problèmes ne sont découverts qu'au moment de la livraison du système ou du correctif.
J'ai déjà travaillé avec des clients qui avaient des années et des années de métier derrière eux, ils voulaient l'informatiser autrement que par des tableurs. Pour eux, tout ce qu'ils disaient était très clair, mais en fait, en modélisant les processus, on s’apercevait qu'ils utilisaient très souvent des abus de langage et qu'un terme, selon les services de la même entreprise couvrait des réalités bien différentes. Parfois, certains termes étaient tellement utilisés dans des sens tellement différents qu'on avait l'impression de se trouver chez les "Schtroumpfs".
Là, le fait d'utiliser une modélisation a permis d'identifier les différentes entités (ou classes) de leur processus.
En effet, tout est bon pour se mettre d'accord sur ce qu'il y a à faire et chaque méthode apporte une autre façon d'appréhender un problème.
C'est sûr que Meurise est utile pour conceptualiser les données. Mais pour les traitements, je ne suis pas preneur, surtout dans les cas complexes.
Souvent chacune apporte aussi son propre vocabulaire pour représenter la même chose et cela embrouille, comme par exemple Objet et Fichier.
Elles ont tendance aussi à vouloir simplifier l'existant, parce que sinon cela devient trop compliqué. mais c'est à la législation de simplifier l'existant.
Au bout d'un moment, on se rend compte que l'on retrouve toujours de grands invariants : le Client, la Facture, le Virement, le Contrat, l'Article, l'Interrogation, la Mise à Jour, les Menus, etc.
Et utiliser des méthodes pour pour au final retomber dessus en utilisant un autre vocabulaire n'est que pure perte de temps et littérature.