IUBH Qualitätssicherung im Softwareprozess IQSS

• Komponententest
• Integrationstest
• Systemtest
• Abnahmetest

• Testanforderungsanalyse
• Testplanung
• Testfallspezifikation
• Testdatenerstellung
• Testausführung
• Testauswertung

• Der Aufwand, der nach der Auslieferung des Systems betrieben wird, sollte kostenoptimal sein.
• Für jedes System individuell bestimmen
• Identifizierten Risiken müssen durch konkrete QS-Maßnahmen adressiert werden.
• Die Testanforderungsanalyse ist vergleichbar mit der Anforderungsanalyse des  SW-Systems
• Hier werden die zu erreichenden Qualitätsziele/der Qualitätsgrad bestimmt
• Es wird beschrieben, welche Systemfunktionen / Systemeigenschaften getestet werden sollen.
• Ergebnis der Testanforderungsanalyse sind noch recht grobe Beschreibungen der Testfälle  ohne jedoch schon auf Details zum Ablauf oder zu den Testdaten einzugehen.

• Je komplexer die Vorbereitung, Durchführung und Auswertung eines Tests ist, desto sorgfältiger muss die Testplanung erfolgen.
• Typischerweise ist diese Aktivität bei Systemtests am stärksten ausgeprägt.
• Die Bereitstellung von Testumgebungen dauert in der Praxis nicht selten mehrere Tage oder Wochen.
• Je nachdem, was für technische oder personelle Ressourcen für die Testdurchführung benötigt werden, müssen diese eingeplant und deren Verfügbarkeiten zugesichert werden.

Was -> Welche Objekte und Funktionen sind zu testen?

Warum -> Welche Ziele verfolgt der Test?

Wann -> Welche Termine sind einzuhalten?

Wo -> Wo soll getestet werden?

Wie -> Unter welchen Bedingungen soll getestet werden?

Womit -> Mit welchen Mitteln/Werkzeugen soll getestet werden?

Wer -> Welche Mitarbeiter führen den Test durch?

• Konkrete Testfälle erstellt und beschrieben.
• Anhand der Testfallspezifikation werden die Tests dann später ausgeführt.
• Aufbauend auf den identifizierten Testfallanforderungen wird eine Beschreibung zu folgenden Aspekten erstellt:
  • Zweck des Testfalls;
  • Testgegenstände;
  • Zustand des Systems vor und nach Testausführung;
  • Art und Struktur der Testdaten;
  • benötige Hard- und Softwareumgebung;
  • benötigtes Personal; 
  • Abhängigkeiten zu anderen Testfällen.
• Bei kleinen und fachlich einfachen Testfällen erfolgt die Testdatenerstellung häufig zeitlich
• Bei komplexen Tests, wie beispielsweise Systemtests, werden bei der Testfallspezifikation Art und Struktur der Testdaten beschrieben, deren Erstellung erfolgt jedoch als separate Aktivität.
• Vor Beginn der Testfallspezifikation sollte festgelegt werden, auf welche Weise die Testfälle gewonnen werden und welcher Abdeckungsgrad mit den Testfällen erreicht werden soll.

• Das Ergebnis sind Testdatensätze, die zur Durchführung der Testfälle benötigt werden.
• Wie viele Testdaten benötigt werden und welche Anforderungen es an die Testdaten gibt, wird in der Testfallspezifikation festgelegt.
• Für einfache Komponenten /Integrationstests reichen häufig einfach strukturierte Testdaten aus
• Für Systemtests oder Abnahmetests sind häufig komplexe Testdatensätze erforderlich,  
• Zur Erstellung von Testdaten können alle dem Tester zur Verfügung stehenden Quellen genutzt werden:
  • Spezifikation
  • Architekturbeschreibung
  • Programmcode
  • Produktionsdaten
  • Testdatenbestand

