Kolumne

Knigge für Softwarearchitekten: Die Qualitätsverbesserer

Gernot Starke

In dieser Folge der Kolumne „Knigge für Software-Architekten“ stellt JAX-Speaker Gernot Starke eine Alternative für aufwändige Architekturbewertungen vor: Mikrobewertungen versprechen eine preiswerte und pragmatische Art, die Qualität von Produkten nachhaltig zu verbessern.

JAX LogoEvent-Tipp: Bis zum Donnerstag, 23. Februar profitieren Sie noch von der Early-Bird-Aktion der JAX 2017. Neben vergünstigten Tickets können Sie auch den Agile Day kostenlos besuchen. Infos unter www.jax.de.

Die Qualitätsverbesserer

Systematische Architekturbewertung, etwa gemäß der bekannten Methode ATAM [1] gehört zu den Aufgaben verantwortungsbewusster Softwarearchitekten und -architektinnen. Leider sind ATAM und Co. relativ formal und aufwendig, sodass wir Ihnen eine pragmatische Alternative für den Alltagseinsatz aufzeigen möchten, die wir Mikrobewertung nennen.

Durch Architekturbewertung sollten Sie die Eignung der Architektur für die Erreichung der wesentlichen Qualitätsziele prüfen. Obwohl der Begriff Bewertung stark nach Schulnoten klingt, ist in der Praxis damit oft die qualitative Bewertung gemeint – also die Einschätzung von Qualitätsrisiken. In der Praxis hat sich dazu die Methode ATAM (Architecture Tradeoff Analysis Method) durchgesetzt, entwickelt vom renommierten Software Engineering Institute (SEI) der Carnegie Mellon University.

Diese Kolumne ist viel zu kurz, um Ihnen ATAM ausführlich erklären zu können. Die Erfinder der Methode benötigen in [1] dazu immerhin fast einhundert Buchseiten. Daher bekommen Sie eine Super-Mini-Kurzversion: Qualitative Bewertung besteht im Groben aus zwei Phasen:

  1. Konkretisieren Sie die Qualitätsanforderungen (Soll-Zustand) an das System mithilfe so genannter Szenarien. Das sind kurze Aussagen, wie sich das System in bestimmten Umständen verhalten soll – also beispielsweise, welche konkrete Performance, Robustheit oder Änderbarkeit notwendig sind. 1 zeigt einige Beispiele.
  2. hruschka_starke_qualitaetsverbesserer_1

    Abb. 1: Exemplarische Qualitätsszenarien

     

  3. Vergleichen Sie diese Anforderungen Stück für Stück mit dem Ist-Zustand, der (bereits implementierten oder avisierten) Architektur des Systems (2). Dabei stoßen Sie für jede der konkreten Qualitätsanforderungen entweder auf:
    • Risiken oder Probleme, falls sich die gerade überprüfte Anforderung mit der gegebenen Architektur nicht erfüllen lässt
    • Kompromisse, die für das gerade überprüfte Qualitätsmerkmal in der Architektur eingegangen wurden, dass etwa Performance auf Kosten höherer Codekomplexität erkauft wurde, oder
    • Erfüllte oder erfüllbare Qualitätsanforderungen, falls die Architektur das jeweilige Qualitätsmerkmal unterstützt

 

hruschka_starke_qualitaetsverbesserer_2

Abb. 2: Qualitative Bewertung als Soll-Ist-Vergleich [2].

Der Bewertungsprozess im Detail läuft in vier Phasen mit minutiös definierten Einzelschritten ab, wie schematisch in Abbildung 3 dargestellt.

hruschka_starke_qualitaetsverbesserer_3

Abb. 3: Schritte bei ATAM (nach [2]).

Puh – das klingt (berechtigt) alles abstrakt und fürchterlich aufwendig. Unserer Erfahrung nach scheuen viele (agile) Entwicklungsprojekte diesen Aufwand und verzichten daher auf entwicklungsbegleitende Architekturbewertung. Das führt zielsicher zu Qualitätsmängeln – denn die wesentlichen Qualitätsanforderungen erfüllen sich ja nicht von allein. Kein System wird rein zufällig „robust genug“ oder „sicher“.

Treffen Sie Gernot Starke auf der JAX 2017

Alle Programm-Infos unter www.jax.de

Konstruktiv statt analytisch

