Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

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

Ähnliche Präsentationen


Präsentation zum Thema: "Copyright: Dr. Klaus Röber 1 Workshop: IT-Projektmanagement - Version 3.0 - 06/2004Modul: Projektplanung Modul Projektplanung Literatur: Informationen."—  Präsentation transkript:

1 Copyright: Dr. Klaus Röber 1 Workshop: IT-Projektmanagement - Version /2004Modul: 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

2 Copyright: Dr. Klaus Röber 2 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Motivation für Projektplanung

3 Copyright: Dr. Klaus Röber 3 Workshop: IT-Projektmanagement - Version /2004Modul: 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 Projektauftrag definierten Teilprojekte separat durchgeführt Projektplan Phase 1 Phase 2 Phase n Phasenplan 1 Phasenplan 2 Phasenplan n Projektplan überarbeitet

4 Copyright: Dr. Klaus Röber 4 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Kernprozesse der Projektplanung ProjektstrukturierungWas ist alles zu tun? MeilensteinplanungWelches sind wichtige Ereignisse im Projektverlauf? EinsatzmittelbedarfsplanungWie viel Arbeitsaufwand und welche sachlichen Einsatzmittel sind zur Erbringung von Arbeitsergebnissen notwendig? TerminplanungIn welcher Reihenfolge und zu welchen Terminen müssen die Arbeitspakete abgearbeitet werden? KostenplanungWie viel Kosten verursachen die einzelnen Arbeitspakete? PlanoptimierungStimmt der bis dahin geplante Projektverlauf mit den Wünschen des Auftraggebers überein? RisikomanagementplanungSind die Aktivitäten des Risikomanagements für das Projekt definiert? IntegrationsmanagementErgibt sich bei der Zusammenführung der Ergebnisse aller Planungsprozesse ein aufeinander abgestimmtes, schlüssiges Dokument?

5 Copyright: Dr. Klaus Röber 5 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Unterstützungsprozesse der Projektplanung RisikoanalyseWas könnte mein Projekt gefährden und welche Maßnahmen kann ich dagegen treffen? QualitätsplanungSind die Qualitätsstandards definiert und ist geplant, wie sie eingehalten werden können? KommunikationsplanungIst 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.

6 Copyright: Dr. Klaus Röber 6 Workshop: IT-Projektmanagement - Version /2004Modul: 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

7 Copyright: Dr. Klaus Röber 7 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Einige Begriffe Zeit - Aufwand- Spanne- Punkt = Ressourcen- verbrauch = Dauer= Termin Z.B. 2 MT (Menschtage) Z.B. 2 Arbeitstage Z.B Uhr

8 Copyright: Dr. Klaus Röber 8 Workshop: IT-Projektmanagement - Version /2004Modul: 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

9 Copyright: Dr. Klaus Röber 9 Workshop: IT-Projektmanagement - Version /2004Modul: 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

10 Copyright: Dr. Klaus Röber 10 Workshop: IT-Projektmanagement - Version /2004Modul: 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)

11 Copyright: Dr. Klaus Röber 11 Workshop: IT-Projektmanagement - Version /2004Modul: 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.

12 Copyright: Dr. Klaus Röber 12 Workshop: IT-Projektmanagement - Version /2004Modul: 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

13 Copyright: Dr. Klaus Röber 13 Workshop: IT-Projektmanagement - Version /2004Modul: 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

14 Copyright: Dr. Klaus Röber 14 Workshop: IT-Projektmanagement - Version /2004Modul: 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 Entwicklung Maschine Gehäuse Schalt- technik Hard- ware Soft- ware Steuerung Beispiel: objektorientierte Strukturierung

15 Copyright: Dr. Klaus Röber 15 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Beispiel: Projektstrukturplan (www.hms-hopf-management.de)

16 Copyright: Dr. Klaus Röber 16 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Beispiel: Projektstrukturplan (www.webagency.de)

17 Copyright: Dr. Klaus Röber 17 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Beispiel: Projektstrukturplan (www.albbw.de)

18 Copyright: Dr. Klaus Röber 18 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Beispiel: Formular zur Arbeitspaketbeschreibung Quelle: Gruber

19 Copyright: Dr. Klaus Röber 19 Workshop: IT-Projektmanagement - Version /2004Modul: 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

20 Copyright: Dr. Klaus Röber 20 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Musterlösung Quelle: Gruber

