software qualitÄtssicherung kapitel 6 …services.informatik.hs-mannheim.de/~schramm/see/... ·...
TRANSCRIPT
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