MS-Word - Das IICM

Implementierung eines
Projektkoordinations-Systems
unter Hyperwave
Diplomarbeit
an der
Technischen Universität Graz
vorgelegt von
Oliver Strasser
Institut für Informationsverarbeitung und Computergestützte neue Medien
(IICM),
Technische Universität Graz
A-8010 Graz
Mai 2004
©2004, Oliver Strasser
Diese Arbeit ist in deutscher Sprache verfasst.
Begutachter: o.Univ.-Prof. Dr. Dr.h.c.mult. Hermann Maurer
Betreuer: Dipl.-Ing. Dr. techn. Christian Gütl
Dipl.-Ing. Dr. techn. Erwin Duschnig
Kurzfassung
Internationale Konzerne setzen aufgrund wirtschaftlicher Notwendigkeit vermehrt globale
Projektteams ein. Um diese Teams strukturieren und managen zu können, wird der
Einsatz von Koordinationssystemen bzw. von Projektmanagement-Tools unumgänglich.
Die spezifischen Anforderungen an diese Systeme sind umfangreich und unterscheiden
sich je nach Branche und Einsatzgebiet, der Kern der Anforderungen lässt sich aber direkt
aus wichtigen Definitionen des Projektmanagements ableiten. Im Umfeld dieser verteilten
Projektteams muss außerdem gewährleistet werden, dass wichtigen Projektinformationen
an allen Projektschauplätzen zur Verfügung stehen. Im Rahmen dieser Arbeit sollen
solche Systeme untersucht und ein effizienter Ansatz für die Verwendung im Bereich der
Softwareentwicklung am Beispiel des IICM dargestellt werden.
Im ersten Teil dieser Arbeit, dem Untersuchungsbereich, werden einleitend wichtige
Definitionen und Bestandteile des Projektmanagements untersucht. Daraus lassen sich
wichtige Anforderungen an Projektmanagement-Systeme ableiten, die durch allgemeine
Anforderungen des Marktes und spezielle in der Softwareentwicklung ergänzt werden.
Ausgehend von diesen Anforderungen wird eine Auswahl an interessanter am Markt
erhältliche Systeme untersucht und deren Einsatz am IICM bewertet. Ergänzend wird kurz
auf Open Source Lösungen eingegangen.
Die Erkenntnisse des Untersuchungsbereiches fließen in ein Realisierungskonzept zur
Erstellung eines Projektkoordinations-Systems ein, welches auf den speziellen
Anforderungen des IICM basiert. Nach genauer Betrachtung der Basiskomponente, dem
Hyperwave Information Server und den verschiedenen Möglichkeiten der
Anwendungsentwicklung, wird noch der standardisierte Vorgang zur Einbindung von
Komponenten auf diesem System dargestellt. Diese Basisinformation führt unter
Verwendung von objektorientierten Entwurfsmethoden zum Design und in weiterer Folge
zur Implementierung des Systems. Hier wird ebenso die Umsetzung der einzelnen
Dialoge und Funktionen, wie die Implementierung der Objekte mittels serverseitigem
Javascript vorgestellt.
Abstract
An economical need for a cost-effective realisation of projects has increased the use of
international project teams within corporate enterprises. For the management and
administration of these teams the use of project management tools and project
coordination systems is essential. There are various specific requirements for project
management systems. The differences within theses requirements are based on the
individual situation and branch in which the systems are used. However, the most
significant requirements can be exposed from the main definitions of project management.
To present all project information to every member of the project team, wherever they
work, is also one of the important tasks of such a system. The subsequent thesis follows
the analysis of such systems and will show an effective approach as an example at the
IICM, for the use in software development.
The theoretical section of this thesis introduces to the most important definitions and
terms of project management. With this theoretical background the different types of
requirements for project management tools are shown and discussed, in special for
software development. There will be an overview of market available systems with focus
on functionality and prerequisites for installation and hosting at the IICM. In counterpart to
these systems an open source solution will be examined.
Due to the finds of the theoretical section, the practical section of this thesis will present a
realisation concept for a project coordination system, which is based on the special
requirements of the IIICM. After a more precise contemplation of the main component, the
Hyperwave information server and the different possibilities of application development,
there will the standardized operation to retention of components on this system depicted.
This basic information leads by using object-oriented approaches to the design and in
further sequence to implementation of the system. This work will end up in the explanation
of the individual dialogues and functions implementation, just as in the implementation of
the server side JavaScript objects.
Inhaltsverzeichnis
1
EINLEITUNG ................................................................................................... 1
1.1
Motivation ............................................................................................................. 1
1.2
Struktur der Arbeit ............................................................................................... 2
2
EINFÜHRUNG IN DIE PROBLEMSTELLUNG ............................................... 4
2.1
Grundlagen des Projektmanagements ............................................................... 4
2.1.1
Projekt ............................................................................................................. 4
2.1.2
Projektmanagement ........................................................................................ 5
2.1.3
Projektsteuerung ............................................................................................. 8
2.1.4
Projektmanagement – Knowledge Management ............................................10
2.1.5
Notwendigkeit von EDV unterstützten PM-Tools ............................................12
2.2
3
Zusammenfassung..............................................................................................13
ANFORDERUNGEN AN PROJEKTMANAGEMENT SOFTWARE .............. 14
3.1
Allgemeine Anforderungen ................................................................................14
3.1.1
Erwartungen an Projektmanagement Software ..............................................14
3.1.2
Standardfunktionalität.....................................................................................14
3.2
Spezielle Anforderungen im Software Design ..................................................16
3.2.1
Koordination ...................................................................................................17
3.2.2
Zusammenarbeit ............................................................................................17
3.2.3
Kommunikation ..............................................................................................17
3.3
Anforderungen des IICM .....................................................................................18
3.4
Zusammenfassung..............................................................................................19
4
4.1
UNTERSUCHUNG VORHANDENER SYSTEME ......................................... 20
Allgemeine Betrachtungen .................................................................................20
4.2
Microsoft Project 2000 - Microsoft Project Central ...........................................20
4.2.1
Allgemeine Beschreibung ...............................................................................20
4.2.2
Funktionalität ..................................................................................................21
4.2.3
Systemvoraussetzungen ................................................................................23
4.2.4
Integrationsfähigkeit am IICM .........................................................................24
4.3
Enact Enterprise System 5.0 ..............................................................................24
4.3.1
Allgemeine Beschreibung ...............................................................................24
4.3.2
Funktionalität ..................................................................................................25
4.3.3
Systemvoraussetzungen ................................................................................29
4.3.4
Integrationsfähigkeit am IICM .........................................................................29
4.4
Celoxis .................................................................................................................29
4.4.1
4.4.2
4.4.3
4.4.4
Allgemeine Beschreibung ...............................................................................30
Funktionalität ..................................................................................................30
Systemvoraussetzungen ................................................................................34
Integrationsfähigkeit am IICM .........................................................................34
4.5
PHPProjekt ..........................................................................................................34
4.5.1
Allgemeine Beschreibung ...............................................................................35
4.5.2
Funktionalität ..................................................................................................35
4.5.3
Systemvoraussetzungen ................................................................................38
4.5.4
Integrationsfähigkeit am IICM .........................................................................39
4.6
TUTOS ..................................................................................................................39
4.6.1
Allgemeine Beschreibung ...............................................................................39
4.6.2
Funktionalität ..................................................................................................39
4.6.3
Systemvoraussetzungen ................................................................................44
4.6.4
Integrationsfähigkeit am IICM .........................................................................45
4.7
Zusammenfassung..............................................................................................45
TEIL II GESTALTUNGSBEREICH ..................................................................... 48
5
REALISIERUNGSKONZEPT FÜR DAS IICM ............................................... 49
5.1
Anforderungsliste an das Projektkoordinations-System .................................49
5.1.1
Anforderungen aus den theoretischen Betrachtungen ....................................49
5.1.2
Allgemeine bzw. spezielle Anforderungen des IICM .......................................50
5.1.3
Anforderungen aus der Evaluierung bestehender Systeme ............................50
5.2
Pflichtenheft für die Umsetzung.........................................................................51
5.3
Hyperwave Information Server ...........................................................................51
5.3.1
Entstehung des Hyperwave Information Servers ............................................51
5.3.2
Grundlegendes...............................................................................................52
5.3.3
Strukturierte Elemente und Objekte................................................................52
5.3.4
Dokumente, Objekte, Attribute .......................................................................52
5.3.5
Trennung von Information und Präsentation ...................................................52
5.3.6
Link Management...........................................................................................53
5.3.7
Customizing ...................................................................................................53
5.3.8
Suchfunktionalität ...........................................................................................53
5.3.9
Security ..........................................................................................................55
5.3.10 Benutzer- und Gruppenverwaltung .................................................................55
5.4
Applikationsentwicklung am Hyperwave Information Server ..........................57
5.4.1
Place ..............................................................................................................57
5.4.2
Serverseitiges Javascript ...............................................................................57
5.4.3
HWLIB ...........................................................................................................59
5.5
Einbinden von Eigenentwicklungen am HWIS ..................................................61
5.6
Zusammenfassung..............................................................................................63
6
IMPLEMENTIERUNG DES SYSTEMS ......................................................... 65
6.1
Design der Umsetzung .......................................................................................65
6.1.1
Dialoge und Funktionen .................................................................................65
6.1.2
Benutzerinterface ...........................................................................................70
6.1.3
Objektorientierter Entwurf ...............................................................................71
6.2
Implementierung der Objekte .............................................................................73
6.2.1
Mitarbeiter Objekt ...........................................................................................73
6.2.2
Mitarbeiter – Dialog Objekt .............................................................................74
6.2.3
Projekt Objekt ................................................................................................76
6.2.4
Projekt – Dialog Objekt...................................................................................77
6.2.5
Statusbericht - Objekt .....................................................................................78
6.2.6
Statusbericht – Dialog Objekt .........................................................................79
6.2.7
AllgemeinerBericht - Objekt ............................................................................79
6.2.8
AllgemeinerBericht – Dialog Objekt ................................................................80
6.3
Zusammenfassung..............................................................................................81
7
AUSBLICK .................................................................................................... 82
8
ZUSAMMENFASSUNG................................................................................. 83
9
ABBILDUNGSVERZEICHNIS ....................................................................... 85
10
BEISPIELVERZEICHNIS ........................................................................... 87
11
TABELLENVERZEICHNIS ........................................................................ 87
12
LITERATURVERZEICHNIS ....................................................................... 88
13
ANHANG .................................................................................................... 92
13.1
Anhang A – CD-Rom .......................................................................................92
13.2
Anhang B – Pflichtenheft ................................................................................93
Einleitung
1
1 Einleitung
1.1 Motivation
Unternehmen müssen sich heute immer schneller und effizienter den Anforderungen und
Gegebenheiten des Marktes anpassen um wettbewerbsfähig zu bleiben. In Zeiten, in
denen wirtschaftlicher Wettkampf zunehmend auf globaler Ebene stattfindet, sind Firmen
fast aller Branchen gezwungen, effizienter zu arbeiten, Zeit und Kosten in der
Projektabwicklung zu sparen und die Qualität des Ergebnisses zu verbessern. Im Zuge
der Konkurrenzfähigkeit ist es auch notwendig, Produkte früher und günstiger auf den
Markt zu bringen als die Konkurrenz. [Maurer 1996a] [Partel 2000]
Dadurch greifen immer mehr Firmen die Idee der teamorientierten Projektabwicklung auf,
Menschen verschiedenster Professionen und Ausbildung arbeiten an einem Projekt
zusammen. Um so große Projekte verwalten zu können, werden diese in Subsysteme
aufgeteilt, von verschiedenen Teams bearbeitet und anschließend wieder zu einem
Gesamtsystem vereint. [Maurer 1996b] [Nastansky et.al.2000]
Damit die Funktion solcher Subsysteme gewährleistet ist, muss auf die Kommunikation
und Koordination zwischen diesen Teams besonderer Wert gelegt werden. Dadurch wird
es absolut notwendig sein, Computerunterstützung im Projektmanagement und in der
Projektkoordination einzusetzen, damit schnell und qualitativ hochwertig auf
Veränderungen reagiert werden kann. [Maurer 1996b] [Nastansky et.al.2000]
Um diesem erhöhtem Kommunikationsbedarf gerecht zu werden und die räumliche
Entfernung zwischen den Teams überbrücken zu können, ist der Einsatz von neuen
Informationstechnologien notwendig. Wichtiger als der Austausch von Daten ist allerdings
der Austausch von Wissen und Erfahrung, welches oft nur schwach strukturiert ist und
somit neue, wissensbasierte Systeme erfordert. [Schindler et.al.]
Durch die große Menge von zu erfassenden Informationen und zu verwaltenden Daten ist
es schwierig den Projektverlauf richtig zu verfolgen und fehlerfrei auszuwerten. Hier sollte
ein Projektkoordinationstool ansetzen und die relevanten Informationen für jeden
einzelnen bereitstellen. [Gupta et.al. 1996] [Schneider et.al.1999]
Ziel dieser Arbeit ist es, allgemeingültige Standards im Bereich des Projektmanagements
und der Projektsteuerung aufzuzeigen. Weiters soll aus bestehenden Systemen,
allgemeinen Anforderungen und den speziellen Anforderungen des IICM ein Konzept zur
Projektkoordination erstellt werden. Aus den Erfahrungen der Projektverläufe am IICM in
der Vergangenheit und allgemeinen Anforderungen an den Einsatz von Tools im Bereich
der Projektkoordination sollen Möglichkeiten für den Einsatz eines solchen Tools
dargestellt und diskutiert werden.
Die im Untersuchungsbereich dieser Arbeit erzielten Ergebnisse sollen dann in Form
eines Pflichtenheftes festgehalten und anschließend mittels einer Implementierung unter
Hyperwave mit der Verwendung von serverseitigem Javascript (SSJS) unter Nutzung der
objektorientierten HWLIB realisiert werden. Dieses System soll die Projekt- und
Mitarbeiterdaten verfügbar halten und den Aufwand bei der Berichtserstellung verringern.
Einleitung
2
1.2 Struktur der Arbeit
Im ersten Teil dieser Arbeit, dem Untersuchungsbereich, werden in Kapitel 2 alle
notwendigen Begriffe und Definitionen erklärt und der Einsatz von Computerunterstützung
im Bereich des Projektmanagements bzw. der Projektkoordination dargestellt.
Abschließend wird im ersten Kapitel noch der Zusammenhang zwischen
Projektmanagement und Knowledge Management behandelt und der nötige Wandel hin
zum wissenorientierten Projektmanagement aufgezeigt.
Die im dritten Kapitel vorgestellten Anforderungen an Projektmanagement- und
Projektkoordinations-Software werden mit bestehenden Software-Systemen verglichen.
Aus der Funktionalität dieser Systeme und den speziellen Anforderungen des IICM wird
im anschließenden Kapitel ein Konzept für das IICM erstellt.
Um das Konzept erstellen zu können wird im vierten Kapitel zuerst kurz die Projekt- und
Managementstruktur am IICM beschrieben. Davon ausgehend soll ein den Anforderungen
des IICM entsprechendes Konzept erstellt werden. Aufbauend auf diesem Konzept und
den Systemanforderungen wird in diesem Kapitel ein System definiert und konzipiert,
dessen Implementation im nächsten Kapitel beschrieben wird.
Im zentralen Teil der Arbeit, dem Gestaltungsbereich, wird im fünften Kapitel das
Realisierungskonzept für ein Projektkoordinationstool vorgestellt und die notwendigen
Komponenten kurz erklärt. Vorgestellt in diesem Rahmen werden der Hyperwave
Information-Server und die Hwlib-Bibliothek, welche für die Realisierung herangezogen
wird.
Kapitel 6 behandelt die Implementierung des Projektkoordinationstools, hier werden die
Funktion und der Aufbau des Tools beschrieben, alle Software-Module und deren
Funktion erklärt. Weiters werden Überlegungen, die zu dieser Implementierung geführt
haben aufgezeigt und die dahinter liegende Technik erklärt.
Im abschließenden Kapitel der Arbeit wird nochmals eine Zusammenfassung der
wichtigsten Punkte der Arbeit gegeben, und ein Ausblick auf die Zukunft solcher Systeme
dargestellt werden. Dabei werden Möglichkeiten der Weiterentwicklung in Hinblick auf
wissensbasierte Systeme und der Einsatz von künstlicher Intelligenz in diesem Bereich
aufgezeigt.
3
Teil I
Untersuchungsbereich
Einführung in die Problemstellung
4
2 Einführung in die Problemstellung
Um im weiteren Verlauf der Arbeit bestehende Projektmanagement-Tools nach fachlichen
Gesichtspunkten untersuchen und ein Konzept für das IICM erstellen zu können, ist es
notwendig, vorerst die wichtigsten Definitionen und Grundlagen von Projekten und
Projektmanagement zu behandeln. Da im Projektmanagement Information und
Informationsfluss zu den wichtigsten Bestandteilen gehören, werden in diesem Kapitel
abschließend die Grundlagen von Knowledge Management erklärt und der
Zusammenhang zwischen Projektmanagement und Knowledge Management hergestellt.
2.1 Grundlagen des Projektmanagements
Projektmanagement wurde in den 1950er Jahren in den USA entwickelt, als man bei
komplexen Raumfahrtprogrammen und bei der Entwicklung von Waffensystemen
erkannte, dass derart komplexe Vorhaben neue Strukturen und Methoden erfordern.
Vorerst wurde Projektmanagement bei den amerikanischen Regierungsstellen eingesetzt
um die Zusammenarbeit von Fachleuten aus verschiedenen Bereichen zu vereinfachen
und fand über Regierungsprojekte den Weg in die Wirtschaft. [Mach 2001]
In diesem Abschnitt werden die wichtigsten Begriffe und Definitionen des
Projektmanagements erklärt und die Grundlagen beschrieben.
2.1.1 Projekt
Um das Wesen eines Projektes zu charakterisieren wird im deutschsprachigen Raum oft
die Übersetzung von Schröder genannt:
„Als Projekt kann jede Aufgabe bezeichnet werden, die einen definierten Anfang und ein
definiertes Ende besitzt, die den Einsatz mehrerer Produktionsfaktoren für jeden der
einzelnen, miteinander verbundenen und wechselseitig voneinander abhängigen
Teilvorgänge erfordert, die ausgeführt werden müssen, und das dieser Aufgabe
vorgegebene Ziel zu erreichen.“ [Elei 1996] [Blüminger 2003]
In der DIN 69901 wird ein Projekt über die Einmaligkeit der Aufgabe definiert: „Vorhaben,
das im wesentlichen durch Einmaligkeit der Bedingungen in ihrer Gesamtheit
gekennzeichnet ist.“ [Elei 1996] [Blüminger 2003]
Diese, in der DIN-Norm beschriebenen Bedingungen, werden über Zielvorhaben,
zeitliche-, finanzielle-, personelle- oder andere Begrenzungen, Abgrenzung gegen andere
Vorhaben und projektspezifische Organisation definiert. Aus diesen beiden Definitionen
lassen sich die folgen, wichtigen Punkte der Projektdefinition ableiten: [Elei 1996] [Mach
2001]



Das Projektvorhaben ist einmalig
Es muss ein definiertes Ziel vorhanden sein
Die zur Verfügung stehenden Ressourcen sind begrenzt und konkurrieren
untereinander, woraus sich eine zeitliche und finanzielle Einschränkung ergibt
Einführung in die Problemstellung



5
Da sich ein Projekt wesentlich von Routineaufgaben unterscheidet, ist die
Organisation auch nicht optimal darauf ausgerichtet. Oftmals sind eine
interdisziplinäre Zusammenarbeit und spezielle Organisation notwendig
Um zum definierten Ziel zu gelangen ist die Lösung von komplexen Teilaufgaben
notwendig
Weiters wird ein Projekt noch über Risikoreichtum, Wichtigkeit für das
Unternehmen und Unsicherheit der Problemlösung charakterisiert.
Projekte können voneinander durch Projektdauer, Projektgröße, Projektart und Projekttyp
unterschieden werden, wobei die Projektdauer von wenigen Monaten bis zu mehreren
Jahren dauern kann. Ein Projekt sollte aber mindestens 2 Monate und nicht länger als 5
Jahre dauern, wobei die Projektdauer über die Anzahl der Projektmitarbeiter gesteuert
werden kann. Die Projektgröße geht von sehr kleinen Projekten mit weniger als drei
Mitarbeitern bis zu sehr großen Projekten mit mehr als 500 Mitarbeitern. [Turowski 2000]
Über die Projektart können Projekte nach Branchen, Standort und Zielen kategorisiert
werden. Projekte mit verschiedenen Zielsetzungen können sein: [Gareis 1999]
Forschungsprojekte die durch Neuheit der Aktivitäten gekennzeichnet sind,
Entwicklungsprojekte die sich über ein klar definiertes Entwicklungsziel darstellen lassen,
das Ziel von Rationalisierungsprojekte ist die Verbesserung von betriebsinternen
Abläufen.
Weiters gibt es noch Projektierungsprojekte, Vertriebsprojekte, BetreuungsUnternehmensprojekte und Planungs- und Vorleistungsprojekte. Diese Unterscheidung in
einzelne Projektarten stellt jedoch nur einen groben Überblick dar, was im einzelnen als
Projekt und welcher Art behandelt wird kann immer nur im Rahmen einer
unternehmensindividuellen Vorgehensweise beantwortet werden. Ebenso lässt sich den
Projektkategorien nur für ein Unternehmen die Anwendung verschiedener
Projektmanagementverfahren zuordnen. [Turowski 2000]
Um jede dieser verschiedenen Projektarten verwalten und managen zu können, ist es
notwendig die grundlegenden Aufgaben und Methoden des Projektmanagements zu
verstehen. Ein Überblick über diese Aufgaben und Methoden wird in Kapitel 2.1.2 bis
2.1.3 gegeben.
2.1.2 Projektmanagement
Projektmanagement stellt einen ganzheitlichen Prozess dar, der alle Teilprozesse des
Projektverlaufes abdecken muss. Dieser Prozess startet mit dem Projektauftrag,
beinhaltet das Managen von Unregelmäßigkeiten im Projektverlauf, die
Projektkoordination während der gesamten Projektdauer und endet mit der Abnahme des
fertig gestellten Projektes.
Abbildung 1 zeigt diese
Projektmanagements.
Projektphasen
mit
den
zugehörigen
Aufgaben
des
Einführung in die Problemstellung
6
Abbildung 1: Projektphasen und zugehörige PM-Aufgaben [Turowski 2000]
In der Projektstartphase, welche die Projektdefinition und Projektplanung umfasst, muss
durch das Projektmanagement ein Know-how Transfer aus der Vorprojektphase in das
Projekt sichergestellt werden. Alle notwendigen Projektziele müssen definiert und alle
Projektpläne erstellt werden. Um einen erfolgreichen Projektverlauf realisieren zu können
müssen eine Projektrisikoanalyse, eine Projektnutzen-Kosten-Analyse und eine
Aufwandsschätzung
erstellt
werden.
In
der
Projektabschluss-Phase
sind
Abschlussberichte zu erstellen, die Projektkosten zu evaluieren, das Projektmarketing
abzuschließen und das Projektteam aufzulösen. [Gareis 1999]
Die während des Projektverlaufes auszuführenden Tätigkeiten der Projektsteuerung
werden in Abschnitt 2.1.3 behandelt. Die DIN 69901 beschreibt Projektmanagement als
"Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mittel für die
Abwicklung eines Projekts". Die wichtigsten Ziele, die durch Projektmanagement erreicht
werden sollen, sind die Sicherung des Projekterfolges (Termin, Kosten und Qualität), die
Verkürzung der Projektdurchlaufzeiten und das Erreichen von Kundenzufriedenheit.
Weiters müssen im Bereich der Teamführung Aufgaben der Mitarbeiterauswahl,
Förderung und Motivation der Teammitglieder, Konfliktbehandlung und Förderung der
Arbeitsbedingungen wahrgenommen werden. [Schelle 1997]
Folgende Prinzipien sollten vom Projektmanagement verfolgt werden: [Schelle 1997]



Strukturieren von Projekten
Starke Betonung der Definitionsphase
Klare Ziele und Vorgaben, die den Beteiligten bekannt sind
Einführung in die Problemstellung




