Vorlesung 3: Wie evaluiert man bestehende Software Architekturen? Flashcards
Bitte beschreibe die Software Architektur Bewertung
Der Zustand einer Software-Architektur muss von Zeit zu Zeit evaluiert werden
- Architekturen werden in Code implementiert
- Systeme werden laufend modifiziert
- Anforderungen (inkl. notwendiger Qualitätsanforderungen) ändern sich
▪ Allgemeine Fragen:
- Ist die entworfene Architektur noch angemessen?
- Funktioniert die Architektur wie geplant?
▪ Verschiedene Formen der Bewertung:
- Durch den Designer (Architekt) innerhalb des Entwurfsprozesses
- Durch Fachkollegen während des Entwurfsprozesses
- Durch Außenstehende, nachdem die Architektur entworfen wurde
Was in jeder Phase bewertet werden sollte, sollte von den folgenden Aspekten bestimmt werden:
Die Wichtigkeit der Entscheidung
Die Anzahl der möglichen Alternativen
Gut genug im Gegensatz zu perfekt („weniger schlechte Architektur“)
Allgemein: Verbringe nicht zu viel Zeit mit unwichtigen Dingen!
Besonders im initialen Design wird zu viel Zeit mit unwichtigen Aspekten verbracht
Dieses Phänomen wird als „Bikeshedding“ bezeichnet
Bitte erkläre Bikeshedding: Das Gesetz der Trivialität
Menschen in einer Organisation schenken trivialen Themen oft oder typischerweise unverhältnismäßig viel Aufmerksamkeit
„Die Zeit, die für einen Punkt auf der Agenda aufgewendet wird, steht in umgekehrtem Verhältnis zu der damit verbundenen Geldsumme.“
Je einfacher das Problem zu verstehen ist, desto detaillierter sind die Diskussionen
Begründung:
Richtig große Entscheidungen zu treffen erfordert intensive Informationssammlung
Lässt Raum (Zeit) für Fehler, bevor alle notwendigen Informationen vorliegen
Ambiguitäts-/Unsicherheitsaversion führt zu (unangemessenem?) Vertrauen in diejenigen, die das Problem hoffentlich vollständig verstehen
Umgekehrt: Menschen hören zu spät auf, sich mit einfachen / kleinen Entscheidungen zu befassen
Bitte beschreibe die Peer Review Bewertung von Softwarearchitektur.
Peer-Reviews werden oft während der Implementierung durchgeführt (z.B. Code-Reviews, Pair-Programming).
Software-Architekturen sollten immer von Kollegen überprüft werden – insbesondere von Nicht-Software-Architekten.
Idealerweise sollten Kollegen bereits am Architekturdesign teilnehmen:
Verhindert den Elfenbeinturm-Effekt
„Demokratisierung der Architektur“
Schritte zur Durchführung eines Architektur-Peer-Reviews:
Umfang der Überprüfung festlegen (verwenden Sie Qualitätsszenarien, falls verfügbar)
Teil der Architektur präsentieren, der bewertet werden soll
Gehen Sie die Architektur durch und erklären Sie, wie die Qualitätsanforderungen erfüllt werden
Potenzielle Probleme erfassen
Bitte beschreibe die Bewertung der Softwarearchitektur durch Personen von außen.
Gutachter können Außenseiter mit unterschiedlichen Perspektiven sein:
Außerhalb der organisatorischen Einheit (aber in derselben Firma)
Außerhalb der Organisation
Bewertungen durch Außenseiter können aus verschiedenen Perspektiven vorteilhaft sein:
Außenseiter haben unterschiedliches Wissen und unterschiedliche Erfahrungen
Es kann möglich sein, Außenseiterexperten für ein bestimmtes Fachgebiet zu finden
Es ist einfacher, Feedback von „unbeteiligten“ Personen zu akzeptieren
Bewertungen durch Außenseiter können im Wesentlichen dem Prozess von Peer-Bewertungen folgen
Bitte erkläre die Architektur-Tradeoff-Analyse-Methode (ATAM)
ATAM ist eine weit verbreitete Methode zur Bewertung von Architekturen.
Ein qualitativer Ansatz zur Architekturbewertung.
Es wird keine vorherige Kenntnis des Geschäfts / der Architektur erwartet; leicht anwendbar für Bewertungen von Außenstehenden.
Teilnehmer am ATAM:
-Bewertungsteam (extern zum Projekt)
-Entscheidungsträger des Projekts (müssen die Autorität haben, -Änderungen am Projekt vorzuschreiben – immer einschließlich „des Architekten“)
-Architekturbeteiligte
Phasen des ATAM:
-Vorbereitung
-Start (Präsentation des aktuellen Zustands)
-Bewertung
-Abschluss
Bitte nenne und beschreibe die
ATAM: Rollen im Bewertungsteam.
Was sind die Ausgaben (Outputs) des ATAM?
Eine prägnante Präsentation der Architektur
Eine Formulierung der Geschäftsziele
Priorisierte Qualitätsanforderungen (z.B. Qualitätsszenarien)
Eine Reihe von Risiken und Nicht-Risiken
Risiken: Entscheidungen, die bezüglich einer oder mehrerer Qualitätsanforderungen problematisch sind
Nicht-Risiken: Entscheidungen, die angemessen sind
Eine Liste von Risikothemen (aggregierte Ansicht der Risiken)
Zuordnung von architektonischen Entscheidungen zu Qualitätsanforderungen
Eine Liste identifizierter Sensitivitäts- und Trade-off-Punkte
Sensitivitätspunkt: Entscheidung, die eine Qualitätsanforderung beeinflusst
Trade-off-Punkt: Entscheidung, die mehrere Qualitätsanforderungen beeinflusst (oft in gegensätzliche Richtungen)
Eine Liste offener Entscheidungen / Probleme
Sieh dir den Konzept Flow des ATAM an.
Das ATAM hat 4 Phasen, bitte beschreibe die ersten beiden “Vorbereitung und Kickoff” (Preparation and Kickoff)
Vorbereitung:
Klärung organisatorischer Aspekte (Zeitpunkt, Ort, etc.)
Identifizierung relevanter Stakeholder
Erwartungsmanagement (“Was sollte im Kickoff präsentiert werden?”)
Kickoff:
Präsentation des ATAM (Erklärung des Prozesses)
Präsentation der Geschäftstreiber (Erläuterung dessen, was wichtig ist – Kontext, Einschränkungen, etc.)
Präsentation der Architektur (Erklärung der Architektur auf angemessenem Niveau; basierend auf architektonischen Ansichten)
Das ATAM hat 4 Phasen, bitte beschreibe die dritte, Bewertung (Assessment)
− Identification von Stilen, Mustern, Taktiken usw., die in der Architektur vorhanden sind
− Zuordnung von Stilen, Mustern, Taktiken usw. zu Qualitätsanforderungen
▪ Erstellen eines Qualitätsbaums
− Priorisierung und Strukturierung von Qualitätsanforderungen mit einem Qualitätsbaum
− Verfeinerung von Qualitätsanforderungen mit Szenarien
▪ Analyse der architektonischen Ansätze
− Im Hinblick auf den Qualitätsbaum (d. h. die Qualitätsszenarien)
− Typischerweise ein Rundgang mit Architekten / Entwicklern (Wie unterstützen / reflektieren Komponenten eines Systems die Qualitätszenarien?)
− Ergebnisse werden Risiken, Nicht-Risiken, Sensitivitätspunkte und Trade-offs sein
Das ATAM hat 4 Phasen, bitte beschreibe die vierte, Schließen (Closing)
▪ Präsentation der Ergebnisse (Zusammenfassung):
− Dokumentierte architektonische Ansätze
− Satz von Qualitätsszenarien
− Qualitätsbaum
− Risiken und Nicht-Risiken
− Sensitivitäts- und Trade-off-Punkte
− Risikothemen (und durch sie gefährdete Geschäftstreiber)
▪ Formulierung von Maßnahmen zur Risikominderung (Risikothemen)
Bitte beschreibe die Quantitativen Ansätze zur Architekturbewertung
▪ Quantitative Ansätze basieren auf KPIs, die für Systeme und Quellcode gemessen werden können.
▪ Es gibt viele Ansätze zur Messung von KPIs:
− Anzahl der geänderten Anforderungen pro Zeiteinheit
− Maße für Kopplung, Zeilen Code (LOC), Komplexität (insbesondere zyklomatische Komplexität)
− Anzahl der Änderungen pro Codeeinheit
− Testabdeckung, Anzahl der Testfälle, Dauer der Testausführungen
− Leistungsmerkmale
− MTTR (Mean Time To Repair), MTBF (Mean Time Between Failures)
▪ KPIs können dazu verwendet werden, “Hotspots” im System zu identifizieren, die Aufmerksamkeit erfordern.
▪ KPIs benötigen einen Kontext, um nützlich zu sein (“Wie viel Testabdeckung ist notwendig?”).
▪ Vorsicht: Die ausschließliche Betrachtung von KPIs kann auch strukturelle Probleme verbergen!
