IUBH Qualitätssicherung im Softwareprozess IQSS

• 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.

• Neben den Artefakten, die in einem Softwareprozess erzeugt werden, können Softwareprozesse bzw. Softwareprozessmodelle ebenfalls hinsichtlich deren Qualität geprüft und verbessert werden.
• Die Grundannahme hinter der Qualitätssicherung und Verbesserung von Softwareprozessen ist, dass es einen Zusammenhang zwischen der Prozessqualität und der Produktqualität gibt.
• Zur Bewertung von Softwareprozessen können verschiedene spezifische Prozessmerkmale herangezogen werden

• Um die Änderungsnotwendigkeit von Softwareprozessen zu erkennen, muss zunächst eine Prozessanalyse durchgeführt werden.
• Das kann recht pragmatisch durch eine Befragung der am Prozess beteiligten Stakeholder erfolgen.
• Eine weitere Möglichkeit ist das strukturierte Bewerten verschiedener Qualitätskriterien, beispielsweise durch Stakeholder des Software prozesses:
  • Verständlichkeit
  • Standardisierung
  • Sichtbarkeit
  • Messbarkeit
  • Unterstützbarkeit
  • Akzeptanz
  • Zuverlässigkeit
  • Stabilität
  • Wartungsfreundlichkeit
  • Schnelligkeit

• Capability Maturity Model Integration (kurz: CMMI) wurde vom amerikanischen Software Engineering Institute (SEI) ein Reifegradmodell für Softwareprozesse entwickelt.
• Das CMMI-Modell ist als Rahmenwerk für Prozessverbesserungen konzipiert. Es enthält dazu unter anderem ein Stufenmodell zur Beurteilung des Reifegrades von Softwareund Managementprozessen.
• Das CMMI-Modell ist sehr umfangreich und umfasst:
  • 22 Prozessgebiete aus dem Software Engineering;
  • Ziele, die spezifisch für jedes Prozessgebiet formuliert werden;
  • Vorgehensweisen, mit denen die Ziele erreicht werden können.
• Der aktuelle Fähigkeitsgrad zu einem Prozess wird dabei auf einer 5-stufigen Skala bestimmt.
• Die Bestimmung des Reifegrades basiert auf der Analyse der aktuellen IST-Prozesse eines Unternehmens.
• CMMI-Grad 1 ist dabei die niedrigste Stufe, Grad 5 entspricht der höchsten Fähigkeitsstufe.

Stufe 1 – Initial: Es gibt keine Prozessdefinition, die Aktivitäten finden ad hoc statt bzw.
werden chaotisch durchgeführt. Der Prozess ist in der Regel nicht wiederholbar.

 Stufe 2 – Geführt: Der Prozess ist wiederholbar. Umfang und Ergebnis der zu erledi-
genden Aktivitäten ist den Teammitgliedern bekannt. Es gibt aber keinen detaillierten
Prozess, der Aktivitäten, Rollen, Ergebnisse und deren Abhängigkeiten explizit definiert.

Stufe 3 – Definiert: Es gibt einen definierten Prozess, in dem Aktivitäten, Rollen und
Ergebnisse verbindlich dokumentiert sind. Der Prozess enthält konkrete Methoden und
Vorgehensweisen zu den einzelnen Software Engineering Aktivitäten.

Stufe 4 – Quantitativ geführt: Die Prozessqualität kann über Messung quantitativer
Prozesseigenschaften festgestellt und gesteuert werden. Über erhobene Kennzahlen zu
Aktivitäten der Prozesse sowie zu den erzeugten Ergebnissen können Havarien identifi-
ziert und entsprechend gegengesteuert werden.

Stufe 5 – Prozessoptimierung: Prozess- und Produktmessungen werden kontinuierlich
erhoben und zur Prozessverbesserung eingesetzt. Je nach Messwert kann der Prozess auf
den aktuellen Bedarf hin angepasst werden.

• Für den Fall, dass bei der Prozessanalyse Verbesserungsvorschläge erarbeitet wurden, müssen diese strukturiert in das Softwareprozessmodell übernommen werden.
• Der Prozess ist ein zyklischer Prozess, das bedeutet, er wird grundsätzlich niemals endgültig sein.
• Die erste Aktivität im Verbesserungsprozess ist das Erkennen von Verbesserungsbedarf in der aktuellen Prozessversion und die Erarbeitung möglicher Verbesserungsvorschläge.
• Im Zuge der Priorisierung werden die Vorschläge auf deren Umsetzbarkeit und den für die Umsetzung erforderlichen weiteren Aktivitäten hin analysiert.
• Die Ergebnisse der Priorisierung sind zum einen ein Änderungsplan, der unter ande rem die Zeitpunkte und Verantwortlichkeiten für die Einführung von Prozessverbesserungen sowie mögliche Abhängigkeiten zwischen einzelnen Verbesserungsschritten dokumentiert.
• Darüber hinaus wird ein Schulungsplan erstellt, auf dessen Grundlage konkrete Schulungsmaßnahmen der von den Änderungen betroffenen Stakeholder durchgeführt werden.
• Neben dem Wissen um die Änderungen im Softwareprozess müssen für die Umsetzung der Prozessänderungen unter Umständen auch neue fachliche Kompetenzen erlangt werden.

