Kostensteigerung durch verspätetes Erkennen und Beheben von Mängeln aus Anforderungen

Artikel von Mahwish Khan und Rabia Akhtar

Der Schwerpunkt dieses Artikels ist es, die Sicht auf das Softwareprozessmanagement, auf Metriken und auf dynamische Prozessmodellierung zu fokussieren und sie zu verbessern. Unsere Analyse wird hauptsächlich die Auswirkungen der Identifizierung von Anforderungsmängeln in der Testphase in Bezug auf Kosten untersuchen. Es können Mängel in jeder Phase der Softwareentwicklung auftreten aber in der Phase, in der die Anforderungen definiert werden, ist das Auffinden von Fehlern enorm wichtig. Anforderungsmängel, die erst in der Testphase identifiziert werden, sind am teuersten zu korrigieren, weil sie sich global im Entwicklungsprozess auswirken können. Zwischen 40 und 60 Prozent aller Mängel in Softwareprojekten basieren auf schlecht formulierten Anforderungen [6].

Boehm zufolge können erst spät im Entwicklungsprozess gefundene Fehler bis zu 100-mal mehr Kosten verursachen, als wenn diese bereits während der Phase der Anforderungsanalyse nachgewiesen und beseitigt werden [5]. Anforderungsmängel resultieren aus fehlerhaften und falsch verstandenen Anforderungen oder impliziten Anforderungen, die ein Nachbessern bedeuten. Die Kosten der Nachbesserung machen zwischen 70 und 80 Prozent der Entwicklungskosten aus [2]. Wir beweisen, dass das Erkennen und Beheben von Mängeln, die bereits während der Definition der Anforderungen entstanden sind, aber erst in der Testphase entdeckt werden, die Kosten erhöht.

1. Hintergrund

Es gibt einen großen Unterschied zwischen Mängeln in den Anforderungen und anderen Mängeln, die wir hier diskutieren. Mängel in
Softwareprodukten lassen sich in zwei Hauptkategorien unterteilen:

  • Mängel in den Anforderungen
  • Mängel in der Umsetzung

Unsere Absicht ist es, sich mit den Anforderungsmängeln, den Konsequenzen und ihren Auswirkungen auf die Kosten der Behebung in einer späteren Phase (wie Design, Code oder Testen) zu befassen. Soren Lausen et al. führte eine Fallstudie durch und sammelte ca. 200 Berichte für dieses Projekt. Von diesen wurden 107 Berichte ausführlich analysiert und dabei wurde Folgendes festgestellt [2]:

  • 65 Berichte betrafen implizierte Anforderungen (Anforderungen, die nicht niedergeschrieben wurden).
  • 20 Berichte betrafen Anforderungen, die falsch waren, missverstanden oder vergessen wurden.
  • 20 Berichte betrafen externe Softwarepakete, hier gab es Missverständnisse darüber, wie diese umgesetzt werden sollten. Dies waren die Fehler, die am teuersten in der Behebung waren.

Mängel beider Arten können in verschiedenen Stadien der Entwicklung nachgewiesen werden. Je früher sie erkannt werden, desto leichter sind sie zu beheben. Idealerweise sollte verhindert werden, dass sie sich einschleichen [3].

Folgend diskutieren wir nur Mängel in den Anforderungen, da deren Beseitigung teurer ist als die Behebung von Mängeln in der Implementierung. Aufgrund ihrer Natur müssen wir andere Techniken verwenden, um sie vor der Umsetzung zu erkennen und zu verhindern. Programmierer können Umsetzungsmängel durch Testen oder durch gegenseitige Inspektion der eigenen Programme finden, aber selten finden sie Anforderungsmängel auf diese Weise.

In Abbildung 2 ist zu erkennen, dass das späte Erkennen von Mängeln zur Nachbesserung führt und dieses direkt die Kosten erhöht. Die Abbildung wurde aus dem Buch „Software Engineering Economics“ von Boehm und Barry und dem IEEE-Paper „Software Management“ von Boehm und Basili entnommen.

2. Soll-­Zustand

Wenn die Entwicklung im Softwarelebenszyklus (SDLC) voranschreitet, sollte sich im Idealfall die Anzahl festgestellter Mängel verringern. Tabelle 1 stellt die idealen Kosten aus Erkennung und Behebung von Mängeln in Beziehung zu den SDLC-Phasen dar. Boehm zufolge erhöhen sich die Kosten exponentiell, wenn wir einen Mangel erst in späteren Phasen identifizieren.

3. Ist­-Zustand

In der Softwareindustrie gibt es sehr wenige Fälle, in denen Praktiken im ursprünglichen Sinne angewendet werden, insbesondere das Requirements Engineering wird nicht so ausgeführt, wie es getan werden sollte. Das ist der Grund warum Mängel phasenübergreifend übersehen werden. Die unerkannten Mängel aus der Designphase führen zu anschließenden Entwicklungsmängeln. Alle Mängel bleiben dann bis zur Erkennung in der Testphase vorhanden, aber das ist sehr teuer. Wenn Mängel erst am Ende der Testphase erkannt werden, ist es notwendig, einzelne Phasen wiederholt zu durchlaufen um diese Mängel auszuräumen.

4. Modellübersicht

