Copyright: Dr. Klaus Röber 1 Workshop: IT-Projektmanagement - Version 3.0 - 06/2004Modul: Projektplanung Modul Projektplanung Literatur: Informationen

Copyright: Dr. Klaus Röber 1Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung

Modul

Projektplanung

Literatur: Informationen finden sich in allen Büchern über Projektmanagement, Hier wurden insbesondere die folgenden Quellen benutzt:• Walter Gruber, Arbeitsbuch Projektmanagement, WEKA 2003)• Gerda Süß, Die wichtigsten Methoden im Projektmanagement, WEKA 2002• Capers Jones, „Software Quality - Analysis and Guidelines for Success“, International Thomson Computer Press 1997• Seminar Testmanagement, Dr. Klaus Röber


Motivation für Projektplanung

Aufwand Ohne systematische Planung:reagieren statt agieren

Mit system atischer Planung:agieren statt reagieren

Angemessener Aufwand für Planung sichert den Projekterfolg!

Projektlaufzeit


Projektplanung

Die Projektplanung hat folgenden Zweck:

- Systematische Informationsgewinnung über den zukünftigen Ablauf des Projekts- Schaffung einer Basis für realistische Sollvorgaben- Schaffung einer Basis für die Kontrolle des Projektfortschritts- Schaffung einer Basis für die Steuerung des Projekts

Sie verläuft phasenorientiert iterativ und wird für jedes der ggf. im Projektauftragdefinierten Teilprojekte separat durchgeführt

Projektplan

Phase 1 Phase 2 Phase n

Phasenplan 1

Phasenplan 2

Phasenplan n

Projektplan überarbeitet

Projektplan überarbeitet

............................

.........


Kernprozesse der Projektplanung

Projektstrukturierung Was ist alles zu tun?

Meilensteinplanung Welches sind wichtige Ereignisse im Projektverlauf?

Einsatzmittelbedarfsplanung Wie viel Arbeitsaufwand und welche sachlichen Einsatzmittel sind zur Erbringung von Arbeitsergebnissen notwendig?

Terminplanung In welcher Reihenfolge und zu welchen Terminen müssen die Arbeitspakete abgearbeitet werden?

Kostenplanung Wie viel Kosten verursachen die einzelnen Arbeitspakete?

Planoptimierung Stimmt der bis dahin geplante Projektverlauf mit den Wünschen des Auftraggebers überein?

Risikomanagementplanung Sind die Aktivitäten des Risikomanagements für das Projekt definiert?

Integrationsmanagement Ergibt sich bei der Zusammenführung der Ergebnisse aller Planungsprozesse ein aufeinander abgestimmtes, schlüssiges Dokument?


Unterstützungsprozesse der Projektplanung

Risikoanalyse Was könnte mein Projekt gefährden und welche Maßnahmen kann ich dagegen treffen?

Qualitätsplanung Sind die Qualitätsstandards definiert und ist geplant, wie sie eingehalten werden können?

Kommunikationsplanung Ist festgelegt, wer welche Informationen wann und wie erhält?

Die Kernprozesse sind in einer zeitlichen Abfolge zu sehen, die allerdings durch Schleifen infolge neuer Erkenntnisse, Anforderungen des Kunden u. Ä. zumeist mehrmals durchlaufen werden (denken Sie an das Teufelsquadrat!).

Die Unterstützungsprozesse können dagegen nicht einzelnen Kernprozessen zugeordnet werden, sie sind prozessübergreifend.


Der Projektplan

ist das zentrale Planungs- und Steuerungsinstrument des Projektmanagements für die konkrete Projektdurchführung.

besteht aus einer Reihe von Einzelergebnissen, die nur in ihrer Gesamtheit alle Planungsaspekte eines Projektes widerspiegeln, z. B.:

– Aktivitäten/Arbeitspakete (Aufwand, Ressourcenzuordnung, Termine)

– Projekt-Meilensteine

– Ressourcenplan

– Teamorganisation

Der Projektplan wird während des Projektverlaufs ( jeweils nach Genehmigung durch den Auftraggeber / Sponsor ) fortgeschrieben.

Ergebnis der Planung: Der Projektplan


Einige Begriffe

Zeit

- Aufwand - Spanne - Punkt

= Ressourcen-verbrauch

= Dauer = Termin

Z.B. 2 MT(Menschtage)

Z.B. 2Arbeitstage

Z.B. 9.9.200014.00 Uhr


Eine Projekt-Baseline ist ein Element ( Eckwert ) der Planung, welches anschließend auch gemessen wird.

Dazu gehören z.B. Umfang, Termine, Aufwand, Kosten, Ressourcen. Zwischen der Verabschiedung des Projektauftrags und dem Start der

Detailplanung kann u.U. ein längerer Zeitraum liegen. Deshalb müssen diese, im Projektauftrag definierten, Baselines in dieser

Aktivität überprüft werden, um sie gegenüber dem Management zu bestätigen oder sie bei gravierenden Veränderungen ggf. neu vom Management genehmigen zu lassen

Arbeitsschritte: Überprüfen, ob die aktuelle Planung mit den gemeinsam vereinbarten

Baselines übereinstimmt Eskalation gegenüber dem Auftraggeber/Sponsor (wenn erforderlich)

Bestätigung der Projekt-Baselines


Phasenmodelle als Grundlage der Projektplanung

Phasenmodelle dienen der Zerlegung eines Projekts in seine einzelnen Lebensphasen

Sie grenzen inhaltliche Abschnitte voneinander ab und setzen sie in einen zeitlichen Bezug zueinander

Entscheidungen über den weiteren Projektverlauf werden häufig am Ende einer Phase getroffen

Die Phaseneinteilung dient als Grundlage für Projektstruktur-, Ressourcen- und Kostenplanung

Phasenmodelle werden meist aus Gründen der Anschaulichkeit graphisch dargestellt

Allgemeine Phasenmodelle können an spezifische Projekterfordernisse angepasst werden

Vgl. dazu Modul Vorgehensmodelle


Projektstruktur-Planung

Voraussetzung:

Zweck:

Verfahren:

- Lastenheft oder Pflichtenheft

- Projekt überschaubar machen- Teilprojekte bilden- Projekt abgrenzen- Vollständigkeit sicher stellen- Ressourcen und Ergebnisse planbar machen- Durchführung kontrollierbar machen

- empirisch-induktiv - systematisch-deduktiv

(wenn Projekt schwer überschaubar)

(wenn Projektüberblick gegeben)


Empirisch-induktive Planung („Bottom-up“)

Den Bottom-up Ansatz wählt man dann, wenn kein Vorgehensmodell für das Projekt existiert und man sich über die Vorgehensweise noch im Unklaren ist.

Im ersten Schritt werden alle Aktivitäten und/oder Teilziele ohne jegliche Ordnung aufgeschrieben. Hierbei handelt es sich um einen Kreativitätsprozess, bei dem auch Kreativitätstechniken wie z. B. Mind-Mapping oder Brainstorming sinnvoll eingesetzt werden können.

Als Nächstes werden die so gefundenen Aktivitäten und/oder Teilziele nach Oberbegriffen geordnet, diese evtl noch einmal in einer übergeordneten Ebene zusammengefasst usw.

So entsteht nach und nach eine Struktur, die im letzten Schritt nochmals von oben nach unten auf Vollständigkeit hin überprüft werden muss.


Systematisch-deduktive Planung

Diesen Ansatz wählt man, wenn man das Projekt gut überschaut und ein Vorgehensmodell vorhanden ist

Auswahl eines Prozessmodells (Vorgehensmodells = Modell des Entwicklungsprozesses, z. B. das bekannte V-Modell)

Editieren des Prozessmodells Zerlegung der Aufgaben des Prozessmodells in Vorgänge

bzw. Teilaufgaben Gruppieren der Teilaufgaben in Arbeitspakete


Projektstruktur-Plan

- Aufgaben- Teilaufgaben- Arbeitspakete (AP) - kann geschlossen an eine Org.-Einheit delegiert werden - beinhaltet ein als Zielgröße definiertes Ergebnis - Reihe der Arbeitspakete ergibt den Projektablaufplan - Summe der Arbeitspakete zeigt den Leistungsumfang eines Projekts

Strukturelemente

Arbeits-paket

Teil-Aufgabe

Aufgabe


Merkmale eines Projektstruktur-Plans

- objekt-, aufbau-, erzeugnisorientiert- funktionsorientiert- gemischt

- hierarchisch: Schubladenplan/Standardstrukturplan Aufgabe-Teilaufgabe-Arbeitspaket- zeitlich: Standard-Projektplan Arbeitspaket-Vorgänge

Möglichkeiten der Strukturierung

Möglichkeiten der Standardisierung

EntwicklungMaschine

Gehäuse Schalt-technik

Hard-ware

Soft-ware

Steuerung

Beispiel: objektorientierte Strukturierung


Beispiel: Projektstrukturplan (www.hms-hopf-management.de)


Beispiel: Projektstrukturplan (www.webagency.de)


Beispiel: Projektstrukturplan (www.albbw.de)


Beispiel: Formular zur Arbeitspaketbeschreibung

Quelle: Gruber


Übung zur Projektstrukturierung (1)

Ihre Aufgabe ist es, ein Projektmanagement-Tool einzuführen. Da dies kein Standardprojekt ist, für das es ein Vorgehensmodell gibt, wählen Sie die empirisch-induktive Methode.

Arbeit im Team (3 – 5 Personen) Zeit 30 Minuten Präsentieren Sie anschließend das Ergebnis im

Plenum


Musterlösung

Quelle: Gruber


Übung zur Projektstrukturierung (2)

Situation in der Fallstudie: Sie befinden sich mit ihrem Projektteam in der Startsitzung

zu Beginn der Teilphase „Spezifikation Sollkonzept“ für das Teilprojekt 1 „Entwicklung Auftragsabwicklung“ Machen Sie gemeinsam für diese Phase eine Aktivitätenplanung

Vorschlag für die Vorgehensweise:– Nehmen Sie die Liste der Endprodukte des

Sollkonzepts und entscheiden Sie, ob Sie die „kann“ – Endprodukte brauchen oder nicht

– Überlegen Sie, welche Aktivitäten Sie durchführen müssen, um Endprodukt zu erstellen

Zeit: 30 Minuten Präsentieren Sie anschließend das Ergebnis


Meilensteinplanung

Meilensteine sind wichtige Ereignisse im Projektverlauf. Sie markieren den Abschluss oder Beginn von wichtigen Projektschritten.

Sie ergeben sich aus der Projektstruktur, d. h. Zergliederung des Projektziels in Teilziele (s. Projektstrukturplan)

Meilensteine sind Punkte, an denen eine Entscheidung über den weiteren Projektfortgang gefällt werden kann.

In der Regel sollte beim Erreichen des Meilensteins eine Reviewsitzung (s. Qualitätsplanung) durchgeführt werden, in der die zum Meilenstein erreichten Arbeitsergebnisse überprüft und freigegeben werden.

Meilensteine können so sog. Meilensteinplänen zusammen gefasst werden Diese geben einen schnellen Überblick über die wesentlichen Eckpunkte der Projektplanung und sind deshalb auch zur Information des Managements geeignet.

Außerdem sind richtig definierte Meilensteine die Basis für ein effektives Controlling-Instrument, der Meilenstein-Trendanalyse (s. Steuerungsprozesse).


Wie werden Meilensteine definiert?

Zur Definition eines Meilensteins gehören:- MS-Name- MS-Verantwortlicher- Termin für die Erbringung der MS-Ergebnisse- festgelegte MS-Ergebnisse (z. B. Dokumente, Prototypen, Modelle, Programme)

Quelle: Süß


Meilenstein-Plan: Beispiel

Nr. Vorgangsname Arbeit Dauer

1 Antragsbogen erfassen 3.501 Std. 89,91 Tage