21 Copyright: Dr. Klaus Röber 21 Workshop: IT-Projektmanagement - Version /2004Modul: 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

22 Copyright: Dr. Klaus Röber 22 Workshop: IT-Projektmanagement - Version /2004Modul: 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).

23 Copyright: Dr. Klaus Röber 23 Workshop: IT-Projektmanagement - Version /2004Modul: 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üß

24 Copyright: Dr. Klaus Röber 24 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Meilenstein-Plan: Beispiel

25 Copyright: Dr. Klaus Röber 25 Workshop: IT-Projektmanagement - Version /2004Modul: 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).

26 Copyright: Dr. Klaus Röber 26 Workshop: IT-Projektmanagement - Version /2004Modul: 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

27 Copyright: Dr. Klaus Röber 27 Workshop: IT-Projektmanagement - Version /2004Modul: 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.

28 Copyright: Dr. Klaus Röber 28 Workshop: IT-Projektmanagement - Version /2004Modul: 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...

29 Copyright: Dr. Klaus Röber 29 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Beispiel zur Aufwandschätzung (Quelle: Süß) AP-Nr.AP-BezeichnungBearbeiterAufwand [PT] PE [%]Dauer [Tage] 1.1Detailplanung Programminhalte Müller55011,5 Schmitt55011,5 Meier ,5 Huber ,5 1.2Erstellung Texte Schmitt51005,75 Huber ,25 1.3Programmierung Müller Personentag ist ja bekanntlich nicht gleich Tag. Dies kann man mit einem Aufschlag von x% auf den Aufwand berücksichtigen: Dauer = (1 + x)*Aufwand/Personaleinsatz. Beispiels- Weise rechnet man oft mit 15% Aufschlag.

30 Copyright: Dr. Klaus Röber 30 Workshop: IT-Projektmanagement - Version /2004Modul: 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

31 Copyright: Dr. Klaus Röber 31 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Aufwandschätzung Musterlösung AP-Nr.BezeichnungMitarbeiterAufwand [PT] PE [%]Dauer [Tage] Konzeption erstellen 1.1Fachkonzept erstellenHr. Huber Berichte erstellenHr. Klaus108014,5 1.3Technikkonzept erstellenFr. Schubert Umsetzung und Test durchführen 2.1Änderungen im Tool vornehmenFr. Schubert Anschließen an die DatenbankFr. Schubert ,5 2.3Test durchführenFr. Seibert51006 Pilotprojekte durchführen 3.1Einführung in das ToolHr. Stern2504,5 3.2Support der PilotprojekteHr. Stern Abschlussbericht erstellenHr. Stern2505 Inbetriebnahme durchführen 4.1Änderungen lt. Pilotprojekt umsetzenFr. Schubert ,5 4.2Anwenderschulung durchführenFr. Ansorge InstallationFr. Schubert11001,5

32 Copyright: Dr. Klaus Röber 32 Workshop: IT-Projektmanagement - Version /2004Modul: 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.

33 Copyright: Dr. Klaus Röber 33 Workshop: IT-Projektmanagement - Version /2004Modul: 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)

34 Copyright: Dr. Klaus Röber 34 Workshop: IT-Projektmanagement - Version /2004Modul: 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 Auftragsabwicklung von 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 ihre Beziehung zu vorhergehenden und nachfolgenden Aufgaben analysiert: - Welche Arbeitspakete können unabhängig voneinander durchgeführt werden? - Welche Arbeitspakete sind unmittelbare Voraussetzungen? - Welche Arbeitspakete können unmittelbar folgen?

35 Copyright: Dr. Klaus Röber 35 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Ablauf- und Terminplanung: Grafische Darstellung Modul Netzplantechnik und Balkendiagramme

36 Copyright: Dr. Klaus Röber 36 Workshop: IT-Projektmanagement - Version /2004Modul: 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.

37 Copyright: Dr. Klaus Röber 37 Workshop: IT-Projektmanagement - Version /2004Modul: 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

38 Copyright: Dr. Klaus Röber 38 Workshop: IT-Projektmanagement - Version /2004Modul: 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 %

39 Copyright: Dr. Klaus Röber 39 Workshop: IT-Projektmanagement - Version /2004Modul: 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 % 120%

40 Copyright: Dr. Klaus Röber 40 Workshop: IT-Projektmanagement - Version /2004Modul: 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

