Richtlinie: Liste der Risiken
Diese Richtlinie beschreibt, wie Risiken von Softwareprojekten identifiziert und verwaltet werden können.
Beziehungen
Zugehörige Elemente
Hauptbeschreibung

Einführung

"Bereit sein ist alles." - Hamlet

Ein Projekt ist so unsicher wie das Leben selbst. Risiken werden nicht um ihrer selbst willen identifiziert, sondern um sie vorwegzunehmen und zu mindern oder, wenn die Risikominderungsstrategien zu kurz greifen, um sie zu reagieren.

Risiken wirken sich auf die Iterationspläne aus. Iterationen werden bei der Behandlung bestimmter Risiken geplant, um sie zu begrenzen oder zu mindern. Die Liste der Risiken wird regelmäßig überprüft, um die Effektivität der Risikominderungsstrategien zu bewerten, die wiederum Überprüfungen des Projektplans und folgender Iterationspläne nach sich ziehen.

Der Schlüssel zum Risikomanagement besteht nicht darin, zu warten, bis ein Risiko auftritt (und zu einem Problem oder einem Fehler wird), bevor man eine Entscheidung über die weitere Vorgehensweise trifft. So wie bei einem Transkontinentalflug eine Kursänderung von nur ein paar Grad eine starke Kursabweichung bei der Landung ergibt, ist das Risikomanagement in einem frühen Stadium fast immer kostengünstiger und einfacher zu bewerkstelligen als in einem späten Stadium.

Risikomanagementstrategien

Es gibt drei Hauptstrategien [siehe Veröffentlichung BOE91]:

  • Risikovermeidung. Reorganisieren Sie das Projekt so, dass das Risiko keine Auswirkungen hat.
  • Risikoübertragung. Reorganisieren Sie das Projekt so, dass jemand bzw. etwas anders das Risiko trägt (Kunde, Hersteller, Bank, ein anderes Element usw.). Eine besondere Strategie der Risikovermeidung.
  • Risikoakzeptanz. Entscheiden Sie sich, mit dem Risiko als unabänderlichem Umstand zu leben. Überwachen Sie die Risikosymptome und beschließen Sie einen Plan für unvorhersehbare Ereignisse, der vorgibt, was zu tun ist, wenn ein Risiko auftritt.

Auch wenn Sie entscheiden, das Risiko zu akzeptieren, können Sie dennoch ein Interesse daran haben, es zu mindern, indem Sie direkte Maßnahmen ergreifen, um seine Auswirkungen zu reduzieren.

Risikotypen

Es ist wichtig, zwischen direkten und indirekten Risiken zu unterscheiden. Ein direktes Risiko ermöglicht ein gewisses Maß an Kontrolle, indirekte Risiken hingegen können nicht gesteuert werden.

Indirekte Risiken sollten zwar nicht außer Acht gelassen werden, haben aber für die Praxis wenig Folgen: Da sie nicht geändert werden können, macht es wenig Sinn, sich ständig Sorgen über sie zu machen. Stattdessen gilt es, sich auf die anstehende Arbeit zu konzentrieren.

Manchmal ist ein scheinbar indirektes Risiko tatsächlich ein direktes. Beispiel: Die Abhängigkeit von einem externen Lieferanten, der eine Komponente oder eine Komponentengruppe bereitstellt. Dies scheint ein indirektes Risiko zu sein, aber mit Plänen für unvorhersehbare Ereignisse hinsichtlich dieser Komponenten kann das Risiko kontrolliert werden. Es besteht die Möglichkeit, alternative Lieferanten auszuwählen oder die benötigte Funktionalität selbst zu entwickeln. Oft gibt es mehr Kontrollmöglichkeiten als man glaubt.

Bei indirekten Risiken kann man entweder feststellen, wie man ein bestimmtes Maß an Kontrolle erreicht werden kann, oder man kann die Risiken dokumentieren und fortfahren. Es macht keinen Sinn, sich den Kopf zu zerbrechen über Dinge, die man nicht ändern kann.

