Risikomanagement im Software-Engineering

Lehrstuhl für Betriebswirtschaftslehre Prof. Wildeman Technische Universität München Dipl.-Kfm. Andreas Schramke TÜV Informatik Service GmbH Manfred Schneider Ulrike Villinger Günter Wilhelm Interdisziplinäres Projekt Informatik, Nebenfach Wirtschaftswissenschaften Risikomanagement im Software-Engineering Cao Cua Christian Pfaller Hemant Sharma 12. Dezember 2001

Inhalt 1 Einleitung... 3 2 Risikomanagement für Software-Engineering-Projekte... 4 2.1 Problemfelder des Software-Engineering... 4 2.2 Risikobegriff... 5 2.3 Festlegen des Risikomanagers... 5 2.4 Phasen des Risikomanagements... 5 2.5 Anwendung des Risikomanagement-Prozess... 6 3 Phasen des Risikomanagement-Prozess... 7 3.1 Phase 1: Risikoidentifikation... 7 3.1.1 Brainstorming... 8 3.1.2 Checkliste... 8 3.1.3 Analyse der Entscheidungsmotive... 12 3.1.4 Annahmenanalyse... 12 3.2 Phase 2: Risikoanalyse... 13 3.2.1 Eintrittswahrscheinlichkeit... 13 3.2.2 Grad der möglichen Auswirkung... 13 3.3 Phase 3: Festlegen der Prioritäten der Risiken... 14 3.3.1 Risikoprioritätszahl... 14 3.3.2 Risc Exposure-Zahl... 15 3.3.3 Risikoportfolio... 15 3.4 Phase 4: Maßnahmenplanung... 16 3.5 Phase 5. Risikoüberwachung und dokumentation... 18 3.5.1 Festlegung der Instanzen zur Überwachung Risiken:... 18 3.5.2 Vorgehensweise... 18 4 Zusammenfassung... 20 5 Literaturverzeichnis... 21 C. Cua, Ch. Pfaller, H. Sharma 12.12.2001 2

1 Einleitung Durch die ständig steigende Größe und Komplexität von Softwareprojekten besteht immer stärker die Gefahr, dass Projekte nicht im vorgesehenen Rahmen verwirklicht werden können. Oft fehlen im Software-Entwicklungsprozess strukturierte Vorgehensweisen welche eine frühzeitige Erkennung von Risiken, die den Projekterfolg beeinträchtigen könnten, ermöglichen würden. Aufgabe des interdisziplinären Projektes war es, eine Vorgehensweise für ein effektives Risikomanagement bei Software-Projekten zu entwickeln. Das Risikomanagement hat dabei die Zielsetzung im Rahmen eines kontinuierlichen und dynamischen Risikomanagement-Prozesses die Risiken eines Projekts zu identifizieren und die identifizierten Risiken zu beurteilen und geeignet zu limitieren. C. Cua, Ch. Pfaller, H. Sharma 12.12.2001 3

2 Risikomanagement für Software-Engineering-Projekte Risikomanagement wird in unterschiedlichen Bereichen angewendet. Neben der Anwendung im Projektmanagement gibt es zum Beispiel auch das Unternehmensrisikomanagement, welches die gesamten Geschäftsrisiken eines Unternehmens behandelt oder auch das technische Risikomanagement, welches die Zuverlässigkeit technischer Systeme (z. B. Atomkraftwerke) behandelt. Im folgenden wird eine Vorgehensweise für Risikomanagement beschrieben, welche zum Einsatz in Projekten des Software-Engineering vorgeschlagen wird. 2.1 Problemfelder des Software-Engineering Studien haben ergeben, dass die häufigsten Probleme bei Software-Engineering Projekten in folgenden Bereichen auftreten: 1. Personalprobleme 2. Unrealistische Zeit und- Budgetplanung 3. Entwickeln der falschen Softwarefunktionalität 4. Entwicklung einer mangelhaften Benutzerschnittstelle 5. Vergolden des Systems 6. Häufige Änderung der Anforderungen 7. Defizite extern bezogener Komponenten 8. Defizite extern ausgeführter Arbeiten 9. Leistungsdefizite in der Anwendung 10. Unzureichende Hard- und Softwaretechnologie Diese Problemfelder geben Aufschluss darüber, in welchen Gebieten auf eventuelle Risiken besonders zu achten ist. C. Cua, Ch. Pfaller, H. Sharma 12.12.2001 4

