Bachelorarbeit. Steffan Schiewe Ein System zur Unterstützung der Zeitplanung für agile Projektabläufe

Transkript

1 Bachelorarbeit Steffan Schiewe Ein System zur Unterstützung der Zeitplanung für agile Projektabläufe Fakultät Technik und Informatik Studiendepartment Informatik Faculty of Engineering and Computer Science Department of Computer Science

2 Steffan Schiewe Ein System zur Unterstützung der Zeitplanung für agile Projektabläufe Bachelorarbeit eingereicht im Rahmen der Bachelorprüfung im Studiengang Technische Informatik am Studiendepartment Informatik der Fakultät Technik und Informatik der Hochschule für Angewandte Wissenschaften Hamburg Betreuender Prüfer : Prof. Dr. Kai von Luck Zweitgutachter : Prof. Dr. Jörg Raasch Abgegeben am 12. Mai 2006

3 Steffan Schiewe Thema der Bachelorarbeit Ein System zur Unterstützung der Zeitplanung für agile Projektabläufe Stichworte Zeitplanung, Zeiterfassung, Projektmanagement, agile Entwicklung, Workload- Management Kurzzusammenfassung Es hat sich in der Praxis bewährt hochdynamische und innovative Projekte durch agile Managementmethoden zu organisieren. Diese Projekte sind von kontinuierlicher Veränderung geprägt. Durch ein iteratives Vorgehen wird ein hohes Maß an Anpassungsfähigkeit gewährleistet. Der Projektmitarbeiter ist selbst verantwortlich für die Ablaufplanung und Koordination von einzelnen Projektaufgaben. In dieser Bachelorarbeit wurde ein System entwickelt, das die Projektmitarbeiter bei ihrer individuellen Zeitplanung unterstützt. Steffan Schiewe Title of the paper A software to support time planning in agile projects Keywords time planning, time registration, project management, agile development, workload management Abstract It is nowadays common practice to use agile management methods in highly dynamic and innovative projects. These kind of projects struggle with continuous change. The use of an iterative process provides a high standard of adaptibility. The project members are responsible for planning and coordination of their own project tasks. This bachelor thesis develops a system to support the project members time planning activities.

4 Inhaltsverzeichnis Abbildungsverzeichnis 7 1. Einleitung Motivation Ziele der Arbeit Grundlagen Fallstudie GAIA AG Autoren Informatiker Berater Projektkoordination in der GAIA AG Fazit Organisation und Planung von Projekten Das Projekt Projektmanagement Fazit Zeitplanung der Mitarbeiter Terminkalender Aufgabenlisten Fazit Überblick der Technologien Terminkalender Projektmanagement Software Zeiterfassungssysteme Ticketing Systeme Fazit Zusammenfassung

5 Inhaltsverzeichnis 5 3. Anforderungsanalyse Anwenderziele Einordnung des Systems Anforderungen Individuelle Zeitplanung Zeiterfassung Zugriff und Einsatzgebiet Eingrenzung Zeitplanungsproblem Definition Ereignis Ereignis Termin Ereignis Projektaufgabe Fazit Anwendungsfälle Systemumgebung Systemauthentifikation Verwaltung von Ereignissen Zeitplanung Zeiterfassung Verwaltung von Benutzern Design und Modellierung Systementwurf Konzeptionelle Fachklassen Klassendiagramm Szenario: Ablauf der Zeitplanung Szenario: Verwaltung von Ereignissen Szenario: Zeiterfassung Auswahl der Zielplattform Web-Technologie Web Ajax Realisierung Implementierung des Prototyps Verwendete Technologie Aufbau der Web-Applikation Realisierung der Planungskomponente Ajax in Aktion Einsatz des Systems Ereignisverwaltung Zeitplanung

6 Inhaltsverzeichnis Zeiterfassung Zusammenfassung und Ausblick Stand der Arbeit Weiterentwicklung Literaturverzeichnis 94 A. Agiles Manifest 98 B. Project Data Sheet 99 C. Inhalt der beigefügten CD-ROM 100

7 Abbildungsverzeichnis 1.1. Struktur der rollenbasierten Projektplanung Faktoren der Zeitplanung für einen Mitarbeiter Klassischer Informationsfluss zwischen Projekt- und Arbeitszeitplanung Informationsfluss in Projekten mit Verwaltungsautonomie der Mitarbeiter Einordnung des Systems Individuelle Zeitplanung mit dem System (reduzierte Darstellung) Ereignis mit definiertem Endtermin, Vorwärtsplanung Ereignis mit definiertem Endtermin, Rückwärtsplanung Ereignis mit definiertem Starttermin, Vorwärtsplanung Ereignis innerhalb eines definierten Zeitintervalls, Vorwärtsplanung Ereignis innerhalb eines definierten Zeitintervalls, Rückwärtsplanung Variables Ereignis ohne Start- und Endtermin, Vorwärtsplanung Anwendungsfälle des Systems Systemauthentifikation Verwaltung von Ereignissen Zeitplanung Zeiterfassung Verwaltung der Benutzer Konzeptionelle Fachklassen Klassendiagramm Initialisierung des Controller Objekts Berechnung des Zeitplans Verarbeitung der Ereignisse durch die zugeordneten Planer Planungsalgorithmus eines Termins (Appointment) Planungsalgorithmus einer Projektaufgabe (FloatingTask) Ereignisverwaltung Beginn der Zeiterfassung eines Ereignisses Beenden der Zeiterfassung eines Ereignisses

8 Abbildungsverzeichnis Seitenfluss der Web-Applikation Einsatz von Ajax in der Ereignisverwaltung Bearbeiten eines Ereignisses Wochenübersicht der Zeitplanung Zeiterfassung B.1. Beispiel eines Project Data Sheet [Highsmith, 2004]

9 1. Einleitung Die GAIA Unternehmensberatung ist in den Geschäftsbereichen Consulting, Gesundheitsund Wissensmanagement tätig. Ihr Kerngeschäft ist die Beratung von Unternehmen aus dem Gesundheitssektor. Ein heterogenes Team von Ärzten, Akademikern aus den Geistesund Naturwissenschaften, der Betriebswirtschaft und Informationstechnologie ermöglicht eine Ausrichtung auf die verschiedenen Geschäftsbereiche. In der Größenordnung von rund zwanzig Mitarbeitern ist die GAIA AG in dem Feld der mittelständischen Unternehmen anzusiedeln. 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 Zeitplanung und Zeiterfassung formuliert, und anhand dieser eine unterstützende Softwarelösung entwickelt wird Motivation In Consultingunternehmen ist das Projekt eine etablierte Organisationsform. Gleichzeitig durchgeführte Projekte gehören zum täglichen Geschäft. Hier können zwei unterschiedliche Perspektiven eingenommen werden bezogen auf das gesamte Projekt und auf den einzelnen 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 Projekte und die Projektmitarbeiter verrichten die einzelnen Arbeitspakete. Für jedes Projekt ergeben sich verbindliche Rahmenbedingungen wie Ressourcen, Budget und Termine, von denen der erfolgreiche Projektabschluss abhängt. Ein Projekt wird dabei für sich im Einzelnen organisiert und geplant. Zudem ist es klar abgegrenzt zu den anderen Projekten und Geschäftsvorgängen zu betrachten. Für eine solche Planung stehen bereits viele geeignete Werkzeuge aus den Bereichen des Projektmanagements und Operations Research bereit. In Unternehmen kommt es oft zur zeitlichen Überschneidung von mehreren Projekten. In

10 1. Einleitung 10 Abbildung 1.1 wird ein Szenario dargestellt, welches die Planungsstrukturen von drei Projekten zeigt, die zeitlich parallel durchgeführt werden. Die einzelnen Projekte bilden hier einen Rahmen, in dem alle Projektaktivitäten, wie z.b. Planung- und Projektaufgaben, definierten Rollen zugeordnet werden. Abbildung 1.1.: Struktur der rollenbasierten Projektplanung Wechselt man nun die Perspektive und betrachtet dieses Szenario aus der Sicht eines Mitarbeiters, so stellt sich dieses wie in Abbildung 1.2 dar. Der Mitarbeiter nimmt verschiedene Rollen in mehreren Projekten ein. Er hat die Rahmenbedingungen unterschiedlicher Projekte 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 P L 1 ). In den Projekten 2 und 3 gehört er zum Projektteam und hat bestimmte Arbeitspakete zu erledigen (Rolle P 2 M 1, P 3 M 1 ). Zudem muss er weitere Aktivitäten, wie das Tagesgeschäft, Besprechungen und Termine, mit seiner Zeitplanung vereinbaren.

11 1. Einleitung 11 Abbildung 1.2.: Faktoren der Zeitplanung für einen Mitarbeiter Der Mitarbeiter versucht, bei seiner eigenen Zeitplanung sowohl den zeitlichen Rahmenbedingungen der Projektaufgaben als auch denen des Tagesgeschäfts zu entsprechen. Diese Aufgabe gestaltet sich schwieriger, je mehr Projekte und damit verbundene Aktivitäten zu koordinieren sind. Die Einbeziehung in mehrere Projekte und das eigenverantwortliche Koordinieren unter komplexen Bedingungen erweisen sich als Hauptfaktor gesundheitlicher Belastung der Mitarbeiter. Dies belegt der aktuelle Report Zwischen Innovation und alltäglichem Kleinkrieg des Instituts für Arbeit und Technik Gelsenkirchen. Die Mitarbeiter sind häufig für mehrere Projekte oder Aufträge gleichzeitig zuständig und müssen ihren Arbeitseinsatz individuell koordinieren.... Häufig genannte Belastungen waren vor allem Probleme durch gleichzeitige Einbindung in mehreren Projekten, ungeplante Zusatzaufgaben sowie Behinderungen durch unzureichende Arbeitsmittel, fehlende Entscheidungen aus dem Management oder mangelnde Kundenkooperation. [IAT, 2006] Ein wesentliches Problem besteht hier im dauerhaften Zeitdruck, der unter anderem durch unzureichende Unterstützung in der individuellen Planung bedingt ist. Der Zeitdruck für die Projektmitarbeiter entsteht oft durch neue bzw. veränderte Anforderungen, die von dem Kunden über die Projektleitung an das Projektteam weitergegeben werden.

12 1. Einleitung 12 Da die zuvor geplanten Auslieferungstermine und Budgetlimits aber weiterhin als verbindlich gelten, erhöht dies die Belastung der Projektmitarbeiter zunehmend. Die Situation verschärft sich, wenn den Mitarbeitern unkoordinierte Anforderungen und zusätzliche Arbeitsaufträge von Projektverantwortlichen aus unterschiedlichen Projekten erteilt werden. Während auf der Seite der Projektplanung also feste Vorgaben für die Arbeitszeitplanung der Mitarbeiter entstehen, findet eine Rückkopplung zwischen Mitarbeiter und Planung kaum statt (Abbildung 1.3). Abbildung 1.3.: Klassischer Informationsfluss zwischen Projekt- und Arbeitszeitplanung In der klassischen Projektorganisation sind die Verantwortlichkeiten zwischen der Projektleitung und den Mitarbeitern fest unterteilt. Der Freiheitsgrad bei der Arbeitszeitplanung wird durch den Projektplan bedingt. In dynamischen Projekten hat der Projektmitarbeiter hat zu wenig Spielraum, seine eigene Zeitplanung geeignet zu koordinieren. Der Projektmitarbeiter sollte hier gewisse Einflussmöglichkeiten haben, um die Rahmenbedingungen seiner Zeitplanung und Organisation der ihm zugeteilten Projektaktivitäten mitzugestalten (Abbildung 1.4). In kleinen Projektteams kann die Projektplanung unter Berücksichtigung der Auslastungssituation der involvierten Mitarbeiter erfolgen. Diese intern kommunizierten Rahmenbedingungen können dann zum Bestandteil in den Verhandlungen mit dem Kunden gemacht werden, um damit einen realistischen Zeitrahmen für ein Projekt und die Projektmitarbeiter zu schaffen. Eine in Zusammenarbeit mit dem Projektteam entstandene Projektplanung, liefert hier Möglichkeiten zur entlastenden Arbeitsgestaltung und -planung der Mitarbeiter.

13 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 Projektleitung lediglich als Koordinator fungiert und die Projektmitarbeiter ein hohes Maß an Selbständigkeit und Verantwortung haben, muss die Zeitplanung der Mitarbeiter besonders behandelt und berücksichtigt werden. Neben den in der Projektplanung eingesetzten Werkzeugen sollte auch den Mitarbeitern für ihre individuelle Zeitplanung geeignete Unterstützung geboten werden, um die Planung effizienter und effektiver zu gestalten. Deshalb wird in dieser Arbeit ein System entworfen, das diesen Prozess der Zeitplanung adäquat unterstützt, um die Mitarbeiter zu entlasten und gleichzeitig für die Kunden stabile Projektgeschäfte zu erreichen.

14 1. Einleitung Ziele der Arbeit Im Rahmen dieser Arbeit wird ein System zur Unterstützung der Zeitplanung in agilen Projektabläufen entwickelt. Die Projektorganisation der GAIA AG wird dabei stellvertretend für mittelständische Unternehmen mit innovativer Produktentwicklung betrachtet. Anhand der Arbeitsweisen der Mitarbeiter werden die Anforderungen an das System formuliert. In Kapitel 2 werden zunächst die Geschäftsfelder und typischen Projekte der GAIA AG vorgestellt sowie die Arbeitsweisen und Methoden der Zeitplanung der Mitarbeiter analysiert. Es wird geklärt, ob das hier angewandte Vorgehen zur Organisation und Planung des klassischen oder des agilen Projektmanagement passt. Abschließend wird geprüft, inwieweit existierende Softwarelösungen auch Anforderungen agiler Projekte gerecht werden. In Kapitel 3 werden anhand der erarbeiteten Anwenderziele genaue Anforderungen an das Zeitplanungssystem analysiert und formuliert. Zudem erfolgt eine Abgrenzung der Systemumgebung und die Festlegung von Anwendungsfällen. In Kapitel 4 wird die Entstehung des Systementwurfs behandelt und in einem Klassenmodell umgesetzt. Danach werden die Vor- und Nachteile einer möglichen Zielplattform abgewogen und schließlich wird eine Auswahl getroffen. Das darauf folgende Kapitel 5 befasst sich mit der prototypischen Umsetzung des Systems zur Unterstützung der Zeitplanung. Hier werden die eingesetzten Technologien vorgestellt, Details der Realisierung erläutert und ein Überblick der erstellten Systemkomponenten gegeben. Eine Zusammenfassung der Ergebnisse und ein Ausblick, über die mögliche Weiterentwicklung des umgesetzten Systems, wird in Kapitel 6 beschrieben.

15 2. Grundlagen Dieses Kapitel stellt das Umfeld und die Begriffswelt der Zeitplanung in agilen Projektablä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 vorgestellt und untersucht. Um die Rollen der Mitarbeiter und die hier eingesetzten Projektmanagementmethoden besser zu verstehen, werden deren wesentliche Merkmale aufgezeigt und von anderen Vorgehensweisen abgegrenzt. Auf Grundlage der vorgestellten Projekteigenschaften und dem Arbeitsumfeld der Mitarbeiter werden dann softwarebasierte Systeme untersucht und bewertet, welche die Zeitplanung unterstützen können. Die hier erlangten Erkenntnisse liefern den Ausgangspunkt, für die Bestimmung genauer Anforderungen an ein geeignetes Planwerkzeug Fallstudie GAIA AG Die Geschäftsfelder der GAIA AG gliedern sich hauptsächlich in die Bereiche Unternehmensberatung und Erstellung von Wissensmanagementsystemen. Im Tätigkeitsfeld Wissensmanagement beschäftigt sich die GAIA AG mit der Entwicklung von Trainings- und Expertensystemen. Dies sind softwarebasierte Systeme, die durch die Bereitstellung von Expertenwissen helfen, bestimmte Problemstellungen zu lösen oder zu bewerten. Expertensysteme bestehen dabei aus einer von Experten gepflegten Wissensbasis und einer Komponente zum Bearbeiten und Darstellen der Wissensbasis. Die Entwicklung verlangt dabei Kompetenzen fü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 nie genau gleich. Aufgrund der Einzigartigkeit der Situation und spezieller Anforderungen der Kunden 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 AG werden deshalb an die Bedürfnisse des Kunden angepasst. Die Projekte werden gemeinsam und in enger Zusammenarbeit mit dem Kunden durchgeführt. Das Feedback des Kunden fließt kontinuierlich als wichtiger Bestandteil in den Entwicklungsprozess ein. Die Planung und Organisation der Projekte muss sich deshalb immer wieder auf Veränderungen und neue

16 2. Grundlagen 16 Rahmenbedingungen einstellen. Dies verlangt flexible Strukturen und Vorgehensweisen bei der 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 jeweiligen Wissensgebieten fungieren. Sie beschäftigen sich mit dem Wissensengineering, der Organisation und Identifikation des Wissens, welches für das Kundenprojekt relevant ist. In Zusammenarbeit mit den Informatikern der IT-Abteilung, welche die technische Umsetzung der Systeme unterstützen, entstehen diese Softwarelösungen. Diese Projekte werden oft parallel durchgeführt und sowohl die Autoren als auch die Informatiker nehmen unterschiedliche Rollen bei der Entwicklung dieser Systeme ein. Interviews mit einzelnen Mitarbeitern der GAIA AG lieferten einen Einblick in die Arbeitsweisen und Methoden der Zeitplanung von Autoren und Informatikern und Beratern, aber auch in die Projektkoordination als Ganzes Autoren Die Autoren der GAIA Experten- und Trainingssysteme beschäftigen sich mit der Aufbereitung und Strukturierung einzelner Wissensgebiete. Die Systeme gliedern sich in unterschiedliche Module zu einzelnen Themenbereichen. Bei der Entwicklung eines Moduls ist der Zeitrahmen für die Fertigstellung durch den Projektplan meist fest vorgegeben. Die konkrete Zeitplanung mit den einzelnen Arbeitsschritten wird von den Autoren selbst erstellt. Die Modulerstellung wird dabei von dem Autor in einzelne überschaubare Arbeitsschritte gegliedert. Der erste Schritt ist die Erstellung der Wissensbasis. In Abhängigkeit von der Größe des Themengebiets und dem Kenntnisstand des jeweiligen Autors sowie den bereits vorliegenden Daten, wird für die Recherche unterschiedlich viel Zeit aufgewendet. Danach erfolgt die Modellierung der Wissenbasis in die Dialogstrukturen des Expertensystems. Die Erstellung multimedialer Inhalte innerhalb der Dialoge muss ebenfalls von dem verantwortlichen Autor koordiniert werden. Nachdem das Modul in seiner ersten Fassung erstellt wurde, wird der Inhalt von anderen Autoren mit entsprechendem Fachwissen verifiziert bzw. durch Glossareinträge ergänzt. Abschließend erfolgt eine technische Nachbearbeitung des Moduls durch einen Informatiker, bevor es an den Kunden ausgeliefert wird. Die Erstellung eines Moduls kann bis zu mehreren Monaten dauern und ist von dem Umfang des Themengebiets sowie den Anforderungen, die an das Modul gestellt werden, und der Anzahl der beteiligten Autoren abhängig. Innerhalb dieser Zeitspanne können sich Prioritäten und Verantwortlichkeiten ändern. Das hat etwa zur Folge, dass die Entwicklung eines Moduls angehalten oder an einen anderen Autor übergeben wird. Eine solche Übergabe erfordert Kommunikation und Wissensabgleich zwischen den Autoren. Der aktuelle Stand eines Projekts muss objektiv nachvollziehbar vorliegen, damit Projektverantwortlichkeiten reibungslos übergeben werden können. Autoren sind teilweise in mehreren Projekten

17 2. Grundlagen 17 gleichzeitig mit unterschiedlichen Anforderungen / Aufgaben konfrontiert (Erstellung eines Glossars, Überprüfung von Inhalten, Dialogführung). Auch dies muss auf individueller sowie projektübergreifender Ebene objektiv nachvollziehbar sein. Aufgrund der ständigen Veränderungen bei der Erstellung eines Moduls nehmen die Autoren nur eine grobe Zeitplanung vor. Eine exakte Planung des Ablaufs würde schnell an Aktualität verlieren und die regelmäßige Pflege der einzelnen Aufgaben würde sich als zu aufwändig gestalten. Als Kompromiss hat sich die Erstellung einer Aufgabenliste bewährt, in der die Ziele und Meilensteine festgehalten werden. Die Aufgabenlisten werden nach dem Scrum-Prinzip 1 geführt und dokumentieren sowohl die erledigten als auch die zukünftigen Arbeitsschritte und Entwicklungsziele. Bei diesem Vorgehen fällt es schwer, besonders bei mehreren Projekten, den Zeitrahmen zu überblicken. Zudem ist das Eintreten bestimmter Projekte noch nicht ganz gesichert, da beispielsweise noch abschließende Kundenverhandlungen ausstehen, aber die benötigten Kapazitäten bereits im Vorwege geprüft werden. Oft bleibt es unklar, wie viel Zeit durch die einzelnen Aufgaben schon verplant wurde und inwieweit der zeitliche Rahmen bereits erschöpft ist. Neben der Zeitplanung innerhalb eines Moduls gilt es für die Autoren selbst, eine individuelle projektübergreifende Planung ihrer Aktivitäten vorzunehmen. Aufgrund des veränderlichen Umfelds kann hier die Planung auch nur in größeren Zeiträumen erfolgen. Wöchentlich werden daher von den Autoren bestimmte Aufgaben aus den Scrum-Listen beteiligter Projekte ausgewählt und als Wochenziel gesetzt. Dabei ist es nicht relevant, an welchem genauen Arbeitstag die jeweilige Projektaufgabe fertiggestellt wird. Auch die längerfristige Planung ihrer Arbeitsschritte liegt in der Verantwortlichkeit der Autoren. Die Komplexität der Arbeitszeitplanung wächst aber mit der betrachteten Zeitspanne, die zeitlichen Faktoren der Projektaufgaben müssen in diesem Zeitraum entsprechend chronologisch geordnet werden. Daraus ergibt sich die Auslastung einzelner Autoren, welche bei der Bestimmung aktuell verfügbarer Ressourcen für neue Projekte wichtig ist. Bisher gibt es für die Autoren keine technischen Mittel, die sie bei ihrer individuellen Zeitplanung des operativen Tagesgeschäfts unterstützen. Die Terminplanung wird von Autoren über die im Unternehmen eingesetzte PIM-Software Microsoft Outlook vorgenommen. Feste Termine gehören aber eher selten zu dem Tagesablauf der Autoren Informatiker Ein Informatiker der GAIA AG hat täglich unterschiedliche Aufgaben zu erledigen: Planung und Entwicklung von Softwarelösungen, die Administration der GAIA Expertensysteme und 1 Scrum ist ein iterativer, inkrementeller Prozess für die Entwicklung von Produkten oder das Management der Arbeit. [www:scrum]

