IT-Projektmanagement Teil 3: Projektverlauf. Wintersemester 2012/2013 Dr. Gerhard Pews

Transkript

1 IT-Projektmanagement Teil 3: Projektverlauf Wintersemester 2012/2013 Dr. Gerhard Pews

2 Dieser Vorlesungsteil vertieft die Projektvorbereitung und die Tätigkeiten innerhalb eines Projekts. Einordnung in den Fahrplan der Vorlesung 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 2

3 AGENDA Einführung Von der Vorstudie zum Projektauftrag Projektinitialisierung Kick-Off Projektdurchführung Touch-Down 3

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. 4

5 Der Projektablauf teilt sich in die eigentliche Projektdurchführung sowie vor- und nachbereitende Phasen Projektablauf in der Übersicht Projekt- Idee und Studie Beauftragung Projektinitialisierung Kick- Off- Meeting Projektdurchführung Touch down Ausschreibung Angebot Auftrag Anforderungsanalyse Fachliche Konzeption Abnahme Tech. Konzeption Abnahme Realisierung Test & Integr. Abnahme 5

6 AGENDA Einführung Von der Vorstudie zum Projektauftrag Projektinitialisierung Kick-Off Projektdurchführung Touch-Down 6

7 Dem Projekt vorgelagert ist die Entwicklung einer Projektidee und ggf. eine Vorstudie. Projektablauf in der Übersicht Projekt- Idee und Studie Beauftragung Projektinitialisierung Kick- Off- Meeting Projektdurchführung Touch down Ausschreibung Angebot Auftrag Anforderungsanalyse Fachliche Konzeption Abnahme Tech. Konzeption Abnahme Realisierung Test & Integr. Abnahme 7

8 IT-Projekte können unterschiedliche Auslöser haben. Entstehung von IT-Projekten: Auslöser von IT-Projekten Auslöser Business Case Handlungsbedarf 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. 8

9 Im Business Case wird der Grundgedanke des Projekts konkretisiert. Entstehung von IT-Projekten: Business Case Auslöser Business Case Handlungsbedarf IT IT-Projekt (Auftrag) 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) 9

10 In der IT entsteht der Handlungsbedarf, ein Projekt durchzuführen. Entstehung von IT-Projekten: Handlungsbedarf in der IT Auslöser Business Case Handlungsbedarf IT IT-Projekt (Auftrag) Handlungsbedarf IT In der IT entsteht Handlungsbedarf, z. B. neue Software umfangreiche Umstellung bestehender Software ein Projekt 10

11 Oft ist es sinnvoll, eine Vorstudie dem Projekt voranzustellen. Einordnung einer Vorstudie Business Case Legt wesentliche Punkte eines Projekts grob fest: Kosten Ziel (Leistungsumfang) Zeitrahmen (ROI) Vorstudie 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 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. 11

12 Im Projektauftrag konkretisiert sich das Projekt. Projektablauf in der Übersicht Projekt- Idee und Studie Beauftragung Projektinitialisierung Kick- Off- Meeting Projektdurchführung Touch down Ausschreibung Angebot Auftrag Anforderungsanalyse Fachliche Konzeption Abnahme Tech. Konzeption Abnahme Realisierung Test & Integr. Abnahme 12

13 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) Ziel, Weg, Randbedingungen Konfliktpotential Auftraggeber Auftrag Auftragnehmer Projektergebnis (scharf) Lieferung 13

14 Nicht vorhandene oder unzureichend fixierte Aufträge sind ein großes Problem im Projektmanagement. Probleme bei der Erteilung eines Auftrags Ziel, Weg, Randbedingungen Ziel, Weg, Randbedingungen Auftrag Auftraggeber Auftragnehmer Probleme nur mündlich, nicht dauerhaft fixiert unklar, zusätzliche Nebenabsprachen Inkonsistent, unvollständig 14

15 Die erste und wichtigste Aufgabe im Projekt ist es, für einen klaren Projektauftrag zu sorgen. Fixieren des Projektauftrags Auftrag Fixieren des Auftrags 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. 15

16 Der Projektauftrag fixiert die wesentlichen Punkte zu einem Projekt. Inhalte eines Projektauftrags Checklisten- Folie Projektauftrag 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 16

