Inspektionen

• #Anzahl Inspektoren: 2, Grund: Bildung von Expertenpaaren
• Lesetechniken: Szenarien, Grund: Trainingseffekt + besseres Wissen über Defekttypen
• Gruppensitzung: meist keine neuen Defekte, Grund: nicht primäre Aufgabe (Defekte unterdrückt wegen soziale Prozesse + Zeitprobleme)
• Probleme Prüflisten: Decken nicht alle Probleme ab, anwendungsspezifisch, erhöhen Programmverständnis nicht
• PBR: Perspektiven auf Dokumente zuschneiden

An Experiment to Assess the Cost-Benefits of Code Inspections in Large Scale Software Development

• Umfeld: professionelle Entwickler, kommerzielle Software, 55K neue C++ Zeilen, 6 interne 5 externe Inspektoren (5 Jahre Erfahrung), Dauer: 18 Monate, 88 Inspektionen
• typischer Ablauf: Preparation, Sammeln, Reparatur
• Fokus: Defekterkennung (zB. nicht Stil, nur Funktionalität)
• $2^2$ x 3 partielle faktorielles Design (zufällige Zuweisung, Behandlung unterschiedlich wahrscheinlich)
• unabh. Variablen: #Reviewer pro Gruppe, #Sessions, Koordination zwischen Sessions (nicht: Defekterkennungsmethode)
• abh. Variable: benötigte Zeit, Aufwand, Errorerkennungsrate, Treffenverstärkungsrate, Treffenunterdrückungsrate
• Inspektionsintervallmodell: Anfang: Codeeinheit fertig, Ende: erkannte Defekte repariert
• Defekterkennungsverhältnis: gefundene Defekte / KNCSL
• Analysestrategie: Auflösungsanalyse (~5 pro Kombination), Kalibrierung, Hypothesentest
• Instrementierung: Datensammlungsformular, Authorreparationsformular
• Signifikanztest: Wilcoxischer Ranksumme $\geq 0.9$, Mediane statt Mittel
• Datenreduktion: defekte Daten (zB. Duplikate), Intervallanpassung (spätere Reparatur, nicht Werktage entfernen)
• Hypothesen
  1. Teamgröße+ --> längere Inspektionsintervalle + nicht mehr gefundene Defekte
  2. Multi-session > single-session Inspektionen + MSI längere Inspektionsintervalle
  3. sequentielle MSI (Fehler in i. Sitzung gefixt vor i + 1) längere Intervalle + Defekterkennungrate+ gegenüber parallelen MSI
• Ergebnisse
  • H1: 4 $\approx$ 2, 1 viel schlechter
  • H2: 2-session $\approx$ single-session
  • H3: kein Effekt auf Defektdichte, aber Intervall+
  • ca. 50% false positives, 35-40% nichtfunktional / Wartbarkeit, nur 13% Defekte
  • 30% Treffenverstärkungen
  • Fazit: wichtigste: Defekterkennungstechniken (nicht Organisation)
• Gültigkeitsbedrohungen
  • intern: Selektion, Reifung, Instrumentierung (selbe Codeeinheit) kontrolliert, Experimentatoreffekt (ungleiche Verteilung der Behandlungen), einige Kombinationen eingestellt (zu ineffektiv || lang), vorher an 1s4p gewöhnt
  • extern: Versuchsmaßstab, Subjektgeneralisierung kontrolliert, verletzt: Repräsentativität (gleiches Unternehmen)
  • Konstrukt: Defekterkennungsverhältnis nicht aussagekräftig, Behandlungen aufgehört, nicht parametrische Techniken

An Internally Replicated Quasi-Experimental Comparison of Checklist and Perspectivebased Reading of Code Documents

• Quasi-Experiment, Feldexperiment, 2 Replikationen, 60 prof. Entwickler (20 pro "run", 10 pro Gruppe, erfahren in Inspektionen, 2-Personen-Inspektionen), Teil eines Trainingskurses, 6 Tage pro Run
• Replikationen: Güte / Generalisierbarkeit erhöhen (selber Trainer)
• Aufbau: 2x2 faktorielle, counterbalanced mehrfache Messungen
• Defektdetektion: eher individuelle Aktivität, "Hauptaktivität"
• Probleme CBR: basiert auf alten Defektinformationen, enthält oft zu viele Fragen, keine Analysedokumentation, jeder alle Fragen
• unabh. Variablen: Technik (PBR || CBR), Reihenfolge (CBR > PBR || PBR > CBR)
• abh. Variablen: Teamdefekterkennungseffektivität, Kosten (Detektion, Treffen, generell)
• Hypothesen
  1. $D(CBR) < D(PBR)$ (Effektivität)
  2. $e_i(PBR) \geq e_i(CBR)$ (Defektdetektionskosten)
  3. $m(CBR) > m(PBR)$ (Treffenkosten)
  4. generelle Kosten