• Durchführung der spezifizierten Testfälle unter Verwendung der Testdatensätze und Protokollierung der Ergebnisse.
• Wurden bei der Testdurchführung Fehler identifiziert, müssen diese in einer Mängelliste dokumentiert werden.
• Zu diesem Zweck werden in der Praxis sogenannte Ticketsysteme / Bugtracker eingesetzt.
• Die Durchführung der Tests erfolgt entweder automatisch oder manuell.
• Bei der manuellen Durchführung werden durch menschliche Nutzer die Vorbedingungen zum Start des Testfalls her- bzw. sichergestellt, der Test durchgeführt, die Nachbedingungen geprüft sowie das Systemverhalten protokolliert und bewertet.
• Bei der automatischen Durchführung von Softwaretests wird die Testfallspezifikation zusammen mit den Testdaten so beschrieben, dass diese von Testsystemen automatisch durchgeführt werden können.
• Automatische Tests sind grundsätzlich in allen Teststufen möglich. Das gilt für technische Tests, in denen Programmfunktionen entweder direkt oder über eine technische Schnittstelle aufgerufen werden. Aber auch für GUI-Tests, bei denen Werte in eine Nutzeroberfläche eingegeben und definierte Interaktionsschritte ausgeführt werden.

• Nach Abschluss der Ausführung werden die Testergebnisse ausgewertet und der Qualitätsgrad des Systems beurteilt.
• Die Ergebnisse der Auswertungen bilden die Grundlagen für Entscheidungen über die weiteren Aktivitäten im Softwareprozess:
  • Wurde der angestrebte Qualitätsgrad erreicht, kann beispielsweise das Quality Gate absolviert oder das System ausgeliefert werden.
  • Wurde der angestrebte Qualitätsgrad nicht erreicht, müssen die erforderlichen Nacharbeiten durchgeführt werden.

• Jede Komponente wird separat implementiert und nach Fertigstellung in das System eingebracht (auch: integriert).
• Während bzw. nach der Fertigstellung einer Softwarekomponente kann diese bereits auf Einhaltung von spezifizierten Vorgaben überprüft werden.
• Das isolierte Prüfen von einzelnen Softwarebestandteilen wird Komponententest genannt

• Um die Qualität des selber erstellen Programmcodes zu testen.
• Mit dieser Art von Tests wird die korrekte Ausführung von einzelnen Komponenten geprüft.
• Das Ziel, das mit dem Einsatz von Unit-Tests erreicht werden soll, ist eine möglichst große Testabdeckung
• Unit-Tests sind White Box-Tests,
• Von automatischen Unit-Tests wird häufig gefordert, dass sie die Eigenschaften Reproduzierbarkeit, Unabhängigkeit und Regressionsfähigkeit haben:

Reproduzierbarkeit

• Ein einmal erstellter Unit-Test sollte uneingeschränkt reproduzierbar sein.
• Das wird unter anderem auch durch das Verwenden von im Testfall fest definierten Testdaten erreicht, die nicht von der erfolgreichen Ausführung anderer Unit-Tests abhängen.

Unabhängigkeit

• Darüber hinaus sollten Unit-Tests keine funktionalen Abhängigkeiten untereinander haben
• Die Reihenfolge der Testausführung der Unit-Tests darf keine Rolle spielen.
• Jeder Test muss individuell dafür sorgen, dass die von ihm benötigten Vorbedingungen hergestellt werden.Dazu zählt beispielsweise auch, dass bei der Durchführung von Tests zuerst der erforderliche Datenbestand in die Datenbank eingespielt wird, auf dem dann der Test durchgeführt wird.

Regressionsfähigkeit

• Am Ende einer Iteration muss der erforderliche Qualitätsgrad sichergestellt sein.
• Für die Unit-Tests bedeutet das, dass alle Unit-Tests, die bereits erfolgreich ausgeführt werden konnten, auch nach einer Überarbeitung erfolgreich durchlaufen werden müssen.
• Die Durchführung bereits bestandener Tests nach Änderungen am Programmcode werden Regressionstests genannt. Am Ende einer Iteration müssen also alle bisher erstellten und alle neuen Unit-Tests erfolgreich durchlaufen werden. Das ist der Grund, warum die Testautomatisierung eine wichtige Voraussetzung für die evolutionäre Softwareentwicklung ist.