Das Modell umfasst die Tätigkeiten von Design bis zum Testing, inklusive der Inspektion von Design und Entwicklungscode und ist in Abbildung 5 dargestellt. Das ITHINK-Modellierungspaket wird zur Implementierung der System-Dynamics-Methode [7] genutzt. In der Industrie sind Systemtests und Inspektionen häufig die einzigen Techniken zum Auffinden von Mängeln.

5. Modellbeschreibung

Mängel werden durch einen Co-Flow von Design- und Entwicklungsaktivitäten erzeugt, und schließlich durch Inspektionen erkannt oder an die nächste Phase übergeben. Die Erkennung von Mängeln ist eine Funktion von Inspektionspraktiken. Alle Mängel, die bei Inspektionen erkannt werden, können dann überarbeitet werden. Es sollte beachtet werden, dass nicht erkannte Anforderungsmängel in Designmängel verstärkt werden, welche wiederum in Entwicklungsmängel resultieren.

Wir betrachten auch den Aufwand für Inspektionen von der Anforderung bis zum Testing und die Auswirkungen auf die Anzahl der festgestellten Mängel. Dann betrachten wir die Kosten für die Nachbesserung eines jeden Mangels, multiplizieren es mit der Anzahl der Mängel, die in jeder Inspektionsphase gefunden wurden, und kombinieren die Aufwände für Nachbesserungen über alle Phasen, um die Gesamtkosten zu ermitteln.

6. Vergleichsanalyse

In unserem Modell haben wir Inspektionen nach jeder Phase eingebaut, um Mängel zu erkennen. Wir haben das Modell in drei unterschiedlichen Fällen eingesetzt. Diese sind:

  • Alle Mängel werden in der Anforderungsphase identifiziert (Idealfall).
  • Alle Mängel werden in der Testphase identifiziert (ungünstigster Fall).
  • Unterschiedliche Prozentsätze von Mängeln werden in den Inspektionen der verschiedenen Phasen identifiziert, zum Beispiel 40 % der Mängel in der Anforderungsphase, 30 % in der Designinspektion, 20 % in der Entwicklungsinspektion und die restlichen 10 % beim Testen (nomineller Fall).

Wir haben die Kosten der Nachbesserung für verschiedene Fälle analysiert und untersucht, wie sich der Anteil der Kosten erhöht, wenn alle Mängel in der Testphase identifiziert werden. Dann haben wir eine vergleichende Analyse der Nachbesserungskosten in den drei oben genannten Fällen durchgeführt.

In der Abbildung 4 ist der erste Fall durch „Rework Cost 2“ (Nachbesserungskosten 2) dargestellt, der zweite durch „Rework Cost 3“ und der dritte durch „Rework Cost 1“. Wie unsere Analyse zeigt, belaufen sich die Kosten auf $150, wenn alle Mängel in der Anforderungsphase identifiziert werden, für „Rework Cost 3“ auf $6000 und für „Rework Cost 1“ auf fast $400. Wenn wir dies genauer analysieren, können wir sagen, dass sich die Nachbesserungskosten im „ungünstigsten Fall“ verglichen mit dem „Idealfall“ um 4000 Prozent erhöhen, sowie um 1500 Prozent im Vergleich zwischen dem „ungünstigsten“ zum „nominellen Fall“.

7. Software Dynamic Model

Siehe Abbildung 5, „Software Dynamic Model“.

8. Fazit

Das dynamische Modell demonstriert erfolgreich mehrere Phänomene von Softwareprojekten, einschließlich der Auswirkungen von Inspektionen. Es hat sich auch gezeigt, dass es sich an die gegebenen Projektgrößen anpassen lässt.

Das Modell zeigt, dass Kosten unter idealen Bedingungen im Entwicklungszyklus gesenkt werden können, denn es müssen weniger Zyklen oder Phasen wiederholt werden. Allerdings hängt die Wirtschaftlichkeit von Inspektionen auch von anderen Faktoren ab, zum Beispiel davon, wie viele Mängel in den einzelnen Phasen entdeckt werden und wie diese in Bezug auf den Aufwand zur Behebung beseitigt werden können.

Quellenangaben

[1] Boehm, B., 1987. Industrial software metrics top-10 list. IEEE Software, 3, 9, 84–85.
[2] Lauesen, S. und Vinter, O., 2000. Preventing Requirement Defects. Proceedings of the Sixth International Workshop on Requirements, Stockholm, REFSQ’2000
[3] Lauesen, S. und Vinter, O., 2001. Preventing Requirement Defects: An Experiment in Process Improvement. Requirements Engineering Journal 6, 37-50. Springer Verlag.
[4] Jones und Capers, 2007. Estimating Software Costs. McGraw Hill, New York.
[5] Boehm, B., 1981. Software Engineering Economics. Prentice Hall, Englewood Cliffs, NJ.
[6] Davis, A. M., 1993. Software Requirements: Objects, Functions, and States. PTR Prentice Hall, Englewood Cliffs, NJ.
[7] Richmond B. et al., 1990. ITHINK User’s Guide and Technical Documentation. High Performance

Der Artikel wurde aus dem Englischen übersetzt und ist erstmals in Testing Experience Nr. 20, „Testing in the Cloud“ (Dezember 2012) erschienen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Kategorien

Recent Posts