Empirische Softwaretechnik

Transkript

1 Empirische Softwaretechnik Prof. Dr. Walter F. Tichy Dr. Matthias Müller Sommersemester

2 Experimente über Lesetechniken für Software-Inspektionen 2

3 Gängige Lesetechniken Ad-hoc, also keine besondere Technik Prüflisten CBR = checklist-based reading Szenarien oder Perspektiven PBR = perspective-based reading 3

4 Prüflisten Liste mit Fragen zum Dokument Fragen sollen das Aufspüren von Defekten erleichtern jede Frage bezieht sich auf ein einzelnes Qualitätsmerkmal Fragen müssen abgehakt werden 4

5 Richtlinien für Prüflisten Sollen höchstens eine Seite lang sein sollen möglichst präzise Fragen stellen sollen typische Defekte widerspiegeln sollen nicht Fragen nach Defekten enthalten, die automatisch geprüft werden können Fragen sollen auf neuestem Stand sein 5

6 Probleme mit Prüflisten Fragen decken nicht alle Arten von Defekten ab. Fragen sind nicht auf die Anwendung zugeschnitten. Fragen fördern nicht das Programmverständnis. Fragen sind möglicherweise veraltet. 6

7 Probleme mit Prüflisten (Forts.) keine Hilfestellung, wie die Prüfliste abgearbeitet werden soll unklar, welche Zusatz-Informationen benötigt werden (z.b. Entwurf oder Anforderungsspezifikation) 7

8 Lese-Szenario kurze Beschreibung der Rolle, mit der gelesen werden soll Anleitung, in welchen Schritten das Dokument durchzuarbeiten ist kleiner Satz von unterstützenden Fragen 8

9 Szenarien-basierte Inspektion verschiedene Szenarien für die einzelnen Inspektoren jedes Szenario deckt andere Perspektive ab (z.b. Tester oder Entwerfer )... oder andere Klasse von Defekten (z.b. Datentyp-Inkonsistenz oder inkorrekte Funktionalität) 9

10 Klare Vorteile von Szenarien fokussieren die Aufmerksamkeit der Inspektoren vermeiden ein Überschwemmen der Inspektoren mit Fragen 10

11 Erhoffte Vorteile von Szenarien geringe Überlappung zwischen den Inspektoren breite Abdeckung der möglichen Defekte: Prüflisten Szenarien 11

12 Haben Szenarien tatsächlich diese Vorteile?! 12

13 1. Experiment: Perspektiven für Code 13

14 Experiment von Laitenberger und DeBaud (1997) Perspective-based Reading of Code Documents at Robert Bosch GmbH Ergebnis: Perspektiven als Lesetechnik unterstützen das Fehlerfinden bei Code- Inspektionen Journal on Information and Software Technology IST 39 (1997)

15 Eingesetzte Perspektiven Code-Analytiker: prüfe Konsistenz von Code, Entwurf und Spezifikation Modul-Tester: prüfe die innere Korrektheit des Moduls Integrationstester: prüfe die Schnittstellen des Moduls 15

16 Beispiel: Perspektive eines Modul-Testers [1] You should read the document from the perspective of a module tester. 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 symbols on the form symbols for test scenarios. Document your control flow graph on the form Results Module Test Scenario. 16

17 Beispiel: Perspektive eines Modul-Testers [2] 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. 17

18 Beispiel: Perspektive eines Modul-Testers [3] Simulate a run of the module by using the developed test cases as input values. Verify, whether the system behaves according to its specification. If differences occur, check whether there is a defect or not. 18

19 Beispiel: Perspektive eines Modul-Testers [4] 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? 19

20 Beispiel: Perspektive eines Modul-Testers [5] 3. Can you generate test cases for each branch of the control flow graph? Can you traverse all branches by using specific test cases? 4. Have you verified all calculations with test cases? Are the calculations performed correctly? 20

21 Untersuchte Fragen Wie effektiv sind die einzelnen Perspektiven? Wie groß ist die Überlappung zwischen den verschiedenen Perspektiven? Wie viele Defekte werden erst in der Gruppensitzung gefunden? 21

22 Fragen (Forts.) Helfen Perspektiven dabei, auch ohne genaue Vorkenntnis des Anwendungsgebiets Defekte zu finden? Helfen Perspektiven dabei, individuelle Leistungs- und Erfahrungsunterschiede der Inspektoren auszugleichen? 22

