Fakultät Technik und Informatik Faculty of Engineering and Computer ScienceStudiendepartment Informatik Department of Computer Science

Steffan Schiewe

Ein System zur Unterstützung der Zeitplanung füragile Projektabläufe

Bachelorarbeit

Bachelorarbeit eingereicht im Rahmen der Bachelorprüfungim Studiengang Technische Informatikam Studiendepartment Informatikder Fakultät Technik und Informatikder Hochschule für Angewandte Wissenschaften Hamburg

Betreuender Prüfer : Prof. Dr. Kai von LuckZweitgutachter : Prof. Dr. Jörg Raasch

Abgegeben am 12. Mai 2006

Steffan Schiewe

Ein System zur Unterstützung der Zeitplanung füragile Projektabläufe

Steffan Schiewe

Thema der BachelorarbeitEin System zur Unterstützung der Zeitplanung für agile Projektabläufe

StichworteZeitplanung, Zeiterfassung, Projektmanagement, agile Entwicklung, Workload-Management

KurzzusammenfassungEs hat sich in der Praxis bewährt hochdynamische und innovative Projekte durch agi-le Managementmethoden zu organisieren. Diese Projekte sind von kontinuierlicherVeränderung geprägt. Durch ein iteratives Vorgehen wird ein hohes Maß an Anpas-sungsfähigkeit gewährleistet. Der Projektmitarbeiter ist selbst verantwortlich für dieAblaufplanung und Koordination von einzelnen Projektaufgaben. In dieser Bachelor-arbeit wurde ein System entwickelt, das die Projektmitarbeiter bei ihrer individuellenZeitplanung unterstützt.

Steffan Schiewe

Title of the paperA software to support time planning in agile projects

Keywordstime planning, time registration, project management, agile development, workloadmanagement

AbstractIt is nowadays common practice to use agile management methods in highly dynamicand innovative projects. These kind of projects struggle with continuous change.The use of an iterative process provides a high standard of adaptibility. The projectmembers are responsible for planning and coordination of their own project tasks.This bachelor thesis develops a system to support the project members time planningactivities.

Inhaltsverzeichnis

Abbildungsverzeichnis 7

1. Einleitung 91.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.2. Ziele der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2. Grundlagen 152.1. Fallstudie GAIA AG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.1.1. Autoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.1.2. Informatiker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.1.3. Berater . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.1.4. Projektkoordination in der GAIA AG . . . . . . . . . . . . . . . . . . 192.1.5. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.2. Organisation und Planung von Projekten . . . . . . . . . . . . . . . . . . . 212.2.1. Das Projekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.2.2. Projektmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . 222.2.3. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.3. Zeitplanung der Mitarbeiter . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.3.1. Terminkalender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.3.2. Aufgabenlisten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.3.3. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.4. Überblick der Technologien . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.4.1. Terminkalender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.4.2. Projektmanagement Software . . . . . . . . . . . . . . . . . . . . . 362.4.3. Zeiterfassungssysteme . . . . . . . . . . . . . . . . . . . . . . . . . 382.4.4. Ticketing Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.4.5. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.5. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Inhaltsverzeichnis 5

3. Anforderungsanalyse 443.1. Anwenderziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.2. Einordnung des Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.3. Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.3.1. Individuelle Zeitplanung . . . . . . . . . . . . . . . . . . . . . . . . . 463.3.2. Zeiterfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.3.3. Zugriff und Einsatzgebiet . . . . . . . . . . . . . . . . . . . . . . . . 48

3.4. Eingrenzung Zeitplanungsproblem . . . . . . . . . . . . . . . . . . . . . . . 483.5. Definition „Ereignis“ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.5.1. Ereignis Termin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503.5.2. Ereignis Projektaufgabe . . . . . . . . . . . . . . . . . . . . . . . . 513.5.3. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

3.6. Anwendungsfälle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.6.1. Systemumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.6.2. Systemauthentifikation . . . . . . . . . . . . . . . . . . . . . . . . . 563.6.3. Verwaltung von Ereignissen . . . . . . . . . . . . . . . . . . . . . . 573.6.4. Zeitplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583.6.5. Zeiterfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.6.6. Verwaltung von Benutzern . . . . . . . . . . . . . . . . . . . . . . . 60

4. Design und Modellierung 624.1. Systementwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.1.1. Konzeptionelle Fachklassen . . . . . . . . . . . . . . . . . . . . . . 624.1.2. Klassendiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634.1.3. Szenario: Ablauf der Zeitplanung . . . . . . . . . . . . . . . . . . . . 704.1.4. Szenario: Verwaltung von Ereignissen . . . . . . . . . . . . . . . . . 754.1.5. Szenario: Zeiterfassung . . . . . . . . . . . . . . . . . . . . . . . . 76

4.2. Auswahl der Zielplattform . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774.2.1. Web-Technologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794.2.2. Web 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804.2.3. Ajax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

5. Realisierung 825.1. Implementierung des Prototyps . . . . . . . . . . . . . . . . . . . . . . . . 82

5.1.1. Verwendete Technologie . . . . . . . . . . . . . . . . . . . . . . . . 825.1.2. Aufbau der Web-Applikation . . . . . . . . . . . . . . . . . . . . . . 845.1.3. Realisierung der Planungskomponente . . . . . . . . . . . . . . . . 855.1.4. Ajax in Aktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

5.2. Einsatz des Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875.2.1. Ereignisverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . 875.2.2. Zeitplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Inhaltsverzeichnis 6

5.2.3. Zeiterfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

6. Zusammenfassung und Ausblick 926.1. Stand der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 926.2. Weiterentwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Literaturverzeichnis 94

A. Agiles Manifest 98

B. Project Data Sheet 99

C. Inhalt der beigefügten CD-ROM 100

Abbildungsverzeichnis

1.1. Struktur der rollenbasierten Projektplanung . . . . . . . . . . . . . . . . . . 101.2. Faktoren der Zeitplanung für einen Mitarbeiter . . . . . . . . . . . . . . . . . 111.3. Klassischer Informationsfluss zwischen Projekt- und Arbeitszeitplanung . . . 121.4. Informationsfluss in Projekten mit Verwaltungsautonomie der Mitarbeiter . . . 13

3.1. Einordnung des Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.2. Individuelle Zeitplanung mit dem System (reduzierte Darstellung) . . . . . . . 473.3. Ereignis mit definiertem Endtermin, Vorwärtsplanung . . . . . . . . . . . . . 513.4. Ereignis mit definiertem Endtermin, Rückwärtsplanung . . . . . . . . . . . . 513.5. Ereignis mit definiertem Starttermin, Vorwärtsplanung . . . . . . . . . . . . 523.6. Ereignis innerhalb eines definierten Zeitintervalls, Vorwärtsplanung . . . . . 523.7. Ereignis innerhalb eines definierten Zeitintervalls, Rückwärtsplanung . . . . . 523.8. Variables Ereignis ohne Start- und Endtermin, Vorwärtsplanung . . . . . . . 533.9. Anwendungsfälle des Systems . . . . . . . . . . . . . . . . . . . . . . . . . 563.10.Systemauthentifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573.11.Verwaltung von Ereignissen . . . . . . . . . . . . . . . . . . . . . . . . . . 583.12.Zeitplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.13.Zeiterfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603.14.Verwaltung der Benutzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.1. Konzeptionelle Fachklassen . . . . . . . . . . . . . . . . . . . . . . . . . . 634.2. Klassendiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644.3. Initialisierung des Controller Objekts . . . . . . . . . . . . . . . . . . . . . . 704.4. Berechnung des Zeitplans . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.5. Verarbeitung der Ereignisse durch die zugeordneten Planer . . . . . . . . . 724.6. Planungsalgorithmus eines Termins (Appointment) . . . . . . . . . . . . . . 734.7. Planungsalgorithmus einer Projektaufgabe (FloatingTask) . . . . . . . . . . 744.8. Ereignisverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754.9. Beginn der Zeiterfassung eines Ereignisses . . . . . . . . . . . . . . . . . . 764.10.Beenden der Zeiterfassung eines Ereignisses . . . . . . . . . . . . . . . . . 77

Abbildungsverzeichnis 8

5.1. Seitenfluss der Web-Applikation . . . . . . . . . . . . . . . . . . . . . . . . 845.2. Einsatz von Ajax in der Ereignisverwaltung . . . . . . . . . . . . . . . . . . 875.3. Bearbeiten eines Ereignisses . . . . . . . . . . . . . . . . . . . . . . . . . 885.4. Wochenübersicht der Zeitplanung . . . . . . . . . . . . . . . . . . . . . . . 905.5. Zeiterfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

B.1. Beispiel eines Project Data Sheet [Highsmith, 2004] . . . . . . . . . . . . . 99

1. Einleitung

Die GAIA Unternehmensberatung ist in den Geschäftsbereichen Consulting, Gesundheits-und Wissensmanagement tätig. Ihr Kerngeschäft ist die Beratung von Unternehmen ausdem Gesundheitssektor. Ein heterogenes Team von Ärzten, Akademikern aus den Geistes-und Naturwissenschaften, der Betriebswirtschaft und Informationstechnologie ermöglicht ei-ne Ausrichtung auf die verschiedenen Geschäftsbereiche. In der Größenordnung von rundzwanzig Mitarbeitern ist die GAIA AG in dem Feld der mittelständischen Unternehmen anzu-siedeln.

Diese Bachelorarbeit beschäftigt sich mit dem Themengebiet Zeitplanung und Zeiterfassung.Anhand der Geschäftsabläufe der GAIA AG werden Anforderung an ein System für Zeitpla-nung und Zeiterfassung formuliert, und anhand dieser eine unterstützende Softwarelösungentwickelt wird.

1.1. Motivation

In Consultingunternehmen ist das Projekt eine etablierte Organisationsform. Gleichzeitigdurchgeführte Projekte gehören zum täglichen Geschäft. Hier können zwei unterschiedlichePerspektiven eingenommen werden bezogen auf das gesamte Projekt und auf den einzel-nen Mitarbeiter. Aus der Projekt Perspektive ergibt sich kein Mangel an IT-Unterstützung,sehr wohl aber aus der Perspektive des einzelnen Mitarbeiters.

Aus Projektsicht ergibt sich folgendes Bild:

Es gibt zwei grundsätzliche Rollen, die der Projektleitung und die des Projektmitarbeiters.Die Projektleitung übernimmt Aufgaben der Organisation, Planung und Steuerung der Pro-jekte und die Projektmitarbeiter verrichten die einzelnen Arbeitspakete. Für jedes Projektergeben sich verbindliche Rahmenbedingungen wie Ressourcen, Budget und Termine, vondenen der erfolgreiche Projektabschluss abhängt. Ein Projekt wird dabei für sich im Einzel-nen organisiert und geplant. Zudem ist es klar abgegrenzt zu den anderen Projekten undGeschäftsvorgängen zu betrachten. Für eine solche Planung stehen bereits viele geeigneteWerkzeuge aus den Bereichen des Projektmanagements und Operations Research bereit.In Unternehmen kommt es oft zur zeitlichen Überschneidung von mehreren Projekten. In

1. Einleitung 10

Abbildung 1.1 wird ein Szenario dargestellt, welches die Planungsstrukturen von drei Projek-ten zeigt, die zeitlich parallel durchgeführt werden. Die einzelnen Projekte bilden hier einenRahmen, in dem alle Projektaktivitäten, wie z.B. Planung- und Projektaufgaben, definiertenRollen zugeordnet werden.

Abbildung 1.1.: Struktur der rollenbasierten Projektplanung

Wechselt man nun die Perspektive und betrachtet dieses Szenario aus der Sicht eines Mit-arbeiters, so stellt sich dieses wie in Abbildung 1.2 dar. Der Mitarbeiter nimmt verschiedeneRollen in mehreren Projekten ein. Er hat die Rahmenbedingungen unterschiedlicher Projek-te und andere Tätigkeiten in seiner individuellen Zeitplanung zu koordinieren. Angenommen,ein Mitarbeiter hat drei Rollen in dem zuvor beschriebenen Projektszenario (Abbildung 1.1).Für Projekt 1 übernimmt er die Leitung und damit die Koordination des gesamten Projekts(Rolle PL1). In den Projekten 2 und 3 gehört er zum Projektteam und hat bestimmte Ar-beitspakete zu erledigen (Rolle P2M1, P3M1). Zudem muss er weitere Aktivitäten, wie dasTagesgeschäft, Besprechungen und Termine, mit seiner Zeitplanung vereinbaren.

1. Einleitung 11

Abbildung 1.2.: Faktoren der Zeitplanung für einen Mitarbeiter

Der Mitarbeiter versucht, bei seiner eigenen Zeitplanung sowohl den zeitlichen Rahmenbe-dingungen der Projektaufgaben als auch denen des Tagesgeschäfts zu entsprechen. Die-se Aufgabe gestaltet sich schwieriger, je mehr Projekte und damit verbundene Aktivitätenzu koordinieren sind. Die Einbeziehung in mehrere Projekte und das eigenverantwortlicheKoordinieren unter komplexen Bedingungen erweisen sich als Hauptfaktor gesundheitlicherBelastung der Mitarbeiter. Dies belegt der aktuelle Report „Zwischen Innovation und alltägli-chem Kleinkrieg“ des Instituts für Arbeit und Technik Gelsenkirchen.

„Die Mitarbeiter sind häufig für mehrere Projekte oder Aufträge gleichzeitig zuständig undmüssen ihren Arbeitseinsatz individuell koordinieren. ...Häufig genannte Belastungen waren vor allem Probleme durch gleichzeitige Einbindung inmehreren Projekten, ungeplante Zusatzaufgaben sowie Behinderungen durch unzureichen-de Arbeitsmittel, fehlende Entscheidungen aus dem Management oder mangelnde Kunden-kooperation.“ [IAT, 2006]

Ein wesentliches Problem besteht hier im dauerhaften Zeitdruck, der unter anderem durchunzureichende Unterstützung in der individuellen Planung bedingt ist.

Der Zeitdruck für die Projektmitarbeiter entsteht oft durch neue bzw. veränderte Anforderung-en, die von dem Kunden über die Projektleitung an das Projektteam weitergegeben werden.

1. Einleitung 12

Da die zuvor geplanten Auslieferungstermine und Budgetlimits aber weiterhin als verbindlichgelten, erhöht dies die Belastung der Projektmitarbeiter zunehmend. Die Situation verschärftsich, wenn den Mitarbeitern unkoordinierte Anforderungen und zusätzliche Arbeitsaufträgevon Projektverantwortlichen aus unterschiedlichen Projekten erteilt werden. Während auf derSeite der Projektplanung also feste Vorgaben für die Arbeitszeitplanung der Mitarbeiter ent-stehen, findet eine Rückkopplung zwischen Mitarbeiter und Planung kaum statt (Abbildung1.3).

Abbildung 1.3.: Klassischer Informationsfluss zwischen Projekt- und Arbeitszeitplanung

In der klassischen Projektorganisation sind die Verantwortlichkeiten zwischen der Projektlei-tung und den Mitarbeitern fest unterteilt. Der Freiheitsgrad bei der Arbeitszeitplanung wirddurch den Projektplan bedingt. In dynamischen Projekten hat der Projektmitarbeiter hat zuwenig Spielraum, seine eigene Zeitplanung geeignet zu koordinieren.

Der Projektmitarbeiter sollte hier gewisse Einflussmöglichkeiten haben, um die Rahmenbe-dingungen seiner Zeitplanung und Organisation der ihm zugeteilten Projektaktivitäten mitzu-gestalten (Abbildung 1.4). In kleinen Projektteams kann die Projektplanung unter Berücksich-tigung der Auslastungssituation der involvierten Mitarbeiter erfolgen. Diese intern kommuni-zierten Rahmenbedingungen können dann zum Bestandteil in den Verhandlungen mit demKunden gemacht werden, um damit einen realistischen Zeitrahmen für ein Projekt und dieProjektmitarbeiter zu schaffen. Eine in Zusammenarbeit mit dem Projektteam entstandeneProjektplanung, liefert hier Möglichkeiten zur entlastenden Arbeitsgestaltung und -planungder Mitarbeiter.

1. Einleitung 13

Abbildung 1.4.: Informationsfluss in Projekten mit Verwaltungsautonomie der Mitarbeiter

Neben der Planung von Projekten nimmt die Koordination der Projektaufgaben und Nebentä-tigkeiten eines Mitarbeiters eine wichtige Rolle ein. In Projekten, in denen die Projektleitunglediglich als Koordinator fungiert und die Projektmitarbeiter ein hohes Maß an Selbständig-keit und Verantwortung haben, muss die Zeitplanung der Mitarbeiter besonders behandeltund berücksichtigt werden. Neben den in der Projektplanung eingesetzten Werkzeugen soll-te auch den Mitarbeitern für ihre individuelle Zeitplanung geeignete Unterstützung gebotenwerden, um die Planung effizienter und effektiver zu gestalten. Deshalb wird in dieser Arbeitein System entworfen, das diesen Prozess der Zeitplanung adäquat unterstützt, um die Mit-arbeiter zu entlasten und gleichzeitig für die Kunden stabile Projektgeschäfte zu erreichen.

1. Einleitung 14

1.2. Ziele der Arbeit

Im Rahmen dieser Arbeit wird ein System zur Unterstützung der Zeitplanung in agilen Pro-jektabläufen entwickelt. Die Projektorganisation der GAIA AG wird dabei stellvertretend fürmittelständische Unternehmen mit innovativer Produktentwicklung betrachtet. Anhand derArbeitsweisen der Mitarbeiter werden die Anforderungen an das System formuliert.

In Kapitel 2 werden zunächst die Geschäftsfelder und typischen Projekte der GAIA AG vor-gestellt sowie die Arbeitsweisen und Methoden der Zeitplanung der Mitarbeiter analysiert.Es wird geklärt, ob das hier angewandte Vorgehen zur Organisation und Planung des klas-sischen oder des agilen Projektmanagement passt. Abschließend wird geprüft, inwieweitexistierende Softwarelösungen auch Anforderungen agiler Projekte gerecht werden.

In Kapitel 3 werden anhand der erarbeiteten Anwenderziele genaue Anforderungen an dasZeitplanungssystem analysiert und formuliert. Zudem erfolgt eine Abgrenzung der Syste-mumgebung und die Festlegung von Anwendungsfällen.

In Kapitel 4 wird die Entstehung des Systementwurfs behandelt und in einem Klassenmodellumgesetzt. Danach werden die Vor- und Nachteile einer möglichen Zielplattform abgewogenund schließlich wird eine Auswahl getroffen.

Das darauf folgende Kapitel 5 befasst sich mit der prototypischen Umsetzung des Systemszur Unterstützung der Zeitplanung. Hier werden die eingesetzten Technologien vorgestellt,Details der Realisierung erläutert und ein Überblick der erstellten Systemkomponenten ge-geben.

Eine Zusammenfassung der Ergebnisse und ein Ausblick, über die mögliche Weiterentwick-lung des umgesetzten Systems, wird in Kapitel 6 beschrieben.

2. Grundlagen

Dieses Kapitel stellt das Umfeld und die Begriffswelt der Zeitplanung in agilen Projektab-läufen vor. Die typische Projektorganisation der GAIA AG dient hier als Veranschaulichung.Zunächst werden die Arbeitsweisen und Aktivitäten sowie die Zeitplanung der Mitarbeiter vor-gestellt und untersucht. Um die Rollen der Mitarbeiter und die hier eingesetzten Projektma-nagementmethoden besser zu verstehen, werden deren wesentliche Merkmale aufgezeigtund von anderen Vorgehensweisen abgegrenzt. Auf Grundlage der vorgestellten Projektei-genschaften und dem Arbeitsumfeld der Mitarbeiter werden dann softwarebasierte Systemeuntersucht und bewertet, welche die Zeitplanung unterstützen können. Die hier erlangten Er-kenntnisse liefern den Ausgangspunkt, für die Bestimmung genauer Anforderungen an eingeeignetes Planwerkzeug.

2.1. Fallstudie GAIA AG

Die Geschäftsfelder der GAIA AG gliedern sich hauptsächlich in die Bereiche Unternehmens-beratung und Erstellung von Wissensmanagementsystemen. Im Tätigkeitsfeld Wissensma-nagement beschäftigt sich die GAIA AG mit der Entwicklung von Trainings- und Expertensys-temen. Dies sind softwarebasierte Systeme, die durch die Bereitstellung von Expertenwissenhelfen, bestimmte Problemstellungen zu lösen oder zu bewerten. Expertensysteme beste-hen dabei aus einer von Experten gepflegten Wissensbasis und einer Komponente zumBearbeiten und Darstellen der Wissensbasis. Die Entwicklung verlangt dabei Kompetenzenfür die inhaltliche und technische Ebene der Realisierung. Ziel ist es, ein System zu liefern,welches individuell auf die Bedürfnisse des Kunden zugeschnitten ist.

Die Problemstellungen und das Umfeld der Kunden ähneln sich zwar teilweise, sind aber niegenau gleich. Aufgrund der Einzigartigkeit der Situation und spezieller Anforderungen derKunden existiert auch nicht die eine Lösung oder gar das eine Wissensmangementsystem.„Die Zeiten des ’one best way’ sind vorbei“ [Weiss, 2005] und die Lösungen der GAIA AGwerden deshalb an die Bedürfnisse des Kunden angepasst. Die Projekte werden gemeinsamund in enger Zusammenarbeit mit dem Kunden durchgeführt. Das Feedback des Kundenfließt kontinuierlich als wichtiger Bestandteil in den Entwicklungsprozess ein. Die Planungund Organisation der Projekte muss sich deshalb immer wieder auf Veränderungen und neue

2. Grundlagen 16

Rahmenbedingungen einstellen. Dies verlangt flexible Strukturen und Vorgehensweisen beider Gestaltung der Projektabläufe.

Die Entwicklung von Experten- und Trainingssystemen ist in Form eines Projekts organisiert.Die Projekte erfordern das Fachwissen der so genannten Autoren, die als Experten in den je-weiligen Wissensgebieten fungieren. Sie beschäftigen sich mit dem Wissensengineering, derOrganisation und Identifikation des Wissens, welches für das Kundenprojekt relevant ist. InZusammenarbeit mit den Informatikern der IT-Abteilung, welche die technische Umsetzungder Systeme unterstützen, entstehen diese Softwarelösungen. Diese Projekte werden oftparallel durchgeführt und sowohl die Autoren als auch die Informatiker nehmen unterschied-liche Rollen bei der Entwicklung dieser Systeme ein. Interviews mit einzelnen Mitarbeiternder GAIA AG lieferten einen Einblick in die Arbeitsweisen und Methoden der Zeitplanung vonAutoren und Informatikern und Beratern, aber auch in die Projektkoordination als Ganzes.

2.1.1. Autoren

Die Autoren der GAIA Experten- und Trainingssysteme beschäftigen sich mit der Aufbe-reitung und Strukturierung einzelner Wissensgebiete. Die Systeme gliedern sich in unter-schiedliche Module zu einzelnen Themenbereichen. Bei der Entwicklung eines Moduls istder Zeitrahmen für die Fertigstellung durch den Projektplan meist fest vorgegeben. Die kon-krete Zeitplanung mit den einzelnen Arbeitsschritten wird von den Autoren selbst erstellt. DieModulerstellung wird dabei von dem Autor in einzelne überschaubare Arbeitsschritte geglie-dert. Der erste Schritt ist die Erstellung der Wissensbasis. In Abhängigkeit von der Größe desThemengebiets und dem Kenntnisstand des jeweiligen Autors sowie den bereits vorliegen-den Daten, wird für die Recherche unterschiedlich viel Zeit aufgewendet. Danach erfolgt dieModellierung der Wissenbasis in die Dialogstrukturen des Expertensystems. Die Erstellungmultimedialer Inhalte innerhalb der Dialoge muss ebenfalls von dem verantwortlichen Autorkoordiniert werden. Nachdem das Modul in seiner ersten Fassung erstellt wurde, wird derInhalt von anderen Autoren mit entsprechendem Fachwissen verifiziert bzw. durch Glossar-einträge ergänzt. Abschließend erfolgt eine technische Nachbearbeitung des Moduls durcheinen Informatiker, bevor es an den Kunden ausgeliefert wird.

Die Erstellung eines Moduls kann bis zu mehreren Monaten dauern und ist von dem Um-fang des Themengebiets sowie den Anforderungen, die an das Modul gestellt werden, undder Anzahl der beteiligten Autoren abhängig. Innerhalb dieser Zeitspanne können sich Prio-ritäten und Verantwortlichkeiten ändern. Das hat etwa zur Folge, dass die Entwicklung ei-nes Moduls angehalten oder an einen anderen Autor übergeben wird. Eine solche Über-gabe erfordert Kommunikation und Wissensabgleich zwischen den Autoren. Der aktuelleStand eines Projekts muss objektiv nachvollziehbar vorliegen, damit Projektverantwortlich-keiten reibungslos übergeben werden können. Autoren sind teilweise in mehreren Projekten

2. Grundlagen 17

gleichzeitig mit unterschiedlichen Anforderungen / Aufgaben konfrontiert (Erstellung einesGlossars, Überprüfung von Inhalten, Dialogführung). Auch dies muss auf individueller sowieprojektübergreifender Ebene objektiv nachvollziehbar sein.

Aufgrund der ständigen Veränderungen bei der Erstellung eines Moduls nehmen die Au-toren nur eine grobe Zeitplanung vor. Eine exakte Planung des Ablaufs würde schnell anAktualität verlieren und die regelmäßige Pflege der einzelnen Aufgaben würde sich als zuaufwändig gestalten. Als Kompromiss hat sich die Erstellung einer Aufgabenliste bewährt, inder die Ziele und Meilensteine festgehalten werden. Die Aufgabenlisten werden nach demScrum-Prinzip1 geführt und dokumentieren sowohl die erledigten als auch die zukünftigenArbeitsschritte und Entwicklungsziele. Bei diesem Vorgehen fällt es schwer, besonders beimehreren Projekten, den Zeitrahmen zu überblicken. Zudem ist das Eintreten bestimmterProjekte noch nicht ganz gesichert, da beispielsweise noch abschließende Kundenverhand-lungen ausstehen, aber die benötigten Kapazitäten bereits im Vorwege geprüft werden. Oftbleibt es unklar, wie viel Zeit durch die einzelnen Aufgaben schon verplant wurde und inwie-weit der zeitliche Rahmen bereits erschöpft ist.

Neben der Zeitplanung innerhalb eines Moduls gilt es für die Autoren selbst, eine individuel-le projektübergreifende Planung ihrer Aktivitäten vorzunehmen. Aufgrund des veränderlichenUmfelds kann hier die Planung auch nur in größeren Zeiträumen erfolgen. Wöchentlich wer-den daher von den Autoren bestimmte Aufgaben aus den Scrum-Listen beteiligter Projekteausgewählt und als Wochenziel gesetzt. Dabei ist es nicht relevant, an welchem genauen Ar-beitstag die jeweilige Projektaufgabe fertiggestellt wird. Auch die längerfristige Planung ihrerArbeitsschritte liegt in der Verantwortlichkeit der Autoren. Die Komplexität der Arbeitszeitpla-nung wächst aber mit der betrachteten Zeitspanne, die zeitlichen Faktoren der Projektauf-gaben müssen in diesem Zeitraum entsprechend chronologisch geordnet werden. Darausergibt sich die Auslastung einzelner Autoren, welche bei der Bestimmung aktuell verfügbarerRessourcen für neue Projekte wichtig ist. Bisher gibt es für die Autoren keine technischenMittel, die sie bei ihrer individuellen Zeitplanung des operativen Tagesgeschäfts unterstützen.Die Terminplanung wird von Autoren über die im Unternehmen eingesetzte PIM-Software Mi-crosoft Outlook vorgenommen. Feste Termine gehören aber eher selten zu dem Tagesablaufder Autoren.

