Lesezeit: 3 Min.

Software Architektur überprüfen – Qualität garantiert in 8 Schritten

Software Architektur überprüfen? Wie kann die Qualität einer Software Architektur sichergestellt werden? In diesem Beitrag wird gezeigt, wie das mit der ATAM Methode erreicht werden kann.

Warum eine Software Architektur überprüfen? Das kann verschiedene Gründe haben: z.B. die Prüfung der Tragfähigkeit, der Skalierbarkeit, der Zukunftsfähigkeit oder die Untersuchung von Architekturproblemen oder auch der Vergleich von verschiedenen Entwürfen eines Systems.

Mit einer systematischen Prüfung einer Software Architektur werden idealerweise Risiken und Schwachstellen identifiziert und auf Problembereiche hingewiesen. Richtig eingeplant, kann eine solche Architekturbewertung das Projektrisiko einer Entwicklung enorm verringern.

Für die Einordnung einer Architekturbewertung in das gesamte Thema Software Architektur siehe hier: Software Architektur ist nicht komplex – Software Architektur einfach und klar.

Software Architektur überprüfen mit Methode

Eine geeignete und bekannte Methode zur systematischen Überprüfung einer Architektur ist die ATAM Methode. Diese vom Software Engineering Institute  (SEI) entwickelte Methode erlaubt die systematische Bewertung anhand von Qualitätsanforderungen sogenannten Quality Attributes (siehe dazu die folgenden Blogartikel Visuelle Erarbeitung von Software Qualities und Quality Attribute Workshop).

Die ATAM Methode

Das folgenden Flipchart welches ich als Präsentationsmittel am Anfang eines ATAM Reviews verwendet habe, gibt einen vereinfachten Überblick über die Methode:

Software Architektur überprüfen - mit der ATAM Methode

Nachfolgend eine kurze Erläuterung der einzelnen Schritte gemäss obigem Flipchart:

1. Present ATAM

Der ATAM Leader präsentiert die Methode allen Beteiligten.

Die ATAM Methode ist so aufgebaut, dass es zwei parallele Phasen gibt: Bei der einen Phase sind die Stakeholder des Systems involviert (im Flipchart gelb hinterlegte Schritte). Bei der anderen Phase sind alle Reviewteilnehmer sowie der Architekt oder das Architekturteam involviert (im Flipchart rot hinterlegte Schritte).

Die nachfolgenden Schritte werden nur mit dem Stakeholder Team durchgeführt.

2. Present Business Driver

Der Projektleiter oder eine andere geeignete Person präsentiert die Ziele (Business Driver), welche hinter dem zu entwicklenden System stehen. Das ist ein zentraler Schritt, damit alle Beteiligte den Fokus auf den Zweck und die Ziele des Systems nicht vergessen.

3. Identify Qualities

In diesem Schritt geht es darum die Qualitätsanforderungen der Stakeholder zu identifizieren. Das sind im Wesentlichen die nichtfunktionalen Anforderungen, welche für die verschiedenen Stakeholder essentiell sind.

4. Define Quality Attributes Scenarios

In diesem Schritt werden die aus Schritt 3 identifizierten Qualities weiter verfeinert und überprüfbar definiert:

Quality Attribute Scenario
Die 6 Aspekte eines Quality Attribute Scenarios

Weitere Infos dazu in den folgenden Blogartikeln: Visuelle Erarbeitung von Software Qualities und Quality Attribute Workshop).

Die nachfolgenden Schritte werden vom Architektur und Review Team durchgeführt.

5. Present Architecture

In diesem Schritt präsentiert der Architekt oder das Architekturteam die geplante oder schon gebaute Architektur des Systems. Die Teilnehmer dieser Präsentation notieren sich wichtige Designentscheidungen.

6. Identify & Analyse Architecture Decisions

Basierend auf der Präsentation in Schritt 5 sowie einem nachfolgenden Workshop werden möglichst komplett die expliziten und impliziten Architektuentscheidungen aufgelistet und basierend auf den Anforderungen welche das Projektteam berücksichtigt hat bewertet.

7. Analysis

In diesem Schritt werden die Bewertungen aus dem Schritt 6 noch mit den Qualitätsszenarien des Stakeholder Teams ergänzt und auch hier wie in Schritt 6 dessen die Erfüllung bewertet.

Die Bewertung wird systematisch mit folgenden Punkten angegeben:

  • Non-Risks: Gute Architekturentscheidung. Ein oder mehrere Qualities werden mit dieser Entscheidung erreicht.
  • Risks: Problematische Architekturentscheidung. Ein oder mehrere Qualities werden mit dieser Entscheidung nicht erreicht oder gar schlechter gemacht.
  • Sensitivity:  Relevante Architekturentscheidung. Ein oder mehrere Qualities werden mit dieser Entscheidung direkt positiv beeinflusst.
  • Tradeoff: Zu überprüfende Architekturentscheidung. Ein oder mehrere Qualities werden mit dieser Entscheidung positiv gleichzeitig werden aber andere Qualities negtiv beeinflusst.

Idealerweise werden die Resultate in diesem Schritt in einem Radardiagramm mit den Qualitätsattributen und den Resultaten visualisiert. Damit kann eine qualitative und quantitative Bewertung oder ein fundierter Vergleich verschiedener Architekturansätze gemacht werden:

Architektur Bewertung visualisiert

Basierend auf dieser systematischen Bewertung folgt der letzte Schritt:

8. Impact / Actions

Hier wird entschieden wie mit dem Resultat der Analyse umgegangen wird. Üblicherweise werden die Risiken genauer betrachtet und diese versucht zu eliminieren. Bei den Trade-Offs und Sensitivities ist sicher sinnvoll die entsprechenden Architekturentscheidungen nochmals zu überdenken. Nicht zu vergessen sind hier aber auch die Non-Risks. Diese „guten“ Entscheidungen weisen explizit, auf gut überlegte Architekturarbeit hin. Dies ist ein wichtiger Aspekt gereade dann, wenn die Analyse für das Projektteam negativ belastet und wie eine Prüfung aufgefasst wird.

2 Gedanken zu „Software Architektur überprüfen – Qualität garantiert in 8 Schritten“

Schreiben Sie einen Kommentar

Weiterlesen:

  • Podcast: Softwareentwicklung wie eine gut geölte Maschine

    Softwareprojekte leiden unter schlechter Architektur und die Ursache liegt oft in den Teams. Aber ist es möglich innerhalb von 2 Wochen alle Schwachstellen zu identifizieren? Damit die Softwareentwicklung wieder wie…

    Weiterlesen >

  • Komplexität reduzieren – geht das eigentlich?

    Das Thema Komplexität ist in aller Munde. Die Welt wird immer komplexer. Die Vielfalt der Möglichkeiten, die Vernetzung und damit die Unsicherheit steigt. Was kann man dagegen tun?

    Weiterlesen >

  • Zusammenarbeit mit einem Software-Partner? Ja, aber dann richtig! 4 Grundmodelle für ein konstruktives miteinander.

    Software-Systeme zu entwickeln ist eine zeit- und ressourcenintensive Angelegenheit. Die heutigen Systeme werden immer komplexer und umfangreicher. In vielen Fällen ist es nicht mehr möglich, ohne zusätzliche Unterstützung durch einen Software-Partner, solche Systeme zu entwickeln. Erfahre hier, wie Du eine effiziente und effektive Zusammenarbeit aufsetzen solltest.

    Weiterlesen >