Empirische Softwaretechnik

1. Empirische Softwaretechnik Prof. Dr. Walter F. Tichy Dr. Frank Padberg Sommersemester 2007

2. Experiment über Prozess-verbesserung bei Inspektionen • Softwaretechnik: • Experiment untersucht und bewertet gängige Vorschläge zur Verbesserung des Ablaufs von Software-Inspektionen • Empirie und Statistik: • faktorieller Experimentaufbau • Median, Quartile und Boxplots • interne und externe Gültigkeit

3. Zeitlicher Ablauf einer Inspektion (schematisch) Schraffierte Blöcke bedeuten, dass Gutachter i oder Autor an der Entsprechenden Inspektions-Phase arbeitet, sonst etwas anderes macht.

4. Vorschläge zur Prozessverbesserung • möglichst viele Inspektoren • mehr als ein „Durchgang“ (session) • besser zwei Durchgänge mit kleinen Teams als ein Durchgang mit einem großen Team • vor jedem Durchgang die bisher gefundenen Fehler korrigieren • mit oder ohne Gruppensitzung • besondere Lesetechniken

5. Experiment von Porter, Siy, Toman und Votta (1997) • An Experiment to Assess the Cost-Benefits of Code Inspections in Large Scale Software Development • Ergebnis: Prozess-Struktur hat geringen Einfluss auf Effektivität und Gesamtdauer, sowie erwarteten Einfluss auf die Kosten • IEEE Transactions on Software Engineering TSE 23:6 (1997) 329-346

6. Experimentumfeld • echtes Feldexperiment (auch natürliches Experiment) • Lucent Technologies (früher: ATT Bell Labs) • reales Softwareprojekt • Code-Inspektionen zur Qualitätssicherung • professionelle Entwickler • üblicher Zeit- und Kostendruck • Kooperation mit University of Maryland

7. Experimentumfeld (Forts.) • reales Softwareprojekt • baue Übersetzer und Entwicklungsumgebung zur Unterstützung von 5ESS-Entwicklern (5ESS = Telephon-Vermittlungsstation) • 55K neuer Code (C++) • Juni 94 bis Dezember 95 • insgesamt 88 Code-Inspektionen

8. Experimentumfeld (Forts.) • professionelle Entwickler • 6 Entwickler im Projekt plus 11 Entwickler aus anderen Projekten als Inspektoren • jeder Entwickler seit mindestens 5 Jahren bei Lucent • Entwickler hatten vergleichbare Programmier-erfahrung (hauptsächlich in C) • Inspektionen sind Standard bei Lucent

9. Experimentumfeld (Forts.) • üblicher Zeit- und Kostendruck • sehr teure Inspektionstechniken konnten nicht durchgehend getestet werden (z.B. 2 Durchgänge mit je 4 Inspektoren) • ineffektive Inspektionstechniken mussten bald erkannt und aufgegeben werden

10. Experimentumfeld (Forts.) • Kooperation mit University of Maryland • Forscher als inspection quality engineer (IQE) • wählt Inspektionstechnik und Inspektoren aus • stellt Formulare bereit, sammelt sie ein und wertet sie aus • achtet auf Effektivität der Inspektionen

11. Änderungen an der Prozess-Struktur im Experiment • Anzahl der Inspektoren (1, 2, oder 4) • Anzahl der Durchgänge (1 oder 2) • bei zwei Durchgängen: mit Fehlerbeheben nach dem ersten Durchgang (repair) oder ohne (non-repair) • das sind die unabhängigen (kontrollierten) Variablen im Experiment • nicht kontrolliert: Lesetechnik

12. Beobachtete Größen im Experiment • Effektivität der Inspektion • Gesamtdauer der Inspektion • Aufwand für die Inspektion • das sind die abhängigen Variablen im Experiment

13. Effektivität einer Inspektion • Effektivität (defect detection ratio) = • Anzahl der tatsächlich enthaltenen Defekte muss geschätzt werden • Annahme im Experiment: Defektdichte (Defekte je tausend Zeilen Code) ist für alle Codestücke gleich, daher reicht es, nur die gefundenen Defekte pro 1000 Zeilen komentarlosen Codes zu vergleichen.

14. Gesamtdauer einer Inspektion • Zeitraum ab Beantragen einer Inspektion bis zur Abgabe des korrigierten Codestücks (inspection interval) • gemessen in Arbeitstagen (working days) • ohne Urlaubstage des Autors, wenn niemand an der Inspektion gearbeitet hat • mit Wochenendtagen, wenn jemand an der Inspektion gearbeitet hat

15. Gesamtdauer (Forts.) • Einschränkung im Experiment: Dauer nur bis zur Gruppensitzung (pre-meeting interval) • ohne Zeit für Fehlerbeheben durch den Autor • Autoren lassen Defektliste oft längere Zeit liegen • bei zwei Durchgängen: • Ohne Fehlerbehebung können die zwei Durchgänge auch gleichzeitig starten. • nehme den längeren der beiden Zeiträume.

