Bewertung und Evolution Flashcards
Welche Aspekte einer Architektur können bewertet werden?
- Prozesse: Entwicklungsprozesse, Betriebsprozesse
- Artefakte: Anforderungen, Architekturen, Quellcode, Dokumente
Davon können jeweils Qualität und Quantität bewertet werden
Welche Arten der Architekturbewertung gibt es?
- szenariobasierte Bewertung (qualitativ)
- erfahrungsbasierte Bewertung (qualitativ)
- metrikbasierte Bewertung (quantitativ)
Wie ist das Vorgehen bei der erfahrungsbasierten Architekturbewertung?
- ein oder mehrere Reviewer bewerten die Architektur auf Basis ihrer Erfahrungen, Kenntnissen und Fähigkeiten
- wird in der Regel für Systemteile oder Reviewziele verwendet, die nicht geschäftskritisch sind
- Während des Reviews werden potenzielle Probleme festgehalten
- Im Anschluss wird bewertet, ob es sich um tatsächliche Probleme handelt und ob diese zu lösen sind
Wie ist das Vorgehen bei der quantitativen Architekturbewertung?
- meist nur für die wichtigsten Qualitätsanforderungen eingesetzt, weil sehr aufwendig
- Jedes Qualitätsmerkmal braucht eine passende Metrik
Was ist das Architecture Quality Assessment (AQA)?
- quantitatives Bewertungsverfahren
- definiert eigene Qualitätsmerkmale
- besitzt 200 Maße
- bezieht sich größtenteils auf das ISO-Kriterium Wartbarkeit
- hoher Durchführungsaufwand weil alle Maße erhoben werden müssen
Was ist das Software Architecture Evaluation Model?
- quantitatives Bewertungsverfahren
- kann nur nach der Implementierung angewandt werden
- basiert auf Metriken der Softwaretechnik
- betrachtet interne und externe Qualitätsmerkmale laut ISO-Standard
- betrachtet zusätzlich Modularität, Komplexität, Kopplung und Kohäsion
- Erhebung & Bewertung erfolgt durch Experten
Was ist die allgemeine Herangehensweise im szenariobasierten Bewertungsansatz?
- Im ersten Schritt Vorstellung des Systems und der Sollarchitektur für alle Reviewer
- Eine Gruppe von Stakeholdern formuliert Qualitätsszenarios
- Reviewer bewerten in einem Walkthrough die Flexibilität der Architektur hinsichtlich der Szenarios
- Das Verfahren erfolgt üblicherweise in einem Bewertungsworkshop
Was ist die Architecture-Level Modifiability Analysis (ALMA)?
- basiert wie ATAM auf SAAM
- kann vor der Implementierung der Sollarchitektur durchgeführt werden
- bewertet die Modifizierbarkeit in Hinblick auf Wartungskosten, Architekturrisiken und alternative Architekturen
- Bewertung kann als Ordinalskala oder in beschreibender Form erfolgen
Welche 5 Schritte der ALMA gibt es?
- Zielsetzung: Auswahl des Analyseziels
- Beschreibung der Architektur
- Szenarioerhebung
- Evaluation
- Interpretation der Ergebnisse
Was ist die Architecture Trade-off Analysis Method (ATAM)?
- szenariobasierte Bewertung einer Architektur in Hinblick auf erfüllte Qualitätsziele
- kann vor der Implementierung angewandt werden
- Benötigt Architekten, Stakeholder und Dokumentation
- Qualitätsziele werden erarbeitet, über die die Bewertung der Architektur erfolgt
Was sind die Schritte bei der ATAM?
- Vorbereitung: Qualitätsmerkmale identifizieren, ATAM vorstellen
- Kick Off: Geschäftsziele & Architektur vorstellen
- Bewertung: Qualitätsbaum erstellen, Qualitätsmerkmale durch Szenarien ergänzen, Architektur dahingehend analysieren
- Abschluss: Entwickler mit einbeziehen, Resultate präsentieren
Welche Metriken gibt es für die quantitative Bewertung?
Für Anforderungen:
- Geänderte Anforderungen pro Zeiteinheit
Für Code:
- Abhängigkeitsmaße
- Codezeilen
- Kommentare im Verhältnis zu Code
- Statische Methoden
- Vererbungstiefe
Für Tests:
- Testfälle pro Klasse/Paket/Anforderung
Für Systeme:
- Performance
Für Fehler:
- Mittlere Zeit bis zur Fehlerbehebung
- Gefundene Fehler pro Baustein
Für Prozesse:
- Getestete Features pro Zeiteinheit
- Neuer Code pro ZE
- Meetings pro Arbeitszeit
- Verhältnis Manager-Entwickler-Tester
Was sind die Gründe für die Degeneration eines Systems?
- Akkumulierte unbehandelte Komplexität
- keine konzeptionelle Integrität
- inadäquate Technologien
- Fehlende Ressourcen
- veraltete Designentscheidungen
- Hohe Kopplung, niedrigere Kohäsion
Wie kann Degeneration verhindert werden?
- Refactoring und Redesign iterativ anwenden
- Abstraktionen verwenden und Komponenten entkoppeln
- Technische Schulden vermeiden
- Adäquate Ressourcen beschaffen
Was sind die Ursachen für technische Schulden?
- Ausnahmen werden zu Regeln
- Code ist schwer verständlich
- Äußere Einflüsse zwingen zu kurzfristigen Kompromissen (quick and dirty)
