Qualitätsmanagement in der Software-Entwicklung Prof. Dr. Thomas Kudraß HTWK Leipzig Seminar PC-Ware AG Leipzig, 26.01.2002

Qualitätsmanagement in der Software-Entwicklung

Prof. Dr. Thomas Kudraß

HTWK Leipzig

Seminar PC-Ware AG Leipzig, 26.01.2002

© Prof. T. Kudraß, HTWK Leipzig

MotivationKleine Bugs Große GAUs

Ein paar falsche Zahlen oder Zeilen und schon passiert‘s:

– Explosion Ariane 5 (1996)– Verlorengegangene Venus-Sonde Mariner1 (1962)– Koffer-Debakel am Flughafen Denver – Bank-Bugs

Neues Computer System bei US Fed (Fehlbuchungen 4 Mrd $) Kundendaten frei im Internet bei Credit Suisse (Image-Schaden) Wall-Street-Crash (1987) Spendable Geldautomaten bei Postbank-Service Card (2002)


Agenda

EINHEIT 1– Einführung Qualitätsmanagement

EINHEIT 2– Qualitätssicherung im Software-Entwicklungsprozess (V-Modell)– Beispiel

EINHEIT 3– Qualitätssicherung in Analyse & Design

A: Qualität von Business-SpezifikationenB: Manuelle Prüfmethoden (Reviews) mit Beispiel

EINHEIT 4– Qualitätssicherung in der Programmierung: Test-Verfahren– Arten von Tests


EINHEIT 1:Einführung Qualitätsmanagement

Qualitätsbegriff Qualitätsmerkmale von Softwareprodukten Qualitätsmodelle Maßnahmen von Qualitätssicherung und

Qualitätsmanagement Prinzipien der Software-Qualitätssicherung Organisatorische Einbettung der QS


Was ist Qualität?Fünf verschiedene Ansätze

Transzendenter Ansatz Produktbezogener Ansatz Benutzerbezogener Ansatz Prozessbezogener Ansatz Kosten/Nutzen-bezogener Ansatz


Produktbezogener Ansatz

Qualität = messbare, genau spezifizierbare Größe, beschreibt das Produkt

Keine Berücksichtigung von subjektiven Wahrnehmungen und Beobachtungen

Berücksichtigt nur das Endprodukt – nicht den Kunden!

Ermöglicht Ranking von Produkten gleicher Kategorie


Benutzerbezogener Ansatz

Qualität durch den Benutzer festgelegt (fitness for use)

Unterschiedliche Wünsche und Bedürfnisse verschiedener Benutzer

Problem für Hersteller– Vage Vorstellungen der Anwender– Bedürfnisse der Benutzer rechtzeitig erkennen


Prozessbezogener Ansatz

Qualität des Produkts hängt ab vom richtigen Prozess der Erstellung

Spezifikation und Kontrolle des Erstellungs-prozesses

Ständige Anpassung des Prozess an neue Kundenbedürfnisse


Definition Qualität

Qualität [DIN 55350, Teil 11]Qualität ist die Gesamtheit von Eigenschaften und Merkmalen eines Produkts oder einer Tätigkeit, die sich auf deren Eignung zur Erfüllung gegebener Erfordernisse bezieht“

Software-Qualität [DIN ISO 9126] ist die Gesamtheit der Merkmale und Merkmals-werte eines SW-Produkts, die sich auf dessen Eignung beziehen, festgelegte oder vorausgesetzte Erfordernisse zu erfüllen


Aufbau von FCM-Qualitätsmodellen

Software-Qualität

Q-Merkmal 1(factor 1)

Q-Merkmal 2(factor 2)

Q-Merkmal n(factor n)...

Q-Teilmerkmal 1(criterion 1)



Q-Teilmerkmal n(criterion n)

Q-Indikatoren(metrics)


Qualitätsmerkmale für Software-Produkte

Funktionalität Zuverlässigkeit Benutzbarkeit Effizienz Änderbarkeit Übertragbarkeit

Quelle: DIN-Norm ISO 9126


Funktionalität

Richtigkeit– Liefert richtige oder vereinbarte Ergebnisse

Angemessenheit– Eignung der Funktionen für spezifizierte Aufgaben

Interoperabilität– Zusammenwirken mit vorgegebenen Systemen

Ordnungsmäßigkeit– Erfüllung von Normen, Vereinbarungen, gesetzl. Vorschriften

Sicherheit– Unberechtigten Zugriff auf Programme und Daten verhindern


Zuverlässigkeit

Reife– Geringe Versagenshäufigkeit durch Fehlerzustände

Fehlertoleranz– Bewahrt Leistungsniveau bei Fehlern oder Nichteinhaltung

Schnittstelle

Wiederherstellbarkeit– Wiederherstellung des Leistungsniveaus bei einem Versagen– Wiedergewinnung der betroffenen Daten– Erforderliche Zeit und Aufwand berücksichtigen


Benutzbarkeit

Verständlichkeit– Aufwand für den Benutzer, Konzept und

Anwendung zu verstehen

Erlernbarkeit– Aufwand für den Benutzer, die Anwendung zu

erlernen (z.B. Bedienung, Ein-/Ausgabe)

Bedienbarkeit


Effizienz

Zeitverhalten– Antwort- und Verarbeitungszeiten sowie Durchsatz

bei der Funktionsausführung

Verbrauchsverhalten– Anzahl und Dauer der benötigten Betriebsmittel für

die Funktionen


Änderbarkeit

Analysierbarkeit– Aufwand zur Fehlerdiagnose oder zur Bestimmung

änderungsbedürftiger Teile zu bestimmen Modifizierbarkeit

– Aufwand für Verbesserung, Fehlerbeseitigung, Anpassung an Umgebungsänderungen

Stabilität– Wahrscheinlichkeit für unerwartete Wirkungen bei Änderungen

Prüfbarkeit– Aufwand zur Prüfung der geänderten Software


Übertragbarkeit (Portierbarkeit)

Anpassbarkeit– Anpassung der Software an verschiedene, festgelegte

Umgebungen (organisatorisch, Hardware, Software) Installierbarkeit

– Aufwand zum Installieren der SW in einer festgelegten Umgebung Konformität

– Erfüllung von Normen oder Vereinbarungen zur Übertrag-barkeit durch die Software

Austauschbarkeit– Verwendung der Software anstelle einer anderen in deren

Umgebung


FURPS Qualitätsmodell

Entwickelt von HP 1985

Merkmale (stark kundenorientiert definiert) Functionality Usability Reliability Performance Supportability


GQM-Ansatz: Goal-Question-MetricVorgehensmodell

1. Definiere die Auswertungsziele für alle zu erfüllenden Qualitätsmerkmale

2. Leite alle Fragestellungen ab, die zu einer Quantifizierung dieser Ziele führen können

3. Leite alle Maße ab, die Informationen zur Beantwortung der Fragestellungen beitragen

4. Entwerfe einen Mechanismus zur möglichst genauen Erfassung der Messwerte

5. Validiere die Messwerte bezüglich aller primitiven Maße

6. Interpretiere die Messergebnisse zur Gesamtbewertung der Qualitätsziele


Beispiel für ein Software-Bewertungsmodell

Z1

F2

M1

Z2 Z3 Z4

F1 F3 F4 F5 F6

M2 M3 M4 M5

Auswertungsziele(goals)

Abgeleitete Frage-stellungen(questions)

Primitive Maße(metrics)


G: Muster zur Formulierung von Zielen im GQM-Ansatz

Zweck der Studie– Prozess, Produkt, Modell, Maß

Blickwinkel der Studie– Entwickler, Manager, SW-QS, Auftraggeber,

Firmenleitung

Umgebung der Studie– Aspekte des Prozesses, Personal, Anwendung,

Methoden, Werkzeuge u.a. Faktoren


Q1: Auswertungsfragen zur Charakterisierung von Prozessen

Qualität der Durchführung Anwendungsbereich

– Beurteile Objekte des Prozesses sowie Kenntnis des Personals darüber

Aufwand der Durchführung Ergebnis der Durchführung Rückkopplung von der Durchführung


Q2: Auswertungsfragen zur Charakterisierung von Produkten

Definition des Produkts– Physische Eigenschaften, z.B. Umfang, Komplexität,

Programmiersprache– Kosten, z.B. Zeitaufwand, Entwicklungsphasen, Aktivitäten– Änderungen, z.B. Fehlerursachen, Fehler, Fehlverhalten– Umfeld, z.B. zu erwartendes Benutzerprofil

Bewertung des Produkts– Relativ zu einem bestimmten Qualitätsmerkmal,

z.B. Zuverlässigkeit, Korrektheit, Zufriedenheit der Benutzer


Erweitertes GQM-Bewertungsmodell

Wir untersuchen Produkte und ...

Qualitätsbaum-Quellcode

Testbarkeit Wartbarkeit

Strukturiertheit

Innere Struktur

Größe des Programms?

Lines of Codes

Qualitätsbaum-AnalyseWeitere Qualitätsbäume

...

......

...

...

Ziel(goal)

Qualitätsbäumefür jedesZwischenprodukt

Fragen(questions)

Kennzahlen(metrics)


Qualitätsbaum “Wartbarkeit“

SWS ist leicht wartbarWB

SWS höchstmöglich standardisiert WB1

SWS leicht verständlich WB2

SWS gut änderbar WB3