18 2. Grundlagen 18 die Unterstützung der Autoren bei technischen Fragen. Desweiteren werden allgemeine Recherchen im Bereich der Softwareentwicklung sowie die Evaluierung neuer Techniken und Workflow unterstützender Softwarelösungen durchgeführt. Die Informatiker sind ebenfalls bei der Aufwandsschätzung neuer Aufträge involviert. Anhand der Kundenanforderungen wird von ihnen der Aufwand für die IT-Abteilung geschätzt. Die Einschätzung der Aufgaben erfolgt mit dem Function-Point-Verfahren, der Analyse von Anwendungsfällen und auf der Basis gesammelter Erfahrungen in anderen Projekten. Im Rahmen der Aufwandsschätzung werden auch mögliche Risiken identifiziert und berücksichtigt. Der Informatiker muss im Durchschnitt, täglich drei bis zehn unterschiedliche Aufgaben zeitlich koordinieren. Der Aufwand für die jeweiligen Aufgaben variiert stark, von einigen Minuten bis hin zu mehreren Stunden. Zudem müssen langfristige parallele Projektaktivitäten vereinbart werden, um eine termingerechte Fertigstellung zu gewährleisten. Die Bedingungen sind damit ähnlich wie bei den Autoren der Expertensysteme. Die Planung der eigenen Arbeitszeit liegt in der Verantwortung der Informatiker. Eine technische Unterstützung wird bei diesem Prozess bisher kaum geboten. Ein Hilfsmittel für die Koordination der Arbeitspakete beschränkt sich auf die Dokumentation der Tätigkeiten nachdem Scrum-Prinzip. Ein zeitlicher Zusammenhang lässt sich aus den Scrum-Listen nur bedingt ableiten. Zudem beschränken sich die in ihnen enthaltenen Informationen nur auf ein Projekt. Die projektübergreifende Einteilung der Arbeitszeit muss daher durch den Informatiker erfolgen. Eigens für das operative Tagesgeschäft erstellte Projektplänen haben sich angesichts der häufigen Veränderungen als unflexibel und zu aufwändig erwiesen. Neben den Projektaufgaben werden die Termine über die Kalenderfunktion der unternehmensweit eingesetzten PIM-Software verwaltet Berater Die Berater der GAIA AG unterstützen und beraten Unternehmen aus dem Gesundheitssektor. Ihre Aktivitätsbereiche umfassen unter anderem Projektarbeiten, Recherchen und Präsentationsvorbereitungen. In Abhängigkeit von der Aufgabe sind ein oder mehrere Mitarbeiter in die Tätigkeiten involviert. Das Tagesgeschäft der Berater ist zudem mit vielen wechselnden Aufgaben und Unterbrechungen verbunden, welche durch Kundenanfragen oder Anfragen interner Mitarbeiter entstehen. Veränderungen der Arbeitsaufträge geschehen laufend und sind schwer kalkulierbar, daher ist es schwer, feste Zusagen über den Fortschritt einzelner Aktivitäten zu geben. Dieses sind meist Schätzungen auf Grundlage der gesammelten Erfahrungen der Berater. Zudem ist die aktuelle Auslastung und der Arbeitsfortschritt der Berater ein wichtiger Faktor bei der Behandlung von Ressourcenanfragen für neue Projekte. Die Beratungstätigkeiten finden oft direkt bei dem Kunden vor Ort statt. Deshalb sind die Besprechungen bei dem Kunden mit Geschäftsreisen verbunden. Die benötigte Reisezeit ist hier ein wesentlicher Faktor, welcher in der Zeitplanung der Berater berücksichtigt werden muss. Die Terminabsprache erfolgt mit dem Kunden per Telefon oder . Die kollaborative

19 2. Grundlagen 19 Terminplanung durch den Einsatz der Groupware ist außerhalb der Unternehmensgrenzen nicht denkbar. Die Planung ist dabei oft an viele Bedingungen gebunden, welche sich zudem kurzfristig ändern können. Die Zeitplanung der Berater richtet sich damit hauptsächlich nach den Vereinbarungen mit dem Kunden und wird nur im gewissen Umfang von ihm selbst bestimmt. Die Berater haben also überwiegend Termine zu planen und weniger Projektaufgaben. Die Zeitplanung der Berater erfolgt zur Zeit mit der Kalenderkomponente von der im Unternehmen eingesetzten Groupware. Die Zeiterfassung ihrer Tätigkeiten wird mit einem Tabellenkalkulationsprogramm durchgeführt und dokumentiert 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 Moderation des Projektteams zur Erreichung der angestrebten Projektziele. In Abhängigkeit von dem Projektcharakter wird innerhalb der GAIA AG ein Mitarbeiter anhand seiner Fähigkeiten als Projektkoordinator ausgewählt. Der Projektkoordinator besitzt bereits Wissen über die Projektdomäne und kann innerhalb des Projektteams die Mitarbeiter anhand ihrer Qualifikation und Fähigkeiten den entsprechenden Rollen zuweisen. Die Aufgabe des Projektmanagments ist es, eine Umgebung zu schaffen in der eine Interaktion und Kollaboration des Projektteams gefördert wird. Dabei sind dem Projektteam so viele Freiheitsgrade wie möglich einzuräumen. In Projekten nimmt das Informationsmanagement eine wichtige Rolle ein. Dem Entscheidungsträger müssen deshalb die aktuellen Projektdaten möglichst zeitnah vorliegen. Für das Projektteam gilt es, alle Informationen der Projekte und der damit verbundenen Aktivitäten möglichst objektiv zu erfassen, nur dann ist effektives Projektcontrolling möglich. Üblicherweise wird der Stand des Projekts von der Leitung und dem verantwortlichen Projektteam in Besprechungen regelmäßig kommuniziert. In agilen Projekten steht die Kommunikation innerhalb des Projektteams im Vordergrund. Die Dokumentation der Vorgänge hingegen sollte angemessen sein und sich auf das Wesentliche konzentrieren. Die Projektkoordination bildet zudem die Schnittstelle zwischen dem Kunden und dem Projektteam. In Verhandlungen werden hier die einzelnen Produkteigenschaften und deren Priorität im Entwicklungprozess vereinbart. Die Umsetzung der Entwicklungsziele erfolgt in agilen Projekten weitgehend in autonomen Projektteams mit den Fähigkeiten der Selbstdisziplin und Selbstorganisation. Anders als in der klassischen Projektorganisation geht es hier nicht darum, detaillierte Arbeitsaufträge über Pläne an die einzelnen Projektmitarbeiter zu verteilen, sondern selbstorganisierte Projektteams Eigenverantwortung für die termingerechte Fertigstellung der vereinbarten Produkteigenschaften übernehmen zu lassen.

20 2. Grundlagen Fazit Aus den hier beschriebenen Arbeitsprofilen lassen sich drei Anwendergruppen bilden. Die Autoren und Informatiker haben aufgrund ihrer Rahmenbedingungen bei der Zeitplanung nahezu die gleichen Anforderungen an ein unterstützendes System. Diese Anwendergruppe benötigt ein Planwerkzeug, das die Planung von Terminen, Multi-Projekttätigkeiten und projektübergreifender Aktivitäten in einem zeitlichen Zusammenhang darstellt. Im Vordergrund steht dabei, dass auf Veränderungen der zeitlichen Rahmenbedingungen möglichst einfach und schnell reagiert werden kann, ohne dass ein Zeitplan aufwändig erstellt werden muss. Die Anwendergruppe der Unternehmensberater unterscheidet sich von den Anforderungen der Autoren und Informatiker, da hier die Terminplanung im Vordergrund steht. Die Zeitplanung ist im Wesentlichen an die Vereinbarungen mit dem Kunden gekoppelt und unterliegt damit nur bedingt dem Einfluss des Beraters. Die dritte Koordination und Lenkung der Projekt- und Geschäftsabläufe, werden von der Projektkoordination und der Geschäftsführung ausgeführt. Diesen Entscheidungsträgern sollten als Entscheidungsgrundlage alle relevanten Informationen bereitgestellt werden. Der Informationsaustausch erfolgt dabei über die Kommunikation mit den verantwortlichen Mitarbeitern. 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. Zusammenfassend werden folgende Faktoren als wesentlich bei der individuellen Arbeitszeitplanung eines Mitarbeiters aufgefasst: Tätigkeiten aus dem Tagesgeschäft zeitliche Rahmenbedingungen (Starttermin, geschätzte Dauer und voraussichtlicher Endtermin) 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

21 2. Grundlagen Organisation und Planung von Projekten Das Projektmanagement beschäftigt sich mit der Planung, Organisation und Durchführung von Projekten. Dieser Abschnitt erläutert zunächst den Begriff des Projekts und die Einteilung in verschiedene Projektarten. Danach werden die wesentlichen Merkmale des klassischen und agilen Projektmanagements vorgestellt und die Unterschiede aufgezeigt Das Projekt Der betriebswirtschaftliche Begriff Projekt wird unter anderem in der DIN definiert. Hier heißt es, ein Projekt ist ein Vorhaben, das im Wesentlichen durch eine Einmaligkeit der Bedingungen 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 Entwicklung von Softwaresystemen vor allem die Qualität [Raasch, 1993]. Die Norm schreibt Projekten eine Einmaligkeit zu, welche im Gegensatz zu der täglichen Routinearbeit eine Besonderheit darstellt. Deswegen bedarf es bei der Durchführung einer projektspezifischen Organisation sowie den Einsatz von Managementmethoden. Die Einmaligkeit bedeutet hier, dass die Projektdurchführung unter den gegebenen Bedingungen einmalig sein muss, dabei sind nicht zwingend alle einzelnen Projektaufgaben gemeint. Weiter ist der Begriff Ziel als ein definierter Soll-Zustand zu verstehen, der für alle Projektmitglieder eindeutig und verbindlich sein muss. Da die Zieldefinition zu Projektbeginn meist aufgrund des Neuheitsgrades noch teilweise unvollständig ist, gilt es im Laufe des Projekts, diese zu konkretisieren und festzulegen. Die Rahmenbedingungen müssen dabei ständig überprüft und eventuell angepasst werden. Desweiteren kennzeichnet ein Projekt die Nutzung von betrieblichen Ressourcen, wie Personal, Kosten und Zeit, die alle oder in Kombination knapp sind. Abschließend gilt es Projekte inhaltlich, finanziell und personell von anderen unternehmerischen Vorhaben abzugrenzen.