2.2 Risikobegriff Der Begriff Risiko kann wie folgt definiert werden: Ein Risiko ist ein Ereignis, von dem nicht sicher bekannt ist, ob es eintreten und/oder in welcher Höhe es einen Schaden verursachen wird. Es lässt sich aber eine Wahrscheinlichkeit für den Eintritt dieses Ereignisses (Risikowahrscheinlichkeit) und/oder für die Höhe des Schadens angeben. Die Angabe der Eintrittswahrscheinlichkeit und des möglichen Schadens muss dabei nicht exakt angegeben werden können. Für das Risikomanagement in Projekten ist im allgemeinen eine mehr oder weniger grobe Abschätzung ausreichend. Auch kann eine Schaden nicht immer in Geldeinheiten gemessen werden, sondern kann z. B. auch in erhöhten Zeitbedarf liegen. 2.3 Festlegen des Risikomanagers Verantwortlich für die Durchführung des Risikomanagements ist der Risikomanager. Dies ist in der Regel der Projektleiter selbst. In Ausnahmefällen, z. B. bei sehr großen Projekten oder falls der Projektleiter das Risikomanagement nicht selbst durchführen kann, kann es auch sinnvoll sein, eine andere geeignete Person als Risikomanager festzulegen. 2.4 Phasen des Risikomanagements Der vorgeschlagene Risikomanagement-Prozess wird in folgenden Teilphasen durchgeführt: 1. Risikoidentifikation 2. Risikoanalyse 3. Festlegen der Prioritäten der Risiken 4. Maßnahmenauswahl zur Begrenzung der Risiken 5. Risikoüberwachung C. Cua, Ch. Pfaller, H. Sharma 12.12.2001 5

2.5 Anwendung des Risikomanagement-Prozess Ein Risikomanagement ist grundsätzlich bei allen Projekten durchzuführen. Es ist auch bei kleinen Projekten sinnvoll, da sich dabei die Umsetzung der einzelnen Arbeitsschritte stark vereinfacht, da sie im wesentlichen vom Projektleiter (= Risikomanager) selbst durchgeführt werden. Die grundsätzlich Vorgehensweise bleibt jedoch die gleiche. Der Risikomanagement-Prozess soll erstmalig vor der Entscheidung über die Durchführung des Projekts oder vor der Erstellung eines Angebots angewendet werden. Im weiteren Projektverlauf soll der Risikomanagement-Prozess weiter regelmäßig angewendet werden, zumindest vor jeden Eintritt in eine neue Projektphase. Außerdem ist es sinnvoll, den Risikomanagement-Prozess auch in bestimmten zeitlichen Mindestintervallen anzuwenden, z. B. alle zwei Wochen. C. Cua, Ch. Pfaller, H. Sharma 12.12.2001 6

3 Phasen des Risikomanagement-Prozess Die fünf Phasen des Risikomanagements werden in diesem Abschnitt detailliert erklärt. 3.1 Phase 1: Risikoidentifikation Für das Risikomanagement kann man aus den unter 2.1 angegebenen Problemfeldern sieben Risikofelder ableiten, da es sinnvoll erscheint, den Punkt Nr. 2 in zwei getrennte Bereiche aufzuspalten und die Punkte 3 6 sowie 7 und 8 zu je einem Bereich zusammenfassen, da diese auf Problemen mit der Anforderungsspezifikation bzw. externer Stellen beruhen. Zusätzlich sollen auch Risiken im Geschäftlichen und kaufmännischen Bereich sowie Risiken des Umfelds betrachtet werden. Im Risikomanagement-Prozess sollen also diese neun Risikofelder berücksichtigt werden: Risiken hinsichtlich der personellen Ressourcen Risiken hinsichtlich der Zeitplanung Risiken hinsichtlich der Kosten und Leistungen Risiken hinsichtlich der Anforderungsspezifikation Risiken extern bezogener Komponenten und extern ausgeführter Arbeiten Anwendungsbezogene Risiken Technische Risiken Geschäftliche und kaufmännische Risiken Risiken des Umfelds Eventuell können in Sonderfällen auch weitre Risikofelder betrachtet werden. Im Formular Risikoidentifikation A. Risikofelder Übersicht werden die personellen Zuständigkeiten durchgeführt. Bei kleineren und mittleren Projekten wird der Risikomanager (Projektleiter) für das Risikomanagement in den meisten Risikofeldern sein. Eine Aufteilung der Verantwortlichkeiten ist nur bei großen Projekten sinnvoll. C. Cua, Ch. Pfaller, H. Sharma 12.12.2001 7

