Empirische Softwaretechnik
Im Jahr 2002 verglichen wir mit einem kontrollierten Experiment Paare von Programmierern mit einzelnen Entwicklern. Letztere wurden durch eine zusätzliche anonyme Durchsicht ihres Programmtextes unterstützt. Motiviert wurde diese Studie durch das Ziel, eine Technik zu finden, die nur 20% der Kosten von Programmiererpaaren hat, aber 80% der Qualität liefert. Da Inspektionen eine anerkannte Technik zur Qualitätssicherung sind, lag es nahe, den Vorbereitungsprozess auf Inspektionen, die Durchsichten, als potentiellen Kandidaten zu untersuchen. Teilnehmer waren 20 Studenten des XP-Praktikums.
Zwei erste Resultate konnten festgehalten werden: Erstens, wenn gleiche Qualität erreicht werden soll, so sind einzelne Entwickler fast genauso teuer wie Entwicklerpaare. Zweitens, wenn gleiche Qualität nicht gefordert ist, sondern nur das Fertigstellen der Aufgabe, so sind die Programme der Paare im Mittel 7 - 13% zuverlässiger bei durchschnittlich jedoch 24% höheren Kosten. Beide Ergebnisse konnten jedoch nicht statistisch untermauert werden.
Planung und Steuerung von Softwareprojekten
Es ist eine schwierige Aufgabe in der Praxis, die verfügbaren Entwickler den Aufgaben in einem Softwareprojekt so zuzuordnen, dass das Projekt möglichst schnell abgeschlossen wird. Die Zuordnung muss berücksichtigen, welche Aufgaben gerade in Arbeit sind, welche Entwickler gut für eine unerledigte Aufgabe geeignet sind, welchen Entwicklungsaufwand die Aufgaben haben und welchen weiteren Verlauf das Projekt nehmen könnte. Eine optimale Zuordnungs-Strategie ist daher schwer zu finden. Manager behelfen sich oft mit einfachen Regeln, z.B. große Komponenten zuerst zu entwickeln.
Aufbauend auf unserem wahrscheinlichkeitstheoretischen Modell für Software-Projekte haben wir ein Werkzeug entwickelt, mit dem man den Verlauf eines Projekts simulieren kann. Aus den Ergebnissen der Simulationsläufe kann man die Wahrscheinlichkeitsverteilung und den Erwartungswert für die Dauer des Projekts berechnen. Beispiele zeigen, dass die Wahl der Strategie einen großen Einfluss auf die Projektdauer hat. Außerdem zeigt sich, dass die Qualität einer Strategie von den Kenndaten des Projekts abhängt, etwa von der Stärke der Kopplung zwischen den Komponenten der Software.
Unsere Forschung wird von der DFG unter dem Projektnamen OASE (Optimale Ablaufsteuerung für die Software-Entwicklung) gefördert.
Leichtgewichtige Software-Prozesse
Extreme Programming und andere leichtgewichtige Software-Prozesse werden viel diskutiert, aber es mangelt an Modellen, mit denen sich der Nutzen und die Kosten dieser Prozesse gegeneinander abwägen lassen. Dazu müssen zunächst einzelne Techniken, z.B. die Paarprogrammierung beim Extreme Programming, bewertet werden. Bei der Paarprogrammierung arbeiten je zwei Entwickler gemeinsam an einer Aufgabe, so dass sich die Personalkosten im Vergleich zur herkömmlichen Entwicklung verdoppeln. Ein Paar von Programmierern ist aber schneller als ein einzelner Programmierer und der entstehende Code meist von höherer Qualität.
Die Frage ist, ob der Nutzen der Paarprogrammierung die erhöhten Personalkosten ausgleicht. Um diese Frage zu untersuchen, haben wir ein Kosten-Nutzen-Modell für Paarprogrammierung entwickelt. Es stellt sich heraus, dass der ökonomische Kontext, in dem ein Projekt abläuft, von entscheidender Bedeutung ist. Ist der Marktdruck besonders hoch, dann kann sich Paarprogrammierung finanziell lohnen. Ist der Marktdruck hingegen niedrig, werden im allgemeinen die Kosten der Paarprogrammierung ihren Nutzen übersteigen.
Methoden der Software-Zuverlässigkeit
Software-Inspektionen sind eine wichtige Technik zur Qualitätssicherung in der Software-Entwicklung. Inspektionen lassen sich auf praktisch alle Dokumente anwenden, die bei der Software-Entwicklung entstehen, also auch Pflichtenhefte oder Entwürfe. Dadurch ist es möglich, Fehler schon weit vor dem Testen zu finden. Um zu entscheiden, ob ein Software-Dokument in die nächste Entwicklungsphase übernommen werden kann oder erst weiter verbessert werden muss, wird anhand der Ergebnisse der Inspektion (z.B. gefundene Fehler je Inspektor) geschätzt, wieviele Fehler noch in dem Dokument enthalten sind.
Bisherige Methoden zum Schätzen der Fehleranzahl nach einer Inspektion sind viel zu ungenau, um in der Praxis brauchbar zu sein. Wir haben einen neuen Ansatz entwickelt, der im Gegensatz zu den bekannten Methoden nicht nur die Ergebnisse der Inspektion selbst, sondern auch die Ergebnisse früherer Inspektionen zur Schätzung ausnutzt. Unser neuer Ansatz liefert auf dem Standardbenchmark für Software-Inspektionen sehr gute Schätzergebnisse: unser Ansatz ist um einen Faktor 4 bis 5 genauer als die bekannten Methoden.
