Analyse von Software-Architekturen

(1) Ziele der Architektur-Analyse

Die Analyse verfolgt vier Hauptziele: Sie identifiziert Probleme, bewertet die Qualität, unterstützt Entscheidungsprozesse und hilft bei der Planung von Verbesserungen. Eine frühzeitige Analyse sorgt dafür, dass Schwachstellen erkannt werden, bevor sie in der Implementierung teure Folgen haben.

(1.1) Identifizierung von Architekturproblemen

Ein zentrales Ziel ist das Aufdecken konkreter Missstände, die die Qualität, Leistung oder Sicherheit gefährden. Zu den häufigsten Problemen gehören:

• Inkonsistente Designentscheidungen: Unterschiedliche Lösungswege in verschiedenen Systemteilen erschweren die Wartung.
• Performance-Probleme: Die Architektur ist nicht für die erwartete Last oder den Durchsatz ausgelegt.
• Sicherheitslücken: Architektonische Fehler machen das System anfällig für Angriffe.
• Mangelnde Skalierbarkeit: Das System kann bei wachsenden Datenmengen oder Nutzerzahlen nicht mitwachsen.
• Technische Schulden: Kompromisse und „schnelle Lösungen“ führen zu ineffizientem Code, der später teuer „zurückgezahlt“ werden muss.

(1.2) Bewertung der Architekturqualität

Eine hochwertige Architektur ist die Basis für effizienten und sicheren Code. Die Bewertung ist ein iterativer Prozess, der technisches Wissen erfordert und sich an folgenden Aspekten orientiert:

• Struktur und Design: Ist das System kohärent und gut organisiert, sodass Entwickler effizient arbeiten können?
• Performance: Arbeitet die Software auch unter Last schnell und effizient?
• Sicherheit: Sind Schutzmechanismen gegen Datenverlust und Angriffe von Anfang an integriert?
• Skalierbarkeit: Kann die Architektur mit neuen Anforderungen wachsen, ohne komplett überarbeitet werden zu müssen?
• Wartbarkeit: Ist das System so gestaltet, dass es leicht verstanden, geändert und erweitert werden kann?

(1.3) Unterstützung von Entscheidungsprozessen

Die Architekturanalyse liefert die notwendigen Fakten, um fundierte Entscheidungen über Design, Implementierung und Wartung zu treffen. Ähnlich wie man beim Hausbau Entscheidungen über Zimmeranzahl oder Materialien basierend auf Budget und Anforderungen trifft, müssen in der Softwareentwicklung Entscheidungen über Struktur und Design getroffen werden. Diese Entscheidungen beeinflussen direkt die Leistung, Sicherheit und Wartbarkeit. Eine Analyse hilft vorherzusagen, ob ein bestimmtes Design später zu Problemen führt (z. B. Sicherheitslücken). Durch das Verständnis der Architektur können Risiken minimiert werden, da Entwickler und Stakeholder nicht auf Vermutungen angewiesen sind, sondern auf Basis von Analysedaten entscheiden können.

(1.4) Planung von Architekturverbesserungen

Die Behebung von identifizierten Schwachstellen ist ein Balanceakt zwischen Kosten, Zeit und Nutzen.

Nach der Identifikation von Problemen wird ein Plan erstellt. Maßnahmen können von einfachem Refactoring (Code-Bereinigung) bis hin zum Überdenken der gesamten Architektur reichen. Wie ein Haus regelmäßige Instandhaltung benötigt, muss auch Software kontinuierlich angepasst werden. Es geht nicht um einmalige Perfektion, sondern um stetige Verbesserung. Die untere Grafik verdeutlicht: Sinkt die Wartbarkeit (Verständlichkeit) der Software über die Zeit, steigen die Kosten für Änderungen drastisch an. Je länger man mit Verbesserungen wartet, desto teurer wird jede zukünftige Änderung.

(2.) Umfang und Vorgehen bei der Analyse

Die Analyse von Software-Architekturen erfordert eine Kombination aus technischem Wissen und strategischem Denken. Der Prozess gliedert sich in vier wesentliche Schritte: Definition des Analyseumfangs, Auswahl der Methoden, Durchführung der Analyse und Interpretation der Ergebnisse. Ziel ist es nicht nur, den Ist-Zustand zu verstehen, sondern auch zukünftige Anforderungen vorherzusagen und Verbesserungen zu planen.

