Wie man mit Statistik schlecht informiert: Praktiken der Ergebnisdarstellung bei Experimenten im Software-Engineering
Ziele der Arbeit sind:- Ermitteln und darstellen, wie heute bei Experimenten die Ergebnisse präsentiert werden
- Kritisieren, was daran verbesserungswürdig ist
- Konkrete Beispiele geben, wie es besser ginge
Die Arbeit wird von Lutz Prechelt ausgegeben und betreut.
- Wie man mit Statistik schlecht informiert: Praktiken der Ergebnisdarstellung bei Experimenten im Software-Engineering
- Überblick
- Zusammentragen einer Grundmenge von Experimenten
- Ermittlung der jeweils verwendeten Präsentationspraktiken
- Vergleich mit den direkt erkennbar sinnvollen Praktiken
- Zusammentragen der Rohdaten der Experimente
- Suche nach Fällen, die robuster Analyseverfahren bedurft hätten
- Risiken der Arbeit
- Schlussbemerkungen
Überblick
Der Ansatz besteht darin, für eine Menge publizierter Experimente zu ermitteln, wie deren Ergebnisse präsentiert werden und dagegen zu stellen, welche Präsentation eigentlich sinnvoll wäre, wobei diese Soll-Form durch heuristische Regeln recht klar im Vorhinein festgelegt ist und nicht jedes Mal einzeln erfunden werden muss.
Kern der Kritik werden voraussichtlich folgende heute üblichen Praktiken sein:- Die Angabe nur von p-Werten anstatt von Vertrauensbereichen (Konfidenzintervallen)
- Die zu geringe Nutzung graphischer Darstellungen
- Zu geringes Detailniveau in graphischen Darstellungen
- Nichtverfügbarkeit der Rohdaten
- Zu geringe Nutzung robuster statistischer Methoden
- Zusammentragen einer Grundmenge von Experimenten
- Ermittlung der jeweils verwendeten Präsentationspraktiken
- Vergleich mit den direkt erkennbar sinnvollen Praktiken
- Zusammentragen der Rohdaten der Experimente
- Suche nach Fällen, die robuster Analyseverfahren bedurft hätten
Zusammentragen einer Grundmenge von Experimenten
Betrachtet werden sollen anfänglich alle kontrollierten Experimente und Quasiexperimente im Jahrgang 2008 von EMSE, ICSE, und TSE. Alle drei sind aus dem FU-Netz im Volltext verfügbar.Ist diese Menge an Experimenten zu klein, kommen ggf. die Jahrgänge 2009 und/oder 2007 hinzu.
Jeder Artikel in diesen Publikationen wird daraufhin untersucht, ob er hauptsächlich ein kontrolliertes Experiment oder ein Quasiexperiment (oder auch mehrere) beschreibt. Dies ergibt sich in der Regel aus dem Titel plus eventuell der Zusammenfassung (Abstract).
Falls ja, wird für den Artikel ein Kürzel gebildet anhand der Seitennummer, auf der der Artikel beginnt (z.B. EMSE8-435 für den Artikel "Presenting software engineering results using structured abstracts: a randomised experiment" aus EMSE 2008) und der Artikel unter diesem Kürzel abgelegt (z.B. articles/EMSE8-435.pdf).
Im folgenden wird der Artikel immer nur durch dieses Kürzel referenziert, so dass die Autoren nur für jemanden sichtbar werden, der sich extra Mühe damit macht, denn es geht hier nicht darum, einzelne Personen zu kritisieren, sondern die üblichen Standards in unserem Feld zu beleuchten und zu hinterfragen.
Ermittlung der jeweils verwendeten Präsentationspraktiken
Nun wird jeder dieser Artikel so weit gelesen, bis man erkennen kann- Sind es mehrere separate Experimente? Gleichartig oder zu verschiedenen Fragen?
- Was ist das Thema jedes Experiments?
- Natur und Struktur der Experimentvariablen und Ihrer Komposition (experiment design)
- Anzahl und Natur der vermutlich leistungsrelevanten Eingabevariablen
- Anzahl und Natur der gemessenen Ausgabevariablen
- Welche Auswertungsverfahren (z.B. t-Test, Rangsummentest, ANOVA, Regression) verwendet wurden
- Welche Ergebnisse zu diesen Verfahren berichtet werden (z.B. p-Werte, Vertrauensbereiche)
- Welche Aussagen und Belege über die Gültigkeit der Voraussetzungen der Verfahren vorhanden sind
- Welche graphischen Darstellungsarten für die Ergebnisse benutzt werden
Eine detaillierte Liste dieser Variablen stellen wir in Verlauf der Arbeit gemeinsam auf.
Vergleich mit den direkt erkennbar sinnvollen Praktiken
Nun lassen sich diese benutzen Präsentationspraktiken mit denen vergleichen, die sinnvoll gewesen wären und ggf. Defizite aufzeigen. Dazu gibt es ein paar Faustregeln:- Vertrauensbereiche anzugeben ist immer besser als nur p-Werte zu berichten
- Annahmen zu benennen ist meistens besser als sie stillschweigend vorauszusetzen
- Annahmen zu begründen ist meistens besser als sie nur zu benennen
- Verfahren mit schwächeren Annahmen zumindest zusätzlich einzusetzen ist meistens besser als sich allein auf Verfahren mit heiklen Annahmen zu stützen
- Visualisieren ist fast immer besser als nur verbal und numerisch zu berichten
- Rohdaten oder viele Details verfügbar zu machen ist meistens besser als nur summarische Resultate zu berichten, wenn die summarischen Resultate dadurch nicht zugeschüttet (oder gar weggelassen) werden
Wir werten diesen Vergleich für jedes Experiment einzeln aus und ziehen dann summarisch ein Fazit, wo besonders häufig Defizite zu finden sind und welche sich besonders einfach schließen ließen.
Zusammentragen der Rohdaten der Experimente
Den oben besprochenen statistischen Auswertungen liegt eine gewisse Menge von Rohdaten zu Grunde. Diese tragen wir maschinenlesbar zusammen, um Sie für weitere Untersuchungen (siehe unten) selbst verwenden zu können.
Es gibt drei mögliche Quellen, um die Rohdaten zu erhalten:- Sehr kleine Datensätze sind manchmal im Artikel abgedruckt
- Oder sie sind öffentlich hinterlegt (bei den Autoren oder bei der Zeitschrift). Manchmal entstammen die Daten einem früher bereits andernorts (z.B. Dissertation) publizierten Experiment und sind in diesem Zusammenhang erhältlich.
- Oder man erhält sie auf Anfrage von den Autoren.
Für Letzteres schreibt man die Autoren einzeln und namentlich nacheinander an und erbittet die Rohdaten. Z.B. so:
"Dear David Budgen,Lutz Prechelt and myself are currently performing a study on the current results reporting practices for software engineering experiments published in EMSE, ICSE, or TSE.
In this context, we attempt to collect as many of the raw data sets that resulted from these experiments as possible. I kindly request that you send me the raw data from the experiment described in 'Presenting software engineering results using structured abstracts: a randomised experiment' (EMSE 2008).
Will that be possible?Or should I contact someone else about it?
Or have I even overlooked that the data is already publicly posted somewhere?
Thank you very much for your help. P.S.: Can we consider these data to be public and for instance distribute them further? We will of course reference your article in that case."
Kommt keine oder eine unhilfreiche Antwort, schreibt man 1-2 Tage später den nächsten Autor an (eventuell auch mehrere Runden lang), bis man die Daten hat oder sicher ist, sie nicht bekommen zu können.
Die Daten werden dann so, wie man sie erhalten hat, in einem Unterverzeichnis abgelegt, das das Artikelkürzel als Namen trägt (z.B. "EMSE8-435/rawdata.xls")
Suche nach Fällen, die robuster Analyseverfahren bedurft hätten
Die "klassischen" (und gängigsten) statistischen Prüfverfahren wie t-Test, ANOVA, lineare Regression reagieren sehr empfindlich auf Ausreißer. Leider kommen solche extremen Werte in Software-Engineering-Experimenten oft vor.
Wir untersuchen deshalb (meistens graphisch anhand von z.B. Box-/Stripplots, Quantil-Quantil-Plots, ggf. x/y-Plots, etc.) wo solche Fälle vorliegen.
Dort hätten dann vermutlich sinnvollerweise robuste oder resistente statistische Methoden zum Einsatz kommen sollen; beispielsweise ein Bootstrap-basierter Test mit M-Schätzern anstelle eines t-Tests oder eine robuste lineare Regression (rlm) oder gar eine resistente lineare Regression (lqs) anstelle einer normalen linearen Regression (lm).Ein paar solche Fälle werden mit diesen Verfahren neu untersucht und als Anschauungsbeispiel dargestellt, wie sich dadurch die Schlussfolgerungen verändern (insbesondere verbessern) können. (Hier helfe ich bei den statistischen wie auch den technischen Fragen kräftig mit.)
Risiken der Arbeit
Eine genaue Diagnose und Darstellung der Defizite ist meist nur möglich, wenn die Rohdaten vorliegen und man die Analyse selbst nachvollziehen und variieren kann.
Deshalb ist es für den Erfolg der Arbeit kritisch, eine ausreichend große Teilmenge der Rohdaten der untersuchten Experimente zusammen zu tragen. Nach bisheriger Erfahrung ist das nicht gerade einfach, so dass einiges Kommunkationsgeschick und eine kluge Auswahl der Arbeitsreihenfolge nötig werden kann, um die Arbeit zum Erfolg zu führen. (Ich stehe dafür beratend zur Verfügung.)