5 Meilenstein Inkrement 1 Antragsbogen 0 Std. 1 Tag

6 Bedarfe 2.592 Std. 90,91 Tage

10 Meilenstein Inkrement 2 Bedarfe 0 Std. 1 Tag

11 Berechnung 2.234 Std. 83 Tage

15 Meilenstein Inkrement 3 Berechnung 0 Std. 1 Tag

16 Zahlung/Buchung 4.480 Std. 124 Tage

20 Meilenstein Inkrement 4 Zahlung/Buchung 0 Std. 1 Tag

21 Druckausgaben 2.487 Std. 130 Tage

25 Meilenstein Inkrement 5 Druckausgaben 0 Std. 1 Tag

26 Datenanalysen/Schnittstellen 3.463 Std. 146 Tage

30 Meilenstein Datenanalysen/Schnittstellen 0 Std. 1 Tag

31 Produkt-Test und -Abnahme Gesamtsystem 952 Std. 111 Tage

35 Meilenstein Betriebsbereitschaft Gesamtsystem 0 Std. 1 Tag

30.10.

26.12.

14.02.

07.06.

24.08.

12.11.

03.12.

Jul Aug Sep OktNov Dez Jan FebMrz Apr Mai Jun Jul Aug Sep Okt NovDez Jan FebMrz3. Quartal 4. Quartal 1. Quartal 2. Quartal 3. Quartal 4. Quartal 1. Quartal


Einsatzmittelbedarfsplanung

In der Einsatzmittelbedarfsplanung wird ermittelt, welche physischen Einsatzmittel (die drei M: Mensch, Maschine, Material) in welcher Menge zur Abarbeitung der einzelnen Arbeitspakete benötigt werden.

Dabei ist es hilfreich, sich zugleich die Frage nach den benötigten Qualifikationen und Sachmitteln zu stellen,:

Sind sie vorhanden oder müssen sie beschafft werden? (z. B. Computer, Drucker, Büromöbel).

Die Ermittlung des Einsatzmittelbedarfs ist die Grundlage für eine Kostenschätzung und –planung.

Wichtigster und schwierigster Unterpunkt bei der Einsatzmittelbedarfsplanung ist die Aufwandsermittlung, da einer bestimmten Menge menschlicher Arbeit nicht immer ein eindeutiges Ergebnis zugeordnet werden kann.

Methoden zur Aufwandschätzung haben wir im Modul „Aufwandschätzung“ betrachtet. Für die Detailplanung eignen sich insbesondere die Bottom-Up Methode bzw. die Expertenschätzung (s. Delphi Methode).


Erinnerung: Aufwandsschätzung

Als Aufwand bezeichnet man die mit einer Tätigkeit verbundene Arbeitsmenge

Jede Schätzung basiert auf Erfahrungen Ziel des Einsatzes von Aufwandsschätzverfahren ist

– gemachte Erfahrungen zu sichern

– den Zugriff auf gesicherte Erfahrungen personenunabhängig zu ermöglichen

Um eine realitätsnahe Schätzung zu erreichen, sollte man sich einer methodischen Unterstützung bedienen

Methoden der Aufwandsschätzung als Mittel zur Projektkalkulation gewinnen immer mehr an Bedeutung, da hierauf alle Plandaten aufbauen

Basis für die Aufwandsschätzung ist das zuvor entwickelte Ergebnis der Strukturierung

Die Schätzung ist als Prozess zu begreifen. Es muss möglich sein, in Abhängigkeit vom Zeitfortschritt mehrere Schätzungen abzugeben


So geht man vor

Basis für die Aufwandschätzung sind die Arbeitspakete aus dem Projektstrukturplan. Jedes Arbeitspaket wird für sich allein betrachtet:– 1. Abschätzen der Arbeitsmenge (= Aufwand, Einheit z. B. Personentage [PT] oder –

stunden [Ph]), die voraussichtlich notwendig sein wird, um das Ziel des Arbeitspakets zu erreichen. Da jede Schätzung einzig und allein auf Erfahrungen basiert, ist es zur Verbesserung der Aufwandschätzung notwendig, Erfahrungssicherung zu betreiben. Beim Schätzen des Aufwands für ein Arbeitspaket sollte unbedingt der zuständige Mitarbeiter mit eingebunden sein – der Projektleiter allein wird dies in der Regel nicht leisten können. Der geschätzte Aufwand sollte möglichst nach den einzelnen Ressourcen getrennt sein.

– Schätzen der Intensität, mit der eine Ressource diesen Aufwand erbringen kann (Personaleinsatz, Einheit entweder in % oder z. B. in [Ph/Tag]). Urlaube, Schulungen oder sonstige geplante Abwesenheiten von Ressourcen werden in diesem Stadium noch nicht berücksichtigt. Dies erfolgt im Rahmen der Planoptimierung.

– Aus den beiden Größen Aufwand und Personaleinsatz lässt sich ableiten, welcher Zeitbedarf (= Dauer, Einheit in Tagen [t], Wochen [w] oder Stunden [h]) für die Durchführung eines Arbeitspakets notwendig ist.

Dauer = Aufwand/Personaleinsatz– Hat man im ersten Schritt bereits die Aufwände für die einzelnen Ressourcen

getrennt, ergibt sich je Ressource eine individuelle Arbeitsdauer. Die längste Bearbeitungsdauer ist die Gesamtdauer des Arbeitspakets.


Ein einfaches praktikables Verfahren

„Expertenschätzung in Konferenz“ Methode– Jedes Mitglied schätzt zunächst für sich den Aufwand für jede der einzelnen

Aktivitäten– Dann werden die Schätzergebnisse miteinander verglichen und die Gruppe

einigt sich auf einen gemeinsamen Wert. Es wird dabei empfohlen, die Diskussion mit den zentralen und wichtigen Aufgaben zu beginnen.

– Zum Schluss überprüft die Gruppe noch einmal, ob die gefundenen Schätzwerte für die einzelnen Aufgaben auch in Relation zueinander sinnvoll sind und gleicht sie gegen die Planvorgaben aus dem Projektauftrag ab..

Dieses Verfahren eignet sich sowohl für die Planung in sehr frühen Phasen als auch für die Detailplanung und auch für ungewöhnliche Projekte, wo wenig Vergleichszahlen vorliegen

Es nutzt das Wissen aller Projektmitarbeiter, nicht nur das des Projektleiters. Und vor allem: alle Teammitglieder wissen durch die gemeinsame Diskussion, was

mit der Aufgabenstellung gemeint ist und unter welchen Vorannahmen die Schätzung zustande gekommen ist. Deswegen wird auch die Gefahr von Missverständnissen deutlich verringert und die Mitarbeiter melden sich früher beim Projektleiter, wenn sie während der Arbeit merken, dass der Aufwand höher ausfällt aufgrund bisher nicht bekannter Umstände...


Beispiel zur Aufwandschätzung (Quelle: Süß)

AP-Nr. AP-Bezeichnung Bearbeiter Aufwand [PT]

PE [%] Dauer [Tage]

1.1 Detailplanung

Programminhalte

Müller 5 50 11,5

Schmitt 5 50 11,5

Meier 10 100 11,5

Huber 10 100 11,5

1.2 Erstellung Texte

Schmitt 5 100 5,75

Huber 15 100 17,25

1.3 Programmierung

Müller 20 100 23

Personentag ist ja bekanntlich nicht gleich Tag. Dies kann man mit einem Aufschlag vonx% auf den Aufwand berücksichtigen: Dauer = (1 + x)*Aufwand/Personaleinsatz. Beispiels-Weise rechnet man oft mit 15% Aufschlag.


Übung: Aufwands- und Zeitbedarfsschätzung

Machen Sie jetzt für die eben erstellte Aktivitätenplanung (s. Übung 1 zur Projektstrukturierung) eine Aufwandsschätzung. Verwenden Sie dabei die Methode „Expertenschätzung in Konferenz“.

Gehen Sie dabei von folgenden Verfügbarkeiten aus: Hr. Huber 50%, Hr. Klaus 80%, Fr. Schubert 100%, Fr. Seibert

100%, Hr. Stern 50%, Fr. Ansorge 100%. Als sog. „Verteilzeiten“, d. h. Zeiten, in denen der Mitarbeiter nicht

für das Projekt arbeitet, sondern anderen Beschäftigungen nachgeht (Administration, Abteilungsbesprechungen, private Kommunikation etc.) setzen Sie 15% an.

Bei der Berechnung wird auf halbe Tage gerundet. Zeit 30 Minuten


Aufwandschätzung Musterlösung

AP-Nr. Bezeichnung Mitarbeiter Aufwand [PT]

PE [%] Dauer [Tage]

Konzeption erstellen

1.1 Fachkonzept erstellen Hr. Huber 6 50 14

1.2 Berichte erstellen Hr. Klaus 10 80 14,5

1.3 Technikkonzept erstellen Fr. Schubert 12 100 14

Umsetzung und Test durchführen

2.1 Änderungen im Tool vornehmen Fr. Schubert 12 100 14

2.2 Anschließen an die Datenbank Fr. Schubert 10 100 11,5

2.3 Test durchführen Fr. Seibert 5 100 6

Pilotprojekte durchführen

3.1 Einführung in das Tool Hr. Stern 2 50 4,5

3.2 Support der Pilotprojekte Hr. Stern 20 50 46

3.3 Abschlussbericht erstellen Hr. Stern 2 50 5

Inbetriebnahme durchführen

4.1 Änderungen lt. Pilotprojekt umsetzen Fr. Schubert 10 100 11,5

4.2 Anwenderschulung durchführen Fr. Ansorge 20 100 23

4.3 Installation Fr. Schubert 1 100 1,5


Die häufigsten Fehler bei der Aufwandschätzung

Erfahrungsgemäß fallen Aufwandschätzungen zu neuen Themen oder von Mitarbeitern, die nur selten bewusst Aufwände schätzen, eher zu niedrig als zu hoch aus.

Viele Mitarbeiter trennen Aufwand und Dauer nicht scharf. Der Aufwand hängt jedoch vom zu erbringenden Arbeitsinhalt ab, die Dauer kann dagegen durch mehr oder weniger intensives Arbeiten an einem Arbeitspaket beeinflusst werden.

Eine bewusste und systematische Erfahrungssicherung, Grundvoraussetzung für eine fundierte Aufwandschätzung, wird häufig aus Zeitmangel oder anderen Gründen nicht gemacht.

Viele Angaben zum voraussichtlichen Aufwand werden unter dem Druck knapper Ressourcen und enger Terminpläne gemach – und sind deswegen von vornherein unrealistisch.

Auch Projektmanagement und Qualitätsmanagement verursachen Aufwand. Dieser wird jedoch häufig nicht in die Planung einbezogen.


Initiieren von Beschaffungen

Diese Aktivität ist dann durchzuführen, wenn aufgrund des aktuellen Ressourcenbedarfs für das Projekt Beschaffungen von Sachmitteln oder Dienstleistungen erforderlich sind.

In diese Aktivität ist der Sponsor eingebunden.

Arbeitsschritte:

Präzisieren Ressourcenbedarf Formulieren Beschaffungsanforderung (entspr. Unternehmensregeln) Initiieren Beschaffung ( über Einkauf )

Ergebnis:

Beschaffungsanforderung (entsprechend Firmen-Standard)


Terminplanung

Ziel der Terminplanung ist

Vorgehen

Die Abhängigkeiten können in einem Netzplan dargestellt werden oder, wenn die Verhältnisse einfach sind, in einem Balkendiagramm. Das Balkendiagramm eignet sich auch für die übersichtliche Darstellung der Termine.

Die logisch-zeitliche Abfolge der im Rahmen der Auftragsabwicklungvon den internen und externen Stellen abzuarbeitenden Vorgänge

festzulegen sowie die auftragsfremden Vorbedingungen einzubeziehen,die zwar nicht zum Auftragsumfang gehören, die aber Voraussetzungen