7
Transparenz über den jeweiligen Projektstand
Frühes Erkennen von Risiken
Schnelle Reaktion auf Projektstörungen
Personifizierte Verantwortung
Ebenfalls wichtige Punkte, die in jeder Projektphase gelöst werden müssen, sind
Verbesserung der Kommunikation im Team, Schaffen und Wahren geeigneter
Rahmenbedingungen und Erkennen und Neutralisieren unerwarteter Schwierigkeiten. Um
diese Aufgaben bewältigen zu können, sind als Voraussetzung Verständnis des
Entwicklungsprozesses, Mechanismen der Produktivitätserhöhung und im Bereich der
Bewertung des Projektstandes und der Planung notwendig. [Lichter 1999]
Projektmanagement stellt keinen Selbstzweck im Unternehmen dar, sondern soll bei den
hohen Anforderungen auch einen dementsprechenden Nutzen bringen. Dieser Nutzen
liegt in der Schaffung von Transparenz, weiters ist es frühzeitig möglich, Risiken und
Planabweichungen zu erkennen, einen Überblick über den Projektfortschritt, die
Strukturierung des Projektinhalts und des Ablaufes, sowie Klarheit über die Zielvorgaben
zu bekommen. Im weiteren Sinne bringt Projektmanagement besser strukturierte
Projektsitzungen, eine größere Anzahl von Bereichsaktivitäten, eine einheitliche und
regelmäßige Projektberichterstattung sowie aufgrund von Standardisierung eine
Rationalisierung der Projektplanung und –verfolgung. [Lichter 1999]
Projektmanagement erbringt auch direkte Wirtschaftlichkeitseffekte: höhere Termin- und
Kostentreue, bessere Erreichung der Leistungsziele und eine Verkürzung der
durchschnittlichen Durchlaufzeiten. Eine höhere Zufriedenheit der Kunden, des
Management und der Mitarbeiter zählen ebenfalls zu den positiven Effekten. [Schelle
1997]
Dieser durch das Projektmanagement erhaltene Nutzen ist jedoch nicht kostenlos für das
Unternehmen. Bei den entstehenden Kosten muss zwischen zentralem und dezentralem
Projektmanagement unterschieden werden. Bei zentralem Projektmanagement, welches
z.B. durch ein Projektbüro abgewickelt wird, sind die Kosten klar zuordenbar. Der Nachteil
bei dezentralem Projektmanagement liegt bei den nicht zuordenbaren und teilweise
höheren Kosten. Abbildung 2 zeigt den prozentualen Kostenanteil der
Projektmanagement-Kosten bei kleinen und großen Projekten: [Turowski 2000]
Abbildung 2: Prozentueller Kostenanteil von Projektmanagementkosten [Turowski 2000]
Einführung in die Problemstellung
8
2.1.3 Projektsteuerung
Projektsteuerung ist eine kontinuierliche Tätigkeit während des Projektverlaufs und Teil
der Projektmanagementfunktion. Sie soll sicherstellen das der tatsächliche Projektverlauf
mit der ursprünglichen Planung in Einklang steht. Zu den Aufgaben der
Projektkoordination zählt man: [PM-Fibel 1998]







die Entwicklung von Kennzahlen und Messsystemen zur Erfassung von
Planabweichungen und des Projektzustand (Projekterfolg)
die Implementierung von Controlling-Standards
den Vergleich der Projektpläne (Soll-/Ist-Vergleich)
die Interpretation der Ergebnisse und Entwicklung von Steuerungsmaßnahmen
die Erstellung von Projektberichten
die Verfolgung des Projektumfeldes
die Sicherstellung der optimalen Nutzung von im Projekt gemachten Erfahrungen
Um diese Aufgaben wahrnehmen zu können, stellt die Projektsteuerung einen sich
periodisch wiederholenden Ablauf dar, welcher die in den nächsten Absätzen
beschriebenen Tätigkeiten umfasst. Erklärt werden die Erfassung der Ist-Daten, der
Soll/Ist-Vergleich, die Meilenstein-Trend-Analyse und Steuerungsmaßnahmen.
2.1.3.1 Erfassung der Ist-Daten
Diese Datenerfassung ist die Basis für jede Projektkoordination. Ziel ist es
herauszufinden, wie das Projekt im Vergleich zum ursprünglichen Plan weiter verlaufen
wird und welche Auswirkungen die derzeitige Situation hat. Weiters ist sie die Grundlage
des Soll/Ist-Vergleichs. Ziel des Soll-/Ist-Vergleichs ist es, durch die Gegenüberstellung
der ursprünglichen Projektplanung und momentaner Planung Abweichungen ersichtlich zu
machen und deren Auswirkungen auf den weiteren Projektverlauf abzuschätzen. [Lichter
1999]
Bei der Erfassung der Ist-Daten ist zwischen vergangenheits- und zukunftsbezogenen IstDaten zu unterscheiden. Vergangenheitsbezogene Ist-Daten werden häufig aus
betriebswirtschaftlichen Gründen erfasst und dienen in erster Linie der
Erfahrungssicherung.
Zukunftsbezogene
Ist-Daten
stellen
keine
Daten
im
betriebswirtschaftlichen Sinn dar sondern aktuelle Schätzungen und stellen die Basis für
ein notwendiges Frühwarnsystem dar. [PM-Fibel 1998]
2.1.3.2 Soll-Ist-Vergleich
Der Soll-Ist-Vergleich ist ein weit verbreitetes Instrument im Projektcontrolling. Es soll
überprüft werden ob die momentane Planung mit der ursprünglichen noch in Einklang
steht. Weiters müssen Abweichungen des Projektverlaufes transparent gemacht werden
und der Einfluss auf den weiteren Projektverlauf abgeschätzt werden. Der Soll-IstVergleich kann mit allen relevanten Daten des Projektes also Kosten, Zeit und Aufwand
durchgeführt werden. Der Soll-Ist-Vergleich muss sich auf einen bestimmten Stichtag
beziehen und schließt vergangenheits- und zukunftsbezogene- Ist-Daten mit ein. [PMFibel 1998]
Einführung in die Problemstellung
9
2.1.3.3 Meilenstein-Trend-Analyse
Ein sehr einfaches und übersichtliches Instrument zur manuellen Darstellung des
Projektstatus ist die Meilenstein-Trend-Analyse. Ein realistischer Terminplan in Form von
richtig definierten Meilensteinen, ist die Voraussetzung für die Anwendung dafür.
Dargestellt werden bei der Meilenstein-Trend-Analyse nur die wesentlichen
Projektereignisse. Ziel ist der Soll-Ist-Vergleich der gesetzten Meilensteine, die
Darstellung der Trendentwicklung und der Gewinn von Aussagen über die Präzision der
zugrunde liegenden Schätzwerte. [Lichter 1999]
Abbildung 3: Meilenstein-Trend-Analyse [PM-Fibel 1998]
Die Meilenstein-Trend-Analyse wird als einzelne Grafik pro Projekt angelegt und im
Projektverlauf nur ergänzt. Auf der Horizontalen werden in dieser Grafik die
Berichtszeitpunkte aufgetragen, in der Vertikalen die Fertigstellungstermine. Jeder der
eingetragenen Meilensteine wird durch eine Grafik gekennzeichnet. Das bedeutet, dass in
periodischen Abständen die Termine entsprechend eingetragen werden. Erfolgt eine
Änderung des Plantermins, muss dies dokumentiert werden. Auf diese Art und Weise
entsteht praktisch "automatisch" eine Dokumentation der wichtigsten Planänderungen und
deren Gründe im Projektverlauf. [PM-Fibel 1998]
2.1.3.4 Steuerungsmaßnahmen
Aufgrund der Analyse können korrigierende Maßnahmen ansetzen und die Ist-Werte an
die Soll-Werte heranführen. Weiters kann der Projektplan durch Änderungen an das Ist
angepasst werden. Die Auswahl der Steuerungsmaßnahmen ist bedingt durch die
Auswirkungen, welche die erkannten Abweichungen auf das Projektziel haben. Leistung,
Kosten und Termine sind dabei zu unterscheiden. [Lichter 1999]
Ist die Leistung zu gering, kann der Ressourceneinsatz erhöht werden, z.B. werden
Überstunden geleistet oder es kommen weitere Mitarbeiter zum Einsatz. Für
Einführung in die Problemstellung
10
Projektmitarbeiter wird ein Leistungsanreizsystem erstellt, Prämien werden ausgesetzt
und man versucht die Motivation noch weiter zu erhöhen. Auch eine Verbesserung der
Kontrolle kann die Leistung der Mitarbeiter erhöhen. [Lichter 1999]
Wenn die vorgesehene Zeit überschritten wird kann wiederum mit einem erhöhten
Ressourceneinsatz gearbeitet werden. Eine Kürzung der Dauer der Arbeitspakete am
kritischen Weg ist auch ein effektives Mittel zur rascheren Erfüllung von einzelnen
Projektschritten. Durch Vorsehen von Überlappungen, Eliminieren von Abhängigkeiten
und der Nutzung des Rationalisierungspotentials ist dies gewährleistet. Die letzte
Steuerungsmaßnahme die bei Zeitüberschreitung angewandt wird, ist die Reduktion der
Funktionalität. [PM-Fibel 1998]
Wird bei der Meilenstein-Trend-Analyse eine Überschreitung der Kosten festgestellt, so
kann als Steuerungsmaßnahme eine Vergabe von Teilleistungen an Subauftragnehmer
gesetzt werden. Dadurch können interne Ressourcen eingespart werden. Auch indem
man die Qualität auf das unbedingt Nötigste beschränkt können Kosten eingespart
werden. Die Nutzung von günstigeren Varianten ist eine weitere Möglichkeit der
Einsparung von finanziellem Aufwand, vor allem im Bereich der Technologie, jedoch führt
diese zu einem höheren Zeitaufwand. Steuerungsmaßnahmen sind mit dem Auftraggeber
abzusprechen, vor allem wenn es dabei um eine Reduktion von Funktionalität oder
Qualität geht. Es muss auch überprüft werden inwieweit die vorgegebenen Ziele
veränderbar sind. [Lichter 1999]
In Abschnitt 2.1.4 wird ein kurzer Überblick über Knowledge Management und den
Zusammenhang zwischen Projekt- und Knowledge-Management gegeben, da diese
beiden Gebiete sehr eng miteinander verwandt sind, bzw. Teilbereiche aus beiden in
Projektmanagement-Tools abgebildet werden sollten.
2.1.4 Projektmanagement – Knowledge Management
Um Projektmanagement im Kontext des Knowledge Management betrachten zu können,
ist es zuerst notwendig, kurz einige Begriffe und Definitionen des Knowledge
Managements zu erläutern. Abbildung 4 zeigt Trends bei Projektmanagement-Systemen
(in dieser Abbildung als PM-Systeme bezeichnet) auf. Trends wie „Web Based
Technologies“, „Groupware“, „virtuelle Projekt-Teams“, „Management by Projects“ und
eben „Wissensmanagement“ werden in verschiedene Dimensionen unterteilt dargestellt.
Einführung in die Problemstellung
11
Abbildung 4: Trends im Projektmanagement [Schindler et.al. 1998]
Um eine Definition des Begriffes „Wissen“ zu geben seien beispielhaft zwei Definitionen
angeführt: Steinmüller definiert Wissen als „Vernetzung von Information, so dass ein
bestimmter Zweck unter spezifischen Kontextbedingungen effizient verfolgt werden kann“
Albrecht definiert Wissen als „das Ergebnis der Verarbeitung von Informationen durch das
Bewusstsein und kann als verstandene Information bezeichnet werden“. Teilbereiche von
Knowledge Management werden je nach Modell unterschiedlich dargestellt. Eine
Möglichkeit ist die Aufteilung in folgende drei Bereiche: Produktion, Distribution und
Verarbeitung von Wissen [Schindler 1998]
Hinter dem Begriff Knowledge Management verbirgt sich aber mehr als reines
Datenbankmanagement, Workflow oder Intranet, vielmehr steckt dahinter die Disziplin im
Unternehmen vorhandenes Wissen besser und effektiver zu nützen. Informationen und
Wissen sollen zielgerichtet verteilt werden und aus bestehenden Datenbeständen sollen
mehr Rückschlüsse gezogen werden. Um das realisieren zu können ist es notwendig, die
Einstellung im Unternehmen zu Wissen und Wissensmanagement dahingehend zu
verändern, dass Information offen gelegt wird. [Schindler et.al. 1998]
Durch den Einsatz verteilter Projektteams steigt der Kommunikationsbedarf innerhalb der
Teams und zwischen den einzelnen Teams. Um diesem gerecht werden zu können und
die räumliche Entfernung zwischen den Teams zu überbrücken ist der Einsatz von
innovativer Kommunikations- und Informationstechnologien notwendig. Diese
Kommunikations- und Informationstechnologien müssen jedoch in ProjektmanagementTools integriert sein, um einen effizienten und erfolgreichen Einsatz zu gewährleisten.
Wobei Information nicht nur in Form von Daten ausgetauscht wird, wichtiger ist der
Austausch von Wissen und Erfahrung, welches oft nur schwach strukturiert ist und somit
neue, wissensbasierte Systeme erfordert. Dadurch wird auch der enge Zusammenhang
zwischen Projektmanagement und Knowledge Management deutlich. Wichtige Teile von
PM-Tools stellen eigentlich KM-Tools dar, umgekehrt werden einzelnen Teile von KM-
Einführung in die Problemstellung
12
Tools im Projektmanagement eingesetzt. Diese Veränderung im Projektmanagement wird
im nächsten Abschnitt genauer behandelt. [Schindler et.al. 1998]
2.1.4.1 Vom traditionellem- zum „wissensorientierten“ Projektmanagement
Bezieht man den Faktor „Wissen“ in die Projektabwicklung mit ein, so verändert dies die
Struktur im Projektablauf. Die herkömmlichen Komponenten Projektidee, Projektauftrag
und Projektdurchführung werden folgend ergänzt: Auf die Projektidee erfolgt eine
Betrachtung der „lessons learned“ alter Projekte, erst darauf folgt der Projektauftrag und
die Projektdurchführung. Am Ende dieses Ablaufes erfolgt noch die Archivierung der
„lesson learned“ für nachfolgende, neue Projekte. Dies ermöglicht eine Sicherung des
Wissens aus bereits abgeschlossenen Projekten für die Zukunft. Das Recycling des
Projekt Know-how reichert außerdem das Wissen im Unternehmen sukzessive an.
[Schindler 1998]
Drei Perspektiven der verteilten Projektabwicklung im Bereich Wissensmanagement
können hervorgehoben werden: [Schindler 1998]
1. Relevantes Projektwissen im Rahmen des operativen Projektmanagements
Wissen im Projektumfeld zur richtigen Zeit den richtigen Personen zur Verfügung zu
stellen, damit diese relevante Information auf konkrete Problemstellungen anwenden
können.
Das
aus
verschiedenen
Teilprojekten
stammende Wissen
soll
projektübergreifend zur Verfügung stehen.

2. Projektwissen im Rahmen einer Betrachtung aus der Führungsperspektive
Die Unternehmenskultur, die Organisationsform und der Führungsstil müssen in
entsprechender Form gebildet werden, um geeignete Methoden und Instrumente
anwenden zu können bzw. den projektorientierten Aufbau des Unternehmens zu
gewährleisten. Im Projektmonitoring muss sichergestellt werden, dass Eskalationsrichtlinien bei Planabweichungen vorhanden sind und diese auch eingesetzt werden.

3. Relevantes Projektwissen im Rahmen von ex-post Betrachtungen
Die Sicherung, Archivierung und das zur Verfügung stellen von relevantem Projektwissen
aus
bereits
abgeschlossenen
Projekten,
Projekterfahrungen,
Fehler
und
Verantwortungsbereiche in der Projektabwicklung müssen dokumentiert werden.
2.1.5 Notwendigkeit von EDV unterstützten PM-Tools
Standardisierte und vielfach im Einsatz befindliche Methoden und Verfahren im
Projektmanagement können nur in begrenztem Rahmen die stark gestiegenen
Anforderungen heutiger Projekte bewältigen. Aufgrund von Faktoren wie verteilten
Projektteams und dem daraus resultierenden hohen Kommunikations- und
Informationsbedarf, der notwendigen schnellen und qualitativ hochwertigen Reaktion auf
aktuelle Marktereignisse und der enormen Menge an zu verwaltenden Projektdaten wird
der Bedarf des Einsatzes von Softwaretools zur Unterstützung des Projektmanagements
ersichtlich. Ob diese Softwaretools nur Teilaufgaben wie Dokumentation, Kostenrechnung
oder Mitarbeiterverwaltung abdecken oder Unterstützung im gesamten Aufgabengebiet
Einführung in die Problemstellung
13
bieten, spielt dabei keine Rolle. Ebenfalls ist unerheblich ob für Detaillösungen
Standardsoftware wie Textverarbeitung oder Tabellenkalkulationen herangezogen
werden, oder hoch spezialisierte Projektmanagement-Software zum Einsatz kommt.
[Schindler 1998]
Knowledge Management wird oft mit dem Einsatz von Software-Tools gleichgesetzt, in
Wirklichkeit kann der Einsatz dieser Tools nur ein Ergebnis von Knowledgle Management
Ansätzen sein. Wie bereits in Abschnitt 2.1.4 beschrieben, befasst sich Knowledge
Management vielmehr mit dem Umgang und der Einflussnahme der Ressource Wissen.
Im Unternehmen soll der Einsatz von Knowledge Management Methoden und Tools die
Leistungsfähigkeit und Konkurrenzfähigkeit steigern. Dies soll durch eine verbesserte
Nutzung von Wissen innerhalb des Unternehmens erreicht werden. Ohne die Integration
der notwendigen Methoden und daraus resultierenden Änderungen in der
Organisationsstruktur im Unternehmen lassen sich die beschriebenen Ziele aber nicht
realisieren. [Rollet 2000]
Der in Abschnitt 2.1.4 betrachtete Übergang von konventionellem Projektmanagement zu
wissensorientiertem Projektmanagement stellt ein weiteres wichtiges Argument für den
Einsatz von Projektmanagement-Software dar. Um Prinzipien des Knowledge
Management im Projektmanagement einsetzen zu können, ist der Einsatz von
entsprechender Software unerlässlich. Erst dadurch wird überhaupt das zur Verfügung
stellen von entsprechendem Wissen zum richtigem Zeitpunkt möglich.
2.2 Zusammenfassung
Um im weiteren Verlauf dieser Arbeit die korrekten Begriffe verwenden zu können und
einen Überblick über die Themen Projekt, Projektmanagement, Projektsteuerung und
Wissensmanagement im Bereich des Projektmanagement zu geben, wurden in diesem
Kapitel alle wichtigen Begriffe erläutert und die Zusammenhänge aufgezeigt.
Durch die Abgrenzung des Projektbegriffes und die Darstellung der unterschiedlichen
Projekttypen wird die Notwendigkeit individuell an das Unternehmen angepasster
Projektmanagementverfahren erläutert. Mittels der einzelnen Projektphasen wurden die
jeweiligen Aufgaben im Projektmanagement skizziert und den Zweck und die Kosten von
Projektmanagement beschrieben.
Projektkoordination als notwendiges Instrument im Projektmanagement und die
zugehörigen Aufgaben wird ebenso beschrieben wie der Zusammenhang zwischen
Projektmanagement und Wissensmanagement. Daraus lassen sich Trends und
zukünftige Entwicklungen in diesem Bereich ableiten, auf welche noch später in dieser
Arbeit eingegangen wird.
Um der Notwendigkeit der Software-Unterstützung, die im Abschnitt 2.1.5 beschrieben
wurde, Rechnung tragen zu können wird im nächsten Kapitel auf genau solche Software
eingegangen. Es sollen die Anforderungen an diese Software beschrieben werden,
weiters sollen die unterschiedlichen Typen dargestellt und im Abschluss ein Überblick
über Software-Pakete am Markt gegeben werden. Aus diesem Überblick soll eine
Zuordnung der verschiedenen Lösungen zu den verschiedenen Anforderungen getroffen
werden.
Anforderungen an Projektmanagement Software
14
3 Anforderungen an Projektmanagement Software
Um der in Abschnitt 2.1.5 beschriebenen Notwendigkeit der EDV-Unterstützung im
Projektmanagement nachkommen zu können, ist es unerlässlich genaue Anforderungen
an Projektmanagement-Software zu definieren. Diese Anforderungen setzen sich aus
allgemeinen Anforderungen des Marktes und den individuellen Anforderungen des
Unternehmens, welche sich aus der Unternehmensstruktur und den Projektmanagement
Prozessen ableiten lassen, zusammen. In Kapitel 3 sollen genau diese Anforderungen
und Möglichkeiten der Abdeckung beschrieben werden.
3.1 Allgemeine Anforderungen
Die allgemeinen Anforderungen an Projektmanagement Software lassen sich in erster
Linie durch Aufgaben beschreiben, welche durch die EDV-Unterstützung einfacher und
effizienter abgedeckt werden sollen. Hier sollen vor allem allgemein gültige
Anforderungen beschrieben werden, Branchenspezifika werden nur am Rande betrachtet.
3.1.1 Erwartungen an Projektmanagement Software
Die Erwartungshaltung, die beim Einsatz vom Projektmanagement Software auftritt, zielt
in erster Linie die Verbesserung im Ablauf der betrieblichen Projekte und die Ergebnisse,
die daraus resultieren. Eingeschränkt werden diese Verbesserungen durch die
Funktionalität der Software, den Mehraufwand durch den Einsatz und einem
Mehraufwand in der Datenpflege. Eine Umfrage der RWTH Aachen, die zum Thema
Erwartungen an Projektmanagement Software mit Konstruktionsleitern mittelständischer
Unternehmen geführt wurde, lieferte folgendes Ergebnis: [Elei 1996]




Verbesserung der Transparenz in der Planung und Ausführung in Hinblick als
Informations- und Kontrollinstrument
Verringerung des Planungs- und Dokumentationsaufwandes
Qualitative Verbesserung der Planung, durch Einbindung von Informationen aus
vergangenen Projekten (Lessons learned)
durchgängigere Auftragsplanung
3.1.2 Standardfunktionalität
Folgende Funktionalitäten werden als notwendige Mindestanforderungen angesehen, die
Projektmanagement Software erfüllen muss. Diese Anforderungen gelten nicht für
Ergänzungstools, deren Funktionalität richtet sich nach dem speziellen Aufgabengebiet:
[Schindler et.al.1998]