• Kann die Qualität nur auf  Basis der Spezifikation  bestimmt  werden   
• Problem  dabei  häufig:    tatsächliche       Erfordernisse       ≠       festgelegte       Erfordernisse      

• Alle organisierten Maßnahmen,  die  der  Verbesserung   der  Qualität  dienen    

• QualitätsPlanung:  Dokumentation  der  Qualitätsanforderungen              
• QualitätsSicherung (kurz: QS):  Sicherstellen, dass festgelegte Qualitätsanforderungen  erfüllt  werden
• QualitätsLenkung: Steuerung und Kontrolle von QS-Aktivitäten       
• QualitätsVerbesserung:  Änderungen  an Produkten- und Prozessen zur Verbesserung des  Qualitätsniveaus      

• Konstruktives Qualitätsmanagement      
• Analytisches  Qualitätsmanagement      

• A priori
• Fehler während Entwicklung vermeiden
• technische Maßnahmen
• organisatorische Maßnahmen 
• zwischenmenschliche Maßnahmen 

• Prüfung des Qualitätsniveaus  von im  SW-Prozess  erstellten Artefakten       
• Systematisches Identifizieren von Fehlern nach der Erstellung
• Statische (analysierende) Verfahren
• Dynamische (testende) Verfahren

• fachliche Anforderungen
• technische Spezifikationen
• Architekturbeschreibungen
• Testfälle

Dynamische Tests sind jedoch nur bei ausführbaren Artefakten möglich. Alle anderen Artefakte werden durch statische Testverfahren geprüft.

• Produkt- und prozessabhängige Qualitätszielbestimmung
• Maximale  konstruktive Qualitätssicherung
• Frühzeitige Fehlerentdeckung und behebung      
• Entwicklungsbegleitende,  integrierte Qualitätssicherung

• Festlegen  von konkreten Qualitätszielen als Richtlinien zur Gestaltung von Qualität 
• Unterscheiden sich von Projekt  zu Projekt      

• Aussagen über die Qualität eines Systems oder Prozesses anhand von Kennzahlen
• Die tatsächlich gemessenen Istwerte werden dazu mit den Sollwerten verglichen.

• Alle  sinnvollen  Maßnahmen  zur Vermeidung von Fehlern sollten ergriffen werden     
• Hohe Produktqualität durch hohe Prozessqualität    

• Früh  erkannte Fehler sind einfacher zu beseitigen als später erkannte      
• QS-Aktivitäten so früh wie möglich im Prozess beginnen      

• QS-Aktivitäten  begleitend  zur Entwicklung, nicht erst  am Ende      

• Überprüfung ohne Abhängigkeiten von individuellen Interessen 
• Soll Programmcode von dem Team getestet werden, das den Code erstellt, wird häufig die für die Qualitätssicherung vorgesehene Zeit nicht in dem Maße für QS genutzt, wie es erforderlich ist, sondern es werden eher weitere Funktionen implementiert.
• Wird die QS allerdings vollständig aus der Verantwortung des Entwicklungsteams genommen, lässt sich häufig eine nachlassende Sorgfalt bei der Entwicklung beobachten, denn für das Finden von Fehlern sind ja „die anderen“ zuständig.

• Testen zeigt die Anwesenheit von Fehlern
• Vollständiges  Testen ist  nicht  möglich
• Testen ist abhängig vom Umfeld
• Trugschluss:  Keine Fehler = brauchbares System   

• Ausführliches Testen reduziert die Wahrscheinlichkeit von unentdeckten Fehlern       
• Fehlerfreiheit kann jedoch nicht  nachgewiesen werden      

• Praktische Durchführung von vollständigen Tests ist in der Regel nicht möglich     
• Sofwaretests immer Stichproben       
• Sorgfältige und bewusste Erstellung von Tespällen erforderlich      

• Großteil  der Fehler häufig nur in wenigen Komponenten

• QS-Aktivitäten werden spezifisch auf  Grundlage der Anforderungen an das System bestimmt  und umgesetzt