Hallo,
Diese Technik nennt man dann auch "von unten hoch", oder?
Ja, ich habe damals im Studium auch gelernt, dass man grundsätzlich zwei Methoden unterscheidet, ein Projekt zu implementieren, nämlich "top-down" und "bottom-up".
Im Lauf der Jahre ist mir aber aufgefallen, dass meine eigene Methode keinem dieser beiden Modelle entspricht. Ich bezeichne sie gern als "inside-out". Damit meine ich nicht, dass ich das Innerste nach außen kehre, sondern dass ich "innen" mit einem Grundgerüst anfange, das erstmal nur ganz grob abstrahiert ist, aber bereits die wesentliche Struktur des Gesamtprojekts widerspiegelt. Dann fange ich erst an, die einzelnen Module im Detail auszuarbeiten, zu testen und dann in das Skelett einzuflechten. Und zwar ungeachtet der Modul-Hierarchie in einer Reihenfolge, die möglichst schnell in sich geschlossene, funktionierende Teilbereiche ergibt.
Bei der bottom-up-Methode arbeitet man dagegen anfangs sehr lange mit einzelnen Fragmenten, die dem Unbedarften nichts sagen. Es entsteht also für den Außenstehenden ziemlich lange der Eindruck, dass es keinen Fortschritt gäbe.
Ähnlich ist es mit der top-down-Methode, wenn man sie wirklich konsequent anwendet. Auch hier ergibt sich erst dann etwas Funktionierendes, wenn man endlich anfängt, die Low-Level-Elemente zu realisieren - also erst gegen Ende der "Evolution".
Und genau da sehe ich den Vorteil der inside-out-Methode: Man hat sehr schnell etwas, mit dem man sich und anderen (Kunde, Chef) zeigen kann, wie das fertige Produkt mal aussehen soll. Es gibt zwar anfangs eine Menge kleine Baustellen und Provisorien, aber man sieht sehr bald die Gesamtstruktur, und die meisten können sich damit am besten ein Bild über das fertige Produkt machen.
So long,
Martin