Einsatz als Steuerungsinstrument
Erfüllen von Planungsaufgaben
Kontroll- und Dokumentationssystem
Grafische Aufbereitung von Berichten
Anforderungen an Projektmanagement Software
15
Im Einzelnen können diese Anforderungen an Funktionalitäten noch nach Teilaufgaben
bzw. Teilfunktionalität eingeteilt werden. Diese Auflistung nach [Elei 1996] stellt einen
Ausschnitt möglicher Funktionalitäten dar und soll lediglich einen Überblick geben:
Projektstrukturierung
In der Projektdefinition müssen Projekte nach Ressourcen, Organisation und
Arbeitspaketen strukturiert werden. Diese Struktur sollte dann in Strukturplänen
abgebildet werden können. In diesem Bereich ist vor allem eine einfache Eingabe und
Wartung der Daten gefordert. Wiederholende Eingaben sollen durch Schablonen
unterstützt bzw. automatisiert werden können. [Elei 1996]
Netzplantechnik und Kalenderfunktionalität
Um Projekttermine planen, anpassen und kontrollieren zu können, dient die
Netzplantechnik als weit verbreitetes Instrument. Diese Planung erfolgt unter
Berücksichtigung von Ressourcen und Kosten, als Grundlage dafür muss ein möglichst
flexibler Kalender dienen. Die Kalenderfunktionalität muss eine Unterteilung des
Kalenders in Projektkalender, Ressourcenkalender und Vorgangskalender bieten, nur
dann ist eine flexible Verwaltung der Unterschiedlichen Daten möglich. [Elei 1996]
Terminplanung und -kontrolle
Bei der Terminplanung bzw. –kontrolle müssen Daten wie Projektanfang, Projektende,
definierte Zeitabstände, Arbeitszeiten, Ausfallzeiten, Dauer von Vorgängen,
Terminvorgaben und kapazitive Beschränkungen vorhanden sein und berücksichtigt
werden. Um im Projektverlauf eine Terminkontrolle durchführen zu können ist es
notwendig, diese Daten den Soll-Werten gegenüberzustellen und gegebenenfalls durch
Warn- und Hilfsfunktionen auf Abweichungen aufmerksam zu machen. Die Unterstützung
in der Terminplanung ermöglicht eine kapazitätsunabhängig und damit termintreue
Planung, oder kapazitätsabhängig, wobei in diesem Fall die Termine nach hinten
verschoben werden. [Elei 1996]
Kapazitätsplanung und -kontrolle
Hier müssen notwendige Ressourcen, die in Form von Arbeitskräften, Maschinen oder
anderen Gerätschaften vorliegen, zeitbezogen geplant und den ausführenden
Organisationseinheiten zur Verfügung gestellt werden. Projektmanagement Software
kommt dann zum Einsatz, wenn die zur Verfügung stehenden Ressourcen nicht
ausreichen um die Projektanforderungen abzudecken. Um diesem Problem zu begegnen,
kommen unterschiedliche Strategien zum Einsatz. Dabei gibt es die Möglichkeit Termine
zu verschieben oder mehr Ressourcen zum Einsatz zu bringen (termintreue Planung).
[Elei 1996]
Zugriff und Einsatzgebiet
Der Zugriff auf das Projektmanagement System kann entweder direkt über eine
Workstation oder ein Firmennetzwerk erfolgen, oder aber über ein Intranet oder das
Internet. Es können auch durchaus verschiedene Zugriffsszenarien notwendig sein,
Anforderungen an Projektmanagement Software
16
abhängig davon welche Mitarbeiter eines Unternehmens welche Funktionalitäten wo
benötigen. Weiters kann eine Unterscheidung hinsichtlich der Benutzerrechte getroffen
werden da im Normfall verschiedene Mitarbeiter Daten einpflegen, abrufen oder Reports
erstellen müssen. [Vandersluis 2000]
Systemarchitektur und Schnittstellen
Die meisten Unternehmen besitzen eine Vielfalt an Datenbanken und Systemen um diese
zu verwalten. Heute ist es unerlässlich für eine erfolgsrelevante Software wie ein
Projektmanagement System, Datenquellen über verschiedene Schnittstellen zu nutzen
und gegebenenfalls auch direkt in andere Systeme integriert werden zu können. Solchen
Anforderungen kann z.B. über eine offene Systemarchitektur Rechnung getragen werden.
[Vandersluis 2000]
Einsatz von Standardsoftware
Haben viele Mitarbeiter bereits umfangreiche Erfahrungen mit Standardsoftware wie
Textverarbeitungsprogrammen,
Tabellenkalkulation,
Datenbanken
oder
Grafikprogrammen, können solche Standardlösungen für Teilaufgaben wie
Dokumentationen, Kostenrechnung oder grafische Auswertungen gut eingesetzt werden.
Sollte der Einsatz von Standardsoftware gefordert sein, so kann dieser auch über
Integration in umfangreichen Projektmanagementsystemen erfolgen. [Schindler
et.al.1998]
Web Interface
Der Einsatz einer webbasierten Lösung oder eines ergänzenden Webinterfaces stellt
unter folgenden Voraussetzungen eine Anforderung an Projektmanagement Software dar:
Sobald die Notwendigkeit besteht, Projektmitarbeiter an verschiedenen und weit
entfernten Arbeitsstätten mit aktuellen Informationen versorgen zu müssen, wird der
Einsatz einer webbasierten Lösungen unumgänglich. Abgesehen von einem verbesserten
Informationsfluss ergeben sich Vorteile im geringeren Aufwand zur Software Installation,
geringeren Wartungskosten und der schnellen Verfügbarkeit des Systems. Die meisten
der gängigen Projektmanagement Systeme bieten die Möglichkeit, die Grundfunktionalität
um den Einsatz eines Webinterfaces zu erweitern. [Vandersluis 2000]
3.2 Spezielle Anforderungen im Software Design
Projektmanagement im Umfeld des Designs und der Entwicklung von Software
differenziert sich mitunter sehr deutlich zu anderen Produkten und Branchen. Es existiert
bei der Entwicklung von Software kein Produktionsprozess. Dadurch verlagern sich
Prozesse die normalerweise während der Produktion durchgeführt werden, wie
Fehlererkennung und –behebung oder Qualitätssicherung in die Entwicklung des
Produkts. Weiters entstehen andere Anforderungen durch den teilweise hohen
Komplexitätsgrad von Software. [Tomayko et.al. 1989]
Verstärkt findet der Einsatz von weltweit verteilten Projektteams in der
Softwareentwicklung statt um Know How für ein bestimmtes Projekt besser bündeln zu
Anforderungen an Projektmanagement Software
17
können. Dadurch muss durch die Projektmanagement Software der erhöhte
Kommunikations- und Informationsaufwand abgedeckt werden. [Tomayko et.al.1989]
Da Software-Development teuer und zeitaufwendig ist und gerade Software Projekte
geplante Kosten und Termine oft überschreiten, ist der Einsatz einer effizienten EDVUnterstützung unerlässlich. Wenn es während der Implementation von Software zu
Änderungen im Sourcecode kommt, müssen diese und deren Auswirkungen auf andere
Module über Changemanagement-Techniken der Projektmanagement Software verfolgt
werden können um Qualitätsrichtlinien zu erfüllen. Drei der wesentlichen Aufgaben von
Projektmanagement-Software, nicht nur in der Software-Entwicklung, sind somit
Kommunikation, Koordination und Zusammenarbeit. Diese drei Aufgaben werden in den
nachfolgenden Abschnitten näher erläutert. [Holz et.al. 1998]
Koordination
Der Koordinationsaufwand kann je nach Projektgröße, örtliche Verteilung der
Projektgruppen und Einbindung verschiedenster Spezialisten stark variieren. Eine der
wichtigsten Aufgaben in der Projektkoordination besteht im Verteilen von Informationen.
Um einen Informationsüberfluss bzw. eine Unterversorgung der Projektmitarbeiter zu
verhindern, ist es absolut notwendig, jedem die richtigen Informationen zum richtigen
Zeitpunkt zukommen zu lassen. Damit dieser Anforderung Rechnung getragen werden
kann, werden zu diesem Zweck oft Prozessmodelle verwendet. Aufgrund der
Repräsentation der Prozesse ist es dann möglich die richtigen Projektmitarbeiter zum
richtigen Zeitpunkt über Änderungen zu informieren. [Holz et.al. 1998]
Zusammenarbeit
Projektteams, denen es nicht möglich ist am selben Ort zusammenzuarbeiten, muss
Unterstützung durch Software Tools angeboten werden. Diese Unterstützung kann in
Form synchroner oder asynchroner Zusammenarbeit erfolgen. Synchron durch virtuelle
Diskussionsräume oder asynchron durch virtuelle Pinwände. Der Einsatz solcher Tools
kann durch die Integration bestehender Groupware Tools in Software Engineering Tools
erfolgen, oder durch die Erweiterung dieser Software Engineering Tools um Groupware
Funktionalität. [Holz et.al. 1998]
Kommunikation
Um Kommunikation effektiv unterstützen zu können, ist es notwendig verschiedenste
Datenformate und Fremdsystem zu unterstützen bzw. integrieren zu können. Diese
Aufgabe wird standardmäßig von Middleware Systemen übernommen. Eine weitere
wichtige Aufgabe dieser Middleware liegt darin, den Datenaustausch unterschiedlicher
Systeme zu unterstützen und damit die Daten überall verfügbar zu machen. [Holz et.al.]
Genau so ein Middleware System stellt der Hyperwave Information Server dar, der die
Anbindung verschiedenster Systeme ebenso ermöglicht, wie die Verwaltung von Daten in
fast allen gängigen Formaten.
Eine Unternehmensform, die in der Software Entwicklung immer häufiger zum Einsatz
kommt, ist das virtuellen Software-Unternehmen. In dieser Unternehmensform schließen
sich mehrere unabhängige Unternehmen mit verschiedenen Kernkompetenzen zu einem
virtuellen, zeitlich begrenzt zusammenarbeitenden Unternehmen zusammen. Diese
einzelnen Unternehmen können durchaus örtlich getrennt agieren, immer öfter setzten
Anforderungen an Projektmanagement Software
18
sich virtuelle Unternehmen aus weltweit verteilten Einzelfirmen zusammen. Die
Kernkompetenzen der Firmen können in ganz unterschiedlichen Unternehmensbereichen
liegen, von Kundenaquirierung bis hin zur eigentlichen Software Entwicklung. Ziel solcher
verteilten, virtuellen Unternehmen besteht darin, schneller auf Marktanforderungen
reagieren zu können ohne die Kernkompetenz oder die Ressourcen einem speziellen
Projekt anpassen zu müssen. [Kötting et.al.]
Neben den großen Vorteilen die virtuellen Unternehmen bieten, stellen sie auch
besondere Anforderungen an Projektmanagement Software. Da sich die Struktur des
virtuellen Unternehmens bei jedem neuen Projekt verändern kann, muss besonderer Wert
auf Flexibilität der Software gelegt werden. Aus diesem Grund können herkömmliche
Workflow Management Systeme nicht die notwendige Unterstützung bieten. Auch die in
diesem Unterkapitel beschriebenen Aufgaben im Bereich der Koordination und
Kommunikation müssen den speziellen Bedürfnissen angepasst werden. Ein flexibel
steuerbarer und dezentraler Datenzugriff mit einer entsprechenden Zugriffssteuerung und
ein ebenso flexibles Kommunikationssystem stellen die Kernpunkte dieser erweiterten
Anforderungen dar. [Kötting et.al.]
3.3 Anforderungen des IICM
Um Projektmanagement Software gezielt im Unternehmen einsetzen zu können, muss
diese an die spezielle Unternehmen- und Projektmanagementstruktur angepasst bzw.
dahingehend ausgewählt werden. Um im nächsten Kapitel bei der Evaluierung von am
Markt befindlichen Systemen eine Vorauswahl treffen und gezielt vorgehen zu können,
werden hier kurz die wichtigsten Kriterien behandelt die für das IICM relevant sind.
Die Organisationsstruktur des IICM gliedert sich in zwei Bereiche, einen universitären,
forschungsorientierten Bereich und einen kundennahen, erfolgsorientierten und
angewandte Forschung betreibenden Bereich. Dieser zweite Bereich ist in verschiedene
Sparten gegliedert. Für die Projektmanagementstruktur bedeutet das eine notwendige
Koordination von verteilten Projektteams und sehr unterschiedlichen Projekten. Aus
diesem Grund existiert eine zentrale Projektmanagement-Stelle, von der ausgehend
Aufgaben an die jeweiligen Teams verteilt werden.
Ausgehend von dieser Struktur ist es für das IICM notwendig, ein System einzusetzen,
welches Multiprojektmanagement unterstützt, zentrale und dezentrale Verwaltung zulässt
und Informationen an beliebigen Orten zur Verfügung stellen kann. Unterstützung für das
Projektmanagement am IICM soll auch im Bereich der Projektberichte geboten werden.
Diese sollen durch Mitglieder der einzelnen Teams dezentral erfasst und gewartet
werden, die Auswertung geschieht jedoch in der zentralen Projektmanagement Stelle.
Der Hyperwave Information Server, der am IICM entwickelt wurde und im
Gestaltungsbereich noch detaillierter beschrieben wird, stellt eine leistungsfähige
Möglichkeit dar Dokumente in den unterschiedlichsten Formaten zu verwalten. Im
weiteren Verlauf dieser Arbeit soll evaluiert werden, ob diese "Middleware" in Verbindung
mit einem Projektmanagement System eingesetzt werden kann. Dieser Einsatz würde
bestehende Technologie und vorhandenes Know How am IICM nutzen. Generell wichtige
Punkte für ein Software System wie Erweiterbarkeit, Mehrsprachigkeit, Flexibilität müssen
ebenfalls in die weiteren Überlegungen einbezogen werden.
Anforderungen an Projektmanagement Software
19
3.4 Zusammenfassung
Die Abdeckung der in diesem Kapitel gezeigten Anforderungen an ProjektmanagementSoftware, ob allgemeine Anforderungen, spezielle im Software-Design oder die
individuellen Anforderungen des IICM, kann auf unterschiedlichste Weise erfolgen. Ob
durch den Einsatz von Standardsoftware, großen Projektmanagement-Systemen oder
individuell gefertigten Einzellösungen: die Auswahl muss immer unter Berücksichtigung
der speziellen Unternehmenscharakteristika durchgeführt werden.
Die Unternehmenscharakteristika können durch Managementstrukturen bzw.
Projektabläufen im Unternehmen gebildet werden, ebenso werden sie durch
Unternehmensform, technische Infrastrukturen und Know How der Mitarbeiter bestimmt.
Im Falle eines Software entwickelnden Unternehmens, wie dem IICM, müssen zusätzliche
Anforderungen wie unter Abschnitt 3.2 und 3.3 beschrieben wurden, abgedeckt werden.
In Kapitel 4 sollen am Markt verfügbare Projektmanagement Systeme unter
Berücksichtigung der Anforderungen des IICM betrachtet und deren Einsatz für das IICM
evaluiert werden. Daraus hervorgehend soll dann ein Lösung- und Umsetzungskonzept in
Kapitel 5 erarbeitet werden.
Untersuchung vorhandener Systeme
20
4 Untersuchung vorhandener Systeme
Um für eine bestimmte Organisationseinheit, in diesem Fall das IICM, entscheiden zu
können ob die speziellen Bedürfnisse von Standardsoftware oder ProjektmanagementSystemen abgedeckt werden, ist es notwendig, einen Überblick über am Markt befindliche
Systeme zu gewinnen. Dieser Überblick soll in diesem Kapitel dargestellt werden. Eine
Auswahl interessanter Systeme soll kurz beschrieben und die Funktionalität dargestellt
werden, es werden auch mögliche Szenarien des Einsatzes am IICM beschrieben.
Aufbauend auf diese Erfahrungen kann dann in Kapitel 5 ein Konzept für das IICM
erarbeitet werden.
4.1 Allgemeine Betrachtungen
Durch die große Anzahl am Markt befindlichen Projektmanagement Systemen ist es
notwendig eine Vorauswahl zu treffen. Aufgrund der beschriebenen Anforderungen
werden hier nur Systeme betrachtet, welche entweder Web-basiert sind oder das
Publizieren von Information im Intra- und Internet unterstützen. Trotz dieser
Einschränkung ist es im Rahmen dieser Arbeit nur möglich einen kleinen Überblick über
vorhandene Systeme zu geben bzw. kann nur eine kleine Anzahl betrachtet und evaluiert
werden.
Damit die verschiedenen Systeme verglichen und für das IICM bewertet werden können,
sollen folgende Kriterien untersucht und im Abschluss verglichen werden:




Allgemeine Beschreibung des Systems
Funktionalität
Systemvoraussetzungen
Integrationsfähigkeit am IICM
4.2 Microsoft Project 2000 - Microsoft Project Central
Eines der am meisten eingesetzten Systeme und deshalb auch das erste betrachtete ist
Microsoft Project1. Die hier untersuchte Version ist Project 2000. Ausgehend von den
Anforderungen des IICM wird hier der Web basierender Teil Microsoft Project Central
evaluiert.
4.2.1 Allgemeine Beschreibung
Mit der Version MS Project 2000 wurde ein neuer, Web basierender Teil dieses
Softwarepaketes vorgestellt, Microsoft Project Central. Durch diese Erweiterung zu
Project 2000 sollen Projekt relevante Daten einfacher und schneller allen Projektteam
Mitgliedern zur Verfügung gestellt und die Kommunikation im Team verbessert werden.
[Microsoft 2000a]
Microsoft Project 2000 – Microsoft Project Central unter
http://www.microsoft.com/office/previous/project/2000tour
1
Untersuchung vorhandener Systeme
21
4.2.2 Funktionalität
Da für diese Arbeit in erster Linie der Web-basierte Teil von Microsoft Project 2000
interessant ist, werden hier ausschließlich Funktionalitäten von Microsoft Project Central
beschrieben.
4.2.2.1 Persönliche Aufgaben und Gant Charts
Teammitglieder der verschiedenen Projekte können ihre eigenen Aufgaben zusätzlich
grafisch als Gant Chart darstellen lassen, wobei diese Darstellung gefiltert, sortiert und
verschieden angeordnet werden kann. Diese Ansicht, wie in Abbildung 5 dargestellt kann
zusätzlich um Aufgaben aus MS Outlook erweitert werden.
Abbildung 5: Persönliche Aufgaben und Gant Chart [Microsoft 200b]
Diese Verwaltung der persönlichen Aufgaben umfasst zusätzliche Funktionalitäten wie
das Einfügen neuer Aufgaben (diese werden erst nach Freigabe durch einen
übergeordneten Projektmanager tatsächlich eingefügt), das Delegieren von Aufgaben an
andere Teammitglieder, die Anzeige von Urlaubs- oder Freizeit und eine Steuerung
welchen Teammitgliedern welche Funktionalität zur Verfügung steht. [Microsoft 2000b]
4.2.2.2 Timesheet
Über die Timesheet-Funktionalität, wie in Abbildung 6 dargestellt, können wichtige
Projektinformationen, wie Arbeitsstunden, prozentueller Anteil der Fertigstellung und
individuelle Projektinformationen durch Team Mitglieder aktualisiert werden.
Untersuchung vorhandener Systeme
22
Abbildung 6: Timesheet [Microsoft 2000b]
Die Darstellung dieser Informationen kann ähnlich den persönlichen Aufgaben gruppiert,
gefiltert und nach verschiedenen Kriterien sortiert werden. Wird die Arbeitszeit für eine
bestimmte Aufgabe aktualisiert, werden die verbleibenden Arbeitsstunden automatisch
verringert. Die Darstellung der Arbeitszeit und der verbleibenden Zeit kann je nach
Notwendigkeit von Projektebene bis Aufgabenebene detailliert werden. Diese Zeiten
können dann direkt via MS Project Central an den Projektmanager gesendet werden.
[Microsoft 2000b]
4.2.2.3 Status Reports
Microsoft Project Central unterstützt die Erfassung und Verwaltung von textuellen StatusReports, die in beliebige Teile gegliedert werden können. Diese Reports können
regelmäßig oder individuell angefordert werden und mit oder ohne Korrektur des
Projektmanagers zu einem Gruppenreport zusammengefasst werden. [Microsoft 2000b]
Abbildung 7: Status Report [Microsoft 2000b]
Untersuchung vorhandener Systeme
23
Wie in Abbildung 7 ersichtlich handelt es sich dabei um einfache Textdokumente, die
einen Überblick des Projektstandes zu einem Stichtag geben sollen. Fällige, bzw.
überfällige Status Reports werden den jeweiligen Team Mitgliedern mit grafischen
Indikatoren angezeigt. [Microsoft 2000b]
4.2.2.4 Adminitrations Modul
Dieses Modul von MS Project Central ermöglicht es dem Projektmanager administrative
Tätigkeiten, wie Benutzerverwaltung, Datenbankwartung und die Verwaltung von
Zugriffsrechten vorzunehmen. Weiters ist Customizing möglich, das Aussehen und
spezielle Kategorien wie Urlaubszeit, Krankheit oder nicht arbeitsrelevante Zeit, können
damit angepasst werden. [Microsoft 200b]
Das Erscheinungsbild von Gant-Charts und Meilenstein-Trend-Diagrammen kann hier
ebenfalls beeinflusst werden. Beinhaltet ist ebenfalls Securitymanagement und BenutzerRollen-Verwaltung, mit der einzelnen Benutzern oder Rollen Funktionen und Sichten auf
verschiedene Projekte und Projektdaten zugeordnet werden können. [Microsoft 200b]
Folgende drei Rollen werden standardmäßig unterstützt, können jedoch beliebig erweitert
werden: [Microsoft 200b]
Rolle
Administrator
Manager
Team Mitglied
Rechte
Wartung und Customizing der Site, Security Management, Rollenvergabe,
Zugriff auf alle Projekte und Projektdaten
Aufgabenzuordnung, Arbeitsstunden Kontrolle, Definition von Status Reports,
Ansicht der Projekteinstellungen
Ansicht der Aufgaben, Wartung der erledigten Arbeit, Ausfüllen von Status
Reports, Ansicht aller Projekte mit zugeordneten Aufgaben
4.2.2.5 Zusatzfunktionen
Über so genannte "Views" können im Überblick Daten einzelner Projekte, einer Gruppe
von Projekten oder Ressourcen dargestellt werden. Teammitglieder, welche nicht immer
online mit dem System verbunden sind, können ihre persönlichen Gant-Charts betrachten
oder ihre Timesheets und Status Reports bearbeiten. Diese lassen sich dann im System
updaten.
4.2.3 Systemvoraussetzungen
Um Microsoft Project Central betreiben zu können, ist der MS Information Server ab
Version 4.0 notwendig, da Project Central auf der ASP-Technologie basiert. Zusätzlich
wird ein Datenbankserver benötigt, unterstützt werden Oracle, MS SQL Server und
Microsoft Database Engine (MSDE). Als Client kann der Internet Explorer ab Version 4.x
eingesetzt werden. [Microsoft 2000b]
Um Project Central einsetzten zu können, muss für jeden der auf den Project Central
Server zugreift, eine Lizenz erworben werden. Wird als Datenbank Server z.B. der MS
SQL Server verwendet müssen hierfür noch für jeden Benutzer eine CAL (Client Access
Lizenz) erworben werden. [Microsoft 2000b]
Untersuchung vorhandener Systeme
24
4.2.4 Integrationsfähigkeit am IICM
Generell für den Einsatz von Microsoft Project Central sprechen die etablierte Stellung
dieses Systems am Markt, eine ausgereifte Konzeption und umfangreiche Features. Im
Bezug auf eine Integration am IICM muss jedoch berücksichtigt werden, dass dieses
System auf einer anderen Plattform betrieben werden muss als am IICM üblich. Daraus
würde sich ein erhöhter Administrationsaufwand ergeben. Durch die Einführung dieses
Systems am IICM würde auch kein Investitionsschutz für bereits bestehende Infrastruktur
wie den Hyperwave Information Server bestehen.
So positiv die vielen Features von Microsoft Project Central zu sehen sind, stellen sie
jedoch Benutzer vor das Problem eines "überladenen" Systems. Dies hat zur Folge das
Übersichtlichkeit und intuitive Verwendung des Systems verloren gehen. Weiters kritisch
zu sehen ist die Notwendigkeit einer Lizenz für jeden Benutzer der auf das System
zugreift, da sich die Anzahl der Benutzer eines IICM Projektmanagement Systems laufend
ändert.
4.3 Enact Enterprise System 5.0
Enact Enterprise System 5.0 2 stellt eine Web-basierende Lösung für unternehmensweites
Projektmanagement und Zusammenarbeit dar. Dieses einfach zu bedienende System
wurde bereits weltweit öfter als zweihundertmal bei Unternehmen der verschiedensten
Branchen installiert. [Enact 2000]
4.3.1 Allgemeine Beschreibung
Aufgrund der einfachen Bedienung, verbesserten Kommunikation und Real Time
Abbildung von Projektdaten und des Projektstatus soll der Projekterfolg und das ROI
(Return Of Investment) laut Herstellerangaben gesteigert werden. [Enact 2000]
Viele traditionelle bzw. herkömmliche Projektmanagement Systeme gehen von statischen
Vorgaben wie fixen Budgets, idealen Kontrollsystemen und willkürlichen Metriken aus. Um
dem dynamischen Verlauf heutiger Projekte Rechnung zu tragen, versucht Enact
flexiblere Methoden anzubieten. [Enact 2000]
In realen Projekten werden Ziele nach hinten verschoben, Budgets überschritten und
Deadlines aufgrund von kurzfristigen Entscheidungen korrigiert. Hier bietet Enact
verbesserte Möglichkeiten durch Real Time Projektstatus, einem Frühwarnsystem und
sofortiger Übernahme und Darstellung von Änderungen. Außerdem versucht Enact den
Projektmanager in kritischen Projektsituationen durch Hilfestellungen in der
Entscheidungsfindung und durch effektive Informationsverteilung an die entsprechenden
Teammitglieder zu unterstützen. [Enact 2000]
2
Enact Enterprise System 5.0 – http://www.enact.com
Untersuchung vorhandener Systeme
25
Abbildung 8: Enact System Architektur [Enact 2000]
Das Enact Enterprise System 5.0 besteht, wie in Abbildung 8 dargestellt, aus dem Enact
Collaboration Server und den drei Client-Hauptkomponenten ActionPlan, ActionTask und
ActionView, welche nachfolgend noch genauer beschrieben werden. [Enact 2000]
4.3.2 Funktionalität
4.3.2.1 ActionPlan
Die clientseitige Komponente ActionPlan (wie in Abbildung 9 dargestellt) von Enact
Enterprise System 5.0 stellt die Hauptfunktionalität für die Projektplanung, wie das
Erstellen, Bearbeiten und Löschen von Plänen, Aufgaben und Usern zur Verfügung.
Abbildung 9: Enact ActionPlan [Enact 2000]
Untersuchung vorhandener Systeme
26
Weiters können Ressourcen verwaltet und den einzelnen Projekten zugeordnet werden.
Um die Informationsversorgung im Projekt zu gewährleisten können Dateien
verschiedenster Formate an Projekte "angehängt" werden. Die Erstellung von ProjektTemplates und persönlichen Szenarien wird ebenfalls unterstützt. [Enact 2000]
4.3.2.2 ActionTask
Diese Komponente ermöglicht das Erstellen und Bearbeiten von Aufgabenlisten.
Verschiedene Aufgabenlisten können vom Projektleiter an bestimmte Team Mitglieder
gesendet werden, nach dem Update durch diese Mitarbeiter stehen die aktuellen
Informationen dann allen zur Verfügung. [Enact 2000]
Abbildung 10: Enact ActionTask [Enact 2000]
Zu jeder Aufgabe kann ein persönlicher Arbeitskalender und Email-Erinnerungsdienst
sowie Gruppennotizen eingerichtet werden. Weiters besteht die Möglichkeit
Aufgabenlisten mit einem Palm OS Handheld zu synchronisieren. [Enact 2000]
4.3.2.3 ActionView
Um eine gute und auf einzelne Funktionen im Projekt abgestimmte Ansicht über wichtige
Projektstatusinformationen geben zu können, wurde die dritte Komponente in Enact
Untersuchung vorhandener Systeme
27
Enterprise System 5.0 entwickelt (Abbildung 11). Vom Projektleiter können diese
Ansichten individuell angepasst werden. Dargestellt werden können alle projektrelevanten
Daten wie Projektstatus, Budgetinformationen oder Projekt Meilensteine. [Enact 2000]
Abbildung 11: Enact ActionView [Enact 2000]
In der Detailansicht dieser Viewpoints besteht zusätzlich die Möglichkeit Links zu
wichtigen Dokumenten, URL's oder Email Adressen und Detailinformation zum Projekt
einzufügen. [Enact 2000]
4.3.2.4 ActionAdmin
Für folgende administrative Tätigkeiten wird die Komponente ActionAdmin (siehe
Abbildung 12) benötigt: Erstellen, Editieren und Löschen von Usern Accounts, User
Attributen, Gruppen, Organisationen und User Rollen. [Enact 2000]
Untersuchung vorhandener Systeme
28
Abbildung 12: Enact ActionAdmin [Enact 2000]
4.3.2.5 Zusätzliche Features
Enact Enterprise System 5.0 bietet Unterstützung für mehrere Sprachen, Text,
Währungen und Datum werden korrekt dargestellt, bei Berechnungen werden diese
Einstellungen ebenfalls berücksichtigt. Reports, die durch ViewPoints und ActionView
automatisch upgedated werden, können von Benutzern erstellt werden. Diese Reports
lassen sich auch beliebig zusammensetzen, da sich die Daten aus dem Enact Repository
mittels SQL-Statements selektieren lassen. [Enact UG]
Imports und Exports können in Standardformate wie MPX3- und MPD4-Dateien
durchgeführt werden. Um die Projekterstellung zu erleichtern, lassen sich Templates
erstellen. Die Userverwaltung wird durch ein rollenbasiertes System erleichtert. Enact
Enterprise System 5.0 läst sich durch gut dokumentierte API's an spezielle Bedürfnisse
anpassen, ebenso lassen sich dadurch einfach bestehende Daten importieren.
3
Beschreibung des MPX-Dateiformats unter
http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/
Q270/1/39.ASP&NoWebContent=1
4 MPD-Dateiformat „Microsoft Project Database File“
Untersuchung vorhandener Systeme
29
4.3.3 Systemvoraussetzungen
Der Enact Collaboration Server, die Java basierte Kernkomponente des Enact Enterprise
System 5.0, kann wahlweise unter Microsoft Windows NT 4 oder Sun Solaris 2.6 / 2.7
installiert werden. Unterstützte Web Server sind Microsoft IIS 4.0, Netscape IPlanet 3.0 /
4.0 und Apache 1.x unter Solaris. Diese Versionen stellen jeweils die
Mindestanforderungen dar, die Installation kann natürlich unter höheren Versionen
erfolgen. [Enact 2000]
Als Datenbank Server werden Oracle 8.0.5 / 8.1.6, Microsoft SQL Server 7.0 oder eine
Enact interne Datenbank (File) unterstützt. Um Enact User nicht neu anlegen zu müssen,
kann im Hintergrund ein LDAP Server, wie der Netscape Directory Server 4.0 / 4.0.1, der
Eudora WorldMail Directory Server oder University of Michigan LDAP Server, eingesetzt
werden. Für den Betrieb von Enact Enterprise System 5.0 wird weiters Perl 5.003 und ein
SMTP Email System benötigt. [Enact 2000]
Clientseitig stehen als Browser Microsoft Internet Explorer ab Version 4.0, Netscape
Navigator ab Version 4.5 zur Verfügung. Um Dokumente aus Enact drucken zu können,
muß der Adobe Acrobat Reader installiert sein. [Enact 2000]
4.3.4 Integrationsfähigkeit am IICM
Positiv stellt sich die Funktionsvielfalt des Produkts dar, nicht enthaltene Funktionalität
könnte recht einfach durch das IICM über sogenannte Enactors, welche
Systemerweiterungen
mittels
Java
API
darstellen,
durchgeführt
werden.
Dementsprechendes Java Know How wäre am IICM vorhanden.
Da dieses System in Java umgesetzt ist und verschiedene Plattformen unterstützt, sollte
eine Installation am IICM problemlos möglich sein. Ein durch Enact unterstütztes
Datenbanksystem wäre ebenfalls am IICM vorhanden.
Dem gegenüber steht wie bei Microsoft Project Central der fehlende Investitionsschutz für
bestehende und akzeptierte Systeme wie den Hyperwave Information Server. Zusätzlich
wäre ein gewisser Anpassungsaufwand nötig um den geforderten Funktionsumfang für
das IICM bereitstellen zu können.
4.4 Celoxis
Das Celoxis System 5 der Firma Celoxis Technologies Pvt. Ltd. stellt eine rein Webbasierte Lösung für vielfältige Aufgaben im Unternehmen dar. Obwohl hauptsächlich
Unterstützung für Projektmanagement angeboten wird, bietet dieses System noch
Dokumentenmanagement-, Kalender- und Aufgabenlisten-Funktionen an.
5
Celoxis – http://www.celoxis.com
Untersuchung vorhandener Systeme
30
4.4.1 Allgemeine Beschreibung
Entwickelt wurde dieses System, um Unternehmen mit geographisch verteilten Teams
Möglichkeiten der Zusammenarbeit, eines Dokumentenmanagement Systems und
anderer notwendiger Funktionen zu bieten. [Celoxis 2000a]
4.4.2 Funktionalität
Celoxis bietet folgende Unterstützung im Bereich des Projektmanagements, welche durch
die web basierte Systemarchitektur von überall zugänglich ist. Angeboten werden:
[Celoxis 2000b]











