Das chronische Problem der Anforderungsanalyse und die Frage: Fehler vermeiden oder früh entdecken?

Das chronische Problem der Anforderungsanalyse und die Frage: Fehler vermeiden oder früh entdecken ?

Oral Avcı, Holger Wagner

Lehrstuhl für Wirtschaftsinformatik, Systementwicklung Universität zu Köln

Albertus-Magnus-Platz, 50923 Köln

oral.avci@uni-koeln.de, holger.wagner@uni-koeln.de

Abstract: In Softwareentwicklungsprojekten werden durch Mängel im Prozess der Anforderungsanalyse viele Anforderungsfehler verursacht. Diese werden häufig erst entdeckt, nachdem zahlreiche Folgefehler im Entwurf und der Implementie- rung aufgetreten sind. Um die hohe Zahl der Anforderungsfehler und ihrer Folge- fehler zu senken, kann versucht werden, Fehler zu vermeiden oder sie früh zu ent- decken. Der vorliegende Beitrag arbeitet die besonderen Merkmale dieser Ansätze heraus und erklärt, warum sequenzielle Vorgehensmodelle sich auf die Fehlerver- meidung und agile auf die frühe Fehlerentdeckung beschränken.

1 Das chronische Problem: Anforderungsfehler und ihre Folgefehler

Die Anforderungsanalyse ist eine Teilaufgabe der Softwareentwicklung mit dem Ziel aus Kundenbedürfnissen Softwareanforderungen abzuleiten. Eine Softwareanforderung be- schreibt dabei ein gewünschtes funktions- oder qualitätsbezogenes Merkmal einer Soft- ware aus Sicht der Kunden, wobei diese Beschreibung unabhängig von dem Entwurf und der Implementierung dieses Merkmals ist. Seit drei Jahrzehnten wird die Anforderungs- analyse als eine eigenständige Teilaufgabe der Softwareentwicklung wahrgenommen.

Trotz zahlreicher Fortschritte weist die Praxis der Anforderungsanalyse ein chronisches Problem auf. Mängel im Prozess der Anforderungsanalyse verursachen viele Anforde- rungsfehler. Diese werden meist erst entdeckt, nachdem zahlreiche Folgefehler im Ent- wurf und der Implementierung aufgetreten sind. Der relative Anteil der Anforderungs- fehler und ihrer Folgefehler an der Gesamtfehlerzahl in Projekten ist deshalb hoch. In mehreren Studien bilden sie die am häufigsten genannte Fehlerkategorie und können bis zu 50% aller Fehler ausmachen [BP84], [LV01].

Um dieses chronische Problem zu lösen, können intuitiv zwei Ansätze unterschieden werden: Fehlervermeidung und frühe Fehlerentdeckung. Was zeichnet diese Ansätze je- weils aus? Wie werden diese Ansätze in sequenziellen und agilen Vorgehensmodellen berücksichtigt? Der vorliegende Beitrag beantwortet diese Fragen und ermöglicht damit, Gestaltungsempfehlungen in Vorgehensmodellen besser zu verstehen und sie bei Bedarf anpassen zu können. Hierzu werden zunächst verschiedene Arten von Fehlern abge- grenzt. Darauf aufbauend werden die Merkmale der Ansätze der Fehlervermeidung und der frühen Fehlerentdeckung dargestellt. Wie diese Ansätze in Vorgehensmodellen be-

rücksichtigt werden, wird anhand von Thesen zu Fehlern erörtert.

2 Zwei Lösungsansätze für das chronische Problem

Eine Softwareanforderung kann als eine Entscheidung in der Anforderungsanalyse auf- gefasst werden. Als solche ist sie die Grundlage für eine oder mehrere Entscheidungen im Entwurf. Eine Entwurfsentscheidung schafft wiederum die Voraussetzung für eine oder mehrere Entscheidungen in der Implementierung. Folglich kann die Softwareent- wicklung als eine Vielzahl von Entscheidungsketten verstanden werden, mit abhängigen Entscheidungen aus der Anforderungsanalyse, dem Entwurf und der Implementierung.

Dies gilt unabhängig davon, wie die Anforderungsanalyse, der Entwurf und die Imple- mentierung als Teilaufgaben zeitlich relativ zueinander ablaufen.

