Softwarequalitätssicherung

Variante:

• Elemente besitzen die gleiche Spezifikation, aber unterschiedliche Implementierung
• z.B. zur Portierung auf andere Plattformen, Betriebssysteme oder zur Ausweitung auf andere Endgeräte

Revision:

• Elemente wurden zwecks Verbesserung überarbeitet

Version:

• Elemente werden ersetzt (Revision) oder hinzugefügt
  => Produktweiterentwicklung
• in einer Konfiguration ist höchstens ein Element aus jeder Variantenfamilie enthalten, die Variante selbst kann in vielen Konfigurationen enthalten sein

Ein Versionsverwaltungssytem unterstützt die Konfigurationsverwaltung.

Aufgaben:

• Verwaltet alle Artefakte eines Softwareprodukts in einem Reposority
• Implementiert die Infrastruktur für die Koordination der Teamarbeit an dem selben Produkt

1. Bestimmung derBaseline-Konfiguration
   => Erfassen aller Artefakte mit Bezug auf das Änderungsmanagement
2. Änderungsmanagement
   • Änderungsanforderung überprüfen
   • Änderungssteuerung im "internen" Auftragsverfahren
   • Sicherung von Konsistenz und Vollständigkeit
3. Zustandserfassung und Archivierung

Ein Vorgehensmodell ist eine Normierung, Anleitung und Hilfestellung für die Entwicklung und Ergebnisdarstellung einer Software.

Bedeutung für die Qualitätssicherung:

Ein wohl definierter Prozess ist Basis für

• Projektplanung, Projektüberwachung
• Einführung neuer Technologien (Methoden, Werkzeuge)
• Integrations von Qualitätssicherungsaktivitäten

Technische Maßnahmen unterstützen die Aktivitäten der eigentlichen Softwareentwicklung.

Wichtige Maßnahmen sind:

1. Auswahl einer geeigneten Softwareentwicklungsumgebung
2. Werkzeugpool
3. Qualitätssichernde Programmiersprachen
4. Wiederverwendung
5. Vorgabe von Entwicklungsrichtlinien
6. Refactoring, Redesign

Ein Reposority speichert die Systembeschreibung, wobei die systembeschreibende Objekte, Verfahren und Methoden zur Objekttransformation in einer Datenbank (Entwurfsdatenbank) abgelegt werden.

Vorteile:

• es erlaubt mehren parallelen Entwicklern ihre Inhalte bereitzustellen und wechselseitig zu nutzen
• es unterstützt die zeitliche Verfolgung der Entwicklung
• es untersützt häufig eine Versionsverwaltung

Die Unterstützung der Entwicklung erfolgt durch

• automatisierte Elemente- und Qualitäts-Datenverwaltung
• automatisierte Konsistenz- und Vollständigkeitsüberprüfung
• vereinfachte Team-Kommunikation

Es gibt Analyse-, Entwurfs- und Implementierungswerkzeuge.

Die Werkzeuge sollten Fähigkeiten zur Prüfung von Artefakten bzw. zur Generierung von neuen Artekfakten besitzen:

• Syntax- und Semantikprüfung von Modellen und Code
• Konsistenzprüfung abhängiger Dokumente im Reposority
• Modelltransformatoren, Codegeneratoren

Wartungswerkezeuge können zum besseren Verständnis der Software schon während der Entwicklung beitragen und erleichtern somit die Fehleranalyse.

Es gibt Reengineering- und Refactoring-Werkzeuge:

• automatische Dokumentatoren und Traceability-Linksysteme während der Entwicklung
• Programmscanner, Mustersucher, Dateikomparatoren zur Codeanalyse, Codenavigatoren
• Code-Transformationen (Modell-Rückerzeugung)

Refactoring ist die automatische oder manuelle Strukturverbesserung von Quelltexten unter Beibehaltung des beobachtbaren Programmverhaltens. Dabei sollen die Lesbarkeit, Verständlichkeit und Wartbarkeit verbessert werden, um den Aufwand zur Fehleranalyse und funktionale Erweiterungen deutlich zu senken. Insofern kann man Refactoring als eine konstruktive Maßnahme zur Qualitätssicherung bezeichnen.

Ein angemessener Grad an Wiederverwendung dient nicht nur zur Produktivitätssteigerung, sondern es werden auch Komponenten eingesetzt, die mehrfach getestet wurden und eine geringe Fehlerwahrscheinlichkeit haben. Daher ist die Wiederverwendung als eine konstruktive Maßnahme zur Qualitätssicherung zu bezeichnen.