Aufgaben, Subaufgaben und Meilensteine mit Eigentümer und Deadline
Gant Charts
Frei konfigurierbare Felder für Projekte
Kosten und Deadline Kontrolle
Einstellmöglichkeit für Arbeits- und Urlaubzeiten
Rollen basierte Userverwaltung und Berechtigungen
Emailverständigungen
Projekt Ordner, Foren und Kosteneinstellungen
Konfigurierbarer Kundenzugang
Projektarchivierung
Volltext Suche
Im Rahmen dieses Kapitels werden Projektverwaltung, Ressourcen Verwaltung, die
persönliche Startseite (myHome), die Kundenliste und die zusätzliche Features von
Celoxis untersucht.
4.4.2.1 Persönliche Startseite (myHome)
Wie in Abbildung 13 ersichtlich, stellt Celoxis myHome eine zentrale Einstiegs- und
Übersichtsseite für das Celoxis System dar. Hier wird ein Überblick über alle Projekte,
Aufgaben (in Abbildung 13 als Tasks bezeichnet), Events und Foren gegeben. Sollte der
Benutzer über Administratorrechte verfügen, werden ebenfalls Links für administrative
Tätigkeiten, wie Benutzerverwaltung und Systemeinstellungen angezeigt.
Über die dementsprechenden Links kann sofort zu detaillierten Informationen eines
Projektes (siehe nächster Abschnitt Projektverwaltung) bzw. einer Aufgabe gewechselt
werden. Weiters können direkt Emails an Personen eines Projektes gesandt,
Detailinformationen dieser Personen abgerufen und neue Projekte hinzugefügt werden.
Untersuchung vorhandener Systeme
31
Abbildung 13: Celoxis myHome [Celoxis OD]
4.4.2.2 Projektverwaltung
In der Ansicht Projektverwaltung (Detaildaten eines Projektes) werden alle
projektrelevanten Daten, wie Status, Kunde, Rechnungsdaten, zugehörige Aufgaben und
der Projekt Gant Chart abgebildet.
Weitere Detailinformationen des Projekts werden direkt verlinkt, über Schaltflächen kann
in den Edit Modus gewechselt, das Projektforum aufgerufen und der Projektordner
angezeigt werden. Der Projektordner stellt eine einfache Möglichkeit dar, um beliebige
Dokumente, Links oder andere relevante Informationen zum Projekt abzuspeichern. Diese
Zusatzdaten können von allen Projektmitarbeitern eingesehen und verwendet werden,
damit stellen diese Projektordner ein Projekt-Archiv dar.
Untersuchung vorhandener Systeme
32
Abbildung 14: Celoxis Projektverwaltung [Celoxis OD]
4.4.2.3 Ressourcen Verwaltung
Über die Ressourcen Verwaltung kann die Auslastung jedes einzelnen Projektmitarbeiters
verfolgt werden. Angezeigt werden, wie in Abbildung 15 gezeigt, Verfügbarkeit, Kapazität
und Auslastung. Über Links können die Projekte und Aufgaben des jeweiligen Mitarbeiters
aufgerufen werden.
Die Änderung der Auslastung bzw. Verfügbarkeit erfolgt über die Zuordnung von
Arbeitsstunden in den einzelnen Aufgaben. Diese können entweder direkt oder über die
Projekte geöffnet werden. Zusätzlich kann die tägliche Auslastung als Diagramm über den
Link "Daily Breakup" angezeigt werden.
Untersuchung vorhandener Systeme
33
Abbildung 15: Celoxis Ressourcen Verwaltung [Celoxis OD]
4.4.2.4 Kundenliste
Diese Liste liefert einen Überblick über alle relevanten Kunden zum aktiven Benutzer.
Auch von hier aus kann direkt zur Editieransicht, den Kundenprojekten, -ordnern und zur
Kontakthistorie gewechselt werden. Wie in Abbildung 16 ersichtlich besteht auch die
Möglichkeit dem Kunden direkt eine Email-Nachricht zu senden.
Abbildung 16: Celoxis Kundenverwaltung [Celoxis OD]
Untersuchung vorhandener Systeme
34
4.4.2.5 Zusätzliche Features
Das Celoxis System bietet vielfältige Funktionalitäten an, die über die Funktion eines
reinen Projektmanagement-Tools hinausgehen. Zusätzlich verfügt das System über
Features wie Telefonanruf, Verwaltung, Aufgabenlisten, Dokumentenmanagement,
Adressen- und Kundenverwaltung, Kalender, Foren, Suche, Ressourcen Management,
Zeit- und Kostenüberwachung und verschiedene Reporting-Möglichkeiten.
4.4.3 Systemvoraussetzungen
Celoxis bietet das System in erster Linie als Applikation Service Provider (ASP) Produkt
an. Diese Variante garantiert minimalen Aufwand im Unternehmen und keine
Notwendigkeit der Anschaffung und Wartung der Hardware und Anwendung. Bei den
entstehenden Kosten handelt es sich um laufende Kosten für den Betrieb der
Anwendung. Investitionskosten fallen nur in geringem Ausmaß bei notwendigen
Anpassungen an.
Eine weitere Möglichkeit stellt die Lizenzierung auf Produktbasis dar. Hier wird das
Celoxis-System im Unternehmen eingerichtet und betrieben. Der größere Aufwand für die
Installation und den Betrieb wird durch größere Flexibilität ausgeglichen. Als Datenbank
werden der MS SQL Server 2000, Oracle 9i oder Postgresql 7.2.3 unterstützt. Da von
Seiten des Java Application Servers lediglich Java 1.3 und ein Servletcontainer
vorausgesetzt wird, lässt sich das Celoxis System auf nahezu allen Betriebssystemen
installieren. Clientseitig kann der MS Internet Explorer ab Version 5.5, Netscape ab
Version 6.2 oder Opera ab Version 6.0 eingesetzt werden.
4.4.4 Integrationsfähigkeit am IICM
Betrachtet man die beiden Betriebsvarianten des Celoxis Systems, stellen sich mehrere
Fragen bezüglich der Integrationsfähigkeit. Wird das System bei der Firma Celoxis
betrieben, wird IICM internes Know How und vorhandene Hardware nicht genutzt. Der
Vorteil liegt wie im letzten Abschnitt bereits erwähnt im geringen Aufwand für das
Unternehmen. Aus Gründen des Investitionschutzes (vorhandene Systeme, Know How)
ist diese Variante aber zu hinterfragen.
Die zweite Betriebsvariante, die Installation und der Betrieb am IICM sollten keine
größeren Probleme aufwerfen. Ein Java Application Server und eines der beschriebenen
Datenbank System wären am IICM vorhanden. Ob und in welcher Form eine Integration
mit dem Hyperwave Information Server möglich ist, müsste noch analysiert werden.
4.5 PHPProjekt
Alle bisher betrachteten Tools stellen kommerzielle Systeme dar und werden von
Unternehmen entwickelt und vertrieben. Im Gegensatz zu dieser Art von Software, gibt es
eine immer mehr Software die frei erhältlich ist. Diese Open Source Software wird von
Untersuchung vorhandener Systeme
35
einer Community entwickelt und kann ohne Entrichtung einer Lizenzgebühr genutzt und
weiterentwickelt werden. Durch den Einsatz von Open Source Software können
Investitionskosten vermieden und die Flexibilität durch eigene Anpassungen gesteigert
werden. Einschränkend erweist sich aber der geringe Support, der oft nur aus
Newsgroups und Foren im Internet besteht.
Das erste betrachtete System aus der Open Source Familie ist PHPProjekt6, eine Open
Source Groupware Suite. Die vorliegende Version ist 3.3 vom Juli 2002.
4.5.1 Allgemeine Beschreibung
PHPProjekt ist eine Groupware Suite, also Software die es den Benutzern ermöglichen
soll, Informationen und Daten auszutauschen und gemeinsam Planungen durchzuführen.
PHPProjekt wird unter der GPL Open Source Lizenz7 entwickelt und kann somit frei
verwendet, kopiert, verändert und weitergegeben werden. Alle Informationen zu diesem
System, Bugfixes, Newesletter und verschiedene Foren können auf der Projekthomepage
unter www.phpprojekt.com nachgelesen werden. [PHPProjekt 2002]
4.5.2 Funktionalität
Zusätzlich zu den grundlegenden Funktionalitäten, die für die Verwaltung von Projekten
benötigt und in den nachfolgenden Abschnitten beschrieben werden, bietet diese Open
Source Lösung folgende Möglichkeiten: [PHPProjekt 2002]







Modularer Aufbau
Mehrstufige Privilegienvergabe, Gruppensystem
Sprachendatei für 25 Sprachen
Anpassung an das eigene Corporate Design
Unterstützt 5 Datenbanksysteme und LDAP Zugriff
Dialoggeführte Installation, Update und Konfiguration
API zum Einfügen eigener Module
Damit ist es auch möglich, das System an die individuellen Bedürfnisse und Vorstellungen
anzupassen.
4.5.2.1 Projekte
Obwohl die Projektverwaltung nur ein Modul dieser Groupware darstellt, bietet sie
umfangreiche Funktionen um Projekte verwalten zu können. In der Hauptansicht
„Projekte“ werden wie in Abbildung 17 ersichtlich alle wichtigen Projektinformationen zu
den Projekten des aktiven Benutzers angezeigt:
6
7
PHPProjekt – http://www.phpprojekt.com
GPL weiterführende Informationen – http://www.gnu.org/copyleft/gpl.html
Untersuchung vorhandener Systeme
36
Abbildung 17: Hauptansicht Projekte in PHPProjekt. [PHPProjekt 2002]
Ist der aktive Benutzer der Gruppe „Chef“ zugeordnet, werden zusätzlich die Spalten
„Budget“, „Stundensatz“ und „bereits gebucht“ angezeigt. Sollte der Wert der gebuchten
Stunden (also das Produkt aus der Summe der gebuchten Stunden mal dem Stundesatz
dieses Projekts) das kalkulierte Budget übersteigen, so wird die Zahl rot dargestellt. Neue
Hauptprojekte können nur von Benutzern der Gruppe „Chef“ angelegt werden,
Unterprojekte zu bestehenden Hauptprojekten auch vom jeweiligen Projektleiter.
[PHPProjekt 2002]
Über das in Abbildung 18 dargestellt Projektformular können die Projektdetails betrachtet
bzw. geändert werden. Unterhalb des Formulars werden alle Notizen und alle Dateien, die
diesem Projekt zugewiesen sind, aufgelistet. Diese Übersicht dient unter anderem einer
'Projekthistorie'. Über einen Klick auf den Namen wird die Notiz aufgerufen bzw. die Datei
heruntergeladen.
Abbildung 18: Projektformular in PHPProjekt [PHPProjekt 2002]
Untersuchung vorhandener Systeme
37
4.5.2.2 Projektstatistik und Zeitverwaltung
Benutzern der Gruppe „Chef“ stehen zusätzlich verschiedene Statistiken zur Verfügung.
Angeboten werden Statistiken über gebuchte Zeiten von Mitarbeitern pro Projekt und
Gant-Charts mit Haupt- und Unterprojekten.
Über die Funktion Zeiterfassung, welche in Abschnitt 4.5.2.3 näher erläutert wird, können
Mitarbeiter ihre Arbeitszeiten verbuchen und diese auch den verschiedenen Projekten
zuordnen. Diese Zuordnung ist nur auf Projekte, bei denen der jeweilige Mitarbeiter
eingetragen ist, möglich. [PHPProjekt 2002]
4.5.2.3 Zeiterfassung
Alle notwendigen Tätigkeiten von Mitarbeitern zur Verwaltung der Arbeitszeit werden
ebenfalls unterstützt. Es kann sowohl die tägliche Arbeitszeit „gebucht“ werden, als auch
die Arbeitszeit verschiedenen Projekten zugewiesen werden. In der Listenansicht der
Zeiterfassung werden die Arbeitszeiten des laufenden Monats dargestellt, bzw. nach
vorheriger Auswahl auch die Buchungsdetails der einzelnen Arbeitstage. Inkonsistente
Einträge, z.B. fehlende Abmeldungen werden farblich markiert und können nachträglich
korrigiert werden. [PHPProjekt 2002]
Die tägliche Arbeitszeit kann einzelnen Projekten zugeordnet werden, Vorraussetzungen
dafür sind:




Das Projekt läuft aktuell
Anfangs- und Endzeit des Projekts schließen den selektierten Tag ein
Der betreffende Mitarbeiter ist Teilnehmer des Projektes
Es existiert ein Eintrag für diesen Tag auf der Zeitkarte
Abbildung 19: Zuweisen von Arbeitszeit auf verschiedene Projekte [PHPProjekt 2002]
Untersuchung vorhandener Systeme
38
Wie in Abbildung 19 ersichtlich, kann zusätzlich zu den Stunden und Minuten, die auf das
ausgewählte Projekt verwendet wurden, eine Bemerkung zu dieser Arbeitseinheit
vermerkt werden. Eine Übersicht aller Projekt-Arbeitszeiten kann im Projektmodul
abgerufen werden, sofern der Benutzer zur Gruppe „Chef“ oder „Projektleiter“ gehört.
[PHPProjekt 2002]
4.5.2.4 Terminkalender
Das Terminkalender-Modul von PHPProjekt bietet alle wichtigen Funktionen zum
Verwalten und Koordinieren von Terminen. Neben den Standardfunktionen, wie in
Abbildung 20 ersichtlich, können Termine Projekten zugeordnet und Ressourcen gebucht
werden. Weiters ist es möglich die Sichtbarkeit des Termins auf bestimmte
Benutzergruppen zu beschränken und Serientermine anzulegen.
Abbildung 20: Erweiterter Terminkalender [PHPProjekt 2002]
Zusätzlich zu den beschriebenen Funktionen bietet PHPProjekt noch ein Helpdesk-Modul,
mit dem Kundenanfragen bearbeitet und verwaltet werden können, einen Kontaktmanager
zur Verwaltung von internen und externen Kontakten und Gruppeninformationen, einen
integrierten Email-Client, ein Forum-Modul, Todo-Listen und eine eingebaute ChatFunktion.
4.5.3 Systemvoraussetzungen
PHProjekt wurde in der Skriptsprache PHP 4 entwickelt und unterstützt die Datenbanken
MySQL, Postgres, Oracle, Informix und MS-SQL. Durch die Verwendung von PHP ist
Untersuchung vorhandener Systeme
39
PHPProjekt solange plattformunabhängig, solange für die verwendete Plattform ein
Webserver mit PHP-Parser vorhanden ist. Als Betriebssysteme kommen daher z.B.
Windows, verschiedene Linuxvarianten und viele Unixderivate in Frage.
Auf der Client-Seite werden keine besonderen Anforderungen an den Browser des
Benutzers gestellt. Es ist lediglich notwendig, dass der Browser framefähig ist und
Javascript unterstützt. Für die Installation stellt PHPProjekt Skripte bereit, die eine
unkomplizierte und rasche Installation des Systems ermöglichen.
4.5.4 Integrationsfähigkeit am IICM
Durch die weite Verbreitung von PHP sollte es prinzipiell kein Problem darstellen,
PHPProjekt zu integrieren. Da am IICM sowohl Windows als auch verschiedene
Unixderivate im Einsatz sind, stellt die Verfügbarkeit geeigneter Hardware mit
entsprechendem Betriebssystem kein Problem dar.
Fraglich bezüglich Integrationsfähigkeit ist, ob am IICM genügend PHP Know How
vorhanden ist. Da es sich bei PHPProjekt um Open Source Software handelt, müssten
auftretende Fehler unter Umständen selbst behoben werden. Ebenso wäre es notwendige
Erweiterungen selbst umzusetzen oder extern zu beauftragen, was sich als problematisch
erweisen könnte, da es vermutlich wenige Unternehmen gibt, die Know How im Bereich
von PHPProjekt haben.
4.6 TUTOS
Dieses System gehört ebenso wie PHPProjekt zur Gruppe der Open Source Lösungen.
Es darf gratis eingesetzt werden, der Sourcecode ist öffentlich verfügbar und es kann den
eigenen Wünschen und Bedürfnissen angepasst werden. TUTOS 8 steht für "The Ultimate
Team Organisation Software" und soll die Teamarbeit und die Abwicklung von Projekten
auf einer breiten Ebene unterstützen.
4.6.1 Allgemeine Beschreibung
Ursprünglich wurde TUTOS entwickelt um Unterstützung bei der Entwicklung, Wartung
und der Installation von Software zu bieten. Diese Funktionalität wurde dann sukzessive
um Groupware-Funktionen weiterentwickelt. Zusätzlich zu den umfangreichen
Funktionen, die im anschließenden Abschnitt erläutert werden, ist auch eine umfangreiche
Dokumentation für User, Administratoren und Programmierer verfügbar.
4.6.2 Funktionalität
TUTOS wurde in den Anfängen für ein deutsches Unternehmen entwickelt, um diesem
einen besseren Überblick über vorhandene Softwareprodukte, Kunden und deren
Software-Installationen zu geben. Zusätzlich sollte internes Qualitätsmanagement
unterstützt werden. Die von TUTOS angebotenen Funktionen decken zum einen den
8
TUTOS - www.tutos.org
Untersuchung vorhandener Systeme
40
Aufgabenbereich im Projektmanagement ab, zum anderen werden Groupware Aufgaben
erfüllt.
4.6.2.1 Persönliche Startseite – myTutos
Meldet man sich am TUTOS-Sytem mit Usernamen und Passwort an, so gelangt man zur
Persönlichen Startseite. Dort wird ein Überblick über alle wichtigen Informationen, die den
jeweiligen Benutzer betreffen, angezeigt. Wie in Abbildung 21 ersichtlich, werden hier die
aktuellen Kalendereinträge, Produkte bzw. Projekte, Dokumente, Nachrichten und
Einträge der Supportdatenbank angezeigt. Die Zusammenstellung der Informationen auf
myTutos kann vom Benutzer über die Benutzervorgaben beliebig verändert und
angepasst werden. [TUTOS 2002]
Abbildung 21: Persönliche Startseite - myTutos [TUTOS 2002]
4.6.2.2 Projektverwaltung
Die Projektverwaltung im TUTOS-System findet man unter dem Menüpunkt „Produkte &
Projekte“. In erster Linie wurde TUTOS zur Verwaltung von Projekten entwickelt, dieselbe
Untersuchung vorhandener Systeme
41
Funktionalität lässt sich aber auch für die Verwaltung von Produkten verwenden. Über
eine einfache bzw. erweiterte Suchfunktion wird eine Liste der zutreffenden Projekte
angezeigt, die angezeigten Projektattribute dieser Liste können vom Benutzer beliebig
verändert werden. Die Detailanzeige eines Projektes liefert das in Abbildung 22
dargestellte Ergebnis.
Abbildung 22: TUTOS Projektansicht [TUTOS 2002]
Zusätzlich zu den Standardinformationen kann noch eine Beziehung zu einem anderen
Projekt hergestellt werden, als Subprojekt, Teilprojekt oder Hauptprojekt. Auch
Informationen über den aktuellen Projektstatus und die Projektklassifikation werden, wie
in Abbildung 23 gezeigt, gut dargestellt. Zu den Standardinformationen, die erfasst
werden können, zählen Projektmanager, Ressourcen, Projektbeschreibung, Status,
Aufgaben, offene Fehler, Preis, voraussichtlicher Start und voraussichtliches Ende.
[TUTOS 2002]
Untersuchung vorhandener Systeme
42
Abbildung 23: Projektdaten Eingabemaske [TUTOS 2002]
4.6.2.3 Timetrack
Timetrack bezeichnet im TUTOS-System die Möglichkeit Arbeitszeiten einzelnen
Projekten oder Aufgaben zuzuordnen. Dies kann von jedem Benutzer selber durchgeführt
werden, spezielle Gruppen können auch eine Übersicht über diese Arbeitszeiten
ansehen. Bei der Erfassung, wie in Abbildung 24 dargestellt, können Informationen wie
geleistete Arbeitszeit, Kosten pro Stunde, Beschreibung, Datum der Arbeitsleistung und
ein Status dieser Zeiterfassung zugeordnet werden. Als Status wird festgehalten ob diese
Arbeitszeit kontrolliert, verrechnet, bezahlt oder nicht verrechenbar ist. [TUTOS 2002]
Abbildung 24: TUTOS – Timetrack [TUTOS 2002]
Untersuchung vorhandener Systeme
43
4.6.2.4 Aufgaben
Mit dieser Funktionalität im TUTOS-System können große Projekte in verschiedene
Teilaufgaben gegliedert werden. Diese Tätigkeiten können, wie in Abbildung 25
ersichtlich, einem verantwortlichen Projektmitarbeiter zugeordnet werden. Zusätzlich
können eine ToDo-Liste der Aufgaben, der Status, geschätzte Arbeitsstunden,
Ressourcen, geplanter Start und geplantes Ende verwaltet werden. [TUTOS 2002]
Diese Teilaufgaben eines Projektes können in weitere Teilaufgaben unterteilt werden.
Dadurch ist es möglich eine auf das jeweilige Projekt abgestimmte Granularität der
Aufgaben und deren Zuordnung an bestimmte Mitarbeiter zu erreichen. Mit der Funktion
„Aufgabenübersicht“ kann eine Übersicht aller Aufgaben eines Projektes dargestellt
werden. Hier werden alle Teilaufgaben mit dem jeweiligen Fertigstellungsgrad aufgelistet
und daraus der Fertigstellungsgrad des Projekts errechnet. Als weitere Funktion im
Bereich der Projektvisualisierung bietet TUTOS die Möglichkeit, ein Projekt und dessen
Teilaufgaben als Gant Diagramm darzustellen (Abbildung 26).[TUTOS 2002]
Abbildung 25: TUTOS – Aufgabe erstellen [TUTOS 2002]
Untersuchung vorhandener Systeme
44
Abbildung 26: TUTOS – Gant Diagramm [TUTOS 2002]
4.6.2.5 Bug-Tracking und Installationen
Da TUTOS ursprünglich für den Bereich der Softwareentwicklung konzipiert wurde, bietet
es einige sehr nützliche Funktionen für dieses Einsatzgebiet. Das System bietet die
Möglichkeit offene Software-Bugs zu erfassen, einem Bearbeiter zuzuweisen, eine
Klassifizierung und den aktuellen Status festzuhalten. Durch die Zuordnung zu einem
Projekt können dort auftretende Fehler einfach behandelt und verfolgt werden. [TUSTOS
2002]
Ähnliche Funktionalität bietet das TUTOS-System zur Evidenzhaltung von bestehenden
Softwareinstallationen bei Kunden. Zusätzlich zu den Installationsdaten können auch
Verkaufsdetails zum ausgewählten Produkt bzw. Projekt, die zuständige Person im
Verkauf und der Mitarbeiter, der die Installation durchgeführt hat, abgespeichert werden.
[TUTOS 2002]
4.6.3 Systemvoraussetzungen
Laut dem TUTOS Administration Guide9 werden folgende Komponenten für eine
Installation benötigt:



9
Apache Webserver
PHP 4.1.0
Datenbank – mySql, Postgres, Oracle 8.0.5 ++ oder Interbase 5
Download unter http://prdownloads.sourceforge.net/tutos/adminguide-1.0.pdf?download
Untersuchung vorhandener Systeme
45
Neben diesen geringen Anforderungen des Systems, bietet TUTOS noch
Installationssupport durch Skripte. Diese erleichtern das Aufsetzen der Datenbank und
der notwendigen Startkonfiguration. Für den Endbenutzer wird lediglich ein Javascript
fähiger Browser verlangt, wodurch alle aktuellen Browser als „Client“ verwendet werden
können.
4.6.4 Integrationsfähigkeit am IICM
Die bereits in Abschnitt 4.5.4 beim Produkt PHPProject dargestellten Vor- und Nachteile
einer PHP basierten Open Source Lösung treffen auch auf TUTOS zu. Die Integration in
die IICM Infrastruktur sollte keine Probleme bereiten, da entsprechende Hardware und
Server-Betriebssysteme, die eine Installation der TUTOS Komponenten ermöglichen,
vorhanden sind.
Ob die Einführung eines Open Source PHP Produkts, mit den notwendigen eigenen
Ressource für die Erweiterung bzw. Fehlerbehebung, für das IICM eine sinnvolle
Alternative zu kommerziellen Produkten oder einer Eigenentwicklung darstellt, muss aus
strategischen Gesichtspunkte entschieden werden. Da aber alle am IICM entwickelten
System auf anderen Technologien und Infrastrukturen aufbauen, wäre zumindest ein
zusätzlicher Know How Aufbau im Bereich von PHP nötig. Als Datenbank könnte Oracle
verwendet werden, hier wäre die entsprechende Erfahrung bereits vorhanden.
4.7 Zusammenfassung
Laut einer Auflistung des Projekt Management Centers [PM Center] gibt es am Markt eine
Anzahl von über 100 Web-basierten Projekt Management Systemen, einer etwa gleich
großen Anzahl von Windows Systemen und vielen Systemen für andere Plattformen.
Durch diese große Anzahl der am Markt befindlichen Projektmanagement-Systeme bzw.
Projektmanagementunterstützenden Systeme konnte in Abschnitt 4 nur ein Überblick
gegeben werden. Zu diesem Zweck wurden drei kommerzielle Systeme und zwei Open
Source Lösungen ausgewählt und untersucht. Diese Systeme wurden aus der Kategorie
"Web-basierte Projektmanagement-Systeme" gewählt, wobei Microsoft Project Central ein
Zusatzprodukt zu Microsoft Project darstellt, die anderen Systeme sind reine "Web
Applikationen".
Die Auswahl dieser evaluierten Systeme erfolgte entweder aufgrund der umfangreichen
Produktdokumentation, bzw. Produktinformation auf der Homepage des jeweiligen
Herstellers oder aufgrund der Tatsache das eine Online Demo Version verfügbar war. Für
Microsoft Project Central lag eine umfangreiche Produktbeschreibung vor, die zur
Evaluierung herangezogen wurde. Mittels dieser und der großen Anzahl an vorhandenen
Screenshots konnte die Funktionalität des Produkts gut abgeschätzt werden.
Für das zweite untersuchte Produkt, Enact Enterprise System 5.0, lagen ebenfalls
umfangreiche Beschreibungen vor, zusätzlich eine Guided Tour und weitere
Informationen auf der Homepage des Herstellers. Das dritte betrachtete System verfügte
nicht über eine so umfangreiche Beschreibung, dafür war eine Onlinedemo verfügbar.
Mittels dieser Onlinedemo und der dafür verfügbaren Hilfefunktion konnten die
Funktionalität des Produkts untersucht werden.
Untersuchung vorhandener Systeme
46
Als Informationsquelle bei den Open Source Lösungen wurden die jeweiligen User- und
Administration-Guides, Zusatzinformationen auf den Produkthomepages und die
verfügbaren Online-Demos herangezogen.
In Bezug auf das IICM und dessen Vorgaben (siehe Abschnitt 3.3) wurden folgende
Entscheidungskriterien erarbeitet:







Kann das Produkt alle geforderten Funktionen abdecken
Ist das Produkt erweiterbar bzw. an individuelle Anforderungen anzupassen
Welche Systemvoraussetzungen fordert das Produkt
Wie groß ist der Aufwand der Wartung
Besteht bereits Know How in der zugrunde liegenden Technologie am IICM
Ist das Produkt in andere, bereits bestehende Systeme (HWIS) integrierbar
Ist Investitionsschutz gegeben (Einsatz bestehender Systeme und Know How)
In Bezug auf diese Entscheidungskriterien konnte folgende Entscheidunge für den Einsatz
eines der evaluierten Systeme am IICM getroffen werden. Durch die Anforderung des
IICM ein Projektmanagement System in Verbindung mit dem Hyperwave Information
Server betreiben zu können, erweist sich eine Integration eines Fremdsystems generell
als schwierig.
Am schwierigsten stellt sich eine Integration von Microsoft Project Central dar. Durch die
notwendige Verwendung einer am IICM "unüblichen" Hardwareinfrastruktur, einer nicht
eingesetzten Technologie (ASP) und eines für das IICM ungünstigen Lizenzmodells. Auch
die Punkte Erweiterbarkeit und Anpassungsfähigkeit mit IICM-internen Ressourcen stellen
den Einsatz dieses Systems in Frage.
Für den Einsatz des Enact Enterprise Systems 5.0 sprechen die Java Technologie,
Unterstützung von verschiedenen Hardware Plattformen und die Erweiterbarkeit, auch
mittels IICM interner Ressourcen, durch ein gut dokumentiertes API. Die BackendDatenbanksysteme sollten am IICM ebenfalls vorhanden sein. Negativ stellt sich ein
gewisser Anpassungsaufwand dar, der durch die Firma Enact oder das IICM zu tragen
wäre, da nicht die gesamte geforderte Funktionalität des IICM vorhanden ist. Fraglich ist
auch die Integrationsfähigkeit mit dem Hyperwave Information Server, trotz der
Verfügbarkeit eines dokumentiertes API’s.
Das Celoxis System stellt umfangreiche, über Projektmanagementtätigkeiten
hinausgehende Funktionalitäten zur Verfügung. Diese Funktionen sind, wie mittels OnlineDemo evaluiert wurde, durch den Anwender einfach zu bedienen. Der Einsatz am IICM
stellt sich jedoch schwierig dar, da das System im Normalfall als ASP-Produkt (Applikation
Service Provider) angeboten wird. Dadurch würde bestehende Hardware und Know How
am IICM nicht genützt, allerdings würde der Wartungsaufwand "outgesourced". Ein
Betrieb auf einem Server des IICM müsste mit der Firma Celoxis verhandelt werden. Wie
gut eine Integration dieses Produkts am IICM möglich wäre, müsste noch untersucht
werden. Eine weitere Frage wirft die Erweiterbarkeit, intern durch das IICM oder durch die
Firma Celoxis, auf.
Vorteile in Bezug auf Wartung, Fehlerbehebung und Erweiterbarkeit bieten die Open
Source Lösungen. Durch den verfügbaren Sourcecode bietet sich die Möglichkeit
notwendige Tätigkeiten selbst durchzuführen oder diese an einen Drittanbieter zu
vergeben. Nachteilig wirkt sich bei diesen Systemen der fehlende Support und die
fehlende Wartungs- und Weiterentwicklungsgarantie durch die Entwickler aus. Dieser
Nachteil resultiert aus dem System von Open Source Software und müsste vom IICM
ausgeglichen werden. Systemtechnisch sollte die Integration der beiden Produkte kein
Untersuchung vorhandener Systeme
47
Problem darstellen, den Systemvoraussetzungen sowohl hardwareseitig als auch in der
zugrundeliegenden Software könnte entsprochen werden.
Funktionalität
MS Project
Projektverw.
Aufgabenlisten
Gruppierungen
Gant Charts
Timesheet
Status Reports
Ressourcen
Templates
Multilanguage
Programmiersprache
MS ASP
Systemvoraussetzungen MS IIS
Oracle
MS SQL
Erweiterbarkeit
Besonderheiten
COM Add-Ins
Enact 5.0
Projektverw.
Aufgabenlisten
Views
Gant Charts
Timesheet
Status Reports
Ressourcen
Templates
Multilanguage
Java
MS IIS
NS Iplanet
Apache
Oracle 8
MS SQL 7
Perl 5
SMTP
Java API
Celoxis
Projektverw.
Aufgabenlisten
Gant Charts
Timesheet
Kundenzugang
Projektarchiv
Volltextsuche
MyHome
Ressourcen
Kundenverw.
Foren
Java
Keine Angabe
Hersteller
PHPProjekt
Projektverw.
Aufgabenlisten
Projektstatistik
Terminkalender
Timesheet
Foren / Chat
Email-Client
Multilanguage
Helpdesk
Kontaktmanager
TUTOS
Projektverw.
Aufgabenlisten
Gant Charts
MyTutos
Timesheet
Bug-Tracking
ProduktInstallationen
PHP
PHP 4
Apache
MySQL
Postgres
Oracle 8
Informix
MS SQL
offen
Open Source
PHP
PHP 4
Apache
MySQL
Postgres
Oracle 8
Interbase 5
offen
Open Source
Tabelle 1 : Übersicht der untersuchten Systeme
Wie die Evaluierung dieser Systeme gezeigt hat, treten bei der Integration eines
Fremdsystems in eine bestehende Infrastruktur unter Umständen schwerwiegende
Probleme auf. Da diese Probleme und notwendige Anpassungen zusätzliche Kosten zu
den eigentlichen Produktkosten verursachen, stellt sich eine Eigenentwicklung oft
kostengünstiger dar. Aufbauend auf die Ergebnisse dieses Kapitels wurde am IICM
beschlossen, ein Projektmanagement-Tool selbst zu entwickeln und zu betreiben, da dies
in Summe eine wesentlich kostengünstigere und exakt auf die Bedürfnisse des IICM
zugeschnittene Lösung ermöglicht.
Das Realisierungskonzept dieser Lösung wird im Gestaltungsbereich dieser Arbeit
erarbeitet und die Umsetzung beschrieben. Einleitend werden die Anforderungen an
dieses spezielle System für das IICM nochmals zusammengefasst und das Pflichtenheft
vorgestellt. Ausgehend davon und der Beschreibung der technologischen
Basiskomponenten wird dann eine Umsetzung erarbeitet.
48
Teil II
Gestaltungsbereich
Realisierungskonzept für das IICM
49
5 Realisierungskonzept für das IICM
Wie die theoretischen Betrachtungen in Abschnitt 2, die allgemeinen Anforderungen in
Abschnitt 3 und die Evaluierung bestehender Systeme in Abschnitt 4 gezeigt haben,
lassen sich nicht alle Problemstellungen im Projektmanagement eines speziellen
Unternehmens mittels Standardsoftware lösen. Oftmals stellt eine „maßgeschneiderte“
Lösung die wesentlich bessere und möglicherweise auch kostengünstigere Variante dar.
Aus diesem Grund soll in diesem zweiten Teil der Arbeit, ein Lösungsansatz für ein
Projektkoordinations-System erarbeitet und die Umsetzung beschrieben werden.
Einleitend wird eine Anforderungsliste für das Projektkoordinations-System erstellt, die
sowohl Aspekte der theoretischen Betrachtungen aus Abschnitt 2 aufnimmt, als auch
Aspekte bestehender Systeme und allgemeine Anforderungen. Diese Anforderungsliste
wird dann in ein Pflichtenheft 10, für die Erstellung eines Projektkoordinations-Systems am
IICM übergeführt. Ausgehend von diesem Pflichtenheft, in dem alle notwendigen
Vorgaben für die Umsetzung beschrieben werden, kann dann mit der Realisierung des
Systems begonnen werden.
Der Lösungsansatz der in diesem Teil der Arbeit beschrieben wird, beruht auf der
Verwendung eines, dieser Problemstellung entsprechenden Grundsystems. Durch den
Einsatz eines leistungsfähigen und offenen Systems kann der Entwicklungsaufwand
reduziert und die Erweiterbarkeit und Flexibilität gewährleistet werden. Da die Auswahl
des Grundsystems auf den Hyperwave Information Server gefallen ist, werden in diesem
Abschnitt die grundlegende Technologien und Komponenten erläutert.
5.1 Anforderungsliste an das Projektkoordinations-System
Die erzielten Ergebnisse aus Teil 1 dieser Arbeit, dem Untersuchungsbereich, sollen hier
in einer Anforderungsliste an das Projektkoordinations-System zusammengefasst werden.
In diese Anforderungsliste sollen sowohl die theoretischen Betrachtungen einfließen, als
auch die Erkenntnisse aus der Evaluierung am Markt bestehender Software-Systeme und
die allgemeinen und speziellen Anforderungen an das System.
5.1.1 Anforderungen aus den theoretischen Betrachtungen
Aus den in Abschnitt 2.1.2 beschriebenen Aufgaben und Tätigkeiten im
Projektmanagement lassen sich folgende Anforderungen an das ProjektkoordinationsSystem extrahieren:




10
Geplante Termine und Aufwände
Projektziele
Zuordnen von Verantwortungen zu Personen (Projektleiter,
Projektleiterstellvertreter)
Ressourcen (Mitarbeiter)
Das Pflichtenheft befindet sich im Anhang A dieser Arbeit
Realisierungskonzept für das IICM
50
Um den Aufgaben der Projektsteuerung, die in Abschnitt 2.1.3 beschrieben wurden,
nachkommen zu können müssen folgende Anforderungen erfüllt werden:



Geplanter und tatsächlicher Aufwand
Projektberichte
Notwendige Daten für den Soll/Ist-Vergleich
Wie in Abschnitt 2.1.4 beschrieben müssen nicht nur Informationen sondern auch
Projektwissen und Know How für die Projektmitarbeiter verfügbar sein um einen Nutzen
für zukünftige Projekte generieren zu können. Daraus ergeben sich folgende
Anforderungen:



Projektwissen (Know How Dokumente, Zusatzinformationen)
Archivierung von Projektwissen
Verwaltung von Standarddateiformaten
5.1.2 Allgemeine bzw. spezielle Anforderungen des IICM
Aus den in Abschnitt 3.1.2 vorgestellten allgemeinen Anforderungen an
Projektmanagement Software können die folgenden für das Projektkoordinations-System
des IICM übernommen werden:







Einfache Projektdefinition
Terminplanung und Kontrolle
Kapazitätsplanung
Unternehmensweiter Zugriff
Systemschnittstellen
Schnittstellen zu Standardsoftware
Web Interface
Zusätzlich müssen spezielle Anforderungen des Softwaredesigns und des IICM erfüllt
werden:







Verteilen von Information
Virtuelle Zusammenarbeit
Flexibilität
Zentrale und dezentrale Verwaltung
Multiprojektmanagement
Einfache Verwaltung von Projektberichten
Mehrsprachigkeit
5.1.3 Anforderungen aus der Evaluierung bestehender Systeme
Nützliche Funktionalitäten, die bei der Evaluierung bestehender Systeme in Abschnitt 4
erkannt wurden, sollen ebenfalls in die Anforderungen einfließen:





Rechtvergabe über vordefinierte Benutzerrollen
Realtimabfrage von Projektdaten
Emailverständigungen
Volltextsuche
Projektarchiv
Realisierungskonzept für das IICM
51
Auf Anforderungen, wie sie an jedes Informationssystem gestellt werden, soll hier nicht
näher eingegangen werden. Exemplarisch seien Funktionalitäten wie Linkmanagement,
Userverwaltung, Rechtvergabe, Suche, benutzerfreundliches Userinterface und
Performance erwähnt. In diesem Abschnitt wurden die Anforderungen an das
Projektkoordinations-System des IICM aus den Betrachtungen des theoretischen Teils der
Arbeit extrahiert und zusammengefasst. Da für die Umsetzung der Hyperwave Information
Server verwendet werden soll, ein am IICM entwickeltes, sehr umfassendes
Informationssystem,
müssen
die
hier
aufgezählten
Anforderungen
an
Informationssysteme nicht weiter berücksichtigt werden. Dieser Anforderungen werden
bereits standardmäßig vom Hyperwave Information Server abgedeckt und verursachen
keinen zusätzlichen Programmieraufwand (siehe auch Kapitel 5.3). Nachdem die
Anforderungen an das Projektkoordinations-System nun definiert sind, können sie im
nächsten Abschnitt in Form eines Pflichtenhefts im Detail und allen Ausprägungen
ausgearbeitet werden.
5.2 Pflichtenheft für die Umsetzung
Um mit der Umsetzung des Projektkoordinations-Systems beginnen zu können, ist es
notwendig, die geforderte Funktionalität genau zu beschreiben und darzustellen. Diesen
Zweck und Inhalt verfolgt das Pflichtenheft. Neben der Beschreibung der geforderten
Funktionen sollen diese mittels Screenshots visualisiert werden. Diese Screenshots
können von einem bestehenden HTML-Prototypen, aus einer früheren Studienarbeit,
verwendet werden. Zusätzlich müssen die Rahmenbedingungen, wie Security,
Userverwaltung, Technologie der Umsetzung, Hardwareinfrastruktur und Betriebskonzept
definiert werden. Das vollständige Pflichtenheft befindet sich im Anhang A dieser Arbeit.
Grundlegende Voraussetzung für jede Implementierung ist die genaue Kenntnis der zu
verwendenden Basis-Technologien. Durch die am IICM bestehende Infrastruktur und
vorhandenen Produkte ergeben sich klare Vorgaben für den Einsatz bestimmter Produkte
und Technologien. In diesem und in den nächsten Abschnitten werden diese kurz
beschrieben, um mit dem Implementierungsdesign beginnen zu können.
5.3 Hyperwave Information Server
In diesem Kapitel soll ein kurzer Überblick zum Hyperwave Information Server, kurz
HWIS, gegeben werden. Dieser Server stellt die grundlegende Infrastruktur dar, auf der
aufbauend der Gestaltungsbereich dieser Arbeit implementiert wurde. Da diese
Infrastruktur direkten Einfluss auf die Umsetzung hat, sollen hier die relevanten Teile
beschrieben werden.
5.3.1 Entstehung des Hyperwave Information Servers
Die Entstehung des Hyperwave Information Servers findet sich 1989 am Institut für
Informationsverarbeitung und Computergestützte neue Medien (IICM) der TU-Graz. Zu
dieser Zeit wurde versucht ein System zu spezifizieren, welches die Nachteile anderer
gängiger Systeme dieser Zeit (z.B. Videotext), wie das Fehlen einer Suchfunktion,
fehlerhafte Links und der unklaren Trennung zwischen Inhalt und Layout beseitigen sollte.
[Maurer 1996c]
Realisierungskonzept für das IICM
52
1990 wurde ein Prototyp eines Servers unter dem Namen Hyper-G entwickelt, und
unterstützte das HTTP- und Gopher-Protokoll. Dieser Prototyp wurde nach dem
erfolgreichen Ersteinsatz als universitäres Informationssystem an der TU-Graz (TUGInfo),
wo sich das Hyper-G Konzept in der Praxis bewährte, in Zusammenarbeit mit dem
Joanneum Research zu einem marktreifen Produkt weiterentwickelt. Nach der
erfolgreichen Weiterführung 1992 als marktfähiges Produkt, konnte das System darauf hin
bei der ESA eingesetzt werden. [Maurer 1996c]
Nachdem 1997 die Hyperwave Information Management GmbH in München von Prof. Dr.
Hermann Maurer, Mag. Gerhard Pail und Dr. Frank Kappe gegründet wurde und alle
Rechte an Hyper-G erwarb, erhielt das Unternehmen noch im selben Jahr den "European
IT Price" der Europäischen Union (EU). [Maurer 1996c]
5.3.2 Grundlegendes
Der Hyperwave Information Server stellt ein Informationsmanagement System dar,
welches es ermöglicht, Wissen und Information in einem Objekt-Repository zu verwalten.
Dieses Repository kann über mehrere Server verteilt betrieben werden und erlaubt eine
organisierte und sichere Verwaltung der Information.
5.3.3 Strukturierte Elemente und Objekte
Collections stellen am HWIS eine grundlegende Komponente zur strukturierten
Wissensablage dar, welche Dokumente, Multimedia Objekte oder wieder andere
Collections enthalten können. Collections können durch Attribute gesteuert, verschiedene
Ausprägungen und Eigenschaften erhalten. Collections sind vergleichbar mit Ordnern in
einem hierarchischen Filesystem, bieten aber den Vorteil selber in mehr als einer
Collection vorkommen zu können. [HWIS UG]
5.3.4 Dokumente, Objekte, Attribute
Der Hyperwave Information Server speichert Dokumente nicht wie bei anderen Web
basierenden Systemen üblich in einem Filesystems, sondern in einer objektorientierten
Datenbank (Repository). Zusätzlich zu den Dokumenten können Informationen über diese
Dokumente als Hyperwave Objekte abgelegt werden, und beinhalten verschiedenste
Attributwerte (sogenannte Metadaten). Neben Benutzerdefinierten Attributen werden vom
System standardmäßig Attribute vergeben welche die Sucheigenschaften beeinflussen
oder Zugriffsrechte bestimmen. [HWIS UG]
5.3.5 Trennung von Information und Präsentation
Die Möglichkeit Layout und Inhalt trennen zu können, wird im HWIS erst durch die
Verwendung von strukturierten Elementen geschaffen. Obwohl verschiedene Konzepte,
Realisierungskonzept für das IICM
53
wie SGML oder XML diese Trennung direkt unterstützen, kann diese in Standard-HTML
(reine Seitenbeschreibungssprache) nicht vollzogen werden. [HWIS UG]
Beim HWIS kann sich der Autor auf die Erstellung des Inhaltes konzentrieren, das Layout
inklusive der Navigation wird vom System bereitgestellt (durch den Administrator
konfigurierbar). Durch diese Verwendung von "administrierbarem" Layout wird auch der
Einsatz von verschiedenen Layouts mit demselben Inhalt, bzw. ein einfacher Wechsel des
Layouts möglich. [HWIS UG]
5.3.6 Link Management
Beim HWIS werden Links nicht wie in anderen Systemen in den jeweiligen Seiten
gespeichert, was bei diesen Systemen Probleme mit der Link-Konsistenz verursacht,
sondern als eigene HWIS-Objekte. Dadurch können auch zusätzliche Funktionen, wie
automatisches Link-Update von verschobenen Dokumenten, Links zu gelöschten
Dokumenten werden nicht mehr als HTML-Links dargestellt, oder die Vergabe von
speziellen Rechten auf einzelne Links, angeboten werden. [HWIS UG]
5.3.7 Customizing
Das Standard-Userinterface, mit dem der HWIS ausgeliefert wird, läßt sich durch
verschiedene Möglichkeiten an individuelle Wünsche anpassen. Das Userinterface basiert
auf DHTML und Javascript clientseitig, serverseitig auf serverseitigem Javascript (SSJS)
und der HTML-Erweiterung Place. Mittels Place und Server Side JS können Templates
generiert und zur Laufzeit dynamisch gefüllt werden. Durch das Javascript Hyperwave
API lassen sich nahezu alle Funktionen des HWIS beeinflussen und somit an die
speziellen Anforderungen des Users anpassen. Neben den hier beschriebenen
programmatischen Anpassungsmöglichkeiten des HWIS gibt es noch Möglichkeiten für
User und Informationsanbieter den HWIS auf die speziellen Anforderungen anzupassen.
Hier seien nur kurz "Multiple Views", "benutzerdefinierte Templates" und "Home
Collections" genannt. [HWIS UG]
5.3.8 Suchfunktionalität
Der Hyperwave Information Server stellt standardmäßig eine Volltextsuche und eine
Suche über Metadaten zur Verfügung. Das bedeutet, dass sowohl gezielt in Attributen von
Dokumenten, als auch im Content gesucht werden kann. Die Suche über die Attribute
eines Dokumentes kann zum Beispiel "finde alle Grafiken mit X im Titel", oder "finde alle
Dokumente die der User X letzte Woche geändert hat" sein und wird in Abbildung 27
dargestellt. Die Volltextsuche umfasst spezielle Funktionalitäten wie: [HWIS UG]





