Ergonomieorientierte Softwareentwicklung

Inhaltsverzeichnis

Abbildungsverzeichnis

Formelverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1 Einleitung
1.1 Problemstellung und Zielsetzung
1.2 Gang der Untersuchung

2 Softwareentwicklung und Softwareergonomie
2.1 Softwareentwicklung und Anwendungssystem-Lebenszyklus
2.2 Ergonomie und Softwareergonomie
2.3 Wirtschaftlichkeit und Risiko

3 Vorgehensmodelle in der Softwareentwicklung unter Betrachtung von Risikoreduktion und Wirtschaftlichkeit
3.1 Was sind Vorgehensmodelle?
3.2 Sequenzielle Vorgehensmodelle
3.2.1 Beschreibung
3.2.2 Risikoreduktion und Wirtschaftlichkeit
3.3 Iterative und inkrementelle Vorgehensmodelle
3.3.1 Beschreibung
3.3.2 Risikoreduktion und Wirtschaftlichkeit
3.4 Kategorisierung von Risiken und Kosten
3.4.1 Risiken
3.4.2 Kosten

4 Charakteristika und Methoden ergonomieorientierter Softwareentwicklung
4.1 Anforderungen, Normen und Richtlinien ergonomischer Software
4.1.1 Institutionen und ihre Normen, Richtlinien und Verordnungen
4.1.2 Das Konzept der Gebrauchstauglichkeit und relevante ISO Normen
4.1.3 DIN EN ISO 13407 – Norm für benutzerorientierte Entwicklungsprozesse
4.2 Methoden zur Erhöhung der Gebrauchstauglichkeit von Software
4.2.1 Auswahl geeigneter Methoden
4.2.2 Prototyping und Szenarien als Basismethoden
4.2.3 Usability Testing
4.2.4 Usability Inspection
4.2.5 Usability Inquiry
4.2.6 Einordnung der Methoden nach ihrem Verwendungszeitpunkt im Entwicklungsprozess

5 Die Integration der Softwareergonomie in den Entwicklungsprozess und deren wirtschaftliche Auswirkungen
5.1 Integration ergonomieorientierter Methoden in das Wasserfallmodell
5.1.1 Positionierung im und Auswirkungen auf den Entwicklungsprozess
5.1.2 Effekt auf die kategorisierten Risiken und Kosten im Stadium der Softwareentwicklung
5.1.3 Offene Fragen im Zusammenhang Risikoreduktion, Wirtschaftlichkeit und ergonomieorientierte Maßnahmen
5.2 Auswirkungen auf die Wirtschaftlichkeit im gesamten Anwendungssystem-Lebenszyklus
5.2.1 Kostenumfang eines Usability Engineering Programms
5.2.2 Entwicklung
5.2.3 Verkauf
5.2.4 Einführung
5.2.5 Betrieb
5.2.6 Wartung und Ablösung
5.2.7 Gegenüberstellung von Nutzen und Kosten

6 Zusammenfassung und Ausblick

Anhang

Literaturverzeichnis

Abbildungsverzeichnis

Abbildung 1: Anwendungssystem-Lebenszyklus

Abbildung 2: Das Verhältnis Mensch – Aufgabe - Computer

Abbildung 3: Wasserfallmodell

Abbildung 4: V-Modell

Abbildung 5: Entwicklung von Nutzerbedürfnissen bzw. Anforderungen im Zeitablauf

Abbildung 6: Iterative und inkrementelle Vorgehensweise

Abbildung 7: Das Spiralmodell

Abbildung 8: Frühe Softwarenutzung durch iterative oder inkrementelle Vorgehensmodelle

Abbildung 9: Risiko-Kategorien

Abbildung 10: Kosten-Kategorien

Abbildung 11: Gebrauchstauglichkeit und ihre Qualitätsfaktoren nach ISO 9241 Teil 11

Abbildung 12: ISO-Norm 9241 – softwareergonomische Teile

Abbildung 13: Zentrale Kapitel der ISO-Norm 13407

Abbildung 14: Prozess der benutzer-orientierten Gestaltung – ISO 13407

Abbildung 15: Entwerfen von Gestaltungslösungen, ISO 13407, Part 7, Gestaltungsaktivität Nr. 3

Abbildung 16: Support-Profil geeigneter Methoden (Kriterien)

Abbildung 17: Szenarien im Vergleich zu Prototypen

Abbildung 18: Kategorisierung von Prototypen nach Anwendungs- und Dialogfunktionalität

Abbildung 19: Einordnung geeigneter Methoden nach Kategorie und Verwendungszeitpunkt

Abbildung 20: Taxonomy of Usability Evaluation Methods

Abbildung 21: Wasserfallmodell mit Prototyping

Abbildung 22: Integration der ergonomieorientierten Methoden in ein angepasstes Wasserfallmodell

Abbildung 23: Zusammenhang zwischen Risiken und Kosten

Abbildung 24: Vergleich der Kosteneinsparungen nach 1. Jahr in Betrieb

Abbildung 25: Vergleich der Kosteneinsparungen nach 4. Jahr in Betrieb

Abbildung 26: Themen der Softwareergonomie

Abbildung 27: Das magische Dreieck des Projektmanagements

Abbildung 28: Modell zur Messung von Gebrauchstauglichkeit

Abbildung 29: Iteratives Vorgehensmodell mit Prototyping

Abbildung 30: Aufbau des Arbeitsschutzrechtes (beispielhafter Auszug)

Formelverzeichnis

Formel 1: Wirtschaftlichkeit I

Formel 2: Wirtschaftlichkeit II

Formel 3: Risk Reduction Leverage

Formel 4: Wirtschaftlichkeit III

Formel 5: Wirtschaftlichkeit IV

Tabellenverzeichnis

Tabelle 1: Usability Engineering Programm und exemplarische Kosten

Tabelle 2: Geldwert einer verkürzten Projektlaufzeit

Tabelle 3: Einsparungen durch weniger Änderungen in späten Phasen der Entwicklung

Tabelle 4: Umsatzsteigerung und resultierende Gewinnsteigerung

Tabelle 5: Kosteneinsparungen bei der Nutzer-Einführungsschulung (interne Entwicklung)

Tabelle 6: Kosteneinsparungen bei der Kunden-Einführungsschulung

Tabelle 7: Kosteneinsparungen durch Produktivitätszuwachs

Tabelle 8: Kosteneinsparungen durch eine verringerte Fehlerrate

Tabelle 9: Kosteneinsparungen durch reduzierte Arbeitnehmerfluktuation

Tabelle 10: Kosteneinsparungen durch reduzierten Selbstsupport

Tabelle 11: Kosteneinsparungen durch Reduktion telefonischen Supports

Tabelle 12: Kosteneinsparungen durch reduzierte Wartung (inhouse)

Tabelle 13: Kosteneinsparungen durch reduzierte Wartung (extern)

Tabelle 14: Gesamtnutzen verteilt über den Anwendungssystem-Lebenszyklus (Eigennutzung)

Tabelle 15: Net Present Value (Eigennutzung)

Tabelle 16: Gesamtnutzen verteilt über den Anwendungssystem-Lebenszyklus (Verkauf)

Tabelle 17: Net Present Value (Verkauf und Betreuung)

Tabelle 18: Begriffliche Inkonsistenzen im Zusammenhang Softwarelebenszyklus, Vorgehensmodell und Softwareentwicklung

Tabelle 19: Gegenseitige Sichten von Nutzer und Entwickler

Tabelle 20: Berechnung der Basisdaten und Stundensätze

Tabelle 21: Exemplarische Kosten der Anwendung ergonomieorientierter Methoden

Tabelle 22: Kostenkomponenten des Prototyping (exemplarisch)

Tabelle 23: Exemplarische Kosten von Interviews, Styleguides und Prototyping Tool

Tabelle 24: Die Beispielunternehmen mit den Basisfakten und Zahlen

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

1.1 Problemstellung und Zielsetzung

‚Das geht jetzt nicht mehr, wir haben eine neue Software!’, antwortet die Sachbearbeiterin eines amerikanischen Unternehmens frustriert auf die Anfrage eines Kunden. Auch ihr Kollege hat Probleme, sich an die neue Software zu gewöhnen und ist fluchend dazu übergegangen Teilarbeitsschritte wieder manuell durchzuführen...^[1] Dieses fiktive Unternehmen mag eines von jenen sein, die in der Summe jährlich ca. 275 Milliarden Dollar (USA-Markt) in die Softwareentwicklung investieren.^[2] Investitionen, um die Produktivität eines Unternehmens zu erhöhen, Investitionen die die Arbeit der Mitarbeiter vereinfachen und beschleunigen sollen, Investitionen die sich baldmöglichst rentieren sollen.

Betrachtet man obiges Beispiel wird deutlich, dass die Kosten einer Software nicht nur die Anschaffungskosten / Entwicklungskosten zuzüglich etwaiger Integrationskosten umfassen, sondern dass die Kosten der Softwarenutzung ebenso ein relevanter Faktor sind. Software, welche an den Benutzer angepasst ist und ihn in seinen Prozessen sowie seiner Arbeitsweise optimal unterstützt ist rar. Tatsächlich vergeuden Anwender 10% ihrer Arbeitszeit am Rechner damit, aufgetretene Probleme zu bewältigen^[3], so dass ‚nutzer un freundliche’ Anwendungssysteme den erhofften Produktivitätszuwachs erheblich mindern können. Aber damit nicht genug – auf Seiten des Softwareentwicklers ergibt sich ein Nachbesserungsaufwand, der beispielsweise um die stärkere Beachtung und das Verständnis von Nutzeranforderungen hätte gemindert oder gar verhindert werden können.^[4] Gemäß Studien liegen die Kosten für Wartung und Pflege von Programmen bei 50-80% des gesamten Programmieraufwands. Dies entspricht dem zwei- bis dreifachen der anfänglichen Entwicklungskosten.^[5]

