Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

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

Ähnliche Präsentationen


Präsentation zum Thema: "Die Architecture-Tradeoff- Analysis-Method (ATAM) im Detail Kay Schützler."—  Präsentation transkript:

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

15

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, (Referenziert als [Clements02a]) Bass, L.; Clements, P.; Kazman, R.: Software Architecture in Practice, 2 nd ed., Addison- Wesley, 2003.


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

Ähnliche Präsentationen


Google-Anzeigen