SOFTWARE QUALITÄTSSICHERUNG UND PRÜFUNG TEIL 2

Transkript

1 Kapitel 6 SOFTWARE QUALITÄTSSICHERUNG UND PRÜFUNG TEIL 2 Software Engineering Prof. Dr. Wolfgang Schramm

2 Übersicht 1 1. Einführung in das Software Engineering 2. Softwareprozesse 3. Anforderungsanalyse und Spezifikation 4. Softwareentwurf 5. Programmierung 6. Software Qualitätssicherung und Prüfung 7. Konfigurationsverwaltung 8. Software Wartung

3 Kapitelübersicht 2 1. Einführung/Definition 2. Testen Teststrategien Vorgehen beim Testen Testautomatisierung 3. Statische Verfahren Übersicht zu verschiedenen Verfahren Software Inspektionen

4 Software Reviews 3 Es besteht Bedarf an ergänzenden Methoden zur Entdeckung und Beseitigung von Fehlern: => Reviews Reviews können das Testen nicht ersetzen, und umgekehrt!

5 Software Reviews 4 Ohne Reviews Fehler-Ursprung Anford. Design Code Test Wartung Fehler-Entdeckung Anford. Design Code Test Wartung Chaos Mit Reviews (ideal) Anford. Design Code Test Wartung Fehler-Ursprung Fehler-Entdeckung Anford. Design Code Test Wartung

6 Übersicht über Review Techniken 5 Sehr formal Weniger formal Inspektion Team Review Walkthrough Pair Programming Peer Desk-Checking Ad-hoc Empirische Studien belegen Inspektionen als die zuverlässigste Review Technik. Inspektionen finden 50% mehr Fehler als Walkthroughs Inspektionen finden bis zu 6x mehr Fehler als Ad hoc Reviews

7 Übersicht über Review Techniken 6 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 Peer Desk Checking Ähnlich Ad hoc Review Der Mitarbeiter führt das zu überprüfende Produkt auf dem Papier aus (meistens Code)

8 Übersicht über Review Techniken 7 Pair Programming 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 wesentlichen Teile des Dokuments zu fokussieren.

9 Inspektion Eigenschaften 9 Welche Aktivitäten werden innerhalb des Inspektionsprozesses ausgeführt? Welche Rollen sind in den Inspektionsprozess involviert? Rollen Prozess Inspektion Lesetechniken Dokumente Welche Dokumente werden in einer Inspektion verwendet? Welche Techniken können eingesetzt werden, um Fehler in einem Softwaredokument zu finden?

10 Der Prozess und die Rollen 10 Planung Til Teilnehmer einladen, Terminvereinbarung von allen Kick-off Inspektionsaktivitäten, Räume festlegen Organisator Vorbereitung Suche nach und Dokumentation von Problemen (d.h. potentielle Fehlern / Fragen / Verbesserungsvorschläge) Inspektoren Meeting Sammeln der Fehler. Entscheiden, ob ein Befund ein tatsächlicher Fehler ist. Suche nach weiteren Fehlern. Entscheiden über Re Inspektion. Korrektur Moderator//Autor/Inspektoren / Korrektur der Fehler Autor Follow-up

11 Inspektionsdokumente 11 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)

12 Bedeutung der Dokumente 12 Ergebnisse einer Inspektion Verbessertes Softwaredokument Dokumentierte Information zur Charakterisierung des inspizierten Dokumentes des Inspektionsprozesses des Software Entwicklungsprozesses ngspro esses Verwendung der Ergebnisse Hilfe für den Autor bei der Überarbeitung seines Dokumentes Charakterisierung / Beurteilung / Vorhersage / Verbesserung des Inspektions und Softwareentwicklungsprozesses und nicht der daran beteiligten Personen!

13 Aktivitäten der Vorbereitungsphase 13 Dokument wird von den Inspektoren nach Befunden durchsucht (Individuaktivität) Fehler werden dokumentiert Ziel: möglichst viele schwere Fehler finden

