Teil 3: Der Einfluss von Requirements Engineering auf die Kosten der Fehlerbehebung
Im ersten Teil dieser Serie haben wir uns mit dem angestrebten Ergebnis eines Entwicklungsprojektes befasst. Auch wenn es zunächst paradox klingt, mit dem Ergebnis zu beginnen – aber ohne die Festlegung eines Projektzieles wird man im Verlauf des Projektes viele teure Umwege machen. Falls Sie es noch einmal nachlesen möchten, hier geht es zum ersten Teil.
Im zweiten Teil standen die Qualität und die Priorisierung der Anforderungen im Mittelpunkt, und wir haben verschiedene Kriterien betrachtet, wie Anforderungen bewertet und ausgewählt werden können (Link zum zweiten Teil der Serie).
Heute befassen wir uns mit dem Einfluss von Requirements Engineering auf die Kosten der Fehlerbehebung. Fehlendes oder unzureichendes Requirements Engineering kann großen Einfluss auf die Menge und die „Severity“ der induzierten Fehler sowie auf die Kosten für deren Beseitigung haben. Untersuchungen bei IBM [1] gliedern die Ursachen für Fehler in diese Kategorien:
Der Schweregrad („Severity“) kennt 4 Stufen:
Die Verteilung von Fehlerursachen und Schweregrad zeigt eine interessante Häufung (Abbildung 6). Dieser Analyse liegen Daten von mittleren bis großen Projekten zugrunde, mit mehr als 50.000 Codezeilen. Obwohl Anforderungsbedingte Fehler nur ca. 15% aller Fehler verursachen, sind diese für die Hälfte aller schweren Fehler verantwortlich. Die andere Hälfte der schweren Fehler hat ihre Ursachen im Design und im Coding.
[1] Nach Capers Jones, Applied Software Measurement – Global Analysis of Productivity and Quality, 3rd edition, McGraw Hill 2008
Aus der Behebung von Fehlern ergibt sich ein erheblicher und kaum planbarer Kostenanteil in Entwicklungsprojekten. Grundsätzlich gilt, je mehr Zeit zwischen Injektion eines Fehlers und dessen Entdeckung liegt, umso aufwendiger ist die Behebung. Übliche Schätzungen gehen aus von einer Vervielfachung für jede Phase des Projektes, die zwischen Injektion und Behebung liegt. Die Faktoren schwanken je nach Quelle zwischen zwei bis drei [1] und 10 („rule of ten“) [2]
Ein typischer Verlauf der Fehlerinjektion ist in Abbildung 7 dargestellt. Lt. Capers Jones werden 85% aller Fehler während der frühen Phasen eines Projektes gemacht. Gleichzeitig werden in diesen Phasen nur wenige Fehler gefunden. Die Kosten der Fehlerbehebung steigen steil an, je später ein Fehler entdeckt wird.
Abb. 7: Fehlerinjektion im Projektverlauf und Kosten der Fehlerbehebung [1]
[1] Capers Jones, Applied Software Measurement – Global Analysis of Productivity and Quality, 3rd edition, McGraw Hill 2008
[2] Capers Jones, Applied Software Measurement – Global Analysis of Productivity and Quality, 3rd edition, McGraw Hill 2008
[3] Capers Jones, Applied Software Measurement – Global Analysis of Productivity and Quality, 3rd edition, McGraw Hill 2008
[4] Six Sigma, Fehlerkosten 10er Regel
Gründe für die rasant steigenden Kosten sind unter anderem:
Ziel vieler Initiativen zur Reduktion der Kosten für Fehlerbeseitigung ist die Verschiebung der Fehlererkennung nach links („shift left“) [1]. Durch frühe Lokalisierung von Fehlern versucht man, die Zeit zwischen Fehlerinjektion und Fehlerbehebung zu verkürzen, um so die Kosten zu reduzieren. Abbildung 8 zeigt beispielhaft einen angestrebten Verlauf.
Es gibt mehrere Ansätze, diesen „Shift left“ zu erreichen, z. B. durch intensives frühes Testen. Konsequentes, durchgängiges Requirements Engineering ist ein weiteres Mittel, Fehler früher im Projektverlauf zu erkennen. Bei regelmäßigen Standortbestimmungen im Verlauf des Projektes prüfen die Stakeholder gemeinsam:
Solche regelmäßigen Reviews lassen sich für jeden Entwicklungsansatz einplanen. Bei agilen Projekten kann beispielsweise bei jedem Sprint eine solcher Review erfolgen, und die Anforderungen fließen sukzessive als Epics oder Stories in den nächsten Sprint und in die schrittweise Verfeinerung ein. Fehler durch falsch interpretierte oder implementierte Anforderungen findet man auf diese Weise relativ schnell und der Aufwand für die Behebung bleibt in vertretbarer Größenordnung.
Bei V-Modell-basierten Projekten sollten diese Reviews begleitend über alle Schritte auf der linken und rechten Seite des V-Modells in regelmäßigen kurzen Abständen durchgeführt werden. Abweichungen und Handlungsbedarf sind frühzeitig erkennbar, solange die Reaktion oder Fehlerbehebung noch mit sinnvollem Aufwand möglich ist. Gleiches gilt für hybride Prozesse, die agile Elemente kombinieren mit V-Modell Techniken.
Fazit
Abschließend lassen sich die zentralen Techniken für zielführendes und durchgängiges Requirements Engineering in Entwicklungsprojekten wie folgt zusammenfassen:
Dabei ist es unerheblich, welche Entwicklungsmethodik im Projekt angewendet wird. Die Vorteile des durchgängigen Requirements Engineering lassen sich sowohl in agilen als auch in traditionellen Projektszenarien erschließen.
[1] Capers Jones, Applied Software Measurement – Global Analysis of Productivity and Quality, 3rd edition, McGraw Hill 2008
[1] The Shift-Left Approach to Software Testing