Techniken

Experiment about Test-First Programming

• kontrolliertes Experiment, XP Kurs, zwei Gruppen (TFG, CG)
• nicht betrachtet: Langzeitwirkung, Entwurfsaspekte
• Aufgabe: Graph-Bibliothek mit vorgegebenen Methodendeklarationen und Hilfsmethoden
• Ablauf: Implementierungsphase (IP) > Akzeptanztestphase (AP, 100%-Schwelle, 20 Tests) > großer Zufallstest (7,5 Mio Zusicherungen, Vergleich zu Goldprogramm)
• Ergebnisse
  • Programmiereffizienz: kein Unterschied
  • Korrektheit : CG schlechter nach IP, nach AP besser (mögliche Antworten: falsche Sicherheit, geringerer Stellenwert des Akzeptanztests)
  • Verständnis des Codes: Weniger Fehler bei / schnellere Weiterbenutzung von Methoden
  • TFG kürzer in der IP, TFG unzuverlässlicherer Code nach IP
  • test first hilft nicht bei der richtigen Verwendung von existierendem Code, aber hilft ihm durch andauernden Testens den Fehler zu beheben
• Gültigkeitsbedrohungen
  • intern: nicht technisch kontrolliert; TFG wurde überprüft, ob sie mit mit test first zurecht kommen
  • extern: Studenten, keine Erfahrung, Aufgabe (Graphen)

An experimental evaluation of the assumption of independence in multiversion programming

• Annahme MVP: Fehler unabh. voneinander, Fehler treten zufällig auf
• Aufgabe: einfaches Antiraketensystem (bereitgestellte Funktion zum Vergleich von reellen Zahlen)
• 27 Versionen der Software, 1 Millionen zufällig generierte Tests, 1 Gold Version
• 241 Ergebnisse (Array, Vektor und Abschussentscheidung)
• Akzeptanztest: 200 zufällig generierte Tests (für jeden andere)
• Ergebnis
  • unabhängig voneinander sehr verlässlich
  • selber Tests von verschiedenen Versionen
  • MVP sollte nur mit Sorgfalt eingesetzt werden
  • manche Teile schwieriger als andere, Anforderungen falsch
• Gültigkeitsbedrohungen
  • verschiedene Entwicklungsumgebungen der beiden Universitäten
  • Akzeptanztest randomisiert -> manche können mehr Fehler finden als andere

A Realistic Empirical Evaluation of the Costs and Benefits of UML in Software Maintenance

• Motivation: bringt UML Vorteile (Verständnis, Kommunikation)
• kontrolliertes Quasi-Experiment, 20 prof. Entwickler (mit Kenntnis von UML + IDE), Java, 5 Wartungsaufgaben, Dauer: 1 - 2 Wochen (in 3 Jahren), IDE: Eclipse, UML-Tool: Borland, Kurs für Experimentiergruppe, keine Zeitbegrenzung
• unabh. Variablen: Verwendung von UML?
• abh. Variablen: Aufwand (ohne / mit Diagrammmodifikation), funktionale Korrektheit (# abgegebener Lösungen), Entwurfsqualität
• Gruppen: Enteilung first-come first-served, wussten nicht von der jeweils anderen Gruppe, max 3 Teilnehmer gleichzeitig
• System: BESTweb, webbasiert, Softwarekosten und -aufwandsschätzung durch Identifikation rel. Paper (1 Use Case, Seq pro Use Case, Klassendiagramme), ausführlich dokumentiert (auch ohne UML)
• Ablauf: Einführung > Fragebogen > Training > Aufgabe > Schätzung > Entwicklung > Akzeptanztest > ... > Interview
• Aufgaben (Wartung): inkrementell schwerer, 3-6 Tage (7.5h/Tag), Kontrolle: Aufgaben in Subaufgaben --> granulärer
• Tests: abgeleitet aus Diagrammen, überdecken alle Pfade, neue Funktionalität: Checklist (Hauptflow, Ausnahmefälle)
• Analyse: quantitativ: abh. Variablen: 2 sample t-test + Wilcoxon Rangsumme + ANCOVA, qualitativ: Interview am Ende (1h)
• Ergebnisse
  • Aufwand ohne Diagrammmod: UML-Gruppe schneller (insignifkant)
  • kompletter Aufwand: UML-Gruppe langsamer (insignifikant)
  • Korrektheit: UML 54% besser (Messung fragwürdig)
  • OO-Qualität: UML besser (1. Aufgaben signifikant)
  • UML: am meisten genutzt Use Case und Seq-Diagramme
  • Fazit: UML unnötig
• Gültigkeitsbedrohungen
  • geringe Güte --> unwahrs. stat. sign. Effekt zu finden
  • intern: Einteilung nicht randomisiert (aber insignifikant), Experimentatoreffekt? (testet und nimmt Lösungen an), Dauer UMLmod geschätzt, Probleme mit Tool
  • Konstrukt: Qualitätsmessung, Teilnehmer müssen UML vorher genutzt haben, Kosten nicht durch Experiment abbildbar, keine eigenen Testfälle
  • extern: nur Wartung (System neu für Entwickler), keine Kommunikation