[et_pb_section fb_built=”1″ _builder_version=”4.6.5″ _module_preset=”default” custom_padding=”30px||0px||false|false” hover_enabled=”0″ sticky_enabled=”0″][et_pb_row _builder_version=”4.6.5″ _module_preset=”default” hover_enabled=”0″ sticky_enabled=”0″][et_pb_column type=”4_4″ _builder_version=”4.6.5″ _module_preset=”default”][et_pb_text _builder_version=”4.6.5″ _module_preset=”default” link_text_color=”#0090d8″ header_2_font=”|600|||||||” header_2_text_color=”#003f86″ custom_margin=”||29px|||” hover_enabled=”0″ sticky_enabled=”0″ ul_line_height=”1.8em” ul_text_color=”#555555″ ul_font=”||||||||” link_font=”|600|||||||”]<\/p>\n
Der Abnahmetermin f\u00fcr die Software steht bevor und das Review der Softwarearchitekturen sorgt f\u00fcr schlaflose N\u00e4chte. Eine Architekturbewertung soll durchgef\u00fchrt werden um die St\u00e4rken und Schw\u00e4chen der Softwarearchitektur zu ermitteln. Wurden die relevanten Qualit\u00e4tsmerkmale erf\u00fcllt und alle Ziele erreicht?<\/p>\n
Grundlegend geht es bei der Architekturbewertung darum, herauszufinden, ob eine Softwarearchitektur die in sie gesetzten Erwartungen erf\u00fcllt oder nicht. Was sind die St\u00e4rken und Schw\u00e4chen einer Architektur und welche Risiken und Probleme ergeben sich daraus?<\/p>\n
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\u00e4uft schneller? Wer springt h\u00f6her? Wer wirft weiter? Wer schie\u00dft mehr Tore?\u00a0 Diese Fragen sind noch einfach zu beantworten. In der Softwarearchitektur sind die Fragen nat\u00fcrlich ein wenig anders: Wie viele gefundene Fehler gibt es pro Paket? Wie hoch ist der Resscourcenverbrauch? Wie viel Zeit wird f\u00fcr die Verarbeitung bestimmter Funktionen oder Anwendungsf\u00e4lle ben\u00f6tigt?<\/p>\n
Doch nicht alle Fragen sind immer so leicht zu beantworten. Die Bewertung von Turniert\u00e4nzern oder Eiskunstl\u00e4ufern ist schon etwas komplizierter und l\u00e4sst sich nicht nach einfachen Zahlen bemessen, sondern funktioniert nach einem komplizierten Schema. Die Qualit\u00e4t entscheidet!<\/p>\n
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.<\/p>\n
In der Softwarearchitektur gibt es verschiedene Methoden und Werkzeuge, die zu unterschiedlichen Zeitpunkten eingesetzt werden k\u00f6nnen. Bei der Bewertung einer Architektur gibt es jedoch zwei Ans\u00e4tze: der qualitative Ansatz und der quantitative Ansatz.<\/p>\n
<\/p>\n
Der qualitative Ansatz erm\u00f6glicht eine Bewertung nach Beschaffenheit oder G\u00fcte der Softwarearchitektur und hilft fr\u00fchzeitig Risiken zu identifizieren, die die Erreichung der Qualit\u00e4tsziele gef\u00e4hrden k\u00f6nnen. Ein Qualit\u00e4tsmodell (wie z.B. ISO 25010) kann verwendet werden. Das ISO Modell definiert acht Qualit\u00e4tsmerkmale: Benutzbarkeit, Effizienz, Funktionale Eignung, Kompatibilit\u00e4t, Sicherheit, \u00dcbertragbarkeit, , Wartbarkeit und Zuverl\u00e4ssigkeit.<\/p>\n
Die qualitative Bewertung sollte jedoch regelm\u00e4\u00dfig und so fr\u00fch wie m\u00f6glich stattfinden. Eine der f\u00fchrenden Methoden im Bereich der Softwarearchitekturbewertung ist ATAM. ATAM seht f\u00fcr Architecture Tradeoff Analysis Method und bezeichnet eine Szenario-basierte Methode zur\u00a0Bestimmung der St\u00e4rken, Schw\u00e4chen und den getroffenen Kompromissen einer Softwarearchitektur. Ein ATAM-Workshop dauert in der Regel 3 \u2013 4 Tage und wird gemeinsam mit den Stakeholdern durchgef\u00fchrt.<\/p>\n
<\/p>\n
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 \u00fcber die Funktionsf\u00e4higkeit der Software. Zur Bewertung wird eine Reihe von Messungen und Metriken verwendet, wie beispielsweise die Anzahl der ge\u00e4nderten Anforderungen pro Zeiteinheit, die Anzahl der Testf\u00e4lle, die Anzahl der gefundenen Fehler pro Paket, die Anzahl der neuen Codezeilen oder die Zyklomatische Komplexit\u00e4t. Der Vorteil ist, dass die Messungen automatisierbar sind und leicht wiederholt werden k\u00f6nnen. Es besteht jedoch auch die Gefahr von Missdeutungen, da ein fachlicher und technischer Kontext ben\u00f6tigt wird, um vergleichbar zu sein. Gesammelte Daten aus Vergleichsprojekten k\u00f6nnen hierbei hilfreich sein.<\/p>\n
Insgesamt gesehen ist die Architekturbewertung ein wichtiges Hilfsmittel zur Bestimmung der Qualit\u00e4t einer Software bei der es aber weniger darum geht die Architektur zu benoten, sondern eher mehr Durchblick zu bekommen.<\/p>\n
<\/p>\n
Das 2-t\u00e4gige iSAQB-akkreditierte Training “Architekturbewertung (AWERT)” vermittelt das notwendige Wissen und die F\u00e4higkeiten, um Softwarearchitekturen bewerten zu k\u00f6nnen. Ziel ist die Beantwortung der Frage: Wie findet man heraus, ob eine Architektur die Erwartungen erf\u00fcllt?<\/span><\/p>\n