Projekte sicher ins Ziel navigieren

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:

• Anforderungen
• Design
• Coding
• Dokumentation
• Einbauen von Fehlern bei der Beseitigung anderer Fehler

Der Schweregrad („Severity“) kennt 4 Stufen:

• 1 – Das System oder Programm funktioniert nicht
• 2 – Wichtige („major“) Funktionen funktionieren nicht oder fehlen
• 3 – Weniger wichtige („minor“) Funktionen funktionieren nicht oder fehlen
• 4 – Vernachlässigbarer („superficial“) Fehler

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, 3^rd 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, 3^rd edition, McGraw Hill 2008
[2] Capers Jones, Applied Software Measurement – Global Analysis of Productivity and Quality, 3^rd edition, McGraw Hill 2008
[3] Capers Jones, Applied Software Measurement – Global Analysis of Productivity and Quality, 3^rd edition, McGraw Hill 2008
[4] Six Sigma, Fehlerkosten 10er Regel

Gründe für die rasant steigenden Kosten sind unter anderem:

• Zu Beginn eines Projektes werden oft fundamentale Entscheidungen getroffen, z. B. bezüglich Architektur oder zentrale Schnittstellen, auf denen viele nachfolgende Artefakte und Entscheidungen aufbauen. Wenn sich in dieser frühen Phase Fehler einschleichen, ist schlimmstenfalls das ganze System betroffen. Je weiter das Projekt fortgeschritten ist, wenn solche Fehler entdeckt werden, um so größer sind die erforderlichen Eingriffe, um diese Fehler zu korrigieren.
• Bei Massenprodukten wie Kraftfahrzeugen, die mit einem Fehler ausgeliefert wurden und vielleicht sogar schon seit Jahren beim Kunden in Betrieb sind, können die Kosten für Rückrufaktionen schnell die Größenordnung von Millionen erreichen.
• Für den Entwickler wird die Einarbeitung in ein fehlerhaftes Artefakt umso schwieriger, je länger die Arbeit daran zurückliegt, und damit erhöht sich auch der Aufwand für die Fehlerbehebung.

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:

• Sind die Anforderungen entsprechend den Erwartungen der Stakeholder umgesetzt worden?
• Sind Änderungen an Anforderungen erforderlich? In diesem Fall muss es einen definierten Prozess für die Formulierung, Freigabe und Verwaltung der Änderungen geben („Requirements Change Management“)
• Ist der Zeitpunkt für Verfeinerungen an Anforderungen gekommen? Auch dafür muss es einen Prozess geben, der alle Stakeholder einbezieht und zu abgestimmten und akzeptierten Detail-Anforderungen führt.
• Können alle entstandenen Artefakte den Anforderungen zugeordnet werden? Die durchgängige Verfolgbarkeit („Traceability“) ermöglicht den Nachweis, dass alle Anforderungen erfüllt wurden und erlaubt die Lokalisierung von Artefakten, die nicht gefordert wurden.

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:

• Einbeziehen aller Stakeholder, einschließlich Kunden (externe und/oder interne) und Anwendern, Management (legt den Kostenrahmen oder KPIs für das Projekt fest), Spezialisten für die einzubauenden Module, Einkauf und Fertigungsexperten (bei Entwicklung von Produkten, die neben Software auch Hardware, Mechanik oder andere Komponenten beinhalten), etc.. Letztendlich muss jede Art oder Kategorie von Anforderungen, die für Ihr Projekt relevant ist, bei der Erhebung, Gewichtung und Verfeinerung der Anforderungen durch entsprechende Experten für diesen Bereich repräsentiert werden.
• Festlegen von Qualitätsstandards für Anforderungen und sicherstellen, dass die Anforderungen entsprechend diesen Qualitätsstandards beschrieben werden.
• Kontinuierliches, regelmäßiges Monitoring der Realisierung der Anforderungen. Auch dabei ist die Einbeziehung aller Stakeholder unabdingbar, die für den zu betrachtenden Projektstatus relevant sind.
• Kontinuierliche Verifikation und Validierung, einschließlich frühzeitiger Tests und Simulationen.
• Kontinuierliche Anpassung und Verfeinerung der Anforderungen falls erforderlich
• Kurze Review-Zyklen, agile und schnelle Reaktion auf Fehler, um die Kosten für Fehlerbehebung zu kontrollieren.

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, 3^rd edition, McGraw Hill 2008
[1] The Shift-Left Approach to Software Testing