SWS gut testbar TB

Hält vereinbarte Standards voll-ständig ein WB11

Ist möglichst ein-heitlich realisiert

WB12

Ist eindeutiginterpretierbar

WB21

SWS leicht verständlich WB22

Ist gut dokumentiert WB23

Ist gut strukturiertWB31

Techniken zur Er-stellung des SWS angemessen

WB32

Umfang des SWS entspricht optimal der Aufgabe WB33

Jede Kompo-nente in sich gut strukturiert WB311

Beziehungen zwischen den Komponenten einfach WB312


Qualitätszielbestimmung

Qualitätsstufen– Wertebereich auf einer Skala zur Klassifizierung von

Software entspr. Qualitätsanforderungen [ISO9126]

Messwert

Maßskala Qualitätsstufen

Sehr gut

Gut

Normal

Schlecht

annehmbar

nicht annehmbar


Qualitätsanforderungen

Ergeben sich aus den Qualitätszielen– Welche Qualitätsmerkmale relevant?– Welche Qualitätsstufe muss erreicht werden?

Auswirkungen auf den SW-Entwicklungsprozess– Produktorientierte Anforderungen

Einfluss auf: Methoden, Werkzeuge, Richtlinien, Checklisten im Entwicklungsprozess

– Prozessorientierte Anforderungen Änderung des SW-Entwicklungsprozesses


Qualitätsmanagement vs. Qualitätssicherung

Qualitätsmanagement– Alle managementbezogenen Tätigkeiten, die Qualitätspolitik,

Ziele und Verantwortungen im Rahmen eines QM-Systems festlegen

– Mittel: Q-Planung, Q-Lenkung, Q-Sicherung, Q-Prüfung

Qualitätssicherung– Alle technikorientierten Aktivitäten innerhalb des QM-Systems

zur Erfüllung der Qualitätsanforderungen– Analytische Maßnahmen in der SW-Entwicklung


Produktorientiertes Qualitätsmanagement

Inhalt– Überprüfung von SW-Produkten und Zwischen-ergebnissen

auf festgelegte Qualitätsmerkmale– Sind Gegenstand der Zertifizierung

Maßnahmen (Beispiele)– Templates für Pflichtenheft (Richtlinie)– Einsatz von Strukturierter Analyse (SA) (Methode)– Programmierrichtlinien

Kein GOTO Überprüfung aller Eingabegrößen (defensives Programmieren) Wiederverwendung von SW-Bausteinen bei OO Programmierung


Prozessorientiertes Qualitätsmanagement

Inhalt– Bezieht sich auf den Erstellungsprozess der Software– Permanente Anpassung an dynamische

Qualitätsanforderungen

Maßnahmen (Beispiele)– Standardisierter Entwicklungsprozess

Welche Teilprodukte (deliverables) wann und von wem?

– Einsatz von Konfigurationsmanagement– Festlegung eines Vorgehensmodells


Konstruktives Qualitätsmanagement

Maßnahmen, die a priori bestimmte Qualitäts-eigenschaften von Produkt / Prozess gewährleisten

Konstruktives Qualitätsmanagement

Technische Maßnahmen

OrganisatorischeMaßnahmen

Methoden Sprachen Werkzeuge Richtlinien Standards Checklisten


Analytisches Qualitätsmanagement

Diagnostische Maßnahmen zur Prüfung und Bewertung der Qualität der Prüfobjekte

Messen vorhandenes Qualitätsniveau, Ausmaß und Ort der Defekte

Klassifikation– Bezug der Prüfung (Produkt- oder Prozessprüfung)– Automatisierungsgrad (manuell und/oder Einsatz von

Software-Werkzeugen)– Nachvollziehbarkeit der Prüfung (Selbstprüfung oder

Nachweisführung)– Einsatzbereich der Prüfung: Definitions-,Entwurfs-,Imple


Maßnahmen zum analytischen Qualitätsmanagement

Analysierende Verfahren

Programmverifikation

Statische Analyse

Animation

Dynamischer Test

Testende Verfahren

Review

Inspektion

Durchsprache

Walkthrough

Audit

Symbolischer Test

Simulation

Schreibtischtest

= manuell


Aktivitäten des Qualitätsmanagement

Qualitätsplanung Qualitätslenkung und –sicherung Qualitätsprüfung


Qualitätsplanung

Festlegung der Qualitätsanforderungen an Produkt und Prozess

– Auswahl und Festlegung eines Qualitätsmodells– Festlegung von Soll-Qualitätsstufen für Qualitätsindikatoren

z.B. Zuverlässigkeit – Anzahl Fehler pro Monat – 0.01– Festlegung von Prioritäten bei gegenläufigen Anforderungen

Festlegung von allgemeinen und produkt-spezifischen Q-Lenkungs- und –Sicherungs-Maßnahmen

– z.B. Messpunkte im Entwicklungsprozess zur Vorhersage der Ziele, Auswahl von Methoden und Werkzeugen zur Erfassung der Messwerte


Qualitätslenkung

Umsetzung der Qualitätsplanung Steuert, überwacht und korrigiert den

Entwicklungsprozess, um Q-Anforderungen zu erfüllen

Überwacht Qualitätsprüfung nach Plan Auswertung der Ergebnisse durch Vergleich

Soll-Ist Eng verknüpft mit SW-Management


Qualitätsprüfung

Führt die im Rahmen der Q-Planung festgelegten Maßnahmen durch zur Bestimmung Ist

Überwacht Umsetzung der konstruktiven Maßnahmen Aktivitäten

– Erfassung von Messdaten über Werkzeuge, Formblätter / Interviews

– Test (zur Erfassung dynamischer Produktmerkmale)– Inspektionen, Reviews, Walkthroughs– Mängel- und Fehleranalysen auf Basis von Problemberichten


Qualitätssicherungsplan

Was muss gesichert werden?– Identifizierung der relevanten Q-Merkmale und ihre

Quantifizierung in Form von Metriken Wann muss gesichert werden?

– Festlegung der Zeitpunkte für Datenerfassung während Entwicklungsprozess

Wie muss gesichert werden?– Auswahl der Techniken und Methoden

Von wem muss gesichert werden?– Festlegung von Verantwortlichkeiten (Rollen)


Prinzipien der Software-Qualitätssicherung

Prinzip der produkt- und prozessabhängigen Qualitätszielbestimmung

Prinzip der quantitativen Qualitätssicherung Prinzip der maximalen konstruktiven

Qualitätssicherung Prinzip der frühzeitigen Fehlerentdeckung und

–behebung Prinzip der entwicklungsbegleitenden, integrierten

Qualitätssicherung Prinzip der unabhängigen Qualitätssicherung


Produkt- und prozessabhängige Qualitätszielbestimmung

Qualitätsziele explizit und transparent vor Entwicklungsbeginn festlegen– Vorteile für Auftraggeber (Kostentransparenz,

Festlegung der Anforderungen)– Vorteile für Lieferant

Maßnahmen für Entwicklungsprozess und Q-Prüfung Wahl geeigneter Methoden und Werkzeuge

– Planungs- und Kalkulationssicherheit für beide


Quantitative Qualitätssicherung

Messen ist zwar schwer, aber nützlich für ...– besseres Verständnis unterschiedlicher Q-Merkmale

(deskriptive Modelle)– bessere Planung und Sicherung von Q-Merkmalen

(präskriptive Modelle)– Verbesserung von Entwicklungsansätze

Methoden und Werkzeuge zur Planung und Durch-führung der Datenerfassung sowie zur statistischen Auswertung / Präsentation von Messdaten

Metriken sind ziel- und kontextabhängig!


Maximale konstruktive Qualitätssicherung

“Vorbeugen ist besser als heilen!“ Viel konstruktiv – wenig analytisch! Beispiele:

– Vollständige Zweigüberdeckung, wenn Verzweigungslogik nicht zu komplex

– Explizite Vereinbarung aller Variablen mit Typfestlegung Vorteile:

– Direkte Verbesserung der Produktqualität– Reduziert und ermöglicht analytische Maßnahmen– Vermeidung von Fehlern


Frühzeitige Fehlerentdeckung und -behebung

Fehler– Jede Abweichung von den Anforderungen des Auftraggebers– Jede Inkonsistenz in den Anforderungen

Jede Verzögerung bei Entdeckung exponentieller Kostenanstieg

Ziel: QM-Maßnahmen (konstruktiv / analytisch) verstärkt am Beginn der SW-Entwicklung einsetzen

Vermeidung von Summationseffekten in nach-folgenden Phasen


Summation von Fehlern und Mängeln

Fehlerhafte Anforderungen

Korrekte Anforderungen

Spezifikations- fehler

Korrekte Spezifikation

Entwurfs- fehler

KorrekterEntwurf

Programm-fehler

Korrektes Programm

Korrigierte Fehler

Korrektes Verhalten

Anforderungs-definition

System-spezifikation

Entwurf

Realisierung

Test undIntegration

Induzierte Fehler aus Anforderungen

Induzierte Fehler aus Anforderungen | Spezifikation

Induzierte Fehler ausAnforderungen | Spezifikation | Entwurf

Bekannte un-korrigierte Fehler

Unbekannte Fehler


Vorzeitige FehlerentdeckungVorteile

Vermeidung von Fehlern in späteren Phasen Reduzierung von Kosten