41 Copyright: Dr. Klaus Röber 41 Workshop: IT-Projektmanagement - Version /2004Modul: 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 %

42 Copyright: Dr. Klaus Röber 42 Workshop: IT-Projektmanagement - Version /2004Modul: 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.

43 Copyright: Dr. Klaus Röber 43 Workshop: IT-Projektmanagement - Version /2004Modul: 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 abgeschlossen sein. Laut Vereinbarung mit dem Auftraggeber muss der Meilenstein spätestens am 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.

44 Copyright: Dr. Klaus Röber 44 Workshop: IT-Projektmanagement - Version /2004Modul: 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.

45 Copyright: Dr. Klaus Röber 45 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Integrierte Aufwands-, Termin- und Ressourcenplanung

46 Copyright: Dr. Klaus Röber 46 Workshop: IT-Projektmanagement - Version /2004Modul: 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.

47 Copyright: Dr. Klaus Röber 47 Workshop: IT-Projektmanagement - Version /2004Modul: 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)

48 Copyright: Dr. Klaus Röber 48 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Beispiel: Formular Kostenplanung Quelle: G. Süß, Die wichtigsten Methoden im Projektmanagement, WEKA Verlag 2002

49 Copyright: Dr. Klaus Röber 49 Workshop: IT-Projektmanagement - Version /2004Modul: 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).

50 Copyright: Dr. Klaus Röber 50 Workshop: IT-Projektmanagement - Version /2004Modul: 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.

51 Copyright: Dr. Klaus Röber 51 Workshop: IT-Projektmanagement - Version /2004Modul: 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.

52 Copyright: Dr. Klaus Röber 52 Workshop: IT-Projektmanagement - Version /2004Modul: 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

53 Copyright: Dr. Klaus Röber 53 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Gliederung des Dokumentes Projektplan : Beispiel (Krafft Foods)

54 Copyright: Dr. Klaus Röber 54 Workshop: IT-Projektmanagement - Version /2004Modul: 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.

55 Copyright: Dr. Klaus Röber 55 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Top Ten Risikoelemente - typische Maßnahmen (1) Quelle: Helmut Balzert, Lehrbuch der Software-Technik, Bd. 1, Spektrum 1998

56 Copyright: Dr. Klaus Röber 56 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Top 10 Risikoelemente - typische Maßnahmen (2) Quelle: Helmut Balzert, Lehrbuch der Software-Technik, Bd. 1, Spektrum 1998

57 Copyright: Dr. Klaus Röber 57 Workshop: IT-Projektmanagement - Version /2004Modul: 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. KategorieBeschreibung des RisikosAuswirkungAlternative MaßnahmenEmpfehlung TerminAuftragserfassung kann nicht zeitgerecht ausgeliefert werden. HochWarten bis die Auftragserfassung implementiert werden kann 2 Funktionalität der Auftragserfassung reduzieren 3 Erstellen eines Bridge- Programms zum existierenden Auftrags- Erfassungssystem 1 BedienungDas vorgesehene Personal kann nicht eingesetzt werden MittelBeschaffen von qualifiziertem Personal 1 Intensives Training für das unerfahrene Personal 2

58 Copyright: Dr. Klaus Röber 58 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Qualitätsmanagement im Projekt planen: Wirtschaftlichkeit

59 Copyright: Dr. Klaus Röber 59 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Prozess Qualitätsmanagement (nach dem V-Modell)

60 Copyright: Dr. Klaus Röber 60 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Produkte des Qualitätsmanagements n Der Qualitäts-Plan beinhaltet die übergeordnete QS- Planung für das gesamte Projekt n Pro Phase eines Projektes und für jeden unterstützenden Prozess (PM, KM, QM ) gibt es jeweils einen Prüfplan. n Jedem Prüfgegenstand ist eine Prüfspezifikation (Checkliste ) als Input zugeordnet. n Als Ergebnis der Prüfung ist jedem Prüfgegenstand ein Prüfprotokoll zugeordnet (s. Projektcontrolling) n Die Anzahl der Prüfspezifikationen und Prüfprotokolle ist von der Anzahl der Prüfgegenstände abhängig.

61 Copyright: Dr. Klaus Röber 61 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Qualitätsmanagement: Rollen und Verantwortungen

62 Copyright: Dr. Klaus Röber 62 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Mit gutem Ziel gewinnt man viel. Quelle: Chaos - ein Teutsches durcheinander von unterschiedlichen Sachen, D. Andr. Sutor, Augsburg 1716 Qualitätsziele (Erinnerung)

