1 / 29

SE-Themen, für die sich Experimente lohnen

SE-Themen, für die sich Experimente lohnen. Nazli Soltani 7.12.2005. Gliederung. Experimente Aktuelle Experimente (2005) eXtreme Programmierung Paar-Programmierung Test First relativ neue Experimente (1996) Reading Technik

trevet
Download Presentation

SE-Themen, für die sich Experimente lohnen

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. SE-Themen, für die sich Experimente lohnen Nazli Soltani 7.12.2005

  2. Gliederung • Experimente • Aktuelle Experimente (2005) • eXtreme Programmierung • Paar-Programmierung • Test First • relativ neue Experimente (1996) • Reading Technik • Code Reading vs Functional Testing vs Structural Testing • Cleanroom vs non-Cleanroom • Senario Based Reading • Ältere Experimente (1986) • Studentisches Beispiel

  3. Experiment • Experiment ist : • "a form of empirical study where the researcher has a control over some of the conditions in which the study takes place and control over the independent variables being studied (execution and measuremnet controls) „ Vivtor R. Basili 1999 • “Experimentation provides a systematic, disciplined, quantifiable and controlled way of evaluating humanbased activities” Wholin 2000

  4. Experiment • Experimente : • kontrollierte Experimente • über kleine Objekte • in vitro • Anfänger und Experten • quasi-experiments oder pre-experimental designs • große Projekte • in vivo • mit Experten • involvieren meistens eine qualitative Analyse

  5. Experimentieren die Wissenschaftler genug? • Eine Zusammenfassung von 612 Veröffentlichungen im SE (Zelkowitz, 1997): • 30% davon beinhalteten keine Experimente, obwohl es notwendig war.(20% in andere Wissenschaften) • Eine Zusammenfassung von 400 Veröffentlichungen (Tichy, 1995): • 40% davon beinhalteten keine Experimente und die brauchten empirische Bewertung.

  6. Warum Experimentieren die Wissenschaftler nicht genug? • Die meisten behaupten: • Es gibt genug Experimente • Informatiker sehen ihre Behauptungen nicht kritisch genug. • Experimente sind zu teuer • gute Planung minimiert die Kosten • gute Experimente sind die höhen Kosten wert

  7. Experimentieren die Wissenschaftler genug? • Die Experimente verlangsamen die Prozesse • mehrere Veröffentlichungen mit bedeutungsvoller Bewertungen beschleunigen den Prozess • „Technology changes too fast“ • die Frage ist sehr schnell irrelevant • die Frage ist nicht genau definiert • Es war von Anfang an nicht die Mühe wert.

  8. Aktuelle Experimente : eXtreme Programmierung • eXtreme Programming die bekannteste Agile Methode • am sorgfältigsten untersuchten Praktiken von XP: Paar-Programmierung und Testgetriebene -Entwicklung. • Eine Zusammenfassung von durchgeführten Experimenten • Universität Karlsruhe 2005 • Walter F. Tichy, Matthias M. Müller, und Frank Padberg • Fakultät für Informatik

  9. Paar Programmierung • 3 Szenarien : • Paar-Programmierung : • 2 Entwickler vor einem Rechner • Partner-Programmierung : • 2 Entwickler vor 2 Rechnern lösen die Aufgabe in konventioneller Gruppenarbeit • Einzel-Programmierung : ein Entwickler löst die Aufgabe allein

  10. Paar Programmierung • Quantitativen Studien • ökonomische Aspekte • Ausgleich der verdoppelten Entwicklungs-Kosten durch die schnellere Entwicklung und die bessere Qualität • Qualitative Studien • soziale Effekte • Auswirkung auf die Lehre

  11. Paar-Programmierung

  12. Test-First • liegen brauchbare Studien vor • nicht so viel wie bei PP • 2 Faktoren : • Zeitpunkt des Erstellens des Tests • immer vor der Entwicklung der zu testenden Software-Komponente • automatische Durchführbarkeit des Tests • als Regressionstest bekannt

  13. Experimente über Testgetriebene Entwicklung (TGE) Übersicht über die untersuchten Testtechniken

  14. Experimente über TGE Empirische Studien über testgetriebenes Entwickeln Merkmale der Studien über testgetriebene Entwicklung

  15. Experimente über TGE • verlangt ein Umdenken der Entwickler • nur mit nachträglichem Testen vertraut sind • erfordert eine lange Lernkurve • Ohne entsprechende Schulung führt zu oberflächlichem Testen, das die Entwickler in falscher Sicherheit lockt • die Zeitspanne unbekannt • nicht Vertrautheit mit der Methode • “Richtige” TGE führt zu • besser testbaren Komponenten • besserer Qualität

  16. Experimente über XP • An der Universität Hannover • Thomas Flohr, Thorsten Schneider • Ergebnisse • Test-First führt zu einer schnelleren Entwicklung • Studenten lehnen Test-First nicht ab • PP um Prozesserfüllung zu sichern • Studenten: Test-First nicht besser oder schlechter

  17. Relativ neue Experimente • Experimente über „Reading-Techniques“ • Was ist eine „Reading-Technique“? • „a concrete set of instructions given to the reader saying how to read and what to look for in a software product.“ • Software Reading: „the individual analysis of a software artifact e.g., requirements, design, code, test plans to achieve the understanding needed for a particular task“ e.g., defect detection, reuse, maintenance • an der Universität von Maryland von V.Basili und NASA.

  18. Experimente über „Reading Techniques“ • Serie von Experimenten: • Code Reading vs Functional Testing vs Structural Testing • Cleanroom vs non-Cleanroom • defect-based reading vs ad-hoc reading vs check-list reading • perspective-based reading vs NASA’s reading Technik.

  19. Experimente über „Reading Techniques“ • Code Reading vs Functional Testing vs Structural Testing • Vergleich von • Fehler-Erkennung und Kosten • Verschiedene Fehler-Klassen • Ergebniss: • Code Reading mehr effektive für Interface-Fehler-Erkennung • „Functional und Structural Testing“ mehr effektive für „control flow“ Fehler • über 90% : „functional testing“ besser ?! • Entwickler wollen nicht glauben, dass „reading“ besser ist.

  20. Experimente über „Reading Techniques“ • Implementieret im SEL Entwicklungsprozess • sehr wenig effektive • lesen und nachher testen • nicht gelesen wie sie müssten • erzwingen zum Lesen • Cleanroom vs non-Cleanroom • Cleanroom-Entwickler waren motiviert zum Lesen • Cleanroom/Reading war effektiv • verringert die kosten für Veränderungen • Cleanroom Produkt • weniger Komplex • näher an der Anforderungen

  21. Experimente über „Reading Techniques“ • „Senario-Based Reading“ • Zielgesteuert • anpassbar an der Umgebung und dem Projekt • verwendbar in vorhandenen Methoden, z.B. Inspektionen • spezifische Notation • Zwei Familien von „Senario-Based reading techniques“ für Anforderungs-Dokumente • Perspektive-Based Reading • fokussiert auf verschiedene Sicht des Anwenders • für Anforderungsdokumente im Englisch • Defect-Based Reading • fokussiert auf verschiedenen Fehlerklasse • für Anforderungsdokumente in SCR Style (Software Cost Reduction)

  22. Experimente über „Reading Techniques“ • Experimente • defect-based reading vs ad-hoc reading vs check-list reading • perspective-based reading vs NASA’s reading Technik. • Vergleich von • Effektivität der Fehlerekennung

  23. Experimente über „Reading Techniques“ • Ergebnisse: • Senario-Based Reading besser als Ad-Hoc, check-list and NASA‘s Readingsmethode • wenn wenig vertraut mit dem Arbeitsgebiet • PBR soll besser an der Umgebung angepasst werden • Effekt mehr in Teamarbeit • findet verschiedene Fehlerklassen abhängig von der Sicht

  24. Ältere Experimente • „Programm Debugging“ • Gould, Drongowski(1974) • die Effekte von • „debugging aids“ • Fehlertyp • Entwickler oder Verwalter • Ergebnisse: • Zuweisungsfehlern Schwierig zu finden • mit Erfahrung einfacher • „debugging aids“ nicht hilfreich

  25. Ältere Experimente • „Flowcharts vs Programm Design Languages (PDL)“ • Ramsey, Atwood, Van Doren (1983) • aus der Sicht des Entwicklers • Ergebnisse: • Kommunikation und „Design Performance“ besser bei PDL

  26. Studentisches Beispiel • Masterarbeit zu zweit • Frage: • ob die Paare die Arbeit beschleunigen oder sich gegenseitig aufhalten??? • ähnlich wie PP? • DIE • Frage: • Welche DIE für welche zwecke? • Eclipse • Net-Beans von Sun • JBuilder von Borland • am schnellsten und besten entwickeln?

  27. Studentisches Beispiel • Alle verfügen über: • Syntax Highlighting • Editor, Debugger und Compiler • Setzen von Breakpoints beim Debuggen • der Editor kann nach den Bedürfnissen des Benutzer angepasst werden • Anzeige der Zeilennummern • Klassenbrowser zum Anzeigen der Klassenstrukturen • eingebauter API Browser (Code Komplettierung) • Entwicklung für verschiedene SDK Versionen möglich (1.3, 1.4 oder 1.5) • …

  28. Gliederung • Experimente • Aktuelle Experimente (2005) • eXtreme Programmierung • Paar-Programmierung • Test First • relativ neue Experimente (1996) • Reading Technik • Code Reading vs Functional Testing vs Structural Testing • Cleanroom vs non-Cleanroom • Senario Based Reading • Ältere Experimente (1986) • Studentisches Beispiel

  29. Quelle • V. R. Basili and F. Lanuble, "Building Knowledge through Families of Experiments,"IEEE Transactions on Software Engineering, vol. 25, pp. 456-473, 1999. • Walter F. Tichy, Matthias M. Müller and Frank Padberg, „Ist XP etwas für mich? Empirische Studien zur Einschätzung von XP“ Fakultät für Informatik, Universität Karlsruhe, 2005. • Walter F. Tichy,“Should Computer Scientists Experiment More?“,1998. • V. R. Basili, „Experimentation in Software Engineering“,1986, 2002. • Matthias M. Müller, Johannes Link, Roland Sand, and Guido Malpohl, “Extreme Programming in Curriculum: Experiences from Academia and Industry“ Universität Karlsruhe, andrena objects ag, 2003. • V. R. Basili, „Evolving an Packaging Reading Technologies“, 1996.

More Related