– 55% aller Fehler entstehen in der Anforderungs- und Entwurfsphase [IEEE Software, Jan.1985]

– 35% dieser Fehler bei Abnahme / im Betrieb gefunden – Fehlerbeseitigung 100fach höher als in der Definitionsphase

Mit höherer Wahrscheinlichkeit Fehlerkorrektur richtig Reduzierung der Fehlerfortpflanzung

Fehler besser vermeiden – oder zumindest frühzeitig erkennen!


Entwicklungsbegleitende, integrierte Qualitätssicherung

Q-Sicherung begleitet gesamte SW-Entwicklung in jeder Phase

Vorteile:– Einbettung der Q-Sicherung in das organisatorische Ablauf-

modell der SW-Entwicklung– QS findet dann statt, wenn sie angebracht ist– QS natürlicher Teil der Software-Erstellung– Teilprodukt erst dann in der nächster Phase verfügbar, wenn

eine bestimmte Qualität gesichert ist– Qualitätsniveau zu jedem Zeitpunkt sichtbar– Realistische Beurteilung des Entwicklungsfortschritts


Entwicklungsbegleitende, integrierte Qualitätssicherung

Produktmodell

Definieren

Entwerfen

Produktarchitektur

Implementieren

Produkt

Änderungen

Prüfen und freigeben


Änderungen


Änderungen

Software-Entwicklung

Produktmodell

Definieren

Entwerfen

Produktarchitektur

Implementieren

Produkt

Produktmodell

Definieren

Entwerfen

Produktarchitektur

Implementieren

Produkt

Software-Entwicklung

QS-Plan


Unabhängige Qualitätssicherung

„testing is a destructive process, even a sadistic process,...“ [Myers, 1979]

2 Alternativen– QS organisatorisch unabhängig von der Entwicklung– QS ist Teil der Entwicklung

Vor- und Nachteile beider Ansätze


Alternative 1:QS unabhängig von Entwicklung

Vorteile– Entwicklung kann keinen Druck auf die QS ausüben– QS ist neutral– Klare Budgetaufteilung möglich– Bedeutung der QS (kein “Anhängsel“ der

Entwicklung) Nachteile

– Gefahr der Isolierung von der Entwicklung– gleichmäßige Personalauslastung schwierig


Alternative 2:QS Teil der Entwicklung

Vorteile– Personal kann flexibler eingesetzt werden– QS nicht im Abseits, sondern bekommt alles mit– Gemeinsame Teamarbeit und vertrauensvollere

Zusammenarbeit leichter möglich Nachteile

– Entwicklungs-Management kann Druck auf die QS ausüben

– Mögliche Umverteilung der Budgetmittel zugunsten der Entwicklung


Personal-Alternativen

Personal für die Qualitätssicherung eingestellt und nur in der QS tätig

Jeder Mitarbeiter rotiert in festgelegten Abständen zwischen QS und Entwicklung

Jeder Mitarbeiter arbeitet sowohl in Entwicklung als auch in der QS bei anderen Entwicklungen


Alternative 1:Nur in QS tätig

Vorteile– Mitarbeiter mit entsprechender Neigung und

Ausbildung einstellen– Hoher Spezialisierungsgrad möglich

Nachteile– Mitarbeiter entfernen sich von Anwendungs-

problemen– Mitarbeiter haben keine Erfahrung mit der

Entwicklung von Software


Alternative 2:Rotation

Vorteile– Jeder Mitarbeiter sieht auch die Probleme der anderen Seite– Systematischer Wissenstransfer sichergestellt– Vermeidet schlechtes Image der QS (Motto: “Alle, die nicht gut

entwickeln, kommen in die QS“)

Nachteile– Mitarbeiten müssen auch Tätigkeiten ausführen, zu denen sie

keine Lust haben– Mitarbeiter u.U, überfordert, beide Tätigkeiten professionell

durchzuführen wegen der verschiedenen Spezialkenntnisse


Alternative 3:QS & Entwicklung parallel

Vorteile– Flexibler Personaleinsatz möglich– Kein Overhead für die Qualitätssicherung

Nachteile– Vermischung von Entwicklungsarbeit und QS

keine Arbeit wird richtig gemacht– Dauernder Wechsel zwischen verschiedenen

Tätigkeiten


Aufteilung der Verantwortung zwischen Entwicklung und QS

QS zuständig für Überprüfung– Entwickler konzentriert sich auf konstruktive Aspekte– Sinkende Sorgfalt bei Entwicklung („Lass die anderen meine

Fehler finden!“) Entwicklung für definierte Qualität zuständig

– Weitere Überprüfung durch die QS erst bei best. Qualitätsgrad– Vorteile:

Klar definierte Verantwortlichkeiten Entwickler muss sein eigenes Produkt überprüfen Höhere Eigenverantwortlichkeit der Entwickler

– Nachteil Erfordert messbare Qualitätsstufen


Quantitative Qualitätssicherung

Entlastet QS, da Maße die Überprüfung der Q-Maßnahmen erleichtern– z.B. Zweigüberdeckung von 80% in Programmen– Alle Analyseberichte fehlerfrei (von Tool erzeugt)

Zusätzliche Aktivitäten– Sammlung von Daten (Maßen)– Validierung dieser Daten– Einrichten einer quantitativ orientierten Entwickungs-

datenbank


Eigenständige Organisationseinheit “Qualitätssicherung“

Teil der Entwicklung oder eigenständige organisatorische Einheit

Kritische Mitarbeiterzahl (mind. 15% der Entwicklungs-Einheit)

Vorteile– Objektive, unabhängige Qualitätssicherung– Heilsame Wirkung auf die Entwicklung, wenn

eigenes Produkt noch von der QS überprüft wird– Qualitätsvergleiche über mehrere Produkte möglich


EINHEIT 2:Qualität in der SW-Entwicklung

V-Modell Submodell QS im V-Modell:

Aktivitäten und Produkte Beispiel-Entwicklungsprozess


V-Modell

AbnahmetestAnforderungs-definition

Grobentwurf

Feinentwurf

Modulimple- mentation

Systemtest

Integrationstest

Modultest

Validation

Verifikation

Anwendungsszenarien

Testfälle

Testfälle

Testfälle


V-Modell (Forts.)

Erweiterung des Wasserfallmodells: Integration der Qualitätssicherung

Bestandteile– Vorgehensmodell “Was ist zu tun?“– die Methodenzuordnung “Wie ist etwas zu tun?“– funktionale Werkzeuganforderungen “Womit ist etwas zu tun?“

Entwicklung durch BMVg, BMI– Anwendung auch in der Industrie– regelmäßige Weiterentwicklung

Öffentlich zugänglich


V-Modell Einführung

Die drei Ebenen der Standardisierung

Werkzeug- anforderungen

Methoden

Vorgehensweise

Konfigurationsmanagement

Qualitätssicherung

Systemerstellung

Projektmanagement


Submodelle im V-Modell

Software-Erstellung (SE)erstellt das System bzw. die Software.

Qualitätssicherung (QS)

gibt Qualitätsanforderungen, Prüffälle und -kriterien vor und untersucht die Produkte und die Einhaltung der Standards

Konfigurationsmanagement (KM)verwaltet die erzeugten Produkte

Projektmanagement (PM)

plant, kontrolliert und informiert die Submodelle SE, QS und KM


Zusammenwirken der 4 Submodelle

Konfigurations- struktur

Projekt planen und kontrollieren

PM

SE

QS KM

Plandaten Istdaten SEU

SEU

QS- Ergebnis

Ist- daten

QS-Anforderung

Produkt

Produkt entwickeln

QS- Anforderungen

vorgeben

Produkte prüfen

Produkte/ Rechte

verwalten

Produktstruktur planen

Plan- daten

SEU SEU Plan- daten

Plan- daten

Ist- daten

Ist- daten

Produkt

Rechte

Voraussetzungen schaffen und Softwareentwicklungs-

umgebung (SEU) bereitstellen


Arbeitsteilung zwischen SE und QSim V-Modell


Analytische Maßnahmen im V-Modell

Prüfung

Selbstprüfung Verifikation

Prozessprüfung Produktprüfung

Validation


Rollenverteilung bei der Durchführung von Prüfaktivitäten

Prüfaktivität Produktersteller QS-Verant-wortlicher

Prüfer AG/Anwender

Selbstprüfung v

Prozessprüfung v m

Produktprüfung b m v

Validation m v m

v verantwortlich b beratend m mitwirkend


Selbstprüfungen

Art der Vorgaben für den Entwickler

Verpflichtungen seitens des Entwicklers

Keine Vorgaben (außer generell Nachvollziehbarkeit)

Dokumentation in freier Form

Statistische Vorgaben (z.B. Mindestabdeckung) zur Durchführung der Prüfung

Dokumentation muss den Vorgaben entsprechen

Genaue Spezifikation der Vorbereitung, Durchführung und Auswertung der Prüfung

Prüfprotokoll gemäß Submodell QS


Formelle PrüfungBeteiligung QS-Verantwortlicher

B1– QS-Verantw. führt formelle Prüfung selbst durch– QS-Verantw. entscheidet über Annahme (“akzeptiert“) oder

Ablehnung (“in Bearb.“) B2

– QS-Verantw. begleitet die Durchführung der Prüfung– QS-Verantw. entscheidet über Annahme der Prüfung– Durchführung der Prüfung durch Entwicklungsteam-Mitglied

