Risikomanagement in der Softwareentwicklung

Gliederung

Abkürzungsverzeichnis

Abbildungsverzeichnis

1 Einleitung
1.1 Ausgangssituation und Problemstellung
1.2 Zielsetzung der Arbeit
1.3 Thematische Abgrenzung
1.4 Vorgehensweise und Aufbau der Arbeit

2 Theoretische Grundlagen
2.1 Theoretische Grundlagen aus dem Bereich Softwareentwicklung
2.1.1 Software
2.1.2 Softwareentwicklung
2.2 Theoretische Grundlagen aus dem Bereich Risikomanagement
2.2.1 Risiko
2.2.2 Risikomanagement
2.3 Theoretische Grundlagen aus dem Bereich Qualitätssicherung
2.3.1 Qualität
2.3.2 Qualitätssicherung
2.4 Theoretische Grundlagen aus dem Bereich Projektmanagement (Ablaufplanung)
2.5 Projekt
2.6 Vorgehensmodell
2.7 Projektmanagement (Ablaufplanung)

3 Bestimmung und Beschreibung von Bewertungskriterien für ein effektives Risikomanagement
3.1 Effektivitätsdefinition
3.2 Ausgesuchte Bewertungskriterien
3.2.1 Adressierung der Top10-Risiken
3.2.2 Prozesseinbettung
3.2.3 Explizite Risikoorientierung
3.2.4 Zielorientierung
3.2.5 Stakeholderorientierung
3.2.6 Berücksichtigung situativer Faktoren

4 Ansätze aus dem Umfeld der Softwareentwicklung
4.1 Ansätze aus dem Bereich Risikomanagement
4.1.1 Das Software Risk Management-Rahmenwerk des SEI
4.1.1.1 TBRI - Taxonomy-Based Risk Identification
4.1.1.2 CRM - Continuous Risk Management
4.1.1.3 TRM - Team Risk Management
4.1.1.4 Bewertung
4.1.2 Das Riskit-Modell
4.1.2.1 Der Riskit Risikomanagementprozess
4.1.2.2 Der Riskit Analysis Graph
4.1.2.3 Die Risikit-Pareto-Ranking-Technik
4.1.2.4 Bewertung
4.2 Ansätze aus dem Bereich Qualitätssicherung
4.2.1 FTA - Fehlerbaumanalyse
4.2.1.1 Methodenbeschreibung
4.2.1.2 Bewertung
4.2.2 FMEA - Fehlermöglichkeits- und Einflussanalyse
4.2.2.1 Methodenbeschreibung
4.2.2.2 Bewertung
4.2.3 COQUALMO - Konstruktives Qualitätsmodell
4.2.3.1 Methodenbeschreibung
4.2.3.2 Bewertung
4.2.4 RBT - Risikobasiertes Testen
4.2.4.1 Methodenbeschreibung
4.2.4.2 Bewertung
4.3 Ansätze aus dem Bereich Projektmanagement (Ablaufplanung)
4.3.1 Das Spiralmodell
4.3.1.1 Methodenbeschreibung
4.3.1.2 Bewertung
4.3.2 Das SAIV-Prozessmodell
4.3.2.1 Methodenbeschreibung
4.3.2.2 Bewertung
4.4 Zusammenfassende Betrachtung der Bewertungsergebnisse

5 Gestaltungsempfehlungen
5.1 Für die Berücksichtigung situativer Faktoren
5.2 Für die Berücksichtigung zielorientierter Aspekte
5.3 Für die Berücksichtigung stakeholderorientierter Aspekte
5.4 Für eine risikoorientierte Softwareentwicklung

6 Zusammenfassung und Ausblick

Literaturverzeichnis

Anhang

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abbildung 1: Gründe für Risikomanagement in der Softwareentwicklung

Abbildung 2: Thematische Abgrenzung

Abbildung 3: Struktureller Aufbau der Arbeit

Abbildung 4: Der Prozess der Softwareentwicklung am Wasserfallmodell

Abbildung 5: Das Magische Dreieck des Projektmanagements

Abbildung 6: Die Top10-Risken von Softwareentwicklungsprojekten

Abbildung 7: Potentielle Ziele der Softwareentwicklung

Abbildung 8: Interne und externe Situationsfaktoren der Softwareentwicklung

