Die Rolle der Empirie in der Softwaretechnik

Transkript

1 Die Rolle der Empirie in der Softwaretechnik Universität Karlsruhe UNIVERSITÄT KARLSRUHE (TH) Fakultät für Informatik

2 Raffaels Schule von Athen Folie 2

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

4 Modernes Verständnis von Wissenschaft Wir überspringen Ptolemäus, Kopernikus, Tycho Brahe, Galileo, Kepler, Francis Bacon, John Lock, 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 Folie 4

5 Was ist ein Experiment? Erfahrungswissenschaftliche Methode, um angenommenes Gesetzmäßigkeiten (Hypothesen) in der Umwelt durch Beobachtung zu überprüfen. Im Experiment wird durch planmäßiges Beobachten eines Sachverhaltes [ ] und dessen Veränderung unter kontrollierten, [ ] wiederholbaren Bedingungen eine Hypothese bestätigt bzw. widerlegt. (Quelle: Microsoft Encarta Online-Enzyklopädie) Wichtig hier: planmäßige Manipulation von Variablen, W iederholbarkeit, Objektive Beobachtung Kausalität (Ursache-W irkung-beziehung) Folie 5

6 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. Folie 6

7 Hierzu gäbe es noch viel mehr zu sagen Lakatos Forschungsprogramme Kuhns Paradigmen Theorie braucht Raum und Zeit für ihre Entwicklung Falsifikationsversuche erst später W issenschaft folgt nicht dem Falsifzierungsweg Sondern es gibt Revolutionen, bei denen eine Theorie zu gunsten einer anderen verworfen wird. Dazwischen findet Normalwissenschaft statt (Ausbau, Stärkung, Abrundung, Anwendung) Feyerabends Anarchie Historisch gesehen gibt es keine wissenschaftliche Methode anything goes um neue Theorien zu finden Der Einzelne muss aber kompetent und informiert sein; wiss. Standards. Folie 7

8 Neugierig geworden? Alan F.Chalmers, What is This Thing Called Science?, Open University Press, Bruno Latour, Science in Action: How to follow Scientists and Engineers through Society, Harvard University Press, Folie 8

9 Und was hat das alles mit Software zu tun? Ist die Methodik der Naturwissenschaften überhaupt auf Softwareforschung, ja auf Informatik anwendbar? Informatik behandelt die Verarbeitung von Information mittels technischer Mittel. Die sind alle künstlich wo ist die Natur? Liegen nicht die (natur-)wissenschaftlichen Aspekte in anderen Disziplinen (z.b. Physik, E-Technik, Mathematik)? Folie 9

10 Informatik ist die Wissenschaft von den Informationsprozessen Künstliche Informationsprozesse ( Computer Science ) Algorithmen Datenbanken Betriebssysteme Übersetzer RechnerArchitekturen Simulation Simulation natürliche Informationsprozesse Simulation Simulation Kognition Intelligenz DNA Immunsystem Folie 10

11 Unterscheidung künstlich/natürlich ist künstlich? Künstliche Informationsprozesse ( Computer Science ) ProgrammierMethoden ProgrammierSprachen SoftwareWerkzeuge Brauchbarkeit? Wie geht Programmieren? natürliche Informationsprozesse Brauchbarkeit? Brauchbarkeit? Folie 11

12 Wozu Empirie in der SWT? Empirie (d.h. Nutzung von Erfahrung, Beobachtung, Experiment) ist aus der Softwareforschung nicht mehr wegzudenken. empirische Studien stellen fest, ob Unterschiede zwischen alternativen Softwaretechniken tatsächlich zu beobachten sind, z.b. hinsichtlich der Qualität oder den Kosten der erstellten Software. dies sind zumeist explorative Studien, d.h. solche, die Phänomene erkunden, ohne sie zunächst erklären zu können. Folie 12

13 Wozu Empirie? Korrelationsstudien untersuchen Zusammenhänge zwischen Variablen bei der Softwarebearbeitung, Vorhersage- und Optimierungsmodelle machen die entdeckten Zusammenhänge für Entscheidungen bei der Softwarebearbeitung nutzbar, z.b. zwischen der Größe der Software und dem benötigten Aufwand zu Ihrer Erstellung. z.b. bei der Kostenschätzung empirische Studien falsifizieren Hypothesen z.b. die Unabhängigkeitsannahme bei Multiversionsprogrammierung Folie 13

