Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE 3.2 Qualitätsmanagement Folie 1LM 14 Risikomanagement Risikomanagement Inhalt Ziele

Universität Stuttgart

Institut für Kernenergetik und Energiesysteme

LE 3.2 Qualitätsmanagement LM 14 Risikomanagement Folie 1

Prüffeldbewertung

0,00,5

1,0

1,5

2,0

2,53,0

3,5

4,0

4,5

5,0Projektstellung

Angebotslage

Projektplanung / -Controlling

Personalsituation / Staffing

/ Projektgründung

Technisches Umfeld

Kunden Umfeld

NebenaufwändeEinarbeitung etc.

Qualitätssicherung

Leistungsstand der Entwicklung

Finanzen

Bewertung

MaxWert

Normalbereich

Risikogrenze

Risikomanagement

Inhalt

• Ziele und Motivation

• Strategisches und Operatives Risiko-Management

• Der Risiko-Management Prozess

• Top 10 Risiken in SW-Projekten

• Erfahrungen




Motivation

Mit jedem IT Projekt ist das Risiko des Scheiterns verbunden. Gründe sind:

• Steigende Komplexität der Systeme

• Mangelndes Verständnis des Projektes

• Falsche Einschätzung der eigenen Möglichkeiten

Wir haben im Teil Prozessqualität Vorgangsmodelle kennen gelernt, mit denen

versucht wird, die Komplexität zu beherrschen. Im Teil Produktqualität wurden

Verfahren vermittelt, Qualität zu benennen und Qualitätsmängel frühzeitig

aufzudecken. In dieser Einheit wird Risikomanagement als ein Verfahren

eingeführt, mit dem man festlegen kann, mit welchen Teilen eines Projektes

begonnen werden sollte (iteratives Vorgehen) und auf welche Indikatoren

besonders geachtet werden muss.




Risikomanagement

Verwendete Lernobjekte

LO2: Ziele und Motivation

LO3: Strategisches und Operatives Risiko-Management

LO4: Der Risiko-Management Prozess

LO5: Top 10 Risiken in SW-Projekten

LO6: Erfahrungen

LO7: Zusammenfassung/Abspann

LO8: Tests

LO9: Definitionen




Das sollten Sie heute lernen

• Risikomanagement versucht die Auswirkungen heutiger Entscheidungen auf die Zukunft abzuschätzen. Es verbessert die Wahrscheinlichkeit, die Softwareprodukte dem Kunden mit den richtigen Inhalten in der geforderten Qualität und im geplanten Budget zu liefern. Alle Risiken haben Einfluss auf 3 elementare Risiko-Elemente:

Zeitrahmen Kostenrahmen Funktionalität/Qualität

• Es werden Verfahren zur Minimierung dieser Risiken vorgestellt




LE 3.2 - LM 14 - LO2

Ziele und Motivation




Risikoanalyse in der Kerntechnik

• In der Kerntechnik werden probabilistische Risikoanalysenüber Fehlerbaum- und Ereignisbaumanalysen durchgeführt.

• Ein Fehlerbaum ist die graphische Umsetzung einer boolschen Funktion: ein Zustand kann vorkommen oder nicht. Zustände werden über die Operatoren UND und ODER verknüpft. Ausgang ist ein unerwünschter Systemzustand, dessen Ursachen deduktiv bestimmt werden.Endpunkte sind Basisereignisse, für deren Eintreten Wahrscheinlichkeiten angegeben werden können.

• Ein Ereignisbaum fragt induktiv nach den Folgen eines unerwünschten Ereignisses. Systeme reagieren auf diese Ereignisse mit Zustandsänderungen,deren Folgen ebenfalls bestimmt werden können. So erhält man Kausalketten, die in Endzustände münden, die vom Analytiker daraufhin untersucht werden müssen, ob sie unerwünscht sind und wenn ja, wie die Wahrscheinlichkeit ihres Eintretens weiter reduziert werden kann.




Ziele und Motivation des Risiko-Managements

• Ziel für Risiko-Management gemäß des CMM (Integrated Software Management, CMM L3):

– Die Risiken des Software-Projekts werden anhand einer dokumentierten Prozedur identifiziert, ausgewertet, dokumentiert, und behandelt.

• Motivation:

– Erhöhe die Fähigkeit, Chancen unmittelbar zu ergreifen

– Erkenne mögliche Bedrohungen und lerne, Sie zu behandeln

– Identifiziere und bewerte verschiedene Handlungsalternativen

