Empirische Softwaretechnik

Empirische Softwaretechnik Dr. Victor Pankratius Andreas Höfer IPD Tichy, Fakultät für Informatik KIT die Kooperation von Forschungszentrum Karlsruhe GmbH und Universität Karlsruhe (TH)

Organisatorisches Folien und Material über SVN: https://svn.ipd.uka.de/lehre/vorlesung/empirischesoftwaretechnik/ws0910/unterlagen Benutzer: eswt, Passwort: tierischempirisch Kontakt Dr. Victor Pankratius http://www.ipd.uka.de/~pankratius Andreas Höfer http://www.ipd.uka.de/tichy/people.php?id=30 Freiwillige Registrierung Ihrer Email-Adresse unter http://www.ipd.uka.de/tichy/teaching.php?id=167 Ziel: Verbesserste Kommunikation zwischen Dozenten und Studenten, Benachrichtigungen bei Raumänderungen, etc. 2 09.10.2009

Organisatorisches Montags (SR 236, Geb. 50.34, 15:45-17:15 Uhr) 1 19.10.09 2 26.10.09 3 02.11.09 4 05.11.09 5 09.11.09 6 16.11.09 7 23.11.09 8 30.11.09 9 07.12.09 10 14.12.09 11 11.01.10 12 18.01.10 13 25.01.10 14 01.02.10 15 08.02.10 Donnerstag (SR 236, Geb. 50.34, 15:45-17:15 Uhr) 3 09.10.2009

Organisatorisches Bildung von Lesegruppen Lesen und Diskussion von Originalartikeln Ggf. kurze Vorstellung und Bewertung in der Vorlesung Originalarbeiten ausgewählt aus: IEEE Transactions on Software Engineering Journal on Empirical Software Engineering Konferenzen Die angegebenen Originalarbeiten lesen! Nur die Folien zu studieren wird nicht ausreichen. Referenzen in Bibtex-Datei vorhanden Originalarbeiten zu lesen ist spannend! 4 09.10.2009

Organisatorisches Danksagung Für eine frühere Version der Folien bedanken wir uns bei: Prof. Walter F. Tichy, PD Dr. Matthias Müller, Dr. Frank Padberg, Prof. Dr. Lutz Prechelt 5 09.10.2009

Agenda Motivation für empirische Forschung Grundlegende Begriffe Stand der Empirie in der Softwaretechnik Empirische Forschungsmethoden Ausblick auf die Vorlesung 6 09.10.2009

Ein praktisches Beispiel zur Motivation empirischer Forschung Fragestellung: Werfen Studenten mit dem Wurfarm zielsicherer als mit dem anderen Arm? Wie würden Sie das herausfinden? Wie würden Sie andere von Ihrer Ansicht überzeugen? Quelle: sxc.hu 7 09.10.2009

Gibt es schwarze Schwäne? Quelle: sxc.hu Cygnus atratus 8 09.10.2009

Und was ist Falsifikation? Falsifikation ist die Widerlegung von Hypothesen oder Theorien durch empirische Aussagen (z.b. Beobachtung, Experiment) Karl Popper: Universelle Hypothesen sind empirisch widerlegbar, aber nicht verifizierbar Alle Schwäne sind weiß kann als vorläufige Hypothese akzeptiert werden, bis der erste nicht-weiße Schwan beobachtet wird. Je länger eine (falsifizierbare) Hypothese Falsifikationsversuchen widersteht, als desto belastbarer wird sie angesehen. Beispiel: Newtons Theorie wurde falsifiziert; Einsteins Relativitätstheorie noch nicht. 9 09.10.2009

Empirie griechisch für Erfahrung. auf methodischem Wege (durch systematisch angestellte Beobachtungen, Versuche und Befragungen) gewonnene Erfahrung. benutzt in der Realität angestellte Beobachtungen, Versuche und Befragungen als Erkenntnisquelle. (Gegensatz: Logik und Mathematik beruhen nicht auf Beobachtungen in der Realität; sie operieren im konzeptuellen Raum: Axiome und was durch logisches Schließen daraus gefolgert werden kann.) 10 09.10.2009

Wozu Empirie? Letztlich sucht der Wissenschaftler auch in der Softwaretechnik nach Erklärungen für beobachtete Zusammenhänge: nach Theorien über die Software-Bearbeitung, aus denen praktisch nutzbare Vorhersagen und Modelle abgeleitet werden können. Belastbare Theorien, die etwas über die Wirklichkeit der Softwarebearbeitung aussagen, sind das eigentliche Ziel der empirischen Forschung. Die Erkenntnisse sollen natürlich auch dem Praktiker nützen. 11 09.10.2009

Wozu Empirie in der SWT? Es existieren zu viele Methoden und Werkzeuge, als dass der einzelne Programmierer oder auch ein Softwarehaus die beste Wahl durch Ausprobieren ermitteln könnte. Diese Wahl ist aber wichtig für den Praktiker. Ohne fundierte Erkenntnisse wäre er Moden, Meinungen, Vorlieben oder Beratern ausgesetzt. Empirische Studien untersuchen, ob Unterschiede zwischen verschiedenen Softwaretechniken tatsächlich beobachtet werden können, z.b. in Bezug auf Zuverlässigkeit, Kosten, oder Wartbarkeit. 12 09.10.2009

