Twin-Peaks-Modell in der Softwareentwicklung

Wer kennt das Henne-und-Ei-Problem der Softwareentwicklung nicht, das da lautet, Architekten können erst mit der Architektur starten, sobald alle Anforderungen vorliegen? Anforderungsspezifikationen warten aber nicht immer mit der benötigten Präzision auf, was zum Beispiel daran liegt, dass sie nicht selten eine Wunschliste definieren. Die Abbildung von Problem- auf Lösungsraum gestaltet sich dementsprechend schwierig, Insbesondere auch die Technologieauswahl.

Genau genommen ergibt sich also folgender Sachverhalt:

• Softwarearchitekten sehen in den Anforderungen, was der Auftraggeber zu brauchen glaubt, nicht aber, was er tatsächlich benötigt.
• Anforderungen zu formulieren fällt ohne Bezugspunkt schwer. Es ergibt sich die Frage: Wie genau wirkt sich eine Anforderung auf das System aus?

Ein Wasserfallmodell tut so, als ob es bei dieser Reihung um eine zeitliche sequenzielle Reihenfolge geht. Erst kommen die Anforderungen, dann das Design. Punkt. Wie wir wissen, funktioniert das nur bei der formalen Herleitung eines Systems oder bei der wiederholten Konstruktion derselben Art von System. Für die Konstruktion eines sehr innovativen und neuen Systems ist das reine Wasserfallmodell schlicht untauglich.

In der Realität bietet es sich an, Anforderungsermittlung und Architekturentwurf verzahnt und parallel zu organisieren. Zunächst erfolgt in erster Näherung die Bereitstellung eines rudimentären Satzes wichtiger Anforderungen, etwa 30 Prozent der wichtigsten Anforderungen. Diese greifen Architekten auf, um daraus ein prototypisches System zu entwickeln, das sie dem Kunden präsentieren. Wenn etwas nicht den Vorstellungen des Kunden entspricht, wird es im nächsten Schritt gerade gerückt. Gleichzeitig testen Entwickler potenzielle Technologien aus dem Lösungsraum auf ihre Tragfähigkeit und durchlaufen Weiterbildungsmaßnahmen für eingesetzte neue Technologien.

Nur weil der Hochglanzprospekt eines Softwareherstellers/Zulieferers einen beeindruckenden Benchmark enthält, sagt das noch nichts darüber aus, wie sich das System in der Projektrealität verhält. Ganz zu schweigen von der undurchschaubaren Kombination verschiedener Technologien miteinander.

Grob entspricht das dem Vorgehen eines Gebäudearchitekten. Aus den Anforderungen des Kunden leitet er ein Design ab, dass er dem Kunden als Modell präsentiert. Schritt für Schritt entstehen aufgrund des Kundenfeedbacks veränderte Modelle, bis der Kunde und die Gewerke grünes Licht für eine Endversion geben. Auch das komplette Verwerfen eines Modells ist dabei jederzeit möglich.

Unterschied beim Software Engineering: In der Softwareentwicklung werden zwischenzeitlich die diskutierten Modelle prototypisch implementiert und Technologien bzw. Designs explorativ erkundet. Das ist bei anderen Disziplinen nur partiell möglich. Hier erweist sich das "soft" in Software als Alleinstellungsmerkmal und als Vorteil.

Leistet agile Softwareentwicklung nicht genau das gesagte? Ja und nein!

• Ja, denn das inkrementelle und iterative Vorgehen mit agilen Praktiken enthält einige Sicherheitsnetze, indem es zum Beispiel auch Refactoring vorsieht.
• Nein, denn bei der agilen Entwicklung wird in der berühmten Iteration 0 eine einigermaßen stabile konzeptionelle Architektur hergeleitet und schrittweise verfeinert. Ein komplettes Ersetzen dieser Architektur ist normalerweise nicht vorgesehen.

Es muss zumindest bei innovativen, risikoreichen Entwicklungsprojekten möglich sein, einen einmal eingeschlagenen Weg komplett zu revidieren, sobald sich neue Gesichtspunkte ergeben, wie es auch bei Erfindungen der Fall ist. Genau das leistet das Twin-Peaks-Modell.

Wer näher in die Thematik einsteigen will, dem empfehle ich eine Websuche nach dem Begriff "Twin Peaks Model".

()