Erinnern Sie sich an eine Serie, die in den Jahren 1991 unter dem Titel “Das Geheimnis von Twin Peaks” im deutschen Fernsehen lief? Ich habe sofort daran gedacht, als ich vom sogenannten Twin Peaks Model gehört habe. Im Gegensatz zur Serie (die übrigens in einem kleinen Städtchen namens “Twin Peaks” spielt) verzichtet das Modell auf ein dunkles Geheimnis oder mysteriöse Begebenheiten. Schließlich hatte hier David Lynch seine Finger nicht im Spiel. Aber das ist auch gut so, denn so gibt es weniger Verwirrung oder Streit darüber, wie man denn nun etwas zu interpretieren habe.
Das Twin Peaks Model ist da einfacher zu verstehen: Es beschreibt, wie Sie Anforderungen und Architektur eines Software-Systems effizient entwickeln.
Was als erstes: Anforderungen oder Architektur?
Der Ursprung des Twin Peak Models findet sich in der bekannten Dilemmasituation: Was muss als erstes da sein – die Anforderungen oder die Architektur?
Leider herrscht häufig das Wasserfallmodell in den Köpfen beider “Parteien”: In der ersten Phase entwickelt man die Anforderungen an das System, dann kommt der Systementwurf. Aber das führt oftmals zu mehr Aufwand und mehr Kosten im Projekt. Denn auf Änderungen wie neue Wünsche der Stakeholder oder neue technische Möglichkeiten schnell zu reagieren, fällt schwer. So resultiert diese Vorgehensweise in Anforderungen, die sich technisch nicht umsetzen lassen, oder in Architekturen, die Stakeholder nicht zufriedenstellt. Das kommt natürlich erst viel zu spät im Projekt zum Vorschein.
Daher schlug Bashar Nuseibeh im Jahre 2001 mit seinem Twin Peaks Model vor, sowohl Anforderungen als auch Architektur iterativ und parallel zueinander zu entwickeln [1]. Wie kam er zu diesem Namen?
Anforderungen und Architektur sind zwei gleichartige Berge
Der Name “Twin Peaks Model” stammt aus dem Englischen und bedeutet übersetzt etwa “Zwillingsgipfel” – also zwei gleichartige Berge. Ein Berg repräsentiert die Anforderungen, der andere die Architektur. Beide sind gleich hoch und gleich wichtig. Beim Twin Peaks Model erklimmen Sie diese Berge jedoch nicht. Stattdessen setzt man Sie auf dem Gipfel ab und Sie müssen Ihren Weg nach unten finden. Irgendwie gemein. Denn erfahrene Bergsteiger wissen: Der Abstieg ist genauso anstrengend, wenn nicht sogar anstrengender, als der Anstieg. Tatsächlich gibt es sogar drei Möglichkeiten, um den Berg sicher hinunterzukommen: taloffen (Rücken zum Berg), seitwärts und frontal (Brust zum Berg) [2]. Toll, wieder etwas gelernt! Bevor ich aber ganz abschweife, noch eine kurze Erläuterung des Bergabstiegs im Sinne des Twin Peaks Model:
Sie fangen mit groben Anforderungen und Architekturmodellen an und verfeinern sie parallel zueinander im gegenseitigen Wechselspiel. So gelangen Sie vom schmalen Gipfel der Berge zu immer mehr und immer detaillierten Anforderungen und Architekturelementen.
Das Twin Peaks Model: Verfeinerung der Anforderungen und Architektur
Jetzt stellt sich die Frage: Wer soll denn jetzt die erste Arbeit leisten, also den ersten Schritt machen?
Stal schlägt vor, als Start circa 30 % der wichtigsten Anforderungen an das System rudimentär zu entwerfen [3]. Darauf basierend entwickeln die Architekten Prototypen, holen Feedback der Stakeholder ein und überarbeiten die Entwürfe. Bevor sie das Rad neu erfinden, prüfen die Architekten z.B. auch, ob sie vorhandene Lösungen einsetzen können. Mit der Entwicklung der einzelnen Komponenten verfeinern sich auch die Anforderungen.
Keiner darf hier also in sein stilles Kämmerlein verschwinden und das eigene Süppchen kochen. Alle Beteiligten müssen kontinuierlich miteinander kommunizieren.
Fazit
Die Entwicklung der Anforderungen und Architektur zu trennen und wasserfallartig vorzugehen, führt zu unbefriedigenden Ergebnissen. Das Twin Peaks Model liefert ein Konzept, das die Ideale der agilen Entwicklung widerspiegelt und mit dem Sie iterativ zur passenden Lösung gelangen. Doch wie können Sie effizient Anforderungen und Architektur parallel entwickeln und verfeinern? Wie sorgen Sie für Traceability und dafür, dass alle Beteiligten miteinander kommunizieren und die Informationen austauschen können?
Dafür haben wir die passende Software: objectiF RPM ermöglicht es Ihnen u.a., mit Diagrammen wie Anforderungsdiagrammen sowie Block- oder Klassendiagrammen zu arbeiten, diese in Dokumente zu generieren oder auszutauschen. Nachvollziehbarkeit ist immer garantiert, da Sie Systemkomponenten mit Anforderungen in Beziehung setzen und diese Beziehungen auswerten können. Änderungen im Projekt sind dadurch kein Problem mehr!
Ein Blockdiagramm in objectiF RPM
Ein Anforderungsdiagramm in objectiF RPM
Einen ersten Einblick in die Features erhalten Sie hier. Oder werfen Sie einen Blick in unser Whitepaper.
Hinweise:
[1] Nuseibeh, B. (2001). Weaving the Software Development Process Between Requirements and Architecture. Proc. Of ICSE 2001 Workshop STRAW-01. Toronto.
[2] Bloch, R. (2011). So gehen Sie sicher im unsicheren Gelände. Von ALPIN http://www.alpin.de/sicher-am-berg/7258/artikel_so_gehen_sie_sicher_im_unsicheren_gelaende.html abgerufen.
[3] Stal, M. (2016). Twin-Peaks-Modell in der Softwareenticklung. Von heise Developer https://www.heise.de/developer/artikel/Twin-Peaks-Modell-in-der-Softwareentwicklung-3133582.html abgerufen.