Projektmanagement aus der Praxis der Softwareentwicklung

Projektmanagement aus der Praxis der Softwareentwicklung

Vorlesung im Wintersemester 2015/16 an der Technischen Universität Dortmund 4. Vorlesung am 30.11.2015: Qualitäts- und Risikomanagement

Oliver Hakim

Kurzprofil Oliver Hakim

Oliver Hakim

Lead Business Consultant

Ausbildung: Diplom-Wirtschaftsinformatiker Geburtsjahr: 1980

Daten und Fakten

Beruflicher Werdegang

• 2005 – 2012

sd&m / Capgemini, Consultant

• 2012 – heute

msg systems ag, Business Consultant

Methodische Schwerpunkte

• Requirements Engineering

• Fachliche Spezifikation

• Testmanagement Fachliche

Schwerpunkte

• Logistik

• Handel

AGENDA

1. Qualitätsmanagement 2. Testmanagement

3. Risikomanagement

AGENDA

1. Qualitätsmanagement 2. Testmanagement

3. Risikomanagement

Was ist Qualität ?

… z.B. bei einem Auto?

Qualität ist „subjektiv“  individuelle Anforderungen!

abhängig von Kultur, Branche, Vorgaben, Bedürfnisse, Erfahrung, Interessen…

Produkt- / Projekt- & Prozessqualität

Qualität ist das Ausmaß, in dem die Eigenschaften denen der Anforderungen genügt

Definierte und erwartete Anforderungen beachten !

Anforderungen werden im Lastenheft, Grobkonzept oder Anforderungskatalog definiert.

Umfangreiche Funktionalität

„una bella macchina“ Sicher und zuverlässig

PDCA-Zyklus – Deming-Kreis

Der PDCA-Zyklus zur kontinuierlichen Verbesserung der Qualität durch Fehlersuche und Problemanalyse

Plan

Do

Check Act

• Planung der Verbesserungsmöglichkeit

• Messmetriken festlegen

• Durchführen

• Dokumentation

• Ergebnisse Vergleichen (Soll-Ist-Vergleich)

• Ursachen ermitteln

• Lessons learned

• Verbesserungen übernehmen

Produkte werden in Prozessen erstellt  Prozesse können optimiert werden.

Qualitätsmanagement

Qualitätsmanagement (QM)

•

Leiten und Lenken einer (Projekt-)Organisation bezüglich Qualitätskriterien.

Qualitätsmanagement-Teilaufgaben

Qualitätsplanung

• Bestimmen der Qualitätsmerkmale (Anforderungen in Pflichtenheft, Normen)

• Messgrößen definieren

• Vorgehen definieren in PSP, Meilensteine mit Quality Gates

• Verantwortlichkeiten

Qualitätslenkung

• Q-Plan umsetzen

• Steuerung durch Soll-Ist-Analyse

• Ursachen finden

• Maßnahmen initiieren

Qualitätssicherung

• Überwachen der Wirksamkeit umgesetzter Maßnahmen

• Projektreviews

• Projektaudits

Qualitätsverbesserung

• Erfahrungssicherung

• Verbesserung des Vorgehens

• Projektmanagement-Audits

Qualitätsmanagement adressiert alle Phasen und Teile des Projektes

Produkt

Anforderungen: Kunde, Branche, Normen, Gesetze Vermeidung von Risiken und Fehler

Produktrealisierungs-Prozesse Produktentwicklungsphasen

Projektmanagement-Prozesse

Anforderungen: Kunde, Branche, Normen, Gesetze…

Zufriedenheit der Stakeholder Lieferanten-Management

Projektteam Qualifikation & Kompetenz (PM, Fach & Methode) Sozialkompetenz

•

Definition der Softwarequalität:



„Die Gesamtheit der Merkmale und Merkmalswerte eines Software-Produkts, die sich auf dessen Eignung beziehen, festgelegte oder vorausgesetzte

Erfordernisse zu erfüllen.“

[ISO 9126]

•

Ansätze beim Qualitätsmanagement:



Produktqualität 

Sicherstellung der Produktqualität durch Vorgabe und Überprüfung definierter Qualitätsmerkmale

(bspw. ISO 9126)



Prozessqualität 

Sicherstellung der Qualität des Entstehungsprozesses (bspw. CMMI)

Was versteht man unter Softwarequalität?

Einschränkung der Variabilität in der Systementwicklung, um gewisse Fehler nicht auftreten zu

lassen und damit ein Maß an Qualität per se zu erreichen.

Datenerhebung, um Ist- und Soll-Zustand zu vergleichen und

so den Grad der erreichten Qualität im Nachhinein

festzustellen.

Konstruktive QS-

Maßnahmen

Analytische QS-

Maßnahmen

Konstruktive und analytische Qualitätsmaßnahmen

A priori

Ex post

Verfahren der konstruktiven Qualitätssicherung

Ko nstru ktive Qua litätssich eru ng

Technische Maßnahmen

Methoden

Sprachen

Werkzeuge

Organisatorische Maßnahmen

