Die Architecture-Tradeoff-Analysis-Method (ATAM) im DetailKay Schtzler

GliederungEinleitungBeteiligte PersonenErgebnisse der ATAMPhasen der ATAMZusammenfassung

EinleitungATAM: umfassende Methode zur Evaluation von Software-ArchitekturenVerbindung von Geschftszielen mit den dafr entscheidenden ArchitekturteilenAbwgung von Kompromissen zwischen einzelnen Qualittszielen

Beteiligte PersonenDas EvaluationsteamProjektexterne 3- bis 5-kpfige Gruppe mit spezieller RollenverteilungProjekt-EntscheidungstrgerProjektvertreter mit nderungsbefugnissenSoftware-Architekt (!), Projektleiter, KundenvertreterArchitektur-InteressentenInkl. Entwickler, Tester, Integratoren, Wartungsverantwortliche, Nutzer, Entwickler anderer abhngiger Systeme u.a.

Beteiligte Personen:Rollen im Evaluationsteam (1)Team LeaderOrganisation der Evaluation, Koordination mit dem Klienten, Vertragserstellung, ...Evaluation LeaderDurchfhrung der Evaluation, Untersttzung bei Szenariofindung, priorisierung und bewertungScenario ScribeDokumentation der Szenarien whrend ihrer Ermittlung, Sicherung gemeinsamer BezeichnungenProceedings ScribeElektronische Erfassung von Szenarien, ihrer Motivation und architekturellen Bedeutung, Erstellung von Szenario-Handouts

Beteiligte Personen:Rollen im Evaluationsteam (2)TimekeeperSicherstellung der ZeiteinhaltungProcess ObserverDokumentation mglicher Verbesserungen des Evaluationsprozesses, Erstellung eines Erfahrungsberichts nach der EvaluationProcess EnforcerDiskret untersttzende Kontrolle des Evaluation Leaders, Sicherstellung korrekter ProzessablufeQuestionerVermeidung von Betriebsblindheit

Ergebnisse der ATAM (1)Eine bersichtliche Darstellung der ArchitekturPrsentierbar in einer StundeDarlegung der GeschftszieleOft erster Kontakt der Entwickler mit diesen ZielenQualittsanforderungen als Sammlung von SzenarienGeschftsziele QualittsanforderungenZuordnung von Architekturentscheidungen zu Qualittsanforderungen

Ergebnisse der ATAM (2)Eine Menge von erkannten sensitivity und tradeoff pointsArchitekturentscheidungen mit Effekten bezglich eines (sensitivity point) oder mehrerer (tradeoff point) QualittsattributeEine Menge von Risiken und Nicht-RisikenRisiko: Architekturentscheidung mit potenziellen unerwnschten Konsequenzen bezglich der QualittsanforderungenEine Menge von Risiko-ThemenThematische Zusammenfassung systematischer Risiken

Phasen der ATAM

Phasen der ATAM: Phase 0Gegenseitiges KennenlernenEinfhrung des Evaluationsteams in das ProjektEinigung ber logistische AufgabenErledigung von FormalittenErstinformation (und Untersttzung) des Projektleiters und des Software-Architekten bezglich ihrer Aufgaben bei der Evaluation

Phasen der ATAM: Phasen 1 und 2Eigentliche EvaluationsphasenEin Treffen mit den EntscheidungstrgernErste AnalysenEin weiteres Treffen nach etwas zeitlichem Abstand mit den Entscheidungstrgern und den Architektur-InteressentenWeitergehende AnalysenUnterteilung in Schritte:Phase 1: Schritte 1 6, Phase 2: Schritte 7 9

Phasen der ATAM: Phase 3Teaminterne Auswertung der EvaluationErfolge, MisserfolgeBericht des Process ObserversAufwandsprotokollierungberprfung der Langzeiteffekte beim Klienten

Einzelne Schritte der Evaluationsphasen (1)Schritt 1 Prsentation der ATAM:Erluterung des Prozesses, Fragenklrung, ...Schritt 2 Prsentation der Business driversWichtigste SystemfunktionenAlle relevanten technischen, konzeptionellen, konomischen und politischen BedingungenHaupt-Interessenshalter der ArchitekturHauptschliche architekturbeeinflussende Qualittsziele

Einzelne Schritte der Evaluationsphasen (2)Schritt 3 Prsentation der ArchitekturAufgabe des Software-ArchitektenBriefing des Architekten sehr empfehlenswertUntersttzender Template-Einsatz gnstigSchritt 4 Identifikation von ArchitekturanstzenPatterns, styles, strategies, ...

Einzelne Schritte der Evaluationsphasen (3)Schritt 5 Erstellung des Quality Attribute Utility TreeErmittlung der entscheidenden QualittsattributeDefinition der Attribute ber SzenarienPriorisierung der Szenarien:Allgemeine Wichtigkeit eines Szenarios (H/M/L)Schwierigkeit eines Szenarios bezglich seiner Umsetzbarkeit in der untersuchten Architektur (H/M/L) Szenarien mit Priorittspaaren ((H,H), (H,M),(M,L),...)

Einzelne Schritte der Evaluationsphasen (4)Schritt 6 Analyse der Architektur-AnstzeDiskussion der hchstpriorisierten Szenarien bezglich ihrer Umsetzbarkeit mit der zu untersuchenden ArchitekturErmittlung von sensitivity und tradeoff points und Charakterisierung dieser als Risiken/Nicht-RisikenRuhephase

Einzelne Schritte der Evaluationsphasen (5)Zweites Treffen in grerem RahmenSchritt 7 Szenario-Brainstorming und PriorisierungBewertung (und Ergnzung) des Utility Trees aus Sicht der InteressenshalterPriorisierung mittels Abstimmung (Stimmenzahl pro Teilnehmer == 30% der Szenarienzahl)Schritt 8 Analyse der ArchitekturanstzeAnalog zu Schritt 6

Einzelne Schritte der Evaluationsphasen (6)Schritt 9 Prsentation der ResultateDokumentierte ArchitekturanstzeSzenarienmenge und ihre Priorisierung aus dem BrainstormingUtility TreeEntdeckte RisikenFestgehaltene Nicht-RisikenGefundene sensitivity und tradeoff pointsRisiko-Themen

ZusammenfassungDie ATAM ist keine Evaluation der Anforderungenist keine Code-Evaluationumfasst keinen tatschlichen Systemtestist kein przises Instrument, aber identifiziert potenzielle Risikobereiche in einer Architekturist eine robuste Methode zwingt Entscheidungstrger und Interessenshalter zu prziser Darstellung der Qualittsanforderungenzeigt die bezglich der Szenario-Umsetzung relevanten Architekturentscheidungen auf

LiteraturClements, 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.

Team Leader: stellt Team zusammen; achtet auf Fertigstellung des Evaluations-ReportsEvaluation Leader: sicher vor PublikumScenario Scribe: Gute Handschrift; fhig Diskussionskernpunkte zu erkennen