• CBR: 27 Fragen (eine Seite), Schema: "where to look" + "how to detect", abgeleitet aus anderen Checklisten
• PBR: Szenario = Einleitung + Anleitung + Fragen (Codeanalyst- + Testerperspektive, Ableitung deterministisch)
• Einschränkungen (Trainingsumgebung): jeder erhält Behandlung, keine Kontrollgruppe, natürliche Gruppenbildung (nicht randomisiert)
• nach Trainingssession: Fragebogen
• Tests auf: Reihenfolge-Effekt, t-Tets, Homogenitätstest, stat. Kombination der p-Werte
• Ergebnisse
  • H1: PBR > CBR (2/3, aber Widersprüchliche geringe Effektgröße)
  • H2: CBR > PBR (2/3, aber PBR besserer Kosten/Defekt)
  • H3: PBR > CBR
  • H4: PBR > CBR (2/3)
  • PBR erhöht Codeverständnis (nach Fragebögen)
• Gültigkeitsbedrohungen
  • intern: Selektion (keine zufälligen Gruppen), Autor fügt Defekte ein (--> künstlich), Historie, kein Möglichkeit Technik zu erzwingen, Reihenfolge-Effekt
  • extern: eine Organisation, Inspektionsprozess als Individuumsprozess (statt Gruppen), Dokumente (nur Code überprüft), keine Vorkenntnisse
  • Konstrukt: ver. Codemodule innerhalb /zwischen Runs, Confounding (Interaktionen nicht separierbar von Gruppeneffekt)
  • $\alpha = 0.1$ + nur Quasi-Experiment
  • Subjekte präferieren CBR (alte Gewohnheiten?)

Perspective-based Reading of Code Documents at Robert Bosch GmbH

• 2 (Dokumenttyp) x 3 (Perspektive) faktorielles wiederholte Messungen Experiment, 2 Trainings-Sessions, reelle Fehler (wieder eingepflanzt)
• Teilnehmer: 11 prof. Entwickler (5 erster Run, 6 zweiten Run), durchschn. 19 Monate Erfahrung in C (ein Ausreißer), alle keine / wenig Erfahrung mit Inspektionen
• unabh. Variablen: Domänne (generisch, Unternehmen), Perspektiven (Analyst, Modultest, Integrationstest)
• abh. Variablen: # gefunde Defekte pro Teilnehmer
• reelle Fehler wiedereingefügt
• Ablauf: Teilnehmer alle 3 Perspektiven auf 3 generische / 3 spez. Module
• Hypothesen
  1. Einfluss Domäne / Szenario / Interaktionseffekt (Domäne x Szenario)
  2. Effektivität der Defekterkennung
  3. Überlappung der Perspektiven
• Ergebnisse
  • PBR untersützt Fehlerfinden, kein Vergleich zu anderen Lesetechniken
  • PBR + Dokumenttyp beeinflussen individuelle Defekterkennung (H1.3)
  • n-individuelle Treffen nicht nützlich ($\alpha = 0.05$), Fehlersuche = individuelle Aktivität
  • Überlappung ver. Perspektiven gering > jede trägt spürbar bei
  • kein sig. Unterschied ob erfahren in Domäne / Inspektionen (keiner mehr als 5) / Programmiersprache oder nicht
• Gültigkeitsbedrohungen
  • intern: Sterblichkeit (-2), Reifung (Lerneffekt unkontrolliert (keine KG), Müdigkeit), Subjekteffekt (Teilnehmer motiviert, 7 präferieren PBR), order effect unkontrolliert, Historie (Tag zwischen runs) , Auswertung n = 6, $\alpha = 0.1$, kurzes Training + unerfahren
  • extern: nur eine Firma, wenige Datenpunkte, geringe Kenntnisse (C + Inspektionen)

The Effectiveness of Software Development Technical Reviews: A Behaviorally Motivated Program of Research

• Fragen
  1. Was macht Reviews effektiv bei Defekterkennung
  2. Wie können Reviews verbessert werden (selbes Design)
  3. Welche Designalternativen wären nach Theorie effektiver
• Analogie: Wekzeuge in der Wüste (erst einzeln bewerten, dann Gruppenbewertung)
• Gruppeninteraktion generieren keine neuen Problemlösungen (nur Lösungen aus individueller Phase)
• Ansatz: Verhaltenstheorie, rein qualitativ (kein empirischer Beweis, nur Anlehnung an Beweise aus Literatur)
• Ergebnisse
  • F1: Aufgabenexpertise Einzelner dominant, Entscheidungsschemen (Pluralitätseffekte), keine Pluralität: interaktive Gruppenperformanz positive Funktion der Prozessskills, Treffen keine neuen Defekte
  • F2: Aufgabentraining+, Performanz/Größe ~ Taskexpertise, nach Schwellwert Performanz nimmt mit Gruppengröße ab
  • F3: n unabh. Inspektoren, Expertenpaar > mehr Personen
• neue Fragen: Defekte erst in Gruppensitzung? optimale # Inspektoren? Training von Insepktoren? ...