(2.1.) Definition des Analyseumfangs

Der erste Schritt besteht darin, die Untersuchung auf die relevanten Bereiche zu beschränken, anstatt das gesamte System pauschal zu prüfen.

Ähnlich wie ein Detektiv nur relevante Spuren verfolgt, konzentriert sich die Analyse auf spezifische, kritische Teile der Architektur. Bei Performance-Problemen liegt der Fokus beispielsweise auf Datenbankzugriffen oder Netzwerkkommunikation; bei neuen Features hingegen auf den davon betroffenen Modulen. Der Umfang wird durch die verfügbaren Ressourcen, die Projektziele und die spezifischen Herausforderungen bestimmt, um effizientes Arbeiten zu gewährleisten.

(2.2) Auswahl der Analysemethoden

Nach der Eingrenzung des Umfangs erfolgt die Wahl der passenden Werkzeuge und Techniken. Die Wahl der Methode hängt analog zur Medizin (Stethoskop vs. Bluttest) von den "Symptomen" und dem Untersuchungsziel ab. Methoden können sich auf unterschiedliche Aspekte wie Struktur, Performance, Sicherheit oder Benutzerfreundlichkeit spezialisieren. Es wird grundsätzlich unterschieden zwischen quantitativen Methoden (basierend auf Messungen und Zahlen) und qualitativen Methoden (basierend auf Beobachtungen und Urteilen).

(2.3) Durchführung der Analyse

Die Durchführung bedeutet die konkrete Anwendung der ausgewählten Methoden auf die definierten Bereiche der Architektur. Dies umfasst praktische Tätigkeiten wie das Lesen und Verstehen von Code, das Durchführen von Messungen und Tests oder das Erstellen von Modellen und Diagrammen. Beobachtungen und Erkenntnisse müssen während dieses Schritts sorgfältig dokumentiert werden. Dies sichert nicht nur den Überblick für den Analysten, sondern macht die Arbeit auch für Dritte nachvollziehbar. Trotz der Herausforderung durch komplexe Systeme führen eine klare Strategie und strukturierte Anwendung der Methoden zu wertvollen Einblicken.

(2.4) Interpretation der Analyseergebnisse Nach der Durchführung liegt eine Fülle von Daten vor, die nun analysiert werden müssen, um Schlussfolgerungen für die Softwareverbesserung zu ziehen.

Ähnlich wie medizinische Testergebnisse (Blutwerte, Röntgenbilder) allein noch keine Diagnose darstellen, müssen Analysedaten interpretiert werden, um den „Gesundheitszustand“ der Software zu verstehen. Es gilt, konkrete Aussagen aus den Daten abzuleiten, etwa warum bestimmte Teile langsamer laufen oder wo Fehlerhäufungen auf tieferliegende Probleme hindeuten. Die Interpretation erfordert sowohl die Betrachtung des großen Ganzen (Zusammenspiel der Teile) als auch der Details. Analysten müssen offen für verschiedene Hypothesen sein, da Ursachen oft nicht offensichtlich sind; Daten müssen kritisch hinterfragt werden, um zu einem vollständigen Verständnis zu gelangen

(3.1) Architektur

Der Begriff „Architektur“ beschreibt den Plan, der die Struktur der Software und das Zusammenwirken ihrer Teile festlegt, vergleichbar mit dem Bauplan eines Hauses. Sie definiert die Aufteilung in Komponenten oder Module, deren Interaktionen, den Datenfluss und die Aufgabenverteilung. Eine gut gestaltete Architektur ist entscheidend für Leistung, Zuverlässigkeit und Wartbarkeit, da sie den Code verständlicher und effizienter macht, während schlechte Designs zu Performance-Problemen und Sicherheitslücken führen.

(3.2) Abstraktionsebenen