Individualität von Programmierstilen führt in großen SW-Projekten zum Effizienzverlust und erschwert die Verständlichkeit.

=> Fehleranfälligkeit steigt

Die Einführung angemessener Richtlinien ist eine technische Maßnahme zur Qualitätssicherung, die zur Verbesserung der Verständlichkeit und zur Vermeidung von Fehlern beiträgt. Die häufigsten Vorgaben sind:

• Notationskonventionen
• Sprachkonventionen

Notationskonventionen:

Notationskonventionen dienen zur Verbesserung der Verständlichkeit. Es gibt unternehmenseigene und sprachbezogene coding styles (z.B. Java Coding Style, .NET Coding Style). Sie betreffen

• die Auswahl und Schreibweise von Bezeichnern
• Einrückungscharakteristik, Aufbau von Kontrollstrukturen
• begleitende Dokumentationsvorgaben

Sprachkonventionen:

Sprachkonventionen definieren feste Regeln für die Nutzung von Sprachkonstrukten. Das Ziel besteht in der Verbesserung der Verständlichkeit sowie in der Vermeidung von Fehlern durch

• Verwendung einheitlicher Lösungsmuster
• Vermeiden von fehlerträchtigen Sprachkonstrukten

Die Bedürfnispyramide ist ein Stufenmodell, wobei die Bedürfnisse nur schrittweise der Pyramide aufsteigend folgend befriedigt werden können. Das Ziel sollte immer darin bestehen, die höchste Motivation und Kreativität der Mitarbeiter zu entwickeln.

Maßnahmen:

• Feedback, Lob, gerechte Beurteilung
• Betriebsklima, Kommunikation, Führungsstile
• Arbeitsaufgabe, Kontinuität

• Kenntnisse der relevanten Methoden und Werkzeuge
• Zuverlässige und exakte Arbeitsweise
• Erfahrung in der Softwareentwicklung
• Gute Produktkenntnisse

Analytische Maßnahmen zur Qualitätssicherung dienen zur Auffindung von Fehler in Artefakten der Softwareentwicklung.

Statische analytische Maßnahmen:

• das Prüfobjekt wird nicht ausgeführt
• Fehler werden gefunden durch
  • menschliche Begutachtung (Review)
  • formale Prüfung und Beweisen

Dynamische analytische Maßnahmen:

• das Prüfobjekt wird mit Testfällen ausgeführt
• Fehler werden durch Testen und Experimentieren gefunden

Ein Review ist ein mehr oder weniger formal geplanter und strukturierter Analyse- und Bewertungsprozess, in dem die Projektergebnisse einem Team von Gutachtern präsentiert und von diesen kommentiert oder genehmigt werden.

Das Prüfobjekt ist hier ein Artefakt im Softwareentwicklungsprozess (z.B. Spezfikationen, Modelle, Entwürfe, Quellcode).

=> frühzeitiger Einsatz in allen Phasen möglich, um Summationseffekte zu vermeiden

(siehe Abbildung)

Unterstützung von Reviews:

1. Formulare
   • Templates zur Planung, Checklisten
   • Templates für den Managementbericht
2. Analysatorwerkzeuge
   • Dokumente-Filter zur Auswahl der Prüfobjekte und spezieller Prüfbereiche
3. Schulungen
   • zur Planung und Organisation
   • zur Kompetenz in Gespärchs- und Personalführung

Vorteile:

• in allen Phasen mögliche, frühe Fehlererkennung
• Projektteamausbildung durch Verbreitung von Know-How
• Zwang zur Einhaltung von Standards, Richtlinien, Regeln und Dokumentationen
  => Verbesserung der Wartbarkeit

Nachteile:

• Erfolg ist abhängig von Teilnehmer und Gesprächsklima
• Kosten der Reviews betragen ca. 15 % der Projektkosten

Walkthrough:

• vorgegebene Testfälle werden durchgespielt und diskutiert

Inspektion:

• vorgebene Prüfbereiche werden analysiert und mit dem Feinentwurf abgeglichen
• Prüfbereiche:
  • Schnittstellen des Prüfobjekts (z.B. Konsistenz globaler Variablen über alle Module)
  • Ablaufstruktur, Vergleiche (z.B. Schleifen, Operationen)
  • Berechnungen, Datenreferenzen (z.B. Korrektheit von Datentypen)
  • Ein-Ausgabe (z.B. Vollständigkeit, Textfehler in der Ausgabe)
  • Andere Prüfungen (z.B. Kommentare, Einhaltung von Standards u.a.)

1. Review
   • Walkthrough
   • Inspektion