Die Softwareergonomie als die „Anpassung von Software-Systemen an die Fähigkeiten des Menschen“^[6], welche durch den angelsächsischen Begriff Usability^[7] seit den 90er Jahren einen Schub erhalten hat^[8], stellt nun den Benutzer in den Vordergrund. Jedoch hat die Softwareergonomie noch nicht in dem Maße Einzug in die Softwareentwicklung erhalten, wie es wünschenswert und nötig wäre.^[9] So kritisierte auch Hasso Plattner kürzlich, dass Softwareanwendungen in der Vergangenheit noch zu sehr aus der Perspektive der Programmierer entwickelt wurden, und das heute die Sicht der Nutzer in den Vordergrund rücken müsse.^[10] Je stärker der Kundenkontakt bei Softwareentwicklungsprojekten ist, dies belegen Studien, umso wahrscheinlicher ist letztendlich der Erfolg.^[11] In engem Zusammenhang dazu steht die Erkenntnis, dass die meisten Schwierigkeiten in Softwaresystemen auf Anforderungsproblemen basieren^[12], welche wiederum oft auf eine Vernachlässigung des Kundenkontaktes und der Anforderungen der Nutzer zurückzuführen sind.

Im Rahmen dieser Arbeit soll daher auf konzeptioneller Ebene untersucht werden, ob die Integration der Softwareergonomie in den Softwareentwicklungsprozess zu einer erhöhten Wirtschaftlichkeit und Risikoreduktion im Anwendungssystem-Lebenszyklus führen kann. Von besonderem Interesse ist dabei die Frage, wie und welche Methoden sowie ergonomische Normen im Entwicklungsprozess berücksichtigt werden können, damit sich über den gesamten Lebenszyklus ein positives Kosten-Nutzen Verhältnis ergibt.

1.2 Gang der Untersuchung

Die Untersuchung beginnt im zweiten Kapitel mit einer definitorischen Darstellung der Hauptbegriffe dieser Arbeit und schafft damit ein Wissensfundament. Dazu wird der Leser zunächst in die Begriffe Softwareentwicklung sowie Anwendungssystem-Lebenszyklus eingeführt. Anschließend werden sowohl die Ergonomie als auch die Softwareergonomie erläutert und schließlich die Begriffe Wirtschaftlichkeit und Risiko definiert.

Das dritte Kapitel analysiert und kategorisiert Risiken und Kosten, die im Rahmen von Softwareentwicklungsprozessen auftreten. Um ein Verständnis über Softwareentwicklungsprozesse zu erhalten, beginnt das Kapitel mit einer Vorstellung verschiedener Vorgehensmodelle. Anhand dieser Vorgehensmodelle können die Kosten und Risiken anschaulich dargestellt und zusammenfassend kategorisiert werden. Eines der Vorgehensmodelle wird in angepasster Form in späteren Kapiteln wieder aufgegriffen.

Im vierten Kapitel werden die Charakteristika einer ergonomieorientierten Softwareentwicklung herausgearbeitet und verschiedene Methoden zur Realisierung dieser untersucht. Dazu müssen die existierenden softwareergonomischen Gesetze und Richtlinien betrachtet werden, um darauf aufbauend Methoden auszuwählen, die dem Prozess der Softwareentwicklung zu einem ergonomieorientierteren verhelfen können. Vorbereitend für das nächste Kapitel werden die identifizierten Methoden in einer Matrix aufgearbeitet, die den tendenziell bestmöglichen Anwendungszeitpunkt im Softwareentwicklungsprozess aufzeigt.

Das fünfte Kapitel führt die Erkenntnisse aus den Kapiteln 3 und 4 zusammen und zeichnet im ersten Teil (5.1) den Weg zur ergonomieorientierten Softwareentwicklung durch eine Integration der Methoden in ein dafür angepasstes Wasserfallmodell (Vorgehensmodell). Zu diesem Zwecke wird zunächst untersucht, welche Veränderungen an dem Wasserfallmodell vorgenommen werden müssen, damit die in Kapitel 4 identifizierten Methoden gewinnbringend integriert werden können. Daraufhin wird unter zur Hilfenahme der Matrix aus Kapitel 4 das angepasste Vorgehensmodell mit den Methoden angereichert. Dieses Modell bietet die Grundlage für eine qualitative Betrachtung der Effekte auf die bereits in Kapitel 3 ausgearbeiteten und kategorisierten Risiken und Kosten der Softwareentwicklung. Nachdem Aspekte der Wirtschaftlichkeit und das Risikoreduktionspotential des neuen ergonomieorientierten Prozesses qualitativ untersucht wurden, wird dieses Wissen in Kapitel 5.2 anhand von Zahlen quantifiziert und auf den gesamten Lebenszyklus von Anwendungssystemen bezogen. Dazu wird der Kostenumfang eines exemplarischen Usability Engineering Programms berechnet und den Nutzenzuwächsen bzw. Kosteneinsparungen in späteren Phasen des Anwendungssystem-Lebenszyklus gegenübergestellt.

Abschließend fasst das sechste Kapitel die wichtigsten Erkenntnisse und Schlussfolgerungen der vorangegangenen Untersuchung zusammen und gibt einen Ausblick auf mögliche zukünftige Entwicklungen und Forschungsschwerpunkte.

2 Softwareentwicklung und Softwareergonomie

2.1 Softwareentwicklung und Anwendungssystem-Lebenszyklus

Die Softwareentwicklung ist eine vergleichsweise junge Ingenieursdisziplin^[13], bei der es um die Herstellung von Softwaresystemen geht. Neben dem Begriff der Softwareentwicklung hat sich im deutschsprachigen Raum die Bezeichnung Software Technik, welche den Ingenieursaspekt betont^[14], als auch die in 1967 von einer NATO-Forschungsgruppe^[15] gebildete angelsächsische Variante Software Engineering^[16] verbreitet. Softwaresysteme bestehen aus einem oder mehreren Computerprogrammen zuzüglich System- und Benutzerdokumentation.^[17]

Grundsätzlich wird zwischen Anwendungssoftware und Systemsoftware unterschieden. Systemsoftware ist Software, die für das Zusammenspiel der Hardware-Komponenten eines Computersystems sorgt (z.B. Betriebssysteme wie DOS, Windows, UNIX etc.). Untersuchungsgegenstand dieser Arbeit ist jedoch die Entwicklung von Anwendungssoftware bzw. Anwendungssystemen. Anwendungssysteme bestehen aus Programmen, die bestimmte, meist betriebswirtschaftlich geprägte Aufgaben lösen, welche vom Unternehmen oder Nutzergruppen definiert wurden.^[18] Ein Unternehmen kann die Software grundsätzlich von der eigenen IT-Abteilung entwickeln lassen oder bei einem Softwareunternehmen erwerben. Um diese beiden Fälle in dieser Arbeit auseinander zu halten, wird bei Eigenentwicklung von einem Anwenderunternehmen (egal welche Branchenzugehörigkeit) gesprochen, im anderen Fall bleibt es bei der Bezeichnung Softwareunternehmen. Ein Softwareunternehmen entwickelt Software entweder für den allgemeinen Markt (z.B. Microsoft mit MSWord) oder im Rahmen eines Auftrags. Personen, die das fertig gestellte Anwendungssystem bei ihrer täglichen Arbeit verwenden, werden als Nutzer oder Benutzer bezeichnet.^[19] Sämtliche Personen, die mit der Konzeption und Entwicklung des Anwendungssystems befasst sind, z.B. Softwareentwickler (Programmierer, Designer), aber auch Projektleiter, Assistenten etc. werden unter der Bezeichnung Entwicklungsteam zusammengefasst.^[20] Ergonomie-Experten sind jene Personen, deren Hauptgebiet die ergonomische Analyse von Software und die Integration ergonomischer Aspekte in den Entwicklungsprozess ist. Sie werden entweder explizit erwähnt, oder im weiteren Diskussionsverlauf begrifflich in das ‚Entwicklungsteam’ mit integriert. Als Kunden werden die Firma oder Abteilung bezeichnet, die die Software in Auftrag gegeben hat. Handelt es sich um Produkte die von einem Softwareunternehmen auf dem allgemeinen Markt angeboten werden, spricht man auch von Endkunden. Bei einer Auftragsentwicklung haben Softwareunternehmen eine weitere bedeutende Kundengruppe im IT-Personal des Kunden. Die interne IT-Abteilung muss die Software in bestehende Systeme integrieren, installieren und warten, soweit dies nicht durch das Softwareunternehmen übernommen wird.^[21]

Der Prozess der Softwareentwicklung ist gemäß Dumke „[…] der gesamte Prozess der Aufgabenerstellung, Planung, Realisierung und Bewertung einer Software-/Hardware-Anwendung einschließlich der verwendeten Hilfsmittel und Methoden und dem erforderlichen Personal“^[22]. Durchgeführt wird dieser Prozess in Form von Projekten^[23], welche durch ein Softwareprojektmanagement geleitet werden. Das Softwareprojektmanagement ist dafür verantwortlich, dass die Softwareentwicklung innerhalb der gesetzten Zeit- und Budgetbeschränkungen bleibt und das auszuliefernde Produkt den Anforderungen des Kunden entspricht.^[24] Kritische Punkte bei der Softwareentwicklung und seinem Management liegen insbesondere in der Nichtgreifbarkeit von Ergebnissen und Zwischenergebnissen, der nicht standardisierten Beziehung zwischen der Art des Produktes und des Fertigungsprozesses^[25], und der meist nicht genauen Festlegbarkeit, Dynamik und Missverständlichkeit von Anforderungen und Wünschen des Kunden im Verlauf des Projekts^[26].

