SAAM
SAAM ist ein Akronym für englisch „software architecture analysis method“. Das Verfahren wurde von Rick Kazman, Gregory Abowd, Len Bass und Paul Clements entwickelt.[1]
Kurzbeschreibung
SAAM ist das erste publizierte und eines der einfacheren Verfahren zur szenariobasierten Architekturbewertung. SAAM eignet sich zur Untersuchung von Softwarearchitekturen im Hinblick auf qualitative Anforderungen wie Verfügbarkeit (Availability), Modifizierbarkeit (Modifiability), Performance, Sicherheit (Security), Testbarkeit (Testability) und Benutzbarkeit (Usability) aber auch zur Evaluation des Funktionsumfangs (funktionale Anforderungen einer Software(architektur)). Grundsätzlich werden bei einer SAAM-Bewertung Szenarien erhoben, priorisiert und den von ihnen betroffenen Teilen der zu untersuchenden Softwarearchitektur zugeordnet. Bereits dies kann auf Probleme in der Architektur hindeuten:
- Problematisch sind eventuell Komponenten, auf die viele Szenarien zugeordnet wurden
- Problematisch sind eventuell Architekturentscheidungen, die dazu führen, dass ein Szenario auf viele Komponenten zugeordnet wurde
Für die Änderungen, die an der Architektur für die jeweiligen Szenarien durchgeführt werden müssen, wird der Änderungsaufwand oder eine damit verbundene Größe geschätzt.
Der Prozess der Zuordnung von Szenarien auf Komponenten kann dabei auch zu einer Verbesserung der Architekturdokumentation führen. Die Bewertung beginnt mit einer schon vorhandenen Architekturdokumentation. Ist für eine sinnvolle Zuordnung diese nicht ausreichend detailliert, werden entsprechende Teile der Architektur genauer dokumentiert.
Ein weiterer Vorteil einer SAAM-Bewertung besteht darin, dass sie die Kommunikation zwischen den Projektbeteiligten verbessert: Der Bewertungsprozess bringt die Projektbeteiligten in Meetings zusammen und ermöglicht ihnen, ihre Wünsche, Vorschläge und Kritikpunkte für die zukünftige Entwicklung des Systems miteinander zu diskutieren. Dabei dient die Architekturbeschreibung als eine gemeinsame Sprache für die Projektbeteiligten. Schon deshalb muss sie in einer für die Projektbeteiligten verständlichen Form beschrieben werden.
Ziel
Ziel der Softwarearchitekturbewertung ist es, eine Softwarearchitektur auf ein bestimmtes Qualitätsmerkmal (oder mehrere Qualitätsmerkmale gleichzeitig) hin zu untersuchen. Mögliche Untersuchungsziele sind dabei:
- Vergleich von zwei alternativen Softwarearchitekturen bezüglich des Qualitätsmerkmals / der Qualitätsmerkmale
- Untersuchung inwieweit eine Softwarearchitektur bestimmte Qualitätsmerkmale erfüllt
- Untersuchung von Risiken, die eine Softwarearchitektur bezüglich bestimmter Qualitätsmerkmale mit sich bringt
- Untersuchung inwieweit die vorgegebene Softwarearchitektur im Code auch eingehalten wurde
Verfahren
Zur Bewertung von Softwarearchitekturen existieren mehrere Ansätze:
Ablauf einer SAAM-Bewertung
Beschreibung der Architektur (Schritt 1)
Die Architekturbeschreibung sollte folgende Elemente der Architektur in einer für die Evaluationsteilnehmer verständlichen Notation enthalten:
- Komponenten und Datenelemente
- Verbindungen zwischen diesen
- Beschreibung des Systemverhaltens (umgangssprachlich oder formal)
Die Architekturbeschreibung kann die Projektbeteiligten zur Formulierung von Szenarien anregen.
Szenarien erheben (Schritt 2)
Die Szenarien dienen zur Beschreibung der Tätigkeiten, die das System momentan unterstützen muss oder eventuell in Zukunft unterstützen soll. Deshalb sollten sie die Aufgaben verschiedener Projektbeteiligter (z. B. Benutzer, Auftraggeber, Marketing, Administrator, Entwickler, Wartungspersonal etc.) möglichst umfassend berücksichtigen. Die Szenarien werden in einem Meeting von Repräsentanten der verschiedenen Stakeholder in einem Brainstorming-ähnlichen Prozess erhoben. Wird für ein Szenario eine genauere Architekturbeschreibung benötigt, muss zu Schritt 1 zurückgekehrt werden, um eine detaillierte Architekturbeschreibung anzufertigen. Anschließend wird anhand der detaillierten Dokumentation Schritt 2 erneut durchgeführt.
Klassifikation und Priorisierung der Szenarien (Schritt 3)
Szenarien werden in zwei Kategorien eingeteilt:
- Direkte Szenarien, d. h. Szenarien, die mit der vorhandenen Architektur ohne Änderungen ausgeführt werden können
- Indirekte Szenarien (Changecases oder Growthcases), d. h. Szenarien, zu deren Ausführung Änderungen an der Architektur vorgenommen werden müssen.
Die Priorisierung der Szenarien dient einer effizienten Architekturbewertung: nur die wichtigsten Szenarien (z. B. die wichtigsten 30 % der Szenarien) werden genauer untersucht. Die Priorisierung erfolgt durch Abstimmung unter den Projektbeteiligten. SAAM schlägt hier eine offene Abstimmung vor.
Einzelne Bewertung der Szenarien (Schritt 4)
Die im vorherigen Schritt zur Bewertung ausgewählten Szenarien werden den betroffenen Elementen der Architektur zugeordnet: Für ein direktes Szenario bedeutet diese eine Beschreibung der Ausführung des Szenarien durch das System. Für ein indirektes Szenario bedeutet dies eine Beschreibung der zur Ausführung des Szenarien nötigen Änderungen an der Architektur. Dabei werden die nötigen Änderungen identifiziert und der Änderungsaufwand geschätzt.
Untersuchung von Szenariointeraktionen (Schritt 5)
Szenariointeraktion bedeutet, dass zwei oder mehr Szenarien Änderungen an derselben Komponente der Architektur erfordern. Eine hohe Szenariointeraktion kann auf zwei verschiedene Probleme hinweisen: Eine Komponente realisiert mehrere nicht zusammengehörige Funktionsbereiche. Die Architektur einer Komponente ist nicht ausreichend genau dokumentiert. In diesem Fall sollte Schritt 1 von SAAM (Architekturbeschreibung) noch einmal ausgeführt werden.
Erstellung der Gesamtbewertung (Schritt 6)
Zur Erstellung der Gesamtbewertung werden die bewerteten Szenarien gewichtet. Diese Gewichte dienen zur Relativierung der Änderungsaufwände für die einzelnen Szenarien.
Auch als "Saam´sche" Unharmonische bekannt.
Einzelnachweise
- https://www.sei.cmu.edu/library/abstracts/whitepapers/scenariobasedanalysisnov1996.cfm%7Ctitle= https://www.sei.cmu.edu/library/abstracts/whitepapers/scenariobasedanalysisnov1996.cfm |author= Rick Kazman, Gregory Abowd, Len Bass, Paul Clements|accessdate=2006-10-22