Abbildung 9: Schema der Risikotaxonomie des TBRI-Ansatzes

Abbildung 10: Übersicht über den Riskit-Risikomanagementprozess

Abbildung 11: Stakeholder-Goal-Priority-Tabelle

Abbildung 12: Beispielszenario für ein Riskit Analysis Graph

Abbildung 13: Riskit-Pareto-Ranking-Tabelle

Abbildung 14: Beispielhafte Fehlerbaumstruktur

Abbildung 15: Anwendungsbeispiel des FMEA-Verfahrens

Abbildung 16: Grundidee des Defect Introduction and Removal Modells

Abbildung 17: Das COQUALMO-Modell

Abbildung 18: Beispiel einer Risk Exposure Berechnung für eine Funktion

Abbildung 19: Beispiel einer Risikokomponentenmatrix

Abbildung 20: Das Spiralmodell

Abbildung 21: Das SAIV-Prozessmodel

Abbildung 22: Zusammenfassende Bewertungsergebnisse

Abbildung 23: Durch Gestaltungsempfehlungen adressierte situative Faktoren

Abbildung 24: Qualitätsmerkmale nach ISO 9126

Abbildung 25: Beurteilungsskala für Fehlerfindungs- und -behebungsprofile

Abbildung 26: Beschreibung der Risikit-Prozesse

Abbildung 27: Einflussfaktoren von COCOMOII

1 Einleitung

1.1 Ausgangssituation und Problemstellung

In den letzten Jahrzehnten - besonders Ende des 20. Jahrhunderts, und Anfang des 21. Jahrhunderts - hat sich ein erhöhtes Interesse an Automation verschiedener Ak- tivitäten herausgestellt. Automation ist in seinem Kern abhängig von einwandfrei funktionsfähiger Software. Dabei hat die Komplexität der Softwareentwicklung über die letzen Jahre erheblich zugenommen. Berichte über Misserfolge von Projekten aus der Softwareindustrie sind nicht überraschend. Die Mehrzahl aller Projekte im Bereich der Softwareentwicklung erreichen ihre gesetzten Ziele nicht. So berichtet die US-amerikanische Fachzeitschrift "SD Times" auf Grundlage des "Chaos-Report" der Standish Group aus dem Jahr 2006, dass fast die Hälfte aller Softwareentwick- lungsprojekte mit Zeit- und Budgetüberschreitungen beendet werden. Knapp ein fünf- tel wird abgebrochen und nur ein Drittel aller Projekte kann erfolgreich abgeschlos- sen werden (siehe Abb. 1, linkes Diagramm). Dies ist sehr alarmierend.¹

McManus erkannte das 65% aller Projektmiseren durch managementbedingte Sachverhalte und 35% durch technische Sachverhalte begründet sind. Managementbedingte Sachverhalte beinhalten Probleme mit der Projektstruktur, Kommunikationskanälen, Projektressourcen, Planungsmethoden und unangemessenes Risikomanagement. Technische Sachverhalte beinhalten mangelndes Softwaredesign, die Nichteinhaltung der Softwareanforderungen, unangemessene technische Reviews, sowie fehlerhafte Entwicklung und Testmethoden.²

Es wird vermutet, dass das Management von Risiken zum Erfolg von Projekten ver- helfen kann. Dabei ist Risikomanagement an sich nichts Neues und in etlichen Nicht- Software-Bereichen seit mehreren Jahrzehnten etabliert. Das Risikomanagement in Softwarebereichen dagegen hat erst seit den Veröffentlichungen von Barry W.

Boehm und Robert N. Charette Ende der 80er Jahre an Bekanntheit und Akzeptanz gewonnen. Seit Anfang der 90er fungiert das Software Engineering Institute (SEI) der Carnegie Mellon University in Pittsburgh, Pennsylvania mit seinen jährlichen Konferenzen als Hauptforum zum Thema. Trotzdem ist das Risikomanagement in der Softwareentwicklung gegenwärtig eine noch zu entwickelnde Disziplin - sie wird nicht ausreichend verstanden und praktiziert.³