2. Formale Verfahren
   • Korrektheitsbeweis
   • Symbolische Programmausführung

=> Reviews sind begutachtend, Formale Verfahren sind beweisend

Ziel:

• Formale Verfahren versuchen durch Software-Verifikation die Korrektheit eines Programms mit Hilfe mathematische Methoden zu beweisen
• Es wird gegen eine formale Spezifikation geprüft

Voraussetzungen:

• Programm und Spezifikation müssen vor der Beweisführung durch ein formales Modell beschrieben werden

=> Prüfobjekt ist meistens der Quellcode

1. Deduktion
2. Abstrakte Interpretation
3. Symbolische Modellprüfung

Prinzip der mathematischen Beweisführung:

• die Eigenschaften eines Programms werden durch Vor- und Nachbedingungen spezifiziert
• die Gültigkeit der Nachbedingungen wird durch Anwendung spezieller Beweisregeln aus den Vorbedingungen abgeleitet
• Basis der Beweisführung ist ein Logikkalkül (z.B. Aussagenlogik oder Prädikatenlogik)

Ablauf:

• schrittweise wird für jede Operation gezeigt, dass sich die Beschreibung einer Nachbedingung aus einer beschriebenen Vorbedingung ableiten lässt
  => Zusicherungsverfahren

Probleme:

• finden geeigneter Zusicherungen ist schwierig (Experten)
• hohe Kosten für aufwendige Verifikationstätigkeiten
• zusätzliche Werkzeuge sind unumgänglich (z.B. Generator für Verifikationsbedingungen)
• nur partieller Korrektheitsbeweis (z.B. Compilerfehler)

Prinzip der Symbolischen Programmausführung:

• jeder Befehl eines Programms wird als Gleichung aufgefasst; alle Gleichungen repräsentieren alle Zustände des Programms
  => aus der Lösungsmenge des Gleichungssystems lassen sich Aussagen über die Korrektheit des Programms ableiten
• Basis der Beweisführung ist die Interpretation des Programms mit symbolischen Stellvertretern für Daten
  • der Prüfer wählt aus der Spezifikation eine Eingabemenge aus
  • der Interpreter arbeitet das Programm ab und erzeugt eine Menge an symbolischen Ausgaben
  • der Prüfer vergleicht die Ein-Ausgabe-Paare

Vorteile:

• erkannt werden Fehlerzustände, wie array-Überschreitungen, Division durch 0 u.a.
• die Menge der automatisch erzeugten Ergebnis-Paare stellen Pfade dar und können als Testfälle für dynamisches Testen verwendet werden

Nachteile:

• Vom Compiler eingefügte Fehler und Einfluss der Laufzeitumgebung bleiben unberücksichtigt
• bei Gleitkommazahlen in Bedingungen treten in der Praxis Probleme auf

Prinzip der symbolischen Modellprüfung:

• Programm wird durch einen endlichen formalen Zustandsautomaten spezifiziert
• Basis der Verifikation sind Temporallogiken und Zustandsbäume
  • Aussagen über die Sequenzen der Zustände (Reihenfolge von Ereignissen)
  • Aussagen über die Sicherheit von Zuständen
  • Aussagen über die Lebendigkeit (Erreichbarkeit) von Zuständen

Vorteile:

• ausgewählte Eigenschaften des Zustandsautomaten können verifiziert werden und gelten auch für ein daraus resultierendes Programm
• Praktikabilität ist bei schamlen Zustandsräumen sehr gut; aber Anzahl der Zustandsräume kann in der Praxis gigantische Ausmaße einnehmen
• sehr gute Werkzeugunterstützung

Praxisrelevanz:

• die volle Automatisierbarkeit führt bei Systemen bis zu etwa 10^20 Zuständen vermehrt zum Einsatz dieses Verfahrens

Der Einsatz formaler Verifikationstechniken in realen Softwareprojekten hängt von drei Faktoren ab:

1. Ausdrucksstärke
   => Welche Eigenschaften der Software können formal beschrieben werden?
2. Skalierbarkeit
   => Ist die Technik auf sehr große Programme anwendbar?
3. Automatisierbarkeit
   => Ist der Aufwand für die Prüfung vertretbar?

Merkmale:

• Prüfobjekt wird mit Eingabedaten der Stichprobe (Testfälle) ausgeführt
• Geprüft wird das Verhalten gegen die Spezifikation
  => Testen der realen Implementierung

Testprinzipien:

