Bah, personnellement, je n'ai pas trop l'habitude de faire beaucoup de conception (design) à l'avance, je me plonge directement sur mon code C/C++, et le programme et sa structure (qui a en général tendance à être plutôt monolithique et procédurale, je n'ai pas vraiment internalisé la pensée "objet") se crystallisent au fur et à mesure que je code.

Un invariant auquel je tiens beaucoup est que le code doit rester compilable au fur et à mesure que je développe. Quand je fais des modifications qui rendent le code non compilable, j'essaie toujours de corriger ça d'abord avant de continuer. Ceci me permet de corriger les fautes facilement (parce que le compilateur me les indique), faire des tests dans une certaine mesure et effectuer des commits réguliers tout le long du développement. Par conséquent, ma stratégie est quelque part entre le top down strict (la manière naturelle de coder sans plan: on code, on voit les fonctions qui manquent, on code ces fonctions etc.) et le bottom up strict (la meilleure manière de garantir la compilabilité: on ne code pas une fonction avant d'avoir les fonctions dont on a besoin codées). Parfois, je travaille top down, parfois bottom up (sur le même logiciel), et souvent je code le long du fil d'exécution (je code, je vois que je veux appeler une fonction qui n'existe pas encore, donc je code la fonction, ensuite je reviens à la fonction appelante; oui, c'est très procédural comme manière de fonctionner).

L'UML, je n'en vois pas vraiment l'utilité, ça ne rentre pas du tout dans ma manière de fonctionner.