Richtlinien

Standards

Checklisten

Verfahren der analytischen Qualitätssicherung

Analytische Qualitätssicherung

Statische Prüfung (Dokument prüfen)

Inspektion und Reviews Statische Codeanalyse Formale Verifikation

Symbolische Ausführung

Dynamische Prüfung

Tests

Black-Box

Äquivalenzklassen

Grenzwertanalyse Zustandsbezogener

Test

White-Box

Anweisungstest

Zweigtest Dynamische

Analyse

Memory Leak Analyse Performance-

messung

Softwarequalität umfasst mehr als nur die Beseitigung von Fehlern Qualitätsmerkmale nach ISO 9126 (1/2)

Funktionalität

• Umfasst Charakteristika, welche die geforderten Funktionalitäten des Systems beschreiben

• Oft durch Ein-/Ausgabeverhalten spezifiziert

• Mit Tests wird spezifiziertes Ein-/Ausgabeverhalten geprüft

• Teilmerkmale:

• Angemessenheit

• Richtigkeit

• Interoperabilität

• Ordnungsmäßigkeit

Zuverlässigkeit

• Fähigkeit eines Systems, sein Leistungsniveau unter festgelegten Bedingungen über einen definierten Zeitraum zu halten.

• Teilmerkmale:

• Reife

• Fehlertoleranz

• Wiederherstellbarkeit

Benutzbarkeit

• Teilmerkmale:

• Verständlichkeit

• Erlernbarkeit

• Bedienbarkeit

• Wichtig für die Akzeptanz der Systeme

• Benutzbarkeit ist abhängig von Benutzergruppe

• Prüfung im Rahmen von nicht-funktionalen Tests

Softwarequalität umfasst mehr als nur die Beseitigung von Fehlern Qualitätsmerkmale nach ISO 9126 (2/2)

Effizienz

• Teilmerkmale:

• Zeitverhalten

• Verbrauchverhalten

• Benötigte Zeit und Verbrauch an Betriebsmitteln für die Erfüllung einer Aufgabe

• Messbare Ergebnisse lassen sich mit Performancetest (nicht-funktionale Tests) ermitteln

Änderbarkeit und Übertragbarkeit

• Wichtige Kriterien, da Softwaresysteme oft über längeren Zeitraum eingesetzt werden.

• Änderbarkeit umfasst folgende Teilmerkmale:

• Analysierbarkeit

• Modifizierbarkeit

• Stabilität

• Prüfbarkeit

• Übertragbarkeit umfasst folgende Teilmerkmale:

• Anpassbarkeit

• Installierbarkeit

• Konformität

• Austauschbarkeit

• Aspekte lassen sich häufig nur durch statische Analysen prüfen

AGENDA

1. Qualitätsmanagement 2. Testmanagement

3. Risikomanagement

Testen verfolgt mehrere Ziele:

•

Identifizierung von Defekten

•

Bestimmung der Qualität des Produkts

•

Vertrauen in das Produkt erhöhen

•

Analyse, um Fehlerwirkungen vorzubeugen



Steigerung der Softwarequalität

natürlich nur, wenn gefundene Fehler behoben werden ;) Aber:

•

Test ist eine stichprobenartige Prüfung



Fehlerfreiheit ist durch Testen nicht erreichbar



Kein umfangreiches Softwaresystem ist fehlerfrei Zum Begriff des Testens

Test ist nur ein Bestandteil umfangreicher

Qualitäts-

maßnahmen

Planung und

•

Allgemeine

Softwareentwicklungsmodelle ordnen Test in Entwicklungsablauf ein und betrachten oft nur die

Testdurchführung

•

Fundamentaler Testprozess:

 Generischer Ablaufplan

 Anpassung an Gegebenheiten und Erfordernisse im Projekt notwendig.

(Rollen und Dokumente sind nicht beschrieben.)

 Verfeinerter Ablaufplan für das Testen.

 Aufgaben im Prozess dürfen sich überschneiden und auch gleichzeitig durchgeführt werden.

Fundamentaler Testprozess (in Anlehnung an ISTQB)

Analyse und Design

Realisierung und Durchführung Auswertung und

Bericht

Abschluss

Steuerung Beginn

Ende

Spillner, A., Linz, T.:

Basiswissen Softwaretest - Aus- und Weiterbildung zum Certified Tester dpunkt, 4. Auflage

Testen im Softwarelebenszyklus – Beispiel V-Modell

• Grundidee V-Modell

Entwicklung und Test sind zueinander korrespondierende, gleichberechtigte Tätigkeiten.

• Grundidee und daraus entstehende Prinzipien lassen sich auf andere Vorgehensmodelle übertragen.

Überblick Teststufen

Komponenten-

test Integrations- Systemtest

test Abnahmetest

• Komponenten- spezifische Anforderungen

• Softwaredesign

• Dokumente auf Systemebene, Spezifikation, Anforderungen ...

• Systemdesign

• Schnittstellen- übergreifende Workflows, UCs

• Dokumente, die System aus Anwendersicht beschreiben