Als Anwendungssystem-Lebenszyklus (oder auch Softwarelebenszyklus bzw. engl. software life cycle) wird die Gesamtheit der Stadien und Phasen bezeichnet, welche ein Anwendungssystem oder generell Software von der Entstehung bis hin zur Deinstalla­tion oder Ersetzung durch eine neues Anwendungssystem durchläuft.^[27] Bedingt vergleichbar mit dem aus dem Marketing bekannten Produktlebenszyklus, welcher sich jedoch i.d.R. auf den Umsatzverlauf in den Lebensphasen (Einführung, Wachstum, Reife, Sättigung, Degeneration) eines Produktes bezieht^[28], dient der Anwendungssystem-Lebenszyklus dazu, a) die Software unter Betrachtung der Variable ‚Zeit’ in Stadien einzuordnen, und b) aufbauend auf dieser Abstraktions- und Diskussionsgrundlage, einzelne Maßnahmen entsprechenden Lebenszyklusstadien zuzuordnen oder auch Untersuchungen durchzuführen, um eventuelle Regelmäßigkeiten abzuleiten. In dieser Arbeit werden die fünf Stadien Softwareentwicklung, Softwareverkauf, Softwareeinführung, Softwarebetrieb und Wartung/Ablösung unterschieden. Das Stadium des Verkaufs findet nur Anwendung, wenn die Software an Kunden verkauft wird. Innerhalb dieser fünf Stadien ergeben sich die in Abbildung 1 dargestellten Phasen und Aktivitäten.

Abbildung 1: Anwendungssystem-Lebenszyklus^[29]

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung.

Bezüglich der Begrifflichkeit sind in der Literatur Inkonsistenzen zu erkennen. Manche Autoren setzen den Softwarelebenszyklus mit einem so genannten Vorgehensmodell (i.d.R. Wasserfallmodell) gleich, meinen damit aber vornehmlich den Prozess der Softwareentwicklung (vgl. Tabelle 18, Anhang S. 95). Bei Hiebl, Igelsböck und Kogler wird dies besonders deutlich: „Der Software Life Cycle ist ein phasenorientiertes Vorgehensmodell.“^[30] Um begriffliche Unklarheiten in dieser Arbeit zu vermeiden: Jedes Softwaresystem durchläuft den Anwendungssystem-Lebenszyklus (Softwarelebenszyklus). Das Stadium der Softwareentwicklung ist nur eines von mehreren im Lebenszyklus. Wie das Stadium der Softwareentwicklung in Phasen und Aktivitäten eingeteilt wird (Vorgehensweise), wird mittels eines Vorgehensmodells geplant und festgelegt. Eine Ausweitung der Betrachtung über das Stadium der Softwareentwicklung bringt tiefere Erkenntnisse über das tatsächliche Nutzen-Kosten Verhältnis einer Software. Denn mit der Auslieferung ist weder das ‚Leben’ eines Anwendungssystems noch die Arbeit der Programmierer zu Ende.^[31] In den Stadien nach der Auslieferung entstehen häufig weitere nicht unerhebliche Aufgaben und Kosten wie z.B. durch Änderung und Anpassung der Software. Vor allem bei Softwaresystemen „[…] mit langer Lebensdauer übersteigen diese Kosten wahrscheinlich die Entwicklungskosten um das Drei- oder Vierfache“^[32].

2.2 Ergonomie und Softwareergonomie

Der Begriff Ergonomie (griechisch: ‚ergon’ (Arbeit, Kraft) und ‚nomos’ (Regel, Gesetz))^[33] findet seinen Ursprung im Jahre 1857 in Polen^[34]. Seinerzeit hat der Wissenschaftler Wojciech Jastrzebowski diesen Begriff zum ersten Mal verwendet und auch definiert: „[Ergonomie ist ein] ’wissenschaftlicher Ansatz…damit wir aus diesem Leben die besten Früchte bei der geringsten Anstrengung mit höchster Befriedigung für das eigene und allgemeine Wohl ernten…’“^[35].

Gegenwärtig, fast 150 Jahre später, hat sich die Ergonomie zu einem interdisziplinären und breit gefächerten Forschungsgebiet entwickelt. Neben den Arbeitswissenschaften haben sich Wissenschaftler aus den Bereichen Psychologie bis hin zur Informatik den Herausforderungen dieses Themas gestellt.^[36] So gibt es heute eine Vielzahl unterschiedlicher Definitionen; die Grundidee von Jastrzebowski ist jedoch erhalten geblieben: Verbesserte Arbeitsbedingungen (‚bei der geringsten Anstrengung’) gepaart mit einer erhöhten Produktivität unter Berücksichtigung von Menge und Güte (‚die besten Früchte’) zugunsten des Menschen (‚mit höchster Befriedigung für das eigene und allgemeine Wohl’). So bezeichnet der Brockhaus die Ergonomie als eine „Disziplin, die sich mit der Anpassung der Arbeit(sbedingungen) an die Eigenschaften des menschlichen Organismus beschäftigt“, mit deren Hilfe „[…]technische Prozesse aufgrund von Messungen […] und Erkenntnissen der Arbeitsmedizin, -physiologie und -psychologie sowohl hinsichtlich humanitärer wie auch ökonomische[r] Ziele optimal gestaltet werden“^[37].

Mit vermehrtem Einzug der Technologie in die Arbeitswelt des Menschen haben Werkzeuge, darunter vor allem Computer, an Bedeutung gewonnen.^[38] In diesem Sinne kann Ergonomie als die Lehre der Anpassung von Technologie an ihre Benutzer, den Menschen, verstanden werden.^[39] Tatsächlich ergibt sich in der Triade zwischen Mensch, Aufgabe und Computer^[40] ein reziprokes Abhängigkeitsverhältnis. Computer werden nicht nur an die durch Menschen und Aufgaben vorgegebenen Bedingungen angepasst, sondern haben ihrerseits einen starken Einfluss auf die Aufgabe und die verwendete Arbeitsweise des Menschen, und folglich auf seine gesamte Arbeitsumgebung. Abbildung 2 stellt diesen Zusammenhang bildlich dar.

Abbildung 2: Das Verhältnis Mensch – Aufgabe - Computer

Abbildung in dieser Leseprobe nicht enthalten

In Anlehnung an: Herczeg (1994), S. 4; Wandmacher (1993), S. 1.

Um dieses Verhältnis hinsichtlich der Qualität des Arbeitslebens des Menschen, sowie der Produktivität als ökonomische Komponente ergonomisch zu gestalten, wird man bei der Software des Computersystems als flexibelste Stellschraube fündig. Die Softwareergonomie, als Teildisziplin der Ergonomie, greift diesen Gedanken auf und wird unter eben diesem Terminus in Deutschland seit Anfang der 80er Jahre verwendet. Bereits im Jahre 1983 tagte die erste Fachkonferenz mit dem Titel ‚Software-Ergonomie’ in Nürnberg.^[41] Gemäß Eberleh, Oberquelle und Oppermann “[…] beschäftigt sich Software-Ergonomie disziplinübergreifend speziell mit der benutzergerechten Gestaltung der Mensch-Computer-Interaktion (MCI), d.h. mit der Gestaltung der Teile eines interaktiven Computersystems, die von Software gesteuert werden und an der so genannten Benutzungsoberfläche wirksam werden.“^[42] Gleichzeitig weisen diese Autoren darauf hin, dass Softwareergonomie nicht an der Benutzungsoberfläche halt machen darf, sondern ebenso die dahinter verborgenen Funktionalitäten und Prozesse behandeln muss.^[43] Daher wird in dieser Arbeit nicht von der Benutzungsoberfläche, sondern von der Benutzerschnittstelle gesprochen, welche neben der Benutzungsoberfläche ebenso die dahinter liegenden Funktionalitäten betont. Anwendungssysteme sind über eine Benutzerschnittstelle, welche den Dreh- und Angelpunkt in der Mensch-Computer-Interaktion darstellt, direkt mit den Nutzern verbunden. Hauptuntersuchungsobjekt der Softwareergonomie ist somit die Benutzerschnittstelle, welche von Rosson und Carroll als „[…] physical representations and procedures that are provided for viewing and interacting with the system functionality“^[44] definiert wird. Die Funktionalität der Software bestimmt die Möglichkeiten des Anwendungssystems, und die Benutzerschnittstelle legt fest, wie die Nutzer agieren müssen, um diese Möglichkeiten auszuschöpfen. Damit wird die Benutzerschnittstelle zum ‚Steuerrad’ sämtlicher Funktionalitäten des Anwendungssystems.^[45] Durch die immer stärker graphisch orientierten Benutzeroberflächen haben Benutzerschnittstellen in der Softwareentwicklung stark an Bedeutung gewonnen. Bereits in einer Studie von 1990 wurde geschätzt, dass die Benutzerschnittstelle bis zu 66% der Codezeilen von Software und mindestens 40% des Entwicklungsaufwands ausmacht.^[46]

Es ist hilfreich die Softwareergonomie anhand der Benutzerschnittstelle in eine ‚grafik-orientierte’ Softwareergonomie, welche sich mit Dialogtechniken und Bildschirmmenüs befasst und in eine ‚prozess-orientierte’ Softwareergonomie, die schwerpunktmäßig an der Ablaufstruktur von Software ansetzt, zu unterteilen. Dies entspricht allerdings nicht ihrer Vielfalt. Softwareergonomie kann weit stärker untergliedert werden (vgl. Abbildung 26, Anhang S. 92). Somit spiegeln sich in den Definitionen unterschiedlicher Autoren verschiedenste Schwerpunkte und Denkweisen wider. So beschreibt z.B. Wandmacher „[…] die Anpassung der Arbeitsbedingungen bei der Mensch-Computer-Interaktion an die sensumotorischen und kognitiven Fähigkeiten und Prozesse des Menschen“^[47] als Gegenstand der Softwareergonomie. Tatsächlich behandelt sein Werk eher die ‚grafik-orientierte’ Softwareergonomie auf Basis der Wahrnehmungs- und Kognitionspsychologie. Unter diesem Fokus wird Softwareergonomie häufig auch als kognitive Ergonomie bezeichnet.^[48]

In dieser Arbeit werden die in Software enthaltenen Funktionalitäten und Prozesse im Arbeitskontext des Benutzers in den Vordergrund gestellt. Im Sinne der obigen Behelfskategorisierung wird also verstärkt die ‚prozess-orientierte’ Softwareergonomie betrachtet. Denn diese Komponenten sind es, die den größten Einfluss auf das Gleichgewicht der Triade haben (vgl. Abbildung 2, S. 8) und im Rahmen der Softwareentwicklung von herausragender Bedeutung sind. Daher wird für diese Arbeit eine pragmatische Definition von Softwareergonomie gewählt, die vom deutschen Delegationsleiter im internationalen Normenausschuss für Softwareergonomie übernommen wird: „[Ergonomische Software ist] ’gebrauchstaugliche’ Software, die den Benutzer bei seiner Arbeit unterstützt ohne ihm Arbeitsschritte oder Probleme aufzubürden, die durch die Software (und nicht durch die Arbeitsaufgabe selbst) bedingt sind.“^[49]

