Qualitätsanforderungen an Software-Architekturen erfüllt?

„Was machen Sie eigentlich mit den Ergebnissen des Requirements Engineering, wenn Ihre neue Anwendung fertiggestellt und in Betrieb genommen ist?” Die Antworten, die man auf diese Frage von Projektmanagern und Product Owners erhält, reichen von „sorgfältig archivieren“ bis „weg damit“. Mit beiden Extremen – im Archiv verwahren bzw. wegwerfen – wird eine große Chance vertan: nämlich die Qualität der Software-Architektur über den gesamten Software Lebenszyklus hinweg aktiv zu erhalten.

Und das lohnt sich. Denn Anwendungssoftware „lebt“ häufig sehr viel länger als erwartet. Unser erstes Tool case/4/0 ist das beste Beispiel dafür: Es ist seit unglaublichen 30 Jahren bei Kunden im Einsatz! Im Falle langlebiger Anwendungen besteht die Maintenance-Phase nicht nur darin, erkannte Fehler zu beseitigen. Maintenance heißt auch, eine Anwendung immer wieder an neue Technologien anzupassen und funktionale Erweiterungen zu realisieren. Aber was geschieht beim Anpassen und Erweitern der Software mit ihren Qualitätseigenschaften wie etwa Sicherheit und Effizienz? Leiden zum Beispiel die Datenintegrität, das Zeitverhalten oder der Ressourcenverbrauch?

Nachfolgend stelle ich Ihnen eine Methode zur qualitativen Bewertung von Software-Architekturen vor. Sie ermöglicht es, die Qualität – genauer, die Einhaltung von Qualitätsanforderungen an die Architektur – mithilfe von Szenarios zu bewerten und im Verlauf des Software-Lebenszyklus wiederholt zu überprüfen. Dabei setzt die Methode immer wieder auf Ergebnissen des Requirements Engineering auf und nutzt diese konsequent. Die Ergebnisse verschwinden also weder im Archiv noch werden sie gelöscht, sie bleiben quicklebendig. Die Instrumente, die Sie für diese Methode brauchen, finden Sie alle in objectiF RM, unserer Software für das Requirements Engineering.

Szenariobasierte Architekturbewertungsverfahren gibt es schon seit geraumer Zeit. Die hier beschriebene Methode lehnt sich in wesentlichen Zügen an die Architecture Tradeoff Analysis Method (ATAM) an, die das Software Engineering Institute (SEI) der Carnegie Mellon University entwickelt hat. Mehr dazu finden Sie zum Beispiel im Buch Software Architecture in Practice. [1]

Das Vorgehen zur szenariobasierten Architekturbewertung

Die Abbildung unten zeigt die wichtigsten Schritte: Am Anfang stehen strukturierte Meetings mit den Stakeholdern, in denen es darum geht, die Ziele der Stakeholder zu ermitteln und zu gewichten. Daraus werden dann konkrete funktionale Anforderungen an die zu entwickelnde Software abgeleitet. Neben den funktionalen Anforderungen werden die Qualitätsmerkmale ermittelt, die die Software erfüllen muss. Sie werden in Form von Qualitätsanforderungen festgehalten. Hier zwei Beispiele: Typische Qualitätsanforderungen in Bezug auf Datenintegrität und Zeitverhalten könnten lauten: „Der Anwender schließt beim Editieren versehentlich die Anwendung. Alle eingegebenen Daten müssen beim Fortsetzen der Arbeit wieder zur Verfügung stehen.“ und „Unter normalen Bedingungen ist mit 100 gleichzeitigen Benutzern zu rechnen. Die Software muss auf 90 % ihrer Anfragen nach maximal einer Sekunde reagieren“. Nach dem Ermitteln der Qualitätsanforderungen sind die Software-Architekten an der Reihe. Sie müssen Architekturansätze finden, mit denen die Stakeholder-Ziele, die funktionalen Anforderungen und auch die Qualitätsanforderungen erfüllt werden können. Fragt sich nur: Wie kann man nachweisen, dass die Architektur später die gewünschten Qualitätsmerkmale tatsächlich besitzen wird? Um diese Frage zu beantworten, werden im nächsten Schritt – am besten wieder unter Einbeziehung von Stakeholdern – Testszenarios entwickelt und dokumentiert. Anhand der Testszenarios werden dann die Architekturansätze bewertet, Risiken aufgedeckt und Möglichkeiten für Kompromisse (Tradeoffs) zwischen der Architektur, Qualitätsanforderungen und Risiken gesucht. Später bei der Realisierung können die Testszenarios dann als Testfälle zu Test Sets zusammengefasst und ausgeführt werden – und das wiederholt im Lebenszyklus der Software. So können die Qualitätsmerkmale auch nach Änderungen oder Erweiterungen der Architektur erneut überprüft werden.

Die Schritte mit objectiF RM

objectiF RM enthält alles, was zur praktischen Umsetzung der Methode notwendig ist:

• Zieldiagramme, um mit den Stakeholdern möglichst anschaulich zu kommunizieren,
• Anforderungsdiagramme, um funktionale Anforderungen, Qualitätsanforderungen und Testszenarios mit ihren Beziehungen untereinander nachvollziehbar abzubilden, Testszenarios werden dabei als Testfälle festgehalten,
• Vereinfachte Blockdiagramme der UML/SysML für die Modellierung der Architekturansätze bzw. der Architektur,
• TestSetExecutions für die Definition, Planung und Durchführung von Tests, die jeweils mehrere Testfälle umfassen,
• Jede Menge Echtzeitauswertungen, die die Ergebnisse des Vorgehens transparent machen.

Wie werden diese Instrumente in objectiF RM für die Schritte zur szenariobasierten Architekturbewertung eingesetzt? Diese Frage beantwortet die nachfolgende kurze Animation:

Video: Szenariobasierte Architekturbewertung mit objectiF RM

Quelle

[1] Len Bass, Paul Clements, Rick Kazmann et al.: Software Architecture in Practice, Addison Wesley, 3. Edition 2012