Baustein 23: Qualitative Risikoanalyse

1. Baustein 23:Qualitative Risikoanalyse

2. Inhalte des Bausteins • Qualitative Risikoanalyse: Charakterisierung • Qualitative Risikoanalyse: Überblick • Input • Werkzeuge und Techniken • Ergebnisse • Graphische Darstellungen • Top-Ten Risiken von Software-Entwicklungsprojekten • Empfehlungen zur qualitativen Risikoanalyse • Übung 3: Qualitative Risikoanalyse

3. Qualitative Risikoanalyse: Charakterisierung • Qualitative Risikoanalyse besteht darin, die Auswirkungen und die Wahrscheinlichkeit der identifizierten Risiken abzuschätzen.In diesem Prozess werden den Risiken Prioritäten zugeordnet entsprechend ihrer möglichen Auswirkung auf die Projektziele. • Qualitative Risikoanalyse sollte mehr als einmal während der Laufzeit des Projekts durchgeführt werden, um mögliche Veränderungen zu erfassen. • Qualitative Risikoanalyse kann zu weiteren Analysen im Prozess „Quantitative Risikoanalyse“ führen oder direkt zum Prozess „Entwickeln von Maßnahmen“.

4. Qualitative Risikoanalyse: Überblick • Input: • Risiko-Management-Plan • Identifizierte mögliche Risiken • Projektstatus • Projekttyp • Skalen zur Bewertung von Wahrscheinlichkeit und Auswirkungen • Werkzeuge und Techniken: • Risikowahrscheinlichkeit und -auswirkungen • Wahrscheinlichkeits-/Auswirkungs-Bewertungsmatrix • Analyse von Risikoauslösern (Trigger) • Analyse der Annahmen • Expertenschätzungen • S:PRIME Assessment • Ergebnisse: • Liste der priorisierten Risiken • Liste der Risiken, die weiter analysiert werden müssen • Auslöser (Symptome) für hohe oder mittlere Risiken • Graphische Darstellung der Risiken

5. Input: Projektstatus, Projekttyp • Projektstatus: • Die Unsicherheit eines Risikos hängt oft davon ab, in welcher Phase sich das Projekt befindet. • In den frühen Phasen des Projekts werden viele Risiken noch nicht sichtbar geworden sein, das Design ist noch nicht ausgereift und Änderungen werden wahrscheinlich sein. • Es ist deshalb wahrscheinlich dass weitere Risiken entdeckt werden. • Projekttyp: • Standardprojekte oder Projekte eines bekannten Typs sind einfacher hinsichtlich ihrer Risiken zu bewerten als sehr komplexe Projekte oder Projekte, in denen State of the Art Technology benutzt wird oder in denen etwas erstmalig zur Anwendung kommt.

6. Input: Skalen zur Bewertung von Wahrscheinlichkeit und Auswirkungen • Hier ist es nicht sinnvoll, zu genau sein zu wollen. Es wird in der Regel wohl kaum möglich sein zu entscheiden, ob ein Risiko eine Eintrittswahrscheinlichkeit von 80% oder 85% oder 90% hat. • Ebenso wird es im Allgemeinen sehr schwer sein, die genauen finanziellen Auswirkungen eines Risikos abzuschätzen, ohne unverhältnismäßig viel Aufwand zu treiben. • Deshalb werden folgende Skalen verwendet: • Auswirkung: Katastrophal, kritisch, marginal, vernachlässigbar • Wahrscheinlichkeit: Sehr wahrscheinlich = 0,9, wahrscheinlich = 0,5, unwahrscheinlich = 0,1.

7. Wahrschein- lichkeit Sehr wahrscheinlich Un- wahrscheinlich Wahrscheinlich Auswirkung 6 Hoch 5 Hoch Katastrophal 4 Mittel 5 Hoch 3 Mittel 4 Mittel Kritisch 3 Mittel 2 Niedrig 4 Mittel Marginal Vernach- lässigbar 1 Niedrig 2 Niedrig 3 Mittel Werkzeuge und Techniken: Wahrschein-lichkeits- Auswirkungsbewertungs Matrix • Die Risikowahrscheinlichkeit ist die Wahrscheinlichkeit, dass ein Risiko eintreten wird. • Die Risikoauswirkung ist der Effekt, den das Risiko auf die Ziele des Projekts haben würde.

8. Komponente Performanz Wartung Kosten Zeitplan Kategorie Performanz nicht erreichbar Katastrophal Software nicht wartbar Budget wird erheblich überzogen (>50%) Meilenstein nicht erreichbar Erhebliche Verzöge- rungen bei Software- änderungen Meilenstein erheblich verzögert (>30% Zeitverzug) Performanz stark beeinträchtigt Kritisch Budget wird deutlich überzogen (~30%) Geringe Verzöge- rungen bei Software- änderungen Meilenstein verzögert (>10% Zeitverzug) Marginal Performanz etwas beeinträchtigt Budget wird überzogen (~10%) Pufferzeiten - nicht auf dem kritischen Pfad- werden aufgezehrt Vernach- lässigbar Wartung ist umständlich Performanz kaumk beeinträchtigt Budgetpolster werden aufgezehrt Beispiel: Bewertung von Risiken

