Twin Peaks Model. Entwicklung der Architektur und Anforderungen
eines Software-Systems.
Wofür benutzt man das Twin Peaks Model? Welche Vorteile bringt es und wie wenden Sie es in der Software-Entwicklung an?
Twin Peaks bedeutet übersetzt "Zwillingsberge". Ein Berg repräsentiert die Anforderungen und einer die Architektur. Im Twin Peaks Model arbeiten Sie sich von den Gipfeln der Berge zum Boden. Das bedeutet: Zuerst liegen Anforderungen und Architektur grob vor und Sie verfeinern beide immer weiter.
Die Verfeinerung geschieht parallel zueinander und im gegenseitigen Wechselspiel. Gibt es z.B. die ersten Anforderungen, entwerfen die Architekten einen Prototypen, holen Feedback der Stakeholder ein und überarbeiten den Entwurf. Auch die Anforderungen verfeinern sich dadurch.
Am Schluss gelangen Sie von allgemeinen und sehr groben zu detaillierten Anforderungen und Architekturelementen.
Was ist das Twin Peaks Model?
Das Twin Peaks Model befasst sich mit der Entwicklung der Anforderungen und der Architektur eines Software-Systems. Erfunden von Bashar Nuseibeh, einem IT-Professor an der Open University in der UK, soll es das „Hennen-Ei-Problem“ der Software-Entwicklung lösen:
Bevor Sie eine Architektur entwerfen, müssen die Anforderungen definiert sein. Anforderungen lassen sich jedoch auch erst ableiten, wenn die Architektur bekannt ist. In der Praxis ergab sich oftmals ein klassisches Wasserfallmodell: Erst spezifizierte man die Anforderungen, dann entwickelte man darauf basierend die Architektur. Diese Vorgehensweise führte jedoch zum Beispiel zu Anforderungen, die sich nicht durch die zu Verfügung stehenden technischen Mitteln umsetzen ließen; oder zu einer schlecht performanten Architektur, die nicht die Erwartungen der Stakeholder erfüllte.
Die Verfeinerung geschieht parallel zueinander und im gegenseitigen Wechselspiel. Gibt es z.B. die ersten Anforderungen, entwerfen die Architekten einen Prototypen, holen Feedback der Stakeholder ein und überarbeiten den Entwurf. Auch die Anforderungen verfeinern sich dadurch. So gelangen Sie von allgemeinen und sehr groben zu detaillierten Anforderungen und Architekturelementen.
Vorteile des Twin Peaks Model im Überblick
- Anforderungen berücksichtigen Systemgrenzen
- Schnelle Findung von Design-Alternativen
- Schnelle Erstellung von Prototypen
- Effiziente Entwicklung der Architektur durch Verwendung bereits existierender Lösungen
- Aufwand der Anforderungen durch erste Grobarchitektur abschätzbar
- Kostensenkung, weil “unrealistische” Anforderungen vor der entwickelten Lösung identifiziert werden
- Risikominderung in der Entwicklung
Definition des Twin Peak Model – kurz und knapp:
Das Twin Peaks Model wird in der Software-Entwicklung angewendet, um iterativ zu den Anforderungen und der Architektur zu gelangen. Beide “Berge” sind gleichwichtig.
Was bringt Ihnen das Twin Peaks Model?
Das Twin Peaks Model hilft Ihnen bei folgenden Problemstellungen:
I’ll Know It When I See It (IKIWISI – “Ich weiß es, wenn ich es sehe.”).
Oftmals lassen sich erst Anforderungen ermitteln, wenn Anwender das System testen konnten. Mit dem Twin Peaks Model beim Software-Engineering können Sie frühzeitig Prototypen entwickeln, mit denen Sie Feedback der Anwender einholen und dadurch iterativ zur gewünschten Lösung gelangen.
Reaktion auf Veränderung.
Projekte müssen mit Veränderung umgehen. Häufig ändern zum Beispiel Stakeholder ihre Meinung, wodurch sich auch die Anforderungen ändern. Wie im agilen Manifest niedergeschrieben, müssen Sie auf Veränderungen reagieren, anstatt am Plan festzuhalten. Mit dem Twin Peaks Model gelingt es Ihnen, trotz sich wandelnder Anforderungen eine stabile Architektur zu erarbeiten.
Lesen Sie hier, um mehr über das agile Manifest und das agile Projektmanagement zu erfahren »
Commercial off-the-shelf software (COTS – “Kommerzielle Produkte aus dem Regal“).
Softwarearchitekten stehen in der Regel bereits existierende Komponenten zur Verfügung, um ihre Architektur zu entwerfen. Durch den Einsatz geeigneter Lösungen können Sie die Kosten bei der Entwicklung senken. Das Twin Peaks Model hilft Ihnen dabei, solche “kommerziellen Produkte aus dem Regal” frühzeitig zu identifizieren und einzusetzen.
Wissen zum Mitnehmen
Lesen Sie, wie Sie mit objectiF RPM Anforderungen und Architektur parallel entwickeln.
Das Twin Peaks Model anwenden
Um das Twin Peaks Model erfolgreich anwenden zu können, müssen Sie also einen Software-Architekt in Ihr Projektteam integrieren – natürlich schon vor Start des Projekts. Was bedeutet das Twin Peaks Model für Software-Architekten und Requirements Engineer?
Aufgaben der Architektur
Der Architekt arbeitet mit bereits existierenden Lösungskomponenten und muss Randbedingungen sowie Schnittstellen wie zum Beispiel zu anderen Systemen berücksichtigen. Darüber hinaus behält er den gesamten Lebenszyklus des Systems im Blick. Daher arbeitet ein Software-Architekt mit unterschiedlichen Bereichen bzw. Rollen zusammen wie beispielsweise Requirements Engineers, Entwickler, Designer, Qualitätsmanager und Produktverantwortliche. Im Sinne des Twin Peaks Models hat ein Software-Architekt folgende Aufgaben:
- Prüfung der vorliegenden funktionalen und nicht-funktionalen Anforderungen (inkl. der Randbedingungen)
- Detailliertere Ausarbeitung der Architektur
- Qualitätssicherung der Architektur u.a. durch Reviews und Prototypen
- Prüfung und Begleitung der Umsetzung (Sicherstellung der Kommunikation zwischen allen Beteiligten)
Aufgaben des Requirements Engineering
Ein Requirements Engineer liefert funktionale und nicht-funktionale Anforderungen, die die Architektur erfüllen muss. Gleichzeitig beeinflusst die Architektur die definierten Anforderungen, indem sie ihnen z.B. technische Grenzen oder Zielkonflikte mit anderen Anforderungen aufzeigt. Im Kontext des Twin Peaks Models hat ein Requirements Engineer folgende Aufgaben zu bewältigen:
- Lieferung der ersten, rohen Anforderungen für die Software-Architekten
- Überarbeitung und Ermittlung neuer Anforderungen mit Hinblick auf die verfügbare Architektur/Randbedingungen
- Anpassung der Anforderungen an Änderungen/Neuerungen technischer Möglichkeiten
Diese Aufgaben führen die Rollen nach dem Twin Peaks Model iterativ und inkrementell durch – also fortlaufend in Kommunikation mit allen Beteiligten.
Lesen Sie hier, um mehr über Ziele und Zielkonflikte zu erfahren »
Und wie verknüpfen Sie diese beiden Aufgabenbereiche in der Praxis? Wenn sich z.B. eine Anforderung ändert, müssen Sie wissen, welchen Komponenten davon betroffen sind. Vor allem in großen Projekten mit über Tausend Anforderungen mit dazugehörigen Systemelementen lässt sich dann schnell den Überblick verlieren. Um daher Requirements Engineering und Architekturentwurf miteinander in der Praxis zu verbinden, ist eine Tool-Unterstützung notwendig. Mit einem Tool können Sie z.B. Diagramme modellieren und so einzelne Anforderungen mit Blockdiagrammen oder individuellen Komponenten über realize-, refine– oder satisfy-Beziehungen verknüpfen. Auf diese Weise stellen Sie die notwendige Traceability sicher.
So setzen Sie das Twin Peaks Modell in der Praxis um.
Mit objectiF RPM entwickeln Sie Architektur und Anforderungen parallel zueinander »
Entwickeln Sie Anforderungen und Architektur iterativ
Um zu einer Software-Lösung zu gelangen, die alle Stakeholder zufriedenstellt, dürfen Sie die Entwicklung der Anforderungen und Architektur nicht einfach streng voneinander trennen. Vielmehr müssen Sie – wie es das Twin Peaks Model vorschlägt – beide Tätigkeiten parallel und mit regelmäßiger Abstimmung aller Beteiligten durchführen. Aber wie lassen sich Anforderungen und Architekturmodelle effizient erstellen, parallel verfeinern und die Nachvollziehbarkeit wahren, wenn diese kontinuierlich Änderungen ausgesetzt sind? Wie stellen Sie die Qualität Ihrer Spezifikationen und Modelle sicher? Und wie können Sie die Kommunikation und den Austausch der Informationen zwischen allen Projektbeteiligten garantieren?
Diese Aufgaben erfordern Unterstützung durch ein Tool: Mit objectiF RPM können Sie zentral Ihre Anforderungen erfassen und Architekturmodelle erstellen. Dafür lassen sich zum Beispiel visuelle Darstellungsmittel wie Anforderungs-, Klassen- und Blockdiagramme einsetzen. Auf diese Weise können Sie u.a. Systemkomponenten mit zugehörigen Anforderungen einfach verbinden und die Traceability jederzeit sicherstellen. Das Tool unterstützt weiterhin Ihre Qualitätssicherung , indem Sie Ihre Anforderungen durch Reviews prüfen. Neugierig geworden?