Abstraktionsebenen dienen als Werkzeug zur Bewältigung von Komplexität, indem sie den Detailgrad der Betrachtung steuern, ähnlich wie die Zoomstufen einer Landkarte. Auf der höchsten Ebene wird das Gesamtsystem betrachtet, beim „Hineinzoomen“ folgen Module und schließlich einzelne Codezeilen. Dies ermöglicht es, auf hoher Ebene zu planen, ohne sich in Details zu verlieren, oder bei Bedarf tief in spezifische Probleme einzutauchen.

(3.3) Komplexität

Komplexität bezieht sich auf die Anzahl der Systemteile und deren Beziehungen zueinander. Wie bei einem Puzzle steigt der Schwierigkeitsgrad mit der Anzahl der Teile und der Kompliziertheit ihrer Verbindungen. Hohe Komplexität erschwert das Verständnis, die Fehlersuche und Änderungen am Code. Es ist oft unmöglich, Komplexität vollständig zu eliminieren; das Ziel ist vielmehr, sie zu verstehen und kontrollierbar zu machen.

(3.4) Technische Schulden

Dieser Begriff beschreibt die langfristigen Kosten von Kompromissen und Abkürzungen („schnelle Lösungen“) in der Entwicklung. Wie bei einem Finanzkredit erhält man sofort einen Vorteil (schnelle Fertigstellung), muss diesen aber später mit „Zinsen“ zurückzahlen. Die „Zinsen“ manifestieren sich in Form von zusätzlicher Arbeit, schwererer Wartbarkeit und Problemen, die sich über die Zeit anhäufen. Technische Schulden müssen nicht zwingend vermieden, aber erkannt und gemanagt werden, um das System langfristig nicht unhaltbar zu machen.

(4.) Qualitätsmodelle, -metriken und -anforderungen

Um Softwarequalität greifbar zu machen, werden drei Werkzeuge genutzt: Qualitätsmodelle bieten einen organisatorischen Rahmen, Metriken liefern konkrete Messwerte und Anforderungen setzen spezifische Ziele.

(4.1.) ISO 25010

Die ISO 25010 ist der internationale Standard für Softwarequalität. Sie definiert acht Hauptmerkmale, die weiter in Untermerkmale unterteilt werden, um Qualität systematisch zu bewerten. Diese Hauptmerkmale sind:

• Funktionale Eignung: Erfüllt das System die Bedürfnisse?
• Zuverlässigkeit: Funktioniert es unter festgelegten Bedingungen stabil?
• Sicherheit: Werden Daten und Informationen geschützt?
• Wartbarkeit: Kann das System einfach modifiziert und verbessert werden?
• Übertragbarkeit (Portability): Läuft es in verschiedenen Umgebungen?
• Benutzbarkeit: Können Benutzer ihre Ziele erreichen?
• Kompatibilität: Kann es mit anderen Systemen Daten austauschen?
• Leistungseffizienz: Ist die Geschwindigkeit im Verhältnis zu den Ressourcen angemessen?

(4.2.) Qualitätsbäume

Qualitätsbäume visualisieren Qualitätsziele hierarchisch, ähnlich einem Baumstamm, der sich in Äste und Blätter verzweigt. An der Wurzel steht das allgemeine Ziel (z. B. Benutzerfreundlichkeit), das in spezifischere Unterziele (z. B. einfache Navigation) zerlegt wird. Sie helfen dabei, Prioritäten zu setzen und Anstrengungen auf die relevantesten Aspekte zu fokussieren.

(4.3) Weitere relevante Modelle und Metriken

Neben der ISO-Norm gibt es spezifische Metriken zur Bewertung des Codes. Wichtig ist, dass keine Metrik isoliert betrachtet werden sollte, sondern immer in Kombination.

• Cyclomatic Complexity: Zählt die unabhängigen Pfade durch den Code, um Risikobereiche zu identifizieren.
• Maintainability Index: Kombiniert verschiedene Metriken (Komplexität, Codezeilen, Kommentare), um die Wartbarkeit einzuschätzen.
• Cohesion & Coupling: Misst die Abhängigkeit zwischen Teilen (Coupling) und den inneren Zusammenhalt (Cohesion).
• Code Churn: Misst die Häufigkeit von Codeänderungen als Indikator für Instabilität.
• Code Duplication: Identifiziert doppelten Code, der Wartungsprobleme verursachen kann.

