Die Hierarchisierung dient der Zerlegung eines Problems in Teilprobleme Die Teilprobleme können dann isoliert für sich betrachtet werden. Es ist immer einfacher mehrere Teilprobleme zu lösen als ein Gesamtproblem. Die Vorgehensweise ist hierbei typischerweise top-down (von oben nach unten), weil ein großes Problem in mehrere mittlere Probleme zerlegt wird, die dann in noch mehr kleine Probleme zersplittert werden. So wird das Projektziel in Teilziele und weiter in konkretere Schritte zerlegt, ganz nach dem chinesischen Sprichwort oben auf dieser Seite. Aus den Teilzielen ergeben sich bei der späteren Realisierung dann auch die Arbeitspakete und damit die Projektmeilensteine und Programmversionen.

Weil ganze Sub-Bäume der Hierarchie voneinander getrennt verlaufen, können in den späteren Projektphasen auch mehrere Entwickler oder gar mehrere Entwicklerteams parallel arbeiten und auch die Qualitätssicherung und die Handbuchschreiber können ihre Arbeit besser aufteilen.

Aus der Zerlegung bei der Hierarchisierung entstehen einzelne Module, die nur über definierte Schnittstellen mit den umgebenden Modulen kommunizieren können und ansonsten kontextunabhängig sind. Wenn diese Schnittstellen vorab präzise definiert werden kann ein Modul in späteren Projekten vielleicht auch wieder benutzt werden und zum treuen Begleiter über mehrere Jahre werden. Durch diese Wiederverwendbarkeit verringert sich in den Folgeprojekten der Entwicklungsaufwand und gleichzeitig erhöht sich die Robustheit der Software, weil bereits getestete, erprobte und sogar bewährte Module zum Einsatz kommen. Diese Module werden zunächst sicherlich in Prosa mit dem Kunden besprochen und dann iterativ immer präziser spezifiziert und durch Änderungsanforderungen im Laufe der Zeit auf dem aktuellen fachlichen Stand gehalten.

Bei der späteren Programmierung der Module werden Code und Daten der gekapselt und über eine gemeinsame Schnittstelle von der Umgebung isoliert. Daher können auch Fehler recht schnell auf Module eingegrenzt und damit lokalisiert werden. Ändert sich durch die Fehlerbehebung die Schnittstelle des Moduls nicht, so ist in der Regel auch der Folgetest nach der Änderung auf eine kleine Anzahl von Modulen begrenzt. Diese Aspekte zeigen deutlich die Wichtigkeit sowohl von Definition als auch von Dokumentation der Schnittstellen.

Die Module selbst ergeben zusammengesetzt wieder die Hierarchie, wobei die Schnittstellen das Zusammenspiel der Module definieren. Die Module selbst sind aus Sicht der Hierarchie Black Boxes, denn es sind nur deren Namen, Aufgabenbeschreibungen und Schnittstellen, aber nicht die Inhalte sichtbar.

Bei der fortschreitenden Entwicklung des Software-Systems müssen natürlich alle Module spezifiziert und letztendlich programmiert werden. Hierfür ist übrigens ein außerordentlich hohes Maß an Disziplin erforderlich, weil sehr viel Detailkram entdeckt, analysiert, diskutiert, hinterfragt, dokumentiert, getestet und manchmal auch wieder verworfen werden muss. Dabei das gesamte Analysedokument stets aktuell und konsistent zu halten, erfordert wirklich eine immer wieder erstaunliche Akribie.

Jeder gefundene Lösungsansatz einer analysierten Fragestellung wirft in aller Regel wieder weitere Fragen auf, die wieder analysiert werden müssen. Dies scheint lange Zeit kein Ende zu finden, weil der Fragenberg immer größer statt kleiner wird. Dabei ist es sehr wichtig, stets das passende Abstraktionsniveau zu finden und zu halten. Gegebenenfalls muss ein Modul nochmals gesplittet werden, weil sich bei der Strukturierung des Moduls noch zuviel Komplexität zeigt. Vielleicht zeigt sich aber auch, das es in dem Modul kaum etwas zu strukturieren gibt und das Modul sehr gut mit einem Nachbarmodul verschmolzen werden kann. An dieser Stelle wächst oft die Ungeduld, weil man sich schon viel weiter wähnte, als man in Wirklichkeit ist. Aber unser Kopf ist schließlich rund, damit das Denken die Richtung ändern kann - also sollte man die neu gewonnenen Ansichten auch umsetzen!

Miller [L8] zeigte schon sehr früh, dass der Mensch sehr gut 7 ± 2 Aspekte überschauen kann. Daran sollten Sie sich orientieren, wenn Sie Ihr Problem zerlegen, hierarchisieren und aufgrund der Ergebnisse der Strukturierungsansätze die Module neu verteilen. Nach jeder Neuverteilung können Sie die nächste Iteration einläuten, also wieder auf Lücken und Widersprüche prüfen und die angepassten Module neu strukturieren.

Für viele Programmierer hat dies nichts mit Programmierung zu tun und sie haben Recht! Denn dies hat vielmehr was mit Softwareentwicklung zu tun; die Programmierung ist nur ein Teil der Softwareentwicklung, aber eben genau der, den die meisten Softwareentwickler am liebsten mögen. Daher wählen sie oft eine vermeintliche Abkürzung und lassen den ganzen Analyse-, Spezifikations- und Dokumentationskram einfach weg. Der Erfolg gibt ihnen zunächst Recht, denn sie haben sehr schnell ein Stück Software am Laufen - aber die Rache der Software ist stets so groß, dass die gewonnene Zeit schnell wieder aufgebraucht ist - von Stabilität, Wartbarkeit und Widerverwendbarkeit ganz zu Schweigen!

In der Regel wird bei der Programmierung der fertig spezifizierten Module die mittlerweile klassische Form der Realisierung mit Funktionen, Variablen, Entscheidungen, Schleifen, usw. eingesetzt. Auch bei der objektorientierten Programmierung sehen beispielsweise die Methoden der Klassen der Geschäftslogik oft sehr strukturiert aus! Es sollten allerdings stets möglichst moderne Verfahren für Fehler-Reporting, Transaktionskontrolle und Protokollierung benutzt werden. Der Entwicklungsrahmen muss natürlich auch Verteilungskonzepte für Server-Landschaften und Skalierbarkeit berücksichtigen.