9. Werkzeuge und Techniken: Analyse von Risikoauslösern • Risikosymptome, manchmal auch Auslöser (Trigger) genannt, sind indirekte Manifestationen wirklicher Risikoereignisse. • Beispielsweise kann eine schlechte Arbeitsmoral im Projekt ein frühes Warnzeichen dafür sein, dass das Projekt vermutlich nicht rechtzeitig fertig wird. • Kostenüberschreitungen bei frühen Aktivitäten können ein Hinweis darauf sein, dass die Schätzung des Aufwands schlecht durchgeführt wurde. • Analysieren Sie deshalb alle Risiken, die mit „hoch“ oder „mittel“ in der Matrix bewertet wurden und versuchen Sie, Symptome zu identifizieren.

10. Werkzeuge und Techniken: Expertenschätzungen • Das Urteil von Experten kann oft alternativ oder zusätzlich zu formalen Methoden angewandt werden. • Beispielsweise könnten Experten die Eintrittswahrscheinlichkeit der Risikoereignisse mit „sehr wahrscheinlich“, „wahrscheinlich“ oder „unwahrscheinlich“ und die Bedeutung mit „katastrophal“, „kritisch“, „marginal“ oder „vernachlässigbar“ bewerten. • Expertenschätzungen sind oft sehr gut. • Nachteilig aber ist, dass nicht nachvollziehbar ist, wie der Experte zu seinem Urteil gekommen ist und dass sich dieses Wissen nicht auf Andere übertragen lässt.

11. Ergebnisse • Liste der priorisierten Risiken: • Die Risiken können nach Rangfolge (hoch, mittel, niedrig) oder danach priorisiert werden wie eilig es ist, Maßnahmen zu ergreifen. • Liste von Risiken, die weitere Analyse erfordern: • Risiken, die als „hoch“ oder „mittel“ eingestuft wurden, sind erste Kandidaten für eine quantitative Risikoanalyse. • Symptome: • Symptome für Risiken mit den Bewertungen „hoch“ und „mittel“ • Graphische Darstellung von Risiken: • Es gibt verschiedene Methoden, Risiken darzustellen (z. B. Radar-Diagramm oder Pareto-Diagramm) s. Folgefolien.

12. Graphische Darstellung: Radar-Diagramm

13. Graphische Darstellung: Pareto-Diagramm

14. Beispiele: Top Ten Risiken von Software-Entwicklungsprojekten • 1. Personelle Defizite • 2. Unrealistische Termin- und Kostenvorgaben • 3. Entwicklung von falschen Funktionen und Eigenschaften • 4. Entwicklung der falschen Benutzerschnittstelle • 5. Vergolden (über das Ziel hinaus schießen) • 6. Kontinuierliche Anforderungsänderungen • 7. Defizite bei extern gelieferten Komponenten • 8. Defizite bei extern erledigten Aufträgen • 9. Defizite in der Echtzeitleistung • 10. Überforderung der Software-Technik Quelle: H. Balzert, Lehrbuch der Software-Technik, Spektrum 1998

15. Empfehlungen zur qualitativen Risikoanalyse • Projekttyp 1: • Wählen Sie alle Risiken mit der Bewertung „hoch“ oder „mittel“ für die weitere Analyse aus (max 20). Analysieren und dokumentieren Sie Symptome für alle ausgewählten Risiken. • Projekttyp 2: • Wählen Sie alle Risiken mit der Bewertung „hoch“ oder „mittel“ für die weitere Analyse aus (max 15). Analysieren und dokumentieren Sie Symptome für alle ausgewählten Risiken. • Projekttyp 3: • Wählen Sie alle Risiken mit der Bewertung „hoch“ oder „mittel“ (max 10) aus gehen sofort zum Prozess „Entwickeln von Maßnahmen“. Analysieren und dokumentieren Sie Symptome für die ausgewählten Risiken. • Projekttyp 4: • Wählen Sie alle Risiken mit der Bewertung „hoch“ aus (max 5) und gehen direkt zum Prozess „Entwickeln von Maßnahmen“. Analysieren und dokumentieren Sie Symptome für alle ausgewählten Risiken.

16. Übung 3: Qualitative Risikoanalyse • Nehmen Sie die in Übung 2 erstellte Risikoliste und bewerten Sie alle Risiken hinsichtlich Wahrscheinlichkeit des Auftretens und Auswirkungen. • Ermitteln Sie dann an Hand der Wahrscheinlichkeits-Auswirkungsmatrix die Top Ten Risiken Ihres Projekts. • Ermitteln Sie mögliche Symptome für die Top Ten Risiken. • Präsentieren Sie das Ergebnis vor der Gruppe • Bewahren Sie die Ergebnisse für eine spätere Übung auf. Arbeit in Teams von 3 - 5 Personen Dauer 45 Minuten

17. Diskussion Qualitative Risikoanalyse