63 Copyright: Dr. Klaus Röber 63 Workshop: IT-Projektmanagement - Version /2004Modul: 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

64 Copyright: Dr. Klaus Röber 64 Workshop: IT-Projektmanagement - Version /2004Modul: 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

65 Copyright: Dr. Klaus Röber 65 Workshop: IT-Projektmanagement - Version /2004Modul: 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 Crosbys 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

66 Copyright: Dr. Klaus Röber 66 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Was ist Qualität – Definition der ISO (Norm 8402)

67 Copyright: Dr. Klaus Röber 67 Workshop: IT-Projektmanagement - Version /2004Modul: 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

68 Copyright: Dr. Klaus Röber 68 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Benutzungsfreundlichkeit Dokumentation Funktionalität Integration Effizienz Portabilität Sicherheit Wartbarkeit Zuverlässigkeit Qualitätsmerkmale eines Softwareprodukts - Beispiel In Anlehnung an ISO/IEC Es gibt diverse andere Ansätze, dies ist nur ein Beispiel.

69 Copyright: Dr. Klaus Röber 69 Workshop: IT-Projektmanagement - Version /2004Modul: 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,

70 Copyright: Dr. Klaus Röber 70 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Qualität Zeit Funktions- umfang Kosten Teamleistung Rahmenbedingungen: Das Teufelsquadrat

71 Copyright: Dr. Klaus Röber 71 Workshop: IT-Projektmanagement - Version /2004Modul: 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.

72 Copyright: Dr. Klaus Röber 72 Workshop: IT-Projektmanagement - Version /2004Modul: 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 einen guten Zweck. Diese werden durch das QMS und die Qualitätsziele des Auftraggebers bereit gestellt.

73 Copyright: Dr. Klaus Röber 73 Workshop: IT-Projektmanagement - Version /2004Modul: 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.

74 Copyright: Dr. Klaus Röber 74 Workshop: IT-Projektmanagement - Version /2004Modul: 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

75 Copyright: Dr. Klaus Röber 75 Workshop: IT-Projektmanagement - Version /2004Modul: 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

76 Copyright: Dr. Klaus Röber 76 Workshop: IT-Projektmanagement - Version /2004Modul: 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

77 Copyright: Dr. Klaus Röber 77 Workshop: IT-Projektmanagement - Version /2004Modul: 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 ZielBewertungsmaßErhebungsartErfüllungsmaß ZeitZeitmessung Antwortzeiten im On-Line Betrieb in 95% aller Fälle unter 1 sek. Qualitätsmerkmale: Benutzerfreundlichkeit ( Beispiel aus einem Projekt )

78 Copyright: Dr. Klaus Röber 78 Workshop: IT-Projektmanagement - Version /2004Modul: 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. ZielBewertungsmaßErhebungsartErfüllungsmaß Versionsführung in den Dokumenten: – Versionsnummer vorhanden – Versionsnummer fehlt Review der Dokumente 100 % dieser Dokumente haben eine Versions- führung Qualitätsmerkmale: Dokumentation ( Beispiel aus einem Projekt )

79 Copyright: Dr. Klaus Röber 79 Workshop: IT-Projektmanagement - Version /2004Modul: 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 ZielBewertungsmaßErhebungsartErfü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 )

80 Copyright: Dr. Klaus Röber 80 Workshop: IT-Projektmanagement - Version /2004Modul: 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 ZielBewertungsmaßErhebungsartErfü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 )

81 Copyright: Dr. Klaus Röber 81 Workshop: IT-Projektmanagement - Version /2004Modul: 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 ZielBewertungsmaßErhebungsartErfüllungsmaß ZeitZeitmessung Zeit <= x Stunden Gehaltsabrechung ist in x Stunden fertig Qualitätsmerkmale: Effizienz ( Beispiel aus einem Projekt )

82 Copyright: Dr. Klaus Röber 82 Workshop: IT-Projektmanagement - Version /2004Modul: 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 )

83 Copyright: Dr. Klaus Röber 83 Workshop: IT-Projektmanagement - Version /2004Modul: 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 ZielBewertungsmaßErhebungsartErfü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 )

84 Copyright: Dr. Klaus Röber 84 Workshop: IT-Projektmanagement - Version /2004Modul: 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 )

