Risiken in der IT: Erkennen - Steuern - Verbessern (BUCHVORSTELLUNG)

Ein Modell für effektives Risikomanagement in Entwicklung und Betrieb

Managementsysteme werden für die unterschiedlichsten Einsatzzwecke benötigt. Dazu gehört die Führung eines Unternehmens ebenso wie die Steuerung eines IT-Vorhabens oder auch die Einhaltung eines Qualitäts-, Umwelt-  oder Informationssicherheitsstandards. Sie zeigen dem Management Ziele auf und geben ihm bewährte Methoden zur Zielerreichung ebenso wie die zugehörigen Steuer- und Kontrollmechanismen an die Hand. Dieses Buch beschreibt anhand eines Modells, wie der Kernprozess des Risikomanagements innerhalb eines solchen Managementsystems funktioniert. Hauptmerkmal des Modells ist die zyklische Wiederholung des Erkennens und Bewertens von Chancen und Risiken, daraus resultierend der Ergreifung notwendiger Steuerungsmaßnahmen und die anschließende Umsetzung davon abgeleiteter Verbesserungsmaßnahmen.

Jeder Zyklus beginnt zunächst mit der Festlegung von für das IT-Vorhaben wesentlichen Zielen. Daran schließen sich die Identifikation von Einflussgrößen, welche die Zielerreichung bedrohen oder auch begünstigen, sowie deren Bewertung an. Dieser Schritt ist durch die Fokussierung auf wesentliche Ziele und akute Bedrohungen eine wichtige Voraussetzung für wirtschaftliches Risikomanagement.

Um Einflussgrößen zu finden, welche das Erreichen der ausgewählten Ziele begünstigen oder bedrohen, wird die Kombination einer methodischen Ursache-Wirkungs-Analyse mit eigenen Erfahrungswerten empfohlen. Die Bewertung ihrer Eintrittswahrscheinlichkeit wie auch der Höhe und Art des möglichen Schadens, der entsteht, falls ein Ziel nicht erreicht wird, ermöglicht die sinnvolle Fokussierung auf eine Teilmenge der Einflüsse.

Modell zum Management von Chancen und Risiken

Das im jeweiligen Zyklus neu bewertete Risikoprofil bildet die Grundlage für Entscheidungen des Managements entweder zur Akzeptanz oder zur Behandlung der Risiken. Eine Behandlung kann beispielsweise im Abschluss einer Versicherung (Risiko-Transfer), in der Auslagerung risikobehafteter Bereiche aus dem betrachteten IT-Vorhaben in andere Teile der Organisation (Umstrukturierung) oder auch in der Durchführung und Nachverfolgung von Maßnahmen zur aktiven Risikoreduzierung bestehen.

Im letzten Schritt eines Zyklus ist zu prüfen, durch welche Maßnahmen die Wirksamkeit des Risikomanagements wie auch das Kosten/Nutzen-Verhältnis verbessert werden können. Hierzu gehört eine Nachbetrachtung aller Bestandteile des Modells wie Prozesse, Methoden, Metriken und Skalen zur Bewertung, Dokumentationen usw.

Erhebliches Potenzial zur Verbesserung liegt darin, Wissen über allgemeine oder auch organisationsspezifische Bedrohungen der Zieltypen explizit zu machen und dieses explizite Wissen auch permanent Veränderungen beispielsweise der Bedrohungslage anzupassen. Eine Art der Implementierung dieses Wissens ist die Erstellung und Pflege von Regelwerken, durch die den mit der Risikoanalyse beauftragten Menschen Fragebögen zur Beantwortung vorgelegt und aus deren Antworten entsprechende Vorschläge für Risikobewertungen erzeugt werden. Diese Vorschlagswerte müssen jedoch aufgrund des eigenen menschlichen Urteilsvermögens und der Intuition validiert, eventuell auch korrigiert werden. Eine weitere Verbesserung ist absehbar, sobald Systeme zum maschinellen Lernen für Zwecke der Risikoanalyse eingesetzt werden können.