In Anlehnung an [Ie90] und [Ch96] können die Begriffe Irrtum (engl. error), Fehler (engl. fault) und Fehlverhalten (engl. failure) unterschieden werden. Ein Projektmitarbei- ter kann sich irren, während er ein Arbeitsergebnis erstellt, d. h. Softwareanforderungen erarbeitet, Entwurfsentscheidungen trifft oder die Software implementiert. SeinIrrtum kann dazu führen, dass das bearbeitete Ergebnis mit einem oder mehreren Fehlern behaf- tet ist. EinFehler ist ein unzureichendes Merkmal oder ein erwartetes, jedoch fehlendes Merkmal eines Arbeitsergebnisses der Softwareentwicklung, sofern es eine Änderung in diesem Ergebnis notwendig macht. Es können Anforderungs-, Entwurfs- und Implemen- tierungsfehler voneinander abgegrenzt werden, je nachdem, ob Entscheidungen in der Anforderungsanalyse, dem Entwurf oder der Implementierung betrachtet werden. Auf- grund des Zusammenhangs zwischen einzelnen Entscheidungen der Teilaufgaben kann sich ein Anforderungsfehler als Entwurfs- und Implementierungsfehler fortsetzen. Diese besonderen Entwurfs- und Implementierungsfehler sind alsoFolgefehler. Einoriginärer Fehler liegt dagegen vor, wenn er infolge eines Irrtums neu eingeführt wird und damit unabhängig von einem anderen Fehler ist. Immer wenn ein Projektmitarbeiter einemIrr- tum unterliegt, finden originäre Fehler Eingang in ein Ergebnis. Eine Software kann ein Fehlverhalten offenbaren, wenn sie einen Implementierungsfehler enthält und ausgeführt wird (siehe Abbildung 1).

Abbildung 1: Entstehung von Fehlern und ihre Auswirkungen

Aufgrund der aufgezeigten Zusammenhänge wird deutlich, warum Anforderungsfehler zahlreiche Folgefehler im Entwurf und der Implementierung verursachen, wenn sie spät entdeckt werden. Die vielen Anforderungsfehler und ihre Folgefehler verursachen einen hohen Überarbeitungsaufwand. Um dieses chronische Problem der Anforderungsanalyse zu lösen, kann man versuchen, Fehler zu vermeiden oder früh zu entdecken. Anforde- rungsfehler als originäre Fehler können niemals ganz ausgeschlossen werden, da der Irr- tum in der Natur des Menschen liegt. Allenfalls kann die Wahrscheinlichkeit reduziert werden, dass sie auftreten. Sowohl der Ansatz der Fehlervermeidung als auch der der frühen Fehlerentdeckung weisen dieses Ziel als Gemeinsamkeit auf. Sie unterscheiden sich nur hinsichtlich ihrer Haltung zu Folgefehlern. Das Ziel des Ansatzes der Fehlerver- meidung ist es, Folgefehler zu vermeiden. Fließen originäre Fehler in ein Arbeitsergeb- nis ein, sind sie so früh zu finden, dass keine Folgefehler entstehen. Der Ansatz der frühen Fehlerentdeckung hingegen verzichtet explizit auf die Forderung, Folgefehler ganz zu vermeiden. Folgefehler werden sogar bewusst provoziert und in Kauf genom- men, um auf diese Weise zügiger die originären Fehler aufzudecken. Dabei wird jedoch angestrebt, die Anzahl der Folgefehler gering zu halten.

3 Thesen zu Fehlern: Korrekturaufwand und Folgefehler

Inwiefern sind die Ansätze der Fehlervermeidung und der frühen Fehlerentdeckung ge- eignet das Problem der Anforderungsfehler zu lösen? Diese Frage wird kontrovers dis- kutiert. Dabei kann die Argumentation der verschiedenen Lager insbesondere auf unter- schiedliche Thesen zu zwei Zusammenhängen zurückgeführt werden: zur Entwicklung des Korrekturaufwandes eines Fehlers und zur Vermeidbarkeit von Folgefehlern.

Korrigiert man einen originären Fehler, muss auch der Aufwand für die Korrektur der entstandenen Folgefehler dem Korrekturaufwand des originären Fehlers zugerechnet werden, da sie durch ihn verursacht wurden. Der Korrekturaufwand eines Fehlers wird somit durch zwei Faktoren maßgeblich beeinflusst. Zum einen durch die Anzahl der durchzuführenden Änderungen, um den originären Fehler und alle Folgefehler zu behe- ben. Zum anderen dadurch, wie leicht bzw. schwierig die erforderlichen Änderungen an den jeweiligen Arbeitsergebnissen durchgeführt werden können. Da die Korrektur eines Fehlers umso aufwändiger wird, je mehr Folgefehler entstehen, ist es nahe liegend, dass insbesondere die Korrektur eines Anforderungsfehlers tendenziell aufwändiger wird, je später er entdeckt und korrigiert wird. Bzgl. dieser These liegt ein Konsens vor. Jedoch existieren unterschiedliche Ansichten darüber, in welchem Maße der Aufwand für die Korrektur eines Fehlers im Verlauf eines Softwareentwicklungsprojekts zunimmt.