85 Copyright: Dr. Klaus Röber 85 Workshop: IT-Projektmanagement - Version /2004Modul: 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 ZielBewertungsmaßErhebungsartErfü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 )

86 Copyright: Dr. Klaus Röber 86 Workshop: IT-Projektmanagement - Version /2004Modul: 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 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 enthalten erläuternde Notizen (Ansicht-Notizenseite von Powerpoint)

87 Copyright: Dr. Klaus Röber 87 Workshop: IT-Projektmanagement - Version /2004Modul: 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

88 Copyright: Dr. Klaus Röber 88 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Wo soll man ansetzen?

89 Copyright: Dr. Klaus Röber 89 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Fehlerverhütung: Wer macht die Fehler?

90 Copyright: Dr. Klaus Röber 90 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Fehlerverhütung: Ursachen für menschlich bedingte Fehler

91 Copyright: Dr. Klaus Röber 91 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Fehlerverhütung: Ursachen für sachlich bedingte Fehler

92 Copyright: Dr. Klaus Röber 92 Workshop: IT-Projektmanagement - Version /2004Modul: 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!

93 Copyright: Dr. Klaus Röber 93 Workshop: IT-Projektmanagement - Version /2004Modul: 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ß.

94 Copyright: Dr. Klaus Röber 94 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Management und Messbarkeit Spezifizieren der Anforderungen Spezifizieren des Modultests Ausführen des Modultests Codieren der Programme Spezifizieren des Design Ausführen des Systemtests Ausführen des Integrations- und Funktionstests Ausführen des Akzeptanztests Review/Audit des Modultests Review des Codes Spezifizieren des Integrations- und Funktionstests Spezifizieren des System- und Akzeptanztests Review der Anforderungen Review/Audit des Integrations- und Funktionsteststests Review des Designs Review des System- 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

95 Copyright: Dr. Klaus Röber 95 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Ergebnis Maßnahmen Anforderungen Systemkonzept DesignProgrammSystem Analyse Test Verifikation Validierung ***** **** ** ****** Quelle: im wesentlichen nach Trauboth, Software Qualitätssicherung, Oldenbourg, 1996 *** ** * häufiger weniger häufig selten Inspektionen Dokumente *** ** () * Einsatz analytischer Testmethoden

96 Copyright: Dr. Klaus Röber 96 Workshop: IT-Projektmanagement - Version /2004Modul: 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

97 Copyright: Dr. Klaus Röber 97 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Ursachen für Softwarefehler Fehlerursache End-User Systeme Anforderungen Design Quellcode Handbücher und Trainingsmaterial Sekundärfehler (fehlerhafte Wartung) Total Durch- schnitt Militär Systeme Systems- software MIS Outsource Systeme Kommerz. Systeme 0,00 % 15,00 % 55,00 % 10,00 % 20,00 % 100,00 % 15,00 % 30,00 % 35,00 % 10,00 % 100,00 % 20,00 % 25,00 % 35,00 % 10,00 % 100,00 % 10,00 % 30,00 % 20,00 % 10,00 % 100,00 % 10,00 % 25,00 % 40,00 % 15,00 % 10,00 % 100,00 % 20,00 % 35,00 % 15,00 % 10,00 % 100,00 % 12,50 % 24,17 % 38,33 % 13,33 % 11,67 % 100,00 %

98 Copyright: Dr. Klaus Röber 98 Workshop: IT-Projektmanagement - Version /2004Modul: 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 ausgezeichnet gut schwach zufrieden- stellend zufrieden- stellend zufrieden- stellend Zufrieden- stellend zufrieden- stellend nicht anwendbar gut schwach Quelle: Capers Jones, Software Quality - Analysis and Guidelines for Success, International Thomson Computer Press 1997

99 Copyright: Dr. Klaus Röber 99 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Fehlerursprung und Entdeckung AnforderungenDesignCodierungDokumentationTestWartung AnforderungenDesignCodierungDokumentationTestWartung AnforderungenDesignCodierungDokumentationTestWartung AnforderungenDesignCodierungDokumentationTestWartung Fehler- ursprung Fehler- ursprung Fehler- entdeckung Fehler- entdeckung Ohne Einsatz formaler Inspektionsmethoden Mit Einsatz formaler Inspektionsmethoden Chaos-Phase

100 Copyright: Dr. Klaus Röber 100 Workshop: IT-Projektmanagement - Version /2004Modul: 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.