Das Buch unterstützt bei der wirtschaftlichen Anwendung einer komplexen Methodik zum Risikomanagement. Es kombiniert verständlich dargestelltes Methodenwissen mit Beispielen aus der umfangreichen IT-Erfahrung des Autors. Es ist als E-Book, Paperback und Hardcover erhältlich (direkt im Tredition-Buch-Shop inkl. Leseprobe - oder im Buchhandel).

Methoden zur direkten und indirekten Aufwandsschätzung (3)

Indirekte Schätzungen durch Bestimmung des funktionalen Umfangs

Eine bewährte Methode zur indirekten Aufwandsschätzung ist die Bestimmung des funktionalen Umfangs (anstelle beispielsweise Story Points) und die Verrechnung mit einem Erfahrungswert, welcher Umfang mit einem bestimmten Personalaufwand umgesetzt werden kann (auch häufig als Produktivität oder Effizienz bezeichnet). Die Grundlagen zur Messung des funktionalen Umfangs sind im Industriestandard ISO/IEC 14143 definiert. Sie erfordern eine Präzisierung der User Stories in Anwendungsfälle.

Beispiel eines Anwendungsfalldiagramms

Ein Anwendungsfall steht für ein Verhalten, das ein System nach außen – bezogen auf die definierten Systemgrenzen – anbietet, dessen Ergebnisse also für einen Akteur von außen wahrnehmbar sind. Dabei können Akteure sowohl Anwender als auch andere Systeme oder Maschinen, Hardware oder Software, sein. Die nebenstehende Abbildung zeigt das Anwendungsfalldiagramm einer (stark vereinfachten) Internet Booking Engine für Flüge. Innerhalb der Systemgrenzen (dargestellt als Rechteck mit der Beschriftung „Internet Booking Engine“) sind Anwendungsfälle durch Ellipsen dargestellt. Sie stehen in Beziehung mit Akteuren, im Beispiel ein Reisender und ein Computerreservierungssystem (CRS), was durch Linien zwischen den Akteuren und den Use-Cases dargestellt wird.

Jeder Anwendungsfall steht für Aktionen, aus denen sich die für eine Bestimmung des funktionalen Umfangs relevanten sogenannten Basis-Funktionskomponenten oder Elementarprozesse identifizieren lassen. Der Anwendungsfall „Search Flight“ könnte beispielsweise vereinfacht aus folgenden Elementarprozessen bestehen:

1. Reisender ruft den Flight Search Dialog auf.
2. Reisender gibt das Abflugdatum ein.
3. Reisender gibt die ersten Buchstaben des Reiseziels ein (Name oder Code).
4. System sucht in der Datenbank nach übereinstimmenden Flughäfen und zeigt eine Liste mit Namen und Codes an.
5. Reisender wählt einen Eintrag aus der Liste aus und klickt auf dem Button „Search“.
6. System sendet eine Nachricht vom Typ „Flight Search Request“ mit Datum und Flughafen-Code an das CRS.
7. System empfängt eine Nachricht vom Typ „Flight Search Response“ vom CRS und liest die Felder Abflugzeit, Ankunftszeit, Fluggesellschaft, Flugnummer, Klasse, Preis und Währung aller aufgeführten Flüge aus.
8. System zeigt in einer Tabelle alle Flüge unter Angabe dieser Informationen an.

In Kenntnis dieser Elementarprozesse kann mit jeder funktionsorientierten Messmethode leicht der funktionale Umfang bestimmt und mit Hilfe eines Erfahrungswerts für die Produktivität der zu erwartende Entwicklungsaufwand ermittelt werden. 

Alternativen:

• Expertenschätzungen
• Indirekte Schätzungen mit Story Points

Buchempfehlung: "Aufwandsschätzungen in der agilen Softwareentwicklung"

Methoden zur direkten und indirekten Aufwandsschätzung (2)