2.1.2. Informatiker

Ein Informatiker der GAIA AG hat täglich unterschiedliche Aufgaben zu erledigen: Planungund Entwicklung von Softwarelösungen, die Administration der GAIA Expertensysteme und

1Scrum ist ein iterativer, inkrementeller Prozess für die Entwicklung von Produkten oder das Management derArbeit. [www:Scrum]

2. Grundlagen 18

die Unterstützung der Autoren bei technischen Fragen. Desweiteren werden allgemeine Re-cherchen im Bereich der Softwareentwicklung sowie die Evaluierung neuer Techniken undWorkflow unterstützender Softwarelösungen durchgeführt. Die Informatiker sind ebenfallsbei der Aufwandsschätzung neuer Aufträge involviert. Anhand der Kundenanforderungenwird von ihnen der Aufwand für die IT-Abteilung geschätzt. Die Einschätzung der Aufgabenerfolgt mit dem Function-Point-Verfahren, der Analyse von Anwendungsfällen und auf derBasis gesammelter Erfahrungen in anderen Projekten. Im Rahmen der Aufwandsschätzungwerden auch mögliche Risiken identifiziert und berücksichtigt.

Der Informatiker muss im Durchschnitt, täglich drei bis zehn unterschiedliche Aufgaben zeit-lich koordinieren. Der Aufwand für die jeweiligen Aufgaben variiert stark, von einigen Minutenbis hin zu mehreren Stunden. Zudem müssen langfristige parallele Projektaktivitäten verein-bart werden, um eine termingerechte Fertigstellung zu gewährleisten. Die Bedingungen sinddamit ähnlich wie bei den Autoren der Expertensysteme. Die Planung der eigenen Arbeits-zeit liegt in der Verantwortung der Informatiker. Eine technische Unterstützung wird bei die-sem Prozess bisher kaum geboten. Ein Hilfsmittel für die Koordination der Arbeitspakete be-schränkt sich auf die Dokumentation der Tätigkeiten nachdem Scrum-Prinzip. Ein zeitlicherZusammenhang lässt sich aus den Scrum-Listen nur bedingt ableiten. Zudem beschränkensich die in ihnen enthaltenen Informationen nur auf ein Projekt. Die projektübergreifende Ein-teilung der Arbeitszeit muss daher durch den Informatiker erfolgen. Eigens für das operativeTagesgeschäft erstellte Projektplänen haben sich angesichts der häufigen Veränderungenals unflexibel und zu aufwändig erwiesen. Neben den Projektaufgaben werden die Termineüber die Kalenderfunktion der unternehmensweit eingesetzten PIM-Software verwaltet.

2.1.3. Berater

Die Berater der GAIA AG unterstützen und beraten Unternehmen aus dem Gesundheits-sektor. Ihre Aktivitätsbereiche umfassen unter anderem Projektarbeiten, Recherchen undPräsentationsvorbereitungen. In Abhängigkeit von der Aufgabe sind ein oder mehrere Mitar-beiter in die Tätigkeiten involviert. Das Tagesgeschäft der Berater ist zudem mit vielen wech-selnden Aufgaben und Unterbrechungen verbunden, welche durch Kundenanfragen oderAnfragen interner Mitarbeiter entstehen. Veränderungen der Arbeitsaufträge geschehen lau-fend und sind schwer kalkulierbar, daher ist es schwer, feste Zusagen über den Fortschritteinzelner Aktivitäten zu geben. Dieses sind meist Schätzungen auf Grundlage der gesam-melten Erfahrungen der Berater. Zudem ist die aktuelle Auslastung und der Arbeitsfortschrittder Berater ein wichtiger Faktor bei der Behandlung von Ressourcenanfragen für neue Pro-jekte. Die Beratungstätigkeiten finden oft direkt bei dem Kunden vor Ort statt. Deshalb sinddie Besprechungen bei dem Kunden mit Geschäftsreisen verbunden. Die benötigte Reisezeitist hier ein wesentlicher Faktor, welcher in der Zeitplanung der Berater berücksichtigt werdenmuss. Die Terminabsprache erfolgt mit dem Kunden per Telefon oder Email. Die kollaborative

2. Grundlagen 19

Terminplanung durch den Einsatz der Groupware ist außerhalb der Unternehmensgrenzennicht denkbar. Die Planung ist dabei oft an viele Bedingungen gebunden, welche sich zu-dem kurzfristig ändern können. Die Zeitplanung der Berater richtet sich damit hauptsächlichnach den Vereinbarungen mit dem Kunden und wird nur im gewissen Umfang von ihm selbstbestimmt. Die Berater haben also überwiegend Termine zu planen und weniger Projektauf-gaben. Die Zeitplanung der Berater erfolgt zur Zeit mit der Kalenderkomponente von der imUnternehmen eingesetzten Groupware. Die Zeiterfassung ihrer Tätigkeiten wird mit einemTabellenkalkulationsprogramm durchgeführt und dokumentiert.

2.1.4. Projektkoordination in der GAIA AG

Die Projektleitung ist die zentrale Organisationseinheit bei der Durchführung von Projekten.In agilen Projekten beruht diese Rolle auf den Funktionen der Koordination und Modera-tion des Projektteams zur Erreichung der angestrebten Projektziele. In Abhängigkeit vondem Projektcharakter wird innerhalb der GAIA AG ein Mitarbeiter anhand seiner Fähigkei-ten als Projektkoordinator ausgewählt. Der Projektkoordinator besitzt bereits Wissen überdie Projektdomäne und kann innerhalb des Projektteams die Mitarbeiter anhand ihrer Qua-lifikation und Fähigkeiten den entsprechenden Rollen zuweisen. Die Aufgabe des Projekt-managments ist es, eine Umgebung zu schaffen in der eine Interaktion und Kollaborationdes Projektteams gefördert wird. Dabei sind dem Projektteam so viele Freiheitsgrade wiemöglich einzuräumen.

In Projekten nimmt das Informationsmanagement eine wichtige Rolle ein. Dem Entschei-dungsträger müssen deshalb die aktuellen Projektdaten möglichst zeitnah vorliegen. Für dasProjektteam gilt es, alle Informationen der Projekte und der damit verbundenen Aktivitätenmöglichst objektiv zu erfassen, nur dann ist effektives Projektcontrolling möglich. Üblicher-weise wird der Stand des Projekts von der Leitung und dem verantwortlichen Projektteam inBesprechungen regelmäßig kommuniziert. In agilen Projekten steht die Kommunikation in-nerhalb des Projektteams im Vordergrund. Die Dokumentation der Vorgänge hingegen sollteangemessen sein und sich auf das Wesentliche konzentrieren.

Die Projektkoordination bildet zudem die Schnittstelle zwischen dem Kunden und dem Pro-jektteam. In Verhandlungen werden hier die einzelnen Produkteigenschaften und deren Prio-rität im Entwicklungprozess vereinbart. Die Umsetzung der Entwicklungsziele erfolgt in agi-len Projekten weitgehend in autonomen Projektteams mit den Fähigkeiten der Selbstdisziplinund Selbstorganisation. Anders als in der klassischen Projektorganisation geht es hier nichtdarum, detaillierte Arbeitsaufträge über Pläne an die einzelnen Projektmitarbeiter zu ver-teilen, sondern selbstorganisierte Projektteams Eigenverantwortung für die termingerechteFertigstellung der vereinbarten Produkteigenschaften übernehmen zu lassen.

2. Grundlagen 20

2.1.5. Fazit

Aus den hier beschriebenen Arbeitsprofilen lassen sich drei Anwendergruppen bilden. DieAutoren und Informatiker haben aufgrund ihrer Rahmenbedingungen bei der Zeitplanungnahezu die gleichen Anforderungen an ein unterstützendes System. Diese Anwendergruppebenötigt ein Planwerkzeug, das die Planung von Terminen, Multi-Projekttätigkeiten und pro-jektübergreifender Aktivitäten in einem zeitlichen Zusammenhang darstellt. Im Vordergrundsteht dabei, dass auf Veränderungen der zeitlichen Rahmenbedingungen möglichst einfachund schnell reagiert werden kann, ohne dass ein Zeitplan aufwändig erstellt werden muss.

Die Anwendergruppe der Unternehmensberater unterscheidet sich von den Anforderungender Autoren und Informatiker, da hier die Terminplanung im Vordergrund steht. Die Zeitpla-nung ist im Wesentlichen an die Vereinbarungen mit dem Kunden gekoppelt und unterliegtdamit nur bedingt dem Einfluss des Beraters.

Die dritte Koordination und Lenkung der Projekt- und Geschäftsabläufe, werden von der Pro-jektkoordination und der Geschäftsführung ausgeführt. Diesen Entscheidungsträgern solltenals Entscheidungsgrundlage alle relevanten Informationen bereitgestellt werden. Der Infor-mationsaustausch erfolgt dabei über die Kommunikation mit den verantwortlichen Mitarbei-tern. Die Dokumentation sollte sich hier auf einen notwendigen Umfang reduzieren.

Anhand der Arbeitsweisen der Mitarbeiter lassen sich konkrete Anforderungen bestimmen,welche an eine Software zur Unterstützung der Zeitplanung gestellt werden müssen. Zu-sammenfassend werden folgende Faktoren als wesentlich bei der individuellen Arbeitszeit-planung eines Mitarbeiters aufgefasst:

• Tätigkeiten aus dem Tagesgeschäft

• zeitliche Rahmenbedingungen (Starttermin, geschätzte Dauer und voraussichtlicherEndtermin) von mehreren Arbeitspaketen aus unterschiedlichen Projekten

• Prioritäten der Termine und Arbeitspakete

• Fortschritt der Arbeitspakete

• Erfassung des Ist-Aufwands der Arbeitspakete

• geschäftliche Termine aus dem Terminkalender des Mitarbeiters

2. Grundlagen 21

2.2. Organisation und Planung von Projekten

Das Projektmanagement beschäftigt sich mit der Planung, Organisation und Durchführungvon Projekten. Dieser Abschnitt erläutert zunächst den Begriff des Projekts und die Eintei-lung in verschiedene Projektarten. Danach werden die wesentlichen Merkmale des klassi-schen und agilen Projektmanagements vorgestellt und die Unterschiede aufgezeigt.

2.2.1. Das Projekt

Der betriebswirtschaftliche Begriff „Projekt“ wird unter anderem in der DIN 69901 definiert.Hier heißt es, ein Projekt ist „ein Vorhaben, das im Wesentlichen durch eine Einmaligkeit derBedingungen in ihrer Gesamtheit gekennzeichnet ist“ [DIN 69901], wie beispielsweise:

• Zielvorgabe

• zeitliche, finanzielle, personelle oder andere Bedingungen

• Abgrenzung zu anderen Vorhaben

• projektspezifische Organisation

Andere Bedingungen sind hier projektabhängig zu definieren und umfassen z.B. in der Ent-wicklung von Softwaresystemen vor allem die Qualität [Raasch, 1993]. Die Norm schreibtProjekten eine Einmaligkeit zu, welche im Gegensatz zu der täglichen Routinearbeit eineBesonderheit darstellt. Deswegen bedarf es bei der Durchführung einer projektspezifischenOrganisation sowie den Einsatz von Managementmethoden. Die Einmaligkeit bedeutet hier,dass die Projektdurchführung unter den gegebenen Bedingungen einmalig sein muss, dabeisind nicht zwingend alle einzelnen Projektaufgaben gemeint. Weiter ist der Begriff „Ziel“ alsein definierter Soll-Zustand zu verstehen, der für alle Projektmitglieder eindeutig und verbind-lich sein muss. Da die Zieldefinition zu Projektbeginn meist aufgrund des Neuheitsgradesnoch teilweise unvollständig ist, gilt es im Laufe des Projekts, diese zu konkretisieren undfestzulegen. Die Rahmenbedingungen müssen dabei ständig überprüft und eventuell ange-passt werden. Desweiteren kennzeichnet ein Projekt die Nutzung von betrieblichen Ressour-cen, wie Personal, Kosten und Zeit, die alle oder in Kombination knapp sind. Abschließendgilt es Projekte inhaltlich, finanziell und personell von anderen unternehmerischen Vorhabenabzugrenzen.

2. Grundlagen 22

Projektarten

Die Einteilung von Projekten lässt sich anhand von unterschiedlichen Faktoren vornehmen.Die Projekte können dabei aus verschiedenen Perspektiven betrachtet und klassifiziert wer-den. Eine grobe Einteilung nach dem Projektziel unterscheidet die folgenden Projektklassennach [DIN 69901]:

• Investitionsprojekte (Bau- oder Anlagebauprojekt)

• Forschungs- und Entwicklungsprojekte (Technik-, Software- oder Produktentwicklung)

• Organisationsprojekte (Reorganisation, Outsourcing)

Außerdem können Projekte anhand des Schwierigkeitsgrades eingeteilt werden. Die Um-setzung der Projektvorhaben kann aufgrund des Neuigkeitsgrades, der Komplexität sowiedes damit verbundenen Risikos bewertet werden. So müssen Projekte aus dem BereichForschung und Entwicklung, mit denen Neuland betreten wird, anders organisiert werdenals Projekte, für die bereits unternehmensspezifische Erfahrungen in ähnlichen Vorhabengesammelt wurden. Die geeigneten Methoden und Vorgehensweisen werden im nächstenAbschnitt beschrieben.

2.2.2. Projektmanagement

Projektmanagement wird laut DIN 69901 als die „Gesamtheit von Führungsaufgaben,-organisation, -techniken und -mittel, die für die Abwicklung eines Projekts notwendig sind“[DIN 69901] definiert. Es ist ein Sammelbegriff für alle organisatorischen Vorkehrungen, wel-che für die erfolgreiche Durchführung eines Projekts getroffen werden. Das Projektmana-gement beinhaltet die Organisation und Koordination der einzelnen Projektaktivitäten zurLösung der Problemstellung. Im Mittelpunkt steht dabei die Zuordnung von Aufgaben, Kom-petenzen und Verantwortlichkeiten an die Projektmitglieder sowie die Organisation von Ent-scheidungsprozessen und die Durchsetzung der getroffenen Entscheidungen. Das Projekt-management unterteilt sich dabei in folgenden Aufgabenbereiche:

• Projektorganisation

• Projektplanung

• Projektcontrolling

Projekte haben viele Facetten, von denen der Einsatz einer konkreten Projektmanagement-methode abhängig ist. Bei den eingesetzten Methoden gibt es zwei Extreme, das klassischeund das agile Projektmanagement. Unter „klassischem Management“ ist hier eine detaillier-te Planung und anschließende Durchführung sowie Steuerung des Projekts zu verstehen.

2. Grundlagen 23

Das agile Projektmanagement hingegen konzentriert sich auf die Durchführung des Projektsin mehreren abgeschlossenen Etappen, mit ständiger Einbeziehung der dabei gesammel-ten Erkenntnisse. Die folgende Tabelle liefert einen Überblick und zeigt die Unterschiede derbeiden Ansätze nach [Boehm und Turner, 2003]:

Projekt klassisch agil

Ziele Vorhersagbarkeit, Stabilität, ho-he Sicherheit

schnelle Wertschöpfung, aufVeränderungen reagieren

Größe umfangreiche Teams und Projek-te

kleine Teams und Projekte

Umfeld stabil, wenig Veränderung,Schwerpunkt auf dem Projektund der Organisation

turbulent, viel Veränderung,Schwerpunkt auf dem Projekt

Änderung derAnforderungen

meist vorhersagbar, hohe An-passungskosten unterstellt

nicht vorhersagbar, Anfor-derungsevolution, niedrigeAnpassungskosten unterstellt

Management

Kundenbeziehung bedarfsorientierte Kundeninvol-vierung, konzentriert auf Ver-tragsbestimmungen

engagiert auf der Kundenseite,konzentriert auf priorisiertem Zu-wachs

Planungund Controlling

Aufgabenplanung, dokumentier-te Pläne, quantitative Kontrolle

Featureplanung, interne Pläne,qualitative Kontrolle

Managementstil Leitung, Mikromanagement Führung, Koordination

Kommunikation explizit dokumentiertes Wissen taktisches Wissen, Kollaboration

Personal

Kultur Wohlbefinden und Mitwirkungs-möglichkeit durch Richtlinien undVorgehensweisen

Wohlbefinden und Mitwirkungs-möglichkeit durch viele Freiheits-grade, Selbstorganisation und-disziplin

Tabelle 2.1.: Vergleich klassisches und agiles Projektmanagement

2. Grundlagen 24

Projektorganisation

Unternehmen besitzen Führungsstrukturen, welche Regelungen für die Organisation undAbwicklung wiederkehrender Geschäftsvorfälle vorgeben. Für Projekte müssen ebenfallstemporär solche Organisationsstrukturen etabliert werden. In Projekten ergibt sich aufgrundder meist fachübergreifenden Kollaboration in einem neuartigen Aufgabenbereich ein erheb-licher Koordinationsbedarf. Mit der Projektorganisation wird ein Rahmen geschaffen, der daszielgerichtete Zusammenwirken der Projektmitarbeiter und den reibungslosen Ablauf desProjekts sichern soll. Die Projektleitung hat je nach gewählter Organisationsform mehr oderweniger Verantwortung und Kompetenzen. Im Gegenzug besitzt das Projektteam einen grö-ßeren oder mehr eingeschränkten Freiheitsgrad bei der Ausführung der Arbeiten. In der Pra-xis existieren verschiedene Mischformen, hier soll deshalb nur der wesentliche Unterschiedzwischen einer streng klassischen und einer agilen Organisation erläutert werden.

Die klassische Organisation von Projekten etabliert feste hierarchische Strukturen für diefachliche und disziplinarische Unterteilung des Projektteams. Es wird dabei ein organisato-rischer Rahmen geschaffen, welcher auf Hierarchie, Kontrolle und Vorschriften basiert. DieKoordination zwischen dem Projekt und der ständigen Organisation des Unternehmens, wirddurch eine feste Definition aller Zuständigkeiten, Verantwortungen und Kompetenzen herge-stellt.

Das agile Projektmanagement dagegen gibt keine festen Strukturen vor, sondern setzt aufdie Selbstorganisation des Projektteams. Die Organisationsstrukturen sind eher flexibel. Eswerden in Abhängigkeit von der Größe des Projekts und Projektteams geeignete Strukturenaufgebaut. Dieses sind keine strengen hierarchischen Strukturen, eher orientieren sie sichdabei an den agilen Prinzipien2, um weiterhin anpassungsfähig zu bleiben. In kleinen Pro-jektteams mit großen Freiräumen sind Eigenverantwortung und Selbstdisziplin der einzelnenMitarbeiter entscheidend, um ein erfolgreiches Zusammenwirken zu erreichen.

Kleine Unternehmen mit hoch dynamischen Projekten sowie gut ausgebildeten Mitarbeiternscheinen besser zu der agilen Projektorganisation zu passen.

Projektplanung

Die Planung beschreibt ein systematisches Vorgehen zur Festlegung von Zielen und künf-tigen Handlungen im Kontext eines Projekts. Projektplanung zählt zu den wichtigsten Auf-gaben im Projektmanagement. Die Planung und Durchführung eines Projekts bildet einenKompromiss unter Vereinbarung der folgenden Faktoren:

• Ressourcen (Personal, Betriebsmittel, Kosten)

2Näheres zu den agilen Werten und Prinzipien ist dem Anhang A zu entnehmen.

2. Grundlagen 25

• Zeit (Termine, Meilensteine)

• Ergebnis (Produkt, Features, Qualität)

Aus der streng klassischen Perspektive betrachtet, sind die Phasen der Planung und Durch-führung aufeinander folgende und getrennte Projektphasen. Die Planung dokumentiert dabeidas Vorgehen zum Erreichen einer bestimmten Zielsetzung. Der Projektplan ist der Maßstab(Sollvorgabe) an dem der Ist-Aufwand bei der Durchführung gemessen wird. Die Planungs-phase ist in klassischen Projekten sehr ausgeprägt. Auf Grundlage der aktuell verfügbarenInformationen und Rahmenbedingungen wird darin ein detaillierter Plan erstellt. Das Vor-gehen teilt sich in zwei Schritte: in die Planung der Projektstruktur und in die Planung desProjektablaufs. In der Planung der Projektstruktur werden aus den Anforderungen die für dasProjekt wichtigen Projektteile und -teilaufgaben extrahiert, abgegrenzt und definiert. Abhän-gigkeiten unter den einzelnen Projektteilen werden bestimmt und damit eine systematischgeordnete Struktur für das Projekt festgelegt. Erst nachdem der Projektstrukturplan kompletterstellt wurde, kann mit der Bestimmung der zugehörigen Arbeitspakete begonnen werden.Die Arbeitspakete sind hier als Aufgaben oder Aktivitäten zu verstehen, welche für die Um-setzung der einzelnen Projektteile ausgeführt werden müssen. Sie dienen als Grundlage fürProjektablaufplanung, welche die logischen Zusammenhänge und Abhängigkeiten zwischenden Arbeitspaketen modelliert. Nachdem die Planung und Analyse des Projektablaufs ab-geschlossen wurde, kann mit der Projektzeitplanung begonnen werden. Der Projektzeitplanbeinhaltet die zeitlichen Zusammenhänge des geplanten Projektablaufs. Hier finden sich al-le Projektaufgaben und Meilensteine in ihrer zeitlichen Abfolge wieder. Die Darstellung derZeitpläne erfolgt oft mit Diagrammen aus der Netzplantechnik. Nachdem die Projektplanungbeendet wurde, kann mit der Durchführung des Projekts begonnen werden.

Beim agilen Projektmanagement unterteilt sich die Planung auf zwei Ebenen. Die erste Pla-nungsebene beschreibt anhand der Anforderungen einen groben Gesamtplan, der Aussagenüber Aufwand, Ressourcen, Dauer, Risiken, Ziele und Termine der Meilensteine macht. Un-ter Berücksichtigung der agilen Prinzipien sollte sich die Dokumentation dabei auf die wich-tigsten Daten konzentrieren. Eine Möglichkeit bietet hier das Project Data Sheet3, welchesauf maximal einer DIN A4 Seite die zentralen Geschäftsziele, Projekt- und Managementin-formationen zusammenfasst. Der Gesamtplan aus der ersten Planungsebene wird bei derkonkreten Umsetzung auf eine zweite Ebene heruntergebrochen. Auf dieser Ebene wird einiteratives Vorgehen angewendet, welches den Entwicklungsprozess in mehrere zeitlich be-grenzte Abschnitte unterteilt. Der Iterationsplan liefert einen groben Überblick aller geplantenIterationen und deren Ergebnisse sowie der definierten Meilensteine. Die detaillierte Zielpla-nung einer bevorstehenden Iteration wird in Zusammenarbeit von Projektleitung und Projekt-mitarbeitern vorgenommen. Dabei werden die angestrebten Ergebnisse diskutiert und die

3Eine beispielhafte Darstellung eines Project Data Sheet findet sich im Anhang B.

2. Grundlagen 26

resultierenden Arbeitsaufträge für einzelne Mitarbeiter oder Teams formuliert. Die Arbeits-aufträge sollten sinnvoll, realistisch und innerhalb der Iteration zu bewältigen sein, ansons-ten müssen sie in mehrere Teilaufgaben zerlegt werden. Nachdem die Verantwortlichkeitender Arbeitsaufträge geklärt wurden, folgt die eigentliche Umsetzung bzw. Entwicklung sowieanschließende qualitative Kontrolle und Lieferung der Ergebnisse. Abschließend wird in ei-ner Review ein Soll-/Ist Vergleich der iterationsspezifischen Ergebnisse angestellt, um denaktuellen Projektfortschritt zu erfassen. Diese Reflektion der Ergebnisse liefert wichtige In-formationen für die Planung der folgenden Iteration und eine Entscheidungsgrundlage fürmögliche Plankorrekturen.

Zeitplanung

Die Zeitplanung nimmt eine wichtige Rolle in Projekten ein. Deshalb soll dieser Vorganghier näher erläutert werden. In der Projektzeitplanung geht es darum, die zeitlichen Zusam-menhänge und Abhängigkeiten zwischen den einzelnen Projektaufgaben (Arbeitspakete, Ar-beitsaufträge) zu erfassen sowie den benötigten Aufwand abzuschätzen. Im Rahmen derZeitplanung sind dabei folgende Begriffe relevant:

Dauer Zeitspanne von Anfang bis Ende einer Tätigkeit bzw. eines Vorgangs

Pufferzeit Zeitspanne, innerhalb derer die Lage eines Vorgangs verändert werdenkann, ohne Auswirkung auf den Endtermin

Zeitpunkt „ein festgelegter Punkt im Ablauf, dessen Lage durch Zeiteinheiten (z.B.Minuten, Tage Wochen) beschrieben und auf einen Nullpunkt bezogen ist“[DIN 69900]

Termin ein durch Kalenderdatum und/oder Uhrzeit festgelegter Zeitpunkt

Meilenstein Stichtag für ein wesentliches Projektergebnis, „ein Ereignis besonderer Be-deutung“ [DIN 69900]

Bei der Zeitanalyse ist zunächst der zeitliche Aufwand der Projektaufgaben zu bestimmen.In der Praxis werden dafür Schätzverfahren eingesetzt. Doch die Projektleitung verfügt meis-tens nicht über die nötige Information, um den zeitlichen Aufwand der Projektaufgaben ab-zuschätzen. In Zusammenarbeit mit den involvierten Fachabteilungen werden geeigneteSchätzungen vorgenommen. Außerdem werden dabei Analogieverfahren verwendet, wel-che die gesammelten Erfahrungswerte aus früheren Projekten nutzen. Unter Verwendungder erfassten Zeiten und Dokumentationen vergangener Projekte können damit fundierteSchätzungen gemacht werden. Grundlage für realistische Schätzungen bilden die folgendenFaktoren [Hunt und Thomas, 2003]:

2. Grundlagen 27

• Die Genauigkeit der abgegebenen Schätzungen muss klar definiert werden. DieSchätzung muss ausreichend abgegrenzt werden und eventuell um Angaben erwei-tert werden, um mögliche Fehlinterpretationen auszuschließen. Die Wahl der Maßein-heit von Schätzwerten ist deswegen von entscheidender Bedeutung und sollte die be-absichtigte Genauigkeit unterstreichen. Eine kleinere Maßeinheit suggeriert vielleichtungewollt eine hohe Genauigkeit.