• Entwickler • Tester • Tester • Kunde

Test- basis

Tester

z.B.

• Funktionalität

• Robustheit

• Effizienz

z.B.

• Erfüllt System die Anforderungen (funktional vs.

nicht-funktional) z.B.

• Schnittstellen- fehler

• Wechsel- wirkungen

z.B.

• Vorgaben Vertrag

• Akzeptanz Nutzer u.

Systembetreiber Test-

ziele

• White-Box • Black-Box • Black-Box • Black-Box

Teststra- tegie

Komponententest und Integrationstest erfolgen nicht streng sequentiell

Systemtest und Abnahmetest fallen typischerweise in die letzten Projektwochen

Frühes Testen ist wichtig für Projekterfolg

Implementierung

Komponententest

Stufenweiser

Integrationstest Systemtest Abnahmetest

•

Frühes Testen verringert die Projektrisiken

•

Frühes Testen macht Entwicklung der Produktqualität transparent

t Bereit zum Systemtest Bereit zur Abnahme

•

Komponententest soll die korrekte Funktionalität der einzelnen Systemkomponenten überprüfen.

•

Schwerpunkt ist die isolierte Prüfung der einzelnen Komponenten.

•

Komponententest wird meist durch den Entwickler durchgeführt vor der Integration

Teststufen - Komponententest

Test der

Komponenten

•

Integrationstest soll das fehlerfreie Zusammenwirken der Systemkomponenten überprüfen.

•

Die einzeln getesteten Komponenten werden schrittweise integriert und das Zusammenwirken getestet.

•

Schwerpunkt ist die Prüfung des Zusammenwirken der Komponenten. Dazu müssen die Schnittstellen in möglichst vielen Kombinationen ausgeführt werden.

Teststufen - Integrationstest

Test der

Schnittstellen

•

Systemtest ist der abschließende Test in einer realitätsnahen Umgebung (ohne den Auftraggeber), u.a.

 Funktionstest gegen die Spezifikation

 Massentest, Performancetest, Lasttest

 Usability Test

•

Schwerpunkt der Prüfung ist das Verhalten des Gesamtsystems Teststufen - Systemtest

Test des

Gesamtsystems

•

Abnahmetest wird in der Einsatzumgebung des Auftraggebers mit realen Daten unter Mitwirkung des Auftraggebers durchgeführt

 Generierung und Installation des Systems

 Testfälle für reale Geschäftsvorfälle

 Zufällige Testfälle

 Prüfung Dokumentation

•

Abnahmetest ist die Grundlage für die Abnahme durch den Auftraggeber.

Teststufen - Abnahmetest

Grundsätze des Softwaretestens (nach ISTQB)

1.

Testen zeigt die Anwesenheit von Fehlern.

2.

Vollständiges Testen ist nicht möglich.

3.

Mit dem Testen frühzeitig beginnen.

4.

Häufung von Fehlern.

5.

Zunehmende Testresistenz (Pesticide paradox).

6.

Testen ist abhängig vom Umfeld.

7.

Trugschluss: Keine Fehler bedeutet ein brauchbares System.

Basiswissen Softwaretest - Aus- und Weiterbildung zum Certified Tester dpunkt, 4. Auflage

Testarten zur Überprüfung von Qualitätszielen

Testarten

Funktionaler Test

Nicht-

Funktionaler Test

Wiederinbetrieb- nahmetest

Stresstest Lasttest Installationstest

Performancetest Interoperabilitätstest

Fehlertest

Oberflächentest Datenkonsistenztest

Sicherheitstest

•

Erneuter Test eines bereits getesteten Programms bzw. einer Teilfunktionalität

vorgenommenen Änderungen keine Fehler eingebaut oder (bisher maskierte Fehler) freigelegt wurden.

•

Regressionstest wird durchgeführt, wenn die Software oder ihre Umgebung verändert wurde.

•

Regressionstest ist grundsätzlich Bestandteil jeder Teststufe.

•

Beim Regressionstest müssen meist große Mengen von Testfällen in kurzer Zeit ausgeführt werden, daher sollte der Regressionstest aus Effizienzgründen

automatisiert werden.

Regressionstest

Erstellung von Testfällen und Testdaten

•

Testfälle werden benötigt um IT-Systeme gegenüber den Anforderungen zu prüfen

 Test der spezifizierten Funktionalität

 Test nicht funktionaler Anforderungen

 Prüfung des Systemverhaltens in Grenzsituationen

•

Testfälle sollten parallel zu Analyse und Entwurf erstellt werden, um eine zusätzliche Qualitätssicherung der Spezifikation zu erreichen.

•

Testfälle müssen zu Beginn der Tests bereits verfügbar sein, nicht erst erstellt werden!!

•

Testfälle sind ein wichtiges Entwicklungsergebnis und müssen dokumentiert werden, z.B. als Nachweis für spätere Zertifizierungen.

•

Testfälle müssen wiederverwendbar sein für spätere Releases und Regressionstest.

Erstellung von Testfällen

•