101 Copyright: Dr. Klaus Röber 101 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Einbettung der Methode Test Rx TM in den Entwicklungszyklus Prozessschritte Entwicklungs- 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/Design Konstruktion Test Wartung Projekt-/Testmanager Testmanager/Tester Tester Entwickler/Tester Tester

102 Copyright: Dr. Klaus Röber 102 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Unterstützende Basistechniken +Konfigurationsmanagement (KM) +Fehlerverfolgung und Problem-Dokumentation (FP) +Testautomation (TA) +Peer Reviews (PR) +Testmetriken (TM)

103 Copyright: Dr. Klaus Röber 103 Workshop: IT-Projektmanagement - Version /2004Modul: 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 FPTAPRTM - = nicht erforderlich, o = optional, x = erforderlich -ooooxxxxx-ooooxxxxx -----xx-xx-----xx-xx -oxxxxxoxx-oxxxxxoxx xxxxxxxxxxxxxxxxxxxx -xxx-xxxxx-xxx-xxxxx

104 Copyright: Dr. Klaus Röber 104 Workshop: IT-Projektmanagement - Version /2004Modul: 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

105 Copyright: Dr. Klaus Röber 105 Workshop: IT-Projektmanagement - Version /2004Modul: 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 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 Februars >Einbeziehen von Daten, die verschiedene Jahrhunderte abdecken >Einbeziehen von Daten, die außerhalb des Zyklus (z. B. des Buchungszyklus) liegen

106 Copyright: Dr. Klaus Röber 106 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Integration der Testplanung in den Entwicklungszyklus Entwicklungszyklusphase Zu erstellender Testplan Auszuführender Testplan Analyse System Design Detailliertes Design Konstruktion Test Produktion/Wartung Systemtestplan Regressionstestplan Integrationstestplan Modultestplan Regressionstestplan Modultestplan Integrationstestplan Systemtestplan

107 Copyright: Dr. Klaus Röber 107 Workshop: IT-Projektmanagement - Version /2004Modul: 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

108 Copyright: Dr. Klaus Röber 108 Workshop: IT-Projektmanagement - Version /2004Modul: 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

109 Copyright: Dr. Klaus Röber 109 Workshop: IT-Projektmanagement - Version /2004Modul: 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

110 Copyright: Dr. Klaus Röber 110 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung White Box Methoden - Auswahl +Überdeckungsorientierte Testfallbestimmung +Datenflussorientierte Testfallbestimmung +Bereichsorientierte Testfallbestimmung

111 Copyright: Dr. Klaus Röber 111 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Fehlererwartung (Error Guessing) Manche Menschen besitzen eine natürliche Begabung zum Programmtesten. Ohne Verwendung einer speziellen Methode scheinen sie über eine Spürnase zum Entdecken von Fehlern zu verfügen. G. J. Myers, Methodisches Testen von Programmen, Oldenbourg 1995

112 Copyright: Dr. Klaus Röber 112 Workshop: IT-Projektmanagement - Version /2004Modul: 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

113 Copyright: Dr. Klaus Röber 113 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Modultest: Inkrementelles vs. nicht-inkrementelles Testen Nicht-inkrementelles Testen: Big Bang Inkrementelles Testen

114 Copyright: Dr. Klaus Röber 114 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Inkrementelles Testen: Top Down vs. Bottom Up STUB 1 STUB 2 Treiber 1 Zwischenschritt beim Top Down Test Zwischenschritt beim Bottom Up Test

115 Copyright: Dr. Klaus Röber 115 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Integrations-/Funktionstest

116 Copyright: Dr. Klaus Röber 116 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung System-/Akzeptanztest E/A Spezifikation Programme Benutzer- dokumentation Leistungsbeschreibung der Programme System-/Akzeptanz test

117 Copyright: Dr. Klaus Röber 117 Workshop: IT-Projektmanagement - Version /2004Modul: 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

118 Copyright: Dr. Klaus Röber 118 Workshop: IT-Projektmanagement - Version /2004Modul: 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

119 Copyright: Dr. Klaus Röber 119 Workshop: IT-Projektmanagement - Version /2004Modul: 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?

120 Copyright: Dr. Klaus Röber 120 Workshop: IT-Projektmanagement - Version /2004Modul: 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

121 Copyright: Dr. Klaus Röber 121 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Einführung neuer Technologien Zeit Engagement des Unternehmens 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