Nach Boehm steigt der Aufwand für die Korrektur eines Fehlers mit jeder Entwicklungs- phase exponentiell an (These 1a) [Bo76]. Eine Studie aus dem Jahr 2002 stützt empirisch diese These [We02]. Mehrere Experten (einschließlich Boehm) bekräftigen die These in aktuellen Beiträgen, schränken jedoch ihre Gültigkeit auf schwerwiegende Fehler in gro- ßen Softwareprojekten ein [Sh02], [BB01]. Leider wird dabei nicht konkretisiert, was schwerwiegende Fehler und große Softwareprojekte sind.

Einige Autoren kritisieren die These des exponentiellen Anstiegs des Korrekturaufwands

jedoch generell [Co02], [Be99]. Sie stützen ihre Kritik auf Ausführungen zu den beiden oben vorgestellten Aufwandsfaktoren bei einer Fehlerkorrektur. Nach ihrer Ansicht ist ein Verlauf mit geringerem Wachstum möglich, wenn durch geeignete Maßnahmen die Wirkung der Aufwandsfaktoren geschwächt wird. Die Anzahl der Folgefehler und der Umfang der erforderlichen Änderungen könne verringert werden, wenn die Anzahl der zu erstellenden Arbeitsergebnisse auf ein Minimum reduziert und stattdessen der Schwerpunkt auf den eigentlichen Softwarecode gelegt wird. Durch eine flexible Archi- tektur und verbesserten Programmierpraktiken sollen zudem Änderungen am Code stark vereinfacht werden. Die Kritiker entwerfen somit folgende Gegenthese: der Aufwand für die Korrektur eines Fehlers steigt zwar über die Zeit an, jedoch mit einem geringeren Wachstum als einem exponentiellen (These 1b). Es liegen allerdings keine empirischen Ergebnisse vor, die diese These stützen könnten.

Neben diesen alternativen Thesen zum Wachstum des Korrekturaufwandes eines Fehlers existieren insbesondere zwei unterschiedliche Thesen zur Vermeidbarkeit von Folge- fehler.These 2a geht davon aus, dass Folgefehler vermeidbar sind, während These 2b genau das Gegenteil beinhaltet, dass sie nämlich nicht vermeidbar sind.

4 Umsetzung der Lösungsansätze in Vorgehensmodellen

Vorgehensmodelle geben Empfehlungen, wie der zeitliche Ablauf der Softwareentwick- lung zu gestalten ist. Zusätzlich enthalten sie meist Empfehlungen und stillschweigende Annahmen zur Gestaltung anderer organisatorischer sowie fachlich-technischer Bereiche [Me04]. Welchen Ansatz verfolgen nun Vorgehensmodelle? Fehlervermeidung oder frü- he Fehlerentdeckung? Betrachtet man Vorgehensmodelle unter diesem Gesichtspunkt, sind zwei Punkte festzustellen: erstens beschränken sich Vorgehensmodelle auf einen der Ansätze, zweitens basiert die Wahl des Ansatzes implizit oder explizit auf den zuvor aufgezeigten Thesen.

Sequenzielle Vorgehensmodelle wie das V-Modell gehen von den Thesen 1a und 2a aus, also einem exponentiellen Wachstum des Aufwands und der Vermeidbarkeit von Folge- fehlern. Hieraus wird die Notwendigkeit einer strikten Fehlervermeidung abgeleitet, was sich in den Empfehlungen sequenzieller Vorgehensmodelle widerspiegelt. Um die Wahr- scheinlichkeit originärer Anforderungsfehler gering zu halten, sollen mehrere Modelle der zu entwickelnden Software erstellt werden, die unterschiedliche Sichten auf die Soft- ware ermöglichen und auf diese Weise Softwareanforderungen präzise dokumentieren.

Folgefehler sollen dadurch unterbunden werden, dass die Teilaufgaben der Anforde- rungsanalyse, des Entwurfs und der Implementierung ohne zeitliche Überlappungen hin- tereinander ausgeführt und die jeweiligen Entscheidungen intensiv geprüft werden. So- fern dennoch ein unentdeckter Anforderungsfehler Folgefehler verursacht, wird eine um- fassende Überarbeitung und Qualitätssicherung der betroffenen Ergebnisse erforderlich.