für die Erbringung der eigenen Leistungen sind

Um die logisch und sachlich erforderlichen Abhängigkeiten zu ermitteln, werden die zu erledigenden Arbeiten erfasst und ihreBeziehung zu vorhergehenden und nachfolgenden Aufgabenanalysiert:

- Welche Arbeitspakete können unabhängig voneinander durchgeführt werden?- Welche Arbeitspakete sind unmittelbare Voraussetzungen?- Welche Arbeitspakete können unmittelbar folgen?


Ablauf- und Terminplanung: Grafische Darstellung

Vo rg a n g

D ata P o in ts

Frühester/SpätesterBeginn/Ende

Vorgang

Ressourcen

Meilen-stein

Vorgangsabhängigkeiten

Netzplan

Vorgang 1

Vorgang 2

Vorgang 3

Januar Februar März April

VorgangszeitplanGantt-Diagramm

Meilen-stein

Meilen-stein

M eilen-stein

M eilen-stein

Modul Netzplantechnik und Balkendiagramme


Planoptimierung

Die bisher erstellte Planung berücksichtigt noch nicht das Umfeld des Projekts. So wurden bis jetzt weder die evtl. mit dem Auftraggeber vereinbarten Meilensteintermine eingearbeitet noch die Verfügbarkeit der Ressourcen berücksichtigt. In der Planoptimierung wird dies ganz systematisch nachgeholt.

Die für eine Planoptimierung relevanten Größen können sich auf eine oder mehrere der drei wichtigsten Planungselemente beziehen:– Ressourcen – z. B. durch die begrenzte Verfügbarkeit, Urlaub oder

anderweitig geplante Abwesenheiten– Termine – z. B. in Form von bereits mit dem Auftraggeber vereinbarten

Meilenstein-Terminen, die in die Planung einzuarbeiten sind.– Kosten – z. B. durch eine Liquiditätsplanung bei großen kapitalintensiven

Projekten.


Planoptimierung nach Ressourcen – das Belastungsdiagramm

Hauptinteresse bei der Optimierung eines Projektplans wird i.d.R. die Auslastung der Ressourcen sein. Um diese mit in den Projektplan einzubinden, wird das sog. Belastungsdiagramm (auch Ressourcenhistogramm oder Ressourcengrafik genannt) angewendet.

Es besteht aus zwei Grundelementen: – der Ressourcenverfügbarkeit (in der Grafik auf der nächsten Folie gestrichelte

Linie) und– dem Ressourcenbedarf (in der Grafik farbige Flächen)

Die Ressourcenverfügbarkeit bildet die voraussichtliche Kapazität ab, mit der die Ressource (also z. B. ein Mitarbeiter) für das Projekt zur Verfügung steht. Ist der MA im Urlaub, sinkt die Linie auf Null.

Der Ressourcenbedarf ergibt sich aus der bisherigen Planung. Die Größe der farbigen Flächen spiegelt den geschätzten Aufwand wider, die zeitliche Lage ergibt sich aus der Netzplanrechnung.

Die Gegenüberstellung von Verfügbarkeit und Bedarf gibt Auskunft darüber, ob die geplanten Aufwände in der dafür vorgesehenen Zeit erbracht werden können. Übersteigt der Bedarf die Verfügbarkeit (wie in der Grafik zu sehen), ist die Planung so nicht realisierbar. Sie muss nochmals überarbeitet werden. Prinzipiell gibt es dafür zwei Möglichkeiten: – Termintreue Planung und– Kapazitätstreue Planung


Belastungsdigramm

Ressourcenverfügbarkeit

Zeit

Noch freie Kapazität Überlastung

AP 1.2

AP 1.1

AP 2.1

AP 3.1

AP 3.2

AP 4.2

100%


Termintreue Planung: Ressourcenerhöhung

Zeit

Noch freie Kapazität

AP 1.2

AP 1.1

AP 2.1

AP 3.1

AP 3.2

AP 4.2

100%

120%


Ressourcenerhöhung

Da die Termine als fest angesehen werden (eine Verschiebung darf nur innerhalb der errechneten Pufferzeiten durchgeführt werden), müssen die Ressourcen – zumindest zeitweise – erhöht werden. Dies kann z. B. geschehen durch:– Umschichtung von Ressourcen innerhalb des Betriebes– Inanspruchnahme von Fremdleistungen– Neueinstellungen, Einkauf– Vergabe an Fremdfirmen– Mehrschichtbetrieb– Überstunden


Kapazitätstreue Planung: Terminänderung

Ressourcenverfügbarkeit

Zeit

Noch freie Kapazität

AP 1.2

AP 1.1

AP 2.1

AP 3.1

AP 3.2

AP 4.2

100%


Und wenn beides nicht klappt?

Führen beide Planungsansätze nicht zum Ziele, nämlich das geforderte Ergebnis in der geforderten Zeit zu bringen, kann nur noch die Höhe des Aufwands, also das Arbeitsvolumen reduziert werden, z. B. durch Verminderung des Auftragsumfangs oder der Qualität.

Beider kapazitätstreuen Planung bieten viele PM-Tools Algorithmen zur Optimierung der Ressourcenauslastung an, die auch projektübergreifend im sog. Multiprojekt-Modus (also für mehrere Projekte gleichzeitig) funktionieren. Je nach Programm sind die Ergebnisse dieser Optimierungsalgorithmen mehr oder weniger brauchbar.

Achtung - Vorsicht ist geboten: Sichern Sie auf jeden Fall Ihren Planungsstand, bevor Sie auf den Button „optimieren“ drücken. Die Optimierungsrechnung hat immer nur Vorschlagscharakter – Sie müssen entscheiden, ob sie brauchbar ist oder nicht. Wenn Sie Ihre Daten nicht gesichert haben, können Sie nicht mehr zurück und verlieren unter Umständen viel Arbeit.


Planoptimierung nach Terminen

Ziel ist es, die bereits vereinbarten Termine in die Planung mit einzubeziehen, insbesondere Meilensteine, für die bereits ein Termin vereinbart wurde (z. B. Pilotversion ist fertig gestellt bis 15.7.).

Prinzipiell bedeutet das manuelle Festlegen von Terminen immer ein Eingreifen in die Netzplanlogik – was eigentlich vermieden werden sollte, um dem Netzplanalgorithmus maximale Freiheit zu geben.

Beispiel:– Ein Meilenstein kann laut Netzplanrechnung frühestens am 15. 8.

abgeschlossen sein. Laut Vereinbarung mit dem Auftraggeber muss der Meilenstein spätestens am 1. 9. erreicht sein. Fügt man diese Bedingung in den Netzplan ein (spätestes Ende des Meilensteins am 1.9.), erhalten alle Vorgänge, die im Pfad vor dem Meilenstein liegen, zwei Wochen Puffer. Sind diese zwei Wochen Puffer aufgebraucht (z. B. durch unvorhergesehene Verzögerungen), werden die Vorgänge kritisch.


Planoptimierung nach Kosten

Eine Optimierung des Plans nach Kostenanfall kommt meist nur in Spezialfällen bei sehr großen Projekten vor. Hier kann es durchaus von Bedeutung sein, bestimmte kostenintensive Arbeitspakete so spät wie möglich zu beginnen – schließlich sind evtl. hohe Finanzierungskosten zu übernehmen.

Basis ist auch hier der Netzplan. Ähnlich wie bei der Optimierung der Ressourcen können die nicht kritischen Arbeitspakete nach hinten geschoben werden, um einen besseren Zahlungsverlauf zu erhalten. Zur Visualisierung wird z. B. eine Gegenüberstellung von geplanten Projektkosten und Zahlungseingang verwendet.


Integrierte Aufwands-, Termin- und Ressourcenplanung


1 Antragsbogen erfassen 3.501 Std. 89,91 Tage

2 Entwurf Antragsbogen 947 Std. 40 Tage

3 Realisierung Antragsbogen 1.894 Std. 40 Tage

4 Test und Abnahme Antragsbogen 660 Std. 45 Tage

5 Meilenstein Inkrement 1 Antragsbogen 0 Std. 1 Tag

6 Bedarfe 2.592 Std. 90,91 Tage

7 Entwurf Bedarfe 697 Std. 40 Tage

8 Realisierung Bedarfe 1.394 Std. 45 Tage

9 Test und Abnahme Bedarfe 501 Std. 40 Tage

10 Meilenstein Inkrement 2 Bedarfe 0 Std. 1 Tag

11 Berechnung 2.234 Std. 83 Tage

12 Entwurf Berechnung 601 Std. 40 Tage

13 Realisierung Berechnung 1.201 Std. 45 Tage

14 Test und Abnahme Berechnung 432 Std. 35 Tage

15 Meilenstein Inkrement 3 Berechnung 0 Std. 1 Tag

Architektur-Team[4,29]

Entwicklungsteam[8,61]

Test-Management[2,67]

30.10.


Entwicklungsteam[5,63]

Test-Management[2,28]

26.12.