122 Copyright: Dr. Klaus Röber 122 Workshop: IT-Projektmanagement - Version /2004Modul: 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

123 Copyright: Dr. Klaus Röber 123 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Gefundene Fehler und Automatisierungsgrad Zeit (Beliebige Einheit) Anzahl der Fehler Niedriger Automationsgrad Hoher Automationsgrad

124 Copyright: Dr. Klaus Röber 124 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Gefundene Fehler und Qualität des Entwicklungsprozesses 0,00 0,25 0,50 0,75 1,00 0,00,51,01,52,0 Zeit (Beliebige Einheit) Anzahl der Fehler (Normiert) Mittlere Qualität Gute Qualität Schlechte Qualität

125 Copyright: Dr. Klaus Röber 125 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Testwerkzeuge: Anforderungs-spezifikation und Design +Analysewerkzeuge für Pläne, Anforderungen und Designs +Systemsimulatoren und Prototype Werkzeuge +Anforderungsverfolgungswerkzeuge +Anforderungsbasierte Testdaten-Generatoren +Testplanungswerkzeuge

126 Copyright: Dr. Klaus Röber 126 Workshop: IT-Projektmanagement - Version /2004Modul: 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

127 Copyright: Dr. Klaus Röber 127 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Testwerkzeuge: Implementierung und Wartung - Fortsetzung +Werkzeuge zur Testvorbereitung >Datenextraktoren >Anwendungsbasierte Testdatengeneratoren >Testdatengeneratoren >Testplanungswerkzeuge

128 Copyright: Dr. Klaus Röber 128 Workshop: IT-Projektmanagement - Version /2004Modul: 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

129 Copyright: Dr. Klaus Röber 129 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Testwerkzeuge: Implementierung und Wartung - Fortsetzung +Werkzeuge zur Testauswertung >Vergleichswerkzeuge >Werkzeuge zur Datenreduktion und -analyse >Werkzeuge zur Verfolgung von Fehlern/Veränderungen

130 Copyright: Dr. Klaus Röber 130 Workshop: IT-Projektmanagement - Version /2004Modul: 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.

131 Copyright: Dr. Klaus Röber 131 Workshop: IT-Projektmanagement - Version /2004Modul: 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)

132 Copyright: Dr. Klaus Röber 132 Workshop: IT-Projektmanagement - Version /2004Modul: 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).

133 Copyright: Dr. Klaus Röber 133 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Prüfobjekte und QS-Maßnahmen (Beispiel Airbus Ausschnitt)

134 Copyright: Dr. Klaus Röber 134 Workshop: IT-Projektmanagement - Version /2004Modul: 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

135 Copyright: Dr. Klaus Röber 135 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Geplante Reviews - Beispiel (I) = inhaltliche Prüfung (A) = Abgabetermin (F) = Formale Prüfung (R) = Reviewtermin

136 Copyright: Dr. Klaus Röber 136 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Zusammenwirken von Entwicklung und Qualitätssicherung

137 Copyright: Dr. Klaus Röber 137 Workshop: IT-Projektmanagement - Version /2004Modul: 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.

138 Copyright: Dr. Klaus Röber 138 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Informationsfluss-Matrix (Beispiel) Als hilfreich hat sich die Informationsfluss-Matrix erwiesen, die die wichtigen Informationen über die Informationsstruktur übersichtlich darstellt. Wer an Wen?ProjektleiterProjektteam Auftraggeber/ Lenkungsaus- schuss Projektbüro ProjektleiterX Wöchentliche Projektsitzung Monatlicher Statusbericht Projektteam Ist-Daten wöchentlichXKeine Meldung Auftraggeber/ Lenkungsaus- schuss Änderungs- anträge Keine MeldungX Anforderung von Budget/ Ressourcen, Änderungsanträge ProjektbüroKeine Meldung Entscheidung über Budget/ Ressourcen, Änderungsanträge X

139 Copyright: Dr. Klaus Röber 139 Workshop: IT-Projektmanagement - Version /2004Modul: Projektplanung Ablauf der Projektdokumentation (Beispiel) Der Mitarbeiter – TH32RX – erstellt ein Arbeitsergebnis und führt die Selbstprüfung durch. Der Teilprojektleiter überprüft das Arbeitsergebnis und 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.


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

Ähnliche Präsentationen


Google-Anzeigen