Software project managers must schedule quality assurance activities. This is difficult because not enough information is available. Therefore, we developed and validated the quantitative model CoBe. It is based on detailed relationships and is quantified with historical data. It allows to decide which reviews and tests have to be conducted, how they are conducted, and how corrected defects are retested. The results are costs and benefits for quality assurance activities during development and after delivery. Results are given in terms of effort, time, and staff. They are summed up and weighted financially so that an optimal trade-off between costs and benefits can be found. The model is validated with real-world data: Detailed relationships and the complete model are validated with data from 21 student projects. A sensitivity analysis was conducted. CoBe was also validated with data of two industry projects. Overall, the model results are sufficiently accurate. But a calibration is necessary for applying the model in a specific environment. For this, only a few parameters must be set. Their values can be obtained from data that is available frequently from past projects.

Verbesserungen in der Software-Entwicklung basieren auf der Annahme, dass Fehler günstiger zu beheben sind, wenn sie möglichst früh entdeckt werden [Boe76,Boe87]. Erfahrungsberichte bestätigen diesen Zusammenhang [Bas84, Hum95, Kan03, Shu02]. Aktuelle oder detaillierte Zahlen liegen aber nicht vor. Darum ist zum Beispiel unklar, ob und wie sich ein objektorientiertes Vorgehen auswirkt und welche anderen Faktoren den Korrekturaufwand bestimmen. Darum untersuchen wir den Korrekturaufwand einzelner Fehler. Wir prüfen, ob die Korrektur eines Fehlers aufwändiger wird, je länger der Fehler unentdeckt bleibt. Die Dauer, über die der Fehler unentdeckt bleibt, bezeichnen wir als Latenzzeit. Fehler werden bei bestimmten Tätigkeiten gemacht, beispielsweise entstehen Spezifikationsfehler bei der Analyse und Spezifikation: Die Tätigkeit bestimmt die Abstraktionsebene des Fehlers. Prüfungen entdecken nur Fehler, die auf einer bestimmten Abstraktionsebene oder darunter gemacht wurden [Frü06]: Spezifikationsfehler können nur durch ein Review der Spezifikation oder wieder ab dem Systemtest entdeckt werden; im Gegensatz dazu werden Codefehler bereits im Unittest entdeckt. Wir vermuten als weiteren Einfluss die Fehlerschwere und die Zahl der zur Korrektur betrachteten oder geänderten Software-Einheiten. Aus diesen Überlegungen haben wir die folgenden Hypothesen abgeleitet:

Software project managers' decisions on reviews and tests are difficult. This paper describes a cost-benefit model for specific decisions on quality assurance. The quantitative model is based on single relationships and is quantified with historical data. Its results are shown and are compared with cost estimations. The model is able to reflect reported results of process improvement. Data collected in student projects is used to evaluate the model. Project averages and single projects are considered. Furthermore, results of a cross-validation are shown.

In der Ausbildung angehender Projektleiter mussen nicht nur theoretische Kenntnisse vermittelt werden, sondern auch deren praktische Anwendung. Die Kombination aus Vorlesung und Praktikum vermittelt die Theorie und verlangt ihre Umsetzung. Sie erlaubt es aber nicht, die Zusammenhange zwischen den theoretischen Grundlagen und der Umsetzung nachzuvollziehen. Diese Schwache lasst sich ausgleichen, in dem wahrend der Ausbildung eine Projektsimulation mit detaillierter Auswertung durchgefuhrt wird. In diesem Artikel zeigen wir, wie die simulierten Projekte ausgewertet werden, stellen Beispielauswertungen vor und diskutieren den dadurch erzielten Lernerfolg.

The benefits of reviews are well-known in software quality assurance. Nevertheless, in industry they are often used in a truncated or shortened way, if at all. The costs are obvious and arise immediately, whereas the benefit of improved quality is hard to measure, and is achieved only in the long run. As decisions often focus on reducing development time and effort, we present an estimation model for costs and benefits of specification and design reviews. The estimation results are discussed in this paper. For in-process benefits, benefits in maintenance and in usage, the results match reported experiences.