ATAM wurde entwickelt, um nachträglich oder auch während der Entwicklung zu prüfen, ob bestimmte Qualitätsanforderungen an Systeme besser oder schlechter erreicht wurden. Grundsätzlich schätzen wir diese szenarienbasierte Methode sehr, möchten aber Qualität konstruktiv erreichen – und nicht nur im Nachhinein Risiken suchen. Daher schlagen wir vor, konkrete Qualitätsanforderungen zum Ausgangspunkt von Architektur- und Implementierungsentscheidungen zu machen.

Lesen Sie auch: Das Fünfsekundenexperiment: Guter Code, schlechter Code?

Qualität systematisch erreichen

Quality-driven Software Architecture (QDSA) [3] greift die grundsätzliche Idee des (analytischen) ATAM auf und wandelt sie in ein konstruktives Vorgehen um. Die Qualitätsziele werden in Form von Szenarien frühzeitig definiert und konkretisiert, im Idealfall als Bestandteil der normalen Anforderungen. Während der Entwicklung bilden sie dann kontinuierlich die Basis der wesentlichen Architektur- und Entwurfsentscheidungen.

In Projekten erleben wir immer wieder, dass explizite und konkrete Qualitätsanforderungen schlichtweg fehlen. In Teams basieren daher wesentliche Architektur- und Entwurfsentscheidungen auf impliziten Annahmen und Hörensagen, statt auf verifizierten Fakten – eine ungesunde Situation. QDSA basiert in hohem Maße auf der Arbeit von [4], und ist dort sowie in dem Blogpost [3] nur sehr informell beschrieben.

Best of both worlds

Wir schlagen vor, einen pragmatischen Extrakt aus ATAM und QDSA in den Entwicklungsalltag zu integrieren, um die geforderten Qualitätseigenschaften von Systemen zielsicher zu erreichen: Sie benötigen zwei kleine, sehr pragmatische Schritte, die praktisch keinerlei zusätzlichen Aufwand erzeugen:

  1. Diskutieren Sie mit Ihren Stakeholdern sowie dem Entwicklungsteam die wesentlichen Themen in punkto Qualität, die das System erreichen muss, beispielsweise Performance, Robustheit, Flexibilität, Sicherheit oder Korrektheit. Dazu formulieren Sie jeweils einige Szenarien, die diese Qualitätsanforderungen konkretisieren. [5] enthält eine Vielzahl von Beispielen dafür – einen ersten Eindruck gibt Abbildung 1. Im Idealfall haben das Ihre Requirements Engineers oder Product Owner bereits erledigt.
  2. Nun wählen Sie mit dem Team eines dieser Qualitätsthemen aus, das für eine Zeitlang im Fokus stehen soll (etwa zwei bis drei Scrum Sprints, ein Quartal o. ä.). In diesem Zeitraum konzentriert sich das Team neben den regulären Features auf die zugehörigen Q-Anforderungen genau dieses Themas. Dieser Fokus hat den Vorteil, dass Ihr Team nicht mehr alle (möglicherweise Dutzende bis Hunderte) einzelnen Qualitätsszenarien im Blick behalten muss.

Eine Viertelstunde Mikrobewertung

Legen Sie beispielsweise mit Ihrem Team fest, die ersten sechs Wochen des Jahres primär auf Robustheit zu achten (Abb. 4). Treffen Sie sich in dieser Zeit mit dem Team, beispielsweise am ersten Februar, zu einer Viertelstunde Mikrobewertung: Gehen Sie gemeinsam einige der zugehörigen Qualitätsszenarien durch und überlegen Sie, wo im System noch Risiken oder Unwägbarkeiten hinsichtlich dieser Szenarien liegen könnten. Suchen Sie primär nach Risiken und Problemen – die Lösungen folgen später. Wir haben solche thematisch strikt fokussierten Diskussionen in Teams von vier bis acht Personen erfolgreich innerhalb von nur zehn bis fünfzehn Minuten geführt – mehr Zeit sollten Sie nicht investieren. Eine ähnliche Diskussion führen Sie einige Zeit später beispielsweise zum Thema Performance: Welche Stellen/Komponenten im System oder der Hardware sind riskant bezüglich der Performance? Wo könnte das System Zeit oder Ressourcen vergeuden? Bei welchen Komponenten haben wir verlässliche Zahlen, und bei welchen sind wir aufs Raten angewiesen? Teammitglieder haben an manchen Stellen vielleicht nur ein ungutes Gefühl – aber das ist für eine Mikrobewertung gut genug.

Abhilfen suchen

