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