– Reduziere Gefahrenpotentiale und plane Alternativ-Lösungen




Motivation




Risikoabschätzung, -analyse und -

bewertungals RSZ-analytisches

Gesamtkonzept




LE 3.2 - LM 14 - LO3

Strategisches und Operatives Risiko-Management




Es gibt viele Arten von Risiken

• Operative Risiken

– Tägliche Unsicherheiten eines Projekts

• Strategische Risiken

– Langfristige Einwirkungen auf das Unternehmen

• Technologie-Risiken

– Einfluss von Technologie und deren Anpassung in einem Projekt

• Wirtschaftliche Risiken

– Verfügbarkeit von Ressourcen, Budget, Kunde, etc.

• Industrielle Risiken

– Entwicklungsprozess, Werkzeuge, etc.

• Implementierungs-Risiken

– Konkrete Implementierung der Software




Strategisches und Operatives Risiko-Management

• Allgemein

– Abschätzung möglicher Konsequenzen von Entscheidungen, sowie

– Aktionen oder Ergebnisse, die darauf folgen können oder müssen.– "Was wäre wenn ..." - Szenarien

• Strategisches Risiko-Management:

– Perspektive auf das ganze Unternehmen

– eher langfristige Regeln (anwendbar für das operative Geschäft)

• Operatives Risiko-Management

– Betrachtung einer ganz bestimmten Aufgabe

– z.B. Kosten, Zeitrahmen, technisches Verhalten, etc.




Zeit, Kosten, Technologie

• Alle diese Risiken habe Einfluss auf 3 elementare Risiko-Elemente

– Zeitrahmen

– Kosten

– Technik / Qualität / Funktionalität

• Beispiel: Compiler-Fehler tritt während der Entwicklung auf

– Unmittelbares technisches Risiko: Software läuft nicht wie erwartet

– Daraus resultiert ein Kostenrisiko: zusätzlicher Aufwand, um den Fehler zu beheben oder eine andere Strategie zu implementieren

– Daraus resultiert ein zeitliches Risiko: der Zusatzaufwand wirkt sich auf Meilensteine aus




LE 3.2 - LM 14 - LO4

Der Risiko-Management Prozess




Risiko-Management im Projekt

Risiko-Management hat nichts mit zukünftigen Entscheidungen zu tun, sondern

mit den Auswirkungen heutiger Entscheidungen auf die Zukunft.

– Erfolgreiche Projektleiter sind gute Risiko-Manager

– Risiko-Management verbessert die Wahrscheinlichkeit, die SWProdukte dem Kunden mit den richtigen Inhalten und der geforderten Qualität im geplanten Budget zu liefern.

– Der beschriebene Risiko-Management Prozess bietet dem Projektleiter die Methoden und Werkzeuge, um Risiken zu kontrollieren - nicht um sie zu vermeiden!




Risiko-Management Prozess

All rights reserved © 2000, Alcatel, Paris.




Risk-Management Prozess

Risk Assessment (def. Intervall), Projektleiter/Risk-Assessor

Projektcontrolling insbes. Überwachung von Aufwand und Budget bzgl. Soll / Ist und korreliert zu Leistungsstand und Zeit

Risk Reporting Risiko-Analyse und Risk-Log

Risiko Identifizierung

RisikoAnalyse / Bewertung

Risikofaktoren -Ereignisse / -unbefriedigende Zustände

Hinsichtlich -Einfluss -Wichtigkeit -Wahrscheinlichkeit

RisikoReduktion/Maßnahmen

Risiken -vermeiden -vermindern -überwälzen -selbst tragen

RisikoÜberwachung

Mitigationplan Maßnahmen managenBeherrschbarkeit Eskalation




Nötige Infrastruktur zum Risiko-Management

LeitlinienDas obere Management muss selbst Leitlinien zum Risikomanagement setzen

VerantwortungenRisiko-Management ist integraler Bestandteil des Projekt-Management und damit unter der vollen Verantwortung des Projektleiters

KulturErreichen gemeinsamer Ziele anstatt Schuldzuweisungen

LernkurveRisiko-Management benötigt ein kontinuierliches Lernen aus Erfolgen und vor allem aus Misserfolgen




Planung als Basis für Risiko-Management

• Praktische operative Projektplanung ist die Basis für jegliches Risiko-Management.– Berücksichtigung von konkreten Ressourcen, Kosten und Dauer

– Identifikation aller wichtigen Aktivitäten

