@little_skunk
Das ein Code im QM aufgrund von Unlesbarkeit abgelehnt wird überrascht mich sehr. Den Testern die ich während meinem Praktikum kennenglernet habe, war es herzlich egal, wie kryptisch der Code war. Es wurden Testcases geschrieben und diese dann durchgeführt. D.h. das System wurde als Blackbox getestet. Aus Sicht des QM zum Kunden hin ist es doch gleichgültig, ob ich in meinen Code die fiesesten Abkürzungen usw. einbaue und nichts kommentiere oder ob ich alles schön ausführlich hinschreibe und immer schöne Kommentare hinterlasse. Wenn die Testcases durchlaufen und keine Fehler entdeckt werden bekommt der Kunde in beiden Fällen die gleiche Qualität (Wenn wir mal davon ausgehen, dass in keinem der beiden Fälle bessere Algorithemen bzw. geeignetere Datenstrukturen verwendet wurden). Der Kunde hat ja keinen Einblick auf den Quellcode. Wenn der Code später jedoch geändert werden soll, ist es natürlich um Welten effizienter schön leserlichen und gut kommentierten Code vor sich zu haben.
@topic
Ich finde die englische Erklärung erheblich besser, als die Deutsche.
http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design
Ich persönlich stelle mir Top-Down ähnlich einer Deduktion vor. Man schließt vom Allgemeinen auf das Besondere. Stelle dir zum Beispiel das allgemeine Problem vor, dass du ein Auto entwerfen sollst. Dieses Problem kannst du in verschiedene Teilprobleme aufteilen. So besteht ein Auto aus einer Karosserie, einem Motor, einem Fahrgestehl und vier Reifen (sehr vereinfacht). Um ein Auto zu entwerfen, musst du also erstmal eine Karosserie usw. entwerfen. Eine Karosserie, wiederrum, kann auch noch weiter unterteilt werden (Dies gilt auch für die anderen Komponenten). Wenn du nun so weitermachst erreichst du die Basiskomponenten, die nicht weiter unterteilt werden können. Du hast das Problem also Top-Down zerlegt.
Ich persönlich steller mir Bottom-Up ähnlich einer Induktion vor. Man schließt vom Besonderen auf das Allgemeine. Zuvor haben wir ja das Auto Top-Down entworfen. Der eigentliche Zusammenbau erfolgt jedoch Bottom-Up. D.h. wir bauen zuerst die Basiskomponenten zusammen, dann werden diese Basiskomponenten weiter zusammengebaut, bis du irgendwann bei der Kassorie, dem Motor usw. angekommen bist. Diese verbaust du dann zu deinem Auto. Du hast das Auto also Bottom-up zusammengebaut.
Wie du sicher gemerkt hast, war dieses Beispiel nicht aus der Softwareentwicklung. Was sich nämlich so einfach für ein Auto anhört ist in der Softwareentwicklung ein ziemliches Chaos. Dies liegt oft daran, dass sich Anforderungen (wie little_skunk bereits bemerkt hat) ändern oder nicht richtig verstanden wurden. Manchmal weiß der Auftraggeber selbst nicht so genau was er nun eigentlich will. Du denkst dir wahrscheinlich: "Ach die müssen nur richtig miteinander reden, dann klappt dass schon." Leider ( und wirklich leider) ist das nicht ganz richtig. Meist sind die Entwickler keine Experten in der Domäne des Kunden. D.h. sie kennen die Thematik des Kunden nicht. Gleiches gilt auch für den Kunden. Hier besteht also ein richtig großes potentielles Kommunikaionsproblem. Das Softwareengineering ist nicht umsonst ein stetig wachsender Teil der Informatik. Um das Problem der veränderten Anforderungen bzw. neuen Anforderungen während eines Projektes zu begegnen gibt es z.b. die agilen Softwareentwicklungsmetoden (z.b.: SCRUM oder Feature Driven Development). Weitere Katogerien sind z.B. sequentielle (Wasserfallmodell) oder prototypische (little_skunk hat das bereits erwähnt) Softwareentwicklungsmethoden.
Du siehst das ist echt ein weites Feld. Hier gibts auch noch ein bisschen Literatur:
http://www.informatikbegriffsnetz.de/arbeitskreise/vorgehensmodelle/publallg.html