17 Wenn der Projektauftrag nicht unterschrieben wird, ist das ein sehr ernstes Warnzeichen. Gründe für einen Start ohne unterschriebenen Auftrag Die Versuchung, einfach loszulegen, ist groß 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. Tiefere Ursachen 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? 17

18 Wird ein Projektauftrag nicht unterschrieben, muss das Projekt reagieren. Reaktionsmöglichkeiten bei fehlender Beauftragung Auf gar keinen Fall einfach so loslegen! Optionen 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. 18

19 AGENDA Einführung Von der Vorstudie zum Projektauftrag Projektinitialisierung Kick-Off Projektdurchführung Touch-Down 19

20 Die Projektinitialisierung ist die wichtigste und kritischste Phase im Projekt. Projektablauf in der Übersicht Projekt- Idee und Studie Beauftragung Projektinitialisierung Kick- Off- Meeting Projektdurchführung Touch down Ausschreibung Angebot Auftrag Anforderungsanalyse Fachliche Konzeption Abnahme Tech. Konzeption Abnahme Realisierung Test & Integr. Abnahme 20

21 Die Projektinitialisierung ist die wichtigste Phase eines Projekts. Einordnung der Projektinitialisierung Bedeutung der Initialisierung 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. Ziel der Projektinitialisierung Alle Rahmenbedingungen für das Team sind geschaffen Die Arbeit kann beginnen, das Team kann loslegen. 21

22 Die Projektinitialisierung muss von den Keyplayern des späteren Projekts durchgeführt werden. Mitwirkende bei der Projektinitialisierung Auftragnehmer Auftraggeber Projektleiter Qualitätssicherer Subject Matter Expert (SME), Architekt, sorgt für inhaltliche Kontinuität aus dem Angebot Ansprechpartner für Fragen als Gegenstück zum Projektteam 22

23 Eine Initialisierung des Projekts ohne den Projektleiter und sein späteres Team verliert deutlich an Wert. Konsequenzen mangelnder Initialisierung Mögliche Konsequenzen, wenn der PL zu spät in das Projekt kommt 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. Projektleiter sind rar, deshalb nicht beliebig verfügbar Als designierter Projektleiter kann man darauf hinwirken, nicht zu spät ins Projekt zu kommen 23

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 24

25 AGENDA Einführung Von der Vorstudie zum Projektauftrag Projektinitialisierung Kick-Off Projektdurchführung Touch-Down 25

26 AGENDA Ziele Einführung Von der Vorstudie zum Projektauftrag Projektinitialisierung Kick-Off Projektdurchführung Touch-Down Qualitätskriterien Projektstruktur Qualitätsmanagement Infrastruktur Controlling-Strukturen Projekthandbuch 26

27 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. 27

28 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? 28

29 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 29

30 Die Inhalte der Ziele sollten Vorgaben folgen, die unter dem Akronym SMART zusammengefasst werden. Regeln für SMARTe Ziele S pezifisch M easurable A chievable R elevant T ime-based Knackig, verständlich, eindeutig, stimmig mit anderen Zielen. Messbar. Es muss klar sein, wann das Ziel erreicht ist. Erreichbar. Unerreichbare Ziele führen zu Demotivation. Die wichtigen Dinge als Ziel formulieren, nicht jeden Kleinkram. 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) 30

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. 31

32 Eine attraktive Zielformulierung ist aktiv, im Präsens und positiv formuliert. Hinweise zur attraktiven Zielformulierung Regel Aktiv formulieren Als erreicht formulieren Positiv formulieren Hinweise und Beispiele 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 Sinn: den Zielzustand heute schon im Kopf erleben, damit man diesen Zustand anstrebt. 32

33 Es ist nicht hilfreich, bei fehlenden Aussagen zu den Zielen einfach loszulegen. Vorgehen bei fehlenden Aussagen zu Zielen Problem Nicht hilfreich Nicht einfach loslegen und die Versäumnisse anderer kompensieren wollen. Aber: blockieren ist nicht hilfreich. Was tun, wenn es keine klare Aussage zu den Zielen vom Auftraggeber gibt? 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. 33

34 AGENDA Ziele Einführung Von der Vorstudie zum Projektauftrag Projektinitialisierung Kick-Off Projektdurchführung Touch-Down Qualitätskriterien Projektstruktur Qualitätsmanagement Infrastruktur Controlling-Strukturen Projekthandbuch 34