Wie hilft Empirie in der SWT? Korrelationsstudien bestimmen Zusammenhänge zwischen verschiedenen Variablen z.b. die Relation zw. Umfang von Software und dem Entwicklungsaufwand. Vorhersage- und Optimierungsmodelle machen die Relation praktisch nutzbar. z.b. für Kostenschätzung, Zeitschätzung, Zuverlässigkeitsschätzung, Leistungsvorhersagen Experimente testen Hypothesen z.b. ob Inspektionen, Entwurfsmuster oder Extreme Programming die Softwareentwicklung beschleunigen oder Software zuverlässiger machen. 13 09.10.2009

Historischer Rückblick Platon: Die Welt der Ideen und Formen kann nur durch die Vernunft erkannt werden. Sie existiert unabhängig von der Erscheinungswelt. (ein sichtbarer Kreis ist nur eine Approximation der Idee des Kreises.) Beobachtung ist wertlos für Erkenntnis. Aristoteles: Wissenschaft untersucht das Allgemeine, welches sich aber in der Existenz einzelner Individuen ausdrückt. Demnach muss Wissenschaft einen Ausgleich zwischen dem Empirismus und der Deduktion schaffen, nicht bloß dazwischen wählen. ( Auch die Beobachtung zählt ) ( Reine Theorie ) 14 09.10.2009

Modernes Verständnis von Wissenschaft Wir überspringen Ptolemäus, Kopernikus, Tycho Brahe, Galileo, Kepler, Francis Bacon, John Locke, Descartes, Newton, Leibniz, Kant und viele andere. Wissenschaftliche Methode: Ausgangspunkt: ein Problem, das erklärt werden muss Suche Erklärung (neue oder verbesserte Theorie) Teste Theorie mittels Experiment 15 09.10.2009

Wissenschaftliche Methodik (1) Realität In der SWT sind erst hier Verstehen Phänomen X Glaube Praxis Mode Verbesserung Berater Entwicklung Modellierung Erfahrung Bewertung Hörensagen Wiederholung wissenschaftliche Untersuchung Theorie von X getestete Theorie von X hier müssen wir hin! Modifikation 16 09.10.2009

Rolle der Empirie Empirie beobachtet, misst und bewertet Phänomene Empirie bestätigt oder verwirft Vorhersagen von Theorien Empirie regt neue/verbesserte Theorien an 17 09.10.2009

Wissenschaftliche Methodik (2) Phänomen griechisch für etwas, das sich zeigt oder erscheint eine Erscheinung ein wiederholt auftretendes Verhalten Gegenstand von empirischen und theoretischen Untersuchungen 18 09.10.2009

Wissenschaftliche Methodik (3) Theorie griechisch für betrachten, schauen Betrachtung der Wahrheit durch reines Denken ordnet und verknüpft Einzelerkenntnisse zu Gesetzmäßigkeiten bildet ein Modell der Realität gewinnt neue Erkenntnisse und Aussagen durch logische Schlussfolgerungen ermöglicht Vorhersagen Experimente bestätigen oder widerlegen (falsifizieren) die Vorhersagen von Theorien. Wissenschaftliche Theorien bilden den Kern unseres Weltverständnisses 19 09.10.2009

Wissenschaftliche Methodik (4) Vom Phänomen zur Theorie Phänomen wird beobachtet (Empirie) Theorie wird aufgestellt, um das Phänomen zu erklären Messungen und Experimente bestätigen oder verwerfen die Theorie (Empirie) Theorie wird angepasst usw. 20 09.10.2009

Warum reicht ausschließlich Empirie nicht aus? Empirische Ergebnisse allein bilden kein kohärentes Wissensgebäude. Angenommen, wir stellen fest, dass Methode A besser als Methode B ist. Das sagt nichts über noch zu entwickelnde Methoden C, D, E aus. Soll man alle Experimente wiederholen? Erklärt auch nicht, warum A besser ist. Allein aus Experimenten heraus ist es schwierig, den Wissensstand zu beschreiben oder die Hypothesen zu bestimmen, die getestet werden sollen. Induktivismus wissenschaftstheoretisch problematisch Die Folgerung Wenn eine große Anzahl von As unter unterschiedlichen Bedingungen beobachtet wurde und alle beobachteten As ohne Ausnahme die Eigenschaft A besaßen, dann besitzen alle As die Eigenschaft B ist logisch falsch. Theorien und Modelle werden benötigt. Wissenschaft braucht beide Säulen: Empirie und Theorie 21 09.10.2009

Welche Rolle hat die Theorie? Erklärt beobachtete Phänomene, Kann noch unbeobachtete Phänomene vorhersagen, Kann zur Formulierung testbarer Hypothesen nutzen, Bildet den Kern einer Wissenschaft, Muss verbessert oder ersetzt werden, wenn unerklärliche Beobachtungen gemacht werden Ist qualitativ oder quantitativ, Ist in der Softwareforschung selten (Warum- und Wie-Fragen nicht beantwortbar) 22 09.10.2009

Beispiel: Theorie zu Inspektionen laut Sauer et al. Der Sachverstand der Gruppe ist bestimmt vom Sachverstand der einzelnen Mitglieder Erhöhen durch Auswahl, Training, Lesetechniken Durch die Interaktion in der Gruppe entstehen keine neuen Lösungen Das Verfahren zur Entscheidungsfindung ist ausschlaggebend dafür, ob vorhandener Sachverstand der Mitglieder genutzt wird Eingriffe am Ablauf einer Inspektion werden nur dann etwas bringen, wenn der bereits vorhandene Sachverstand nicht optimal eingesetzt wird 23 09.10.2009

