risikomanagement beim softwareprojektmanagement v5 · risikomanagement beim...
TRANSCRIPT
Risikomanagement beim
Softwareprojektmanagement
Seminararbeit
Eingereicht bei: Univ.-Prof. Dr. Dr. habil. Horst Wildemann
Betreuer: Dipl. Ing. Franz Alt
von: Joachim Burkhardt
Studiengang MBA
2. Semester
Abgabetermin: 28. Juni 2004
- I -
Inhaltsverzeichnis
Inhaltsverzeichnis ................................................................................................... I
Abbildungsverzeichnis........................................................................................... II
Abkürzungsverzeichnis.......................................................................................... II
1 Einleitung ........................................................................................................1
2 Gründe für das Scheitern von Softwareprojekten ...........................................3
3 Risikomanagement bei der Softwareentwicklung...........................................7
3.1 Einführung ...............................................................................................7
3.2 Risikoidentifikation................................................................................10
3.3 Risikoanalyse .........................................................................................12
3.4 Risikoplanung ........................................................................................15
3.5 Risikoüberwachung................................................................................20
4 Spezielle Risiken beim Outsourcing von Softwareprojekten........................21
5 Zusammenfassung .........................................................................................24
Literaturverzeichnis ..............................................................................................III
- II -
Abbildungsverzeichnis
Abb. 1: Erfolgreiche und gescheiterte IT-Projekte.................................................4
Abb. 2: Projektrisikomanagement-Kreislauf. .........................................................8
Abb. 3: Das SEI Risikomanagement-Schema. .......................................................9
Abb. 4: Risikodokumentations-Formular .............................................................12
Abb. 5: Risikoportfolio .........................................................................................14
Abb. 6: Abhängigkeitsgraph von Risiken.............................................................15
Abb. 7: Risiko (R) nach Risikovermeidung (1), Risikoverminderung (2), … .....17
Abb. 8: Wirkungsmatrix zur Risikoplanung.........................................................19
Abkürzungsverzeichnis
ACM Association for Computing Machinery
AktG Aktiengesetz
IEEE Institute of Electrical and Electronics Engineers
KonTraG Gesetz zur Kontrolle und Transparenz im Unternehmensbereich
NIVADIS Niedersächsisches Vorgangsbearbeitungs-, Analyse-, Dokumentati-
ons- und Informationssystem
SEI Software Engineering Institute (at the Carnegie Mellon University)
USAF United States Air Force
- 1 -
1 Einleitung
In fast allen Bereichen der Wirtschaft spielt heute die Datenverarbeitung und
damit die Softwareentwicklung eine entscheidende Rolle. Nicht nur von Natur
aus sehr stark datenverarbeitungsgestützte Bereiche wie Banken und Versiche-
rungen, sonder auch klassische Industriebetriebe, sind heute auf die elektronische
Datenverarbeitung angewiesen. Softwarelösungen sind in viele Geschäftsprozes-
se sehr stark integriert, wie beispielsweise weltweit per Internet verfügbare Busi-
ness to Business Plattformen. Bei manchen Unternehmen hängt sogar das gesam-
te Vertriebsmodell von einer Online-Vertriebsplattform ab. Die eingesetzte Soft-
ware kann also maßgeblich zum Erfolg oder Misserfolg einer Unternehmung bei-
tragen und wird immer mehr zu einem entscheidenden Faktor. Trotz dieser ent-
scheidenden Stellung der Software, läuft die Softwareentwicklung heute oft noch
sehr unkontrolliert ab, wie verschiedene Studien über gescheiterte Softwarepro-
jekte zeigen.1 Prominente Beispiele für gescheiterte Softwareprojekte sind die
Finanzamt-Software „Fiskus“2 oder das Polizei-Computersystem NIVADIS.3
In dieser Arbeit soll zunächst aufgezeigt werden, welche Gründe für das Schei-
tern von Softwareprojekten verantwortlich sind und kurz etablierte Prozessmo-
delle zur Softwareentwicklung vorgestellt werden. Solche Prozessmodelle struk-
turieren den Entwicklungsprozess nach vorgegebenen Standards und ermögli-
chen die Installation von Risikomanagementsystemen zur proaktiven Behandlung
von Risiken. Ein proaktives Risikomanagementsystem reagiert nicht erst beim
Eintritt eines Risikos, sondern integriert den Umgang mit Risiken durch Vorbeu-
gende Maßnahmen, Notfallpläne und stetige Überwachung in den Entwicklungs-
prozess. Ein solchen Risikomanagementsystems kann aus den Bausteinen Risiko-
identifikation, Risikoanalyse, Risikoplanung und Risikoüberwachung bestehen,
welche in dieser Arbeit beschrieben werden.
1 Vgl. Gaulke (2001), S. 30f. 2 Vgl. Klesse (2004), [Stand 26.6.2004]. 3 Vlg. Mansmann (2004), [Stand 26.6.2004].
- 2 -
Um Kosten einzusparen, geht ein Trend bei der Softwareentwicklung heutzutage
zum Outsourcing von Entwicklungsprojekten. Besonders großes Einsparungspo-
tential verspricht man sich vom so genannten Offshore Outsourcing, d. h. der
Vergabe von Projekten an Outsourcing-Unternehmen in Länder mit sehr niedri-
gem Lohnniveau, die außerhalb des eigenen Kulturkreises liegen, wie Indien,
China oder Russland. Outsourcing und Offshore Outsourcing bergen zusätzliche
Risiken für ein Softwareprojekt, die in einem Risikomanagementsystem berück-
sichtigt werden müssen. Auf diese speziellen Risiken soll im letzten Abschnitt
der vorliegenden Arbeit eingegangen werden.
- 3 -
2 Gründe für das Scheitern von Softwareprojekten
Die Entwicklung von Software weist die typischen Eigenschaften eines Projektes
auf: große Bedeutung des Projektergebnisses, Einmaligkeit, zeitliche Befristung,
großer Umfang, Komplexität, Innovation, begrenzte Ressourcen (z. B. Budget
und Personal) und Risikobehaftung.4 Das Projektmanagement muss den Projekt-
ablauf so steuern, dass die vorgegebenen Ziele im Spannungsfeld von Ressour-
ceneinsatz, Zeit und Leistung bzw. Qualität erreicht werden. Im Unterschied zu
anderen Projekten ist das Ergebnis jedoch rein immateriell und erfordert große
kreative und schöpferische Leistungen. Der immaterielle Charakter von Software
erschwert hierbei eine genaue Überwachung des Projektfortschritts durch die
Projektleitung. Auch der Einsatz von sehr fortschrittlichen, oft unerprobten Tech-
nologien unterscheidet Softwareprojekte von anderen Projekten. Vor allem auf-
grund des kreativen Charakters der Softwareentwicklung, laufen Softwareprojek-
te oft ohne ausreichende Prozesskontrollen ab, obwohl der Umfang der Projekte
meist sehr erheblich ist. Indikatoren für unkontrolliert ablaufende Prozesse bei
der Softwareentwicklung sind:5
• Wiederauftauchen bereits korrigierter Fehler.
• Verlust von Source-Code.
• Fehlende Dokumentation von Programmveränderungen.
• Redundante Wartung und Entwicklung.
• Test und Integration von falschen (z. B. veralteten) Modulen.
Solche unkontrollierten Prozesse können letztendlich zum Scheitern von Soft-
wareprojekten oder zum Verfehlen von vorgegebenen Zielen führen. Von einem
gescheiterten Softwareprojekt spricht man, wenn das Projekt während der Ent-
wicklungszeit eingestellt wird oder die entwickelte Software nie eingesetzt wird.6
Von einem nur teilweise erfolgreichen Projekt ist die Rede, wenn eine Software
zwar fertig gestellt wurde und eingesetzt wird, jedoch die geplanten Ressourcen
4 Vgl. Gaulke (2002), S. 9f. 5 Vgl. Gaulke (2001), S. 40. 6 Vgl. The Standish Group International Inc. (2001), S 2.
- 4 -
überschritten, der Zeitplan nicht eingehalten oder weniger Funktionen implemen-
tiert wurden als geplant.
Die Unternehmensberatung The Standish Group untersucht seit 1994 in zweijäh-
rigem Rhythmus den Erfolg von IT-Projekten amerikanischer Unternehmen.7 Die
Daten aus Abb. 1 zeigen zwar, dass der Anteil an erfolgreichen Softwareprojek-
ten seit 1994 leicht gestiegen ist, jedoch immer noch weniger als ein drittel aller
Softwareprojekte als erfolgreich bezeichnet werden können. Der Anstieg der Er-
folgreichen Projekte ist deshalb auch mit Vorsicht zu genießen, da Projektmana-
ger aufgrund der schlechten Erfahrungen dazu neigen, die Projektkosten und -
zeiten zu überschätzen, um diese dann einhalten zu können.8
16%
27%
26%
28%
53%
33%
46%
49%
31%
40%
28%
23%
0% 20% 40% 60% 80% 100%
1994
1996
1998
2000
erfolgreich
eingeschränkter Erfolg
gescheitert
Abb. 1: Erfolgreiche und gescheiterte IT-Projekte, in Anlehnung an
The Standish Group International Inc., (2001), S 2.
Boehm hat eine Top Ten Liste der Risiken aufgestellt, die den Erfolg von Soft-
wareprojekten am meisten gefährden:9
1. Personalprobleme, z. B. mangelnde Qualifikation durch Neueinstellung,
Umschichtung oder mangelhafte Fortbildung
2. Unrealistische Pläne und Budgets, z. B. durch Unter-Preis-Angebote
wegen hohem Wettbewerbsdruck oder Nachverhandlungen
3. Entwickeln der falschen Funktionen und Eigenschaften, z. B. bei ei-
nem Online-Shop der mit unzureichender Kundenanalyse geplant wurde
7 Vgl. The Standish Group International Inc. (2001), S 1ff. 8 Vgl. ebenda, S 3. 9 Vgl. Boehm (1991), S. 32ff.
- 5 -
4. Entwickeln der falschen Benutzungsschnittstelle, z. B. komplizierte
Kommandozeile statt graphischer Oberfläche
5. „Goldverzierungen“, z. B. graphisch animierte Oberfläche
6. Ständiger Wechsel der Anforderungen, z. B. durch unzureichend ausge-
arbeitetes Pflichtenheft
7. Versagen externer Komponenten, z. B. Fehler des zugrunde liegenden
Betriebssystems
8. Versagen externer Aufträge, z. B. externer Lieferant für Datenbanklö-
sung geht in Konkurs
9. zu geringe Leistung pro Zeit, z. B. Überbelastung von Servern
10. Fehleinschätzung des Standes der Technik, z. B. Performance neu ent-
wickelter Datenbanktechnik wird überschätzt
Weitere Risiken, die den Projekterfolg gefährden können sind: Instabilität der
Entwicklungsplattform, Unzulänglichkeit der Infrastruktur, räumlich verteilte
Systementwicklung, unvertraute Entwicklungsmethodik, zu starre Regulatorien,
inadäquate bzw. unrealistische Teststrategie und Parallelarbeit der Entwickler.
Problematisch ist oft auch, dass Risiken und mögliche Unsicherheiten von den
Entwicklern zwar aufgedeckt werden, vom Management jedoch nur die positivs-
ten Schätzungen wahrgenommen werden und somit eine wirkungsvolle Bekämp-
fung verhindert wird.10
Zur Vermeidung unkontrolliert ablaufender Prozesse wurden zahlreiche Pro-
zessmodelle zur Softwareentwicklung entwickelt. Das erste solche Modell, das
auch den Einfluss von Risiken auf die Prozesse einbezieht, ist das Spiralmodell
von Boehm.11 Dieses Modell wird heute kaum in seiner ursprünglichen Form
angewandt, es existieren jedoch weit verbreitete Modelle wie das Wasserfallmo-
dell oder das in Deutschland oft angewandte V-Modell, die als erweiterte Imple-
mentierungen des Spiralmodells angesehen werden können.12 Die Anwendung
10 Vgl. Wiegers (1998), [Stand 26.6.2004]. 11 Vgl. Ould (1990), S. 32ff. 12 Vgl. Ould (1990), S. 38ff.
- 6 -
von etablierten Prozessmodellen als „best practice“ sichert strukturiert ablaufen-
de Prozesse.
Das Scheitern oder der nur teilweise Erfolg von Projekten können neben erhebli-
chen finanziellen Schäden auch weit reichende Imageschäden für die ausführen-
den Unternehmen haben. Ein Beispiel hierfür sind die am Mautsystem Toll Col-
lect beteiligten Firmen.
Um den Projekterfolg von Softwareprozessen zu sichern, ist deshalb in die durch
ein Softwareprozessmodell kontrollierten Prozesse ein Risikomanagementsystem
zu integrieren. Dies ermöglicht die frühzeitige Erkennung von Risiken und das
Ergreifung von entsprechenden Maßnahmen. Die Bausteine eines solchen Risi-
komanagementsystems sollen im folgenden Abschnitt dargestellt werden.
- 7 -
3 Risikomanagement bei der Softwareentwicklung
3.1 Einführung
Bei Finanzgeschäften spielen Risikomanagementsysteme schon seit langem eine
entscheidende Rolle. Die Methoden zur Risikobehandlung finden zunehmend
auch in allen anderen Unternehmensbereichen Einzug. Neben wirtschaftlichen
Gründen ist das Gesetz zur Kontrolle und Transparenz im Unternehmensbereich
(KonTraG) hierfür verantwortlich. Das KonTraG schreibt vor, dass „der Vor-
stand […] geeignete Maßnahmen zu treffen [hat], insbesondere ein Überwa-
chungssystem einzurichten, damit den Fortbestand der Gesellschaft gefährdende
Entwicklungen früh erkannt werden“.13
Ein Risiko ist ein Problem, das Auftreten kann, und bei dessen Auftritt Kosten
entstehen, einzelne Projektziele gefährdet werden oder sogar der gesamten Pro-
jekterfolg in Frage gestellt wird. Risiko berücksichtigt also vor allem zwei As-
pekte. Die Eintrittswahrscheinlichkeit eines Ereignisses und die (negative) Aus-
wirkung beim Eintritt des Ereignisses. Mann kann die Bedrohung durch ein Risi-
ko definieren als Produkt dieser beiden Faktoren:
Risikobedrohung = Eintrittswahrscheinlichkeit × Auswirkungen bei Eintritt.
Wichtig ist es, Risiken als potentiell auftretende Probleme von den aktuellen
Problemen eines Softwareprojekts zu unterscheiden, da beide Situationen unter-
schiedliche Handlungsweisen erfordern.14
Durch ein aktives Risikomanagement wird ein formelles, strukturiertes System
installiert, das es ermöglicht, die Risiken eines Projektes kontrollierbar zu ma-
chen. Ziel des Risikomanagements ist es dabei nicht, alle Risiken komplett aus-
zuschließen, sondern die Risiken berechenbar und überschaubar zu halten, denn
Risiken bedeuten auch immer Chancen für ein Unternehmen. Das Risikomana-
gementsystem soll sicherstellen, dass die Risiken, die ein Projekt am ernsthaftes- 13 § 91 Abs. 2 AktG. 14 Vgl. Wiegers (1998), [Stand 26.6.2004].
- 8 -
ten bedrohen, am stärksten überwacht und kontrolliert werden. Ein systemati-
sches Risikomanagement für alle Softwareprojekte eines Unternehmens verein-
facht durch eine einheitliche Dokumentation auch die Nutzung von Erfahrungen
aus vorangegangenen Projekten. So können Fehler, die in diesen Projekten be-
gangen wurden, vermieden werden und erfolgreiche Risikobehandlungsmaß-
nehmen erneut eingesetzt werden.
Für das Risikomanagement bei Softwareprojekten werden in der Literatur zahl-
reiche Vorgehensmodelle beschrieben. Die einzelnen Vorgehensschritte orientie-
ren sich zumeist an einer von Boehm eingeführte Einteilung.15 Boehm unterteilt
das Risikomanagement in Risikoeinschätzung und Risikokontrolle. Die Risiko-
einschätzung unterteilt sich weiter in Risikoidentifizierung, Risikoanalyse und
Risikopriorisierung. Die Risikokontrolle besteht aus Risikoplanung, Risikobe-
handlung und Risikoüberwachung.
Abb. 2: Projektrisikomanagement-Kreislauf, Gaulke, (2002), S.44.
Zur Implementierung von Risikomanagementsystemen in Softwareprojekten gibt
es zahlreiche aktuelle Modelle. Diese Modelle ordnen die Schritte nach Boehm
oder entsprechende Schritte meist in einem Managementkreislauf an, der wäh-
rend der gesamten Projektlaufzeit stetig durchlaufen wird. Dies ist nötig, da das
Risikomanagement keinen einmaligen Prozess zu Projektbeginn darstellt, son-
dern ständig auf sich verändernde und neu auftretende Risiken reagieren muss.
Abb. 2 zeigt beispielhaft einen solchen Managementkreislauf nach Gaulke,
15 Vgl. Boehm (1989), S. 2.
Projektrisiken erkennen
und beurteilen
Projektrisiken und
Maßnahmen überwachen
Projektkontrollen aufnehmen
und beurteilen
Verbleibende
Projektrisiken analysieren
Maßnahmen bewerten
und ergreifen
- 9 -
Abb. 3 zeigt den Kreislauf des SEI-Risikomanagement-Schemas.16 Ein weiteres
Risikomanagementmodell stellt die Riskit Methode der Universität von Mary-
land dar.17
Zentraler Punkt des SEI-Risikomanagement-Schemas ist die Kommunikation.
Nur wenn ein ausreichender und schneller Kommunikationsfluss zwischen allen
Projektbeteiligten besteht, kann das Risikomanagementsystem funktionieren, da
nur so alle Informationen über Risiken die Risikoverantwortlichen erreichen. Vor
allem für die in Abschnitt 3.5 beschriebene Risikoüberwachung ist die reibungs-
lose Kommunikation unerlässlich. Unterstützt werden kann die Kommunikation
durch ein standardisiertes, internes Berichtswesen.
Das Risikomanagement sollte von Personen koordiniert werden, die nicht direkt
am entsprechenden Projekt beteiligt sind. Dies ist nötig, da bei Personen, die am
Projekt beteiligt sind, stets die Gefahr der verzerrten Informationsweitergabe be-
steht. Vor allem negative Informationen werden nicht immer in vollem Umfang
weitergegeben.18
Abb. 3: Das SEI Risikomanagement-Schema, in Anlehnung an Carr et al, (1993), S. 4.
Auf die einzelnen weiteren Schritte eines Risikomanagementsystems soll nun im
Folgenden genauer eingegangen werden.
16 Vgl. Carr et al (1993), S. 4f. 17 Vgl. Kontio (1997), S. 1ff. 18 Vgl. Gaulke (2002), S. 47.
Kommunikation
Risikokontrolle
Risikoüberwachung
Risikoplanung
Risikoanalyse
Risikoidentifikation
- 10 -
3.2 Risikoidentifikation
Zunächst müssen die Risiken in einem Softwareprojekt identifiziert werden. Die
Risiken bei der Softwareprojektentwicklung lassen sich grob in zwei Klassen
einteilen: projektspezifische Risiken und allgemeine Risiken bei der Software-
entwicklung. Die projektspezifischen Risiken sind abhängig vom speziellen
Softwareprojekt und ergeben sich aus dessen spezifischen Eigenschaften. Sie
müssen von der Projektleitung durch Erfahrungsdatenbanken mit ähnlichen Pro-
jekten, Mitarbeiterworkshops wie Brainstorming oder genauer Analyse des Pro-
jektplanes entdeckt und festgelegt werden. Allgemeine Risiken bei der Software-
entwicklung sind Risiken, die bei jedem Softwareprojekt in unterschiedlich star-
ker Ausprägung auftreten können. Capers Jones hat ein Handbuch entwickelt,
das die 60 wichtigsten dieser Risiken auflistet und zu jedem Risiko detaillierte
Informationen und Checklisten liefert. Diese Informationen umfassen unter ande-
rem:19
1. Die Definition des Risikos
2. Die Ernsthaftigkeit
3. Die Eintrittshäufigkeit
4. Mögliche Bereiche des Auftritts
5. Anfälligkeit und Resistenz
6. Die Ursachen des Risikos
7. mit dem Risiko verbundene Probleme
8. Kosten bei Eintritt des Risikos
9. Vorbeugende Maßnahmen
10. Kontrollmaßnahmen
Jones gibt die Informationen zu jedem Risiko in Abhängigkeit der Art des Soft-
wareprojekts an. Hierzu teilt Jones Softwareprojekte in sechs Kategorien ein:20
1. Management-Informationssysteme
19 Vgl. Jones (1994), S. 46ff. 20 Vgl. ebenda, S. 28.
- 11 -
2. Systemsoftware
3. kommerzielle Software
4. militärische Software
5. für dritte entwickelte Software
6. vom Enduser entwickelte Software
Kritikpunkte an dieser Einteilung sind das Fehlen von wissenschaftlicher Soft-
ware und die Vermischung von Anwendungsbereich der Software und Hersteller
der Software in den Kategorien.
Eine weitere mögliche Technik zur Identifikation von Risiken ist die Verwen-
dung von Expertenwissen und standardisierten Fragebögen. Der Taxonomy-
Based Risk Identification Questionnaire des SEI stellt einen solchen Frageboden
dar, der es ermöglicht einen Großteil möglicher Risiken zu entdecken.21 Die Fra-
gen eines solchen Fragebogens sollten nicht nur einmal zu Beginn des Projekts
beantwortet werden, sondern in regelmäßigen Abständen während der Projekt-
laufzeit wiederholt werden. So werden auch neu auftretende Risiken rechtzeitig
identifiziert.
Der Taxonomy-Based Risk Identification Questionnaire gliedert die Risiken der
Softwareentwicklung in drei Hauptkategorien: Produktentwicklung, Entwick-
lungsumgebung und Produktvorgaben. Diese Hauptkategorien werden weiter
unterteilt, um die verschiedenen Risikoaspekte genauer einzugrenzen. Eine Frage
des SEI Fragebogens zur Entwicklungsumgebung lautet beispielsweise: „Are
there enough workstations and processing capacity for all staff?“22
Die anschließende Dokumentation der identifizierten Risiken ist entscheidend, da
die Dokumentation zur späteren Risikoüberwachung benötigt wird. Es hat sich
außerdem gezeigt, dass das Management schriftlich niedergelegten Risiken eine
höhere Aufmerksamkeit schenkt. Eine Möglichkeit zur Dokumentation ist ein
standardisiertes Risikodokumentations-Formular. Ein standardisiertes Dokumen-
21Vgl. Carr et al (1993): S. B-1ff. 22Ebenda: S. B-12.
- 12 -
tationsformular hat zudem den Vorteil der schnellen und einfachen Verständlich-
keit für alle Projektbeteiligten. Abb. 4 zeigt wie ein Formular zur Dokumentation
eines Risikos aussehen kann. Es enthält auch Informationen zur Risikoanalyse
und Risikoplanung, auf die in den Abschnitten 3.3 und 3.4 genauer eingegangen
wird.
Risiko #: laufende Nummer Klassifikation: Risikokate-gorie z. B. nach SEI
Datum: letztes Update des Formulars
Beschreibung: Beschreibung des Risikos mit Bedingung und Konsequenz des Risikos
Wahrscheinlichkeit: Wahr-scheinlichkeit, mit der das Risiko auftritt
Auswirkung: Auswirkung bei Eintritt des Risikos
Risikobedrohung: Produkt aus Wahrscheinlichkeit und Aus-wirkung
Frühwarnsignal: Signal, das möglichst früh den möglichen Eintritt des Risikos anzeigt
Verminderungsmaßnahmen: Maßnahmen, die zur Risikominderung ergriffen werden
Startdatum: Start der Maß-nahmen
Enddatum: geplante Beendi-gung der Maßnahmen
Verantwortlicher: Verantwort-licher für die Maßnahmen
Aktueller Stand: Aktueller Stand der Maßnahmen
Notfallplan: Aktionen, die im Falle des Eintritts ausgeführt werden sollen
Auslöser für Notfallplan: Signal, das den Notfallplan Auslöst
Abb. 4: Risikodokumentations-Formular,
in Anlehnung an Wiegers, (1998), [Stand 26.6.2004].
3.3 Risikoanalyse
Nach der Risikoidentifikation erfolg die Analyse der zuvor identifizierten Risi-
ken. Die Analyse der Risiken ist notwendig, um festzulegen, mit welcher Priori-
tät die einzelnen Risiken behandelt werden müssen. Hierzu müssen die einzelnen
Risiken bewertet werden.
Die Bewertung erfolgt in zwei Schritten: Zunächst wird die Wahrscheinlichkeit
für den Eintritt eines Risikos geschätzt. Ideal wäre es, jedem Risiko eine Wahr-
scheinlichkeit zwischen 0 und 1 zuzuordnen. Aufgrund der Natur der Risiken ist
eine solche quantitative Analyse jedoch nicht für alle Risiken möglich. Das Risi-
ko wird dann qualitativ geschätzt und einer Klasse zugeordnet. Das USAF Hand-
buch zur Risikobekämpfung schlägt hierzu beispielsweise die Zuordnung jedes
Risikos zu einer der Klassen sehr gering, gering, mittel, hoch und sehr hoch
- 13 -
vor.23 Die Kategorisierung erfolgt meist intuitiv und erfordert deshalb möglichst
große Erfahrung in der Einschätzung von Risiken. Die Einteilung sollte durch
Erfahrungen aus vorangegangenen Projekten und Wissensdatenbanken unter-
stützt werden.
Nach der Festlegung der Wahrscheinlichkeit wird die Auswirkung bei Eintritt
eines Risikos auf das Softwareprojekt untersucht. Wünschenswert wäre wieder
die quantitative Bewertung der Auswirkung jeden Risikos, z. B. auf einer Skala
von 1 bis 10 oder durch die entstehenden Kosten beim Eintritt. Ist dies nicht
möglich, so muss die Bewertung wieder durch Klassenbildung erfolgen. Das
USAF Handbuch kategorisiert hierzu jedes Risiko als unbedeutend, gering, kri-
tisch oder katastrophal.24 Der Eintritt eines Risikos kann sich in verschiedener
Hinsicht auf das Projekt auswirken. Mann kann hier zwischen Auswirkungen auf
die Kosten, die Funktionalität oder den Zeitplan unterscheiden.
Zur Ermittlung der Risikobewertung stehen heute auch zahlreiche computerge-
stützte Simulationstools wie zum Beispiel Palisade @RISK oder Crystal Ball zur
Verfügung.
Sind die Wahrscheinlichkeit für den Eintritt und die Auswirkung bei Eintritt für
alle Risiken festgelegt, so kann für jedes Risiko eine Gesamtbeurteilung vorge-
nommen werden. Eine Möglichkeit zu Ermittlung dieser Gesamtbeurteilung ist
die Erstellung eines Risikoportfolios. Dies ist für qualitativ und quantitativ be-
wertete Risiken möglich. Jedes Risiko wird hierzu in eine Auswir-
kung/Wahrscheinlichkeits-Matrix eingetragen. In Abb. 5 ist ein solches Risiko-
portfolie dargestellt.
Werden Eintrittswahrscheinlichkeit und Auswirkung jeweils durch einheitliche
Maßzahlen quantifiziert, so lässt sich zu jedem Risiko die Risikobedrohung be-
rechnen und dem Risiko als Gesamtbewertung zuordnen. Die Risiken können
dann nach absteigender Risikobedrohung sortiert werden.
23 Vgl. Pinkerton (1995), [Stand 26.6.2004]. 24 Vgl. ebenda (1995), [Stand 26.6.2004].
- 14 -
Abb. 5: Risikoportfolio
Bei der Bewertung eines Risikos ist auch die Auswirkung auf andere Risiken zu
beachten. Risiken können meist nicht isoliert betrachtet werden, denn es bestehen
Beziehungen zwischen den Risiken. So kann der Eintritt eines Risikos beispiels-
weise Auswirkung auf die Eintrittswahrscheinlichkeit anderer Risiken haben.
Risiken, die große Auswirkung auf viele andere Risiken haben müssen mit er-
höhter Priorität betrachtet werden und es müssen verstärkt Ressourcen zu deren
Abschwächung bereitgestellt werden. Zur Darstellung der Abhängigkeiten zwi-
schen verschiedenen Risiken eignet sich ein Graph, wie er in Abb. 6 beispielhaft
dargestellt ist. Durch jeden Pfeil wird dargestellt, dass Risiken aus einem Bereich
Auswirkungen auf einen anderen Bereich haben. Im diesem Beispiel wird nicht
die Abhängigkeit aller Risiken zueinander dargestellt, da diese oft zu komplex
sind, sonder die Abhängigkeit der Risiken aus bestimmten Risikokategorien auf
Risiken aus anderen Risikokategorien. Man erkennt aus dem Diagramm, dass
Risiken, die die Finanzierung betreffen, direkt oder indirekt auf alle anderen Ri-
siken Auswirkungen haben und deshalb mit hoher Priorität behandelt werden
müssen. Durch unterschiedlich dicke Pfeile wäre zusätzlich eine Kennzeichnung
der stärke der Abhängigkeiten möglich. Keil und Wallace haben in einer Studie
mit über 500 Softwareprojekten die Abhängigkeit zwischen Risiken aus den Be-
reichen Kundeneinbindung, Projektanforderungen und -ziele und Projektausfüh-
rung gezeigt.25
25 Keil; Wallace (2004), S. 73.
Wahrscheinlichkeit mittel gering
katastrophal
Auswirkung
kritisch
gering
unerheblich
hoch
hoch
gering
Risiko
- 15 -
Abb. 6: Abhängigkeitsgraph von Risiken
3.4 Risikoplanung
Nach Identifikation und Analyse der Risiken wird die Risikoplanung vorgenom-
men, die festlegt, wie die identifizierten Risiken zu behandeln sind. Da bereits
vor Eintritt eines Risikos Maßnahmen zu dessen Behandlung ergriffen werden
spricht man von einem proaktiven Risikomanagement. Die Risikoplanung legt
zum einen fest, wie im Vorhinein mit einem identifizierten Risiko umzugehen ist,
d. h. welche Handlungsschritte einzuleiten sind, um das Risiko beispielsweise zu
mindern oder zu vermeiden. Zum andern wird für die Risiken ein Notfallplan
entwickelt, d. h. eine konkrete Vorgehensweise, die bei Eintritt oder zu erwarten-
dem Eintritt des Risikos anzuwenden ist. Hierzu wird eine Anzahl an Risiken mit
der höchsten Gesamtbewertung für die Risikoplanung ausgewählt. Die Anzahl
der ausgewählten Risiken richtet sich dabei nach der Gesamtanzahl an identifi-
zierten Risiken und der durch sie ausgehenden Bedrohung. Für Risiken mit ge-
ringer Gesamtbewertung ist es nicht sinnvoll Ressourcen in die Risikoplanung zu
investieren.
Mögliche Vorgehensweisen zur Behandlung eines Risikos sind Risikovermei-
dung, Risikoverminderung, Risikobegrenzung, Risikoverlagerung und Risikoak-
zeptanz.26 26 Vgl. Gaulke (2002), S. 159.
Finanzierung
Organisation
Methoden
und Tools
Ressourcenzuwei-
sung
Projektpla-
nung
Schulung Systemleistung
Schnittstellen
- 16 -
Risikovermeidung
Die Risikovermeidung hat eine vollkommene Beseitigung von Risiken zum
Ziel.27 Dies ist möglich, indem das gesamte geplante Projekt nicht durchgeführt
oder in wesentlichen Punkten eingeschränkt wird. Risiken können ebenfalls ver-
mieden werden, indem auf den Einsatz neuer Technologien und Methoden ver-
zichtet wird. Da Risiken jedoch immer auch Chancen bieten, gehen dem Unter-
nehmen diese Chancen mit der kompletten Risikovermeidung verloren. Es muss
daher sorgfältig abgewogen werden, welche Risiken vollkommen vermieden
werden, da durch die Vermeidung auch Geschäfts- und Projektziele gefährdet
werden können.
Risikoverminderung
Maßnahmen zur Risikoverminderung sollen die Eintrittswahrscheinlichkeit für
ein Risiko im Vorhinein vermindern. Die Maßnahmen lassen sich in die folgen-
den Kategorien einteilen:28
• Korrektur von Projektplanung- und zielen
• Erhöhung der Produktivität
• Veränderung und Erhöhung der Ressourcen
• Neugestaltung der Projektstruktur und des Entwicklungsprozesses
Risikobegrenzung
Die Maßnahmen zur Risikobegrenzung haben die Verringerung des potentiellen
Schadens bei Eintritt eines Risikos zum Ziel. Dies kann geschehen durch den
Aufbau von Redundanzen, z. B. durch die Bearbeitung der gleichen Aufgabe
durch ein zweites Team, oder durch die Bereithaltung von Handlungsalternativen
für den Fall des Risikoeintritts.29 Da die Maßnahmen zur Risikoverminderung
zumeist sehr teuer sind, werden sie vor allem für sehr kritische Risiken angewen-
det.
27 Vgl. Gaulke (2002), S. 161. 28 Vgl. ebenda, S. 162. 29 Vgl. ebenda, S. 164.
- 17 -
Risikoverlagerung
Durch die Risikoverlagerung wird das Risiko auf Dritte übertragen. Denkbar ist
hierbei die Übertragung an Versicherungen oder Vertragspartner.30 Die Übertra-
gung an Versicherungen geschieht meist für Risiken mit zwar sehr geringer Ein-
trittswahrscheinlichkeit aber überproportional hohem Schaden bei Eintritt. Das
Risiko wird bei Risikoverlagerung nicht beseitigt, sondern lediglich die finanziel-
len Auswirkungen abgeschwächt. Nicht abgeschwächt werden kann durch die
Risikoverlagerung ein möglicher Imageverlust, der durch das Scheitern eines
Projektes eintreten kann.
Risikoakzeptanz
Eine letzte Möglichkeit der Risikobehandlung stellt die Risikoakzeptanz dar.
Hierbei wird keine der zuvor genannten Maßnahmen angewandt, sonder ein Ri-
siko bewusst in Kauf genommen. Zur Abfederung solcher in Kauf genommener
Risiken können im Projektplan geeignete zeitliche und finanzielle Puffer vorge-
sehen werden.
Die Abb. 7 zeigt, wie sich die Position eines Risikos (R) in einem Risikoportfo-
lio nach Anwendung einer Maßnahme zur Risikovermeidung (1), zur Risikover-
minderung (2), zur Risikobegrenzung (3) oder zur Risikoverlagerung (4) verän-
dern kann.
Abb. 7: Risiko (R) nach Risikovermeidung (1), Risikoverminderung (2),
Risikobegrenzung (3) und Risikoverlagerung (4)
30 Vgl. Gaulke (2002), S. 165.
Wahrscheinlichkeit gering
katastrophal
Auswirkung
unerheblich
hoch
R
1
2
3
4
- 18 -
Nach der Erstellung der Risikoplanung muss diese sorgfältig dokumentiert wer-
den, um eine exakte Umsetzung und Überwachung der Planung zu ermöglichen.
Eine solche Dokumentation sollte für jedes Risiko folgende Punkte enthalten:31
• Warum ist das Risiko wichtig?
• Welche Informationen werden benötigt, um das Risiko zu beobachten?
• Wer ist für das Risikomanagement verantwortlich?
• Welche Ressourcen werden für das Risikomanagement benötigt?
• Einen detaillierten Maßnahmenplan, der die festgelegten Präventiv- und
Notfallmaßnahmen beschreibt. Auch Gründe für die Verlagerung oder
Akzeptanz müssen hier dokumentiert werden.
• Wann soll der Plan umgesetzt werden?
Eine solche Dokumentation kann wieder mittels des in Abb. 4 aus Abschnitt 3.2
vorgestellten Risikodokumentationsformulars sichergestellt werden.
Die einzelnen Maßnahmen zur Risikobehandlung verursachen Kosten. Es dürfen
nur solche Maßnahmen in die Risikoplanung aufgenommen werden, deren Kos-
ten ihren Nutzen nicht übersteigen. Ein Maß für den Nutzen einer Maßnahme ist
durch folgende Formel gegeben:32
Bedrohung vor Maßnahme - Bedrohung nach MaßnahmeNutzenKosten für Maßnahme
=
Die Risikobedrohung ist hierbei in Kosten zu bewerten. Der Nutzen einer Maß-
nahme ist umso größer, je größer der berechnete Wert ist. Eine Maßnahme sollte
nur ausgeführt werden, wenn der Wert größer als eins ist, da anderenfalls die
Kosten für die Maßnahme die Reduzierung der Bedrohung übersteigen.
Maßnahmen zur Risikobehandlung können Auswirkungen auf mehrere Risiken
haben. In solchen Fällen muss eine geeignete Auswahl der Maßnahmen getroffen
werden. Diese Auswahl kann durch eine Wirkungsmatrix unterstütz werden, wie
31 Vgl. Pinkerton (1995), [Stand 26.6.2004]. 32 Vgl. Gaulke (2002), S. 163.
- 19 -
sie Abb. 8 zeigt.33 Die Felder der Matrix geben an, wie gut die einzelnen Risiken
(R1-R6) durch die möglichen Maßnahmen (M1-M4) behandelt werden können.
Der Wert 0 gibt dabei an, dass eine Maßnahme keine Auswirkung auf ein Risiko
hat, der Wert 3 gibt eine maximale Verminderung des Risikos durch die Maß-
nahme an. Die Aktivsumme (AS) gibt an, wie groß der Gesamteffekt einer Maß-
nahme ist, die Passivsumme (PS) gibt an, wie stark ein Risiko durch die Maß-
nahmen abgemildert werden kann. Im Beispiel hat die Maßnahme M1 den größ-
ten Gesamteffekt, und die Risiken R3 und R4 können durch die betrachteten
Maßnahmen am meisten abgeschwächt werden.
Die Wahrscheinlichkeit, dass eine geplante Risikobehandlungsmaßnahme nicht
den gewünschten Effekt erzielt, wird als Sekundärrisiko bezeichnet. Die Wahr-
scheinlichkeit, dass ein Risiko trotz funktionierender Maßnahmen Eintritt wird
als Restrisiko bezeichnet.
Beispiele für Risikobehandlungsmaßnahmen sind die Einstellung von sehr guten
Bewerbern unabhängig vom aktuellen Personalbedarf und der Vertragsschluss
mit Zeitarbeitsfirmen für plötzlich auftretenden Personalbedarf. Aufgaben in
Teams können mit Überschneidungen ausgelegt werden, um den Ausfall von
Mitarbeitern zu kompensieren. Auch die betriebliche Gesundheitsvorsorge kann
als Risikovorbeugende Maßnahme angesehen werden. Um dem Risiko sich än-
dernder Anforderungen vorzubeugen, kann vor der eigentlichen Implementierung
z. B. zunächst ein Prototyp erzeugt werden.
R1 R2 R3 R4 R5 R6 AS
M1 2 1 0 3 0 0 6
M2 0 0 3 0 0 1 5
M3 0 0 1 1 1 0 4
M4 0 0 0 0 1 0 1
PS 2 1 4 4 2 1
Abb. 8: Wirkungsmatrix für zur Risikoplanung
33 Vgl. Gaulke (2003), S. 160f.
- 20 -
3.5 Risikoüberwachung
Das Risikomanagement findet nicht nur zu Beginn des Softwareprojektes statt,
sondern währen der gesamten Projektlaufzeit muss eine Überwachung der Risi-
ken und Maßnahmen zur Risikobehandlung stattfinden. Die Überwachung um-
fasst die Beobachtung und Verfolgung aller identifizierten Risiken, die Identifi-
kation neu auftretender Risiken und die Überwachung der ergriffenen Maßnah-
men, um ihre Wirksamkeit zu prüfen.34
Zur Überwachung der Risiken müssen Indikatoren und Maßzahlen festgelegt
werden, durch deren Beobachtung der aktuelle Status eines Risikos ermittelt
werden kann und welche eine möglichst frühe Erkennung von kritischen Situati-
onen ermöglicht. Somit wird dem Management ermöglicht, gegebenenfalls
rechtzeitig gegensteuern zu können. Neben dem aktuellen Status muss auch die
Bewertung der Risiken überwacht und ggf. aktualisiert werden. So kann die Ein-
trittswahrscheinlichkeit eines Risikos mit zunehmender Projektdauer zum Bei-
spiel fallen, die Auswirkungen beim Eintritt des Risikos jedoch stark ansteigen.
Zusätzlich zur Überwachung der identifizierten Risiken muss das Projekt auch
ständig auf neu auftretende Risiken untersucht werden. Diese können z. B. bei
geänderten Anforderungen oder geänderten Prozessabläufen eintreten.
Neben den identifizierten Risiken werden ebenfalls die Risikoplanung und die
Maßnahmen überwacht. Diese Überwachung gibt Auskunft über Effektivität und
Effizienz des Risikoplans und ermöglicht somit unter Umständen eine Anpas-
sung von Risikoplan und Maßnahmen.
Die Risikoüberwachung – vor allem gegen Ende des Projektes – kann zusätzlich
wertvolle Daten über die Entwicklung der Indikatoren und die Auswirkungen der
gewählten Maßnahmen liefern. Diese Informationen sollten in einer Datenbank
gesammelt werden, um als Datenbasis für zukünftige Projekte zu dienen. Zur
Risikoüberwachung zählt auch die regelmäßige Berichterstattung über die Risi-
ken an die Unternehmensleitung.
34 Charette (1989), S. 249f.
- 21 -
4 Spezielle Risiken beim Outsourcing von Softwareprojekten
Viele Unternehmen aus Industrieländern lagern ihre Softwareentwicklung heute
in Länder wie Indien, Russland oder China aus, da in diesen Ländern die Soft-
wareentwickler einen Bruchteil vergleichbarer Entwickler in Europa, Japan oder
den USA kosten. Wenn sich die Unternehmen, an die die Softwareentwicklungs-
aufträge übertragen werden auf einem andern Kontinent, oder in einem andern
Kulturkreis befinden, spricht man auch von Offshore Outsourcing. Outsourcing
und speziell Offshore Outsourcing birgt neben den „normalen“ Risiken bei der
Softwareentwicklung zahlreiche weitere Risiken, die in ein Risikomanagement-
system eingebunden werden müssen, um ein Entwicklungsprojekt erfolgreich
outsourcen zu können. Risiken ergeben sich zum Beispiel aus unterschiedlichen
kulturellen Hintergründen und Arbeitsauffassungen. Besonders problematisch
kann hierbei die unterschiedliche Art und Weise der Kommunikation in den ver-
schiedenen Ländern sein. Im Folgenden sollen mögliche Risiken, die beim Out-
sourcing von Softwareprojekten, speziell auch beim Offshore Outsourcing, auf-
treten können beschrieben werden.
Sprachbarriere und Kommunikation
Eine der wichtigsten Voraussetzungen zur erfolgreichen Durchführung von Off-
shore Outsourcing Projekten ist eine gut funktionierende und stetige Kommuni-
kation zwischen den Vertragspartnern. Nur so ist es für den Auftraggeber mög-
lich ein effektives Überwachungs- und Risikomanagement zu installieren. Prob-
leme bei der Kommunikation können vor allem durch unterschiedliche Sprachen
entstehen. Es sollte für international ausgerichtete Unternehmen heute eigentlich
kein Problem darstellen, diese Kommunikation auf Englisch abzuwickeln. Ist
Englisch jedoch für beide Vertragspartner eine Fremdsprache, so kann es trotz-
dem zu Kommunikationsschwierigkeiten kommen. Dies ist auch daran zu sehen,
dass englischsprachige Firmen aus den USA oder England vor allem nach Indien
outsourcen, da die meisten indischen Entwickler sehr gut Englisch sprechen. Ein
weiteres Hindernis für die Kommunikation kann die oft nicht unerhebliche Zeit-
verschiebung zwischen den Sitzen der Vertragspartner sein. Diese macht eine
Kommunikation per Telefon oft sehr schwierig.
- 22 -
Kulturelle Unterschiede
Zwischen den Kulturen der Länder der beiden Vertragspartner können beträchtli-
che Unterschiede bestehen. Dies kann sich beispielsweise in sehr unterschiedli-
chen Arbeitsauffassungen und der Auslegung von Vertragsinhalten auswirken.
Beispiele für mögliche Konfliktfelder sind hier Termintreue oder die Art und
Weise der Kommunikation. Um Risiken aufgrund kultureller Unterschiede zu
vermeiden, kann ein Outsourcing-Partner in einem Land gewählt werden, das
sich in der Kultur möglichst wenig unterscheidet. Norwegische Firmen wählen
aus diesem Grund vorwiegend russische Partner für Outsourcing-Projekte. Japa-
nische Unternehmen harmonieren aufgrund der räumlichen und kulturellen Nähe
am besten mit chinesischen Outsourcing-Unternehmen.
Lieferung der gewünschten Funktionalität
Beim Outsourcing müssen die Anforderungen an die Funktionalität im Vorhinein
sehr genau festgelegt werden, damit die gelieferte Software auch den gewünsch-
ten Anforderungen entspricht. Problematisch kann dies werden, wenn die Ent-
wicklung die Kenntnisse der eigenen Anwenderkultur erfordern. Zur Verminde-
rung des Risikos kann in solchen fällen die Prototypenentwicklung eingesetzt
werden um beispielsweise die Anwenderschnittstelle bereits in einem frühen Sta-
dium festzulegen. Auch die Auswahl der Projekte ist für die Ausprägung diese
Risikos entscheidend. So können Teile eines Operationssystems leichter „kultur-
neutral“ spezifiziert werden als endkundennahe Anwendersoftware.35
Schutz von geistigem Eigentum
Beim Outsourcing besteht die Gefahr, dass Mitarbeiter des Outsourcing-
Unternehmens das geistige Eigentum des Auftraggebers, z. B. durch den Verkauf
an einen Konkurrenten, verletzen.36 Zur Vermeidung solcher Risiken mit beson-
ders gravierenden Auswirkungen sind die Gesetzte zum Schutz von geistigem
Eigentum im Land des Vertragspartners zu prüfen. Der Vertragspartner sollte
möglichst auch Vermögen und ein rechtlich belangbares Tochterunternehmen im 35 Vgl. Krishna (2004), S. 64. 36 Vgl. Fitzgerald (2003), [Stand 26.6.2004].
- 23 -
Land des Auftraggebers besitzen. Wichtig ist auch eine eingehende Kontrolle der
Sicherheitsmaßnahmen des Vertragspartners.
Know-How Verluste
Bei der Vergabe von Entwicklungstätigkeiten besteht für das outsourcende Un-
ternehmen immer die Gefahr des Verlustes von Know-How. Vor der Vergabe
von Softwareentwicklungsprojekten an externe Anbieter ist deshalb zu prüfen, ob
mit dem Projekt Know-How abgegeben wird, das für die strategischen Ziele des
Unternehmens von Bedeutung ist.
Weitere Risiken können beim Outsourcing beispielsweise durch unterschiedliche
Prozesse und Technologien, zusätzliche Überwachungskosten, Kommunikati-
onskosten, Reisekosten, versteckte Servicekosten, mangelhaften Service oder
schlechte Termintreue entstehen.
Die Auswahl, welche (Teil-)Projekte an Outsourcing Partner vergeben werden
sollen und an welche Partner sie vergeben werden sollen kann durch verschiede-
ne Portfolios unterstütz werden. Mögliche Portfolios bestehen aus Entwicklungs-
zyklus, geographischer Lage des Vertragspartners und Geschäftsprozess, den das
Projekt betrifft, oder Risiko der Auslagerung und erwartete Einsparungen. Zur
quantitativen Bewertung von Outsourcing-Vorhaben kann die Risk-Return-
Rating Methode (R3) dienen.37
Eine Übersicht über mögliche Länder für die Vergabe von Outsourcing Projekten
hat Stephanie Overby zusammengestellt.38 Die Übersicht gibt zu jedem Land un-
ter anderem Informationen über die Entwicklerkosten, die vorhandene Infrastruk-
tur, das geopolitische Risiko sowie mögliche Vor- und Nachteile des Outsour-
cings in dieses Land an. Als Beispiel für ein erfolgreiches Risikomanagement
können verschiedene große IT-Outsourcing-Projekte der Firma British Petroleum
betrachtet werden, welche detailliert veröffentlicht und diskutiert wurden.39
37 Vgl. Kleinhammer et al (2003), [Stand 26.6.2004]. 38 Vgl. Overby (2002), [Stand 26.6.2004]. 39 Vgl. Benoit et al (2000), S. 4ff.
- 24 -
5 Zusammenfassung
Trotz ausgefeilter Prozessmodelle für die Softwareentwicklung werden ein Groß-
teil der Softwareprojekte in Unternehmen heute nicht erfolgreich abgeschlossen.
Softwareprojekte nahmen jedoch eine immer entscheidendere Position in den
Unternehmen ein. Diese beiden Entwicklungen erfordern zusätzliche Maßnah-
men, die den erfolgreichen Abschluss von Softwareprojekten unterstützen. Durch
die Implementierung eines proaktiven Risikomanagementsystems wird diese Un-
terstützung gegeben und zusätzlich die gesetzliche Forderung nach Überwachung
geschäftswichtiger Prozesse erfüllt.
Hierzu wurden in der vorliegenden Arbeit die Risiken der Softwareentwicklung
analysiert und die grundlegenden Bausteine eines Risikomanagementsystems für
die Softwareentwicklung vorgestellt: Die Risikoidentifikation, die Risikoanalyse,
die Risikoplanung und die Risikoüberwachung.
Viele Unternehmen lagern ihre Softwareentwicklung heute aus, um so Kosten
einzusparen. Hierdurch entstehen neue Risiken, die in einem Risikomanagement-
system beachtet werden müssen. Diese Risiken entstehen vor allem durch die oft
sehr große räumliche Entfernung und kulturelle Unterschiede zwischen Auftrag-
geber und Auftragnehmer.
- III -
Literaturverzeichnis
Benoit, Aubert A.; Patry Michel; Rivard Suzanne; Smith Heather (2000): IT
Outsourcing Risk Management at British Petroleum, CIRCANO Scientific Se-
ries, Montréal, 2000.
Boehm, Barry W. (1989): Tutorial: Software Risk Management, Washington D.
C. (IEEE Computer Society Press), 1989.
Boehm, Barry W. (1991): Software Risk Management: Principles of Software
Engineering, in IEEE Software, Vol. 8, 1991, No.1, S. 32-41.
Carr, Marvin J. u. A. (1993): Taxonomy-Based Risk Identification, Software
Engineering Institute at Carnegie Mellon University, Pittsburgh, 1993.
Charette, Robert N. (1989): Software Engineering Risk Analysis and Manage-
ment, NewYork u. a. (Multiscene Press), 1989.
Fitzgerald, Michael (2003): At Risk Offshore ,in: CIO Magazine, 2003, elektro-
nisch veröffentlicht:
URL.: http://www.cio.com/archive/111503/offshore.html [Stand 26.6.2004].
Gaulke, Markus (2001): Risikomanagement bei Softwareentwicklung und -
einführung, in: KES – Zeitschrift für Kommunikations- und EDV-Sicherheit,
2001, Nr. 4, S. 40-42.
Gaulke, Markus (2002): Risikomanagement in IT-Projekten, München u. a. (Ol-
denbourg), 2002.
Jones, Capers (1994): Assessment and Control of Software Risks, Englewood
Cliffs (Yourdon Press), 1994.
Keil, Mark; Wallace, Linda (2004): Software Project Risks and their Effect on
Outcomes, in: Communications of the ACM, Vol. 47, 2004, No. 4, S. 68–73.
- IV -
Kleinhammer, Rod; Nelsen Todd; Warner AJ (2003): Balancing the Risk,
elektronisch veröffentlicht:
URL.: http://www.darwinmag.com/read/060103/risk.html [Stand 26.6.2004].
Klesse, Anne (2004): Finanzamt: Fiskus frisst Millionen, manager-magazin.de,
elektronisch veröffentlicht: URL.:
http://www.e-lo-go.de/html/modules.php?name=News&file=print&sid=5373
[Stand 26.6.2004].
Kontio, Jyrki (1997): The Riskit Method for Software Risk Management, Ver-
sion 1.00, Computer Science Technical Reports, Institute for Advanced Com-
puter Studies and Department of Computer Science, University of Maryland,
1997.
Krishna, S.; Sahay, Sundeep; Walsham, Geoff (2004): Managing Cross-
Cultural Issues in Global Software Outsourcing, in: Communication of the
ACM, Vol. 47, 2004, No. 4, S. 62-66.
Mansmann, Urs (2004): Vorläufiger Stopp für Polizei-Computersystem NIVA-
DIS, heise online, elektronisch veröffentlicht:
URL.: http://www.heise.de/newsticker/meldung/43744 [Stand 26.6.2004].
Ould, Martyn A. (1990): Strategies for Software Engineering, Chichester (John
Wiley), 1990.
Overby Stephanie (2002): A Buyer’s Guide to Offshore Outsourcing, CIO Ma-
gazine, 2002, elektronisch veröffentlicht:
URL.: http://www.cio.com/offshoremap/, [Stand 26.6.2004].
Pinkerton, Andrew (1995): Software Risk Management, elektronisch veröffent-
licht: URL.: http://www.eas.asu.edu/~riskmgmt/intro.html [Stand 26.6.2004].
- V -
The Standish Group International Inc. (Hrsg.) (2001): Extreme Chaos, elekt-
ronisch veröffentlicht: URL.:
http://www.standishgroup.com/sample_research/PDFpages/extreme_chaos.pdf
[Stand 27.6.2004].
Wiegers, Karl E. (1998): Know Your Enemy: Software Risk Management, in:
Software Development, Vol. 6, 1998, No. 10, elektronisch veröffentlicht:
URL.: http://www.processimpact.com/articles/risk_mgmt.html
[Stand 26.6.2004].
Ehrenwörtliche Erklärung
Ich erkläre hiermit ehrenwörtlich, dass ich die vorliegende Arbeit selbständig
angefertigt habe; die aus fremden Quellen direkt oder indirekt übernommenen
Gedanken sind als solche kenntlich gemacht.
Die Arbeit wurde bisher keiner anderen Prüfungsbehörde vorgelegt und auch
noch nicht veröffentlicht.
München, 28.6.2004