In Abgrenzung zu den sequenziellen Vorgehensmodellen liegt agilen Vorgehensmodel- len wie Extreme Programming die These 1b eines nicht-exponentiellen Wachstums des Aufwands zugrunde. Des Weiteren wird die Annahme vertreten, dass sich bestimmte Anforderungen erst in der Auseinandersetzung mit einer lauffähigen Version der Soft-

ware konkretisieren oder ergeben. Demnach sind also Folgefehler nicht vermeidbar (These 2b). Aus den beiden Thesen wird deshalb gefolgert, eine frühe Fehlerentdeckung anzustreben. Um die Wahrscheinlichkeit originärer Anforderungsfehler gering zu halten, werden andere Instrumente vorgeschlagen als bei sequenziellen Vorgehensmodellen.

Hierzu zählt z. B. eine umfassende Beteiligung von Benutzern an der Softwareent- wicklung, die nicht nur Informationen liefern oder Arbeitsergebnisse abnehmen, sondern die Arbeitsergebnisse mit erstellen. Um die Anzahl möglicher Folgefehler gering zu hal- ten, können bei agilen Vorgehensweisen Entwurfs- und Implementierungsentscheidun- gen können bereits auf der Basis einer kleinen Menge von Softwareanforderungen ge- troffen werden, obwohl noch nicht alle Softwareanforderungen vorliegen. So kann früh eine lauffähige Version der Software angestrebt werden, welche schrittweise weiterent- wickelt wird. Eine regelmäßige Überprüfung der lauffähigen Version soll eine schnelle Entdeckung von Folgefehlern ermöglichen, um so originäre Anforderungsfehler erken- nen und weitere Folgefehler vermeiden zu können.

Die Gestaltungsempfehlungen, die in den sequenziellen und agilen Vorgehensmodellen jeweils aus dem Ansatz der Fehlervermeidung oder der frühen Fehlerentdeckung abge- leitet werden, schließen sich z. T. aus. Dies bedeutet jedoch nicht zwangsläufig, dass sich auch die Ansätze selber ausschließen müssen. Vielmehr sollte ein dritter Weg offen gehalten werden: Fehlervermeidung und frühe Fehlerentdeckung als komplementäre Strategien. Beide Ansätze gleichzeitig einzusetzen bedeutet, Folgefehler möglichst zu vermeiden und in den Fällen, in denen dies nicht möglich, mit wenigen Folgefehlern ent- standene originäre Fehler früh zu entdecken. Dies muss durch Gestaltungsmaßnahmen umgesetzt werden, die miteinander vereinbar sind.

Literaturverzeichnis

[BB01] B. Boehm, V. Basili: Software defect reduction top 10 list. In: Computer. Nr. 1, 2001, S.

135-137.

[Be99] K. Beck: Extreme Programming Explained: Embrace Change. Reading 1999.

[Bo76] B. Boehm: Software Engineering. In: IEEE Trans. on Comp. Nr. 12, 1976, S. 1226-1241.

[Bo81] B. Boehm: An experiment in small-scale application software engineering. In: IEEE Transactions on Software Engineering. Nr. 5, 1981, S. 482-493.

[BP84] V. Basili, B. T. Perricone: Software errors and complexity: an empirical investigation.

In: Communications of the ACM. Nr. 1, Jg. 27, 1984, S. 42-52.

[Ch96] Ram Chillarege: Orthogonal Defect Classification. In: Michael R. Lyu (Hrsg.): Hand- book of software reliability engineering. Los Alamitos, California u. a. 1996, S. 359-400.

[Co02] J. Coldewey: Agile Entwicklung Web-basierter Systeme: Einführung und Überblick. In:

Wirtschaftsinformatik. Nr. 3, Jg. 44, 2002, S. 237-248.

[Ie90] IEEE Standard Glossary of Software Engineering Terminology. New York 1990.

[LV01] S. Lauesen, O. Vinter: Preventing requirement defects: An experiment in process impro- vement. In: Requirements Engineering. Nr. 1, Jg. 6, 2001, S. 37-50.

[Me04] W. Mellis: Projektmanagement der SW-Entwicklung. Wiesbaden 2004.

[Sh02] Forrest Shull u. a.: What we have learned about fighting defects. In: IEEE (Hrsg.): Proc.

of the 8th IEEE Symposium on Software Metrics 2002. Los Alamitos, 2002, S. 249-258.

[We02] J. C. Westland: The cost of errors in software development: evidence from industry. In:

Journal of Systems and Software. Nr. 1, Jg. 62, 2002, S. 1-9.