14 Probleme der Vorbereitungsphase 14 Es gibt oft keine konkrete k Anleitung für Inspektoren was in einem Softwaredokument zu überprüfen ist wie ein Softwaredokument tnach Fehlern Fhl zu durchsuchen h ist it Motto: Jeder Inspektor überprüft alles Ineffiziente Inspektion (#gefundene Fehler / Zeit)

15 Lesetechniken reduzieren die Probleme 15 Lesetechniken: Erleichtern und unterstützen die Überprüfung der Qualitätseigenschaften von Softwaredokumenten in einer Inspektion Ad hoc Keine weitere Unterstützung für Inspektor 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

16 Checklisten 16 No. Frage Fragen das gesamte Dokument betreffend 1 Existiert zu jedem Use Case im Use Case Diagramm genau ein formell beschriebener Use Case und umgekehrt? 2 Ist das gewünschte System durch die Gesamtheit der Use Cases vollständig beschrieben? Auszug aus einer Checkliste für Anforderungsdokumente

17 Hinweise zur Checklistenerstellung 17 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 g Fehler 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

18 Übung 18 Entwickeln sie eine Checkliste zur Inspektion eines Anforderungsdokumentes. Nh Nehmen sie zur Entwicklung dieser Checkliste ihre Unterlagen zum Thema Anforderungen zur Hand und rufen sie sich ins Gedächtnis, was ein gutes Anforderungsdokument ausmacht. Beachten sie auch die Hinweise zur Erstellung von Checklisten.

19 Fehlersuche mit Checklisten 19 Vorgehen: Anhand der Checklisten Fragen das Dokument untersuchen Markieren eines Befundes im Dokument Eintragen der Nummer des Befundes in die Problemliste 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.

20 Die Problemliste 20 Inspektor: Startzeit: Endzeit: Aufwand: Dokument: Nummer Seite Zeile # Kurze Beschreibung des Problems Verbesserungsvorschlag

21 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 Der Einfluss der Erfahrung von Inspektoren auf die Effektivität der Inspektion wird geringer Während der Inspektion wird aktiv mit dem Dokument gearbeitet Verständnis erhöht, Ergebnisse kontrollierbar

22 Leseszenarien 22 Jeder Dokumentnutzer hat Qualitätsanforderungen an das Dokument. Diese hängen von der Rolle des Dokumentennutzers im Entwicklungsprozess ab. Kunde System- Tester Dokument Entwickler

23 23 Szenario Beispiel You should read the document from the perspective of a module tester. In doing so, take the code documentandextract 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 symbols 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 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 Results Module Test Scenario. While performing the activities, ask yourself the following questions: 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? ( Quelle :

24 Übung 24 Welche Perspektiven, würden sie zur Inspektion eines Architekturdokumentes empfehlen fhl Welche Aktivitäten sollten durch die entsprechenden Szenarien beschrieben werden, auf welche Qualitätsaspekte sollten die verschiedenen Inspektionen achten?

25 Abdeckung und Überlappung 25 Dokument mit Fehlern hohe Überlappung geringe Abdeckung geringe Überlappung hohe h Abdeckung

26 26 Reviews durch Inspektion Zusammenfassung Planung Fehlersuche Meeting Korrektur Organisator Moderator Inspektor Autor (Schriftführer) Rollen Prozess Inspektion Lesetechniken Ad-hoc Checklistenbasiertes i t Lesen Dokumente Perspektivenbasiertes Lesen Organisations- liste Problemliste Fehlerliste Korrekturliste

27 Zusammenfassung 27 Reviews tragen bei zur Verbesserung und Bewertung der Dokumentqualität, der Prozessqualität und zur Kostenreduktion plus: weitere Vorteile (z.b. Wissenstransfer) Reviews sind auf allen Dokumenten im SW Lifecycle möglich Lesetechniken sind der zentraler Bestandteil von Inspektionen Inspektionen und Testen gemeinsam anwenden

28 Diskussion 28 Vergleichen sie die beiden Methoden Testen und Inspektionen als Methoden der Qualitätssicherung. i Nennen sie mindestens vier Unterschiede/Vor oder Nachteile der einen oder anderen Methode.

29 Testen versus Inspektionen 29 Test benötigt ablauffähigen Code/ Inspektionen kann auch auf Dokumenten durchgeführt h werden Testen ist erst spät möglich/inspektionen können bereits in der Anforderungsphase durchgeführt werden Testen entdeckt Fehlverhalten/ Inspektionen entdecken die Fehler selbst Testen: Isolation des Fehlers kostet zusätzlichen Aufwand Inspektionen fördern den Wissenstransfer zwischen Mitarbeitern

30 Literatur 30 Tom Gilb & Dorothy Graham, Software Inspection, Addison Wesley, kompetenz.de