Was ist Risikomanagement?
Folie 10:
Risikomanagement ist
systematische Erfassung und Bewertung von Risiken
Steuerung von Reaktionen auf festgestellte Risiken
Folie 47:
Allgemeines Risikomanagement
Einfaches und kompaktes Vorgehen
Einfacher Bewertungsalgorithmus
Klare und einfache Dokumentation
Gesunder Menschenverstand und Intuition
Keep it simple!
Welche vier Schritte werden im zyklischen Prozess des Risikomanagements durchlaufen ?
Folien 20-21, 23, 26, 38, 42, 44-46
Identifizierung
„Welche Risiken bestehen für ein Projekt ?“
In einem ersten Schritt werden mögliche Risiken für das Projekt ermittelt.
Für ein IT-Projekt kann es sehr viele und sehr unterschiedliche Risiken geben.
Es besteht die Gefahr, nur „bekannte“ Risiken zu betrachten!
Bewertung
„Welche Auswirkung hat ein Risiko ?“
Nicht alle Risiken sind gleichwertig und müssen betrachtet werden
Eintrittswahrscheinlichkeit und Schadenshöhe sind oft sehr unterschiedlich
Mittels einer einfachen Formel wird ein Wert für jedes einzelne Risiko berechnet, um eine Rangfolge der verschiedenen Risiken zu erstellen
Steuerung
„Wie kann ein Risiko reduziert werden ?“
Risikoabschwächung kostet zusätzlichen Aufwand und verursacht damit Kosten
Bei der Wahl der Behandlung eines Risikos spielen neben der Eintrittswahrscheinlichkeit und der Auswirkung auch die Kosten der Abschwächung eine Rolle
Präventivmaßnahmen - werden im Vorfeld durchgeführt und haben zum Ziel, das Risiko entweder zu vermeiden, die Schadenshöhe oder die Eintrittswahrscheinlichkeit zu verringern
Notfallmaßnahmen – werden durchgeführt, wenn das Risiko eingetreten ist und werden in der Regel im Vorfeld vorbereitet
Verfolgung
„Wie entwickelt sich ein Risiko ?!“
Risikoverfolgung ist notwendig, weil
sich Auswirkungen und Wahrscheinlichkeiten ändern,
Maßnahmen zur Abschwächung überwacht werden,
sich neue Risiken ergeben oder
Indikatoren „triggern“ können.
Risikoverfolgung erfolgt regelmäßig, wenn
ein Meilenstein erreicht ist,
sich die „Projektumgebung“ erheblich ändert oder
wenn Risikoindikatoren aktiviert werden.
Techniken:
Checklisten
Reviews
Statusübersicht
Projektmeeting
Projektreview
Geben Sie Techniken an, mit denen ein Risiko ermittelt werden kann!
Folie 24:
Risikomanagement - Identifizierung
Techniken zur Risikoidentifizierung:
Risiko-Templates und -Checklisten
Unabhängige Einschätzungen (Audits, Assessments)
Erfahrung aus abgeschlossenen Projekten
(Experten-) Interviews
(Risiko-) Brainstorming
Risiko-Workshop oder –Reviews
Ursachenanalyse
Bedrohungsszenarien
Sinnvoll ist eine Kombination von verschiedenen Techniken: „Checklisten aus vorherigen Projekten und Brainstorming mit den aktuellen Projektmitarbeitern“
Sinnvoll ist eine zusätzliche Risikobewertung durch unabhängige Personen: „Am Projekt beteiligte Personen sind eventuell voreingenommen – Externe Personen liefern vielleicht eine realistischere Einschätzung“
Beschreiben Sie kurz den Aufbau einer Risiko-Matrix ?
Welche vier Möglichkeiten haben Sie, auf ein identifiziertes Risiko zu reagieren ?
Folie 39:
Vermeiden: „Das Risiko nicht eingehen !“
Begrenzen: „Die Risikoauswirkung reduzieren !“
Behandeln: „Die Risikowahrscheinlichkeit reduzieren !“
Ignorieren: „Das Risiko akzeptieren !“
Beschreiben Sie Situationen, in denen die Wahrnehmung und Bewertung eines Risikos beeinflusst wird !
Folie 22:
Risikoeinschätzung oder -wahrnehmung
Aktive und passive Situation
Gute und schlechter Erfahrung
Optimistische und pessimistische Einstellung
Experten-und Laien-Wissen
Panik-Effekt
Risikogewöhnung
Nennen Sie die sechs Hauptqualitätsmerkmale für Software ?
Folie 52-53:
Funktionalität
Software soll die Anforderungen des Auftraggebers erfüllen
Zuverlässigkeit (Robustheit)
Software darf im Fall des Versagens keine physischen oder ökonomischen Schäden verursachen
Benutzbarkeit
Software muss sich nach den Bedürfnissen der Benutzer richten
Die Dokumentation muss in allen Detaillierungsgraden ausreichend zur Verfügung stehen
Änderbarkeit (Wartbarkeit)
Software muss anpassbar an neue Anforderungen sein
Effizienz (Verbrauchsverhalten)
Software muss ökonomischen Gebrauch von Ressourcen des unterliegenden Systems machen
Übertragbarkeit (Portabilität)
Software muss (nach wenigen Modifikationen) von einer Systemumgebung auf andere übertragbar sein
Welche zwei Hauptgebiete unterscheidet man in der Qualitätssicherung ?
Folie 72:
Analytische Qualitätssicherung
Fokus auf Fehlerfindung
Fokus auf das Produkt
Konstruktive Qualitätssicherung
Fokus auf Fehlervermeidung
Fokus auf den Prozess
Folie 73: Qualitätssicherung - Übersicht
Nennen Sie verschieden Formen von Reviews !
Folie 79-82:
Informelles Review
Beim informellen Review wird das Dokument von einem oder mehreren Gutachtern ohne formalen Prozess geprüft und mit Anmerkungen versehen.
Walkthrough
Beim Walkthroughleitet der Autor der Dokumente die Review-Sitzung und kann so zusätzliche Informationen geben. Der Walkthroughzielt darauf ab, in einem gemeinsamen Prozess Qualitätsmängel zu identifizieren und ein konsolidiertes Verständnis der Anforderungen herzustellen.
Technisches Review
Das technische Review hat die Übereinstimmung des Prüfobjektes mit Vorgaben und Standards im Fokus. Technische Reviews sind oft Experten-oder Peer-Reviews.
Inspektion
Inspektionen sind formal definierte Reviews mit festgelegten Rollen und Abläufen. Inspektionen sehen eine gründliche Vorbereitung aller Teilnehmer vor. Inspektionen sind sehr effektiv aber auch sehr aufwendig und damit teuer.
Welche Hauptphasen werden in einem Review normalerweise durchlaufen ?
Folie 78:
Ein Review besteht aus sechs Hauptphasen:
Planung
Kick-Off
Individuelle Vorbereitung
Review-Sitzung
Überarbeitung
Nachbearbeitung
Was versteht man unter einem White-Box-Test ?
Folie 98:
QS und Testen - White-Box-Testen
Folie 99-100:
Zu den dynamischen Testverfahren in der analytischen Qualitätssicherung gehört der White-Box-Test.
Das White-Box-Verfahren zählt zu den strukturbasierter Testverfahren und betrachtet die innere Struktur des Testobjektes.
Im White-Box-Test wird das Testobjekt zur Ausführung gebracht.
In der Regel müssen die zu testenden Programme vor der Testausführung „instrumentalisiert“ werden. Dazu wird der Programmcode um Zahler erweitert, auf deren Basis nach der Testausführung eine Auswertung erfolgt.
Was versteht man unter einer UR-Anomalien und warum kann ein JavaProgramm, das eine UR-Anomalie enthält, nicht ausgeführt werden ?
Folie 92-94:
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.
Drei Zustände von Variablen:
Undefiniert - Die Variable hat keinen zugewiesenen Wert
Definiert - Die Variable hat einen Wert zugewiesen bekommen
Referenziert - Der Wert der Variable wird gelesen bzw. geändert
Drei Variablen-Anomalien:
UR-Anomalie -Verwendung von Variablen ohne sie vorher zu definieren
DU-Anomalie -Definition von Variablen ohne eine Verwendung
DD-Anomalie -Erneute Definition einer Variable ohne eine Verwendung
Wie werden die Testfälle in einem Black-Box-Test ermittelt ?
Folie 114:
Folie 115-117:
Black-Box-Test bezeichnet eine Methode des Softwaretests, bei der die Tests ohne Kenntnisse über die innerer Funktionsweise des zu testenden Systems entwickelt werden.
Für die Ermittlung der Testfälle werden nur die Anforderungen, nicht aber die Implementierung des Testobjektes herangezogen.
Ziel des Black-Box-Tests ist die Übereinstimmung eines Testobjektes mit seiner Spezifikation zu überprüfen.
Der Black-Box-Test ist ein funktionaler Test.
Testfälle werden systematisch aus den Anforderungen und den Spezifikationen abgeleitet.
Fehler in den Anforderungen und den Spezifikationen können mit Black-Box-Test-Verfahren nicht festgestellt werden !
Ziel ist eine möglichst umfassende, aber redundanzarme Prüfung der Funktionalität.
Folie 118:
Black-Box-Verfahren zeichnen sich durch eine systematische Ableitung von Testfällen aus:
Äquivalenzklassenbildung
Grenzwertanalyse
Entscheidungstabellen
Ursache-Wirkung-Graph
klären Sie kurz das Äquivalenzklassen-Verfahren !
Folie 120-121:
Bei der Äquivalenzklassenbildung wird die Eigenschaft genutzt, dass jeder Wert aus einer Äquivalenzklasse ein identisches Verhalten des Testobjektes verursacht !
Die 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 eine Wert herangezogen.
Die Äquivalenzklassenbildung muss alle möglichen Eingaben und Wirkungen berücksichtigen.
Auf welcher Annahme basiert das Grenzwertverfahren bei der Testfallermittlung ?
Folie 124-125:
Die Grenzwertanalyse basiert auf der Erfahrung, dass Grenzwerte von Äquivalenzklassen häufig Fehler aufdecken.
Die Äquivalenzklassenbildung ist die Basis der Grenzwertanalyse. Die Grenzwertanalyse betrachtet gültige und ungültige Werte um den Grenzwert.
Wann benutzt man Entscheidungstabellen in der Testfallermittlung ?
Folie 127-129, 132:
Mit dem Entscheidungstabellentest kann man Kombinationen zwischen Eingabebedingungen für die Testfallermittlung darstellen.
Jede Ursache wird als Bedingung beschrieben, die aus Eingabedaten besteht und die Werte wahr und falsch annimmt.
Alle Wirkungen werden ebenfalls in die Tabelle aufgenommen.
Danach werden alle Kombinationen der Eingaben betrachtet und diesen Wirkungen zugeordnet.
Das Verfahren wird auch als Ursache-Wirkungs-Graph bezeichnet.
Die 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.
Die Zahl der Testfälle kann durch die sogenannte Konsolidierung reduziert werden:
Führen zwei Regeln zur selben Wirkung (Aktion) UND
Unterscheiden sich diese nur in einer Eingabe (Bedingung)
Nennen Sie eine unsystematische Testtechnik!
Folie 136-139:
Neben den vorgestellten Testtechniken kommen oft auch unsystematische Testtechniken zum Einsatz:
Informelles Testen
Beim adhoc-Testen („exploratorytesting“) findet keine Testvorbereitung statt.
Die Testdesign und Testausführung finden simultan statt und es wird keine spezifische Vorgehensweise befolgt.
Es gibt kein definiertes Endkriterium und es gibt keine Anforderung für die Dokumentation der Testfälle.
Für „gute“ Testergebnisse sind gute Kenntnisse von Teststrategien und besondere Test-Erfahrungen notwendig.
Intuitives Testen
Beim intuitivem Testen („errorguessing“) basieren die Testfälle auf Erfahrung und Wissen des Testers.
Testfälle basieren auf vorhandenen Fehlerlisten, Erfahrungen und Intuition.
Testfälle werden in Prosaform oder in Checkliste dokumentiert.
Intuitives Testen ist nicht formalisiert und die Ergebnisse sind bedingt wieder verwendbar.
Schwachstellenbasiertes Testen
Beim schwachstellenbasierten Testen wird nach dem Auftreten von Fehlern durch unsystematische Testtechniken an diesen Stellen der Test vertieft.
Mögliche Schwachstellen sind
besonders fehlerträchtige Module,
anfällige Schnittstellen aufgrund der Architektur und
mangelhaftes Fachwissen der beteiligter Personen.
Unsystematische Testtechniken kommen zum Einsatz bei Testobjekten mit geringem Risiko oder als Ergänzung zu anderen Testtechniken.
Nennen Sie zwei Test-Ende-Kriterien !
Test-Ende-Kriterien hängt mit White-Box-Tests und Black-Box-Tests zusammen.
Bei einfacher Software kann man alle Fälle der Software testen,
bei komplexer software geht das nicht mehr, dann muss man ein Ende definieren.
Endkriterien sind: Zeit, Budget,...
Was wird in einem Integrationstest getestet ?
Folie 143:
Im Integrationstest werden voneinander abhängige Komponenten eines Systems auf ihr Zusammenspiel in einem gemeinsamen Kontext getestet.
In der Regel sind die einzelnen Komponenten vorher im Modultest separat getestet worden.
Getestet wird neben dem Datenaustausch über die gemeinsame Schnittstelle die Gesamtfunktionalität der verbundenen Komponenten.
Der Aufwand für Integrationstest steigt mit wachsender Komponentenzahl überproportional an.
Folie 144-146:
Die Teststrategie „Bottom-Up“ beginnt mit dem Test der Basis-Komponenten und fasst diese im weiteren Test zu neuen Komponenten zusammen.
Vorteile:
Keine Platzhalter
Einfacher Testfallentwurf
Testergebnisse leicht interpretierbar
Nachteile:
Testtreiber erforderlich
Spätes, lauffähiges Gesamtsystem
Die Teststrategie „Top-Down“ beginnt mit dem Test auf oberster Ebene und setzt den Test bis zu den Basiskomponenten fort.
Frühzeitiges Simulationsergebnis
Verzahnung von Entwurf und Implementierung
Platzhalter für nicht implementierte Module notwendig
Schwierige Testfälle für BasiskomponentenQualitätssicherung
Geben Sie Beispiele für nichtfunktionale Tests !
Folie 148-152:
Durch nichtfunktionales Testen werden alle Anforderungen getestet, die nicht direkt mit der geforderten Funktionalität zu tun haben:
Zuverlässigkeit
Effizienz
Änderbarkeit
Übertragbarkeit
Performance-Test:
Das zeitliche Antwortverhalten eines Systems wird getestet.
Für einen Test sind realistischen Vorgaben für das Antwortverhalten einzelner Funktionen, Komponenten oder des Gesamtsystems notwendig.
Der Aufbau der Testumgebung muss die spätere Einsatzumgebung möglichst realistisch abbilden, damit die Testergebnisse verwertbare Aussagen liefert.
Last-Test:
Das Verhalten des System bei Belastung mit einer konstanten Menge wird getestet.
Stress-Test:
Das Verhalten des System bei kurzfristiger Überlastung wird getestet.
Volumentest:
Das System wird unter der Annahme extremer Datenmengen getestet.
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 einer langfristiger und dauerhafter Belastung getestet.
Beschreiben Sie kurz den Ablauf eines Last-Tests !
Folie 150:
Was versteht man unter einem Reifegrad-Modell ?
Folie 166-168:
Bieten „Best Practices“ an
Unternehmen adaptieren die Praktiken, um erfolgreicher zu werden und schrittweise Reifegradstufen zu erreichen
Reifegradmodelle stellen keine Prozessbeschreibung zu Verfügung
Die allgemeinen Praktiken dienen als Grundlage für die Entwicklung von Prozessbeschreibungen
Die Prozesse passen sich den betrieblichen Erfordernissen an
Reifegradstufen dienen der Orientierung
Reifegradstufen beschreiben die Verbesserung der Prozesse
Reifegradstufen geben Prioritäten für die Reihenfolge der Verbesserungsbereiche
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
Folie 199:
Reifegradmodelle sind Modelle zur Messung, Bewertung und Verbesserung von Prozessen
Reifegradmodelle 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
Die bekanntesten Modelle sind CMMI und Automotive SPICE.
Wie wird der Reifegrad einer Organisation ermittelt ?
Folie 170:
Um den Erfolg von Projekten zu verbessern, gibt es Ansätze wie CMMI, SPICE (oder TPI) mit den Zielen:
Verbesserung der Planung und Umsetzung von Projekten
Erhöhung der Transparenz über den Projektstand und –Fortschritt
Steigerung der Qualität der ausgelieferten Produkte
Senkung der Kosten während der Entwicklung und der Wartung
Verkürzung der Entwicklungszeit
Folie 171-173:
CMMI:
Grundannahme:
Eine Verbesserung der Prozesse der Softwareerstellung führt sowohl zu eine Verbesserung der Qualität als auch zu eine Verbesserung der Planung und Umsetzung.
5 Reifegradstufen:
Initial (Projektmanagement)
Gemanagt (definierte Prozesse für Entwicklung und Management)
Definiert (Erhebung von Kennzahlen)
Quantitativ gemanagt (Kontinuierliche Verbesserung)
Optimierend
Folie 198:
Spice:
Für jeden untersuchten Prozess werden die Erfüllungsgrade der neun Prozessattribute ermittelt
Aus der Erfüllungsgraden der Prozessattribute ergibt sich der Reifegrad für diesen Prozess
Jeder Prozess bekommt eine individuelle Stufe zugeordnet, aus denen sich ein Gesamtprofil ergibt
Das Gesamtprofil zeigt Verbesserungspotenziale an
Die Prozessbeschreibung der nächsten Reifegrades zeigt die Verbesserung auf
Level:
Unvollständig
Durchgeführt (Prozessdurchführung)
Gesteuert (Leistungs-/Ergebnissteuerung)
Etabliert (Prozessdefinition/-Umsetzung)
Vorhersagbar (Prozessmessung/-Steuerung)
Optimierend (Prozessinnovation/-Optimierung)
Beschreiben Sie den Six-Sigma-Kernprozess DMAIC !
Folie 206-207:
Six-Sigma:
Allgemeines Vorgehensmodell zur Prozessverbesserung
Daten und statische Analysen dienen zur Ermittlung von Problemen und Verbesserungsmöglichkeiten
Ziel sind fehlerfreie Produkte durch fehlerfreie Prozesse
Qualität entscheidet -Kundenwünsche und -zufriedenheit sind das Wichtigste
Mängel vermeiden -Keine Auslieferung von Produkten, die den Kundenerwartungen nicht gerecht werden
Prozessreife gewährleisten -Nur bei entsprechender Prozessgüte werden hochwertige Produkte erzeugt
Schwankungen gering halten -Dem Kunden muss eine gleichbleibende Qualität geliefert werden
Beständiger Arbeitsablauf -Ein konsistenter und vorhersagbarer Prozess garantiert Kundenzufriedenheit mit den Produkten
Begriff leitet sich aus der Statistik ab: Sigma bezeichnet die Standardabweichung einer statistischen Verteilung
Bei 3x Sigma ist der untersuchte Prozess zu 93,3% fehlerfrei !
Bei 6x Sigma ergeben 1 Mio. Fehlermöglichkeiten nur 3,4 Fehler !
Folie 208-210:
Six-Sigma – Kernprozess DMAIC:
DMAIC ist die häufigste Six-Sigma-Methode
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
Analyze
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
Zyklischer Projekt-und Regelkreis-Ansatz für bestehende Prozesse
Welcher Grundgedanken liegt TQM (Total Quality Management) zugrunde ?
Folie 205:
Prozesse provozieren Fehler
Alle Mitarbeiter sind für Fehler verantwortlich
Null Fehler ist das Ziel
Partnerschaft mit wenigen Lieferanten
Alles ist auf vollkommene Kundenzufriedenheit ausgerichtet
Folie 202-204:
TQM–Prinzipien:
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.
Zuletzt geändertvor einem Jahr