14 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, empirisch überprüfte Theorien, die etwas über die Wirklichkeit der Softwarebearbeitung aussagen, sind das eigentliche Ziel der Forschung. Gegensatz: Math. Theorie fußt auf Annahmen und logischen Folgerungen, nicht auf Beobachtung. Folie 14

15 Softwareforschung Was ist mit Software automatisierbar und wie? Technik Produkt & Prozess Methoden W erkzeuge Was geht in der SW-Entwicklung eigentlich vor? Wie entwickelt man Software schnell und gut? Stimmt die Theorie? Wie funktionieren Methoden? Was passiert wenn...? Theorie Empirie Modelle, Gesetze, Metriken,Psychologie, Formalisierung Theorietest Technikbewertung Erkundung v. Phänomenen empirische Methodik Folie 15

16 Forschungsmethoden Fallstudie Umfrage Korrelationsstudie Feldexperiment Kontrolliertes Experiment Metastudie Ethnographische Studie Langzeitstudie Simulation Benchmark-Studien U.a. Folie 16

17 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-VersionsProgrammierung geringer als angenommen. Folie 17

18 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! Folie 18

19 Ü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 das Zuverlässigkeit bei weitem nicht so hoch, wie gedacht (100%), aber durch die Redundanz sicher besser als ohne. Folie 19

20 Noch ein Experiment: Inspektionen (Porter et al.) Interessanter Experimentaufbau: Durchführung als Teil einer professionellen Software-Entwicklung Wieviele Inspektionen braucht die Software? Ergebnis 1: zwei Inspektoren reichen Ergebnis 2: Mehr Inspektoren verbessern zwar die inspizierten Komponenten (Sättigung), aber reduzieren insgesamt die Anzahl der inspizierten Komponenten (keine Zeit, keine Zeit!), so dass letztlich mehr Fehler unentdeckt bleiben. Folie 20

21 Ernüchterung... wir sind erst hier... Mode Berater... da müssen wir hin! Folie 21

22 Was ist falsch am reinen Empirismus? 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 wissenschaftstheoret. 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, die sich gegenseitig informieren. Folie 22

23 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) Folie 23

24 Theorie zu Inspektionen laut Sauer et al. Folie 24

25 Erklärungen der Theorie 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 Folie 25

26 Weitere Erklärungen zum Nutzen der Gruppensitzung: Gruppensitzung trägt nicht signifikant zum Entdecken von Fehlern bei. Notwendigkeit des Identifizierens von vermeintlichen Defekten Interaktion in der Gruppe bringt keine neuen Lösungen Gruppe hat mehr Sachverstand über Defekte als ein einzelner Inspektor Fehlt: Gruppengröße beeinflusst die verfügbaren Termine und damit die Überdeckung mit Inspektionen. Folie 26

27 Paarprogrammierung Folie 27

28 28Tichy Walter F. Folie 28

29 Paarprogrammierung Ein zentrale Technik der sog. agilen Methoden. Jede Zeile Produktionscode wird von zwei Programmierern an einem Rechner und einer Tastatur erstellt. Gegner: Anarchie! Verschwendung! Glorifziertes Hacken! Befürworter: Schluss mit Software-Bürokratie! Geschwindigkeit, Qualität, Flexibilität, Spaß am Programmieren! Hat alle Zeichen eines Religionskrieges (ist einer) Experimente geben mal dem einen, mal dem anderen den Vorzug. Zu viele Variablen Komplexität, Größe der Probleme Erfahrung der Paare, Marktdruck Gewünschte Flexibilität der Software, etc.) Folie 29

30 Überraschung: Ein einfaches Modell führt ziemlich weit! Padberg und Müller benutzen ein ökonomisches Modell, um Paarprogrammierer und Einzelprogrammierer zu vergleichen (see ESEC/FSE 2003): Kapitalwert-Betrachtung, um den Wert des frühen Markteintritts zu quantifzieren Berücksichtigt den Geschwindigkeitsvorteil der Paare Berücksichtigt den Qualitätsvorteil der Paare Berücksichtigt die höheren Kosten der Paare. Folie 30

31 Kapitalwert (engl. Net Present Value) NPV = AssetValue / (1+ DiscountRate)DevTime - DevCost DevCostPP ~ DevTimePP x NumOfPairs x 2 DevCostS ~ DevTimeS x NumOfDevelopers DevTime is dependent on project size, productivity of pairs vs. single programmers rework time of single programmers to get same defect density (compensating pair quality advantage) Folie 31