• Über das Schätzobjekt müssen genügend Informationen verfügbar sein. Präzise An-forderungen verbessern das Verständnis einer Projektaktivität und auch die Genau-igkeit der Aufwandsschätzung. Mangelnde Informationen haben zur Folge, dass eineReihe von Annahmen für bestimmte Punkte getroffen werden, was die Qualität derSchätzung erheblich vermindert. Bei der Durchführung eines Projekts verändern sichdie Erkenntnisse und Anforderungen an ein Schätzobjekt. Dieser Effekt wird als schlei-chender Funktionszuwachs (engl. requirements creep) bezeichnet. Mit verändertenBedingungen muss deshalb die Aufwandsschätzung während des Projektfortschrittsmehrmals wiederholt werden.

Aus der Sicht des traditionellen Projektmanagements erfolgt die Erstellung eines umfas-senden Projektzeitplans auf Grundlage der gesamten Struktur und des logischen Ablaufsdes Projekts. Die Zeitplanung projiziert dabei den Projektablauf auf eine Zeitachse. In derZeitanalyse werden die zeitlichen Aspekte und Beziehungen der Projektaufgaben genauerbetrachtet. Mit geeigneten Schätzverfahren wird ein geplanter Sollaufwand für die einzel-nen Projektaufgaben bestimmt. Desweiteren kann die Verrichtung voneinander unabhängi-ger Projektaufgaben zeitlich parallelisiert werden. In Abhängigkeit von der Projektkomplexitätwird die Zeitplanung meist unter Verwendung der Netzplantechnik ausgeführt. Ein Netzplanist die „graphische oder tabellarische Darstellung von Abläufen und der Abhängigkeiten“ [DIN69900]. Der Netzplan liefert Informationen über Termine, Dauer, Kapazitäten und Kosten desgesamten Projekts oder einzelne Vorgänge. Die Netzplantechnik gehört zu dem Bereich desOperations Research4, das Verfahren zur Analyse und Optimierung der Planungsprozessebietet. Die Zeitplanung im Sinne des klassischen Projektmanagements ist eine Hauptaufga-be der Projektleitung und orientiert sich dabei an der Planung von Projektaufgaben (engl.task-driven). Die Projektleitung hat die Projektpläne an das Projektteam zu verteilen z.B. alsPersonaleinsatzplan.

Im Gegensatz dazu gibt es in agilen Projekten zwei Ebenen der Planung. Während die Pro-jektleitung das gesamte Projekt koordiniert und durch die grobe Iterationsplanung die Richt-ung steuert, wird die ausführliche Planung einer Iteration in enger Zusammenarbeit mit demProjektteam vorgenommen. Die Planung konzentriert sich dabei auf die Definition von Zie-len (z.B. Produkteigenschaften), welche in dieser begrenzten Zeitspanne erreicht werdensollen (engl. feature-driven). Aus den definierten Zielen ergeben sich Arbeitsaufträge, deren

4Eine nähere Erklärung des Begriffs Operations Research befindet sich im Abschnitt 2.2.2

2. Grundlagen 28

Aufwand vom Projektteam geschätzt wird. Die konkrete Zeitplanung und Koordination derArbeitsaufträge und der Aktivitäten ist nicht mehr eine Aufgabe der Projektleitung, sondernliegt in der Verantwortung des Projektteams. Die Planungsaktivitäten der Projektleitung kon-zentrieren sich auf die Koordination des ganzen Projekts, ohne eine detaillierte Planung derProjektaufgaben durchzuführen. Als Vermittler zwischen Kunde und Projektteam werden vonder Projektleitung die einzelnen Iterationsziele vereinbart.

Zusammenfassend lässt sich festhalten, dass die Struktur- und Ablaufplanung in klassischenProjekten hauptsächlich von der Projektleitung durchgeführt wird. In agilen Projekten hinge-gen liegt nur die gesamte Projektkoordination in der Verantwortung der Projektleitung. Diegenaue Zeitplanung und Aufwandsschätzung für einzelne Arbeitsaufträge verlagert sich aufdas Projektteam. Folglich sollten in klassischen und agilen Projekten, abhängig vom Einsatz-gebiet, geeignete Planwerkzeuge bereitgestellt werden.

Projektcontrolling

Das Projektcontrolling vergleicht die Sollvorgaben aus der Projektplanung mit den aktuellenIst-Werten. Ein Vergleich ermöglicht eine Bewertung des bisherigen Projektverlaufs, um da-mit Prognosen über den weiteren Ablauf zu erstellen. Die Überwachung des Projekts beziehtsich dabei primär auf die Projektziele, Termine und Kosten. Der Überwachungsprozess setztsich aus drei Phasen zusammen [Litke, 1995]:

• Bereitstellung von aktuellen Ist-Daten (Fortschritts- und Zeiterfassung)

• Soll-/Ist Vergleich (Abweichungsanalyse)

• Bewertung der Analyse und Einleitung von Korrekturmaßnahmen

Im klassischen Projektmanagement bildet meist der erstellte Netzplan die Grundlage desProjektcontrollings. Der Soll-/Ist Vergleich konzentriert sich auf den Fertigstellungsgrad undden bereits geleisteten Aufwand für die einzelnen Projektaufgaben. Insbesondere sind dabeidie Projektaufgaben auf dem kritischen Pfad regelmäßig zu überprüfen, da hier eine mögli-che Verzögerung die gesamte Projektdauer beeinflusst. Der Abgleich des Projektfortschrittserfolgt meist in Besprechungen und über softwarebasierte Projektmanagementsysteme zurAktualisierung der Netzpläne.

Im agilen Projektmanagement hingegen überprüft die Projektleitung am Ende jeder Iterationdie zuvor definierten Ziele mit den gelieferten Ergebnissen. Da die Zeitplanung und Koor-dination der einzelnen Arbeitsaufträge in der Eigenverantwortung des Projektteams liegen,werden sie nicht als Maßstab herangezogen. Die Überwachung und Steuerung seitens der

2. Grundlagen 29

Projektleitung erfolgt über die qualitative Kontrolle der Projektziele bzw. Produkteigenschaf-ten. Das Projektcontrolling hat in agilen Projekten eher den Charakter des Produktcontrol-lings. Der Projektfortschritt wird in täglichen Besprechungen kommuniziert sowie im Reviewder Ergebnisse am Ende einer jeden Iteration.

Zeiterfassung

Grundlage für effektives Projektcontrolling ist eine konsequente Dokumentation der Projekt-aktivitäten. Nur wenn der aktuelle Stand des Projekts bekannt ist, kann man den Ablauf an-passen, anstatt nachträglich auf Probleme zu reagieren. Die Dokumentation eines Projektserfolgt auf verschiedenen Ebenen. In Abhängigkeit von der Ebene gibt es unterschiedlicheDetaillierungsgrade und Intervalle, in denen der Projektstatus veröffentlicht wird. WährendAuftraggeber und Interessenvertreter nur eine Übersicht der aktuellen Eckdaten des Pro-jekts verlangen, muss ein Projektmanager ständig über den genauen Aufwand und Fort-schritt aller Projektaktivitäten informiert sein. Die Zeiterfassung dokumentiert kontinuierlichden Aufwand und Fortschritt eines Projekts und bildet damit eine wichtige Grundlage für dasProjektcontrolling.

Aus einer streng klassischen Perspektive liefert die Zeiterfassung den aktuellen Ist-Aufwandeinzelner Projektaufgaben und bildet zusammen mit dem Fertigstellungsgrad eine Grundla-ge zur Analyse des aktuellen Projektfortschritts. Der erstellte Netzplan wird daher von derProjektleitung kontinuierlich mit den Ist-Daten aktualisiert. In Abhängigkeit vom Projektum-fang gestaltet sich die Aufbereitung der Projektdaten recht aufwändig. In der Praxis werdendaher Projektmanagementsysteme eingesetzt, welche die Pflege, Verwaltung und Verarbei-tung der Projektdaten unterstützen und effizienter machen. Eine Aufzeichnung des gesamtenProjektverlaufs liefert zudem wichtige Informationen für die Post-mortem-Analyse sowie fürdie Planung zukünftiger Projekte.

Im agilen Projektmanagement liegt die Verantwortung der Zeitplanung und Koordination derAufgaben bei dem Projektteam. Auch hier wird der zuvor abgeschätzten Soll-Aufwand mitden Ist-Daten verglichen, um den Fortschritt zu kontrollieren. Ein wesentlicher Unterschiedbesteht aber darin, dass es in einem kleineren und begrenzten Umfeld betrachtet wird. Diegetroffenen Vereinbarungen einer Iteration geben dabei sowohl zeitlich als auch inhaltlicheinen festen Rahmen vor. Trotzdem ist es auch hier sinnvoll den aktuellen Aufwand undFortschritt kontinuierlich zu dokumentieren. Im Sinne des „Self-improvement“ ermöglichendie gesammelten Informationen den Projektmitarbeitern, die Arbeitsaufträge zukünftiger Ite-rationen oder Projekte besser einzuschätzen.

Vor dem Hintergrund der projektspezifischen Organisation innovativer Produktentwicklung inkleinen Unternehmen erweisen sich die Ansätze des agilen Projektmanagements als sinn-voll. Die Projekte werden dabei oft über Festverträge mit dem Kunden vereinbart, beinhalten

2. Grundlagen 30

daher auch ein festes Budget. Die genaue Zeiterfassung ist primär auch nicht die Basis fürdie Rechnungserstellung, wie es beispielsweise bei Servicedienstleistern der Fall ist. Trotz-dem sollten im Rahmen des klassischen und agilen Projektmanagements geeignete Sys-teme zur Zeiterfassung etabliert werden, sei es für das Projektcontrolling, die Prüfung derWirtschaftlichkeit oder als Grundlage für Aufwandsschätzungen zukünftiger Projekte.

Exkurs Operations Research

Operations Research (OR) hat das Ziel, anhand der Analyse von komplexen Problemstel-lungen eines Planungsprozesses mit mathematischen Methoden, eine möglichst optima-le Entscheidung zu unterstützen. Hierbei werden reale Entscheidungsprobleme mit einemOptimierungs- oder Simulationsmodell abgebildet und durch die Anwendung bzw. Entwick-lung eines Algorithmus gelöst. Diese Aufgaben werden mit der Unterstützung von Softwaredurchgeführt. Die Planungsprozesse im OR lassen sich in die folgenden sechs Phasen ein-teilen [Domschke und Drexl, 2005]:

• Erkennen und Analysieren eines Problems (bzw. Entscheidungs- und Handlungsmög-lichkeiten)

• Bestimmen von Zielen und Handlungsmöglichkeiten (Erstellung eines deskriptiven Mo-dells)

• Mathematisches Modell (auf Grundlage des deskriptiven Modells)

• Datenbeschaffung (liefert Daten für das Modell)

• Lösungsfindung (algorithmische Lösung des mathematischen Modells)

• Bewertung der Lösung (Analyse der erhaltenen Lösung)

Die Modellbildung spielt im OR eine wichtige Rolle. Dabei hängt der Schwierigkeitsgrad derLösbarkeit von Modellen im Wesentlichen von deren Konstruktion ab. Es wird daher eine ef-fiziente Modellierung angestrebt. Die Entscheidungs- oder Planungsprobleme werden durchgeeignete Entscheidung- bzw. Optimierungsmodelle dargestellt. Ziel dieser Modelle ist dieEntwicklung optimaler oder suboptimaler Lösungsvorschläge. Komplexe Optimierungsmo-delle, für die keine analytischen Verfahren zur Problemlösung existieren, werden mit Hil-fe von Simulationsmodellen abgebildet. Damit lassen sich einzelne Alternativen und derenKonsequenzen durchspielen und anschließend analysieren. Die Anwendung des OperationsResearch auf die zugrunde liegenden Optimierungsmodelle unterteilt sich in verschiedeneTeilgebiete: die lineare, kombinatorische, dynamische und nichtlineare Optimierung.

Die Graphentheorie und Netzplantechnik werden zur graphischen Darstellung von Organi-sationsstrukturen oder Projektabläufen häufig in der Praxis verwendet. In diesen Modellen

2. Grundlagen 31

werden Verfahren angewendet, um kürzeste sowie maximale Wege innerhalb der Graphenzu bestimmen. Ein Netzplan besteht aus Vorgängen und Ereignissen, die in definierten Be-ziehungen zueinander stehen. Diese Vorgänger-Nachfolger-Beziehungen beschreiben dieAblaufstruktur des Projekts. In der Strukturplanung werden gegebenenfalls schon die Dauersowie die Mindest- und/oder Maximalabstände der einzelnen Elemente des Netzplans be-rücksichtigt. Diese werden als Eingangsgrößen für die konkrete Zeit- und Terminplanung ver-wendet, in der alle Projektvorgänge bzw. Ereignisse terminiert werden. Desweiteren werdendie Methoden der Netzplantechnik in deterministische und stochastische Vorgehensweisenunterteilt. Bei den deterministischen Methoden ist jeder Vorgang auszuführen und die Dauerbzw. Abstände zwischen ihnen werden als bekannt vorausgesetzt. Dazu zählen Verfahrenwie Critical Path Method (CPM) und Metra-Potenzial-Methode (MPM). Bei stochastischenMethoden hingegen ist die Dauer und/oder die Ausführung eines Vorgangs mit einer gewis-sen Wahrscheinlichkeit behaftet. Zur dieser Gruppe gehören Verfahren wie Program Evalua-tion and Review Technique (PERT) und Graphical Evaluation and Review Technique (GERT).Die stochastischen Methoden erfordern vergleichsweise umfangreiche mathematische Ana-lysen, deshalb werden in der Praxis überwiegend deterministische Methoden eingesetzt.

Die Optimierung durch OR wird hauptsächlich in der Planungsphase des klassischen Pro-jektmanagements eingesetzt. Die gesamte Projektdurchführung wird bereits zu Beginn desProjekts in der Planungsphase anhand der bekannten Rahmenbedingungen detailliert ge-plant. Mit dem Einsatz von OR wird der erstellte Netzplan effizienter gestaltet, um beispiels-weise unabhängige Vorgänge zu parallelisieren und damit eine kürzere gesamt Projektdauerzu erreichen. Während „Optimierung“ besagt, dass man schon genau weiß, wie man etwaszu tun hat, dies aber verbessert werden soll, geht es bei der Innovation gerade erst darumherauszufinden, wie man etwas tut. Im Rahmen der innovativen Entwicklung mit agilen Ma-nagementmethoden existieren viele unbekannte Anforderungen, die sich erst im Verlauf desProjekts konkretisieren, daher ist es nicht förderlich mit dieser Ungewissheit genaue Plänezu erstellen und anschließend zu optimieren. Die erstellten Pläne würden aufgrund unvor-hersehbarer Veränderungen zu schnell an Aktualität verlieren und einen zu hohen Pflege-aufwand verursachen.

2.2.3. Fazit

Dieser Abschnitt hat die Ansätze des klassischen und agilen Projektmanagements umrissen.Beide verfolgen verschiedene Methoden und Vorgehensweisen, deren Auswahl vom Projektund der Organisation des Unternehmens abhängt.

Das traditionelle Projektmanagement basiert auf den Prozessen der Planung und Kontrolle.In aufeinander aufbauenden Schritten erfolgt die Bestimmung der Organisationsform, danndie detaillierte Planung und abschließend die Ausführung sowie Steuerung des Projekts.

2. Grundlagen 32

Zu Beginn besteht ein großer Planungsaufwand, da das Projekt über die Strukturplanungbis zum terminierten Ablauf einzelner Arbeitsschritte in Plänen definiert wird. Die genaueund ausführliche Planung wird dabei mit Methoden aus dem Operations Research wie derNetzplantechnik unterstützt. In der Umsetzung gilt es, durch einen kontinuierlichen Soll-/IstVergleich des Projektcontrollings das Projekt auf dem geplanten Kurs zu halten.

Agiles Projektmanagement hingegen ist auf die eigentliche Umsetzung des Projekts aus-gerichtet. Das Projektmanagement unterstützt hierbei primär den Prozess der Entwicklungund führt das Projektteam von der Vision zum echten Produkt. Das gesamte Vorhaben istergebnisorientiert und konzentriert sich dabei auf die wesentlichen Aktivitäten, welche einehöhere Wertschöpfung für den Kunden liefern. Dazu zählen auch Planungs- und Kontrollak-tivitäten, sie sind aber nicht der Schwerpunkt im agilen Projektmanagement. In der agilenProduktentwicklung geht es darum, sich auf Innovation und Anpassungsfähigkeit anstatt aufEffizienz und Optimierung zu konzentrieren. Gerade zu Beginn des Projekts ist es schwie-rig geeignete Pläne zu erstellen, da zu diesem Zeitpunkt noch am wenigsten Informationenüber das Projekt verfügbar sind und damit Grundlagen für wichtige Entscheidungen fehlen.Im agilen Ansatz der iterativen und inkrementellen Entwicklung in zeitlich begrenzten Pha-sen gilt es, die Veränderung zu akzeptieren und geeignet in den Prozess aufzunehmen. DieZiele einer Iteration und mögliche Plankorrekturen werden dabei im Zusammenwirken vonProjektkoordination und Projektteam erarbeitet.

Beide Ansätze des Projektmanagements haben ihre Vor- und Nachteile und müssen daheranhand der aktuellen Gegebenheiten ausgewählt werden. Ein kombinierter Einsatz von klas-sischen und agilen Managementmethoden zum Ausgleich der Risiken ist ebenfalls möglich.Auf Grundlage der Risikobewertung beschreibt beispielsweise das Buch „Balancing Agilityand Discipline: A Guide for the Perplexed“ [Boehm und Turner, 2003] einen Ansatz, der dieVorteile beider Vorgehensweisen nutzt.

Desweiteren lässt sich festhalten, dass der Aufwand für die Zeitplanung und Koordinationvon Projektaufgaben aus Sicht der Projektmitarbeiter in klassischen Projekten niedriger istals in agilen Projekten. Während der klassische Ansatz durch Mikromamangement und Per-sonaleinsatzplanung genaue Vorgaben macht, liegen in agilen Projekten diese Planungsak-tivitäten in der Eigenverantwortung des Projektteams. Im folgenden Abschnitt soll daher dieZeitplanung von Mitarbeitern in dieser Situation genauer betrachtet werden.

2.3. Zeitplanung der Mitarbeiter

Wie in Abschnitt 2.1 erläutert wurde, befinden sich Mitarbeiter oft zeitgleich in unterschiedli-chen Projekten. Die individuelle Zeitplanung liegt in der Verantwortung der einzelnen Mitar-beiter. Dabei müssen sie die projektübergreifende Koordination der Projektaufgaben sowie

2. Grundlagen 33

die Vereinbarung mit den Tätigkeiten aus dem Tagesgeschäft (z.B. Email-Korrespondenz,Besprechungen) selbst vornehmen. Die Rahmenbedingungen für die Planung gehen dabeiaus den vereinbarten Iterationszielen sowie dem Terminkalender des Mitarbeiters hervor.Jeder Mitarbeiter muss dann für sich selbst eine Einteilung seiner täglichen Arbeitszeit vor-nehmen, um den gegebenen zeitlichen Bedingung zu entsprechen. Während dies für einProjekt noch recht übersichtlich erscheint, nimmt die Komplexität der Zeitplanung mit mehre-ren Projekten und den daraus resultierenden Projektaufgaben zu. In der Praxis ist es üblich,dass ein Mitarbeiter in verschiedenen Projekten arbeitet. Die Angaben werden dabei oft inProzentsätzen ausgedrückt. Beispielsweise ist ein Mitarbeiter einer Fachabteilung für 30%Projekt A und für 70% Projekt B zugeteilt. Um hier einen Überblick zu halten, werden vonden Mitarbeitern Terminkalender und Aufgabenlisten (engl. todo list, task list) geführt.

2.3.1. Terminkalender

Ein Terminkalender dient der Planung von Ereignissen und Vorgängen. Es ist ein einfachesWerkzeug, um Termine zu koordinieren, festzuhalten und an sie erinnert zu werden. Der Ka-lender bietet einen zeitlichen Rahmen zur Planung von Aktivitäten zu einem Termin. Die Er-eignisse in einem Kalender werden dabei mit einem fixen Start- und Endtermin angegeben.Die Lösung von Terminkonflikten lässt sich mit einem Kalender einfach und übersichtlichvornehmen. Die entsprechenden Planungseinträge werden auf einen freien Zeitraum ver-schoben oder ersetzt. Der Einsatz eines Terminkalenders dient sowohl der geschäftlichenals auch der persönlichen Zeitplanung.

Heutzutage werden in den meisten Unternehmen softwarebasierte Terminkalender einge-setzt. Damit wird der Kalender um zusätzliche Funktionalitäten erweitert, wie zum Beispieldie Terminerinnerungsfunktion und die Planung von Serienterminen. Zudem können Be-sprechungstermine unternehmensweit mit ausgewählten Mitarbeitern elektronisch kommuni-ziert werden. Die Veröffentlichung der Kalender ermöglicht im Vorwege eine Übersicht freierZeitressourcen für die Abstimmung von Besprechungsterminen.

Man könnte Terminkalender auch für die Planung von Aufgaben und Terminen aus Projek-ten nutzen. Diese werden dann außer im Projektplan auch in den Kalendern der involviertenMitarbeiter geführt. Anhand der Verantwortlichkeiten können die Aufgaben explizit in die Ter-minkalender der Mitarbeiter eingetragen werden, und der einzelne Mitarbeiter erhält dabeieinen individuellen Überblick seiner Termine und Projektaktivitäten. Problematisch ist hierjedoch die Distribution von aktualisierten Projektplänen, welche über eine manuelle Pflegedurch den Mitarbeiter aufwändig und fehleranfällig ist.

2. Grundlagen 34

2.3.2. Aufgabenlisten

Aufgabenlisten werden zur Erfassung und Verwaltung von Aufgaben verwendet. Neben derDokumentation ist das Ziel von Aufgabenlisten die Überwachung und Erinnerung an nochnicht erledigte Aufgaben. Sie sind typischerweise tabellarisch aufgebaut und jede Aufgabewird durch weitere Eigenschaften genauer beschrieben, wie beispielsweise Priorität, Zustän-digkeit oder Termin. Aufgabenlisten werden in der Praxis z.B. zum Selbst-Management ein-zelner Personen, im Projektmanagement oder auch in der Softwareentwicklung eingesetzt.Die Verwaltung und Pflege von diesen Listen kann prinzipiell sowohl von Einzelpersonenals auch durch Teams erfolgen. Die Verwendung einer Aufgabenliste zur Verwaltung derzugeteilten Projektaufgaben bietet dem Mitarbeiter die Möglichkeit, einen Überblick seineraktuellen Aktivitäten zu bekommen. Mit einer Aufgabenliste lassen sich die Aufgaben ausmehreren Projekten zusammengefasst darstellen. Eine Übersicht der individuellen Arbeits-last eines Mitarbeiters lässt sich aufgrund der tabellarischen Darstellungsform nicht genauerkennen.

2.3.3. Fazit

Leider mangelt es der Aufgabenliste an der Darstellung der zeitlichen Zusammenhänge,leicht werden hier zeitliche Engpässe übersehen oder erst zu spät erkannt. Die Folgen kön-nen Terminüberschreitungen von kritischen Vorgängen sein, die das gesamte Projekt verzö-gern. Die Planung der Projektaufgaben in einem Terminkalender stellt zwar einen zeitlichenBezug her, doch gestaltet sich dies als sehr aufwändig, sobald Veränderungen auftretenoder Prioritäten geändert werden. Sie ist damit in der Praxis nicht durchführbar. Es wird einPlanwerkzeug benötigt, welches die Vorteile beider Werkzeuge in sich vereint.

2.4. Überblick der Technologien

Dieser Abschnitt gibt einen Überblick über aktuell verfügbare Softwarelösungen zur Un-terstützung der Planungsaktivitäten in Projekten. Betrachtet werden Terminkalender,Projektmanagement-, Zeiterfassungs- und Ticketing-Systeme. Im Hinblick auf den Einsatz-bereich in klassischen oder agilen Projekten ergeben sich unterschiedliche Anforderungenan die eingesetzten Systeme. Zunächst werden verschiedene Softwarelösungen aufgezeigt.Anschließend wird die Anwendbarkeit der Zeitplanung für den einzelnen Projektmitarbeiterspeziell für das agile Projektmanagement geprüft.

2. Grundlagen 35

2.4.1. Terminkalender

Terminkalender sind heute meist eine Komponente innerhalb von Groupware und Softwarezum Personal Information Management (PIM). Diese Softwareprodukte helfen bei der Or-ganisation von persönlichen Informationen und Nachrichten, dazu gehören unter anderemEmails, Adressbücher, Kalender, Aufgabenlisten und Notizen.

Microsoft Outlook [www:Outlook] ist eine Groupware-Lösung, obwohl es häufig nur als EmailApplikation eingesetzt wird. In Verbindung mit dem Microsoft Exchange Server bildet dasSystem eine Kommunikationsstruktur für viele Unternehmen weltweit. Eine aktuelle Stu-die der Radicati Group beziffert für 2005 den Marktanteil von Microsoft im Bereich derKommunikations-Software auf 57% [Radicati, 2005]. Stellvertretend für eine Vielzahl vonTerminkalendern wird Microsoft Outlook im folgenden Abschnitt betrachtet. Ein Vergleich mitden Anforderungen des Zeitplanungssystems soll den Funktionsumfang von Outlook genau-er aufzeigen.

Die Kalender-Komponente von Microsoft Outlook bietet eine allgemeine Verwaltung von be-ruflichen und persönlichen Terminen, Besprechungen und Ereignissen. Die grundlegendeOrganisation der Planungseinträge kann an unterschiedliche zeitliche Aspekte gebundenwerden. Die Einträge z.B. Termine sind aber immer Aktivitäten mit festen Anfangs- und End-zeitpunkten. Mit Terminserien können Zeiten für sich wiederholende Aktivitäten innerhalb ei-ner Zeitspanne eingeplant und reserviert werden. Besprechungen können zudem innerhalbeiner Unternehmung unter Berücksichtigung der Zeitressourcen der involvierten Mitarbeiterkollaborativ geplant werden. Unabhängig von dem Terminkalender bietet Outlook eine Auf-gabenliste, in der individuelle Aufgaben eines Mitarbeiters verwaltet werden können. EineVerbindung zu den Planungseinträgen des Kalenders wird in der Aufgabenliste nicht herge-stellt.

Eine kollaborative Planung und Verwaltung von Projektaufgaben innerhalb von Outlook wirdnicht unterstützt. Die automatisierte Synchronisation von Projektaktivitäten über eine Schnitt-stelle zu der Projektmanagement Software Microsoft Project fehlt. Eine Synchronisation derbeiden Programme kann nur über zusätzliche Software realisiert werden. Die Integration die-ser Software ist mit weiteren Lizenz- und Schulungskosten verbunden. Das Produkt Allocatus[www:Allocatus] zum Beispiel ist eine Software, welche eine Synchronisation von MicrosoftProject und Outlook herstellt. Die Aufgaben und Meilensteine aus dem Microsoft ProjectProjektplan lassen sich damit direkt als Kalendereinträge in Outlook exportieren. Der Infor-mationsfluss erfolgt dabei nur in eine Richtung, Rückmeldungen aus Outlook heraus wer-den nicht unterstützt. Die Dokumentation des Fortschritts bearbeiteter Aufgaben beschränktsich damit auf die lokale Installation und wird nicht für das Projektteam bereitgestellt. DieSynchronisation der Projektaufgaben setzt neben Outlook ein lokal installiertes Programmvoraus, welches für die Installation und spätere Aktualisierungen aufwändig verteilt werdenmuss. Zudem besteht eine Plattformabhängigkeit, die Windows als Betriebssystem für die

