Sasume (./12) :

L’approche bottom-up est intéressante car elle te conduit généralement à développer des petits composants réutilisables, indépendant du reste de l’application : tu vas par exemple développer une routine chargée d’afficher un sprite, une autre chargée de réaliser une autre tâche, etc. Au final chaque fonction fera une seule chose et le fera bien. Cependant, une telle approche peut te conduire à te disperser : tu risques de développer plein de petits composants éparpillés et ça peut être compliqué à assembler, ou simplement faire trop de choses par rapport à tes besoins.
C’est là que l’approche top-down est intéressante : elle te conduit à dessiner les grandes lignes de ton programme, sans te préoccuper de certains détails qui pourront être affinés ultérieurement, et permet d’obtenir un code assez concis, rapidement testable. L’inconvénient c’est qu’en procédant de la sorte tu risques d’introduire du couplage entre tes composants, ce qui pourra poser des problèmes si ton architecture change à un moment ou un autre.

Tiens, c'est marrant, pendant mes études on m'a "éduqué" à ces deux méthodes, mais sans me les nommer.
Cela dit, personnellement, je cumule un peu ces deux approches : je fais d'abord un top-down au moment de l'analyse avec les demandeurs (qui veulent souvent un prototype réalisé à l'arrache - fonctionnel ou pas, d'ailleurs ; ça se résume souvent à une IHM ayant le rendu final - pour tester et demander de nouvelles fonctionnalités), puis je fais du bottom-up en effectuant une réécriture totale (ou presque) très modulaire (c'était la méthode préférée de notre prof d'algo - qui était aussi et surtout prof de maths - parce que ça nous permettait en tant qu'étudiants de réaliser que les gros problèmes ont souvent besoin d'être découpés en petits problèmes qui, au final, sont assez triviaux).

Je dirais que le top-down permet d'avoir plus d'échanges avec les demandeurs (les clients, quoi, mais dans mon cas ça n'en sont pas), alors que le bottom-up est ce qui me permet d'avoir un code modulaire, réutilisable et plus facilement évolutif.

Bon, dans la réalité des faits, mon bottom-up est (malheureusement) toujours un peu bâclé faute de temps

Souane (./6) :
Du haut de mon très très peu d'expérience et de cours de génie logiciel, je dirais que, peu importe ce que tu choisis comme méthode, ce qui compte avant tout c'est que tu sois convaincue de son bien-fondé et que tu restes organisé.

L'objectif du programme est aussi très important... en particulier, ces points qui (à mon sens) sont cruciaux :
- quelle est la durée de vie du programme ? (il m'arrive d'avoir à écrire des applications - plutôt petites - dont la durée de vie ne sera que d'un an, voire moins, parce qu'on sait que les règles du jeu vont changer suite à des directives ministérielles ou autres...)
- quel est le niveau d'évolutivité potentiel du programme ? (est-ce que l'histoire nous dit que les processus en liens avec l'application évoluent souvent ou pas ?)
- qui peut avoir à retravailler le code de l'application ?

Dans le cas où l'application va pas mal évoluer et sur une longue durée, on a intérêt à utiliser des méthodologies assez classiques qui permettront à n'importe quel informaticien de reprendre le travail.
Si la durée de vie est courte (deux à trois ans) je pense personnellement qu'on peut se permettre d'employer des méthodes plus libres et plus souples.

(Bon, mon expérience est aussi assez limitée : je n'ai pas ou peu travaillé sur de très très gros projets avec de grosses équipes de développeurs, donc ça joue aussi sur ma façon de faire).