32 Was bringt s? Abwägung: Bei welchen Parameterwerten gewinnt Paaroder Einzelprogrammierung? Bestimme die Break-Even-Kurve; Sensitivitäts-Analyse; Was macht man mit begrenzter Entwicklermannschaft? Paare oder einzeln? Bestimme Effekt von inkrementeller Lieferung; Lernkurve kann mit berücksichtigt werden; Hypothesen können mit Experiment oder Simulation überprüft werden; Liefert klare Empfehlungen; Ende des Glaubenskrieges. Folie 32

33 Qualitative Recommendations Pair programming yields higher NPV than single programmers if discount rate is high (0.75) and pairs are almost twice as fast as single programmers (1.8) If a project allows enough parallelism and the speed advantage is not great, use single programmers. Incremental delivery increase the NPV for both, but more so for pair programming. An extension of the model takes into account the learning curve of pairs (Metrics 2004). Exponential or S-curve learning: added cost is a few percentage points. Folie 33

34 Komplizierteres Modell: Kostenschätzung Schätzmodell Mittlerer Fehler Funktionspunkte 103% CoCoMo 600% Slim 772% (Kemerer 1987) Problem: traditionelle Modelle sind statisch, d.h. sie basieren auf einer einzigen Schätzgröße (LOC) und beziehen mögliche Projektverläufe nicht mit ein. Folie 34

35 Einflussfaktoren Kosten hängen ab vom Projektverlauf Exakte Entwicklungsdauer von Komponenten ist unbekannt. Verzögerungen, Fehler, Nachbesserungen erreignen sich. Benötigt ist eine Wahrscheinlichkeitsverteilung der Entwicklungsdauern, nicht eine einzige Zahl. Entwurfsänderungen führen zu Zusatzarbeit. Benötigt wird ein Maß für die Kopplung zw. Komponenten, d.h. die Wahrscheinlichkeit, dass sich eine Änderung fortpflanzt. Folie 35

36 Markov-Modell: Projektbaum Projektstart Komponente A fertig Redesign Komponente B Komponente C fertig fertig Komponente A fertig Redesign Komponente A Redesign fertig Knoten ~ Meilenstein-Ereignis Pfad w ~ einzelner Projektverlauf P(w) ~ Wahrscheinlichkeit von Pfad w Folie 36

37 Aufsummierung von P(w) für geg. Dauer Wahrscheinlichkeit (Prozent) Dauer (Wochen) Viel besser als eine einzelne Zahl! Wahrscheinlichkeit berechenbar, dass Projekt in n Wochen fertig ist. Risikoabwägung möglich. Folie 37

38 Planung wird zum stochastischen Optimierungsproblem Welche Komponente übernimmt ein Team als nächstes? Finde Abwicklung mit minimalen Kosten im Markovmodell. Gibt es praktikable Planungsstrategien? Wie weit liegen diese vom Optimum? Sollten Komponenten mit hohem Kopplungsgrad früh oder spät entwickelt werden? Voraussagen des Modells testbar. Folie 38

39 Dringend notwendige Experimente Funktionale vs. imperative vs. OO vs. SkriptSprachen Was hat wann Vorteile? Dynamische Typisierung vs. statische Typisierung Verifikation vs. Testen UML vs. Kommentare oder schriftl. Doku Testverfahren Testgetrieben Entwicklung vs. ad hoc Testen vs. Zusicherungen Nutzen von Qualitätsstandards? (CMM, etc.) Fremdvergabe vs. lokale Entwicklung (OffshoreDebatte) Folie 39

40 Was sollten wir in den nächsten 10 Jahren erzielen? Wissen darüber, welche Methoden und Werkzeuge besser funktionieren als andere, unter welchen Umständen und warum. Belastbare theoretische Modelle, die erklären und vorhersagen. Professionelle Entwickler, die die Vertrauenswürdigkeit von Experimenten einschätzen können. die vernünftige Fragen über Experimente und Theorien stellen und die Antworten verstehen. Zahlreiche neue Methoden und Werkzeuge, die die Softwarebearbeitung nachweislich erleichtern. Empirie ist mittendrin in der Softwaretechnik! Folie 40

41 Fragen? (Goldener Schnitt) Folie 41

42 Weitere Beispiele für Experimente Übersicht über die in Karlsruhe durchgeführten Experimente: Simula Research Lab, Norway, Software Engineering: Folie 42