B3– QS-Verantw. entscheidet allein aufgrund der Prüfdokumentation– Durchführung der Prüfung durch Entwicklungsteam-Mitglied


Kritikalität = Bedeutung von Fehlverhalten

Kritikalität ... bei administrativen Administrationssystemen

... bei technischen Systemen

hoch macht sensitive Daten für unberechtigte Personen zugänglich, verhindert administrative Vorgänge (z.B. Gehaltsauszahlung), führt zu Fehlentscheidungen infolge fehlerhafter Daten

kann zum Verlust von Menschenleben führen

mittel kann die Gesundheit von Menschen gefährden oder zur Zerstörung von Sachgütern führen

niedrig verhindert Zugang zu Informationen, die regelmäßig benötigt werden

kann zur Beschädigung von Sachgütern führen, ohne jedoch Menschen zu gefährden

keine beeinträchtigt die zugesicherten Eigenschaften nicht wesentlich

gefährdet weder Gesundheit noch Sachgüter


Submodell QS

Aktivitäten– Planungsaktivitäten (QS1, QS2)– Prüfaktivitäten (QS3, QS4)– Lenkungsaktivitäten (QS5)

Produkte– QS-Plan– Prüfplan– Prüfspezifikation– Prüfprozedur– Prüfprotokoll


Submodell QS im Überblick

QS 1 QS-InitialisierungQS 1.1 QS-Plan erstellenQS 1.2 Prüfplan erstellen QS-Plan

QS 2 PrüfungsvorbereitungQS 2.1 Prüfmethoden und –kriterien festlegenQS 2.2 Prüfumgebung definieren PrüfplanQS 2.3 Prüffälle festlegen PrüfspezifikationQS 2.4 Prüfprozedur erstellen Prüfprozedur

QS 3 Prozessprüfung von Aktivitäten Prüfprozedur

QS 4 ProduktprüfungQS 4.1 Prüfbarkeit feststellenQS 4.2 Produkt inhaltlich prüfen Prüfprotokoll

QS 5 Berichtswesen Berichtsdokumente


QS 1: QS-Initialisierung


Inhalte eines QS-Plans im V-Modell

2. Qualitätsziele und Risiken im Projekt2.1 Qualitätsziele für Produkte und Prozesse2.2 Qualitätsrisiken2.3 Maßnahmen aufgrund der Qualitätsziele und -risiken

3. QS-Maßnahmen gemäß Kritikalität und IT-Sicherheit3.1 Verwendete Richtlinien oder Normen3.2 Einstufungsbedingte QS-Maßnahmen

4. Entwicklungsbegleitende Qualitätssicherung4.1 Zu prüfende Produkte4.2 Zu prüfende Aktivitäten

5. Spezifische Kontrollmaßnahmen5.1 Eingangskontrolle von Fertigprodukten5.2 Kontrolle von Unterauftragnehmern5.3 Ausgangskontrolle der Softwarebausteine5.4 Änderungskontrolle5.5 Kontrolle von Bearbeitungskompetenzen5.6 Kontrolle des Konfigurationsmanagements


Prüfplan im V-Modell

Prüfgegenstände Aufgaben und Verantwortlichkeiten bei den Prüfungen Zeitliche Planung Erforderliche Ressourcen

Welche Produkte und Aktivitäten in welchem Zustand werden wann, von wem und womit geprüft?


QS 2: Prüfungsvorbereitung


Inhalte einer Prüfspezifikation im V-Modell

2. Anforderungen2.1 Einstufung der Funktionseinheit hinsichtlich Kritikalität und IT-Sicherheit2.2 Prüfanforderungen

3. Methoden der Prüfung

4. Prüfkriterien4.1 Abdeckungsgrad 4.2 Checklisten4.3 Endekriterien

5. Prüffälle5.1 Prüffallbeschreibung5.2 Abdeckungsmatrix5.2.1 Architektur-Elemente und Schnittstellen5.2.2 Fachliche und technische Anforderungen


Prüfprozedur

Arbeitsseinleitung Für jeden Prüfungsgegenstand festgelegt Inhalt

– Genaue Anweisungen für jede einzelne Prüfung– Definiert einzelne Schritte der Prüfung– Festlegung der zu erwartenden Prüfergebnisse– Vorschriften zur Prüfungsvor- und -nachbereitung


QS 3: Prozessprüfung

Prüfung von Aktivitäten auf Einhaltung vorgegebener Vorgehensweisen und Projektstandards

Umfasst: SE, QS, KM, PM (besonders Konfigurationsmanagement)

Bei Prüfung von QS-Aktivitäten– Rollenverteilung absichern!


QS 4: Produktprüfung


QS 4.1: Prüfbarkeit feststellen

Checkliste für Produkt– Ist das Produkt gut verstehbar und übersichtlich

gestaltet?– Sind alle Produkte, aus denen das zu prüfende

Produkt hervorging, verfügbar?– Sind die Anforderungen, gegen die das Produkt

geprüft werden soll,alle dokumentiert, klar und verständlich?

– Wurden die anzuwendenden Richtlinien und Normen eingehalten?


QS 4.2: Produkt inhaltlich prüfen

Prüfprotokoll Pro Prüfgegenstand Pro Prüfung Aufzeichnungen über den Verlauf der Prüfung Gegenüberstellung von Soll- und Ist-Ergebnis


QS 5: QS-Berichtswesen

Auswertung der Prüfprotokolle– Anzahl der Probleme– Schwere der Probleme– Klassifikation der Probleme (gleichartige Probleme auch

woanders?)– Ursache der Probleme, z.B. fehlende Ressourcen und

Qualifikation, ungeeignete Tools Bewahrung von Erfahrungen über Projektgrenzen

hinweg Erfahrungen mit QS-Maßnahmen Projektabschluss-

bericht


EINHEIT 3:Qualität in Analyse & Design

A:Was sind gute Business-Spezifikationen?

B: Fall-Beispiel Seminarorganisation Manuelle Prüfmethoden

– Reviews u.a. Methoden Verbesserung der Prozess-Qualität (Überblick)


Fall-BeispielSeminarorganisation

Die Firma Teachware veranstaltet öffentliche und firmeninterne Seminare mit externen Dozenten. Sie besteht aus:– Geschäftsführer: verantwortlich für Planung und

Verwaltung der Seminare und Dozenten– Kundensachbearbeiter: verwaltet Kunden und

Buchungen– Kundenbetreuer: betreut Kunden und Dozenten

vor Ort


Seminar-OrganisationPflichtenheft

1. Ziele2. Produkteinsatz3. Produktumgebung4. Produktfunktionen5. Produktdaten6. Produktleistungen (nicht-funktionale Anforderungen)7. Benutzerschnittstelle8. Qualitätsziele9. Globale Testfälle (Use Cases)10. Entwicklungsumgebung


Seminar-OrganisationObjektorientierte Analyse

OOA-Diagramm


Manuelle Prüfmethoden

Eigenschaften– Produkte und Teilprodukte manuell analysiert,

geprüft und begutachtet– Ziel: Auffinden von Fehlern, Defekten,

Inkonsistenzen und Unvollständigkeiten– Überprüfung in Gruppensitzung durch kleines Team

mit definierten Rollen


Manuelle PrüfmethodenVoraussetzungen

Aufwand und Zeit fest einplanen Jedes Mitglied des Prüfteams muss in der

Prüfmethode geschult sein Prüfergebnisse nicht zur Beurteilung von Mitarbeitern

benutzen Prüfmethode schriftlich festlegen Hohe Priorität (kurzfristig durchführen nach

Beantragung) Keine Vorgesetzten und Zuhörer bei den Prüfungen


Manuelle Prüfmethoden - Vorteile

Einzige Möglichkeit zur Überprüfung von Semantik Effizientes Mittel zur Qualitätssicherung Notwendige Ergänzung werkzeuggestützter Prüfungen Verantwortung für Produktqualität aufs ganze Team

übertragen Da Überprüfung in Gruppensitzung, wird Wissensbasis der

Teilnehmer verbreitert Jedes Mitglied des Prüfteams lernt Arbeitsweise der anderen

kennen Bemühen um verständliche Ausdrucksweise Mehr Prüfungen Weniger Fehler


Manuelle Prüfmethoden - Nachteile

Hoher Aufwand– Bis zu 20% der Erstellungskosten für das Prüfobjekt– Overhead (zusätzliche Protokolle, Auswertungen)

Situation für die Autoren– Psychologisch manchmal schwierig

“Anklagebank“


Manuelle Prüfmethoden

Inspektion “formales Review“ Review Walkthrough “abgeschwächtes Review“ Stellungnahme


Reviews

Definition– Manuelle, semiformale Prüfmethode, um Stärken und

Schwächen eines schriftlichen Dokuments anhand von Referenzunterlagen zu identifizieren und durch den Autor beheben zu lassen

Ziel– Feststellung von Mängeln, Fehlern, Inkonsistenzen,

Unvollständigkeiten– Auffinden von Verstößen gegen Vorgaben, Richtlinien,

Standards, Pläne– Formale Planung und Strukturierung des Bewertungs-

prozesses und formale Abnahme des Prüfobjekts


Reviews (Forts.)

Objekte der Prüfung– Jeder lesbare Teil von Software, z.B. Dokument, Quellcode-

Modul, Spezifikation

