empirische softwaretechnik
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 PresentationTRANSCRIPT
1
Empirische Softwaretechnik
Prof. Dr. Walter F. TichyDr. 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 derEntsprechenden 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.
Defekte nenthaltene der Anzahl
Defekte gefundenen der Anzahl
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
223
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
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 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
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ützung effizienter 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