Das Dokumentieren einer Softwarearchitektur ist für den Projekterfolg unabdinglich. Entwürfe, Entscheidungen und Lösungen müssen nachvollziehbar und wirkungsvoll festgehalten werden. Hierzu gehört idealerweise auch die Beschreibung der verworfenen Alternativen. Denn es stellt sich die Frage, wer nach einem Monat oder auch länger noch alle Gründe weiß, weshalb man sich nun für die eine oder andere Variante entschieden hat. Oder eben auch gegen die eine oder anderen Variante.

Typische Fragen in Softwareprojekten sind beispielsweise:

„Wie sieht das Schichtenmodell aus?”

„Welche Design Patterns wurden verwendet?”

„Welche externen Webservices werden verwendet?”

„Wieso habt Ihr das so gemacht? Ist das nicht zu kompliziert?”

Und wenn die Antworten dann lauten:

„Das war schon so, als ich ins Projekt kam.”

„Es wurde in einem Meeting entschieden.”

„Es gibt keine Dokumentation, weil wir agil vorgehen.”

…dann entfachen immer wieder die gleichen Diskussionen. Durch die Entwürfe, die Diagramme und die Konzepte der Architekturdokumentation sollen allen Projektbeteiligten bessere Antworten auf diese Fragen in Softwareprojekten parat stehen. Eine ausführliche Architekturdokumentation kann also sehr klärend wirken, die Kommunikation unterstützen und Konflikte vorbeugen. Der Softwarearchitekt hat folglich die Aufgabe, eine angemessene Lösung zu entwerfen, um eine Nachvollziehbarkeit und gleichzeitig Lerneffekte zu gewährleisten.

Für alle Arten von Architekturdokumentation gelten daher einige übergreifende Anforderungen und Regeln, die Sie bei der Erstellung solcher Dokumente berücksichtigen sollten. Softwarearchitekten benötigen dabei ein grundlegendes Verständnis der Beschreibung von Softwarearchitekturen. Lernen Sie effektiv und praxisorientiert Softwarearchitekturen zu dokumentieren und zielgruppengerecht zu kommunizieren. Erfahren Sie, wie die Architekturdokumentation zu einem integralen Kommunikations- und Arbeitsmittel wird. Lernen Sie architekturrelevante Einflussfaktoren und zentrale Entscheidungen festzuhalten.

Unser 2-tägiges Softwarearchitektur-Training ‚Architekturdokumentation (ADOC)‘ vermittelt neben fachlichen Aspekten auch die wichtigen organisatorischen und sozialen Faktoren der Architekturdokumentation. Neben den Grundbegriffen der Architekturdokumentation bekommen Sie das Wissen rund um die Bestandteile, Vorgehensmodelle, Werkzeuge, Vorgaben und Bewertung an die Hand.

Am Ende dieses Softwarearchitektur-Trainings haben Sie das Rüstzeug, um die Architekturdokumentation eines mittleren oder großen Systems zu erstellen, zu bewerten und das Vorgehen zur Dokumentation eines solchen Systems zu definieren. Das Softwarearchitektur-Training ‚Architekturdokumentation (ADOC)‘ deckt einen Bereich der methodischen Kompetenzen des CPSA Advanced Levels (CPSA-A) ab und ist entsprechend beim iSAQB lizenziert. Wenn Sie die CPSA-A Zertifizierung anstreben, können Sie sich mit der Teilnahme 20 Credit Points anrechnen lassen.

Hier kommen Sie zu weiteren Informationen und zur Anmeldung.

Bei Fragen beraten wir Sie gerne unter training@itech-progress.com oder +49 621 595702 41

Der Abnahmetermin für die Software steht bevor und das Review der Softwarearchitekturen sorgt für schlaflose Nächte. Eine Architekturbewertung soll durchgeführt werden um die Stärken und Schwächen der Softwarearchitektur zu ermitteln. Wurden die relevanten Qualitätsmerkmale erfüllt und alle Ziele erreicht?

Grundlegend geht es bei der Architekturbewertung darum, herauszufinden, ob eine Softwarearchitektur die in sie gesetzten Erwartungen erfüllt oder nicht. Was sind die Stärken und Schwächen einer Architektur und welche Risiken und Probleme ergeben sich daraus?

Als Vergleich zur Softwarearchitekturbewertung nehmen wir einmal die Bewertung von sportlichen Leistungen. Genau wie bei der Softwarearchitektur lassen sich auch sportlichen Leistungen je nach Disziplin mehr oder weniger gut beurteilen. Wer läuft schneller? Wer springt höher? Wer wirft weiter? Wer schießt mehr Tore?  Diese Fragen sind noch einfach zu beantworten. In der Softwarearchitektur sind die Fragen natürlich ein wenig anders: Wie viele gefundene Fehler gibt es pro Paket? Wie hoch ist der Resscourcenverbrauch? Wie viel Zeit wird für die Verarbeitung bestimmter Funktionen oder Anwendungsfälle benötigt?