Aufgaben und Fragestellungen der empirischen Softwaretechnik Empirische Softwaretechnik erkundet Phänomene bei Erstellung und Einsatz von Software. bewertet Werkzeuge und Methoden zur Software-Erstellung. testet Theorien über Software und ihre Erstellung. bewertet Eigenschaften von Software. Typische Fragestellungen Steigern die Techniken von XP die Zuverlässigkeit von Programmen? Hängt der Wartungsaufwand für ein OO-Programm von der Vererbungstiefe ab? Sind Szenario-basierte Inspektionen wirkungsvoller als Inspektionen mit Prüflisten? 24 09.10.2009

Überblick über die Softwareforschung Technik Produkt & Prozess Methoden Werkzeuge Wie entwickelt man Software schnell und gut? Was geht in der SW-Entwicklung eigentlich vor? Theorie Modelle, Gesetze, Metriken,Psychologie, Formalisierung Stimmt die Theorie? Wie funktionieren Methoden? Was passiert wenn...? Empirie Theorietest Technikbewertung Erkundung v. Phänomenen empirische Methodik 25 09.10.2009

Stand der Forschung der SWT (1) Technik stärkster Teil der Softwaretechnikforschung viele nützliche Werkzeuge verschiedene Programmierparadigmen mehrere Vorgehensweisen (z.b. klassische Entwicklungsphasen, Cleanroom Development, Extreme Programming) siehe Vorlesung Softwaretechnik u.a. 26 09.10.2009

Stand der Forschung der SWT (2) Theorie Weniger gut entwickelt formale Softwareprozess-Modelle erste ökonomische Modelle und Kosten-Nutzen-Analysen 27 09.10.2009

Stand der Forschung der SWT (3) Empirie viel Forschung über Software-Metriken viele Fallstudien in den letzten 10 Jahren Dramatisches Wachstum an kontrollierten Experimenten wichtige empirische Erkenntnisse drastisch verbesserte Methodik 28 09.10.2009

Empirische Forschungsmethoden Deskriptive Forschung beschreibt Phänomene, Ereignisse, Situationen Experimentelle Forschung Beschreibt Ursache-Wirkung, ist quantitativ Quantitative Studie Qualitative Studie Umfrage Korrelations-Studie Ex post facto Studie Langzeit- und Querschnittsstudie Naturalistische Beobachtung Meta-Studie Fallstudie Ethnographie Phänomenologie Laborexperiment Feldexperiment Simulation / Benchmark 29 09.10.2009

Fallstudie genaue Beschreibung und Analyse... eines Vorgangs einer Organisation eines Ereignisses oder auch mehrere davon. nutzt verschiedene Informationsquellen... Interviews Zeugenaussagen Dokumente Testergebnisse technische Analysen Nachrichten etc. 31 09.10.2009

Beispiel: Absturz der Ariane 5 Die Airane 5 Rakete explodierte 40 s nach dem Start. (1996, $500 Mill. Verlust). 32 09.10.2009

Fallstudie des Absturzes ergab: Ein Überlauf ereignete sich bei der Konvertierung einer 64-Bit Ganzzahl in eine 16-Bit Ganzzahl in einem Programm genannt Inertial Reference System. Dieser Überlauf wurde nicht abgefangen, daher hielt die ganze Lagesteuerung an, was die Rakete in eine unzulässige Schräglage brachte, worauf sie sich selbst sprengte. Große Verwirrung: Das Programm, das den Überlauf verursachte, war während des Fluges gar nicht benötigt (nur bis -9s Startzeit). Es lief aber 50 s lang nach dem Start weiter, um bei einem Abbruch des Starts eine Re-Initialisierung von mehreren Stunden zu vermeiden. Das Programm war für die Ariane 4 Rakete entwickelt worden, bei der dieser Überlauf nicht auftreten konnte. Der Defekt war also ein Wiederverwendungsfehler, verursacht durch fehlende Spezifikation der Bedingungen, unter denen die Software richtig arbeitete. 33 09.10.2009

Fallstudien Fallstudien sind meistens qualitativ, obwohl sie quantitative Elemente enthalten können. In der Software-Forschung werden sie oft benutzt, um die Funktionalität eines Werkzeuges vorzuführen (Existenzbeweis). Fallstudien sind auch nützlich, um seltene Fälle zu verstehen (wie z.b. Unfälle, die durch Software verursacht werden). ACM SIGSOFT Software Engineering Notes publiziert in der Rubrik Risks to the Public zahlreiche Fallstudien über Ausfälle und Unfälle, die mit Software zu tun haben (Bankenwesen, Verkehr, Gesundheitswesen, Sicherheitslücken, usw.) Fallstudien lassen sich nicht verallgemeinern, da die Ursache eines bestimmten Ereignisses nicht mit Sicherheit bestimmt werden kann. Um Wirkungszusammenhänge mit Sicherheit festzustellen benötigen wir Experimente. 34 09.10.2009

Beispiel einer Fallstudie: Test-Driven Development bei IBM Maximilien u. Williams: Assessing Test-Driven Development at IBM studiert, wie sich Test-Driven Development (TDD) auf die Defektdichte in einem realen Projekt bei IBM auswirkt International Conference on Software Engineering ICSE 25 (2003) 564-569 35 09.10.2009