(4.4) Anforderungen an gute Architekturen

Eine gute Architektur muss konkrete Anforderungen erfüllen, um langfristig erfolgreich zu sein:

• Verständlichkeit: Entwickler und Stakeholder müssen das System verstehen können.
• Anpassungsfähigkeit: Änderungen und neue Funktionen müssen ohne Störung des Gesamtsystems möglich sein.
• Zuverlässigkeit & Sicherheit: Das System muss Fehler abfangen und gegen Bedrohungen geschützt sein.
• Leistung: Geschwindigkeit und Reaktionszeit müssen den Anforderungen entsprechen.
• Wartbarkeit & Integration: Fehlerbehebung muss einfach sein, und Schnittstellen zu anderen Systemen müssen vorhanden sein.

(5.) Analysearten

Wir haben verschiedene Werkzeuge, um die Softwarearchitektur in der Praxis zu analysieren. Wir können zwischen Messbarem (Zahlen, Daten) und Beurteilbarem (Szenarien, Expertenmeinung) unterscheiden.

• Die Quantitative Analyse ist das „Blutbild“: Sie liefert objektive Werte (z. B. „Zyklomatische Komplexität von 15“), sagt aber nicht zwingend, warum der Patient krank ist.
• Die Qualitative Analyse ist das „Arztgespräch“: Sie untersucht Zusammenhänge und User-Experience, ist aber subjektiver.

Keine Methode reicht allein aus; erst die Kombination liefert ein verlässliches Bild.

(5.1) Quantitative Analysearten

Diese Analysen basieren auf messbaren Daten, um eine objektive Bewertung zu ermöglichen. Sie sind ideal, um Probleme zu identifizieren und Trends über die Zeit zu verfolgen, benötigen aber immer Kontext zur Interpretation.

Diese Metriken können in fünf Kategorien unterteilt werden:

(5.1.1) Konkrete Code-Metriken messen die physischen Eigenschaften des Codes.

• Lines of Code (LOC): Gibt einen groben Überblick über die Größe.
• Cyclomatic Complexity (McCabe): Zählt die linearen unabhängigen Pfade; identifiziert schwer testbare Bereiche.
• Code Duplication: Zeigt Redundanzen und schlechte Praktiken auf.
• Function Points: Misst die Funktionalität aus Nutzersicht. Sie berücksichtigt die Anzahl und Komplexität der Funktionen, die das Programm bietet.

(5.1.2) Komplexitätsmetriken fokussieren auf die Vernetzung.

• Kopplung (Coupling): Wie stark hängen Teile voneinander ab? (Hohe Kopplung = schlecht für Wartung).
• Kohäsion: Wie gut arbeiten Funktionen innerhalb eines Moduls zusammen? (Hohe Kohäsion = gut).

(5.1.3) Leistungsmetriken messen die Effizienz.

Dazu gehören Durchsatz (Transaktionen pro Zeit), Reaktionszeit (Latenz) und Ressourcenauslastung. Sie messen jedoch nur Quantifizierbares, nicht die gefühlte Nutzererfahrung.

(5.1.4) Fehlermetriken dienen dem Qualitätsmanagement.

Beispiele von Fehlermetriken sind:

• Fehler pro KLOC (Tausend Zeilen Code): Diese Metrik misst die Anzahl der Fehler pro tausend Zeilen Code. Sie kann dazu verwendet werden, die Qualität des Codes oder die Effektivität der Qualitätssicherungsprozesse zu bewerten.
• Fehler pro Funktionseinheit: Diese Metrik misst die Anzahl der Fehler pro Funktionseinheit, wie z. B. eine Methode oder eine Klasse. Sie kann dazu verwendet werden, die Qualität des Designs oder die Komplexität der Funktionseinheiten zu bewerten.
• Fehler pro Personentag: Diese Metrik misst die Anzahl der Fehler pro Personentag. Sie kann dazu verwendet werden, die Produktivität der Entwickler oder die Effektivität der Ausbildung und Unterstützung zu bewerten.

(5.1.5) Wartungsmetriken bewerten die Langlebigkeit.