Als Ergebnis jeder kurzen Mikrobewertung erhalten Sie eine informelle Liste mit Risiken oder Problemen, basierend auf konkreten Qualitätsanforderungen oder -szenarien. Das ist eine gute Basis, um daraufhin Lösungsoptionen für genau diese Qualitätsrisiken zu entwickeln: Auch hier bietet sich ein Workshop mit dem Team an – je nach Teamgröße auch in leicht reduzierter Runde. Legen Sie solche Solution-Workshops unmittelbar hinter Ihre Mikrobewertungen – dann sind alle Beteiligten noch im Thema, und die Lösungsvorschläge kommen fast von allein. Sie werden überrascht sein, wie viele gute Ideen zur Lösung von Qualitätsrisiken in kurzer Zeit auf den Tisch kommen. Für solche Solution-Workshops geben Sie dem Team ebenfalls eine Timebox, diesmal aber ruhig 30 bis 60 Minuten. Es geht ja lediglich darum, Lösungsmöglichkeiten („Optionen“) zu sammeln. Falls das Team bezüglich einzelner Risiken oder Probleme sehr unsicher ist, könnte eine sinnvolle Maßnahme darin bestehen, dieses Risiko zuerst einmal genauer zu untersuchen, um Vermutung in Gewissheit zu verwandeln. Danach können Sie, unterstützt von Product Owner oder ähnlichen Rollen, diese Vorschläge ganz normal in die reguläre Arbeitsplanung des Teams aufnehmen (Backlog o. ä.).

hruschka_starke_qualitaetsverbesserer_4

Abb. 4: Beispiel eines Qualitätskalenders (Kalendervorlage nach [6]).

Unserer Erfahrung nach sind Entwicklungsteams sehr qualitätsbewusst und wollen gute Systeme liefern: Es schmerzt ein Team, wenn es faule Kompromisse eingehen muss, nur um einen Termin zu halten. Daher nehmen Teams den Fokus auf Qualität positiv auf, zumal die kurzen Mikrobewertungen sowie zugehörigen Solution-Workshops als willkommene Abwechslung im Arbeitsalltag gelten: Wir pausieren kurz – und reflektieren alle gemeinsam zu einem (wichtigen) Thema.

Lesen Sie auch: Im Selbsttest zu mehr Architektur: Entwickler an die Macht

Timeboxed und fokussiert

Mikrobewertungen sind leichtgewichtig. Als Grundvoraussetzung benötigen Sie lediglich konkrete Aussagen über Qualitätsanforderungen (Qualitätsszenarien). Wir setzen bewusst auf sehr kurze Time-Boxen statt langer Diskussionen. Dieses Vorgehen bewährt sich in der Praxis: In kurzer Zeit das Wichtigste identifizieren, statt ewig zu diskutieren. Mikrobewertungen konzentrieren sich jeweils auf ein einziges Qualitätsmerkmal mit zugehörigen Szenarien. Alle Beteiligten sprechen über die gleiche Sache, jeweils aus ihrer Perspektive. Damit lernen alle etwas über die Teile von anderen.

Fazit

Mikrobewertungen sind eine preiswerte und pragmatische Art, die Qualität Ihrer Produkte regelmäßig und nachhaltig zu verbessern. Nebenbei auch noch eine prima Quelle zur Steigerung der Motivation im Entwicklungsteam, das durch solche Mikrobewertungen die Message erhält: „Qualität ist unserer Organisation etwas wert“. Sie können morgen mit Ihrer ersten Mikrobewertung anfangen. Die Skills im Entwicklungsteam sind meist gut genug, um qualitative Schwachstellen im Produkt rasch und ohne Overhead zu identifizieren. Sie schaffen damit im Team ein deutliches Bewusstsein für Qualität („Quality Awareness“). In diesem Sinne wünschen wir Ihnen viel Erfolg auf Ihrem Weg zu besseren Systemen.

 

Geschrieben von
Gernot Starke
Gernot Starke
    Informatikstudium an der RWTH Aachen, Dissertation über Software-Engineering an der J. Kepler Universität Linz. Langjährige Tätigkeit bei mehreren Software- und Beratungsunternehmen als Softwareentwickler, -architekt und technischer Projektleiter. 1996 Mitgründer und technischer Direktor des „Object Reality Center“, einer Kooperation mit Sun Microsystems. Dort Entwickler und technischer Leiter des ersten offizielle Java-Projekts von Sun in Deutschland. Seit 2011 Fellow der innoQ GmbH.  
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.