Doch nicht alle Fragen sind immer so leicht zu beantworten. Die Bewertung von Turniertänzern oder Eiskunstläufern ist schon etwas komplizierter und lässt sich nicht nach einfachen Zahlen bemessen, sondern funktioniert nach einem komplizierten Schema. Die Qualität entscheidet!

Wie ist das nun in der Softwarearchitektur? Gibt es hier sowas wie Messlatten und Schiedsrichter? Wie sieht hier das Ergebnis aus? Im Sport ist das klar: Der Gewinner bekommt die Goldmedaille.

• Wie zuverlässig läuft das System?
• Wie sicher ist das System?
• Kann die Software ihr Leistungsniveau unter festgesetzten Bedingungen über einen bestimmten Zeitraum aufrechterhalten?
• Wie sparsam ist die Software zur Lösung eines festgelegten Problems bezüglich der Ressourcen, Zeitverhalten bei Anfragen und Bearbeitungen sowie Speicherplatz?
• Wie hoch ist der Aufwand zur Fehlerbeseitigung, zur Umsetzung von Verbesserungen oder zur Anpassung an Umgebungsveränderungen?
• Ist die Software auch auf anderen Systemen (Hard- und Software) einsetzbar?

In der Softwarearchitektur gibt es verschiedene Methoden und Werkzeuge, die zu unterschiedlichen Zeitpunkten eingesetzt werden können. Bei der Bewertung einer Architektur gibt es jedoch zwei Ansätze: der qualitative Ansatz und der quantitative Ansatz.

Qualitativer Ansatz zur Architekturbewertung

Der qualitative Ansatz ermöglicht eine Bewertung nach Beschaffenheit oder Güte der Softwarearchitektur und hilft frühzeitig Risiken zu identifizieren, die die Erreichung der Qualitätsziele gefährden können. Ein Qualitätsmodell (wie z.B. ISO 25010) kann verwendet werden. Das ISO Modell definiert acht Qualitätsmerkmale: Benutzbarkeit, Effizienz, Funktionale Eignung, Kompatibilität, Sicherheit, Übertragbarkeit, , Wartbarkeit und Zuverlässigkeit.

Die qualitative Bewertung sollte jedoch regelmäßig und so früh wie möglich stattfinden. Eine der führenden Methoden im Bereich der Softwarearchitekturbewertung ist ATAM. ATAM seht für Architecture Tradeoff Analysis Method und bezeichnet eine Szenario-basierte Methode zur Bestimmung der Stärken, Schwächen und den getroffenen Kompromissen einer Softwarearchitektur. Ein ATAM-Workshop dauert in der Regel 3 – 4 Tage und wird gemeinsam mit den Stakeholdern durchgeführt.

Quantitativer Ansatz zur Architekturbewertung

Der quantitative Ansatz ist eine Bewertung der Artefakte in Zahlen und kann helfen, kritische Teile innerhalb von Systemen zu identifizieren. Im Gegensatz zur qualitativen Bewertung liefert sie keine Aussage über die Funktionsfähigkeit der Software. Zur Bewertung wird eine Reihe von Messungen und Metriken verwendet, wie beispielsweise die Anzahl der geänderten Anforderungen pro Zeiteinheit, die Anzahl der Testfälle, die Anzahl der gefundenen Fehler pro Paket, die Anzahl der neuen Codezeilen oder die Zyklomatische Komplexität. Der Vorteil ist, dass die Messungen automatisierbar sind und leicht wiederholt werden können. Es besteht jedoch auch die Gefahr von Missdeutungen, da ein fachlicher und technischer Kontext benötigt wird, um vergleichbar zu sein. Gesammelte Daten aus Vergleichsprojekten können hierbei hilfreich sein.

Insgesamt gesehen ist die Architekturbewertung ein wichtiges Hilfsmittel zur Bestimmung der Qualität einer Software bei der es aber weniger darum geht die Architektur zu benoten, sondern eher mehr Durchblick zu bekommen.

Sie möchten noch mehr erfahren?

Das 2-tägige iSAQB-akkreditierte Training “Architekturbewertung (AWERT)” vermittelt das notwendige Wissen und die Fähigkeiten, um Softwarearchitekturen bewerten zu können. Ziel ist die Beantwortung der Frage: Wie findet man heraus, ob eine Architektur die Erwartungen erfüllt?

Zu den Terminen