Test-Driven Development zuerst die Testfälle für eine Methode schreiben, dann die Methode implementieren ( test-first ) automatisches Ausführen aller Testfälle (mit JUnit o. ä.), beliebig oft wichtige Technik bei XP 36 09.10.2009

Fallstudie: TDD bei IBM (2) Produkt JavaPOS (Java for Point of Sale) definiert eine Bibliothek von Java Beans zum Ansprechen von Geräten an der Kasse. bisherige Versionen von JavaPOS hatten zu hohe Defektdichte. abschließender functional verification test für jede Version stand zur Verfügung. 37 09.10.2009

Fallstudie: TDD bei IBM (3) Management war offen für Veränderung JavaPOS wurde mit einem neuen Team und TDD komplett neu entwickelt ( neu ) später wurde zusätzlich basierend auf dem alten Code mit erfahrenen Entwicklern eine funktional mit der Neuentwicklung vergleichbare Version erstellt ( alt ), aber ohne TDD. 38 09.10.2009

Fallstudie: TDD bei IBM (4) Entwickler im Projekt JavaPOS alt viel Erfahrung mit früheren Versionen (Spezifikation und Code) entsprechende Java-Erfahrung Entwickler im Projekt JavaPOS neu 7 von 9 ohne Erfahrung mit Spezifikation oder früheren Versionen einige hatten wenig Java-Erfahrung junges, enthusiastisches Team [laut Vortrag] 39 09.10.2009

Erhoffte Vorteile von TDD niedrigere Defektdichte durch früheres und häufigeres Testen verkürzte Implementierungszyklen durch Automatisieren der Testläufe verbesserte Code-Integration durch laufende Regressionstests höhere Testqualität durch Ansammeln vieler Testfälle 40 09.10.2009

Defektdichte bei JavaPOS alt tatsächlich erwartet 7,0 Defekte/KLOC tatsächlich; 5,5 Defekte/KLOC erwartet 41 09.10.2009

Defektdichte bei JavaPOS neu tatsächlich erwartet 3,7 Defekte/KLOC tatsächlich; 4,0 Defekte/KLOC erwartet 42 09.10.2009

Einige Unklarheiten JavaPOS neu hatte 71 KLOC, aber Größe von JavaPOS alt wird nicht angegeben JavaPost neu zeigt 247 Defekte, JavaPOS alt nur 80. Bei Defektdichte 7 und 80 Defekten müsste JavaPOS alt nur 11 KLOC groß gewesen sein. unklar, ob Defektdichte bei JavaPOS alt sich nur auf hinzugekommenen und geänderten Code bezieht oder den ganzen Code. Dauer, Größe und Zusammensetzung des Abschlusstests wird nicht angegeben 43 09.10.2009

Fazit der Studie Verringerung der Defektdichte allein auf Test-Driven Development zurückgeführt dabei wird ignoriert: unterschiedlicher Projektumfang (Neuentwicklung versus Delta zu alter Version) Teams mit unterschiedlichen Vorkenntnissen kausaler Zusammenhang ist nicht schlüssig nachgewiesen! 44 09.10.2009

Einordnung der Studie begonnen als Fallstudie: Einsatz von TDD bei einem Projekt bei IBM Messen von Defektdichte, Aufwand, u. a. ausgebaut zu Feldexperiment: Vergleich mit Parallel-Projekt, das ohne TDD durchgeführt wird kontrollierte Variable ist die Testtechnik (unsystematisches Testen versus TDD) 45 09.10.2009

Ethnografie Experimentator wird Teil der Gruppe Lebensweise/Kultur einer Gruppe untersuchen Makro-Kulturen: Länder, Religionsgruppen, Mikro-Kulturen: Firma, Studenten-WG, Verschiedene Techniken möglich: Tiefeninterviews Beobachtung der Teilnehmer Kritische Punkte: Zugang zur Gruppe Akzeptanz durch die Gruppe Wahrung der Objektivität des Forschers 47 09.10.2009

Phänomenologie Erleben eines Phänomens durch Individuen oder Gruppe beschreiben und verstehen Von Interesse ist nicht nur das Erlebnis selbst sondern auch dessen Interpretation oder Bedeutung Häufigste Methode ist das Tiefeninterview 49 09.10.2009

Definition Feldexperiment Experiment, das in einer realen Umgebung durchgeführt wird. der Experimentator... variiert eine oder mehrere Eigenschaften, die sog. unabhängigen Variablen (z.b. die Programmiermethodik) hält so viele wie möglich der übrigen Eigenschaften (sog. Störvariablen) konstant (z.b. Qualität der Programmierer) beobachtet den Einfluss der variierten Variablen auf die abhängigen Variablen (z.b. Dauer, Kosten, Qualität) 51 09.10.2009

Feldexperiment (2) unabhängige Variablen werden manipuliert Störvariablen werden konstant gehalten oder ihre Auswirkung neutralisiert. abhängige Variablen werden beobachtet und gemessen. die Wirkung der unabhängigen Variablen auf die abhängigen Variablen wird untersucht. 52 09.10.2009

Feldexperiment (3) Anwendung interessierende Situation kann im Labor nicht realistisch nachgestellt werden für Schlussfolgerungen nötige Menge an Daten kann nur in der Praxis angesammelt werden Fragestellung erfordert Beobachtung über längeren Zeitraum 53 09.10.2009