1. Zwei Testansätze verfolgen
   • Test, ob ein Programm tut, was erwartet wird (spezifiziertes Verhalten test)
   • Testeb, ob ein Programm etwas außerhalb der Spezifikation tut, was es nicht soll (Verhaltenstest bei Fehleingaben)
2. Fehlersensibel und ökonomisch Testen
   • systematischer Testfallentwurf
   • Vorgabe von Testzielen und Testendekriterien
3. Personelle Trennung von Entwicklern und Testern

Anforderungen:

Testfälle müssen

1. repräsentativ
2. fehlersensitiv
3. ökonomisch
4. redundanzarm
5. testzielorientiert

sein.

1. Testzielkriterien
   => Können aus der Abdeckung von Testfällen (Vorgabe der Kombination von Anfoderung, strukturelle Abdeckungskriterien etc.) abgeleitet werden.
2. Testendekriterien
   => Können durch eine Vorgabe der zu erwartenden Fehler oder durch Beobachtung der Fehlerrate bestimmt werden

Prüfkriterium: Funktional

1. Funktionaler Test
   => Verhalten durch ausgewählte Ein-Ausgaben testen
2. Zufallstest
   => Verhalten durch zufällig generierte Eingaben testen
3. Error Guessing
   => erfahrungsbasiert fehlersensible Aspekte testen
4. Crash Test
   => Versuch das System abstürzen zu lassen
5. Kompatibilitätstest
   => Verträglichkeitsaspekte testen, Schnittstellen und Formatstandards

Prüfkriterium: Operational

• Installationstests
• Ergonomietests
  => Struktur der Menüführung, Aufbau des Hilfesystems und der Dokumentation
• Sicherheitstest

Prüfkriterium: Temporal

• Laufzeittest
  => Messungen des Zeitverhaltens von Modulen aber auch vollständigen Use Cases
• Lasttest
  => Test der spezifierten Lastprofile (Datenlast, Transaktionslast, Speicherung)
• Stresstest

Der Testprozess besteht aus vier Phasen, die jede Prüfebene abdecken:

1. Modul- bzw. Unittest
2. Integrationstest
3. Systemtest
4. Abnahmetest

=> Der Testprozess verläuft parallel-verzahnt zur Entwicklung (siehe V-Modell) und muss durch das Projektmanagement für alle Testphasen geplant werden

1. Prüfmethode Black-Box-Test:

• Funktionsorientierter Test,
  • Tester hat keine Information zur Struktur des Programms
  • Testfälle werden auf Basis der funktionalen Spezifikation bzw. den Anforderungen abgeleitet
• Vollständiger Test
  • Prüfung aller möglichen Kominationen von erwarteten und unerwarteten Eingaben

=> für alle Prüfebenen im Einsatz

2. Prüfmethode White-Box-Test:

• Strukturorientierter Test
  • die Struktur ist dem Tester bekannt
  • Testfälle werden aus dem Kontrollfluss abgeleitet
• Vollständiger Test
  • Abdeckung aller möglichen Pfade durch ein Programm

=> meistens für Modultest, teilweise auch für System- und Integrationstest im Einsatz

1. Testplanung

• Aktivitäten:
  • Testspezifikationen festlegen
  • Ablauf festlegen
• Produkte:
  • Prüfplan

2. Testvorbereitung:

• Aktivitäten:
  • Testfallentwurf
• Produkte:
  • Testfälle
  • Testabläufe
  • Testgeschirr

3. Testdurchführung:

• Aktivitäten:
  • Testfälle durchführen
• Produkte:
  • Protokoll, Ergebnisse

4. Testauswertung:

• Aktivitäten:
  • Testprotokolle analysieren
• Produkte:
  • Testbericht

5. Testanalyse:

• Produkte:
  • Fehlerprognose

1. Top down Integration:

• beginnend von den Modulen auf der höchsten Entwurfsebene der Aufruf- bzw. Klassenhierarchie folgend
• nicht integrierte Komponenten werden durch Platzhalter ersetzt

Vorteile:

• Steuerungsfunktionalität wird sofort überprüft

Nachteile:

• Hardware-Test erst sehr spät möglich
• Stubs benötigt

2. Bottom Up Integration:

• beginnend von den Modulen auf der niedrigsten Entwurfsebene der Aufruf- bzw. Klassenhierarchie folgend
• nicht integrierte Komponenten werden durch Testtreiber (erzeugt Eingaben) ersetzt

Vorteile:

• frühzeitiger Hardware-Software-Integrationstest möglich
• Fehleingaben

Nachteile:

• Treiber notwendigen
• Vorzeigen eines Produktes erst sehr spät möglich