Zu jedem Risikofeld ist ein Arbeitskreis von beteiligten Personen festzulegen, welche zur Risikoidentifikation beitragen können. Dies können Projektmitarbeiter aber auch der Auftraggeber oder auch externe Berater sein. Entscheidend ist, dass die jeweiligen Personen zum Erkennen von Risiken in dem jeweiligen Risikofeld beitragen können. Ein Arbeitskreis sollte aber auch nicht aus mehr als etwa zehn Personen bestehen. Die Risikoidentifikation für die einzelnen Risikofelder wird mit Hilfe des Formulars Risikoidentifikation: B. Risikofeldbetrachtung durchgeführt. Dies erfolgt durch die vier Schritte Brainstorming, Checkliste, Analyse der Entscheidungsmotive, Annahmenanalyse. Die einzelnen Schritte sind im folgenden beschrieben. Hier können auch sofort Ideen für Handlungsoptionen festgehalten werden, welche dann später für die Maßnahmenauswahl herangezogen werden sollen. Absurde oder sehr konstruierte Risiken (minimalste Eintrittswahrscheinlichkeit und dabei nur schwer beeinflussbar) sollten nicht in der Risikoidentifikation erfasst werden, da diese den Risikomanagement-Prozess nur aufblähen würden. 3.1.1 Brainstorming Zunächst soll die Arbeitsgruppe offen überlegen und diskutieren, welche Risiken in dem jeweiligen Risikofeld möglich sind. 3.1.2 Checkliste Im nächsten Schritt werden die Fragen der Checkliste beantwortet. Kann eine Frage mit ja beantwortet werden, so ist kein Risiko zu erwarten. Andernfalls sollen die möglichen konkreten Risiken, welche zur Beantwortung mit nein führen, festgehalten werden. Für die einzelnen Risikofelder werden folgende Checklisten vorgeschlagen, welche gegebenenfalls auch um weitere Fragen erweitert werden können. Risiken hinsichtlich der personellen Ressourcen: Stehen die besten Mitarbeiter zur Verfügung? Sind für ALLE anspruchsvollen Aufgaben zuständige Mitarbeiter gefunden? Stehen genügend viele Mitarbeiter zur Verfügung? C. Cua, Ch. Pfaller, H. Sharma 12.12.2001 8

Passen Personen in Schlüsselpositionen zusammen? Haben Mitarbeiter realistische Erwartungen an ihre Aufgabe? Entsprechen sich Kompetenz und Aufgabe der Mitarbeiter? Stehen Mitarbeiter für die gesamte Projektdauer zur Verfügung? Stehen Mitarbeiter Vollzeit zur Verfügung? Erfüllen die Entwickler die nötigen Voraussetzung (Ausbildung, Schulungen, etc.)? Risiken hinsichtlich der Zeitplanung: Das Projektteam ist bereits eingespielt Die nötige Ausstattung (Hard- und Software) ist vorhanden Ein genauer Zeitplan (Meilenstein etc.) ist festgelegt Die Anforderungen sind klar spezifiziert Änderungen der Anforderungen sind eher nicht zu erwarten Die Komplexität des Projekts entspricht der früherer Projekte Risiken hinsichtlich der Kosten und Leistungen: Die Anforderungsspezifikation ist abgegrenzt und nicht zu komplex Die Hardware beschränkt die Funktionalität der Software nicht Es handelt sich um eine eigene Anwendung, ohne in andere Systeme eingebunden zu sein Die eingesetzten Techniken wurden bereits öfter verwendet Die Anforderungsspezifikation ist stabil, keine häufigen Änderungen zu erwarten Das Personal ist verfügbar, gut abgestimmt und hat die notwendigen Erfahrungen Wiederverwendete Software ist ohne wesentliche Veränderungen einsetzbar C. Cua, Ch. Pfaller, H. Sharma 12.12.2001 9