Entwicklungsteam[4,85

Test-Management

14.02.

Jul Aug Sep Okt Nov Dez Jan Feb Mrz Apr3. Quartal 4. Quartal 1. Quartal 2. Quart


37 Management 5.616 Std. 390 Tage

38 Projektmanagement 3.092 Std. 390 Tage

39 Qualitätsmanagement 1.262 Std. 390 Tage

40 Konfigurationsmanagement 1.262 Std. 390 Tage

Jul Aug Sep Okt Nov Dez Jan Feb Mrz Apr3. Quartal 4. Quartal 1. Quartal 2. Quart


Projektkostenplanung

In der Regel ist mit der offiziellen Erteilung eines Projektauftrags auch die Freigabe eines bestimmten Projektbudgets verbunden, z. B. dem Budget, das in der Projektvorstudie geschätzt und im Projektantrag beantragt wurde. Der Projektleiter ist dafür verantwortlich, im Rahmen dieses Projektbudgets die vereinbarten Projektziele zu erreichen.

Um die Höhe des Projektbudgets zu verifizieren, ist eine Abschätzung der voraussichtlichen Projektkosten notwendig. Erst danach ist eine fundierte Aussage möglich, wie viel die Realisierung der Projektziele voraussichtlich kosten wird.

Liegen die voraussichtlichen Projektkosten über dem Projektbudget, muss der Projektleiter dies sofort mit dem Auftraggeber abstimmen. Wird eine entsprechende Budgetkorrektur abgelehnt, sollte dies auch von Auftraggeberseite sachlich zu begründen sein.

Stimmen Kostenplanung und Budget überein, so ist die Kostenplanung die Basis für eine kostenorientierte Projektsteuerung.


Wie plane ich die Projektkosten?

Basis für die Projektkostenplanung ist der Projektstrukturplan, der eine vollständige Aufstellung aller für die Erreichung des Projektziels notwendigen Arbeitspakete beinhaltet.

Die Gesamtkosten des Projekts sind dann die Summe der Kosten aller Arbeitspakete. U. U. ist diesen Kosten noch ein Anteil hinzu zu rechnen, der bei der Planoptimierung durch Termin- oder Kapazitätsprobleme auftritt, wenn Ressourcen länger als geplant benötigt werden oder wenn zeitweilig Leerlauf eintritt.

Zur Planung der Arbeitspaketkosten wird in erster Linie die Kostenartenrechnung angewandt. Dazu kann auf die Kostenarten des betrieblichen Rechnungswesens zurück gegriffen werden.

Falls dies zu detailliert oder aus anderen Gründen ungeeignet ist, empfehlen sich folgende Kostenarten:

– Personalkosten (Aufwand der Ressourcen mal Kostensatz)

– Materialkosten (Verbrauchsmaterialien, die besorgt werden müssen, damit ein Arbeitspaket abgearbeitet werden kann)

– Gerätekosten (da Geräte meist über das Projektende hinaus Verwendung finden, sollte nur ein Anteil angerechnet werden)

– Sonstige Kosten (z. B. Reisekosten, Aufwendungen für Geschenke)


Beispiel: Formular Kostenplanung

Quelle: G. Süß, Die wichtigsten Methoden im Projektmanagement, WEKA Verlag 2002


Risikomanagementplanung

Die Planung des Risikomanagementprozesses soll sicher stellen, dass dieser dem Risiko und der strategischen Bedeutung des Projekts für as Unternehmen angemessen ist (vgl. Module Risikomanagement) .

Der Risikomanagementplan beschreibt, wie die Identifikation, qualitative und quantitative Analyse, Maßnahmenplanung, Verfolgung und Kontrolle von Risiken strukturiert und über den gesamten Lebenszyklus des Projekts durchgeführt werden soll (PMBOK).


Risikomanagementplan

Der Risikomanagementplan kann Folgendes beinhalten:– Methoden: Festlegung, welche Methoden, Werkzeuge und Datenquellen im

konkreten Projekt zur Anwendung kommen. In unterschiedlichen Projektphasen können durchaus verschiedene Methoden angemessen sein.

– Rollen und Verantwortlichkeiten: Definition und Besetzung der Rollen für die Aktionen gemäß Risikomanagementplan

– Budget: Für das Risikomanagement muss ein Budgetrahmen genehmigt werden.

– Zeitplan: Legt fest, wie oft im Projektlebenszyklus der Risikomanagementprozess durchgeführt wird. Diese Festlegung sollte periodisch überprüft werden.

– Berechnung und Interpretation: Definition der Berechnungs- und Interpretationsmethoden, die bei den verschiedenen Typen von qualitativen und quantitativen Risiken zur Anwendung kommen. Die Vorab-Festlegung sichert die Konsistenz des Risikomanagements.

– Schwellenwerte: Festlegung akzeptabler Schwellenwerte, da diese i.d.R. bei verschiedenen Stakeholdern unterschiedlich sind.

– Berichtsformate: Beschreiben Inhalt und Format des Risikomaßnahmenplans. Wie werden die Ergebnisse des Risikomanagementprozesses dokumentiert, analysiert und an die Stakeholder kommuniziert.


Integrationsmanagement

Integrationsmanagement ist die Koordinierung der unterschiedlichen Elemente des Projekts. In der Projektplanungsphase wird durch das Integrationsmanagement der Projektplan generiert, der die Ergebnisse der verschiedenen Planungsprozesse zu einem schlüssigen und zusammenhängenden Dokument integriert, das die Projektausführung und –steuerung lenkt.

Der Projektplan kann sowohl ein Dokument als auch eine aufeinander abgestimmte Dokumentensammlung sein.

Der Projektplan dient:– der Steuerung der Projektausführung– der Dokumentation der Projektplanungsannahmen– der Dokumentation der Planungsentscheidungen und der Alternativen– der Erleichterung der Kommunikation– der Festlegung von Inhalt, Umfang und Terminierung der

Schlüsselreviews des Managements– als Basisplan für die Messung der Projektleistung und der

Projektsteuerung.


Inhalt des Projektplans

Die sinnvolle Strukturierung des Projektplans hängt u. a, von der Art und dem Umfang des konkreten Projekts ab. Üblicherweise beinhaltet er folgende Punkte:– Projektauftrag– Beschreibung des Projektmanagementansatzes oder der –strategie (meist

im Unternehmen generell geregelt)– Beschreibung des Inhalts und Umfangs des Projekts einschließlich der

Projektliefergegenstände und der Projektziele– Projektstrukturplan bis zur Ebene, au der die Steuerung stattfindet– Kostenschätzung, geplante Anfangstermine und

Verantwortungszuweisungen der Arbeitspakete– Basispläne zur Fortschrittsmessung von Terminen und Kosten– Meilensteine mit Terminen– Schlüsselpersonal oder erforderliche Mitarbeiter– Hauptrisiken mit Einschränkungen und Annahmen sowie die geplanten

Maßnahmen– Offene Punkte


Gliederung des Dokumentes Projektplan : Beispiel (Krafft Foods)

Inhalt..............................................................................................Abbildungen...............................................................................

Vorwort..........................................................................................Dokumentationshinweise .............................................................

Verteiler .....................................................................................1. Arbeitspakete ............................................................................

1.1 Überblick alle Arbeitspakete................................................1.2 Arbeitspaket Analyse Finanzbuchhaltung ...........................1.3 Arbeitspaket Pilotierung Anlagenbuchhaltung ....................

2. Aufwandsschätzung..................................................................2.1 Intern ....................................................................................2.2 Extern...................................................................................

3. Terminplan................................................................................3.1 Überblick gesamtes Projekt .................................................3.2 Detailplan laufende/nächste Arbeitspakete..........................

4. Projekt-Meilensteine.................................................................4.1 Meilenstein-Überblick .........................................................4.2 Meilenstein 1: Abstimmung FIBU.......................................4.3 Meilenstein 2: Entscheiden FIBU........................................

5. Ressourcen-Plan........................................................................5.1. Überblick.............................................................................5.2. Ressourcenzuordnung .........................................................5.3. Externe Ressourcen.............................................................5.4 Sonstige Ressourcen ............................................................

6. Projektorganisation ..................................................................6.1. Team-Organisation ( bei größeren Projekten ) ...................6.2. Projekt-Kommunikation .....................................................

7. Projektrisiken............................................................................Anhang: Referenz-Dokumente ....................................................

A1 Standards, Spezifikationen etc. ...........................................A2 Andere Dokumente .............................................................


Risikoanalyse, -bewertung und Maßnahmenfestlegung

Aufgabe der Risikoanalyse ist es, Faktoren, die eine Gefahr für den Projekterfolg (die im Projektauftrag definierte Leistung in geplanter Zeit mit den geplanten Ressourcen im Rahmen des vorgegebenen Budgets zu erbringen) zu identifizieren, zu beschreiben, zu bewerten und entsprechende Gegenmaßnahmen vorzubereiten bzw. einzuleiten (vgl. Module über Risikomanagement).

Zu unterscheiden sind:– projektimmanente Risiken (Projektrisiken) – Risiken, die sich aus der

Projektabwicklung, also aus dem Prozess heraus ergeben und– produktimmanente Risiken (Produktrisiken) – Risiken, die sich aus dem zu

erstellenden Produkt, also dem neuen Anwendungssystem oder der neuen Organisationsform ergeben.

Zum Risikomanagement der Produktrisiken existieren je nach Produktart (technische Produkte, Software, Anlagenbau etc.) meist firmenspezifische Konzepte (z. B. FMEA, Testverfahren), die i.d.R. Bestandteil des Qualitätsmanagements sind.


Risikoelement Risikomanagementmaßnahmen1. Personelle Defizite Hochtalentierte Mitarbeiter einstellen

Teams zusammenstellen2. Unrealistische Termin- und Kostenvorgaben

Detaillierte Kosten- und Zeitschätzungmit mehreren Methoden

Produkt an Kostenvorgabenorientieren

Inkrementelle Entwicklung Wiederverwendung von Software Anforderungen streichen

3. Entwicklung von falschen Funktionen und Eigenschaften

Benutzerbeteiligung Prototypen Frühzeitiges Benutzerhandbuch

4. Entwicklung der falschen Benutzer- schnittstelle

Prototypen Aufgabenanalyse Benutzerbeteiligung

5. Vergolden (über das Ziel hinaus- schießen)

Anforderungen streichen Prototypen Kosten-/Nutzenanalyse Entwicklung an den Kosten orientieren

Top Ten Risikoelemente - typische Maßnahmen (1)

Quelle: Helmut Balzert, Lehrbuch der Software-Technik, Bd. 1, Spektrum 1998


Risikoelement Risikomanagementmaßnahmen6. Kontinuierliche Anforderungs- änderungen

Hohe Änderungsschwelle Inkrementelle Entwicklung

(Änderungen auf spätereErweiterungen verschieben)

7. Defizite bei extern gelieferten Komponenten

Leistungstest Inspektionen Kompatibilitätsanalyse

8. Defizite bei extern erledigten Aufträgen Prototypen Frühzeitige Überprüfung Kompatibilitätsanalyse

9. Defizite in der Echtzeitleistung Simulation Leistungstest Modellierung Prototypen Instrumentierung Tuning

10. Überfordern der Software-Technik Technische Analyse Kosten-/Nutzenanalyse Prototypen

Top 10 Risikoelemente - typische Maßnahmen (2)

Quelle: Helmut Balzert, Lehrbuch der Software-Technik, Bd. 1, Spektrum 1998


Projektrisiken: Ergebnis-Beispiel

Dieses Ergebnis definiert die Risiken und alternative Maßnahmen zur Reduzierung der Auswirkungen der Risiken auf das Projekt oder auf einzelne Funktionen.

Es wird während der Detailplanung oder bei kritischen Projekten bereits in der Vorbereitungsphase eines Projektes erstellt und bei Bedarf während des Projektverlaufs fortgeschrieben.

Kategorie Beschreibung des Risikos Auswirkung Alternative Maßnahmen Empfehlung

Termin Auftragserfassung kann nicht

zeitgerecht ausgeliefert werden.

Hoch Warten bis die

Auftragserfassung

implementiert werden

kann

2

Funktionalität der

Auftragserfassung

reduzieren

3

Erstellen eines Bridge-

Programms zum

existierenden Auftrags-

Erfassungssystem

1

Bedienung Das vorgesehene Personal kann

nicht eingesetzt werden

Mittel Beschaffen von qualifiziertem

Personal

1

Intensives Training für

das unerfahrene Personal

2


Qualitätsmanagement im Projekt planen: Wirtschaftlichkeit

1000

500

200

100

50

20

10

5

2

Analyse Design Implemen-tierung

Entwicklungs-Test

Abnahme-Test

Betrieb

Rela

tive K

os t

en, u

m e

i nen F

ehle

rzu

finden u

nd z

u b

eheben

KleinereSoftware-Projekte

GrößereSoftware-Projekte

Phase, in der ein Fehler entdeckt und korrigiert wird


Prozess Qualitätsmanagement (nach dem V-Modell)

QSinitialisieren

Prüfungvorbereiten

QS-PlanPrüfplan

Prüf-spezifikation

Projektauftrag,Projektplan

Durchführungs-entscheidung

QS-Berichtswesen

Produktprüfen

Entscheidungs-Protokoll

Prozeßprüfen

Prüfprotokoll

Prüfprotokoll

Prüf-spezifikation


Produkte des Qualitätsmanagements

Der Qualitäts-Plan beinhaltet die übergeordnete QS-

Planung für das gesamte Projekt Pro Phase eines Projektes und für jeden unterstützenden

Prozess (PM, KM, QM ) gibt es jeweils einen Prüfplan. Jedem Prüfgegenstand ist eine Prüfspezifikation

(Checkliste ) als Input zugeordnet. Als Ergebnis der Prüfung ist jedem Prüfgegenstand ein

Prüfprotokoll zugeordnet (s. Projektcontrolling) Die Anzahl der Prüfspezifikationen und Prüfprotokolle ist

von der Anzahl der Prüfgegenstände abhängig.


Qualitätsmanagement: Rollen und Verantwortungen

Pro

jekt

ma

na

ge

r

Pro

du

kte

rste

ller

QS

-Ma

na

ge

r IS

QS

-Ma

na

ge

r P

roje

kt

Prü

fer

Au

ftra

gg

eb

er

QS-Initialisierung M D E/M

Prüfung vorbereiten D/E

Produkt prüfen M D/E

Prozeß prüfen M D/E

Durchführungsentscheidung M I D E

QS-Berichtswesen I D/E M

Die Einträge in der Matrix zeigen an, ob die einer Aktivität zugeordnete Rolle durchführungs-verantwortlich ( D ) mitwirkend ( M ) entscheidet ( E ) oder informiert wird ( I ).


Mit gutem Ziel gewinnt man viel.

Quelle: Chaos - ein Teutsches durcheinander von unterschiedlichen Sachen, D. Andr. Sutor, Augsburg 1716

Qualitätsziele (Erinnerung)


Ziele: liegen in der Zukunft sind vorstellbar und realistisch das Erreichen kann gedanklich

vorweggenommen werden das Erreichen ist nur durch

aktives Handeln möglich werden bewusst angestrebt das Erreichen ist gewünscht die Entscheidung ist bewusst

getroffen worden im Interesse des Erreichens

werden Einschränkungen und Anstrengungen in Kauf genommen

sie sind idealerweise messbar

Nicht-Ziele was sowieso in der Zukunft

eintreten wird was ohne Aktivität „erwartet“

werden kann Ereignisse, die zufällig

eintreten können Ereignisse, die nicht

gewünscht sind

Ziele und Nicht-Ziele


Habe ich das richtige Ziel definiert?

(Frage nach der Richtigkeit und dem Nutzen der Erreichung des Ziels)

Habe ich das Ziel richtig definiert?

(Frage nach der Erreichbarkeit des Ziels)

Zielfestlegung – 2 Fragen


Garvins fünf Ansätze:

Der transzendente Ansatz

kompromisslose Standards und extrem hohe Anforderungen

Der produktbezogene Ansatz

Differenzen von Eigenschaften Der kundenbezogene Ansatz

Jurans „fitness for use“ Der fertigungsbezogene Ansatz

Crosby‘s conformance to requirements Der wertbezogene Ansatz

„Value for money“

Was ist Qualität?

Quelle: D. A. Garvin: What does product quality really mean?, Sloan Management Review 1984


Was ist Qualität – Definition der ISO (Norm 8402)


Softwarequalität ist die Gesamtheit aller

Merkmale und Eigenschaften, die ein

Softwareprodukt haben muss, um sicherzu-

stellen, dass es (beweisbar und messbar!) die vorgegebenen oder vorausgesetzten

Anforderungen des Anwenders/Auftraggebers erfüllt die Anwender es so verwenden können, dass der von

ihnen erwartete Nutzen auch realisiert wird keine nicht erwünschten Operationen ausführt.

Anwendung der ISO Norm auf Software-Qualität


Benutzungsfreundlichkeit Dokumentation Funktionalität Integration Effizienz Portabilität Sicherheit Wartbarkeit Zuverlässigkeit

Qualitätsmerkmale eines Softwareprodukts - Beispiel

In Anlehnung an ISO/IEC 9126. Es gibt diverse andere Ansätze, dies ist nur ein Beispiel.


Qualität konzentriert sich auf folgende 6 Schlüsselfaktoren:

geringe Fehlerrate im Einsatz, idealerweise nahezu 0 hohe Zuverlässigkeit, d. h. ohne Zusammenbrüche oder seltsame

Ergebnisse zu laufen bei Untersuchungen der Anwenderzufriedenheit ist die Mehrzahl

der Anwender sehr zufrieden eine Struktur, die die Auswirkungen von „bad fixes“ oder das

Einbringen neuer Fehler bei der Reparatur minimiert effektive Anwenderunterstützung, wenn Probleme auftreten schnelle Reparatur bei Auftreten von Fehlern, insbesondere, wenn

diese schwerwiegend sind

Eigenschaften von Qualitätssoftware

Quelle: Capers Jones, Software Quality - Analysis and Guidelines For Success, Int. Thomson Computer Press, 1997,


Qualität

Zeit

Funktions-

umfang

Kosten

Teamleistung

--

++

Rahmenbedingungen: Das Teufelsquadrat


Qualitätsplanung und -sicherung

„Qualität ist kein Ereignis; Qualität ist eine Gewohnheit“ – das wusste schon Aristoteles. Qualität lässt sich nicht hinterher in ein Produkt hinein prüfen, sondern sie muss von Anfang an eingebaut sein. Alles andere wird i.d.R. sehr teuer.

Am besten ist es deshalb, wenn die Projektarbeit von vornherein im Rahmen eines Qualitätsmanagementsystems (QMS) stattfindet, das beispielsweise auf der internationalen Qualitätsnorm ISO 9000: 2000 aufgebaut ist. Wenn so gearbeitet wird, sind die Chancen größer, dass der Prüfer bei einem Qualitätsreview feststellt, dass alle Qualitätsanforderungen erfüllt sind und dass keine Beanstandungen vorliegen.


Quellen der Qualität

Die Qualität eines Produkts (wie z. B. eines Tongefäßes) hängt ab von:– Der Qualität des Materials (dem Ton),– Der Qualität der Werkzeuge (der Töpferscheibe),– Der Qualität des Bearbeiters (des Töpfers)– Der Qualität der Struktur (der Form des Gefäßes) und von– Der Qualität des Zwecks (beabsichtigte Verwendung des Gefäßes)

Für die Entwicklung eines Anwendungssystems bedeutet das:Die verwendete Hardware entspricht dem Ton. Das Vorgehensmodell und die Entwicklungswerkzeuge entsprechen der Töpferscheibe. Der Entwickler ent-spricht dem Töpfer. Aber Qualität verlangt auch eine gute Struktur und einenguten Zweck. Diese werden durch das QMS und die Qualitätsziele desAuftraggebers bereit gestellt.


Notwendigkeit qualitätssichernder Maßnahmen

Nicht einmal ein übernatürlich guter Mitarbeiter kann systematisch perfekte Qualität liefern, wenn die anderen Komponenten nicht stimmen.– Der Einfluss eines Mitarbeiters auf die Qualität im Projekt ist immer

begrenzt. Einflussnahme des Managements, unklare Projektziele, nicht optimales Projektmanagement, eine qualitätsunfreundliche Unternehmenskultur, nicht ausreichende Ressourcen oder nicht ausreichende Fachbereichsbeteiligung können zur Folge haben, dass ein Projekt trotz bester Absichten des Teams seine Qualitätsziele nicht erreichen kann.

Deshalb sind qualitätssichernde Maßnahmen grundsätzlich erforderlich– um dem Auftraggeber gegenüber den Nachweis erbringen zu können,

dass die Qualitätsziele erreicht wurden– um den Mitarbeitern zu helfen, ihre Arbeit auch in einer schwierigen

Umgebung mit Erfolg durchführen zu können.


Qualitätssichernde Maßnahmen

Es gibt drei Arten von QS-Maßnahmen:– Planerische und administrative Maßnahmen (vorbeugende Maßnahmen) z. B. Vorgaben von Kriterien und Rahmenbedingungen

Konstruktive Maßnahmen (vorbeugende Maßnahmen)– z. B. Gliederung des Entwicklungsprozesses durch Anwendung eines

Entwicklungsstandards (Vorgehensmodell)– Auswahl von Methoden und Werkzeugen zur Unterstützung des

Entwicklungsprozesses– Festlegung von Projektstandards und –richtlinien– Training der Mitarbeiter in bestimmten für das Projekt relevanten

Fähigkeiten– Durchführung einer Risikoanalyse für das Projekt und Ableitung

entsprechender Maßnahmen Analytische Maßnahmen (prüfende Maßnahmen)

– Reviews, Audits, Testen


Qualitätsplan – Inhalt (Beispiel Airbus)

1. Allgemeines zum Qualitätsplan– Zielsetzung– Reichweite– Ergänzende Dokumente

Das Projekt XYZ– Projektziele– Kritikalität– Genereller Qualitätsanspruch an das Projekt– Projektrisiken

Qualitätsziele Konstruktive QS-Maßnahmen Analytische QS-Maßnahmen


Bei einer Standardlösung hat das Implementierungsteam nur einen begrenzten Einfluss auf die Qualität.

Beispiel:

Qualitätsziel: Keine Eingabemaske zeigt mehr als 10 Informationen

an, damit die Übersichtlichkeit nicht leidet.

Entweder sieht die Software dies bereits vor, dann ist das Ziel erreicht oder es

gibt Eingabemasken , die mehr Informationen anzeigen. Da Eingriffe in Stan-

dardsoftware meist mit erheblichen Kosten verbunden sind, ist ein solches

Qualitätsziel nicht vernünftig, da es sich nicht auf wirtschaftliche Art und

Weise erreichen läßt.

Qualität bei Standardsoftware


„ Eignung des Systems bzw. seiner Teile zum Erlernen seiner Funk-

tionen, zu seiner Bedienung und Handhabung sowie zur Interpretation

seiner Meldungen und Ergebnisse durch den vorgesehenen Benutzer.“

Das Merkmal Benutzungsfreundlichkeit kann in folgende Teilmerkmale zerlegt werden:

Antwortzeitverhalten, Bedienbarkeit, Erlernbarkeit, Verständlichkeit.

Beispiel: Antwortzeitverhalten:

Für die Anwender muss

ein zügiges Arbeiten

mit dem System mög-

lich sein

Ziel Bewertungsmaß Erhebungsart Erfüllungsmaß

Zeit Zeitmessung

Antwortzeiten im

On-Line Betrieb in

95% aller Fälle

unter 1 sek.

Qualitätsmerkmale: Benutzerfreundlichkeit (Beispiel aus einem Projekt)


„ Beschaffenheit der Dokumente, die während der Projektabwicklung

zur Erstellung und Einführung eines IV-Produkts erzeugt werden.“

Das Merkmal Dokumentation kann in folgende Teilmerkmale zerlegt werden:

Aktualität, Identifizierbarkeit, Konformität zu bestehenden Standards,

Vollständigkeit, Verständlichkeit, Widerspruchsfreiheit.

Beispiel: Identifizierbarkeit

Für Dokumente, die Er-

gebnischarakter haben

und die im Zeitverlauf

veränderbar sind, gibt es

eine Versionsführung.


Versionsführung in den

Dokumenten:– Versionsnummer

vorhanden– Versionsnummer fehlt

Review der Dokumente100 % dieser Dokumente

haben eine Versions-

führung

Qualitätsmerkmale: Dokumentation (Beispiel aus einem Projekt)


„ Eignung des Systems bzw. seiner Teile, die im Pflichtenheft spezi-

fizierten Funktionen ausführen zu können.“

Das Merkmal Funktionalität kann in folgende Teilmerkmale zerlegt werden:

Ordnungsmäßigkeit, Richtigkeit, Vollständigkeit.

Beispiel: Richtigkeit


Prozentsatz der identifi-

zierten Eingabe- und

Bedienungsfehler

Testen am System auf

Basis definierter Testfälle

(Falscheingaben)

100 % der Eingabe- und

Bedienungsfehler werden

bei den als kritisch einge-

stuften Testfällen erkannt,

sonst 90%.

Eingabe- und Bedie-

nungsfehler werden

vom System erkannt

Qualitätsmerkmale: Funktionalität (Beispiel aus einem Projekt)


„ Integration ist das Ausmaß, in dem das System in sein IV-technisches

und organisatorisches Umfeld eingebunden ist.“

Das Merkmal Integration kann in folgende Teilmerkmale zerlegt werden:

Interoperabilität (Schnittstellen), Prozeßintegration.

Beispiel: Ausgabe-Schnittstellen


Prozentsatz der korrekt

übergebenen Datenfelder

Testen am empfangen-

den System

100 % der Felder werden

korrekt übergeben

Ausgabe-Schnittstellen

werden korrekt bedient

Qualitätsmerkmale: Integration (Beispiel aus einem Projekt)


„ Die Effizienz ist das Ausmaß der Inanspruchnahme von Betriebs-

mitteln (Hardware) durch das Software Produkt bei gegebenen

Funktionsumfang“

Das Merkmal Effizienz kann in folgende Teilmerkmale zerlegt werden:

Laufzeitverhalten, Speicherungsbedarf, Zugriffsoptimierung.

Beispiel: Laufzeitverhalten


Zeit Zeitmessung Zeit <= x Stunden

Gehaltsabrechung ist in

x Stunden fertig

Qualitätsmerkmale: Effizienz (Beispiel aus einem Projekt)


„ Portabilität ist ein Maß für den Anpassungsaufwand des Systems an eine

andere Hard- oder Softwareumgebung bei identischer Funktionalität aller

Komponenten“

Das Merkmal Portabilität kann in folgende Teilmerkmale zerlegt werden:

Implementierungsfreundlichkeit, Kompatibilität, Übertragbarkeit,

Wiederverwendbarkeit.

Beispiel (Standardsoftware):

Nicht erforderlich; da es sich um Standardsoftware handelt,

besteht kaum eine Einflussmöglichkeit des Teams.

Qualitätsmerkmale: Portabilität (Beispiel aus einem Projekt)


„ Eignung des Systems bzw. seiner Teile, sich vor Beeinträchtigungen

von außen zu schützen“

Das Merkmal Sicherheit kann in folgende Teilmerkmale zerlegt werden:

Datenschutz, Datenintegrität, Zugriffsschutz.

Beispiel: Zugriffsschutz


Wahrscheinlichkeit, dass

eine Schutzfunktion

versagt

Testen durch ein Mitglied

des Chaos-Computer-

clubs

Unerlaubter Zugang

wurde nicht geschafft

Aller unerlaubte Zugriff

auf Personaldaten muss

ausgeschlossen sein

Qualitätsmerkmale: Sicherheit (Beispiel aus einem Projekt)


„ Wartbarkeit ist ein Maß für den Aufwand zur Weiterentwicklung bzw.

Fehlerbeseitigung eines bereits existierenden Programms.“

Das Merkmal Wartbarkeit kann in folgende Teilmerkmale zerlegt werden:

Anpassbarkeit, Analysierbarkeit, Änderbarkeit, Erweiterbarkeit, Testbarkeit,

Verständlichkeit.

Beispiel (Standardsoftware):

Nicht erforderlich; da es sich um Standardsoftware handelt und

die vorhandenen Info- bzw. RASA Programme möglichst weiter

benutzt werden sollen, besteht kaum eine Einflussmöglichkeit

des Teams.

Qualitätsmerkmale: Wartbarkeit (Beispiel aus einem Projekt)


„ Eignung des Systems bzw. seiner Teile, während einer vorgegebenen

Anwendungsdauer fehlerfrei zu funktionieren.“

Das Merkmal Zuverlässigkeit kann in folgende Teilmerkmale zerlegt werden:

Reproduzierbarkeit, Robustheit, Stabilität, Verfügbarkeit, Wiederherstellbarkeit.

Beispiel: Stabilität


Anzahl der System-

ausfälle in der

Beobachtungszeit

Zählen

Max. Anzahl der System-

ausfälle < 1,5*Anzahl der

Tage der Beobachtungs-

phase

Das System ist stabil,

soweit dies in der Ver-

antwortung des Entwick-

lungsteams liegt

Qualitätsmerkmale: Zuverlässigkeit (Beispiel aus einem Projekt)


Qualitätssicherung: „Testen“

„Testen ist der Prozess, ein Programm mit der Absicht

auszuführen, Fehler zu finden“

„Testen nennt man jede Aktivität, die zum Ziel hat,

eine Eigenschaft oder Fähigkeit eines Programms

oder Systems zu überprüfen, um festzustellen, ob die Anforderungen erfüllt sind“

Quelle: Myers, G. J., “Methodisches Testen von Programmen”Oldenbourg 1995 (Erstausgabe 1979)

Quelle: Hetzel, Bill, “A Complete Guide to Software Testing,QED Information Sciences Inc. 1988

Wir benutzen hier eine allgemeine Definition: Jede Maßnahme der analytischen Qualitäts-sicherung, d. h. jede prüfende Maßnahe , kann man unter „testen“ subsumieren.

Hinweis: Die Folien 86-129 enthalten erläuternde Notizen (Ansicht-Notizenseite von Powerpoint)


Strategien zur Elimination von Softwarefehlern

1. Effektive Fehlerverhütung 2. Hohe Effizienz bei der Fehlerreparatur 3. Genaue Vorhersage von Fehlern bevor die

Realisierung im Projekt beginnt 4. Exakte Fehlerverfolgung während der

Entwicklung 5. Nützliche Qualitätsmessungen 6. Sicherstellen hoher Anwenderzufriedenheit

Quelle: Capers Jones, „Software Quality - Analysis and Guidelines for Success“,International Thomson Computer Press 1997


Wo soll man ansetzen?

100%

75%

50%

25%

FehlerverhütungPrüfkosten

Fehlerkosten

Folgekosten


Fehlerverhütung: Wer macht die Fehler?

4-M-Methode: Der Mensch ist das schwächste Glied in der Qualitäts-Kette. Quelle: Ried Management

1 0 0 %

7 5 %

5 0 %

2 5 %

M en sch

M a sch in e

M eth o d e

M a ter ia l


Fehlerverhütung: Ursachen für menschlich bedingte Fehler

Streß

Überforderung

Eventuell mangelnde Qualifikation

Mangelhafte Informationsweitergabe

Informationsübernahmeohne Prüfung

Krankheit

Nachlässigkeit

Mangelnde Bereitschaftzur Kommunikation

Mangelnde Bereitschaftzur Teamarbeit

Mangelndes Interessean der Sache

Mangelnde Selbstdisziplin

Frust


Ungenügende Arbeitshilfen

Nicht adäquateArbeitsmethoden

Nicht ausreichendeAusbildung

Mangelhafte Arbeitsbedingungen

Fehlen vonQualitätsmaßstäben

UngenügendeInformationen

Fehlen von vorbeugenderWartung und Instandhaltung

Umweltbedingungenam Arbeitsplatz

Ungenügendes TrainingGeräuschbelästigungen

Fehlen von Prüf- (Test-)plänen

Fehlerverhütung: Ursachen für sachlich bedingte Fehler


Psychologie des Testens (analytische QS): Wer soll testen?

Ziel des Testens ist, Fehler zu finden (nach Myers) Ein Test ist dann erfolgreich, wenn er Fehler findet Menschen sind gegenüber eigenen Fehlern toleranter als gegenüber

fremden und übersehen sie deshalb leicht Wenn etwas missverstanden wurde, ist es unmöglich, selbst den

Fehler zu entdecken

der Autor (z. B. der Programmierer) ist in der

Regel die ungeeignetste Person zum Testen!


Ökonomie des Testens

Black Box Test:Der Tester betrachtet das Programm als Black Box, d.h. er ist nicht an der inneren Struktur interessiert, sondern daran, Umstände zu entdecken, bei denen sich das Programm nicht gemäß den Spezifikationen verhält.

Alle Fehler finden:Wenn man mit diesem Verfahren alle Fehler finden will, so ist der vollständige Eingabetest, d.h. Kombination aller möglichen Eingabebedingungen,

Voraussetzung dafür. Diese Zahl ist aber meist sehr groß.

White Box Test:Bei diesen Testverfahren ist die innere Struktur der Programme bekannt. Der Tester definiert die Testfälle mit Kenntnis der Programmlogik (und oft unglücklicherweise) unter Vernachlässigung der Spezifikation

Alle Fehler finden:

Weder möglich durch Testen aller Statements noch durch erschöpfendes Pfadtesten, da beispielsweise Pfade fehlen können oder das Programm einfach das Falsche tut, weil es Missverständnisse gab. Außerdem ist die Anzahl möglicher Pfade meist sehr groß.


Management und Messbarkeit

Spezifizieren der Anforderungen

Spezifizieren des Modultests

Ausführen desModultests

Codierender Programme

Spezifizieren des Design

Ausführen desSystemtests

Ausführendes Integrations-

und Funktionstests

Ausführen desAkzeptanztests

Review/Audit des Modultests

Reviewdes Codes

Spezifizieren des Integrations-

und Funktionstests

Spezifizieren des System- und Akzeptanztests

Review derAnforderungen

Review/Audit desIntegrations-

und Funktionsteststests

Review desDesigns

Review desSystem- und

Akzeptanztests

Spezifizierende Tätigkeiten

Ausführende Tätigkeiten

Überprüfende Tätigkeiten

Quelle: Daich, G. et al., “Software Test Technologies Report”STSC, Hill Air Force Base 1994


Ergebnis

Maßnahmen

AnforderungenSystemkonzept Design Programm System

Analyse

Test

VerifikationValidierung

*** **

** ** *** *

** *** ***

* ** ***

***

Quelle: im wesentlichen nach Trauboth, „Software Qualitätssicherung“, Oldenbourg, 1996 *** **

*

häufigerweniger häufigselten

Inspektionen

Dokumente

***

**

( ) *

**

Einsatz analytischer Testmethoden


Formale und weniger formale Überprüfungsmethoden

Reviews überprüfen am Ende jeder Entwicklungsphase Umfang und Qualität der Zwischenprodukte. Projektpersonal, Auftragnehmer-management und Auftraggeber entscheiden gemeinsam, ob die nächste Phase angegangen werden kann

Audits sind offizielle Reviews zur Verifikation besonders kritischer Teile durch das QS-Personal

Ziel eines Walk-Throughs ist, Problembereiche zu entdecken, sie aber erst nach Abschluß des Walk-Throughs und nach Zustimmung des Erstellers zu beheben

Peer Review entspricht dem Walk Through. Es geht dabei um eine methodische Examinierung der Ergebnisse durch sachkundige Kollegen (Peers). Ziel ist, Fehler zu finden und Bereiche, in denen Änderungen erforderlich sind

Inspection ist eine sehr formale Gruppensitzung, in der die zu inspizierende Unterlage vom Autor vorgelesen und sequentiell Wort für Wort durchgearbeitet wird


Ursachen für Softwarefehler

Fehlerursache End-UserSysteme

Anforderungen

Design

Quellcode

Handbücher und Trainingsmaterial

Sekundärfehler (fehlerhafte Wartung)

Total

Durch-schnitt

MilitärSysteme

Systems-software

MIS OutsourceSysteme

Kommerz.Systeme

0,00 %

15,00 %

55,00 %

10,00 %

20,00 %

100,00 %

15,00 %

30,00 %

35,00 %

10,00 %

10,00 %

100,00 %

20,00 %

25,00 %

35,00 %

10,00 %

10,00 %

100,00 %

10,00 %

30,00 %

30,00 %

20,00 %

10,00 %

100,00 %

10,00 %

25,00 %

40,00 %

15,00 %

10,00 %

100,00 %

20,00 %

20,00 %

35,00 %

15,00 %

10,00 %

100,00 %

12,50 %

24,17 %

38,33 %

13,33 %

11,67 %

100,00 %


Fehlerursprung und Fehlerbereinigungseffizienz

Anforderungs-fehler

Design-fehler

Code-fehler

Dokumenten-fehler

Performanz-fehler

Inspektions-methoden

Proto-typing

Testen

Korrektheits-beweise

zufrieden-stellend

gut

schwach

schwach

ausgezeichnet

ausgezeichnet

ausgezeichnet gut

gut

gut

schwach

schwach

zufrieden-stellend

zufrieden-stellend

zufrieden-stellend

Zufrieden-stellend

zufrieden-stellend

nichtanwendbar

gut

schwach

Quelle: Capers Jones, „Software Quality - Analysis and Guidelines for Success“,International Thomson Computer Press 1997


Fehlerursprung und Entdeckung

Anforderungen Design Codierung Dokumentation Test Wartung



Anforderungen Design Codierung Dokumentation Test WartungFehler-

ursprung

Fehler-ursprung

Fehler-entdeckung

Fehler-entdeckung

Ohne Einsatz formaler Inspektionsmethoden

Mit Einsatz formaler Inspektionsmethoden

Chaos-Phase


Wie erreicht man eine hohe „Fehlerbereinigungseffizienz“?

Fehlerverhütung Formale Anforderungsanalyse (z. B. Joint Application Design) Formale Risikoanalyse frühzeitig in der Entwicklung Prototyping Strukturierte oder formale Spezifikationsmethoden Strukturierte Programmiermethoden Zertifizierte wiederverwendbare Design- und Codekomponenten

Fehlerbereinigung vor dem Test Inspektion der Anforderungen Inspektion des Designs Inspektion des Codes Reviews des Testplans Inspektion der Testfälle Editieren oder reviewen der Anwenderdokumentation

Testen Modultest durch die Programmierer Testen neuer Funktionalität Regressionstest Performanztest Integrationstest Systemtest Feldtest (externer Beta Test)

Jede einzelne Maßnahme hat einen Wirkungsgrad von ca 30% (d. h. findet 30% der verbleibenden Fehler). Um eine hohe Fehlerbereinigungseffizienz (% der Fehler, die Während des Projekts gefunden werden) zu erreichen, müssen mehrere Maßnahmen hintereinander ausgeführt werden.


Einbettung der Methode Test Rx TM in den Entwicklungszyklus

ProzessschritteEntwicklungs-

phase Beteiligte

1. Testteam benennen

2. Risikoanalyse durchführen

3.Testziele festlegen

4.Testpläne aufstellen

5.Testfälle entwickeln

6.Modul-/Integrationstest ausführen

7.Systemtest durchführen

8.Analysieren der Testergebnisse

9.Regressionstest durchführen

10. Analysieren der Testergebnisse

Analyse

Analyse

Analyse

Analyse/Design

Analyse/Design

Konstruktion

Test

Test

Wartung

Wartung

Projekt-/Testmanager

Projekt-/Testmanager

Testmanager/Tester

Testmanager/Tester

Testmanager/Tester

Tester

Entwickler/Tester

Tester

Tester

Tester


Unterstützende Basistechniken

Konfigurationsmanagement (KM) Fehlerverfolgung und Problem-Dokumentation (FP) Testautomation (TA) Peer Reviews (PR) Testmetriken (TM)


Der Testprozess und die unterstützenden Techniken

Prozessschritte KM

1. Testteam benennen

2. Risikoanalyse durchführen

3.Testziele festlegen

4.Testpläne aufstellen

5.Testfälle entwickeln

6.Modul-/Integrationstest ausführen

7.Systemtest durchführen

8.Analysieren der Testergebnisse

9.Regressionstest durchführen

10. Analysieren der Testergebnisse

FP TA PR TM

- = nicht erforderlich, o = optional, x = erforderlich

-ooooxxxxx

-----xx-xx

-oxxxxxoxx

xxxxxxxxxx

-xxx-xxxxx


Wie verbessert die Definition von Testzielen die Testplanung?

Testziele bringen Disziplin in den Testprozeß Testziele sagen dem Tester, was er erreichen soll Testziele garantieren, daß der Test vollständig ausgeführt

wird Die Operationalisierung der Testziele in Form einer

Qualitätscheckliste macht die Überprüfung einfach


Beispiel: Testziele und Checkliste für den Modultest (‚korrektes Datum‘)

Ziele: Sicherstellen, dass Schaltjahre die

Verarbeitung nicht aufhalten Sicherstellen, dass Monate 00 und 13 die

Verarbeitung nicht aufhalten Sicherstellen, dass Tage 00 und 32 die

Verarbeitung nicht aufhalten Sicherstellen, dass 29. 30. 31. Februar die

Verarbeitung nicht aufhalten Sicherstellen, dass der 30. Februar als

Fehler ausgewiesen wird Sicherstellen, dass ein

Jahrhundertwechsel die Verarbeitung nicht aufhält

Sicherstellen, dass Daten außerhalb des Zyklus die Verarbeitung nicht aufhalten

Sicherstellen, dass Daten außerhalb des Zyklus als Fehler ausgewiesen werden

Checkliste: Einbeziehen von Schaltjahren Einbeziehen der Monate 00 und 13 Einbeziehen der Tage 00 und 32 Einbeziehen des 29. 30. 31. Februars Einbeziehen von Daten, die

verschiedene Jahrhunderte abdecken Einbeziehen von Daten, die außerhalb

des Zyklus (z. B. des Buchungszyklus) liegen


Integration der Testplanung in den Entwicklungszyklus

EntwicklungszyklusphaseZu erstellender

TestplanAuszuführender

Testplan

Analyse

Analyse

System Design

Detailliertes Design

Konstruktion

Konstruktion

Test

Produktion/Wartung

Systemtestplan

Regressionstestplan

Integrationstestplan

Modultestplan

Regressionstestplan

Modultestplan

Integrationstestplan

Systemtestplan


Inhalt eines Testplans (1)

Ein umfassender Testplan leistet folgendes: Er definiert die globalen messbaren Testziele im Test-Rahmenplan und

definiert spezielle messbare Ziele für Teiltestpläne. Er enthält eine vollständige Beschreibung der Funktionalität und der

Struktur des zu testenden Systems Er adressiert Testen vom Standpunkt eines Testzyklus aus, der parallel

zum traditionellen Entwicklungszyklus verläuft und sichert so, dass Testen frühzeitig in der Entwicklung beginnt und über den gesamten Prozess hinweg fortgesetzt wird sowie dass bestimmte Review-Meilensteine gesetzt werden

Er legt spezielle Aufgaben fest, die während jeder Phase des Tests auszuführen sind inklusive der Kosten und Ressourcenschätzungen für diese Aufgaben

Er identifiziert Startkriterien und Abschlußkriterien für jede Testaktivität Er identifiziert alle Personen, die in den Testprozess involviert sind, weist

ihnen Aufgaben zu und stellt Arbeitspläne auf


Inhalt eines Testplans (2)

Fortsetzung: Er identifiziert die erforderlichen Ressourcen für das Design, die

Dokumentation und Ausführung der Testfälle bzw. Testszenarios sowie für die Aufzeichnung, Analyse und Berichterstattung der Testergebnisse

Er identifiziert erwartete Ergebnisse für alle Tests Er legt Notfallmaßnahmen fest, die im Falle eines katastrophalen Fehlers

des neuen Systems bzw. der neuen Version zum Tragen kommen er definiert manuelle und automatische Testtechniken und Werkzeuge

sowie wann und wie sie verwendet werden sollen er definiert Prozeduren zur Lokalisierung, Entfernung und Verfolgung von

Fehlern (debugging) Er legt das erforderliche Training für die Testmitarbeiter fest Er enthält einen Index, in dem Informationsquellen über die

implementierten Testmethoden und Prozeduren zu finden sind


Black Box Methoden (Auswahl)

Aufgabenorientierte Testfallbestimmung Funktionsorientierte Testfallbestimmung Bildung von Äquivalenzklassen Grenzwertanalyse Ursache-Wirkung-Analyse Statistische Testdatenauswahl

Quelle: H. Trauboth, „Software-Qualitätssicherung“, Oldenbourg 1996


White Box Methoden - Auswahl

Überdeckungsorientierte Testfallbestimmung Datenflussorientierte Testfallbestimmung Bereichsorientierte Testfallbestimmung


Fehlererwartung (Error Guessing)

„Manche Menschen besitzeneine natürliche Begabungzum Programmtesten.Ohne Verwendung einerspeziellen Methode scheinensie über eine Spürnase zumEntdecken von Fehlern zuverfügen.“G. J. Myers, Methodisches Testen von Programmen, Oldenbourg 1995


Strategie des Testfallentwurfs

Beginnen mit dem Ursache-Wirkungsgraphen (Wenn die Spezifikation Kombinationen von Eingabebedingungen enthält)

Grenzwertanalyse anwenden Äquivalenzklassen für Ein- und Ausgabe festlegen und

Testfälle ergänzen, wenn nötig Fehlererwartungstechnik anwenden, um weitere

Testfälle hinzuzufügen Programmlogik untersuchen, wie weit deren Test erfüllt

ist. Ggf. Testfälle zur Überdeckung hinzufügen


Modultest: Inkrementelles vs. nicht-inkrementelles Testen

Nicht-inkrementellesTesten: Big Bang

InkrementellesTesten

1.

2.

3.

4.

5.

6.

1.

2.

3.

4.

5.

6.

7.


Inkrementelles Testen: Top Down vs. Bottom Up

STUB 1

STUB 2

Treiber 1

Zwischenschritt beim Top Down Test

Zwischenschritt beim Bottom Up Test


Integrations-/Funktionstest


System-/Akzeptanztest

E/A SpezifikationProgramme

Benutzer-dokumentation

Leistungsbeschreibungder Programme

System-/Akzeptanztest


Sollte man Tests automatisieren? - Ja!

Automatisiertes Testen reduziert Testfehler Automatisiertes Testen reduziert den Einfluss individueller

Unterschiede Automatisiertes Testen konserviert Wissen, das sonst nur

im Gehirn des Testers vorhanden ist Automatisiertes Testen reduziert die Zufälligkeit der

Testfälle Automatisiertes Testen reduziert die Personalkosten Automatisiertes Testen reduziert die „Bottleneck“ Funktion

des Testens


Sollte man Tests automatisieren? Vielleicht! - ein Szenario

Automatisierungswerkzeuge sind vorhanden Tests können voll-, teil- oder gar nicht automatisiert werden Sowohl automatisiertes wie manuelles Testen sind

grundsätzlich möglich Das Unternehmen verlangt nicht unbedingt die

Automatisierung Der Test wird zunächst designed und dann die

Entscheidung gefällt Man hat nur eine bestimmte Zeit zum Testen


Sollte man Tests automatisieren? - drei entscheidende Fragen

Automatisieren und einmalige Ausführung eines Tests wird i. d. R. mehr kosten als ihn manuell durchzuführen. Wieviel mehr?

Ein automatisierter Test hat eine begrenzte Lebenszeit, in der er seine Kosten wieder einspielen muss. Wird dieser Test früher oder später sterben? Welche Ereignisse werden seinen Tod wahrscheinlich beeinflussen?

Wie wahrscheinlich ist es, dass dieser Test während seines Lebens neue Fehler findet? Wie verhält sich dieser unsichere Nutzen gegenüber den Automatisierungskosten?


Anforderungen an eine ideale Test Umgebung

Eine ideale Testumgebung sollte (nach Mosley): sowohl Mainframe als auch Client/Server Entwicklungsumgebungen unterstützen das Testen von Desk Top und Web Top Client/Server Anwendungen unterstützen von einem Anbieter kommen, der groß genug ist, um im Markt zu bleiben erweiterbar sein, wenn neue Testanforderungen auftreten automatisches Testmanagement, automatische Testausführung, automatisches

Aufzeichnen der Ergebnisse, automatische Verfolgung von Fehlern und Berichterstattung über Probleme sowie automatische Erstellung von Ergebnisberichten können

sollte Tests von Schnittstellen von Mainframe, Client/Server Desk Top und Client/Server Web Top erlauben

sollte Funktionstests in diesen Umgebungen unterstützen sollte Anwenderakzeptanztests in diesen Umgebungen unterstützen sollte Regressionstests in diesen Umgebungen unterstützen sollte es erlauben, dass Tests auf dem PC designed werden, aber auch dem Mainframe,

dem Client/Server Desk Top oder dem Client/Server Web Top ausgeführt werden


Einführung neuer Technologien

Zeit

Eng

agem

ent

des

Unt

erne

hmen

s

Erstkontakt

Auswertung

Probelauf

Einführung

Institutionalisierung

Verständnis

Bewußtsein

Quelle: Conner, Daryl R. et al., “Building Commitment to Organizational Change”Training and Development Journal, Vol 36 No 4, April 1982


Empfehlungen für den Auswahlprozess

Anforderungen an Testwerkzeuge in maximal 5 Tagen definieren Funktionalität von Testwerkzeugen untersuchen und Prioritäten für die

gewünschten Charakteristiken festlegen in maximal 10 Tagen durchführen Nicht mehr als 5 Tage für Demonstrationen von Werkzeugen verwenden Nicht mehr als 30 Tage für eine Probeinstallation verwenden Eine Langfristige Vision für den Einsatz von automatisierenden

Werkzeugen entwickeln. Die Vision sollte folgendes enthalten: Die Software-Entwicklungsmethode, die implementiert ist bzw.

implementiert werden sollte Den Software-Testprozess, der implementiert ist bzw. werden

implementiert soll Die zukünftige Computerumgebung des Unternehmens (% Mainframe

vs. Client/Server , % Desk Top vs. Web Top) Die Automatisierung möglichst aller Aktivitäten von Test Rx TM

Die Automatisierung des Testprozesses sollte Teil einer Initiative sein, den gesamten Entwicklungsprozess zu automatisieren


Gefundene Fehler und Automatisierungsgrad

0.00

0.25

0.50

0.75

1.00

0.0 0.5 1.0 1.5 2.0

Zeit (Beliebige Einheit)

An

zah

l der

Feh

ler

Niedriger Automationsgrad

Hoher Automationsgrad


Gefundene Fehler und Qualität des Entwicklungsprozesses

0,00

0,25

0,50

0,75

1,00

0,0 0,5 1,0 1,5 2,0

Zeit (Beliebige Einheit)

An

zah

l d

er

Fe

hle

r (N

orm

iert

)

Mittlere Qualität

Gute Qualität

Schlechte Qualität


Testwerkzeuge: Anforderungs-spezifikation und Design

Analysewerkzeuge für Pläne, Anforderungen und Designs Systemsimulatoren und Prototype Werkzeuge Anforderungsverfolgungswerkzeuge Anforderungsbasierte Testdaten-Generatoren Testplanungswerkzeuge


Testwerkzeuge: Implementierung und Wartung

Compiler Statische Quellcode Analysatoren

Audit Werkzeuge Komplexitätsgrad-Messwerkzeuge Cross Reference Werkzeuge Größenmewerkzeuge Werkzeuge zur Strukturüberprüfung Syntax und Semantik Analysatoren


Testwerkzeuge: Implementierung und Wartung - Fortsetzung

Werkzeuge zur Testvorbereitung Datenextraktoren Anwendungsbasierte Testdatengeneratoren Testdatengeneratoren Testplanungswerkzeuge



Testausführungswerkzeuge Capture-Replay Werkzeuge Deckungsgrad Analysatoren Debugger Emulatoren Netzanalyse Werkzeuge Performanzanalyse/Lasttest Werkzeuge Run-Time Fehlerprüfungswerkzeuge Simulatoren Testausführungsmanagement Werkzeuge Validierungswerkzeuge



Werkzeuge zur Testauswertung Vergleichswerkzeuge Werkzeuge zur Datenreduktion und -analyse Werkzeuge zur Verfolgung von

Fehlern/Veränderungen


Konstruktive QS-Maßnahmen (Beispiel Airbus)

Vorgehensmodell– Da es sich um die Einführung von Standardsoftware handelt, ist das Vorgehensmodell für Eigenentwicklung nicht geeignet.

Deshalb wurde das Vorgehensmodell von Peoplesoft gewählt. Um möglichst sicher zu gehen, wurde dieses gegen das Vorgehensmodell von SAP abgeglichen.

Eingesetzte Methoden und Werkzeuge– Entwicklungssprache: INFO– Testen: Mercury Testsuite– Ablaufdokumentation: ARIS– Textverarbeitung: MS Word– Spreadsheet: MS Excel– Projektmanagementsoftware: MS Project– Graphik: MS-Powerpoint

Ordnung halten im Projekt (Konfigurationsmanagement): Die Grundidee des Konfigurationsmanagements besteht darin, durch Disziplin und Systematik Ordnung zu halten. Regeln, wie dies für die Arbeitsergebnisse des Projekts zu geschehen hat, wurden im Document „Projektcontrolling und

Qualitätssicherung im IV-Projekt – Überblick“ festgelegt. Regeln für die Versionsführung der einzelnen System-Komponenten werden von Teilprojekt „Basis“ erarbeitet. Projekt-Office: Zur Unterstützung der Projekt- bzw. Teilprojektleitung wurde ein Projekt-Office eingerichtet. Seine Aufgaben sind:

– Definition/Auswahl des Vorgehensmodells– Unterstützung bei der Projektplanung und -controlling– Qualitätsplanung und Qualitätssicherung– Dokumentation des Projektablaufs in MS Projekt/Führung der Projektakte– Erstellung von Präsentationsmaterial für externe Präsentationen

Schulungsmaßnahmen:– Überblick über die Peoplesoft-Software für die Mitglieder des Projekt-Office– Schulung in „Structured Walk-Through“ für die Teammitglieder– Schulung in „Inspektion“ für ausgewählte Teammitglieder

Risikoanalyse: Um sicher zu gehen, dass alle notwendigen Vorkehrungen für den Projekterfolg getroffen wurden, wird eine Risiko-Analyse nach dem

S:PRIME Verfahren vorgeschlagen.


Analytische QS-Maßnahmen

Analytische QS-Maßnahmen haben die Prüfung, Bewertung und den Nachweis der Qualität des Prüfgegenstandes zum ziel. Analytische Maßnahmen sind z. B. :– Selbstprüfung = Prüfung eines Prüfobjekts durch den Ersteller– Verifizierung = Prüfung eines Prüfobjekts durch einen Prüfer– Prozessprüfung = Prüfung von Aktivitäten der Projektabwicklung– Ergebnisprüfung = Prüfung eines Zwischen- oder Endergebnisses– Test = Ausführung eines Programms mit der Absicht,

Fehler zu finden – Validierung = Überprüfung des fertigen Systems oder seiner Teile

durch den Anwender bzw. Auftraggeber oder einen

Experten, um festzustellen, ob es so funktioniert, wie erwartet diese Art der Prüfung findet nicht in Form von Reviews sondern im Rahmen des Akzeptanz- Tests statt)