– Hierarchische Verfeinerung von Aktivitäten

– Alle Aktivitäten sind mit Aufwand, Status, Ressourcen, Dauer, und Daten verbunden

– Abhängigkeiten sind definiert

• Methodik:– Gantt Charts (Balkendiagramme), PERT Diagramme (Netzplantechnik)

– Analysen für kritischen Pfad und für unterschiedliche Szenarien

– Rückwärts-Planung




Projekt-Reviews

• Formaler und standardisierter Status-Review des Projekts durch ein explizit ausgewiesenes Review-Team

– Verfolgung des Fortschritts im Vergleich zum Projektplan und zu den Projektzielen (Entwicklungsergebnisse, Qualität, Kosten)

– Bewertung des Status und Entscheidung zwischen Alternativen

– Zuweisung oder Reduzierung von Ressourcen

• Beispiele:

– Meilenstein-Review

– Management-Übersicht




Projektverfolgung




Hilfsmittel Risk-Log

• Zur Konsequenten Verfolgung von Risiken empfiehlt sich das Führen eines Risk-Logs

• Review des Risk-Logs ist fester Agenda-Punkt bei allen– Projektleitungssitzungen– Lenkungsausschuss-Sitzungen– Sitzungen anlässlich des Endes / Start einer Projektphase

• Wichtigste Elemente– Benennung des Risikos– Benennung eines Verantwortlichen für die Verfolgung des Risikos– Da Risiken zu verschiedenen Zeitpunkt i.d.R. unterschiedlich

bewertet werden, bzw. mindernde Maßnahmen greifen, ist eine Versionierung der Risiko-Einträge erforderlich.




Typische Inhalte des Risk-Logs

• Administrative Daten wie eindeutige Referenz, Beschreibung, Datum der Identifikation, aufgedeckt durch, Verantwortlicher usw.

• Einschätzung des Risikos hinsichtlich

– Wahrscheinlichkeit des Eintretens

– Auswirkung auf das Projekt bei Eintreten

– Mögliche Auswirkungen des Risikos auf das Projekt

– Referenz zu den unternommen Handlungen um das Risiko zu handhaben

– Status des Risikos (z.B.: vermindern, beobachten, abgeschlossen)

– Lenkbarkeit des Risikos - sind entsprechende Gegenmassnahmen möglich wie etwa:

– Projekt Manager hat Risiko unter Kontrolle

– Ausser Kontrolle des Projekt Managers (Unterstützung nötig)

– Keine Gegenmassnahmen möglich




LE 3.2 - LM 14 - LO5

Top 10 Risiken in SW-Projekten




Die Top 10 Software-Risiken

Risiko mögliche Risiko-Linderung

1 Unzureichende Resourcen Fähigkeiten beachten; beste Fähigkeiten einsetzen;Team Building; Abstimmungen mit Konkurrenzprojekten;Training von Ersatzpersonen

2 Unrealistische Zeitplanungund Budget

Detaillierte Kostenschätzung; Design to Cost;inkrementelle Entwicklung; Reuse; Anforderungendurchforsten

3 Falsche Funktionen werdenentwickelt

Analyse der Projektziele; Benutzer-Interviews; Use cases;Prototyping; frühe Dokumentation; Quality-FunctionDeployment

4 FalscheBenutzerschnittstelle

Prototyping; Use cases; Szenarios; Benutzer-Interviews;Benutzer-Mitarbeit; Benutzer-Laboratorium

5 Over-Engineering Anforderungen durchforsten; Prototypen; Kosten-Nutzen-Analyse;Design to cost; Wertanalyse




Die Top 10 Software-Risiken

Risiko mögliche Risiko-Linderung

6 Ständige Änderungen derAnforderungen

Schwellen für Änderungsgenehmigungen; inkrementelleEntwicklung; Information Hiding

7 Defizite bei externenKomponenten

benchmarking der Lieferanten; Inspektionen;Kompatibilitätsanalyse; gemeinsame frühzeitige Tests

8 Defizite im Outsourcing vonAktivitäten

Schnittstellenkontrolle; Audits vor jedem Meilenstein;Entnutzenorientierte Verträge; Wettbewerb; gemeinsameTeams

9 Defizite im Echtzeit-Verhalten

Simulation; Modellierungen; Prototypen;Instrumentierung; Performance-Tuning; früheTestumgebungen für kritische Resourcen

10 Unzureichendes technischesKnow-How