Referenzunterlagen– Ursprungsprodukt– Vorgaben für die Erstellung des Prüfobjekts– Relevante Richtlinien und Standards– Fragenkataloge mit Listen von Fragen, die im Review

beantwortet werden (Checklisten)– Evtl. Anleitung für Durchführung des Reviews


Reviews (Forts.)

Beschreibungsform der Prüfung– Prüfobjekte

Informal (z.B. Pflichtenheft) Semiformal (z.B. Pseudocode) Formal (z.B. OOA-Modell, Quellcode)

– Bezugsobjekte Informal (z.B. Richtlinien) Semiformal (z.B. Pseudocode) Formal (z.B. OOA-Modell)

Ergebnisse– Review-Protokolle– Empfehlung über Freigabe an Manager– Überarbeitetes Prüfobjekt


Reviews (Forts.)

Teilnehmer– Review-Team mit 4-7 Personen:

Moderator, Autor, Protokollführer, 2-5 Gutachter Durchführung

– Eingangsprüfung– Evtl. Einführungssitzung: Vorstellung von Prüfobjekt– Individuelle Vorbereitung– Review-Sitzung– Überarbeitung des Prüfobjekts (durch den Autor)– Bei gravierenden Mängeln erneute Review-Sitzung

© Prof. T. Kudraß, HTWK Leipzig Ursprungsprodukt

Entw icklungsphase i

Manager Autor

Prüfobjekt

Ein-gangsprü-

fung

EinführungssitzungModerator, Autor,

Gutachter

IndividuelleVorbereitung & Prüfung

Gutachter

Prüfobjekt m itMarkierungen Gutachter

Review-SitzungModerator, Autor,

Gutachter, Protokollführer

Freigabe-empfehlung an

Manager

freigegebenesPrüfobjekt

Erstellungsregeln

Reviewplan

Fragenkataloge

ÜberarbeitungAutor

NachüberprüfungModerator / Gutachter

Protokoll

Defekte

1/2 - 1 h

nicht OK

< 2 h

akzeptiert m .Überarbeitung

Gutachter

nicht akzeptiert

ManagerReview

Ablauf eines Reviews


Reviews Kosten und Nutzen

Kosten– 15-20% des Erstellungsaufwands des Prüfobjekts

Beispiel:– Dokument mit 50 Seiten– 5 Gutachter (+Mod.+Autor), Vorb. 10 Seiten/Std., 2 Std. Sitzung– Summe Review-Aufwand 5 Personentage, Erstellungsaufwand 25

Personentage (bei 2 Seiten/Tag) Nutzen

– 60-70% der Fehler in Dokument gefunden– Reduktion der Fehlerkosten in der Entwicklung von ca. 75%

Code-Review: ähnliche Zahlen


Fallbeispiel Seminar-Organisation Unterlagen für Review

Prüfobjekt– Klassen-Diagramm Seminarorganisation V1.1

Referenzunterlagen– Ursprungsprodukt: Pflichtenheft Seminar-

organisation V 2.2– Erstellungsregeln: OOA-Methode– Checklisten: Klassen, Attribute, Operationen,

Assoziation & Aggregration


Inhalt des Review-Protokolls

Datum Name von Moderator und Teilnehmer Prüfobjekt Referenzunterlagen Defekte mit folgenden Angaben:

– Kurzbeschreibung des Defekts– Ort des Defekts– Bezug zu Regeln und Checklisten– Fehlergrad (leicht / schwer)– Wann identifiziert? (Sitzung / Vorbereitung)– Verbesserungsvorschläge (z.B. für Regeln, Checklisten)– Fragen an den Autor


Review-Protokoll: Beispiel

Review Klassendiagramm “Seminar-Organisation“

Beispiel-Protokoll


Inspektion

“formales Review“ [ANSI/IEEE Std.729-1983] Zusätzliche Eigenschaften:

– Verbesserung der Entwicklungsregeln und des Entwicklungsprozesses

– Metriken ermitteln (mit Hilfe von Statistiken über Erkennung von Defekten)

– Inspektionsprotokoll stärker formalisiert als beim Review

– Freigabe erfolgt durch Moderator


Walkthrough - Ablauf

Prüfobjekt

Individuelle Vorbereitung & PrüfungGutachter

Walkthrough-SitzungAutor, Gutachter

Protokoll Prüfobjekt

Defekte

Walkthrough


Walkthrough - Bewertung

Vorteile – Geringer Aufwand– Auch für kleine Entwicklungsteams geeignet (<= 5Mitarbeiter)– Sinnvoll für “unkritische“ Dokumente– Einbeziehung von Endbenutzern als Gutachter Erkennung von

Unvollständigkeiten und Missverständnissen– Wissen über ein Dokument auf breite Basis stellen

Nachteile– Nur wenige Defekte identifiziert– Autor kann Walkthrough-Sitzung dominieren und Gutachter “blenden“– Überarbeitung des Prüfobjekts im Ermessen des Autors, wird nicht

nachgeprüft


Weitere Prüfmethoden

Stellungnahme– Kommentare zum Prüfobjekt an den Autor auf dessen Bitte hin– Ungeplant, zwischen normalen Tätigkeiten

Round Robin Review– Review-Sitzung mit “umgekehrten Vorzeichen“ (Argumente für

die Güte des Prüfobjekts suchen) Peer Review

– Review-Team organisiert selbst Aufgabenteilung und Vorgehensweise

– Ein Moderator: Sitzungsleitung, Organisation


Verbesserung der Prozessqualität (Überblick)

ISO 9000-Ansatz TQM (Total Quality Management) CMM (Capability Maturity Matrix) Business Engineering


ISO 9000 Ansatz: Prozessqualität

Allgemeingültige Anforderungen für Aufbau- und Ablauforganisation eines Unternehmens

Definiert wichtige Dokumente und Inhalte Regelung von Zuständigkeiten, Befugnissen,

Verantwortungsbereichen Orientiert sich am Auftraggeber-Lieferanten-Verhältnis Fordert organisatorische Unabhängigkeit der QS Integriert QS in die gesamte Organisation Ziel: reproduzierbare Entwicklungsprozesse Zertifikat: für betriebliche Abläufe (nicht Produkt!)


Bewertung ISO 9000

Vorteile– Externe Zertifizierung und Wiederholungsaudits QM-System

aufrecht erhalten!– Erleichtert Akquisition von Aufträgen (Werbung)– Niedrigeres Produkthaftungsrisiko– Qualitätsbewusstsein

Nachteile– Unsystematisch: Mischung von Tätigkeiten und Dokumenten– Keine saubere Trennung der QS- von anderen Aufgaben– Gefahr der “Software-Bürokratie“– Benötigt Unterstützung durch CASE-Werkzeuge– Standardisierte Verfahrensabläufe und Dokumente, oft zu starr


TQM-Ansatz

M

QT

Totales Qualitätsmanagement • Prozessqualität• Produktqualität• Kontinuierliche Qualitätsverbesserung

• Bereichs- und funk- tionsübergreifend• Kundenorientierung• Einbeziehung aller Mitarbeiter

• Vorbildfunktion des Managements• Qualität wird bei Management- entscheidungen gleichberechtigt zu Kosten und Terminen bewertet

An Software-Entwicklung anpassen


TQM: Einige Methoden

Qualitätszirkel / Brainstorming Pareto-Analyse

– 80:20 Regel (80% des Aufwandes für 20% der Probleme)

Ursache-Wirkungs-Diagramm– Ishikawa-Diagramm (Fishbone Chart)

QFD-Konzept (Quality Function Deployment)


CMM (Capability Maturity Model)

Beschreibt Qualität des Software-Entwicklungs-prozesses

Unterscheidet 5 Qualitätsstufen von Entwicklungsprozessen– Höherer Reifegrad höhere Termintreue

geringere Schwankungsbreite

– Ermittlung der Reifegrade anhand von Hauptkriterien (key process areas) und Aspekten (key practices)


CMM-Reifegradstufen

In

In

In

In

Out

Out

Out

Out

Stufe 5Optimierender Prozess

Stufe 4Gesteuerter Prozess

Stufe 3Definierter Prozess

Stufe 2Wiederhol-barer Prozess

Stufe 1Initialer Prozess

OutIn


EINHEIT 4:Testende Verfahren

Grundbegriffe Klassifikation

– Strukturtest (White Box-Test)– Funktionaler Test (Black Box-Test)

Testmethodik Test-Arten

– Integrationstest– Systemtest

Testprozess und -dokumentation


Einführung

Produktqualität = Produktqualität jeder Systemkomponente Produktqualität der Beziehungen zwischen den

Systemkomponenten

Qualitätsmerkmale

Konstruktive und analytische Maßnahmen

Eigenschaften der Systemkomponente

Konstruktion Analyse

FunktionalitätZuverlässigkeit(Änderbarkeit)


Fehler

Definition– Abweichung der tatsächlichen Ausprägung eines

Qualitätsmerkmals von der vorgesehenen Soll-Ausprägung– Inkonsistenz zwischen Spezifikation und Implementierung– Entspricht Richtigkeit (Funktionalität) und Reife und

Fehlertoleranz (Zuverlässigkeit) [DIN ISO 9126] Konstruktives Ziel

– Fehlerfreie Software-Komponenten entwickeln Analytisches Ziel

– Fehlerfreiheit einer Software-Komponente nachweisen– Vorhandene Fehler finden


Auswahl analytischer Maßnahmen

