Post on 11-Aug-2019
transcript
Wintersemester 2012/2013
Dr. Gerhard Pews
IT-Projektmanagement
Teil 3: Projektverlauf
Dieser Vorlesungsteil vertieft die Projektvorbereitung und die Tätigkeiten
innerhalb eines Projekts.
Einordnung in den Fahrplan der Vorlesung
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 2
Inhalte
• Einführung
• Das „Was“: Der Gegenstand von Softwareprojekten
• Das „Wie“: Die Tätigkeiten in einem Projekt und wie man sie ausführt
• Vorbereitung eines Projekts
• Projektplanung
• Durchführen eines Projekts
• Unterstützende Tätigkeiten
• Soft Factors
• Wirtschaftliche Aspekte
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 3
• Einführung
• Von der Vorstudie zum Projektauftrag
• Projektinitialisierung
• Kick-Off
• Projektdurchführung
• Touch-Down
AGENDA
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 4
Ziel dieser Einheit ist, den Studierenden das Wissen über die
Durchführung der Projektaktivitäten zu vermitteln.
Ziele der Vorlesungseinheit
Inhalte
• Diese Einheit orientiert sich am Ablauf eines Projekts
• Tätigkeiten werden vorgestellt
• Die Nutzung typischer Werkzeuge wird vermittelt
• Besonders prominente Tätigkeiten wie z. B. Schätzung oder Planung werden in eigenen, späteren Einheiten behandelt.
• Ein Schwerpunkt liegt auf der Projektvorbereitung.
Der Projektablauf teilt sich in die eigentliche Projektdurchführung sowie
vor- und nachbereitende Phasen
Projektablauf in der Übersicht
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 5
Projekt- Idee und Studie
Beauftragung Projekt- initiali- sierung
Projekt- durchführung
Ab- nah- me
Aus- schrei- bung
Ange- bot
Auf- trag
Kick- Off- Meeting
Touch down
Anfor- derungs- analyse
Fachliche Konzeption
Tech. Konzeption
Reali- sierung
Test & Integr.
Ab- nah- me
Ab- nah- me
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 6
• Einführung
• Von der Vorstudie zum Projektauftrag
• Projektinitialisierung
• Kick-Off
• Projektdurchführung
• Touch-Down
AGENDA
Dem Projekt vorgelagert ist die Entwicklung einer Projektidee und ggf.
eine Vorstudie.
Projektablauf in der Übersicht
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 7
Beauftragung Projekt- initiali- sierung
Projekt- durchführung
Ab- nah- me
Aus- schrei- bung
Ange- bot
Auf- trag
Kick- Off- Meeting
Touch down
Anfor- derungs- analyse
Fachliche Konzeption
Tech. Konzeption
Reali- sierung
Test & Integr.
Ab- nah- me
Ab- nah- me
Projekt- Idee und Studie
IT-Projekte können unterschiedliche Auslöser haben.
Entstehung von IT-Projekten: Auslöser von IT-Projekten
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 8
Auslöser Business Case
Handlungs-bedarf IT
IT-Projekt
(Auftrag)
Beispielhafte Auslöser
• In einem Großunternehmen wird eine neue Unternehmensstrategie festgelegt, bzw. neue Aspekte eingebracht.
• Eine neue IT-Strategie wird festgelegt.
• Ein Programm zur Kostensenkung/Effizienzsteigerung wird aufgelegt.
• Ein neuer Markt soll erschlossen werden.
Im Business Case wird der Grundgedanke des Projekts konkretisiert.
Entstehung von IT-Projekten: Business Case
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 9
Business Case
• Ein Business Case wird erstellt:
– Warum lohnt sich eine Investition: was ist der erwartete Nutzen, was sind die erwarteten Kosten?
– Was sind die zu ändernden Bereiche? (neue Software, neue Prozesse, neue Produkte – nur ein Teil betrifft die IT)
– Ab wann überwiegt der Nutzen (gespartes/eingenommenes Geld) die Kosten der Investition? (ROI – Return On Investment)
Auslöser Business Case
Handlungs-bedarf IT
IT-Projekt
(Auftrag)
In der IT entsteht der Handlungsbedarf, ein Projekt durchzuführen.
Entstehung von IT-Projekten: Handlungsbedarf in der IT
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 10
In der IT entsteht Handlungsbedarf, z. B.
– neue Software
– umfangreiche Umstellung bestehender Software
ein Projekt
Handlungsbedarf IT
Auslöser Business Case
Handlungs-bedarf IT
IT-Projekt
(Auftrag)
Oft ist es sinnvoll, eine Vorstudie dem Projekt voranzustellen.
Einordnung einer Vorstudie
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 11
Legt wesentliche Punkte eines Projekts grob fest:
• Kosten
• Ziel (Leistungsumfang)
• Zeitrahmen (ROI)
Business Case
Dient dem Nachweis von Machbarkeit und Nutzen eines Software-Projekts. Sie legt in der Regel fest:
• Die wichtigsten Anforderungen an eine Software
• Eine grobe Skizze der technischen Realisierung
Vorstudie
Eine Studie im Vorfeld gibt es z. B. in folgenden Fällen:
• bei größeren Vorhaben
• wenn die Aufgabenstellung noch nicht ganz klar ist
• wenn genauer nachvollzogen werden soll, ob sich die Investition lohnt.
Im Projektauftrag konkretisiert sich das Projekt.
Projektablauf in der Übersicht
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 12
Projekt- Idee und Studie
Projekt- initiali- sierung
Projekt- durchführung
Ab- nah- me
Aus- schrei- bung
Ange- bot
Auf- trag
Kick- Off- Meeting
Touch down
Anfor- derungs- analyse
Fachliche Konzeption
Tech. Konzeption
Reali- sierung
Test & Integr.
Ab- nah- me
Ab- nah- me
Beauftragung
Mit dem Projektauftrag müssen die Vorstellungen von Auftraggeber und
Auftragnehmer in Deckung gebracht werden.
Der Auftrag legt fest, welches Ergebnis das Projekt erzielt
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 13
Ziel, Weg, Randbedingungen (z. T. unscharf)
Auftraggeber Auftragnehmer
Auftrag
Ziel, Weg, Randbe-dingungen
Lieferung Projektergebnis (scharf)
Konflikt- potential
Nicht vorhandene oder unzureichend fixierte Aufträge sind ein großes
Problem im Projektmanagement.
Probleme bei der Erteilung eines Auftrags
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 14
Ziel, Weg, Randbe-dingungen
Auftraggeber Auftragnehmer
Auftrag
Ziel, Weg, Randbe-dingungen
• nur mündlich, nicht dauerhaft fixiert
• unklar, zusätzliche Nebenabsprachen
• Inkonsistent, unvollständig
Probleme
Die erste und wichtigste Aufgabe im Projekt ist es, für einen klaren
Projektauftrag zu sorgen.
Fixieren des Projektauftrags
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 15
Auftrag
• Ziele und Aufgabenstellung für das Projekt glasklar festlegen
• Schriftlich fixiert: Bei Gesprächen ist vieles „klar“, richtig klar ist es erst, wenn es schriftlich festgehalten ist.
• Verbindlichkeit schaffen: der Auftraggeber unterschreibt den Auftrag.
Fixieren des Auftrags
Der Projektauftrag fixiert die wesentlichen
Punkte zu einem Projekt.
Inhalte eines Projektauftrags
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 16
Checklisten- Folie
• Projektleiter: Verantwortlicher für das Projekt
• Auftraggeber: Wer will das Projekt eigentlich? Derjenige, der bezahlt, bestimmt auch – oder – wer bestimmen will, muss auch zahlen.
• Kurzbeschreibung des Projekts
• Anforderungen, Rahmenbedingungen, Prämissen
• Ziele, ggf. hierarchisch verfeinert
• Zu erbringende Leistungen und Ergebnisse, Ausgrenzungen und Annahmen
• Abhängigkeiten von anderen Projekten und Personen, Zulieferungen
• Start, Ende, Meilensteine
• Change Request-Verfahren
Projektauftrag
Wenn der Projektauftrag nicht unterschrieben wird, ist das ein sehr
ernstes Warnzeichen.
Gründe für einen Start ohne unterschriebenen Auftrag
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 17
• Geld ist schon da, verfällt sonst
• Projektmitarbeiter sind schon freigestellt, müssen beschäftigt werden
• Formulierung scheitert an vermeintlich unwichtigen Details
• Das Schreiben ist lästig, der Kopf ist voller Ideen und man möchte lieber loslegen.
Die Versuchung, einfach loszulegen, ist groß
• Oft gibt es versteckte Gründe, die das Projekt insgesamt in Frage stellen und die Unterschrift verhindern.
• Wenn es wirklich so klar ist, dass der Auftrag unterschrieben werden wird, warum ist es noch nicht längst geschehen?
Tiefere Ursachen
Wird ein Projektauftrag nicht unterschrieben, muss das Projekt reagieren.
Reaktionsmöglichkeiten bei fehlender Beauftragung
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 18
• Eskalation bis zu einer Instanz im Projektmanagement, die die Beauftragung durchsetzen kann
• Wenn es die nicht gibt, wird das Projekt in große Schwierigkeiten kommen
• Arbeiten auf einer Arbeitshypothese
• Nicht abgestimmten Auftrag formulieren und als Arbeitshypothese nutzen
• Diese Arbeitshypothese klar kommunizieren.
Optionen
Auf gar keinen Fall einfach so loslegen!
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 19
• Einführung
• Von der Vorstudie zum Projektauftrag
• Projektinitialisierung
• Kick-Off
• Projektdurchführung
• Touch-Down
AGENDA
Die Projektinitialisierung ist die wichtigste und kritischste Phase im
Projekt.
Projektablauf in der Übersicht
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 20
Projekt- Idee und Studie
Beauftragung Projekt- durchführung
Ab- nah- me
Aus- schrei- bung
Ange- bot
Auf- trag
Kick- Off- Meeting
Touch down
Anfor- derungs- analyse
Fachliche Konzeption
Tech. Konzeption
Reali- sierung
Test & Integr.
Ab- nah- me
Ab- nah- me
Projekt- initiali- sierung
Die Projektinitialisierung ist die wichtigste Phase eines Projekts.
Einordnung der Projektinitialisierung
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 21
• Ein Projekt in einer bestimmten Richtung aufzusetzen und anzuschieben ist relativ einfach. Ein Projekt, das in Fahrt gekommen ist, auf einen anderen Weg zu lenken, ist extrem aufwändig.
• Während ein Projekt läuft, können so gut wie keine grundsätzlichen Korrekturen mehr vorgenommen werden.
Bedeutung der Initialisierung
• Alle Rahmenbedingungen für das Team sind geschaffen
• Die Arbeit kann beginnen, das Team kann loslegen.
Ziel der Projektinitialisierung
Die Projektinitialisierung muss von den Keyplayern des späteren Projekts
durchgeführt werden.
Mitwirkende bei der Projektinitialisierung
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 22
Ansprechpartner für Fragen als Gegenstück zum Projektteam
Projektleiter
Qualitätssicherer
Subject Matter Expert (SME), Architekt, sorgt für inhaltliche Kontinuität aus dem Angebot
Auftragnehmer Auftraggeber
Eine Initialisierung des Projekts ohne den Projektleiter und sein späteres
Team verliert deutlich an Wert.
Konsequenzen mangelnder Initialisierung
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 23
• Die Initialisierung findet erst während des Projekts statt
• Zeitverlust
• Schon geleistete Arbeit ist ggf. überholt und verschwendet.
• Initialisierung nur oberflächlich durchgeführt und resultiert später in Problemen
• Das Projekt ist zu Beginn führungslos
• Eine Initialisierung ohne Projektleiter findet nur halbherzig statt, da die beteiligten Personen von den Folgen einer mangelhaften Initialisierung nicht direkt betroffen sind.
Mögliche Konsequenzen, wenn der PL zu spät in das Projekt kommt
• Projektleiter sind rar, deshalb nicht beliebig verfügbar
• Als designierter Projektleiter kann man darauf hinwirken, nicht zu spät ins Projekt zu kommen
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 24
Tätigkeiten innerhalb der Projektinitialisierung
• Ziele klären
• Qualitätskriterien klären
• Organisation des Projekts festlegen, incl. Ansprechpartner des
Auftraggebers
• Projektstruktur festlegen (Projektstrukturplan)
• Schätzung validieren
• Planung: Grobplanung, Feinplanung für die ersten Schritte
• Infrastruktur etablieren
• Struktur für das Controlling aufsetzen
• Im Projekthandbuch festhalten.
Eigene Themen, später
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 25
AGENDA
• Einführung
• Von der Vorstudie zum Projektauftrag
• Projektinitialisierung
• Kick-Off
• Projektdurchführung
• Touch-Down
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 26
AGENDA
• Einführung
• Von der Vorstudie zum Projektauftrag
• Projektinitialisierung
• Kick-Off
• Projektdurchführung
• Touch-Down
–Ziele
–Qualitätskriterien
–Projektstruktur
–Qualitätsmanagement
–Infrastruktur
–Controlling-Strukturen
–Projekthandbuch
Das Fallbeispiel verdeutlicht, dass Projektbeteiligte nicht automatisch
das gleiche Verständnis für Ziele haben.
Fallbeispiel zu Projektzielen
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 27
Entwickler: Wir wollen das Altsystem ablösen. Das alte System hat zwar noch funktioniert, wir brauchen aber ein neues System, weil die VAX-Plattform ausläuft und demnächst nicht mehr existiert. Dabei ziehen wir noch ein paar Dinge im System gerade, die uns schon seit langem gestört haben.
IT-Chefin: Wir wollen ein Referenzsystem für unseren Konzern schaffen. Dieses System ist die Grundlage für die neue europäische IT-Architektur. Da kommt es gerade recht, dass wir eh an dieses System ranmüssen.
Ziele sind elementar wichtig für Projekte und andere Tätigkeiten
Motivation
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 28
Bedeutung von Zielen
Ziele haben eine elementare Bedeutung für ein Projekt:
• Gemeinsames Bild, Verständnis, Ausrichtung
• Präzisierung von schwammigen Vorstellungen
Ziele für verschiedene Aufgaben
Ziele sollte man für alle wichtigen Tätigkeiten definieren, z. B.:
• Meetings
– Schlechtes Ziel: „Wir haben darüber gesprochen“
• Dokumente
– wozu ist das Dokument gut, was macht man damit?
Ziele müssen einfach kommunizierbar sein und die richtigen Inhalte in
der richtigen Form transportieren.
Leitlinien für die Erstellung von Zielen
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 29
Einfach kommunizierbar
• Ziele auf den Punkt bringen, hierarchisch verfeinern. vgl: „elevator pitch“: Die Zeit, die man während einer Fahrstuhlfahrt hat, um das Wichtigste zu vermitteln.
• Was man nicht in 5 Minuten erklären kann, taugt entweder nichts oder man hat es nicht verstanden.
Die richtigen Inhalte
• Ausgangsbasis für Projektziele: Auftrag, Vertrag, Briefing, etc.
• Ziele SMART festhalten
Die richtige Form
• Ziele attraktiv formulieren
Die Inhalte der Ziele sollten Vorgaben folgen, die unter dem Akronym
SMART zusammengefasst werden.
Regeln für SMARTe Ziele
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 30
S pezifisch Knackig, verständlich, eindeutig, stimmig mit
anderen Zielen.
M easurable Messbar. Es muss klar sein, wann das Ziel
erreicht ist.
A chievable Erreichbar. Unerreichbare Ziele führen zu
Demotivation.
R elevant Die wichtigen Dinge als Ziel formulieren,
nicht jeden Kleinkram.
T ime-based Es gibt einen Zeitpunkt, an dem das Ziel
erreicht sein soll (ist im Projektkontext
automatisch gegeben)
Hinweis: Für das Akronym SMART findet man manchmal auch noch alternative
Auslegungen: schriftlich, simple, attractive realistic (gleichbedeutend zu achievable)
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 31
Attraktive Ziele
Antoine de Saint Exupéry:
„Wenn du mit anderen ein
Schiff bauen willst, so beginne
nicht, mit ihnen Holz zu
sammeln, sondern wecke in
ihnen die Sehnsucht nach dem
großen, weiten Meer.“
Eine attraktive Zielformulierung ist aktiv, im Präsens und positiv
formuliert.
Hinweise zur attraktiven Zielformulierung
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 32
Regel
Aktiv formulieren
Als erreicht formulieren
Positiv formulieren
Aktive Formulierung wählen:
• Nicht: Man wird mir das Rauchen abgewöhnen
• Sondern: Ich werde nicht mehr rauchen.
Ein Ziel so formulieren, als ob es schon erreicht ist (Gegenwart statt Zukunft):
• Nicht: Ich werde nicht mehr rauchen
• Sondern: Ich rauche nicht mehr.
Ein Ziel positiv formulieren:
• Nicht: Ich rauche nicht mehr.
• Sondern: Ich kann frei atmen, ich bin gesund
Hinweise und Beispiele
Sinn: den Zielzustand heute schon im Kopf erleben, damit man diesen Zustand anstrebt.
Es ist nicht hilfreich, bei fehlenden Aussagen zu den Zielen einfach
loszulegen.
Vorgehen bei fehlenden Aussagen zu Zielen
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 33
Problem
Was tun, wenn es keine klare Aussage zu den Zielen vom Auftraggeber gibt?
Nicht hilfreich
• Nicht einfach loslegen und die Versäumnisse anderer kompensieren wollen.
• Aber: blockieren ist nicht hilfreich.
Lösungsmöglichkeit
• Formulieren von Zielen in der Form von Arbeitshypothesen
• Arbeitshypothesen dem Auftraggeber klar kommunizieren
Dieses Vorgehen funktioniert generell an vielen Stellen des Projekts.
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 34
AGENDA
• Einführung
• Von der Vorstudie zum Projektauftrag
• Projektinitialisierung
• Kick-Off
• Projektdurchführung
• Touch-Down
–Ziele
–Qualitätskriterien
–Projektstruktur
–Qualitätsmanagement
–Infrastruktur
–Controlling-Strukturen
–Projekthandbuch
Neben den Projektzielen gibt es für den Auftraggeber noch
Qualitätskriterien, an denen er den Projekterfolg misst.
Beschreibung von Qualitätskriterien
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 35
Qualitätskriterien
• Qualitätskriterien sind in der Regel nicht als explizite Projektziele formuliert
• Beispiele:
– Know-how beim Auftraggeber aufbauen
– Sich pro-aktiv um alles kümmern (Auftraggeber-Sorglos-Paket)
– Qualifizierte Mitarbeiter ins Projekt stecken
– Schnelle Resultate, schnell ein vorzeigbares Ergebnis
Qualitätskriterien müssen direkt erfragt werden
Erfragen von Qualitätskriterien
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 36
Erfragen von Qualitätskriterien
• Vom Auftraggeber die Kriterien erfragen, nach denen er seine Zufriedenheit misst.
• Herausfinden, an welchen Ecken des Teufelsquadrats gezogen werden kann.
• Tipp: Nicht mit einer Auswahlliste arbeiten, sondern frei formulieren lassen. Nur bei Bedarf mit Beispielen aushelfen
Vom Auftraggeber nicht genannte Kriterien sind für ihn entweder selbstverständlich oder weniger wichtig.
Fallbeispiele zeigen, dass Auftraggeber unterschiedliche
Qualitätskriterien wichtig sind
Fallbeispiele für Qualitätskriterien
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 37
Fall 1: Entwicklungsprojekt
• Technische Expertise
• Teamfähige Mitarbeiter (gemischte Teams)
• Flexibilität (bzgl. zum Beispiel Arbeitszeiten vor Einführungsterminen)
• Preis-Leistungsverhältnis
Fall 2: Beratungsprojekt
• Die Projektarbeit soll „beim Thema bleiben“
• Projektziel einhalten
• Keine unnützen Formalismen
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 38
AGENDA
• Einführung
• Von der Vorstudie zum Projektauftrag
• Projektinitialisierung
• Kick-Off
• Projektdurchführung
• Touch-Down
–Ziele
–Qualitätskriterien
–Projektstruktur
–Qualitätsmanagement
–Infrastruktur
–Controlling-Strukturen
–Projekthandbuch
Große Projekte werden erst dann beherrschbar, wenn man eine sinnvolle
Aufteilung in Teilthemen findet
Reduktion der Komplexität durch Teilthemen
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 39
Wichtig: die Teilthemen sollten möglichst unabhängig voneinander sein
Der Projektstrukturplan (PSP) zerlegt das Projekt in handhabbare Teile.
Motivation eines Projektstrukturplans
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 40
Ziel
Handhabbare Teile
Orientierung
• Prinzip: „Teile und herrsche“
• Zerlegung des Projekts in kleinere Einheiten, die man besser managen kann.
• Wichtig: Reduktion und Transparenz der Abhängigkeiten und damit der Komplexität.
• vgl. englische Bezeichnung: „work breakdown structure“ (WBS)
• Finden einer grundsätzlichen Strukturierung, mit der man das Projekt im Griff hat.
• Diese Strukturierung findet man an vielen Stellen im Projekt, z. B.:
– Gliederung von Konzepten
– Teamstrukturen
– Planungsstränge
Hinweise
Ein Projektstrukturplan lässt sich anhand verschiedener
Strukturierungsmerkmale bilden.
Strukturierungsmerkmale für einen PSP
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 41
Produktstruktur
1
3 2
Funktionen/ Rollen
Projekt- ablauf
PSP
1. Produktstruktur
• Orientierung an den Teilen des zu erstellenden Produkts, z. B. einer zu erstellende Software.
• Orientierung an den Liefergegenständen.
2. Funktionen/Rollen
• Orientierung an den Projektrollen, den Skills der einzelnen Mitarbeitern
3. Projektablauf
• Orientierung an den Arbeitsschritten, dem Vorgehen zur Erstellung des Ergebnisses.
• Mischformen sind üblich.
• Ein PSP muss – wie jeder Plan – bei Bedarf angepasst werden.
Im Beispiel wird ein Projekt nach der zu erstellenden Software
strukturiert.
Fallbeispiel für einen an der Produktstruktur orientierten PSP
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 42
Fachlichkeit
System zum Verkauf von Konzertkarten, Funktionalität:
• Verkauf von Plätzen in Hallen, Verwaltung von freien und belegten Sitzen
• Abrechnung der Tickets
PSP 1: Strukturierung nach Produkt
• Pflege der Stammdaten: Konzert, Halle, Sitz, Preis, Künstler, etc.
• Verkauf der Karten
• Abrechnung, Bezahlung von Künstlern/Agenturen
• Basisfunktionen, z. B.: Berechnung von Restplätzen oder elementare Datenzugriffsfunktionen
Das gleiche Projekt ließe sich auch nach anderen Kriterien strukturieren.
PSP nach Funktionen/Rollen und nach Projektablauf
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 43
PSP 3: Strukturierung nach Projektablauf
• Fachkonzeption
• Technische Konzeption
• Realisierung
• Test/Integration
PSP 2: Strukturierung nach Funktionen/Rollen
• Fachlichkeit: Themen, die von Fachspezialisten z. B. für juristische Fragestellungen oder Abrechnungsfragen bearbeitet werden. Diese Spezialisten erfassen z. B. Anforderungen und führen Tests durch
• GUI-Design: Themen für HTML/Flash-Spezialisten
• Programmierung: Themen für Software-Entwickler
Betriebliche Informationssysteme lassen sich oft nach einem festen
Schema nach Produktstruktur zerlegen
Häufig anwendbares Schema für die Zerlegung von Betrieblichen IS
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 44
Schema für Strukturierung nach Produkt
• Stammdatenpflege (GUI): Pflege der wesentlichen Entitäten im System
• Erstellung von Aufträgen: Aufträge definieren Aufgaben, die das System durchführen soll. Diese werden aber nicht online, sondern asynchron im Hintergrund abgearbeitet.
• Automatisierte Auftragsbearbeitung: Abwicklung der eingegebenen Aufträge
• Gemeinsam genutzte Basisfunktionen
Ein an der Produktstruktur orientierter PSP minimiert die Abhängigkeiten
üblicherweise am stärksten.
Diskussion der Alternativen
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 45
Der Projektstrukturplan ist das wesentliche Mittel, um ein Projekt handhabbar zur machen und damit kritisch für den Projekterfolg.
Hinweise
• An der Produktstruktur orientierter PSP
– minimiert die inhaltlichen Abhängigkeiten in der Regel am besten
– benötigt aber in der Regel auch Mitarbeiter, die verschiedene Tätigkeiten/Rollen im Projekt durchführen können
– ist nur mit guter Fachkenntnis zu finden
• Ein an Ablauf oder Rollen orientierter PSP
– ist auch ohne Kenntnis der Fachlichkeit zu finden, aber weniger wirksam.
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 46
AGENDA
• Einführung
• Von der Vorstudie zum Projektauftrag
• Projektinitialisierung
• Kick-Off
• Projektdurchführung
• Touch-Down
–Ziele
–Qualitätskriterien
–Projektstruktur
–Qualitätsmanagement
–Infrastruktur
–Controlling-Strukturen
–Projekthandbuch
In der Projektinitialisierung sollte auch das Qualitätsmanagement
aufgesetzt werden
Hinweise zum Aufsetzen des Qualitätsmanagements
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 47
Sinn der Initialisierung zu diesem frühen Zeitpunkt
• Viele Projektrisiken und Qualitätsanforderungen sind zu diesem Zeitpunkt schon bekannt
• Jetzt kann man planerisch und organisatorisch reagieren.
Konkrete Todos
• Erstellen eines ersten Wurfs der Risikoliste (konkretes Vorgehen und Vertiefung später)
• Aufsetzen eines QM-Plans, in dem die wesentlichen Qualitätsmerkmale und Maßnahmen für konstruktive und analytische Qualitätssicherung festgehalten sind. (Vertiefung später in der Vorlesung)
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 48
AGENDA
• Einführung
• Von der Vorstudie zum Projektauftrag
• Projektinitialisierung
• Kick-Off
• Projektdurchführung
• Touch-Down
–Ziele
–Qualitätskriterien
–Projektstruktur
–Qualitätsmanagement
–Infrastruktur
–Controlling-Strukturen
–Projekthandbuch
Die Etablierung der Projektinfrastruktur ist aufwändig und sollte früh
angegangen werden.
Hinweise zum Aufbau der Infrastruktur
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 49
Motivation
Etablieren der Infrastruktur hört sich trivial an, aber
• ist zeitaufwändig und daher nicht zu unterschätzen
• nicht vorhandene Infrastruktur behindert das Team massiv.
Aufbau der Infrastruktur früh planen und initiieren, Anschaffungen haben oft langen Vorlauf.
Die Projektinfrastruktur umfasst
• Generell: alle Hilfsmittel, die das Team zum Arbeiten benötigt, z. B.: Räume, Arbeitsmittel, Software-Umgebungen, Dateiablage, Werkzeuge
• Ggf. Nutzungskonzepte, wie diese genutzt werden sollen.
Zur Projektinfrastruktur gehören Arbeitsmittel und eine Projektablage.
Beispiele und Hinweise zu Arbeitsmitteln und Projektablage
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 50
Arbeitsmittel
• Räume
• Rechner, Drucker, Telefone, Videokonferenz…
• Email-Verteiler anlegen
Gemeinsame Räume sind wichtig für Informationsfluss und Teamgeist.
Projektlaufwerk/Projektablage
• z. B. gemeinsames Netzlaufwerk (mit Sicherung!)
• für verteilte Teams und Teams unterschiedlicher Firmen: BSCW, Sharepoint (Projektverzeichnisse per WebDav)
Hinweise:
• Die Ablage sollte konform zu Organisation und Projektstrukturplan sein
• Namenskonventionen erstellen: Namensgebung von Ordnern und Dateien.
Projekte benötigen je nach Größe einen umfangreichen Werkzeug-Stack.
Beispiele und Hinweise zu Werkzeugen in Projekten
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 51
Werkzeuge (Beispiele)
• Office-Tools, Dokumenterstellung, Druckstückerzeugung/PDF, Zeichentools.
• Entwicklungs-Tools: Software-Entwicklung (IDE), Konfig-Mgmt, Test, Modellierungstools, DB-Tool
• Management-Tools: Projektplanungstool, Anforderungsmanagement, Testfallmanagement
• Kommunikationstools wie Wiki, NetMeeting, Office Communicator etc.
Hinweis Nutzungskonzepte: Ein Tool allein reicht oft nicht, es muss auch festgelegt sein, wie es im Projekt eingesetzt werden soll.
Während der Projektinitialisierung sollte man bereits den Aufbau der
Software-Umgebungen initiieren
Hinweise und Beispiele zu Umgebungen
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 52
Umgebungen
• Software-Umgebungen
– Entwicklung
– Test
– Qualitätssicherung
• Wenn schon bekannt: Aufbau der Software-Infrastruktur planen bzw. veranlassen, z. B.:
– Middleware wie CORBA, MQ-Series,
– ApplicationServer,
– Datenbank
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 53
AGENDA
• Einführung
• Von der Vorstudie zum Projektauftrag
• Projektinitialisierung
• Kick-Off
• Projektdurchführung
• Touch-Down
–Ziele
–Qualitätskriterien
–Projektstruktur
–Qualitätsmanagement
–Infrastruktur
–Controlling-Strukturen
–Projekthandbuch
Die Erfassung der Arbeitszeiten in einem Projekt erfolgt in der Regel über
Werkzeuge, in denen Kontierungen erfasst werden.
Schema für Arbeitszeiterfassung
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 54
Aufgabe (Konto) Mo Di Mi Do Fr
Konzeption Phase 1 5,5 8
Realisierung Dialoge 2,5 8,5 8
Schulung 8
Summe 8 8 8,5 8 8
Zeiterfassung
• Der Mitarbeiter erfasst die Arbeitszeit, die er für verschiedene Aufgaben erbracht hat.
• Der Projektleiter erhält eine Auswertung, welche Aufwände in Summe für eine Aufgabe erbracht wurden und wer alles Aufwände erbracht hat.
Typischerweise hat man intern und extern unterschiedliche Sichten auf
ein Projekt
Innen- und Außensicht auf Projektaufwände
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 55
Konten & Aufwände
Innensicht
Detaillierte Beschreibung, wer wann an welcher Aufgabe gearbeitet hat
Außensicht
Dient als Abrechnungsgrundlage in Richtung Auftraggeber
Unterschiede zwischen den Sichten
• Die Sichten unterscheiden sich normalerweise. Beispiele:
– Nach außen dargestellte Aufwände sind weniger granular als in der internen Darstellung
– In manchen Fällen werden z. B. Reisekosten nicht extern ausgewiesen, müssen aber natürlich trotzdem intern erfasst werden.
– Extern wird eine Abrechnung auf Tagesbasis vorgenommen. Die Maßeinheit „1Tag“ kann sich aber je nach Mitarbeiter und Arbeitsvertrag unterscheiden: 7,7h (38,5h-Woche), 8h (40h-Woche), 9h oder 10h.
Die Strukturen des Projektcontrolling sollten früh genug erstellt werden
und sich am Projektplan orientieren.
Tipps zum Aufsetzen der Kontenstruktur
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 56
Hinweise zum Aufsetzen der Kontenstrukturen
• Früh genug aufsetzen: Am besten in der Projektinitialisierung die Konten festlegen. Falsch oder gar nicht erfasste Kontierungen lassen sich im Nachhinein kaum noch rekonstruieren.
Das ist besonders wichtig, wenn die Kontierung als Grundlage für Rechnungen genutzt wird, z. B. bei freiberuflichen Projektmitarbeitern
• Nicht zu granular: Eher Tage als Stunden. Zu detaillierte Kontierung belastet die Mitarbeiter über Gebühr und wird selten wirklich benötigt.
• Analog zu Projektplan: Die Konten/Aufgaben orientieren sich an den Tätigkeiten im Projektplan.
• Einfach bleiben: Nicht zu viele Sichten definieren, z.B. für den Einsatz von freiberuflichen Mitarbeitern. Auch wenn sich die Umrechnungsregeln einfach anhören, bringen sie unnötige Komplexität in das Projekt.
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 57
AGENDA
• Einführung
• Von der Vorstudie zum Projektauftrag
• Projektinitialisierung
• Kick-Off
• Projektdurchführung
• Touch-Down
–Ziele
–Qualitätskriterien
–Projektstruktur
–Qualitätsmanagement
–Infrastruktur
–Controlling-Strukturen
–Projekthandbuch
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 58
Tätigkeiten innerhalb der Projektinitialisierung
Ziele klären (im letzten Abschnitt mit Auftrag besprochen)
Qualitätskriterien klären
Organisation des Projekts festlegen, incl. Ansprechpartner des
Auftraggebers
Projektstruktur festlegen (Projektstrukturplan)
Schätzung validieren
Planung: Grobplanung, Feinplanung für die ersten Schritte
Infrastruktur etablieren
Struktur für das Controlling aufsetzen
Im Projekthandbuch festhalten.
Die Ergebnisse der Projektinitialisierung werden im Projekthandbuch
festgehalten
Allgemeine Hinweise zum Projekthandbuch
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 59
Ziel eines Projekthandbuchs
• Ein Mitarbeiter, der neu in das Projekt kommt, findet dort alle Informationen, die er benötigt, um arbeitsfähig zu sein.
• Es ist der zentrale Einstiegspunkt, von dem aus man sich das ganze Projekt erschließen kann.
Erstellung
Ein Projekthandbuch wird während der Projektinitialisierung erstellt und ständig fortgeschrieben
Umsetzung
Ein Projekthandbuch kann ein Foliensatz, ein Textdokument oder auch z. B. ein Wiki sein.
Projekthandbücher müssen angemessen und einfach sein.
Tipps zum Projekthandbuch
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 60
Hinweise
• Einfach halten. Keine Wissenschaft aus dem Projekthandbuch machen! Es ist ein Einstieg und dient zur Übersicht der wichtigsten Projektinformationen.
• Angemessenheit. Das Projekthandbuch muss dem Projekt angemessen sein. Kein 200-Seiter für ein 50-Tage-Projekt.
• Wiki-Hinweise:
– Klare Verantwortlichkeit für die Redaktion des Wiki festlegen.
– Auf Möglichkeit achten, das Projekthandbuch auch mal offline nutzen zu können (z. B. Ausgedruckt in der S-Bahn)
Ein Projekthandbuch sollte alles das enthalten, was für den Einstieg in
das Projekt nützlich ist.
Hinweise zum Inhalt eines Projekthandbuchs
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 61
Inhalte
• Die Inhalte müssen alles Wichtige zum Projekt in der richtigen Tiefe abdecken.
• Viele Teile finden sich immer wieder in Projekthandbüchern, sie können als Anregung und Gedächtnisstütze dienen
Projektinhalt
Planung
Projektorganisation
Qualitätsmanagement
Aufwandsverfolgung
Projektablage
Interne Handbücher
Sonstiges
Das Projekthandbuch gibt einen kompletten Überblick über das Projekt
und sein Umfeld und stellt die Planung im Überblick dar.
Inhalte der Themenbereiche „Projektinhalt“ und „Planung“
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 62
Projektinhalt
• ggf. Vorgeschichte, übergeordnetes Ziel, Business Case
• Kurze Darstellung des Projektinhalt
• Referenz auf Auftrag bzw. Vertrag und Angebot
• Ergebnisse, ggf. detaillierter als im Angebot
• Kriterien des Auftraggebers für Qualität/Zufriedenheit
• Kriterien des Teams für Zufriedenheit
• Projektstrukturplan
Planung
• Meilensteine
• Projektplan in der Übersicht (Power-Point Folie), Referenz auf detaillierten Projektplan
Im Projekthandbuch finden sich die wichtigen Angaben zur
Projektorganisation, das Qualitätsmanagement wird referenziert.
Inhalte der Themenbereiche „Projektorganisation“ und „Qualitätsmanagement“
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 63
Projektorganisation
• Organigramm
• Eskalationswege
• Aufgabenverteilung: wer hat welchen Hut auf? AKV – Aufgaben, Kompetenzen, Verantwortlichkeiten
• Teamliste, Erreichbarkeiten (Email, Telefon, Handy)
• Email-Verteiler
• Regelmäßige Meeting-Termine
Qualitätsmanagement
• Referenz auf QM-Plan
• Referenz auf Ablage der Risikoliste
• Vorgehen zum Risikomanagement (z. B. Führen einer Risikoliste mit regelmäßiger Aktualisierung)
Im Projekthandbuch werden verschiedene Spielregeln und
weiterführende Informationen dokumentiert.
Inhalte von„Aufwandsverfolgung“, „Projektablage“ und „Handbücher“
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 64
Vorgaben zur Aufwandsverfolgung
• Überblick über Konten
• Kontierungsregeln, z. B. für Reisezeiten, Reisekosten, etc.
Struktur der Projektablage
• Gliederung, Verzeichnisse
• Namenskonventionen für Verzeichnisse und Dateien
Interne Handbücher
• Als Referenzen genannt
• Beispiele
– Nutzungskonzepte
– Coding- und Dokumentationsregeln
Das Projekthandbuch kann noch eine Vielzahl von nützlichen Tipps und
Informationen rund um das Projekt enthalten.
Sonstige Inhalte des Projekthandbuchs
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 65
Sonstige Inhalte
• Bus- und S-Bahnlinien, Abfahrpläne
• Hotellisten, Preislisten
• Laufzettel für neue Mitarbeiter
• Schlüssel
• Account
• Email-account
• Parkkarte
• …
Die Projektinitialisierung ist die letzte Chance, die Ziele zu fixieren.
Tipps zur Projektinitialisierung
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 66
Tipps
• Die Klärung der Ziele hat höchste Priorität
• Zusätzliches Know-how einholen
– Mit einem Qualitätssicherer oder erfahrenen Kollegen zusammensetzen und das Projekt durchdiskutieren.
– Weitere Meinungen einholen, prüfen, ob es irgendwo im Unternehmen Know-how gibt, das einem nützlich sein kann.
• Ein formaler Rahmen ist hilfreich!
– Projekthandbuch mit fest vorgegebenen Inhaltsverzeichnis
– Auftrag mit vorgegebener Gliederung und Unterschrift des Auftraggebers
• Es ist hilfreich, wenn die Qualitätssicherung als Hebel dienen kann, um diesen formalen Rahmen durchzusetzen.
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 67
• Einführung
• Von der Vorstudie zum Projektauftrag
• Projektinitialisierung
• Kick-Off
• Projektdurchführung
• Touch-Down
AGENDA
Das Kick-Off-Meeting schwört die Projektbeteiligten auf das gemeinsame
Ziel ein
Projektablauf in der Übersicht
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 68
Projekt- Idee und Studie
Beauftragung Projekt- initiali- sierung
Projekt- durchführung
Ab- nah- me
Aus- schrei- bung
Ange- bot
Auf- trag
Touch down
Anfor- derungs- analyse
Fachliche Konzeption
Tech. Konzeption
Reali- sierung
Test & Integr.
Ab- nah- me
Ab- nah- me
Kick- Off- Meeting
Das Kick-Off-Meeting gibt den Startschuss zum Projekt.
Motivation des Kick-Offs
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 69
Ziel des Kick-Off
• Bewussten Startpunkt für die Projektarbeit setzen: „Jetzt geht‘s los!“
• Das Team auf ein gemeinsames Ziel einschwören.
• Teambuilding: es ist wichtig, dass sich Projektmitarbeiter als Team verstehen
• Team über die wichtigsten Inhalte der Projektinitialisierung informieren, auf Stand zum Arbeiten bringen.
Die Liste der Inhalte des Kick-Off-Meetings dient zur
Vorbereitung des Termins
Inhalte des Kick-Off
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 70
Inhalte
• Projektziele, Inhalt des Projektauftrags
• Projektstruktur
• Projektvorgehen und Planung kommunizieren: Phasen, Stufen, wichtige Meilensteine
• Wichtige Standards festlegen bzw. kommunizieren
• Verantwortlichkeiten, Rollen kommunizieren, Organigramm
• Verhaltens- und Kommunikationsregeln des Teams fixieren, ggf. im Kickoff erarbeiten.
Ein Kick-Off-Meeting wird durch den Projektleiter moderiert und auch von
ihm nachbereitet.
Hinweise zur Durchführung eines Kick-Off-Meetings
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 71
Durchführung eines Kick-Off-Meetings
• Dauer des Kick-Offs: ca. ½ - 1 Tag
• Moderation durch Projektleiter
• Ein Kick-Off muss nachbereitet werden, Protokoll erstellen:
– Ein Protokoll konserviert die Ergebnisse des Kick-Offs.
– Ein Protokoll ist ein gutes Symbol: Protokolle werden auch im weiteren Projekt benötigt, also gleich mit gutem Vorbild voran gehen. Protokolle erstellt und verschickt man zeitnah.
– Mit Folien zusammen per Email an die Teilnehmer verschicken oder gleich die vorhergesehene Stelle auf der Teamablage nutzen
Neben der inhaltlichen Verständigung bietet das Kick-Off-Meeting auch
die Möglichkeit für eine besseres persönliches Verstehen.
Tipps zum Kick-Off
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 72
Tipps
• Früh genug darum kümmern, dass alle am Kick-Off teilnehmen können.
• Gut vorbereitet sein: Präsentation vorbereiten, nicht darauf verlassen, dass man die Inhalte aus der Initialisierung immer noch präsent hat.
• Bei Teams mit unterschiedlichem Erfahrungshintergrund die grundlegende Begrifflichkeiten klarstellen
– Software Engineering: FK, Pflichtenheft, etc.
– Projektmanagement: CR, QM-Plan, Projektstrukturplan, etc.
• Das Meeting mit einem informellen Teil zu verbinden, z. B.:
– anschließendes, gemeinsames Essen
– Beieinandersein an Stehtischen im Foyer
– Gelegenheit, einen persönlichen Draht zu entwickeln und Meinungen zu hören, die die Leute in größerer Runde nicht äußern wollen
• Meeting kann man auch extern durchführen, z. B. in Tagungshotel
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 73
• Einführung
• Von der Vorstudie zum Projektauftrag
• Projektinitialisierung
• Kick-Off
• Projektdurchführung
• Touch-Down
AGENDA
Die Analyse der Anforderungen bildet die Grundlage für die Erstellung der
Software
Projektablauf in der Übersicht
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 74
Projekt- Idee und Studie
Beauftragung Projekt- initiali- sierung
Projekt- durchführung
Ab- nah- me
Aus- schrei- bung
Ange- bot
Auf- trag
Kick- Off- Meeting
Touch down
Fachliche Konzeption
Tech. Konzeption
Reali- sierung
Test & Integr.
Ab- nah- me
Ab- nah- me
Anfor- derungs- analyse
Eine Anforderung ist eine Aussage über eine Eigenschaft der zu
erstellenden Lösung.
Definition Anforderung
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 75
Definition Anforderung
Eine Anforderung ist eine Aussage über
eine zu erfüllende Eigenschaft oder zu erbringende Leistung
eines Produktes, eines Prozesses oder der am Prozess beteiligten Personen.
Funktionale Anforderung
• Funktionsumfang des Systems
• Beispiel: „ Es soll die Adresse eines Kunden im System erfasst werden können“
Nicht Funktionale Anforderung
Beispiele:
• „Das System muss nach dem V-Modell erstellt werden“
• „Das System muss skalierbar sein“
Unterscheidung Funktionale und Nicht Funktionale Anforderungen
Das Volere-Schema der Atlantic Systems Guild ist ein gutes Vorbild für
die strukturierte Erfassung einer Anforderung.
Beispiel: Volere-Schema
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 76
Anforderungen sollen nicht die Fachliche Konzeption vorwegnehmen.
Hinweise zur inhaltlichen Ausgestaltung der Anforderungen
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 77
Abgrenzung zur Fachlichen Konzeption
• Nicht mit Anforderungen das Fachliche Konzept schreiben
• Zu detaillierte Anforderungen
– schränken den Gestaltungsspielraum des Projekts ein
– werden zu unübersichtlich, weil sie zu viel beschreiben
• Abgrenzung zwischen Anforderungen und Fachlichem Konzept
– Anforderung: Was muss das System können?
– Spezifikation: Wie sieht die Lösung aus?
Abnahmekriterien konkretisieren die Anforderungen und bilden die
Grundlage für die Abnahme.
Hinweise zu Abnahmekriterien
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 78
Formulierungshilfe
Einfache Anforderungen können als Kriterium haben: „… steht zur Verfügung und kann fehlerfrei durchgeführt werden“
Abnahmekriterien
• Zu jeder Anforderung gibt es mindestens ein Abnahmekriterium.
• Abnahmekriterien sind die Ausgangsbasis für die Abnahme des Systems.
• Ein Abnahmekriterium ist testbar, minimal und vollständig.
• Bei der Formulierung von Abnahmekriterien erfolgt häufig eine Verbesserung der Anforderungen (z. B. Sonderfälle)
• Abnahmekriterien können nicht nur durch lauffähige Software nachgewiesen werden, sondern auch durch Reviews von Konzepten.
Anforderungen haben typischerweise immer die gleichen
Schwachstellen, die man durch Kontrollfragen identifizieren kann.
Kontrollfragen für typische Schwachstellen in der Anforderungsanalyse
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 79
Kontrollfragen für Probleme/Schwachstellen
• Ist die Anforderung eindeutig formuliert?
– Nicht eindeutig feststellbar, ob eine Anforderung erfüllt ist
– Anforderung ist unklar formuliert
– verwendete Begrifflichkeit ist nicht eindeutig
• Gibt es „Löcher“ in den Anforderungen?
– nicht vollständige Anforderungen, unbewusste Anforderungen, "eigentlich" selbstverständliche Anforderungen
• Wurden die Anforderungen von den richtigen Leuten definiert? Sind das diejenigen, die auch das Projektergebnis abnehmen?
• Beschreiben die Anforderungen eigentlich schon die Lösung?
• Wo gibt es unaufgelöste Widersprüche in den Anforderungen?
Das Fallbeispiel zeigt, wie man sinnvoll mit „Löchern“ in den
Anforderungen umgeht.
Frage aus Fallbeispiel
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 80
Eine Anforderung ist vom Auftraggeber nicht festgelegt, z. B. die Verfügbarkeit der Anwendung (nicht funktionale Anwendung)
Soll das Projekt dieses Loch stopfen?
Frage: „Löcher“ in der Anforderungsliste
?
Ja. Probleme sollen früh verhandelt werden.
• Vermeiden geht nicht: das System wird eine Verfügbarkeit haben.
• Vorteile der frühen Klärung:
– Zugeständnisse des Auftraggebers fallen ihm einfacher
– Änderungen sind noch machbar
Antwort
!
In der Praxis kann es vorkommen, dass die Anforderungsanalyse droht,
kein Ende zu finden.
Problemstellung aus der Praxis
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 81
Der Auftraggeber bringt immer wieder neue Anforderungen in das Projekt ein. Die Anforderungsanalyse findet kein Ende.
Was tun?
Frage: Wünsch dir was!
?
Eskalieren. Es gibt Projektgrundlagen und den Projektauftrag, die wahrscheinlich im Widerspruch zu ausufernden Anforderungen stehen.
Auf gar keinen Fall ohne abgeschlossene Anforderungsanalyse weitermachen!
Antwort
!
Anforderungen sind schwierig zu managen. Sie müssen mit Blick auf die
Abnahme erstellt werden.
Tipps zum Management einer Anforderungsanalyse
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 82
Tipps
• Abnahmeverfahren für die Software frühzeitig mit Auftraggeber klären.
• CR-Verfahren etablieren (Vertiefung später in Vorlesung)
• Die Detailplanung für eine Anforderungsanalyse ist schwierig
– Ein am Produkt ausgerichteter Projektstrukturplan hilft: Top-Down Vorgehen, die vollständige Spezifikation einzelner Bereiche kann als Meilenstein gemanaged werden.
• Anforderungen kann man bei Bedarf noch vor dem fachlichen Konzept abnehmen lassen, sonst sind sie Teil des fachlichen Konzepts.
Die Konzeptionen sind schwierig zu managen.
Projektablauf in der Übersicht
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 83
Projekt- Idee und Studie
Beauftragung Projekt- initiali- sierung
Projekt- durchführung
Ab- nah- me
Aus- schrei- bung
Ange- bot
Auf- trag
Kick- Off- Meeting
Touch down
Anfor- derungs- analyse
Reali- sierung
Test & Integr.
Fachliche Konzeption
Tech. Konzeption
Ab- nah- me
Ab- nah- me
Das Management einer Konzeption ist schwierig, weil die
Vorgehensweise bei der Konzepterstellung oft nicht klar ist.
Herausforderungen beim Management einer Konzeption
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 84
Schwierigkeiten beim Management
• Vorgehen ist nicht offensichtlich oder sogar den Mitarbeitern nicht bewusst.
• Fortschritt ist schwer zu messen.
Typisches Vorgehen bei einer Konzeption
• zunächst iterativ: Annähern an Lösung mittels Workshops und Interviews
• Danach Konsolidierung der Ergebnisse, Strukturierung, Dokumentation, Erstellen des Dokuments.
• Begleitung der Abnahme
• Abnahmeerklärung durch Auftraggeber, üblich: Abnahme unter Auflagen
Planung einer Konzeption
• Als Projektleiter Struktur und Vorgehen hinterfragen und erklären lassen
• Auf Meilensteine herunter brechen
• Planung muss das Vorgehen wiederspiegeln: Kapitel des Konzepts sind nicht die Arbeitsschritte oder Planungseinheiten!
Gerade Konzepte benötigen ausreichend Zeit für die Qualitätssicherung.
Tipps zum Management eines Konzepts
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 85
Tipps
• Schriftlichkeit ist sehr wichtig: Workshop- und Meeting-Protokolle führen. Oft merkt man erst beim Aufschreiben, dass man es doch nicht verstanden hat.
• Genügend Zeit für Qualitätssicherung vorsehen:
– Einzeln erarbeitete Teilergebnisse (Kapitel, Abschnitte) müssen sich inhaltlich zu einem Ganzen zusammenfügen.
– Für konsistente Begrifflichkeit sorgen.
– Allein die einheitliche Darstellung in Word kann schon ein großer Aufwand sein.
– Für einen sauberen äußeren Eindruck sorgen: gute Inhalte leiden unter chaotischer Formatierung und Tippfehlern.
Bei der Erstellung von Konzepten ist es oft sinnvoll, die erarbeiteten
Ergebnisse früh in einem „Durchstich“ zu validieren.
Hinweise zum Durchstich
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 86
Ursprung des Durchstichs: Technik
• Technische Sicht: Schichten-Architektur
• Es wird ein kleines Stück Software realisiert, das alle Schichten „durchsticht“ und das die Software-Architektur validiert.
Übertragung auf andere Bereiche
• „Durchstich“ wird oft als Synonym für die beispielhafte Erprobung eines Konzepts genutzt.
Beispiele für fachliche Durchstiche
• Es wird eine Methodik zur Dokumentation entwickelt. Diese wird an einem kleinen Beispiel verprobt.
• GUI-Walkthrough: Die Masken sind nur als Grafiken vorhanden. Mit dem Anwender werden diese Masken auf dem Papier ausgefüllt und das Verhalten der Masken durchgesprochen („Papier-Prototyp“)
Das Fachliche Konzept beschreibt, wie die fachliche Lösung der
Anforderungen aussieht.
Typische Inhalte eines Fachlichen Konzepts
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 87
Inhalte
• Anforderungen, falls nicht separat dokumentiert.
• Geschäftsprozesse
• Anwendungsfälle (Use Cases): Die Teile eines Geschäftsprozesses, die durch Software unterstützt werden.
• Fachliches Datenmodell
• Nutzung des Systems: GUI, Batches, Druckausgaben
• Schnittstellen zu Nachbarsystemen
• Einführung, Datenmigration aus Altsystemen
• Fachlicher Systemüberblick, Fachliche Architektur
Eine angemessene fachliche Lösung ist der wesentliche Grundstein für
die spätere wirtschaftliche Umsetzbarkeit.
Tipps für die Erstellung einer Fachlichen Konzeption
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 88
Tipps
• Die Fachliche Konzeption bietet die wesentlichen Stellschrauben für die späteren Aufwände in der Realisierung. Beispiel: Datenpflege:
– Tabellarische Pflege der Daten, Nutzer kann frei navigieren oder
– „Wizard“-Ansatz: Nutzer wird durch den Erfassungsprozess geleitet.
Kritisch hinterfragen, ob die fachliche Lösung nicht „zu schön“ ist.
• Die fachliche Konzeption muss in Hinblick auf die Umsetzbarkeit erfolgen. Beispiel HTML-GUI: Eine hoch interaktive GUI mit schnellen Reaktionszeiten, so wie sie z. B. für ein Beratungsgespräch nötig ist, ist mit HTML kaum umzusetzen.
Frühzeitig das Know-how zur Realisierung mit einbinden.
Die Technische Konzeption beschreibt, wie die Lösung technisch
umgesetzt wird und enthält konkrete Anleitungen für die Entwickler.
Typische Inhalte einer Technischen Konzeption
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 89
Inhalte
• Architektur der technischen Infrastruktur: Hardware, Netze, Systemsoftware, Middleware
• Architektur der Software, Top-Down beschrieben
– Außensicht: Schnittstellen nach außen, Beziehungen zu benachbarten Systemen/Modulen
– Innensicht
• Konkretes SW-Design, Modulstruktur, Namen (z. B.: in Java: Packages), Vorgaben für die Implementierung
• Querschnittliche Funktionen, z. B.: Error Handling, Logging, Nutzerberechtigung, System-Management, Konfiguration
• Entwicklungsumgebung, Nutzungskonzepte, Namenskonventionen
• Installation der Software, Betrieb der Software, Migration von Alt-Datenbeständen
Bei der Erstellung einer Technischen Konzeption ist es wichtig, auf die
Angemessenheit für die Problemstellung zu achten.
Tipps zum Management einer Technischen Konzeption
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 90
Tipps
• Die Detailtiefe muss angemessen sein. Ein Entwickler als Leser hat unterschiedlichen Informationsbedarf:
– Entwicklung vor Ort beim Auftraggeber
– Entwicklung im Büro „daheim“
– Entwicklung Offshore, z. B. in Indien
• Beim Thema bleiben. Insbesondere Großprojekte sind Brutstätten für eigentlich überflüssige Systemkomponenten, die jeder schon mal gerne implementieren wollte:
– GUI-Editoren
– Workflow-Engines
– überdimensionierte Lösungen im Allgemeinen
Nach der Realsierung werden die einzelnen Codemodule miteinander
integriert und als Ganzes getestet.
Projektablauf in der Übersicht
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 91
Projekt- Idee und Studie
Beauftragung Projekt- initiali- sierung
Projekt- durchführung
Ab- nah- me
Aus- schrei- bung
Ange- bot
Auf- trag
Kick- Off- Meeting
Touch down
Anfor- derungs- analyse
Fachliche Konzeption
Tech. Konzeption
Ab- nah- me
Ab- nah- me
Reali- sierung
Test & Integr.
Während der Realisierung entsteht mehr als nur der pure Code.
Inhalte der Realisierung
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 92
Realisierung umfasst
• Erstellen des Codes.
• Dokumentieren des Codes, in der Regel durch Entwicklerkommentare.
• Testen des Codes im Rahmen von Entwicklertests.
Coding und Dokumentation nicht Gegenstand der Vorlesung, werden nicht vertieft.
Testverfahren können unterschieden werden nach dynamischen und
statischen Verfahren und der Kenntnis des inneren Aufbaus der Software.
Klassifizierung von Testverfahren
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 93
Statisch
Dynamisch
Black Box
White Box
Test Testverfahren
• Statische Tests erfolgen, ohne den Code auszuführen. Beispiele: Reviews, Walkthroughs, Code-Analyzer wie findbugs, copy-paste-detector, checkstyle.
• Black-Box-Tests testen die Software „von außen“ ohne Kenntnisse ihres inneren Aufbaus („Black Box“)
• White-Box-Tests nutzen Wissen über den Aufbau der Software, um die Tests zu konzipieren. Beispiel Codeabdeckung: Fragestellung: Wurden alle Statements ausgeführt, sind alle Kontrollflüsse/Sprünge durchlaufen?
Module werden einzeln durch die Entwickler getestet, bevor sie integriert
und in der Gesamtheit getestet werden.
Typische Testformen im Projektverlauf
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 94
Vom Entwickler durchgeführte Tests
• Modultest (auch Entwicklertest, Unit-Test): Ein White-Box-Test, in dem ein einzelnes Softwaremodul aufgerufen und die Ergebnisse geprüft werden.
• Statische Code-Analyse, i. d. R. durch Tools
Während der Systemintegration durchgeführte Tests
• Integrationstest: Ein Black-Box-Test, in dem das Verhalten des Gesamtsystem getestet wird (gemäß fachlicher Konzeption). I. d. R.: automatisierte Tests, die durch Freihandtests ergänzt werden.
Begleitend
• Begleitend und im Rahmen eines Durchstichs: Lasttests, um die Dimensionierung des Systems und die Performance zu bestimmen.
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 95
Entwicklung und Tests werden auf verschiedenen Umgebungen
durchgeführt.
Die Umgebungen sind je nach Projekt und Kunde unterschiedlich
• Für die Tätigkeiten werden unterschiedliche Umgebungen bereit gestellt.
• Entwicklungsumgebung, z. B.:
– Entwickler-Laptop
– Spezieller Bereich im Großrechner
• Testumgebung
• Schulungsumgebung
• Lasttestumgebung
• Produktionsumgebung
(Hinweis: Namensgebung ist nicht standardisiert)
Mögliche Umgebungen Parallele Tätigkeiten
• Tätigkeiten bei der Software-Entwicklung sind parallelisiert
• Beispiele:
– Software-Entwicklung einzelner Module
– Fachliche Tests durch Kunden
– Lasttests
– Schulungen der späteren Nutzer
– Integrationstests
Beispielhafte Umgebungen in einem Software-Projekt.
Die Umgebungen werden zunehmend ähnlicher zur Produktionsumgebung.
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 96
Entwicklungsumgebung
• Software-Entwicklung auf Laptops der einzelnen Entwickler
• Lokale Datenbanken, Stubs für Nachbarsysteme
Vorintegrationsumgebung
• Integration der einzelnen Module unterschiedlicher Entwickler
• Eine zentrale Datenbank, Nachbarsysteme sind in Testversionen vorhanden.
Systemtestumgebung
• Fachliche Abnahmetests durch Kunden, Lasttests
• Produktionsähnliche Umgebung: Cluster für Anwendungsserver, Datenbanken. Dimensionierung z. B. halb so groß wie Produktionsumgebung
Produktionsumgebung
• Software im produktiven Einsatz durch den Kunden
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 97
• Einführung
• Von der Vorstudie zum Projektauftrag
• Projektinitialisierung
• Kick-Off
• Projektdurchführung
• Touch-Down
AGENDA
Der Touch-Down bietet die Möglichkeit, aus den Projekterfahrungen zu
lernen.
Projektablauf in der Übersicht
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 98
Projekt- Idee und Studie
Beauftragung Projekt- initiali- sierung
Projekt- durchführung
Ab- nah- me
Aus- schrei- bung
Ange- bot
Auf- trag
Kick- Off- Meeting
Anfor- derungs- analyse
Fachliche Konzeption
Tech. Konzeption
Reali- sierung
Test & Integr.
Ab- nah- me
Ab- nah- me
Touch down
Der Touch-Down dient dazu, aus den Erfahrungen des Projekts zu lernen.
Motivation und Tätigkeiten des Touch-Down
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 99
Ziel des Touch-Down
Nach abgeschlossenem Projekt ein Resümee ziehen und für das nächste Mal lernen.
Tätigkeiten
• Durchführen eines Touch-Down-Meetings: Besondere Erfahrungen des Projektteams werden konsolidiert und festgehalten.
• Nachkalkulation: Die tatsächlichen Aufwände mit den geschätzten Aufwänden aus der Angebotsphase verglichen.
• Archivierung der Projektergebnisse: nicht einfach auf einem Laufwerk liegen lassen, sonst sind sie irgendwann weg.
Das Touch-Down-Meeting mag manchmal unangenehm sein, stiftet aber
einen hohen Nutzen, weil man für zukünftige Projekte lernt.
Hinweise zum Touch-Down-Meeting
© 2010 Capgemini – All rights reserved
03-PROJEKTVERLAUF.PPTX 100
Touch-Down-Meeting
• Gegenstück zum Kick-Off: Das offizielle Ende der Projektdurchführung
• Teilnehmer des Meetings
– alle Projektbeteiligten
– Bei Auftraggeber/Auftragnehmer-Situation: gern auch beteiligte Mitarbeiter des Auftraggebers, dann aber noch einen Auftragnehmer-internes Meeting machen.
• Rückblick und Diskussion
– Stärken und Schwächen des Projekts
– Probleme einzelner Mitarbeiter
– Leistungen in der Projektdurchführung
Unangenehm? Trotzdem machen!
Vielen Dank für Ihre Aufmerksamkeit!
www.capgemini.com