Feldexperiment (4) Liefert realistische Ergebnisse Es kann vorkommen, dass nicht alle Störvariablen kontrolliert werden können (Quasi-Experiment) Kontext oft schwer zu erfassen; dann ist Übertragbarkeit auf andere Situationen fraglich. Kosten oft hoch benötigt Unterstützung durch Management zur Durchführung 54 09.10.2009

Wissenschaftliches Experiment oder kontrolliertes Experiment Erfahrungswissenschaftliche Methode, um angenommenes Gesetzmäßigkeiten (Hypothesen) in der Realität durch Beobachtung zu überprüfen. (Das Wort Experiment kommt vom Lateinischen experimentum Versuch, Beweis, Prüfung, Probe ) Im Experiment wird durch planmäßiges Beobachten eines Sachverhaltes [ ] und dessen Veränderung unter kontrollierten, [ ] wiederholbaren Bedingungen eine Hypothese bestätigt oder widerlegt. (Quelle: Microsoft Encarta Online-Enzyklopädie) 56 09.10.2009

Wichtige Attribute des wiss. Experiments Planmäßige Manipulation von unabhängigen Variablen ( Kontrolle der unabhängigen Variablen). Objektive Beobachtung der abhängigen Variablen; d.h. ein anderer Beobachter würde die selbe Beobachtung machen. (Besondere Maßnahmen bei subjektiver Einschätzung nötig mehrere Einschätzer benutzen und deren Übereinstimmung überprüfen.) Störvariablen (weitere unabhängige Variablen, die die abhängigen Variablen beeinflussen können) werden konstant gehalten oder in ihrer Wirkung neutralisiert ( Kontrolle der Störvariablen, z.b. durch zufällige Zuweisung von Experimentbedingungen an Teilnehmer.) Kausalität (Ursache-Wirkung-Beziehung), so vorhanden, wird beobachtbar. Wiederholbarkeit des Experiments durch andere (dadurch werden Beobachtungen überprüfbar Irrtümer und Schwindel aufdeckbar.) Beispiel: Experiment über kalte Fusion von Ponds und Fleishman (1989) enthielt einen Irrtum gemessen wurde nicht Energie aus einer Kernfusion, sondern aus der Radonstrahlung des Wassers. 57 09.10.2009

Kontrolliertes Experiment Im kontrollierten Experiment werden die Beobachtungen in mehreren Situationen verglichen, in denen alle Bedingungen identisch sind, außer den Variablen, deren Einfluss getestet wird. Beispiel: Test eines Medikamentes: Die Versuchs- oder Experimentgruppe erhält das zu testende Medikament, eine zweite Gruppe, die sog. Kontrollgruppe, erhält kein Medikament oder Kontrollgruppe erhält einen Placebo, damit kein Teilnehmer weiß, was er erhält (einfach blinder Versuch Subjekteffekt neutralisiert). Von einem doppelt blinden Versuch spricht man, wenn auch der Experimentator während des Versuchs nicht weiß, wer Medikament und wer Placebo erhalten hat (Experimentator kann Subjekte nicht beeinflussen.) Übung: Angenommen, wir führen einen Versuch zum Vergleich zweier Programmiersprachen, z.b. Java vs. C#, durch. Was sind die unabhängigen Variablen? Was sind mögliche Störvariablen? Wie können sie kontrolliert werden? Ist ein blinder Versuch möglich? Kann/soll der Experimentator im Unklaren gelassen werden über die Zuordnung der Subjekte zu Programmiersprachen? 58 09.10.2009

Laborexperiment, Feldexperiment, Quasi- Experiment Das Laborexperiment wird im Labor durchgeführt, das Feldexperiment in realer Umgebung. Das Feldexperiment ist oft realistischer, aber schwieriger durchzuführen. Beim Quasi-Experiment gelingt es nicht, alle Variablen zu kontrollieren, z.b. wenn Teilnehmer nicht zufällig an Experimentbedingungen zugewiesen werden. (Feldexperimente sind oft Quasi-Experimente). Alle drei Typen sind kontrollierte, wiss. Experimente. 59 09.10.2009

Beispiel: Kontrolliertes Experiment über Test-Zuerst Müller u. Hagner: Experiment about Test-first Programming untersucht den Einfluß von "Test-Zuerst" auf die Entwicklungsdauer und die Korrektheit von Programmen IEE Proceedings Software, Vol. 149, (5), p. 131-136, Oct 2002. 60 09.10.2009

Beispiel: Kontrolliertes Experiment über Test-Zuerst Teilnehmer Studenten des XP Praktikums 2001 ( Subjekte ) Programmiererfahrung reicht von Anfänger bis vergleichbar mit Profi 61 09.10.2009

Beispiel: Kontrolliertes Experiment über Test-Zuerst Aufgabe Entwicklung der Hauptklasse einer Graphenbibliothek Gerichtete/ungerichtete Kanten Gewichtete/ungewichtete Kanten und Knoten Operationen zum Hinzufügen/Löschen von Knoten und Kanten Methodensignaturen vorgegeben Sprache: Java 62 09.10.2009

Beispiel: Kontrolliertes Experiment über Test-Zuerst Variablen Testtechnik als unabhängige Variable (mit Test-Zuerst versus beliebig) Entwicklungsdauer und Programmkorrektheit als abhängige Variablen Aufgabenstellung kontrolliert abschließende Programmkorrektheit ebenfalls kontrolliert (durch Akzeptanztest) 63 09.10.2009