• Code Churn: Wie oft wird eine Datei geändert? (Hoher Churn = Instabilität)
• Technische Schulden: Misst den Aufwand, der nötig ist, um schlechten Code zu korrigieren

(5.2.) Qualitative Analysearten

Im Gegensatz zu quantitativen Methoden, die auf messbaren Daten basieren, konzentrieren sich qualitative Analysen auf das Verständnis der Eigenschaften und Beziehungen innerhalb der Architektur. Sie sind subjektiver und erfordern mehr Interpretation, liefern dafür aber Einblicke, die über reine Zahlen hinausgehen. Es geht darum, Zusammenhänge zu erkennen und zu bewerten, wie gut das System seine Aufgaben im realen Kontext erfüllt .

(5.2.1) Szenariobasierte Analyse

Diese Methode nutzt konkrete Anwendungsfälle (Szenarien), um die Architektur „auf die Probe zu stellen“. Man spielt spezifische Situationen durch (real oder hypothetisch), z. B. „Ein Kunde legt ein Produkt in den Warenkorb und schließt den Kauf ab“. Bewertung, wie gut das System diese Abläufe bewältigt und wo Probleme auftreten.

• Vorteile: Vertieftes Verständnis für die Funktionalität in der Praxis und Fokus auf die Benutzererfahrung (UX). Deckt Probleme auf, die Metriken übersehen
• Nachteile: Kann sehr zeitaufwendig sein und deckt systembedingt immer nur Ausschnitte ab (die gewählten Szenarien)

(5.2.2) Checklistenbasierte Analyse

Hier wird das System anhand einer vordefinierten Liste von Kriterien geprüft. Nutzen von Checklisten für verschiedene Bereiche wie Code-Reviews (Einhaltung von Standards), Sicherheit (bekannte Lücken) oder Performance.

• Vorteile: Bietet eine strukturierte und systematische Methode, stellt sicher, dass Standards eingehalten werden, und ist flexibel anpassbar an Projektziele
• Nachteile: Die Qualität hängt stark von der Erfahrung des Analysten ab (Subjektivität). Zudem können Aspekte übersehen werden, die nicht auf der Liste stehen, und die Prüfung kann bei umfangreichen Listen zeitintensiv sein

(6.) Analysetechniken

Es gibt mehrere etablierte Methoden zur Architekturanalyse, darunter ATAM, CBAM, SACAM und PBAR. Jede Technik hat einen spezifischen Fokus. Während manche auf Qualitätsattribute oder Risiken abzielen, konzentrieren sich andere auf Kosten-Nutzen-Rechnungen. Ziel der Architekturanalyse ist es, die passende Methode für die spezifischen Bewertungsziele auszuwählen

(6.1.) ATAM (Architecture Tradeoff Analysis Method)

ATAM wurde vom Software Engineering Institute (SEI) entwickelt und zielt darauf ab, die Auswirkungen von Designentscheidungen auf die Qualitätsziele zu bewerten.

Das Kernziel ist das Identifizieren von Trade-offs (Kompromissen/Handelsbeziehungen). Beispiel: Wie beeinflusst eine hohe Verschlüsselung (Sicherheit) die Antwortzeit (Performance)? .

Die Methode läuft in vier Phasen ab:

• Vorbereitung: Identifikation der Stakeholder.
• Kickoff-Phase: Vorstellung der Methode und der Geschäftsziele.
• Bewertungsphase: Erstellung von Qualitätsbäumen und Szenarien; Analyse der Architektur anhand dieser Szenarien.
• Abschluss: Präsentation der Ergebnisse.

Qualitätsbäume sind ein wichtiges Werkzeug und werden erstellt, um abstrakte Ziele (z. B. „Sicherheit“) in konkrete Szenarien (z. B. „Admin ändert Passwort in < 1 Sekunde“) zu übersetzen.

Vor- und Nachteile:

• Vorteile: Risiken werden früh erkannt; Kompromisse zwischen konkurrierenden Zielen werden sichtbar.
• Nachteile: Das Verfahren ist zeitaufwendig und erfordert hohes Expertenwissen, was die Anwendung in kleineren Projekten erschweren kann.

(6.2.) CBAM (Cost Benefit Analys Method)