• Mit Test Driven Development soll eine hohe Qualität und eine hohe Abdeckung des erstellten Programmcodes durch Unit-Tests sichergestellt werden, i
• Der Unterschied zur herkömmlichen Entwicklung von Testfällen ist die Erstellung von Unit-Tests zu Funktionen, bevor deren Methodenrumpf programmiert wird.
• Die Systemfunktionen werden nun schrittweise implementiert und bereits während der Implementierung getestet.
• In der praktischen Anwendung wechseln sich die Aktivitäten Testen und Implementieren in kurzen Zyklen ab, sodass ein Zyklus oft nur wenige Minuten dauert.
• Wird der Test erstellt, bevor der Programmcode implementiert wird, muss sich der Entwickler zuerst intensiv mit der zu erstellenden Funktion auseinandersetzen, bevor die erste Zeile Programmcode geschrieben wurde. Mit diesem Zwang zum vorherigen Durchdenken der Fachlichkeit und möglicher Fehlersituationen wird ein Bewusstsein für möglicherweise kritische und fehleranfällige Bereiche der Funktionen geschaffen, die dann bei der Implementierung direkt mit berücksichtigt werden können.

• Sobald mindestens zwei Softwarekomponenten fertiggestellt wurden, können sie zu einem System zusammengeführt, also integriert werden.
• Während bzw. nach der Integration wird in Integrationstests das Zusammenspiel von Gruppen von Komponenten getestet und geprüft, ob die Komponenten so zusammenarbeiten, wie es in der Spezifikation beschrieben wurde.
• Im Vergleich zum Komponententest soll bei Integrationstests nicht das interne Verhalten einzelner Komponenten intensiv geprüft werden, sondern das Zusammenspiel
• Für Integrationstest müssen gezielt solche Testfälle erstellt und durchgeführt werden, mit denen die durch die Schnittstellen bereitgestellten Funktionen umfangreich geprüft werden.
• Dazu zählt insbesondere auch das Verhalten von Schnittstellen bei fehlerhaften Aufrufen und fehlerhaft übermittelten Daten.
• Test Driven Development ist auch für Schnittstellen zwischen Systemkomponenten möglich.

• Bei Softwaresystemen mit vielen Komponenten sind nicht alle zur gleichen Zeit fertig.
• In diesen Fällen werden fehlende Komponenten durch sogenannte Treiber und Dummies simuliert, damit bereits mit den Test begonnen werden kann.
• Als Treiber werden dabei die Softwarefragmente bezeichnet, die das Aufrufen anderer Komponenten simulieren.
• Dummies hingegen simulieren Komponenten, die durch andere Komponenten aufgerufen werden.

• Bei der Bottom Up-Strategie werden die Basiskomponenten zuerst implementiert.
• Dabei  werden intensiv Treiber eingesetzt.
• Aufbauend auf den Basiskomponenten werden anschließend die Komponenten implementiert, die auf Basisdienste zugreifen. 
• Bei der Bottom Up-Strategie beginnt die Systementwicklung in der untersten Systemebene und wird Ebenenweise sukzessive bis zur obersten Systemebene durchgeführt.
• Dabei werden die Treiber Stück für Stück durch die fertiggestellten Komponenten ersetzt.
• Ein Vorteil der Bottom Up-Strategie ist die frühzeitige Prüfung von Basiskomponenten, die aufgrund ihrer Nähe zur Hardware und zur Infrastruktur bezogen auf die eingesetzten Technologien sehr heterogen ist. Darüber hinaus können durch den Einsatz von Treibern die erstellten Testdaten gezielt und direkt eingegeben werden.
• Nachteil, dass den Anwendern erst am Ende der Integration das System präsentiert werden kann und damit ein wesentliches Projektrisiko nicht frühzeitig adressiert werden kann. Weiterhin können keine gezielten falschen Rückgabewerte von aufgerufenen Komponenten getestet werden, da bei der Bottom Up-Strategie keine Dummies zum Einsatz kommen.