Die Rechte an wiederverwendeter Software sind bereits erworben Die Werkzeuge und Arbeitsplätze benötigen keine Veränderungen und sind Verfügbar Die Rechte an den Entwicklungswerkzeugen sind bereits erworben Risiken hinsichtlich der Anforderungsspezifikation: Wurde mit dem Auftraggeber bereits zusammengearbeitet? Hat der Auftraggeber eine genaue Vorstellung der Anforderungen und wurden diese schriftlich festgehalten? Ist der Auftraggeber bereit, die Anforderungen formal zu spezifizieren? Ist die Kommunikation mit dem Auftraggeber unproblematisch? Versteht der Auftraggeber die technische Komplexität des Projekts? Kennt der Auftraggeber den Software-Engineering Prozess? Ist die geforderte Funktionalität der Software klar und verstanden? Ist die geforderte Benutzerschnittstelle mit den Anwendern abgestimmt? Gibt es keine komplexen Funktionen und Komponenten, welche auch einfacher erstellt werden könnten? Sind keine häufigen Änderungen der Anforderungsspezifikation zu erwarten? Risiken extern bezogener Komponenten und extern ausgeführter Arbeiten: Müssen keine vom Auftraggeber gestellten Komponenten eingebunden werden? Entsprechen alle eingesetzten Werkzeuge der notwendigen Leistungsfähigkeit? Wurde extern bezogenen Komponenten ausführlich evaluiert, getestet? Sind die Zusagen der externen Stellen verlässlich? Richten sich die externen Stellen genau nach den Vorgaben? C. Cua, Ch. Pfaller, H. Sharma 12.12.2001 10

Bleibt der Überblick über das Gesamtprojekt erhalten? Anwendungsbezogene Risiken: Sind Mitarbeiter vorhanden die Erfahrung beim lösen von Performance Problemen haben? Sind Messverfahren der Performance während der Implementierung vorgesehen? Beinhaltet die Anforderungsspezifikation Performance Vorgaben? Sind die notwendigen Verfahren und Tools bekannt zum messen der Performance? Gibt es Korrekturpläne für den Fall von Performance Engpässen? Wurde nach möglichen Performance Engpässen gesucht? Technische Risiken: Ist ein Software-Projektmanagement und Prozessmanagement Tool verfügbar? Sind passende Werkzeuge für Systemanalyse und Design verfügbar? Sind die notwendigen Compiler, Debugger, Entwicklungsumgebungen verfügbar? Sind die Mitarbeiter für die eingesetzten Werkzeuge geschult? Sind Experten vor Ort, um Fragen zu den Tools zu beantworten? Sind die Hilfesysteme der Tools nützlich? Die eingesetzten Techniken haben sich bereits ausreichend bewährt? Schwierige Felder der Informatik, wie z. B. verteiltes Rechnen, künstliche Intelligenz werden nicht berührt Geschäftliche und kaufmännische Risiken: Die Vertragsgestaltung berücksichtigt ein Änderungsmanagement Für Projektpartner wären Alternativen möglich C. Cua, Ch. Pfaller, H. Sharma 12.12.2001 11