Die Cost Benefit Analysis Method dient dazu, architektonische Entscheidungen rational auf der Basis von Kosten und Nutzen zu treffen.

Zunächst werden architektonische Strategien identifiziert, die die Systemqualität verbessern könnten. Für jede Option werden die Kosten (direkte Implementierungskosten + indirekte Auswirkungen) und der Nutzen (Verbesserung von Performance, Sicherheit etc.) bewertet. Die Entscheidung erfolgt meist auf Basis des Return on Investment (ROI), um die wirtschaftlichste Vorgehensweise zu ermitteln.

Vor- und Nachteile:

• Vorteile: Die Methode ist systematisch und objektiv, da sie auf quantitativen Daten basiert. Sie fördert die Kommunikation zwischen Stakeholdern, da sie eine gemeinsame (wirtschaftliche) Sprache für technische Entscheidungen bietet.
• Nachteile: Die Durchführung ist oft zeitaufwendig und komplex. Es ist in der Praxis oft schwer, genaue und zuverlässige Daten über Kosten und Nutzen im Vorfeld zu ermitteln. Nicht alle Aspekte (z. B. „weiche“ Faktoren) lassen sich leicht in Zahlen messen.

Anwendungsbeispiel: Ein Vergleich zweier Architekturen, bei der „Architektur A“ billig in der Erstellung, aber teuer in der Wartung ist, während „Architektur B“ teurer in der Erstellung, aber günstiger im Betrieb ist. CBAM hilft hier, die langfristig günstigere Option über die gesamte Lebensdauer zu berechnen.

(6.3.) SACAM (Software Architecture Complexity Analysis Method)

Die Software Architecture Comparison Analysis Method ist ein Verfahren, um rational zwischen verschiedenen Softwarearchitektur-Kandidaten zu entscheiden. Sie ist besonders hilfreich, wenn geprüft werden soll, ob eine bestehende Architektur für neue Produktlinien taugt, oder wenn man sich zwischen Konkurrenzvorschlägen von Subunternehmern entscheiden muss.

Die Methode verläuft in fünf Schritten:

1. Vorbereitung: Identifikation der Geschäftsziele und Sichtung der Dokumentation.
2. Kriterien: Ableitung konkreter Vergleichskriterien aus den Geschäftszielen.
3. Extraktion: Analyse der Kandidaten, um Belege (Ansichten, Muster) für die Erfüllung der Kriterien zu finden.
4. Bewertung: Beurteilung, wie gut jeder Kandidat die Kriterien erfüllt.
5. Zusammenfassung: Empfehlung für die Entscheidungsträger

Der Vorteil dieser Methode ist ihre Objektivität. Durch einen strukturierten Analyserahmen ersetzt sie reine Intuition ("Bauchgefühl") bei der Entscheidung. Darüber hinaus bietet SACAM einen qualitativen Vergleich, der über reine Kostenaspekte hinausgeht und ist streng zielorientiert, da Architekturen direkt gegen die geschäftlichen Anforderungen gemessen werden.

(6.4.) PBAR (Performance-Based Architecture Review)

Die Performance-Based Architecture Review konzentriert sich ausschließlich auf die Analyse und Bewertung der Leistungsfähigkeit einer Softwarearchitektur. Im Gegensatz zu strukturorientierten Methoden liegt der Schwerpunkt hier auf der Leistung in der Praxis. Untersucht werden konkrete Merkmale wie Antwortzeiten, Durchsatz, Skalierbarkeit und Zuverlässigkeit. Die Architektur wird analysiert, um zu verstehen, welche Komponenten (z. B. Datenbankabfragen) die Antwortzeiten beeinflussen. Die Ergebnisse dienen dazu, Flaschenhälse zu identifizieren und zukünftige Designänderungen zu steuern.

Vor- und Nachteile:

• Vorteile: Ermöglicht eine direkte Bewertung der Leistung und ist sehr praxisnah auf reale Systeme anwendbar
• Nachteile: Die Methode ist komplex, da sie tiefes Wissen über Leistungsmetriken erfordert, und die Durchführung von Messungen ist zeitaufwendig