• Beim Einsatz der Top Down-Strategie beginnt die Integration der Systemkomponenten an der obersten Systemebene und endet mit der Integration der Basiskomponenten.
• Zuletzt werden im Rahmen einer Top Down-Strategie die Basiskomponenten implementiert und mit deren Integration in das Gesamtsystem die verbleibenden Dummies entfernt.
• Die Vorteile der Top Down-Strategie sind eine frühzeitige Verfügbarkeit der Systemebene, mit denen die Anwender arbeiten. Daher können somit zur Steigerung der Anwenderzufriedenheit recht schnell erste Erfahrungen und Verbesserungswünsche gesammelt werden. Darüber hinaus lassen sich fehlerhafte Rückgabewerte von aufgerufenen Basiskomponenten leicht simulieren, da diese direkt durch die Dummies erzeugt werden können.
• Nachteile der Top Down-Strategie ist allerdings die sehr späte Integration von  Basiskomponenten zu nennen, die häufig verschiedene Technologierisiken bergen. Außerdem können im Vergleich zur Bottom Up-Strategie die Testdaten nicht so gezielt eingegeben werden, da bei der Top Down-Strategie keine Treiber eingesetzt werden.

• Bei der in diesem Skript By Value-Strategie genannten Integrationsstrategie erfolgt die Integration der Komponenten nach Aspekten der Wertorientierung einzelner Komponenten.
• Im Vergleich zur Top Down-Strategie oder Bottom Up-Strategie orientiert sich die By Value- Strategie nicht strikt entlang der technischen Ebene der Komponenten im Gesamtsystem, sondern an den tatsächlichen Bedürfnissen des Softwareprojektes.
• Die Reihenfolge der Integration der Komponenten in das Gesamtsystem wird projektabhängig festgelegt. Begonnen wird dabei mit den Komponenten, mit denen der größte Wertbeitrag geliefert werden kann.
• Damit handelt es sich bei der By Value-Strategie um eine Mischform, die sowohl Treiber als auch Dummies für die Durchführung der Komponententests benötigt.
• Die Vorteile der By Value-Strategie liegen in der Möglichkeit abhängig von der aktuellen Projektsituation entscheiden zu können, welche Komponenten integriert und getestet werden sollen. Mit dem Einsatz von Treibern und Dummies sind sowohl gezielte Eingaben von Testdaten alsauch die gezielte Simulation fehlerhafter Rückgabewerte möglich.
• Nachteil der By Value- Strategie ist der Einsatz sowohl von Treibern als auch von Dummies, womit der Aufwand zur Erstellung von reinen Testartefakten im Vergleich zu anderen Integrationsstrategien gegebenenfalls höher ist.

• Strategien Bottom Up und Top Down in der Regel Idealmuster, praktisch so keine Anwendung
• By Value genannte Integrationsstrategie bietet dem Projektteam die entsprechenden Freiräume je nach aktuellem Bedarf auch auf geänderte Situationen angemessen zu reagieren

• Dummy stellt alle von der Komponente benötigten Schnittstellen/ Funktionen zur Verfügung,
• Andere Entwicklungsteams, können jederzeit die Dummy-Komponente einsetzen.
• Durch die Verantwortung zur Pflege ist sichergestellt, dass der  Entwicklungs-stand aktuell ist
• Da sie alle Schnittstellenfunktionen simulieren können, können sie sowohl als Treiber als auch als Dummies eingesetzt werden.
• Für die Durchführung von Integrationstests muss zu jeder Komponente in jedem Fall ein Dummy erstellt werden.
• Es ist zu jedem Zeitpunkt sichergestellt, dass dieser eine Dummy sich genauso verhält wie die echte Komponente.
• Mit der Lieferung von Dummy und echter Komponente aus einer Hand kann eine hohe Testqualität sichergestellt werden.