Funktionalität

Richtigkeit Reife

Zuverlässigkeit

Fehlertoleranz

Qualitätsmerkmale

Analysierbarkeit

Änderbarkeit

Modifizierbarkeit

Stabilität

Prüfbarkeit

Testende Verfahren Verifizierende Verfahren Analysierende Verfahren

Spezifikation

ImplementierungKlassenDatentyp-ModuleDatenobjekt-ModuleFunktionale Module

Beschreibung Komp.-Art

(z.T. ermittelbar durch Metriken)

Komponenteneigenschaft


Begriffe

Prüfling, Testobjekt– Software-Komponente, die getestet werden soll

Testfall– Satz von Testdaten, der die vollständige Ausführung eines

Programms bewirkt

Testdatum– Eingabewert für Eingabeparameter oder Eingabevariable

des Testobjekts

Testtreiber– Testrahmen zum interaktiven Aufrufen einer

Prozedur/Funktion


Weitere Begriffe

Instrumentierung– Ziel: Protokollierung ausgeführter Testfälle– Analyse des Quellcodes des Prüflings durch ein Testwerkzeug– Einbau von Zählern und Auswertung der Zählerstände

(Protokoll) Überdeckungsgrad

– Grad der Vollständigkeit eines Test in einem Testverfahren Regressionstest

– Wiederholung aller Testfälle nach Änderung des Prüflings mit Soll/Ist-Ergebnisvergleich


Klassifikation testender Verfahren

Dynamische VerfahrenStrukturtest (White Box-Test, Glass Box-Test)Kontrollflussorientierter Test• Anweisungsüberdeckungstest• Zweigüberdeckungstest• Pfadüberdeckungstest (vollständig, strukturiert, boundary interior)• Bedingungsüberdeckungstest (einfach, minimal, mehrfach, mehrfach)

Datenflussorientierter Test• Defs / Uses-Verfahren

Funktionaler Test (Black Box-Test)• funktionale Äquivalenzklassenbildung• Grenzwertanalyse• Test spezieller Wert• Zufallstest


Beispiel C++ Prozedur ZaehleZchn

Programm ZaehleZchn (Spezifikation / Header)

Die Prozedur liest solange Zeichen von der Tastatur, bis ein Zeichen erkannt wird, das kein Großbuchstabe ist, oder Gesamtzahl den größten durch den Datentyp int darstellbaren Wert INT_MAX erreicht.Ist ein gelesenes Zeichen ein Großbuchstabe zwischen A und Z, dann wird Gesamtzahl um 1 erhöht. Ist der Großbuchstabe ein Vokal, dann wird auch Vokalanzahl um 1 erhöht. Ein/Ausgabeparameter sind Gesamtzahl und Vokalanzahl.Randbedingung:Das aufrufende Programm stellt sicher, dass Gesamtzahl stets größer oder gleich Vokalanzahl ist.


Beispielprogramm ZaehleZchn

void ZaehleZchn (int &VokalAnzahl, int &Gesamtzahl){

char Zchn;cin >> Zchn;while((Zchn >= ‘A‘) && (Zchn <= ‘Z‘) && (Gesamtzahl < INT_MAX)){

Gesamtzahl = Gesamtzahl + 1;if ((Zchn == ‘A‘) || (Zchn == ‘E‘) || (Zchn == ‘I‘)

|| (Zchn == ‘O‘) || (Zchn == ‘U‘)) {

VokalAnzahl = VokalAnzahl + 1;} // end ifcin >> Zchn;

} // end while}


Beispielprogramm ZaehleZchn (2)

void main

{

int AnzahlVokale = 0;

int AnzahlZchn = 0;

cout << “Programm ZaehleZchn“ << endl;

cout << “Zeichen bitte eingeben:“ << endl;

ZaehleZchn(AnzahlVokale, AnzahlZchn);

cout << “Anzahl Vokale: “ << AnzahlVokale << endl;

cout << “Anzahl Zeichen: “<< AnzahlZchn << endl;

}


Kontrollflussgraph

n1

n2

n3

n4

n5

Knoten Zweig, Kante

Pfad

nfinal

nstart

cin >> Zchn;

while ((Zchn >= ‘A‘) && (Zchn <= ‘Z‘) && (Gesamtzahl < INT_MAX))

Gesamtzahl = Gesamtzahl + 1;

if ((Zchn == ‘A‘) || (Zchn == ‘E‘) || (Zchn == ‘I‘) || (Zchn == ‘O‘) || (Zchn == ‘U‘)) VokalAnzahl = VokalAnzahl + 1;

cin >> Zchn;n6


Anweisungsüberdeckung vs. Zweigüberdeckung

n1

n2

n3

n4

n5

nfinal

nstart

cin >> Zchn;




cin >> Zchn;n6

n1

n2

n3

n4

n5

nfinal

n6

nstart


AnweisungsüberdeckungstestC0-Test

Prinzip– Mindestens einmalige Ausführung aller Anweisungen des

Programms (d.h. alle Knoten) Eigenschaften

– Kontrollstrukturen / Datenabhängigkeiten nicht geprüft– Jede Anweisung gleichgewichtig gewertet– Notwendiges, aber nicht hinreichendes Testkriterium– Nicht ausführbarer Code kann gefunden werden– Als eigenständiges Testverfahren nicht geeignet

Leistungsfähigkeit– Geringste Fehleridentifizierungsquote (18%)


ZweigüberdeckungstestC1-Test

Prinzip– Ausführung aller Zweige des zu testenden Programms, d.h. Durchlaufen aller

Kanten des Kontrollflussgraphen– Das minimale Testkriterium

Leistungsfähigkeit– Findet nicht ausführbare Programmzweige– Kontrolliert Korrektheit an den Verzweigungsstellen– Erkennt und optimiert häufig durchlaufene Programmteile– Bessere Fehleridentifizierungsquote (35%)

Schwächen– Unzureichend für den Test von Schleifen– Berücksichtigt nicht Abhängigkeiten zwischen Zeigen, sondern betrachtet

einzelne Zweige– Unzureichend für den Test komplexer, d.h. zusammengesetzter Bedingungen


Pfadüberdeckungstest

n1

n2

n3

n4

n5

nfinal

nstart

cin >> Zchn;




cin >> Zchn;n6

p

q2q1

r


Pfadüberdeckungstest

Prinzip– Ausführung aller unterschiedlichen Pfade des zu testenden Programms– Pfad = Sequenz von Knoten (i,n1, n2, ..., nm)

Leistungsfähigkeit– Ist das mächtigste kontrollflussorientierte Verfahren (über 60%

Identifizierungsquote) Schwächen

– Pfadanzahl wächst bei Wiederholungsanweisungen für den Test von Schleifen – ohne feste Wiederholungszahl

– Teil der konstruierbaren Pfade nicht ausführbar Vollständigkeit nicht gesichert

– Keine praktische Bedeutung aufgrund eingeschränkter Durchführbar-keit ( eingeschränktere Ansätze zum Testen verfolgen)


Boundary-Interior-Pfadtest

Prinzip– Schwächere Version des Pfadüberdeckungstests– Keine Überprüfung von Pfaden, die durch mehr als einmalige

Schleifenwiederholung erzeugt werden – Gezieltere Überprüfung von Schleifen praktikabel

Eigenschaften– Grenztest-Gruppe (boundary test):

Alle Pfade, die die Schleife zwar betreten, sie aber nicht wiederholen; Ausführung aller unterschiedlichen Pfade innerhalb des Schleifenkörpers

– Gruppe zum Test des Schleifeninneren (interior test): Alle Pfade, die mindestens eine Schleifenwiederholung beinhalten; Ausführung aller unterschiedlichen Pfade während der ersten beiden Ausführungen des Schleifenkörpers


Testfall für den Pfad außerhalb der Schleife– Aufruf mit Gesamtzahl = INT_MAX

Testfall für den Grenztest– Aufruf mit Gesamtzahl = 0, Zchn = ‘A‘, ‘1‘– Aufruf mit Gesamtzahl = 0, Zchn = ‘B‘, ‘1‘

Testfälle für den Schleifenkörper: mindestens eine Schleifenwiederholung, 4 mögliche Pfade bei 2 Ausführungen des Schleifenkörpers

– Zchn = ‘E‘, ‘I‘, ‘N‘, ‘*‘ – Zchn = ‘A‘‚ ‘H‘, ‘!‘ – Zchn = ‘H‘, ‘A‘, ‘+‘– Zchn = ‘X‘, ‘X‘, ‘,‘

Beispiel Boundary-Interior-Pfadtest


Bedingungsüberdeckungstest-Verfahren

Prinzip– Benutzen Bedingungen in Wiederholungs- und Auswahlkonstrukten

zur Definition von Tests Eigenschaften

– Einfache Bedingungsüberdeckung:Überdeckung aller atomaren Bedingungen. Evaluation aller atomarer Bedingungen muss mindestens einmal true und false ergeben

– Mehrfach-Bedingungsüberdeckung: Bildung aller Variationen der atomaren Bedingungen. Bei n Bedingungen 2n Variationen große Anzahl Testfälle

– Minimale Mehrfach-Bedingungsüberdeckung:Jede Bedingung – atomar oder zusammengesetzt – muss mindestens einmal true und einmal false sein


BedingungsüberdeckungBeispiel

Zwei Bedingungen

a) 3 atomare Bedingungen