23 Fragen (Forts.) nicht untersucht: Effektivität von Perspektiven im Vergleich zu anderen Lesetechniken (etwa Prüflisten) 23

24 Experimentumfeld kontrolliertes Experiment im Rahmen von Trainingseinheiten zur Einführung von PBR in einer Abteilung bei Bosch durchgeführt von Fraunhofer IESE Code-Inspektionen (Sprache: C) 24

25 Teilnehmer 11 professionelle Entwickler bei Bosch hatten durchschnittlich 19 Monate Programmiererfahrung in C; einige hatten aber kaum C-Erfahrung wenig oder gar keine Erfahrung mit Inspektionen 25

26 Dokumente drei Dokumente von Bosch zwischen 10 und 15 Defekte waren den Teilnehmern nicht bekannt drei generische Dokumente blendet Erfahrung der Entwickler im Anwendungsgebiet aus zwischen 12 und 16 Defekte alle zwischen 200 und 300 Zeilen Defekte waren ursprünglich entdeckt und in die Dokumente wieder eingepflanzt worden. 26

27 Experimentaufbau faktorieller Aufbau: Dokumenttyp (2 mögliche Werte: generisch oder von Bosch) benutzte Perspektive (3 mögliche Werte: Code-Analytiker, Integrationstester, Modultester) ergibt Aufbau

28 Experimentaufbau (Forts.) jeder Teilnehmer sollte jede der drei Perspektiven benutzt haben, und zwar sowohl auf einem generischen als auch auf einem Bosch-Dokument insgesamt 6 Inspektionen je Teilnehmer die (ursprünglich 15) Teilnehmer wurden zufällig durchnumeriert 28

29 Experimentaufbau (Forts.) Dokumente und Perspektiven wurden dann nach folgendem Schema zugeteilt: Etwas unausgeglichen, da von 15 geplanten Teilnehmern nur 11 ganz mitmachten. 29

30 Durchführung erster Tag: Einführung in Inspektionen und PBR Inspektion der drei generischen Dokumente, mit jeweils einer anderen Methode jeweils 2 Stunden individuelle Fehlersuche Gruppensitzungen mit jeweils drei Teilnehmern pro Dokument, so dass alle drei Perspektiven vertreten waren. zweiter Tag: Inspektion der drei Bosch-Dokumente... Gruppensitzungen Fragebogen 30

31 Ergebnis: Effektivität der Perspektiven normalisierte Erkennungsrate: 31

32 Ergebnis: Effektivität der Perspektiven (Forts.) Mediane und Streuungen für die drei Perspektiven sind ähnlich nebenbei: die Gesamtrate ( meeting ) ist deutlich höher als für die einzelnen Perspektiven; das deutet auf geringe Überlappung zwischen Perspektiven hin 32

33 Ergebnis: Überlappung durchschnittliche Erkennungsraten: 33

34 Ergebnis: Überlappung (Forts.) 31 % der Defekte werden von einzelnen Inspektoren gefunden, etwa 17% von mehreren; nur 6% in der Gruppensitzung. jede der drei Perspektiven hat spürbar zum Fehlerfinden beigetragen die Überlappung zwischen den Perspektiven ist eher gering Fehlersuche ist eher eine individuelle als eine Gruppen-Aktivität 34

35 Ergebnis: Erkennungsrate vs. C-Erfahrung durchschnittliche Erkennungsrate: 35

36 Ergebnis: Erkennungsrate vs. C-Erfahrung (Forts.) null Monate C-Erfahrung bedeutet: nur an einem C-Training teilgenommen Graphik zeigt: auch in C unerfahrene Inspektoren konnten mit Perspektiven eine hohe Erkennungsrate erreichen 36

37 Ergebnis: Erkennungsrate vs. Anwendungserfahrung durchschnittliche Erkennungsrate: 37

38 Ergebnis: Erkennungsrate vs. Anwendungserfahrung (Forts.) dabei natürlich nur Bosch-Dokumente berücksichtigt null Monate Erfahrung bedeutet: gerade begonnen, in diesem Anwendungsgebiet zu programmieren Graphik zeigt: auch unerfahrene Inspektoren konnten mit Perspektiven eine hohe Erkennungsrate erreichen 38