Indirekte Schätzungen mit Story Points

Eine direkte Schätzung des Entwicklungsaufwands (siehe: Expertenschätzungen) ist von den persönlichen Fähigkeiten des Schätzers abhängig und nicht von der Leistungsfähigkeit des Teams, das für die Entwicklung vorgesehen ist. Im Gegensatz zu einer direkten Schätzung ermitteln indirekte Methoden zunächst die Größe der zu entwickelnden Objekte oder Anforderungen und stellen diese anschließend in Relation zu Erfahrungswerten idealerweise des gleichen Teams aus früheren Sprints. 

Im Fall der Story Point-Methode bewerten Schätzer die Größe von User Stories, jedoch nicht in einer absoluten Maßeinheit sondern relativ zueinander. Beispiel: „Die Auswahl des Zielflughafens und Datums ist eine 1. Die Abfrage verfügbarer Flüge ist im Verhältnis dazu eine 3. Die Buchung eines ausgewählten Flugs ist dann eine 8.“ Die Skala für die zu vergebenden Story Points orientiert sich an der Fibonacci-Folge: 1, 2, 3, 5, 8, 13 und so weiter. Dadurch entfallen kleinteilige Diskussionen und Entscheidungen zwischen den zulässigen Werten werden erleichtert. Gleichzeitig macht die Skala jedoch auch deutlich, dass die Genauigkeit der Bewertung mit zunehmender Größe abnimmt.

Die Berechnung des voraussichtlichen Entwicklungsaufwands auf Basis von Story Points erfordert einen Erfahrungswert, wie viele Story Points das Team unter vergleichbaren Rahmenbedingungen je Inkrement bzw. Sprint umsetzen kann. Dieser Erfahrungswert wird Velocity genannt und nach jedem abgeschlossenen Sprint dadurch aktualisiert, dass die Größe der tatsächlich entwickelten Stories mit der dafür benötigten Zeit ins Verhältnis gesetzt wird.

Eine Aufwandsschätzung durch Story Points hat den Vorteil, dass sie schnell angewendet werden kann und von der aktuellen Leistungsfähigkeit des Teams und nicht einzelner Individuen ausgeht. Durch die permanente Nachkalibrierung der Velocity kann sich diese innerhalb von wenigen Sprints an Veränderungen beispielsweise in der Team-Zusammensetzung oder sonstiger Rahmenbedingungen anpassen.

Ein Nachteil der Methode ist die Detaillierung des Schätzobjekts: eine User Story, die eine Anforderung meist nur umgangssprachlich in einem Satz beschreibt. Unerwartete Komplexität, die erst bei der Umsetzung festgestellt wird, führt dann häufig zu einer Überschreitung des geschätzten Aufwands.

Alternativen:

• Expertenschätzungen
• Indirekte Schätzungen durch Bestimmung des funktionalen Umfangs

Buchempfehlung: "Aufwandsschätzungen in der agilen Softwareentwicklung"

Methoden zur direkten und indirekten Aufwandsschätzung (1)

Expertenschätzungen

Eine bewährte Methode, um sich dem notwendigen Aufwand zur Umsetzung von Anforderungen bzw. User Stories anzunähern, ist die Expertenschätzung. Ein oder auch mehrere Experten schätzen unabhängig voneinander den Aufwand auf Basis ihrer Erfahrungen mit vergleichbaren Aufgabenstellungen. Da diese Erfahrungen sehr unterschiedlich sein können und sich oft an den eigenen Fähigkeiten orientieren ist eine Mittelwertbildung über mehrere Schätzergebnisse naheliegend. Ein weiteres Problem dieser Methode ist neben der Subjektivität, dass Experten meist Mitglieder eines Entwicklungsteams sind und für die Dauer der Schätzung nicht produktiv zum Entwicklungsprozess beitragen können.