Die vollständige Abdeckung aller Ein/Ausgabe-Möglichkeiten für ein IT-System ist i.d.R. nicht möglich. Damit enthält jedes IT-System Restrisiken für Fehler.

•

Unter Beachtung der Wirtschaftlichkeit und des möglichen Schadens werden Testfälle aus der theoretisch möglichen Kombinationsmenge ausgewählt

 Bei administrativen Systemen, z. B. bei Rechnungsstellung werden Testfälle nach ihrer Wichtigkeit für den Geschäftsablauf ausgewählt.

 Bei technischen Systemen, z.B. Steuerung einer Werkzeugmaschine werden Testfälle nach den Qualitätsanforderungen des Produktionsprozess ausgewählt.

 Systeme mit Gefahren für Leib und Leben, z.B. Flugzeugsteuerung und sehr hohe Sachwerte, z.B. Raumfahrt werden sehr intensiv getestet um Risiken nachweisbar zu minimieren.

Risikobasiertes Testen

• Blackbox-Test

Der Blackbox-Test ist ein reiner Ein-/Ausgabe-Test. Die Testdaten werden aus der Spezifikation abgeleitet. Es wird nicht nur mit

zulässigen Eingabedaten getestet, sondern auch mit möglichen fehlerhaften Daten. Es werden zulässige und unzulässige

Transaktionen getestet, um das Systemverhalten zur überprüfen.

• Whitebox-Test

Der Whitebox-Test ist ein logisch-orientierter Test unter

Berücksichtigung der Abläufe im Source-Code. Die Testdaten werden mit Kenntnis der Programmlogik definiert. Angestrebt wird eine

bestimmte Abdeckung der möglichen Pfade im Source-Code.

Betrachtungsweise beim Test

• Äquivalenzklasse

Sammlung von Ein/Ausgabewerten, für die ein System das gleiche Fehlerverhalten aufweist. Für die Testabdeckung muss nur ein Testfall aus der Äquivalenzklasse ausgeführt werden.

Bei diesem Prinzip der Ableitung von Testfällen wird untersucht,

welche Klassen von möglichen Eingabewerten zu einer ähnlichen Art der Verarbeitung führen.

• Grenzwertanalyse

Die Grenzwertanalyse ist eine spezielle Form der

Äquivalenzklassenanalyse. Die Werte, die sich auf und in der

Umgebung der Grenzen der Äquivalenzklassen befinden, nennt man Grenzwerte .

Testfallerstellung mit Äquivalenzklassen und Grenzwerten

• In der Spezifikation eines Online-Banking-Systems wird gefordert, dass nur Beträge von 0,01 bis 500 € eingegeben werden dürfen. Für Tests sollte es daher ausreichen, drei Äquivalenzklassen zu bilden (eine gültige und zwei ungültige Äquivalenzklassen):

 Werte von 0,01 bis und mit 500,00 € (gültig)

 Werte kleiner gleich null (ungültig)

 Werte größer als 500,00 € (ungültig)

• Jede Überweisung im Online-Banking-System muss durch die Eingabe einer TAN

autorisiert werden. Analog zur ersten Äquivalenzklasse können hier für die Eingabe der TAN vier Äquivalenzklassen gebildet werden:

 Eingabe einer korrekten TAN

 Eingabe einer falschen TAN

 Eingabe zu kurzer TAN

 Eingabe zu langer TAN

• Auf Basis der beiden Äquivalenzklassen werden die nachfolgenden Testfälle definiert:

 Gültiger Wert (z. B. 123,45 €) und korrekte TAN (ausgeführt, weil alles korrekt ist.)

 Gültiger Wert (z. B. 123,45 €) und falsche TAN (fehlgeschlagen, weil falsche TAN.)

 Ungültiger Wert (z. B. 600,00 €) und korrekte TAN (fehlgeschlagen, weil ungültiger Wert.)

 Gültiger Wert (z. B. 123,45 €) und zu kurze TAN (fehlgeschlagen, weil TAN zu kurz ist.)

 Gültiger Werts (z. B. 123,45 €) und zu lange TAN (fehlgeschlagen, weil TAN zu lang ist.)

