IUBH Qualitätssicherung im Softwareprozess IQSS

• 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      

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

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

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

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

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

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

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

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

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

• Konstruktives Qualitätsmanagement      
• Analytisches  Qualitätsmanagement      

• 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      

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

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

Softwarequalität ist die Gesamtheit der Merkmale und Merkmalswerte eines Softwareprodukts, die sich auf dessen Eignung beziehen, festgelegte Erfordernisse zu erfüllen.

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

• 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

• 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

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

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.

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

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

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

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

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

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

• 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?“

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

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