Twin Peaks Model
Inhaltsverzeichnis: Definition – Ursprung – Visualisierung – Parallele Entwicklung – Vorteile paralleler Entwicklung – Kommunikation – Download – Architektur im Blick – Hinweise
Wissen kompakt: Das Twin Peaks Model beschreibt die Konkretisierung von Anforderungen parallel zur Erforschung passender Systemarchitekturen.
Twin Peaks Model Definition
Das Twin Peaks Model beschreibt, wie Sie Anforderungen und Architektur eines Systems iterativ und parallel zueinander entwickeln. Es liefert die Antwort auf die Frage “Was muss zuerst entwickelt werden – die Anforderungen oder die Architektur?”. Es veranschaulicht die zusammenhängenden Aktivitäten des Requirements Engineerings und der Entwicklung der Systemarchitektur.
Der Ursprung im Spiralmodell
Das Twin Peaks Model ist eine vereinfachte Version des Spiralmodells und geht auf Professor Bashar Nuseibeh zurück, der im Jahre 2001 dafür plädierte, die Anforderungsermittlung und den Architekturentwurf verzahnt und parallel zu organisieren. Er hatte erkannt, dass eine sequenzielle Reihenfolge aus “Requirements first, Design second” bei innovativen Systemen nicht zweckmäßig ist.
Die Visualisierung der Twin Peaks
Visualisiert wird das Twin Peaks Model mit zwei gleichartigen Bergen (daher Twin Peaks genannt); der eine Berg repräsentiert die Anforderungen, der andere die Architektur. Beide sind gleich hoch und gleich wichtig. Sie beginnen mit groben Anforderungen und Architekturmodellen und verfeinern sie parallel zueinander im gegenseitigen Wechsel. So gelangen Sie vom schmalen Gipfel der Berge mit zunehmender Detaillierung zu neuen Anforderungen und Architekturelementen.
Anforderungen und Architektur im Twin Peaks Model
Parallele Entwicklung
Viele IT Organisationen stehen vor der Frage, wie sie bei der Entwicklung eines neuen Systems vorgehen sollen. Gilt es zuerst Anforderungen zu erfassen oder wäre es besser, zuerst die Softwarearchitektur zu entwerfen? Anforderungen können sich ändern, neue Technologien erscheinen und frühere Designentscheidungen in Frage stellen. Es empfiehlt sich daher zu Beginn, die wichtigsten Anforderungen an ein System rudimentär zu entwerfen. Entwickeln Sie mit diesen Anforderungen einen Prototypen oder ein Minimum Viable Product (MVP), holen Sie sich Feedback der Stakeholder ein und überarbeiten Sie Ihren Entwurf. Leiten Sie daraus neue Anforderungen ab und bewerten und priorisieren Sie vorhandene Anforderungen erneut. Und setzen Sie die priorisierten Anforderungen wieder in der Architektur um.
Die Kommunikation bei paralleler Entwicklung
Das Twin Peaks Model beschreibt ein dynamisches Zusammenspiel zwischen Anforderungen und Architektur. Für dieses Zusammenspiel ist eine gute Kommunikation zwischen den Projektbeteiligten essentiell. Idealerweise gibt es in dem Projektteam sowohl einen Anforderungsanalysten als auch einen Systemarchitekten. Beide arbeiten gleichzeitig und iterativ. So werden einerseits Probleme bei Architekturbeschränkungen besser verstanden und anderseits Architekturen auf Basis von Anforderungen besser entwickelt oder angepasst. Natürlich benötigt der Systemarchitekt einen hervorragenden Überblick über das System und seine Umgebung. Er beurteilt die Auswirkungen und Abhängigkeiten von Anforderungen auf die Architektur und kommuniziert Anforderungen, die sich aus verschiedenen Architekturalternativen ergeben.
Vorteile der parallelen Entwicklung
Anforderungen und die Architektur eines Systems sind stark voneinander abhängig. Das Twin Peaks Model verfolgt den Gedanken, parallel auf Anforderungen und Architektur zu achten. Dadurch ergeben sich verschiedene Vorteile:
- Die Detaillierung und Konkretisierung von Anforderungen erfolgt genauso schrittweise wie die Erforschung passender Architekturalternativen. Somit wächst die Architektur anhand der Anforderungen und Architekturentscheidungen können zu Konkretisierung und Neubewertungen von Anforderungen führen.
- Die Architektur steht im Fokus und lässt sich so gestalten, dass sowohl die gesetzten Ziele als auch funktionale und nicht-funktionalen Anforderungen erfüllt werden. Gleichzeitig wird ein Architecture-Indifferent Design mit einer Vernachlässigung der Architektur vermieden, bei der Entwickler vorhandene oder in der Domäne übliche Architekturen (Presumptive Architecture) verwenden.
- Projekt- und Produktrisiken lassen sich durch die Evaluation von Alternativen mittels Analysen, Simulationen, Prototyping oder Refactoring reduzieren.
- Die Nachvollziehbarkeit wird erhöht, denn Architekturentscheidungen lassen sich auf Anforderungen und vice versa zurückführen.
- Inkonsistenzen zwischen Anforderungen und Architektur werden vermieden.
- Ohne frühzeitige Architekturbewertung werden kritische Anforderungen leicht übersehen. Dies führt häufig zu Nacharbeiten, verspäteten Designänderungen und hohen Kosten. Mit dem Twin Peaks Modell lässt sich dies vermeiden.
Jetzt den Twin Peaks Model Guide kostenlos downloaden.
Alles Wichtige über das Twin Peaks Model auf einen Blick.
- Definition
- Parallele Entwicklung von Anforderungen und Architektur
- Visualisierung
- Vorteile und Herausforderungen
Wissen auf 6 Seiten zum Mitnehmen.
Herausforderungen für Unternehmen
Die Architektur im Blick behalten
Wenn Sie sich mit Software- und Systementwicklung beschäftigen, haben Sie vielleicht auch schon die Erfahrung gemacht, dass es im Laufe der Zeit zu einer Architekturverschlechterung kommt. Trotz agiler Methoden wie Scrum und Kanban passiert es immer wieder, dass sich der Fokus beim Zusammenspiel aus Anforderungen und Architektur verschiebt und die Systemarchitektur etwas in den Hintergrund tritt. Um dies zu vermeiden sollten IT-Organisationen über den Lebenszyklus eines Produkts hinweg folgende Fragen im Blick behalten:
- Welche Softwarearchitekturen sind bei sich ändernden Anforderungen stabil und wie wählen wir diese aus?
- Welche Anforderungen sind stabiler als andere und wie identifizieren wir sie?
- Welche Anforderungen sind volatil und wie identifizieren wir sie?
- Wie gelingt die zukunftssichere Skalierung von Systemen?
- Wie erreiche ich eine Modularisierung von Systemen?
Hinweise:
Haben Sie Lust auf einen neuen Lieblings-Newsletter?
Die Inhalte auf dieser Seite dürfen Sie gerne teilen oder verlinken.
Hier finden Sie ergänzende Informationen aus unserem t2informatik Blog:
Der beste Prozess im Anforderungsmanagement
Das Problem mit Problembeschreibungen
Der destruktive Weg zu Anforderungen