Der Umfang des Projektes ist nicht wesentlich größer als bei vergangenen Projekten Die Verträge sind rechtssicher Die Finanzierung notwendiger Investitionen ist sichergestellt Schadensersatzfälle bei Fehlfunktion des Produkts wurden beachtet Risiken des Umfelds: Die Anforderungen Mitbestimmungsgesetzes sind beachtet Relevante Gesetze, Vorschriften und Normen sind beachtet Eine Änderung relevanter gesetzlicher Vorschriften o. ä. ist nicht zu erwarten Notwendige Räume und Arbeitsplatzausstattung sind vorhanden Programmänderungen im Management des Auftraggebers sind nicht zu erwarten oder blieben ohne Auswirkungen auf das Projekt Es gibt keine "wichtigeren" Projekte die zeitgleich bearbeitet werden müssen Notwendige Veränderungsprozesse im Unternehmen sind erkannt und werden vom Top-Management unterstützt 3.1.3 Analyse der Entscheidungsmotive Hier sollen für das jeweilige Risikofeld die bereits vorgegebenen Entscheidungen a- nalysiert werden. Häufig wurden Entscheidungen getroffen, welche nicht unbedingt am Projekterfolg orientiert waren sondern aus unternehmenspolitischen, marketingbezogenen oder sonstigen Gründen gefällt wurden. Aus solchen Entscheidungen ergeben sich häufig Risiken, welche in diesem Punkt festgehalten werden sollen. 3.1.4 Annahmenanalyse Schließlich wird untersucht, ob die Annahmen, welche bereits getroffenen Entscheidungen zugrunde liegen, realistisch sind. Ist dies nicht der Fall, ergeben sich entsprechende Risiken. C. Cua, Ch. Pfaller, H. Sharma 12.12.2001 12

3.2 Phase 2: Risikoanalyse Zur Risikoanalyse muss der Risikomanager zunächst die, in der Risikoidentifikation erkannten, Risiken zusammenfassen, da in der vorhergehenden Phase manche Risiken wahrscheinlich mehrmals genannt wurden oder sich überschneiden. Anschließend erfolgt die Analyse der Risiken hinsichtlich Eintrittswahrscheinlichkeit und Grad der möglichen Auswirkung. Hierzu wird das Formular Risikoanalyse: Übersicht über die Risiken verwendet. Zu jedem identifizierten Risiko werden die Risikofelder, in denen sie gefunden wurden, angegeben. 3.2.1 Eintrittswahrscheinlichkeit Für die Bewertung der Eintrittswahrscheinlichkeit werden folgenden Bewertungskriterien vorgeschlagen: Eintrittswahrscheinlichkeit 1 unwahrscheinlich unter 10 % 2 wenig wahrscheinlich 10 % - 25 % 3 möglicherweise 25 % - 50 % 4 wahrscheinlich 50 % - 75 % 5 äußerst wahrscheinlich über 75 % Anstatt der Werte 1 bis 5 kann auch eine feinere Einteilung vorgenommen werden, zum Beispiel der Prozentwert. 3.2.2 Grad der möglichen Auswirkung Die Bewertung des möglichen Auswirkungsgrad kann anhand folgender Aufstellung vorgenommen werden: Grad möglicher Auswirkungen 1 unerheblich keine Einschränkung der techn. Performance Budget muss möglicherweise nicht vollständig ausge- C. Cua, Ch. Pfaller, H. Sharma 12.12.2001 13

Budget muss möglicherweise nicht vollständig ausgeschöpft werden früher Fertigstellungszeitpunkt erreichbar 2 gering minimale oder kleine Einschränkungen der techn. Performance finanzielle Ressourcen reichen aus Zeitplan bleibt realistisch und erreichbar 3 kritisch einige Einschränkungen der techn. Performance leichte Knappheit der finanziellen Mittel, mögliche Budgetüberschreitung Verzögerung im Zeitplan möglich 4 katastrophal gravierende Einschränkung der techn. Performance gravierende Finanzknappheit, Budgetüberschreitung wahrscheinlich Zeitplan nicht mehr möglich Auch hier kann eine feinere Einteilung vorgenommen werden, z. B. unerheblich = 1 10, gering = 11 bis 20, usw. Die Risikoanalyse führt der Risikomanager, gegebenenfalls in Rücksprache mit den jeweils beteiligten Arbeitskreis durch. 3.3 Phase 3: Festlegen der Prioritäten der Risiken Nach der vorhergehenden Phase hat der Risikomanager nun eine Liste der Risiken mit ihren Eintrittswahrscheinlichkeiten und ihrem Auswirkungsgrad vorliegen. Diese müssen nun nach ihrer Wichtigkeit bzw. Relevanz für das Projekt in Reihenfolge gebracht werden, was auf 2 Arten geschehen kann: 3.3.1 Risikoprioritätszahl Dazu wird die sog. Risikoprioritätszahl RPZ berechnet: C. Cua, Ch. Pfaller, H. Sharma 12.12.2001 14