Beispiel: Kontrolliertes Experiment über Test-Zuerst Experimententwurf Experimentgruppe: entwickelt mit Test-Zuerst benutzt junit zur Testautomatisierung Kontrollgruppe: testet nach Belieben benutzt junit zur Testautomatisierung Teilnehmer zufällig den Gruppen zugeordnet ( randomisiert ) 64 09.10.2009

Beispiel: Kontrolliertes Experiment über Test-Zuerst Ablauf Implementierung: Teilnehmer entscheiden selbständig, ob Programm fertig oder nicht Qualitätssicherung (QS): automatischer Akzeptanztest wird gestartet Vorgabe: 100% der Testfälle erfolgreich Teilnehmer korrigieren Fehler, bis Vorgabe erfüllt 65 09.10.2009

Beispiel: Kontrolliertes Experiment über Test-Zuerst Tests auf Korrektheit Akzeptanztest der Qualitätssicherung 20 Testfälle erwartetes Programmverhalten wird überprüft (sind erwartete Knoten/Kanten vorhanden?) Bestehen garantiert eine Mindestqualität Großer Zufallstest nach bestehen des Akzeptanztest zufälliger Aufbau eines Graphen gleichzeitig wird identischer Graph mit "Goldprogramm" (sicher korrekt) aufgebaut. 730.000 Graph-Operationen, 7,5 Mill. Zusicherungen Nach jeder Operation erfolgt Vergleich der Knoten- und Kantenmengen des Subjektprogramms und "Goldprogramms". 66 09.10.2009

Exkurs: Boxplots http://kortenkamps.net/material/stochastik/quartile.html 25 % 50 % 25 % Interquartilsabstand Max. 1,5 Interquartilsabstand Schnurrbart Median Ausreißer

Beispiel: Kontrolliertes Experiment über Test-Zuerst Ergebnisse für Zeit Control Group Test First Group Gesamtzeit in Minuten (Implementierung plus QS) 68 09.10.2009

Beispiel: Kontrolliertes Experiment über Test-Zuerst Ergebnisse für Qualität, vor QS Control Group Test First Group Anteil bestandener Zusicherungen aus Akzeptanztest, nach Implementierung, vor Qualitätssicherung. Unterschied signifikant, p=0,03. 69 09.10.2009

Beispiel: Kontrolliertes Experiment über Test-Zuerst Ergebnisse für Qualität, nach QS Control Group Test First Group Anteil bestandener Zusicherungen aus Zufallstest, nach QS, p=0,2. (starke Streuung) 70 09.10.2009

Beispiel: Kontrolliertes Experiment über Test-Zuerst Ergebnisse zusammengefasst Entwicklungsdauer: Test-Zuerst-Gruppe braucht etwas länger (Implementierung plus QS) Programmkorrektheit vor QS: Test-Zuerst-Gruppe signifikant schlechter Programmkorrektheit nach QS: Test-Zuerst-Gruppe etwas besser 71 09.10.2009

Beispiel: Kontrolliertes Experiment über Test-Zuerst Gründe Offensichtlich: Test-Zuerst-Gruppe hat in der Implementierungsphase zu einseitig oder zu wenig getestet Möglicherweise: Test-Zuerst-Gruppe hatte falsches Gefühl der Sicherheit (das ergab die Auswertung der Fragebögen am Ende des Experiments) 72 09.10.2009

Beispiel: Kontrolliertes Experiment über Test-Zuerst Mögliche Schwachpunkte Studenten, keine Profis Technik war noch zu neu (Test-Zuerst noch nicht in Fleisch und Blut übergegangen ) Keine direkte Überprüfung während des Experiments, ob wirklich gemäß Test-Zuerst entwickelt wurde Zu enge Aufgabenstellung Zu wenig Teilnehmer, um einen Effekt sichtbar werden zu lassen 73 09.10.2009

Beispiel: Kontrolliertes Experiment über Test-Zuerst Fazit des Experiments Test-Zuerst erfüllt Erwartungen (erstmal) nicht Test-Zuerst verlangt Erfahrung beim Schreiben geeigneter Tests und Disziplin Durchsetzen einer Mindest-Qualität der Programme im Experiment ist wichtig, da sonst Zeitdauer ohne Aussagekraft. Tatsächliches Anwenden der Technik im Experiment muss überprüft werden Weitere Experimente nötig 74 09.10.2009

Ein mustergültiges Experiment: Multi-Versions- Programmierung (Knight & Leveson) Ein klassisches Falsifikationsexperiment MVP: N unabhängig entwickelte Implementierungen der gleichen Spezifkation laufen parallel; die Mehrheit bestimmt das Ergebnis (in der Praxis N=3). Das Experiment falsifiziert die Annahme, dass unabhängige Implementierungen der gleichen Spezifikation unabhängig voneinander versagen. Damit ist das Zuverlässigkeit bei Multi-Versions- Programmierung geringer als angenommen. 75 09.10.2009

MVP-Experiment fortgesetzt Spannende Fragestellung, heiß debattiert Sehr sauber durchgeführtes Experiment 27 unabhängige Versionen mit 99,9% Zuverlässigkeit Akzeptanztest mit 100 zufälligen Testfällen, Stichprobe mit 1 Mio zufälligen Testfällen Die beobachtete Häufung von Mehrfachversagern ist unter der Unabhängigkeitsannahme extrem unwahrscheinlich Erklärung: Programmierer machen an den gleichen Stellen Fehler! 76 09.10.2009