(/http://de.wikipedia.org/wiki/Dynamisches_Software-Testverfahren)

Beispiel für Äquivalenzklassen

• Für die Prüfung der Grenzwerte werden nicht beliebige Werte getestet, sondern nur Randwerte oder Grenzwerte. Im Beispiel wären dies die Werte

 0,00 € (ungültige Eingabe)

 0,01 € (gültige Eingabe)

 500,00 € (gültige Eingabe)

 500,01 € (ungültige Eingabe)

(/http://de.wikipedia.org/wiki/Dynamisches_Software-Testverfahren)

Beispiel für Grenzwerte

Beschreibung von Testfällen

Der Testfall wird mit

Ein/Ausgabedaten

beschrieben und kann

manuell ausgeführt und

dokumentiert werden

Werkzeuge zur Unterstützung und Automatisierung

• Manueller Test ist aufwändig und fehleranfällig, da die Konzentrationsfähigkeit von Testern begrenzt ist.

• Bei größeren Anwendungssystemen werden regelmäßig neue

Releases geliefert, die umfassend getestet werden müssen. Für den Regressionstest steht meist nur wenig Zeit zur Verfügung.

• Manche Architekturschichten haben keine Nutzeroberfläche und können daher nicht manuell getestet werden.

• Bei modernen Entwicklungsprozessen wird hochgradig iterativ

gearbeitet. Im Rahmen von Nightly Build und Continuous Integration müssen Testfälle täglich wiederholt werden.

Motivation für Testautomatisierung

Werkzeuge für Management, Steuerung von Tests

• Erfassung, Verwaltung, Überwachung von Testfällen

• Verwaltung Problem-, Fehlermeldungen

• Verwaltung von Anforderungen (Requirements)

• Konfigurationsmanagement

Werkzeuge zur Testspezifikation

• Verwaltung Vor-/Nachbedingungen von Testfällen

• Testdatengeneratoren

(datenbankbasiert, spezifikationsbasiert, …)

Werkzeuge für statische Tests

• Werkzeuge zur Reviewunterstützung

• Statische Analysen (z.B. zykomatische Anzahl)

• Model Checker

Werkzeugtypen zur Unterstützung und Automatisierung von Tests (1/2)

Werkzeuge für dynamischen Tests

• Testtreiber, Testrahmen

• Simulatoren, Testroboter (z.B. Capture-and-Replay-Tools)

• Komparatoren

• Überdeckungsanalyse, Dynamische Analyse

Werkzeuge für nicht-funktionale Tests

• Last-/Performancetests

• Monitore

Werkzeugtypen zur Unterstützung und Automatisierung von Tests (2/2)

Beispiel Testmanagement: HP Quality Center

• HP ist führendes Tool im Kontext

Testmanagement (Forrester Wave Studie)

• Browserbasiert

• Möglichkeit zur Automatisierung von Tests

mit HP Quick Test

Checkstyle

• Prüfung von Coding Conventions in Java

• Projektkonfiguration notwendig

• Integration in Eclipse möglich

FindBugs

• Durchsucht Java-Programmen nach Fehlermuster

• Fehlermuster deuten oft auf tatsächliche Fehler hin.

• Filterung bei größeren Projekten notwendig:

Anzahl der angezeigten Warnungen sehr groß

Sonograph for Java:

• Hinterlegung von Architekturmodellen für Projekt

• Identifikation von Architektur-oder Abhängigkeitsverletzungen

• Identifikation zyklischer Abhängigkeiten

Werkzeuge für statische Tests

Beispiele

•

Framework zum Testen von Java-Programmen

•

Insbesondere zur Erstellung von Testtreibern für automatisierte Unit-Tests (Klassen oder Methode)

Werkzeuge für die Testautomatisierung Beispiel JUnit

Architekturüberblick aus

„JUnit A Cook's Tour“

public class StringTest extends TestCase { protected void setUp(…)

protected void tearDown(…)

public void testSimpleAdd() {

String s1 = new String(“abcd”);

String s2 = new String(“abcd”);

assertTrue(“Strings not equal”, s1.equals(s2));

} }

Einfacher JUnit-Testfall Test erben von Oberklasse TestCase

Initialisierung des Testobjekts

Testobjekt wird geprüft mit assert-Methoden

von JUnit Zurücksetzen des

Testobjekts nach Ausführung des Tests

• In Projekten wird Testframework aufgesetzt, das die Junit-TestCase-Klasse spezialisiert.

• Initialisierung der Datenbank, Komponenten, … wird einheitlich für alle Tests gekapselt.

• Nur spezifische Initialisierungen in konkreten Tests enthalten.

JUnit: Integration in Eclipse

Vorteile

• Einfache Erstellung von Testtreibern

• Tests können automatisiert werden

• Integration in IDEs

• Regelmäßig Durchführung der Tests möglich (nightly builds)

• Projektspezifische Anpassungen möglich

• Refactorings wirken sich auch auf Testtreiber aus

Nachteile

• Keine Trennung von Testcode und Testdaten in Testtreibern

• Abhängige Komponenten müssen mit eingebunden werden in Test

• GUI-Tests nicht möglich

Vorteile, Nachteile JUnit

•

Testframework für Webanwendungen

•

Aufzeichnung manuell durchgeführter Bedienschritte

•

Bedienschritte werden als Testskript gespeichert.

•

Beliebige Wiederholung der

aufgezeichneten Skripte möglich

•

Testskripte können als HTML-Tabellen abgelegt werden

•

Selenium basiert rein auf HTML und JavaScript

•

Selenium-IDE als Firefox-Addon verfügbar

•

http://seleniumhq.org/

Werkzeuge für die Testautomatisierung - Beispiel Selenium

Capture-and-Replay-Tool

Vorteile

• Einfache Erstellung von GUI- Testtreibern

• Gut geeignet für Regressionstests

• Vernünftiges Reporting durchgeführter Testfälle

• Generierung von Testskripten möglich

Nachteile

• Keine Trennung von Testcode und Testdaten in Testtreibern

• Empfindlich ggü. Änderungen an GUI

• Kein Refactoring der Testfälle möglich

• Nachbearbeitung der Skripte notwendig

• Für langlebigen Einsatz ist angemessene Architektur notwendig (Modularisierung Testfälle, …)

Vorteile, Nachteile Selenium

Chancen

• Zeitdruck und Risiko

vermindern sich in späten Projektphasen

• Kurzfristige Absicherung von Änderungen während des Produktivbetriebs

• Absicherung von Seiteneffekten

• Kostenersparnis

• Weniger stupider Test

Risiken

• Zu wenig (Test-)Erfahrung im Team

• Ungeeignetes Werkzeug

• Sammlung von

Testwerkzeugen passt nicht zusammen

• Testfälle sind nicht wartbar oder automatisierbar

• Pflegeaufwände für Testfälle ist hoch

Chancen und Risiken durch automatisiertes Testen

•

Nicht als erstes über Werkzeuge zur Automatisierung der Testdurchführung nachdenken

•

Nur wenn ein systematischer Testprozess definiert, eingeführt und gelebt wird, kann die Produktivität durch Tests zur Automatisierung erhöht werden.

•

Reihenfolge zur Einführung von Werkzeugen

2. Konfigurationsmanagement 3. Testplanung

4. Testdurchführung 5. Testspezifikation

Automating chaos gives faster chaos*

*Fewster, M., Graham, D.:

Software Automation,

Effective use of test execution tools

Abhängig von der Anzahl Wiederholungen der Testdurchführung lohnt sich eine Testautomatisierung

Anzahl Wiederholungen Testfälle

Kosten

Manuelle Tests

Automatisierte Tests

Kosten Test-

spezifikation Kosten Implemen tierung TF Kosten Wartung TF

• Ab ca. 5 Wiederholungen lohnt sich eine Testautomatisierung

• Große Projekte laufen oft über mehrere Jahre mit mehreren Releases

 Früh über Testautomatisierung nachdenken

• Die Anzahl der entdeckten Fehler für sich alleine genommen, ist wertlos als Maß für die Qualität der

Software.

• Ist die Testqualität nicht hoch genug, so werden wenige Fehler entdeckt und damit implizit die Software als gut eingeschätzt.

• Zur Bewertung der Qualität von Software muss die Qualität des Testens betrachtet werden.

Softwarequalität

niedrig hoch

Testqualität niedrig hoch

Wenige Fehler Viele

Fehler

Wenige Fehler

Wenige Fehler

Man denkt, man ist hier…

…dabei ist

man hier! ^Quelle: D. Graham, M. Fewster:

Testing Essentials – Testing Principles.

TEST Congress, London 2000.

Eine gute Testqualität ist Voraussetzung für die Beurteilung der Softwarequalität

Erst eine gute Testqualität erlaubt zusammen mit der Anzahl der entdeckten Fehler Aussagen über die Softwarequalität.

80/20 Regel

Pareto-Prinzip

Aufwand

Nutzen

Mit 20% Testabdeckung können 80%

der Fehler gefunden werden?

In 20% der Anwendung stecken 80%

der Fehler?

20% der Fehler verursachen 80%

der Kosten?

Erkenntnis: Testaufwände auf kritische Komponenten fokussieren.

DDT

Literatur

A. Spillner, T Linz:

Basiswissen Softwaretest: Aus- und Weiterbildung zum Certified Tester - Foundation Level nach ISTQB-Standard)

• Guter Überblick über die Grundlagen des Softwaretestens.

• Vorstellung statischer und dynamischer Testverfahren, Testwerkzeuge

• Testen im Softwarelebenszyklus

• Aufgaben des Testmanagements

• Konform zum zum Certified Tester - Foundation Level

F. Westphal:

Testgetriebene Entwicklung mit JUnit & FIT:

Wie Software änderbar bleibt

• Einführung in JUnit und FIT!

• Vorgehensweise beim Test Driven Development

Webseiten

• http://www.opensourcetesting.org/ - Open Source Tools for Software Testing Professionals

• http://java-source.net/open-source/testing-tools - Üb erblick über Open-Source-Java-Testtools

• http://www.testbench.info/ - Testwerkzeug (Ebene Testmanagement)

• http://www.imbus.de/downloads/praxiswissen-softwaretest/ - Review-Formulare, Test-Tool-Requirements, …

• http://junit.sourceforge.net/doc/cookstour/cookstour.htm - Überblick über JUnit

AGENDA

1. Qualitätsmanagement 2. Testmanagement

3. Risikomanagement

Thesen

Definition Risiko:

„Ein Risiko beschreibt die Möglichkeit des Eintretens eines nicht geplanten Ereignisses bzw. des Ausbleibens eines geplanten Ereignisses mit negativen Folgen für das Projekt.“

Was sind Risiken?

Wie werden Risiken identifiziert?

Projektumfeldfaktoren

Sachlich sozial

mittelbar unmittelbar

ökonomisch

technisch

natürlich

rechtlich- politisch soziokulturell

Chancen

Risiken

Durch frühzeitige Analyse des Projektumfeldes lassen sich Chancen

und Risiken identifizieren.

Ein guter Projektleiter managt Risiken, ein schlechter Projektleiter managt Probleme.

Risiken managen

Risiken identifizieren

Risiken analysieren

Maßnahmen planen

Maßnahmen kontrollieren

niedrig mittel hoch Schadenshöhe

niedrigmittel hoch

Eintrittswahrscheinlichkeit

R1

R2

R3 R4

R5

R6

•

Für jedes Risiko sollte man sich Gedanken machen, welche Maßnahmen sinnvoll mit eingeplant werden können, um

 die Eintrittswahrscheinlichkeit (ETW in %) zu reduzieren (präventive Maßnahmen)

• Vermeiden von Risiken

• Vermindern der Eintrittswahrscheinlichkeit durch geeignete Maßnahmen

 die Schadenshöhe (SH in €) zu reduzieren (korrektive Maßnahmen)

• Begrenzen des Schadens, falls das Risiko eintritt

• Verlagern des Schadens, wenn das Risiko eintritt (z.B. Versicherung)

 Selbstragende Maßnahmen

• Akzeptieren, dass das Risiko mit berechneter Schadenshöhe existiert und darüber berichten

•

Richtwert für Umsetzen der Maßnahmen:

 wenn Kosten der Maßnahme und neuer Risikowert (RW = ETW * SH) geringer sind als der alte Risikowert

 wenn Mensch, Umwelt und Unternehmen gefährdet werden !

Die Maßnahmen werden als Arbeitspakete definiert, geschätzt und im PSP integriert!

Maßnahmen für Risiken einplanen

Nr. Risikobeschreibung / Wirkung

Ursache Auswirkung Klassifizierung

1 10 Netzwerkdrucker in der Hauptniederlassung können nicht in das neue Netzwerk integriert werden, da sie die Sicherheitsprotokolle nicht verstehen.

Die vorhandenen

Netzwerkdrucker sind zum Teil schon sehr alt.

Die Kosten für neue Drucker überschreiten das Budget

Technisches Risiko,

Wirtschaftliches Risiko

2 Die 25 Thin-Clients des GB X können für die gefundene Lösung nicht konfiguriert werden.

Das Betriebssystem auf den Thin-Clients ist ein Embedded Windows mit eingeschränkter Funktionalität. Windows XP Embedded bietet weniger Funktionalität als die neuste Version des Betriebssystems, benötigt aber auch weniger Speicher.

Kein Netzzugang und somit kompletter Produktivausfall von drei Tagen (Versandzeit neuer Hardware). Die Hardware (4GB Speicher) und das

Betriebssystem (Windows 7 Embedded) der Thin-Clients muss dann aufgerüstet werden.

Wirtschaftliches Risiko

3 Fremdrechner mittels Hackertools im Netz

Es gibt keine 100% ige Sicherheit, wenn Gäste oder Mitarbeiter Hackertools einsetzen.

Fremde (ggf. private) Rechner gelangen in das abgesicherte Netzwerk, es droht ein

Datenverlust.

Wirtschaftliches Risiko

Beispiellösung: Risiken erfassen (1 von 3)

Nr. Risiko ETW in % SH in € RW in €

1 Inkompatible Netzwerkdrucker

30% 50.000 € 15.000 €

2 25 Thin-Clients des GB X aufrüsten

30% 53.688 € 16.107 €

3 Fremdrechner mit

Hackertools im Netzwerk

2% 1.500.000 € 30.000 €

Beispiellösung: Risiken quantifizieren (2 von 3)

Nr. Risiko Maßnahme Kosten ETW neu SH neu RW neu Um- setzen 1 Inkompatible

Netzwerk- drucker

Korrektiv-Verlagern: das Thema Netzwerkdrucker kann aus dem Projekt-Scope entfernt werden, da ein Projekt zur Modernisierung der Drucker vorgesehen ist. Hierzu müssen problematische Drucker ermittelt und für die Planung des Drucker-Projektes kommuniziert werden.

680€ 30% 0 € 0 € Ja

2 25 Thin- Clients des GB X aufrüsten

Präventiv-Vermeiden: Alle Thin- Clients werden mit Speicher erweitert und bekommen das neuste Betriebssystem aufgespielt

14.688 € 0% 53.688 € 0 € Ja

3 Fremdrechner mit

Hackertools im Netzwerk

Akzeptiert: Es existiert hier keine 100% Absicherung, vor allem nicht gegen „Innen-Täter“ (Mitarbeiter).

0 € 2% 1.500.000 € 30.000 € -

Beispiellösung: Maßnahmen für Risiken planen (3 von 3)

Risikomanagement…

•

ermöglicht es, Risiken aggressiv einzugehen

•

minimiert die Kosten für Schutz- & Notfallmaßnahmen

•

Ermöglicht es Risiken objektiv zu beurteilen und angelernten Verhaltensweisen (die persönliche Risikowahrnehmungsschwelle) entgegenzuwirken

•

ist Teil eines Frühwarnsystems (PM muss Weitblick haben)

•

verhindert eine unbemerkte Verlagerung der Risikoverantwortung

•

bereitet Projekten den Weg zum Erfolg – ohne Risikomanagement haben Projekte keine Möglichkeit, zwischen gewagten Zielen und vernünftigen Erwartungen zu unterscheiden

Risikomanagement ist kritisch für den Projekterfolg

Risikomanagement

•

Vermeidung

•

Verminderung

•

Begrenzung

•

Verlagerung

•

Akzeptanz Risiken

Maßnahmen

•

Kaufmännische Risiken

•

Technische Risiken

•

Terminrisiken

•

Ressourcenrisiken

•

Politische Risiken

Instrumente und Hilfsmittel in PROFI/PRIMA

Risikoanalyse Risiko-

Behandlung

Risiko- Identifikation

RM

Initiale Risikobetrachtung

Risikomanagementplan

„PM_Risikomanagementplan_msg_tmpl.xls“

PROFI

• Risikocheckliste QM

• Risiko Kurzanalyse

• Risikoaudits Risikocheckliste für Angebotserstellung

„PM_SchaetzenUndRisiko_msg_tmpl.xls“

PROFI-Vorgehen für Individualsoftware- entwicklung

Risikoidentifikation im Projekt

Identifizierte Risiken Probleme aus früheren Projekten

Persönliche Erfahrungen

Weitere Taxonomien (z.B. vom SEI*)

Quelle: www.sei.cmu.edu Suche nach „Taxonomy-Based Risk Identification“, Report No. SEI.93-TR-006

Risikocheckliste QM: Risikokurzanalyse für Festpreisprojekte > 500.000 €

QM: Risikoaudits

Risikocheckliste

Risikoart

Prozentualer

Anteil max

Risiko- zahl

Gesamtrisiko 29% 339 99

Projekt-Ziele und -Inhalte 24% 62 15

Bes.Anford. an Lieferg./Leistg. 33% 36 12

Erfahrungen im Projektteam 71% 42 30

MA-Einsatz und Auslastung 22% 36 8

Termine 24% 17 4

Planung 32% 57 18

Verfolgung und Lenkung 0% 15 0

Modelle/Methoden/Tools 0% 12 0

Finanzielle Risiken 15% 20 3

Vertragl. Regelung 24% 37 9

Auslandsgeschäft 0% 5 0

0%

20%

40%

60%

80%

100%

Gesamtrisiko Projekt-Ziele und -Inhalte Bes.Anford. an Lieferg./Leistg. Erfahrungen im Projektteam MA-Einsatz und Auslastung Termine Planung Verfolgung und Lenkung Modelle/Method en/Tools Finanzielle Risiken Vertragl. Regelung Auslandsgeschä ft

Relatives Angebotsrisiko

Risikomanagementplan

Projekt- Ziele

Detailplan, Statusbericht Risikomanagementplan

Ist das zentrale Dokument des Risikomanagement und enthält

• Beschreibung und Bewertung aller Risiken

• die Maßnahmen zur Risikominderung

• Hilfsmittel:

oCheckliste, oRisikoportfolio, oRisikotrend

Risikomanagementplan

A - Vertrag

B - Kunde

C - Management (msg)

D - Projektteam

E - Lieferanten F -

Projektmanangement G - Anforderungen

H - Umsetzung I - Einführung

Wert / Themenbereich

9 5 4

76

8 Wahrscheinlichkeit niedrighoch

niedrig hoch

Auswirkung Diagrammtitel

0 10 20 30 40 50 60

0 1 2 3 4 5 6

Relativer Risikowert

Schadenskategorie

Schadenskategorie relativer Risikowert

Quelle:PM Studie 2008 "Erfolg und Scheitern im PM"

Top Risiken identifizieren: Was macht Projekte erfolgreich?

Risikomanagement für Projekte – RM-Prozess

Risikoanalyse Risiko-

Behandlung

Risiko- Identifikation

RM

• Risikoidentifikation ist Aufgabe des gesamten Teams

• Regelmässige Teamrunden

• Risikobewertung

- Risikowahrscheinlichkeit - Risikoauswirkung

Initiale

Risikobetrachtung

• Risikoklassifizierung

• Priorisierung

• Konsequentes Monitoring

• Aufnahme in den Statusbericht

• Einleitung von Massnahmen

• Eskalation von Risiken

Risikomanagement für Projekte – Strategien

VON NACH

Risiken ignorieren

Übertragung

Vermeidung

Minderung

Akzeptanz

Notfallplan

Vielen Dank für Ihre Aufmerksamkeit

Oliver Hakim

Lead Business Consultant – GB Travel & Logistics

Max-Planck-Str. 40, 50354 Hürth Mobil: +49 151 167 49 132

E-Mail: oliver.hakim@msg-systems.com www.msg-systems.com