39 Interne Gültigkeit Sterblichkeit: einige Teilnehmer sind zwischendurch ausgeschieden, dadurch unbalancierte Aufteilung. Reifung: Müdigkeit durch ganztägige Veranstaltung; Lernen im Verlauf des Experiments Historie: es lag ein Tag Pause zwischen den beiden Experimentabschnitten 39

40 Externe Gültigkeit nur wenige Datenpunkte reale Dokumente professionelle Entwickler, aber zum Teil nur geringe C-Kenntnisse kaum Kenntnisse über Inspektionen 40

41 Verbesserungsvorschlag der Autoren mittlere Erkennungsrate bei generischen Dokumenten war etwas höher als bei Bosch-Dokumenten daher: Perspektiven sollten auf die Art der untersuchten Dokumente zugeschnitten werden 41

42 2. Experiment: Perspektiven für Code im Vergleich zu Prüflisten 42

43 Experiment von Laitenberger, El Emam und Harbich (2001) An Internally Replicated Quasi-Experimental Comparison of Checklist and Perspectivebased Reading of Code Documents Ergebnis: Perspektiven als Lesetechnik sind effektiver und kostengünstiger als Prüflisten IEEE Transactions on Software Engineering TSE 27:5 (2001)

44 Untersuchte Fragen Sind Inspektionen mit Perspektiven effektiver als mit Prüflisten? Sind Inspektionen mit Perspektiven teurer als mit Prüflisten? Fördern Perspektiven das Programmverständnis? 44

45 Experimentumfeld Experiment im Rahmen von Schulungen zu Inspektionen bei Bosch Telecom zwischen März und Juli 1998 durchgeführt von Fraunhofer IESE Code-Inspektionen (Sprache: C) 45

46 Teilnehmer 60 professionelle Entwickler bei Bosch Programmiererfahrung in C: experienced (Median) Erfahrung im Anwendungsgebiet: rather experienced (Median) 46

47 Dokumente sechs Dokumente von Bosch waren bereits in Verwendung galten als fehlerfrei waren den Teilnehmern (mit zwei Ausnahmen) nicht bekannt dazu Anforderungsspezifikation realistische Defekte von Experten in die Codestücke eingebaut 47

48 Dokumente (Forts.) zwischen etwa 400 und 900 Zeilen zwischen 8 und 16 eingebaute Defekte 48

49 Experimentaufbau Experiment plus zwei Replikationen insgesamt also drei Durchläufe mit je 20 Teilnehmern in jedem Durchlauf zwei Gruppen mit je 10 Inspektoren dabei 2-Personen-Inspektionen 49

50 Warum 2-Personen- Inspektionen? minimale Teamgröße spart Kosten [Porter ea. TSE 1997] hatten gezeigt, daß 4 Inspektoren nicht effektiver sind als 2 (allerdings: Lesetechnik wurde nicht kontrolliert) die beiden Tester-Perspektiven aus [Laitenberger ea. IST 1997] ließen sich gut zusammenführen 50

51 Eingesetzte Perspektiven Code-Analytiker: implementiert der Code die richtige Funktionalität? Tester: arbeitet die Implementierung korrekt? 51

52 Beispiel: Perspektive eines Code-Analytikers [1] Assume you have the role of a code analyst. As a code analyst you have to ensure that the right functionality is implemented in the code. In doing so, take the code document and determine the functions that are implemented in this code module. Determine the dependencies among these functions and document them in the form of a call graph. 52

53 Beispiel: Perspektive eines Code-Analytikers [2] Starting with the functions at the leaves of the call graph, determine the implemented operation of each function in the following manner. Identify (sequences of) assignment operations and highlight them. Determine the meaning of these (sequences of) assignment operations. Combine the (sequences of) assignment operations by taking into account conditions and loops. Determine the meaning of the larger structures. 53

54 Beispiel: Perspektive eines Code-Analytikers [3] Repeat this until you have determined the operation that is implemented in a function. Document the operation of each function. Hint: It is useful to describe the different levels of abstraction as formally as possible. Using implicit knowledge, such as assumptions of global variable values, should be avoided. 54

55 Beispiel: Perspektive eines Code-Analytikers [4] Check for each function, whether your description matches the description that is given in code comments and the description in the specification. If differences exist, check whether there is a defect. Document each defect you detect on the defect report form. 55