Suche nach Synonymen
Suche nach Ausdrücken in der Einzahl, Mehrzahl oder Deklinationen
Phonetische Suche
Klein-/Großschreibung
Einschränkung der Suche auf Wörter im selben Paragraphen
Realisierungskonzept für das IICM
54
Abbildung 27: Hyperwave Suchdialog [HWIS UG]
Um die Suche nach den speziellen Bedürfnissen einschränken zu können, bietet der
Hyperwave Information Server die Möglichkeit ein Suchgebiet (Scope) anzugeben.
Dadurch wird eine Einschränkung auf einzelne oder mehrere Collections, einen oder
mehrere Server möglich. Diese Funktionalität wird bei der Implementierung des
Projektkoordinations-Systems verwendet werden, z.B. zur Suche nach Usern oder
Projekten. [HWIS UG]
Realisierungskonzept für das IICM
55
5.3.9 Security
Eine wesentliche Funktionalität des Hyperwave Information Server, welche auch als
Grundfunktionalität für das Projektkoordinations-System herangezogen wird, sind die
eingebauten Security Einrichtungen. Jedes in Hyperwave gespeicherte Objekt besitzt
seine eigenen Security-Attribute. Diese Attribute, mögliche Werte sind Read, Write und
Delete, spezifizieren genau welcher Benutzer welche Rechte auf dieses Objekt besitzt.
[HWIS UG]
Neben dieser Security Grundfunktionalität, stellt der Hyperwave Information Server auch
die nötigen Dialoge zum Verwalten von Security relevanten Einstellungen zur Verfügung.
Wie in Abbildung 28 als Beispiel dargestellt, können mit diesem Dialog die Rechte für ein
Objekt am Server eingestellt werden. [HWIS UG]
Abbildung 28: Hyperwave Rechte Wizard [HWIS UG]
5.3.10 Benutzer- und Gruppenverwaltung
Hyperwave stellt eine hierarchische Benutzer- und Gruppenverwaltung zur Verfügung. Ein
Benutzer kann Mitglied in einer oder mehreren Gruppen sein, welche ebenfalls wieder
Mitglied in mehreren Gruppen sein können. Ähnlich dem in Abbildung 29 und Abbildung
Realisierungskonzept für das IICM
56
30 gezeigten Dialogen zum Erstellen neuer Benutzer und Gruppen können die Attribute
dieser gewartet werden. [HWIS UG]
Abbildung 29: Hyperwave "Neuer Benutzer" Wizard [HWIS UG]
Abbildung 30: Hyperwave "Neue Gruppe" Wizard [HWIS AG]
Diese, vom Hyperwave Information Server umfangreich zur Verfügung gestellte Security,
wird als Basiskomponente für die Implementierung des Projektkoordinations-Systems
herangezogen. Dadurch kann eine standardkonforme Security Implementation
gewährleistet werden und verhindert einen Mehraufwand in der Umsetzung.
Realisierungskonzept für das IICM
57
5.4 Applikationsentwicklung am Hyperwave Information Server
Für den Anwendungsentwickler bieten sich verschiedene Möglichkeiten Applikationen für
den
Betrieb
am
Hyperwave
Information
Server
zu
entwickeln,
bzw.
Standardfunktionalitäten des Servers an die speziellen Bedürfnisse anzupassen. Dafür
stellt der HWIS verschiedene Funktionalitäten zur Verfügung.
Das Aussehen der dynamisch vom Server generierten HTML-Seiten wird durch die
Wavemaster-Templates gesteuert. Durch Programmierung der Wavemaster-Templates
kann auf das Aussehen Einfluss genommen werden. Der HWIS bietet standardmäßig
zwei Möglichkeiten, Place und Server Side JS, um in die Templates eingreifen zu können.
5.4.1 Place
Place ist eine eigen für den Hyperwave Information Server entwickelte Meta HTMLSprache, mit deren Hilfe das Verhalten des Servers und das Benutzerinterface beeinflusst
werden kann. Zusätzlich geben zur Laufzeit verschiedene Place-Variablen Auskunft über
den aktuellen Server-, bzw. Benutzerstatus. Place besteht im Wesentlichen aus den
einfachen Sprachkonstrukten if-Statement, while-Schleife, macro-Aufrufen und
verschiedensten Placeholders. [HWIS PG]
Place kommt in den Hyperwave Templates zum Einsatz, die aus einer Mischung von
Place und HTML-Code bestehen. Ein solches Template kann z.B. feststellen, ob am
Server ein Fehler aufgetreten ist und in diesem Fall eine entsprechende Fehlermeldung
anzeigen, den aktuellen Benutzer ausgeben oder die Parents einer Collection auflisten.
Place-Anweisungen müssen mit einem „%%“-Zeichen beginnen und enden. [HWIS PG]
Einen wichtigen Placeholder-Typ stellen die Actions dar. Sie dienen nicht der Übergabe
von Werten, sondern werden zum Durchführen von Aktionen verwendet. Neben
vordefinierten
Hyperwave-Actions
kommen
bei
der
Implementation
des
Projektkoordinations-Systems auch selbstdefinierte Actions zum Einsatz. Mit Hilfe dieser
können direkt vom Benutzerinterface Aktionen am Hyperwave Information Server
ausgelöst werden. [HWIS PG]
Um in das Verhalten der Wavemaster-Templates einzugreifen bietet Place nur begrenzte
Möglichkeiten. Es können keine benutzerdefinierten Variablen verwendet werden, ServerVariablen können nur in Bezug auf das aktuelle Objekt ausgelesen aber nicht gesetzt
werden. Damit wird keine Möglichkeit geboten Objektattribute upzudaten. [HWIS PG]
Aus diesem Grund wird für die Umsetzung des Projektkoordinations-Systems in erster
Linie serverseitiges Javascript verwendet, Place wird für verschiedene Statusabfragen
und Actions eingesetzt.
5.4.2 Serverseitiges Javascript
Die Programmiersprache Javascript wurde von Netscape Communications Cooperations
für den clientseitigen Einsatz in den Netscape-Browsern und für den serverseitigen
Einsatz auf Webservern entwickelt. Javascript stellt eine einfache, interpretierte und nicht
Realisierungskonzept für das IICM
58
typorientierte Sprache dar. Zusätzlich kann in Javascript begrenzt objektorientiert
programmiert werden.
Hyperwave bietet neben der clientseitigen Verwendung von Javascript im Browser zwei
Möglichkeiten serverseitiges Javascript einzubinden: [HWIS PG]


HWJS
JavaScript in Wavemaster Templates
HWJS ist ein Kommandozeilen-Tool, mit welchen Javascript-Files am HWIS ausgeführt
werden können. Damit ist es möglich über vordefinierte Javascript Objekte auf den Server
einzuwirken. Da HWJS für die Implementierung des Projektkoordinations-Systems aber
nicht zum Einsatz kommt, wird hier nicht näher darauf eingegangen. [HWIS PG]
5.4.2.1 JavaScript in Wavemaster Templates
Mittels Javascript in Wavemaster Templates kann das Verhalten des HWIS wesentlich
besser beeinflußt werden als mit Place. Javascript lässt sich auf verschiedene Weisen in
die Templates einbinden: [HWIS PG]




JavaScript wird von einem <SERVER></SERVER> Tag eingeschlossen.
JavaScript befindet sich in einem eigenen File und wird mit dem include-Tag
eingebunden. <SERVER SRC = "file://path/filename">
In einem HTML-Tag als Attribut-Name durch Backquotes eingebunden.
JavaScript wird in einem HTML-Tag als Attribut-Wert durch Backquotes
eingebunden.
Um die verschiedenen Möglichkeiten zu demonstrieren, wurde Beispiel 1 aus [HWIS PG]
entnommen:
<!-- this is a HTML template -->
<H1>Welcome</H1>
<SERVER>
// this is pure JavaScript
function pref()
{
return “HREF”;
}
function url()
{
return “http://hyperwave.com”;
}
write(“hello and welcome”);
</SERVER>
<!—- invocation in a tag -->
<A ‘pref()‘=‘url()‘>Go to Hyperwave</A>
<!—- a include -->
<SERVER SRC=”file://test.js”>
Beispiel 1: Verschiedene Möglichkeiten der Javascript Einbindung am HWIS [HWIS PG]
Realisierungskonzept für das IICM
59
Um auf den HWIS mit Javascript zugreifen zu können, werden standardmäßig folgende
Javascript Objekte angeboten:
Tabelle 1: Javascript Objekte am HWIS [HWIS PG]
Wie man sieht, bietet die Kombination der Funktionen des Hyperwave Information
Servers und serverseitigem Javascript eine mächtige Möglichkeit um Applikationen zu
entwickeln. Durch die große Anzahl an vordefinierten Funktionen und Objekten wird nicht
nur die Entwicklungszeit verkürzt, sondern auch ein Standard geschaffen. Dieser
Standard kann mit relativ geringem Aufwand erweitert und an die individuellen
Bedürfnisse angepasst werden.
Aufgrund der hier aufgezeigten Möglichkeiten, wird für die Implementierung des
Projektkoordinations-Systems serverseitiges Javascript verwendet. Place kommt nur für
bestimmte Server-Statusabfragen zum Einsatz.
5.4.3 HWLIB
Die HWLIB (HyperWave LIBrary) stellt ein Javascript Bibliothek dar, die am IICM
entwickelt wurde um das objektorientierte Programmieren unter Javascript zu
vereinfachen und vordefinierte Objekte für den HWIS zur Verfügung zu stellen. Zusätzlich
wird der Entwicklungsprozess beschleunigt, die Qualitätssicherung verbessert und durch
das Bibliothekskonzept Wiederverwendbarkeit, Stabilität und Modularität gewährleistet.
[HWLIB RG]
Realisierungskonzept für das IICM
60
In diesem Kapitel sollen kurz die wichtigsten Konzepte der HWLIB und das
Zusammenspiel mit dem HWIS beschrieben werden, da die Implementierung des
Projektkoordinations-Systems unter Verwendung der HWLIB erfolgen soll.
Alle Objekte der HWLIB, welche in Abbildung 31 dargestellt werden, haben das
hw_Object als Basisobjekt, von dieser Superklasse werden alle Objekte abgeleitet. Sie
besitzen das Prefix „hw_“ und werden jeweils in einer eigenen „.js“-Datei gespeichert, zB.
das hw_TextObject in „hw_TextObject.js“. Die gesamte Bibliothek wird in einem eigenem
Verzeichnis unter „~/wavemaster/hwlib“ abgelegt und besitzt folgende grundlegende
Eigenschaften: [HWLIB RG]



Die HWLIB stellt ein Interface zwischen dem Hyperwave API und der ApplikationsProgrammierung in Javascript dar.
Es wird die volle Funktionalität zur Verfügung gestellt, die benötigt wird um mit
dem HWIS zu interagieren.
Durch die HWLIB ist es nicht mehr nötig alle Details des HWIS API’s zu kennen.
Abbildung 31: Objekte Hierarchie der HWLIB [HWLIB RG]
Das hw_Object stellt folgende, wichtige Funktionalitäten zur Verfügung, welche von den
abgeleiteten Objekten gegebenenfalls überschrieben, erweitert oder einfach benützt
werden: [HWLIB RG]



Methoden zur Attribut-Manipulation
Methoden für den Attribut-Zugriff
Methoden für die Anzeige
Realisierungskonzept für das IICM



61
Methoden für diverse Konvertierungen
Methoden für den Zugriff und die Suche
Utility-Methoden , wie z.B. holen der Eltern-Objekte, duplizieren, usw.
Um die Bibliothek HWLIB unter Hyperwave nutzen zu können, muss das bereits
beschriebene hwlib-Verzeichnis in das wavemaster-Verzeichnis kopiert werden. Damit die
HWLIB-Objekte dann in den Wavemaster Templates zur Verfügung stehen, sind
Änderungen des Master-Templates notwendig. Hier müssen vier Includes eingefügt
werden, welche die Funktionen der HWLIB in den HWIS einbinden. [HWLIB RG]
Nachdem in diesem Kapitel alle wichtigen Basistechnologien beschrieben wurden, die für
die Entwicklung des Projektkoordinations-Systems notwendig sind, wird in den folgenden
Kapiteln noch auf die Einbindung von Eigenentwicklungen am Hyperwave Information
Server eingegangen.
5.5 Einbinden von Eigenentwicklungen am HWIS
Der Hyperwave Information Server bietet einen Standardmechanismus um
Eigenentwicklungen einzubinden. Jede Applikation wird als Modul gesehen und als
solches eingebunden. Dafür sind die folgenden Schritte notwendig: [HWIS PG]




Erzeugen der Verzeichnisstruktur
Erzeugen der Datei „include.html“
Erzeugen des „Komponenten-Master“
Erzeugen der notwendigen Menüeinträge
5.5.1.1 Verzeichnisstruktur
Die Verzeichnisstruktur für das Einbinden von Applikationen sollte dem in Abbildung 32
dargestellten
Standard
entsprechen,
und
im
Verzeichnis
„\Server\v6_2\apps\his\v6.2\components“
angelegt
werden.
Das
Verzeichnis
„mycomponent“ stellt dabei das Stammverzeichnis der Applikation dar und sollte
dementsprechend bezeichnet werden. Im Unterverzeichnis „ui“ werden alle
Komponenten, die das Userinterface betreffen abgelegt, im Verzeichnis code der restliche
Applikations-Sourcecode. [HWIS PG]
Abbildung 32: Verzeichnisstruktur für HWIS Module [HWIS PG]
Nachdem die Verzeichnisstruktur angelegt worden ist, müssen folgende zwei Dateien im
Stammverzeichnis der Applikation angelegt werden.
Realisierungskonzept für das IICM
62
5.5.1.2 Erzeugen der Datei „include.html“
Diese Datei inkludiert alle, für dieses Modul (Applikation) notwendigen Script-Dateien. Sie
selber muss in der globalen „Server\v6_2\apps\his\v6.2\hwincludes.html“-Datei
eingetragen werden, welche eine Include-Zeile für jedes installierte Modul enthält. Am
Ende der „include.html“ des Moduls wird dann noch der „Komponenten Master“
eingebunden. [HWIS PG]
5.5.1.3 Erzeugen des „Komponenten Master“
Die „Master“-Datei wird ebenfalls im Stammverzeichnis der Applikation erzeugt und sollte
den Namen „*master.html“ besitzen, wobei der * für den Komponentennamen steht.
<SERVER>actionhandler.component("searchmaster");</SERVER>
%%#%%
%%macro searchmaster%%
<SERVER>actionhandler.status("done");</SERVER>
%%if (action == "querynotify.action")%%
%%querynotify%%
%%else%%
Hyperwave Programmer’s Guide - PLACE
%%if action == "dialog.savequery.action" || action ==
"dialog.savequerywhatsnew.action" || action ==
"dialog.savequeryscheduled.action" || action ==
"dialog.savequerywhatsnewsched.action"%%
%%dialog_savequery%%
%%else%%
%%if action == action.extended.search%%
%%dialog_searchresult%%
%%else%%
%%if action == "dialog.search.action" %%
%%dialog_search%%
%%else%%
%%if action == "dialog.extendedsearch.action" %%
%%dialog_extendedsearch%%
%%else%%
<SERVER>actionhandler.status("");</SERVER>
%%endif%%
%%endif%%
%%endif%%
%%endif%%
%%endif%%
%%endmacro%%
Beispiel 2: Beispiel für eine Komponenten Master Datei (searchMaster.html) [HWIS PG]
Wie in Beispiel 2 dargestellt, enthält die erste Zeile den Verweis für den HWIS
Actionhandler und referenziert das, für das Handling dieser Komponente zuständige
Makro oder serverseitige Javascript. Der HWIS Actionhandler leitet dann die Actions an
den
zuständigen
Subactionhandler
weiter.
Die
Javascript-Zeile
Realisierungskonzept für das IICM
63
„<SERVER>actionhandler.status("done");</SERVER>“ gibt nur dem HWIS
Actionhandler bekannt, dass die Action von diesem Subactionhandler behandelt wird und
wird am Ende der Datei wieder zurückgesetzt. Im „Body“ der Datei befinden sich alle
notwendigen „if-else“ Anweisungen. [HWIS PG]
Um das Einbinden einer Komponente am HWIS abzuschließen, müssen nur noch die
notwendigen Menüeinträge generiert werden.
5.5.1.4 Erzeugen der notwendigen Menüeinträge
Alle Menüeinträge und deren Struktur am HWIS werden in der Datei
„Server\v6_2\apps\his\v6.2\config\menudef.js“ eingetragen. Für das Erzeugen eines oder
mehrerer neuer Menüeinträge sind folgende Änderungen in dieser Datei notwendig:
[HWIS PG]
Ein Menüeintrag für das Projektkoordinations-System wird durch Einfügen dieser Zeile
erzeugt:
iicm_pm_M.add("Projekte",{child:iicm_pm_project_M});
Beispiel 3: Menüeintrag für das Projektkoordinatios-System [HAI-PL Sourcecode]
5.6 Zusammenfassung
Der Entwicklungsprozess und die Implementierung von Software stellen einen komplexen
Prozess dar. Um diesen Prozess qualitätsgesichert und zügig durchlaufen zu können, ist
es notwendig, grundlegende Vorraussetzungen dafür zu schaffen. Diese
Vorraussetzungen werden durch die in diesem Kapitel beschriebenen Hilfsmittel, wie dem
Pflichtenheft bzw. durch die Evaluierung und die Auswahl der Basisinfrastruktur (in
diesem Fall der Hyperwave Information Server) bereitgestellt.
Die Erstellung eines Pflichtenheftes, welches genau beschreibt welche Anforderungen an
das Produkt gestellt werden, ist vom Auftraggeber durchzuführen. Dieses dient als
Grundlage aller weiteren Entwicklungsschritte. Zusätzlich sind gemeinsam mit dem
Entwicklungsteam die Rahmenbedingungen festzulegen, die vom Produkt einzuhalten
sind. Dazu gehören sowohl Infrastrukturen auf denen das Produkt lauffähig sein muss als
auch zu verwendende Technologien bei der Umsetzung und Abhängigkeiten zu anderen
Systemen und Produkten.
Aus den genannten Gründen wurde in diesem Abschnitt das Pflichtenheft vorgestellt und
die zu verwendenden Technologien beschrieben. Durch den Einsatz des Hyperwave
Information Server, der die grundlegende Infrastruktur für die Entwicklung des
Projektkoordinations-Systems
darstellt,
können
Standardfunktionalitäten
eines
Informationssystem abgedeckt und so Programmier Mehraufwand vermieden werden. Zu
diesen Standardfunktionalitäten zählen Dinge wie Security, Userverwaltung,
Dokumentenmanagement und Berechtigungshierarchien, um nur einige zu nennen.
Aufbauend auf die Kenntnis des HWIS mussten Möglichkeiten der Programmierung
evaluiert und eine Entscheidung für die zu verwendende Technologie getroffen werden.
Realisierungskonzept für das IICM
64
Aus den zwei Standardmöglichkeiten die der HWIS bietet, Place und Server Side JS,
wurde aufgrund der größeren Flexibilität und der Möglichkeit objektorientiert zu
Programmieren, Server Side JS ausgewählt Im Abschluss wurde die Methodik für die
Einbindung einer Eigenentwicklung am HWIS vorgestellt.
Damit wurden alle Vorraussetzungen und Rahmenbedingungen abgeklärt und
Entscheidungen für die zu verwendenden Technologien getroffen. Damit kann im
nächsten Abschnitt mit dem Design und der Umsetzung der Applikation fortgesetzt
werden. Neben der Beschreibung der einzelnen Applikationsmodule werden auch
Implementierungs-Entscheidungen und -Konzepte aufgezeigt.
Implementierung des Systems
65
6 Implementierung des Systems
Im ersten Teil dieser Arbeit, dem Untersuchungsbereich, wurde theoretisch auf die
Aufgaben und Problemstellungen von Projektmanagement eingegangen, am Markt
befindliche Systeme evaluiert und deren Integration am IICM geprüft. Ausgehend von
diesen Ergebnissen und der Schlussfolgerung, eine Entwicklung am Hyperwave
Information Server durchzuführen, wurde in Kapitel 5.1 gemeinsam mit dem IICM ein
Pflichtenheft für das Projekt Koordinations-System erarbeitet.
Anschließend wurde der Hyperwave Information Server betrachtet und Möglichkeiten der
Programmierung aufgezeigt. Nachdem diese grundlegenden Dinge geklärt wurden, kann
in diesem Abschnitt mit der Implementierung des Systems begonnen werden. Im ersten
Schritt der Implementierung wird das Design des Systems, das Design des
Benutzerinterfaces ebenso wie das Design der Javascript Objekte festgelegt.
Nachdem das Design des Projekt Koordinations-Systems festgelegt ist, wird noch auf die
eigentliche Umsetzung der Javascript Objekte und notwendigen Konfigurationen am
Hyperwave Information Server eingegangen.
6.1 Design der Umsetzung
Dieser Schritt kann in drei Teilschritte untergliedert werden. Das Design der Dialoge und
Funktionen, das Design des Benutzerinterfaces und dem objektorientierten Entwurf. Diese
drei Schritte werden in diesem Abschnitt behandelt, bevor mit der eigentlichen Umsetzung
der Javascript Objekte begonnen werden kann. Ausgegangen wird hier von den bereits
definierten Anforderungen und umzusetzenden Funktionalitäten, die im Pflichtenheft
gemeinsam mit dem IICM festgelegt wurden.
6.1.1 Dialoge und Funktionen
Im ersten Schritt des Designs muss das Zusammenspiel der Dialoge und Funktionen für
das Projekt Koordinations-System untersucht werden. Zu diesem Zweck werden EventDiagramme der notwendigen Funktionalitäten gebildet und beschrieben.
Die Funktionalitäten können in die Gruppen Mitarbeiterverwaltung, Projektverwaltung und
Berichte unterteilt werden. Abzubilden sind alle Funktionalitäten, die im Pflichtenheft in
Abschnitt 5.1 aufgelistet wurden. Begonnen wird mit dem Design der
Mitarbeiterverwaltung , deren Funktionen und Dialoge im Pflichtenheft Kapitel 3.2.2
konzipiert wurden.
Implementierung des Systems
66
6.1.1.1 Mitarbeiterverwaltung
Dialog:
Neuen
Mitarbeiter
anlegen
Dialog:
Projektliste
Mitarbeiter
A2
ok
cancel
Neu
anlegen
A8
A1
Projektliste
A7
Stand sichern
Dialog:
Mitarbeiter
anzeigen
A1
Hauptfunktion
Mitarbeiterverw.
A1
A4,A1
edit
delete
A5
ok
cancel
ok
Dialog:
Mitarbeiter
editieren
Abbildung 33 : Event-Diagramm der Funktionsgruppe Mitarbeiterverwaltung
Wie in Abbildung 33 dargestellt, kann der Benutzer über den Menüpunkt „Mitarbeiter“, der
sich in die Unterpunkte „Alle Mitarbeiter“ und „Mitarbeiter von PL“ und „Mitarbeiter-Archiv“
gliedert, die Mitarbeiterverwaltung aufrufen. Vom Dialog „Mitarbeiter anzeigen“ aus, in
dem eine Liste der Mitarbeiter angezeigt wird, eine je nach Menüpunkt „Alle Mitarbeiter“
oder „Mitarbeiter von PL“ selektierte Liste, können alle weiteren Funktionen der
Mitarbeiterverwaltung bedient werden:





Über den Button „Neu anlegen“ wird ein zweites Browserfenster geöffnet, in dem
die Daten für die Anlage eines neuen Mitarbeiters eingegeben werden können.
Nach Absenden dieser Daten über den „Anlegen“ Button wird der Datensatz am
Server gespeichert.
Jeder Mitarbeiter kann durch Anklicken des „Delete“ Icons in das Mitarbeiter
Archiv verschoben werden.
Durch das Icon „Editieren“ kann der Datensatz des Mitarbeiters im Dialog
„Mitarbeiter editieren“, in einem eigenem Browserfenster, bearbeitet werden.
Der Link „Projektanzahl“ führt zur Funktion „Projekte des Mitarbeiters“ der
Projektverwaltung.
Die Funktion „Mitarbeiterstand sichern“ ermöglicht das Abspeichern des aktuellen
Mitarbeiterstands als html-Datei.
Implementierung des Systems
67
Die hier beschriebenen Funktionen werden in der nachfolgenden Tabelle 2 Server-Actions
zugeordnet.
Aktion
Name der Server-Action
A1
Dialog „Mitarbeiter anzeigen“
iicm.pm.stafflist.action
A2
Dialog „Neuen Mitarbeiter anlegen“
iicm.pm.staffnew.action
A3
Aktion „Neuen Mitarbeiter anlegen“
iicm.pm.staffinsertnew.action
A4
Aktion „Mitarbeiter löschen“
iicm.pm.staffdelete.action
A5
Dialog „Mitarbeiter editieren“
iicm.pm.staffedit.action
A6
Aktion „Mitarbeiter editieren“
iicm.pm.staffchange.action
A7
Aktion „Mitarbeiterstand sichern”
iicm.pm.stafflistsave.action
A8
Dialog „Projektliste des Mitarbeiters"
iicm.pm.staffprojects.action
Tabelle 2: Zuordnung von Funktionen zu Server-Actions der Mitarbeiterverwaltung
6.1.1.2 Projektverwaltung
Dialog:
Neues
Projekt
Dialog:
Detailbeschr.
Projekt
A2
ok
Neu
anlegen
ok
cancel
A1
A7
Projektbeschreibung
Dialog:
Projekte
anzeigen
A1
Hauptfunktion
Projektverw.
A8
A4,A1
edit
delete
A5
ok
A4
A1
Stand
sichern
ok
cancel
Dialog:
Projekt
editieren
Abbildung 34: Event-Diagramm der Funktionsgruppe Projektverwaltung
Über den Menüpunkt „HAI-PL -> Projekte -> Alle Projekte“ oder „HAI-PL -> Projekte ->
Projekte von PL“ gelangt der Benutzer zur Hauptfunktion der Projektverwaltung. Wie im
Implementierung des Systems
68
Event-Diagramm in Abbildung 34 dargestellt, können von hier aus die folgenden
Funktionen aufgerufen werden:





Der Button „Neu anlegen“ ruft den Dialog „Neues Projekt“ in einem eigenen
Browserfenster auf, in dem Daten für ein neues Projekt eingegeben und
gespeichert werden können.
Um den Dialog für die Detailbeschreibung eines Projektes aufzurufen, muss der
Link im Projektnamen angeklickt werden. In diesem Dialog werden alle Daten des
Projekts und vorhandene Dateien in der Projekt-Collection angezeigt.
Bei jedem Projekt wird über ein Icon ein Link zum Dialog „Projekt editieren“
angeboten. Hier können bestehende Projektdaten verändert und gespeichert
werden.
Ebenfalls über ein Icon bei jedem Projekt kann dieses gelöscht werden.
Über den Button „Projektstand sichern“ wird die Projektliste als html-Datei
gespeichert.
In Tabelle 3 werden die beschriebenen Funktionen Server-Actions zugeordnet.
Aktion
6.1.1.3 Name der Server-action
A1
Dialog „Projekte anzeigen“
iicm.pm.projectlist.action
A2
Dialog „Neues Projekt anlegen“
iicm.pm.projectnew.action
A3
Aktion „Neues Projekt anlegen“
iicm.pm.projectinsertnew.action
A4
Aktion „Projekt löschen“
iicm.pm.projectdelete.action
A5
Dialog „Projekt editieren“
iicm.pm.projectedit.action
A6
Aktion „Projekt editieren“
iicm.pm.projectchange.action
A7
Dialog „Projektbeschreibung einz. Pr" iicm.pm.projectfull.action
Tabelle 3: Zuordnung von Funktionen zu Server-Actions der Projektverwaltung
6.1.1.4 Berichte
Die Funktionsgruppe Berichte unterteilt sich in „Allgemeiner- bzw. Statusbericht von PL ..“,
eine Funktion zum Check auf das Vorhandensein der Berichte für die PL-Sitzung und eine
Funktion zum markieren der Berichte der PL-Sitzung. Die Funktionen „Allgemeiner- bzw.
Statusbericht von PL ..“ werden direkt aud dem HAI-PL Menü aus aufgerufen und deshalb
nicht als Event-Diagramm dargestellt. Die erste hier beschriebene und in Abbildung 35
dargestellte Funktion, ist der Check auf Vorhandensein der Berichte für die PL-Sitzung.
A2
Mail senden
Dialog:
Fehl. Berichte
anzeigen
A1
Check auf vorh.
Berichte
Abbildung 35: Event-Diagramm der Funktionsgruppe „Berichte checken“
Implementierung des Systems
69
Aktion
Name der Server-Action
A1
Dialog „fehlende Berichte anzeigen“
iicm.pm.checkreportlist.action
A2
Aktion „Mail senden“
iicm.pm.checkreportmail.action
Tabelle 4: Zuordnung von Funktionen zu Server-Actions „Berichte checken“
Berichte, dazu zählen allgemeine Berichte und Statusberichte, die in die Pl-Sitzung
gelangen, werden mittels der Funktion „Berichte markieren“ gekennzeichnet, gesammelt
abgespeichert und für den Ausdruck vorbereitet.
HTML-File mit
allen Berichten
A3
A1
Neue Berichte
markieren
Markieren
Berichte
der
A2
Keine neuen
Berichte:
alte Berichte
speziell
markieren
Abbildung 36: Event-Diagramm der Funktionsgruppe „Berichte markieren“
Aktion
Name der Server-Action
A1
Aktion „vorh. Berichte markieren“
iicm.pm.stampreport.action
A2
Aktion „alte Berichte spez. markieren“ iicm.pm.stampreportold.action
A3
Aktion „HTML File generieren”
Iicm.pm.stampreportfile.action
Tabelle 5: Zuordnung von Funktionen zu Server-Actions „Berichte markieren“
Nachdem in diesem Abschnitt das genaue Verhalten des Projektkoordinations-Systems
mittels Event-Diagrammen untersucht und definiert wurde, kann in weiterer Folge mit dem
Design des Benutzerinterfaces begonnen werden. Anhand dieser beiden Komponenten,
den definierten Server-Actions und dem Frontend, wird der objektorientierte Entwurf
umgesetzt.
Implementierung des Systems
70
6.1.2 Benutzerinterface
In diesem Abschnitt soll exemplarisch der Entwurf des Benutzerinterfaces für das
Projektkoordinations-System dargestellt werden. Als Beispiel werden der Hauptdialog der
Mitarbeiterverwaltung und der Dialog zum Erstellen und Editieren von Mitarbeitern
verwendet.
6.1.2.1 Hauptdialog der Mitarbeiterverwaltung
Im Hauptdialog werden alle notwendigen Funktionen angeboten, um Mitarbeiterdaten
anlegen, editieren und löschen zu können. Der Dialog ist in Form einer Liste aufgebaut,
wie in Abbildung 37 dargestellt.
Abbildung 37: Hauptdialog der Mitarbeiterverwaltung
Die Funktion zum Sichern der Mitarbeiterliste wird über den Button „Mitarbeiterstand
sichern“ realisiert, die Funktion zum Anzeigen der Projektliste des jeweiligen Mitarbeiters
über einen Link in der Projektanzahl. Das Benutzerinterface sieht für die Menüpunkte „alle
Mitarbeiter“ und „Mitarbeiter von PL“ gleich aus, lediglich in der Darstellung des
Mitarbeiterarchivs wird anstelle des Icons zum Löschen und Editieren ein Icon zum
Wiederherstellen des Mitarbeiters angeboten.
6.1.2.2 Dialog zum Erstellen und Editieren eines Mitarbeiters
In diesem Dialog können die Mitarbeiterdaten eingegeben bzw. verändert und gespeichert
werden. Dieser Dialog wird in einem eigenen Browserfenster dargestellt, um den
Hauptdialog weiterhin zur Verfügung zu haben.
Abbildung 38: Dialog zum Anlegen und Editieren von Mitarbeiterdaten
Implementierung des Systems
71
Folgende Funktionen müssen beim Entwurf des Dialoges umgesetzt werden:


Eingabefelder, wie in Abbildung 38 dargestellt
Clientseitige Javascript Funktionen zum Prüfen der Pflichtfelder
Der Aufruf der notwendigen serverseitigen Funktionen, Mitarbeiterdaten anlegen und
Abbrechen, wird über zwei Buttons realisiert. Beim Dialog zum Editieren der
Mitarbeiterdaten wird der Titel des Dialoges geändert und die Eingabefelder mit den
Daten des entsprechenden Mitarbeiters vorbelegt.
Der Entwurf der Dialoge für die Projektverwaltung und die Funktionsgruppe Berichte
erfolgt analog, die Darstellung erfolgte bereits in Abschnitt 5.1 im Pflichtenheft. Nachdem
in diesem Abschnitt der Entwurf der Dialoge behandelt und in Abschnitt 6.1.1 die
Funktionalität des Systems und die zugehörigen Server-Actions beschrieben wurden,
kann im nächsten Abschnitt mit dem objektorientierten Entwurf begonnen werden.
6.1.3 Objektorientierter Entwurf
In diesem Abschnitt soll das Design der Javascript Objekte für das ProjektkoordinationsSystem beschrieben werden, welches für die Implementierung notwendig ist. Die Objekte
sollen in die folgenden Hauptgruppen unterteilt und im Anschluss beschrieben werden:






Objekte der Mitarbeiterverwaltung
Objekte zur Darstellung der Mitarbeiterverwaltung
Objekte der Projektverwaltung
Objekte zur Darstellung der Projektverwaltung
Berichtobjekte
Objekte zur Darstellung der Berichte
6.1.3.1 Objekte der Mitarbeiterverwaltung
Neben den notwendigen Attributen der Mitarbeiterverwaltung, welche im Pflichtenheft
ersichtlich sind, müssen die Objekte der Mitarbeiterverwaltung folgende Funktionalität
abdecken:




Methode zum Auslesen der Mitarbeiterattribute
Sichern der Mitarbeiterdaten
Verschieben des Mitarbeiters in das Mitarbeiterarchiv
„Wiederherstellen“ des Mitarbeiters aus dem Archiv
6.1.3.2 Objekte zur Darstellung der Mitarbeiterverwaltung
Diese Objekt decken die Funktionalität zum Darstellen der Dialoge dar. Neben den
notwendigen Methoden zur Erzeugung dieser Dialoge müsse folgende Funktionen
umgesetzt werden:


Darstellung der Mitarbeiterliste
Dialog zum Anlegen bzw. Editieren der Mitarbeiterdaten
Implementierung des Systems



72
Darstellung des Mitarbeiterarchivs
Sichern des Mitarbeiterstandes als html-Datei
Anzeige einer Liste der Mitarbeiterprojekte
6.1.3.3 Objekte der Projektverwaltung
Analog zu den Objekten der Mitarbeiterverwaltung, decken diese Objekte alle Attribute
und Grundfunktionalität der Projektverwaltung ab. Dies sind Methoden zum Auslesen der
Attribute, Sichern der Daten und Löschen des Projektes.
6.1.3.4 Objekte zur Darstellung der Projektverwaltung



Darstellung der Projektliste
Dialog zum Anlegen bzw. Editieren der Projektdaten
Sichern der Projektliste als html-Datei
6.1.3.5 Berichtobjekte
Berichtobjekte teilen sich in Objekte des Statusberichts und Objekte des Allgemeinen
Berichts. Da die Funktionalität dieser Objekte sehr ähnlich ist, und sie sich nur in der
Struktur unterscheiden wird hier nur vom Berichtobjekt gesprochen.


Methoden zum Auslesen der Berichtattribute
Methoden zum Speichern der Berichtdaten
6.1.3.6 Objekte zur Darstellung der Berichte
Umgesetzt werden müssen Methoden zum Anlegen und Editieren der Berichte.
Zur besseren Übersicht werden in der nachfolgenden Tabelle 13 alle Objekte des Projekt
Koordinations-Systems aufgelistet.
Objektname
Funktion
hw_StaffObject
Objekt der Mitarbeiterverwaltung
hw_StaffDialogObject
hw_ProjectObject
Darstellungsobjekt der Mitarbeiterverwaltung
Objekt der Projektverwaltung
hw_ProjectDialogObject
Darstellungsobjekt der Projektverwaltung
hw_ReportStatusObject
Objekt der Statusberichtverwaltung
hw_ReportStatusDialogObject
Darstellungsobjekt der Statusberichtverwaltung
hw_ReportGeneralObject
Objekt für den allgemeinen Bericht
hw_ReportGeneralDialogObject
Darstellungsobjekt für den allgemeinen Bericht
Tabelle 13: Objekte des Projekt Koordinations-Systems
Implementierung des Systems
73
6.2 Implementierung der Objekte
Die Implementierung der Objekte für das Projekt Koordinations-System, die im letzten
Abschnitt mit ihren Funktionen grob definiert wurden, wird in diesem Abschnitt genau
ausgearbeitet. Dafür ist es notwendig die einzelnen Variablen, Methoden und zu
übergebenden Parameter genau zu definieren.
6.2.1 Mitarbeiter Objekt
hw_StaffObject – abgeleitet von hwCollectionObject
6.2.1.1 Methoden
Methodenname
Funktion
getAttr ()
Auslesen der Mitarbeiter-Attribute
remove ()
Mitarbeiter löschen
insert ()
neuen Mitarbeiter einfügen
searchProjects ()
Liefert alle Projekte des Mitarbeiters
Tabelle 6: Methoden von hw_staffObject
6.2.1.2 constructor
Syntax:
new hw_StaffObject (parameter)
Parameter:
Wird der Constructor ohne Parameter aufgerufen so wird ein leeres
hw_StaffObject erzeugt, wird als Parameter eine staff_id übergeben so
werden die Attribute des Mitarbeiters am Server ausgelesen und das
hw_StaffObject damit instanziert. Wird der Mitarbeiter nicht gefunden so
wird ein leeres hw_StaffObject erzeugt.
Beschreibung:Die Klasse hw_StaffObject stellt die Möglichkeit dar ein neues
Mitarbeiterobjekt anzulegen, die Attribute auszulesen und es zu löschen.
6.2.1.3 getAttr ()
Returns:
Array der Mitarbeiter-Attribute
Beschreibung: liefert die Mitarbeiter-Attribute des hw_StaffObjects zurück.
6.2.1.4 remove ()
Returns:
true, falls das Objekt erfolgreich vom Server entfernt wurde, sonst false
Beschreibung:Wird diese Methode aus der Mitarbeiterverwaltung für alle Mitarbeiter
aufgerufen so wird das Objekt am Server gelöscht, sonst nur für den
entsprechenden PL. Mit dieser Methode wird das hw_StaffObject ungültig
Implementierung des Systems
74
und kann nicht mehr weiter verwendet werden. Wird der Mitarbeiter nur in
der PL-Mitarbeiterliste gelöscht so wird der Mitarbeiter auch aus allen
laufenden Projekten entfernt.
6.2.1.5 insert ()
Returns:
true, falls das Objekt erfolgreich am Server eingefügt wurde, sonst false
Beschreibung:fügt ein neues hw_StaffObject mit allen notwendigen Mitarbeiter-Attributen
am Server ein. Diese Methode steht nur für die allgemeine
Mitarbeiterverwaltung zur Verfügung.
6.2.1.6 searchProjects ()
Returns :
Array aus Proj_ID’s und Projektnamen
Beschreibung:Suchfunktion die alle Projekte dieses Mitarbeiters als Array der Projekt-ID’s
und Projektnamen zurückliefert.
6.2.2 Mitarbeiter – Dialog Objekt
hw_StaffDialogObject – abgeleitet von hwObject
6.2.2.1 Methoden
Methodenname
Funktion
showStaffAttr ()
Mitarbeiter-Attribute in Ausgabeform konv.
showNewStaffDlg ()
Dialog zum Anlegen eines neuen Mitarbeiters
showChangeStaffDlg ()
Dialog zum Ändern von Mitarbeiterdaten
showListStaffDlg ()
Dialog, der alle Mitarbeiter auflistet
saveStaffList ()
Mitarbeiterliste sichern
showStaffProjectDlg ()
Projekte des Mitarbeiters anzeigen
Tabelle 7: Methoden von hw_StaffDialogObject
6.2.2.2 constructor
Syntax:
new hw_StaffDialogObject (parameter)
Parameter:
Wird der Constructor ohne Parameter aufgerufen so wird ein leeres
hw_StaffDialogObject erzeugt, wird als Parameter eine staff_id übergeben
so wird das hw_StaffDialogObject für diesen Mitarbeiter instanziert.
Beschreibung:Das hw_StaffDialogObject stellt Dialoge zum Anlegen und Editieren von
Mitarbeiterobjekten, zum Anzeigen aller Mitarbeiter und der Projekte des
Mitarbeiters zur Verfügung.
Implementierung des Systems
75
6.2.2.3 showStaffAttr ()
Syntax:
showStaffAttr (parameter)
Parameter:
Array der Mitarbeiter-Attribute
Beschreibung:Liefert die als Parameter übergebenen
hw_StaffObject‘s in Ausgabeform zurück
Mitarbeiter-Attribute
des
6.2.2.4 showNewStaffDlg ()
Beschreibung:Stellt einen Dialog zum Anlegen eines neuen Mitarbeiters zur Verfügung. In
diesem Dialog kann der Benutzer alle notwendigen Attribute des
Mitarbeiters setzen und diesen anschließend anlegen. Dieser Dialog steht
nur für die allgemeine Mitarbeiterverwaltung zur Verfügung.
6.2.2.5 showChangeStaffDlg ()
Beschreibung:Stellt einen Dialog zum Editieren der Mitarbeiter-Attribute zur Verfügung. Es
können alle mitarbeiterspezifischen Attribute des hw_StaffObjects geändert
werden, jedoch nur in der allgemeinen Mitarbeiterverwaltung.
6.2.2.6 showListStaffDlg ()
Syntax:
showListStaffDlg(PL_ID)
Parameter:
PL_ID des PL dessen Mitarbeiter angezeigt werden sollen. Werden keine
Parameter übergeben, so werden alle Mitarbeiter angezeigt..
Beschreibung:Die Liste der Mitarbeiter eines bestimmten PL‘s wird aus allen laufenden
Projekten, Diplomarbeiten, usw. des PL’s erstellt, die Liste aller Mitarbeiter
aus dem Verzeichnis PL-HAI/Mitarbeiter.
6.2.2.7 saveStaffList ()
Syntax:
saveStaffList(PL_ID)
Parameter:
PL_ID des PL’s dessen aktuelle Mitarbeiterliste gesichert werden soll. Wird
kein Parameter übergeben, so wird der aktuelle Mitarbeiterstand aller
Mitarbeiter gesichert.
Beschreibung:Die Sicherungsdatei mit dem aktuellen Mitarbeiterstand wird im Verzeichnis
des PL’s (HAI-PL/Berichte:xxx) gespeichert. Wird die Sicherung für alle
Mitarbeiter durchgeführt, so wird diese im Verzeichnis HAI-PL/ArchivMitarbeiter gespeichert.
Implementierung des Systems
76
6.2.2.8 showStaffProjectDlg ()
Syntax:
showStaffProjectDlg (parameter)
Parameter:
Staff_ID des Mitarbeiters für den die Projekte angezeigt werden sollen.
Beschreibung:Liefert eine Liste mit kurzer Beschreibung aller Projekte denen der
Mitarbeiter angehört. Es werden alle Projekte aus den Verzeichnissen
HAI-PL/ Projektleiter/Berichte: PL1/Laufende Projekte,
../Laufende Diplomarbeiten und ../Laufende EDV-Projekte aller
PL’s nach diesem Mitarbeiter durchsucht.
6.2.3 Projekt Objekt
hw_ProjectObject – abgeleitet von hwCollectionObject
6.2.3.1 Methoden
Methodenname
Funktion
getAttr ()
Auslesen der Projekt-Attribute
remove ()
Projekt löschen
insert ()
Neues Projekt einfügen
Tabelle 8: Methoden von hw_ProjectObject
6.2.3.2 constructor
Syntax:
new hw_ProjectObject (parameter)
Parameter:
Wird der Constructor ohne Parameter aufgerufen, so wird ein leeres
hw_ProjectObject erzeugt. Wird als Parameter eine project_id übergeben,
so werden die Attribute des Projektes am Server ausgelesen und das
hw_Project-Object damit erzeugt. Wird das Projekt nicht gefunden, so wird
ein leeres hw_ProjectObject erzeugt.
6.2.3.3 getAttr ()
Returns:
Array der Projekt-Attribute
Beschreibung: liefert die Projekt-Attribute des hw_ProjectObject zurück
6.2.3.4 remove ()
Returns:
true, falls das Objekt erfolgreich vom Server entfernt wurde, sonst false
Implementierung des Systems
77
Beschreibung:Das Objekt wird am Server gelöscht. Mit dieser Methode wird das
hw_ProjectObject ungültig und kann nicht mehr weiter verwendet werden.
6.2.3.5 insert ()
Returns:
true, falls das Objekt erfolgreich am Server eingefügt wurde, sonst false
Beschreibung:fügt ein neues hw_ProjectObject mit allen notwendigen Projekt-Attributen
am Server ein.
6.2.4 Projekt – Dialog Objekt
hw_ProjectDialogObject – abgeleitet von hwObject
6.2.4.1 Methoden
Methodenname
Funktion
showProjectAttr ()
Projekt-Attribute in Ausgabeform
showNewProjectDlg ()
Dialog zum Anlegen eines neuen Projektes
showChangeProjectDlg ()
Dialog zum Ändern von Projektdaten
showListProjectDlg ()
Dialog, der alle Projekte auflistet
displayFullObject ()
darstellen aller Attribute des Projektobjektes
Tabelle 9 : Methoden von hw_ProjectDialogObject
6.2.4.2 constructor
Syntax:
new hw_ProjectDialogObject (parameter)
Parameter:
Wird der Constructor ohne Parameter aufgerufen, so wird ein leeres
hw_ProjectDialogObject erzeugt. Wird als Parameter eine project_id
übergeben so wird das hw_ProjectDialogObject für dieses Objekt
instanziert.
Beschreibung:Das hw_ProjectDialogObject stellt Dialoge zum Anlegen und Editieren von
Projektobjekten, zum Anzeigen aller Projekte und der umfangreichen
Version der Projektdaten zur Verfügung.
6.2.4.3 showProjectAttr ()
Syntax:
showProjectAttr (parameter)
Parameter:
Array der Projekt-Attribute
Implementierung des Systems
78
Beschreibung:Liefert die als Parameter übergebenen Attribute des hw_ProjectObject’s in
Ausgabeform zurück.
6.2.4.4 showNewProjectDlg ()
Beschreibung:Stellt einen Dialog zum Anlegen eines neuen Projektes zur Verfügung. In
diesem Dialog kann der Benutzer alle notwendigen Attribute des Projektes
setzen und dieses anschließend am Server einfügen.
6.2.4.5 showChangeProjectDlg ()
Beschreibung:Stellt einen Dialog zum Editieren der Projekt-Attribute zur Verfügung. Es
können alle projektspezifischen Attribute des hw_ProjectObjects geänder
werden.
6.2.4.6 showListProjectDlg ()
Syntax:
showListProjectDlg(PL_ID)
Parameter:
PL_ID des PL dessen Projekte angezeigt werden sollen.
Beschreibung:Diese Methode liefert einen Dialog der alle laufenden Projekte,
Diplomarbeiten und EDV-Projekte des PL’s auflistet.
6.2.5 Statusbericht - Objekt
hw_ReportStatusObject – abgeleitet von hw_ProjectObject
6.2.5.1 Methoden
Methodenname
Funktion
getStatusAttr ()
auslesen der Status-Attribute
Tabelle 10: Methoden von hw_ReportStatusObject
6.2.5.2 constructor
Syntax:
new hw_ReportStatusObject (parameter)
Parameter:
Wird der Constructor ohne Parameter aufgerufen, so wird ein leeres
hw_ReportStatusObject erzeugt. Wird als Parameter eine PL_ID
übergeben, so wird das hw_ReportStatusObject damit erzeugt.
6.2.5.3 getStatusAttr ()
Returns:
Array der Status-Attribute
Implementierung des Systems
79
Beschreibung: liefert die zusätzlichen Status-Attribute des hw_ReportStatusObject’s
zurück.
6.2.6 Statusbericht – Dialog Objekt
hw_ReportStatusDlgObject – abgeleitet von hw_ProjectDialogObject
6.2.6.1 Methoden
Methodenname
Funktion
showStatusAttr ()
Status-Attribute in Ausgabeform
showChangeStatusDlg ()
Dialog zum Ändern von Status-Attributen
showStatusDlg ()
Dialog zum Anzeigen des Statusberichtes
Tabelle 11: Methoden von hw_ReportStatusDlgObject
6.2.6.2 constructor
Syntax:
new hw_ReportStatusDlgObject (parameter)
Parameter:
Wird der Constructor ohne Parameter aufgerufen, so wird ein leeres
hw_ReportStatusDlgObject erzeugt. Wird als Parameter eine PL_ID
übergeben so wird das Objekt für diesen PL instanziert.
Beschreibung:Das hw_ReportStatusDlgObject stellt Dialoge zum Anlegen, Editieren und
Anzeigen des Statusberichtes zur Verfügung.
6.2.6.3 showStatusAttr ()
Syntax:
showProjectAttr (parameter)
Parameter:
Array der Statusberichts-Attribute
Beschreibung:Liefert
die
als
Parameter
übergebenen
hw_ReportStatusObject’s in Ausgabeform zurück.
Attribute
des
6.2.6.4 showChangeStatusDlg ()
Beschreibung:Stellt einen Dialog zum Editieren der Status-Attribute zur Verfügung. Als
Editiergrundlage dienen die Daten des vorangegangenen Statusberichtes.
6.2.7 AllgemeinerBericht - Objekt
hw_ReportGeneralObject – abgeleitet von hw_Object
Implementierung des Systems
80
6.2.7.1 Methoden
Methodenname
Funktion
getAttr ()
Auslesen der Bericht-Attribute
Tabelle 12: Methoden von hw_ReportGeneralObject
6.2.7.2 constructor
Syntax:
new hw_ReportGeneralObject (parameter)
Parameter:
Wird der Constructor ohne Parameter aufgerufen so wird ein leeres
hw_ReportGeneralObject erzeugt. Wird als Parameter eine PL_ID
übergeben, so wird das hw_ReportGeneralObject damit erzeugt.
6.2.7.3 getAttr ()
Returns:
Array der Bericht-Attribute
Beschreibung: liefert die Attribute des hw_ReportGeneralObjekts zurück.
6.2.8 AllgemeinerBericht – Dialog Objekt
hw_ReportGeneralDlgObject – abgeleitet von hwObject
6.2.8.1 Methoden
Methodenname
Funktion
showChangeReportDlg()
Dialog zum Ändern von Berichtdaten
Tabelle 13: Methoden von hw_ReportGeneralDlgObject
6.2.8.2 constructor
Syntax:
new hw_ReportGeneralDlgObject (parameter)
Parameter:
Wird der Constructor ohne Parameter aufgerufen, so wird ein leeres
hw_ReportGeneralDlgObject erzeugt. Wird als Parameter eine PL_ID
übergeben, so wird das Objekt für diesen PL instanziert.
Beschreibung:Das hw_ReportGeneralDlgObject stellt einen Dialog zum Editieren des
Allgemeinen Berichtes zur Verfügung.
Implementierung des Systems
81
6.2.8.3 showChangeStatusDlg ()
Beschreibung:Stellt einen Dialog zum Editieren der Attribute des Allgemeinen Berichtes
zur Verfügung. Als Editiergrundlage dienen die Daten des
vorangegangenen Berichtes.
6.3 Zusammenfassung
Ausgehend von den Ergebnissen des Untersuchungsbereichs, dem in Abschnitt 5.1
daraus abgeleiteten Pflichtenheft und den in Abschnitt 5.2 bis 5.4 festgelegten
Rahmenbedingungen, wurde in Abschnitt 6 das Design für die Umsetzung des Projekt
Koordinations-Systems festgelegt.
Für diesen technischen Entwurf mussten in Abschnitt 6.1.1 alle Funktionalitäten und
Abläufe in Form von Event-Diagrammen entworfen und dargestellt werden. Darauf
aufbauend wurde eine Server-Action für jede Funktion bzw. jedes Event definiert und
diesem zugeordnet.
In Abschnitt 6.1.2 wurden an je einem Beispiel der Entwurf und das Design der Dialoge
für das Projekt Koordinations-System dargestellt, wobei alle Listen und Dialoge nach
demselben Prinzip und Design erstellt wurden.
Mit diesen in Abschnitt 6.1.1 und 6.1.2 vorbereiteten Komponenten wurde in Abschnitt
6.1.3 der objektorientierte Entwurf umgesetzt. Dabei wurden alle Objekte für das Projekt
Koordinations-System definiert und deren Zuständigkeit bzw. Funktion festgelegt.
Dieser strukturierte Entwurfsprozess ist bei komplexen Systemen notwendig, um die
Qualität der zu entwickelnden Software garantieren zu können. Durch die Verwendung
der beschriebenen Hilfsmittel, den Einsatz von Standardkomponenten und die
Modularisierung von großen Projekten ist es möglich, das Design effizient und rasch zu
erstellen.
Abschließend konnte in Abschnitt 6.1.3 die Implementierung der Objekte umgesetzt
werden. Hier wurden alle Details der Objekte wie Variablen, Methoden und Parameter
genau definiert, um das System ausprogrammieren zu können. Erfahrungsgemäß nimmt
das Programmieren des Systems am meisten Zeit in Anspruch und stellt somit den
größten Teil dieser Diplomarbeit dar.
Ausblick
82
7 Ausblick
Das im Rahmen dieser Diplomarbeit umgesetzte Projekt Koordinations-System wurde
nach den Anforderungen des IICM umgesetzt. Die Umsetzung in dieser Form ergab sich
einerseits durch die Ergebnisse im ersten Teil dieser Arbeit, dem Untersuchungsbereich,
andererseits durch die speziellen Anforderungen und Rahmenbedingungen des IICM.
Bei der Umsetzung wurden alle Anforderungen, die im Pflichtenheft in Abschnitt 5.1
dargestellt wurden umgesetzt. Dennoch sind folgende Erweiterungen bzw.
Verbesserungen denkbar und in Zukunft sinnvollerweise zu realisieren:




Mehrsprachigkeit des Systems, zumindest Deutsch und Englisch. Dabei kann auf
Funktionalitäten des Hyperwave Information Servers aufgesetzt werden, der diese
Unterstützung standardmäßig bietet.
Ausbau der Informationen über Mitarbeiter und Projekte. Dies würde eine
Erweiterung der Attribute der einzelnen Objekte bedeuten.
Erstellung einer Installationsroutine um zukünftige Installationen des Systems
einfacher und rascher vornehmen zu können. Dabei müssten sowohl alle
notwendigen Verzeichnisse und User angelegt, als auch der Programmcode
installiert werden.
Unterstützung von Abläufen durch Hinterlegung mit einem Workflow. Im Moment
ist lediglich eine Mailbenachrichtigung bei nicht vorhandenen Berichten und eine
„Markierfunktion“ für Berichte implementiert. Hier wären verschiedene Workflows,
bei fehlenden Mitarbeiter bzw. Projektinformationen oder unvollständigen
Berichten denkbar.
Zusammenfassung
83
8 Zusammenfassung
Um den Leser dieser Arbeit an die verschiedenen Problemstellungen im
Projektmanagement heranzuführen, wurden in Abschnitt 2 Grundlagen beschrieben und
auch ein Zusammenhang zwischen Projektmanagement und Knowledge Management
hergestellt. Hier wurde versucht die Definition und Charakteristik von verschiedenen
Projektmanagementbegriffen, wie Projekt, Projektmanagement oder Projektsteuerung
aufzuzeigen.
Weiters wurden Teilaufgaben der Projektsteuerung veranschaulicht und der Einfluss und
die Auswirkungen auf den Verlauf eines Projektes beschrieben. Abschließend wurden die
Unterschiede und der Weg vom traditionellen Projektmanagement hin zum
wissensorientierten Projektmanagement dargestellt.
In
Abschnitt
3
wurden
Anforderungen
an
die
große
Gruppe
der
Projektmanagementsysteme aufgezeigt. Behandelt wurden allgemeine Anforderungen,
Erwartungen, die an solche System gesetzt werden, und Funktionalitäten, die am Markt
als Standard angesehen werden. Da sich das IICM mit der Entwicklung von
Softwaresystemen beschäftigt und sich das Projektmanagement in dieser Branche
mitunter von anderen Branchen differenziert, wurde versucht daraus entstehende
Anforderungen zu spezifizieren. Die für die weitere Arbeit notwendigen Anforderungen
des IICM wurden im Abschluss von Abschnitt 3 dargestellt.
Nicht immer ist die Entwicklung eines speziellen Softwarepaketes für das Unternehmen
die beste und ökonomisch günstigste Variante. Oftmals ist die Verwendung eines
Standardpaketes, unter Umständen in angepasster Form, wesentlich effizienter. Genau
mit dieser Entscheidungsfindung beschäftigt sich Abschnitt 4. Es werden am Markt
befindliche
Systeme
analysiert
und
deren
Systemvoraussetzungen
und
Integrationsfähigkeit am IICM behandelt. Aufbauend auf diese Ergebnisse wird versucht
eine Entscheidung für das IICM zu finden. Da am IICM viel Know How in diesem Bereich
vorhanden ist und die notwendige Infrastruktur besteht, wurde beschlossen, das Projekt
Koordinations-System selbst zu entwickeln und zu betreuen.
Der zweite Teil dieser Arbeit, der Gestaltungsbereich, beschäftigt sich mit der Umsetzung
des Projekt Koordinations-Systems. Dafür ist es notwendig einleitend ein Pflichtenheft zu
erstellen, um genau definierte Anforderungen zu erhalten. Hier wird beschrieben, welche
Funktionalitäten mit dem System umzusetzen sind, welche Rahmenbedingungen und
Designvorgaben eingehalten werden müssen. Als Grundlage ist es zusätzlich notwendig
einzusetzende Infrastrukturen und deren Verwendung zu evaluieren. In Abschnitt 5.2 wird
der Hyperwave Information Server, dessen Elemente, Securitymöglichkeiten,
Suchfunktionalitäten und die Gruppen- und Benutzerverwaltung beschrieben. Ebenso
werden die Möglichkeiten des Hyperwave Information Server aufgezeigt, Information und
Präsentation zu trennen, Objekte verschiedenster Typen strukturiert abzulegen und Links
zu managen.
Die verschiedenen Varianten, die der Hyperwave Information Server bietet um
Applikationen zu entwickeln und diese am Server einzubinden, werden in Abschnitt 5.3
aufgezeigt. Es wird kurz auf die Programmiersprache Place eingegangen, auf die
Applikationsentwicklung mit serverseitigem Javascript und die am IICM entwickelte
Objektbibliothek HWLIB. Abschließend wurde in Kapitel 5 noch auf die notwendigen
Zusammenfassung
84
Schritte beim Einbinden von Eigenentwicklungen am Hyperwave Information Server
eingegangen.
Beim eigentlichen Umsetzungsprozess muss als erstes das Design der Implementierung
erarbeitet werden. Dafür ist es notwendig, den Ablauf und das Verhalten der Applikation
mittels Event-Diagrammen festzulegen, daraus die Dialoge und Funktionen zu entwickeln
und das Benutzerinterface zu gestalten. Da die Implementierung objektorientiert und mit
serverseitigem Javascript erfolgen soll, werden die zuvor definierten Funktionalitäten im
objektorientierten Entwurf den jeweiligen Objekten zugeordnet.
Die eigentliche Implementierung der Javascript Objekte umfasst die genaue Definition der
Objektvariablen und -methoden, unterteilt in drei Gruppen. Eine Gruppe ist die
Mitarbeiterverwaltung. Hier wird je ein Objekt zur Manipulation und zur Darstellung der
Mitarbeiterdaten umgesetzt. Analog werden Objekte für die Gruppe der Projektverwaltung
und Berichte implementiert.
Als Abschluss dieser Arbeit werden in Abschnitt 7 Möglichkeiten für die Erweiterung des
Projekt Koordinations-Systems dargestellt. Sowohl Verbesserungen des Systems, als
auch Ideen für eine spätere Projektphase bzw. Version 2 werden aufgezeigt.
9 Abbildungsverzeichnis
[1]
Projektphasen und die zugehörigen PM-Aufgaben
Quelle siehe Literaturverzeichnis [Turowski 2000]
[2]
Prozentualer Anteil der Projektmanagement-Kosten an den Gesamtprojekt-Kosten
Quelle siehe Literaturverzeichnis [Turowski 2000]
[3]
Meilenstein Trendanalyse
Quelle siehe Literaturverzeichnis [PM-Fibel]
[4]
Trends im Projektmanagement
Quelle siehe Literaturverzeichnis [Schindler et.al.]
[5]
MS Project Central - Persönliche Aufgaben und Gant Chart
Quelle siehe Literaturverzeichnis [Microsoft 2000b]
[6]
MS Project Central - Timesheet
Quelle siehe Literaturverzeichnis [Microsoft 2000b]
[7]
MS Project Central - Status Report
Quelle siehe Literaturverzeichnis [Microsoft 2000b]
[8]
Enact Enterprise System 5.0 - System Architektur
Quelle siehe Literaturverzeichnis [Enact 2000]
[9]
Enact Enterprise System 5.0 - ActionPlan
Quelle siehe Literaturverzeichnis [Enact 2000]
[10]
Enact Enterprise System 5.0 - ActionTask
Quelle siehe Literaturverzeichnis [Enact 2000]
[11]
Enact Enterprise System 5.0 - ActionView
Quelle siehe Literaturverzeichnis [Enact 2000]
[12]
Enact Enterprise System 5.0 - ActionAdmin
Quelle siehe Literaturverzeichnis [Enact 2000]
[13]
Celoxis - myHome
Quelle siehe Literaturverzeichnis [Celoxis OD]
[14]
Celoxis - Projektverwaltung
Quelle siehe Literaturverzeichnis [Celoxis OD]
[15]
Celoxis - Ressourcen Verwaltung
Quelle siehe Literaturverzeichnis [Celoxis OD]
[16]
Celoxis - Kundenliste
Quelle siehe Literaturverzeichnis [Celoxis OD]
[17]
PHP-Projekt - Hauptansicht Projekte
Quelle sihe Literaturverzeichnis [PHPProjekt 2002]
[18]
PHP-Projekt – Projektformular
Quelle sihe Literaturverzeichnis [PHPProjekt 2002]
[19]
PHP-Projekt – Zuweisen von Arbeitszeit auf verschiedene Projekte
Quelle sihe Literaturverzeichnis [PHPProjekt 2002]
[20]
PHP-Projekt – Erweitertet Terminkalender
Quelle sihe Literaturverzeichnis [PHPProjekt 2002]
[21]
TUTOS - Persönliche Startseite – myTutos
Quelle sihe Literaturverzeichnis [TUTOS 2002]
[22]
TUTOS – Projektansicht
Quelle sihe Literaturverzeichnis [TUTOS 2002]
[23]
TUTOS – Projektdaten Eingabemaske
Quelle sihe Literaturverzeichnis [TUTOS 2002]
[24]
TUTOS – Timetrack
Quelle sihe Literaturverzeichnis [TUTOS 2002]
[25]
TUTOS – Aufgabe erstellen
Quelle sihe Literaturverzeichnis [TUTOS 2002]
[26]
TUTOS – Gant Diagramm
Quelle sihe Literaturverzeichnis [TUTOS 2002]
[27]
Hyperwave Suchdialog
Quelle siehe Literaturverzeichnis [HWIS UG]
[28]
Hyperwave Rechte Wizard
Quelle siehe Literaturverzeichnis [HWIS UG]
[29]
Hyperwave "Neuer Benutzer" Wizard
Quelle siehe Literaturverzeichnis [HWIS UG]
[30]
Hyperwave "Neue Gruppe" Wizard
Quelle siehe Literaturverzeichnis [HWIS AG]
[31]
Objekte Hierarchie der HWLIB
Quelle siehe Literaturverzeichnis [HWIS PG]
[32]
Verzeichnisstruktur für HWIS Module
Quelle siehe Literaturverzeichnis [HWIS PG]
[33]
Event-Diagramm der Funktionsgruppe Mitarbeiterverwaltung
[34]
Event-Diagramm der Funktionsgruppe Projektverwaltung
[35]
Event-Diagramm der Funktionsgruppe „Berichte checken“
[36]
Event-Diagramm der Funktionsgruppe „Berichte markieren“
[37]
Hauptdialog der Mitarbeiterverwaltung
[38]
Dialog zum Anlegen und Editieren von Mitarbeiterdaten
10 Beispielverzeichnis
[1]
Verschiedene Möglichkeiten der Javascript Einbindung am HWIS
Quelle siehe Literaturverzeichnis [HWIS PG]
[2]
Beispiel für eine Komponenten Master Datei (searchMaster.html)
Quelle siehe Literaturverzeichnis [HWIS PG]
[2]
Menüeintrag für das Projektkoordinations-System
Quelle HAI-PL Sourcecode
11 Tabellenverzeichnis
[1]
Javascript Objekte am HWIS
Quelle siehe Literaturverzeichnis [HWIS PG]
[2]
Zuordnung von Funktionen zu Server-Actions der Mitarbeiterverwaltung
[3]
Zuordnung von Funktionen zu Server-Actions der Projektverwaltung
[4]
Zuordnung von Funktionen zu Server-Actions „Berichte checken“
[5]
Zuordnung von Funktionen zu Server-Actions „Berichte markieren“
[6]
Methoden von hw_staffObject
[7]
Methoden von hw_StaffDialogObject
[8]
Methoden von hw_ProjectObject
[9]
Methoden von hw_ProjectDialogObject
[10]
Methoden von hw_ReportStatusObject
[11]
Methoden von hw_ReportStatusDlgObject
[12]
Methoden von hw_ReportGeneralObject
[13]
Objekte des Projekt Koordinations-Systems
12 Literaturverzeichnis
[Blümlinger 2003]
Blümlinger, K.: Projektmanagement-Vorlesung; Institut für Informationsverarbeitung und
Computergestützte neue Medien (IICM), Technische Universität Graz, 2003, last visit 200312-10,
URL http://courses.iicm.edu/project_management/unterlagen/project_management_main.pdf
[Celoxis 2000a]
Celoxis: Faq; Pune, India, 2000, last visit 2002-08-23
URL http://www.celoxis.com
[Celoxis 2000b]
Celoxis: Fact Sheet; Pune, India, 2000, last visit 2002-08-22
URL http://www.celoxis.com
[Celoxis OD]
Celoxis: Online Demo; 2000, last visit 2002-08-22
URL http://www.celoxis.com
[Elei 1996]
Elei, J.: Rahmenbedingungen des computergestützten Projektmanagements und
Evaluierung ausgewählter Werkzeuge; Universität Koblenz, Institut für Wirtschaftsinformatik,
1996
[Enact 2000]
Enactex Inc.: Enact Enterprise System 5.0; Campbell, California, 2000, last visit 2002-08-12,
URL http://www.enact.cc
[Enact UG]
Enactex Inc.: Enact Enterprise System 5.0.Enact User Guide; Campbell California, 2000,
last visit 2002-07-25,
URL http://www.enact.cc
[Gareis 1999]
Gareis, R.: PM Baseline; Projektmanagement Austria, 1999, last update 1999-11-01, last
visit 2000-11-25,
URL www.wu-wien.ac.at/projekt/pm
[Gupta et al. 1996]
Gupta, L., Chionglo, J.F., Fox, M.S.: A Constraint Based Model of Coordination in
Concurrent Design Projects; IEEE, Proceeding of the Workshops on Enabling Technologies:
Infrastructure for Collaborative Enterprises (WET ICE 1996), IEEE Computer Society Press,
1996, and
URL http://www.eil.utoronto.ca/kbd/papers/gupta-wetice96.pdf
[Holz et al. 1998]
Holz, H., Goldmann, S., Maurer F.: Working Group Report on Coordinating Distributed
Software Development Projects; University of Kaiserslautern, AG Expert Systems, WET ICE
1998, IEEE Computer Society Press, 1998, and
URL http://wwwagse.informatik.uni-kl.de/publications/paper/wetice-1998c.pdf
[HWIS UG]
Hyperwave AG i.G.: Hyperwave Information Server.Users Guide; Munich, Germany
[HWIS PG]
Hyperwave AG i.G.: Hyperwave Information Server.Users Guide; Munich, Germany
[HWIS AG]
Hyperwave AG i.G.: Hyperwave Information Server.Users Guide; Munich, Germany
[HWLIB RG]
Wurzenberger, G.: HWLIB Reference Guide; Institut für Informationsverarbeitung und
Computergestützte neue Medien (IICM), Technische Universität Graz, 2000, last visit 200301-26, URL http://www2.iicm.edu/cguetl/education/projects/gwurze/hw_main.ps
[Kötting et al. 1999]
Kötting, B., Maurer, F.: Approaching Process Support for Virtual Software Corporations;
University of Kaiserslautern, 1999, last visit 1003-12-10,
URL http://sern.ucalgary.ca/~maurer/ICSE99WS/Submissions/Koetting/Koetting.html
[Lichter 1999]
Lichter, H.: SW-Projektmanagement; Skriptum zur Vorlesung, RWTH Aachen, 1999, last
visit 2001-01-20,
URL www-lufgi3.informatik.rwth-aachen.de/LUFGI3/EDUCATION/WS99_00/VL_SPM/INFOS/
[Mach 2001]
Mach: Grundlagen des Projektmanagements; Skriptum zur Vorlesung, TU Berlin,
Fachgebiet Innovations- und Technologiemanagement, 2001, last visit 2003-06-02,
URL http://www.tim.tuberlin.de/lehre/archiv/02ws/02ws_vorlesung_projektmanagement/download/pm_mach1.pdf
[Maurer 1996a]
Maurer, F.: Computer Support in Project Coordination;
IEEE, Proceeding of the Workshops on Enabling Technologies: Infrastructure for
Collaborative Enterprises (WET ICE 1996), IEEE Computer Society Press, 1996
[Maurer 1996b]
Maurer, F.: Project Coordination in Design Processes; IEEE, Proceedings of the Workshops
on Enabling Technologies: Infrastructure for Collaborative Enterprises (WET ICE 96), IEEE
Computer Society Press, 1996, and
URL http://wwwagr.informatik.uni-kl.de/~maurer/WETICE96_Papers/Frank_Maurer
[Maurer 1996c]
Maurer, H.: Hyper-G now Hyperwave.The next generation web solution; Addison Welsley
Longman, 1996
[Microsoft 2000a]
Microsoft Corporation: Microsoft Projekt 2000.Feature Guide; Redmont, 2000, last visit
2002-07-16,
URL http://www.projectability.co.uk/downloads/project%202000%20features.doc
[Microsoft 2000b]
Microsoft Corporation: Microsoft Projekt 2000.Project Enhancements Guide; Redmont,
2000, last visit 2002-07-16, URL http://download.microsoft.com/download/c/2/8/c28831e9-684e4aab-9af3-f061bf68ad70/ProjPEG.doc
[Nastansky et al. 2000]
Nastansky, L., Ehlers, P.: Verteilte DV-Systeme in der Betriebswirtschaft;
Groupware Competence Center (GCC), Fachbereich Wirtschaftswissenschaften, Universität
Paderborn, 2000, last visit 2003-06-02,
URL http://pbfb5www.unipaderborn.de/__C1255ED9002504C7.nsf/0/665014A9CC4FB50F41256448004ABA78?Open
[Partel 2000]
Partel, A.: Management Manual - Können Mitarbeiter virtuell geführt werden?; Graduate
School of Business Administration Zurich, Seminararbeit, 2000, last visit 2003-06-02,
URL http://www.partel.de
[PHPProjekt 2002]
PHPProjekt: Dokumentation; 2002, last visit 2003-10-10, URL
http://www.phprojekt.com/documentation
[PM Center]
The Project Management Center,
URL http://www.infogoal.com/pmc
[PM-Fibel 1998]
Projektmanagement Fibel, Managementsoftware-Informationszentrum, 1998, last visit 200204-16
URL http://www.managementsoftware.de/msi-pm-fibel/einfuehrung/default.htm
[Rollet 2000]
Rollet, H.: Aspekte des Wissensmanagements; TU-Graz, Institut für
Informationsverarbeitung und Computergestützte Neue Medien (IICM), Diplomarbeit, 2000,
last visit 2003-12-10,
URL http://www.know-center.tugraz.at/de/divisions/publications/pdf/hrollett2000-01.pdf
[Schelle 1997]
Schelle, H.: Die Einführung in das Projektmanagement; Universität der Bundeswehr
München, Fakultät für Informatik, 1997, last visit 2000-11-16
URL http://emma.informatik.unibw-muenchen.de/inst5/lehre/SWEnII/Einfuehrung%20PM.pdf
[Schindler et al.1998]
Schindler, M., Hilb, M., Fausch, M.: Trends und Technologien im Rahmen der verteilten
Projektabwicklung; Universität St. Gallen, Institut für Medien- und
Kommunikationsmanagement, 1998, last visit 2001-08-14,
URL http://www.mcm.unisg.ch
[Schindler 1998]
Schindler, M.: Knowledge Management im Rahmen der verteilten Projektabwicklung;
Universität St. Gallen, Institut für Medien- und Kommunikationsmanagement, 1998, last visit
2002-02-08,
URL http://www.mcm.unisg.ch
[Schneider et al.1999]
Schneider, W.G., Hieber, D.: Software zur ressourcenbeschränkten Projektplanung; Institut
für Wirtschaftstheorie und Operations Research, Universität Karlsruhe, WIOR-Report 494,
1999, and
URL http://www.ubka.uni-karlsruhe.de/vvv/1997/wiwi/5/5.pdf
[Tomayko et al. 1989]
Tomayko, J.E., Hallman, H.K.: Software Project Management; The Wichita State University,
Software Engineering Institute, 1989, last visit 2002-07-16,
URL ftp://ftp.sei.cmu.edu/pub/documents/misc/cms/pdf//cm21.pdf
[TUTOS 2002]
TUTOS: Dokumentation; 2002, last visit 2003-10-01, URL http://www.tutos.org
[Turowski 2000]
Turowski, K.: DV-Projektmanagement; Skriptum zur Vorlesung, Arbeitsgruppe
Wirtschaftsinformatik, Universität Magdeburg, 2000, last visit 2000-11-17,
URL www-wi.cs.uni-magdeburg.de/lehre/ss2000/projekt/
[Vandersluis 2000]
Vanderluis, C.: Deploying a Project Management System; HMS-Software, PM-Times, 2000,
last visit 2001-05-09,
URL http://www.hmssoftware.ca/resourcecentre/articles/pm_times1.php
13 Anhang
13.1 Anhang A – CD-Rom
13.2 Anhang B – Pflichtenheft