SOFTWARE‐QUALITÄTSSICHERUNG UND –PRÜFUNG

Kapitel 6UND  PRÜFUNG

TEIL 2

Software Engineering

Prof. Dr. Wolfgang Schramm

Übersicht1

1. Einführung in das Software Engineering

2. Softwareprozesse3. Anforderungsanalyse und ‐

Spezifikation4. Softwareentwurf5. Programmierung6. Software‐Qualitätssicherung und ‐

Prüfung7. Konfigurationsverwaltung8. Software‐Wartung

Kapitelübersicht2

1. Einführung/Definition2. Testen

TeststrategienVorgehen beim TestenTestautomatisierung

3. Statische VerfahrenÜbersicht zu verschiedenen VerfahrenSoftware Inspektionen

Software‐Reviews3

Es besteht Bedarf an ergänzenden Methoden zur Entdeckung und Beseitigung von Fehlern:Beseitigung von Fehlern:=> Reviews

Reviews können das Testen nichtersetzen und umgekehrt!ersetzen, und umgekehrt!

Software‐Reviews4

Ohne Reviews

Fehler-UrsprungDesign Code TestAnford. Wartung

Ohne Reviews

Design Code TestAnford. WartungFehler-Entdeckung

Chaos

D i C d T tA f d W t

Mit Reviews (ideal)

Fehler-Entdeckung

Fehler-UrsprungDesign Code TestAnford. Wartung

Design Code TestAnford. Wartungg

Übersicht über Review‐Techniken5

Sehr Wenigerformal

Wenigerformal

Inspektion TeamReview

Walkthrough PairProgramming

PeerDesk-Checking

Ad-hoc

Empirische Studien belegen Inspektionen als die Empirische Studien belegen Inspektionen als die zuverlässigste Review‐Technik. Inspektionen finden 50% mehr Fehler als Walkthroughs Inspektionen finden 50% mehr Fehler als Walkthroughs Inspektionen finden bis zu 6x mehr Fehler als Ad‐hoc Reviews

Übersicht über Review‐Techniken6

Ad‐hoc Review Wenn man ein Problem nicht lösen kann bittet man einen Mitarbeiter 

spontan um Hilfe Ergebnis hängt vollständig von der Erfahrung des einen Mitarbeiters ab Ergebnis hängt vollständig von der Erfahrung des einen Mitarbeiters ab

Peer Desk‐Checking Peer Desk Checking Ähnlich Ad‐hoc Review Der Mitarbeiter “führt das zu überprüfende Produkt auf dem Papier 

aus” (meistens Code) 

Übersicht über Review‐Techniken7

Pair‐Programmingkl l h b l d b Zwei Entwickler teilen sich einen PC‐Arbeitsplatz und arbeiten 

gemeinsam an einem Stück Code. Eine der Praktiken des eXtreme Programming

Walkthrough Der Autor eines Dokuments präsentiert es Mitarbeitern, um ein 

allgemeines Verständnis zu erlangen und die Qualität des Dokuments zu verbessern.

Kein vorgegebener Prozess und keine Anleitung, wie Fehler zu finden sind.

Risiko: Der Autor vergisst während der Präsentation leicht auf die Risiko: Der Autor vergisst während der Präsentation leicht auf die wesentlichen Teile des Dokuments zu fokussieren.

Inspektion – Eigenschaften9

Welche Aktivitäten werden innerhalb des Inspektionsprozesses ausgeführt?

ProzessWelche Rollen

Welche Dokumente

Rollen DokumenteWelche Rollen

sind in den Inspektions-

prozess involviert?

Dokumente werden in

einer Inspektion

d t?

Inspektion

Lesetechnikeninvolviert? verwendet?

Welche Techniken können eingesetzt werden, um Fehler in einem Softwaredokument zu finden?

Der Prozess und die Rollen10

T il h i l dPl Teilnehmer einladen, Terminvereinbarung von allen Inspektionsaktivitäten, Räume festlegen Organisator

Planung

Kick-offfestlegen  Organisator 

Suche nach und Dokumentation von Problemen (d.h. potentielle Fehlern / F / V b hlä )

Vorbereitung

Fragen / Verbesserungsvorschläge)  Inspektoren

Sammeln der Fehler. Entscheiden, ob Meeting ein Befund ein tatsächlicher Fehler ist. Suche nach weiteren Fehlern. Entscheiden über Re‐Inspektion. d // / kModerator//Autor/Inspektoren

Korrektur der Fehler  AutorKorrektur

Follow-up

Inspektionsdokumente11

Problemliste Dokumentation der Befunde (potentielle 

Fehler/Fragen/Verbesserungsvorschläge) sowie des Aufwands für die Fehlersuche