2. Grundlagen 36

Klientenrechner voraussetzt. Ein Einsatz auf anderen Betriebssystemen oder auf mobilenGeräten ist nicht möglich.

2.4.2. Projektmanagement Software

Projektmanagement Software unterstützt die Prozesse innerhalb von Projekten. Die Softwa-re erleichtert das projektbezogene Informationsmanagement und bietet Werkzeuge für Pla-nung, Analyse und Darstellung der Projektdaten. Die Datenverwaltung von Personal, Res-sourcen und Betriebsmitteln bildet die Datenbasis. Die Erstellung von Projektplänen und de-ren Darstellung in Form von Netzplan- und Gantt-Diagrammen gehört unter anderem zu denAufgaben der Software. Visualisiert werden Fortschritt, Abhängigkeiten und Aufwände dereinzelnen Projektaktivitäten. Ein zeitlicher Zusammenhang wird hergestellt und bietet eineÜbersicht der Termine und Meilensteine. Die Software übernimmt die aufwändigen Berech-nungen der Pufferzeiten und des kritischen Pfads. Besonders komplexe Abhängigkeitsstruk-turen großer Projekte lassen sich einfach und effizient aktualisieren.

Der Markt bietet eine Vielzahl von Projektmanagement Softwarelösungen. Die Software soll-te daher in Abhängigkeit vom jeweiligen Einsatzgebiet ausgewählt werden. Während bei derDurchführung kleinerer Projekte eine Einzelplatzversion ausreicht, um die Projektdaten ma-nuell und lokal zu verwalten, werden große Projekte durch den Einsatz von integrierten Pro-jektmanagement Softwaresystemen unterstützt. Diese Systeme erweitern das Managementder Projekte um andere Komponenten wie z.B. Zeiterfassung und Dokumentenverwaltung.Schnittstellen zu den angebundenen Komponenten ermöglichen einen Datenaustausch imganzen System. Eine automatisierte Verarbeitung der Daten aktualisiert Projektpläne unddokumentiert den Fortschritt. Basierend auf einer Client/Server Architektur werden dieseSysteme im Intranet der Unternehmen betrieben. Diese Systeme unterstützen den Informa-tionsfluss in Projekten, um die aktuellen Projektdaten der Projektleitung, dem Projektteamund den Interessenvertretern unternehmensweit bereitzustellen.

Microsoft Project

Microsoft Project [www:Project] ist eine kommerzielle Software für Projektmanagement. DieSoftware unterstützt Tätigkeiten im Projektmanagement wie die Erstellung von Projektplä-nen, Erfassung des Fortschritts, Verwaltung von Ressourcen und der Budgetplanung. DieSoftware ist als Einzelplatzversion und auch als Netzwerkversion zu erwerben. MicrosoftProject wurde mit dem Microsoft Office Project Server erweitert, welcher eine zentrale Da-tenbank für die Speicherung und Verwaltung von Projekten bereitstellt. Die Microsoft ProjectWeb Access Komponente ermöglicht einen dezentralen Zugriff auf die Daten des Office Pro-ject Servers über einen Browser. Die autorisierten Anwender können über das Web-Portal

2. Grundlagen 37

unternehmensweit die Dokumente und Informationen von allen Projekten abrufen, analy-sieren und aktualisieren. Eine Integration von Microsoft Project mit anderen Produkten vonDrittanbietern ist generell möglich, erfordert aber den Einsatz weiterer Software, die eineSynchronisation der Projektdaten bereitstellt.

NetOffice

NetOffice [www:NetOffice] ist eine Open-Source Software für integriertes Projektmanage-ment. Die Applikation ist web-basiert und bietet eine Plattform für kollaborative Projektar-beiten. NetOffice wurde in der Programmiersprache PHP entwickelt und verwaltet die Da-tenbasis in einer MySQL Datenbank. Eine Veröffentlichung der Applikation ist im Intranet,Extranet und Internet möglich. Die enthaltene Benutzerverwaltung gewährleistet die eindeu-tige Authentifizierung der Anwender. NetOffice weist jedem Benutzer eine definierte Rollezu, so können auch gewünschte Informationen an externe Kunden bereitgestellt werden.Neben den Funktionen für das Projektmanagement unterstützt die Applikation die Kollabo-ration innerhalb eines Projekts. An Projekte können Diskussionen angefügt werden, welcheunter Beteiligung der Projektmitarbeiter geführt werden. Im Gegensatz zu der Kommunika-tion über Email bleibt die Diskussion im Projektkontext und alle Beteiligten verfügen zudemüber denselben Stand. Das integrierte leichtgewichtige CRM-System übernimmt die Verwal-tung der Supportanfragen eines Projekts.

SAP Projektsystem

Das SAP Projektsystem [www:SAP] ist ein Modul innerhalb des Enterprise Ressource Plan-ning Systems der SAP AG. Die Komponente bietet umfassende Unterstützung bei der Pla-nung, Durchführung und Steuerung von Projekten. Die Integration des Projektsystems inSAP R/3 ermöglicht einen wechselseitigen Informationszugriff im gesamten System mit einereinheitlichen Datenbasis. Aufgrund der Verknüpfung mit den anderen System-Komponenten,ist ein unabhängiger Einsatz der Projektmanagement Software ohne das ERP-System R/3nicht möglich. Für Unternehmen, die nicht bereits über ein SAP R/3-System verfügen, be-deutet dies eine Anpassung der gesamten IT an die Systemlösung von SAP.

Fazit

Die zentrale Projektmanagement Software ist ein Werkzeug für die klassische Projektpla-nung. Diese Systeme sind darauf ausgelegt die Planungs- und Kontrollprozesse des klas-sischen Projektmanagements zu unterstützen. Sie bieten gezielt Lösungen an, um die Dar-stellung und Verwaltung der Projektdaten effizienter zu gestalten.

2. Grundlagen 38

Der zeitliche Rahmen wird von dem Umfang des Projekts vorgegeben. Die Dauer kann dabeieinige Monate oder teilweise auch Jahre betragen. Die Planungen im Projektmanagementsind eher taktisch und haben große Bedeutung für den Verlauf des gesamten Projekts. DiePlanung der Projektaufgaben auf Grundlage der Netzplantechnik bildet eine Kernfunktiona-lität der vorgestellten Programme. Es erlaubt der Projektleitung, die Aufgaben in komplexenProjektabläufen auch in großen Zeitspannen anzuordnen und zu optimieren. Die Dokumen-tation des Projekts ist eine zentrale Aufgabe im klassischen Projektmanagement und einwichtiges Mittel der Kommunikation. Hierbei geht es um die Planung und Distribution vonProjektplänen, beispielsweise in Form eines Personaleinsatzplans.

Im agilen Projektmanagement ist die genaue Planung und Dokumentation des gesamtenProjekts nicht so ausgeprägt. Aufgrund unterstellter unvorhersehbarer Veränderungen derAnforderungen im Projektverlauf wäre die Gültigkeit der erstellten Dokumente nur kurz. DiePlanungsaktivitäten der Projektleitung konzentrieren sich auf die Erstellung des bereits ge-nannten Project Data Sheet und des Iterationsplans. Die Planung mehrerer Iterationen ori-entiert sich an festgelegten Projektzielen, ohne dabei eine detailliert Aufgabenplanung vor-zunehmen. Die Planung und Koordination der einzelnen Projektaufgaben einer bevorstehen-den Iteration verlagert sich auf das Projektteam.

2.4.3. Zeiterfassungssysteme

Zeiterfassungssysteme werden verwendet, um gezielt die tatsächlichen Aufwände und Kos-ten von Projektaufgaben zu erfassen. Die ermittelten Zeiten zeigen die aktuelle Projektent-wicklung und bilden für das Projektcontrolling eine wichtige Grundlage zur Steuerung desProjektverlaufs. Zeiterfassungssysteme gibt es als einzelne Softwarelösung oder als inte-grierte Komponente einer Projektmanagement Applikation. Um einen Überblick des Soll-/Ist-Aufwands zu bekommen, werden die erfassten Zeiten mit den Vorgaben aus der Projektpla-nung verglichen. Dazu werden die Zeiten von dem Zeiterfassungssystem über Schnittstel-len bereitgestellt oder innerhalb einer Anwendung für alle Komponenten verfügbar gemacht.Stellvertretend für Zeiterfassungssysteme soll im folgenden Absatz die integrierte Zeiterfass-ung der A-Plan Projektmanagementsoftware [www:Braintool] betrachtet werden.

Das Zeiterfassungsmodul der A-Plan Projektmanagementsoftware stellt eine Erweiterungbereit, mit der Mitarbeiter ihre angefallenen Aufwände für die Projektaufgaben erfassen kön-nen. Durch die Angabe von Zeitintervallen werden die einzelnen Einträge in der Zeiterfass-ung aufgenommen. Die Diagramme und Darstellungen der Projektpläne werden mit denDaten aus der Zeiterfassung ebenfalls aktualisiert. Der Export und Austausch erfasster Zei-ten als Report erfolgt im Standardformat gängiger Tabellenkalkulationsanwendungen. DieseReports liefern Informationen über den Soll-/Ist-Aufwand der Projektaktivitäten und die damitverbundenen Kosten innerhalb eines gewählten Zeitraums.

2. Grundlagen 39

2.4.4. Ticketing Systeme

Die Kommunikation innerhalb von Projekten und bei dem Betrieb von Servicestellen pro-duziert täglich eine Menge Informationen. Oftmals ist es schwierig, dabei den Überblick zubehalten, und eine eingehende Nachricht sofort in den richtigen Kontext einzuordnen. DieEinführung von Ticketing Systemen sorgt hier dafür, dass alle Anfragen aufgenommen, ka-nalisiert und deren Abarbeitung überwacht wird.

Ticketing Systeme unterstützen das Informationsmanagement dieser Prozesse. Die Korres-pondenz einzelner Aufgaben, wie einer Support-Anfrage oder der Aktivität eines Teilprojekts,können hiermit systematisch erfasst und bearbeitet werden. Aufgaben können effizient untermehreren Mitarbeitern aufgeteilt und die damit verbundene Kommunikation sinnvoll erfasstwerden. Der Einsatz von Ticketing Systemen eignet sich für verschiedene Bereiche z.B.:

• Support- und Servicestellen

• Softwareentwicklung (Bugtracking)

• Projektentwicklung (Interne Dokumentation)

• Geschäftsprozesse

Ticketing Systeme werden in Support- und Servicestellen verwendet, um den Kunden nachdem Erwerb eines Produktes oder einer Dienstleistung weiterhin zu unterstützen. Diese Sys-teme sind organisatorische Mittel zur Abwicklung von Kundenanfragen im Bereich der AfterSales Aktivitäten. Die Serviceanforderungen werden zuvor mit dem Kunden vereinbart undals Service-Level-Agreements dokumentiert. Ein Vertrag enthält alle Rechte und Pflichtendes Unternehmens, die in Form von Support-Dienstleistungen erbracht werden müssen.Eingesetzt werden Ticketing Systeme meist in den Call Centern der Unternehmen, welchedie Anfragen der Kunden telefonisch und per Email entgegennehmen. Die aufgenomme-nen Tickets werden zentral verwaltet und den einzelnen Kundenbetreuern zugewiesen. DieTicketing Systeme helfen, den Informationsfluss zum Kunden im Prozess der Problemlösungaufrecht zu erhalten und ihn bei allen Statusänderungen der Tickets unmittelbar zu informie-ren.

Als weitere Variante von Ticketing Systemen werden Bugtracker in der Softwareentwicklungeingesetzt. Mit ihnen werden die Informationen zu Programmfehlern, Funktionswünschenund Supportanfragen im gesamten Software Life Cycle erfasst, aufgezeichnet und aufberei-tet. Ein rollenbasierter Zugriff auf ein Bugtracking System erfolgt von der Projektleitung, denEntwicklern und dem Kunden. Das System bildet hiermit eine zentrale Schnittstelle für dieKommunikation und das Informationsmanagement in der Softwareentwicklung. Außerdem

2. Grundlagen 40

lassen sich spezifische Workflows erstellen, die eine automatisierte Verarbeitung der Pro-grammfehler ermöglichen. Ansonsten würden eventuell aufgetretene Programmfehler verlo-ren gehen oder nicht ausreichend priorisiert werden. Die erstellte Datenbasis liefert genaueAussagen über die behobenen Fehler und Fehlerzeiten sowie die damit verbundene Korres-pondenz. Zusammen mit Versionsverwaltungssystemen bildet Bugtracking einen wichtigenTeil des Konfigurationsmanagements in der Softwareentwicklung.

Die eingesetzte Ticketing Software unterstützt das Informationsmanagement und verwaltetdie Tickets, Prioritäten, Verantwortlichkeiten und die Kontakthistorie der Kommunikation mitdem Kunden. Außerdem bieten die Systeme eine ständige Überwachung und Prüfung allerTickets, somit können vorhandene Tickets gegebenenfalls eskaliert werden. Die Resultateder Monitoring-Prozesse dienen als Grundlage, um die Arbeitsprozesse noch effektiver zugestalten.

Die Ticketing Systeme sind in ihrer Anwendung meist sehr speziell und an das entsprechen-de Einsatzgebiet angepasst. Die Systeme sind ausgelegt, um die für die Bearbeitung desTickets relevanten Informationen strukturiert zu erfassen. Der Einsatz eines Ticketing Sys-tems in der Form eines Bugtrackers eignet sich damit nur für die Softwareentwicklung undnicht für ein anderes Anwendungsgebiet. Der zeitliche Ablauf bei der Bearbeitung der Ticketsund die damit verbundenen Aktivitäten sind ebenfalls vom Umfeld abhängig. Während bei derSoftwareentwicklung die Erfüllung bestimmter Tickets über die Versionsnummern der Soft-ware definiert wird, erfolgt die Bearbeitung der Tickets in Servicestellen meist zeitnah und inAbhängigkeit der Priorität.

2.4.5. Fazit

Die hier vorgestellten Softwarelösungen zur Zeitplanung und Zeiterfassung im Rahmen desProjektmanagements sind auf unterschiedliche Einsatzgebiete ausgerichtet. Unterstützungbieten die Systeme vor allem bei der Dokumentation und dem Informationsmanagement inProjekten.

Der Terminkalender ist ein typisches Werkzeug zur Planung von Aktivitäten eines Mitarbei-ters. Der Kalender ermöglicht dem Mitarbeiter, einen zeitlichen Zusammenhang zwischenden Tätigkeiten des Tagesgeschäfts, Terminen und projektübergreifenden Aktivitäten herzu-stellen. Der Terminkalender ist universell und kann für die Zeitplanung von allen Mitarbeiterneingesetzt werden. Die softwarebasierten Kalender gehören ebenfalls zur Standardsoftwa-re in Unternehmen, und viele Mitarbeiter haben bereits Erfahrungen im Umgang mit diesenProgrammen gemacht. Leider gestaltet sich die Pflege der aufeinanderfolgenden Projektvor-gänge im Terminkalender als zu aufwändig, wenn es zu Veränderungen in der Projektpla-nung kommt. Der Einsatz einer Software zur Synchronisation der Projektaufgaben mit derProjektmanagent Software löst dieses Problem nur teilweise, da der Informationsfluss von

2. Grundlagen 41

der Projektplanung nur in Richtung der Projektmitarbeiter erfolgt. Die Erfassung von Auf-wand und Fortschritt ist auf das lokale Programm beschränkt und wird der Projektleitungnicht unmittelbar bereitgestellt. Der Report des aktuellen Projektfortschritts ist also mit ei-nem Mehraufwand verbunden. Die Planung der Projektaufgaben mit einem Terminkalendergestaltet sich aufgrund häufiger Veränderungen als zu unflexibel und zeitaufwändig.

In agilen Projekten helfen Terminkalender und Aufgabenlisten bei der Zeitplanung der ein-zelnen Mitarbeiter. Bei der Projektarbeit in kleinen Teams erfolgt die Koordinationen der Auf-gaben hauptsächlich über die direkte Kommunikation mit dem verantwortlichen Mitarbeiterund richtet sich dabei nach den agilen Werten. In selbstorganisierten Projektteams ist eswichtig, dass die Mitarbeiter ihre eigene Arbeitsbelastung (engl. workload) einschätzen kön-nen. Besonders zu Beginn einer Iteration müssen die Projektmitarbeiter zusammen mit derProjektleitung anhand ihrer aktuellen Arbeitslast realistische Iterationsziele vereinbaren. DasWorkload-Management der Mitarbeiter mit Aufgabenlisten, ist gerade bei zeitlich parallelenProjekten schwierig.

Um die Projektabläufe planen, korrigieren und kontrollieren zu können, wird in vielen Un-ternehmen Projektmanagement Software eingesetzt. Diese Software unterstützt die Doku-mentation und Informationsverwaltung bei der Planung und Umsetzung von Projekten. Zu-dem verringert Projektmanagement Software den Planungs- und Dokumentationsaufwand,wie beispielsweise bei der sonst rechenintensiven Planung mit Hilfe von Netzplänen oderBalkendiagrammen. Die Projektplanung ist eine Hauptaufgabe der Projektleitung und ver-langen daher fundiertes Wissen über die eingesetzten Plantechniken, wie beispielsweise dieNetzplantechnik. Die eingesetzten Softwaresysteme haben ganz in Abhängigkeit von ihremEinsatzgebiet unterschiedliche Anforderungen zu erfüllen. Es existieren daher Softwarepro-dukte von der Einzelplatz-Applikation bis hin zur integrierten Systemlösungen, welche andie Geschäftsabläufe der Unternehmen angepasst werden. Einige Projektmanagement Soft-waresysteme bieten Möglichkeiten zur Erweiterung der Funktionalität durch Anbindung vonKomponenten wie z.B. einer Zeiterfassung. Die Zeit- und Aufwandserfassung in Projektenliefert wichtige Informationen für das Projektcontrolling. Nur mit einem Zugriff auf die aktuel-len Ist-Daten können die Entscheidungsträger der Projektleitung die Projektabläufe bewertenund steuern. Die Zeiterfassung ist oft eine Komponente innerhalb von ProjektmanagementSystemen. Der direkte Datenaustausch zwischen den einzelnen Systemkomponenten ver-bessert den Informationsfluss und reduziert einen Mehraufwand bei der Datenpflege.

Das agile Projektmanagement zielt darauf, mit einem schlanken Entwicklungsprozess demKunden möglichst schnell eine Wertschöpfung zu liefern. Die Aktivitäten der Planung undDokumentation des Projekts reduzieren sich dabei auf den gerade notwendigen Umfang. MitStandardsoftware wie Textverarbeitungs- und Tabellenkalkulationsprogrammen kann daherdie zweckmäßige Dokumentation beispielsweise in Form eines Iterationsplans oder ProjectData Sheets erfolgen. Das bedeutet nicht, dass Projektmanagement Software z.B. zur Er-stellung von Balkendiagrammen in agilen Projekten generell nicht eingesetzt wird, sondern

2. Grundlagen 42

es ist von den projektspezifischen Eigenschaften abhängt. Bei kleinen Projektteams erübrigtsich der Einsatz umfassender Projektmanagement Software, da die Planungsaktivitäten inagilen Projekten einen anderen Schwerpunkt setzen.

Ticketing Systeme stellen in Abhängigkeit des Einsatzgebiets eine Methode dar, um Aufga-ben organisiert abarbeiten zu können. Die Systeme versuchen die erfassten Aufgaben undderen Verlauf der Bearbeitung möglichst in der Gesamtheit zu dokumentieren. So könneneinzelne Aufgaben an unterschiedliche Mitarbeiter verteilt werden, ohne dass die Übergabeaufwändig kommuniziert werden muss. Diese Art Aufgabenliste wird zur Koordination inner-und außerhalb eines Projektkontextes verwendet. Der zeitliche Zusammenhang verschiede-ner Aufgaben ist mit den Ticketing Systemen nur schwer zu überblicken. Die Priorisierungder Aufgaben ist auch weniger durch Termine bestimmt, sondern orientiert sich zweckmäßigan anderen Parametern. Neben den Funktionalitäten des Informationsmanagements liefernTicketing Systeme eine erweiterte Form einer Aufgabenliste. Als mögliche Unterstützung fürdie Zeitplanung der Mitarbeit in agilen Projekten, fehlt die Darstellung zeitlicher Zusammen-hänge.

Die betrachteten Softwarelösungen zur Zeitplanung und Zeiterfassung im Rahmen des Pro-jektmanagements sind an die klassischen Managementmethoden angepasst. Aufgrund derunterschiedlichen Vorgehensweise bei der Planung und Durchführung von klassischen undagilen Projekten (Abschnitt 2.2) liefern diese Werkzeuge im Rahmen der Zeitplanung in agi-len Projektabläufen keine hinreichende Unterstützung.

2.5. Zusammenfassung

Das agile Projektmanagement passt vor allem zur innovativen Produktentwicklung in kleinenProjektteams. Die Etablierung eines leichtgewichtigen und iterativen Entwicklungsprozessesunterstützt die Planung und Durchführung von Projekten mit hohem Innovationsgrad undunvorhersehbaren Veränderungen der Anforderungen. Agiles Projektmanagement verlangtdabei aber ein funktionierendes Projektteam, das sich durch ein hohes Maß an Eigenverant-wortung, Selbstorganisation und Selbstdisziplin auszeichnet. Die Projektplanung unterteiltsich in zwei Ebenen, der weitgehenden groben Iterationsplanung des gesamten Projektsund der genauen Planung einer bevorstehenden Iteration. Während die Projektleitung dengesamten Projektablauf koordiniert, ist das Projektteam für die Koordination der Projektauf-gaben vereinbarter Ziele einer Iteration zuständig. Die Projektmitarbeiter müssen dabei ihreindividuelle Zeitplanung selbst vornehmen.

Die betrachteten Softwaresysteme für die Zeitplanung in Projekten liefern nur Werkzeugefür das klassische Projektmanagement. Die Systeme bieten umfangreiche Werkzeuge zurErstellung, Verwaltung und Optimierung detaillierter Pläne des gesamten Projekts z.B. auf

2. Grundlagen 43

Basis der Netzplantechnik. Vor dem Hintergrund der Zeitplanung der Mitarbeiter in agilenProjekten liefern die betrachteten Planwerkzeuge keine ausreichende Unterstützung.

Für die Projektmitarbeiter in agilen Projekten müssen daher andere Anforderungen an einSystem zur Zeitplanung formuliert werden. Das Planwerkzeug sollte daher einfach, zweck-mäßig, verständlich und auch in heterogenen Projektteams einsetzbar sein. Zudem sollteder Pflegeaufwand auch bei veränderten Rahmenbedingungen möglichst gering sein. Diegeeignete Kombination eines persönlichen Kalenders und einer Aufgabenliste stellt hier eineLösung dar. Im folgenden Kapitel 3 werden die Anforderungen an ein Zeitplanungssystemfür die Projektmitarbeiter analysiert und festgelegt.

3. Anforderungsanalyse

Auf Basis der in Kapitel 2 herausgearbeiteten Rahmenbedingungen der Zeitplanung, folgthier die Analyse und die Definition der Anforderungen an das zu erstellende System. Zu-nächst werden die Ziele verschiedener Mitarbeiter aufgegriffen und zusammengefasst dar-gestellt. Danach werden die Systemanforderungen hinsichtlich der Unterstützung der Zeit-planung der Mitarbeiter erläutert. Es folgt die Darstellung und Klassifizierung der für die Pla-nung benötigten Ereignisse. Abschließend wird die Systemumgebung aufgezeigt und einzel-ne Vorgänge in Anwendungsfällen werden genauer beschrieben. Auf Grundlage der Anfor-derungsanalyse kann im darauf folgenden Kapitel 4 der Entwurf des Systems erfolgen.

3.1. Anwenderziele

Die Projektplanung ist eng mit der Arbeitszeitplanung verknüpft und beide Planungsebenenteilen sich gewisse Informationen. Von dem System werden Daten für die Projektmitarbei-ter, Projektleitung und Geschäftsführung bereitgestellt. Auf Grundlage der Interviews ausAbschnitt 2.1 wurden folgende Rollen und Ziele definiert:

Rolle Ziele

Projektmitarbeiter - persönliche Arbeitszeitplanung- Zeiterfassung der zugeteilten Projektaufgaben- Darstellung der aktuellen Auslastung

Projektleitung - übersichtliche Darstellung der Projektplanung- Bestimmung der Auslastung von Mitarbeitern(Kapazitätsplanung)- Darstellung der Ist-Werte von Projekten(Aufwand, Fortschritt, Kosten)

Geschäftsführung - wirtschaftliche Bewertung der Projekte- langfristige Projekt- und Personalplanung

Tabelle 3.1.: Rollen und Ziele der Anwender

3. Anforderungsanalyse 45

In der Praxis werden von Unternehmen viele verschiedene Softwaresysteme für das Infor-mationsmanagement in Projekten eingesetzt. Da die eingesetzten Informationssysteme vonUnternehmen zu Unternehmen und Projekt zu Projekt sehr unterschiedlich sein können,werden hier nur die Anforderungen an ein Zeitplanungssystem aus Sicht der Projektmitar-beiter betrachtet. Die von diesem System bereitgestellten Funktionalitäten sind allgemeingültig und auch unabhängig von einem konkreten Projekt einsetzbar. Die Erweiterung bzw.Anbindung des Zeitplanungssystems an vorhandene Softwaresysteme kann bei Bedarf überentsprechende Schnittstellen realisiert werden.

3.2. Einordnung des Systems

Für die Planungsaktivitäten im klassischen Projektmanagement existieren bereits eine Rei-he von Softwarelösungen. Angepasst auf das jeweilige Projekt können die Prozesse derPlanung, Überwachung und Steuerung durch den Einsatz von Projektmanagement Softwareeffektiver gestaltet werden. Im Gegensatz dazu stehen den Mitarbeitern in agilen Projek-ten bei ihrer Arbeitszeitplanung mit Terminkalender und Aufgabenlisten nur unzureichendePlanwerkzeuge zur Verfügung. Das Zeitplanungssystem versucht, für diese Planungsebeneeine bessere Unterstützung zu bieten. Ziel ist es dabei, die Zeitplanung möglichst flexibelund dynamisch zu gestalten. Neben der Zeitplanungskomponente werden zusätzlich Funk-tionen zur Zeit- und Fortschrittserfassung der Projektaktivitäten bereitgestellt. Die Mitarbeiterwerden gezielt bei ihren Planungs- und Verwaltungsaktivitäten unterstützt, um ihnen einenÜberblick ihrer individuellen Arbeitslast zu geben. Unter Berücksichtigung der Arbeitslastkann die Projektleitung zusammen mit dem Projektteam die termingerechte Fertigstellungder Projektziele besser koordinieren. (Abbildung 3.1)

Abbildung 3.1.: Einordnung des Systems

3. Anforderungsanalyse 46

3.3. Anforderungen

In diesem Abschnitt wird durch eine wiederholte Betrachtung der Problemstellung eine Listevon Anforderungen erstellt, die an ein Zeitplanungssystem gestellt werden.