Um Software auf ihre Ergonomie hin beurteilen und auch unter diesem Aspekt ent­wickeln zu können, soll die Softwareergonomie letztendlich auch Gesetze und Normen bereitstellen.^[50] Aktuelle Richtlinien dahingehend, wie ergonomische Software charakterisiert wird, was der oben erwähnte Begriff ‚Gebrauchstauglichkeit’ bedeutet und welche Implikationen dies für die Softwareentwicklung hat, werden ab Kapitel 4 diskutiert.

2.3 Wirtschaftlichkeit und Risiko

Im Kontext dieser Arbeit sollen die Auswirkungen einer ergonomieorientierten Softwareentwicklung auf die Wirtschaftlichkeit und das Risikoreduktionspotenzial im Anwendungssystem-Lebenszyklus untersucht werden. Die Wirtschaftlichkeit ist ein zen­trales Element im Zielsystem eines Unternehmens, dies gilt auch für den Bereich der Softwareentwicklung bzw. den Lebenszyklus von Anwendungssystemen. In der Betriebswirtschaft werden zur Bestimmung der wertmäßigen Wirtschaftlichkeit i.d.R. die Größen Ertrag und Aufwand ins Verhältnis gesetzt (vgl. Formel 1).^[51] Eine Steigerung der Wirtschaftlichkeit wird demnach durch einen Anstieg des entsprechenden Quotienten im Zeitverlauf angezeigt.

Formel 1: Wirtschaftlichkeit I

Abbildung in dieser Leseprobe nicht enthalten

Formel 2: Wirtschaftlichkeit II

Abbildung in dieser Leseprobe nicht enthalten

Für die in späteren Kapiteln durchgeführten Kalkulationen bietet es sich jedoch an, die Wirtschaftlichkeit im Sinne eines absoluten Gewinnziels zu definieren.^[52] In dieser Arbeit wird die Wirtschaftlichkeit daher als die Differenz zwischen Nutzen und Kosten formuliert (vgl. Formel 2). Der Begriff Nutzen ist weiter gefasst als der Begriff Ertrag. Durch die Wahl der Größe Nutzen wird erstens, dem in der angelsächsischen Literatur oft verwendeten Begriffspaar ‚cost-benefit’^[53] entsprochen und zweitens, geht es bei der ergonomieorientierten Softwareentwicklung um einen Nutzen, der sich aus den verschiedensten Bestandteilen zusammensetzen. So lässt sich zwischen einem quantitativen und einem qualitativen Nutzen unterscheiden. Letzterer ist nur bedingt greifbar und kann nicht immer in Zahlen ausgedrückt werden.^[54] Ein solcher Nutzen kann sich z.B. in einem positiven Gefühl eines Anwenders bei der Verwendung guter Software ausdrücken.

Generell sind die Kosten eines Softwareentwicklungsprojektes u.a. stark davon abhängig, wie komplex die zu entwickelnde Software ist und welches Vorgehensmodell angewendet wird.^[55] So ist in späteren Kapiteln ebenso zu untersuchen, welche möglicherweise negativen Auswirkungen die Integration der Softwareergonomie in ein Vorgehensmodell auf der Kostenseite haben kann. Unter Umständen entstehen im Stadium der Entwicklung dadurch sogar höhere Kosten, so dass sich die Frage ergibt, ob dieser zusätzliche Aufwand in späteren Stadien überhaupt wieder kompensiert werden kann. Unter Betrachtung des Lebenszyklus von Anwendungssystemen müssen demnach die Total Cost of Ownership (TCO) untersucht werden. Hierunter können alle Kosten, die nach der Entwicklung der Software anfallen, definiert werden.^[56] Darüber hinaus bewegt sich die Kostenvariable während des Softwareentwicklungsprojekts im so genannten magischen Dreieck des Projektmanagements, einem Zielkonflikt mit den Variablen Zeit und Produkt (vgl. Abbildung 27, Anhang S. 93). Die Veränderung einer dieser drei Variablen führt immer auch zu einer Veränderung von mindestens einer der anderen.^[57]

Risiken können negative Auswirkungen auf alle drei Komponenten des magischen Dreiecks haben. Dadurch kann das Softwareentwicklungsprojekt aus dem Gleichgewicht geraten, was wiederum verstärkt negative Effekte erzeugt und weitere Risiken nach sich zieht. Die Analyse von Risiken in Zusammenhang mit der Analyse von Nutzen und Kosten ist als ein wichtiger Bestandteil der Wirtschaftlichkeitsanalyse von IT-Projekten zu sehen.^[58] In der Literatur finden sich zahlreiche unterschiedliche Definitionen des Risikobegriffs^[59]. Schulte betont (im Hinblick auf diese Untersuchung besonders treffend) den Charakter der unvollständigen Information und weist auf die Divergenz vom Geplanten hin: „Risiko resultiert ursachenbezogen aus der Unsicherheit zukünftiger Ereignisse – wobei dies regelmäßig mit einem unvollständigen Informationsstand einhergeht – und schlägt sich wirkungsbezogen in einer negativen Abweichung von einer festgelegten Zielgröße nieder.“^[60] Der Informationsstand über ein Risiko als auch das Wissen um ein Risiko dienen also der Risikoreduktion. Im Sinne der ergonomieorientierten Softwareentwicklung bedeutet dies, je besser mein Informationsstand über den Nutzer und seinen Nutzungskontext, umso geringer sind damit zusammen­hängende Risiken. Boehm erstellte im Jahre 1988 eine Liste der zehn häufigsten Risiken bei Softwareentwicklungsprojekten. Darunter erscheinen die Folgenden als besonders interessant: a) Entwickeln der falschen Softwarefunktionalität, b) Entwickeln einer falschen Benutzerschnittstelle und c) kontinuierlicher Wandel der Nutzeranforderungen.^[61]

Risiken werden gemeinhin durch eine Multiplikation der antizipierten Konsequenzen bzw. deren Kosten mit der Eintrittswahrscheinlichkeit quantifiziert.^[62] Das Produkt wird risk exposure genannt. Dividiert man risk exposure durch die Kosten, die nötig sind, um das Risiko zu reduzieren erhält man den risk leverage. Schließlich ergibt sich der so genannte risk reduction leverage gemäß untenstehender Formel.^[63]

Formel 3: Risk Reduction Leverage

Abbildung in dieser Leseprobe nicht enthalten

Stellt sich heraus, dass der risk reduction leverage nicht hoch genug ist, den Risikoreduktionsaufwand zu rechtfertigen, müssen andere Methoden zur Anwendung kommen.^[64] Es ist daher zu prüfen, ob die ergonomieorientierte Softwareentwicklung einen angemessenen Beitrag zur Risikoreduktion zu leisten vermag. Angemessen ist dieser dann, wenn möglichst viele Risiken bei gegebenem Kostenaufwand vermieden werden können.^[65] Der Beitrag wird im Rahmen dieser Untersuchung ebenso als angemessen betrachtet, wenn ein projektentscheidendes Risiko (also mit extrem hoher risk exposure) mit an Sicherheit angrenzender Wahrscheinlichkeit vermieden werden kann und der Kostenaufwand unter den potentiellen Schadenskosten liegt.

3 Vorgehensmodelle in der Softwareentwicklung unter Betrachtung von Risikoreduktion und Wirtschaftlichkeit

Würden 100 Softwareentwickler exemplarisch die gleiche Aufgabenstellung erhalten, würde es keine identischen Ergebnisse geben. Auch der Weg dorthin wird kaum zweimal exakt übereinstimmen. Diese schöpferische Freiheit macht den Reiz aber gleichzeitig auch die Schwierigkeit der Softwareentwicklung aus.^[66] Wenn eine Vielzahl Entwickler und sonstige Projektbeteiligte gleichzeitig am Werk sind, ist eine strukturierte und methodische Vorgehensweise notwendig.^[67] Kosten und Risiken müssen in kontrollierten Bahnen gehalten werden.

3.1 Was sind Vorgehensmodelle?

Vorgehensmodelle (auch Prozessmodelle bzw. Process Models^[68] und Projektmodelle^[69] ) geben diese Struktur vor, indem sie den Prozess der Softwareentwicklung abstrakt abbilden und als Strategie bei der Durchführung dienen.^[70] Sie bestimmen die Kriterien, wann von einer zur nächsten Aktivität übergegangen werden darf^[71], und legen somit die Abfolge von Meilensteinen^[72] und Phasen eines Projektes fest.^[73] Idealisiert haben Vorgehensmodelle eine Vielzahl wünschenswerter Auswirkungen auf Softwareent­wicklungsprojekte. Sie bieten einen Rahmen für die Planung, Aufwandsschätzung und Durchführung von Softwareentwicklungsprojekten. Anhand von Meilensteinen und festgelegten Teilaktivitäten weiß dass Projektteam, welche Aktivitäten wann durchzuführen sind. Zwischenschritte und Zwischenprodukte sind aufeinander abgestimmt und sowohl Redundanzen als auch Inkonsistenzen können besser vermieden werden.^[74]

Die Wahl eines Vorgehensmodells hängt von der Art der zu entwickelnden Software^[75], den gesetzten Prioritäten im magischen Dreieck (vgl. Kapitel 2.3) und den Erfahrungen, Fähigkeiten und Gewohnheiten des Entwicklungsteams ab. Die Wahl eines ungünstigen Vorgehensmodells kann allerdings dazu führen, dass das Projekt nur schleppend voranschreitet und sich eine allgemeine Frustration ausbreitet. Projektplanung und Effizienz werden beeinträchtigt. Ebenso kann aber auch die Entscheidung, kein Vorgehensmodell zu verwenden diese negativen Auswirkungen nach sich ziehen.^[76]

