Nur Fragenkatalog!

Systematische Erfassung & Bewertung von Risiken & die Steuerung von Reaktionen auf festgestellte Risiken

—> umfasst Implementierung von Maßnahmen für↓ Risiken & Auswirkungen unvorhergesehener Ereignisse zu ↓

Risiko

• die Gefahr, einen Schaden o. einen Verlust zu erleiden

• ein Ereignis, das den Erfolg eines Produktes oder einer Organisation bedroht

Allgemeines Risikomanagement

• Einfaches & kompaktes Vorgehen

• Einfacher Bewertungsalgorithmus

• Klare & einfache Dokumentation

• Gesunder Menschenverstand & Intuition

—> Keep it simple!

Kreislauf!

1. Identifizierung: Welche Risiken bestehen für das Projekt?

   • IT sehr viele, Gefahr nur bekannte zu betrachten

2. Bewertung: Welche Auswirkungen hat das Risiko?

   • Eintrittswahrscheinlichkeit & Schadenshöhe oft unterschiedlich

   • Mit einfacher Formel Rangfolge

3. Steuerung: Wie kann Risiko reduziert werden

   • Risikoabschwächung kostet Aufwand/Geld

   • Präventivmaßnahmen & Notfallmaßnahmen (idR auch vorher geplant)

4. Verfolgung: Wie entwickelt sich ein Risiko?

   • Notwendig weil sich neue Risiken ergeben,

   • sich Auswirkungen/Wahrscheinlichkeiten ändern,

   • Maßnahmen zur Abschwächung überwacht werden müssen

• Risiko-Templates & -Checklisten (vorherige Projekte)

• unabhängige Einschätzungen (Audits, Assessments)

• Erfahrung aus abgeschlossenen Projekten

• (Experten) Interviews

• (Interviews) Brainstorming

• Risiko- Workshops o. -Reviews

• Ursachenanalyse

• Bedrohungsszenarien

  
  

  Sinnvoll ist,…

  —> Kombi versch. Techniken

  —> zusätzl. Risikobewertung durch unabhängige Personen

• visualisiert Risikosituation eines Produktes/Projektes in einer individuellen Darstellung

• Für:

  • Identifikation von zu behandelnden Risiken

  • Beurteilung der Effizienz von Risikomaßnahmen

• Ziel:

  • Visualisierung d. Risiken in Form der Matrix

  • Priorisierung der Risikomaßnahmen

  • Vorlagen für Ausschüsse zur Entscheidungsfindung

• Vorteile:

  • Intuitive Visualisierung der Risikosituation

  • ohne umfangreiche Vorkenntnisse sofort einsetzbar

• Vermeiden: Risiko nicht eingehen

• Begrenzen: Risikoauswirkung ↓

• Behandeln: Risikowahrscheinlichkeit ↓

• Ignorieren: Risiko akzeptieren

• Aktive u. Passive Situationen

• Gute u. schlechte Erfahrungen

• Optimistische u. pessimistische Einstellung

• Experten u. Laien Wissen

• Panik-Effekt

• Risikogewöhnung

• Funktionalität

  • SW soll Anforderungen des Auftraggebers erfüllen

  • z.B. Sicherheit, Richtigkeit

• Zuverlässigkeit/Robustheit

  • SW darf im Fall des Versagens keine physischen o. ökonomischen Schäden verursachen

  • z.B. Fehlertoleranz, Wiederherstellbarkeit

• Benutzbarkeit

  • SW muss sich nach den Bedürfnissen der Benutzer richten

  • Dokumentation muss in allen Detaillierungs- graden ausreichend zur Verfügung stehen

• Änderbarkeit (Wartbarkeit)

  • SW muss anpassbar an neue Anforderungen sein

  • z.B. Analysierbarkeit, Stabilität, Prüfbarkeit

• Effizienz (Verbrauchsverhalten)

  • SW muss ökonomischen Gebrauch von Ressourcen des unterliegenden Systems machen

  • z.B. Zeit-/Verbrauchsverhalten

• Übertragbarkeit (Portabilität)

  • Software muss (nach wenigen Modifikationen) von einer Systemumgebung auf andere übertragbar sein

  • z.B. Installierbarkeit, Konformität