RPZ = Eintrittswahrscheinlichkeit(Risiko) * Auswirkung(Risiko) Die Eintrittswahrscheinlichkeit und Auswirkung des Risikos wurden in der vorhergehenden Phase ermittelt. Nun werden die Risiken entsprechend der RPZ (mit der größten beginnend) geordnet und man kann mit der Maßnahmenplanung bei der ersten anfangen (Phase4). 3.3.2 Risc Exposure-Zahl Eine weitere Möglichkeit die Risiken zu bewerten und in eine Reihenfolge zu bringen ist folgende: Man berechnet die sogenannte RE-Zahl (RE = Risc Exposure): RE = Wahrsch(UO) * Verlust(UO) Wahrsch(UO) = Wahrscheinlichkeit für nicht zufriedenstellendes Ergebnis (z. B. durch Softwarefehler) Verlust(UO) = Verlust in Geldeinheiten, der durch Fehler entsteht Wahrsch(UO) ergibt sich dabei aus der vorherigen Phase und Verlust(UO) muss geschätzt werden. Wenn man die RE-Zahl für alle Risiken berechnet hat, so kann man die Risiken entsprechend der RE (mit der größten beginnend) ordnen und mit der Maßnahmenplanung bei der ersten anfangen (Phase 4). 3.3.3 Risikoportfolio Aus den Daten der Risikoanalyse kann auch ein Risikoportfolio hinsichtlich Eintrittswahrscheinlichkeit und Auswirkungsgrad erstellt werden. Vorrangig sollten dabei die Risiken rechts und oben behandelt werden. C. Cua, Ch. Pfaller, H. Sharma 12.12.2001 15

Risikoportfolio 5 risiko a risiko b Grad möglicher Auswirkungen 4 3 2 1 2 niedrigere Priorität 1 3 12 20 hohe Priorität 12 risiko c risiko d risiko e risiko f risiko g 2,5 0 0 1 2 3 4 5 6 Eintrittswahrscheinlichkeit 3.4 Phase 4: Maßnahmenplanung Die notwendigen Maßnahmen zur Abwehr eines Risikos werden meist schon bei dess Identifikation klar, zum Beispiel durch die Checklisten-Fragen. Auch kann man sich bei der Maßnahmenplanung an den festgestellten Problemfeldern orientieren, in welche die Risiken fallen können. Folgende Maßnahmen können für die einzelnen Felder beispielhaft ausgemacht werden: Personalprobleme: Teams bilden moralische Festigung übergreifende Ausbildung Unrealistische Zeit- und Budgetplanung: Detaillierte Schätzungen dies betreffend Wiederverwendung von Software Anforderungen überdenken C. Cua, Ch. Pfaller, H. Sharma 12.12.2001 16

Probleme der Anforderungsspezifikation Analyse der Organisation Analyse der Aufgabe(n), Kundenbefragung Defizite extern bezogener Komponenten Benchmarking Inspektionen Referenzen prüfen Kompatibilität analysieren Defizite extern ausgeführter Arbeiten Referenzen prüfen Teams bilden Verträge überarbeiten Leistungsdefizite in der Anwendung: Simulation Benchmarking Modelle Informatik Fähigkeiten an den Grenzen: Technische Analyse Kostennutzen Analyse Referenzen prüfen Unzureichende Hard- und Softwaretechnologie: Technische Analyse C. Cua, Ch. Pfaller, H. Sharma 12.12.2001 17