Wie bereits in Kapitel 2 erläutert, existieren keine hinreichenden Planwerkzeuge für die Zeit-planung der Mitarbeiter. Die Planung mit einem Terminkalender stellte sich als unpraktikabelund zeitaufwändig heraus, wenn damit Projektaufgaben geplant werden müssen (Abschnitt2.3.1). Die Verwendung einer Aufgabenliste entfällt als Alternative, da an eine übersichtli-che Darstellung der zeitlichen Zusammenhänge fehlt. Die Zeitdauer einzelner Aufgaben wirdnicht geeignet veranschaulicht, so dass sich die aktuelle Arbeitslast eines Mitarbeiters damitnur schwer bestimmen lässt (Abschnitt 2.3.2). Die individuelle Zeitplanung auf Grundlageerstellter Projektpläne ist gerade bei der Einbeziehung in mehrere Projekte unübersichtlich.Hier müssen die einzelnen Projektaufgaben der verschiedenen Projektpläne entnommenund in eine eigene Zeitplanung übertragen werden.

3.3.1. Individuelle Zeitplanung

Ein geeignetes Planwerkzeug soll den Mitarbeitern bei ihrer individuellen Zeitplanung dienotwendige Unterstützung geben. Das System soll eine übersichtliche, zeitliche Darstellungvon Terminen und Projektaufgaben innerhalb eines Kalenders bereitstellen und zugleich eineeffiziente Datenpflege ermöglichen. Die Projektaufgaben können dabei durch einen entspre-chenden Planer automatisiert, zeitlich angeordnet und in einzelne Kalendereinträge umge-wandelt werden. Diese Berechnung des Zeitplans wird über das Zeitplanungssystem reali-siert. Eine aufwändige Planung der Projektaufgaben durch den Mitarbeiter von Hand ist da-mit nicht mehr nötig. Die Korrektur bestimmter Daten, wie der zeitliche Rahmen (Start- undEndtermin) oder die Änderung der Priorität einer Projektaufgabe, wird bei einer erneuten Be-rechnung berücksichtigt und im Zeitplan entsprechend angezeigt. Eine optimale Zeitplanung(siehe Abschnitt 3.4) ist hier nicht erforderlich. Es genügt, dem Mitarbeiter eine Übersicht sei-ner aktuellen Arbeitslast zu geben, um ein verbessertes Workload-Management zu ermögli-chen. Wichtig ist hier vor allem, dem Mitarbeiter eine einfache Verwaltung seiner geplantenAktivitäten zu bieten und ihn auf Konflikte in seiner Zeitplanung rechtzeitig hinzuweisen. DerMitarbeiter wird informiert, falls der zuvor geschätzte Soll-Aufwand einer Projektaufgabe be-reits durch den von ihm geleisteten Ist-Aufwand erschöpft ist. Außerdem wird der Mitarbeiterbenachrichtigt, wenn ein geplanter Abgabetermin einer Projektaufgabe nicht mehr eingehal-ten werden kann. Dieser Planungskonflikt entsteht z.B. sobald der aktuelle Soll-Aufwand indie verbleibende Zeitspanne bis zum Abgabetermin nicht mehr vollständig eingeplant wer-den kann oder wenn dem Mitarbeiter ein Termin bzw. ein zusätzliches Arbeitspaket höhe-rer Priorität zugewiesen wird. Das Zeitplanungssystem warnt den Mitarbeiter frühzeitig vor

3. Anforderungsanalyse 47

zeitlichen Engpässen und bietet ihm damit die Möglichkeit rechtzeitig zu reagieren, um dietermingerechte Umsetzung der Projektaufgaben nicht zu gefährden.

Abbildung 3.2.: Individuelle Zeitplanung mit dem System (reduzierte Darstellung)

3.3.2. Zeiterfassung

Neben der Zeitplanung soll der Aufwand der geplanten Aufgaben auch zeitnah erfasst wer-den. Der bereits benötigte Aufwand wird dem System bereitgestellt und liefert wertvolle In-formationen über den Fortschritt einzelner Projektaufgaben. Diese Daten fließen dabei direktwieder in die Zeitplanung der Ereignisse ein, um die bereits verstrichene Zeit zu berücksich-tigen. Ein Vergleich des Soll-/Ist-Aufwands liefert dem Mitarbeiter eine bessere Einschät-zung seiner eigenen Leistung und hilft ihm für zukünftige Arbeitsaufträge eine verbesserteAufwandsschätzung abzugeben. Desweiteren werden mit der Zeiterfassung detaillierte Wer-te protokolliert, welche die wirtschaftliche Bewertung von ganzen oder auch ausgewähltenProjektteilen in einem wählbaren Zeitraum z.B. einer Iteration ermöglichen. Dieses lässt sichauch auf die Ermittlung von Kosten und die Analyse der Produktivität der Mitarbeiter über-tragen.

3. Anforderungsanalyse 48

Die erfassten Zeiten bilden zusätzlich eine unternehmensspezifische Datenbasis, in welcherder tatsächliche Aufwand von Projektaufgaben gespeichert ist. Für die Aufwandsschätzungzukünftiger Aufträge und Projekte ist dies von unschätzbarem Wert. Mit einer Annotierungder bereits abgeschlossenen Projekte können gezielt Aufwände von einzelnen Projektaktivi-täten gesucht werden. Auf Grundlage der gesammelten Erfahrungswerte können beispiels-weise Analogieverfahren zur Aufwandsschätzung für ähnliche Aufgaben in aktuellen Projek-ten eingesetzt werden.

3.3.3. Zugriff und Einsatzgebiet

Die Bereitstellung von Informationen auch außerhalb des Unternehmens und der Zugriff aufdie Daten des Intranets wird zunehmend wichtiger. Der mobile Zugriff auf Emails, Termin-planung und andere Informationsquellen ist zu einem festen Bestandteil in den Unterneh-men geworden und sorgt für einen verbesserten Informationsfluss. Das Zeitplanungssystemerlaubt dem Anwender die Darstellung der Arbeitszeitplanung und Auslastung der Mitarbei-ter, sowie Informationen über aktuelle und vergangene Projekte abzurufen. Der Zugriff aufdiese Daten sollte den Anwendern nicht nur innerhalb des Firmennetzwerks sondern auchstandortunabhängig bereitgestellt werden. Besonders bei entfernten Arbeitsstätten ist einedezentrale Bereitstellung aktueller Planungs- und Statusinformationen wichtig. Desweiterenergeben sich bei der Datenpflege unterschiedliche Zugriffsszenarien, welche eine Verteilungvon Rollen mit entsprechenden Benutzerrechten notwendig machen.

3.4. Eingrenzung Zeitplanungsproblem

Die Grundlage für die Planung bilden die zeitlichen Rahmenbedingungen der Termine undProjektaufgaben. Innerhalb der Kalenderdarstellung müssen diese Ereignisse mit Hilfe einesZeitplanungsalgorithmus entsprechend ihrer Eigenschaften angeordnet werden. Aus denEigenschaften wie Zeitrahmen, Dauer und Priorität ergeben sich für jedes Ereignis unter-schiedliche Nebenbedingungen, die bei der Planung berücksichtigt werden müssen. DasZeitplanungsproblem umfasst dabei die Zeitplanung mit den gegebenen Beschränkungen.Gibt es bei einem Zeitplanungsproblem eine Zeitplanung, welche alle zeitlichen Nebenbedin-gungen erfüllt, dann ist diese Planung eine Lösung des Problems. Doch die Lösung solcherProbleme stellt eine echte Herausforderung dar.

Das Finden einer optimalen Lösung gehört zu den Aufgaben kombinatorischen Optimier-ung als Teilgebiet des Operations Research. Zu dieser Problemgruppe zählen Zuordnungs-,Reihenfolge-, Gruppierungs- und Auswahlprobleme. Zur Lösung dieser Probleme werden inProgrammen Algorithmen formuliert, die Speicherplatz und vor allem Rechenzeit benötigen.

3. Anforderungsanalyse 49

In Abhängigkeit von dem jeweiligen Problemtyp kann eine allgemeine Aussage über den Re-chenaufwand eines Algorithmus gemacht werden. Der Rechenaufwand eines Algorithmuswird auch als Ordnung f (n) bzw. O(f (n)) bezeichnet. Handelt es sich bei der Funktionf (n) um ein Polynom braucht man einen polynomialen Aufwand (z.B. O(f (n2))), ansonstenexponentiellen Aufwand (z.B. O(f (5n))). Die Komplexitätstheorie beschreibt welchen Re-chenaufwand einzelne Problemtypen verursachen, um ein optimale Lösung zu finden. DieOptimierungsprobleme werden dabei hauptsächlich in zwei Komplexitätsklassen unterteilt[Domschke und Drexl, 2005]:

• Klasse N - polynomialer Aufwand; effizient lösbar

• Klasse NP-schwer - exponentieller Aufwand; es ist bisher kein Algorithmus bekannt,der auch das am schwierigsten zu lösende Problem desselben Typs mit polynomialenAufwand löst

Für Optimierungsprobleme der Klasse NP-schwer mit vielen Eingabeparamentern lässt sicheine optimale Lösung nicht in angemessener Zeit ermitteln. Die Anwendung von Heuristikenhilft hier dennoch, gute zulässige Lösungen zu bestimmen.

Zeitplanungsprobleme bzw. Stundenplanprobleme gehören zu den NP-schweren Proble-men. Der Zeitplanungsalgorithmus für das Ereignis-Scheduling, welcher in dieser Arbeitentwickelt wird, liefert keine optimale Lösung im Sinne der kombinatorischen Optimierung.Vielmehr wird dem Anwender nur eine mögliche Lösung dargestellt. Aus dieser Darstellungerhält er einen Überblick der aktuellen Ereignisse und auf Basis dieser Informationen kanner seine Zeitplanung im Tagesgeschäft vornehmen.

3.5. Definition „Ereignis“

Ein Ereignis leitet einen bestimmten Vorgang bzw. eine bestimmte Aktivität ein und ist hiereine Verallgemeinerung aller planbaren Elemente in der Zeitplanung, wie etwa Projektaufga-ben, Meilensteine, Termine und Besprechungen. Ein Ereignis wird dabei mit den folgendenEigenschaften definiert:

• Ort (Platz der Verrichtung)

• Zeit (Start- und Endzeitpunkt)

• Ressourcen (Personen, Betriebsmittel)

• Kontext (Umfeld des Ereignisses)

3. Anforderungsanalyse 50

Die Eigenschaften der Ereignisse werden weitgehend durch die Projektplanung bzw. Ite-rationsplanung oder den Mitarbeiter selbst vorgegeben. Der Ort beschreibt den konkretenAusführungsort (z.B. Standort des Unternehmens, Raum) eines Ereignisses. Außerdem er-gibt sich für jedes Ereignis durch den Iterationsplan ein verbindlicher Zeitrahmen (Start- undEndtermin, Dauer), in dem die Projektaufgabe ausgeführt werden soll. Ebenfalls werden beider Iterationsplanung für die Verrichtung der Projektaufgaben die Verantwortlichkeiten unddamit die Personalressourcen zugewiesen. Der Kontext des Ereignisses ergibt sich aus derBeziehung zum übergeordneten Projekt oder einer Aktivität aus dem Tagesgeschäft.

Grundlage für die Zeitplanung eines Mitarbeiters sind hier vorrangig die zeitlichen Eigen-schaften der ihm zugeteilten Ereignisse und der Kontext, in dem sie ausgeführt werden. Zu-dem sind die Personalressourcen durch die Zuweisung der Verantwortlichkeit vorgegeben.Der Ort und die benötigten Betriebsmittel werden im Zeitplanungssystem nicht berücksichtigtund müssen von der Projektleitung oder dem Mitarbeiter selbst koordiniert werden.

3.5.1. Ereignis Termin

Dieser Ereignistyp beschreibt alle Aktivitäten die im Sprachgebrauch als Termin bezeich-net werden. Sie entsprechen also einem üblichen Kalendereintrag. Diese Einträge werdenüber einen fixen Start- und Endtermin definiert, der Zeitraum dazwischen ergibt die Dauerdieses Ereignisses. Beispiele für solche Ereignisse sind Besprechungen und Geschäftsrei-sen. Für einen Termin ist der Zeitraum seiner Verrichtung also zeitlich festgelegt und mit denbeteiligten Personen fest vereinbart. Die Ausführung zu einem anderen Zeitpunkt erübrigtsich damit. Anders verhält es sich mit der Zeitplanung von Projektaktivitäten, für die nur einZeitrahmen gegeben ist und der Mitarbeiter selbst den konkreten Zeitpunkt der Verrichtungwählen kann.

Die Darstellung von Ereignissen mit Angaben, wie es für Termine üblich ist, zeigt sich als zuunflexibel, um die zeitliche Planung von Projektaufgaben damit abzubilden. Wird die Planungder Projektaktivitäten eines Mitarbeiters mit Hilfe dieser Ereignisse vorgenommen, ergibt sichein großer Pflegeaufwand, auch wenn nur kleine Korrekturen an bestimmten Ereignissenvorgenommen werden. Aufgrund der Zeitplanung wirken sich Veränderungen an wenigenEreignissen auf die folgenden aus, welche dann zeitlich verschoben werden. Eine Iterationmit einem Start- und Endtermin gibt eine Zeitspanne vor, in dem die Projektaktivität variabeleingeplant werden kann. Abhängig ist die Planung von der Auslastung der Mitarbeiter. Des-weiteren wird die Planung von den aktuellen Geschäftsprioritäten bestimmt, Projekte werdenmöglicherweise für vorrangige Projekte zurückgestellt. Für die zeitliche Planung von Projek-taufgaben innerhalb eines Kalenders gelten somit andere Anforderungen, welche in einemgeeigneten Ereignistyp definiert werden müssen.

3. Anforderungsanalyse 51

3.5.2. Ereignis Projektaufgabe

Für die Projektaufgaben der Mitarbeiter muss eine Darstellung gefunden werden, welchealle wichtigen Informationen eines Ereignisses speichert. Für jede Projektaufgabe gibt eszumindest zwei zeitliche Merkmale, mit denen sie beschrieben werden kann. Zum einen istes der geschätzte Soll-Aufwand, welche in der Planung der Iterationsziele analysiert und ver-einbart werden. Zum anderen ist für die Aktivität ein Zeitspanne bzw. Iteration angegeben,in welcher die Projektaufgabe erledigt werden soll. In diesem Zeitraum kann die eigentlicheVerrichtung der Aufgabe durch den zugeteilten Mitarbeiter selbst eingeteilt und ausgeführtwerden. Aus diesen Daten lassen sich Ereignisklassen bilden, welche die sinnvollen Kombi-nationen der Zeitmerkmale einer Aktivität darstellen. Die unterschiedlichen Ereignisklassenwerden im Folgenden definiert.

Definierter Endtermin

Diese Ereignisklasse beschreibt alle Aufgaben, die bis zu einem bestimmten Termin erledigtsein müssen. Der Termin kann dabei durch ein Datum beschrieben werden oder durch einenZeitstempel mit Datum und Uhrzeit. Das Zeitintervall dieser Klasse ergibt sich durch den ak-tuellen Zeitpunkt (t1) bei der Berechnung der Zeitplanung und dem gegebenen Endtermin(t2). Der aktuell noch benötigte Aufwand kann nur in dieser Zeitspanne eingeplant werden.Die Planung des Aufwands kann dabei in zwei Richtungen vorgenommen werden: Entwedererfolgt sie von dem Starttermin in Richtung Endtermin, oder von dem Endtermin in RichtungStarttermin. Für Ereignisse dieser Klasse kann es passieren, dass die verfügbare Zeit inner-halb des Planungsintervalls kleiner als der noch benötigte Aufwand ist. In diesem Fall liegtein Konflikt in der Planung vor, welcher dem Benutzer durch eine entsprechende Nachrichtmitgeteilt wird. Typische Ereignisse dieses Typs sind der Launch einer Anwendung oder derRedaktionsschluss eines Artikels.

Abbildung 3.3.: Ereignis mit definiertem Endtermin, Vorwärtsplanung

Abbildung 3.4.: Ereignis mit definiertem Endtermin, Rückwärtsplanung

3. Anforderungsanalyse 52

Definierter Starttermin

Ein weitere Ereignisklasse beschreibt Aktivitäten, die nur einen vorgegeben frühesten Start-termin (t1) besitzen. Die Zeitplanung dieses Ereignistyps beginnt damit, dass ab dem Start-termin der noch benötigte Aufwand in die verfügbaren Zeiträume der folgenden Arbeitsta-ge eingeplant wird. Dies geschieht solange, bis der gesamte Aufwand komplett eingeplantwurde. Planungskonflikte können bei dieser Klasse nicht entstehen, da das Intervall durchkeinen Endtermin beschränkt wird. Liegt der definierte Starttermin in der Vergangenheit, sowird er bei der Planung auf die aktuelle Zeit korrigiert. Ein Ereignis, welches dieser Klas-se angehört, ist z.B. die Einarbeitungszeit eines neuen Kollegen, der in zwei Wochen seineArbeit beginnt.

Abbildung 3.5.: Ereignis mit definiertem Starttermin, Vorwärtsplanung

Zeitintervall mit definiertem Start- und Endtermin

Die Ereignisklasse charakterisiert alle Aktivitäten, welche innerhalb eines definierten Zeitin-tervalls (t1, t2) erfolgen sollen. Die gesamt Aufwände der Aktivitäten sollten also innerhalbder festgelegten Zeitspanne über die Zeitplanberechnung entsprechend angeordnet werden.Die Zeitspanne wird über den Aufwand der Aufgabe und einen zusätzlich eingeplanten Zeit-puffer definiert. Stehen innerhalb dieses Intervalls nicht genügend Zeitressourcen zur Verfü-gung, so wird der Benutzer über diesen Planungskonflikt informiert. Liegt zum Zeitpunkt derBerechnung der angegebene Starttermin bereits in der Vergangenheit, so wird dieser aufdie aktuelle Zeit korrigiert. In dem Fall verhält sich die Klasse identisch zu der Ereignisklas-se mit einem festen Endtermin. Diese Ereignisse können ebenfalls vorwärts und rückwärtsinnerhalb der gegebenen Zeitspanne eingeplant werden.

Abbildung 3.6.: Ereignis innerhalb eines definierten Zeitintervalls, Vorwärtsplanung

3. Anforderungsanalyse 53

Abbildung 3.7.: Ereignis innerhalb eines definierten Zeitintervalls, Rückwärtsplanung

Variables Zeitintervall ohne Start- und Endtermin

Diese Ereignisklasse wird durch keine zeitlichen Bedingungen eingeschränkt. Der jeweiligeStarttermin wird implizit bei der Berechnung des Zeitplans auf die aktuelle Zeit gesetzt. Vondem Zeitpunkt aus erfolgt die Planung des Aufwands durch Verteilung auf die freien Zeiträu-me der folgenden Arbeitstage. Die Zeitspanne ist durch keinen Endtermin beschränkt, des-halb können bei dieser Klasse keine Planungskonflikte auftreten. Diese Ereignisklasse eignetsich für allgemeine Forschungs- und Entwicklungsaufgaben, welche an keinen festen Termingebunden sind.

Abbildung 3.8.: Variables Ereignis ohne Start- und Endtermin, Vorwärtsplanung

Ereignis Priorität

Um den Ereignissen ein unterschiedliches Planverhalten zu ermöglichen, wird neben denzeitlichen Eigenschaften eine Priorität der Aufgaben eingeführt. Diese hilft bei der Ord-nung der Aufgaben nach gegebenen Geschäftsprioritäten oder nach der vom Mitarbeitergewünschten Priorisierung. Ereignisse mit niedriger Priorität werden von Ereignissen mit ho-her Priorität verschoben und zurückgestellt.

Ereignis Fortschritt

Eine weitere wichtige Eigenschaft definiert der Fortschritt einer Aufgabe. Mit einer Prozent-angabe kann Fortschritt des Ereignis bzw. Aufgabe charakterisiert werden. Diese Form derFortschrittsangabe ermöglicht dem Mitarbeiter, einen Wert des Fertigstellungsgrades einerAufgabe zu schätzen. Der benötigte zeitliche Aufwand für eine Aufgabe sollte möglichst pro-portional zum eigentlichen Fortschritt sein. Die Fehlschätzungen eines Soll-Aufwands zeigtein anderes Verhalten und lässt sich identifizieren. Beispielsweise: Wenn in 5% der verblei-benden Zeit noch 80% der Aufgabe erledigt werden muss, wurde die Aufgabe während derAufwandsschätzung falsch bewertet.

3. Anforderungsanalyse 54

Ereignis Wiederholungen

Die Ereignisse können auch in festgelegten Abständen wiederholt werden. Für die Termineund Aufgaben kann eine Ereignisserie definiert werden. Folgende Wiederholungen wärendabei beispielsweise denkbar:

• täglich, werktäglich

• wöchentlich

• monatlich

• jährlich

Das durch die zeitliche Wiederholung definierte Intervall darf dabei nicht kürzer sein als dieDauer des Termins oder der Aufgabe. Der definierte Ereignistyp Termine ist immer an einenfesten Start- und Endzeitpunkt gebunden und damit stets vor der nächsten Wiederholung be-endet. Anders verhält es sich mit der Planung von Ereignissen des Typs Projektaufgabe. DerStartzeitpunkt einer Aufgabe ist variabel und passt sich den zeitlichen Rahmenbedingungenerst bei der Berechnung des Zeitplans an. Deshalb können bei der Berechnung Situatio-nen entstehen, in denen Aufgaben gar nicht oder nur teilweise in das Wiederholungsintervallpassen. In dem Fall wird der Anwender über eine Hinweismeldung des Systems über dasentstandene Planungsproblem informiert.

3.5.3. Fazit

Die Unterscheidung zwischen den Ereignisklassen ermöglicht die Darstellung von Termi-nen und Projektaufgaben in einem zeitlichen Zusammenhang. Durch die Kombination derEreigniseigenschaften und der Zuordnung einer Ereignisklasse ergibt sich ein bestimmtesPlanverhalten. Die Ereigniseigenschaften definieren einen Zeitrahmen, in dem die jeweiligenKalendereinträge angeordnet werden können.

Um diese Berechnung der Kalenderdarstellung vorzunehmen, muss die Applikation eineKomponente besitzen, welche die klassenspezifischen Eigenschaften der Ereignisse aus-wertet und bei einer automatisierten Planung entsprechend im Kalender anordnet. Das Plan-verhalten der Klassen ist vorgegeben und wird von der Planungskomponente umgesetzt.Kommt es bei der Planung zu Konflikten, werden diese an den Anwender zur Lösung dele-giert.

3. Anforderungsanalyse 55

3.6. Anwendungsfälle

3.6.1. Systemumgebung

Die Systemumgebung (Abbildung 3.9) setzt sich aus den Anwendungsfällen der Arbeitszeit-planung der Mitarbeiter sowie der Planung und Überwachung von Projekten zusammen. Bei-de Planungsebenen teilen sich gewisse Informationen, wie die zeitlichen Eigenschaften, denbenötigten Aufwand und den Fortschritt einzelner Ereignisse (Projektaufgaben oder Meilen-steine). Diese Informationen gilt es, neben der Projektleitung auch für die Geschäftsleitungund Buchhaltung bereitzustellen. Die Geschäftsleitung ist am Projektverlauf besonders inter-essiert, daher wird sie über die wichtigen Entwicklungen im Projekt informiert. Die Projektesind zudem wirtschaftlich auswertbare Vorgänge, die in der Kostenrechnung überwacht wer-den. Die Zeiterfassungskomponente des Systems liefert für die Kostenerfassung detaillierteInformationen über den Aufwand der Projektmitarbeiter oder einzelner Projektaktivitäten.

Die Anwendungsfälle der Projektleitung, Buchhaltung und Geschäftsführung werden hiererwähnt, aber in den folgenden Beschreibungen nicht weiter ausgeführt. Hier werden dieUse-Cases der Zeitplanung aus Sicht der Mitarbeiter näher erläutert. Diese sind weitgehendunabhängig von einem konkreten Projekt einsetzbar, während die für das Informationsmana-gement eingesetzten Softwaresysteme im agilen Projektmanagement in Abhängigkeit vomProjekt auszuwählen sind. Diese Systeme sind änderbar und auf das entsprechende Pro-jekt sowie das Unternehmen zugeschnitten. Allgemein gilt es den Dokumentationsaufwandauf das Wesentliche zu konzentrieren, um keine wichtigen Ressourcen zur Erfüllung vonFormalitäten zu verschwenden.

Für das klassische Projektmanagement existieren bereits viele Programme für die Projekt-planung. Insbesondere die softwarebasierte Erstellung von Netzplänen wird von vielen Sys-temen (siehe Abschnitt 2.4.2) unterstützt. Bei Bedarf kann das Zeitplanungssystem überentsprechende Schnittstellen an externe Systeme angebunden werden. Um eine automati-sierte Distribution aktualisierter Projektpläne herzustellen, muss unter anderem eine syste-mübergreifende, eindeutige Identifikation aller Ereignistypen, wie z.B. Termine, Projektauf-gaben und Meilensteine, gewährleistet sein. Die Erweiterung der Systemfunktionalität durchdie Implementierung einer internen Projektplanungskomponente ist ebenfalls möglich. Zu-dem können beispielsweise die Daten der Zeiterfassung für die Weiterverarbeitung durchdie Buchhaltung über Dokumente, im Format gängiger Tabellenkalkulationsprogramme, be-reitgestellt werden.

Das erstellte Anwendungsfalldiagramm gestaltet sich wie folgt:

3. Anforderungsanalyse 56

Applikation

Terminverwaltung

Aufgabenverwaltung

Zeiterfassung

Zeitplanung

Projektverwaltung

Team Verwaltung

Iterations− und Meilensteinplanung

Benutzerverwaltung

Rechteverwaltung

Projektplanung

Ereignisverwaltung

Auswahl einer Aufgabe

Ereignisplanung

Projektüberwachung

Personalplanung

<< use >>

<< use >>

<< use >>

<< use >>

<< use >>

<< include >>

<< use >> << use >>

<< include >>

wirtschaftliche Aufwandsbewertung

Rechnungserstellung

Gehaltsabrechnung

Ereignis erstellen

Ereignis bearbeiten

Ereignis anzeigen

Ereignis löschen

<< use >>

<< use >>

<< use >>

<< use >>

<< use >>

Authentifikation

Anwendungsfalldiagramm

Projektmitarbeiter

Projektleitung

Buchhaltung

Geschäftsführung

Administrator

Anwender

Abbildung 3.9.: Anwendungsfälle des Systems

3.6.2. Systemauthentifikation

Hauptaktor: AnwenderZuständigkeitsbereich: ApplikationsdienstEbene: AnwenderzielInteressengruppe und Interessen: Anwender - Eindeutige Identifikation des Anwendersgegenüber dem System.Erfolgszusicherung: Die Applikation empfängt die Login-Daten des Anwenders; das Sys-tem authentifiziert den Anwender.

3. Anforderungsanalyse 57