Bei der Delphi-Methode stellt ein Moderator zu Beginn mehreren Experten Details der zu schätzenden User Stories vor, die sie anschließend völlig unabhängig voneinander schätzen. Danach wertet der Moderator die Ergebnisse aus und präsentiert die Abweichungen. Diskussionen sind dabei unerwünscht, um eine Gruppendynamik durch dominante Experten zu vermeiden. Jeder Experte hat die Möglichkeit, seine Schätzung zu überdenken und gegebenenfalls zu verändern. Dieser Prozess wird so lange wiederholt, bis die Abweichungen eine Toleranzschwelle nicht mehr überschreiten. Ein Vorteil der Delphi-Methode liegt in der iterativen Verfeinerung der einzelnen Expertenschätzungen und der damit verbundenen meist höheren Genauigkeit. Ein Nachteil ist die noch größere zeitliche Bindung der Experten.

Alternativen:

• Indirekte Schätzungen mit Story Points
• Indirekte Schätzungen durch Bestimmung des funktionalen Umfangs

Buchempfehlung: "Aufwandsschätzungen in der agilen Softwareentwicklung"

Agile Prinzipien sind Methoden zur Risikominderung

Viele Risiken kommerzieller Softwareentwicklung können durch agile Prinzipien gemindert werden:

Risiko: Die Anforderungen des Auftraggebers werden nicht ausreichend abgedeckt. Seine Erwartungen beispielsweise an die Gebrauchstauglichkeit des Produkts werden nicht vollständig erfüllt.
Maßnahmen: Das geplante Produkt wird inkrementell entwickelt, das heißt in möglichst kurzen Zyklen, deren Ergebnis jeweils lauffähige Software ist, die vom Auftraggeber hinsichtlich der Erfüllung seiner Erwartungen überprüft werden kann. Der Auftraggeber, insbesondere seine fachlichen und technischen Experten, arbeiten eng und intensiv mit dem Entwicklungsteam zusammen.

Risiko: Ziele und Anforderungen des Auftraggebers verändern sich, bevor die Entwicklung abgeschlossen ist, beispielsweise infolge von Veränderungen des Marktes.
Maßnahmen: Ein Prinzip des Agilen Manifests lautet: "Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden." Agile Softwareentwicklung zeichnet sich grundsätzlich durch die Bereitschaft aus, neue oder geänderte Anforderungen zu berücksichtigen. Jedoch schließt dies nicht eine Einigung zwischen Vertragspartnern bezüglich der kaufmännischen Auswirkungen von Veränderungen auf ein Entwicklungsprojekt aus.

Risiken: Falsche Einschätzung des Entwicklungsfortschritts, Verzögerungen durch Kommunikationsprobleme, Verlust von Know-how durch Personalausfall.
Maßnahmen: Diese Risiken werden in der agilen Entwicklung durch ein hohes Maß an Teamarbeit gemindert. Tägliche kurze Meetings dienen der Diskussion aufgetretener Probleme, der gemeinsamen Einschätzung des Fortschritts und der Verteilung anstehender sowie, falls es sinnvoll erscheint, auch der Umverteilung begonnener Aufgaben. Die Vermeidung starrer Rollen- und Aufgabenzuordnungen macht das Team robust gegenüber dem Ausfall einzelner Mitglieder.

Risiko: Mehraufwand durch zu spät erkannte Qualitätsdefizite.
Maßnahmen: Ein Merkmal agiler Entwicklung sind automatisierte Prozesse zur täglichen Neuerstellung einer lauffähigen Anwendung. Dabei durchläuft der Code in der Regel eine automatisierte Codeanalyse, durch programmierte Komponententests wird die Funktionalität einzelner Komponenten überprüft und, soweit möglich, werden nach der Integration zu einer lauffähigen Anwendung Skripte zur Ausführung von Testfällen aufgerufen.