Analytische Qualitätssicherung

• Fokus auf Fehlerfindung

• Fokus auf Produkt

Konstruktive Qualitätssicherung

• Fokus auf Fehlervermeidung

• Fokus auf Prozess

• Nicht nur Produkte haben Qualität, sondern auch Prozesse (was dann wiederum die Quali der Produkte verbessert)

ALLE:

• Kritische Überprüfung, Bewertung o. Analyse von etwas

• Ziel: Fehler, Inkonsistenten u Unvoliständigkeiten finden

• Überprüfung erfolgt in kl. Gruppen mit definierten Rollen

• Frühzeitige Qualitätssicherung & Verifikation im V-Modell

1. Informelles Review:

   • Dokument wird von einem oder mehreren Gutachtern ohne formalen Prozess geprüft & mit Anmerkungen versehen

2. Walkthrough

   • Autor der Dokumente leitet die Review-Sitzung & kann so Zusatz-Infos geben (mit dabei gleichgestellte Kollegen)

   • Ziel: Identifikation von Qualitätsmängeln in einem gemeinsamen Prozess & gefestigtes Verständnis der Anforderungen

3. technisches Review

   • Oft Experten- oder Peer-Reviews

   • Ziel: Übereinstimmung des Prüfobjektes mit Vorgaben & Standards

4. Inspektion

   • formal definierte Reviews mit festgelegten Rollen & Abläufen

   • Gründliche Vorbereitung aller Teilnehmer

   • sehr effektiv, aber sehr aufwendig & teuer

1. Planung: Ich will dass jemand meine BA Korrektur liest.

2. Kick-Off: Person anrufen & fragen.

3. Individuelle Vorbereitung: Person liest BA durch.

4. Review-Sitzung: Person sagt, was ich verbessern muss.

5. Überarbeitung: Fehler korrigieren.

6. Nachbearbeitung: korrigierte Fehler nochmal überprüfen & Lessons learned

• Zählt zu strukturbasierten Testverfahren & betrachtet innere Struktur des Testobjektes (man versucht dann jede Programmzeile durch Tests abzudecken)

• Testobjekt wird zur Ausführung gebracht

  • idR müssen die zu testenden Programme vor der Testausführung „instrumentalisiert“ werden

  • dazu wird Programmcode um Zahler erweitert, auf deren Basis nach der Testausführung eine Auswertung erfolgt

• White Box Test ist super aufwändig, daher nur, wenn es absolut katastrophal wäre

Datenfluss-Anomalien: Durch die statische Analyse werden sogenannte Datenfluss-Anomalien im Programmcode entdeckt. Anomalien sind Unstimmigkeiten, die zu einer Fehlerwirkung führen können, aber nicht zwingend zu einer Fehlerwirkung führen müssen.

UR: Verwendung von Variablen ohne sie vorher zu definieren

DU: Definition von Variablen ohne eine Verwendung

DD: Erneute Definition einer Variable ohne eine Verwendung

• funktionaler, anforderungsorientierter Test

• “Black Box” weil es unwichtig ist, wie das Programm aussieht, es ist nur wichtig, was das Programm kann (man sieht nur was rein und rauskommt & wenn das zusammenpasst ist Test erfolgreich)

• Methode des Softwaretests, bei der die Tests ohne Kenntnisse über die innerer Funktionsweise des zu testenden Systems entwickelt werden

• Systematische Ableitung von Testfällen aus Anforderungen & Spezifikationen:

  • Äquivalenzklassenbildung mit Grenzwertanalyse

  • Entscheidungstabellen/Ursache-Wirkung-Graph

Ziel:

• Überprüfung, ob ein Testobjekte mit seiner Spezifikation übereinstimmt

• möglichst umfassende, aber redundanzarme Prüfung der Funktionalität (wenige Durchgänge: je weniger ich teste, desto kostengünstiger ist es ——> so wenig wie möglich, so viel wie nötig)

Was kann dadurch nicht abgeleitet werden?

• Fehler in den Anforderungen und den Spezifikationen!

Black-Box-Optimization:

Man sieht auch nur was rein- und rauskommt, will hier aber bspw. die Eingabe finden, die zu der größtmöglichen Ausgabe führt.

• Menge der Eingaben wird in (möglichst wenige) Äquivalenzklassen zerlegt.

• Dabei wird angenommen, dass jeder Wert der Klasse die gleiche Wirkung erzeugt.

• Zur Bildung der Testfälle wird pro Äquivalenzklasse nur ein Wert herangezogen.

• Berücksichtigung von alle möglichen Eingaben und Wirkungen!

—> Idee dahinter: jedes Element liefert die selbe Antwort (ob richtig programmiert), deshalb reicht es, pro Klasse einen Test zu machen

• Äquivalenzklassenbildung ist Basis für Grenzwertanalyse

• Grenzwertanalyse betrachtet gültige und ungültige Werte um den Grenzwert

• Basiert auf der Erfahrung, dass Grenzwerte von Äquivalenzklassen häufig Fehler aufdecken.

• Mit Entscheidungstabellentest kann man Kombinationen zw. Eingabebedingungen für Testfallermittlung darstellen

• Alt. Bezeichnung: Ursache-Wirkungs-Graph:

  • Jede Ursache wird als Bedingung beschrieben, die aus Eingabedaten besteht und die Werte wahr & falsch annimmt

  • Alle Wirkungen werden ebenfalls in die Tabelle aufgenommen

• Danach werden alle Kombinationen der Eingaben betrachtet und diesen Wirkungen zugeordnet

Problem: Zahl der Kombinationen kann schnell unübersichtlich werden. Mit geeigneter Werkzeugunterstützung kann die Zahl der Kombinationen und damit die Zahl der notwendigen Testfälle reduziert werden. Geschieht durch Konsolidierung:

• 2 Regeln Unterscheiden dich diese nur in einer Eingabe (Bedingung) UND

• Führen zur selben Wirkung (Aktion)

Unsystematische Testfallermittlung

• Geringe Vorbereitungsaufwand

• „Schneller“ Test

• Findet die „häufigen“ Fehler ABER

  • Fehler werden übersehen

  • Schlechte Dokumentation

  • Fachwissen notwendig

  • Fehler schwer zu reproduzieren

Informelles Testen / adhoc-Testen („exploratory testing“):

• Basis: keine Testvorbereitung (Testdesign & -ausführung simultan)

• Dokumentation: keine Anforderung, kein definiertes Endkriterium

• Problem: Für „gute“ Testergebnisse sind gute Kenntnisse v. Teststrategien & besondere Test-Erfahrungen notwendig

Intuitives Testen (“errorguessing”):

• Basis: vorhandene Fehlerlisten, Erfahrungen & Intuition

• Dokumentation: Prosaform o. Checkliste

• Problem: nicht formalisiert, Ergebnisse sind bedingt wieder verwendbar.

Schwachstellenbasierten Testen:

• Basis: nach Auftreten von Fehlern Vertiefung an diesen Teststellen durch unsystematische Testtechniken

• Einsatz: Testobjekte mit geringem Risiko o. Ergänzung

• Problem:

  • besonders fehlerträchtige Module,

  • anfällige Schnittstellen aufgrund der Architektur und

  • mangelhaftes Fachwissen der beteiligter Personen.

Endekriterien sind Bedingungen, die erfüllt sein müssen, um den jeweiligen SW-Test (zB White/Blackbox) abzuschließen. Bei einfacher SW kann man alle Fälle testen, bei komplexer geht das nicht mehr, da muss man Ende definieren.

Beispiele:

• Test ist ungeeignet – Testabbruch

• Test ist erfolgreich durchgeführt worden

• Testabdeckung ist erreicht

• Vorgegebene Zahl Testfälle ausgeführt

• Testziel erreicht

• Zeit ist abgelaufen

• Vorgegebene Zahl Fehler gefunden

• Test findet keine neuen Fehler

• Kein Budget mehr

• Testziel erreicht

• WB: Anweisungsabdeckung: Alle Codezeilen müssen mindestens einmal während der Tests durchlaufen werden.

• BB: Funktionsabdeckung: Alle definierten Funktionen in der Software müssen erfolgreich getestet werden.