Erfolgsszenario:1. Der Anwender öffnet die Applikation.2. Der Anwender gibt Benutzername und Passwort in der Login-Eingabemaske ein.3. Die Applikation überprüft die empfangenen Login-Daten.4. Die Applikation authentifiziert den Anwender und zeigt die Startseite.Erweiterungen:1a. Die Applikation ist durch einen technischen Fehler nicht erreichbar.1a1. Der Anwender sollte den System-Administrator über den Fehler unterrichten.3a. Die vom Anwender angegebenen Login-Daten sind unvollständig oder inkorrekt.3a1. Die Applikation zeigt dem Anwender erneut die Eingabemaske und einen Hinweis,dass die Authentifikation fehlgeschlagen ist.3a2. Der Anwender korrigiert seine Login-Daten.

Anwendungsfalldiagramm − Authentifikation

Anwender

Authentifikation

Abbildung 3.10.: Systemauthentifikation

3.6.3. Verwaltung von Ereignissen

Hauptaktor: Anwender (Projektmitarbeiter)Zuständigkeitsbereich: ApplikationsdienstEbene: AnwenderzielInteressengruppe und Interessen: Anwender - Verwalten der eigenen Termine und Pro-jektaufgaben.Vorbedingungen: Der Anwender besitzt einen aktiven System-Account und ist am Systemerfolgreich authentifiziert.Erfolgszusicherung: Die Applikation empfängt die Verwaltungsanfrage des Anwenders;die Anfrage wird bearbeitet und das Ereignis des Anwenders wird entsprechend aktualisiert.Erfolgsszenario:1. Der Anwender lässt sich die Liste seiner aktuellen Termine und Aufgaben anzeigen.2. Die Applikation liefert eine Liste der noch nicht erledigten Ereignisse.

3. Anforderungsanalyse 58

3. Der Anwender wählt ein Ereignis aus der Liste aus.4. Die Applikation zeigt das ausgewählte Ereignis in einer Eingabemaske an.5. Der Anwender ändert oder ergänzt die Daten des Ereignisses.6. Die Applikation empfängt die Änderungen des Anwenders und speichert das geänderteEreignis.7. Die Applikation zeigt dem Anwender die aktualisierte Ereignis-Liste.Erweiterungen:6a. Die vom Anwender angegebenen Daten sind unvollständig.6a1. Die Applikation zeigt dem Anwender erneut die Eingabemaske und einen Hinweis derunvollständigen Daten.6a2. Der Anwender ergänzt die fehlenden Daten.

Anwendungsfalldiagramm − Verwaltung von Ereignissen

Ereignis löschen

Ereignis erstellen

Ereignisverwaltung

<< use >>

<< use >>

ProjektmitarbeiterAufgabenverwaltung

<< use >>

Terminverwaltung

<< use >>

Ereignis anzeigen<< use >>

Ereignis bearbeiten

<< use >>

Abbildung 3.11.: Verwaltung von Ereignissen

3.6.4. Zeitplanung

Hauptaktor: Anwender (Projektmitarbeiter)Zuständigkeitsbereich: ApplikationsdienstEbene: AnwenderzielInteressengruppe und Interessen: Anwender - Erstellung der eigenen Arbeitszeitplanung.Vorbedingungen: Der Anwender besitzt einen aktiven System-Account und ist am Systemerfolgreich authentifiziert.Erfolgszusicherung: Die Applikation empfängt die Planungsanfrage des Anwenders; dieAnfrage wird bearbeitet und die Ereignisse des Anwenders werden entsprechend ihrerEigenschaften geplant.Erfolgsszenario:1. Der Anwender wählt einen Zeitraum und lässt sich für diesen die Zeitplanung seiner

3. Anforderungsanalyse 59

aktuellen Ereignisse anzeigen.2. Die Applikation liefert die Zeitplanung für den angegebenen Zeitraum.Erweiterungen:2a. Die automatisierte Zeitplanung für ein oder mehr Ereignisse konnte nicht vollständigausgeführt werden.2a1. Die Applikation erzeugt Fehlermeldungen für die entsprechenden Ereignisse.2a2. Der Anwender korrigiert die Eigenschaften der Ereignisse über die Ereignisverwaltung.2a3. Der Anwender führt danach die Zeitplanung erneut aus.

Anwendungsfalldiagramm − Zeitplanung

Zeitplanung Ereignisplanung

Projektmitarbeiter

<< use >>

Abbildung 3.12.: Zeitplanung

3.6.5. Zeiterfassung

Hauptaktor: Anwender (Projektmitarbeiter)Zuständigkeitsbereich: ApplikationsdienstEbene: AnwenderzielInteressengruppe und Interessen: Anwender - Arbeitszeit einer Projektaufgabe erfassen.Vorbedingungen: Der Anwender besitzt einen aktiven System-Account und ist am Systemerfolgreich authentifiziert.Erfolgszusicherung: Die Applikation empfängt die Zeiterfassungsanfrage des Anwenders;die Anfrage wird bearbeitet und die benötigte Arbeitszeit wird für ein Ereignis gespeichert.Erfolgsszenario:1. Der Anwender lässt sich die Liste seiner aktuellen Termine und Aufgaben anzeigen.2. Die Applikation liefert eine Liste der noch nicht erledigten Ereignisse.3. Der Anwender wählt eine Aufgabe aus der Liste aus und startet die Zeiterfassung.4. Die Applikation speichert den Startzeitpunkt und zeigt das aktive Ereignis an.5. Nachdem der Anwender die Aufgabe erledigt hat, beendet er die Zeiterfassung.6. Die Applikation empfängt die Anfrage und speichert den Endzeitpunkt der Zeiterfassung.Erweiterungen:

3. Anforderungsanalyse 60

5a. Der Anwender versäumt es, die Zeiterfassung zu beenden, nachdem er die Aufgabeerledigt hat.5a1. Der Anwender muss nachträglich den erfassten Aufwand der Aufgabe korrigieren undspeichern.5b. Zum Zeitpunkt der Erledigung der Aufgabe ist die Applikation durch einen technischenFehler nicht erreichbar.5b1. Der Anwender muss zu einem späteren Zeitpunkt den erfassten Aufwand der Aufgabekorrigieren und speichern.

Anwendungsfalldiagramm − Zeiterfassung

Projektmitarbeiter

Zeiterfassung

Auswahl einer Aufgabe

<< use >>

Ereignis bearbeiten

Ereignis erstellen

Ereignis anzeigen

Ereignis löschen

Ereignisverwaltung

<< use >>

<< use >>

<< use >>

<< use >>

<< use >>

Abbildung 3.13.: Zeiterfassung

3.6.6. Verwaltung von Benutzern

Hauptaktor: AdministratorZuständigkeitsbereich: ApplikationsdienstEbene: AnwenderzielInteressengruppe und Interessen: Administrator - Anlegen neuer Benutzer und Änderungder Daten bestehender Benutzer.Vorbedingungen: Administrator besitzt einen aktiven System-Account mit Administrations-privilegien und ist am System erfolgreich authentifiziert.Erfolgszusicherung: Die Applikation empfängt die Verwaltungsanfrage des Administrators;Die Anfrage wird bearbeitet und die aktualisierten Benutzerdaten werden gespeichert.Erfolgsszenario:1. Der Administrator lässt sich die Liste der System-Accounts anzeigen.2. Die Applikation liefert eine Liste der aktuellen Accounts.3. Der Administrator wählt einen Benutzer aus der Liste aus.

3. Anforderungsanalyse 61

4. Die Applikation zeigt die ausgewählten Benutzerdaten in einer Eingabemaske an.5. Der Administrator ändert oder ergänzt die Daten des Benutzers.6. Die Applikation empfängt die Änderungen des Administrators und speichert die geänder-ten Daten.7. Die Applikation zeigt dem Administrator die aktualisierte Benutzer-Liste.Erweiterungen:6a. Die vom Administrator angegebenen Daten sind unvollständig oder inkorrekte Eingabedes Passworts.6a1. Die Applikation zeigt erneut die Eingabemaske und einen Hinweis der unvollständigenDaten.6a2. Der Administrator ergänzt die fehlenden Daten.

Anwendungsfalldiagramm − Verwaltung der Benutzer

Benutzerverwaltung Rechteverwaltung<< include >>

Administrator

Abbildung 3.14.: Verwaltung der Benutzer

4. Design und Modellierung

Dieses Kapitel erläutert den konkreten Entwurf eines Zeitplanungssystems für agile Projek-tabläufe. Es folgt zunächst ein Überblick über das System mittels Abstraktion auf die kon-zeptionellen Fachklassen. Anschließend wird das realisierte Modell mit einem Klassendia-gramm ausführlich erklärt sowie eine genaue Beschreibung der erstellten Klassen und de-ren Verantwortlichkeiten geliefert. Die bereits in Abschnitt 3.6 vorgestellten Anwendungsfällewerden noch einmal aufgegriffen und anhand von Sequenzdiagrammen näher beschrieben.Abschließend wird für das System eine entsprechende Zielplattform ausgewählt. Die Imple-mentierung dieses Systementwurfes erfolgt danach in Kapitel 5.

4.1. Systementwurf

Widmen wir uns vorerst dem plattformunabhängigen Entwurf des Systems, indem alle Klas-sen vorgestellt und deren Eigenschaften näher erläutert werden.

4.1.1. Konzeptionelle Fachklassen

Die Modellierung der Applikation wird zunächst grob betrachtet, desweiteren werden die ver-wendeten Konzeptklassen identifiziert und erläutert. Dabei reduziert sich die Anwendung aufdie Klassen User, Activity, Expense, Planner und Calendar (Abbildung 4.1). Diese Fachklas-sen und deren Beziehungen zueinander bilden die Vorlage für das Design des Klassenmo-dells (Abschnitt 4.1.2).

4. Design und Modellierung 63

User

Activity

Planner

Calendar

Expense

Abbildung 4.1.: Konzeptionelle Fachklassen

Die Klasse User repräsentiert alle Benutzer der Applikation mit ihren unterschiedlichen Rol-len wie Projektmitarbeiter, Projektleitung, Buchhaltung und Geschäftsführung. Ein Benutzerkann nicht nur eine, sondern mehrere Rollen im System wahrnehmen. Der gesamte Per-sonalpool bildet die Basis, welcher Termine, Meilensteine und Projektaufgaben zugeordnetwerden. Diese planbaren Vorgänge werden hier allgemein als Aktivitäten bezeichnet und mitder Klasse Activity dargestellt. Alle für die zeitliche Planung relevanten Eigenschaften sowiedie Zuordnung zu den Mitarbeitern werden mit einer Aktivität beschrieben. Die durch eineAktivität tatsächlich aufgewendete Zeit wird mit der Klasse Expense repräsentiert. Die Über-setzung der Aktivitäten in die Einträge des Kalenders wird von den Planer-Klassen (Planner )vorgenommen. Der Einsatz mehrerer Planer realisiert ein unterschiedliches Planverhaltenbei der Berechnung des Zeitplans. Das Ziel ist die Erstellung einer vom Benutzer abhängi-gen Zeitplanung, die innerhalb eines Kalenders (Calendar ) dargestellt wird. Die geplantenAktivitäten eines Mitarbeiters werden damit in einen zeitlichen Kontext übersetzt und visuali-siert.

4.1.2. Klassendiagramm

In folgender Abbildung 4.2 werden die modellierten Klassen und deren Beziehungen zu-einander aufgezeigt. Anschließend werden die Klassen genauer erläutert und die jeweiligeVerantwortlichkeiten beschrieben.

4. Design und Modellierung 64

Scheduler

CalendarXML

CalendarICAL

CalendarDay

Capability

ProblemSolver

CalendarDecorator

WeekScheme

<< abstract >>

SchedulerEventBase

Appointment

Milestone

FloatingTask

User Group

<< abstract >>

Event

Track

EventContainer

CalendarEvent

Calendar

Controller

WorkCalendar

<< abstract >>

SchedulerBase

* * * *

*

*

DependencyDependencyDependency

SchedulerEvent SchedulerTrack

*

*

*

Abbildung 4.2.: Klassendiagramm

4. Design und Modellierung 65

Benutzer- und Rechteverwaltung

Für die Verwaltung der Benutzer und Rechte sind die Klassen User, Group und Capabi-lity zuständig. Die benutzerabhängigen Eigenschaften werden als Attribute in der KlasseUser verwaltet. Zur strukturierten Rechteverwaltung werden alle Benutzer Gruppen (Group)zugeordnet, welche mit ausgewählten Zugriffsrechten (Capability ) ausgestattet sind. Damitkönnen den Benutzern eine oder mehrere Rollen zugewiesen werden. Die Zugriffsrechte derBenutzergruppen werden über eine Capability-Liste verwaltet, welche die Zugriffsart auf dieverschiedenen Systemfunktionen festlegt. Die Klassen der Benutzer- und Rechteverwaltunghaben die folgenden Verantwortlichkeiten:

• Authentifizierung der Benutzer mit einem Challenge-Response Verfahren durch Über-prüfung von Name und Passwort.

• Bereitstellung aller Informationen des Benutzerkontos wie z.B. Name, Passwort undweitere Eigenschaften.

• Ermittlung der Zugriffsrechte von Benutzern über die zugeordneten Gruppen.

Wochenschema

Die Definition der wöchentlichen Arbeitszeit wird über die Klasse WeekScheme vorgenom-men. Die tägliche Arbeitszeit wird für jeden Wochentag mit einem Zeitintervall festgelegt.Das Wochenschema bildet den zeitlichen Rahmen für die Zeitplanung der Projektaufgaben.Im Gegensatz dazu können fixe Termine und Meilensteine zu jedem Zeitpunkt inner- undaußerhalb der Arbeitszeit definiert werden. Die Klasse WeekScheme hat die folgende Ver-antwortlichkeit:

• Ermittlung der wöchentlichen Arbeitstage und täglichen Arbeitszeiten.

Ereignis

Die abstrakte Klasse Event repräsentiert mit ihren generalisierten Attributen eine Basis füralle konkreten Ereignisklassen der Applikation. Die abgeleiteten Klassen beschreiben einenspeziellen Typ von Ereignis beispielsweise Appointment, Milestone oder FloatingTask. Die-se Vererbungsstruktur erlaubt die flexible Erweiterung um neue Ereignistypen. Die Klas-sifizierung in einzelne Ereignistypen und das damit verbundene Planungsverhalten bildendie Grundlage für die automatisierte Berechnung des Zeitplans. Somit kann jedes Event-Objekt identifiziert und über den zugeordneten Algorithmus entsprechend geplant werden.Die Verantwortlichkeiten der Ereignisse werden mit einer Beziehung zu mindestens einemBenutzer modelliert, um eine entsprechende Zuordnung einzelner oder kollaborativer Pro-jektaufgaben zu ermöglichen. Die an den Benutzer gebundene Zeitplanerstellung identifi-ziert die Zugehörigkeit der Ereignisse über dieses Klassenattribut. Eine universelle Basis

4. Design und Modellierung 66

für alle Ereignisse verspricht ein einheitliches Handling der Termine (Appointment) und Pro-jektaufgaben (FloatingTask, etc.) bei der Verwaltung und peristenten Speicherung. TypischeCRUD-Operationen1 können für alle Event Objekte über die gleiche Methoden erfolgen. DieKlasse Event hat die folgenden Verantwortlichkeiten:

• Bereitstellung der gemeinsamen Ereignisattribute wie Name, Beschreibung,Start/Endzeitpunkt, Dauer, Fortschritt, Priorität und Sichtbarkeit.

• Verwaltung der Ereignisverantwortlichkeit durch Referenzen zu den Benutzern.

• Verwaltung des zugeordneten Planungsalgorithmus.

• Bereitstellung von Funktionen zur Erstellung und Zugriff auf die erfassten Zeiten(Track ) des Ereignisses.

• Bereitstellung von Methoden für die Objekt-Persistenz zur Sicherung in der Daten-bank.

Die Klasse EventContainer dient zur Gruppierung und Strukturierung der Ereignisse. DerFortschritt und die gesamte Dauer eines EventContainers ergibt sich dabei aus den zuge-ordneten Event Objekten. Die EventContainer erlauben die Anordnung von Ereignissen ineiner Baumstruktur, ein EventContainer kann Referenzen auf Event- oder EventContainer -Objekte enthalten. Die Verantwortlichkeit der Klasse ist folgende:

• Ermittlung des Gesamtfortschritts und der Dauer der untergeordneten Event- undEventContainer -Objekte.

Abhängigkeiten

Zwischen Event- und EventContainer -Objekten können verschiedene kausale Abhängigkei-ten über eine Dependency bestimmt werden. Über die Instanzen dieser Klasse wird definiert,ob bestimmte Ereignisse oder Ereignisgruppen vor oder nach anderen Ereignissen erfolgenmüssen. Bei der Festlegung der Abhängigkeiten und bei Gruppierung von Ereignissen mussdie Konsistenz der definierten Abhängigkeiten geprüft werden. Es darf nicht möglich sein,gegensätzliche Abhängigkeiten zwischen einer Ereignisgruppe und den zugeordneten Er-eignissen zu definieren. Die Klasse Dependency ist verantwortlich für:

• Bereitstellung von kausalen Abhängigkeiten zwischen Event- und/oder EventContai-ner -Objekten.

1CRUD ist ein Akronym für die Basisfunktionen einer Datenbank oder Persistenzschicht (Create, Read,Update, Delete)

4. Design und Modellierung 67

Zeiterfassung

Die Klasse Track dient zur Darstellung der erfassten Zeiten. Die Assoziation eines Track -Objekts wird zu dem entsprechenden Event sowie User hergestellt. Ein Statusattribut gibtan, ob das Track Objekt gerade aktiv ist und die Zeit aktuell erfasst wird oder ob die Zeit-erfassung bereits beendet wurde. Die Länge der erfassten Zeit ergibt sich direkt aus demZeitraum zwischen Start- und Endzeitpunkt, Pausen oder tägliche Arbeitszeiten werden nichtberücksichtigt. Die Klasse Track besitzt die folgende Verantwortlichkeit:

• Berechnung und Bereitstellung des zeitlichen Aufwands aus dem erfassten Start- undEndzeitpunkt.

Planer

Die Planungskomponente umfasst mehrere Klassen, deshalb werden hier zusammen-fassend die Klassen SchedulerBase, Scheduler, ProblemSolver, SchedulerEventBase,SchedulerEvent und SchedulerTrack betrachtet.

Die Aufgabe der Planer ist es, alle Ereignisse (Event) eines Benutzers in einen Terminka-lender zu übertragen. Ein Ereignis kann dabei auf verschiedene Kalendereinträge an unter-schiedlichen Tagen aufgeteilt werden, solange, bis die Ereignisdauer eingeplant wurde. Indie Planung fließt dabei nur die effektiv notwendig zu planende Ereignisdauer ein, also dergeschätzte Soll-Aufwand abzüglich der bereits erfassten Ist-Aufwände (Track ). Der Planerversucht, unter Berücksichtigung der zeitlichen Ereigniseigenschaften und der verfügbarenZeitressourcen des Terminkalenders eine konsistente Zeitplanung zu erstellen. Ist dies nichtmöglich, werden für die betroffenen Ereignisse entsprechende Warnmeldungen generiertund den Benutzern mitgeteilt.

Die abstrakte Klasse SchedulerBase bildet die Basis, von der aus alle konkreten Implemen-tierungen der Planungsalgorithmen abgeleitet werden. Die Klasse beinhaltet Attribute undMethoden, die unabhängig von der konkreten Umsetzung eines Planers Verwendung finden.Zudem definiert die Basisklasse abstrakte Methoden für die Planung der einzelnen Ereigni-stypen, welche über die Subklassen mit einem ausgewählten Planungsverhalten versehenwerden. Die Klassen Scheduler und ProblemSolver stellen damit für jeden Ereignistyp un-terschiedliche Implementierungen mit eigenem Planungsverhalten dar.

Beispielsweise können mit den Algorithmen der Klasse ProblemSolver Vorschläge für diePlanung überfälliger Aufgaben gemacht werden. Gezielt kann der Benutzer bestimmte Auf-gaben diesem Planer zuweisen und damit mögliche Planungsszenarien darstellen. Die durchden ProblemSolver vorgeschlagenen Korrekturen an den zeitlichen Eigenschaften der Auf-gaben müssen abschließend von dem Benutzer bestätigt werden.

Die Planer-Klassen haben folgende Verantwortlichkeiten:

4. Design und Modellierung 68

• Bereitstellung wiederverwendbarer Funktionen zur Ereignisplanung.

• Bereitstellung von Planungsalgorithmen zur Verarbeitung der Ereignistypen.

Die Ereignisse (Event) und die erfassten Zeiten (Track ) werden vor der Verarbeitung durcheinen Planer in Objekten der Klassen SchedulerEvent und SchedulerTrack gekapselt. Dieseerweitern die beiden Klassen um Methoden und Attribute, die nur während der Berechnungdes Zeitplans benötigt werden. Der Planer dekrementiert mit jedem erstellten Kalenderein-trag die Ereignisdauer und kann feststellen inwieweit ein Ereignis bereits verplant wurde. Diegemeinsame Basisklasse SchedulerEventBase vereinheitlicht den Zugriff auf die relevan-ten Attribute der unterschiedlichen Ursprungsklassen Event und Track. Somit arbeiten diePlaner nur mit Objekten der Subklasse von SchedulerEventBase. Die Verantwortlichkeit derKlassen SchedulerEventBase, SchedulerEvent und SchedulerTrack ist folgende:

• Bereitstellung von Methoden zur Dekrementierung und Abfrage der Ereignisdauer.

Controller

Die Klasse Controller koordiniert den Prozess der gesamten Zeitplanberechnung und stelltdabei die Verbindung zwischen dem Benutzer, Wochenschema, Ereignissen, erfassten Zei-ten, Kalender und den Planern her. Der Controller ermittelt bei der Planung die benutzer-abhängigen Ereignisse, instantiiert den Kalender und dekoriert ihn mit dem Wochenschemades Benutzers. Für die Zeitplanung werden die Ereignisse an die zugeordneten Planer über-geben, welche die Umwandlung in die einzelnen Kalendereinträge vornehmen. Die KlasseController hat die folgenden Verantwortlichkeiten:

• Bereitstellung des Kalenders (Calendar ).

• Ermittlung der Arbeitszeiten als Wochenschema (Weekscheme).

• Ermittlung der aktiven Ereignisse (Event).

• Ermittlung der erfassten Zeiten (Track ) im angegebenen Zeitraum.

• Erstellung des Zeitplans für einen angegebenen Zeitraum über die Planer (Scheduler,ProblemSolver ).

Kalender

Die Calendar Klasse dient als Abstraktion eines Terminkalenders, in dem Ereignisse wieTermine und Projektaufgaben dargestellt werden. Diese Klasse verwaltet Objekte der Ca-lendarDay Klasse, welche einen Tag mit der Einteilung in Stunden und Minuten abbildet.Mit Objekten der CalendarEvent Klassen werden konkrete Kalendereinträge an einem Tagangelegt. Diese Einträge werden bei der Berechnung des Zeitplans aus den Terminen bzw.Aufgaben eines Benutzer erstellt. Als Zuordnung zu den Objekten der Ursprungsereignisse

4. Design und Modellierung 69

bleibt eine Referenz in jedem Kalendereintrag erhalten. Durch die Objektkomposition ergibtsich ein existenzielles Abhängigkeitsverhältnis zwischen dem Calendar und aggregiertenCalendarDay und CalendarEvent Objekten.

Um die Planung der Projektaufgaben zu realisieren, ergibt sich ein anderer zeitlicher Rah-men als nur der eigentliche Kalender. In Abhängigkeit von dem Benutzer wird ein weitauskleinerer Zeitrahmen durch die wöchentliche Arbeitszeit vorgegeben. Die Erweiterung dieserFunktionalität der Klasse wird mit der Anwendung eines Dekorierer Entwurfmusters (engl.decorator pattern) [Gamma, 1996] vorgenommen. Der Dekorierer wird in der Klasse Calen-darDecorator implementiert und bietet die durch den Kalender vorgegebenen Schnittstellen.Die WorkCalender Klasse bildet eine Unterklasse des Dekorierers und implementiert diezusätzlichen Methoden, welche bei der Ereignisplanung innerhalb der vorgegeben Arbeits-zeiten benötigt werden.

Die Klasse Calendar hat die folgenden Verantwortlichkeiten:

• Verwaltung der aggregierten CalendarDay und CalendarEvent Objekte.

• Bereitstellung von Methoden zum Setzen eines Datums und Zeitpunkts.

• Ermittlung der erstellten Einträge (CalendarEvent) an einem Kalendertag.

• Ermittlung der freien Zeitressourcen an einem Kalendertag.

Darstellung

Zur Darstellung und Verarbeitung des Terminkalenders muss die Calendar Objektkompositi-on in ein einheitliches Format gewandelt werden. Die Klasse CalendarXML wandelt deshalbdie Kalenderdaten eines angegebenen Zeitraums in ein XML-Dokument um. XML erlaubtdie Darstellung der Kalenderdaten unabhängig von einer konkreten Repräsentation z.B. inForm einer Tabelle oder Grafik. Die XML-Daten werden mit XSLT in eine andere Darstellungtransformiert oder direkt durch eine Anwendungen verarbeitet.

Die Klasse CalendarICAL wandelt die Kalenderdaten in das im RFC 2445 [www:RFC2445]spezifizierten iCalendar Format um. Dieses Format dient zum Austausch von Kalenderinfor-mationen und wird von vielen Terminkalender-Applikationen unterstützt.

Die Darstellungsklassen CalendarXML und CalendarICAL haben folgende Verantwortlich-keit:

• Umwandlung und Bereitstellung der Calendar Objekte in Dokumente im XML oderiCalendar Format.

4. Design und Modellierung 70

4.1.3. Szenario: Ablauf der Zeitplanung

Der in Abschnitt 3.6.4 beschriebene Anwendungsfall soll hier mit Sequenzdiagrammen nähererläutert werden. Die folgenden Diagramme wurden in zwei Phasen eingeteilt: Die Initialisie-rung aller benötigten Objekte und die Berechnung des Zeitplans bzw. Kalenderdarstellung.

Abbildung 4.3.: Initialisierung des Controller Objekts

Das Controller Objekt orchestriert alle Objekte, welche für die Zeitplanerstellung benötigtwerden. Nachdem der Calendar instantiiert wurde, wird die Arbeitszeit mit dem Wochen-schema des Benutzers auf den Terminkalender dekoriert. Die aktiven Ereignisse des Be-nutzers und die Planer werden aus der Datenbank geladen. Die Peer Klassen (EventPeer,SchedulerPeer ) dienen als Schnittstelle zum persistenten Speicher und stellen statische Me-thoden bereit zur Abfrage und Erstellung der Event und Scheduler Objekte.

4. Design und Modellierung 71

Abbildung 4.4.: Berechnung des Zeitplans

Nach der Initialisierung des Controller Objekts erfolgt die Zeitplanung mit dem Methoden-aufruf von createSchedule(), der eine Zeitspanne durch die Parameter Start und Stop über-gibt. Zunächst werden die fixen Termine (Appointment) ausgewählt und in den Kalendereingetragen, gefolgt von den Projektaufgaben (FloatingTask, FloatingTaskWithStop etc.), dienach ihrer Priorität sortiert und in der Reihenfolge eingeplant werden. Die private Metho-de processEvents() übernimmt die Planung der einzelnen Ereignisse (Event). Abschließendwerden die erfassten Zeiten des Benutzers über die Klasse TrackPeer aus der Datenbankgeladen und über processTracks() in den Kalender eingetragen. Mit getCalendar() liefert derController eine Referenz auf die Calendar Instanz, die zur Verarbeitung an die Darstellungs-klassen CalendarXML und CalendarICAL übergeben wird.