Risiko: Invalide Planung hinsichtlich des erforderlichen Personalaufwands, um den Entwicklungsauftrag in der notwendigen Zeit erfüllen zu können.
Maßnahmen: Diesem Risiko kann durch die Verwendung von Aufwandsschätzmethoden begegnet werden, deren Genauigkeit sich mit jeder Retrospektive verbessert. Solche Methoden werden in meinem Buch "Aufwandsschätzungen in der agilen Softwareentwicklung" beschrieben.

Das Buch zu Aufwandsschätzungen in der agilen Softwareentwicklung

Agile Softwareentwicklung und ein fest vereinbarter Liefertermin oder Festpreis schließen sich nicht aus. Im Gegenteil: Die Prinzipien agiler Softwareentwicklung erweisen sich als gute Maßnahmen zur Minderung typischer Risiken, denen Entwicklungsprojekte mit verbindlichen Vorgaben ausgesetzt sind.

Kritisch für die Erreichung von Projektzielen ist eine verlässliche Planung, die ohne großen Aufwand erstellt und im Fall geänderter Anforderungen flexibel nachjustiert werden kann. Bewährt haben sich unter diesen Rahmenbedingungen indirekte Aufwandsschätzungen auf Basis von Umfangsmessungen. Sie erfordern einen nach präzisen Regeln ermittelten Wert für den Umfang der funktionalen Anforderungen sowie einen Erfahrungswert für die eigene Produktivität unter vergleichbaren Rahmenbedingungen.

Zum Shop

Notwendig für die Bestimmung des funktionalen Umfangs sind Kenntnisse der gewählten Methode, beispielsweise der Function Point-, Data Interaction Point- oder COSMIC-Methode, sowie eine ausreichende Präzisierung der Anforderungen, beispielsweise eine Beschreibung durch Anwendungsfälle und Elementarprozesse. Unter diesen Voraussetzungen ist der Wert, den man erhält, eine valide Kennzahl für den Umfang der funktionalen Anforderungen. Er ist unabhängig von der Person, die ihn ermittelt, und bei jeder wiederholten Anwendung auf dieselben Anforderungen erhält man den gleichen Wert. 

Einen Erfahrungswert für die eigene Produktivität, das heißt den mit einer bestimmten Arbeitsleistung des eigenen Teams typischerweise implementierbaren funktionalen Umfang, erhält man durch regelmäßige Nachbetrachtungen fertiggestellter Inkremente bzw. Releases. Dabei setzt man den implementierten Umfang mit der dafür benötigten Arbeitsleistung ins Verhältnis. Die methodische Bestimmung des implementierten Umfangs basiert – je nach Methode - auf der Zählung von beispielsweise Elementarprozessen oder Datenelementen, die bei entsprechender Abbildung auf konstruktive Merkmale automatisiert werden kann. Ein einmal erstelltes Zählprogramm kann in kürzester Zeit den Umfang der implementierten Anwendung und durch Vergleich mit dem vorhergehenden Ergebnis den durch den letzten Entwicklungsprozess entstandenen Zuwachs des funktionalen Umfangs liefern.

Regelmäßig erhobene und gegenübergestellte Messwerte für Produktivität und Qualität (im einfachsten Fall die Fehleranzahl) helfen, Handlungsbedarf zu erkennen und die Wirksamkeit zuvor umgesetzter Verbesserungsmaßnahmen zu verifizieren.

Das Buch beschreibt, wie Umfangsmetriken in der Praxis einer an agilen Werten orientierten Softwareentwicklung gewinnbringend eingesetzt werden können, welche Unterschiede und Einschränkungen es gibt, wie die Genauigkeit der Aufwandsschätzungen mit jedem Sprint erhöht werden kann und wie automatisierte Messungen möglich sind. Es ist als E-Book, Paperback und Hardcover erhältlich (im Tredition-Buch-Shop oder bei Amazon.de).
 

Buchreihe "Produktivitätssteigerung in der Softwareentwicklung"