Ausprägung der Prüfaktivitäten

Hier ist zu unterscheiden, ob eine Prüfung der Nachweisführung nach außen dient oder intern zur Feststellung des Bearbeitungsendes erfolgt.

Die Prüfung am Bearbeitungsende ist eine Selbstprüfung. Hier ist vom Qualitätsbeauftragten festzulegen, welcher Art diese Selbstprüfung ist und welchen QS-Vorschriften sie genügen soll:– Keine Vorgaben (außer Nachvollziehbarkeit), Dokumentation in freier Form– Checklisten, Dokumentation gemäß Checkliste– Genaue Spezifikation und Vorbereitung, Durchführung und Ausführung der

Prüfung, Dokumentation gemäß Anforderungen an ein QS-Review bzw. an einen Modultest.

Nach der Selbstprüfung wird das Arbeitsergebnis aus dem Status „in Bearbeit-ung“ in den Status „vorgelegt“ versetzt, der vom Ersteller selbst vergeben wird.

Die (formelle) Prüfung wird nach den Regelungen der QS durchgeführt. Sie stellt eine auch für Außenstehende nachvollziehbare Nachweisführung dar, dass das Prüfobjekt die gestellten Anforderungen erfüllt. Das Prüfobjekt rückt nach erfolgreicher Nachweisführung in den Status „akzeptiert“ vor. Die Prüfung wird gemäß Prüfspezifikation und Prüfprozedur durchgeführt (vgl. Qualitätsplan).