56 Beispiel: Perspektive eines Code-Analytikers [5] While following the instructions, ask yourself the following questions: 1. Does the operation described in the code match the one described in the specification? 2. Are there operations described in the specification that are not implemented? 56

57 Beispiel: Perspektive eines Code-Analytikers [6] 3. Is data (i.e., constants and variables) used in a correct manner? 4. Are all the calculations performed in a correct manner? 5. Are interfaces between functions used correctly? 57

58 Benutzte Prüfliste insgesamt 27 Fragen auf einer Seite generisch, also typische C-Fehler Ausschnitt: 58

59 Gegenbalancierter Aufbau kombiniere jede Aufgabe mit jeder Methode setze jede mögliche Kombination aus Aufgabe und Methode an jede Stelle im Versuchsplan 59

60 Experimentaufbau (Forts.) faktorieller gegenbalancierter Aufbau: Lesetechnik (Perspektiven oder Prüfliste) untersuchtes Dokument (zwei je Durchlauf) ergibt Aufbau 2 2 z.b. bei der ersten Replikation: 60

61 Durchführung jeder Durchlauf über sechs Tage: drei für die erste 10-er Gruppe und danach drei für die zweite 10-er Gruppe Teilnahme nach Terminkalender quasi -Experiment: keine Kontrolle über Zusammensetzung der 10-er Gruppen anders gesagt: keine (vollständige) Randomisierung 61

62 Durchführung (Forts.) jeder Durchlauf nach dem Schema: 62

63 Zur Statistischen Analyse keine Übertragungseffekte nachweisbar also getrennte Analyse der Durchläufe zulässig t-test für jeden Durchlauf dann Homogenitätstest für die Durchläufe keine Inhomogenität nachweisbar, also gemeinsame Analyse zulässig statistische Kombination der p-werte (Meta- Analyse, da unterschiedliche Dokumente benutzt) 63

64 Ergebnis: Effektivität der Techniken im 1. Durchlauf Perspektiven sind besser als die Prüfliste (p < 1%) 64

65 Ergebnis: Effektivität der Techniken im 2. Durchlauf Perspektiven sind eher besser als die Prüfliste (p = 10%) 65

66 Ergebnis: Effektivität der Techniken im 3. Durchlauf Perspektiven sind besser als die Prüfliste (p = 2%) 66

67 Ergebnis: gemeinsame Analyse der Effektivität Perspektiven-basiertes Lesen hat signifikant höhere Erkennungsrate als Prüflisten (α = 0,1) 67

68 Ergebnis: Kosten durchschnittliche Zeit zur Fehlersuche der Inspektoren, in Minuten: mit den Perspektiven wird i.a. mehr Zeit gebraucht, aber es werden auch mehr Defekte gefunden! 68

69 Ergebnis: Kosten je Defekt im 1. Durchlauf Perspektiven sind eher besser als die Prüfliste (p = 11%) 69

70 Ergebnis: Kosten je Defekt im 2. Durchlauf Perspektiven sind besser als die Prüfliste (p = 4%) 70

71 Ergebnis: Kosten je Defekt im 3. Durchlauf Perspektiven sind nicht besser als die Prüfliste (p = 23%) 71

72 Ergebnis: gemeinsame Analyse der Kosten je Defekt Perspektiven-basiertes Lesen hat signifikant günstigere Kosten je Defekt als Prüflisten (α = 0,1) 72

73 Ergebnis: Programmverständnis helps improve my understanding of the code : 73

74 Interne Gültigkeit keine echte Randomisierung ( intact groups ) Reihenfolge-Effekt: beide Lesetechniken sind präskriptiv (das heißt, geben eine Arbeitsvorschrift); bei präskriptiven Anweisungen ist der Reihenfolge-Effekt weniger wahrscheinlich als in Fällen, wo eine Anweisung nicht präskriptiv ist (z.b. Durchsichten ohne genauere Anweisung). Güte oft erst mit Zusammenlegen der Ergebnisse der Durchläufe 74

75 Externe Gültigkeit reale Code-Dokumente nur eine Firma professionelle Entwickler keine Vorkenntnisse über Inspektionen 75

76 Fazit benutze Perspektiven und spezialisierte Prüflisten als Lesetechnik! schneide die Lesetechnik auf die Art der Dokumente und die Firma zu! 76

77 ENDE 77