Wenn man sich mit Softwareentwicklung beschäftigt wird man, gerade als Anfänger, auf das Wasserfallmodell stoßen.
http://de.wikipedia.org/wiki/Wasserfallmodell
Um ein grobes Verständnis von Softwareentwicklung zu bekommen genügt das.
Nun ja... das "Wasserfallmodell" kommt nach meiner praktischen Erfahrung real eher nur noch noch ganz unten bei Großprojekten zum Einsatz...
Für echte kleine Kundenprojekte wo es keinen Softwarearchitekten als Planer gibt, also der Kunde seine Anforderungen als Vorgabe gibt, da läuft es fast immer so:
http://de.wikipedia.org/wiki/Extreme_Programming
Wie ein Projekt läuft, hängt auch stark vom existierendem Hintergrund ab. Wenn Kunde B nur ein SubSet der Funktionalität einer lösung will, die man für Kunde A schon vor Jahren realisiert hat, dann kommt es durchaus vor, das man 60% des Codes ungenutzt lässt und nur die gewüschte Sollfunktion in per
GUI/Schnittstelle realisiert.
Bei völligem Neuland und "10" Anforderungen, kann man schon Meilensteine definieren und diese einzeln realisieren. Wenn man sich selbst und erst recht im Team von Anfang an 100% gekapselte autonome Module/Schichten hält, kann man auch später mit vertretbarem Aufwand mal eine komplette Schicht austauschen oder neu schreiben. Da es eh keine perfekte Software gibt, realisiere ich lieber zeitnah funktionierende Software, deren sinnvolle strukturelle Grenzen ich kenne.