Fehlerliste Dokumentation der tatsächlichen Fehler,,

sowie des Aufwandes für das Meeting

Korrekturliste Dokumentation der Fehlerkorrektur (oft in Fehlerliste integriert)

Bedeutung der Dokumente12

E b i i I kti Ergebnisse einer Inspektion Verbessertes Softwaredokument Dokumentierte Information zur Charakterisierung Dokumentierte Information zur Charakterisierung 

des inspizierten Dokumentes des Inspektionsprozesses des Soft are Ent ickl ngspro esses des Software‐Entwicklungsprozesses

Verwendung der Ergebnisse Hilfe für den Autor bei der Überarbeitung seines Hilfe für den Autor bei der Überarbeitung seines 

Dokumentes Charakterisierung / Beurteilung / Vorhersage /  

Verbesserung des Inspektions‐ undVerbesserung des Inspektions‐ und Softwareentwicklungsprozessesund nicht der daran beteiligten Personen!

Aktivitäten der Vorbereitungsphase13

Dokument wird von den Inspektoren nach Befunden durchsucht  (Individuaktivität)

Fehler werden dokumentiert Ziel: möglichst viele schwere Fehler findeng

Probleme der Vorbereitungsphase14

b f k k k l f k Es gibt oft keine konkrete Anleitung für Inspektoren was in einem Softwaredokument zu überprüfen ist  i i S ft d k t h F hl d h h i t wie ein Softwaredokument nach Fehlern zu durchsuchen ist

Motto: Jeder Inspektor überprüft alles