So wird gemäß einer Studie von Mohsen Rezagholi zum Verbreitungsstand des Risi- komanagements in Projekten der Softwareentwicklung aus dem Jahr 2007 lediglich in 9% aller Projekte professionelles Risikomanagement betrieben. In 38% aller Fälle bestehen Ansatzpunkte und in mehr als der Hälfte findet kein Risikomanagement statt (siehe Abb.1, rechtes Diagramm).⁴ Besonders unverständlich aus der Tatsache heraus, dass komplexe Softwareprojekte eine hohe Misserfolgsquote aufweisen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Gründe für Risikomanagement in der Softwareentwicklung⁵

Zudem ist das Volumen der Risikomanagementliteratur im Bereich der Softwareent- wicklung, verglichen mit der verfügbaren Risikomanagementliteratur in anderen Be- reichen (wie z.B. im Finanzsektor oder im Fertigungsbereich) begrenzt und das ob- wohl das Management von Risiken in Softwareentwicklung ein bedeutsames Thema ist, das Millionen von Geldern in Projekten bewahren kann. Vor allem vor dem Hin- tergrund, da jedes Jahr weltweit hunderte Milliarden Dollar für die Entwicklung von Software investiert werden und schon gegen Ende diesen Jahres die beträchtliche Schwelle von zwei Billionen Dollar für jährliche Softwareausgaben überschritten wird.⁶

Aufgrund des aktuellen Stands in Forschung und Praxis besteht somit ein hoher Nachholbedarf sich mit der Thematik des Risikomanagement in der Softwareentwicklung wissenschaftlich zu beschäftigen.

1.2 Zielsetzung der Arbeit

Während der letzten zwei Jahrzehnte wurden verschiedene Ansätze zum Thema Risikomanagement im Kontext der Softwareentwicklung entworfen und veröffentlicht. Diese gehen dabei auf verschiedene Schlüsselaspekte ein.

Deshalb beabsichtigt diese Diplomarbeit eine theoretische Lücke zu schließen, in- dem diese Ansätze aufgegriffen, systematisiert und bewertet werden, um ihre Beiträ- ge für ein effektives Risikomanagement für eine situative, risiko-, ziel-, und stakehol- derorientierte Softwareentwicklung festzustellen. Konkretisiert wird dieses Anliegen durch die drei nachfolgenden Forschungsfragen, die mit dieser Arbeit beantwortet werden sollen:

(1) Welche Methoden, Techniken und Heuristen gibt es im Umfeld der Software- entwicklung und was können Sie für ein effektives Risikomanagement beitra- gen?
(2) Wie können situative, ziel- und stakeholderorientierte Aspekte in der Soft- wareentwicklung berücksichtigt werden?
(3) Wie kann die Softwareentwicklung risikoorientiert durchgeführt werden?

Dabei bedingen die Forschungsfragestellungen (2) und (3) die Forschungsfrage (1). Es soll untersucht werden inwieweit, die in der Forschungsfrage (1) untersuchten Ansätze u.a. situative, ziel- und stakeholder- und risikoorientierte Aspekte enthalten. Bei Forschungsfrage (2) und (3) sollen auf den Ergebnissen von (1) aufbauend Gestaltungsempfehlungen in Form von Hypothesen abgeleitet werden.

1.3 Thematische Abgrenzung

Die nachstehende Erläuterung bezweckt den Betrachtungsgegenstand dieser Dip- lomarbeit thematisch in die betreffenden theoretischen Zusammenhänge einzugren- zen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Thematische Abgrenzung⁷

Abbildung 2 präsentiert die involvierten Themenbereiche. Sie bilden zugleich den Bezugsrahmen für die zu untersuchenden Methoden und Ansätze. Das Thema der Arbeit betreffend, werden in erster Linie Ansätze aus dem Bereich des Risikomana- gement der Softwareentwicklung betrachtet. Daneben fokussiert die Arbeit ferner auf Ansätze an den Schnittstellen des Risikomanagement zum Qualitäts- und Projekt- management der Softwareentwicklung. Verschiedene Modelle und Techniken aus diesen Schnittstellen finden deshalb in besonderem Maße Berücksichtigung. Damit grenzt die Diplomarbeit Ansätze ohne expliziten Risikobezug von der Thematik her ab.

Nachstehend erfolgt eine Eingrenzung von Ansätzen aus dem Bereich des Risikomanagement und seiner angesprochenen Schnittstellen:

Ansätze aus dem Risikomanagement: Diese Ansätze versuchen Risiken über den gesamten Softwarentwicklungsverlauf zu erfassen, analysieren und zu managen. In dieser Arbeit betrachtet werden klassische (Carr 1993; Higuera et al. 1994; Higuera/Haimes 1996) als auch neuere Ansätze (Kontio 1997, 1998, 2001).