Kostennutzen Analyse Referenzen prüfen Wichtig hierbei ist, dass man Liste der Risiken nach einem bestimmten Zeitraum auffrischt, immer nachdem Maßnahmen ausgeführt wurden. Die Maßnahmen zu den Risiken, sowie die Verantwortlichen für deren Umsetzung, werden auf den Formular Maßnahmenplan festgehalten. 3.5 Phase 5. Risikoüberwachung und dokumentation 3.5.1 Festlegung der Instanzen zur Überwachung Risiken: Eng verbunden mit der Risikosteuerung ist die Überwachung und Dokumentation der Risiken. Ihre systematische Überwachung kann durch ein regelmäßiges Risikoreporting im Unternehmen verankert werden, was nicht zuletzt in die Darstellung der Risiken der künftigen Entwicklung im Lagebericht mündet. Als Initialisierungsaufwand für diesen Prozess ist zu klären, wer welche Risikopositionen berichtet bekommt. Dies ergibt sich logisch aus den Verantwortungslimiten der Führungskräfte: Derjenige, der die Risiken verantworten muss, ist Berichtsempfänger. 3.5.2 Vorgehensweise Ziel der Risikoüberwachung ist es, dass tatsächliche und gewünschte Risikolage sich entsprechen und Risikoänderungen kontinuierlich erfasst und kommuniziert werden. Soll-Ist-Vergleiche: Durch Soll-Ist-Vergleiche und Abweichungsanalysen können Ursachen ermittelt und Konsequenzen gezogen werden. Dabei ist auf die Funktionstüchtigkeit des Risikomanagementsystems als auch der Unternehmensprozesse zu achten. Sofortige Meldung bei Limitüberschreitungen Eventuell auftretende Limitüberschreitungen müssen sofort gemeldet und Steuermaßnahmen ergriffen oder ergänzt werden. Auch die Wirksamkeit der getroffenen Maßnahmen muss überwacht werden. Interne Kontrollsysteme C. Cua, Ch. Pfaller, H. Sharma 12.12.2001 18

Bestandteil der Risikoüberwachung sind auch die Interne Kontrollsysteme. Diese überwachen die Risiken und das Risikomanagement. Maßstab sind die Wirksamkeit, Angemessenheit und Effizienz der eingeleiteten Maßnahmen. Schwachstellen werden analysiert, organisatorische und inhaltliche Änderung passen das System veränderten Risikosituationen an. C. Cua, Ch. Pfaller, H. Sharma 12.12.2001 19

4 Zusammenfassung Beim Risikomanagement im Software-Engineering handelt es sich im allgemeinen um einen kreativen und kontinuierlichen Prozess. Dieser Prozess gliedert sich in fünf verschieden Prozessphasen zur Identifikation und Analyse der Risiken, zum setzten der Prioritäten der Risiken, zur Auswahl der Gegenmaßnahmen und zur Überwachung der Minimierung der Risiken. Diese Phasen werden während des Projekts wiederholt angewendet. Im Idealfall stellt das Risikomanagement sogar die Grundlage des Entwicklungsprozesses dar. Hauptverantwortlicher für das Risikomanagement bleibt meist der Projektleiter als Risikomanager. Allgemein soll der vorgeschlagene Prozess keine starre Vorschrift sondern offen und flexibel für künftige Erweiterungen sein. C. Cua, Ch. Pfaller, H. Sharma 12.12.2001 20

5 Literaturverzeichnis B. Boehm: Software Risk Management. IEEE Computer Society Press, Los Alamitos, Second Printing 1993. Controlling Innovations Center, Dortmund: Risikomanagement W. Gleißner: Ratschläge für ein leistungsfähiges Risikomanagement. WIMA Gesellschaft für angewandte Betriebswirtschaft mbh, Leinenfelden-Echterdingen G. Göbels, U. Schnarrenberg: Risikomanagement in Projekten. Methoden und ihre praktische Anwendung. Braunschweig-Wiesbaden 1997 R. Higuera, Y. Haimes: Software Risk Management. Software Engineering Institute, Carnegie Mellon University, Pittsburgh, 1996 KPMG: Integriertes Risikomanagement. Berlin, 1998 G. Lichtenberg: Risikomanagement bei EDV-Projekten. Technische und vertragliche Aspekte. expert verlag, Ehningen, 1992 R. Paulic, A. Starke: Rechnergestützte Fehlermöglichkeits- und Einflußanalyse (FMEA). Methodik und Softwaremarkt. Peter Lang Verlag, Frankfurt am Main, 1994 I. Sommerville: Software Engineering. Addison-Wesley, Harlow, Sixth Edition 2001 C. Cua, Ch. Pfaller, H. Sharma 12.12.2001 21