Die PASS-Gruppe setzt seit mehreren Jahren Kennzahlen als Grundlage ihres IT-Managements in über 10 unterschiedlichen Anwendungslandschaften mit mehr als 500 Kunden und über 250.000 Anwendern ein und veröffentlicht ihre Erfahrungen nun in Form einer Buchreihe. In einzelnen Bereichen belegen die regelmäßig erhobenen Kennzahlen eine um den Faktor 100 höhere Auslieferungsproduktivität als noch vor wenigen Jahren und sie zeigen auf, in welchen Bereichen weitere Verbesserungen möglich sind.

Warum Produktivität messen?

IT hat bereits nahezu alle Lebensbereiche durch fundamentale Innovationen verändert. Unsere Zukunft wird von der Virtualisierung und smarten Helfern, also mit Intelligenz ausgestatteten Dingen, dominiert werden. Software ist der Stoff, aus dem Innovationen entstehen. Softwareentwicklung ist eine Schlüsselkompetenz.

Für Unternehmen, die Software entwickeln, sind Produktivität und Qualität kritische Erfolgsfaktoren. Nur mit geeigneten Messmethoden, durch regelmäßige Messungen und eine schnelle Rückkopplung der Messwerte an das Team und an sein Management können einerseits der Aufwand geplanter Entwicklungen zuverlässig ermittelt und andererseits Produktivität und Qualität kontinuierlich verbessert werden.

Band 1: "Produktivitäts- und Leistungsmessung - Messbarkeit und Messmethoden"

Buchreihe "Produktivitätssteigerung in der Softwareentwicklung"

Das erste Buch der Reihe erläutert zunächst eine für die Softwareentwicklung praktikable Definition des Produktivitätsbegriffs und zeigt dadurch die Bedingungen auf, unter denen Produktivität überhaupt gemessen werden kann. Es beschreibt den Standard ISO/IEC 14143 als wichtige gemeinsame Basis aller modernen funktionsorientierten Messmethoden. Einige Methoden werden im Detail und anhand von Praxisbeispielen erklärt - bewährte wie auch neue – und ihre Vor- und Nachteile gegenübergestellt. Das Buch geht auf die Automatisierbarkeit von Messungen ein, zeigt jedoch auch ihre Grenzen auf, deren Überschreitung aufgrund einer zu starken Orientierung an konstruktiven Merkmalen an Stelle von Anwendungsfällen zu invaliden Messungen führt.

Ein weiteres Thema ist der Einfluss der Komplexität auf den zu messenden Umfang, die unterschiedliche Berücksichtigung der Komplexität durch verschiedene Messmethoden und die Grenzen der Messbarkeit durch funktionsorientierte Metriken, beispielsweise bei Systemen mit überdurchschnittlich hoher algorithmischer Komplexität.

Band 2: "Managementmodell, Aufwandsermittlung und KPI-basierte Verbesserung"

Das zweite Buch beschreibt ein Modell, das auf drei Leistungskennzahlen (Key Performance Indicators, KPIs) basiert: Produktivität (gemessen unter Anwendung der im ersten Buch beschriebenen Messmethoden), Kosten und Qualität. Es erklärt ihre zyklische Erhebung, ihre analytische Auswertung und Indikatoren, beispielsweise aus der Gegenüberstellung des zeitlichen Verlaufs von Produktivität und Qualität oder als Ergebnis methodischer Fehlerursachenanalysen, die zu Verbesserungsmaßnahmen in wichtigen Einflussbereichen der Softwareentwicklung, sogenannten Key Performance Areas (KPAs), führen. Um den Nutzen der Maßnahmen vorab einschätzen zu können liefert es Erfahrungswerte wie auch ein Verfahren zur Berechnung ihrer Wirksamkeit. Das beschriebene Modell ist ein Navigationsinstrument, das dem Management stets zeigt, in welche Richtung und mit welcher Geschwindigkeit es sich hinsichtlich seiner drei KPIs bewegt.

Die Bücher sind als E-Book, Paperback und Hardcover erhältlich (im PASS-Buchshop oder bei Amazon.de).