Ansätze aus dem Qualitätsmanagement: Diese Ansätze adressieren verschiedene Softwarerisiken, wie z.B. Zuverlässigkeit und Effizienz. Betrachtet werden hier klassi- sche (Fehlerbaumanalyse; Fehlermöglichkeits- und Effektanalyse) als auch neuere Ansätze (Amland 1999; Bach 1999; Chualani 1997, 1999; Boehm/Huang 2006).

Ansätze aus dem Projektmanagement (Ablaufplanung): Diese Ansätze beschäftigen sich mit dem Prozessablauf der Softwareentwicklung. Betrachtet werden das „klassische“ Spiralmodell (Boehm 1989) und dessen weiterentwickelte Variante (Boehm et al. 2002), aufgrund ihrer risikoorientierten Charakteristik.

1.4 Vorgehensweise und Aufbau der Arbeit

Die nachfolgenden Ausführungen schaffen die Grundlage der Diplomarbeit in mehr- facher Hinsicht. Zuerst wird die wissenschaftliche Vorgehensweise vorgestellt, die der Lösungserarbeitung, der vorab beschrieben Zielsetzung (vgl. Abschnitt 1.2) zugrunde liegt. Danach wird der strukturelle Aufbau der Diplomarbeit beschrieben, auf dessen Basis sich die Zusammenhänge der nachfolgenden Kapitel beruhen.

Auf Grundlage umfangreicher Literaturanalyse werden im ersten Schritt Effektivitäts- kriterien für Forschungsfrage (1) aufgestellt. Die Aufstellung erfolgt unter Hinzuzie- hung diverser Theorien, wie z.B. Organisationstheorie und auf Grundlage empiri- scher Studien. Davon ausgehend werden im zweiten Schritt Methoden und Ansätze aus den involvierten Themenbereichen (vgl. Abschnitt 1.3) beschrieben und anhand der aufgestellten Kriterien bewertet. Anschließend werden die Bewertungsergebnisse bzw. Ausprägungen in einer Tabelle zusammengefasst und diskutiert. Ausgehend von den Ergebnissen bzw. Ausprägungen, der untersuchten Methoden und Ansätze werden für die Beantwortung der Forschungsfragen (2) und (3) Gestaltungsempfehlungen in Form von Hypothesen abgeleitet.

Der Aufbau der Arbeit orientiert sich am beschriebenen Vorgehen und an der, in Ka- pitel 1.3 beschriebenen, Einteilung in Risiko-, Qualitäts- und Projektmanagementan- sätzen. In Abbildung 3 ist die Kapitelstruktur dargestellt, die nachstehend eingehend erörtert wird.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Struktureller Aufbau der Arbeit⁸

[...]

¹ Vgl. Balzert (2000), S. 9f.; Misra et al. (2006), S. 196 und Rubinstein (2007), URL siehe Literaturver- zeichnis

² Vgl. McManus (2004), S. 1f.

³ Kontio (2001), S.32 und Misra et al. (2006), S. 196

⁴ Vgl. Rezagholi (2007a), S. 96f.

⁵ Linkes Diagramm in Anlehnung an den Standish Group Report 2006 (www.standishgroup.com), Studie mit ca. 10.000 Projekten pro Jahr, USA und außerhalb, Fortune 1000 Unternehmen und KMU, ca. 50% Neuentwicklungen. Vgl. Rubinstein (2007), URL siehe Literaturverzeichnis; rechtes Diagramm in Anlehnung an eine Studie von Mohsen Rezagholi aus dem Jahr 2007 mit 45 Projekten unterschiedlicher Projektgröße und -Typen aus den Jahren 1995-2004. Vgl. Rezagholi (2007a), S.96f.

⁶ Die Marktforschungsgesellschaft Gartner geht davon aus, dass die weltweiten Investitionen bzw. Ausgaben für Software von 1,77 Billionen Dollar (2007) auf 1,98 Billionen Dollar (2008) ansteigen werden. Vgl. Reder (2007), URL siehe Literaturverzeichnis

⁷ Eigene Darstellung in Anlehnung an Henrich (2002), S. 4

⁸ Eigene Darstellung