Seit Vorgehensmodelle Ende der 70er Jahre aufkamen, wurden sie ständig weiter entwickelt oder durch neue ersetzt. Heute gibt es eine große Mannigfaltigkeit von Vorgehensmodellen und viele Unternehmen verwenden eigens entwickelte Varianten. In Deutschland machen dies ca. 34% (2000) und in England ca. 59% (1999) der softwareentwickelnden Unternehmen.^[77] Aktuelle Entwicklungen zeigen jedoch auch, dass es eine Tendenz weg von der strikt bürokratischen Anwendung dieser Modelle gibt. Die teils allheilmittelartigen Erwartungen konnten oft nicht erfüllt werden. Dies führte dazu, dass nicht wenige Entwickler Vorgehensmodellen sehr kritisch gegenüberstehen und manche Organisationen nahezu komplett of diese verzichten. Sie bevorzugen weniger formale Vorgehensweisen, die ein Programmieren ‚aus dem Stegreif’ ermöglichen. Im Bereich der Web-basierten Anwendungsentwicklung ist diese Vorgehensweise derzeit recht verbreitet. Man verlässt sich auf die Fähigkeiten einzelner Schlüsselmitarbeiter.^[78] Avison und Fitzgerald warnen aber auch vor dieser Entwicklung. „The current swirl of diversity could signal a return to the days of ad hoc systems development, lack of formal methodology, and consequent increase in failure.“^[79]

So ist es bedeutend zu erkennen, dass jeder Entwicklungsprozess auf die entsprechende Situation abgestimmt werden muss. Es geht nicht darum, das perfekte Modell für alle Situationen parat zu haben. Im Sinne einer Prozessmodellierung kommt einem Vorgehensmodell stattdessen die wichtige Rolle zu, dem Entwicklungsteam zu signalisieren, an welchen Stellen die notwendige Anpassung an die individuellen Gegebenheiten vollzogen werden muss.^[80]

3.2 Sequenzielle Vorgehensmodelle

3.2.1 Beschreibung

Sequenzielle Vorgehensmodelle, hierunter das Phasenmodell und insbesondere das so genannte ‚Wasserfallmodell’, sind die Pioniere der Vorgehensmodelle.^[81] Sequenzielle Vorgehensmodelle basieren auf der Idee des Anwendungssystem-Lebenszyklus (vgl. Kapitel 2.1), der eine sequenzielle Abfolge von vorbestimmten Phasen im Leben von Softwaresystemen definiert.^[82] Sequenzielle Modelle sehen für die Softwareentwicklung entsprechend ein lineares Vorgehen, und zwar mindestens einmalig durch alle entsprechenden Phasen vor. Sollte es zu Änderungen in den Anforderungen kommen, werden in einem neuen Durchgang wiederum alle Phasen des Vorgehensmodells in der vorgesehenen Reihenfolge sequenziell durchgearbeitet.^[83] Grundlegend ist das „[…] Prinzip, dass für jede der Phasen klar zu definieren ist, welche Ergebnisse erzielt werden müssen und dass eine Phase erst dann in Angriff genommen werden darf, wenn die vorhergehende vollständig abgeschlossen ist.“^[84] Als Durchführungskontrolle werden zum Abschluss jeder Phase ein oder mehrere Dokumente erstellt, welche als Spezifikation für die nächste Phase dienen.^[85]

Abbildung 3: Wasserfallmodell

Abbildung in dieser Leseprobe nicht enthalten

In Anlehnung an: McConnell (1996), S. 137; Sommerville (2001), S. 58; Pfleeger (2001), S. 49.

Das Wasserfallmodell (vgl. Abbildung 3), welches bereits eine leichte Weiterentwicklung des ursprünglichen Phasenmodells darstellt, führt die Rückkopplungsmöglichkeit bei zwei aufeinander folgenden Phasen ein (siehe blaue Pfeile in Abbildung 3).^[86]

Abbildung 4 zeigt das das V-Modell, welches eine Variation des Wasserfall-Modells darstellt. Ebenso wie das Wasserfallmodell wird der Entwicklungsprozess in sequenziell abfolgende Phasen strukturiert. Durch das dargestellte V wird deutlich, dass sich auf verschiedenen Ebenen jeweils zwei Phasen gegenüberstehen. Auf der linken Seite befinden sich analyse- und designbezogene Aktiviäten und auf der rechten Seite entsprechende Testaktivitäten. Das V-Modell betont demnach in besonderer Weise die Zusammengehörigkeit von (Zwischen-)Produkten und validierenden Tests. Falls in den Testphasen auf der der rechten Seite des Modells Probleme identifiziert werden, so kann ein Rücksprung in die entsprechende Phase auf der linken Seite des Modells erfolgen und Fehler behoben werden.^[87]

Abbildung 4: V-Modell

Abbildung in dieser Leseprobe nicht enthalten

In Anlehnung an: Pfleeger (2001), S. 53.

3.2.2 Risikoreduktion und Wirtschaftlichkeit

Phasenmodelle haben sich in der Praxis der Softwareentwicklung oftmals als unbefriedigend herausgestellt. Dies ist vor allem darauf zurückzuführen, dass in sehr theoretischer Weise der Prozess der Softwareentwicklung mit gängigen industriellen Produk­tionsprozessen gleichgesetzt wird.^[88] Es wird davon ausgegangen, dass die Produktion des Softwareproduktes genau vorhersehbar und kontrollierbar ist und somit fest definierte Phasen sequenziell durchlaufen werden können. Die detaillierte Definition von Anforderungen zu Beginn des Prozesses sei damit ausreichend. Etwaige auftretende Fehler während des Prozesses könne man in der Phase der Wartung ausmerzen.^[89]

Diese starre Vorgehensweise soll zu einer besseren Plan-, Organisier-, und Kontrollierbarkeit führen.^[90] Jedoch zeigte die Realität, dass eine gänzlich sequenzielle Vorgehensweise nur selten durchführbar ist.^[91] So beschreibt Pfleeger das Kernproblem trefflich: „The biggest problem with the waterfall model is that it does not reflect the way code is really developed. Except for very well understood problems, software is usually developed with a great deal of iteration.“^[92] Phasenmodelle sind insgesamt sehr anfällig für Fehler in frühen Phasen der Entwicklung. Bei später Entdeckung kann dies zu einem hohen Korrekturaufwand führen.^[93]

Als ein gravierendes Risiko (im ursprünglichen Phasenmodell) erweist sich daher das Fehlen der Möglichkeit einen oder mehrere Schritte zurück zu gehen, wenn z.B. während der Implementierungsphase Änderungen an den Anforderungen auftreten.^[94] Reine Phasenmodelle zeigen dem Entwicklungsteam keinen Weg auf, wie in solchen Situationen vorzugehen ist.^[95] Das V-Modell betont im stärkeren Maße als das Wasserfallmodell die Möglichkeit der Wiederholung und des Rücksprungs zu Entwicklungsaktivitäten in frühen Phasen.^[96] Doch auch dies ist nicht ausreichend. Denn bei Anwendungssystemen können, wie Abbildung 5 zeigt, Anforderungen seitens der Benutzer oft erst im Zeitverlauf oder nach einer Phase der Erprobung festgelegt werden. Ferner können Anforderungen durch eine Umgestaltung der Arbeitsprozesse im Unternehmen kontinuierlichen Veränderungen unterliegen.^[97]

Abbildung 5: Entwicklung von Nutzerbedürfnissen bzw. Anforderungen im Zeitablauf

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Davis/ Bersoff/ Comer (1988), S. 1455.

Im Extrem heißt dies: „[…] you cannot know what to build until you first build the wrong system.“^[98] Um diese Problematik zumindest annähernd lösen zu können, muss die Anforderungsanalyse fortlaufend oder zumindest mehrfach während des Softwareentwicklungsprozesses erfolgen.^[99] Sinnvoller Weise immer in enger Interaktion mit den letztendlichen Nutzern des Anwendungssystems. Doch auch in diesem Punkt zeigen strikt sequenzielle Vorgehensmodelle Schwächen. Die Kommunikation mit den Anwendern des Systems ist auf die Phase der Anforderungsanalyse und –definition begrenzt. Bis zur Auslieferung können Monate oder gar Jahre vergehen. Eine mangelnde Akzeptanz durch die Anwender ist bei solchen Projekten keine Seltenheit und führt beim Kunden zu erhöhten TCOs (vgl. Kapitel 2.3).^[100]

Ein weiteres Risiko liegt darin, dass die Softwarekomponenten gemäß des Wasserfallmodells erst zum Ende des Entwicklungsprozesses getestet werden. Dies liegt daran, dass generell erst sehr spät test- bzw. nutzbare Softwarekomponenten vorliegen. Da Entwicklungsprojekte teilweise über Jahre andauern, kann dies negative wirtschaftliche als auch zeitliche Folgen haben. Eine fortlaufende Qualitäts- bzw. Anforderungskontrolle wäre daher angebracht.^[101]

Die Bedingung, dass ein Schritt erst dann abgeschlossen werden kann, wenn alle vorgegebenen Produkte für diesen Teilschritt erreicht worden sind, dient der Risikominimierung für den nächsten Arbeitsschritt.^[102] Diese Vorgehensweise ist heutzutage jedoch, da es auf möglichst kurze Auslieferungszeiten ankommt, nur bedingt zeitgemäß.^[103] Die starke Dokumentengetriebenheit kostet viel Zeit und Ressourcen. Das V-Modell ist hier effizienter, da es stärker auf die korrekte Ausführung der Aktivitäten selber ausgerichtet ist und Dokumente nicht so stark in den Vordergrund stellt.^[104]

3.3 Iterative und inkrementelle Vorgehensmodelle

3.3.1 Beschreibung

