Empirische Softwaretechnik Prof. Dr. Walter F. Tichy Dr. Matthias Müller Sommersemester 2006 1
Organisatorisches prüfbar im Vertiefungsfach Softwaretechnik und Übersetzerbau Folien und Material unter http://www.ipd.uni-karlsruhe.de/tichy weiter unter Lehre, Empirische Softwaretechnik Kontakt: IPD, Info-Neubau Zimmer 368/372 tichy/muellerm@ira.uka.de 608-3934/7333 2
Erster Teil Einführung in die Thematik der Vorlesung 3
Naheliegende Fragen... Warum heißt die Vorlesung Empirische Softwaretechnik? Was hat diese Vorlesung mit den Methoden und Werkzeugen der Softwareentwicklung zu tun, die in der Pflichtvorlesung vorgestellt werden? 4
Empirie griechisch für Erfahrung. auf methodischem Wege (durch absichtlich 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.) 5
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 6
Phänomen griechisch für etwas, das sich zeigt oder erscheint eine Erscheinung ein wiederholt auftretendes Verhalten Gegenstand von empirischen und theoretischen Untersuchungen 7
Phänomen, Theorie und Empirie beobachten messen bewerten anregen bestätigen verwerfen 8
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. 9
Rolle der Empirie Empirie beobachtet, misst und bewertet Phänomene Empirie bestätigt oder verwirft Vorhersagen von Theorien Empirie regt neue Theorien an 10
Definition: 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 11
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? 12
Stand der Forschung Technik stärkster Teil der Softwaretechnikforschung viele nützliche Werkzeuge verschiedene Programmierparadigmen mehrere Vorgehensweisen (z.b. klassische Entwicklungsphasen, Cleanroom Development, Extreme Programming) siehe Pflichtvorlesung 13
Stand der Forschung (2) Theorie gering entwickelt und meist nur qualitativ formale Softwareprozess-Modelle erste ökonomische Modelle und Kosten-Nutzen- Analysen 14
Stand der Forschung (3) Empirie viel Forschung über Software-Metriken viele Fallstudien in den letzten 10 Jahren mehr systematische Experimente wichtige empirische Erkenntnisse drastisch verbesserte Methodik 15
Gegenstand der Vorlesung konkrete Fallstudien und Experimente aus der Softwaretechnik experimentelle Methodik statistische Datenanalyse softwaretechnische Bewertung der empirischen Ergebnisse neuere Empirie-basierte Theorien 16
Vorgehensweise in der Vorlesung Schritt für Schritt aufbereitete, beispielhafte Originalarbeiten empirisch-methodische Grundlagen anhand der Originalarbeiten statistische Grundlagen nur soweit, wie zur Auswertung der empirischen Arbeiten nötig Zeit für Fragen und Diskussionen 17
Softwaretechnische Themen in der Vorlesung Multiversions-Programmierung Vererbungstiefe Zusicherungen Paarprogrammierung Software-Inspektionen Formale Methoden 18
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 können 19
Lernziele (2) methodische und statistische Grundlagen für empirische Untersuchungen in der Softwaretechnik beherrschen Beispiele Empirie-basierter Theorien in der Softwaretechnik beschreiben können 20
Übergeordnete Lernziele Qualität empirischer Untersuchungen in der Softwaretechnik beurteilen können Tragfähigkeit der daraus abgeleiteten Schlussfolgerungen beurteilen können Kosten und Nutzen von Entwicklungstechniken objektiv abwägen können 21
Literatur Originalarbeiten IEEE Transactions on Software Engineering Journal on Empirical Software Engineering Wohlin et al.: Experimentation in Software Engineering (Kluwer, 2000) Juristo u. Moreno (Herausgeber): Lecture Notes on Empirical Software Engineering (World Scientific, 2003) 22
Literatur (2) Christensen: Experimental Methodology (Allyn and Bacon, 2001) Endres u. Rombach: A Handbook of Software and Systems Engineering (Pearson 2003) 23
Literatur (3) Forschungsarbeiten am Lehrstuhl Tichy Prechelt: Kontrollierte Experimente in der Softwaretechnik (Habilschrift, Springer, 2001) Empirical Informatics Research Group http://www.ipd.uka.de/~exp neuere Publikationen auf den Webseiten von M. Müller und F. Padberg 24
Zweiter Teil Wichtige empirische Forschungsmethoden im Überblick 25
Empirische Forschungsmethoden Fallstudie Feldexperiment kontrolliertes Experiment Umfrage Metastudie 26
Fallstudie genaue Beschreibung und Analyse... eines Vorgangs einer Organisation eines Ereignisses nutzt verschiedene Informationsquellen... Interviews Dokumente Messungen 27
Fallstudie (2) Anwendung Illustration eines Werkzeugs Machbarkeitsstudie Abschätzung der Effizienz einer Technik relativ einfach durchzuführen Ergebnis schwierig zu verallgemeinern Bekannte Fallstudie: Absturz der Adriane- Rakete 28
Feldexperiment in einer realen Umgebung durchgeführt 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) 29
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. 30
Anwendung Feldexperiment (3) 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 31
Feldexperiment (4) realistische Ergebnisse Kontext oft schwer zu erfassen Kosten oft hoch benötigt Unterstützung durch Management 32
Feldexperiment (5) Spezialfall: Software-Archäologie eingriffsfreies Feldexperiment alle Beobachtungen erfolgen erst im Nachhinein basiert auf Daten, die das Projekt sowieso gesammelt hat (Versionsdatenbank, Fehlermeldungen, Fehlerdichten, Bearbeitungszeiten) Qualität der Daten oft schwer einzuschätzen oft fehlen Daten oder Zusatzinformationen 33
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 Fehlerdichte in einem realen Projekt bei IBM auswirkt International Conference on Software Engineering ICSE 25 (2003) 564-569 34
Test-Driven Development zuerst die Testfälle schreiben, dann implementieren ( test-first ) häufiges automatisches Ausführen aller Testfälle (mit junit) wichtige Technik bei XP 35
Fallstudie: TDD bei IBM (2) Produkt JavaPOS (Java for Point of Sale) definiert eine Bibliothek von Java Beans zum Ansprechen von Geräten am Verkaufsplatz bisherige Versionen von JavaPOS hatten zu hohe Fehlerdichte abschließender functional verification test für jede Version 36
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. 37
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] 38
Erhoffte Vorteile von TDD niedrigere Fehlerdichte 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 39
Fehlerdichte bei JavaPOS alt tatsächlich erwartet 7,0 Fehler/KLOC tatsächlich 5,5 Fehler/KLOC erwartet 40
Fehlerdichte bei JavaPOS neu tatsächlich erwartet 3,7 Fehler/KLOC tatsächlich 4,0 Fehler/KLOC erwartet 41
Einige Unklarheiten JavaPOS neu hatte 71 KLOC, aber Größe von JavaPOS alt wird nicht angegeben unklar, ob Fehlerdichte bei JavaPOS alt sich nur auf hinzugekommenen (bzw. geänderten) Code bezieht; JavaPOS neu zeigt 247 Fehler, JavaPOS alt nur 80 Dauer, Größe und Zusammensetzung des Abschlusstests wird nicht angegeben 42
Fazit der Studie Verringerung der Fehlerdichte 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! 43
Einordnung der Studie begonnen als Fallstudie: Einsatz von TDD bei einem Projekt bei IBM Messen von Fehlerdichte, Aufwand, u. a. ausgebaut zu Feldexperiment: Vergleich mit Parallel-Projekt, das ohne TDD durchgeführt wird kontrollierte Variable ist die Testtechnik (unsystematisch versus TDD) 44
Fortsetzung folgt... 45