Ressourcenbezogene Risiken

Organisation
  • Ist das Engagement für das Projekt ausreichend (einschließlich Management, Tester, Qualitätssicherung und andere externe beteiligte Parteien)?
  • Handelt es sich um das größte Projekt, das diese Organisation jemals in Angriff genommen hat?
  • Gibt es einen klar definierten Prozess für die Softwareentwicklung? Werden die Anforderungen erfasst und gibt es ein Anforderungsmanagement?
Finanzierung
  • Ist die Finanzierung des Projekts gesichert?
  • Ist die Finanzierung für Schulung und Anleitung gesichert?
  • Ist das Budget so begrenzt, dass das System zu einem Festpreis geliefert werden muss und andernfalls der Projektabbruch erfolgt?
  • Sind die Kostenvoranschläge präzise?
Personal
  • Ist genug Personal verfügbar?
  • Verfügen die Mitarbeiter über ausreichend Know-how und Erfahrung?
  • Haben die Teilnehmer des Projekts schon früher zusammengearbeitet?
  • Sind sie vom Erfolg des Projekts überzeugt?
  • Stehen Benutzervertreter für Überprüfungen zur Verfügung?
  • Sind Fachleute verfügbar?
Zeit
  • Ist der Zeitplan realistisch?
  • Kann der Umfang der Funktionalität gesteuert werden, um Zeitpläne einzuhalten?
  • Wie kritisch ist das Lieferdatum?
  • Wurde genug Zeit für präzises Arbeiten eingeplant?

Geschäftsrisiken

  • Wie soll reagiert werden, wenn ein Mitbewerber sein Produkt zuerst auf den Markt bringt?
  • Wie ist vorzugehen, wenn die Finanzierung des Projekts gefährdet ist? Oder, andersherum formuliert: Was kann getan werden, um die angemessene Finanzierung des Projekts sicherzustellen?
  • Ist der erwartete Nutzen des Projekts größer als die erwarteten Kosten? (Stellen Sie sicher, dass Sie den Zeitwert des Geldes nachweisen und die Kapitelkosten rechtfertigen können.)
  • Was wäre, wenn keine Verträge mit wichtigen Anbietern geschlossen werden können?

Technische Risiken Seitenanfang

Risiken, die den Umfang betreffen
  • Kann der Erfolg gemessen werden?
  • Gibt es Übereinstimmung hinsichtlich der Erfolgsmessung?
  • Sind die Anforderungen stabil und klar definiert?
  • Ist der Projektumfang fix oder nimmt er noch zu?
  • Sind die geplanten Zeiträume für die Projektentwicklung zu kurz und unflexibel?
Technologische Risiken
  • Hat die Technologie sich bereits in der Praxis bewährt?
  • Sind die Ziele für die Wiederverwendung angemessen?
    • Ein Arbeitsergebnis muss bereits einmal verwendet worden sein, bevor es wiederverwendet werden kann.
    • Möglicherweise sind mehrere Releases nötig, damit eine Komponente so stabil ist, dass sie ohne wichtige Änderungen wiederverwendet werden kann.
  • Sind die Transaktionsvolumen in den Anforderungen angemessen?
  • Sind die Schätzungen für die Transaktionsrate glaubwürdig? Sind sie zu optimistisch?
  • Sind die Datenvolumen angemessen? Können sie gegenwärtig von Großrechnern bewältigt werden, oder, wenn aus den Anforderungen hervorgeht, dass eine Workstation oder ein Unternehmenssystem Teil des Design ist, können die Daten auf diesen Systemen angemessen bewältigt werden?
  • Gibt es ungewöhnliche oder schwierige technische Anforderungen, aufgrund derer das Projektteam Probleme in Angriff nehmen muss, mit denen es nicht vertraut ist?
  • Ist Erfolg abhängig von neuen bzw. nicht erprobten Produkten, Services, Technologien, Techniken oder neuer bzw. nicht erprobter Hardware oder Software?
  • Gibt es externe Abhängigkeiten von Schnittstellen zu anderen Systemen einschließlich derer außerhalb des Unternehmens? Gibt es die erforderliche Schnittstellen oder müssen sie erstellt werden?
  • Gibt es Verfügbarkeits- und Sicherheitsanforderungen, die extrem unflexibel sind (z. B. "das System darf niemals versagen")?
  • Sind die Benutzer des Systems unerfahren mit dem zu entwickelnden Systemtyp?
  • Besteht ein erhöhtes Risiko aufgrund der Größe und Komplexität der Anwendung oder der Neuartigkeit der Technologie?
  • Gibt es Anforderungen hinsichtlich der Unterstützung nationaler Zeichensätze?
  • Ist es möglich, dieses System zu entwerfen, zu implementieren und dann auszuführen? Es gibt Systeme, die einfach zu groß oder komplex sind, als dass sie ordnungsgemäß ausgeführt werden könnten.