Iterative (evolutionäre^[105] ) und inkrementelle Vorgehensmodelle entstanden aus der Absicht, die Produktauslieferungszeit (cycle time) für den Kunden bzw. Auftraggeber des Softwareentwicklungsprojektes zu reduzieren. Hierbei wird der Softwareentwicklungsprozess so gestaltet, dass das Anwendungssystem stufenweise in unterschiedlich weit entwickelten Versionen an den Kunden ausgeliefert werden kann. Es gibt also keinen einzelnen meist Jahre in der Zukunft liegenden Endabgabetermin wie dies oft bei sequenziellen Vorgehensmodellen der Fall ist. Dementsprechend kann der Kunde das System bereits in frühen Phasen, allerdings mit eingeschränkter Funktionalität, nutzen.^[106] Die abgeschlossene Anforderungsanalyse ist im Gegensatz zum Wasserfall-Model nicht Bedingung für den Übergang zum Entwurf und zur Implementierung. Stattdessen bekommt der Kunde sein System deutlich früher zu Gesicht und kann es operativ einsetzen und somit auch testen. Die ausgelieferten Systeme wachsen dann schrittweise mit neu hinzukommenden Anforderungen.^[107] In der Praxis werden meist Mischformen der iterativen und inkrementellen Vorgehensweise verwendet.^[108] Aus Gründen der Anschaulichkeit werden die beiden Grundmodelle hier jedoch zunächst getrennt vorgestellt.

Bei der iterativen Vorgehensweise enthält bereits die erste ausgelieferte Version alle Subkomponenten der Software. Der Kunde erhält alle Basisfunktionalitäten, jedoch in vereinfachter bzw. primitiver Form. Von Auslieferung zu Auslieferung werden die einzelnen Softwarekomponenten vervollständigt, um am Ende alle Detailfunktionalitäten zu enthalten. Inkrementelle Vorgehensmodelle unterteilen das geplante Anwendungssystem in einzelne Subkomponenten gemäß ihrer Funktionalität. Die erste Auslieferung enthält nur einen Teil der Subkomponenten, diese jedoch bereits mit voller Funktionalität. In den nächsten Auslieferungen werden die restlichen Subkomponenten schrittweise hinzugefügt.^[109] Abbildung 6 stellt die beiden Vorgehensweisen graphisch dar.

Abbildung 6: Iterative und inkrementelle Vorgehensweise

Abbildung in dieser Leseprobe nicht enthalten

In Anlehnung an: Pfleeger (2001), S. 57.

Das bekannte und vergleichsweise anspruchsvolle Spiralmodell von Boehm nutzt die iterative Vorgehensweise in einem eigenen Konzept.^[110] Der Prozess der Softwareentwicklung wird anhand einer Spirale dargestellt, welche in vier Sektoren (Phasen) unterteilt ist. Diese Sektoren werden entlang der Spirale im Sinne einer iterativen Softwareentwicklung mehrfach durchlaufen. Ein einmaliger Durchlauf (Iteration) enthält gemäß der vier Sektoren die in Abbildung 7 dargestellten Kerntätigkeiten.^[111] Markantestes Merkmal des Spiralmodells ist die Risikoorientierung und die sich danach ausrichtende Aufteilung des Softwareprojektes in einzelne Teilprojekte. Eine Iteration entspricht der Durchführung eines Teilprojektes, in dem es zunächst darum geht, die identifizierten Risiken zu beseitigen.^[112] Die Anzahl der Iterationen wird so lange erhöht, bis die Risikoanalyse zeigt, dass die bedeutendsten Risiken durch Gegenmaßnahmen unter Kontrolle gebracht werden konnten. Erst dann wird die Programmierung des eigentlichen Anwendungssystems vorgenommen. Hierbei ist die Vorgehensweise frei wählbar.^[113] Das Spiralmodell kann dementsprechend fast beliebig mit anderen Vorgehensmodellen kombiniert werden. Es endet normalerweise jedoch mit den Schritten des Wasserfallmodells.^[114] Abbildung 7 zeigt eine mögliche Form des Spiralmodells. Nach McConnell ist der Grundgedanke, „[…] you start on a small scale in the middle of the spine, explore the risk, make a plan to handle the risk, and then commit to an approach for the next iteration.”^[115]

Abbildung 7: Das Spiralmodell

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Zuser et al. (2001), S. 48; vgl. auch Boehm (1988), S. 64.

3.3.2 Risikoreduktion und Wirtschaftlichkeit

Iterative und inkrementelle Grundmodelle

Softwareentwicklung in Stufen ist insbesondere dann geeignet, „[…] wenn der Kunde seine Anforderungen noch nicht vollständig überblickt bzw. sich über die Möglichkeiten zur Realisierung der Anforderungen nicht bewusst ist und deshalb die Anforderungen nicht formulieren kann.“^[116] Der Kunde als auch der Entwickler gewinnen mit dem wachsenden Anwendungssystem an Erfahrung und Erkenntnissen, welche in die Entwicklung der darauf folgenden Version einfließen können.^[117]

Die Gefahr, dass Nutzeranforderungen in späteren Phasen unverhofft auftreten, wird minimiert und das Risiko, letztlich falsche oder nicht ausreichende Funktionalitäten zu entwickeln wird deutlich reduziert. Begünstigt dadurch, dass bei der inkrementellen Entwicklung als erstes die wichtigsten Funktionalitäten von Beginn an entwickelt und ausgeliefert werden, unterliegen die wichtigen Subkomponenten der längsten Testphase. Das Risiko von Softwareausfällen ist hiermit besonders gering. Auch hinsichtlich der Flexibilität und Reaktionszeit, bezogen auf die Implementierung von Anforderungsänderungen, schneiden die genannten Modelle im Vergleich zu sequenziellen Modellen gut ab. Denn die Vorgehensweise ist in sich auf eine schrittweise Anpassung des Systems ausgerichtet, und falls die Anforderung bisher noch nicht implementiert wurde, wird diese einfach bei der nächsten Version berücksichtigt.^[118]

Abbildung 8: Frühe Softwarenutzung durch iterative oder inkrementelle Vorgehensmodelle

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Pfleeger (2001), S. 56.

Unter Betrachtung der TCO^[119], ergeben sich erhebliche Kosteneinsparungs­möglich­keiten. So ist der Zeitraum zwischen Projektstart und erster Inbetriebnahme im Vergleich zu sequenziellen Vorgehensmodellen stark verkürzt.^[120] Der Kunde kann dadurch, wie in Abbildung 8 ersichtlich, viel früher einen Nutzen aus seiner Investition ziehen und daher die Wirtschaftlichkeit seiner Investition erhöhen. Darüber hinaus kann die Einarbeitung der Mitarbeiter zeitig stattfinden. Dies erleichtert die Analyse, ob die Prozesse der Mitarbeiter durch das Anwendungssystem entsprechend unterstützt werden oder ob zusätzliche Verbesserungen an der Benutzerschnittstelle notwendig sind.^[121] Durch diese frühen Erkenntnisse kann der Auftragnehmer das Risiko vermeiden erst spät erkannte Probleme unter besonders hohem Kostenaufwand zu lösen.^[122]

Iterative und inkrementelle Vorgehensmodelle bergen jedoch auch Risiken. Da die Lauffähigkeit der auszuliefernden Systemteile im Vordergrund steht, wird die Entwicklung hauptsächlich durch den Code angetrieben.^[123] Mit der Gewissheit im Hinterkopf, dass die aktuelle Version sowieso noch durch verbesserte bzw. erweiterte Versionen ersetzt wird, kann es dazu kommen, dass unstrukturiert ‚drauflos’ programmiert und die Benutzerfreundlichkeit vernachlässigt wird. Gegebenenfalls zieht sich dadurch das ganze Projekt unnötig in die Länge und erzeugt Mehrkosten. Hinzu kommt, dass stetige Veränderungen i.d.R. dazu führen, dass die Struktur der Software beeinträchtigt wird. Die Einbindung von Softwareänderungen (insbesondere beim iterativen Ansatz) wird zunehmend komplizierter und teurer.^[124]

Ein weiteres Risiko, das insbesondere in fortgeschrittenen Projektstadien schwerwiegende Auswirkungen haben kann, verbirgt sich in einer der Hauptstärken dieser Modelle. Die Möglichkeit Anforderungen in späteren Auslieferungen einzubauen mag dazu verleiten eben diese zu Beginn nicht akribisch genug zu erfragen. Demzufolge kann es dazu kommen, dass in einer fortgeschrittenem Stufe der Produktentwicklung die Softwarearchitektur für die Umsetzung der verbleibenden Anforderungen nicht mehr geeignet ist. Eine kostenintensive, nachträgliche Änderung der Architektur wäre die Folge.

Spiralmodell

Wie dargestellt, sind die Risikoanalyse und damit verbundene Maßnahmen zur Risikoreduktion in das Spiralmodell integriert. Bei identifizierten Risiken sieht Sektor Nr. 2 z.B. die Möglichkeit vor, Prototypen anzufertigen, Benutzerbefragungen durchzuführen, oder ein Benchmarking vorzunehmen.^[125] Welche Methoden hier zum Einsatz kommen, bleibt der jeweiligen Situation überlassen, so dass das Projektteam selbst die als wirksam erachteten Maßnahmen ableiten kann. Diese inhärente Fokussierung auf “[…] areas of uncertainty that are significant sources of project risk”^[126] verhelfen dem Spiralmodell zu einer sehr guten Risikoreduktionsfähigkeit.

Das Spiralmodell erweist sich außerdem als äußerst flexibel. Je nach Art und Verschiedenheit der identifizierten Risiken gleicht es mal mehr herkömmlichen Vorgehensmodellen, oder aber es führt Charakteristika einzelner Modelle zu einem Neuen zusammen. Wenn das Risiko, eine falsche Benutzerschnittstelle zu entwickeln gering ist, und die Kosten als auch die Zeitplanung strengen Restriktionen unterliegen, so wird es mehr dem Wasserfallmodell gleichen. Im umgekehrten Fall wird das Spiralmodell verstärkt Elemente einer evolutionären bzw. iterativen Vorgehensweise enthalten. Ein Mix von Risiken wird sich auch in einem ‚bunten’ Spiralmodell widerspiegeln.^[127]