Prüfobjekte und QS-Maßnahmen (Beispiel Airbus Ausschnitt)


Prüfplan - Inhalt (Beispiel Airbus)

Allgemeines zum Prüfplan– Zielsetzung– Reichweite– Ergänzende Dokumente

Geplante Prüfungen– Teilprojekt Basis– Teilprojekt Integration Paisy– Teilprojekt Reporting– Teilprojekt Berechtigungskonzept

Abnahmegremium für Meilensteinabnahmen


Geplante Reviews - Beispiel

(I) = inhaltliche Prüfung(A) = Abgabetermin(F) = Formale Prüfung(R) = Reviewtermin


Zusammenwirken von Entwicklung und Qualitätssicherung

Entwicklung Qualitätssicherung

Festlegung derQualitätsziele

gemeinsam mit demAuftraggeber

Entwicklung gemäßkonstruktiver Maßnahmen

unter Berücksichtigungder

Qualitätsziele

Selbstprüfung nach(Teil-) Ergbnis-

erstellung

Definition erforderlicherkonstruktiver Maßnahmen

Festlegung von geeigneten analytischen

Prüfmaßnahmen

Nachweisführung: Prozeßprüfung

Ergebnisprüfung

(Teil-) Ergebnis

Entwicklungsprozeß

Qualitätsziele

