Herangehensweise an Softwareprojekte
Wenn man vor der seltenen Herausforderung steht, ein völlig neues Softwaresystem zu erfinden, dann gibt es nur eine handvoll sinnvoller Möglichkeiten.
Der Glaube an den Plan
Der Auftraggeber beschreibt im Detail alle benötigten Funktionen und Prozesse. Der Softwarehersteller übersetzt diese Anforderungen in eine Reihe von Modellen und Diagrammen (Use Cases, Strukturmodelle, Objektdiagramm, Datenmodell, Verhaltensmodell, State Engine - die Liste ist lang). Anschließend wird das System anhand der Modelle programmiert.
Jeder, der schon einmal an einem Software-Entwicklungsprojekt mitgearbeitet hat, bei dem diese Herangehensweise gewählt wurde, weiß, dass die Annahme unrealistisch ist, der Auftraggeber sei in der Lage, das Endprodukt vollständig zu beschreiben. Es gibt nur wenige Menschen, die mit dem genialen Vorstellungsvermögen eines Felix Wankel gesegnet sind.
Iteration
Man wird also vernünftigerweise eine schrittweise Herangehensform wählen. Der Auftraggeber beschreibt die wesentlichen Ziele eines großen Funktionsblocks. Der Softwarehersteller setzt diesen um, am besten in engem Kontakt zum Auftraggeber. Im nächsten Schritt wird diese Umsetzung verfeinert und verbessert. Danach widmet man sich in gleicher Weise dem nächsten großen Programmblock.
Das in dieser bewährten Weise entstehende Softwareprodukt kann somit nur schwer von Anfang an eine Architektur aufweisen, die die späteren Komponenten berücksichtigt. Kommt beispielsweise bei einem Webshop erst nachträglich die Anforderung auf, Teillieferungen zu generieren, wenn einzelne Artikel längere Bestellzeiten haben, dann wird das entweder einen größeren Umbau erfordern oder es wird an verschiedenen Stellen "angeklebt".
Im ersten Fall wird die Entwicklung dieser Anforderung direkt zu hohen Kosten und langer Wartezeit führen, im zweiten Fall später - denn das Gesamtsystem würde durch die angeflanschten Querverbindungen starrer, schwieriger zu durchschauen, fragiler und vor allem komplexer. Dabei ist nicht die notwendige Komplexität das Problem, sondern die gewachsene Komplexität - a.k.a. Chaos.
Modularisierung
Diesem Effekt versucht man, durch einen hohen Grad an Modularisierung entgegenzuwirken. Jeder Programmierer weiß: Spaghetticode ist schlecht, Module sind gut. Praktisch jedes größere Softwareprojekt wird heutzutage objektorientiert und damit modularisiert umgesetzt. Warum aber wirken sich trotzdem bei sehr vielen IT-Systemen nach wenigen Jahren die Untiefen in der Komplexität lähmend auf die Weiterentwicklungsgeschwindigkeit aus?
Das liegt oft daran, dass in gereifter Software hunderte von Modulen in einer empfindlichen Choreografie zusammenwirken. Jede Störung bringt das Ballett aus dem Tritt. Schlimmstenfalls ist selbst das Abschalten des Systems nicht mehr ohne Schaden möglich. Die Module des Systems verhalten sich wie die Organe eines Körpers, bei dem lokale Störungen das Funktionieren des Gesamtsystems behindern können. Versuchen Sie mal, mit einem entzündeten Zehennagel Squash zu spielen.
weiter mit Scatterware Architekturüberlegungen