4. Design und Modellierung 72

Abbildung 4.5.: Verarbeitung der Ereignisse durch die zugeordneten Planer

Ein Blick in die Methode processEvents() zeigt die Zeitplanung einzelner Ereignisty-pen über die zugeordneten Planer. Die Event Objekte werden identifiziert und in einemSchedulerEvent gekapselt, bevor es an den Planungsalgorithmus des entsprechenden Pla-ners übergeben wird. Folgende Sequenzdiagramme zeigen den Ablauf der Planung zweiunterschiedlicher Ereignistypen.

4. Design und Modellierung 73

Abbildung 4.6.: Planungsalgorithmus eines Termins (Appointment)

Der Planungsalgorithmus für Appointment Objekte erstellt in dem vom Ereignis vorgegebe-nen Zeitraum Kalendereinträge (CalendarEvent). Das Wochenschema des Benutzers sowiedie gegebenenfalls vorhandenen Einträge werden nicht berücksichtigt.

4. Design und Modellierung 74

Abbildung 4.7.: Planungsalgorithmus einer Projektaufgabe (FloatingTask)

Der Planungsalgorithmus für FloatingTask Objekte erstellt Kalendereinträge (CalendarEvent)in Abhängigkeit des Wochenschemas und der noch verfügbaren Zeitressourcen. Der Ereig-nistyp FloatingTask unterliegt keinen zeitlichen Einschränkungen und wird deshalb auf diefreien Zeitressourcen im Kalender zum Zeitpunkt der Berechnung verteilt.

4. Design und Modellierung 75

4.1.4. Szenario: Verwaltung von Ereignissen

Die Verwaltung der Ereignisse eines Benutzers erfolgt in drei Schritten (Abbildung 4.8). DieKlasse EventActions ist der Controller zwischen der Benutzeroberfläche und der Daten-schicht. Der Controller empfängt alle Interaktionen des Anwenders von der Benutzerober-fläche und steuert die einzelnen Aktionen auf dem Datenmodell. Zunächst werden alle akti-ven Ereignisse eines Benutzers über die Klasse EventPeer aus der Datenbank geladen undüber die Benutzerschnittstellen ausgegeben. Aus der Ereignisliste wählt der Benutzer an-schließend das zu bearbeitende Ereignis aus. Der Controller empfängt die eindeutige Iden-tifikationsnummer (ID) des Ereignisses und lädt das Objekt (event) aus dem persistentenSpeicher. Die graphische Benutzeroberfläche zeigt die aktuellen Attribute des ausgewähl-ten Ereignisses an und der Benutzer kann nun die Änderungen vornehmen. Abschließendwerden die Änderungen im Objekt aktualisiert und in der Datenbank gespeichert.

Abbildung 4.8.: Ereignisverwaltung

4. Design und Modellierung 76

4.1.5. Szenario: Zeiterfassung

Die Zeiterfassung erfolgt in zwei Schritten. Nach dem Prinzip einer Stoppuhr kann die Zeit-erfassung zu einem Zeitpunkt gestartet und zu einem späteren Zeitpunkt wieder gestopptwerden. Der Benutzer startet die Zeiterfassung für ein ausgewähltes Ereignis (event). Dabeiwird ein neues Objekt der Klasse Track instantiiert und der aktuelle Zeitstempel als Start-zeitpunkt gesetzt. Zudem wird der Status des Track Objekts auf den Wert 1 (aktiv) gesetzt.Anschließend wird das Objekt in der Persistenzschicht gespeichert. (Abbildung 4.9)

Abbildung 4.9.: Beginn der Zeiterfassung eines Ereignisses

Im zweiten Schritt beendet der Benutzer die Zeiterfassung für ein Ereignis. Dabei wird zu-nächst das Ereignis Objekt (event) über die Klasse EventPeer aus der Datenbank geladen.Danach wird über die Klasse TrackPeer das aktive track Objekt des zugehörigen Zeiterfass-ungsvorgangs instantiiert. Der Stopzeitpunkt des track Objekts wird gesetzt und der Statusauf den Wert 2 (abgeschlossen) aktualisiert. Abschließend wird das Objekt der Klasse Trackim persistenten Speicher gesichert. (Abbildung 4.10)

4. Design und Modellierung 77

Abbildung 4.10.: Beenden der Zeiterfassung eines Ereignisses

4.2. Auswahl der Zielplattform

Die Anforderung aus Abschnitt 3.3.3 führen zur einer Grundsatzentscheidung bei der konkre-ten Realisierung der Client/Server Architektur des Systems. Das bei der Modellierung einerClient/Server Architektur eingesetzte Drei-Schichten-Modell (engl. three-tier model) trenntdie Präsentations- (engl. presentation tier), Logik- (engl. logic tier) und Datenschicht (engl.data tier) logisch voneinander. Die Realisierung einer Client/Server Architektur legt weiter-hin fest, welche (Teil)Schichten auf dem Client und welche auf dem Server umgesetzt wer-den. Diese Entscheidung beeinflusst im Wesentlichen die softwaretechnische Umsetzungder Applikation und der Kommunikationsschnittstelle zwischen Client und Server. Die Be-grifflichkeiten Thin- und Fat-Client existieren sowohl im Bereich der Software als auch in derHardware. An dieser Stelle wird aber ausschließlich auf den Bereich der Software einge-gangen. Die Eigenschaften von Thin- und Fat-Client Applikationen können daher wie folgtdargestellt werden:

4. Design und Modellierung 78

Thin-Client Fat-Client

Verfügbarkeit online online und offline

Datenhaltung zentrale Datenbank dezentrale und zentrale Da-tenbanken, Replikation nötig

Portabilität hoch, oft plattformunabhängig niedrig, meist plattformabhän-gig

Technologie Web (HTML, ASP, PHP, JSP),Terminal Services (Metafra-me, X11)