22 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 werden. Eine grobe Einteilung nach dem Projektziel unterscheidet die folgenden Projektklassen nach [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 Umsetzung der Projektvorhaben kann aufgrund des Neuigkeitsgrades, der Komplexität sowie des damit verbundenen Risikos bewertet werden. So müssen Projekte aus dem Bereich Forschung und Entwicklung, mit denen Neuland betreten wird, anders organisiert werden als Projekte, für die bereits unternehmensspezifische Erfahrungen in ähnlichen Vorhaben gesammelt wurden. Die geeigneten Methoden und Vorgehensweisen werden im nächsten Abschnitt beschrieben Projektmanagement Projektmanagement wird laut DIN 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, welche für die erfolgreiche Durchführung eines Projekts getroffen werden. Das Projektmanagement beinhaltet die Organisation und Koordination der einzelnen Projektaktivitäten zur Lösung der Problemstellung. Im Mittelpunkt steht dabei die Zuordnung von Aufgaben, Kompetenzen und Verantwortlichkeiten an die Projektmitglieder sowie die Organisation von Entscheidungsprozessen und die Durchsetzung der getroffenen Entscheidungen. Das Projektmanagement unterteilt sich dabei in folgenden Aufgabenbereiche: Projektorganisation Projektplanung Projektcontrolling Projekte haben viele Facetten, von denen der Einsatz einer konkreten Projektmanagementmethode abhängig ist. Bei den eingesetzten Methoden gibt es zwei Extreme, das klassische und das agile Projektmanagement. Unter klassischem Management ist hier eine detaillierte Planung und anschließende Durchführung sowie Steuerung des Projekts zu verstehen.

23 2. Grundlagen 23 Das agile Projektmanagement hingegen konzentriert sich auf die Durchführung des Projekts in mehreren abgeschlossenen Etappen, mit ständiger Einbeziehung der dabei gesammelten Erkenntnisse. Die folgende Tabelle liefert einen Überblick und zeigt die Unterschiede der beiden Ansätze nach [Boehm und Turner, 2003]: Projekt klassisch agil Ziele Größe Vorhersagbarkeit, Stabilität, hohe Sicherheit umfangreiche Teams und Projekte schnelle Wertschöpfung, auf Veränderungen reagieren kleine Teams und Projekte Umfeld stabil, wenig Veränderung, Schwerpunkt auf dem Projekt und der Organisation turbulent, viel Veränderung, Schwerpunkt auf dem Projekt Änderung der Anforderungen Management meist vorhersagbar, hohe Anpassungskosten unterstellt nicht vorhersagbar, Anforderungsevolution, niedrige Anpassungskosten unterstellt Kundenbeziehung bedarfsorientierte Kundeninvolvierung, konzentriert auf Vertragsbestimmungen engagiert auf der Kundenseite, konzentriert auf priorisiertem Zuwachs Planung und Controlling Aufgabenplanung, dokumentierte 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 Mitwirkungsmöglichkeit durch Richtlinien und Vorgehensweisen Wohlbefinden und Mitwirkungsmöglichkeit durch viele Freiheitsgrade, Selbstorganisation und -disziplin Tabelle 2.1.: Vergleich klassisches und agiles Projektmanagement

24 2. Grundlagen 24 Projektorganisation Unternehmen besitzen Führungsstrukturen, welche Regelungen für die Organisation und Abwicklung wiederkehrender Geschäftsvorfälle vorgeben. Für Projekte müssen ebenfalls temporär solche Organisationsstrukturen etabliert werden. In Projekten ergibt sich aufgrund der meist fachübergreifenden Kollaboration in einem neuartigen Aufgabenbereich ein erheblicher Koordinationsbedarf. Mit der Projektorganisation wird ein Rahmen geschaffen, der das zielgerichtete Zusammenwirken der Projektmitarbeiter und den reibungslosen Ablauf des Projekts sichern soll. Die Projektleitung hat je nach gewählter Organisationsform mehr oder weniger Verantwortung und Kompetenzen. Im Gegenzug besitzt das Projektteam einen größeren oder mehr eingeschränkten Freiheitsgrad bei der Ausführung der Arbeiten. In der Praxis existieren verschiedene Mischformen, hier soll deshalb nur der wesentliche Unterschied zwischen einer streng klassischen und einer agilen Organisation erläutert werden. Die klassische Organisation von Projekten etabliert feste hierarchische Strukturen für die fachliche und disziplinarische Unterteilung des Projektteams. Es wird dabei ein organisatorischer Rahmen geschaffen, welcher auf Hierarchie, Kontrolle und Vorschriften basiert. Die Koordination zwischen dem Projekt und der ständigen Organisation des Unternehmens, wird durch eine feste Definition aller Zuständigkeiten, Verantwortungen und Kompetenzen hergestellt. Das agile Projektmanagement dagegen gibt keine festen Strukturen vor, sondern setzt auf die Selbstorganisation des Projektteams. Die Organisationsstrukturen sind eher flexibel. Es werden in Abhängigkeit von der Größe des Projekts und Projektteams geeignete Strukturen aufgebaut. Dieses sind keine strengen hierarchischen Strukturen, eher orientieren sie sich dabei an den agilen Prinzipien 2, um weiterhin anpassungsfähig zu bleiben. In kleinen Projektteams mit großen Freiräumen sind Eigenverantwortung und Selbstdisziplin der einzelnen Mitarbeiter entscheidend, um ein erfolgreiches Zusammenwirken zu erreichen. Kleine Unternehmen mit hoch dynamischen Projekten sowie gut ausgebildeten Mitarbeitern scheinen besser zu der agilen Projektorganisation zu passen. Projektplanung Die Planung beschreibt ein systematisches Vorgehen zur Festlegung von Zielen und künftigen Handlungen im Kontext eines Projekts. Projektplanung zählt zu den wichtigsten Aufgaben im Projektmanagement. Die Planung und Durchführung eines Projekts bildet einen Kompromiss unter Vereinbarung der folgenden Faktoren: Ressourcen (Personal, Betriebsmittel, Kosten) 2 Näheres zu den agilen Werten und Prinzipien ist dem Anhang A zu entnehmen.

25 2. Grundlagen 25 Zeit (Termine, Meilensteine) Ergebnis (Produkt, Features, Qualität) Aus der streng klassischen Perspektive betrachtet, sind die Phasen der Planung und Durchführung aufeinander folgende und getrennte Projektphasen. Die Planung dokumentiert dabei das 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 Planungsphase ist in klassischen Projekten sehr ausgeprägt. Auf Grundlage der aktuell verfügbaren Informationen und Rahmenbedingungen wird darin ein detaillierter Plan erstellt. Das Vorgehen teilt sich in zwei Schritte: in die Planung der Projektstruktur und in die Planung des Projektablaufs. In der Planung der Projektstruktur werden aus den Anforderungen die für das Projekt wichtigen Projektteile und -teilaufgaben extrahiert, abgegrenzt und definiert. Abhängigkeiten unter den einzelnen Projektteilen werden bestimmt und damit eine systematisch geordnete Struktur für das Projekt festgelegt. Erst nachdem der Projektstrukturplan komplett erstellt 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 Umsetzung der einzelnen Projektteile ausgeführt werden müssen. Sie dienen als Grundlage für Projektablaufplanung, welche die logischen Zusammenhänge und Abhängigkeiten zwischen den Arbeitspaketen modelliert. Nachdem die Planung und Analyse des Projektablaufs abgeschlossen wurde, kann mit der Projektzeitplanung begonnen werden. Der Projektzeitplan beinhaltet die zeitlichen Zusammenhänge des geplanten Projektablaufs. Hier finden sich alle Projektaufgaben und Meilensteine in ihrer zeitlichen Abfolge wieder. Die Darstellung der Zeitpläne erfolgt oft mit Diagrammen aus der Netzplantechnik. Nachdem die Projektplanung beendet wurde, kann mit der Durchführung des Projekts begonnen werden. Beim agilen Projektmanagement unterteilt sich die Planung auf zwei Ebenen. Die erste Planungsebene beschreibt anhand der Anforderungen einen groben Gesamtplan, der Aussagen über Aufwand, Ressourcen, Dauer, Risiken, Ziele und Termine der Meilensteine macht. Unter Berücksichtigung der agilen Prinzipien sollte sich die Dokumentation dabei auf die wichtigsten Daten konzentrieren. Eine Möglichkeit bietet hier das Project Data Sheet 3, welches auf maximal einer DIN A4 Seite die zentralen Geschäftsziele, Projekt- und Managementinformationen zusammenfasst. Der Gesamtplan aus der ersten Planungsebene wird bei der konkreten Umsetzung auf eine zweite Ebene heruntergebrochen. Auf dieser Ebene wird ein iteratives Vorgehen angewendet, welches den Entwicklungsprozess in mehrere zeitlich begrenzte Abschnitte unterteilt. Der Iterationsplan liefert einen groben Überblick aller geplanten Iterationen und deren Ergebnisse sowie der definierten Meilensteine. Die detaillierte Zielplanung einer bevorstehenden Iteration wird in Zusammenarbeit von Projektleitung und Projektmitarbeitern vorgenommen. Dabei werden die angestrebten Ergebnisse diskutiert und die 3 Eine beispielhafte Darstellung eines Project Data Sheet findet sich im Anhang B.

26 2. Grundlagen 26 resultierenden Arbeitsaufträge für einzelne Mitarbeiter oder Teams formuliert. Die Arbeitsaufträge sollten sinnvoll, realistisch und innerhalb der Iteration zu bewältigen sein, ansonsten müssen sie in mehrere Teilaufgaben zerlegt werden. Nachdem die Verantwortlichkeiten der Arbeitsaufträge geklärt wurden, folgt die eigentliche Umsetzung bzw. Entwicklung sowie anschließende qualitative Kontrolle und Lieferung der Ergebnisse. Abschließend wird in einer Review ein Soll-/Ist Vergleich der iterationsspezifischen Ergebnisse angestellt, um den aktuellen Projektfortschritt zu erfassen. Diese Reflektion der Ergebnisse liefert wichtige Informationen für die Planung der folgenden Iteration und eine Entscheidungsgrundlage für mögliche Plankorrekturen. Zeitplanung Die Zeitplanung nimmt eine wichtige Rolle in Projekten ein. Deshalb soll dieser Vorgang hier näher erläutert werden. In der Projektzeitplanung geht es darum, die zeitlichen Zusammenhänge und Abhängigkeiten zwischen den einzelnen Projektaufgaben (Arbeitspakete, Arbeitsaufträge) zu erfassen sowie den benötigten Aufwand abzuschätzen. Im Rahmen der Zeitplanung sind dabei folgende Begriffe relevant: Dauer Pufferzeit Zeitpunkt Termin Meilenstein Zeitspanne von Anfang bis Ende einer Tätigkeit bzw. eines Vorgangs Zeitspanne, innerhalb derer die Lage eines Vorgangs verändert werden kann, ohne Auswirkung auf den Endtermin ein festgelegter Punkt im Ablauf, dessen Lage durch Zeiteinheiten (z.b. Minuten, Tage Wochen) beschrieben und auf einen Nullpunkt bezogen ist [DIN 69900] ein durch Kalenderdatum und/oder Uhrzeit festgelegter Zeitpunkt Stichtag für ein wesentliches Projektergebnis, ein Ereignis besonderer Bedeutung [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 meistens nicht über die nötige Information, um den zeitlichen Aufwand der Projektaufgaben abzuschätzen. In Zusammenarbeit mit den involvierten Fachabteilungen werden geeignete Schätzungen vorgenommen. Außerdem werden dabei Analogieverfahren verwendet, welche die gesammelten Erfahrungswerte aus früheren Projekten nutzen. Unter Verwendung der erfassten Zeiten und Dokumentationen vergangener Projekte können damit fundierte Schätzungen gemacht werden. Grundlage für realistische Schätzungen bilden die folgenden Faktoren [Hunt und Thomas, 2003]:

27 2. Grundlagen 27 Die Genauigkeit der abgegebenen Schätzungen muss klar definiert werden. Die Schätzung muss ausreichend abgegrenzt werden und eventuell um Angaben erweitert werden, um mögliche Fehlinterpretationen auszuschließen. Die Wahl der Maßeinheit von Schätzwerten ist deswegen von entscheidender Bedeutung und sollte die beabsichtigte Genauigkeit unterstreichen. Eine kleinere Maßeinheit suggeriert vielleicht ungewollt eine hohe Genauigkeit. Über das Schätzobjekt müssen genügend Informationen verfügbar sein. Präzise Anforderungen verbessern das Verständnis einer Projektaktivität und auch die Genauigkeit der Aufwandsschätzung. Mangelnde Informationen haben zur Folge, dass eine Reihe von Annahmen für bestimmte Punkte getroffen werden, was die Qualität der Schätzung erheblich vermindert. Bei der Durchführung eines Projekts verändern sich die Erkenntnisse und Anforderungen an ein Schätzobjekt. Dieser Effekt wird als schleichender Funktionszuwachs (engl. requirements creep) bezeichnet. Mit veränderten Bedingungen muss deshalb die Aufwandsschätzung während des Projektfortschritts mehrmals wiederholt werden. Aus der Sicht des traditionellen Projektmanagements erfolgt die Erstellung eines umfassenden Projektzeitplans auf Grundlage der gesamten Struktur und des logischen Ablaufs des Projekts. Die Zeitplanung projiziert dabei den Projektablauf auf eine Zeitachse. In der Zeitanalyse werden die zeitlichen Aspekte und Beziehungen der Projektaufgaben genauer betrachtet. Mit geeigneten Schätzverfahren wird ein geplanter Sollaufwand für die einzelnen Projektaufgaben bestimmt. Desweiteren kann die Verrichtung voneinander unabhängiger Projektaufgaben zeitlich parallelisiert werden. In Abhängigkeit von der Projektkomplexität wird die Zeitplanung meist unter Verwendung der Netzplantechnik ausgeführt. Ein Netzplan ist die graphische oder tabellarische Darstellung von Abläufen und der Abhängigkeiten [DIN 69900]. Der Netzplan liefert Informationen über Termine, Dauer, Kapazitäten und Kosten des gesamten Projekts oder einzelne Vorgänge. Die Netzplantechnik gehört zu dem Bereich des Operations Research 4, das Verfahren zur Analyse und Optimierung der Planungsprozesse bietet. Die Zeitplanung im Sinne des klassischen Projektmanagements ist eine Hauptaufgabe 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. als Personaleinsatzplan. Im Gegensatz dazu gibt es in agilen Projekten zwei Ebenen der Planung. Während die Projektleitung das gesamte Projekt koordiniert und durch die grobe Iterationsplanung die Richtung steuert, wird die ausführliche Planung einer Iteration in enger Zusammenarbeit mit dem Projektteam vorgenommen. Die Planung konzentriert sich dabei auf die Definition von Zielen (z.b. Produkteigenschaften), welche in dieser begrenzten Zeitspanne erreicht werden sollen (engl. feature-driven). Aus den definierten Zielen ergeben sich Arbeitsaufträge, deren 4 Eine nähere Erklärung des Begriffs Operations Research befindet sich im Abschnitt 2.2.2

28 2. Grundlagen 28 Aufwand vom Projektteam geschätzt wird. Die konkrete Zeitplanung und Koordination der Arbeitsaufträge und der Aktivitäten ist nicht mehr eine Aufgabe der Projektleitung, sondern liegt in der Verantwortung des Projektteams. Die Planungsaktivitäten der Projektleitung konzentrieren sich auf die Koordination des ganzen Projekts, ohne eine detaillierte Planung der Projektaufgaben durchzuführen. Als Vermittler zwischen Kunde und Projektteam werden von der Projektleitung die einzelnen Iterationsziele vereinbart. Zusammenfassend lässt sich festhalten, dass die Struktur- und Ablaufplanung in klassischen Projekten hauptsächlich von der Projektleitung durchgeführt wird. In agilen Projekten hingegen liegt nur die gesamte Projektkoordination in der Verantwortung der Projektleitung. Die genaue Zeitplanung und Aufwandsschätzung für einzelne Arbeitsaufträge verlagert sich auf das Projektteam. Folglich sollten in klassischen und agilen Projekten, abhängig vom Einsatzgebiet, geeignete Planwerkzeuge bereitgestellt werden. Projektcontrolling Das Projektcontrolling vergleicht die Sollvorgaben aus der Projektplanung mit den aktuellen Ist-Werten. Ein Vergleich ermöglicht eine Bewertung des bisherigen Projektverlaufs, um damit Prognosen über den weiteren Ablauf zu erstellen. Die Überwachung des Projekts bezieht sich dabei primär auf die Projektziele, Termine und Kosten. Der Überwachungsprozess setzt sich 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 des Projektcontrollings. Der Soll-/Ist Vergleich konzentriert sich auf den Fertigstellungsgrad und den bereits geleisteten Aufwand für die einzelnen Projektaufgaben. Insbesondere sind dabei die Projektaufgaben auf dem kritischen Pfad regelmäßig zu überprüfen, da hier eine mögliche Verzögerung die gesamte Projektdauer beeinflusst. Der Abgleich des Projektfortschritts erfolgt meist in Besprechungen und über softwarebasierte Projektmanagementsysteme zur Aktualisierung der Netzpläne. Im agilen Projektmanagement hingegen überprüft die Projektleitung am Ende jeder Iteration die zuvor definierten Ziele mit den gelieferten Ergebnissen. Da die Zeitplanung und Koordination der einzelnen Arbeitsaufträge in der Eigenverantwortung des Projektteams liegen, werden sie nicht als Maßstab herangezogen. Die Überwachung und Steuerung seitens der

29 2. Grundlagen 29 Projektleitung erfolgt über die qualitative Kontrolle der Projektziele bzw. Produkteigenschaften. Das Projektcontrolling hat in agilen Projekten eher den Charakter des Produktcontrollings. Der Projektfortschritt wird in täglichen Besprechungen kommuniziert sowie im Review der Ergebnisse am Ende einer jeden Iteration. Zeiterfassung Grundlage für effektives Projektcontrolling ist eine konsequente Dokumentation der Projektaktivitäten. Nur wenn der aktuelle Stand des Projekts bekannt ist, kann man den Ablauf anpassen, anstatt nachträglich auf Probleme zu reagieren. Die Dokumentation eines Projekts erfolgt auf verschiedenen Ebenen. In Abhängigkeit von der Ebene gibt es unterschiedliche Detaillierungsgrade und Intervalle, in denen der Projektstatus veröffentlicht wird. Während Auftraggeber und Interessenvertreter nur eine Übersicht der aktuellen Eckdaten des Projekts verlangen, muss ein Projektmanager ständig über den genauen Aufwand und Fortschritt aller Projektaktivitäten informiert sein. Die Zeiterfassung dokumentiert kontinuierlich den Aufwand und Fortschritt eines Projekts und bildet damit eine wichtige Grundlage für das Projektcontrolling. Aus einer streng klassischen Perspektive liefert die Zeiterfassung den aktuellen Ist-Aufwand einzelner Projektaufgaben und bildet zusammen mit dem Fertigstellungsgrad eine Grundlage zur Analyse des aktuellen Projektfortschritts. Der erstellte Netzplan wird daher von der Projektleitung kontinuierlich mit den Ist-Daten aktualisiert. In Abhängigkeit vom Projektumfang gestaltet sich die Aufbereitung der Projektdaten recht aufwändig. In der Praxis werden daher Projektmanagementsysteme eingesetzt, welche die Pflege, Verwaltung und Verarbeitung der Projektdaten unterstützen und effizienter machen. Eine Aufzeichnung des gesamten Projektverlaufs liefert zudem wichtige Informationen für die Post-mortem-Analyse sowie für die Planung zukünftiger Projekte. Im agilen Projektmanagement liegt die Verantwortung der Zeitplanung und Koordination der Aufgaben bei dem Projektteam. Auch hier wird der zuvor abgeschätzten Soll-Aufwand mit den Ist-Daten verglichen, um den Fortschritt zu kontrollieren. Ein wesentlicher Unterschied besteht aber darin, dass es in einem kleineren und begrenzten Umfeld betrachtet wird. Die getroffenen Vereinbarungen einer Iteration geben dabei sowohl zeitlich als auch inhaltlich einen festen Rahmen vor. Trotzdem ist es auch hier sinnvoll den aktuellen Aufwand und Fortschritt kontinuierlich zu dokumentieren. Im Sinne des Self-improvement ermöglichen die gesammelten Informationen den Projektmitarbeitern, die Arbeitsaufträge zukünftiger Iterationen oder Projekte besser einzuschätzen. Vor dem Hintergrund der projektspezifischen Organisation innovativer Produktentwicklung in kleinen Unternehmen erweisen sich die Ansätze des agilen Projektmanagements als sinnvoll. Die Projekte werden dabei oft über Festverträge mit dem Kunden vereinbart, beinhalten

30 2. Grundlagen 30 daher auch ein festes Budget. Die genaue Zeiterfassung ist primär auch nicht die Basis für die Rechnungserstellung, wie es beispielsweise bei Servicedienstleistern der Fall ist. Trotzdem sollten im Rahmen des klassischen und agilen Projektmanagements geeignete Systeme zur Zeiterfassung etabliert werden, sei es für das Projektcontrolling, die Prüfung der Wirtschaftlichkeit oder als Grundlage für Aufwandsschätzungen zukünftiger Projekte. Exkurs Operations Research Operations Research (OR) hat das Ziel, anhand der Analyse von komplexen Problemstellungen eines Planungsprozesses mit mathematischen Methoden, eine möglichst optimale Entscheidung zu unterstützen. Hierbei werden reale Entscheidungsprobleme mit einem Optimierungs- oder Simulationsmodell abgebildet und durch die Anwendung bzw. Entwicklung eines Algorithmus gelöst. Diese Aufgaben werden mit der Unterstützung von Software durchgeführt. Die Planungsprozesse im OR lassen sich in die folgenden sechs Phasen einteilen [Domschke und Drexl, 2005]: Erkennen und Analysieren eines Problems (bzw. Entscheidungs- und Handlungsmöglichkeiten) Bestimmen von Zielen und Handlungsmöglichkeiten (Erstellung eines deskriptiven Modells) 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 der Lösbarkeit von Modellen im Wesentlichen von deren Konstruktion ab. Es wird daher eine effiziente Modellierung angestrebt. Die Entscheidungs- oder Planungsprobleme werden durch geeignete Entscheidung- bzw. Optimierungsmodelle dargestellt. Ziel dieser Modelle ist die Entwicklung optimaler oder suboptimaler Lösungsvorschläge. Komplexe Optimierungsmodelle, für die keine analytischen Verfahren zur Problemlösung existieren, werden mit Hilfe von Simulationsmodellen abgebildet. Damit lassen sich einzelne Alternativen und deren Konsequenzen durchspielen und anschließend analysieren. Die Anwendung des Operations Research auf die zugrunde liegenden Optimierungsmodelle unterteilt sich in verschiedene Teilgebiete: die lineare, kombinatorische, dynamische und nichtlineare Optimierung. Die Graphentheorie und Netzplantechnik werden zur graphischen Darstellung von Organisationsstrukturen oder Projektabläufen häufig in der Praxis verwendet. In diesen Modellen

31 2. Grundlagen 31 werden Verfahren angewendet, um kürzeste sowie maximale Wege innerhalb der Graphen zu bestimmen. Ein Netzplan besteht aus Vorgängen und Ereignissen, die in definierten Beziehungen zueinander stehen. Diese Vorgänger-Nachfolger-Beziehungen beschreiben die Ablaufstruktur des Projekts. In der Strukturplanung werden gegebenenfalls schon die Dauer sowie die Mindest- und/oder Maximalabstände der einzelnen Elemente des Netzplans berücksichtigt. Diese werden als Eingangsgrößen für die konkrete Zeit- und Terminplanung verwendet, in der alle Projektvorgänge bzw. Ereignisse terminiert werden. Desweiteren werden die Methoden der Netzplantechnik in deterministische und stochastische Vorgehensweisen unterteilt. Bei den deterministischen Methoden ist jeder Vorgang auszuführen und die Dauer bzw. Abstände zwischen ihnen werden als bekannt vorausgesetzt. Dazu zählen Verfahren wie Critical Path Method (CPM) und Metra-Potenzial-Methode (MPM). Bei stochastischen Methoden hingegen ist die Dauer und/oder die Ausführung eines Vorgangs mit einer gewissen Wahrscheinlichkeit behaftet. Zur dieser Gruppe gehören Verfahren wie Program Evaluation and Review Technique (PERT) und Graphical Evaluation and Review Technique (GERT). Die stochastischen Methoden erfordern vergleichsweise umfangreiche mathematische Analysen, deshalb werden in der Praxis überwiegend deterministische Methoden eingesetzt. Die Optimierung durch OR wird hauptsächlich in der Planungsphase des klassischen Projektmanagements eingesetzt. Die gesamte Projektdurchführung wird bereits zu Beginn des Projekts in der Planungsphase anhand der bekannten Rahmenbedingungen detailliert geplant. Mit dem Einsatz von OR wird der erstellte Netzplan effizienter gestaltet, um beispielsweise unabhängige Vorgänge zu parallelisieren und damit eine kürzere gesamt Projektdauer zu erreichen. Während Optimierung besagt, dass man schon genau weiß, wie man etwas zu tun hat, dies aber verbessert werden soll, geht es bei der Innovation gerade erst darum herauszufinden, wie man etwas tut. Im Rahmen der innovativen Entwicklung mit agilen Managementmethoden existieren viele unbekannte Anforderungen, die sich erst im Verlauf des Projekts konkretisieren, daher ist es nicht förderlich mit dieser Ungewissheit genaue Pläne zu erstellen und anschließend zu optimieren. Die erstellten Pläne würden aufgrund unvorhersehbarer Veränderungen zu schnell an Aktualität verlieren und einen zu hohen Pflegeaufwand verursachen Fazit Dieser Abschnitt hat die Ansätze des klassischen und agilen Projektmanagements umrissen. Beide verfolgen verschiedene Methoden und Vorgehensweisen, deren Auswahl vom Projekt und 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, dann die detaillierte Planung und abschließend die Ausführung sowie Steuerung des Projekts.

32 2. Grundlagen 32 Zu Beginn besteht ein großer Planungsaufwand, da das Projekt über die Strukturplanung bis zum terminierten Ablauf einzelner Arbeitsschritte in Plänen definiert wird. Die genaue und ausführliche Planung wird dabei mit Methoden aus dem Operations Research wie der Netzplantechnik unterstützt. In der Umsetzung gilt es, durch einen kontinuierlichen Soll-/Ist Vergleich des Projektcontrollings das Projekt auf dem geplanten Kurs zu halten. Agiles Projektmanagement hingegen ist auf die eigentliche Umsetzung des Projekts ausgerichtet. Das Projektmanagement unterstützt hierbei primär den Prozess der Entwicklung und führt das Projektteam von der Vision zum echten Produkt. Das gesamte Vorhaben ist ergebnisorientiert und konzentriert sich dabei auf die wesentlichen Aktivitäten, welche eine höhere Wertschöpfung für den Kunden liefern. Dazu zählen auch Planungs- und Kontrollaktivitäten, sie sind aber nicht der Schwerpunkt im agilen Projektmanagement. In der agilen Produktentwicklung geht es darum, sich auf Innovation und Anpassungsfähigkeit anstatt auf Effizienz und Optimierung zu konzentrieren. Gerade zu Beginn des Projekts ist es schwierig 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 Phasen gilt es, die Veränderung zu akzeptieren und geeignet in den Prozess aufzunehmen. Die Ziele einer Iteration und mögliche Plankorrekturen werden dabei im Zusammenwirken von Projektkoordination und Projektteam erarbeitet. Beide Ansätze des Projektmanagements haben ihre Vor- und Nachteile und müssen daher anhand der aktuellen Gegebenheiten ausgewählt werden. Ein kombinierter Einsatz von klassischen und agilen Managementmethoden zum Ausgleich der Risiken ist ebenfalls möglich. Auf Grundlage der Risikobewertung beschreibt beispielsweise das Buch Balancing Agility and Discipline: A Guide for the Perplexed [Boehm und Turner, 2003] einen Ansatz, der die Vorteile beider Vorgehensweisen nutzt. Desweiteren lässt sich festhalten, dass der Aufwand für die Zeitplanung und Koordination von Projektaufgaben aus Sicht der Projektmitarbeiter in klassischen Projekten niedriger ist als in agilen Projekten. Während der klassische Ansatz durch Mikromamangement und Personaleinsatzplanung genaue Vorgaben macht, liegen in agilen Projekten diese Planungsaktivitäten in der Eigenverantwortung des Projektteams. Im folgenden Abschnitt soll daher die Zeitplanung von Mitarbeitern in dieser Situation genauer betrachtet werden Zeitplanung der Mitarbeiter Wie in Abschnitt 2.1 erläutert wurde, befinden sich Mitarbeiter oft zeitgleich in unterschiedlichen Projekten. Die individuelle Zeitplanung liegt in der Verantwortung der einzelnen Mitarbeiter. Dabei müssen sie die projektübergreifende Koordination der Projektaufgaben sowie

33 2. Grundlagen 33 die Vereinbarung mit den Tätigkeiten aus dem Tagesgeschäft (z.b. -Korrespondenz, Besprechungen) selbst vornehmen. Die Rahmenbedingungen für die Planung gehen dabei aus den vereinbarten Iterationszielen sowie dem Terminkalender des Mitarbeiters hervor. Jeder Mitarbeiter muss dann für sich selbst eine Einteilung seiner täglichen Arbeitszeit vornehmen, um den gegebenen zeitlichen Bedingung zu entsprechen. Während dies für ein Projekt noch recht übersichtlich erscheint, nimmt die Komplexität der Zeitplanung mit mehreren 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 in Prozentsä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 von den Mitarbeitern Terminkalender und Aufgabenlisten (engl. todo list, task list) geführt Terminkalender Ein Terminkalender dient der Planung von Ereignissen und Vorgängen. Es ist ein einfaches Werkzeug, um Termine zu koordinieren, festzuhalten und an sie erinnert zu werden. Der Kalender bietet einen zeitlichen Rahmen zur Planung von Aktivitäten zu einem Termin. Die Ereignisse 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 übersichtlich vornehmen. Die entsprechenden Planungseinträge werden auf einen freien Zeitraum verschoben oder ersetzt. Der Einsatz eines Terminkalenders dient sowohl der geschäftlichen als auch der persönlichen Zeitplanung. Heutzutage werden in den meisten Unternehmen softwarebasierte Terminkalender eingesetzt. Damit wird der Kalender um zusätzliche Funktionalitäten erweitert, wie zum Beispiel die Terminerinnerungsfunktion und die Planung von Serienterminen. Zudem können Besprechungstermine unternehmensweit mit ausgewählten Mitarbeitern elektronisch kommuniziert werden. Die Veröffentlichung der Kalender ermöglicht im Vorwege eine Übersicht freier Zeitressourcen für die Abstimmung von Besprechungsterminen. Man könnte Terminkalender auch für die Planung von Aufgaben und Terminen aus Projekten nutzen. Diese werden dann außer im Projektplan auch in den Kalendern der involvierten Mitarbeiter geführt. Anhand der Verantwortlichkeiten können die Aufgaben explizit in die Terminkalender der Mitarbeiter eingetragen werden, und der einzelne Mitarbeiter erhält dabei einen individuellen Überblick seiner Termine und Projektaktivitäten. Problematisch ist hier jedoch die Distribution von aktualisierten Projektplänen, welche über eine manuelle Pflege durch den Mitarbeiter aufwändig und fehleranfällig ist.

34 2. Grundlagen Aufgabenlisten Aufgabenlisten werden zur Erfassung und Verwaltung von Aufgaben verwendet. Neben der Dokumentation ist das Ziel von Aufgabenlisten die Überwachung und Erinnerung an noch nicht erledigte Aufgaben. Sie sind typischerweise tabellarisch aufgebaut und jede Aufgabe wird durch weitere Eigenschaften genauer beschrieben, wie beispielsweise Priorität, Zuständigkeit oder Termin. Aufgabenlisten werden in der Praxis z.b. zum Selbst-Management einzelner Personen, im Projektmanagement oder auch in der Softwareentwicklung eingesetzt. Die Verwaltung und Pflege von diesen Listen kann prinzipiell sowohl von Einzelpersonen als auch durch Teams erfolgen. Die Verwendung einer Aufgabenliste zur Verwaltung der zugeteilten Projektaufgaben bietet dem Mitarbeiter die Möglichkeit, einen Überblick seiner aktuellen Aktivitäten zu bekommen. Mit einer Aufgabenliste lassen sich die Aufgaben aus mehreren Projekten zusammengefasst darstellen. Eine Übersicht der individuellen Arbeitslast eines Mitarbeiters lässt sich aufgrund der tabellarischen Darstellungsform nicht genau erkennen 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önnen Terminüberschreitungen von kritischen Vorgängen sein, die das gesamte Projekt verzögern. Die Planung der Projektaufgaben in einem Terminkalender stellt zwar einen zeitlichen Bezug her, doch gestaltet sich dies als sehr aufwändig, sobald Veränderungen auftreten oder Prioritäten geändert werden. Sie ist damit in der Praxis nicht durchführbar. Es wird ein Planwerkzeug benötigt, welches die Vorteile beider Werkzeuge in sich vereint Überblick der Technologien Dieser Abschnitt gibt einen Überblick über aktuell verfügbare Softwarelösungen zur Unterstützung der Planungsaktivitäten in Projekten. Betrachtet werden Terminkalender, Projektmanagement-, Zeiterfassungs- und Ticketing-Systeme. Im Hinblick auf den Einsatzbereich in klassischen oder agilen Projekten ergeben sich unterschiedliche Anforderungen an die eingesetzten Systeme. Zunächst werden verschiedene Softwarelösungen aufgezeigt. Anschließend wird die Anwendbarkeit der Zeitplanung für den einzelnen Projektmitarbeiter speziell für das agile Projektmanagement geprüft.

35 2. Grundlagen Terminkalender Terminkalender sind heute meist eine Komponente innerhalb von Groupware und Software zum Personal Information Management (PIM). Diese Softwareprodukte helfen bei der Organisation von persönlichen Informationen und Nachrichten, dazu gehören unter anderem s, Adressbücher, Kalender, Aufgabenlisten und Notizen. Microsoft Outlook [www:outlook] ist eine Groupware-Lösung, obwohl es häufig nur als Applikation eingesetzt wird. In Verbindung mit dem Microsoft Exchange Server bildet das System eine Kommunikationsstruktur für viele Unternehmen weltweit. Eine aktuelle Studie der Radicati Group beziffert für 2005 den Marktanteil von Microsoft im Bereich der Kommunikations-Software auf 57% [Radicati, 2005]. Stellvertretend für eine Vielzahl von Terminkalendern wird Microsoft Outlook im folgenden Abschnitt betrachtet. Ein Vergleich mit den Anforderungen des Zeitplanungssystems soll den Funktionsumfang von Outlook genauer aufzeigen. Die Kalender-Komponente von Microsoft Outlook bietet eine allgemeine Verwaltung von beruflichen und persönlichen Terminen, Besprechungen und Ereignissen. Die grundlegende Organisation der Planungseinträge kann an unterschiedliche zeitliche Aspekte gebunden werden. Die Einträge z.b. Termine sind aber immer Aktivitäten mit festen Anfangs- und Endzeitpunkten. Mit Terminserien können Zeiten für sich wiederholende Aktivitäten innerhalb einer Zeitspanne eingeplant und reserviert werden. Besprechungen können zudem innerhalb einer Unternehmung unter Berücksichtigung der Zeitressourcen der involvierten Mitarbeiter kollaborativ geplant werden. Unabhängig von dem Terminkalender bietet Outlook eine Aufgabenliste, in der individuelle Aufgaben eines Mitarbeiters verwaltet werden können. Eine Verbindung zu den Planungseinträgen des Kalenders wird in der Aufgabenliste nicht hergestellt. Eine kollaborative Planung und Verwaltung von Projektaufgaben innerhalb von Outlook wird nicht unterstützt. Die automatisierte Synchronisation von Projektaktivitäten über eine Schnittstelle zu der Projektmanagement Software Microsoft Project fehlt. Eine Synchronisation der beiden Programme kann nur über zusätzliche Software realisiert werden. Die Integration dieser Software ist mit weiteren Lizenz- und Schulungskosten verbunden. Das Produkt Allocatus [www:allocatus] zum Beispiel ist eine Software, welche eine Synchronisation von Microsoft Project und Outlook herstellt. Die Aufgaben und Meilensteine aus dem Microsoft Project Projektplan lassen sich damit direkt als Kalendereinträge in Outlook exportieren. Der Informationsfluss erfolgt dabei nur in eine Richtung, Rückmeldungen aus Outlook heraus werden nicht unterstützt. Die Dokumentation des Fortschritts bearbeiteter Aufgaben beschränkt sich damit auf die lokale Installation und wird nicht für das Projektteam bereitgestellt. Die Synchronisation der Projektaufgaben setzt neben Outlook ein lokal installiertes Programm voraus, welches für die Installation und spätere Aktualisierungen aufwändig verteilt werden muss. Zudem besteht eine Plattformabhängigkeit, die Windows als Betriebssystem für die

36 2. Grundlagen 36 Klientenrechner voraussetzt. Ein Einsatz auf anderen Betriebssystemen oder auf mobilen Geräten ist nicht möglich Projektmanagement Software Projektmanagement Software unterstützt die Prozesse innerhalb von Projekten. Die Software erleichtert das projektbezogene Informationsmanagement und bietet Werkzeuge für Planung, Analyse und Darstellung der Projektdaten. Die Datenverwaltung von Personal, Ressourcen und Betriebsmitteln bildet die Datenbasis. Die Erstellung von Projektplänen und deren Darstellung in Form von Netzplan- und Gantt-Diagrammen gehört unter anderem zu den Aufgaben der Software. Visualisiert werden Fortschritt, Abhängigkeiten und Aufwände der einzelnen Projektaktivitäten. Ein zeitlicher Zusammenhang wird hergestellt und bietet eine Übersicht der Termine und Meilensteine. Die Software übernimmt die aufwändigen Berechnungen der Pufferzeiten und des kritischen Pfads. Besonders komplexe Abhängigkeitsstrukturen großer Projekte lassen sich einfach und effizient aktualisieren. Der Markt bietet eine Vielzahl von Projektmanagement Softwarelösungen. Die Software sollte daher in Abhängigkeit vom jeweiligen Einsatzgebiet ausgewählt werden. Während bei der Durchführung kleinerer Projekte eine Einzelplatzversion ausreicht, um die Projektdaten manuell und lokal zu verwalten, werden große Projekte durch den Einsatz von integrierten Projektmanagement Softwaresystemen unterstützt. Diese Systeme erweitern das Management der Projekte um andere Komponenten wie z.b. Zeiterfassung und Dokumentenverwaltung. Schnittstellen zu den angebundenen Komponenten ermöglichen einen Datenaustausch im ganzen System. Eine automatisierte Verarbeitung der Daten aktualisiert Projektpläne und dokumentiert den Fortschritt. Basierend auf einer Client/Server Architektur werden diese Systeme im Intranet der Unternehmen betrieben. Diese Systeme unterstützen den Informationsfluss in Projekten, um die aktuellen Projektdaten der Projektleitung, dem Projektteam und den Interessenvertretern unternehmensweit bereitzustellen. Microsoft Project Microsoft Project [www:project] ist eine kommerzielle Software für Projektmanagement. Die Software unterstützt Tätigkeiten im Projektmanagement wie die Erstellung von Projektplänen, Erfassung des Fortschritts, Verwaltung von Ressourcen und der Budgetplanung. Die Software ist als Einzelplatzversion und auch als Netzwerkversion zu erwerben. Microsoft Project wurde mit dem Microsoft Office Project Server erweitert, welcher eine zentrale Datenbank für die Speicherung und Verwaltung von Projekten bereitstellt. Die Microsoft Project Web Access Komponente ermöglicht einen dezentralen Zugriff auf die Daten des Office Project Servers über einen Browser. Die autorisierten Anwender können über das Web-Portal

37 2. Grundlagen 37 unternehmensweit die Dokumente und Informationen von allen Projekten abrufen, analysieren und aktualisieren. Eine Integration von Microsoft Project mit anderen Produkten von Drittanbietern ist generell möglich, erfordert aber den Einsatz weiterer Software, die eine Synchronisation der Projektdaten bereitstellt. NetOffice NetOffice [www:netoffice] ist eine Open-Source Software für integriertes Projektmanagement. Die Applikation ist web-basiert und bietet eine Plattform für kollaborative Projektarbeiten. NetOffice wurde in der Programmiersprache PHP entwickelt und verwaltet die Datenbasis in einer MySQL Datenbank. Eine Veröffentlichung der Applikation ist im Intranet, Extranet und Internet möglich. Die enthaltene Benutzerverwaltung gewährleistet die eindeutige Authentifizierung der Anwender. NetOffice weist jedem Benutzer eine definierte Rolle zu, so können auch gewünschte Informationen an externe Kunden bereitgestellt werden. Neben den Funktionen für das Projektmanagement unterstützt die Applikation die Kollaboration innerhalb eines Projekts. An Projekte können Diskussionen angefügt werden, welche unter Beteiligung der Projektmitarbeiter geführt werden. Im Gegensatz zu der Kommunikation über bleibt die Diskussion im Projektkontext und alle Beteiligten verfügen zudem über denselben Stand. Das integrierte leichtgewichtige CRM-System übernimmt die Verwaltung der Supportanfragen eines Projekts. SAP Projektsystem Das SAP Projektsystem [www:sap] ist ein Modul innerhalb des Enterprise Ressource Planning Systems der SAP AG. Die Komponente bietet umfassende Unterstützung bei der Planung, Durchführung und Steuerung von Projekten. Die Integration des Projektsystems in SAP R/3 ermöglicht einen wechselseitigen Informationszugriff im gesamten System mit einer einheitlichen Datenbasis. Aufgrund der Verknüpfung mit den anderen System-Komponenten, ist ein unabhängiger Einsatz der Projektmanagement Software ohne das ERP-System R/3 nicht möglich. Für Unternehmen, die nicht bereits über ein SAP R/3-System verfügen, bedeutet dies eine Anpassung der gesamten IT an die Systemlösung von SAP. Fazit Die zentrale Projektmanagement Software ist ein Werkzeug für die klassische Projektplanung. Diese Systeme sind darauf ausgelegt die Planungs- und Kontrollprozesse des klassischen Projektmanagements zu unterstützen. Sie bieten gezielt Lösungen an, um die Darstellung und Verwaltung der Projektdaten effizienter zu gestalten.

38 2. Grundlagen 38 Der zeitliche Rahmen wird von dem Umfang des Projekts vorgegeben. Die Dauer kann dabei einige Monate oder teilweise auch Jahre betragen. Die Planungen im Projektmanagement sind eher taktisch und haben große Bedeutung für den Verlauf des gesamten Projekts. Die Planung der Projektaufgaben auf Grundlage der Netzplantechnik bildet eine Kernfunktionalität der vorgestellten Programme. Es erlaubt der Projektleitung, die Aufgaben in komplexen Projektabläufen auch in großen Zeitspannen anzuordnen und zu optimieren. Die Dokumentation des Projekts ist eine zentrale Aufgabe im klassischen Projektmanagement und ein wichtiges Mittel der Kommunikation. Hierbei geht es um die Planung und Distribution von Projektplänen, beispielsweise in Form eines Personaleinsatzplans. Im agilen Projektmanagement ist die genaue Planung und Dokumentation des gesamten Projekts nicht so ausgeprägt. Aufgrund unterstellter unvorhersehbarer Veränderungen der Anforderungen im Projektverlauf wäre die Gültigkeit der erstellten Dokumente nur kurz. Die Planungsaktivitäten der Projektleitung konzentrieren sich auf die Erstellung des bereits genannten Project Data Sheet und des Iterationsplans. Die Planung mehrerer Iterationen orientiert sich an festgelegten Projektzielen, ohne dabei eine detailliert Aufgabenplanung vorzunehmen. Die Planung und Koordination der einzelnen Projektaufgaben einer bevorstehenden Iteration verlagert sich auf das Projektteam Zeiterfassungssysteme Zeiterfassungssysteme werden verwendet, um gezielt die tatsächlichen Aufwände und Kosten von Projektaufgaben zu erfassen. Die ermittelten Zeiten zeigen die aktuelle Projektentwicklung und bilden für das Projektcontrolling eine wichtige Grundlage zur Steuerung des Projektverlaufs. Zeiterfassungssysteme gibt es als einzelne Softwarelösung oder als integrierte Komponente einer Projektmanagement Applikation. Um einen Überblick des Soll-/Ist- Aufwands zu bekommen, werden die erfassten Zeiten mit den Vorgaben aus der Projektplanung verglichen. Dazu werden die Zeiten von dem Zeiterfassungssystem über Schnittstellen bereitgestellt oder innerhalb einer Anwendung für alle Komponenten verfügbar gemacht. Stellvertretend für Zeiterfassungssysteme soll im folgenden Absatz die integrierte Zeiterfassung der A-Plan Projektmanagementsoftware [www:braintool] betrachtet werden. Das Zeiterfassungsmodul der A-Plan Projektmanagementsoftware stellt eine Erweiterung bereit, mit der Mitarbeiter ihre angefallenen Aufwände für die Projektaufgaben erfassen können. Durch die Angabe von Zeitintervallen werden die einzelnen Einträge in der Zeiterfassung aufgenommen. Die Diagramme und Darstellungen der Projektpläne werden mit den Daten aus der Zeiterfassung ebenfalls aktualisiert. Der Export und Austausch erfasster Zeiten als Report erfolgt im Standardformat gängiger Tabellenkalkulationsanwendungen. Diese Reports liefern Informationen über den Soll-/Ist-Aufwand der Projektaktivitäten und die damit verbundenen Kosten innerhalb eines gewählten Zeitraums.

39 2. Grundlagen Ticketing Systeme Die Kommunikation innerhalb von Projekten und bei dem Betrieb von Servicestellen produziert täglich eine Menge Informationen. Oftmals ist es schwierig, dabei den Überblick zu behalten, und eine eingehende Nachricht sofort in den richtigen Kontext einzuordnen. Die Einführung von Ticketing Systemen sorgt hier dafür, dass alle Anfragen aufgenommen, kanalisiert und deren Abarbeitung überwacht wird. Ticketing Systeme unterstützen das Informationsmanagement dieser Prozesse. Die Korrespondenz einzelner Aufgaben, wie einer Support-Anfrage oder der Aktivität eines Teilprojekts, können hiermit systematisch erfasst und bearbeitet werden. Aufgaben können effizient unter mehreren Mitarbeitern aufgeteilt und die damit verbundene Kommunikation sinnvoll erfasst werden. 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 nach dem Erwerb eines Produktes oder einer Dienstleistung weiterhin zu unterstützen. Diese Systeme sind organisatorische Mittel zur Abwicklung von Kundenanfragen im Bereich der After Sales Aktivitäten. Die Serviceanforderungen werden zuvor mit dem Kunden vereinbart und als Service-Level-Agreements dokumentiert. Ein Vertrag enthält alle Rechte und Pflichten des Unternehmens, die in Form von Support-Dienstleistungen erbracht werden müssen. Eingesetzt werden Ticketing Systeme meist in den Call Centern der Unternehmen, welche die Anfragen der Kunden telefonisch und per entgegennehmen. Die aufgenommenen Tickets werden zentral verwaltet und den einzelnen Kundenbetreuern zugewiesen. Die Ticketing Systeme helfen, den Informationsfluss zum Kunden im Prozess der Problemlösung aufrecht zu erhalten und ihn bei allen Statusänderungen der Tickets unmittelbar zu informieren. Als weitere Variante von Ticketing Systemen werden Bugtracker in der Softwareentwicklung eingesetzt. Mit ihnen werden die Informationen zu Programmfehlern, Funktionswünschen und Supportanfragen im gesamten Software Life Cycle erfasst, aufgezeichnet und aufbereitet. Ein rollenbasierter Zugriff auf ein Bugtracking System erfolgt von der Projektleitung, den Entwicklern und dem Kunden. Das System bildet hiermit eine zentrale Schnittstelle für die Kommunikation und das Informationsmanagement in der Softwareentwicklung. Außerdem

40 2. Grundlagen 40 lassen sich spezifische Workflows erstellen, die eine automatisierte Verarbeitung der Programmfehler ermöglichen. Ansonsten würden eventuell aufgetretene Programmfehler verloren gehen oder nicht ausreichend priorisiert werden. Die erstellte Datenbasis liefert genaue Aussagen über die behobenen Fehler und Fehlerzeiten sowie die damit verbundene Korrespondenz. Zusammen mit Versionsverwaltungssystemen bildet Bugtracking einen wichtigen Teil des Konfigurationsmanagements in der Softwareentwicklung. Die eingesetzte Ticketing Software unterstützt das Informationsmanagement und verwaltet die Tickets, Prioritäten, Verantwortlichkeiten und die Kontakthistorie der Kommunikation mit dem Kunden. Außerdem bieten die Systeme eine ständige Überwachung und Prüfung aller Tickets, somit können vorhandene Tickets gegebenenfalls eskaliert werden. Die Resultate der Monitoring-Prozesse dienen als Grundlage, um die Arbeitsprozesse noch effektiver zu gestalten. Die Ticketing Systeme sind in ihrer Anwendung meist sehr speziell und an das entsprechende Einsatzgebiet angepasst. Die Systeme sind ausgelegt, um die für die Bearbeitung des Tickets relevanten Informationen strukturiert zu erfassen. Der Einsatz eines Ticketing Systems in der Form eines Bugtrackers eignet sich damit nur für die Softwareentwicklung und nicht für ein anderes Anwendungsgebiet. Der zeitliche Ablauf bei der Bearbeitung der Tickets und die damit verbundenen Aktivitäten sind ebenfalls vom Umfeld abhängig. Während bei der Softwareentwicklung die Erfüllung bestimmter Tickets über die Versionsnummern der Software definiert wird, erfolgt die Bearbeitung der Tickets in Servicestellen meist zeitnah und in Abhängigkeit der Priorität Fazit Die hier vorgestellten Softwarelösungen zur Zeitplanung und Zeiterfassung im Rahmen des Projektmanagements sind auf unterschiedliche Einsatzgebiete ausgerichtet. Unterstützung bieten die Systeme vor allem bei der Dokumentation und dem Informationsmanagement in Projekten. Der Terminkalender ist ein typisches Werkzeug zur Planung von Aktivitäten eines Mitarbeiters. Der Kalender ermöglicht dem Mitarbeiter, einen zeitlichen Zusammenhang zwischen den Tätigkeiten des Tagesgeschäfts, Terminen und projektübergreifenden Aktivitäten herzustellen. Der Terminkalender ist universell und kann für die Zeitplanung von allen Mitarbeitern eingesetzt werden. Die softwarebasierten Kalender gehören ebenfalls zur Standardsoftware in Unternehmen, und viele Mitarbeiter haben bereits Erfahrungen im Umgang mit diesen Programmen gemacht. Leider gestaltet sich die Pflege der aufeinanderfolgenden Projektvorgänge im Terminkalender als zu aufwändig, wenn es zu Veränderungen in der Projektplanung kommt. Der Einsatz einer Software zur Synchronisation der Projektaufgaben mit der Projektmanagent Software löst dieses Problem nur teilweise, da der Informationsfluss von

41 2. Grundlagen 41 der Projektplanung nur in Richtung der Projektmitarbeiter erfolgt. Die Erfassung von Aufwand und Fortschritt ist auf das lokale Programm beschränkt und wird der Projektleitung nicht unmittelbar bereitgestellt. Der Report des aktuellen Projektfortschritts ist also mit einem Mehraufwand verbunden. Die Planung der Projektaufgaben mit einem Terminkalender gestaltet sich aufgrund häufiger Veränderungen als zu unflexibel und zeitaufwändig. In agilen Projekten helfen Terminkalender und Aufgabenlisten bei der Zeitplanung der einzelnen Mitarbeiter. Bei der Projektarbeit in kleinen Teams erfolgt die Koordinationen der Aufgaben hauptsächlich über die direkte Kommunikation mit dem verantwortlichen Mitarbeiter und richtet sich dabei nach den agilen Werten. In selbstorganisierten Projektteams ist es wichtig, dass die Mitarbeiter ihre eigene Arbeitsbelastung (engl. workload) einschätzen können. Besonders zu Beginn einer Iteration müssen die Projektmitarbeiter zusammen mit der Projektleitung anhand ihrer aktuellen Arbeitslast realistische Iterationsziele vereinbaren. Das Workload-Management der Mitarbeiter mit Aufgabenlisten, ist gerade bei zeitlich parallelen Projekten schwierig. Um die Projektabläufe planen, korrigieren und kontrollieren zu können, wird in vielen Unternehmen Projektmanagement Software eingesetzt. Diese Software unterstützt die Dokumentation und Informationsverwaltung bei der Planung und Umsetzung von Projekten. Zudem verringert Projektmanagement Software den Planungs- und Dokumentationsaufwand, wie beispielsweise bei der sonst rechenintensiven Planung mit Hilfe von Netzplänen oder Balkendiagrammen. Die Projektplanung ist eine Hauptaufgabe der Projektleitung und verlangen daher fundiertes Wissen über die eingesetzten Plantechniken, wie beispielsweise die Netzplantechnik. Die eingesetzten Softwaresysteme haben ganz in Abhängigkeit von ihrem Einsatzgebiet unterschiedliche Anforderungen zu erfüllen. Es existieren daher Softwareprodukte von der Einzelplatz-Applikation bis hin zur integrierten Systemlösungen, welche an die Geschäftsabläufe der Unternehmen angepasst werden. Einige Projektmanagement Softwaresysteme bieten Möglichkeiten zur Erweiterung der Funktionalität durch Anbindung von Komponenten wie z.b. einer Zeiterfassung. Die Zeit- und Aufwandserfassung in Projekten liefert wichtige Informationen für das Projektcontrolling. Nur mit einem Zugriff auf die aktuellen Ist-Daten können die Entscheidungsträger der Projektleitung die Projektabläufe bewerten und steuern. Die Zeiterfassung ist oft eine Komponente innerhalb von Projektmanagement Systemen. Der direkte Datenaustausch zwischen den einzelnen Systemkomponenten verbessert den Informationsfluss und reduziert einen Mehraufwand bei der Datenpflege. Das agile Projektmanagement zielt darauf, mit einem schlanken Entwicklungsprozess dem Kunden möglichst schnell eine Wertschöpfung zu liefern. Die Aktivitäten der Planung und Dokumentation des Projekts reduzieren sich dabei auf den gerade notwendigen Umfang. Mit Standardsoftware wie Textverarbeitungs- und Tabellenkalkulationsprogrammen kann daher die zweckmäßige Dokumentation beispielsweise in Form eines Iterationsplans oder Project Data Sheets erfolgen. Das bedeutet nicht, dass Projektmanagement Software z.b. zur Erstellung von Balkendiagrammen in agilen Projekten generell nicht eingesetzt wird, sondern

42 2. Grundlagen 42 es ist von den projektspezifischen Eigenschaften abhängt. Bei kleinen Projektteams erübrigt sich der Einsatz umfassender Projektmanagement Software, da die Planungsaktivitäten in agilen Projekten einen anderen Schwerpunkt setzen. Ticketing Systeme stellen in Abhängigkeit des Einsatzgebiets eine Methode dar, um Aufgaben organisiert abarbeiten zu können. Die Systeme versuchen die erfassten Aufgaben und deren Verlauf der Bearbeitung möglichst in der Gesamtheit zu dokumentieren. So können einzelne Aufgaben an unterschiedliche Mitarbeiter verteilt werden, ohne dass die Übergabe aufwändig kommuniziert werden muss. Diese Art Aufgabenliste wird zur Koordination innerund außerhalb eines Projektkontextes verwendet. Der zeitliche Zusammenhang verschiedener Aufgaben ist mit den Ticketing Systemen nur schwer zu überblicken. Die Priorisierung der Aufgaben ist auch weniger durch Termine bestimmt, sondern orientiert sich zweckmäßig an anderen Parametern. Neben den Funktionalitäten des Informationsmanagements liefern Ticketing Systeme eine erweiterte Form einer Aufgabenliste. Als mögliche Unterstützung für die Zeitplanung der Mitarbeit in agilen Projekten, fehlt die Darstellung zeitlicher Zusammenhänge. Die betrachteten Softwarelösungen zur Zeitplanung und Zeiterfassung im Rahmen des Projektmanagements sind an die klassischen Managementmethoden angepasst. Aufgrund der unterschiedlichen Vorgehensweise bei der Planung und Durchführung von klassischen und agilen Projekten (Abschnitt 2.2) liefern diese Werkzeuge im Rahmen der Zeitplanung in agilen Projektabläufen keine hinreichende Unterstützung Zusammenfassung Das agile Projektmanagement passt vor allem zur innovativen Produktentwicklung in kleinen Projektteams. Die Etablierung eines leichtgewichtigen und iterativen Entwicklungsprozesses unterstützt die Planung und Durchführung von Projekten mit hohem Innovationsgrad und unvorhersehbaren Veränderungen der Anforderungen. Agiles Projektmanagement verlangt dabei aber ein funktionierendes Projektteam, das sich durch ein hohes Maß an Eigenverantwortung, Selbstorganisation und Selbstdisziplin auszeichnet. Die Projektplanung unterteilt sich in zwei Ebenen, der weitgehenden groben Iterationsplanung des gesamten Projekts und der genauen Planung einer bevorstehenden Iteration. Während die Projektleitung den gesamten Projektablauf koordiniert, ist das Projektteam für die Koordination der Projektaufgaben vereinbarter Ziele einer Iteration zuständig. Die Projektmitarbeiter müssen dabei ihre individuelle Zeitplanung selbst vornehmen. Die betrachteten Softwaresysteme für die Zeitplanung in Projekten liefern nur Werkzeuge für das klassische Projektmanagement. Die Systeme bieten umfangreiche Werkzeuge zur Erstellung, Verwaltung und Optimierung detaillierter Pläne des gesamten Projekts z.b. auf

43 2. Grundlagen 43 Basis der Netzplantechnik. Vor dem Hintergrund der Zeitplanung der Mitarbeiter in agilen Projekten liefern die betrachteten Planwerkzeuge keine ausreichende Unterstützung. Für die Projektmitarbeiter in agilen Projekten müssen daher andere Anforderungen an ein System zur Zeitplanung formuliert werden. Das Planwerkzeug sollte daher einfach, zweckmäßig, verständlich und auch in heterogenen Projektteams einsetzbar sein. Zudem sollte der Pflegeaufwand auch bei veränderten Rahmenbedingungen möglichst gering sein. Die geeignete Kombination eines persönlichen Kalenders und einer Aufgabenliste stellt hier eine Lösung dar. Im folgenden Kapitel 3 werden die Anforderungen an ein Zeitplanungssystem für die Projektmitarbeiter analysiert und festgelegt.

44 3. Anforderungsanalyse Auf Basis der in Kapitel 2 herausgearbeiteten Rahmenbedingungen der Zeitplanung, folgt hier die Analyse und die Definition der Anforderungen an das zu erstellende System. Zunächst werden die Ziele verschiedener Mitarbeiter aufgegriffen und zusammengefasst dargestellt. Danach werden die Systemanforderungen hinsichtlich der Unterstützung der Zeitplanung der Mitarbeiter erläutert. Es folgt die Darstellung und Klassifizierung der für die Planung benötigten Ereignisse. Abschließend wird die Systemumgebung aufgezeigt und einzelne Vorgänge in Anwendungsfällen werden genauer beschrieben. Auf Grundlage der Anforderungsanalyse kann im darauf folgenden Kapitel 4 der Entwurf des Systems erfolgen Anwenderziele Die Projektplanung ist eng mit der Arbeitszeitplanung verknüpft und beide Planungsebenen teilen sich gewisse Informationen. Von dem System werden Daten für die Projektmitarbeiter, Projektleitung und Geschäftsführung bereitgestellt. Auf Grundlage der Interviews aus Abschnitt 2.1 wurden folgende Rollen und Ziele definiert: Rolle Projektmitarbeiter Projektleitung Geschäftsführung Ziele - persönliche Arbeitszeitplanung - Zeiterfassung der zugeteilten Projektaufgaben - Darstellung der aktuellen Auslastung - übersichtliche Darstellung der Projektplanung - Bestimmung der Auslastung von Mitarbeitern (Kapazitätsplanung) - Darstellung der Ist-Werte von Projekten (Aufwand, Fortschritt, Kosten) - wirtschaftliche Bewertung der Projekte - langfristige Projekt- und Personalplanung Tabelle 3.1.: Rollen und Ziele der Anwender

45 3. Anforderungsanalyse 45 In der Praxis werden von Unternehmen viele verschiedene Softwaresysteme für das Informationsmanagement in Projekten eingesetzt. Da die eingesetzten Informationssysteme von Unternehmen zu Unternehmen und Projekt zu Projekt sehr unterschiedlich sein können, werden hier nur die Anforderungen an ein Zeitplanungssystem aus Sicht der Projektmitarbeiter betrachtet. Die von diesem System bereitgestellten Funktionalitäten sind allgemein gültig und auch unabhängig von einem konkreten Projekt einsetzbar. Die Erweiterung bzw. Anbindung des Zeitplanungssystems an vorhandene Softwaresysteme kann bei Bedarf über entsprechende Schnittstellen realisiert werden Einordnung des Systems Für die Planungsaktivitäten im klassischen Projektmanagement existieren bereits eine Reihe von Softwarelösungen. Angepasst auf das jeweilige Projekt können die Prozesse der Planung, Überwachung und Steuerung durch den Einsatz von Projektmanagement Software effektiver gestaltet werden. Im Gegensatz dazu stehen den Mitarbeitern in agilen Projekten bei ihrer Arbeitszeitplanung mit Terminkalender und Aufgabenlisten nur unzureichende Planwerkzeuge zur Verfügung. Das Zeitplanungssystem versucht, für diese Planungsebene eine bessere Unterstützung zu bieten. Ziel ist es dabei, die Zeitplanung möglichst flexibel und dynamisch zu gestalten. Neben der Zeitplanungskomponente werden zusätzlich Funktionen zur Zeit- und Fortschrittserfassung der Projektaktivitäten bereitgestellt. Die Mitarbeiter werden gezielt bei ihren Planungs- und Verwaltungsaktivitäten unterstützt, um ihnen einen Überblick ihrer individuellen Arbeitslast zu geben. Unter Berücksichtigung der Arbeitslast kann die Projektleitung zusammen mit dem Projektteam die termingerechte Fertigstellung der Projektziele besser koordinieren. (Abbildung 3.1) Abbildung 3.1.: Einordnung des Systems

46 3. Anforderungsanalyse Anforderungen In diesem Abschnitt wird durch eine wiederholte Betrachtung der Problemstellung eine Liste von Anforderungen erstellt, die an ein Zeitplanungssystem gestellt werden. Wie bereits in Kapitel 2 erläutert, existieren keine hinreichenden Planwerkzeuge für die Zeitplanung der Mitarbeiter. Die Planung mit einem Terminkalender stellte sich als unpraktikabel und zeitaufwändig heraus, wenn damit Projektaufgaben geplant werden müssen (Abschnitt 2.3.1). Die Verwendung einer Aufgabenliste entfällt als Alternative, da an eine übersichtliche Darstellung der zeitlichen Zusammenhänge fehlt. Die Zeitdauer einzelner Aufgaben wird nicht geeignet veranschaulicht, so dass sich die aktuelle Arbeitslast eines Mitarbeiters damit nur schwer bestimmen lässt (Abschnitt 2.3.2). Die individuelle Zeitplanung auf Grundlage erstellter Projektpläne ist gerade bei der Einbeziehung in mehrere Projekte unübersichtlich. Hier müssen die einzelnen Projektaufgaben der verschiedenen Projektpläne entnommen und in eine eigene Zeitplanung übertragen werden Individuelle Zeitplanung Ein geeignetes Planwerkzeug soll den Mitarbeitern bei ihrer individuellen Zeitplanung die notwendige Unterstützung geben. Das System soll eine übersichtliche, zeitliche Darstellung von Terminen und Projektaufgaben innerhalb eines Kalenders bereitstellen und zugleich eine effiziente Datenpflege ermöglichen. Die Projektaufgaben können dabei durch einen entsprechenden Planer automatisiert, zeitlich angeordnet und in einzelne Kalendereinträge umgewandelt werden. Diese Berechnung des Zeitplans wird über das Zeitplanungssystem realisiert. Eine aufwändige Planung der Projektaufgaben durch den Mitarbeiter von Hand ist damit nicht mehr nötig. Die Korrektur bestimmter Daten, wie der zeitliche Rahmen (Start- und Endtermin) oder die Änderung der Priorität einer Projektaufgabe, wird bei einer erneuten Berechnung 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 seiner aktuellen Arbeitslast zu geben, um ein verbessertes Workload-Management zu ermöglichen. Wichtig ist hier vor allem, dem Mitarbeiter eine einfache Verwaltung seiner geplanten Aktivitäten zu bieten und ihn auf Konflikte in seiner Zeitplanung rechtzeitig hinzuweisen. Der Mitarbeiter wird informiert, falls der zuvor geschätzte Soll-Aufwand einer Projektaufgabe bereits durch den von ihm geleisteten Ist-Aufwand erschöpft ist. Außerdem wird der Mitarbeiter benachrichtigt, wenn ein geplanter Abgabetermin einer Projektaufgabe nicht mehr eingehalten werden kann. Dieser Planungskonflikt entsteht z.b. sobald der aktuelle Soll-Aufwand in die verbleibende Zeitspanne bis zum Abgabetermin nicht mehr vollständig eingeplant werden kann oder wenn dem Mitarbeiter ein Termin bzw. ein zusätzliches Arbeitspaket höherer Priorität zugewiesen wird. Das Zeitplanungssystem warnt den Mitarbeiter frühzeitig vor

47 3. Anforderungsanalyse 47 zeitlichen Engpässen und bietet ihm damit die Möglichkeit rechtzeitig zu reagieren, um die termingerechte Umsetzung der Projektaufgaben nicht zu gefährden. Abbildung 3.2.: Individuelle Zeitplanung mit dem System (reduzierte Darstellung) Zeiterfassung Neben der Zeitplanung soll der Aufwand der geplanten Aufgaben auch zeitnah erfasst werden. Der bereits benötigte Aufwand wird dem System bereitgestellt und liefert wertvolle Informationen über den Fortschritt einzelner Projektaufgaben. Diese Daten fließen dabei direkt wieder in die Zeitplanung der Ereignisse ein, um die bereits verstrichene Zeit zu berücksichtigen. Ein Vergleich des Soll-/Ist-Aufwands liefert dem Mitarbeiter eine bessere Einschätzung seiner eigenen Leistung und hilft ihm für zukünftige Arbeitsaufträge eine verbesserte Aufwandsschätzung abzugeben. Desweiteren werden mit der Zeiterfassung detaillierte Werte protokolliert, welche die wirtschaftliche Bewertung von ganzen oder auch ausgewählten Projektteilen in einem wählbaren Zeitraum z.b. einer Iteration ermöglichen. Dieses lässt sich auch auf die Ermittlung von Kosten und die Analyse der Produktivität der Mitarbeiter übertragen.

48 3. Anforderungsanalyse 48 Die erfassten Zeiten bilden zusätzlich eine unternehmensspezifische Datenbasis, in welcher der tatsächliche Aufwand von Projektaufgaben gespeichert ist. Für die Aufwandsschätzung zukünftiger Aufträge und Projekte ist dies von unschätzbarem Wert. Mit einer Annotierung der bereits abgeschlossenen Projekte können gezielt Aufwände von einzelnen Projektaktivitäten gesucht werden. Auf Grundlage der gesammelten Erfahrungswerte können beispielsweise Analogieverfahren zur Aufwandsschätzung für ähnliche Aufgaben in aktuellen Projekten eingesetzt werden Zugriff und Einsatzgebiet Die Bereitstellung von Informationen auch außerhalb des Unternehmens und der Zugriff auf die Daten des Intranets wird zunehmend wichtiger. Der mobile Zugriff auf s, Terminplanung und andere Informationsquellen ist zu einem festen Bestandteil in den Unternehmen geworden und sorgt für einen verbesserten Informationsfluss. Das Zeitplanungssystem erlaubt dem Anwender die Darstellung der Arbeitszeitplanung und Auslastung der Mitarbeiter, sowie Informationen über aktuelle und vergangene Projekte abzurufen. Der Zugriff auf diese Daten sollte den Anwendern nicht nur innerhalb des Firmennetzwerks sondern auch standortunabhängig bereitgestellt werden. Besonders bei entfernten Arbeitsstätten ist eine dezentrale Bereitstellung aktueller Planungs- und Statusinformationen wichtig. Desweiteren ergeben sich bei der Datenpflege unterschiedliche Zugriffsszenarien, welche eine Verteilung von Rollen mit entsprechenden Benutzerrechten notwendig machen Eingrenzung Zeitplanungsproblem Die Grundlage für die Planung bilden die zeitlichen Rahmenbedingungen der Termine und Projektaufgaben. Innerhalb der Kalenderdarstellung müssen diese Ereignisse mit Hilfe eines Zeitplanungsalgorithmus entsprechend ihrer Eigenschaften angeordnet werden. Aus den Eigenschaften wie Zeitrahmen, Dauer und Priorität ergeben sich für jedes Ereignis unterschiedliche Nebenbedingungen, die bei der Planung berücksichtigt werden müssen. Das Zeitplanungsproblem umfasst dabei die Zeitplanung mit den gegebenen Beschränkungen. Gibt es bei einem Zeitplanungsproblem eine Zeitplanung, welche alle zeitlichen Nebenbedingungen erfüllt, dann ist diese Planung eine Lösung des Problems. Doch die Lösung solcher Probleme stellt eine echte Herausforderung dar. Das Finden einer optimalen Lösung gehört zu den Aufgaben kombinatorischen Optimierung als Teilgebiet des Operations Research. Zu dieser Problemgruppe zählen Zuordnungs-, Reihenfolge-, Gruppierungs- und Auswahlprobleme. Zur Lösung dieser Probleme werden in Programmen Algorithmen formuliert, die Speicherplatz und vor allem Rechenzeit benötigen.

49 3. Anforderungsanalyse 49 In Abhängigkeit von dem jeweiligen Problemtyp kann eine allgemeine Aussage über den Rechenaufwand eines Algorithmus gemacht werden. Der Rechenaufwand eines Algorithmus wird auch als Ordnung f (n) bzw. O(f (n)) bezeichnet. Handelt es sich bei der Funktion f (n) um ein Polynom braucht man einen polynomialen Aufwand (z.b. O(f (n 2 ))), ansonsten exponentiellen Aufwand (z.b. O(f (5 n ))). Die Komplexitätstheorie beschreibt welchen Rechenaufwand einzelne Problemtypen verursachen, um ein optimale Lösung zu finden. Die Optimierungsprobleme 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 polynomialen Aufwand löst Für Optimierungsprobleme der Klasse NP-schwer mit vielen Eingabeparamentern lässt sich eine optimale Lösung nicht in angemessener Zeit ermitteln. Die Anwendung von Heuristiken hilft hier dennoch, gute zulässige Lösungen zu bestimmen. Zeitplanungsprobleme bzw. Stundenplanprobleme gehören zu den NP-schweren Problemen. Der Zeitplanungsalgorithmus für das Ereignis-Scheduling, welcher in dieser Arbeit entwickelt wird, liefert keine optimale Lösung im Sinne der kombinatorischen Optimierung. Vielmehr wird dem Anwender nur eine mögliche Lösung dargestellt. Aus dieser Darstellung erhält er einen Überblick der aktuellen Ereignisse und auf Basis dieser Informationen kann er seine Zeitplanung im Tagesgeschäft vornehmen Definition Ereignis Ein Ereignis leitet einen bestimmten Vorgang bzw. eine bestimmte Aktivität ein und ist hier eine Verallgemeinerung aller planbaren Elemente in der Zeitplanung, wie etwa Projektaufgaben, Meilensteine, Termine und Besprechungen. Ein Ereignis wird dabei mit den folgenden Eigenschaften definiert: Ort (Platz der Verrichtung) Zeit (Start- und Endzeitpunkt) Ressourcen (Personen, Betriebsmittel) Kontext (Umfeld des Ereignisses)

50 3. Anforderungsanalyse 50 Die Eigenschaften der Ereignisse werden weitgehend durch die Projektplanung bzw. Iterationsplanung oder den Mitarbeiter selbst vorgegeben. Der Ort beschreibt den konkreten Ausführungsort (z.b. Standort des Unternehmens, Raum) eines Ereignisses. Außerdem ergibt sich für jedes Ereignis durch den Iterationsplan ein verbindlicher Zeitrahmen (Start- und Endtermin, Dauer), in dem die Projektaufgabe ausgeführt werden soll. Ebenfalls werden bei der Iterationsplanung für die Verrichtung der Projektaufgaben die Verantwortlichkeiten und damit die Personalressourcen zugewiesen. Der Kontext des Ereignisses ergibt sich aus der Beziehung zum übergeordneten Projekt oder einer Aktivität aus dem Tagesgeschäft. Grundlage für die Zeitplanung eines Mitarbeiters sind hier vorrangig die zeitlichen Eigenschaften der ihm zugeteilten Ereignisse und der Kontext, in dem sie ausgeführt werden. Zudem sind die Personalressourcen durch die Zuweisung der Verantwortlichkeit vorgegeben. Der Ort und die benötigten Betriebsmittel werden im Zeitplanungssystem nicht berücksichtigt und müssen von der Projektleitung oder dem Mitarbeiter selbst koordiniert werden Ereignis Termin Dieser Ereignistyp beschreibt alle Aktivitäten die im Sprachgebrauch als Termin bezeichnet werden. Sie entsprechen also einem üblichen Kalendereintrag. Diese Einträge werden über einen fixen Start- und Endtermin definiert, der Zeitraum dazwischen ergibt die Dauer dieses Ereignisses. Beispiele für solche Ereignisse sind Besprechungen und Geschäftsreisen. Für einen Termin ist der Zeitraum seiner Verrichtung also zeitlich festgelegt und mit den beteiligten Personen fest vereinbart. Die Ausführung zu einem anderen Zeitpunkt erübrigt sich damit. Anders verhält es sich mit der Zeitplanung von Projektaktivitäten, für die nur ein Zeitrahmen gegeben ist und der Mitarbeiter selbst den konkreten Zeitpunkt der Verrichtung wählen kann. Die Darstellung von Ereignissen mit Angaben, wie es für Termine üblich ist, zeigt sich als zu unflexibel, um die zeitliche Planung von Projektaufgaben damit abzubilden. Wird die Planung der Projektaktivitäten eines Mitarbeiters mit Hilfe dieser Ereignisse vorgenommen, ergibt sich ein großer Pflegeaufwand, auch wenn nur kleine Korrekturen an bestimmten Ereignissen vorgenommen werden. Aufgrund der Zeitplanung wirken sich Veränderungen an wenigen Ereignissen auf die folgenden aus, welche dann zeitlich verschoben werden. Eine Iteration mit einem Start- und Endtermin gibt eine Zeitspanne vor, in dem die Projektaktivität variabel eingeplant werden kann. Abhängig ist die Planung von der Auslastung der Mitarbeiter. Desweiteren wird die Planung von den aktuellen Geschäftsprioritäten bestimmt, Projekte werden möglicherweise für vorrangige Projekte zurückgestellt. Für die zeitliche Planung von Projektaufgaben innerhalb eines Kalenders gelten somit andere Anforderungen, welche in einem geeigneten Ereignistyp definiert werden müssen.

51 3. Anforderungsanalyse Ereignis Projektaufgabe Für die Projektaufgaben der Mitarbeiter muss eine Darstellung gefunden werden, welche alle wichtigen Informationen eines Ereignisses speichert. Für jede Projektaufgabe gibt es zumindest zwei zeitliche Merkmale, mit denen sie beschrieben werden kann. Zum einen ist es der geschätzte Soll-Aufwand, welche in der Planung der Iterationsziele analysiert und vereinbart 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 eigentliche Verrichtung der Aufgabe durch den zugeteilten Mitarbeiter selbst eingeteilt und ausgeführt werden. Aus diesen Daten lassen sich Ereignisklassen bilden, welche die sinnvollen Kombinationen der Zeitmerkmale einer Aktivität darstellen. Die unterschiedlichen Ereignisklassen werden im Folgenden definiert. Definierter Endtermin Diese Ereignisklasse beschreibt alle Aufgaben, die bis zu einem bestimmten Termin erledigt sein müssen. Der Termin kann dabei durch ein Datum beschrieben werden oder durch einen Zeitstempel mit Datum und Uhrzeit. Das Zeitintervall dieser Klasse ergibt sich durch den aktuellen 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: Entweder erfolgt sie von dem Starttermin in Richtung Endtermin, oder von dem Endtermin in Richtung Starttermin. Für Ereignisse dieser Klasse kann es passieren, dass die verfügbare Zeit innerhalb des Planungsintervalls kleiner als der noch benötigte Aufwand ist. In diesem Fall liegt ein Konflikt in der Planung vor, welcher dem Benutzer durch eine entsprechende Nachricht mitgeteilt wird. Typische Ereignisse dieses Typs sind der Launch einer Anwendung oder der Redaktionsschluss eines Artikels. Abbildung 3.3.: Ereignis mit definiertem Endtermin, Vorwärtsplanung Abbildung 3.4.: Ereignis mit definiertem Endtermin, Rückwärtsplanung

52 3. Anforderungsanalyse 52 Definierter Starttermin Ein weitere Ereignisklasse beschreibt Aktivitäten, die nur einen vorgegeben frühesten Starttermin (t1) besitzen. Die Zeitplanung dieses Ereignistyps beginnt damit, dass ab dem Starttermin der noch benötigte Aufwand in die verfügbaren Zeiträume der folgenden Arbeitstage eingeplant wird. Dies geschieht solange, bis der gesamte Aufwand komplett eingeplant wurde. Planungskonflikte können bei dieser Klasse nicht entstehen, da das Intervall durch keinen Endtermin beschränkt wird. Liegt der definierte Starttermin in der Vergangenheit, so wird er bei der Planung auf die aktuelle Zeit korrigiert. Ein Ereignis, welches dieser Klasse angehört, ist z.b. die Einarbeitungszeit eines neuen Kollegen, der in zwei Wochen seine Arbeit 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 Zeitintervalls (t1, t2) erfolgen sollen. Die gesamt Aufwände der Aktivitäten sollten also innerhalb der festgelegten Zeitspanne über die Zeitplanberechnung entsprechend angeordnet werden. Die Zeitspanne wird über den Aufwand der Aufgabe und einen zusätzlich eingeplanten Zeitpuffer definiert. Stehen innerhalb dieses Intervalls nicht genügend Zeitressourcen zur Verfügung, so wird der Benutzer über diesen Planungskonflikt informiert. Liegt zum Zeitpunkt der Berechnung der angegebene Starttermin bereits in der Vergangenheit, so wird dieser auf die aktuelle Zeit korrigiert. In dem Fall verhält sich die Klasse identisch zu der Ereignisklasse mit einem festen Endtermin. Diese Ereignisse können ebenfalls vorwärts und rückwärts innerhalb der gegebenen Zeitspanne eingeplant werden. Abbildung 3.6.: Ereignis innerhalb eines definierten Zeitintervalls, Vorwärtsplanung

53 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 jeweilige Starttermin wird implizit bei der Berechnung des Zeitplans auf die aktuelle Zeit gesetzt. Von dem Zeitpunkt aus erfolgt die Planung des Aufwands durch Verteilung auf die freien Zeiträume der folgenden Arbeitstage. Die Zeitspanne ist durch keinen Endtermin beschränkt, deshalb können bei dieser Klasse keine Planungskonflikte auftreten. Diese Ereignisklasse eignet sich für allgemeine Forschungs- und Entwicklungsaufgaben, welche an keinen festen Termin gebunden 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 den zeitlichen Eigenschaften eine Priorität der Aufgaben eingeführt. Diese hilft bei der Ordnung der Aufgaben nach gegebenen Geschäftsprioritäten oder nach der vom Mitarbeiter gewünschten Priorisierung. Ereignisse mit niedriger Priorität werden von Ereignissen mit hoher Priorität verschoben und zurückgestellt. Ereignis Fortschritt Eine weitere wichtige Eigenschaft definiert der Fortschritt einer Aufgabe. Mit einer Prozentangabe kann Fortschritt des Ereignis bzw. Aufgabe charakterisiert werden. Diese Form der Fortschrittsangabe ermöglicht dem Mitarbeiter, einen Wert des Fertigstellungsgrades einer Aufgabe zu schätzen. Der benötigte zeitliche Aufwand für eine Aufgabe sollte möglichst proportional zum eigentlichen Fortschritt sein. Die Fehlschätzungen eines Soll-Aufwands zeigt ein anderes Verhalten und lässt sich identifizieren. Beispielsweise: Wenn in 5% der verbleibenden Zeit noch 80% der Aufgabe erledigt werden muss, wurde die Aufgabe während der Aufwandsschätzung falsch bewertet.

54 3. Anforderungsanalyse 54 Ereignis Wiederholungen Die Ereignisse können auch in festgelegten Abständen wiederholt werden. Für die Termine und Aufgaben kann eine Ereignisserie definiert werden. Folgende Wiederholungen wären dabei 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 die Dauer des Termins oder der Aufgabe. Der definierte Ereignistyp Termine ist immer an einen festen Start- und Endzeitpunkt gebunden und damit stets vor der nächsten Wiederholung beendet. Anders verhält es sich mit der Planung von Ereignissen des Typs Projektaufgabe. Der Startzeitpunkt einer Aufgabe ist variabel und passt sich den zeitlichen Rahmenbedingungen erst bei der Berechnung des Zeitplans an. Deshalb können bei der Berechnung Situationen entstehen, in denen Aufgaben gar nicht oder nur teilweise in das Wiederholungsintervall passen. In dem Fall wird der Anwender über eine Hinweismeldung des Systems über das entstandene Planungsproblem informiert Fazit Die Unterscheidung zwischen den Ereignisklassen ermöglicht die Darstellung von Terminen und Projektaufgaben in einem zeitlichen Zusammenhang. Durch die Kombination der Ereigniseigenschaften und der Zuordnung einer Ereignisklasse ergibt sich ein bestimmtes Planverhalten. Die Ereigniseigenschaften definieren einen Zeitrahmen, in dem die jeweiligen Kalendereinträge angeordnet werden können. Um diese Berechnung der Kalenderdarstellung vorzunehmen, muss die Applikation eine Komponente besitzen, welche die klassenspezifischen Eigenschaften der Ereignisse auswertet und bei einer automatisierten Planung entsprechend im Kalender anordnet. Das Planverhalten 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 delegiert.

55 3. Anforderungsanalyse Anwendungsfälle Systemumgebung Die Systemumgebung (Abbildung 3.9) setzt sich aus den Anwendungsfällen der Arbeitszeitplanung der Mitarbeiter sowie der Planung und Überwachung von Projekten zusammen. Beide Planungsebenen teilen sich gewisse Informationen, wie die zeitlichen Eigenschaften, den benötigten Aufwand und den Fortschritt einzelner Ereignisse (Projektaufgaben oder Meilensteine). Diese Informationen gilt es, neben der Projektleitung auch für die Geschäftsleitung und Buchhaltung bereitzustellen. Die Geschäftsleitung ist am Projektverlauf besonders interessiert, daher wird sie über die wichtigen Entwicklungen im Projekt informiert. Die Projekte sind zudem wirtschaftlich auswertbare Vorgänge, die in der Kostenrechnung überwacht werden. Die Zeiterfassungskomponente des Systems liefert für die Kostenerfassung detaillierte Informationen über den Aufwand der Projektmitarbeiter oder einzelner Projektaktivitäten. Die Anwendungsfälle der Projektleitung, Buchhaltung und Geschäftsführung werden hier erwähnt, aber in den folgenden Beschreibungen nicht weiter ausgeführt. Hier werden die Use-Cases der Zeitplanung aus Sicht der Mitarbeiter näher erläutert. Diese sind weitgehend unabhängig von einem konkreten Projekt einsetzbar, während die für das Informationsmanagement eingesetzten Softwaresysteme im agilen Projektmanagement in Abhängigkeit vom Projekt auszuwählen sind. Diese Systeme sind änderbar und auf das entsprechende Projekt sowie das Unternehmen zugeschnitten. Allgemein gilt es den Dokumentationsaufwand auf das Wesentliche zu konzentrieren, um keine wichtigen Ressourcen zur Erfüllung von Formalitäten zu verschwenden. Für das klassische Projektmanagement existieren bereits viele Programme für die Projektplanung. Insbesondere die softwarebasierte Erstellung von Netzplänen wird von vielen Systemen (siehe Abschnitt 2.4.2) unterstützt. Bei Bedarf kann das Zeitplanungssystem über entsprechende Schnittstellen an externe Systeme angebunden werden. Um eine automatisierte Distribution aktualisierter Projektpläne herzustellen, muss unter anderem eine systemübergreifende, eindeutige Identifikation aller Ereignistypen, wie z.b. Termine, Projektaufgaben und Meilensteine, gewährleistet sein. Die Erweiterung der Systemfunktionalität durch die Implementierung einer internen Projektplanungskomponente ist ebenfalls möglich. Zudem können beispielsweise die Daten der Zeiterfassung für die Weiterverarbeitung durch die Buchhaltung über Dokumente, im Format gängiger Tabellenkalkulationsprogramme, bereitgestellt werden. Das erstellte Anwendungsfalldiagramm gestaltet sich wie folgt:

56 3. Anforderungsanalyse 56 Anwendungsfalldiagramm Applikation Authentifikation << use >> Ereignis erstellen Ereignis bearbeiten Anwender Terminverwaltung << use >> Ereignisverwaltung << use >> << use >> Ereignis anzeigen Aufgabenverwaltung << use >> << use >> << use >> Ereignis löschen Zeiterfassung << use >> Auswahl einer Aufgabe Projektmitarbeiter Zeitplanung << use >> Ereignisplanung Personalplanung Projektüberwachung Projektplanung Geschäftsführung Projektleitung Projektverwaltung << include >> << use >> << use >> Iterations und Meilensteinplanung Team Verwaltung wirtschaftliche Aufwandsbewertung << use >> Benutzerverwaltung << include >> Buchhaltung Gehaltsabrechnung Administrator Rechnungserstellung Rechteverwaltung Abbildung 3.9.: Anwendungsfälle des Systems Systemauthentifikation Hauptaktor: Anwender Zuständigkeitsbereich: Applikationsdienst Ebene: Anwenderziel Interessengruppe und Interessen: Anwender - Eindeutige Identifikation des Anwenders gegenüber dem System. Erfolgszusicherung: Die Applikation empfängt die Login-Daten des Anwenders; das System authentifiziert den Anwender.

57 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 Authentifikation Anwender Abbildung 3.10.: Systemauthentifikation Verwaltung von Ereignissen Hauptaktor: Anwender (Projektmitarbeiter) Zuständigkeitsbereich: Applikationsdienst Ebene: Anwenderziel Interessengruppe und Interessen: Anwender - Verwalten der eigenen Termine und Projektaufgaben. Vorbedingungen: Der Anwender besitzt einen aktiven System-Account und ist am System erfolgreich 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.

58 3. Anforderungsanalyse 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änderte Ereignis. 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 der unvollständigen Daten. 6a2. Der Anwender ergänzt die fehlenden Daten. Anwendungsfalldiagramm Verwaltung von Ereignissen Ereignis erstellen Terminverwaltung << use >> << use >> Ereignis bearbeiten Ereignisverwaltung << use >> << use >> Ereignis anzeigen Projektmitarbeiter Aufgabenverwaltung << use >> << use >> Ereignis löschen Abbildung 3.11.: Verwaltung von Ereignissen Zeitplanung Hauptaktor: Anwender (Projektmitarbeiter) Zuständigkeitsbereich: Applikationsdienst Ebene: Anwenderziel Interessengruppe und Interessen: Anwender - Erstellung der eigenen Arbeitszeitplanung. Vorbedingungen: Der Anwender besitzt einen aktiven System-Account und ist am System erfolgreich authentifiziert. Erfolgszusicherung: Die Applikation empfängt die Planungsanfrage des Anwenders; die Anfrage wird bearbeitet und die Ereignisse des Anwenders werden entsprechend ihrer Eigenschaften geplant. Erfolgsszenario: 1. Der Anwender wählt einen Zeitraum und lässt sich für diesen die Zeitplanung seiner

59 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ändig ausgefü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 << use >> Ereignisplanung Projektmitarbeiter Abbildung 3.12.: Zeitplanung Zeiterfassung Hauptaktor: Anwender (Projektmitarbeiter) Zuständigkeitsbereich: Applikationsdienst Ebene: Anwenderziel Interessengruppe und Interessen: Anwender - Arbeitszeit einer Projektaufgabe erfassen. Vorbedingungen: Der Anwender besitzt einen aktiven System-Account und ist am System erfolgreich 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:

60 3. Anforderungsanalyse 60 5a. Der Anwender versäumt es, die Zeiterfassung zu beenden, nachdem er die Aufgabe erledigt hat. 5a1. Der Anwender muss nachträglich den erfassten Aufwand der Aufgabe korrigieren und speichern. 5b. Zum Zeitpunkt der Erledigung der Aufgabe ist die Applikation durch einen technischen Fehler nicht erreichbar. 5b1. Der Anwender muss zu einem späteren Zeitpunkt den erfassten Aufwand der Aufgabe korrigieren und speichern. Anwendungsfalldiagramm Zeiterfassung << use >> Ereignis erstellen Zeiterfassung Ereignisverwaltung << use >> Ereignis bearbeiten << use >> << use >> << use >> Projektmitarbeiter Auswahl einer Aufgabe << use >> Ereignis anzeigen Ereignis löschen Abbildung 3.13.: Zeiterfassung Verwaltung von Benutzern Hauptaktor: Administrator Zuständigkeitsbereich: Applikationsdienst Ebene: Anwenderziel Interessengruppe und Interessen: Administrator - Anlegen neuer Benutzer und Änderung der Daten bestehender Benutzer. Vorbedingungen: Administrator besitzt einen aktiven System-Account mit Administrationsprivilegien 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.

61 3. Anforderungsanalyse 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änderten Daten. 7. Die Applikation zeigt dem Administrator die aktualisierte Benutzer-Liste. Erweiterungen: 6a. Die vom Administrator angegebenen Daten sind unvollständig oder inkorrekte Eingabe des Passworts. 6a1. Die Applikation zeigt erneut die Eingabemaske und einen Hinweis der unvollständigen Daten. 6a2. Der Administrator ergänzt die fehlenden Daten. Anwendungsfalldiagramm Verwaltung der Benutzer Benutzerverwaltung << include >> Rechteverwaltung Administrator Abbildung 3.14.: Verwaltung der Benutzer

62 4. Design und Modellierung Dieses Kapitel erläutert den konkreten Entwurf eines Zeitplanungssystems für agile Projektabläufe. Es folgt zunächst ein Überblick über das System mittels Abstraktion auf die konzeptionellen Fachklassen. Anschließend wird das realisierte Modell mit einem Klassendiagramm ausführlich erklärt sowie eine genaue Beschreibung der erstellten Klassen und deren Verantwortlichkeiten geliefert. Die bereits in Abschnitt 3.6 vorgestellten Anwendungsfälle werden noch einmal aufgegriffen und anhand von Sequenzdiagrammen näher beschrieben. Abschließend wird für das System eine entsprechende Zielplattform ausgewählt. Die Implementierung dieses Systementwurfes erfolgt danach in Kapitel Systementwurf Widmen wir uns vorerst dem plattformunabhängigen Entwurf des Systems, indem alle Klassen vorgestellt und deren Eigenschaften näher erläutert werden Konzeptionelle Fachklassen Die Modellierung der Applikation wird zunächst grob betrachtet, desweiteren werden die verwendeten Konzeptklassen identifiziert und erläutert. Dabei reduziert sich die Anwendung auf die Klassen User, Activity, Expense, Planner und Calendar (Abbildung 4.1). Diese Fachklassen und deren Beziehungen zueinander bilden die Vorlage für das Design des Klassenmodells (Abschnitt 4.1.2).

63 4. Design und Modellierung 63 User Activity Planner Expense Calendar Abbildung 4.1.: Konzeptionelle Fachklassen Die Klasse User repräsentiert alle Benutzer der Applikation mit ihren unterschiedlichen Rollen wie Projektmitarbeiter, Projektleitung, Buchhaltung und Geschäftsführung. Ein Benutzer kann nicht nur eine, sondern mehrere Rollen im System wahrnehmen. Der gesamte Personalpool bildet die Basis, welcher Termine, Meilensteine und Projektaufgaben zugeordnet werden. Diese planbaren Vorgänge werden hier allgemein als Aktivitäten bezeichnet und mit der Klasse Activity dargestellt. Alle für die zeitliche Planung relevanten Eigenschaften sowie die Zuordnung zu den Mitarbeitern werden mit einer Aktivität beschrieben. Die durch eine Aktivität tatsächlich aufgewendete Zeit wird mit der Klasse Expense repräsentiert. Die Übersetzung der Aktivitäten in die Einträge des Kalenders wird von den Planer-Klassen (Planner) vorgenommen. Der Einsatz mehrerer Planer realisiert ein unterschiedliches Planverhalten bei der Berechnung des Zeitplans. Das Ziel ist die Erstellung einer vom Benutzer abhängigen Zeitplanung, die innerhalb eines Kalenders (Calendar) dargestellt wird. Die geplanten Aktivitäten eines Mitarbeiters werden damit in einen zeitlichen Kontext übersetzt und visualisiert Klassendiagramm In folgender Abbildung 4.2 werden die modellierten Klassen und deren Beziehungen zueinander aufgezeigt. Anschließend werden die Klassen genauer erläutert und die jeweilige Verantwortlichkeiten beschrieben.

64 4. Design und Modellierung 64 WeekScheme User * * Group * * Capability Appointment * Milestone << abstract >> Event EventContainer * Track FloatingTask * Dependency CalendarEvent * CalendarDay SchedulerEvent SchedulerTrack CalendarXML * Calendar << abstract >> SchedulerEventBase CalendarICAL CalendarDecorator Controller << abstract >> SchedulerBase WorkCalendar Scheduler ProblemSolver Abbildung 4.2.: Klassendiagramm

65 4. Design und Modellierung 65 Benutzer- und Rechteverwaltung Für die Verwaltung der Benutzer und Rechte sind die Klassen User, Group und Capability zuständig. Die benutzerabhängigen Eigenschaften werden als Attribute in der Klasse User verwaltet. Zur strukturierten Rechteverwaltung werden alle Benutzer Gruppen (Group) zugeordnet, welche mit ausgewählten Zugriffsrechten (Capability) ausgestattet sind. Damit können den Benutzern eine oder mehrere Rollen zugewiesen werden. Die Zugriffsrechte der Benutzergruppen werden über eine Capability-Liste verwaltet, welche die Zugriffsart auf die verschiedenen Systemfunktionen festlegt. Die Klassen der Benutzer- und Rechteverwaltung haben die folgenden Verantwortlichkeiten: Authentifizierung der Benutzer mit einem Challenge-Response Verfahren durch Überprüfung von Name und Passwort. Bereitstellung aller Informationen des Benutzerkontos wie z.b. Name, Passwort und weitere Eigenschaften. Ermittlung der Zugriffsrechte von Benutzern über die zugeordneten Gruppen. Wochenschema Die Definition der wöchentlichen Arbeitszeit wird über die Klasse WeekScheme vorgenommen. 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- und außerhalb der Arbeitszeit definiert werden. Die Klasse WeekScheme hat die folgende Verantwortlichkeit: Ermittlung der wöchentlichen Arbeitstage und täglichen Arbeitszeiten. Ereignis Die abstrakte Klasse Event repräsentiert mit ihren generalisierten Attributen eine Basis für alle konkreten Ereignisklassen der Applikation. Die abgeleiteten Klassen beschreiben einen speziellen Typ von Ereignis beispielsweise Appointment, Milestone oder FloatingTask. Diese Vererbungsstruktur erlaubt die flexible Erweiterung um neue Ereignistypen. Die Klassifizierung in einzelne Ereignistypen und das damit verbundene Planungsverhalten bilden die 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 einem Benutzer modelliert, um eine entsprechende Zuordnung einzelner oder kollaborativer Projektaufgaben zu ermöglichen. Die an den Benutzer gebundene Zeitplanerstellung identifiziert die Zugehörigkeit der Ereignisse über dieses Klassenattribut. Eine universelle Basis

66 4. Design und Modellierung 66 für alle Ereignisse verspricht ein einheitliches Handling der Termine (Appointment) und Projektaufgaben (FloatingTask, etc.) bei der Verwaltung und peristenten Speicherung. Typische CRUD-Operationen 1 können für alle Event Objekte über die gleiche Methoden erfolgen. Die Klasse 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 Datenbank. Die Klasse EventContainer dient zur Gruppierung und Strukturierung der Ereignisse. Der Fortschritt und die gesamte Dauer eines EventContainers ergibt sich dabei aus den zugeordneten Event Objekten. Die EventContainer erlauben die Anordnung von Ereignissen in einer 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- und EventContainer-Objekte. Abhängigkeiten Zwischen Event- und EventContainer-Objekten können verschiedene kausale Abhängigkeiten über eine Dependency bestimmt werden. Über die Instanzen dieser Klasse wird definiert, ob bestimmte Ereignisse oder Ereignisgruppen vor oder nach anderen Ereignissen erfolgen müssen. Bei der Festlegung der Abhängigkeiten und bei Gruppierung von Ereignissen muss die Konsistenz der definierten Abhängigkeiten geprüft werden. Es darf nicht möglich sein, gegensätzliche Abhängigkeiten zwischen einer Ereignisgruppe und den zugeordneten Ereignissen zu definieren. Die Klasse Dependency ist verantwortlich für: Bereitstellung von kausalen Abhängigkeiten zwischen Event- und/oder EventContainer-Objekten. 1 CRUD ist ein Akronym für die Basisfunktionen einer Datenbank oder Persistenzschicht (Create, Read, Update, Delete)

67 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 gibt an, ob das Track Objekt gerade aktiv ist und die Zeit aktuell erfasst wird oder ob die Zeiterfassung bereits beendet wurde. Die Länge der erfassten Zeit ergibt sich direkt aus dem Zeitraum zwischen Start- und Endzeitpunkt, Pausen oder tägliche Arbeitszeiten werden nicht berücksichtigt. Die Klasse Track besitzt die folgende Verantwortlichkeit: Planer Berechnung und Bereitstellung des zeitlichen Aufwands aus dem erfassten Start- und Endzeitpunkt. Die Planungskomponente umfasst mehrere Klassen, deshalb werden hier zusammenfassend die Klassen SchedulerBase, Scheduler, ProblemSolver, SchedulerEventBase, SchedulerEvent und SchedulerTrack betrachtet. Die Aufgabe der Planer ist es, alle Ereignisse (Event) eines Benutzers in einen Terminkalender zu übertragen. Ein Ereignis kann dabei auf verschiedene Kalendereinträge an unterschiedlichen Tagen aufgeteilt werden, solange, bis die Ereignisdauer eingeplant wurde. In die Planung fließt dabei nur die effektiv notwendig zu planende Ereignisdauer ein, also der geschätzte Soll-Aufwand abzüglich der bereits erfassten Ist-Aufwände (Track). Der Planer versucht, unter Berücksichtigung der zeitlichen Ereigniseigenschaften und der verfügbaren Zeitressourcen des Terminkalenders eine konsistente Zeitplanung zu erstellen. Ist dies nicht möglich, werden für die betroffenen Ereignisse entsprechende Warnmeldungen generiert und den Benutzern mitgeteilt. Die abstrakte Klasse SchedulerBase bildet die Basis, von der aus alle konkreten Implementierungen der Planungsalgorithmen abgeleitet werden. Die Klasse beinhaltet Attribute und Methoden, die unabhängig von der konkreten Umsetzung eines Planers Verwendung finden. Zudem definiert die Basisklasse abstrakte Methoden für die Planung der einzelnen Ereignistypen, welche über die Subklassen mit einem ausgewählten Planungsverhalten versehen werden. Die Klassen Scheduler und ProblemSolver stellen damit für jeden Ereignistyp unterschiedliche Implementierungen mit eigenem Planungsverhalten dar. Beispielsweise können mit den Algorithmen der Klasse ProblemSolver Vorschläge für die Planung überfälliger Aufgaben gemacht werden. Gezielt kann der Benutzer bestimmte Aufgaben diesem Planer zuweisen und damit mögliche Planungsszenarien darstellen. Die durch den ProblemSolver vorgeschlagenen Korrekturen an den zeitlichen Eigenschaften der Aufgaben müssen abschließend von dem Benutzer bestätigt werden. Die Planer-Klassen haben folgende Verantwortlichkeiten:

68 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 durch einen Planer in Objekten der Klassen SchedulerEvent und SchedulerTrack gekapselt. Diese erweitern die beiden Klassen um Methoden und Attribute, die nur während der Berechnung des Zeitplans benötigt werden. Der Planer dekrementiert mit jedem erstellten Kalendereintrag die Ereignisdauer und kann feststellen inwieweit ein Ereignis bereits verplant wurde. Die gemeinsame Basisklasse SchedulerEventBase vereinheitlicht den Zugriff auf die relevanten Attribute der unterschiedlichen Ursprungsklassen Event und Track. Somit arbeiten die Planer nur mit Objekten der Subklasse von SchedulerEventBase. Die Verantwortlichkeit der Klassen 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 stellt dabei die Verbindung zwischen dem Benutzer, Wochenschema, Ereignissen, erfassten Zeiten, Kalender und den Planern her. Der Controller ermittelt bei der Planung die benutzerabhängigen Ereignisse, instantiiert den Kalender und dekoriert ihn mit dem Wochenschema des Benutzers. Für die Zeitplanung werden die Ereignisse an die zugeordneten Planer übergeben, welche die Umwandlung in die einzelnen Kalendereinträge vornehmen. Die Klasse Controller 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 wie Termine und Projektaufgaben dargestellt werden. Diese Klasse verwaltet Objekte der CalendarDay Klasse, welche einen Tag mit der Einteilung in Stunden und Minuten abbildet. Mit Objekten der CalendarEvent Klassen werden konkrete Kalendereinträge an einem Tag angelegt. Diese Einträge werden bei der Berechnung des Zeitplans aus den Terminen bzw. Aufgaben eines Benutzer erstellt. Als Zuordnung zu den Objekten der Ursprungsereignisse

69 4. Design und Modellierung 69 bleibt eine Referenz in jedem Kalendereintrag erhalten. Durch die Objektkomposition ergibt sich ein existenzielles Abhängigkeitsverhältnis zwischen dem Calendar und aggregierten CalendarDay und CalendarEvent Objekten. Um die Planung der Projektaufgaben zu realisieren, ergibt sich ein anderer zeitlicher Rahmen als nur der eigentliche Kalender. In Abhängigkeit von dem Benutzer wird ein weitaus kleinerer Zeitrahmen durch die wöchentliche Arbeitszeit vorgegeben. Die Erweiterung dieser Funktionalität der Klasse wird mit der Anwendung eines Dekorierer Entwurfmusters (engl. decorator pattern) [Gamma, 1996] vorgenommen. Der Dekorierer wird in der Klasse CalendarDecorator implementiert und bietet die durch den Kalender vorgegebenen Schnittstellen. Die WorkCalender Klasse bildet eine Unterklasse des Dekorierers und implementiert die zusätzlichen Methoden, welche bei der Ereignisplanung innerhalb der vorgegeben Arbeitszeiten 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 Objektkomposition in ein einheitliches Format gewandelt werden. Die Klasse CalendarXML wandelt deshalb die Kalenderdaten eines angegebenen Zeitraums in ein XML-Dokument um. XML erlaubt die Darstellung der Kalenderdaten unabhängig von einer konkreten Repräsentation z.b. in Form einer Tabelle oder Grafik. Die XML-Daten werden mit XSLT in eine andere Darstellung transformiert 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 Kalenderinformationen und wird von vielen Terminkalender-Applikationen unterstützt. Die Darstellungsklassen CalendarXML und CalendarICAL haben folgende Verantwortlichkeit: Umwandlung und Bereitstellung der Calendar Objekte in Dokumente im XML oder icalendar Format.

70 4. Design und Modellierung Szenario: Ablauf der Zeitplanung Der in Abschnitt beschriebene Anwendungsfall soll hier mit Sequenzdiagrammen näher erläutert werden. Die folgenden Diagramme wurden in zwei Phasen eingeteilt: Die Initialisierung 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ötigt werden. Nachdem der Calendar instantiiert wurde, wird die Arbeitszeit mit dem Wochenschema des Benutzers auf den Terminkalender dekoriert. Die aktiven Ereignisse des Benutzers und die Planer werden aus der Datenbank geladen. Die Peer Klassen (EventPeer, SchedulerPeer) dienen als Schnittstelle zum persistenten Speicher und stellen statische Methoden bereit zur Abfrage und Erstellung der Event und Scheduler Objekte.

71 4. Design und Modellierung 71 Abbildung 4.4.: Berechnung des Zeitplans Nach der Initialisierung des Controller Objekts erfolgt die Zeitplanung mit dem Methodenaufruf von createschedule(), der eine Zeitspanne durch die Parameter Start und Stop übergibt. Zunächst werden die fixen Termine (Appointment) ausgewählt und in den Kalender eingetragen, gefolgt von den Projektaufgaben (FloatingTask, FloatingTaskWithStop etc.), die nach ihrer Priorität sortiert und in der Reihenfolge eingeplant werden. Die private Methode processevents() übernimmt die Planung der einzelnen Ereignisse (Event). Abschließend werden die erfassten Zeiten des Benutzers über die Klasse TrackPeer aus der Datenbank geladen und über processtracks() in den Kalender eingetragen. Mit getcalendar() liefert der Controller eine Referenz auf die Calendar Instanz, die zur Verarbeitung an die Darstellungsklassen CalendarXML und CalendarICAL übergeben wird.

72 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 Ereignistypen über die zugeordneten Planer. Die Event Objekte werden identifiziert und in einem SchedulerEvent gekapselt, bevor es an den Planungsalgorithmus des entsprechenden Planers übergeben wird. Folgende Sequenzdiagramme zeigen den Ablauf der Planung zwei unterschiedlicher Ereignistypen.

73 4. Design und Modellierung 73 Abbildung 4.6.: Planungsalgorithmus eines Termins (Appointment) Der Planungsalgorithmus für Appointment Objekte erstellt in dem vom Ereignis vorgegebenen Zeitraum Kalendereinträge (CalendarEvent). Das Wochenschema des Benutzers sowie die gegebenenfalls vorhandenen Einträge werden nicht berücksichtigt.

74 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 Ereignistyp FloatingTask unterliegt keinen zeitlichen Einschränkungen und wird deshalb auf die freien Zeitressourcen im Kalender zum Zeitpunkt der Berechnung verteilt.

75 4. Design und Modellierung Szenario: Verwaltung von Ereignissen Die Verwaltung der Ereignisse eines Benutzers erfolgt in drei Schritten (Abbildung 4.8). Die Klasse EventActions ist der Controller zwischen der Benutzeroberfläche und der Datenschicht. Der Controller empfängt alle Interaktionen des Anwenders von der Benutzeroberfläche und steuert die einzelnen Aktionen auf dem Datenmodell. Zunächst werden alle aktiven Ereignisse eines Benutzers über die Klasse EventPeer aus der Datenbank geladen und über die Benutzerschnittstellen ausgegeben. Aus der Ereignisliste wählt der Benutzer anschließend das zu bearbeitende Ereignis aus. Der Controller empfängt die eindeutige Identifikationsnummer (ID) des Ereignisses und lädt das Objekt (event) aus dem persistenten Speicher. Die graphische Benutzeroberfläche zeigt die aktuellen Attribute des ausgewählten Ereignisses an und der Benutzer kann nun die Änderungen vornehmen. Abschließend werden die Änderungen im Objekt aktualisiert und in der Datenbank gespeichert. Abbildung 4.8.: Ereignisverwaltung

76 4. Design und Modellierung Szenario: Zeiterfassung Die Zeiterfassung erfolgt in zwei Schritten. Nach dem Prinzip einer Stoppuhr kann die Zeiterfassung zu einem Zeitpunkt gestartet und zu einem späteren Zeitpunkt wieder gestoppt werden. Der Benutzer startet die Zeiterfassung für ein ausgewähltes Ereignis (event). Dabei wird ein neues Objekt der Klasse Track instantiiert und der aktuelle Zeitstempel als Startzeitpunkt 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 zunä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 Zeiterfassungsvorgangs instantiiert. Der Stopzeitpunkt des track Objekts wird gesetzt und der Status auf den Wert 2 (abgeschlossen) aktualisiert. Abschließend wird das Objekt der Klasse Track im persistenten Speicher gesichert. (Abbildung 4.10)

77 4. Design und Modellierung 77 Abbildung 4.10.: Beenden der Zeiterfassung eines Ereignisses 4.2. Auswahl der Zielplattform Die Anforderung aus Abschnitt führen zur einer Grundsatzentscheidung bei der konkreten Realisierung der Client/Server Architektur des Systems. Das bei der Modellierung einer Client/Server Architektur eingesetzte Drei-Schichten-Modell (engl. three-tier model) trennt die Präsentations- (engl. presentation tier), Logik- (engl. logic tier) und Datenschicht (engl. data tier) logisch voneinander. Die Realisierung einer Client/Server Architektur legt weiterhin fest, welche (Teil)Schichten auf dem Client und welche auf dem Server umgesetzt werden. Diese Entscheidung beeinflusst im Wesentlichen die softwaretechnische Umsetzung der Applikation und der Kommunikationsschnittstelle zwischen Client und Server. Die Begrifflichkeiten Thin- und Fat-Client existieren sowohl im Bereich der Software als auch in der Hardware. An dieser Stelle wird aber ausschließlich auf den Bereich der Software eingegangen. Die Eigenschaften von Thin- und Fat-Client Applikationen können daher wie folgt dargestellt werden:

78 4. Design und Modellierung 78 Thin-Client Fat-Client Verfügbarkeit online online und offline Datenhaltung zentrale Datenbank dezentrale und zentrale Datenbanken, Replikation nötig Portabilität hoch, oft plattformunabhängig niedrig, meist plattformabhängig Technologie Verteilung, Aktualisierung Web (HTML, ASP, PHP, JSP), Terminal Services (Metaframe, X11) einfach, zentral native Desktop-Anwendung (C++, C#,.net, Java) aufwändig, dezentral Benutzeroberfläche einfach bis komplex einfach, komplex, spezielle Anforderungen (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, wie z.b. Ultra-Thin-Client oder Rich-Client. Diese besitzen Eigenschaften von beiden Applikationsformen und werden in der Praxis als Ableger von Thin- bzw. Fat-Client Anwendungen angesehen. Die Realisierung in Form eines Fat-Clients erhöht die Verfügbarkeit der Applikation, so kann auch im Offline-Betrieb der Zugriff auf die lokale Datenbasis realisiert werden. Bei einer Synchronisation mit dem Server werden die benötigten Daten auf die lokale Datenbank des Clients repliziert. Die lokalen Daten des Clients sind zum Zeitpunkt der Synchronisation mit dem Server identisch. Da sich die Daten auf dem Server mit der Zeit ändern, verliert die lokale Datenbank auf dem Client an Aktualität. So können Informationen der Planung bereits veraltet sein und sich zwischenzeitlich verändert haben. Dies ist in erster Linie von der Anzahl der Anwender sowie der Änderungsfrequenz abhängig. Um die volle Funktionalität des Systems auch im Offline-Betrieb zu ermöglichen, ist eine Replikation der gesamten Server-Datenbank auf den Client notwendig, da die Planung und Analyse der aktuellen und vergangenen Projekte bereitgestellt wird. Dies bedeutet einen erhöhten Speicherplatzbedarf auf den mobilen Geräten (z.b. Notebooks). Problematisch ist ebenfalls, dass im Fall der Entwendung oder Kompromittierung eines mobilen Geräts sensitive Daten des Unternehmens für Dritte offengelegt werden. Die Daten umfassen hier detaillierte Informationen von aktuel-

79 4. Design und Modellierung 79 len und abgeschlossenen Projekten sowie Daten aus der Zeiterfassung aller Mitarbeiter. Im Sinne des Datenschutzes soll ein Zugriffsschutz und die Sicherheit der Daten gewährleistet werden. Eine Replikation der Datenbank erhöht somit das Risiko eines nicht autorisierten Zugriffs. Abhilfe schafft hier eine zusätzliche Verschlüsselung der lokalen Datenbank. Die Umsetzung in Form einer Thin-Client Applikation hingegen ist auf die Verbindung zum Server angewiesen, da sowohl die Logik- und als auch die Datenschicht serverseitig realisiert sind. Ein Offline-Einsatz ist mit dieser Applikationsform nicht gegeben. Die gesamte Applikationslogik wird auf dem Server ausgeführt, der Client realisiert lediglich die Darstellung der Benutzeroberfläche. Alle Interaktionen des Anwenders werden zur Verarbeitung weiter an den Server gesendet. Die Anforderungen an die Hardware und Rechenleistung der mobilen Geräte (z.b. Notebook, PDA, Smartphone) sind hier verhältnismäßig niedrig. Zudem werden, abgesehen von den temporären Cachedaten, keine sensitiven Informationen aus der Datenbank auf dem Client gespeichert. Die Entwendung eines mobilen Geräts ist damit weitgehend als unbedenklich anzusehen. Die Kompromittierung des Geräts durch Schadprogramme (engl. malware) ist aber weiterhin gegeben und sollte daher in der Sicherheitsstrategie des Unternehmens berücksichtigt werden Web-Technologie Der Einsatz einer webbasierten Lösung und damit einer Form von Thin-Client ist notwendig, sobald Mitarbeiter an unterschiedlichen Standorten ständig mit aktuellen Informationen versorgt werden müssen. Für den Zugriff auf die aktuellen Daten ist das mobile Geräte auf eine Netzwerkverbindung zum Applikationsserver angewiesen. Diese scheinbare Einschränkung 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 Programmiersprache zur Erstellung dynamischer Inhalte. Eine angebundene Datenbank stellt den persistenten Speicher für alle Anwendungsdaten. Durch die zentrale Datenhaltung können besser Maßnahmen für die Datensicherung und den Datenschutz etabliert werden. Die Wartbarkeit der Applikation ist gegeben und Veränderungen sowie Erweiterungen werden zentral aktualisiert. 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 Browser vorgenommen und ist damit unabhängig vom Betriebssystem. Zudem ist der Zugriff auf die Applikation von vielen Orten möglich. Die im Intranet veröffentlichte Anwendung ist außerdem von Extern über eine VPN-Verbindung aufrufbar. Im Vergleich zu der Ausführung eines lokalen Programms, ergibt sich für Web-Applikationen der Nachteil einer eingeschränkten Interaktivität des Anwenders. Desktop-Applikationen bieten eine bessere Reaktionsfähigkeit und können Daten auch nur in bestimmten Bereichen

80 4. Design und Modellierung 80 des Fensters sofort aktualisieren. Aufgrund der verwendeten Web-Technologie ist nur ein seitenbasierter Aufruf von HTML-Seiten möglich. Jede Veränderung erfordert also eine neue Anfrage an den Server, welcher eine weitere HTML-Seite als Antwort sendet. Der Einsatz von HTML-Frames stellt keine hinreichende Lösung des Problems. Um die Interaktionen der Benutzer dennoch möglichst flexibel zu halten, wurden bisher Java Applets [www:applet] oder Macromedia Flash [www:flash] Technologien eingesetzt, welche aber neben dem Browser weitere Software zur Darstellung benötigen Web 2.0 Ein Modewort des Jahres 2005 war Web 2.0, welches die nächste Generation von Dienstleistungen und Applikationen im World Wide Web beschreibt. Im Rahmen der zweiten Web 2.0 Conference, die im Oktober 2005 stattfand, wurde festgehalten, welche Innovationen, Internetservices, Web-Applikationen und Geschäftsmodelle das Internet von heute im Wesentlichen bestimmen. Die Web 2.0 Konzepte haben dabei keine vorgegebenen Grenzen, sondern sind eher als eine Sammlung von Prinzipien und Methoden anzusehen. Primär wird das Web als Plattform genutzt, auf der dem Anwender serviceorientiert Applikationen bereitgestellt und diese wiederum durch sein eigenes Mitwirken verbessert werden. Die Kernkompetenzen der Web 2.0 Unternehmen zeichnen sich durch kostengünstige skalierbare Onlineservices, Kontrolle über einzigartige Datenquellen, Verbindung von kollektiver Intelligenz, Beteiligung der Benutzer sowie eine geräteunabhängige Verbreitung der Softwarelösungen aus. [O Reilly, 2005] Web 2.0 umfasst dabei eine inhaltliche und eine technische Ebene. Der Benutzer spielt bei der Modellierung der Inhalte eine wesentliche Rolle. Die Internetangebote gewinnen durch die Involvierung der Anwender an Attraktivität und es ist längst nicht mehr nur die Meinung des Autors eines Artikels gefragt, sondern auch die der Leser. Auf diesem Fundament setzen die Prinzipien von Wikiwebs, Blogging und Tagging auf. Jeder Benutzer kann seinen Teil beisteuern und erweitert damit die Vielfalt der angebotenen Inhalte. Der Erfolg des Web 2.0 sieht sich durch Portale und Communities wie Flickr [www:flickr] und Wikipedia [www:wikipedia] bestätigt. Auch kommerzielle Unternehmungen haben diese Bewegung erkannt und nutzen sie zum eigenen Vorteil, wie etwa die Kunden-Rezension von Amazon [www:amazon]. Die Grundlage dafür schaffte die technische Weiterentwicklung der Web-Applikationen gefolgt von einer gesteigerten Benutzerakzeptanz. Die leichte Bedienbarkeit (engl. usability) der Web-Anwendungen steht im Vordergrund und mit innovativen Benutzeroberflächen wird ein reichhaltiges Benutzererlebnis (engl. rich user experience) geschaffen. Mit dem Einsatz 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.

81 4. Design und Modellierung 81 Die Web 2.0 Technologien sollen bei Entwicklung der Benutzeroberfläche berücksichtigt werden und eine verbesserte Interaktivität der Anwender ermöglichen Ajax Ajax 2 (Asynchrones JavaScript und XML) beschreibt eine Technik, mit der innerhalb von HTML-Seiten weitere Anfragen an einen Webserver gestellt werden können. Damit wird es möglich, die Funktionalität von Web-Applikationen reichhaltiger zu gestalten und interaktive Bedienelemente, 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 XHTML 3 und CSS 4 Dynamische Ausgabe und Interaktion über das Document Object Model (DOM 5 ) Datenaustausch und Veränderung mit XML 6 und XSLT 7 Asynchroner Abruf von Daten durch XMLHttpRequests JavaScript als verbindende Programmiersprache In der Praxis bedeutet dies, dass Ajax eine Schnittstelle bietet, die auch zwischen den Seitenwechseln eine Kommunikationsverbindung zum Server bereitstellt, um HTTP-Anfragen im 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 in beliebigen Formaten wie z.b. HTML und JavaScript vom Server übermittelt werden. Im Allgemeinen wird auf die Eingaben und Interaktionen der Benutzer unmittelbar reagiert, ohne unnötig Overhead zu erzeugen. Es werden nur die jeweils gewünschten Daten an den Browser gesendet und der Abruf einer gesamten HTML-Seite wird umgangen. Die Wartezeiten für den Benutzer werden verkürzt und verbessern die Bedienbarkeit der Applikation. Bei der Erstellung einer Web-Applikation mit Ajax ergeben sich unter anderem neue Anforderungen bei der Gestaltung des Seitenflusses (engl. page flow), die den Entwicklungsprozess komplexer gestalten. Es gibt aber bereits für Ajax adaptierte Entwicklungsmuster, die Methoden zur Lösung typischer Problemstellungen vorgeben [Crane und Pascarello, 2006]. 2 Ein Begriff den Jesse James Garrett von Adaptive Path geprägt hat. [Garrett, 2005] 3 Extensible HyperText Markup Language [www:xhtml] 4 Cascading Style Sheets [www:css] 5 API für den Zugriff auf HTML/XML-Dokumente [www:dom] 6 Extensible Markup Language [www:xml] 7 Extensible Stylesheet Language Transformation [www:xslt]

82 5. Realisierung Nachdem das Design im vorherigen Kapitel 4 erörtert wurde, werden hier ausgewählte Details der prototypischen Implementierung des Zeitplanungssystems dargestellt. Zuerst werden die eingesetzten Technologien erläutert sowie der Aufbau des Systems vorgestellt. Zur Erstellung eines Zeitplans wird von dem Prototyp eine Planungskomponente benutzt, deren Realisierung hier genauer betrachtet wird. Abschließend folgt ein Überblick des erstellten Prototypen, 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äheres zum Inhalt ist dem Anhang C zu entnehmen Implementierung des Prototyps Verwendete Technologie Die Umgebung für die Implementierung des Prototyps bildet eine LAMP 1 Plattform. Diese Kombination freier Software Programme bildet zusammen einen flexiblen und skalierbaren Web-Server mit Datenbankanbindung. Aufgrund der geringen Kosten ist LAMP eine sehr gute Alternative im Vergleich zum Einsatz kommerzieller Web-Plattformen. Die Implementierung der Web-Applikation wird mit der Skriptsprache PHP 5 2 vorgenommen. Mit der Einführung der Version 5 entwickelte sich PHP zu einer ausgewachsenen objektorientierten Programmiersprache. Das neue Objektmodell unterstützt die Auszeichnung der Zugreifbarkeit von Klassenvariablen und Klassenmethoden sowie die Deklaration von Konstruktoren bzw. Destruktoren. Zusätzlich wird die Introspektion eines objektorientierten Systems mit der Erweiterung durch die Reflection API etabliert, welche unter anderem bei der Überprüfung der Systemfunktionalität durch Unit-Tests Verwendung findet. Die Umsetzung von Entwurfsmustern aus dem Umfeld der objektorientierten Programmierung ist mit dem neu eingeführten Objektmodell ebenfalls gegeben [Bergmann, 2005]. 1 LAMP ist ein Akronym für Linux, Apache, MySQL, PHP, das von Michael Kunze geprägt wurde. [Kunze, 1998] 2 Die aktuelle Version von PHP ist abrufbar unter [www:php] (benutzt wurde die Version vom )

83 5. Realisierung 83 Die Entwicklung der Anwendung stützt sich außerdem auf das Web-Applikations Framework Symfony 3. Symfony ist ein Open-Source Framework für PHP 5, mit dem Ziel die, Entwicklung und Wartung von Web-Applikationen zu beschleunigen und einfacher zu gestalten. Es implementiert 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 Rails 4 wurden auch Funktionen 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 die agilen Entwicklungsprozesse für Web-Anwendungen ein und unterstützt die Anwendung von Designprinzipien wie z.b. DRY (Don t repeat yourself). Das Framework verfügt zusätzlich über Werkzeuge zur Erstellung von Unit-Tests und der Klassendokumentation. 3 Symfony Project [www:symfony] (benutzt wurde die Version vom ) 4 Ruby on Rails Web Application Framework [www:rails]

84 5. Realisierung Aufbau der Web-Applikation Die Abbildung 5.1 zeigt den Seitenfluss (engl. page flow) der Web-Applikation in Form eines Zustandsdiagramms. Sie liefert einen Überblick wie die Benutzer in der Applikation navigieren. Nach der erfolgreichen Authentifizierung über die Login Seite kann der Benutzer über das Navigationsmenü zu den Komponenten der Anwendung gelangen, wie dem Zeitplan, der Ereignisverwaltung und der Benutzerverwaltung. Das Navigationsmenü ist ein Teil jeder HTML-Seite (engl. partial web page) innerhalb der Applikation und wird von allen Seiten inkludiert und angezeigt, ausgenommen der Login Seite. Abbildung 5.1.: Seitenfluss der Web-Applikation Die Implementierung des Seitenflusses wird über den Controller 5 umgesetzt, welcher als Vermittler zwischen Datenmodell (engl. model) und Darstellung (engl. view) agiert und ein wichtiger Teil des MVC Paradigmas ist. Der Controller erlaubt es, eine komplexe Logik für die Navigation und Abfolge der Webseiten in der Anwendung zu definieren. Der Controller hat 5 Gemeint ist hier die Klasse sfcontroller des Symfony Frameworks [www:symfony]

85 5. Realisierung 85 dabei Zugriff auf die Variablen der Benutzersession und kann damit ein zustandsabhängiges 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öglich an zentraler Stelle Filter und Regeln zu etablieren. Wird beispielsweise für eine Aktion die Authentifizierung des Benutzers vorausgesetzt, kann der Controller die Anfrage zurück auf die Login-Seite leiten. In dem Zustandsdiagramm 5.1 sind die Aktionen, die über Ajax realisiert wurden, mit blau gekennzeichnet. Die Ajax Funktionalität unterstützt beim Darstellen der Wochenübersicht die Auswahl der angezeigten Woche und liefert in der Ereignisverwaltung die erfassten Zeiten zu ausgewählten Ereignissen (siehe Abschnitt 5.1.4) Realisierung der Planungskomponente Die Grundlage der Planungskomponente bildet die abstrakte Klasse SchedulerBase, die Attribute und wiederverwendbare Methoden für die abgeleiteten Planer-Klassen bereitstellt. Mit der Definition der verschiedenen Ereignistypen aus der Anforderungsanalyse (Abschnitt 3.3) ergeben sich für die Planer typenabhängige Planungsverhalten. Im Grunde lässt sich die Modellierung dieser Verhalten aber auf die drei nachfolgend erläuterten Methoden reduzieren. Der einzelne oder kombinierte Einsatz dieser Methoden ermöglicht die Planung aller vorhandenen Ereignistypen. processstaticevent Diese Methode stellt einen Algorithmus zur Planung aller Ereignisse mit einem fixen Start- und Endzeitpunkt bereit. Den zeitlichen Rahmen für die Planung bildet der gesamte Kalender. Die generierten Kalendereinträge sind nicht an die noch freien Zeitressourcen gebunden, sondern werden, wie von dem Ereignis angegeben, unverändert in den Kalender übernommen. Ein Ereignis wird von der Methode immer vollständig eingeplant, was bedeutet, dass zwei oder mehrere statische Ereignisse auch parallel im Kalender liegen können. Als Ereignisse mit fixem Start- und Endzeitpunkt werden die Objekte der Klassen Appointment und Track mit diesem Algorithmus in Kalendereinträge gewandelt. processforwardfloatevent Mit dieser Klassenmethode wird ein Algorithmus für die Planung der Projektaufgaben (Abschnitt 3.5.2) bereitgestellt. Charakteristisch für diesen Vorgang ist, dass nur eine Zeitspanne für die Ausführung der Aufgabe angegeben wird, weder ein konkreter Tag noch eine Uhrzeit. Das von der Aufgabe bestimmte Zeitintervall setzt sich aus dem geschätzten Aufwand und einem Zeitpuffer zusammen. Der Algorithmus bestimmt also selber die konkreten Zeitpunkte in Form der Kalendereinträge für die Ausführung der

86 5. Realisierung 86 Projektaktivität. Für die Bearbeitung der Aufgabe stehen die noch freien Zeitressourcen innerhalb der wöchentlichen Arbeitszeit des Mitarbeiters zur Verfügung. Zudem wird der Methode 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ügbaren Zeitressourcen für die vollständige Planung der Aufgabe ausreichen, kann nach der Ausführung der Methode ein Teil des geschätzten Aufwands noch übrig bleiben. Diese unvollständige Planung der Projektaufgabe wird von dem Planer erkannt und erzeugt eine Warnmeldung für den Benutzer. In Abhängigkeit des verwendeten Planers kann diese verbleibende Zeit auch weiter eingeplant werden, wie es etwa der ProblemSolver Planer tut. Der Algorithmus geht nun so vor: Die Planung der Aufgabe erfolgt vom Startzeitpunkt zum Endzeitpunkt. Die von dem Algorithmus erstellten Kalendereinträge fließen vom Startzeitpunkt Vorwärts in Richtung Zukunft. Daher entstand die Namensgebung für die Klassenmethode processforwardfloatevent. Optional ist bei dem Aufruf der Methode die Angabe eines Endzeitpunkts, welcher das Planungsintervall nach oben beschränkt. Ist dieser nicht bestimmt, werden so viele Kalendereinträge erstellt, bis der Aufgabenaufwand vollständig eingeplant ist. processbackwardfloatevent Diese Methode arbeitet im Prinzip wie der Algorithmus der processforwardfloatevent, nur eben in entgegengesetzter Richtung. Die erstellten Kalendereinträge fließen hier in Richtung Vergangenheit. Das Planungsintervall wird der Methode ebenfalls vorgegeben und der Algorithmus plant von dem Endzeitpunkt zum Startzeitpunkt. Der Zeitrahmen wird dabei auch von den verfügbaren Zeitressourcen in der wöchentlichen Arbeitszeit des Mitarbeiters bestimmt. Die Angabe eines Startzeitpunkts ist dabei optional, wird aber als sinnvoll erachtet Ajax in Aktion Die in Abschnitt vorgestellte Methode, Web-Applikationen mit dem Einsatz von Ajax interaktiver zu gestalten, wird in dem folgenden Beispiel verdeutlicht. Für die Erstellung und Verwaltung von Aufgaben, Meilensteinen oder Terminen wird dem Benutzer eine Liste der zur Zeit aktiven Ereignisse angezeigt (Abbildung 5.2). Um nun gezielt von einem einzelnen Ereignis 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 aus der Datenbank die dem Ereignis zugeordneten Zeiten und erstellt aus den Daten eine partielle HTML-Seite. Die vom Server gelieferte Antwort wird direkt über eine DOM-Manipulation in die bereits angezeigte HTML-Seite eingefügt. Die detaillierte Übersicht der erfassten Zeiten einer Aufgabe werden dann in der Liste der Ereignisse entsprechend ergänzt. In der Praxis

87 5. Realisierung 87 bedeutet es eine Reduzierung der Ladezeit von HTML-Seiten, da zunächst auf die Übertragung von versteckten Detailinformationen einzelner Seitenelemente verzichtet wird. Erst durch den expliziten Aufruf des Benutzers werden die angeforderten Informationen nachträ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 zunächst die wesentlichen Funktionalitäten zur Zeitplanung und der Zeiterfassung der Mitarbeiter. Diese werden in dem folgenden Abschnitt vorgestellt und erläutert. Das Design des Systems orientiert sich an dem Styleguide für Web-Applikationen der GAIA AG. Eine Veränderung des Layouts kann aber durch Anpassung des Cascading Style Sheets (CSS) vorgenommen werden Ereignisverwaltung Die Ereignisverwaltung liefert eine Übersicht der aktuellen Aktivitäten eines Mitarbeiters (Abbildung 5.2). Die Einteilung in Aufgaben, Termine und Meilensteine erfolgt entsprechend der

88 5. Realisierung 88 bereits vorgestellten Ereignistypen (Abschnitt 3.5). Über die Ereignisverwaltung werden alle Veränderungen an den Eigenschaften der einzelnen Ereignisse vorgenommen. Die Bedienoberfläche zur Bearbeitung eines Ereignisses teilt sich in zwei Bereiche (Abbildung 5.3). Im oberen Bereich werden allgemeine Eigenschaften angezeigt, die unabhängig vom gewählten Ereignistyp sind. Hier werden Titel und eine detaillierte Beschreibung des Ereignisses gespeichert. In der Beschreibung können weitere Notizen und Schlagwörter zur näheren Erklärung als Freitext formuliert werden. Abbildung 5.3.: Bearbeiten eines Ereignisses Im unteren Bereich werden die speziellen Eigenschaften eines Ereignistyps angezeigt. Hier werden neben den zeitlichen Eigenschaften wie Start- und Endzeitpunkt, die Dauer (Sollaufwand) und der Fortschritt des Ereignisses vom Mitarbeiter abgeschätzt und gespeichert. Mit der seperaten Erfassung von geschätztem Fortschritt und aufgewendeter Zeit, können im Projektverlauf kritische Aufgaben identifiziert werden. Durch die wählbaren Prioritäten können bei der Berechnung des Zeitplans gezielt Aufgaben bevorzugt behandelt werden. Das Sichtbarkeitsattribut eines Ereignisses beschreibt die Art der Veröffentlichung innerhalb der Applikation. In Abhängigkeit von den Benutzerrechten können auch andere Mitarbeiter auf die Zeitplanung der anderen zugreifen. Insbesondere, um die aktuelle Auslastung einzelner Mitarbeiter zu ermitteln. Alle Aktivitäten, die mit dem Attribut geschäftlich gekennzeichnet

89 5. Realisierung 89 sind können von dem Mitarbeiter selbst und der Projektleitung eingesehen werden. Öffentliche Aktivitäten können unternehmensweit von allen Mitarbeitern angesehen werden. Private Termine und Aufgaben sind im Gegensatz hierzu nur von dem Mitarbeiter selbst einsehbar. Die Auswahl der Farbe eines Ereignisses wird nach den Präferenzen des Anwenders vorgenommen. Die Farbwahl hilft bei der Einordnung bestimmter Aufgaben oder Termine Zeitplanung Die Darstellung der Zeitplanung eines Anwenders erfolgt in einer Wochenübersicht und ähnelt dem Format eines Stundenplans. Entscheidend für den verfügbaren Planungszeitraum ist die wöchentliche Arbeitszeit des Mitarbeiters. Mit Ausnahme der festen Termine und Meilensteine, werden die Aufgaben nur innerhalb der täglichen Arbeitszeit des Mitarbeiters eingeplant. In der Benutzerverwaltung wird ein Wochenschema zur Definition der wöchentlichen Arbeitszeit hinterlegt. Die Berechnung des Zeitplans erfolgt immer von dem aktuellen Zeitpunkt aus. Die bereits erfassten Zeiten einzelner Aktivitäten werden dabei ebenfalls berücksichtigt. Bei der Erstellung des Zeitplans ordnet die Planungskomponente die einzelnen Ereignisse zunächst nach der Priorität und führt dann in der festgelegten Reihenfolge die Berechnung durch. Gegebenenfalls werden dabei Ereignisse vom Typ Aufgabe in mehrere Kalendereinträge unterteilt, wie z.b. das Ereignis Aufgabe 4 in Abbildung 5.4, das, in drei Kalendereinträge unterteilt, auf zwei Kalendertage eingeplant wurde. Desweiteren werden Planungsprobleme in der Kalenderdarstellung hervorgehoben. In der Wochenübersicht in Abbildung 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. Dieses Planungsproblem wird dem Anwender mit einem rot gefärbten Ereignis in der Vergangenheit visualisiert. Der Benutzer muss nun reagieren und den Planungsfehler durch die Veränderung der Ereigniseigenschaften beheben. Eine weitere Möglichkeit besteht darin, das System einen Vorschlag zur Konfliktlösung machen zu lassen, in dem dem Ereignis ein anderer Planer (z.b. ProblemSolver) zugewiesen wird. In diesem Beispiel würde das System dann versuchen den Konflikt zu lösen und die Zeitplanung von Aufgabe 3 am nächsten Tag fortsetzen sowie den Endzeitpunkt entsprechend verschieben. Dieses sind lediglich Vorschläge des Systems, welche explizit durch den Anwender auf die Durchführbarkeit geprüft werden müssen. Zudem müssen entscheidende Veränderungen mit der Projektleitung kommuniziert werden.

90 5. Realisierung 90 Abbildung 5.4.: Wochenübersicht der Zeitplanung Zeiterfassung Innerhalb der Ereignisverwaltung wurde eine Zeiterfassung integriert (Abbildung 5.5). Hier kann der Anwender parallel zu seiner Tätigkeit den zeitlichen Aufwand direkt erfassen. Nach dem Prinzip einer Stoppuhr können für die aktiven Ereignisse die Aufwandszeiten erfasst werden. Dies gilt für die Ereignistypen Aufgaben und Termine, aber nicht für die Meilensteine, da diese keine zeitliche Spanne besitzen. Die Beendung der Zeiterfassung eines Ereignisses kann direkt vom Anwender kommentiert werden, um nähere Informationen über die durchgeführten Arbeitsschritte zu dokumentieren. Bei einer abschließenden Analyse des Vorgehens einzelner Aktivitäten gibt es Aufschluss über konkrete Arbeitsschritte, wann diese erfolgt sind und welcher Aufwand entstanden ist.

91 5. Realisierung 91 Abbildung 5.5.: Zeiterfassung