Methode	Vollständiger Name	Fokus & Ziel	Kernfrage	Vorteile	Nachteile
ATAM	Architecture Tradeoff Analysis Method	Qualitäts-Kompromisse: Bewertung von Designentscheidungen im Hinblick auf Qualitätsziele und deren Wechselwirkungen	"Wie beeinflusst Designentscheidung X die Qualität Y (z. B. Sicherheit vs. Performance)?"	Identifiziert Risiken frühzeitig macht Handelsbeziehungen (Trade-offs) transparent	Zeitaufwendig erfordert tiefes Expertenwissen über Architektur und Qualitätsattribute
CBAM	Cost Benefit Analysis Method	Wirtschaftlichkeit: Bewertung von Architekturoptionen basierend auf Kosten und Nutzen (ROI)	"Lohnt sich die Investition in diese Architekturänderung finanziell?"	Objektive Entscheidungsfindung durch quantitative Daten fördert Kommunikation mit Stakeholdern	Zeitaufwendig genaue Daten zu Kosten/Nutzen sind im Vorfeld schwer zu ermitteln
SACAM	Software Architecture Comparison Analysis Method	Auswahl & Vergleich: Rationaler Vergleich der Eignung verschiedener Architektur-Kandidaten für ein System	"Welcher der vorgeschlagenen Architektur-Kandidaten erfüllt unsere Geschäftsziele am besten?"	Ersetzt "Bauchgefühl" durch Analyserahmen qualitativer Vergleich über reine Kosten hinaus	Die Bewertung erfordert eine sehr genaue Analyse der Kandidaten
PBAR	Performance-Based Architecture Review	Leistung: Analyse und Bewertung der Leistungsmerkmale (Antwortzeit, Durchsatz, Skalierbarkeit)	"Hält die Architektur der realen Last stand und wo sind die Flaschenhälse?"	Praxisnah auf reale Systeme anwendbar direkte Bewertung der Performance	Komplex durch notwendiges Metrik-Wissen Messungen sind zeitaufwendig

(7.) Werkzeuge für die Architekturbewertung

Zur Architekturbewertung stehen mehrere praktische Werkzeuge zur Verfügung, die sich je nach Funktion in Kategorien unterscheiden lassen. Tools können helfen, fundierte Entscheidungen zu treffen.

(7.1) Überblick über gängige Werkzeuge

In der Literatur werden verschiedene Arten von Werkzeugen unterschieden, die je nach Projektanforderung eingesetzt werden. Die Auswahl hängt stark von den spezifischen Zielen ab.

• Groupware-Tools: Unterstützen die Zusammenarbeit im Team (z. B. gemeinsame Dokumente, Aufgabenverwaltung)
• Web 2.0-Tools: Nutzen Internet-Mechanismen wie Wikis, Blogs oder Tagging, um Informationsaustausch und soziale Interaktion im Team zu fördern
• Spezialisierte Tools (z. B. BAIT): BAIT (ein Tool zur Architekturanalyse von Biofilmen), dient als Beispiel, wie spezialisierte Tools spezifische Aspekte einer Architektur untersuchen können
• Energieorientierte Tools: Diese analysieren die Effizienz (ursprünglich von Gebäuden, übertragbar auf Software-Energieverbrauch) und bieten Simulationen

(7.2.) Funktionen und Vorteile von Architekturbewertungswerkzeugen

Architekturbewertungswerkzeuge sind spezialisierte Softwarelösungen zur Analyse und Verbesserung von Softwarearchitekturen. Kernfunktionen:

• Visualisierung: Die grafische Darstellung von Komponenten und Beziehungen reduziert Komplexität und hilft, Abhängigkeiten zu verstehen.
• Analyse und Bewertung: Automatisierte Prüfung von Code-Metriken und Qualitätsattributen.
• Kollaboration: Funktionen wie Diskussionsforen oder gemeinsame Bearbeitung fördern die Teamarbeit.
• Anpassungsfähigkeit: Tools lassen sich oft flexibel an spezifische Projektbedürfnisse und Kriterien anpassen.

Diese Werkzeuge bieten mehrere Vorteile:

• Qualitätssteigerung: Schwachstellen und Probleme werden durch automatisierte Einblicke schneller erkannt.
• Bessere Kommunikation: Die Zusammenarbeit und Entscheidungsfindung im Team wird durch eine gemeinsame Datenbasis erleichtert.
• Produktivität: Zeitaufwendige manuelle Aufgaben entfallen, wodurch der Entwicklungsprozess beschleunigt wird.

(8.) Maßnahmen zur Verbesserung der Architekturqualität

Zur Steigerung der Projekt-Erfolgschancen sind Maßnahmen sowohl während der Planung (präventiv) als auch nach der Fertigstellung (korrektiv) nötig. Diese unterteilen sich in:

• Technische Maßnahmen: Einsatz spezifischer Designprinzipien, Technologien und Werkzeuge.
• Organisatorische Maßnahmen: Verbesserung der Kommunikation im Team, Zusammenarbeit sowie die Einführung von Best Practices und Standards.

(8.1) Refactoring

Refactoring ist die systematische Verbesserung des Codes, ohne dessen externes Verhalten zu ändern. Ziel ist sauberer, verständlicherer und wartungsfreundlicherer Code. Dies sichert die langfristige Erweiterbarkeit des Systems.

Konkrete Tätigkeiten sind beispielsweise das Entfernen von redundantem oder totem Code: Das Löschen nicht genutzter Passagen verbessert die Lesbarkeit und eliminiert Fehlerquellen. Lange Methoden werden aufgeteilt, verschachtelte Bedingungen vereinfacht und komplizierte Ausdrücke geklärt. Oder aber Strukturierung des Codes: Zusammengehöriger Code wird in Module/Klassen gruppiert, Variablennamen werden verbessert und Dateistrukturen organisiert. Man kann die Code-Qualität auch verbessern, indem Coding-Standards angewender, die Testabdeckung erhöht und die Dokumentation aktualisiert werden.

Refactoring ist eine Daueraufgabe im gesamten Lebenszyklus, kein einmaliges Event. Es erfordert sorgfältige Planung und kleine Schritte, die durch Tests abgesichert werden müssen, um die Funktionalität nicht zu gefährden. Zum Beispiel können unklare Variablennamen und redundante Berechnungen durch Auslagerung und Umbenennung optimiert werden.

(8.2) Technische Schulden abbauen

Technische Schulden bezeichnen die zusätzlichen Kosten, die entstehen, wenn kurzfristige Lösungen oder Abkürzungen einer soliden, langfristigen Implementierung vorgezogen werden. Wie bei einem Finanzkredit fallen über die Zeit „Zinsen“ an, die sich in Form von höherem Aufwand für Wartung, Fehlerbehebung und langsamerer Entwicklung manifestieren.

Der Abbau erfordert Investitionen an Zeit und Ressourcen, senkt aber langfristig die Kosten und erhöht die Produktivität. Er umfasst:

• Refactoring: Bereinigung des Codes, um ihn wartungsfreundlicher zu machen
• Verbesserung der Testabdeckung: Sicherstellung der korrekten Funktionalität, um unerwartete Probleme bei Änderungen zu vermeiden
• Aktualisierung veralteter Technologien: Austausch alter Systeme, die schwer zu warten sind und keine modernen Funktionen bieten
• Verbesserung der Dokumentation: Erleichtert das Verständnis und die Wartung, besonders bei Personalwechsel

(8.3) Implementierung von Qualitätsstandards

Qualitätsstandards definieren die Erwartungen an die Software und bilden den Rahmen für deren Bewertung und Verbesserung. Ihre Einführung steigert die Zuverlässigkeit der Software, fördert das Verständnis im Team und erhöht die Zufriedenheit der Stakeholder.

Der Implementierungsprozess kann in folgenden Phasen aufgeteilt werden:

• Auswahl: Geeignete Standards (z. B. für Codequalität oder Sicherheit) müssen passend zu den Projektzielen gewählt werden
• Anpassung: Standards müssen oft modifiziert werden, um den spezifischen Bedingungen und Anforderungen des Projekts gerecht zu werden
• Überwachung: Die Einhaltung muss kontinuierlich durch Audits oder Feedback geprüft und bewertet werden

Die Umsetzung ist ein fortlaufender Prozess, der das Engagement des gesamten Teams erfordert.