((Zchn >= ‘A‘) && (Zchn <= ‘Z‘) && (Gesamtzahl < INT_MAX))

b) 5 atomare Bedingungen

((Zchn == ‘A‘) || (Zchn == ‘E‘) || (Zchn == ‘I‘) ||(Zchn == ‘O‘) || (Zchn == ‘U‘))


Einfache Bedingungsüberdeckung

Variablen 1 2 3

Gesamtzahl 0 1 2 3 4 5 0 INT_MAX

Zchn ‘A‘ ‘E‘ ‘I‘ ‘O‘ ‘U‘ ‘1‘ ‘a‘ ‘D‘

Zchn>=‘A‘ T T T T T F T T

Zchn<=‘Z‘ T T T T T T F T

Gesamtzahl < INT_MAX

T T T T T T T F

Zchn==‘A‘ T F F F F - - -

Zchn==‘E‘ F T F F F - - -

Zchn==‘I‘ F F T F F - - -

Zchn==‘O‘ F F F T F - - -

Zchn==‘U‘ F F F F T - - -

Testfälle Variablenwerte

Atomare Bedingungen Wahrheitswerte der atomaren Bedingungen


Bedingungsüberdeckung Vollständige Prüfung d. Bedingungen

Variablen 1 2 3

Gesamtzahl 0 1 2 3 4 5 6 0 INT_MAX

Zchn ‘A‘ ‘E‘ ‘I‘ ‘O‘ ‘U‘ ‘B‘ ‘1‘ ‘a‘ ‘D‘

Zchn>=‘A‘

Zchn<=‘Z‘

T

T

T

T

T

T

T

T

T

T

T

T

F

T

T

F

T

T

Gesamtzahl < INT_MAX

T T T T T T T T F

Bedingung a T T T T T T F F F

Zchn==‘A‘ T F F F F F - - -

Zchn==‘E‘ F T F F F F - - -

Zchn==‘I‘ F F T F F F - - -

Zchn==‘O‘ F F F T F F - - -

Zchn==‘U‘ F F F F T F - - -

Bedingung b T T T T T F - - -

Testfälle


Datenflussorientierte Strukturtestverfahren

Prinzip– Dynamisches Strukturtestverfahren– Nutzt Definition von Variablen sowie lesende und schreibende

Zugriffe auf Variablen in Anweisungen und Bedingungen für Testziele

– Geeignet zum Test von Datenobjekt- und Datentypmodulen Defs/Uses-Verfahren, 3 Kategorien

– Wertzuweisung / Definition (def)– Berechnung von Werten innerhalb eines Ausdrucks

(computational-use, c-use)– Bildung von Wahrheitswerten in Bedingungen (predicate-use,

p-use)


Kontrollflussgraph - Datenflussdarstellung

nstartImport von ‘VokalAnzahl‘ und ‘Gesamtzahl‘char Zchn; cin >> Zchn;




cin >> Zchn;

Export von ‘VokalAnzahl‘ und ‘Gesamtzahl‘

n1

n2

n3

n4

n5

nfinal

n6

def (Gesamtzahl)def (VokalAnzahl)

def (Zchn)

p-use (Zchn)p-use (Gesamtzahl)

c-use (Gesamtzahl)def (Gesamtzahl)

p-use (Zchn)

c-use (VokalAnzahl)def (VokalAnzahl)

def (Zchn)

c-use (VokalAnzahl)c-use (Gesamtanzahl)

nin

nout


Datenflussorientierte Testverfahren

all defs-Kriterium– Jede Variablendefinition benutzen

all p-uses-Kriterium– Jede Kombination Variablenbenutzung + prädikative

Variablenbenutzung (zweigüberdeckend) all c-uses-Kriterium

– Ausführung mindestens eines definitionsfreien Pfades all c-uses / some p-uses-Kriterium

– Test aller Kombinationen Variablendefinition + berechnende Variablenbenutzung


Analytische Verfahren – Black Box Tests (Funktionale Tests)

Funktionale Testverfahren– Funktionale Äquivalenzklassenbildung– Grenzwertanalyse– Test spezieller Werte

Kombination Funktion- und Strukturtest


Funktionale Äquivalenzklassenbildung

Prinzip– Dynamisches funktionales Testverfahren, das Tests aus der funktionalen

Spezifikation ableitet (Black Box-Test) Eigenschaften

– Äquivalenzklassen der Eingabewerte durch Zerlegung des Definitionsbereichs gebildet

– Bildung von Ausgabe-Äquivalenzklassen– Repräsentant für einen Testfall irgendein Element aus Äquivalenzklasse

Bewertung– Geeignetes Verfahren für Ableitung von Testfällen– Basis für Grenzwertanalyse– Aufteilung in Äquivalenzklassen nicht immer mit Programmstruktur identisch– Nur Betrachtung von Ein- und Ausgabe, aber nicht Ursache-Wirkung!


Regeln zur Äquivalenzklassenbildung

1. Ein zusammenhängender Wertebereich eine gültige Äquivalenzklasse und 2 ungültige Äquivalenzklassen

Eingabebereich: 1 <= Tage <= 31 Tage1 gültige Klasse: 1 <= Tage <= 312 ungültige Klassen: Tage < 1, Tage > 31

2. Anzahl von Werten 1 gültige und 2 ungültige ÄquivalenzklassenEingabebereich: 1..6 Besitzer eines Autos1 gültige Klasse: 1..6 Besitzer2 ungültige Klassen: Kein Besitzer, Mehr als 6 Besitzer

3. Anzahl von n Werten mit unterschiedlicher Behandlung n gültige und 1 ungültige Äquivalenzklasse

Tasteninstrumente: Klavier, Cembalo, Spinett, Orgel 4 gültige Klassen: Klavier, Cembalo, Spinett, Orgel 1 ungültige Klasse: z.B. Violine


Regeln zur Äquivalenzklassenbildung (Forts.)

4. Situation, die zwingend erfüllt sein muss 1 gültige und 1 ungültige Äquivalenzklasse

Das erste Zeichen muss ein Buchstabe sein1 gültige Klasse: Das erste Zeichen ist ein Buchstabe1 ungültige Klasse: Das erste Zeichen ist kein Buchstabe

5. Äquivalenzklasse auftrennen, wenn deren Elemente unterschiedlich behandelt werden

6. Bildung von Ausgabe-Äquivalenzklassen (1-5 analog)Eingabewert Ausgabewert? Ausgabewert in Wertebereich?

Ausgabebereich: 1 <= Wert <= 99 1 gültige Klasse: Alle Eingaben, die Ausgaben zwischen 1 und 99 erzeugen2 ungültige Klassen: - Alle Eingaben, die Ausgaben kleiner als 1 erzeugen- Alle Eingaben, die Ausgaben größer als 99 erzeugen


BeispielÄquivalenzklassen und Testfälle

Eingaben Äquivalenzklassen

Gesamtzahl 1 0<=Gesamtzahl < INT_MAX

2 Gesamtzahl = INT_MAX

VokalAnzahl 3 0<=VokalAnzahl<=Gesamtzahl

Zchn 4a Zchn < ‘A‘

4b Zchn > ‘Z‘

5 ‘A‘ <= Zchn <= ‘Z‘

6a Zchn = ‘A‘

6b Zchn = ‘E‘

6c Zchn = ‘I‘

6d Zchn = ‘O‘

6e Zchn = ‘U‘

Testfall 1 2 3

Getestete Äquivalenzkl.

1, 3, 5, 6a, 6b, 6c, 6d, 6e, 4a

1, 3, 4b 2, 3

Gesamtzahl 100 1 INT_MAX

VokalAnzahl 50 1 50

Zchn ‘X‘,‘A‘,‘E‘,‘I‘,‘O‘,‘U‘,‘I‘

‘a‘ -

Soll: Gesamtzahl

106 1 INT_MAX

Vokalanzahl 55 1 50

ÄquivalenzklassenFür ZaehleZchn

Testfälle fürZaehleZchn


Grenzwertanalyse

Prinzip– Dynamisches funktionales Testverfahren, das Tests aus der funktionalen

Spezifikation ableitet (Black Box-Test)– Basiert auf Äquivalenzklassenbildung

Eigenschaften– Jeder Rand der Äquivalenzklasse getestet Setzt eine natürliche Ordnung der

Elemente in Äquivalenzklasse voraus Bewertung

– Sinnvolle Erweiterung und Verbesserung Äquivalenzklassenbildung– Identifiziert wichtige Typen von Testfällen

Beispielvoid setzeMonat (short Monat); // Eingabeparameter– 1 gültige Äquivalenzklasse (1<=m<=12), 2 ungültige (m<1,m>12)– Testfälle: monat = 1; monat = 12; monat = 0; monat =13;


Test spezieller Werte

Ziel– Aufstellung von fehlersensitiven Testfällen aus der Erfahrung

heraus (Spezialfälle) Kriterien

– Grenzwertanalyse– Zero values-Kriterium– Distinct values-Kriterium

Beispiele– Wert 0 als Eingabe- oder Ausgabewert– Sonder- oder Steuerzeichen bei der Eingabe von Zeichenketten– NULL-Werte in Tabellen


Zufallstest

Prinzip– Erzeugung zufälliger Testfälle aus dem Wertebereich der

Eingabedaten– Werkzeugnutzung (Testdatenerzeugung)