16. Aufwand für eine Inspektion • Personalkosten (effort) • gemessen in Personenstunden je tausend Zeilen Code (person-hours per KNCSL) • NCSL = non-commentary source lines

17. Experimentaufbau • faktorieller Aufbau = mehrere Einflussfaktoren sind gleichzeitig variabel • Inspektoren (3 mögliche Werte) • Durchgänge (2) • mit oder ohne Fehlerbeheben (2) • ergibt Aufbau • Randbedingung: bei zwei Durchgängen haben die beiden Teams dieselbe Anzahl von Inspektoren

18. Experimentaufbau (Forts.) • treatment = eine bestimmte Kombination von Faktoren („Behandlung“) • Schreibweise: 1s4p = 1 session, 4 persons2s2pR = 2 sessions, 2 persons, repair2s2pN = 2 sessions, 2 persons, norepair • 1s4p ist Standard bei Lucent

19. Experimentaufbau (Forts.) • geplante Anteile der verschiedenen Faktor-Kombinationen an allen Inspektionen:

20. Experimentaufbau (Forts.) • partieller Aufbau = nicht alle Kombinationen werden getestet oder sind sinnvoll • die geplanten Anteile wurden nicht genau eingehalten, da ineffektive Techniken aufgegeben wurden

21. Nicht-kontrollierte Variablen • Lesetechnik frei wählbar • keine Zeitbeschränkung für individuelle Vorbereitungsphase (typisch bei Lucent: 2 Stunden) • Codestücke unterschiedlicher Länge (meist etwa 300 Zeilen)

22. Durchführung • Autor des Codestücks beantragt bei IQE (inspection quality engineer) eine Inspektion • IQE wählt zufällig .... • die Inspektionstechnik (treatment) • die Inspektoren • aber: Autor nie selbst Inspektor • IQE stellt benötigtes Material (Formulare, Code, Anleitung) bereit

23. Durchführung (Forts.) • Inspektoren untersuchen den Code • Gruppensitzung (vom Autor organisiert) • Autor klassifiziert und behebt die Defekte • IQE spricht mit dem Autor die Defektliste durch (wenn nötig) • IQE wertet alle Inspektionsformulare aus

24. Durchgeführte Inspektionen • insgesamt 88 Inspektionen • aufgegebene Techniken: 1s1p, 2s1pR, 2s2pR

25. Statistische Auswertung • viele paarweise Vergleiche, zum Beispiel Effektivität von1s1p vs. 1s2p vs. 1s4p • Stichprobenwerte bei festgehaltener Faktor-Kombination waren nicht normalverteilt • jeweils Wilcoxon-Test für die Hypothese, dass die in zwei verschiedenen Faktor-Kombinationen beobachteten Werte aus derselben Verteilung stammen

26. Auswertung (Forts.) • Problem: wir haben weder die Rohdaten noch die p-Werte der Wilcoxon-Tests • lediglich Aussagen der Autoren über die Signifikanz von Unterschieden .... • .... sowie Boxplots für die Stichproben zu den einzelnen Faktor-Kombinationen

27. Messung: Aufwand

28. Auswertung: Aufwand • signifikanter Einfluss der Zahl der insgesamt beteiligten Inspektoren (wie zu erwarten) • z.B. 1s1p < 1s2p < 1s4p • aber: 1s2p 2s1p sowie 2s2p 1s4p • Ergebnis: kein Hinweis auf Einfluss der Prozess-Struktur auf den Aufwand, mit Ausnahme der Gesamtzahl der Inspektoren

29. Messung: Intervall vor Sitzung

30. Auswertung: Intervall vor Sitzung • 2s2pR weicht nach oben ab, haben aber nur 4 Datenpunkte (Schlussfolgerung offen) • Sonst kein verlängertes Intervall durch 2 Durchgänge (Quartilbereiche überlappen) • Serialisierung der Durchgänge durch Reparatur (N vs. R) verlängert Intervall nur für 2-Personen-Teams • Ergebnis: kein Hinweis auf Einfluss der Prozess-Struktur auf Intervall liegt vor, außer bei 2s2pR

31. Klassifikation der Defekte • durch den Autor: false positives (vermeintliche Defekte), soft maintenance (Programmierkonventionen), true defects (echte Defekte) • im Schnitt waren nur ein Fünftel der gesammelten Schwachpunkte „echte“ Defekte • nur echte Defekte bei Berechnung der Effektivität der Inspektion berücksichtigt

32. Klassifikation (Forts.)

33. Messung: Effektivität

34. Auswertung: Effektivität • 1s1p weicht signifikant nach unten ab • 2s2pR weicht nach oben ab, haben aber nur 4 Datenpunkte (Schlussfolgerung offen) • Teamgröße: 1s2p ähnlich 1s4p (1s1p schlechter) • Durchgänge: bei Teamgröße 2 kein Unterschied (1s2p vs 2s2p); Unterschied nur bei Teamgröße 1 (1s1p vs 2s1p) • Kein Unterschied bei konstanter Gesamtanzahl von Inspektoren (1s2p vs 2s1p, sowie 1s4p vs 2s2p) • Reparatur zwischen Durchgängen: kein Unterschied für Teamgröße 1

