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

Empirische Softwaretechnik

  • Upload
    alden

  • View
    37

  • Download
    0

Embed Size (px)

DESCRIPTION

Empirische Softwaretechnik. Prof. Dr. Walter F. Tichy Dr. Frank Padberg. Sommersemester 2007. Experiment über Prozess-verbesserung bei Inspektionen. Softwaretechnik : Experiment untersucht und bewertet gängige Vorschläge zur Verbesserung des Ablaufs von Software-Inspektionen - PowerPoint PPT Presentation

Citation preview

Page 1: Empirische Softwaretechnik

1

Empirische Softwaretechnik

Prof. Dr. Walter F. TichyDr. Frank Padberg

Sommersemester 2007

Page 2: Empirische Softwaretechnik

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

Page 3: Empirische Softwaretechnik

3

Zeitlicher Ablauf einer Inspektion (schematisch)

Schraffierte Blöcke bedeuten, dass Gutachter i oder Autor an derEntsprechenden Inspektions-Phase arbeitet, sonst etwas anderes macht.

Page 4: Empirische Softwaretechnik

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

Page 5: Empirische Softwaretechnik

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

Page 6: Empirische Softwaretechnik

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

Page 7: Empirische Softwaretechnik

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

Page 8: Empirische Softwaretechnik

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

Page 9: Empirische Softwaretechnik

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

Page 10: Empirische Softwaretechnik

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

Page 11: Empirische Softwaretechnik

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

Page 12: Empirische Softwaretechnik

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

Page 13: Empirische Softwaretechnik

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.

Defekte nenthaltene der Anzahl

Defekte gefundenen der Anzahl

Page 14: Empirische Softwaretechnik

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

Page 15: Empirische Softwaretechnik

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.

Page 16: Empirische Softwaretechnik

16

Aufwand für eine Inspektion

Personalkosten (effort)

gemessen in Personenstunden je tausend Zeilen Code (person-hours per KNCSL)

NCSL = non-commentary source lines

Page 17: Empirische Softwaretechnik

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

223

Page 18: Empirische Softwaretechnik

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

Page 19: Empirische Softwaretechnik

19

Experimentaufbau (Forts.)

geplante Anteile der verschiedenen Faktor-Kombinationen an allen Inspektionen:

Page 20: Empirische Softwaretechnik

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

Page 21: Empirische Softwaretechnik

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)

Page 22: Empirische Softwaretechnik

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

Page 23: Empirische Softwaretechnik

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

Page 24: Empirische Softwaretechnik

24

Durchgeführte Inspektionen

insgesamt 88 Inspektionen

aufgegebene Techniken: 1s1p, 2s1pR, 2s2pR

Page 25: Empirische Softwaretechnik

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

Page 26: Empirische Softwaretechnik

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

Page 27: Empirische Softwaretechnik

27

Messung: Aufwand

Page 28: Empirische Softwaretechnik

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

Page 29: Empirische Softwaretechnik

29

Messung: Intervall vor Sitzung

Page 30: Empirische Softwaretechnik

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

Page 31: Empirische Softwaretechnik

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

Page 32: Empirische Softwaretechnik

32

Klassifikation (Forts.)

Page 33: Empirische Softwaretechnik

33

Messung: Effektivität

Page 34: Empirische Softwaretechnik

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

Page 35: Empirische Softwaretechnik

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

Page 36: Empirische Softwaretechnik

36

Fazit des Experiments

große Teams und mehrere Durchgänge bringen nicht viel

versuche, Inspektionen durchbesondere Lesetechniken und

Werkzeugunterstützung effizienter zu machen !

Page 37: Empirische Softwaretechnik

37

Diskussion des Experiments

hoher Stellenwert wichtige Forschungsfrage überraschende Aussagen

lehrreicher Aufbau mehrere kontrollierte Variablen Durchführung in realer Produktionssituation gründlich vorbereitet

Page 38: Empirische Softwaretechnik

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 ?

Page 39: Empirische Softwaretechnik

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

Page 40: Empirische Softwaretechnik

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.

Page 41: Empirische Softwaretechnik

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

Page 42: Empirische Softwaretechnik

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.

Page 43: Empirische Softwaretechnik

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)

Page 44: Empirische Softwaretechnik

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 !

Page 45: Empirische Softwaretechnik

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

Page 46: Empirische Softwaretechnik

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.

Page 47: Empirische Softwaretechnik

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

Page 48: Empirische Softwaretechnik

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

Page 49: Empirische Softwaretechnik

49

Ausblick

Auswertung des Experiments bez. Effektivität von Gruppensitzungen

Experimente zu Lesetechniken