intensive technische Analyse von Anforderungen vs.Fähigkeiten; Kosten-Nutzen-Analyse; Prototypen;Training; Coaching; Consulting




Risiko-Bewertung

• Risiko = Wahrscheinlichkeit * Auswirkungen

Wahrscheinkichkeit

Stufe Wert Kriterien

5 so gut wie sicher alles deutet darauf hin, dass dies zum Problem wird

4 sehr sicher grosse Wahrscheinlichkeit, dass dies zum Problem wird

3 wahrscheinlich (50/50) gleichverteilte Chance, das dies eintritt

2 unwahrscheinlich manchmal wird dies zum Problem

1 fast unmöglich sehr unwahrscheinlich, dass dies jemals eintritt

Auswirkungen

Stufe Wert Technische Kriterien Kosten-Kriterien Zeitrahmen-Kriterien 5 katastrophal keine Kontrolle möglich > DM 50 Mio Abbruch

4 kritisch gravierende Mängel, DM 10...50 Mio Einfluß auf Folgeprojekt

3 mittelmässig beträchtliche Abweichungen DM 1...10 Mio Beträchtlich; Umplanung

2 gering Performanzeinflüsse DM 0,1...1 Mio > 1 Monat Verzögerung

1 vernachlässigbar unbedeutend unbedeutend unbedeutend




Risiko-Dimensionen

• Projektstellung

• Projektplanung / - Controlling

• Personalsituation

• Technisches Umfeld

• Finanzen

• Leistungsstand der Entwicklung

• Qualitätssicherung

• Zusätzliche Dimensionen in Beratungsprojekten

– Angebotslage

– Kundenumfeld

– Nebenaufwände




Beispiel-Ergebnis einer RisikoanalysePrüffeldbewertung

0,00,5

1,0

1,5

2,0

2,53,0

3,5

4,0

4,5

5,0Projektstellung

Angebotslage

Projektplanung / -Controlling

Personalsituation / Staffing

/ Projektgründung

Technisches Umfeld

Kunden Umfeld

NebenaufwändeEinarbeitung etc.

Qualitätssicherung

Leistungsstand der Entwicklung

Finanzen

Bewertung

MaxWert

Normalbereich

Risikogrenze




LE 3.2 - LM 14 - LO6

Erfahrungen




Einsatzzeitpunkte einer Risikoanalyse

• Angebotsphase

• Projekt-Generierung

• regelmäßig im Projektverlauf

• Projektabschluß

• Zusätzliche Analysen

– In besonderen Situationen (Entscheidung des PL)

– Auf Anforderung des Lenkungsteams

• Angebotsphase

• Projekt-Generierung

• regelmäßig im Projektverlauf

• Projektabschluß

• Zusätzliche Analysen

– In besonderen Situationen (Entscheidung des PL)

– Auf Anforderung des Lenkungsteams




Risiko-Management praktischer Einsatz

Risiko-Management braucht keine besonders ausgefeilten Werkzeuge.

Wichtig sind eher:

– Konkrete und realistische Projektplanung

– Kontinuierliche Projektverfolgung mit Projekt-Reviews

– Allseits verstandenes und eingehaltenes Requirements Management

– Inkrementelle Entwicklung

– Klare Abschätzung und Dokumentation von Entscheidungsalternativen

– Klare Verantwortung für Ergebnisse




Risikomanagement: Gegenmassnahmen

Problem Mögliche Gegenmassnahmen Mögliche Konsequenzen aus denGegenmassnahmen

Terminabweichung Zusätzliche Ressourcen

Auslastung der vorhandenenRessourcen erweitern(Linienfunktionen verringern,Überstunden, ...)

Funktionsumfang verringern

Budgetüberschreitung

Qualität der Arbeit sinkt

Mögliche Budgetüberschreitung

Budgetüberschreitung Ressourcen verringern Terminabweichung

Interpersonelle Konflikte Moderator einsetzen

Persönliche Probleme vonProjektmitarbeitern

Linienvorgesetzten/Betriebsrateinschalten

Geforderte Funktionalität nichtrealisierbar

Spezialisten hinzuziehen

Kunden eine Alternativlösunganbieten

Budgetüberschreitung




Risikomanagement: Iterativ-inkrementelles Vorgehen

Falls sich herausstellt, dass die dem Software-Entwicklungsprozess zugrundeliegenden Regeln (Vorgehensmodell) nicht mehr den Anforderungen entsprechen, dann muss das Projekt-Controlling dafür sorgen, dass das Vorgehensmodell dementsprechend angepasst wird.