35. Ergebnis: Effektivität • Mehr als zwei Inspektoren bringt nichts • Aufspalten eines großen Teams in zwei kleine Teams und zwei Durchgänge bringt nichts • Reparatur zwischen Durchgängen bringt nichts

36. Fazit des Experiments große Teams und mehrere Durchgänge bringen nicht viel versuche, Inspektionen durchbesondere Lesetechniken und Werkzeugunterstützungeffizienter zu machen !

37. Diskussion des Experiments • hoher Stellenwert • wichtige Forschungsfrage • überraschende Aussagen • lehrreicher Aufbau • mehrere kontrollierte Variablen • Durchführung in realer Produktionssituation • gründlich vorbereitet

38. Diskussion (Forts.) • einige Probleme in Aufbau und Auswertung • fragwürdige Annahme, dass die Defektdichte für alle Codestücke konstant ist • abgebrochene Inspektionstechniken • Inspektionen nur für Code • Einfluss der Lesetechnik nicht kontrolliert • interne und externe Gültigkeit?

39. Interne Gültigkeit • genau dann erreicht, wenn der beobachtete Effekt ausschließlich auf Verändern der unabhängigen Variable(n) zurückgeht • in der Praxis schwer zu erreichen, da meist nicht alle Einflussfaktoren kontrolliert oder gemessen werden können („Störvariablen“) • typisches Beispiel: unterschiedliches Vorwissen der Versuchpersonen

40. Interne Gültigkeit (Forts.) • wichtiges Ziel beim Experimentaufbau ist, Störvariablen vorher zu erkennen und ihren Einfluss auf den beobachteten Effekt konstant zu halten • bei der statistischen Auswertung wird dann versucht, den Einfluss der Störvariablen „herauszurechnen“ oder zu neutralisieren.

41. Interne Gültigkeit des Inspektions-Experiments • Auswahleffekte • Problem: unterschiedliches Können der Entwickler • Maßnahmen: • erfahrene Entwickler mit ähnlichen Kenntnissen • zufälliges Zusammenstellen der Inspektionsteams

42. Interne Gültigkeit des Inspektions-Experiments (Forts.) • Reifungseffekte • Problem: das Können der Entwickler nimmt im Verlauf des Experiments zu • Maßnahmen: • Gruppe der Inspektoren (6+11) ist stabil und hat Erfahrung mit Inspektionen • zufälliges Zusammenstellen der Inspektionsteams über alle Faktorenkombinationen, so dass alle Kombinationen gleichmäßig betroffen waren.

43. Interne Gültigkeit des Inspektions-Experiments (Forts.) • Instrumentierungseffekte • Problem: das bereitgestellte Material ändert sich (hier insbesondere die Größe und Qualität der untersuchten Codestücke) • Maßnahmen: • Formulare für jede Inspektion gleich • zufälliges Auswählen der eingesetzten Inspektionstechnik (Faktorkombination)

44. Interne Gültigkeit des Inspektions-Experiments (Forts.) • gänzlich unkontrollierte Variablen • Lesetechnik • Zeit für individuelle Fehlersuche (preparation phase) • Unterschiede im Prozess könnten durch Variation der unkontrollierten Variablen überlagert worden sein!

45. Externe Gültigkeit • umso größer, auf je mehr Situationen, die nicht genau mit dem Experimentumfeld übereinstimmen, das Ergebnis übertragbar ist („Generalisierung“) • in der Praxis meist eingeschränkt • typisches Beispiel: andere Firma mit anderem Entwicklungsprozess

46. Externe Gültigkeit des Inspektions-Experiments • Realitätsnähe: gefährdet, wenn die Experimentierumgebung oder die eingesetzten Materialien (z.B. die inspizierten Programme) nicht repräsentativ für die industrielle Praxis sind. • Hier ist die Realitätsnähe groß, da ein tatsächliches Projekt in echter Umgebung mit professionellen Entwicklern durchgeführt wurde.

47. Externe Gültigkeit des Inspektions-Experiments (Forts.) • Populationseffekte • Wie repräsentativ sind die Entwickler im Hinblick auf die gesamte Software-Industrie? • einige Diskussionspunkte: • professionelle Entwickler • relativ homogene und stabile Entwicklergruppe • Entwickler hatten Erfahrung mit Inspektionen

48. Externe Gültigkeit des Inspektions-Experiments (Forts.) • Umgebungseffekte • Wie repräsentativ ist das Experiment-Umfeld im Hinblick auf andere Software-Projekte? • einige Diskussionspunkte: • nur eine bestimmte Firma (Lucent) • nur Code-Inspektionen • etablierte Firma mit definiertem Entwicklungsprozess • Größe der Inspektionsteams

49. Ausblick • Auswertung des Experiments bez. Effektivität von Gruppensitzungen • Experimente zu Lesetechniken