Im Studiengang Softwaretechnik an der Universitat Stuttgart mussen alle Studierenden im Hauptdiplom an zwei Studienprojekten teilnehmen. Das erste Studienprojekt (Studienprojekt A) wird von den Informatikinstituten ausgegeben, das zweite Studienprojekt (B) wird im Anwendungsfach von Instituten anderer Fakultaten durchgefuhrt [Stu05]. Die Teilnehmer an einem Studienprojekt sollen die wesentlichen Aktivitaten von Softwareprojekten selbststandig planen und durchfuhren [Lud01]. Neben allen Tatigkeiten zur Entwicklung mit Vorprojekt, Spezifikation, Entwurf, Implementierung, Integration, Test und Auslieferung gehoren dazu auch Projektplanung und -kontrolle, Qualitatssicherung und weitere projektbegleitende Masnahmen. Unterstutzend stehen ihnen Betreuer der ausgebenden Abteilung zur Seite. Ein Teilnehmer ubernimmt die Rolle des Projektleiters. Die Kundenrolle wird von einem Mitarbeiter der Abteilung ubernommen, aber auch von externen Kunden aus der Industrie [Ham05]. An jedem Studienprojekt nehmen 6 bis 12 Studierende teil. Die Studienordnung [Stu05] nennt fur Studienprojekte eine Dauer von zwei Semestern und einen Aufwand von 16 SWS (Semesterwochenstunden) pro Teilnehmer. Davon entfallen 6 SWS auf konventionelle Lehrveranstaltungen. Die Projektarbeit mit 10 SWS entspricht 400 Eh (Entwicklerstunden) pro Teilnehmer. Bislang wurden Metriken in den Studienprojekten von den Teilnehmern erhoben und anekdotisch in den Abschlussprasentationen gezeigt. Da diese Daten aber nicht zentral gesammelt wurden, war ein Vergleich zwischen mehreren Projekten nicht moglich. Eine erste systematische Analyse des Aufwands und des Umfangs wurde fur die Studienprojekte der Abteilung Programmiersprachen durchgefuhrt [Sim05]. In einer Studienarbeit wurden umfangreich Metriken aus abgeschlossenen Studienprojekten A erhoben [Thu05]. Die Ergebnisse der Arbeit und die Erfahrungen mit der Metrikerhebung und -analyse werden in diesem Artikel vorgestellt. Die Ziele dieser Erhebung waren: Unterstutzung der Kostenschatzung. Die Aufgabenstellung wird von den Betreuern und Kunden auf die Rahmenbedingungen des Studienprojekts zugeschnitten, der Umfang der Anforderungen wird aber im Vorprojekt und wahrend der Spezifikation endgultig geklart. Fur das Angebot im Vorprojekt werden die Teilnehmer mit den Schwierigkeiten der Kostenschatzung konfrontiert, weil sie alle Anforderungen des Kunden realisieren sollen, der mogliche Aufwand aber begrenzt ist. Fur die Planung mussen einzelne Phasen und Arbeitspakete definiert und mit Aufwand und Dauer geplant werden. Wahrend in der Praxis uberwiegend Expertenschatzungen durchgefuhrt werden [Jor04], konnen die Studienprojektteilnehmer nicht auf eigene Erfahrungen mit Projekten dieser Grose zuruckgreifen. Darum sollen die Teilnehmer durch Daten aus abgeschlossenen Studienprojekten unterstutzt werden.

Mit dem SESAM-Projekt (Software Engineering Simulation by Animated Models) der Abteilung Software Engineering an der Universitat Stuttgart wird die Ausbildung von Projektleitern um eine Simulationskomponente erweitert. Der Simulator fuhrt dazu Modelle von Software-Projekten aus. Die Modelle enthalten alle fur die Ausbildung relevanten Aspekte eines Projekts. Ausnahme ist der Projektleiter, der das simulierte Projekt durchfuhrt. In der Ausbildung wird das QS-Modell (Qualitatssicherungs-Modell) bereits eingesetzt. Der Schwerpunkt des Modells liegt auf Masnahmen zur Qualitatssicherung, das Projekt wird von der Analyse bis zur Ubergabe an den Kunden nachgebildet. Die Simulation des Modells erfolgt auf Tagesbasis. Diese Zeitgranularitat schrankt die simulierten Effekte ein, da sich Vorgange innerhalb eines Tages nicht beobachten lassen und der Projektleiter nur tageweise eingreifen kann. Ziel dieser Diplomarbeit ist, die Moglichkeiten, aber auch Probleme einer feineren Zeitgranularitat zu untersuchen. Die vermuteten Moglichkeiten und Probleme werden zuerst als Hypothesen formuliert. Um die Hypothesen zu untersuchen, werden einzelne Phasen des QS-Modells auf eine feinere Zeitgranularitat von zwei Stunden umgestellt. Diese Variante des QS-Modells wird um feingranulare Effekte erweitert. Der Schwerpunkt liegt dabei auf dem Reviewprozess, der feingranular modelliert wird. Anhand dieser feingranularen Variante werden die aufgestellten Hypothesen uberpruft.