KonstruktiveMaßnahmen

AnalytischePrüfmaßnahmen

Qualitätsziele


Kommunikationsplanung

Die Kommunikationsplanung ist die Voraussetzung dafür, dass die Projektbeteiligten die für sie relevanten Informationen rechtzeitig und zuverlässig erhalten (s. dazu Modul Projektberichtswesen).

Die Kommunikationsplanung wird im Kommunikationsmanagementplan dokumentiert. Darin ist folgendes enthalten (PMBOK):– Erfassungs- und Ablagesystem: welche Verfahren werden

eingesetzt, um die Informationen zu sammeln und zu speichern.– Verteiler: wer erhält welche Informationen in welcher Form.– Beschreibung der Informationen: Format, Inhalt,

Detaillierungsgrad.– Termine: wann werden die verschiedenen Berichte erstellt.– Verfahren für den Zugang zu Informationen zwischen den

geplanten Berichten.


Informationsfluss-Matrix (Beispiel)

Als hilfreich hat sich die Informationsfluss-Matrix erwiesen, die die wichtigen Informationen über die Informationsstruktur übersichtlich darstellt.

Wer an Wen? Projektleiter Projektteam

Auftraggeber/ Lenkungsaus-

schussProjektbüro

Projektleiter X

Wöchentliche

