Bon, je connais pas les méthodes de dév logiciel étant donné que je me suis surtout formé sur le tas, donc il se peut que je raconte des conneries, mais y'a quelque chose que je voudrais souligner :

Je trouve que beaucoup de 'méthodes' abusent du "top-down", en faisant croire que la réflexion/planification préalable c'est 99% du boulot et qu'une fois que c'est fait, la prog se fait toute seule ou presque. Je ne dis pas qu'il ne faut pas réfléchir avant de coder, c'est indispensable au contraire, mais je pense aussi qu'il est dangereux de trop s'abstraire de l'implémentation :

- commencer à implémenter (en partie) assez tôt, ça permet de vérifier la viabilité des choix
- et surtout, ne raisonner que sur papier, c'est un excellent moyen de faire un système formidable sur papier, mais "surconçu", lourd, lent, voire irréalisable en pratique.

Avec la puissance des machines actuelles, on a pas mal de marge de manœuvre, mais sur des plateformes limitées comme une TI (ou pire, des systèmes embarqués à faible coût), il est illusoire de séparer planification et implémentation : faut avoir en tête les contraintes matérielles dès le début, à partir du moment où on écrit le cahier des charges. Savoir ce qu'on veut c'est bien, savoir ce qu'on peut faire c'est essentiel.

(oui, ceci est indirectement un coup de gueule déguisé contre les soi-disant profs d'algo qui commencent leur cour par "on va supposer qu'on a une machine avec une mémoire illimitée", ceux qui prétendent "n'importe qui peut coder, y'a que le design qui compte", et les supérieurs qui te disent "au fait j'ai promis ça, ça et ça comme features au client, je sais pas comment faire mais je suis sûr que tu vas trouver un moyen pour l'implémenter". 3,2,1, flammez )