Ineffiziente Inspektion(#gefundene Fehler / Zeit)(#gefundene Fehler / Zeit) 

Lesetechniken reduzieren die Probleme15

Lesetechniken: Erleichtern und unterstützen die Überprüfung l h f f kder Qualitätseigenschaften von Softwaredokumenten in einer 

Inspektion Ad h Ad‐hoc Keine weitere Unterstützung für Inspektor

Ch kli t Checklisten:  Der Inspektor bekommt eine Checkliste mit Fragen, die er beim Lesen 

beantworten soll

Perspektivenbasiertes Lesen/Szenariobasiertes Lesen:  Der Inspektor folgt einem Leseszenario. Dieses gibt bestimmte p g g

Aktivitäten vor, die während der Fehlersuche durchzuführen sind und fokussiert den Inspektor auf bestimmte Aspekte

Checklisten16

N FNo. Frage

Fragen das gesamte Dokument betreffendg g

1 Existiert zu jedem Use Case im Use Case Diagramm genau ein formell beschriebenerDiagramm genau ein formell beschriebener

Use Case und umgekehrt?

2 Ist das gewünschte System durch die2 Ist das gewünschte System durch die Gesamtheit der Use Cases vollständig

beschrieben?

Auszug aus einer Checkliste für Anforderungsdokumente

Hinweise zur Checklistenerstellung17

Formulierung von Fragen  Die Beantwortung der Frage mit „Nein“ bedeutet Fehler Nicht länger als eine Din A4 Seite (15 Fragen) Gliederung der Fragen nach Qualitätsaspekten/Struktur  Die Fragen beziehen sich auf häufige/wichtige Fehlerg g g Die Fragen können von „Richtlinien“ oder Qualitätszielen 

abgeleitet werden Aus der Literatur können nur Anregungen/Beispiele 

entnommen werden  Die Checkliste muss angepasst werden

Übung18

Entwickeln sie eine Checkliste zur Inspektion eines Anforderungsdokumentes. N h i E t i klNehmen sie zur Entwicklung dieser Checkliste ihre Unterlagen zum ThemaUnterlagen zum Thema „Anforderungen“ zur Hand und rufen sie sich ins Gedächtnis, was ein gutes Anforderungsdokument 

ht B ht i h diausmacht. Beachten sie auch die Hinweise zur Erstellung von ChecklistenChecklisten.

Fehlersuche mit Checklisten19

V hVorgehen: Anhand der Checklisten‐Fragen das 

Dokument untersuchen  Markieren eines Befundes im Dokument Eintragen der Nummer des Befundes in die 

ProblemlisteProblemliste Nummer des Befundes zum Fehler im 

Dokument schreiben Auf der Problemliste das Dokument, die 

Seite und die Zeile eintragen, in der sich der Befund befindet

Eine kurze Beschreibung des Befundes  durchführen.

Die Problemliste20

Inspektor: _______________Startzeit:__________________Endzeit: __________________Aufwand: _________________Dokument:Dokument: ________________

Nummer Seite Zeile # Kurze Beschreibung des Problems Verbesserungsvorschlag

13+.20

Perspektivenbasiertes Lesen (PBR)21

Wesentliche Eigenschaften von PBR: Leseszenarien geben konkrete Anleitung bei der Fehlersuche Inspektoren nehmen verschiedene Blickwinkel (Perspektiven) 

ein, die die Aufmerksamkeit auf verschiedene Aspekte fokussieren weniger Überlappung weniger Überlappung

Der Einfluss der Erfahrung von Inspektoren auf die Effektivität der Inspektion wird geringerder Inspektion wird geringer

Während der Inspektion wird aktiv mit dem Dokument gearbeitet Verständnis erhöht Ergebnisse kontrollierbargearbeitet  Verständnis erhöht, Ergebnisse kontrollierbar 

Leseszenarien22

Jeder Dokumentnutzer hat Qualitätsanforderungen an das k h llDokument. Diese hängen von der Rolle des 

Dokumentennutzers im Entwicklungsprozess ab.

Kunde

System-TesterTester

Dokument

Entwickler

Szenario ‐ Beispiel23

You should read the document from the perspective of a module tester. In doing so, take the code document and extract a controltester. In doing so, take the code document and extract a control flow graph: Aggregate suitable sequences of code, e.g., a sequence of statements. Make sure that all branches can be identified in your control flow graph. For building the control flow graph use the g p g g psymbols on the form “ symbols for test scenarios”. Document your control flow graph on the form “Results Module Test Scenario”.

Use the control flow graph to derive test cases: For each branch of Use the control flow graph to derive test cases: For each branch of the control flow graph and each calculation, develop a test or a set of tests that allow you to ensure the internal correctness of the code module. Document your test cases on the form “ResultsyModule Test Scenario”.

While performing the activities, ask yourself the followingquestions: q 1. Do you have all the information that is necessary to identify a test case 

(e.g., are all constant values and interfaces defined) ? 2. Are all data values used in a correct way?y( Quelle : http://www.ipd.uka.de/Tichy)

Übung24

Welche Perspektiven, würden sie zur Inspektion eines Architekturdokumentes 

f hlempfehlen Welche Aktivitäten sollten durch 

die entsprechenden Szenariendie entsprechenden Szenarien beschrieben werden, auf welche Qualitätsaspekte sollten dieQualitätsaspekte sollten die verschiedenen Inspektionen achten? 

Abdeckung und Überlappung25

Dokumentmit Fehlern

hohe Überlappungi Abd k

geringe Überlappungh h Abd kgeringe Abdeckung hohe Abdeckung

Reviews durch Inspektion –Zusammenfassung

26Zusammenfassung

Planung Fehler-suche Meeting Korrektur

Prozess• Organisator • Organisations-

Rollen Dokumente• Organisator

• Moderator

• Inspektor

Organisationsliste

• Problemliste• Fehlerliste

Inspektion

Lesetechniken• Autor

• (Schriftführer)

• Korrekturliste

• Ad-hocCh kli t b i t L• Checklistenbasiertes Lesen

• Perspektivenbasiertes Lesen

Zusammenfassung27

Reviews tragen bei zur Verbesserung und Bewertung der Dokumentqualität,  der Prozessqualität und 

K t d kti zur Kostenreduktion  plus: weitere Vorteile (z.B. Wissenstransfer)

Reviews sind auf allen Dokumenten im SW Lifecycle möglich Reviews sind auf allen Dokumenten im SW‐Lifecycle möglich Lesetechniken sind der zentraler Bestandteil von 

InspektionenInspektionen Inspektionen und Testen gemeinsam anwenden

Diskussion28

Vergleichen sie die beiden Methoden Testen und Inspektionen als Methoden der Q lität i h N iQualitätssicherung. Nennen sie mindestens vier Unterschiede/Vor‐ oderUnterschiede/Vor oder Nachteile der einen oder anderen Methode.

Testen versus Inspektionen29

Test benötigt ablauffähigen Code/ Inspektionen kann auch f k h f hauf Dokumenten durchgeführt werden

Testen ist erst spät möglich/Inspektionen können bereits in d A f d h d h füh t dder Anforderungsphase durchgeführt werden

Testen entdeckt Fehlverhalten/ Inspektionen entdecken die Fehler selbstFehler selbst

Testen: Isolation des Fehlers kostet zusätzlichen AufwandI k i fö d d Wi f i h Inspektionen fördern den Wissenstransfer zwischen Mitarbeitern

Literatur30

Tom Gilb & Dorothy Graham, Software Inspection,lAddison‐Wesley, 1993

www.software‐kompetenz.de