MVP-Experiment Übertragung auf Verifkation Verifikation ist 2-Versions-Programmierung: Version 1: Spezifkation, Version 2: Implementierung Anstelle ein drittes Programm als Schiedsrichter bei unterschiedlichen Ausgaben zu benutzen, wird per Verifikation sichergestellt, dass die Programme die gleichen Ergebnisse (und Fehler) liefern. Auch hier gilt: Unabhängigkeit der Versager in beiden Versionen nicht gegeben! Damit ist die Zuverlässigkeit bei weitem nicht so hoch, wie gedacht (100%), aber durch die Redundanz sicher besser als ohne. 77 09.10.2009

Umfrage Sammelt Informationen durch Fragen an Repräsentanten einer bestimmten Zielgruppe Repräsentanten vertreten die Zielgruppe durch entsprechende Merkmale, Verhaltensweisen und Einstellungen Gibt Einblick in den momentanen Zustand der Zielgruppe Beispiele: Wie finden Sie die Vorlesung Empirische Softwaretechnik? (1 hervorragend, 2 gut, 3 mittelmäßig, 4 eher schlecht, 5 sehr schlecht) 79 09.10.2009

Umfrage (2) Fragen können sich auf subjektive oder objektive Sachverhalte beziehen Fragen werden schriftlich (Fragebogen, per Post, E-Post, Pop- Up-Survey im Web) oder mündlich (Interview) gestellt. Antworten sind immer subjektiv und nur begrenzt überprüfbar Beispiel: Putzen Sie regelmäßig die Zähne? (Achtung, Subjekteffekt (Teilnehmer wollen sich möglichst gut darstellen); besser: Haben Sie heute morgen die Zähne geputzt?) Was war der Schwierigkeitsgrad der Aufgaben? Subjektive Faktoren wie Zufriedenheit, Stress, Bekanntheit, Vorlieben, Angemessenheit eines Verfahrens nur über Umfragen ermittelbar. Wie bei anderen empirischen Methoden bleiben Teilnehmer anonym. 80 09.10.2009

Umfrage (3) Einfach und relativ kostengünstig Direkter Kontakt mit Zielgruppe notwendig Verlässlichkeit der Ergebnisse ist zu diskutieren Repräsentativität der Stichprobe ist zu diskutieren. Evtl. Anreize schaffen, z.b. Verlosung eines Geschenks 81 09.10.2009

Beispiel: Umfrage zu Softwarekostenschätzung Molokken-Østvold et al., A Survey on Software Estimation in the Norwegian Industry Interviews, um die Schätzpraktiken und Schätzgenauigkeit in der SW-Industrie zu bestimmen (in Norwegen). Proc. 10th Int l Symposium on Software Metrics, METRICS 04, IEEE, 2004. 82 09.10.2009

Umfrage Kostenschätzung (1) 18 verschiedene Beratungs-Firmen in Norwegen, 52 verschiedene, vor kurzem abgeschlossene Projekte. Strukturierte, tiefgehende, persönliche Interviews mit den Leitern der Projekte. Interviews auf Band aufgenommen, nachträglich ausgewertet. Dauer: 30 bis 70 Minuten pro Interview. Projekte erforderten zw. 180 h und 14.000 h Entwicklungszeit (Mittelwert 3124 h) 83 09.10.2009

Umfrage Kostenschätzung (2) 35 30 25 20 15 10 5 0 Tatsächliche Kosten im Vergleich zur Schätzung 19 % geringer 5 % wie geschätzt 72 % höher 30 25 20 15 10 5 0 Tatsächlicher Zeitpunkt der Fertigstellung im Vergleich zur Schätzung 2 % 36 % 62 % zu früh pünktlich zu spät Nur 42 der 52 Projekte wurden ausgewertet, da für den Rest die Daten nicht vollständig waren oder die Projekte abgebrochen wurden. 84 09.10.2009

Umfrage Kostenschützung (3) Balanced Relative Error (BRE): Verteilung der Abweichung von der Kostenschätzung Mittlere Abweichung: +41% 85 09.10.2009

Umfrage Kostenschätzung (4) Weitere Ergebnisse: Dominante Schätzmethode ist Expertenschätzung (84%) Projektleiter überschätzen die Schätzgenauigkeit in ihren Firmen: Sie meinen 45% der Projekte werden im Kostenrahmen fertig, obwohl es nur 10% sind. Wenn man eine Kostenerhöhung von 25% noch als akzeptabel ansieht, dann sind 43% der Projekte noch akzeptabel. Im Vergleich mit ähnlichen, älteren Studien hat sich in den vergangenen 20 Jahren die Schätzgenauigkeit nicht verbessert. 86 09.10.2009

Korrelationsstudie Quantitative Methode, die die Wechselbeziehung zwischen zwei oder mehreren Variablen ermittelt. Gesucht ist ein funktionaler Zusammenhang Aus Kenntnis einer Variablen kann dann die andere bestimmt werden. Beispiele: Zusammenhang zw. Produkt- und Prozessmetriken einerseits und Entwicklungsdauer, Teamgröße, Fehlerdichte andererseits. Aber: kein kausaler Zusammenhang ableitbar (Gefahr der verborgenen, dritten Variablen ); liefert daher keine Erklärung. Beispiel: positive Korrelation zw. Schuhgröße und Gehalt. Was ist die verborgene Variable? 88 09.10.2009