Bewertung– Schließt menschliches Fehlverhalten bei Testdatenerzeugung

aus, da regellose Testdatenerzeugung– Als alleiniges Verfahren nicht ausreichend (minimale

Testkriterien nicht erfüllt) – Nur als ergänzendes Verfahren geeignet, z.B. in Kombination

mit Äquivalenzklassen


Strukturtest vs. Funktionstest

Nachteil Strukturtest– Fehlende Funktionalität nicht erkannt (stattdessen triviale

Testfälle z.B. bei Zweigüberdeckung) Nachteil Funktionstest

– Implementierung nicht geeignet berücksichtigt– Nur Teil aller Zweige berücksichtigt

Kombination Strukturtest + Funktionstest!

Sicht des Programmierers/Testers vs. Sicht des Managements


Anforderungen an die Testmethodik

Erfüllen von anerkannten Minimalkriterien– Ausführung aller Zweige (Zweigüberdeckungstest)– Test anhand von Spezifikation (Funktionstest)

Erzeugung von fehlersensitiven Testdaten Erzeugung von Testdaten, die das korrekte Funktionieren

zeigen Wirtschaftlichkeit der Prüfung Systematik des Tests Nachvollziehbarkeit Verwendung eines geeigneten Werkzeugs

– Testprotokollierung, Testmetrik, Regressionstest


Testmethodik

1. Funktionstesta) Testobjekt mit Testwerkzeug instrumentieren

(protokolliert Überdeckung)

b) Mit Hilfe Spezifikation bestimmen:- Äquivalenzklassen, Grenzwerte, Spezialwerte, Testdaten - Keine Implementierung!

c) Testfälle mit Testobjekt durchführen:- Soll-Ist-Vergleich- Keine Überdeckungsrate betrachten


Testmethodik (Forts.)

2. Strukturtesta) Überdeckungsstatistik nach Funktionstest auswerten –

Nichtabdeckungen untersuchen (z.B. Fehlerabfragen, “tote“ Zweige)

b) Testfälle für noch nicht durchlaufene Zweige, Pfade, Bedingungen aufstellen

c) Durchführung Testlauf für jeden Testfalld) Ende des Überdeckungstests bei Erreichen einer bestimmten

Überdeckungsrate

3. RegressionstestFalls Fehlerkorrektur: Regressionstest mit den bisherigen Testfällen (d.h. nochmalige Durchführung der protokollierten Testfälle und Soll-Ist-Vergleich)


Allgemeine Tipps zum Testen

Testwerkzeuge / Hoher Automatisierungsgrad Konstruktive Voraussicht bei Entwurf und Spezifikation Funktionstest im Entwurf berücksichtigen (Herleitung der

Testfälle ohne Blick in den Quellcode) Funktionstests sorgfältig vorbereiten Strukturtest nach dem Funktionstest zielgerichtet möglich Einzeltests mit jeder Systemkomponente vor

Integrationstest Einbau der Testwerkzeuge in den Entwicklungs-prozess

(Richtlinien, Checklisten)


Integrationstest – Einführung und Überblick

Aufgabe:– Fehlerfreies Zusammenwirken der Systemkomponenten

testen

Voraussetzung:– Jede Systemkomponente bereits überprüft

Unterschiedliche Integrationsstrategien Klassifikation von Integrationstests:

– Dynamisch vs. Statisch– Black Box vs. White Box


Integrationsstrategien

bottom-up

top-down

inside-out

hardest first

outside-in

big bang

geschäftsprozess-orientiert

funktionsorientiert

nach der Verfügbarkeit

Nicht-inkrementell

Inkrementell

vorgehensorientiert testzielorientiert


Testtreiber und Platzhalter

Testtreiber (Driver)– Zum Test einer Systemkomponente, deren Dienst nicht direkt

vom User Interface (mit Parametern) aufgerufen wird Platzhalter (Dummies, Stubs)

– Beim Aufruf von Systemkomponenten, die noch nicht implementiert sind, sondern nur spezifiziert

Beispiel C

GG: abstrakter Datentyp mit 2 Operatoren: LeseNaechstenSatz und LoescheSatz

C: liest jeden Satz einer Datei und löscht dann


Integrationstest-Verfahren

DynamischTest der integrierten Komponenten mit konkreten Eingabewerten

Strukturorientiert– Kontrollflussorientiert– Datenflussorientiert

Funktionalzu wenig Funktionalität / zu viel Funktionalität / falsche Funktionalität

WertbezogenTest mit extremen Werten (vgl. Grenzwertanalyse, Test spezieller Werte)


Prüfziele eines Systemtests

Vollständigkeit– Alle funktionalen und nicht-funktionalen Anforderungen aus dem

Pflichtenheft. Funktionale Anforderungen Funktionstest– Beispiel:

Produktfunktionen lt. Pflichtenheft Globale Testfälle (Funktionssequenzen)

Volumen– Test mit umfangreichen Datenmengen (Massentest)– Beispiel:

Max. 50.000 Teilnehmer, max. 10.000 Seminare Importschnittstelle für Massendaten


Prüfziele eines Systemtests (2)

Zeit– Antwortzeiten und Durchsatzraten bei starker Systembelastung

(Zeittest)– Beispiel:

Reaktionszeiten < 2 sec Verarbeitungsfunktionen max. 15 sec

Zuverlässigkeit– Test des Systems unter Spitzenbelastung über längere Zeit

hinweg (Lasttest), im grünen Bereich– Beispiel:

Datei nicht vorhanden bei Dateischnittstelle Datei zu groß



Fehlertoleranz, Robustheit– Test des Systems unter Überlast, im roten Bereich (Stresstest)– Simulierte Situationen: geringerer Speicher, Plattenausfall – Beispiel:

Was passiert bei: 100.000 Teilnehmern, 50.000 Seminaren?

Benutzbarkeit– Verständlichkeit, Erlernbarkeit, Bedienbarkeit aus der Sicht des

Endbenutzers (Benutzbarkeitstest)– Beispiel:

Anforderungen an User Interface aus Pflichtenheft 2 Rollen: Kundensachbearbeiter, Seminarsachbearbeiter

Sicherheit– Datenschutz-Mech. (Sicherheitstest), Passwörter, Zugriffsrechte



Interoperabilität– Zusammenarbeit des Systems mit anderen Systemen, Kompatibilität

von Schnittstellen und Daten (Interoperabilitätstest)– Beispiel:

Zusammenarbeit Seminarorganisation mit Buchhaltungssystem

Konfiguration– System für unterschiedliche HW/SW-Plattformen und

Konfigurationen geeignet Dokumentation

– Vorhandensein, Güte und Angemessenheit der Benutzer- und Wartungsdokumentation (Dokumentenprüfung)

Installations- und Wiederinbetriebnahmetest


Abnahmetest (Acceptance Test)

Test des Systems– Unter Mitwirkung und Federführung des Auftraggebers– In der realen Einsatzumgebung beim Auftraggeber– Möglichst mit echten Daten des Auftraggebers

Arten:– Werkabnahme (Ausführung aller vorgesehenen Testfälle)– Abnahme in der realen Umgebung– Betriebsabnahme (Pilotphase) – endgültiger Inbetriebnahme


Testprozess und -dokumentation

Testprozess– Testplanung– Testdurchführung– Testkontrolle

Dokumente– Testplan und

Testvorschrift– Testbericht

Testbericht [ANSI/IEEE Std. 829-1983]– Testzusammenfassung– Testprotokoll (ergibt sich aus Testvorschrift)– Liste der Problemmeldungen– Liste der Software-Einheiten


Inhalt einer Testvorschrift

1. Einleitung1.1 Zweck des Tests1.2 Testumfang1.3 Referenzierte Unterlagen

2. Testumgebung2.1 Überblick2.2 Test-Software und -Hardware2.3 Testdaten, Testdatenbanken2.4 Personalbedarf

3. Abnahmekriterien3.1 Kriterien für Erfolg und Abbruch 3.2 Kriterien für Unterbrechungen3.3 Voraussetzungen für Wiederaufnahme


Inhalt einer Testvorschrift (Forts.)

4. Testabschnitt 14.1 Einleitung4.1.1 Zweck, Referenz zur Spezifikation4.1.2 Getestete Software-Einheiten4.1.3 Vorbereitungsarbeiten für den Testabschnitt4.1.4 Aufräumarbeiten nach dem Testabschnitt4.2 Testsequenz 1-14.2.1 Testfall 1-1-1

Eingabe, Anweisung, Soll-Ausgabe, Raum für Ist-Ausgabe und Befund4.2.2 Testfall 1-1-24.3 Testsequenz 1-2:4.n Ergebnis des Abschnitts 1

5. Testabschnitt 2:


Testzusammenfassung

Allgemeine Daten– Nr., Beginn, Ende, Dauer

Gegenstand und Zweck des Tests– Projekt, Release-Nr.– Geliefert von: Einzeltest, Integrationstest, Systemtest, Abnahmetest

Testvorschrift (siehe dort) Empfehlung

– Akzeptieren / Nicht akzeptieren (d.h. Testwiederholung)? Beilagen

– Liste der getesteten Software-Einheiten– Liste der Problemmeldungen

Documents

Qualitätsmanagement in der Software-Entwicklung Prof. Dr. Thomas Kudraß HTWK Leipzig Seminar PC-Ware AG Leipzig, 26.01.2002