• Nach Abschluss der Entwicklungsarbeiten/Integration wird das System als Ganzes getestet.
• Ziel des Systemtests ist die Überprüfung, ob das System als Ganzes die spezifizierten Anforderungen erfüllt.
• Neben Funktionstests werden dabei auch Performancetests und Lasttestsdurchgeführt.
• Eine große Herausforderung ist die möglichst originalgetreue Nachbildung der Produktivumgebung des Kunden.
• Black Box Test
• Die Durchführung der Testfälle erfolgt auf Dateneingaben in der Nutzerober fläche oder über das Aufrufen der Systemschnittstellen, durch die das System mit seinen Umsystemen verbunden ist.
• Die Auswertung der Testfälle erfolgt anhand des nach außen sichtbaren Systemverhaltens.

• Beim Performancetest wird das Verhalten des Systems unter Belastung auf Einhaltung der spezifizierten Qualitätseigenschaften und der Messung der Leistungsfähigkeit geprüft.
• Wichtig hierbei ist die genaue Nachbildung der Hardwareund Softwareumgebung
• Typische Indikatoren für die Leistungsfähigkeit von Softwaresystemen:
  • Latenz
  • Durchsatz
  • Transaktionsrate

• Lasttests testen das Systemverhalten unter besonders hohen Anforderungen, bspw. durch das gezielte Entziehen von Ressourcen.
• Beispiele für den Ressourcenentzug sind das Wegnehmen von verfügbarem Arbeits- oder Festplattenspeicher,
  die Reduzierung von Netzwerkbandbreite oder die Senkung der Verarbeitungsgeschwindigkeit des Datenbanksystems
• Beispiele für die Lasterzeugung sind das gleichzeitige Anmelden und Arbeiten extrem vieler Nutzer, die Eingabe von sehr großen Datenmengen oder das Anstoßen von sehr vielen Transaktionen.
• Mit der Durchführung von Lasttests wird beobachtet wie sich das System im Fall einer Überlast verhält, ob es dabei zum Verlust oder zu Inkonsistenzen von Daten kommt und ob sich das System bei dem Hinzufügen von Ressourcen wieder stabilisiert.

• Sicherheitstest: Ausprobieren typischer Angriffsszenarien und Sicherstellung, dass das System die geforderten Sicherheitseigenschaften erfüllt;
• Usability-Test: Methodische Überprüfung der Gebrauchstauglichkeit des Systems hinsichtlich der spezifizierten Anforderungen an die Benutzbarkeit, die beispielsweise als Experiment mit Probanden der späteren Nutzergruppe durchgeführt wird;
• Wiederinbetriebnahmetest: Prüfen, ob sich das System nach einem Ausfall wieder in den ursprünglichen Betriebszustand überführen lässt. Hierzu zählen insbesondere auch das Einspielen von Backups und die Überprüfung, ob der ursprüngliche Systemzustand inklusive aller Anwendungsdaten wiederhergestellt werden kann.

• Bereits erfolgreich durchgeführte Tests nach einer Anpassung des Systems erneut durchführen
• In der Regel sollten alle erstellten Testfälle regressionsfähig sein.
• Am Ende einer jeden Iteration wird jedes Mal das Gesamtsystem getestet. en.
• Die Fähigkeit alle bereits bestehenden Testfälle kontinuierlich zu wiederholen,
• Erreichung eines kontinuierlich hohen Qualitätsgrades
• Durchführung der Testfälle weitestgehend durch Automatisierung