native Desktop-Anwendung(C++, C#, .net, Java)

Verteilung,Aktualisierung

einfach, zentral aufwändig, dezentral

Benutzeroberfläche einfach bis komplex einfach, komplex, spezielleAnforderungen (z.B. 3D,CAD)

Tabelle 4.1.: Vergleich der Merkmale von Thin- und Fat-Client Applikationen

Weiterhin existieren neben Thin- und Fat-Client Anwendungen noch weiter Mischformen, wiez.B. Ultra-Thin-Client oder Rich-Client. Diese besitzen Eigenschaften von beiden Applikati-onsformen und werden in der Praxis als Ableger von Thin- bzw. Fat-Client Anwendungenangesehen.

Die Realisierung in Form eines Fat-Clients erhöht die Verfügbarkeit der Applikation, so kannauch im Offline-Betrieb der Zugriff auf die lokale Datenbasis realisiert werden. Bei einerSynchronisation mit dem Server werden die benötigten Daten auf die lokale Datenbank desClients repliziert. Die lokalen Daten des Clients sind zum Zeitpunkt der Synchronisation mitdem Server identisch. Da sich die Daten auf dem Server mit der Zeit ändern, verliert dielokale Datenbank auf dem Client an Aktualität. So können Informationen der Planung be-reits veraltet sein und sich zwischenzeitlich verändert haben. Dies ist in erster Linie von derAnzahl der Anwender sowie der Änderungsfrequenz abhängig. Um die volle Funktionali-tät des Systems auch im Offline-Betrieb zu ermöglichen, ist eine Replikation der gesamtenServer-Datenbank auf den Client notwendig, da die Planung und Analyse der aktuellen undvergangenen Projekte bereitgestellt wird. Dies bedeutet einen erhöhten Speicherplatzbedarfauf den mobilen Geräten (z.B. Notebooks). Problematisch ist ebenfalls, dass im Fall der Ent-wendung oder Kompromittierung eines mobilen Geräts sensitive Daten des Unternehmensfür Dritte offengelegt werden. Die Daten umfassen hier detaillierte Informationen von aktuel-

4. Design und Modellierung 79

len und abgeschlossenen Projekten sowie Daten aus der Zeiterfassung aller Mitarbeiter. ImSinne des Datenschutzes soll ein Zugriffsschutz und die Sicherheit der Daten gewährleistetwerden. Eine Replikation der Datenbank erhöht somit das Risiko eines nicht autorisiertenZugriffs. Abhilfe schafft hier eine zusätzliche Verschlüsselung der lokalen Datenbank.

Die Umsetzung in Form einer Thin-Client Applikation hingegen ist auf die Verbindung zumServer angewiesen, da sowohl die Logik- und als auch die Datenschicht serverseitig rea-lisiert sind. Ein Offline-Einsatz ist mit dieser Applikationsform nicht gegeben. Die gesamteApplikationslogik wird auf dem Server ausgeführt, der Client realisiert lediglich die Darstel-lung der Benutzeroberfläche. Alle Interaktionen des Anwenders werden zur Verarbeitungweiter an den Server gesendet. Die Anforderungen an die Hardware und Rechenleistungder mobilen Geräte (z.B. Notebook, PDA, Smartphone) sind hier verhältnismäßig niedrig.Zudem werden, abgesehen von den temporären Cachedaten, keine sensitiven Informatio-nen aus der Datenbank auf dem Client gespeichert. Die Entwendung eines mobilen Gerätsist damit weitgehend als unbedenklich anzusehen. Die Kompromittierung des Geräts durchSchadprogramme (engl. malware) ist aber weiterhin gegeben und sollte daher in der Sicher-heitsstrategie des Unternehmens berücksichtigt werden.

4.2.1. Web-Technologie

Der Einsatz einer webbasierten Lösung und damit einer Form von Thin-Client ist notwen-dig, sobald Mitarbeiter an unterschiedlichen Standorten ständig mit aktuellen Informationenversorgt werden müssen. Für den Zugriff auf die aktuellen Daten ist das mobile Geräte aufeine Netzwerkverbindung zum Applikationsserver angewiesen. Diese scheinbare Einschrän-kung der Mobilität wird durch die weit verbreiteten Kommunikationsinfrastrukturen wie GSM,UMTS und WLAN Access Points wieder aufgehoben.

Als Plattform für die Applikation dient ein Webserver mit entsprechender Programmierspra-che zur Erstellung dynamischer Inhalte. Eine angebundene Datenbank stellt den persisten-ten Speicher für alle Anwendungsdaten. Durch die zentrale Datenhaltung können besserMaßnahmen für die Datensicherung und den Datenschutz etabliert werden. Die Wartbarkeitder Applikation ist gegeben und Veränderungen sowie Erweiterungen werden zentral aktua-lisiert. Eine aufwändige Verteilung der Applikation und weitere Updates, wie es bei Desktop-Anwendungen üblich ist, entfällt. Der Zugriff auf die Web-Applikation wird über einen Browservorgenommen und ist damit unabhängig vom Betriebssystem. Zudem ist der Zugriff auf dieApplikation von vielen Orten möglich. Die im Intranet veröffentlichte Anwendung ist außer-dem von Extern über eine VPN-Verbindung aufrufbar.

Im Vergleich zu der Ausführung eines lokalen Programms, ergibt sich für Web-Applikationender Nachteil einer eingeschränkten Interaktivität des Anwenders. Desktop-Applikationen bie-ten eine bessere Reaktionsfähigkeit und können Daten auch nur in bestimmten Bereichen

4. Design und Modellierung 80

des Fensters sofort aktualisieren. Aufgrund der verwendeten Web-Technologie ist nur einseitenbasierter Aufruf von HTML-Seiten möglich. Jede Veränderung erfordert also eine neueAnfrage an den Server, welcher eine weitere HTML-Seite als Antwort sendet. Der Einsatzvon HTML-Frames stellt keine hinreichende Lösung des Problems. Um die Interaktionen derBenutzer dennoch möglichst flexibel zu halten, wurden bisher Java Applets [www:Applet]oder Macromedia Flash [www:Flash] Technologien eingesetzt, welche aber neben demBrowser weitere Software zur Darstellung benötigen.

4.2.2. Web 2.0

Ein Modewort des Jahres 2005 war „Web 2.0“, welches die nächste Generation von Dienst-leistungen und Applikationen im World Wide Web beschreibt. Im Rahmen der zweiten Web2.0 Conference, die im Oktober 2005 stattfand, wurde festgehalten, welche Innovationen,Internetservices, Web-Applikationen und Geschäftsmodelle das Internet von heute im We-sentlichen bestimmen. Die Web 2.0 Konzepte haben dabei keine vorgegebenen Grenzen,sondern sind eher als eine Sammlung von Prinzipien und Methoden anzusehen. Primär wirddas Web als Plattform genutzt, auf der dem Anwender serviceorientiert Applikationen bereit-gestellt und diese wiederum durch sein eigenes Mitwirken verbessert werden. Die Kernkom-petenzen der Web 2.0 Unternehmen zeichnen sich durch kostengünstige skalierbare Onli-neservices, Kontrolle über einzigartige Datenquellen, Verbindung von kollektiver Intelligenz,Beteiligung der Benutzer sowie eine geräteunabhängige Verbreitung der Softwarelösungenaus. [O’Reilly, 2005]

Web 2.0 umfasst dabei eine inhaltliche und eine technische Ebene. Der Benutzer spielt beider Modellierung der Inhalte eine wesentliche Rolle. Die Internetangebote gewinnen durchdie Involvierung der Anwender an Attraktivität und es ist längst nicht mehr nur die Meinungdes Autors eines Artikels gefragt, sondern auch die der Leser. Auf diesem Fundament setzendie Prinzipien von Wikiwebs, Blogging und Tagging auf. Jeder Benutzer kann seinen Teil bei-steuern und erweitert damit die Vielfalt der angebotenen Inhalte. Der Erfolg des Web 2.0 siehtsich durch Portale und Communities wie Flickr [www:Flickr] und Wikipedia [www:Wikipedia]bestätigt. Auch kommerzielle Unternehmungen haben diese Bewegung erkannt und nut-zen sie zum eigenen Vorteil, wie etwa die Kunden-Rezension von Amazon [www:Amazon].Die Grundlage dafür schaffte die technische Weiterentwicklung der Web-Applikationen ge-folgt von einer gesteigerten Benutzerakzeptanz. Die leichte Bedienbarkeit (engl. usability)der Web-Anwendungen steht im Vordergrund und mit innovativen Benutzeroberflächen wirdein reichhaltiges Benutzererlebnis (engl. rich user experience) geschaffen. Mit dem Ein-satz von leichtgewichtigen Technologien wie JavaScript, DHTML und Ajax (Abschnitt 4.2.3)verblasst der technische Vorsprung von Desktop zu Web-Applikationen zunehmend. Web-Anwendungen gewinnen an Fähigkeiten und bieten mit reichhaltigen Oberflächen eine fastäquivalente Bedienbarkeit zu typischen Desktop-Anwendungen.

4. Design und Modellierung 81

Die Web 2.0 Technologien sollen bei Entwicklung der Benutzeroberfläche berücksichtigt wer-den und eine verbesserte Interaktivität der Anwender ermöglichen.

4.2.3. Ajax

Ajax2 (Asynchrones JavaScript und XML) beschreibt eine Technik, mit der innerhalb vonHTML-Seiten weitere Anfragen an einen Webserver gestellt werden können. Damit wird esmöglich, die Funktionalität von Web-Applikationen reichhaltiger zu gestalten und interaktiveBedienelemente, wie sie aus Desktop-Applikationen bekannt sind, in das Web zu integrieren.Um dieses Ziel zu erreichen, vereint Ajax den Einsatz der folgenden Technologien [Garrett,2005]:

• Standardisierte Darstellung mit XHTML3 und CSS4

• Dynamische Ausgabe und Interaktion über das Document Object Model (DOM5)

• Datenaustausch und Veränderung mit XML6 und XSLT7

• Asynchroner Abruf von Daten durch XMLHttpRequests

• JavaScript als verbindende Programmiersprache

In der Praxis bedeutet dies, dass Ajax eine Schnittstelle bietet, die auch zwischen den Sei-tenwechseln eine Kommunikationsverbindung zum Server bereitstellt, um HTTP-Anfragenim Hintergrund zu senden und die Antworten direkt in die aktuelle HTML-Seite einzufügen.Die vom Browser angeforderten Daten können nicht nur in Form von XML, sondern auch inbeliebigen Formaten wie z.B. HTML und JavaScript vom Server übermittelt werden. Im All-gemeinen wird auf die Eingaben und Interaktionen der Benutzer unmittelbar reagiert, ohneunnötig Overhead zu erzeugen. Es werden nur die jeweils gewünschten Daten an den Brow-ser gesendet und der Abruf einer gesamten HTML-Seite wird umgangen. Die Wartezeitenfür den Benutzer werden verkürzt und verbessern die Bedienbarkeit der Applikation. Bei derErstellung einer Web-Applikation mit Ajax ergeben sich unter anderem neue Anforderungenbei der Gestaltung des Seitenflusses (engl. page flow), die den Entwicklungsprozess kom-plexer gestalten. Es gibt aber bereits für Ajax adaptierte Entwicklungsmuster, die Methodenzur Lösung typischer Problemstellungen vorgeben [Crane und Pascarello, 2006].

2Ein Begriff den Jesse James Garrett von Adaptive Path geprägt hat. [Garrett, 2005]3Extensible HyperText Markup Language [www:XHTML]4Cascading Style Sheets [www:CSS]5API für den Zugriff auf HTML/XML-Dokumente [www:DOM]6Extensible Markup Language [www:XML]7Extensible Stylesheet Language Transformation [www:XSLT]

5. Realisierung

Nachdem das Design im vorherigen Kapitel 4 erörtert wurde, werden hier ausgewählte De-tails der prototypischen Implementierung des Zeitplanungssystems dargestellt. Zuerst wer-den die eingesetzten Technologien erläutert sowie der Aufbau des Systems vorgestellt. ZurErstellung eines Zeitplans wird von dem Prototyp eine Planungskomponente benutzt, derenRealisierung hier genauer betrachtet wird. Abschließend folgt ein Überblick des erstelltenPrototypen, der den Einsatz des Systems und die enthaltenen Funktionalitäten kurz vorstellt.Der vollständige Quelltext des Prototypen befindet sich auf der beiliegenden CD, nähereszum Inhalt ist dem Anhang C zu entnehmen.

5.1. Implementierung des Prototyps

5.1.1. Verwendete Technologie

Die Umgebung für die Implementierung des Prototyps bildet eine LAMP1 Plattform. DieseKombination freier Software Programme bildet zusammen einen flexiblen und skalierbarenWeb-Server mit Datenbankanbindung. Aufgrund der geringen Kosten ist LAMP eine sehrgute Alternative im Vergleich zum Einsatz kommerzieller Web-Plattformen.

Die Implementierung der Web-Applikation wird mit der Skriptsprache PHP 52 vorgenommen.Mit der Einführung der Version 5 entwickelte sich PHP zu einer ausgewachsenen objektori-entierten Programmiersprache. Das neue Objektmodell unterstützt die Auszeichnung derZugreifbarkeit von Klassenvariablen und Klassenmethoden sowie die Deklaration von Kon-struktoren bzw. Destruktoren. Zusätzlich wird die Introspektion eines objektorientierten Sys-tems mit der Erweiterung durch die Reflection API etabliert, welche unter anderem bei derÜberprüfung der Systemfunktionalität durch Unit-Tests Verwendung findet. Die Umsetzungvon Entwurfsmustern aus dem Umfeld der objektorientierten Programmierung ist mit demneu eingeführten Objektmodell ebenfalls gegeben [Bergmann, 2005].

1LAMP ist ein Akronym für Linux, Apache, MySQL, PHP, das von Michael Kunze geprägt wurde. [Kunze,1998]

2Die aktuelle Version von PHP ist abrufbar unter [www:PHP] (benutzt wurde die Version 5.1.2 vom 12.1.2006)

5. Realisierung 83

Die Entwicklung der Anwendung stützt sich außerdem auf das Web-Applikations FrameworkSymfony3. Symfony ist ein Open-Source Framework für PHP 5, mit dem Ziel die, Entwicklungund Wartung von Web-Applikationen zu beschleunigen und einfacher zu gestalten. Es imple-mentiert eine Drei-Schichten-Architektur nach dem Model-View-Controller Schema (MVC)und unterstützt die Abbildung von objektorientierten Daten auf eine relationale Datenbank(engl. object relational mapping, ORM). Inspiriert von Ruby on Rails4 wurden auch Funk-tionen für das Scaffolding, zur automatisierten Generierung von Programmcode für CRUD-Operationen, in das Framework integriert. Symfony fügt sich mit einem klaren Design in dieagilen Entwicklungsprozesse für Web-Anwendungen ein und unterstützt die Anwendung vonDesignprinzipien wie z.B. DRY (Don’t repeat yourself). Das Framework verfügt zusätzlichüber Werkzeuge zur Erstellung von Unit-Tests und der Klassendokumentation.

3Symfony Project [www:Symfony] (benutzt wurde die Version 0.6.1 vom 7.3.2006)4Ruby on Rails Web Application Framework [www:Rails]

5. Realisierung 84

5.1.2. Aufbau der Web-Applikation

Die Abbildung 5.1 zeigt den Seitenfluss (engl. page flow) der Web-Applikation in Form einesZustandsdiagramms. Sie liefert einen Überblick wie die Benutzer in der Applikation navigie-ren. Nach der erfolgreichen Authentifizierung über die Login Seite kann der Benutzer überdas Navigationsmenü zu den Komponenten der Anwendung gelangen, wie dem Zeitplan,der Ereignisverwaltung und der Benutzerverwaltung. Das Navigationsmenü ist ein Teil je-der HTML-Seite (engl. partial web page) innerhalb der Applikation und wird von allen Seiteninkludiert und angezeigt, ausgenommen der Login Seite.

Abbildung 5.1.: Seitenfluss der Web-Applikation

Die Implementierung des Seitenflusses wird über den Controller5 umgesetzt, welcher alsVermittler zwischen Datenmodell (engl. model) und Darstellung (engl. view) agiert und einwichtiger Teil des MVC Paradigmas ist. Der Controller erlaubt es, eine komplexe Logik für dieNavigation und Abfolge der Webseiten in der Anwendung zu definieren. Der Controller hat

5Gemeint ist hier die Klasse sfController des Symfony Frameworks [www:Symfony]

5. Realisierung 85

dabei Zugriff auf die Variablen der Benutzersession und kann damit ein zustandsabhängi-ges Regelwerk an Routen und Weiterleitungen festlegen. Grundsätzlich werden alle HTTP-Anfragen an die Applikation zunächst von dem Controller verarbeitet, somit ist es möglichan zentraler Stelle Filter und Regeln zu etablieren. Wird beispielsweise für eine Aktion dieAuthentifizierung des Benutzers vorausgesetzt, kann der Controller die Anfrage zurück aufdie Login-Seite leiten.

In dem Zustandsdiagramm 5.1 sind die Aktionen, die über Ajax realisiert wurden, mit blaugekennzeichnet. Die Ajax Funktionalität unterstützt beim Darstellen der Wochenübersicht dieAuswahl der angezeigten Woche und liefert in der Ereignisverwaltung die erfassten Zeitenzu ausgewählten Ereignissen (siehe Abschnitt 5.1.4).

5.1.3. Realisierung der Planungskomponente

Die Grundlage der Planungskomponente bildet die abstrakte Klasse SchedulerBase, die At-tribute und wiederverwendbare Methoden für die abgeleiteten Planer-Klassen bereitstellt.Mit der Definition der verschiedenen Ereignistypen aus der Anforderungsanalyse (Abschnitt3.3) ergeben sich für die Planer typenabhängige Planungsverhalten. Im Grunde lässt sichdie Modellierung dieser Verhalten aber auf die drei nachfolgend erläuterten Methoden redu-zieren. Der einzelne oder kombinierte Einsatz dieser Methoden ermöglicht die Planung allervorhandenen Ereignistypen.

processStaticEvent Diese Methode stellt einen Algorithmus zur Planung aller Ereignissemit einem fixen Start- und Endzeitpunkt bereit. Den zeitlichen Rahmen für die Planung bil-det der gesamte Kalender. Die generierten Kalendereinträge sind nicht an die noch freienZeitressourcen gebunden, sondern werden, wie von dem Ereignis angegeben, unverändertin den Kalender übernommen. Ein Ereignis wird von der Methode immer vollständig einge-plant, was bedeutet, dass zwei oder mehrere „statische“ Ereignisse auch parallel im Kalen-der liegen können. Als Ereignisse mit fixem Start- und Endzeitpunkt werden die Objekte derKlassen Appointment und Track mit diesem Algorithmus in Kalendereinträge gewandelt.

processForwardFloatEvent Mit dieser Klassenmethode wird ein Algorithmus für die Pla-nung der Projektaufgaben (Abschnitt 3.5.2) bereitgestellt. Charakteristisch für diesen Vor-gang ist, dass nur eine Zeitspanne für die Ausführung der Aufgabe angegeben wird, wederein konkreter Tag noch eine Uhrzeit. Das von der Aufgabe bestimmte Zeitintervall setzt sichaus dem geschätzten Aufwand und einem Zeitpuffer zusammen. Der Algorithmus bestimmtalso selber die konkreten Zeitpunkte in Form der Kalendereinträge für die Ausführung der

5. Realisierung 86

Projektaktivität. Für die Bearbeitung der Aufgabe stehen die noch freien Zeitressourcen in-nerhalb der wöchentlichen Arbeitszeit des Mitarbeiters zur Verfügung. Zudem wird der Me-thode ein zeitlicher Rahmen vorgegeben, in dem die Projektaufgabe eingeplant werden soll.Da es zu diesem Zeitpunkt der Berechnung des Zeitplans unbekannt ist, ob die verfügbarenZeitressourcen für die vollständige Planung der Aufgabe ausreichen, kann nach der Ausfüh-rung der Methode ein Teil des geschätzten Aufwands noch übrig bleiben. Diese unvollständi-ge Planung der Projektaufgabe wird von dem Planer erkannt und erzeugt eine Warnmeldungfür den Benutzer. In Abhängigkeit des verwendeten Planers kann diese verbleibende Zeitauch weiter eingeplant werden, wie es etwa der ProblemSolver Planer tut.

Der Algorithmus geht nun so vor: Die Planung der Aufgabe erfolgt vom Startzeitpunkt zumEndzeitpunkt. Die von dem Algorithmus erstellten Kalendereinträge „fließen“ vom Startzeit-punkt Vorwärts in Richtung Zukunft. Daher entstand die Namensgebung für die Klassen-methode processForwardFloatEvent. Optional ist bei dem Aufruf der Methode die Angabeeines Endzeitpunkts, welcher das Planungsintervall nach oben beschränkt. Ist dieser nichtbestimmt, werden so viele Kalendereinträge erstellt, bis der Aufgabenaufwand vollständigeingeplant ist.

processBackwardFloatEvent Diese Methode arbeitet im Prinzip wie der Algorithmus derprocessForwardFloatEvent, nur eben in entgegengesetzter Richtung. Die erstellten Kalende-reinträge „fließen“ hier in Richtung Vergangenheit. Das Planungsintervall wird der Methodeebenfalls vorgegeben und der Algorithmus plant von dem Endzeitpunkt zum Startzeitpunkt.Der Zeitrahmen wird dabei auch von den verfügbaren Zeitressourcen in der wöchentlichenArbeitszeit des Mitarbeiters bestimmt. Die Angabe eines Startzeitpunkts ist dabei optional,wird aber als sinnvoll erachtet.

5.1.4. Ajax in Aktion

Die in Abschnitt 4.2.3 vorgestellte Methode, Web-Applikationen mit dem Einsatz von Ajaxinteraktiver zu gestalten, wird in dem folgenden Beispiel verdeutlicht. Für die Erstellung undVerwaltung von Aufgaben, Meilensteinen oder Terminen wird dem Benutzer eine Liste derzur Zeit aktiven Ereignisse angezeigt (Abbildung 5.2). Um nun gezielt von einem einzelnenEreignis die bereits erfasste Zeit anzuzeigen, wird mit einem Mausklick auf das Uhrensymbolüber Ajax eine weitere HTTP-Anfrage an den Web-Server geschickt. Der Server ermittelt ausder Datenbank die dem Ereignis zugeordneten Zeiten und erstellt aus den Daten eine partiel-le HTML-Seite. Die vom Server gelieferte Antwort wird direkt über eine DOM-Manipulation indie bereits angezeigte HTML-Seite eingefügt. Die detaillierte Übersicht der erfassten Zeiteneiner Aufgabe werden dann in der Liste der Ereignisse entsprechend ergänzt. In der Praxis

5. Realisierung 87

bedeutet es eine Reduzierung der Ladezeit von HTML-Seiten, da zunächst auf die Über-tragung von versteckten Detailinformationen einzelner Seitenelemente verzichtet wird. Erstdurch den expliziten Aufruf des Benutzers werden die angeforderten Informationen nach-träglich in die Webseite injiziert.

Abbildung 5.2.: Einsatz von Ajax in der Ereignisverwaltung

5.2. Einsatz des Systems

Der Prototyp des Systems umfasst neben der Authentifikation und Benutzerverwaltung zu-nächst die wesentlichen Funktionalitäten zur Zeitplanung und der Zeiterfassung der Mitar-beiter. Diese werden in dem folgenden Abschnitt vorgestellt und erläutert. Das Design desSystems orientiert sich an dem Styleguide für Web-Applikationen der GAIA AG. Eine Verän-derung des Layouts kann aber durch Anpassung des Cascading Style Sheets (CSS) vorge-nommen werden.

5.2.1. Ereignisverwaltung

Die Ereignisverwaltung liefert eine Übersicht der aktuellen Aktivitäten eines Mitarbeiters (Ab-bildung 5.2). Die Einteilung in Aufgaben, Termine und Meilensteine erfolgt entsprechend der

5. Realisierung 88

bereits vorgestellten Ereignistypen (Abschnitt 3.5). Über die Ereignisverwaltung werden alleVeränderungen an den Eigenschaften der einzelnen Ereignisse vorgenommen. Die Bedieno-berfläche zur Bearbeitung eines Ereignisses teilt sich in zwei Bereiche (Abbildung 5.3). Imoberen Bereich werden allgemeine Eigenschaften angezeigt, die unabhängig vom gewähl-ten Ereignistyp sind. Hier werden Titel und eine detaillierte Beschreibung des Ereignissesgespeichert. In der Beschreibung können weitere Notizen und Schlagwörter zur näherenErklärung als Freitext formuliert werden.

Abbildung 5.3.: Bearbeiten eines Ereignisses

Im unteren Bereich werden die speziellen Eigenschaften eines Ereignistyps angezeigt. Hierwerden neben den zeitlichen Eigenschaften wie Start- und Endzeitpunkt, die Dauer (Sollauf-wand) und der Fortschritt des Ereignisses vom Mitarbeiter abgeschätzt und gespeichert. Mitder seperaten Erfassung von geschätztem Fortschritt und aufgewendeter Zeit, können imProjektverlauf kritische Aufgaben identifiziert werden. Durch die wählbaren Prioritäten kön-nen bei der Berechnung des Zeitplans gezielt Aufgaben bevorzugt behandelt werden. DasSichtbarkeitsattribut eines Ereignisses beschreibt die Art der Veröffentlichung innerhalb derApplikation. In Abhängigkeit von den Benutzerrechten können auch andere Mitarbeiter aufdie Zeitplanung der anderen zugreifen. Insbesondere, um die aktuelle Auslastung einzelnerMitarbeiter zu ermitteln. Alle Aktivitäten, die mit dem Attribut „geschäftlich“ gekennzeichnet

5. Realisierung 89

sind können von dem Mitarbeiter selbst und der Projektleitung eingesehen werden. „Öffent-liche“ Aktivitäten können unternehmensweit von allen Mitarbeitern angesehen werden. „Pri-vate“ Termine und Aufgaben sind im Gegensatz hierzu nur von dem Mitarbeiter selbst ein-sehbar. Die Auswahl der Farbe eines Ereignisses wird nach den Präferenzen des Anwendersvorgenommen. Die Farbwahl hilft bei der Einordnung bestimmter Aufgaben oder Termine.

5.2.2. Zeitplanung

Die Darstellung der Zeitplanung eines Anwenders erfolgt in einer Wochenübersicht und äh-nelt dem Format eines Stundenplans. Entscheidend für den verfügbaren Planungszeitraumist die wöchentliche Arbeitszeit des Mitarbeiters. Mit Ausnahme der festen Termine und Mei-lensteine, werden die Aufgaben nur innerhalb der täglichen Arbeitszeit des Mitarbeiters ein-geplant. In der Benutzerverwaltung wird ein Wochenschema zur Definition der wöchentli-chen Arbeitszeit hinterlegt. Die Berechnung des Zeitplans erfolgt immer von dem aktuellenZeitpunkt aus. Die bereits erfassten Zeiten einzelner Aktivitäten werden dabei ebenfalls be-rücksichtigt. Bei der Erstellung des Zeitplans ordnet die Planungskomponente die einzelnenEreignisse zunächst nach der Priorität und führt dann in der festgelegten Reihenfolge dieBerechnung durch. Gegebenenfalls werden dabei Ereignisse vom Typ Aufgabe in mehrereKalendereinträge unterteilt, wie z.B. das Ereignis „Aufgabe 4“ in Abbildung 5.4, das, in dreiKalendereinträge unterteilt, auf zwei Kalendertage eingeplant wurde. Desweiteren werdenPlanungsprobleme in der Kalenderdarstellung hervorgehoben. In der Wochenübersicht inAbbildung 5.4 bleibt nicht genügend Zeit, um die geschätzte Ereignisdauer der „Aufgabe 3“komplett einzuplanen. Die „Aufgabe 3“ hat einen fixen Endzeitpunkt am 3.4 um 18:00. DiesesPlanungsproblem wird dem Anwender mit einem rot gefärbten Ereignis in der Vergangenheitvisualisiert. Der Benutzer muss nun reagieren und den Planungsfehler durch die Verände-rung der Ereigniseigenschaften beheben. Eine weitere Möglichkeit besteht darin, das Sys-tem einen Vorschlag zur Konfliktlösung machen zu lassen, in dem dem Ereignis ein andererPlaner (z.B. ProblemSolver ) zugewiesen wird. In diesem Beispiel würde das System dannversuchen den Konflikt zu lösen und die Zeitplanung von „Aufgabe 3“ am nächsten Tag fort-setzen sowie den Endzeitpunkt entsprechend verschieben. Dieses sind lediglich Vorschlägedes Systems, welche explizit durch den Anwender auf die Durchführbarkeit geprüft werdenmüssen. Zudem müssen entscheidende Veränderungen mit der Projektleitung kommuniziertwerden.

5. Realisierung 90

Abbildung 5.4.: Wochenübersicht der Zeitplanung

5.2.3. Zeiterfassung

Innerhalb der Ereignisverwaltung wurde eine Zeiterfassung integriert (Abbildung 5.5). Hierkann der Anwender parallel zu seiner Tätigkeit den zeitlichen Aufwand direkt erfassen. Nachdem Prinzip einer Stoppuhr können für die aktiven Ereignisse die Aufwandszeiten erfasstwerden. Dies gilt für die Ereignistypen Aufgaben und Termine, aber nicht für die Meilen-steine, da diese keine zeitliche Spanne besitzen. Die Beendung der Zeiterfassung einesEreignisses kann direkt vom Anwender kommentiert werden, um nähere Informationen überdie durchgeführten Arbeitsschritte zu dokumentieren. Bei einer abschließenden Analyse desVorgehens einzelner Aktivitäten gibt es Aufschluss über konkrete Arbeitsschritte, wann dieseerfolgt sind und welcher Aufwand entstanden ist.

5. Realisierung 91

Abbildung 5.5.: Zeiterfassung

6. Zusammenfassung und Ausblick

6.1. Stand der Arbeit

Im Rahmen dieser Arbeit wurde ein System zur Unterstützung der Zeitplanung in agilen Pro-jektabläufen entwickelt. Dabei wurde exemplarisch die GAIA AG als ein mittelständischesUnternehmen, das im Projektgeschäft hochinnovative Individuallösungen für seine Kundenerstellt, betrachtet. Diese Projekte verlangen dabei einen Stamm von gut ausgebildeten Spe-zialisten aus unterschiedlichen Arbeitsgebieten. Anhand der Organisation und Planung derProjekte sowie den Arbeitsweisen der Mitarbeiter wurden die Anforderungen an das Zeitpla-nungssystem formuliert. Bei der Organisation und Durchführung einer iterativen Produktent-wicklung mit agilen Projektmanagementmethoden, verlagert sich die Planung von Projek-taufgaben zum Erreichen der geplanten Iterationsziele hauptsächlich auf das Projektteam.Im Gegensatz zum klassischen Projektmanagement, welches eine detaillierte Ablaufplanungvornimmt, hat sich im agilen Projektmanagement eine leichtgewichtige Zeitplanung als eineangemessene Unterstützung für die Projektmitarbeiter herausgestellt.

In dieser Arbeit wurde ein lauffähiger Prototyp implementiert, der die Komponenten der Zeit-planung und Zeiterfassung in einem System vereint. Das System befindet sich aktuell imEinsatz bei der GAIA AG. Es unterstützt die Mitarbeiter bei ihrer eigenverantwortlichen Zeit-planung von Aufgaben und Terminen aus verschiedenen Projekten. Das System vereint da-bei die Darstellung von Terminen und Projektaufgaben in Form eines Terminkalenders. Eineintegrierte Planungskomponente sorgt dafür, dass die Projektaufgaben anhand ihrer defi-nierten zeitlichen Eigenschaften geplant und automatisch in eine Kalenderdarstellung über-tragen werden. Die Zeitplanung richtet sich dabei nach den individuellen Planungseinträ-gen eines Mitarbeiters sowie seiner wöchentlichen Arbeitszeit. Durch die automatisierte Pla-nung der Projektaufgaben reduziert sich der Pflegeaufwand beispielsweise bei verändertenPrioritäten. Somit lassen sich Planungsszenarien schnell editieren und darstellten. Folglichkönnen sich die Mitarbeiter einfach über ihre aktuelle Arbeitslast informieren und ein bes-seres Workload-Management durchführen. Denn nur unter Berücksichtigung der gesamtenArbeitsbelastung aus mehreren Projekten können realistische Ziele zu Beginn einer Iterationmit der Projektleitung vereinbart werden. Zudem kann die Beantwortung von Ressourcenan-fragen für zukünftige Projekte zeitnah und begründet erfolgen. Desweiteren werden mit derZeiterfassung kontinuierlich Ist-Daten bereitgestellt, welche direkt wieder in die Zeitplanung

6. Zusammenfassung und Ausblick 93

einfließen. Der Mitarbeiter wird darauf hingewiesen, wenn der geschätzte Soll-Aufwand einerProjektaufgabe bereits aufgebraucht wurde. Der direkte Soll-/Ist Vergleich bildet die Basis fürbessere Schätzungen vergleichbarer Aufgaben in zukünftigen Projekten. Das System stelltden Mitarbeitern in agilen Projektabläufen eine sinnvolle Unterstützung ihrer Zeitplanungs-aktivitäten zur Verfügung.

6.2. Weiterentwicklung

Eine Weiterentwicklung des erstellten Systems im Hinblick auf den Einsatz für die Zeitpla-nung im klassischen Projektmanagement lässt sich durchaus vornehmen. Hier ist eine Distri-bution von Projektaufgaben meist auf Grundlage erstellter Projektpläne, z.B. Netzpläne, vor-rangig. Das System kann dafür eingesetzt werden, aktualisierte Planversionen zu verteilenund über die vorhandene Zeiterfassung Ist-Daten zu protokollieren und bereitzustellen. Da-für muss das System um eine Planungskomponente zur Erstellung von Projektplänen bzw.Netzplänen erweitert werden. Dies kann beispielsweise durch die Anbindung externer Pro-jektmanagement Systeme oder durch die Implementierung einer integrierten Systemkompo-nente erfolgen. Zudem können durch die im System modularisierten Planungsalgorithmenebenfalls neue Algorithmen für die Zeitplanung hinzugefügt werden, z.B. basierend auf denAnsätzen des Operations Research.

Literaturverzeichnis

[37Signals 2006] 37SIGNALS: Getting Real - The smarter, faster, easier way to builda successful web application. (2006), April. – URL https://gettingreal.37signals.com. – Zugriffsdatum: 2006-04-20

[Beck 2000] BECK, Kent: Extreme Programming. 1. Auflage. Addison-Wesley, 2000. –ISBN 3-827-31709-6

[Bergmann 2005] BERGMANN, Sebastian: Professionelle Softwareentwicklung mit PHP 5.1. Auflage. Dpunkt-Verlag, 2005. – ISBN 3-898-64229-1

[Boehm und Turner 2003] BOEHM, Barry ; TURNER, Richard: Using risk to balanceagile and plan-driven methods. (2003), Juni. – URL http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/2/27119/01204376.pdf?tp=&arnumber=1204376&isnumber=27119. – Zugriffsdatum: 2006-04-20

[Bundschuh 2000] BUNDSCHUH, Manfred: Aufwandschätzung von IT-Projekten. 1. Aufla-ge. MITP-Verlag, 2000. – ISBN 3-826-60534-9

[Cockburn 2001] COCKBURN, Alistair: Writing Effective Use Cases. 1. Auflage. Addison-Wesley, 2001. – ISBN 0-201-70225-8

[Crane und Pascarello 2006] CRANE, Dave ; PASCARELLO, Eric: Ajax in Action. 1. Auflage.Manning Publications Co., 2006. – ISBN 1-932394-61-3

[DIN 69900 ] DIN: DIN 69900 - Netzplantechnik. Deutsches Institut für Normung, Frankfurt1983

[DIN 69901 ] DIN: DIN 69901 - Projektmanagement. Deutsches Institut für Normung,Frankfurt 1980

[Domschke und Drexl 2005] DOMSCHKE, Wolfgang ; DREXL, Andreas: Einführung in Ope-rations Research. 6. Auflage. Springer-Verlag, 2005. – ISBN 3-540-23431-4

[Gamma 1996] GAMMA, Erich: Entwurfsmuster - Elemente wiederverwendbarer objektori-entierter Software. 1. Auflage. Addison-Wesley, 1996. – ISBN 3-8273-1862-9

Literaturverzeichnis 95

[Garrett 2005] GARRETT, Jesse J.: Ajax: A New Approach to Web Applications. (2005),Februar. – URL http://www.adaptivepath.com/publications/essays/archives/000385.php. – Zugriffsdatum: 2006-04-07

[Goldmann und Schraudolph 2004] GOLDMANN, Martin ; SCHRAUDOLPH, Markus: PHP 5- Die Neuerungen. 1. Auflage. Galileo Press, 2004. – ISBN 3-898-42490-1

[Highsmith 2004] HIGHSMITH, Jim: Agile Project Management. Creating Innovative Pro-ducts. 1. Auflage. Addison-Wesley, 2004. – ISBN 0-3212-1977-5

[Humphrey 2005] HUMPHREY, Watt S.: PSP A Self-Improvement Process for SoftwareEngineers. 1. Auflage. Addison-Wesley, 2005. – ISBN 0-321-30549-3

[Hunt und Thomas 2003] HUNT, Andrew ; THOMAS, David: Der Pragmatische Program-mierer. 1. Auflage. Hanser, 2003. – ISBN 3-446-22309-6

[IAT 2006] LATNIAK, Erich ; GERLMAIER, Anja: Zwischen Innovation und alltäglichem Klein-krieg - Zur Belastungssituation von IT-Beschäftigten. (2006), April. – URL http://www.iatge.de/iat-report/2006/report2006-04.pdf. – Zugriffsdatum: 2006-04-20

[Jeffries und Anderson 2001] JEFFRIES, Ron ; ANDERSON, Ann: Extreme Programminginstalled. 1. Auflage. Addison-Wesley, 2001. – ISBN 3-827-31818-1

[Kunze 1998] KUNZE, Michael: Let There be Light. (1998), Dezember. – URL http://www.heise.de/ct/english/98/12/230/. – Zugriffsdatum: 2006-04-07

[Larman 2005] LARMAN, Craig: Applying UML and Patterns. 3. Auflage. Prentice HallPTR, 2005. – ISBN 0-13-148906-2

[Litke 1995] LITKE, Hans-Dieter: Projektmanagement: Methoden, Techniken, Verhaltens-weisen. 3. Auflage. Carl Hanser, 1995. – ISBN 3-446-18310-8

[Nokes und Greenwood 2003] NOKES, Sebastian ; GREENWOOD, Alan: The DefinitiveGuide to Project Management. 1. Auflage. Prentice Hall PTR, 2003. – ISBN 0-273-66397-6

[Oestereich 2005] OESTEREICH, Bernd: Analyse und Design mit UML 2. 7. Auflage.Oldenbourg, 2005. – ISBN 3-486-57654-2

[O’Reilly 2005] O’REILLY, Tim: What is Web 2.0 - Design Patterns andBusiness Models for the Next Generation of Software. (2005), Oktober.– URL http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html. – Zugriffsdatum: 2006-04-07

[Raasch 1993] RAASCH, Jörg: Systementwicklung mit strukturierten Methoden. 3. Auflage.Hanser Verlag, 1993. – ISBN 3-446-17490-7

Literaturverzeichnis 96

[Radicati 2005] RADICATI GROUP: Exchange Server Market Share Statistics, 2005.(2005), Juli. – URL http://www.microsoft.com/exchange/evaluation/compare/market_share.mspx. – Zugriffsdatum: 2006-04-07

[Schmidt 2000] SCHMIDT, Götz: Methode und Techniken der Organisation. 12. Auflage.Verlag Götz Schmidt, 2000. – ISBN 3-921-313-627

[Thomas 2005] THOMAS, Dave: Programming Ruby. 2. Auflage. The Pragmatic Program-mers, 2005. – ISBN 0-9745140-5-5

[Thomas und Hansson 2005] THOMAS, Dave ; HANSSON, David H.: Agile Web Develop-ment with Rails. 1. Auflage. The Pragmatic Programmers, 2005. – ISBN 0-9766940-0-X

[Weiss 2005] DR. WEISS, Mario ; LEHNERT, Oliver: Interview, Maßarbeit statt Konfekti-onsware. Wissensmanagement Magazin 5/05, Bertelsmann Verlag, 2005. – 34,35 S

[www:AgileManifesto ] BECK, K. ; COCKBURN, A. ; FOWLER, M. ; HUNT, A. ; THO-MAS, D.: Manifesto for Agile Software Development. . – URL http://www.agilemanifesto.org. – Zugriffsdatum: 2006-04-07

[www:Allocatus ] ALLOCATUS: Firmenseite; Allocatus. . – URL http://www.allocatus.com. – Zugriffsdatum: 2006-04-07

[www:Amazon ] AMAZON INC.: Firmenseite; Amazon. . – URL http://www.amazon.de. – Zugriffsdatum: 2006-04-07

[www:Applet ] SUN MICROSYSTEMS, INC.: Produktseite; Java Applet. . – URL http://java.sun.com/applets/. – Zugriffsdatum: 2006-04-07

[www:Braintool ] BRAINTOOL SOFTWARE GMBH: Firmenseite; Braintool Software GmbH.. – URL http://www.braintool.com. – Zugriffsdatum: 2006-04-07

[www:CSS ] W3C: CSS, Cascading Style Sheets Homepage. . – URL http://www.w3.org/Style/CSS/. – Zugriffsdatum: 2006-04-07

[www:DOM ] W3C: DOM, Document Object Model Homepage. . – URL http://www.w3.org/DOM/. – Zugriffsdatum: 2006-04-07

[www:Flash ] ADOBE SYSTEMS, INC. ; FORMERLY MACROMEDIA: Produktseite; Flash.. – URL http://www.macromedia.com/software/flash/. – Zugriffsdatum:2006-04-07

[www:Flickr ] YAHOO! INC.: Projektseite; Flickr. . – URL http://www.flickr.com.– Zugriffsdatum: 2006-04-07

Literaturverzeichnis 97

[www:NetOffice ] NETOFFICE: Projektseite; NetOffice - A free solution for networked teamwork. . – URL http://netoffice.sourceforge.net. – Zugriffsdatum: 2006-04-07

[www:Outlook ] MICROSOFT CORPORATION: Produktseite; Microsoft Outlook. . – URLhttp://www.microsoft.com/outlook/. – Zugriffsdatum: 2006-04-07

[www:PHP ] THE PHP GROUP: Projektseite; Programmiersprache PHP. . – URL http://www.php.net. – Zugriffsdatum: 2006-04-07

[www:Project ] MICROSOFT CORPORATION: Produktseite; Microsoft Project. . – URLhttp://www.microsoft.com/project/. – Zugriffsdatum: 2006-04-07

[www:Rails ] HANSSON, DAVID H. ; RUBY ON RAILS TEAM: Projektseite; Ruby on Rails -Web Application Framework. . – URL http://www.rubyonrails.com. – Zugriffs-datum: 2006-04-07

[www:RFC2445 ] NETWORK WORKING GROUP: RFC2445, Internet Calendaring andScheduling Core Object Specification. . – URL http://www.ietf.org/rfc/rfc2445.txt. – Zugriffsdatum: 2006-04-07

[www:SAP ] SAP AG: Firmenseite; SAP AG. . – URL http://www.sap.com/germany/. – Zugriffsdatum: 2006-04-07

[www:Scrum ] ADVANCED DEVELOPMENT METHODS, INC.: Scrum. . – URL http://www.controlchaos.com. – Zugriffsdatum: 2006-04-07

[www:Symfony ] SYMFONY TEAM: Projektseite; Symfony - Web Application Framework. .– URL http://www.symfony-project.com. – Zugriffsdatum: 2006-04-07

[www:Wikipedia ] WIKIMEDIA FOUNDATION INC.: Projektseite; Wikipedia. . – URL http://www.wikipedia.org. – Zugriffsdatum: 2006-04-07

[www:XHTML ] W3C: XHTML, Extensible HyperText Markup Language Homepage. . –URL http://www.w3.org/TR/xhtml1/. – Zugriffsdatum: 2006-04-07

[www:XML ] W3C: XML, Extensible Markup Language Homepage. . – URL http://www.w3.org/XML/. – Zugriffsdatum: 2006-04-07

[www:XSLT ] W3C: XSLT, XSL Transformations Homepage. . – URL http://www.w3.org/TR/xslt20/. – Zugriffsdatum: 2006-04-07

A. Agiles Manifest

„Agil“ steht für „beweglich, wendig, flink“, ein agiler Prozess in der Softwareentwicklung undinnerhalb des Projektmanagements hat die Fähigkeit, auf Veränderungen schnell zu rea-gieren. Es geht darum, Prozesse flexibel und leichtgewichtig zu halten, damit sie selbst ineinem sich schnell ändernden Umfeld anpassungsfähig bleiben. Prinzipien für die agile Soft-wareentwicklung wurden im Jahr 2001 von einer Gruppe von Softwareentwicklern formuliert.Entstanden ist das „Agile Manifest1“, welches folgende Leitsätze definiert:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

Das „Agile Manifest“ bezieht sich auf den Prozess der Softwareentwicklung. Aber die prak-tische Anwendung der agilen Prinzipien auf das Management von Projekten anderer Artist durchaus möglich und üblich. Eine Verallgemeinerung der agilen Ansätze im Bezug aufdie innovative Produktentwicklung findet sich z.B. in dem Buch „Agile Project Management.Creating Innovative Products.“ [Highsmith, 2004]. Als ein weiterer agiler Entwicklungspro-zess ist noch Scrum zu nennen, dessen Ursprung eine Taktik eines Spielzugs im Rugbyist, und zunächst durch Hirotaka Takeuchi und Ikujiro Nonaka2 auf die Produktentwicklungübertragen wurde, und anschließlich von Jeff Sutherland und Ken Schwaber3 auf die Soft-wareentwicklung angewandt wurde.

1Manifesto for Agile Software Development [www:AgileManifesto]2genannt in "The New New Product Development Game", Harvard Business Review, Jan-Feb 19863Agile Project Management with Scrum [www:Scrum]

B. Project Data Sheet

Abbildung B.1.: Beispiel eines Project Data Sheet [Highsmith, 2004]

C. Inhalt der beigefügten CD-ROM

Dieser Arbeit liegt eine CD-ROM mit folgender Verzeichnisstruktur bei:

• [ Ausarbeitung ]

– [ Bachelorarbeit ] beinhaltet diese Arbeit als PDF-Datei.

– [ Internet Quellen ] beinhaltet Kopien der referenzierten Internetseiten.

• [ Planning and Tracking ] beinhaltet die prototypische Implementierung desZeitplanungs- und Zeiterfassungssystem mit dem Symfony Framework.

• [ Software ] beinhaltet alle eingesetzten Softwareprodukte.

Danksagung

An dieser Stelle möchte ich mich bei allen bedanken, die an der Entstehung dieser Arbeitbeteiligt waren. Vielen Dank für die freundliche Unterstützung an die Mitarbeiter der GAIAAG. Ein besonderer Dank geht dabei an Matthias Stolt, der für alle meine Fragen immerein offenes Ohr hatte und seine Antworten, die mich kontinuierlich sowohl fachlich als auchmoralisch unterstützt haben. Weiter möchte ich meinen wissenschaftlichen Betreuern HerrnProf. Dr. Kai von Luck und Herrn Prof. Dr. Jörg Raasch für die freundliche Unterstützung undfür ihren vielseitigen fachlichen Rat danken. Ein großer Dank geht an Maren Sommerbeck,die sich Zeit genommen hat meine Arbeit Korrektur zu lesen. Ein riesengroßer Dank gehtan meine Eltern und meine Familie, ohne euch wäre das Ganze überhaupt nicht möglichgewesen. Bedanken möchte ich mich außerdem bei Prof. Dr. Erhard Gabriel, der mir mitseinen Ratschlägen nicht nur andere Perspektiven aufgezeigt hat, sondern auch über dieseArbeit hinaus Lebensweisheiten mit auf den Weg gegeben hat.

Versicherung über Selbstständigkeit

Hiermit versichere ich, dass ich die vorliegende Arbeit im Sinne der Prüfungsordnung nach§24(5) ohne fremde Hilfe selbstständig verfasst und nur die angegebenen Hilfsmittel benutzthabe.

Hamburg, 12. Mai 2006Ort, Datum Unterschrift