35 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 35

36 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. 36

37 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 37

38 AGENDA Ziele Einführung Von der Vorstudie zum Projektauftrag Projektinitialisierung Kick-Off Projektdurchführung Touch-Down Qualitätskriterien Projektstruktur Qualitätsmanagement Infrastruktur Controlling-Strukturen Projekthandbuch 38

39 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 39

40 Der Projektstrukturplan (PSP) zerlegt das Projekt in handhabbare Teile. Motivation eines Projektstrukturplans Ziel Handhabbare Teile Orientierung Hinweise 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 40

41 Ein Projektstrukturplan lässt sich anhand verschiedener Strukturierungsmerkmale bilden. Strukturierungsmerkmale für einen PSP 1. Produktstruktur Orientierung an den Teilen des zu erstellenden Produkts, z. B. einer zu erstellende Software. Orientierung an den Liefergegenständen. Funktionen/ Rollen 2 1 Produktstruktur PSP Projektablauf 3 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. 41

42 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 42

43 Das gleiche Projekt ließe sich auch nach anderen Kriterien strukturieren. PSP nach Funktionen/Rollen und nach Projektablauf 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 PSP 3: Strukturierung nach Projektablauf Fachkonzeption Technische Konzeption Realisierung Test/Integration 43

44 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 44

45 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. 45

46 AGENDA Ziele Einführung Von der Vorstudie zum Projektauftrag Projektinitialisierung Kick-Off Projektdurchführung Touch-Down Qualitätskriterien Projektstruktur Qualitätsmanagement Infrastruktur Controlling-Strukturen Projekthandbuch 46

47 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) 47

48 AGENDA Ziele Einführung Von der Vorstudie zum Projektauftrag Projektinitialisierung Kick-Off Projektdurchführung Touch-Down Qualitätskriterien Projektstruktur Qualitätsmanagement Infrastruktur Controlling-Strukturen Projekthandbuch 48

49 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. 49

50 Zur Projektinfrastruktur gehören Arbeitsmittel und eine Projektablage. Beispiele und Hinweise zu Arbeitsmitteln und Projektablage Arbeitsmittel Räume Rechner, Drucker, Telefone, Videokonferenz -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. 50

51 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. 51

52 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 52

53 AGENDA Ziele Einführung Von der Vorstudie zum Projektauftrag Projektinitialisierung Kick-Off Projektdurchführung Touch-Down Qualitätskriterien Projektstruktur Qualitätsmanagement Infrastruktur Controlling-Strukturen Projekthandbuch 53

54 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. 54

55 Typischerweise hat man intern und extern unterschiedliche Sichten auf ein Projekt Innen- und Außensicht auf Projektaufwände Innensicht Detaillierte Beschreibung, wer wann an welcher Aufgabe gearbeitet hat Außensicht Dient als Abrechnungsgrundlage in Richtung Auftraggeber Unterschiede zwischen den Sichten Konten & Aufwände 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. 55

56 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. 56

57 AGENDA Ziele Einführung Von der Vorstudie zum Projektauftrag Projektinitialisierung Kick-Off Projektdurchführung Touch-Down Qualitätskriterien Projektstruktur Qualitätsmanagement Infrastruktur Controlling-Strukturen Projekthandbuch 57

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. 58

59 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. 59

60 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) 60

61 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 61

62 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 62

63 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 ( , Telefon, Handy) -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) 63

64 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 64

65 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 -account Parkkarte 65

66 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. 66

67 AGENDA Einführung Von der Vorstudie zum Projektauftrag Projektinitialisierung Kick-Off Projektdurchführung Touch-Down 67

68 Das Kick-Off-Meeting schwört die Projektbeteiligten auf das gemeinsame Ziel ein Projektablauf in der Übersicht Projekt- Idee und Studie Beauftragung Projektinitialisierung Kick- Off- Meeting Projektdurchführung Touch down Ausschreibung Angebot Auftrag Anforderungsanalyse Fachliche Konzeption Abnahme Tech. Konzeption Abnahme Realisierung Test & Integr. Abnahme 68

69 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. 69

70 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. 70

71 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 an die Teilnehmer verschicken oder gleich die vorhergesehene Stelle auf der Teamablage nutzen 71

72 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 72