• Die letzte Teststufe i(auch: Akzeptanztest).
• Das fertige System beim Auftraggeber installiert und unter den tatsächlichen Betriebsbedingungen getestet.
• Wird geprüft, ob das System aus Kundensicht die vertraglich vereinbarten Leistungsmerkmale aufweist.
• Der Auftraggeber führt den Abnahmetest selber durch oder wird in die Durchführung miteinbezogen.
• Ist eine spezielle Art des Systemtests, eine trennscharfe Abgrenzung ist dabei in der Regel schwierig.
• Der wichtigste Unterschied gegenüber dem Systemtest ist jedoch die Durchführung durch eine andere Organisation als die, die das System entwickelt hat.
• Ein erfolgreicher Abnahmetest ist häufig die vertraglich vereinbarte Voraussetzung für die Rechnungslegung.

• Die analytische Qualitätssicherung von Anforderungen
• Das Ziel der Aktivitäten zum Prüfen und Abstimmen ist die Freigabe der Anforderungen zur Umsetzung in den nach gelagerten Phasen des Softwareprojekts.
• Bbeginnt nach der Ermittlung der fachlichen Anforderungen
• So soll sichergestellt werden,dass vor der Weiterverarbeitung deren Qualität gesichert wird.
• Notwendig, weil alle weiteren Aktivitäten im SW Prozess direkt oder indirekt von den dokumentierten Anforderungen abhängig sind.
• Jeder Fehler in den Anforderungen, der nicht frühzeitig erkannt wird, pflanzt sich über die technische Spezifikation und Architektur bis hin zum Programmcode fort.
• Zusätzlich für fachliche Anforderungen wichtig, dass sie mit allen relevanten Stakeholdern abgestimmt sind.
• Außerdem lassen sich einmal umgesetzte Anforderungen nicht ohne weiteres ändern oder wieder aus dem System entfernen.
• Eine Abstimmung zwischen den Stakeholdern ist erforderlich, sobald in der Menge der dokumentierten Anforderungen Widersprüche identifiziert wurden. Falls die sich widersprechenden Anforderungen von verschiedenen Stakeholdern stammen, die jeweils auch noch widersprüchliche Ziele innerhalb des Projektes verfolgen, liegt eine Konfliktsituation vor.
• Ein weiterer Auslöser für einen Konflikt ist die Identifikation eines Widerspruchs zwischen den dokumentierten Anforderungen und der Ansicht eines Stakeholders. Gründe für diese Situation können beispielsweise im Projektverlauf geänderte Anforderungen an das System oder eine unvollständige Anforderungsermittlung sein.
• In der Praxis zeigt sich, dass sich widersprechende Anforderungen oft aus einem unterschiedlichen Verständnis von Begriffen, Zuständigkeiten und der Motivation des Projektes resultieren.

• Die Aktivitäten zum Prüfen und Abstimmen von Anforderungen lassen sich in vier Schritte unterteilen:

1. Prüfkriterien festlegen;
2. Prüfprinzipien und Prüftechniken auswählen;
3.  Prüfung durchführen und Ergebnisse dokumentieren; sowie
4. Abstimmen der Anforderungen / Konfliktmanagement.

• Auch für die Qualitätssicherung von Anforderungen gilt „Vollständiges Testen ist nicht möglich“.
• In der Praxis sind auch Anforderungs dokumente in der Regel weder völlig fehlerfrei noch vollständig.
• Menge der Anforderungen genau geprüft werden soll.
• Requirements Engineer ist für die Erstellung verantwortlich.
• Prüfkriterien für Anforderungen lassen sich drei verschiedenen Qualitätsaspekten zuordnen:

Prüfen des Inhalts

• „Sind alle relevanten Anforderungen im erforderlichen Detailgrad so erfasst, dass sie verstanden werden können?“.

Prüfen der Dokumentation

• „Wurden sie verständlich und unter Einhaltung der Vorschriften zur Dokumentation dokumentiert?“

Prüfkriterien zur Abgestimmtheit