Projektsitzung

Monatlicher Statusbericht

Monatlicher Statusbericht

Projektteam

Ist-Daten

wöchentlich X Keine Meldung Keine Meldung

Auftraggeber/ Lenkungsaus-

schussÄnderungs-

anträgeKeine Meldung X

Anforderung von Budget/ Ressourcen,

Änderungsanträge

Projektbüro Keine Meldung Keine Meldung

Entscheidung über Budget/

Ressourcen,

Änderungsanträge

X


Ablauf der Projektdokumentation (Beispiel)

TH32RX Qualitäts-sicherung

Projekt-akte

Projekt-akte

historie

Teil-projekt

Selbst-prüfungerfo lgt

Vorprüfung durchden Teilpro jekt-le iter und ggf.

Zusatzprüfungen

nur Lesezugrifffür d ie Team s

R eviewerfo lgre ich

durchgeführt

C hecklisten

Form ulare

Tem plates

N eue E rgebnisse

Akzeptierte E rgebnisse

Der Mitarbeiter – TH32RX – erstellt ein Arbeitsergebnis und führt die Selbstprüfung durch. Der Teilprojektleiter überprüft das Arbeitsergebnisund stellt es in den Ordner ‚Neue Ergebnisse‘. Diese werden zu den geplanten Reviewterminen überprüft und bei Akzeptanz vom Qualitäts-beauftragten in den Ordner ‚Akzeptierte Ergebnisse‘ eingestellt. Der Qualitätsbeauftragte überführt die akzeptierten Ergebnisse in die Projektakte, auf die die ProjektMitarbeiter nur lesenden Zugriff haben.

Documents

Copyright: Dr. Klaus Röber 1 Workshop: IT-Projektmanagement - Version 3.0 - 06/2004Modul: Projektplanung Modul Projektplanung Literatur: Informationen