• Es werden voneinander abhängige Komponenten eines Systems auf ihr Zusammenspiel in einem gemeinsamen Kontext getestet

• idR sind die einzelnen Komponenten vorher im Modultest separat getestet worden

• getestet wird neben dem Datenaustausch über gem. Schnittstelle die Gesamtfunktionalität der verb. Komponenten

• Aufwand für Integrationstest ↑ mit wachsender Komponentenzahl überproportional an

Ziel:

• Fehlerfindung in Schrittstellen u. im Zusammenwirken von integrierten Komponenten

Performance-Test:

• zeitliches Antwortverhaltens eines Systems

• notwendig: realistische Vorgaben für das Antwortverhalten einzelner Funktionen, Komponenten o. des Gesamtsystems

• Aufbau der Testumgebung sollte spätere Einsatzumgebung möglichst realistisch abbilden

Last-Test:

• Verhalten des Systems bei Belastung mit konstanter Menge (Funktionen sehr schnell hintereinander o. Parallele Aktivitäten von virtuellen Benutzern)

Stress-Test:

• Verhalten des Systems bei kurzfristiger Überlastung (System bewusst über Lastgrenze gebracht)

Volumentest:

• Systemtestung unter der Annahme extremer Datenmengen

• Neben der Verarbeitung sehr großer Datenmengen (Massentest) kann auch der Betrieb mit sehr kleinen Mengen (Leere Datenbank) getestet werden.

• Im Gegensatz zum Last- und Stress-Test wird mit langfristiger und dauerhafter Belastung getestet

Reifegradmodelle

• Modelle zur Messung, Bewertung und Verbesserung von Prozessen

• Enthalten modellhafte, bewährte Vorgehensweisen, die mit den realen Unternehmensprozessen verglichen werden

• Auf Grund der Ergebnisse des Vergleichs werden neben den Reifegradstufen auch Stärken und Schwächen identifiziert und konkrete Empfehlungen gegeben

• Reifegradstufen werden durch (unabhängige) Assessments bestimmt

• In einem Assessment werden die betrieblichen Abläufe mit den Anforderungen des Modells verglichen

• Das Ergebnis eines Assessments ist eine Aussage über den Reifegrad und die Stärken und Schwächen in den einzelnen Prozessen

DMAIC ist die häufigste Six-Sigma-Methode: Zyklischer Projekt- und Regelkreis-Ansatz für bestehende Prozesse

Define

• Identifizierung und Dokumentation des zu verbessernden Prozesses und Beschreibung des Problems

• Beschreibung des gewünschten Zielzustands und der vermuteten Ursachen für die Abweichung vom Ziel

• Projektdefinition mit Mitgliedern, Ressourcen und Zeitplan

Measure

• Datenerhebung für die ausgewählten Prozesse in Hinblick auf Kundenzufriedenheit und Qualitätsmerkmale

Analyse

• Auswertung der Prozess- und Versuchsdaten

• Identifizierung der Ursachen des Problems

Improve

• Planung der notwendigen Verbesserungen

• Test der geplanten Verbesserungen

• Einführung der getesteten Verbesserungen

Control

• Überwachung des neuen Prozesses

• Kundenorientierung: Nicht was technisch machbar ist, sondern was der Kunde fordert, soll produziert werden.

• Prozessorientierung: Qualität als Ergebnis eines definierten, reproduzierbaren und permanent verbesserungsfähigen Prozesses.

• Qualitätsorientierung: Qualität hat absoluten Vorrang und bezieht sich auf das Produkt und den Prozess.

• Mitarbeiterorientierung: Jeder Mitarbeiter ist für die Qualität verantwortlich.

• Kunden-Lieferanten-Verhältnis: Durch eine frühe Einbeziehung des Kunden wird dessen Mitverantwortung für das Produkt gesteigert.

• Kontinuierliche Verbesserung: (Kleine,) Gemeinsame Fortschritte statt großer Veränderungen führen zum Ziel

• Stabilisierung der Verbesserung: Neben der Einführung von Änderungen muss deren langfristige Wirkung gefördert werden

• Rationale Entscheidungen: Entscheidungen und Änderungen sind auf Basis von Daten und Fakten zu treffen.