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

Präsentation zum Thema: "1 Empirische Softwaretechnik Prof. Dr. Walter F. Tichy Dr. Frank Padberg Sommersemester 2007."—  Präsentation transkript:

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

2 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 18 Experimentaufbau (Forts.) treatment = eine bestimmte Kombination von Faktoren (Behandlung) Schreibweise: 1s4p = 1 session, 4 persons 2s2pR = 2 sessions, 2 persons, repair 2s2pN = 2 sessions, 2 persons, no repair 1s4p ist Standard bei Lucent

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

20 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 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 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 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 24 Durchgeführte Inspektionen insgesamt 88 Inspektionen aufgegebene Techniken: 1s1p, 2s1pR, 2s2pR

25 25 Statistische Auswertung viele paarweise Vergleiche, zum Beispiel Effektivität von 1s1p 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 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 27 Messung: Aufwand

28 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 29 Messung: Intervall vor Sitzung

30 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 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 32 Klassifikation (Forts.)

33 33 Messung: Effektivität

34 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 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 36 Fazit des Experiments große Teams und mehrere Durchgänge bringen nicht viel versuche, Inspektionen durch besondere Lesetechniken und Werkzeugunterstützung effizienter zu machen !

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

38 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 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 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 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 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 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 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 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 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 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 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 49 Ausblick Auswertung des Experiments bez. Effektivität von Gruppensitzungen Experimente zu Lesetechniken