Ex Post Facto Studie Untersuchte Variable(n) sind nicht manipulierbar, müssen im Nachhinein gewählt werden Ausgangspunkt sind Gruppen, die sich in einer Variable bereits unterscheiden, z.b. Geschlecht, Alter, Anschließend Aufzeichnen und Auswerten des Verhaltens der Gruppenmitglieder: Gibt es Unterschied zwischen den Gruppen? Vorsicht: Gruppeneinteilung nicht randomisiert. Problem der verborgenen, dritten Variablen (siehe Korrelationsstudie) 90 09.10.2009

Langzeit- und Querschnittsstudie Langzeitstudie verfolgt eine Gruppe von Teilnehmern über einen längeren Zeitraum Beispiel: nimmt die Verwendung von UML oder Paarprogrammierung oder Test-Zuerst mit der Zeit zu, ab, oder bleibt sie gleich? Querschnittsstudie untersucht eine Stichprobe einer Population zu einem bestimmten Zeitpunkt Betrachtet dabei Unterschiede nach Alter, Geschlecht, Ausbildung, etc. Teilnehmer haben nicht notwendigerweise vergleichbare Erfahrung gemacht (z.b. haben heute Fünfzigjährige nicht schon in der Schule Computerspiele und Mobiltelephonie ausprobiert), daher ist die Langzeitstudie zuverlässiger, aber auch aufwendiger. 92 09.10.2009

Naturalistische Beobachtung Datensammlung über natürlich auftretendes Verhalten. Subjekte werden in ihrer natürlichen Umgebung beobachtet. Wichtig: Beobachter darf nicht auffallen/entdeckt werden, da sich die Subjekte sonst möglicherweise anders verhalten. Ideal um Hypothesen für spätere Laborexperimente zu sammeln, aber unerkannt bleiben ist oft schwer Beobachtungszeiträume sind oft lang 94 09.10.2009

Metastudie Studie über Studien Auswertung mehrerer bereits vorhandener Studien zu einem Thema Material ist Forschungsliteratur entnommen fasst nicht nur zusammen, sondern vergleicht und analysiert (im Gegensatz zu Überblicksartikel) 96 09.10.2009

Metastudie (2) bietet Orientierung und konsolidiert Wissen: bestätigen sich Ergebnisse gegenseitig? ergänzen sich Ergebnisse? zu welchen Aspekten liegen noch keine Ergebnisse vor? welche Ergebnisse widersprechen sich? Beispiel: es gibt zahlreiche Untersuchungen zu Paarprogrammierung. Diese sind teilweise widersprüchlich. In den meisten Fällen sind die Teilnehmer Studenten. Meistens haben die Teilnehmer Paarprogrammierung erst kürzlich erlernt und nur mit wenigen Partnern geübt. Langzeitstudien zu dem Thema gibt es nicht. Welche Schlussfolgerungen ziehen Sie daraus? 97 09.10.2009

Metastudie (3) vergleichsweise geringer Aufwand zugrundeliegende empirische Studien müssen schon vorhanden sein kann Lücken und Mängel in den vorhandenen Studien nicht mehr ausgleichen, aber aufdecken. zeigt Ansatzpunkte für weitere Forschung 98 09.10.2009

Metastudie (4) Spezialfall: Meta-Analyse gemeinsame statistische Analyse verschiedener Studien (in der Regel Experimente) Ziel: neue quantitative Aussage gibt es einen signifikanten Effekt, wenn man die Einzelergebnisse kombiniert? wie groß ist der Effekt, wenn man die einzelnen Effektgrößen kombiniert? 99 09.10.2009

Ausblick auf die Vorlesung Schritt für Schritt aufbereitete, beispielhafte Originalarbeiten, z.b. zu Vererbungstiefe Zusicherungen Paarprogrammierung Test-getriebene Entwicklung Software-Inspektionen Formale Methoden empirisch-methodische Grundlagen anhand der Originalarbeiten statistische Grundlagen nur soweit, wie zur Auswertung der empirischen Arbeiten nötig Zeit für Fragen und Diskussionen 100 09.10.2009

Ausblick auf die Vorlesung - Lernziele Stellenwert der Empirie in der Softwaretechnik darlegen können Beispiele empirischer Untersuchungen in der Softwaretechnik, ihre Ergebnisse und die dabei eingesetzten empirischen Methoden beschreiben und bewerten können Methodische und statistische Grundlagen für empirische Untersuchungen in der Softwaretechnik beherrschen Eigene empirische Untersuchungen in der Softwaretechnik gestalten können. Beispiele empiriebasierter Theorien in der Softwaretechnik beschreiben können Tragfähigkeit der daraus abgeleiteten Schlussfolgerungen beurteilen können Kosten und Nutzen von Entwicklungstechniken objektiv abwägen können 101 09.10.2009

Literatur Originalarbeiten ausgewählt aus: IEEE Transactions on Software Engineering Journal on Empirical Software Engineering Konferenzen Die angegebenen Originalarbeiten lesen! Nur die Folien zu studieren wird nicht ausreichen. Referenzen in Bibtex-Datei vorhanden Originalarbeiten zu lesen ist spannend! 102 09.10.2009

Literatur (2) Grundlagen Christensen: Experimental Methodology, Allyn and Bacon, 200x David C. Howell (1999), Fundamental Statistics for the Behavioral Sciences, Brooks/Cole Publishing Company, 4th edition, ISBN 0-534-35821-7 103 09.10.2009