IT-Projektmanagement - Projektverlauf · Dieser Vorlesungsteil vertieft die Projektvorbereitung und...

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



• Einführung

• Von der Vorstudie zum Projektauftrag

• Projektinitialisierung

• Kick-Off

• Projektdurchführung

• Touch-Down

AGENDA



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



Projekt- Idee und Studie

Beauftragung Projekt- initialisierung

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



• Einführung



• Kick-Off


• Touch-Down

AGENDA

Dem Projekt vorgelagert ist die Entwicklung einer Projektidee und ggf.

eine Vorstudie.






Ab- nah- me

Aus- schrei- bung

Ange- bot

Auf- trag

Kick- Off- Meeting

Touch down



Tech. Konzeption

Reali- sierung

Test & Integr.

Ab- nah- me

Ab- nah- me


IT-Projekte können unterschiedliche Auslöser haben.

Entstehung von IT-Projekten: Auslöser von IT-Projekten



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



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)


Handlungs-bedarf IT

IT-Projekt

(Auftrag)

In der IT entsteht der Handlungsbedarf, ein Projekt durchzuführen.

Entstehung von IT-Projekten: Handlungsbedarf in der IT



In der IT entsteht Handlungsbedarf, z. B.

– neue Software

– umfangreiche Umstellung bestehender Software

ein Projekt

Handlungsbedarf IT


Handlungs-bedarf IT

IT-Projekt

(Auftrag)

Oft ist es sinnvoll, eine Vorstudie dem Projekt voranzustellen.

Einordnung einer Vorstudie



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.





Projekt- initialisierung


Ab- nah- me

Aus- schrei- bung

Ange- bot

Auf- trag

Kick- Off- Meeting

Touch down



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



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




Auftraggeber Auftragnehmer

Auftrag


• 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



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



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



• 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



• 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!



• Einführung



• Kick-Off


• Touch-Down

AGENDA

Die Projektinitialisierung ist die wichtigste und kritischste Phase im

Projekt.





Beauftragung Projekt- durchführung

Ab- nah- me

Aus- schrei- bung

Ange- bot

Auf- trag

Kick- Off- Meeting

Touch down



Tech. Konzeption

Reali- sierung

Test & Integr.

Ab- nah- me

Ab- nah- me

Projekt- initialisierung

Die Projektinitialisierung ist die wichtigste Phase eines Projekts.

Einordnung der Projektinitialisierung



• 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



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



• 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



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



AGENDA

• Einführung



• Kick-Off


• Touch-Down



AGENDA

• Einführung



• Kick-Off


• 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



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



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



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



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)



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



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



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.



AGENDA

• Einführung



• Kick-Off


• Touch-Down

–Ziele


–Projektstruktur


–Infrastruktur


–Projekthandbuch

Neben den Projektzielen gibt es für den Auftraggeber noch

Qualitätskriterien, an denen er den Projekterfolg misst.

Beschreibung von Qualitätskriterien



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



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



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



AGENDA

• Einführung



• Kick-Off


• Touch-Down

–Ziele


–Projektstruktur


–Infrastruktur


–Projekthandbuch

Große Projekte werden erst dann beherrschbar, wenn man eine sinnvolle

Aufteilung in Teilthemen findet

Reduktion der Komplexität durch Teilthemen



Wichtig: die Teilthemen sollten möglichst unabhängig voneinander sein

Der Projektstrukturplan (PSP) zerlegt das Projekt in handhabbare Teile.

Motivation eines Projektstrukturplans



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



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



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



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



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



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.



AGENDA

• Einführung



• Kick-Off


• Touch-Down

–Ziele


–Projektstruktur


–Infrastruktur


–Projekthandbuch

In der Projektinitialisierung sollte auch das Qualitätsmanagement

aufgesetzt werden

Hinweise zum Aufsetzen des Qualitätsmanagements



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)



AGENDA

• Einführung



• Kick-Off


• Touch-Down

–Ziele


–Projektstruktur


–Infrastruktur


–Projekthandbuch

Die Etablierung der Projektinfrastruktur ist aufwändig und sollte früh

angegangen werden.

Hinweise zum Aufbau der Infrastruktur



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



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



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



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



AGENDA

• Einführung



• Kick-Off


• Touch-Down

–Ziele


–Projektstruktur


–Infrastruktur


–Projekthandbuch

Die Erfassung der Arbeitszeiten in einem Projekt erfolgt in der Regel über

Werkzeuge, in denen Kontierungen erfasst werden.

Schema für Arbeitszeiterfassung



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



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



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.



AGENDA

• Einführung



• Kick-Off


• Touch-Down

–Ziele


–Projektstruktur


–Infrastruktur


–Projekthandbuch



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



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



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



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“



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“



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“



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



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



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.



• Einführung



• Kick-Off


• Touch-Down

AGENDA

Das Kick-Off-Meeting schwört die Projektbeteiligten auf das gemeinsame

Ziel ein







Ab- nah- me

Aus- schrei- bung

Ange- bot

Auf- trag

Touch down



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



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



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



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



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



• Einführung



• Kick-Off


• Touch-Down

AGENDA

Die Analyse der Anforderungen bildet die Grundlage für die Erstellung der

Software







Ab- nah- me

Aus- schrei- bung

Ange- bot

Auf- trag

Kick- Off- Meeting

Touch down


Tech. Konzeption

Reali- sierung

Test & Integr.

Ab- nah- me

Ab- nah- me


Eine Anforderung ist eine Aussage über eine Eigenschaft der zu

erstellenden Lösung.

Definition Anforderung



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



Anforderungen sollen nicht die Fachliche Konzeption vorwegnehmen.

Hinweise zur inhaltlichen Ausgestaltung der Anforderungen



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



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



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



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



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



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.







Ab- nah- me

Aus- schrei- bung

Ange- bot

Auf- trag

Kick- Off- Meeting

Touch down


Reali- sierung

Test & Integr.


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



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



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



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



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



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



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



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.







Ab- nah- me

Aus- schrei- bung

Ange- bot

Auf- trag

Kick- Off- Meeting

Touch down



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



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



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



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.



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.



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



• Einführung



• Kick-Off


• Touch-Down

AGENDA

Der Touch-Down bietet die Möglichkeit, aus den Projekterfahrungen zu

lernen.







Ab- nah- me

Aus- schrei- bung

Ange- bot

Auf- trag

Kick- Off- Meeting



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



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



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

IT-Projektmanagement - Projektverlauf · Dieser Vorlesungsteil vertieft die Projektvorbereitung und...

Documents

Transcript of IT-Projektmanagement - Projektverlauf · Dieser Vorlesungsteil vertieft die Projektvorbereitung und...