•  „Stimmen alle relevanten Stakeholder den dokumentierten Anforderungen zu und sind die bekannten Konflikte gelöst?“

• Im Rahmen der Prüfung von Anforderungen können verschiedene Prüfprinzipien unterschieden werden, die zwar selber noch keine Prüftechnik darstellen, jedoch bei der Auswahl der Prüftechniken helfen.
• Prüftechniken hingegen sind konkrete Verfahren oder Vorgehensweisen, die zur Durchführung der Prüfung eingesetzt bzw. genutzt werden.
• Eine Prüftechnik kann ein oder mehrere Prüfprinzipien unterstützen.

Prüfprinzipien:
•     Prinzip 1: Beteiligung der richtigen Stakeholder;
•     Prinzip 2: Trennung von Fehlersuche und Fehlerkorrektur;
•     Prinzip 3: Prüfung aus unterschiedlichen Sichten;
•     Prinzip 4: Geeigneter Wechsel der Dokumentationsform;
•     Prinzip 5: Konstruktion von Entwicklungsartefakten;
•     Prinzip 6: Wiederholte Prüfung.

• Nach Abschluss der fachlichen Vorbereitung muss die Prüfung organisatorisch geplant werden.
• Dazu zählen die Organisation der benötigten Infrastruktur, die zeitliche Planung aller Beteiligten und gegebenenfalls die Koordination von externen Gutachtern.
• Wichtig bei der Durchführung ist dabei die Konzentration auf die Dokumentation der Prüfungsergebnisse.
• Die Fehlerbehebung und Überarbeitung der dokumentierten Anforderungen erfolgt im Anschluss und ist nicht Teil der Prüfung.

• Falls sich widersprechende Anforderungen identifiziert wurden und diese nicht einfach behoben werden können, liegt eine Konfliktsituation vor.
• Mit den Aktivitäten zur Abstimmung von Anforderungen soll zum einen die Erreichung eines gemeinsamen und übereinstimmenden Verständnisses der Menge der Anforderungen unter den Stakeholdern erreicht werden
• Zum anderen müssen aber auch Entscheidungen getroffen werden, welche Anforderungen tatsächlich umgesetzt werden sollen. Dabei soll mit den Mitteln des Konfliktmanagements der Konflikt aufgelöst und gleichzeitig die Kooperationsbereitschaft der Stakeholder aufrechterhalten werden.

• Wann und mit welchen Techniken die Qualität von Architekturen geprüft und bewertet wird, ist grundsätzlich vom Ziel der Prüfung abhängig:
  • Zum einen kann die Eignung einer konzipierten Architektur vor der Implementierung (ex ante) und auf Basis der Architekturbeschreibung geprüft werden.
  • Zum anderen kann begleitend zur Implementierung und nach Ende der Implementierung (ex post) geprüft werden, ob sich die tatsächlich erstellte Architektur an die Vorgaben der vor der Implementierung erstellten Architekturbeschreibung hält.

• Mit der Bewertung einer Architektur vor deren Umsetzung soll eine Aussage über die Eignung einer Architektur zur Erfüllung der Anforderungen an ein System erreicht werden.
• Bezieht sich in der Regel auf die Erfüllung von Qualitätseigenschaften und Randbedingungen, da diese Arten von Anforderungen den größten Einfluss auf die Wahl einer geeigneten Architektur haben.
• Für diesen Zweck werden Techniken der szenariobasierten Architekturanalyse angewendet. Eine häufig eingesetzte Technik zur szenariobasierten Architektur analyse ist die Architecture Tradeoff Analysis Method (kurz: ATAM).
• Das Grundprinzip der szenariobasierten Architekturanalyse ist die Bewertung von Architekturdefinitionen anhand von konkreten Anwendungsszenarien des zu erstellenden Systems.
• Nachdem eine Architekturdefinition erstellt und dokumentiert wurde, wird diese anhand von ausgewählten Anwendungsszenarien untersucht. Dabei wird bei der Architekturdefinition bewertet, ob insbesondere die von der Anwendung geforderten Qualitätseigenschaften unterstützt werden.

