Upload
theudobald-armbrecht
View
133
Download
24
Embed Size (px)
Citation preview
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
Copyright: Dr. Klaus Röber 2Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 3Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
............................
.........
Copyright: Dr. Klaus Röber 4Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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?
Copyright: Dr. Klaus Röber 5Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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.
Copyright: Dr. Klaus Röber 6Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 7Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 8Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 9Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 10Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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)
Copyright: Dr. Klaus Röber 11Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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.
Copyright: Dr. Klaus Röber 12Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 13Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 14Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 15Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
Beispiel: Projektstrukturplan (www.hms-hopf-management.de)
Copyright: Dr. Klaus Röber 16Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
Beispiel: Projektstrukturplan (www.webagency.de)
Copyright: Dr. Klaus Röber 17Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
Beispiel: Projektstrukturplan (www.albbw.de)
Copyright: Dr. Klaus Röber 18Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
Beispiel: Formular zur Arbeitspaketbeschreibung
Quelle: Gruber
Copyright: Dr. Klaus Röber 19Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
Ü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
Copyright: Dr. Klaus Röber 20Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
Musterlösung
Quelle: Gruber
Copyright: Dr. Klaus Röber 21Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
Ü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
Copyright: Dr. Klaus Röber 22Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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).
Copyright: Dr. Klaus Röber 23Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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üß
Copyright: Dr. Klaus Röber 24Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 25Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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).
Copyright: Dr. Klaus Röber 26Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 27Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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.
Copyright: Dr. Klaus Röber 28Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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...
Copyright: Dr. Klaus Röber 29Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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.
Copyright: Dr. Klaus Röber 30Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
Ü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
Copyright: Dr. Klaus Röber 31Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 32Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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.
Copyright: Dr. Klaus Röber 33Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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)
Copyright: Dr. Klaus Röber 34Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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?
Copyright: Dr. Klaus Röber 35Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 36Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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.
Copyright: Dr. Klaus Röber 37Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 38Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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%
Copyright: Dr. Klaus Röber 39Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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%
Copyright: Dr. Klaus Röber 40Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 41Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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%
Copyright: Dr. Klaus Röber 42Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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.
Copyright: Dr. Klaus Röber 43Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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.
Copyright: Dr. Klaus Röber 44Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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.
Copyright: Dr. Klaus Röber 45Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
Integrierte Aufwands-, Termin- und Ressourcenplanung
Nr. Vorgangsname Arbeit Dauer
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.
Architektur-Team[3,17]
Entwicklungsteam[5,63]
Test-Management[2,28]
26.12.
Architektur-Team[2,73]
Entwicklungsteam[4,85
Test-Management
14.02.
Jul Aug Sep Okt Nov Dez Jan Feb Mrz Apr3. Quartal 4. Quartal 1. Quartal 2. Quart
Nr. Vorgangsname Arbeit Dauer
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
Copyright: Dr. Klaus Röber 46Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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.
Copyright: Dr. Klaus Röber 47Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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)
Copyright: Dr. Klaus Röber 48Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
Beispiel: Formular Kostenplanung
Quelle: G. Süß, Die wichtigsten Methoden im Projektmanagement, WEKA Verlag 2002
Copyright: Dr. Klaus Röber 49Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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).
Copyright: Dr. Klaus Röber 50Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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.
Copyright: Dr. Klaus Röber 51Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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.
Copyright: Dr. Klaus Röber 52Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 53Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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 .............................................................
Copyright: Dr. Klaus Röber 54Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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.
Copyright: Dr. Klaus Röber 55Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 56Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 57Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 58Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 59Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 60Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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.
Copyright: Dr. Klaus Röber 61Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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 ).
Copyright: Dr. Klaus Röber 62Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
Mit gutem Ziel gewinnt man viel.
Quelle: Chaos - ein Teutsches durcheinander von unterschiedlichen Sachen, D. Andr. Sutor, Augsburg 1716
Qualitätsziele (Erinnerung)
Copyright: Dr. Klaus Röber 63Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 64Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 65Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 66Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
Was ist Qualität – Definition der ISO (Norm 8402)
Copyright: Dr. Klaus Röber 67Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 68Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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.
Copyright: Dr. Klaus Röber 69Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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,
Copyright: Dr. Klaus Röber 70Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
Qualität
Zeit
Funktions-
umfang
Kosten
Teamleistung
--
++
Rahmenbedingungen: Das Teufelsquadrat
Copyright: Dr. Klaus Röber 71Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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.
Copyright: Dr. Klaus Röber 72Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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.
Copyright: Dr. Klaus Röber 73Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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.
Copyright: Dr. Klaus Röber 74Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 75Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 76Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 77Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
„ 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)
Copyright: Dr. Klaus Röber 78Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
„ 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.
Ziel Bewertungsmaß Erhebungsart Erfüllungsmaß
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)
Copyright: Dr. Klaus Röber 79Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
„ 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
Ziel Bewertungsmaß Erhebungsart Erfüllungsmaß
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)
Copyright: Dr. Klaus Röber 80Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
„ 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
Ziel Bewertungsmaß Erhebungsart Erfüllungsmaß
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)
Copyright: Dr. Klaus Röber 81Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
„ 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
Ziel Bewertungsmaß Erhebungsart Erfüllungsmaß
Zeit Zeitmessung Zeit <= x Stunden
Gehaltsabrechung ist in
x Stunden fertig
Qualitätsmerkmale: Effizienz (Beispiel aus einem Projekt)
Copyright: Dr. Klaus Röber 82Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
„ 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)
Copyright: Dr. Klaus Röber 83Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
„ 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
Ziel Bewertungsmaß Erhebungsart Erfüllungsmaß
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)
Copyright: Dr. Klaus Röber 84Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
„ 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)
Copyright: Dr. Klaus Röber 85Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
„ 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
Ziel Bewertungsmaß Erhebungsart Erfüllungsmaß
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)
Copyright: Dr. Klaus Röber 86Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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)
Copyright: Dr. Klaus Röber 87Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 88Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
Wo soll man ansetzen?
100%
75%
50%
25%
FehlerverhütungPrüfkosten
Fehlerkosten
Folgekosten
Copyright: Dr. Klaus Röber 89Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 90Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 91Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 92Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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!
Copyright: Dr. Klaus Röber 93Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
Ö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ß.
Copyright: Dr. Klaus Röber 94Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 95Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 96Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 97Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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 %
Copyright: Dr. Klaus Röber 98Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 99Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
Fehlerursprung und Entdeckung
Anforderungen Design Codierung Dokumentation Test Wartung
Anforderungen Design Codierung Dokumentation Test Wartung
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
Copyright: Dr. Klaus Röber 100Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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.
Copyright: Dr. Klaus Röber 101Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 102Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
Unterstützende Basistechniken
Konfigurationsmanagement (KM) Fehlerverfolgung und Problem-Dokumentation (FP) Testautomation (TA) Peer Reviews (PR) Testmetriken (TM)
Copyright: Dr. Klaus Röber 103Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 104Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 105Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 106Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 107Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 108Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 109Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 110Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
White Box Methoden - Auswahl
Überdeckungsorientierte Testfallbestimmung Datenflussorientierte Testfallbestimmung Bereichsorientierte Testfallbestimmung
Copyright: Dr. Klaus Röber 111Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 112Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 113Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
Modultest: Inkrementelles vs. nicht-inkrementelles Testen
Nicht-inkrementellesTesten: Big Bang
InkrementellesTesten
1.
2.
3.
4.
5.
6.
1.
2.
3.
4.
5.
6.
7.
Copyright: Dr. Klaus Röber 114Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
Inkrementelles Testen: Top Down vs. Bottom Up
STUB 1
STUB 2
Treiber 1
Zwischenschritt beim Top Down Test
Zwischenschritt beim Bottom Up Test
Copyright: Dr. Klaus Röber 115Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
Integrations-/Funktionstest
Copyright: Dr. Klaus Röber 116Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
System-/Akzeptanztest
E/A SpezifikationProgramme
Benutzer-dokumentation
Leistungsbeschreibungder Programme
System-/Akzeptanztest
Copyright: Dr. Klaus Röber 117Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 118Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 119Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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?
Copyright: Dr. Klaus Röber 120Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 121Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 122Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 123Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 124Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 125Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
Testwerkzeuge: Anforderungs-spezifikation und Design
Analysewerkzeuge für Pläne, Anforderungen und Designs Systemsimulatoren und Prototype Werkzeuge Anforderungsverfolgungswerkzeuge Anforderungsbasierte Testdaten-Generatoren Testplanungswerkzeuge
Copyright: Dr. Klaus Röber 126Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 127Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
Testwerkzeuge: Implementierung und Wartung - Fortsetzung
Werkzeuge zur Testvorbereitung Datenextraktoren Anwendungsbasierte Testdatengeneratoren Testdatengeneratoren Testplanungswerkzeuge
Copyright: Dr. Klaus Röber 128Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
Testwerkzeuge: Implementierung und Wartung - Fortsetzung
Testausführungswerkzeuge Capture-Replay Werkzeuge Deckungsgrad Analysatoren Debugger Emulatoren Netzanalyse Werkzeuge Performanzanalyse/Lasttest Werkzeuge Run-Time Fehlerprüfungswerkzeuge Simulatoren Testausführungsmanagement Werkzeuge Validierungswerkzeuge
Copyright: Dr. Klaus Röber 129Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
Testwerkzeuge: Implementierung und Wartung - Fortsetzung
Werkzeuge zur Testauswertung Vergleichswerkzeuge Werkzeuge zur Datenreduktion und -analyse Werkzeuge zur Verfolgung von
Fehlern/Veränderungen
Copyright: Dr. Klaus Röber 130Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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.
Copyright: Dr. Klaus Röber 131Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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)
Copyright: Dr. Klaus Röber 132Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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).
Copyright: Dr. Klaus Röber 133Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
Prüfobjekte und QS-Maßnahmen (Beispiel Airbus Ausschnitt)
Copyright: Dr. Klaus Röber 134Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 135Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
Geplante Reviews - Beispiel
(I) = inhaltliche Prüfung(A) = Abgabetermin(F) = Formale Prüfung(R) = Reviewtermin
Copyright: Dr. Klaus Röber 136Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 137Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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.
Copyright: Dr. Klaus Röber 138Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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
Copyright: Dr. Klaus Röber 139Workshop: IT-Projektmanagement - Version 3.0 - 06/2004 Modul: Projektplanung
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.