73 AGENDA Einführung Von der Vorstudie zum Projektauftrag Projektinitialisierung Kick-Off Projektdurchführung Touch-Down 73

74 Die Analyse der Anforderungen bildet die Grundlage für die Erstellung der Software Projektablauf in der Übersicht Projekt- Idee und Studie Beauftragung Projektinitialisierung Kick- Off- Meeting Projektdurchführung Touch down Ausschreibung Angebot Auftrag Anforderungsanalyse Fachliche Konzeption Abnahme Tech. Konzeption Abnahme Realisierung Test & Integr. Abnahme 74

75 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. Unterscheidung Funktionale und Nicht Funktionale Anforderungen 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 75

76 Das Volere-Schema der Atlantic Systems Guild ist ein gutes Vorbild für die strukturierte Erfassung einer Anforderung. Beispiel: Volere-Schema 76

77 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? 77

78 Abnahmekriterien konkretisieren die Anforderungen und bilden die Grundlage für die Abnahme. Hinweise zu Abnahmekriterien 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. Formulierungshilfe Einfache Anforderungen können als Kriterium haben: steht zur Verfügung und kann fehlerfrei durchgeführt werden 78

79 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? 79

80 Das Fallbeispiel zeigt, wie man sinnvoll mit Löchern in den Anforderungen umgeht. Frage aus Fallbeispiel Frage: Löcher in der Anforderungsliste? Eine Anforderung ist vom Auftraggeber nicht festgelegt, z. B. die Verfügbarkeit der Anwendung (nicht funktionale Anwendung) Soll das Projekt dieses Loch stopfen? Antwort 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! 80

81 In der Praxis kann es vorkommen, dass die Anforderungsanalyse droht, kein Ende zu finden. Problemstellung aus der Praxis Frage: Wünsch dir was!? Der Auftraggeber bringt immer wieder neue Anforderungen in das Projekt ein. Die Anforderungsanalyse findet kein Ende. Was tun? Antwort Eskalieren. Es gibt Projektgrundlagen und den Projektauftrag, die wahrscheinlich im Widerspruch zu ausufernden Anforderungen stehen. Auf gar keinen Fall ohne abgeschlossene Anforderungsanalyse weitermachen!! 81

82 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. 82

83 Die Konzeptionen sind schwierig zu managen. Projektablauf in der Übersicht Projekt- Idee und Studie Beauftragung Projektinitialisierung Kick- Off- Meeting Projektdurchführung Touch down Ausschreibung Angebot Auftrag Fachliche Konzeption Anforderungsanalyse Abnahme Tech. Konzeption Abnahme Realisierung Test & Integr. Abnahme 83

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

85 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. 85

86 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 ) 86

87 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 87

88 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. 88

89 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 89

90 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 90

91 Nach der Realsierung werden die einzelnen Codemodule miteinander integriert und als Ganzes getestet. Projektablauf in der Übersicht Projekt- Idee und Studie Beauftragung Projektinitialisierung Kick- Off- Meeting Projektdurchführung Touch down Ausschreibung Angebot Auftrag Anforderungsanalyse Fachliche Konzeption Abnahme Tech. Konzeption Abnahme Realisierung Test & Integr. Abnahme 91

92 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. 92

93 Testverfahren können unterschieden werden nach dynamischen und statischen Verfahren und der Kenntnis des inneren Aufbaus der Software. Klassifizierung von Testverfahren 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? Statisch Black Box Test Dynamisch White Box 93

94 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. 94

95 Entwicklung und Tests werden auf verschiedenen Umgebungen durchgeführt. Die Umgebungen sind je nach Projekt und Kunde unterschiedlich 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 Mögliche Umgebungen 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) 95

96 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 96

97 AGENDA Einführung Von der Vorstudie zum Projektauftrag Projektinitialisierung Kick-Off Projektdurchführung Touch-Down 97

98 Der Touch-Down bietet die Möglichkeit, aus den Projekterfahrungen zu lernen. Projektablauf in der Übersicht Projekt- Idee und Studie Beauftragung Projektinitialisierung Kick- Off- Meeting Projektdurchführung Touch down Ausschreibung Angebot Auftrag Anforderungsanalyse Fachliche Konzeption Abnahme Tech. Konzeption Abnahme Realisierung Test & Integr. Abnahme 98

99 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. 99

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

101 Vielen Dank für Ihre Aufmerksamkeit!