Risiko externer Abhängigkeiten
  • Ist das Projekt von anderen (parallelen) Entwicklungsprojekten abhängig?
  • Ist der Erfolg von gebrauchsfertigen oder extern entwickelten Komponenten abhängig?
  • Ist der Erfolg abhängig von der erfolgreichen Integration von Entwicklungstools (Designtools, Compilern usw.), Implementierungstechnologien (Betriebssystemen, Datenbanken, Mechanismen für Interprozesskommunikation usw.). Haben Sie einen Backup-Plan, der die Fertigstellung des Projekts ohne diese Technologien vorsieht?

Planrisiken

Die Erfahrung zeigt, dass 85 % der Risiken direkte oder indirekte Auswirkungen auf den Zeitplan und daher auch auf die Kosten haben. Nur etwa 5 % wirken sich auf die Kosten aus. Der Rest hat keine direkten Auswirkungen auf die Kosten oder den Zeitplan, jedoch auf die Qualität.

Wenn der Terminplan sehr eng ist, nähern Sie sich dem Endtermin schrittweise mit Teillieferungen an. Vermeiden Sie es, alles auf einmal zu liefern, nur um den Zeitplan zu halten.

Manche Projekte haben unverrückbare Endtermine. Beispielsweise hat Software, mit der Wahlergebnisse in der Wahlnacht live analysiert werden sollen, keinen Wert mehr, wenn sie eine Woche nach der Wahl geliefert wird. Oder die Software wird obsolet, weil ein Konkurrent ein besseres Produkt herausbringt als Sie, während Sie sich noch mitten in der Konstruktionsphase befinden. Plötzlich sind Sie aus dem Rennen, und Sie können nichts daran ändern. Im Allgemeinen jedoch haben nur wenige Projekt einen solch kritischen Endtermin. Verzögerungen wirken sich meist auf die Kosten aus.

Im Allgemeinen sollten Sie Ihren Zeitplan anhand Ihrer besten Schätzung erstellen und dabei einen angemessenen Spielraum für unvorhersehbare Ereignisse einkalkulieren.

Festlegung = Schätzung + Spielraum für unvorhersehbare Ereignisse

Andere Methoden sehen vor, dass man die Erwartungen an die Pläne für unvorhersehbare Ereignisse annähert, aber das ist ein wenig zu pessimistisch, da nicht alle Risiken tatsächlich auftreten.

Planrisiken sind in verschiedene Tools für Schätzung und Kostenberechnung integriert. Beispielsweise sind viele Kostenfaktoren im COCOMO-Modell, wie

  • Komplexität (cplx)
  • Vorgaben für Echtzeit (time)
  • Vorgaben für Speicher (stor)
  • Erfahrung (Vexp)
  • Verfügbarkeit guter Tools (tool)
  • Zeitdruck (sced)

eigentlich Risikofaktoren.

Höher entwickelte Techniken für das Risikomanagement beinhalten die Verwendung der Monte-Carlo-Simulation, in der eine große Anzahl von Szenarios von einem Simulationstool ausgeführt werden, um allgemeine Risiken und unvorhersehbare Ereignisse zu berechnen [siehe Veröffentlichung KAR96].