In dieser Flexibilität liegt jedoch auch ein Risiko. Das Entwicklungsteam muss in der Lage sein, die kritischen Risiken zu identifizieren und das Spiralmodell entsprechend darauf ausrichten. Bei unerfahrenen Entwicklern besteht die Gefahr, leicht erkennbare und eventuell eher unbedeutende Risiken im Spiralmodell detailliert zu berücksichtigen, versteckte kritische Risiken hingegen außen vor zu lassen. In solch einem Fall befände sich das Entwicklungsteam in einer gefährlichen Phase des vermeintlichen Fortschritts.^[128] Aus Sicht der Projektplanung erweist sich die Tatsache, dass beim Spiralmodell die Anzahl der Durchläufe im Projekt durch die auftretenden Risiken bestimmt wird als problematisch. Eine Zeit- und Kostenplanung ist damit zu Beginn des Projektes äußerst schwierig und unsicher. Dies kann z.B. dazu führen, dass das Projekt durch unnötige Iterationen in die Länge gezogen wird und somit erhöhte Kosten nach sich zieht.^[129] In Zusammenhang damit steht eine gewisse Unsicherheit darüber, welchen Stand das Entwicklungsprojekt aktuell hat. Das Ausmerzen von Risiken durch diverse Methoden mag manch einem Entwickler wie ein ‚auf der Stelle treten’ vorkommen. So merkt auch Boehm selbst an, dass das Spiralmodell einen starken Bedarf an Meilensteinen, Zeitplansynchronisationstechniken und Statusindikatoren hat. Insbesondere unerfahrene Entwickler benötigen Orientierungshilfen wie z.B. Checklisten.^[130]

3.4 Kategorisierung von Risiken und Kosten

3.4.1 Risiken

Die identifizierten Risiken können, wie Abbildung 9 zeigt, in sechs Kategorien eingeteilt werden. Die farbliche Kennzeichnung betont die Verwandtschaft jeweils zweier Kategorien. Kategorie Nr. 1 beschreibt Risiken, die auf fehler- oder lückenhafte Anforderungen zurückzuführen sind.^[131] Anforderungen seitens des Kunden können sich im Verlaufe des Entwicklungsprozesses gravierend ändern. Teils haben Kunden Schwierigkeiten ihre eigenen Anforderungen zu verstehen oder in Worte zu fassen. Darüber hinaus kann es sein, dass Kunden die Möglichkeiten zur Realisierung von Anforderungen nicht kennen und diese daher auf ein Minimum herunterschrauben, um dann z.B. nach gesehenen Prototypen höhere Ansprüche zu stellen. Wie bereits beschrieben, muss das Entwicklungsteam dafür Sorge tragen, jederzeit über die Anforderungen Bescheid zu wissen und diese kontinuierlich durch einen Abgleich mit dem Kunden aktualisieren. Bei Eintreffen von Risiken aus Kategorie Nr. 1 kommt es zu falschen oder nicht ausreichenden Funktionalitäten. Laut einer Studie der British Computer Society (BCS) aus dem Jahre 2001 zählen unklare Ziele und Anforderungen zu den häufigsten Projektscheiterungsgründen. Die über 1000 befragten Projektmanager wählten darüber hinaus ‚klare und detaillierte Anforderungen’ zum wichtigsten Erfolgsfaktor bei IT-Projekten.^[132]

Risikokategorie Nr. 2 ‚ Flexibilität ’ bezieht sich auf den möglichen Grad an Flexibilität im Prozess der Softwareentwicklung. Eine geringe Flexibilität birgt hohe Risiken, insbesondere in Bezug auf wechselnde Anforderungen. Sequenzielle Vorgehensmodelle haben hier ebenso wie im Bereich der Anforderungen starke Schwächen gezeigt. Die Möglichkeit von Sprüngen in vorige Phasen sollte gewährleistet sein, oder wie z.B. bei der iterativen Vorgehensweise ggf. gar nicht mehr nötig sein. Ein flexibler Prozess wird jedoch auch an seiner Reaktionszeit gemessen. Ein hohes Flexibilitätsrisiko liegt demnach auch in einer langsamen Reaktionszeit.

Abbildung 9: Risiko-Kategorien

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung.

Die nächste Kategorie umfasst die interne als auch die externe Kommunikation. Intern verbirgt sich hinter mangelnder Kommunikation das Risiko, dass die Projektmitglieder in ihren jeweils eigenen projektbezogenen Problemen versinken. So kann z.B. eine geringe Kommunikation bei Anwendung des Spiral-Modells zur Orientierungslosigkeit und folglich zu einer schlechteren Plan- und Kontrollierbarkeit führen. Beim dokumentengetriebenen Wasserfallmodell ist die projektinterne Kommunikation nicht so risikoanfällig. Die externe Kommunikation bezieht sich auf die Kommunikation mit den externen Stakeholdern, hierunter sind insbesondere Nutzer bzw. Kunden gemeint. Eine mangelhafte Kommunikation mit diesen kann zur Implementierung falscher oder unzureichender Funktionalitäten führen. Die im Rahmen der BCS Studie befragten Manager wählten die Kommunikationsfähigkeit zur wichtigsten Komponente des IT-Projektmanagements.^[133]

Das Risiko einer mangelnden externen Kommunikation erhöht das Risiko einer zu geringen Partizipation der Nutzer und somit auch einer fehlenden Nutzerakzeptanz. Risiko Nr. 4 bezieht sich sowohl auf den Zeitraum der Softwareentwicklung, als auch auf die nachfolgenden Stadien im Anwendungssystem-Lebenszyklus. Können die Nutzer nicht eingebunden werden, fehlt ihre Unterstützung in Sachen Anforderungs-KnowHow während der Entwicklung. Bekommen die Nutzer nach einem mehrjährigen Projekt ohne eigene Beteiligung eine Software ‚vorgesetzt’ so ist das Risiko einer Ablehnung hoch. Dies verstärkt sich in Projekten, in denen das Wasserfallmodell angewandt wurde.

Risikokategorien Nr. 5 und Nr. 6 beziehen sich jeweils auf das Projektmanagement. Risiken der Kategorie ‚ Fähigkeiten und Erfahrungen ’ umfassen die Kenntnisse und die Eignung der Projektmitglieder. So kann z.B. die Beschäftigung unerfahrener Programmierer zu unwartbarem Code führen. Bei unerfahrenen Projektmitgliedern kann es dazu kommen, dass z.B. im Spiralmodell die falschen Risiken angegangen werden oder dass das Projekt durch zu viele Iterationen die Zeit- und Ressourcenplanung übersteigt. Schließlich besteht in der Komplexität der Planung und Kontrolle von Softwareentwicklungsprojekten ein hohes Risiko. Ironischerweise entsteht dieses Risiko meist selbst aus plötzlich auftauchenden Problemen. Ein erfahrenes Entwicklungsteam kann zur Reduktion dieser Risiken beitragen. Bemerkenswerterweise ergab sich aus der Studie der British Computer Society, dass „[…] clear and detailed planning, and consistent project direction […]“^[134] als eher unbedeutende Erfolgsfaktoren beurteilt werden. Die Verfasser der Studie führen dies darauf zurück, dass ohnehin die Erwartung vor­herrsche, dass sich die Projektumstände laufend ändern und eine Neuausrichtung der Planung ständig notwendig sei.^[135] Die befragten Manager scheinen demnach das Planungsrisiko als so hoch einzuschätzen, dass sie es einfach hinnehmen. Daraus kann gefolgert werden, dass ebenso das Risiko einer geringen Flexibilität einen hohen Stellenwert in der Praxis haben muss.

3.4.2 Kosten

Die Einordnung der Kosten erfolgt, wie in Abbildung 10 dargestellt, in acht Kategorien. In Anlehnung an den Anwendungssystem-Lebenszyklus umfasst die Kategorisierung sowohl Kosten des Stadiums der Softwareentwicklung als auch Kostenfaktoren nachfolgender Stadien. Allgemeine Projektkosten beinhalten Kosten der Vergütung der Projektmitglieder, Kosten der Projektverwaltung und Kosten der Kommunikation sowie Dokumentation. Diese Kosten sind abhängig von der Anzahl der Projektmitglieder, vom allgemeinen Umfang des Projektes, aber auch von den Fähigkeiten und Erfahrungen der Projektmitglieder.

[...]

^[1] Vgl. Rudlof/ Becker-Töpfer (1997), S. 69; Oberquelle (2000), S. 5.

^[2] Vgl. Wallace/ Keil (2004), S. 68.

^[3] Vgl. Rudlof/ Becker-Töpfer (1997), S. 48; Oberquelle (2000), S. 5.

^[4] Dieser Aufwand wird ggf. auch vom Kunden getragen.

^[5] Vgl. Müller/ Fackelmayer (2003), S. 10; Sommerville (2001), S. 615.

^[6] Rudlof/ Becker-Töpfer (1997), S. 9.

^[7] ‚Usability’ bedeutet ‚Gebrauchstauglichkeit’ und ist ein Teilbereich der Softwareergonomie.

^[8] Vgl. Nielsen (1993 a).

^[9] Vgl. Ferré et al. (2001), S. 22.

^[10] Vgl. o.V. (2004); Hasso Plattner ist Chairman von SAP, des weltweit führenden Softwareunternehmens im Gebiet der Standardsoftware; siehe auch Sommerville (2001), S. 13.

^[11] Vgl. Beyer/ Holtzblatt (1998), S. 29; McConnell (1996), S. 234.

^[12] Vgl. Beyer/ Holtzblatt (1998), S. 29.

^[13] Vgl. Zuser et al. (2001), S. 15.

^[14] Vgl. Siedersleben (2003), S. 1.

^[15] Vgl. Zuser et al. (2001), S. 15.

^[16] Vgl. Sommerville (2001), S. 13.

^[17] Vgl. ebenda S. 20.

^[18] Vgl. Rudlof/ Becker-Töpfer (1997), S. 69.

^[19] Vgl. Rauterberg et al. (1994), S. 4.

^[20] Detaillierte Informationen zu den verschiedenen Rollen im Entwicklungsteam liefert z.B. Zuser et al. (2001), S. 35-43 und Pfleeger (2001), S. 25-27.

^[21] Vgl. Nielsen (1992), S. 14.

^[22] Dumke (2000), S. 6.

^[23] Vgl. ebenda S. 8.

^[24] Vgl. Sommerville (2001), S. 83; siehe auch Kapitel 2.3 zum Zielkonflikt dieser Größen.