• Architecture Tradeoff Analysis Method
• Umfasst nicht nur Aktivitäten zur Bewertung von Architekturdefinitionen, verbindet mit dem Finden Alternativen.

Phase 1: Vorbereitung und Präsentation

• Vorbereitung und Präsentation der Basisarchitektur unter Einbeziehung aller relevanten.
• Zunächst wird in Schritt 1 allen Beteiligten die Vorgehensweise ATAM vorgestellt und erläutert,
• In Schritt 2 werden die funktionalen Anforderungen, Qualitätsanforderungen und Randbedingungen vorgestellt. Business Driver gennant.
• Letzte Schritt der Phase 1 ist die Vorstellung der durch die Architekten erstellten Basisarchitektur. Handelt sich um einen noch zu verfeinernden Architekturentwurf, Ziel von Schritt 3 ist Darstellung des aktuellen Stands der Architekturdefinition sowie die Klärung von noch offenen Punkten.

Phase 2: Untersuchung und Analyse

• Mit den Erkenntnissen aus der ersten Phase erstellt das Architekturteam in Schritt 4 auf Grundlage der Basisarchitektur verschiedene Architekturvarianten
• Im Hinblick auf die Evaluation der Architektur in Phase 3 werden in Schritt 5 Anwendungsszenarien erstellt und priorisiert, mit denen Qualitätseigenschaften beschrieben werden. (Utility Tree)
• In Schritt 6 von ATAM werden die in Schritt 4 erstellten Architekturvarianten auf Erfüllung der in Schritt 5 hergeleiteten Szenarien geprüft. Ergebnis ist eine prio Liste der Architekturvarianten

Phase 3: Test

• Ermittlung der am besten geeigneten Architekturvariante. Dazu wird zunächst in Schritt 7 die bereits in Schritt 5 erstellte Menge von Szenarien verfeinert, erweitert und priorisiert.
• In Schritt 8 erfolgt dann die detaillierte Analyse der Architekturvarianten unter Verwendung der in Schritt 7 detaillierten Menge von Szenarien. Diese Prüfung erfolgt vergleichbar wie in Schritt 6, nun allerdings auf Basis der erweiterten und detaillierteren Szenarien.
• Es wird eine Gesamteinschätzung erarbeitet, bei der die Abhängigkeiten zwischen Qualitätseigenschaften sowie der Erreichungsgrad der Eigenschaften unter Einsatz der verschiedenen Architekturvarianten und den damit verbundenen Risiken dokumentiert wird.

Phase 4: Berichterstattung

• Dokumentation der Analyseergebnisse und der getroffenen Architekturentscheidungen.
• Den Abschluss von ATAM bildet die in Schritt 9 stattfindende Berichterstattung gegenüber den Stakeholdern.
• Bei der Dokumentation von Architekturentscheidungen ist auf deren Nachvollziehbarkeit zu achten.

• Sicherstellen dass sich das Ergebnis der Entwicklungsarbeiten an die durch die Architekturdefinition aufgestellten Vorgaben hält.
• Sicherstellen, dass die vom Architekturteam getroffenen Entscheidungen auch tatsächlich im Programmcode umgesetzt wurden.
• Eine Technik hierzu ist das sogenannte Architecture Compliance Checking. Die Grundidee dabei ist die Erstellung eines Softwaremodells auf Basis des tatsächlich erstellen Programmcodes der Anwendung, beispielsweise in Form eines UML-Klassendiagramm oder UML-Komponentendiagramms. Dieses Softwaremodell wird mit dem Modell verglichen, mit dem die Architektur vor der Implementierung beschrieben wurde.
• Können Abweichungen zwischen den beiden Modellen identifiziert werden, müssen diese vom Architekten bewertet und je nach Einschät zung vom Entwicklungsteam behoben werden.