die architecture-tradeoff- analysis-method (atam) im detail kay schützler
TRANSCRIPT
Die Architecture-Tradeoff-Analysis-Method (ATAM) im Detail
Kay Schützler
Gliederung
Einleitung Beteiligte Personen Ergebnisse der ATAM Phasen der ATAM Zusammenfassung
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
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.
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
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
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
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
Phasen der ATAM
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
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
Phasen der ATAM: Phase 3
Teaminterne Auswertung der Evaluation– Erfolge, Misserfolge– Bericht des Process Observers– Aufwandsprotokollierung
Überprüfung der Langzeiteffekte beim Klienten
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
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, ...
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),...)
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
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
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
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
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.