Dies kann eine Vielzahl von Konsequenzen haben, die vom Management eingeleitet werden müssen.

Alle schlagen sich in Modifikationen des Projekthandbuches und evtl. des Qualitätshandbuches nieder.




LE 3.2 - LM 14 - LO 7 Zusammenfassung und Abspann




Zusammenfassung

• Risiken sind Bestandteil jeder Projektarbeit

• Das Projekt-Risk-Management ist ein wesentliches Instrument des Managements von Projekten

• Hauptaufgaben des Projekt-Risk-Management

– Früherkennung von Risiken

– Risiken richtig einschätzen

• Risk-Assessor ist eine eigene Rolle in der Projektorganisation

– Ergänzend zur Qualitätssicherung

– Unterstützung des Projektleiters durch Coaching

• Risiken sind Bestandteil jeder Projektarbeit

• Das Projekt-Risk-Management ist ein wesentliches Instrument des Managements von Projekten

• Hauptaufgaben des Projekt-Risk-Management

– Früherkennung von Risiken

– Risiken richtig einschätzen

• Risk-Assessor ist eine eigene Rolle in der Projektorganisation

– Ergänzend zur Qualitätssicherung

– Unterstützung des Projektleiters durch Coaching




Literatur

• G. J. Myers, The Art of Softwaretesting, New York, 1979• T. A. Thayer, Software Reliability, Amsterdam, 1978• G. E. Thaller, Software Test: Verifikation und Validation Heise, 2002• Balzert, Helmut: Lehrbuch der Software-Technik : Software-Management, Software-

Qualitätssicherung. Heidelberg u.a.: Spektrum Verlag, 1998.• Thaller, Erwin: Verifikation und Validation : Software-Test für Studenten und Praktiker.

Braunschweig u.a.: Vieweg, 1994.• Balzert, Helmut: Lehrbuch der Software-Technik : Software-Entwicklung. Heidelberg u.a.:

Spektrum Akademischer Verlag, 1996.• Davis, Alan: Software Requirements: Analysis and Specification. Englewood Cliffs: Prentice

Hall, 1990.• Gaulke, Markus:Risikomanagement in IT Projekten, ISBN 3-486-25743-9, Oldenburgverlag

2002• R. Mock, Risiko, Sicherheit und Zuverlässigkeit, Informatik Spektrum 26-3, 2003• Universität GH Essen: "Modellierung 1 Einheit 7: Software Risk Evaluation“

http://nestroy.wi-inf.uni-essen.de/Lv/mod1.html




Danksagung

Aus folgenden Vorlesungen und Foliensammlungen aus dem Bereich Softwaretechnik konnten wir Anregungen zur Gestaltung dieses Lernmoduls gewinnen:

P. Göhner Softwaretechnik 1 IAS Uni Stuttgart

A. Schürr Software Engineering 1 Uni BW München

M. Hinkelmann Projektmanagement HdM Stuttgart




LE 3.2 - LM 14 - LO 8

Tests zu LM 14




Diese Fragen sollten Sie jetzt beantworten können

• Gründe für Risiko

• Elementare Risiko-Elemente

• Elemente des Risiko Management Prozesses

• Risiko Dimensionen

• Infrastruktur zum Risiko Management Prozess

• Bedeutung von Checklisten

Test 1




Checklisten

Zur Planung einer Risikoanalyse empfehlen wir die Checklisten des ISTE Stuttgart für den Software-Entwicklungsprozess heranzuziehen (Ansatz Tayloring)

http://www.iste.uni-stuttgart.de/se/service/checklists/index.html

Von Interesse sind insbesondere Checklist of Software Risk Items [HTML] Checklist for Risk Assessment [HTML] Checklist of Risk Management Techniques [HTML] Checklist for Project Control [HTML] Checklist for Project Continuation [HTML] Checklist for Deciding about Project Completion [HTML]




LE 3.2 - LM 14 - LO 9

Definitionen zu LM 14




Definitionen

• Risiko: Möglichkeit eines körperlichen oder materiellen Schadens oder Verlustes durch eine Aktivität.

• Risikomanagement: Führungsstil, bei dem sich der Manager auf

die Risiko-Bewertung und die Risiko-Beherrschung konzentriert.

Documents

Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE 3.2 Qualitätsmanagement Folie 1LM 14 Risikomanagement Risikomanagement Inhalt Ziele