^[25] Vgl. ebenda S. 84 ; Jurison (1999), S. 3-4.

^[26] Vgl. Davis/ Bersoff/ Comer (1988), S. 1454-1455; Beer (2003) S. 32; Grehag (2001), S. 183-184; Boehm/ Papaccio (1988), S. 1465.

^[27] Vgl. Dumke (2000), S. 17.

^[28] Vgl. Thommen/ Achleitner (2001), S. 166-169.

^[29] Es ist anzumerken, dass die Stadien in der Praxis nicht so strikt nacheinander ablaufen. Z.B. verläuft die Wartung in manchen Phasen parallel zum Betrieb.

^[30] Hiebl/ Igelsböck/ Kogler (1999), S. 10.

^[31] Vgl. Pfleeger (2001), S. 464.

^[32] Sommerville (2001), S. 25.

^[33] Vgl. Marquardt (1997), S. 9.; Redtenbacher (o.D.).

^[34] Vgl. Laurig (o.D.).

^[35] Jastrzebowski (1857) zitiert nach: Laurig (o.D.); erst im Jahre 1949 tauchte der Begriff der Ergonomie durch K.F.H. Murrell als ‚ergonomics’ wieder auf, vgl. hierzu Laurig (o.D.).

^[36] Vgl. Urbanek (1991), S. 1.

^[37] Brockhaus (1999).

^[38] Vgl. Herczeg (1994), S. 1.

^[39] Vgl. Eberleh/ Oberquelle/ Oppermann (1994), S. 1.

^[40] Vgl. Herczeg (1994), S. 3-4; Wandmacher (1993), S. 1.

^[41] Vgl. Eberleh/ Oberquelle/ Oppermann (1994), S. 1; Wandmacher (1993), S. 13, Tagung des German Chapter of the ACM.

^[42] Eberleh/ Oberquelle/ Oppermann (1994), S. 1; zur Abgrenzung: Hardware-Ergonomie behandelt die benutzerfreundlich Gestaltung von Bildschirmarbeitsplätzen und Computerperipherie, vgl. Herczeg (1994), S. 3 und S. 252.

^[43] Vgl. Eberleh/ Oberquelle/ Oppermann (1994), S. 1.

^[44] Rosson/ Carroll (2002), S. 382.

^[45] Vgl. ebenda S. 80-81; durch entsprechendes Prototyping kann die Benutzerschnittstelle während des Entwicklungsstadiums gar zur Kontrolle der Funktionalitäten eingesetzt werden.

^[46] Vgl. Bevan (2000), S. 9; Ehrlich/ Rohn (1994), S. 97; Müller/ Fackelmayer (2003), S. 10.

^[47] Wandmacher (1993), S. 1.

^[48] Vgl. ebenda S. 1.

^[49] Redtenbacher (o.D.).

^[50] Vgl. Herczeg (1994), S. 3.

^[51] Vgl. Thommen/ Achleitner (2001), S. 105-106; Wöhe/ Döring (2000), S. 48; siehe zum Vergleich auch Koreimann (2000), S. 325, er definiert Wirtschaftlichkeit als Verhältnis zwischen Leistung und Kosten.

^[52] Vgl. Thommen/ Achleitner (2001), S. 105.

^[53] Vgl. Bevan (2000).

^[54] Aus betriebswirtschaftlicher Sicht möchten wir möglichst jeden (auch qualitativen) Nutzen in einem quantitativen Ertrag zahlenmäßig ausdrücken, jedoch würde dies den Rahmen dieser Arbeit sprengen. Daher wird sich die Wirtschaftlichkeitsanalyse bisweilen auf den Kostenpart der Wirtschaftlichkeitsformel beschränken.

^[55] Vgl. Sommerville (2001), S. 24.

^[56] Vgl. Blasius (2004), S.58-59.

^[57] Vgl. Lennertz (2002), S. 343-344; McConnell (1996), S. 126; Jurison (1999), S. 6 ; Gaulke (2002), S. 13-14.

^[58] Vgl. Steinweg (2000), S. 60.

^[59] Vgl. Gaulke (2002), S. 10 ; Blasius (2004), S. 4; Mayr (2001), S. 170-171.

^[60] Schulte (1997), S. 12 zitiert nach: Wolf/ Runzheimer (2000), S. 24; anzumerken bzw. zu ergänzen ist, dass es durchaus auch zu einer positiven Abweichung vom Erwartungswert kommen kann.

^[61] Vgl. Boehm (1988), S. 70.

^[62] Vgl. Blasius (2004), S. 3; Pfleeger (2001), S. 115.

^[63] Vgl. Pfleeger (2001), S. 115 & 118.

^[64] Vgl. ebenda S. 115 & 118.

^[65] Oder vorher definierte Risiken bei möglichst geringem Kostenaufwand.

^[66] Vgl. Scheidle/ Taubner (2003), S. 5.

^[67] Vgl. Zuser et al. (2001), S. 19; Scheidle/ Taubner (2003), S. 5.

^[68] Vgl. Pfleeger (2001), S. 48.

^[69] Vgl. Reisin (1994), S. 313.

^[70] Vgl. Sommerville (2001), S. 56; Zuser et al. (2001), S. 45.

^[71] Vgl. McConnell (1996), S. 133.

^[72] Ein Meilenstein ist ein Zeitpunkt in einem Projekt, zu dem evaluiert wird, ob eine vorgegebene (Entwicklungs-)Stufe erreicht wurde und entsprechend Entscheidungen für den weiteren Projektverlauf getroffen werden. Vgl. Zuser et al. (2001), S. 25.

^[73] Vgl. Zuser et al. (2001), S. 25.

^[74] Vgl. Scheidle/ Taubner (2003), S. 7; Zuser et al. (2001), S. 19.

^[75] Vgl. Pfleeger (2001), S. 33.

^[76] Vgl. McConnell (1996), S. 134 & S. 465.

^[77] Vgl. GFK/ IESE/ ISI (2000), S. 127; Avison/ Fitzgerald (2003), S. 80.

^[78] Vgl. Avison/ Fitzgerald (2003), S. 81-82; Rosson/ Carroll (2002), S. 8.

^[79] Avison/ Fitzgerald (2003), S. 79.

^[80] Vgl. Pfleeger (2001), S. 48.

^[81] Vgl. Rauterberg et al. (1994), S. 81.

^[82] Vgl. Zuser et al. (2001), S. 45; Hiebl/ Igelsböck/ Kogler (1999), S. 10.

^[83] Vgl. Zuser et al. (2001), S. 45.

^[84] Mayr (2001), S. 71.

^[85] Vgl. Rosson/ Carroll (2002), S. 6; Davis/ Bersoff/ Comer (1988), S. 1453.

^[86] Vgl. Mayr (2001), 71-72; Zuser et al. (2001), S. 45-46.

^[87] Vgl. Zuser et al. (2001), S. 47; Pfleeger (2001), S. 52.

^[88] Vgl. Reisin (1994), S. 313; Pfleeger (2001), S. 28 & 50.

^[89] Vgl. Reisin (1994), S. 313.

^[90] Vgl. Mayr (2001), S. 71.

^[91] Vgl. Rosson/ Carroll (2002), S. 8; Mayr (2001), S. 71.

^[92] Pfleeger (2001), S. 50.

^[93] Vgl. Zuser et al. (2001), S. 47.

^[94] Vgl. ebenda S. 45.

^[95] Vgl. Pfleeger (2001), S. 50.

^[96] Vgl. ebenda S. 52.

^[97] Vgl. Reisin (1994), S. 313.

^[98] Rosson/ Carroll (2002), S. 7; vgl. auch Pfleeger (2001), S. 236.

^[99] Vgl. Rosson/ Carroll (2002), S. 38.

^[100] Vgl. Suhr/ Suhr (1993), S. 109.

^[101] Vgl. Reisin (1994), S. 313 ; Mayr (2001), S. 71.

^[102] Vgl. Zuser et al. (2001), S. 45.

^[103] Vgl. Pfleeger (2001), S. 56.

^[104] Vgl. ebenda S. 52.

^[105] Vgl. Balzert (1994), S. 416; Sommerville (2001), S. 58.

^[106] Vgl. Pfleeger (2001), S. 56; Balzert (1994), S. 416.

^[107] Vgl. Zuser et al. (2001), S. 49.

^[108] Vgl. Pfleeger (2001), S. 57.

^[109] Vgl. Pfleeger (2001), S. 56-57.

^[110] Vgl. Kunstmann (1993), S. 96.

^[111] Vgl. Boehm (1988), S. 64-65.

^[112] Vgl. McConnell (1996), S. 141.

^[113] Vgl. Zuser et al. (2001), S. 48.

^[114] Vgl. McConnell (1996), S. 141; Kunstmann (1993), S. 96.

^[115] McConnell (1996), S. 141.

^[116] Zuser et al. (2001), S. 49.

^[117] Vgl. ebenda S. 49; Sommerville (2001), S. 64.

^[118] Vgl. Davis/ Bersoff/ Comer (1988), S. 1454; Zuser et al. (2001), S. 49; Sommerville (2001), S. 65.

^[119] Zur Definition siehe Kapitel 2.3.

^[120] Vgl. Davis/ Bersoff/ Comer (1988), S. 1454.

^[121] Vgl. Pfleeger (2001), S. 57.

^[122] Vgl. Beyer/ Holtzblatt (1998), S. 29.

^[123] Vgl. Zuser et al. (2001), S. 49.

^[124] Vgl. Sommerville (2001), S. 59.

^[125] Vgl. Boehm (1988), S. 65.

^[126] Ebenda S. 65.

^[127] Vgl. ebenda S. 69.

^[128] Vgl. ebenda, S. 70.

^[129] Vgl. Zuser et al. (2001), S. 48-49; Kunstmann (1993), S. 96.

^[130] Vgl. Boehm (1988), S. 71.

^[131] Vgl. Sommerville (2001), S. 182.

^[132] Vgl. Taylor (2001).

^[133] Vgl. Taylor (2001).

^[134] Taylor (2001).

^[135] Vgl. ebenda.