Die Architecture-Tradeoff-Analysis-Method (ATAM) im Detail

1. Die Architecture-Tradeoff-Analysis-Method (ATAM) im Detail Kay Schützler

2. Gliederung • Einleitung • Beteiligte Personen • Ergebnisse der ATAM • Phasen der ATAM • Zusammenfassung

3. Einleitung • ATAM: umfassende Methode zur Evaluation von Software-Architekturen • Verbindung von Geschäftszielen mit den dafür entscheidenden Architekturteilen • Abwägung von Kompromissen zwischen einzelnen Qualitätszielen

4. Beteiligte Personen • Das Evaluationsteam • Projektexterne 3- bis 5-köpfige Gruppe mit spezieller Rollenverteilung • Projekt-Entscheidungsträger • Projektvertreter mit Änderungsbefugnissen • Software-Architekt (!), Projektleiter, Kundenvertreter • Architektur-Interessenten • Inkl. Entwickler, Tester, Integratoren, Wartungsverantwortliche, Nutzer, Entwickler anderer abhängiger Systeme u.a.

5. Beteiligte Personen:Rollen im Evaluationsteam (1) • Team Leader • Organisation der Evaluation, Koordination mit dem Klienten, Vertragserstellung, ... • Evaluation Leader • Durchführung der Evaluation, Unterstützung bei Szenariofindung, –priorisierung und –bewertung • Scenario Scribe • Dokumentation der Szenarien während ihrer Ermittlung, Sicherung gemeinsamer Bezeichnungen • Proceedings Scribe • Elektronische Erfassung von Szenarien, ihrer Motivation und architekturellen Bedeutung, Erstellung von Szenario-Handouts

6. Beteiligte Personen:Rollen im Evaluationsteam (2) • Timekeeper • Sicherstellung der Zeiteinhaltung • Process Observer • Dokumentation möglicher Verbesserungen des Evaluationsprozesses, Erstellung eines Erfahrungsberichts nach der Evaluation • Process Enforcer • Diskret unterstützende Kontrolle des Evaluation Leaders, Sicherstellung korrekter Prozessabläufe • Questioner • Vermeidung von Betriebsblindheit

7. Ergebnisse der ATAM (1) • Eine übersichtliche Darstellung der Architektur • Präsentierbar in einer Stunde • Darlegung der Geschäftsziele • Oft erster Kontakt der Entwickler mit diesen Zielen • Qualitätsanforderungen als Sammlung von Szenarien • Geschäftsziele  Qualitätsanforderungen • Zuordnung von Architekturentscheidungen zu Qualitätsanforderungen

8. Ergebnisse der ATAM (2) • Eine Menge von erkannten „sensitivity“ und „tradeoff points“ • Architekturentscheidungen mit Effekten bezüglich eines (sensitivity point) oder mehrerer (tradeoff point) Qualitätsattribute • Eine Menge von Risiken und Nicht-Risiken • Risiko: Architekturentscheidung mit potenziellen unerwünschten Konsequenzen bezüglich der Qualitätsanforderungen • Eine Menge von Risiko-Themen • Thematische Zusammenfassung systematischer Risiken

9. Phasen der ATAM

10. Phasen der ATAM: Phase 0 • Gegenseitiges Kennenlernen • Einführung des Evaluationsteams in das Projekt • Einigung über logistische Aufgaben • Erledigung von Formalitäten • Erstinformation (und Unterstützung) des Projektleiters und des Software-Architekten bezüglich ihrer Aufgaben bei der Evaluation

11. Phasen der ATAM: Phasen 1 und 2 • Eigentliche Evaluationsphasen • Ein Treffen mit den Entscheidungsträgern • Erste Analysen • Ein weiteres Treffen nach etwas zeitlichem Abstand mit den Entscheidungsträgern und den Architektur-Interessenten • Weitergehende Analysen • Unterteilung in Schritte: • Phase 1: Schritte 1 – 6, Phase 2: Schritte 7 – 9

12. Phasen der ATAM: Phase 3 • Teaminterne Auswertung der Evaluation • Erfolge, Misserfolge • Bericht des Process Observers • Aufwandsprotokollierung • Überprüfung der Langzeiteffekte beim Klienten

13. Einzelne Schritte der Evaluationsphasen (1) • Schritt 1 – Präsentation der ATAM: • Erläuterung des Prozesses, Fragenklärung, ... • Schritt 2 – Präsentation der „Business drivers“ • Wichtigste Systemfunktionen • Alle relevanten technischen, konzeptionellen, ökonomischen und politischen Bedingungen • Haupt-Interessenshalter der Architektur • Hauptsächliche architekturbeeinflussende Qualitätsziele

14. Einzelne Schritte der Evaluationsphasen (2) • Schritt 3 – Präsentation der Architektur • Aufgabe des Software-Architekten • Briefing des Architekten sehr empfehlenswert • Unterstützender Template-Einsatz günstig • Schritt 4 – Identifikation von Architekturansätzen • Patterns, styles, strategies, ...

16. Einzelne Schritte der Evaluationsphasen (3) • Schritt 5 – Erstellung des „Quality Attribute Utility Tree“ • Ermittlung der entscheidenden Qualitätsattribute • Definition der Attribute über Szenarien • Priorisierung der Szenarien: • Allgemeine Wichtigkeit eines Szenarios (H/M/L) • Schwierigkeit eines Szenarios bezüglich seiner Umsetzbarkeit in der untersuchten Architektur (H/M/L) •  Szenarien mit Prioritätspaaren ((H,H), (H,M),(M,L),...)

17. Einzelne Schritte der Evaluationsphasen (4) • Schritt 6 – Analyse der Architektur-Ansätze • Diskussion der höchstpriorisierten Szenarien bezüglich ihrer Umsetzbarkeit mit der zu untersuchenden Architektur • Ermittlung von sensitivity und tradeoff points und Charakterisierung dieser als Risiken/Nicht-Risiken • Ruhephase

18. Einzelne Schritte der Evaluationsphasen (5) • Zweites Treffen in größerem Rahmen • Schritt 7 – Szenario-Brainstorming und – Priorisierung • Bewertung (und Ergänzung) des Utility Trees aus Sicht der Interessenshalter • Priorisierung mittels Abstimmung (Stimmenzahl pro Teilnehmer == 30% der Szenarienzahl) • Schritt 8 – Analyse der Architekturansätze • Analog zu Schritt 6

19. Einzelne Schritte der Evaluationsphasen (6) • Schritt 9 – Präsentation der Resultate • Dokumentierte Architekturansätze • Szenarienmenge und ihre Priorisierung aus dem Brainstorming • Utility Tree • Entdeckte Risiken • Festgehaltene Nicht-Risiken • Gefundene sensitivity und tradeoff points • Risiko-Themen

20. Zusammenfassung • Die ATAM • ist keine Evaluation der Anforderungen • ist keine Code-Evaluation • umfasst keinen tatsächlichen Systemtest • ist kein präzises Instrument, aber identifiziert potenzielle Risikobereiche in einer Architektur • ist eine robuste Methode • zwingt Entscheidungsträger und Interessenshalter zu präziser Darstellung der Qualitätsanforderungen • zeigt die bezüglich der Szenario-Umsetzung relevanten Architekturentscheidungen auf

21. Literatur • Clements, P.; Kazman, R.; Klein, M.: Evaluating Software Architectures: Methods and Case Studies, Addison-Wesley, 2002. (Referenziert als [Clements02a]) • Bass, L.; Clements, P.; Kazman, R.: Software Architecture in Practice, 2nd ed., Addison-Wesley, 2003.