Fakultat fur Informatik
Professur Verteilte und selbstorganisierende Rechnersysteme
Studienarbeit
Konzeption und Entwicklung eines webbasierten,
communitygestutzten Work
owmanagementsystems
(Codename Goal1)
Robert Krawatzeck
Michael Krug
Daniel Pouzemski
Chemnitz, den 01. Juni 2010
Prufer: Prof. Dr. Martin Gaedke
Betreuer: Dipl.-Inf. Jens Wegener

Krawatzeck, Robert
Krug, Michael
Pouzemski, Daniel
Konzeption und Entwicklung eines webbasierten, communitygestutzten Work
owma-
nagementsystems (Codename Goal1)
Studienarbeit, Fakultat fur Informatik
Technische Universitat Chemnitz, Juni 2010

Inhaltsverzeichnis
Abbildungsverzeichnis iii
Tabellenverzeichnis v
1 Einleitung 1
2 Entwicklung eines leichtgewichtigen, webbasierten Work
owmanagement-
systems 3
2.1 Stand der Technik . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 To-do-Listen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2 Grasche Spezikationssprachen . . . . . . . . . . . . . . . . . 6
2.1.3 XML-basierte Ausfuhrungssprachen . . . . . . . . . . . . . . . 7
2.1.4 Gantt-Diagramm . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.5 Open Work Bench . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Losungskonzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1 Begriserklarung . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.2 Projekt-Editor . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.3 Workpackages . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.4 Rollenbasiertes Rechtemanagement . . . . . . . . . . . . . . . 17
2.3 Realisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.1 Projekt-Editor . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.2 Workpackages . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3.3 Rollenbasiertes Rechtemanagement . . . . . . . . . . . . . . . 27
2.3.4 Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3 Aufbau einer Work
ow-Community 31
3.1 Stand der Technik . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1.1 Business Networking Sites . . . . . . . . . . . . . . . . . . . . 34
3.1.2 Social Networks . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.1.3 Content and Media Sharing Networks . . . . . . . . . . . . . . 35
3.1.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2 Losungskonzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.1 Die Hierarchie der Bedurfnisse . . . . . . . . . . . . . . . . . . 38
3.2.2 Leitfaden zum Entwickeln einer Online-Community . . . . . . 38
i

Inhaltsverzeichnis
3.2.3 Abbildung von Interessengruppen . . . . . . . . . . . . . . . . 42
3.2.4 Au
istung der in einer Community, Area oder einem Projekt
beteiligten Mitglieder . . . . . . . . . . . . . . . . . . . . . . . 42
3.2.5 Nutzerprole . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2.6 Bewertungs- / Reputationssysteme . . . . . . . . . . . . . . . 43
3.2.7 Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.3 Realisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.3.1 Strukturierung der Community -
"
das Konzept der
achen Hier-
archie\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.3.2 Sichtbarkeiten von Interessengruppen . . . . . . . . . . . . . . 49
3.3.3 Selbstdarstellung und Prasentation von Interessensgruppen im
Netz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4 Nutzung der Intelligenz der Massen 53
4.1 Stand der Technik . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.1.1 Google Wave . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.1.2 myExperiment . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.1.3 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.2 Losungskonzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.2.1 Wiederverwendung von Work
ows . . . . . . . . . . . . . . . . 62
4.2.2 Exploration von Work
ows . . . . . . . . . . . . . . . . . . . . 63
4.2.3 Dierenzierung von Work
ows . . . . . . . . . . . . . . . . . . 70
4.3 Realisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.3.1 Wiederverwendung durch Kopieren . . . . . . . . . . . . . . . 72
4.3.2 Exploration der Projekte . . . . . . . . . . . . . . . . . . . . . 76
5 Auswertung 83
6 Zusammenfassung und Ausblick 85
Literaturverzeichnis 87
ii

Abbildungsverzeichnis
2.1 ein Reisebuchungsprozess abgebildet mit BPMN [24] . . . . . . . . . 6
2.2 Ausschnitt aus dem BPEL-Code fur den in Abbildung 2.1 gezeigten
"
Check Credit Card\ Task [24] . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Gantt-Diagramm [25] . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Openworkbench Ober
ache . . . . . . . . . . . . . . . . . . . . . . . 9
2.5 Ausschnitt aus der Projektubersichts-Seite . . . . . . . . . . . . . . . 19
2.6 leere Bearbeitungsansicht des Projekteditors . . . . . . . . . . . . . . 20
2.7 Auszug der XML-Struktur des in Abbildung 2.8 dargestellten Work
ows 21
2.8 Darstellung eines Work
ows mittels des Projekteditors . . . . . . . . 22
2.9 XML-Struktur eines Beispiel-Workpackages . . . . . . . . . . . . . . . 25
2.10 Darstellung eines Workpackage-Formulars . . . . . . . . . . . . . . . 26
2.11 Eingabedaten eines Meilensteins . . . . . . . . . . . . . . . . . . . . . 26
2.12 Rollendenition in der Projekt-XML-Datei . . . . . . . . . . . . . . . 27
2.13 Ausschnitt der Dashboard-Ansicht . . . . . . . . . . . . . . . . . . . . 28
3.1 Die Maslowsche Bedurfnispyramide [1] . . . . . . . . . . . . . . . . . 38
3.2 Ubersichtsseite der Community
"
VSR\ . . . . . . . . . . . . . . . . . . 48
3.3 Ubersicht uber mogliche Sichtbarkeiten fur Communities, Areas und
Projekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.4 Detailseite der Community
"
VSR\ . . . . . . . . . . . . . . . . . . . . 51
4.1 Kodierung der Nachfolger-Beziehungen zwischen zwei Projekten mit-
tels RDF+XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.2 Speicherung der Tags als Resourcen in den Projektmetadaten . . . . 66
4.3 Query zur Abfrage von ahnlichen Resourcen . . . . . . . . . . . . . . 67
4.4 Kategorien des DBPedia in die
"
Berlin\ eingeordnet ist . . . . . . . . 68
4.5 Zu
"
Berlin\ ahnliche Ressourcen als Antwort von DBPedia . . . . . . 69
4.6 Berucksichtigung der Bewertungsinformationen in der globalen XML-
Datei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.7 Berucksichtigung der Bewertungsinformationen in der XML-Datei des
Nutzers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.8 Ordnerstruktur eines Projekts aus der Sicht einer Area . . . . . . . . 72
4.9 Interface zum Kopieren eines Projekts . . . . . . . . . . . . . . . . . 73
4.10 Projekt-XML vor dem Kopiervorgang . . . . . . . . . . . . . . . . . . 74
4.11 Projekt-XML nach dem Kopiervorgang . . . . . . . . . . . . . . . . . 75
iii

Abbildungsverzeichnis
4.12 Au
istung aller Projekte im Goal1 . . . . . . . . . . . . . . . . . . . 78
4.13 Au
istung der Communties, Areas und Projekte in Goal1 . . . . . . . 80
4.14 Community- und Areabaum im Dashboard eines Goal1 Nutzers . . . 81
4.15 Ubersicht der eigenen und involvierten Projekte eines Nutzers . . . . 82
iv

Tabellenverzeichnis
2.1 Bewertung der untersuchten Prozessdarstellungsarten . . . . . . . . . 11
3.1 Bewertung der untersuchten Community-Typen . . . . . . . . . . . . 37
3.2 Uberfuhrung der Bedurfnishierarchie in die Online-Welt [8] . . . . . . 41
4.1 Bewertung Google Wave und MyExperiment . . . . . . . . . . . . . . 61
5.1 Bewertung der erstellten Anwendung . . . . . . . . . . . . . . . . . . 83
v

1 Einleitung
In der heutigen Zeit hat man mit einer steigenden Flut an Aufgaben zu tun, welche
besonders schnell und ezient bewaltigt werden mussen. Auch Freizeit und Fami-
lienleben sind oft uberfullt mit Aktivitaten, denen man zugig nachzukommen hat.
Alltagliche Handlungen, beru
iche Arbeiten und Freizeitbeschaftigungen sind einem
Tempo unterworfen, das der Lebensqualitat an die Substanz geht. So leiden soziale
Kontakte und das Engagement in Interessengruppen liegt oft auerhalb der zeitlichen
Moglichkeiten.
Oftmals ist man aus beru
ichen Grunden standig unterwegs und es existiert kein
fester Arbeitsplatz mehr. Das
"
Mobile Oce\ spielt eine immer groere Rolle. Um
weiterhin konkurrenzfahig zu bleiben, ist man im Zeitalter der Globalisierung ge-
zwungen, Aufgaben ohne personliche Anwesenheit vor Ort zu erledigen. Der Zeit-
druck steigt und damit auch die Notwendigkeit sich zu organisieren und Aufgaben
ezient zu verwalten.
Bei der Bearbeitung von Aufgaben stot man selbst oft an die Grenzen der eigenen
Kompetenz und ist nicht in der Lage sich in der Kurze der Zeit weiterzubilden. So
werden Arbeiten nicht in der gewunschten Qualitat oder nicht in der vorgegebenen
Zeit erledigt.
Es existiert eine Reihe von Softwarelosungen im Bereich der Unterstutzung von Ab-
laufen und Aufgabenautomatisierung. Diese Losungen sind jedoch haug zu komplex
und erfordern einen hohen Lernaufwand. Des Weiteren sind viele Anwendungen an
eine bestimmte Plattform gebunden und bieten keine Moglichkeit zur kooperativen
Arbeit mit mehreren Benutzern. Fur Gruppenarbeit konzipierte Tools sind meist nur
in kleinen Gruppen einsetzbar und eignen sich nur begrenzt fur die Verwendung in
groen Umgebungen.
Spezialisten in unterschiedlichen Gebieten, dessen Rat entscheidend zur Erledigung
von eigenen Aufgaben sein konnte, sind oft im Internet in Online-Communities und
Foren unterwegs. Solche Communities bieten zwar eine ausgebaute Kommunikations-
und Kollaborationsinfrastruktur, sind jedoch zur Verwendung als ein Work
ow bzw.
Projektmanagementsystem kaum geeignet.
In der Regel unterliegen nicht nur komplexe, sondern auch alltagliche Prozesse einer
gewissen Grundstruktur. Anders ausgedruckt, folgen sie einem bestimmten Muster.
1

1 Einleitung
Diese Muster konnten im Rahmen einer Online-Plattform zwischen Nutzern ausge-
tauscht werden und die Erledigung der Aufgaben fur jeden Beteiligten fordern und
beschleunigen.
Das Ziel der Arbeit ist es, zu untersuchen, wie ein System realisiert werden kann,
welches die Vorteile eines Work
owmanagementsystems mit den Vorteilen des kolla-
borativen Ansatzes einer Online-Community kombiniert. Dabei soll das System fur
die Verwaltung von unternehmerischen Kernprozessen und Prozessen aus allen Be-
reichen des Alltags gleichermaen geeignet und somit universell einsetzbar sein.
Im Einzelnen soll das System:
 eine Plattform zum Austausch von Erfahrungen fur Nutzer zur Verfugung stel-
len, in der jeder seine Erfahrungen bei der Losung von Aufgaben mit Anderen
teilen kann. Grundsatzlich soll das System als Informations- und Wissensbe-
schaungsquelle dienen, um tagliche Probleme ezienter losen zu konnen.
 dem Nutzer bei der Bewaltigung der Komplexitat von Aufgaben helfen, indem
es hilfsbereite Personen in einer Online-Community organisiert.
 den Nutzer bei der Organisation und Ablaufkoordination wahrend der Durch-
fuhrung von Aufgaben durch einfach zu benutzende Werkzeuge unterstutzen.
Im Rahmen dieser Arbeit wird eine solche Anwendung unter der Bezeichnung
"
Goal1\
entwickelt. Die Erwahnung der Begrie "
System\,
"
Applikation\,
"
Plattform\, sowie
"
Community\ ist synonym dazu zu verstehen.
In den folgenden 3 Abschnitten werden die Moglichkeiten der Umsetzung dieser An-
forderungen naher untersucht. Zunachst wird im Abschnitt 2 untersucht, welche Form
der technischen und visuellen Unterstutzung zur Aufgabenerledigung besser geeignet
ist und anschlieend das Konzept eines einfach zu bedienenden webbasierten Work-
owmanagementsystems erlautert und implementiert.
Im Abschnitt 3 werden die Vorteile von communitybasierten Systemen aufgezeigt und
untersucht, inwiefern diese in Verbindung mit einem Work
owmanagementsystem
eingesetzt werden konnen.
Im Abschnitt 4 wird untersucht, wie eine Internetplattform aufgebaut werden kann,
deren Nutzer gemeinsam zum Erfahrungsaustausch und Aufbau eines Wissenspools
aktiv beitragen und wie der Erfahrungsaustausch selbst realisiert werden kann.
Abschlieend wird eine Bewertung der im Rahmen der Arbeit umgesetzten Software
anhand ausgewahlter Kriterien vorgenommen, sowie eine mogliche Weiterentwicklung
des Systems beleuchtet.
2

2.1 Stand der Technik
re eine To-do-Liste, welche mittlerweile auch webbasiert angeboten wird, wie zum
Beispiel von Remember The Milk (RTM)1 oder Toodledo2.
Jedoch fehlt es an einer Softwarelosung, welche die umfassenden Moglichkeiten zur
Strukturierung von Work
ows mit den Verwaltungsfunktionen von Work
owmana-
gementsystemen und dem geringen Lernaufwand von To-do-Listen vereint und platt-
formunabhangig uber das Web anbietet.
In den folgenden Kapiteln werden existierende Ansatze untersucht und bewertet.
Ferner wird das Konzept der eigenen Losung sowie deren Realisierung vorgestellt.
2.1 Stand der Technik
Da die Hauptfunktionalitat des zu entwickelnden Systems in der Erstellung und Ab-
arbeitung von verschiedensten Prozessablaufen bestehen soll, werden im folgenden
Kapitel bestehende Ansatze und Losungen zur Modellierung und Darstellung von
Prozessen vorgestellt und fur einen moglichen Einsatz im System bewertet. Es wer-
den To-do-Listen als einfache Hilfsmittel zur Aufgabenverwaltung vorgestellt, sowie
grasche Prozessplane am Beispiel von Gantt-Diagrammen und Spezikationsspra-
chen wie BPMN und BPEL untersucht.
2.1.1 To-do-Listen
Als grundlegende Werkzeuge zur Aufgabenverwaltung wurden To-do-Listen ange-
sprochen. Um den Funktionsumfang zu untersuchen, wurden zwei Online-Tools zur
Verwaltung solcher Listen untersucht. Zum einen Toodledo und zum anderen Re-
member The Milk (RTM). Diese bieten auf einfache Art und Weise eine Moglichkeit
sich eine (teilweise geordnete) Abfolge von Aufgaben (Tasks) anzulegen, um diese
spater abarbeiten zu konnen. Dabei besteht die Moglichkeit, sich eine Deadline, d.h.
ein gewisses Datum festzulegen, bis wann diese Aufgabe erfullt sein muss. Man kann
Eintrage kategorisieren und priorisieren. Einfache Zusammenarbeit ist uber "
Sharing\
gegeben. Man kann dabei seine Aufgaben mit anderen Personen sowohl nur lesend als
auch schreibend teilen, wobei schreibend noch in
"
kann Tasks erstellen\ und
"
kann
Tasks erledigen\ unterschieden werden kann. Bei Toodledo sind diese Optionen je-
doch zahlenden Nutzern vorbehalten. Abhangigkeiten sowie Nebenlaugkeit lassen
sich bei diesen Systemen jedoch nicht abbilden, was aber bei simplen Aufgabenlisten
auch keine Rolle spielt. [22] [15]
1http://www.rememberthemilk.com
2http://www.toodledo.com
5

2 Entwicklung eines leichtgewichtigen, webbasierten
Workflowmanagementsystems
Fur die Modellierung umfangreicher Work
ows ist diese Art der Aufgabenplanung
nicht verwendbar, da die Moglichkeiten zur Strukturierung solcher Work
ows nicht
gegeben sind. Jedoch ist eine Verwendung ahnlicher To-do-Listen als Mittel zur Struk-
turierung von Aufgaben vorgesehen.
2.1.2 Grasche Spezikationssprachen
Am Beispiel der Business Process Modeling Notation (BPMN) wurden grasche Spe-
zikationssprachen untersucht. Mittels Symbolen wird es ermoglicht, Arbeitsablaufe
zu modellieren und zu dokumentieren. Es lassen sich komplexe Prozess
usse erstel-
len, welche Abhangigkeiten, Schleifen und Verzweigungen enthalten konnen. Deniert
werden Activities (Aufgaben), Gateways (Entscheidungspunkte) und Events (Ereig-
nisse). Verbunden werden diese durch Flows (Nachrichten-Flusse), welche auch die
Reihenfolge der Ausfuhrung vorgeben. Dies ermoglicht einen sehr hohen Freiheits-
grad beim Spezizieren der Prozessmodelle. In Abbildung 2.1 wird dies durch einen
Prozess zur Reisebuchung exemplarisch dargestellt. Das konkrete Ausfuhren der er-
stellten Work
ows ist jedoch nicht Bestandteil dieser Sprache. [23]
Abbildung 2.1: ein Reisebuchungsprozess abgebildet mit BPMN [24]
6

2 Entwicklung eines leichtgewichtigen, webbasierten
Workflowmanagementsystems
2.1.4 Gantt-Diagramm
Ein weiteres bekanntes Werkzeug zur Darstellung von Arbeitsablaufen ist das Gantt-
Diagramm. In dieser Reprasentation eines Prozesses werden alle Aktivitaten in ihrer
zeitlichen Abfolge als Balken, mit ihrer der Bearbeitungsdauer entsprechenden Lange,
auf einer Zeitleiste dargestellt. Dadurch sind genaue Aussagen uber die benotigte Zeit
fur die Ausfuhrung der Tasks, als auch des gesamten Projektes moglich. Allerdings
gibt es starke Einschrankungen bei der Modellierung von Abhangigkeiten.
Bei einer wachsende Menge an Aufgaben wird das Gantt-Diagramm schnell unuber-
sichtlich, da neue Tasks eine neue Zeile ergeben und ihre Balkenreprasentation immer
weiter nach rechts verschoben wird, da die Position den Zeitraum ihrer Bearbeitung
darstellt. So dehnt sich das Diagramm sowohl horizontal als auch vertikal weit aus
und erschwert es dem Nutzer einen Uberblick uber das ganze Projekt zu erhalten.
Aus diesem Grund bietet sich das Gantt-Diagramm nur bei einer geringen bis mitt-
leren Anzahl an Aktivitaten an. Ebenso bindet man sich fruhzeitig an feste Termine
und muss vorher gut abschatzen, wie viel Zeit fur jede einzelne Aufgabe eingeplant
werden muss.
Einsatz ndet diese Darstellungsform in Software-Produkten wie zum Beispiel Gantt-
Project3, OpenProj 4 oder Microsoft Project5.
Abbildung 2.3: Gantt-Diagramm [25]
2.1.5 Open Work Bench
Mit Open Work Bench wurde ein Work
owmanagementsystem untersucht. Als Fea-
tures werden unter anderem auf der Webseite6 aufgefuhrt:
3http://www.ganttproject.biz
4http://www.serena.com/products/openproj/index.html
5http://office.microsoft.com/de-de/project/default.aspx
6http://www.openworkbench.org/index.php?option=com_content&task=view&id=
31&Itemid=41
8

2.1 Stand der Technik
 Projektplanung (Denition und Erstellung von Aktivitaten)
 Zeitplanung (manuell oder automatisch)
 Ressourcenmanagement (Denition von Ressourcen wie Mensch, Equipment
und Material; Zuweisung von Ressourcen zu Aufgaben)
 Berichterstellung (Status; prozentueller Fortschritt; erwartete Dauer)
 Visualisierung (Gantt- und PERT-Diagramme; kritischer Pfad)
Es handelt sich um eine Windows Desktop Anwendung ohne Netzwerkunterstutzung.
Das heit, es kann nur von einer Person zur Planung von Projekten verwendet werden.
Dies schrankt die Moglichkeiten der Nutzung auf verschiedenen Plattformen stark
ein und unterstutzt keine Koordination und Kooperation von mehreren Mitarbeitern
eines Projektes.
Abbildung 2.4: Openworkbench Ober
ache
Grundlegend wird alles uber Eintrage in speziellen Tabellen, wie in Abbildung 2.4
dargestellt, erstellt und verwaltet. Dies konnte einen unerfahrenen Anwender uberfor-
dern. Die Darstellung des Projektablaufs kann uber Gantt- oder PERT-Diagramme
(Program Evaluation and Review Technique) erfolgen. Ein PERT-Diagramm, auch
Ereignis-Knoten-Darstellung genannt, ist eine ereignisorientierte Netzplantechnik.
Man versucht damit, Abhangigkeiten im zeitlichen Ablauf von Projekten darzustel-
len. Insbesondere geht es darum, den sogenannten kritischen Pfad darzustellen. Dies
hilft zwar sein Projekt zu uberblicken und zeitlich einzuplanen, jedoch greifen bei
9

2 Entwicklung eines leichtgewichtigen, webbasierten
Workflowmanagementsystems
einer wachsenden Menge von Aufgaben die im Abschnitt zu Gantt-Diagrammen auf-
gefuhrten Nachteile, wie die mangelhafte Darstellung von Abhangigkeiten und die
nachlassende Ubersichtlichkeit. [10]
Da das zu erstellende System sowohl plattformunabhangig sein, umfassende Mog-
lichkeiten zur Zusammenarbeit bieten und auf komplizierte Eingabemasken { wie in
diesem Fall Tabellen { verzichten soll, entspricht dieses Produkt nicht den gewunsch-
ten Anforderungen.
2.1.6 Zusammenfassung
Im Folgenden werden die untersuchten Ansatze zur Prozessverwaltung nach ausge-
wahlten Kriterien bewertet.
Einfachheit: Unter diesem Kriterium ist der Aufwand zum Erfassen und Erlernen der
Strukturen und Moglichkeiten des jeweiligen Systems zu verstehen. Es wird bewertet,
wie viel Lernaufwand notig ist, um das System in seinen Moglichkeiten auszuschopfen
und ezient damit zu arbeiten.
Ubersichtlichkeit: Dieses Kriterium pruft die Systeme auf die ubersichtliche Repra-
sentation des Prozesses und anstehender Aufgaben. Dabei wird untersucht, ob dem
Nutzer sowohl bei kleinen Projekten als auch bei groen Unternehmensprozessen ein
geeigneter Ablaufplan zur Verfugung gestellt wird.
Ausfuhrbarkeit / Automatisierbarkeit: Unter der Ausfuhrbarkeit versteht man, ob das
System eine direkte Bearbeitung der ausstehenden Aufgaben unterstutzt. Erweitert
wird dieser Punkt durch die Betrachtung, inwieweit sich Aktivitaten automatisieren
lassen.
Zuganglichkeit: Das Zuganglichkeits-Kriterium spiegelt die gewunschte Plattformun-
abhangigkeit und Erreichbarkeit uber moderne Zugangspunkte, wie das Internet und
Mobilgerate, wider.
Strukturierbarkeit: Mittels dieses Kriteriums wird bewertet, welche Moglichkeiten zur
Abbildung verschiedenster Ablaufe zur Verfugung gestellt werden. Es wird betrachtet,
ob sich sequentielle, parallele und auch alternative Aktivitaten abbilden lassen.
Flexibilitat: Die Flexibilitat beschreibt, ob ein System auch Ad-Hoc-Prozesse unter-
stutzt. Das heit, ob und in welchem Ausma auch Prozesses wahrend der Abarbei-
tung in ihrer Struktur verandert beziehungsweise erweitert werden konnen.
Anhand der Tabelle 2.1 wird deutlich, dass keine der untersuchten Losungen in al-
len Kriterien gut abschneidet. To-Do-Listen sind als einfachstes und ubersichtlichstes
10

2.2 Losungskonzept
To-do-
Liste
Gantt-
Diagramm
BPMN BPEL Open Work
Bench
Einfachheit ++ + { { { 
Ubersichtlichkeit ++  + { { +
Ausfuhrbarkeit /
Automatisierbarkeit
 { { { { ++ +
Zuganglichkeit ++ {  + { {
Strukturierbarkeit { { { ++ ++ {
Flexibilitat ++ + { { { {
Tabelle 2.1: Bewertung der untersuchten Prozessdarstellungsarten
Tool anzusehen, jedoch mangelt es an der geforderten Strukturierbarkeit. Durch die
Bereitstellung von Listen-Verwaltung uber das Web wird eine weitreichende Zugang-
lichkeit ermoglicht. Das Gantt-Diagramm ist zur Darstellung von Prozessen mit einer
kleinen bis mittleren Anzahl an Vorgangen gut geeignet. Moglichkeiten zur Ausfuh-
rung von Aktivitaten werden nicht deniert. Ebenso stellt das Diagramm nur wenige
Moglichkeiten zur Strukturierung bereit. Die Business Process Modeling Notation
erweist sich als bestes Hilfsmittel zur graschen Modellierung von Prozessablaufen.
Es wird eine umfassende Palette an Symbolen zur Modellierung komplexer Struk-
turen geboten. Wie auch beim Gantt-Diagramm wird die Ausfuhrung der einzelnen
Aufgaben nicht ermoglicht. Diesen Nachteil hat BPEL nicht, denn diese Sprache
deniert, wie Aktivitaten uber Webservices bearbeitet werden. Eine grasche Dar-
stellung des Prozessablaufs gibt es jedoch nicht. Ebenso ist die Beschreibung in XML
nur schwer vom Menschen zu erfassen. Das Work
owmanagementsystem Open Work
Bench stellt eine Kombination einer Prozessplanung uber tabellarische Eintrage und
der Darstellung als Gantt-Diagramm dar. Aufgaben konnen im System direkt ab-
geschlossen werden. Komplexe Prozessstrukturen lassen sich nicht abbilden. Da die
Software nur als Einzelplatz-Windows-Anwendung vorliegt, ist Benutzung auf ver-
schiedenen Plattformen und uber das Netzwerk nicht moglich.
Im folgenden Kapitel wird die eigene, anhand der aufgestellten Kriterien entwickelte
Losung vorgestellt.
2.2 Losungskonzept
Als Erstes wurde im Zuge der Entwicklung des Work
owmanagementsystems un-
tersucht, wie man einen Projekt-Editor gestalten konnte, der es dem Benutzer er-
11

2 Entwicklung eines leichtgewichtigen, webbasierten
Workflowmanagementsystems
moglicht, sich einen Work
ow zusammenzustellen, ohne sich in komplizierte XML-
Sprachen oder Graphen einarbeiten zu mussen. Trotz der angestrebten einfachen
Nutzbarkeit sollen verschiedene Abhangigkeiten darstellbar sein, wie zum Beispiel
Nebenlaugkeit und Alternativen. Des Weiteren soll die Anwendung plattformunab-
hangig uber das Web zu erreichen sein.
2.2.1 Begriserklarung
Da das System im Bereich des Projektmanagements Anwendung ndet, wurde sich
auf einen einheitlichen Begriskatalog geeinigt. Die wichtigsten Begrie und deren
Denition wurden aus dem PMBOK (Project Management Body of Knowledge) uber-
nommen [14]:
 Project (Projekt): ist ein zeitlich begrenztes Vorhaben zur Schaung eines ein-
maligen Produktes oder Dienstleistung.
 Workpackage (Arbeitspacket): entspricht einem Liefergegenstand auf der nied-
rigsten Ebene des Projektstrukturplans. Arbeitspakete konnen in Vorgange zer-
legt werden.
 Activity (Vorgang), Task (Aufgabe): ist ein wahrend des Projektverlaufs durch-
gefuhrtes Ablaufelement. Ein Vorgang hat eine erwartete Dauer, erwartete Kos-
ten und einen erwarteten Einsatzmittelbedarf. Vorgange werden oft in Aufga-
ben untergliedert (To-Do-Liste).
 Milestone (Meilenstein): kennzeichnet ein bedeutendes Ereignis im Projekt, in
der Regel der Abschluss eines Hauptliefergegenstandes.
 Start Date (Anfangstermin): ist ein Zeitpunkt, der den Beginn eines Vorgangs
kennzeichnet.
 Finish Date (Due Date, Endtermin): ist ein Zeitpunkt, der den Abschluss eines
Vorgangs kennzeichnet.
 Percent Complete (Fortschrittsgrad): entspricht einer in Prozent angegebenen
Schatzung, in welchem Umfang die Arbeit an einem Vorgang oder einer Vor-
gangsgruppe fertiggestellt wurde.
 Monitoring ( Uberwachung): umfasst das Erfassen, die Analyse und den Bericht
der Projektleistung, ublicherweise im Vergleich zum Plan.
12

2 Entwicklung eines leichtgewichtigen, webbasierten
Workflowmanagementsystems
durchgefuhrt. Dabei wurde festgestellt, dass sich diese in funf Typen kategorisieren
lassen.
Workpackage-Typen
Die Workpackages wurden in folgende Grundtypen aufgeteilt:
 To-Do-Liste,
 Input (Benutzereingabe),
 Datei-Upload,
 Information und
 Meilenstein.
Diese Einteilung hat sich durch eine Untersuchung eines typischen Work
ows im
universitaren Umfeld ergeben. Es wurde die Anfertigung einer Studienarbeit an der
Professur VSR als Prozess betrachtet und deren wesentliche Arbeitsschritte erfasst.
Darunter befanden sich die folgenden Aufgaben, die von jedem Studenten in ahnlicher
Weise erfullt werden mussen:
 Thema suchen
 Thema eingeben
 Thema bestatigen (von Professor)
 Visionsdokument verfassen
 Arbeit anmelden
 Arbeit VSR-intern anmelden
 Interne Anmeldung bestatigen (von Mitarbeiter)
 Kontaktdaten hinterlegen
 Quellen recherchieren
 Gliederung anlegen

"
Stand der Technik\-Analyse durchfuhren
14

2 Entwicklung eines leichtgewichtigen, webbasierten
Workflowmanagementsystems
schon bekannten und gewohnten Tool bearbeitet werden konnen und mit dem ver-
bundenen Prozess im System synchronisiert werden.
Meilenstein
Der Meilenstein spielt eine besondere Rolle unter den Workpackages. Da andere Ar-
beitspakete nicht durch Stichtage oder Ausfuhrungszeiten an Fristen gebunden wer-
den konnen, aber die Moglichkeit zur termingerechten Planung nicht verloren gehen
sollte, wurde das Konzept des Meilensteins zur Strukturierung und zeitlichen Planung
von Projekten ubernommen. Neben den Zeitpunkten "
Projekt Start\ und
"
Projekt
Ende\ kann man durch den Einsatz eines Meilensteins zum Beispiel eine Deadline
festgelegen, bis zu der eine gewisse Menge an Aufgaben erfullt sein muss. So kann
man Projektabschnitten genaue Zeitspannen zur Abarbeitung zuweisen und damit
Abschatzungen zum aktuellen Fortschritt eines Projektes ermitteln. Dies ist vor allem
im Bereich des Monitoring und Reporting ein wichtiger Punkt. Durch Meilensteine
ist es moglich, bald anstehende Termine und uberfallige Aufgaben zu ermitteln und
den Nutzer gesondert daruber zu informieren.
Gewichtung von Workpackages
Den Workpackages, ausgenommen Meilensteine, kann jeweils eine Wertigkeit bzw.
Gewichtung zugeteilt werden, welche durch eine Ganzzahl reprasentiert wird. Dies
lasst eine Dierenzierung der Wichtigkeit oder des erforderlichen Aufwands der ein-
zelnen Aufgaben zu. Aus der Summe der Werte der einzelnen Workpackages wird
die Gesamtwertigkeit eines Projektes errechnet. Diese Gesamtwertigkeit ist kein Ver-
gleichskriterium unter Projekten, sondern dient zur Abschatzung des Projektfort-
schritts. Dieser wird durch den Vergleich der Wertigkeiten der bisher abgearbeiteten
Aufgaben und der Gesamtwertigkeit ermittelt. So konnte man beispielsweise einer
Aufgabe 1 die Gewichtung 80 zuteilen, dagegen einer Aufgabe 2 nur die Gewichtung
20. Waren diese beiden Aufgaben die einzigen Aktivitaten des Projektes, so ergaben
diese eine Gesamtwertung von 100. Somit wurde die Bearbeitung der ersten Aufgabe
einem Projektfortschritt von 80% entsprechen.
Wiederverwendung von Workpackages
Die Workpackages wurden als Grundelemente zur Wiederverwendung in Prozessen
deniert. Es ware wunschenswert, wenn ein umfassender Satz an verschiedensten Ak-
tivitaten im System verwaltet und mit Hilfe von Suchkriterien dem Nutzer bei der
16

2 Entwicklung eines leichtgewichtigen, webbasierten
Workflowmanagementsystems
Durch die Auslagerung der Strukturerzeugung auf die Seite des Klienten (Browser)
wird eine reaktionsschnelle Anwendung garantiert. Dabei wird mit Hilfe von Java-
Script aus der bestehenden HTML-Darstellung des Projektes eine XML-Abbildung
erzeugt und einmalig zum Server transferiert. Die vorher angewendete Strategie, bei
der jede Anderung am Prozess eine Anfrage an den Webserver ausloste, konnte diesem
Qualitatskriterium nicht standhalten, da je nach Internetverbindung und Antwortzeit
des Webservers Latenzwerte im Sekundenbereich bei der Erstellung von Work
ows
auftraten. Die Denition eines XML-Schemas ermoglicht eine Validierung der emp-
fangenen Struktur auf der Serverseite.
Abbildung 2.8: Darstellung eines Work
ows mittels des Projekteditors
In Abbildung 2.8 ist ein Beispiel-Work
ow dargestellt, welcher mit dem entworfenen
Projekteditor angelegt wurde. Durch die gestrichelten Platzhalter wird angedeutet,
dass die Struktur einem festen Raster unterliegt. Einzelne Aktivitaten sind als farbige
22

2 Entwicklung eines leichtgewichtigen, webbasierten
Workflowmanagementsystems
Abbildung 2.10: Darstellung eines Workpackage-Formulars
Abbildung 2.11: Eingabedaten eines Meilensteins
26

2 Entwicklung eines leichtgewichtigen, webbasierten
Workflowmanagementsystems
2.3.4 Dashboard
Das Dashboard dient als zentrale Anlaufstelle, um Informationen uber aktuelle Pro-
jekte des Benutzers zu erhalten. Als erstes werden ausstehende Aufgaben seiner Pro-
jekte als eine To-do-Liste dargestellt. Des Weiteren bekommt man eine Ubersicht uber
den Fortschritt der eigenen Projekte, mit Angabe der nachsten zu erfullenden Auf-
gabe prasentiert. Ein Ausschnitt des Dashboards mit der erwahnten To-do-Liste und
der Projekteau
istung ist in Abbildung 2.13 gezeigt. Der Fortschritt wird durch eine
Balkengrak angezeigt, welche aus zwei Teilen besteht. Zum einen der \Ist\-Stand
des Projekts, welcher durch die schon erledigten Aufgaben in Relation zur Gesamt-
menge reprasentiert wird und zum anderen der "
Soll\-Stand. Der
"
Soll\-Stand ergibt
sich aus dem Projekt-Start- und End-Datum, sowie der schon vergangenen Zeit seit
Projektbeginn. Dabei wird ein linearer Projektfortschritt uber die Zeit angenommen
und die schon vergangene Zeit als farbig dierenzierter Balken dargestellt.
Abbildung 2.13: Ausschnitt der Dashboard-Ansicht
28

3 Aufbau einer Work
ow-Community
Jeder steht vor der Herausforderung, seine taglich anfallenden Aufgaben und P
ichten
zu erledigen und somit seinen Alltag zu gestalten. Die Aufgabenvielfalt kann dabei
von kleinen Routineaufgaben, uber Freizeit- und Hobbyprojekte bis hin zu Gro-
projekten, welche blo mit einer Vielzahl von Beteiligten erledigt werden konnen,
reichen.
Da die Anzahl solcher Aufgaben zunehmend steigt und immer hohere Anforderungen
an diese gestellt werden, muss mehr Aufwand betrieben werden, um diese P
ichten
zu bewaltigen. Infolgedessen fehlt einem zunehmend die Zeit, um beispielsweise seine
sozialen Kontakte zu p
egen oder sich in Vereinen zu engagieren.
Um ein erfolgreiches und erfulltes Leben zu fuhren, sollte man weder seine Aufga-
ben noch menschliche Interaktionen vernachlassigen. Es ist also angebracht, sowohl
seinen P
ichten als auch der P
ege seiner sozialen Kontakte in einem angebrachten
und zufriedenstellenden Verhaltnis nachzugehen. Wunschenswert ware ein Software-
system, welches einen Nutzer bei der Erfullung dieser beiden Anspruche unterstutzt,
um sowohl beru
iche als auch private Ziele ezienter erreichen zu konnen.
Im Rahmen dieser Arbeit wird eine Online-Community im Kontext eines Work
ow-
managementsystems (vgl. Abschnitt 2) errichtet. Es wird dadurch ein Ort geschaen,
an dem man Aufgaben verwalten kann und man Probleme mit anderen dort bespre-
chen und losen kann, wo sie auch auftauchen.
Die Community dient dabei als Plattform zur Interaktion von Menschen mit gleichen
oder ahnlichen Interessen. Preece grenzt eine Community wie folgt ab [13]:
"
An Online-Community consists of:
 People, who interact socially as they strive to satisfy their own needs
or perform special roles, such as leading or moderating.
 A shared purpose, such as an interest, need, information exchange,
or service that provides a reason for the community.
 Policies, in the form of tacit assumptions, rituals, protocols, rules,
and laws that guide people's interaction.
31

3 Aufbau einer Workflow-Community
 Computer Systems, to support and mediate social interactions and
facilitate a sense of togetherness.\
Entscheidend fur eine Community sind demnach Mitglieder, welche miteinander in-
teragieren, um ihre eigenen Bedurfnisse zu erfullen oder besondere Rollen einnehmen
zu konnen. Diese Interaktion sollte durch ein Regelwerk deniert werden. Des Wei-
teren ist ein gemeinsam verfolgtes Ziel wichtig. Uber diese geteilten Interessen kann
eine Community durch die Unterstutzung eines Computersystems zu einer Art Ge-
meinschaftsgefuhl fuhren.
Eine Work
owmanagement-Community konnte die Ablaufe von Projekten verbes-
sern, indem sie Moglichkeiten zur Organisation und Koordination von mehreren Pro-
jektbeteiligten anbietet und eine Umgebung schat, in der sich diese uber Projekte
austauschen, beraten und gegenseitig unterstutzen konnen.
Die Kombination eines Work
owmanagementsystems und einer Online-Community
bietet zum einen den Vorteil, dass bestehende Verbindungen mit Freunden, Kollegen
oder Vereinsmitgliedern gep
egt und genutzt werden konnen. Zum anderen ergibt
sich zusatzlich auch die Moglichkeit, neue Kontakte mit Gleichgesinnten oder Exper-
ten aus verschiedenen Interessengebieten aufzubauen und von deren Fahigkeiten zu
protieren.
Im Folgenden wird erlautert, wie eine solche Community aufgebaut wurde, wobei:
 im Abschnitt 3.1 (Stand der Technik) verschiedene Ansatze fur Online-Commu-
nities vorgestellt und jeweils anhand typischer Vertreter untersucht werden
 im Abschnitt 3.2 (Losungskonzept) Uberlegungen, wie man eine Community im
Kontext eines Work
owmanagementsystems realisieren kann, vorgestellt wer-
den und
 im Abschnitt 3.3 (Realisierung) die bisher implementierten Teile der Commu-
nity beschrieben werden.
3.1 Stand der Technik
Zur Untersuchung werden typische Vertreter verschiedener Online-Community-Arten
betrachtet. Dabei wird die Community-Klassizierung von Schrammel, Koel und
Tscheligi verwendet, welche vier Kategorien von elektronischen Communities bein-
haltet [16]:
32

3.1 Stand der Technik
"
[::] we developed our own set of community categories [:::] communities
were dierentiated into the following four categories:
 Business Networking Sites. These are networking sites that are main-
ly used to maintain and administer existing and new business con-
tacts. [:::]
 Social Networks. This term comprehends sites that are mainly used
for maintaining private relationships and contacts. [:::]
 Content and Media Sharing Networks. On these sites the major fo-
cus is on sharing content with others and not on maintaining re-
lationships (even though sharing contents is an important aspect of
maintaining relationships). [:::]
 Social News and Bookmarking Sites. These sites are used to share
and discover interesting links to news and contents in the web. Sites
can be more focused on the collaborative bookmarking aspect [:::] or
the social news aspect.
Das Aunden und Austauschen von Links zu interessanten Webinhalten wird im
Sinne eines Work
owmanagementsystems als irrelevant erachtet. Deshalb beschrankt
sich die Untersuchung auf die drei Typen
"
Business Networking Sites \,
"
Social Net-
works\, und
"
Content and Media Sharing Networks \. Im Kontext einer Work
owma-
nagement-Community waren vor allem Funktionen sinnvoll, welche es den Nutzern
gestatten, sich vor- bzw. darzustellen und sich zu gruppieren. Dadurch konnten Ar-
beitsgemeinschaften abgebildet werden, in denen es auch moglich ist, mehr uber die
Nutzer zu erfahren, mit denen man zusamenarbeitet. Des Weiteren ist es notwendig,
dass die Mitglieder in der Lage sind, untereinander zu kommunizieren, um sich in
ihren Ablaufen organisieren und koordinieren zu konnen.
Zusammenfassend ergeben sich folgende vier Untersuchungskriterien:
 Kommunikation: Auf welchen Wegen konnen die Nutzer miteinander kommu-
nizieren?
 Gruppierung: Inwieweit konnen sich die User in Subgruppen organisieren?
 Privatbereich: Konnen hinterlegte Informationen vor anderen Benutzern des
Systems geschutzt werden?
 Selbstdarstellung: In welchem Umfang lassen sich personliche Daten hinterle-
gen?
33

3.1 Stand der Technik
3.1.2 Social Networks
In
"
Social Networks\ konnen ebenfalls Kontakte verwaltet werden, wobei der Fokus
dabei im Gegensatz zu
"
Business Networking Sites\ (vgl. Abschnitt 3.1.1) auf pri-
vaten, anstatt geschaftlichen Beziehungen liegt [16]. Im Folgenden wird "
Facebook\,
welches mit uber 400 Millionen Benutzern [2] das weltweit grote soziale Netzwerk
darstellt, untersucht.
Facebook
Als weltgrotes soziales Netzwerk bietet Facebook2 seinen Mitgliedern viele Moglich-
keiten zur Kommunikation. So konnen die Benutzer beispielsweise:
 an alle andere Nutzer Nachrichten verschicken,
 Sammelnachrichten an bis zu 20 Empfanger versenden,
 mit bestatigten Kontakten live chatten,
 als Admin einer Gruppe Nachrichten an alle Gruppenmitglieder verteilen und
 auf einer Pinnwand Statusmeldungen hinterlassen, welche fur alle Interessierten
zuganglich sind.
Des Weiteren bietet Facebook sehr umfangreiche Moglichkeiten, Informationen auf
einer Nutzerprolseite anzugeben.Dazu zahlen neben Kontaktdaten auch Bilder und
Videos. Fur alle diese angegebenen Informationen kann separat eine Datenfreiga-
be eingestellt werden. Es ist jedem User gestattet, eine Gruppe mit einer von drei
Zuganglichkeitsstufen zu eronen, um Strukturen und Interessengemeinschaften ab-
bilden zu konnen. Dabei kann zwischen oenen Gruppen (= fur alle zuganglich),
geschlossenen Gruppen (= fur alle sichtbar, aber nur mit Einladung zuganglich) und
geheimen Gruppen (= nicht sichtbar und nur mit Einladung betretbar) gewahlt wer-
den.
3.1.3 Content and Media Sharing Networks
"
Content and Media Sharing Networks\ legen ihren Fokus auf den Austausch von
Inhalten mit anderen Nutzern [16]. Stellvertretend fur diese Systeme wird die Frage-
2http://www.facebook.com/
35

3.2 Losungskonzept
NEED OFFLINE ONLINE
physiological Food, clothing, shelter,
health
System access; the abili-
ty to maintain one's iden-
tity, and participate in a
Web community
security and safety Protection from crimes
and war; the sense of li-
ving in a fair and just so-
ciety
Protection from hacking
and personal attacks; the
sense of having a
"
level
playing eld\
social The ability to give and re-
ceive love; the feeling of
belonging to a group
Belonging to the com-
munity as a whole, and
to subgroups within the
community
self-esteem Self-respect; the ability to
earn the respect of others,
and contribute to society
The ability to contribute
to the community, and be
recognized for those con-
tributions
self-actualization The ability to develop
skills and fulll one's po-
tential
The ability to take on a
community role that de-
velops skills and opens up
new opportunities
Tabelle 3.2: Uberfuhrung der Bedurfnishierarchie in die Online-Welt [8]
Nutzern zuruckgreifen. Es wird angenommen, dass Process Designer die Community
vorrangig zur Aggregation von Gleichgesinnten nutzen werden. So werden sie neue
Prozesse anstoen und diese mit Hilfe der Community-Mitglieder bearbeiten. Quality
Coachs mochten primar uber Vorgange innerhalb der von ihnen betreuten Prozesse
informiert werden, um basierend auf diesen Informationen Entscheidungen zu treen
und, wenn notig, regulierend eingreifen zu konnen. Diese Anforderungen entsprechen
der folgenden Denition von
"
Community Awareness\ nach Wolfgang Prinz [17]:
"
[:::] is an understanding of the presence and activities of others within
a shared hybrid environment, which provides a context for mutual orien-
tation and opportunities for situative reactions.\
Mogliche Motivationen fur die Gruppe der Experts sind der Wunsch nach Anerken-
nung beziehungsweise Bestatigung oder das Streben nach (Weiter-)Entwicklung von
Fahigkeiten. Sie benotigen also ein System, welches ihnen das Gefuhl gibt, dass ihre
geleistete Arbeit gewurdigt und anerkannt wird.
41

3.2 Losungskonzept
damit zum Beispiel Falle abgedeckt werden, welche die Kommunikation mit einer
gesamten Community oder Area erfordern. Des Weiteren sollte es auch moglich sein,
Nachrichten zu einem bestimmten Projekt hinterlassen zu konnen, um Anregungen
und Hilfestellungen zu unterbreiten.
Im Folgenden werden einige, in Social Communitys bekannte, Kommunikationssyste-
me aufgefuhrt, deren Kern deniert und eventuelle Einsatzgebiete in Goal1 erlautert.
Direct Messages
Bei Direct Messages handelt es sich um private Nachrichten, welche direkt von einem
Benutzer (Sender) zu einem anderen Benutzer (Empfanger) verschickt werden. Die
Kommunikation lauft privat und asynchron ab.
Das System der Direct Messages konnte in Goal1 zum direkten Ansprechen von Nut-
zern innerhalb der Community verwendet werden. Um die Kommunikation moglichst
ezient zu gestalten, konnten Nutzer uber neue, an sie gerichtete Nachrichten infor-
miert werden (siehe
"
Notikation\).
Shoutbox
Im Gegensatz zu Direct Messages ist der Shoutbox-Ansatz oentlich und damit nicht
an einzelne Empfanger gebunden. Die Kommunikation lauft ebenfalls asynchron ab.
Hier ware es denkbar, dass jede Community und Area ihre eigene Shoutbox besitzt,
in der die Community- oder Areamitglieder ihre Nachrichten absetzen konnen. So
konnten Gruppenevents oder gruppenspezische Informationen, wie gesetzte und er-
reichte Ziele, veroentlicht werden.
Microblogging
Ein Microblogging-System ermoglicht das Hinterlassen von Nachrichten, welche in
ihrer Lange begrenzt sind. Jedes zu verwaltende Projekt in der Community Goal1
konnte einen eigenen Microblog besitzen, in dem, im Gegensatz zum Shoutbox-
Ansatz, auch projektauenstehende Benutzer Informationen hinterlassen und ver-
breiten konnten. So konnten hilfsbereite Experten Hinweise zu weiterfuhrenden In-
formationen oder dem gewahlten Projektaufbau einbringen und eventuell mit Pro-
jektbeteiligten oder anderen Experten diskutieren.
45

3.3 Realisierung
Interessensgebieten erlaubt es, eine Vielzahl von verschiedenen Projekttypen in einer
Community zu verwalten und gibt den Usern die Moglichkeit, sich in Subgruppen,
die deren Interessen entsprechen, zu beteiligen. Damit die Ubersichtlichkeit nicht dar-
unter leidet, wird den Nutzern die Moglichkeit eingeraumt, in einem eingeschrankten
Rahmen beliebige Interessensgruppen zu bilden und zu strukturieren. Dieses Konzept
wird im Folgenden als
"
Konzept der
achen Hierarchie\ bezeichnet.
Das Konzept der
achen Hierarchie sieht vor, dass Nutzer sich ihre eigenen Com-
munities anlegen konnen, welche sich zum Beispiel dadurch auszeichnen, dass sie
ein bestimmtes Interessengebiet abdecken oder eine Organisation darstellen. Inner-
halb dieser Communities konnen dann ferner so genannte Areas (Bereiche) angelegt
werden, um die Community-Interessen oder Organisationsstrukturen noch weiter spe-
zizieren zu konnen. In diesen genauer spezizierten Bereichen konnen dann die zu
verwaltenden Projekte angelegt werden. Im Umkehrschluss bedeutet dies, dass ein
Projekt immer einer Area angehort, welche selbst immer einer Community unterge-
ordnet ist. In einer Community selbst konnen keine Projekte erstellt werden.
Mit dieser vertikalen Einteilung haben die User die Moglichkeit, einfache Struktu-
ren abzubilden und dennoch den Uberblick uber den Aufbau der Communities zu
behalten.
In manchen Fallen kann es sinnvoll sein, noch weitere Strukturierungsmanahmen
vorzunehmen. Ein Beispielszenario ware:
Die Professur
"
Verteilte und selbstorganisierende Rechnersysteme\ (VSR) besitzt meh-
rere Forschungsbereiche, wie zum Beispiel die Bereiche
"
Web Engineering\ und
"
Ser-
vice Infrastructures\. Innerhalb dieser Forschungsbereiche werden verschiedene Pro-
jekte betreut. Die Professur VSR konnte in Goal1 als eine Community mit den Areas
"
Web Engineering\ und
"
Service Infrastructures\ dargestellt werden. Weiterhin ist die
Professur logisch mit der Hochschule
"
TU Chemnitz\ verbunden, welche ebenfalls als
Community in Goal1 angelegt werden konnte.
Um dieses Verhaltnis abbilden zu konnen, wurde das Konzept der
achen Hierar-
chie erweitert. Es ist zusatzlich zu der vertikalen Einteilung einer Community (eine
Beschreibung ihrer Struktur) eine horizontale Beschreibung (die Verbindungen zu
anderen Communities) moglich. Es wurden drei Arten von Verbindungen deniert:
 Sub Communities sind Communities, welche logisch einer anderen Community
untergeordnet sind.
 Eine Parent Community ist die Community, welche logisch anderen Communi-
ties ubergeordnet ist, wobei jede Community maximal eine Parent Community
besitzen kann.
47

3.3 Realisierung
Abbildung 3.4: Detailseite der Community
"
VSR\
51

4 Nutzung der Intelligenz der Massen
Einstiegshurde, sowie einfache Moglichkeiten, Ein
uss auszuuben, fuhrten dazu, dass
sich 2007 uber einer Million Deutsche in Wikis beteiligten. [21]
Laut einer Untersuchung des Wissenschaftlichen Informationsdienst Koln, welche
vom Wochenmagazin Stern (Ausgabe vom 06.12.07) in Auftrag gegeben wurde, schnei-
det die von Nutzern erstellte Wikipedia in 43 von 49 Fallen in den Punkten Rich-
tigkeit, Vollstandigkeit, Aktualitat sowie Verstandlichkeit besser ab als die bekannte
Brockhaus Enzyklopadie. [18]
Diesem liegt { wie von James Surowiecki beschrieben { ein gruppendynamisches
Phanomen, der so genannten Schwarmintelligenz, zu Grunde. Dabei kann uber das
Internet und seine Nutzer verteilte Intelligenz nach auen als eine einzelne Superin-
telligenz auftreten, die qualitativ bessere Ergebnisse im Vergleich zu Einzelpersonen
liefert und etliche Aufgaben schneller, ezienter und nicht selten kostengunstiger
erledigen kann.
Der ehemalige Slogan der Wikipedia benennt ebenfalls treend die Macht der Mas-
senweiheit:
"
Nobody knows everything, everyone knows something\
Surowiecki beschreibt auerdem die Vorteile einer unorganisierten Entscheidungsn-
dung [20], wobei eine Gruppe wesentlich genauere Entscheidungen treen kann als
Experten oder Komitees. Dies wird besonders bei der dritten Art der Internetakti-
vitat der Nutzer sichtbar. Dabei wird besonders qualitatives Wissen im Internet von
Nutzern durch Blogs, Twitter, Facebook oder soziales Bookmarking (Folksonomy)
weitervermittelt. Andere Informationen gehen in dieser Flut meist unter. Filterme-
chanismen wie Google Pagerank helfen dabei, Themen, uber die verstarkt gebloggt
wird, herauszuheben und somit die Weisheit der Masse sichtbar zu machen. [6]
Sowohl die Schwarmintelligenz als auch die unorganisierte Entscheidungsndung konn-
ten im Kontext des Erfahrungsaustauschs im Internet genutzt werden und diesen
sogar fordern.
Intelligenz der Massen als Grundlage des webbasierten Work
owmanagements
Work
ows eigenen sich ideal als Trager der zur Losung eines Problems benotigter
Erfahrung (in Form von Arbeitschritten bzw. Workpackages) und beinhalten zudem
Regeln zur Ablauforganisation (Kodierung der Abhangigkeiten bzw. der Reihenfolge
der Abarbeitung dieser Arbeitsschritte). Was noch wesentlich wichtiger ist: sie eignen
sich auch gut als Wiederverwendungseinheiten.
54

Die Idee hinter dem Work
owaustausch im Internet ist folgende: Nutzer sollen eigene
Workpackages erstellen und in eine Internetplattform einp
egen konnen. Aus diesen
konnen sie Work
ows zur Losung von Problemen zusammenstellen und allen ande-
ren Nutzern zur Verfugung stellen. Ferner sollen andere Nutzer bestehende Work
ows
als Schablonen nutzen, verandern, fur ihre Zwecke anpassen und prazisieren konnen.
Nach gemachten Anderungen sollen auch diese Work
ows der Allgemeinheit zur Ver-
fugung stehen. So entsteht durch die Anwendung der Massenintelligenz ein Pool an
Losungen fur unterschiedliche Probleme im privaten, geschaftlichen und wissenschaft-
lichen Umfeld.
Im Gegensatz dazu stehen typische Work
owmanagementsysteme, bei denen es sich
um geschlossene Systeme handelt, die innerhalb einer Organisation eingesetzt werden.
Diese stellen sehr begrenzte Moglichkeiten fur die Wiederverwendung von Work
ows
zur Verfugung, da eine verhaltnismaig geringe Anzahl an Work
ows vorhanden ist.
Durch Wiederverwendung und Anpassung entsteht eine groe Vielfalt an Auspra-
gungen von gleichen Work
ows in unterschiedlichen Abstraktionsstufen und unter-
schiedlicher Qualitat. Umso wichtiger wird es, im System ezient nach Work
ows
explorieren zu konnen.
Unorganisierte Entscheidungsndung als Filtermechanismus fur Work
ows
Bei einer Vielfalt von Work
ows ist es wichtig, den Uberblick nicht zu verlieren. Dazu
sollten besonders qualitative, aktuell relevante oder nutzliche Work
ows besonders
prominent prasentiert werden. Die Macht der Masse kann nutzlich sein, um solche
Work
ows ohne zusatzlichen Aufwand seitens des Plattformbetreibers zu selektieren.
Durch einen Bewertungsmechanismus konnten die Nutzer fur sie wichtige Work
ows
kenntlich machen. Die von den meisten Nutzern positiv ausgezeichneten Work
ows
konnten dann anderen Nutzern prasentiert werden und somit die Suche nach passen-
den Work
ows erleichtert werden.
Im folgenden Abschnitt wird eine
"
Stand der Technik\-Betrachtung im Hinblick auf
die Realisierungsmoglichkeiten eines Systems, welches von der Intelligenz der Massen
protiert, durchgefuhrt. Anschlieend ndet die Vorstellung des Konzepts des bei
der Professur Verteilte und Selbstorganisierende Rechnersysteme der TU-Chemnitz
und im Rahmen dieser Arbeit angefertigten Systems Goal1 statt. Auf die konkre-
te Implementierung der ausgewahlten Aspekte wird im darauolgenden Abschnitt
eingegangen.
55

4.1 Stand der Technik
 bei wissenschaftlicher Nutzung interdisziplinare und facherubergreifende Nut-
zung von Work
ows uber die Grenzen von Forschungsgebieten und Forschungs-
organisationen hinaus.
Wird der Gedanke der Wiederverwendung vom System umgesetzt, so ist es fur den
Nutzer essentiell, die Moglichkeit einer ezienten Suche nach Work
ows zu haben.
Denn um von Wiederverwendung zu protieren, ist es zunachst notwendig, ein pas-
sendes Projekt zu nden, welches vererbt werden kann.
Durch Wiederverwendung wachst naturlich die Anzahl an ahnlichen Projekten in
einem System. Ahnlichkeit bedeutet nicht unbedingt, dass die Projekte thematisch
zusammen einzuordnen sind. Projekte, die beispielsweise voneinander geerbt haben
unterscheiden sich zwar nicht thematisch, weisen aber unter Umstanden andere unter-
schiedliche Eigenschaften auf. So konnen sie spezischer oder allgemeiner, vollstandi-
ger oder unvollstandig, sowie mehr oder weniger widerspruchlich sein. Umso wichtiger
ist es, auf einen Blick dierenzieren zu konnen, welcher von diesen Work
ows sich
eher zur eigenen Wiederverwendung eignet. Diese Unterscheidung konnte zum Bei-
spiel durch ein Bewertungssystem realisiert werden, welches { durch das Wissen der
Masse { von den meisten Nutzern favorisierte Work
ows hervorhebt.
4.1.1 Google Wave
Google Wave2 ist ein im Mai 2009 vorgestelltes webbasiertes Kollaborationssystem.
Die Kollaboration erfolgt innerhalb von so genannten Waves { Diskussionsstrangen,
die meist ein Thema vorgeben und entweder allen oder einem ausgewahlten Kreis
an Nutzern zuganglich sind. Waves bestehen aus mehreren Blips { einzelnen Nach-
richten, die in einer Baumstruktur untereinander eingeordnet sind. Es ist fur jeden
Nutzer moglich, Blips aller anderen Beteiligten zu bearbeiten. Dank des von Google
eigenentwickelten XMPP-basierten3 Protokolls wird jede Aktualisierung eines Blips
in Echtzeit an andere Teilnehmer ubertragen. Jede Anderung wird zudem proto-
kolliert und ist mittels eines Sliders auch fur neu dazu gekommene Teilnehmer im
zeitlichen Verlauf von Anfang an nachvollziehbar. Neben chat-ahnlicher Kommuni-
kation stellt auch eine wiki-ahnliche kollaborative Bearbeitung von Dokumenten ein
Anwendungsgebiet dar. Es ist zudem als eine Art Blog einsetzbar, wobei Teilnehmer
der Wave im Sinne von Awareness4 die Anderungen verfolgen und Feedback abgeben
konnen.
2http://wave.google.com
3mehr unter http://de.wikipedia.org/wiki/XMPP
4mehr unter http://www.zephoria.org/thoughts/archives/2009/08/16/twitter_pointle.
html
57

4.1 Stand der Technik
Community-Features wie Tagging von Work
ows, Kommentar- und Bewertungsfunk-
tionen, sowie Gruppenbildung fur Nutzer werden unterstutzt. Auer Work
ows selbst
konnen noch zusatzliche Daten, die im wissenschaftlichem Umfeld relevant sind, wie
Dokumentationen, Testdaten oder Simulationsergebnisse angehangt werden. Mittels
eines RDF-basierten Standards
"
Object Reuse and Exchange\6 ist es moglich, uber
das Web verteilte Ressourcen innerhalb eines Packs, einem Container fur Work
ows,
zusammenzufassen.
Neben einer zentralen Online-Instanz ist es moglich, die Software lokal zu installieren.
Des Weiteren sind grundlegende Moglichkeiten vorhanden, um mehrere Instanzen in
Rahmen einer Foderation zu betreiben.
Wiederverwendung stellt einen der Grundgedanken des Systems dar. Es existiert
keine Moglichkeit, Work
ows innerhalb des Systems zu bearbeiten. Vielmehr sollte
man dazu Work
ows herunterladen, abandern und erneut hochladen, um sie anderen
Teilnehmern zur Verfugung zu stellen.
Es ist fur den Autor eines Work
ows moglich, beim Hochladen anzugeben, von wel-
chem Work
ow dieser entstammt. Damit wird automatisch eine beidseitige Verlin-
kung { sowohl im hochgeladenen Work
ow als auch in seinem Stammwork
ow {
realisiert. Zusatztlich ist es moglich, die Anderungshistorie eines einzelnen Work-
ows nachzuvollziehen. Thematisch ahnliche Work
ows konnen mit den selben Tags
versehen und gemeinsam angezeigt werden. Eine zweite Moglichkeit ist es, solche
Work
ows innerhalb eines Packs einzuordnen. Zu weiteren Navigationsmoglichkei-
ten zahlen eine tagbasierte Navigation, Navigation durch Gruppen, Prolseiten und
Sortierung der Ergebnismenge nach folgenden Kriterien:
 am meisten heruntergeladen,
 am haugsten angesehen oder
 kurzlich aktualisiert.
Nutzer konnen Work
ows innerhalb von myExperiment mit bis zu funf Punkten
bewerten. Dieses Rating wird dann auf der Work
ow-Beschreibungsseite angezeigt.
Weiterhin wird eine Sortierung der Work
ow-Au
istung nach diesem Kriterium un-
terstutzt. Zusatzliche Informationen, beispielsweise zur Qualitat eines Work
ows,
konnen entweder in einer Rezension oder in den Kommentaren hinterlassen wer-
den, die ebenfalls auf der Work
owseite aufgelistet werden. Daruber hinaus konnen
einzelne Nutzer Work
ows favorisieren. Der Link zu diesen Projekten erscheint dann
auf der Prolseite des Nutzers. Dieser Nutzer wird dann auch namentlich auf der
Work
owseite mit einem Link erwahnt. Es ist also fur einen Besucher moglich, von
6mehr unter http://www.openarchives.org/ore/
59

4 Nutzung der Intelligenz der Massen
einem Work
ow zu einer Person zu navigieren. Da davon auszugehen ist, dass ei-
ne Person in einer bestimmten Fachrichtung forscht, konnten uber ihre Prolseite
weitere ahnliche favorisierte Projekte entdeckt werden.
4.1.3 Zusammenfassung
Wiederverwendung von Wissen ist ein wesentliches Mittel zur Produktivitatssteige-
rung. Google Wave lost dieses Problem mit dem Ansatz des Kopierens ziemlich gut,
jedoch wird eine Teilwiederverwendung und Neukombination dieser Teile nicht direkt
unterstutzt und ist nur uber Umwege mittels Copy und Paste moglich. Dies schrankt
die Einsatzmoglichkeiten des Systems in dieser Hinsicht ein. Die lockere Strukturie-
rung der Informationen sorgt zwar fur Flexibilitat, erfordert aber fur ein ernsthaftes
Work
owmanagement viel Aufwand und Disziplin. Es fehlen zudem in dieser Doma-
ne wichtige Features wie Meilensteine und eine Ubersicht uber die als nachstes zu
erledigenden Aufgaben.
Bei myExperiment wird die Wiederverwendung dadurch erschwert, dass die Work-
ows nicht innerhalb des Systems bearbeitet werden konnen. Die Neukombination
aus mehreren Work
ow-Teilen ist zwar moglich, erfordert aber den Einsatz einer
Drittsoftware, welche unter Umstanden weitere Kosten mit sich zieht. Durch den
Herunter- und Hochlade-Prozess wird der Nutzer auch nicht explizit aufgefordert,
seinen geanderten Work
ow wieder hochzuladen. Dies kann sich einschrankend auf
die Ausbreitung des Work
owpools auswirken.
Google setzt bei der thematischen Exploration von Work
ows/Waves hauptsachlich
auf Volltextsuche. Wahrend diese Google-typisch gut funktioniert, ist es mit Goo-
gle Wave nicht moglich, Verwandschaftsbeziehungen zwischen kopierten Projekten
nachzuvollziehen. Durch zusatzlichen Aufwand konnte diese Verbindung zwar ma-
nuell hergestellt werden, da dies jedoch nicht explizit verlangt wird, werden wohl
die wenigsten Nutzer Gebrauch davon machen. Thematisch kann mittels Tags navi-
giert werden, wobei dies keine Ideallosung darstellt. Nutzer neigen dazu unterschiedli-
che Tags oder Synonyme zur Beschreibung gleicher Sachverhalte zu verwenden. Dies
konnte zwar mittels Autovervollstandigung optimiert werden, doch Google macht
davon keinen Gebrauch.
myExperiment erlaubt es, beim Hochladen von Work
ows Informationen uber ihren
Ursprungswork
ow zu hinterlegen, um diesen mit ihm bidirektional zu verknupfen.
Dies wird jedoch nicht zwingend verlangt. Hier wird ein weiterer Nachteil des von dem
System gewahlten Wiederverwendungsprozesses sichtbar. Wurde die Wiederverwen-
dung komplett innerhalb des Systems ablaufen, konnte diese Verbindung automatisch
und obligatorisch hergestellt werden. Denn gerade im wissenschaftlichen Bereich stel-
60

4.2 Losungskonzept
len Plagiate eine groe Bedrohung dar. Zur thematischen Zusammenfassung werden
ebenfalls Tags verwendet, deren Eigenschaften bereits weiter oben erwahnt wurden.
Bei Google Wave fehlt es an Moglichkeiten zur Bewertung und Dierenzierung von
Waves. Die Realisierung durch Tags stellt nur eine Notlosung durch ihre Zweckent-
fremdung dar, die zwar moglich ist, aber sicherlich nicht haug benutzt werden wird.
Somit macht es die Auswahl des optimalen Work
ows zwischen mehreren Kandidaten
zu einer lastigen Aufgabe. Textuelle Bewertungen waren zwar moglich, gehen aber
sicherlich in der Flut der Blips einer Wave leicht unter.
myExperiment unterstutzt hingegen einen Ratingmechanismus, sowie Exploration
der Projekte sortiert nach ihrem Rating. Durch Rezensionen ist es moglich, zusatzli-
che Informationen zur Qualitat und zum praktischen Einsatz dieses Work
ows nach-
zuschlagen.
Es lasst sich zusammenfassend feststellen, dass myExperiment zwar weniger fur die
Verwaltung von Ad-hoc-Work
ows geeignet ist, allgemein jedoch wesentlich mehr
Moglichkeiten dazu bietet als Google Wave. Verbesserungspotential besteht bei bei-
den Systemen.
Ein Vergleich zwischen myExperiment und Google Wave anhand der drei Kriterien
kann der Tabelle 4.1 entnommen werden.
Google Wave MyExperiment
Wiederverwendung von Projekten + {
Exploration von Projekten { +
Dierenzierung von Projekten { { ++
Tabelle 4.1: Bewertung Google Wave und MyExperiment
Im folgenden Kapitel werden die im Rahmen der Software Goal1 entwickelten Ansatze
zur Wiederverwendung, Exploration und Dierenzierung von Work
ows vorgestellt.
4.2 Losungskonzept
In diesem Kapitel wird das entwickelte Konzept zur Wiederverwendung von Work-
ows beschrieben. Fur die Konzepte der Exploration von Work
ows sowie ihrer Dif-
ferenzierung wird eine mogliche Implementierung erlautert. Aus Zeitgrunden wurden
diese beiden Konzepte jedoch im Rahmen dieser Arbeit nicht umgesetzt.
61

4.2 Losungskonzept
Fur die Nutzer konnte dann eine Moglichkeit geboten werden, durch die Hierarchie-
struktur zu navigieren. Weiterhin konnen folgende Informationen dargestellt wer-
den: direkter Vorganger, Ursprungsprojekt auf der Root-Ebene, direkter und weitere
Nachfolger des Projekts.
Die Semantik der Beziehungen wird mittels eines Vokabulars deniert, welches in der
Web Ontology Language (OWL)7 kodiert ist. Im Internet existieren bereits geeignete
Vokabulare fur Vorganger-Nachfolger-Beziehungen. Ein passendes OWL-Vokabular
ware bspw. http://www.loa-cnr.it/ontologies/ExtendedDnS.owl#successor.
Eine Kodierung der Nachfolger-Beziehung mittels RDF+XML konnte damit wie in
Abbildung 4.1 dargestellt aussehen.
1 <?xml version="1.0 " encoding="UTF8" ?>
2 <rdf:RDF xmlns : rd f="h t t p : //www.w3 . org /1999/02/22 rdf syntax ns#"
xmlns:ont="h t t p : //www. loa cnr . i t / on t o l o g i e s /ExtendedDnS . owl ">
3 <rdf:Description
4 rd f : about="h t t p : // goa l1 . example . com/community/area/ p ro j e c t 1 ">
5 <o n t : d i r e c t s u c c e s s o r
6 r d f : r e s o u r c e="h t t p : // goa l1 . example . com/community/area/ p ro j e c t 2 "/>
7 </rdf:Description>
8 </rdf:RDF>
Abbildung 4.1: Kodierung der Nachfolger-Beziehungen zwischen zwei Projekten mit-
tels RDF+XML
Eine Implementierung dieser Funktionalitat wurde im Rahmen dieser Arbeit aus
Zeitgrunden nicht vorgenommen.
Mittels RDF ist es ebenfalls moglich, ein anderes wichtiges Feature zu realisieren: die
Suche nach thematisch ahnlichen Projekten. Eine der wichtigsten Voraussetzungen
dafur ist die Beschreibung von Projekten mittels Metadaten, welche von Nutzern vor-
genommen werden soll. Wie im Stand der Technik bereits beleuchtet, werden fur eine
thematische Gruppierung von Projekten in der Regel Tags verwendet. Die ubliche Im-
plementierung des Taggings, bei der zwei Projekte nur dann als ahnlich eingestuft
werden, wenn sie genau den selben Tag aufweisen, ist jedoch nicht machtig genug.
Durch Verwendung von Synonymen oder unterschiedlichen Begrien zur Beschrei-
bung von gleichen Sachverhalten werden ahnliche Projekte nicht mehr aundbar.
Das Ziel der Arbeit ist es, eine tagbasierte Verknupfung von Projekten zu realisieren,
die semi-automatisch ablauft. Nutzer mussen weiterhin Tags vergeben, um ein Pro-
jekt zu beschreiben. Die Verknupfung von ahnlichen Projekte wird jedoch nicht nur
7mehr unter http://de.wikipedia.org/wiki/Web_Ontology_Language
65

4 Nutzung der Intelligenz der Massen
manuell durch Vergabe von gleichen Tags realisiert, sondern zum Teil automatisch
durch Aundung von Projekten mit
"
ahnlichen\ Tags durchgefuhrt.
Das Konzept sieht vor, dass fur das Explorieren von ahnlichen Projekten mittels Lin-
ked Data8 weitere Metadaten beschaen werden sollen, die eine Ahnlichkeit zu den im
Projekt hinterlegten Metadaten aufweisen. Ahnlichkeit zwischen zwei Metadaten be-
deutet, dass sie Synonyme sind oder ahnliche Konzepte beschreiben, beziehungsweise
sich in dieselbe Kategorie einordnen lassen.
Zur Abfrage von ahnlichen Daten konnte DBpedia9, eine Initiative zur kollektiven
Erstellung von semantischen Metadaten fur Wikipedia-Artikel, als Datensilo bezie-
hungsweise Trippelstore benutzt werden. Um Abfragen nach dieser Art zu realisieren,
mussen die Ausgangsmetadaten, mit denen ein Projekt von Nutzern beschrieben
wird, zunachst selbst als Ressourcen vorliegen. Eine mogliche Kodierung kann der
Abbildung 4.2 entnommen werden.
1 <?xml version="1.0 " encoding="ut f 8"?>
2 <project
3 xmlns : rd f="h t t p : //www.w3 . org /1999/02/22 rdf syntax ns#"
4 xmlns:dc="h t t p : // pur l . org /dc/ e lements /1.1/ "
5 xmlns:geo="h t t p : //www.w3 . org /2003/01/ geo/wgs84 pos#"
6 xmlns : rd f s="h t t p : //www.w3 . org /2000/01/ rdf schema#">
7 <meta>
8 <rdf:RDF>
9 <rdf:Description
10 rd f : about="h t t p : // goa l1 . example . com/community/TUBer l in ">
11 <dc : t i t l e>Pr ivate</ dc : t i t l e>
12 <dc:creator>Benutzer</dc:creator>
13 <dc:created>20100505 T13:36:02</dc:created>
14 <dc:description></dc:description>
15 <rdfs:seeAlso
16 r d f : r e s o u r c e="h t t p : // dbpedia . org / resource /Ber l in " />
17 </rdf:Description>
18 <geo:Point>
19 <geo:lat></ geo:lat><geo:long></geo:long>
20 </geo:Point>
21 </rdf:RDF>
22 </meta>
23 </project>
Abbildung 4.2: Speicherung der Tags als Resourcen in den Projektmetadaten
8eine Initiative zum Bereitstellen von oentlich verfugbaren Daten im Internet, mehr unter http:
//www.linkeddata.org
9http://www.dbpedia.org
66

4.2 Losungskonzept
Von Nutzern als Zeichenkette (Literal) eingegebene Metadaten konnen mit Hilfe des
DBpedia URI Lookup Service10 in Ressourcen umgewandelt werden. Dieser Service
liefert eine URI zuruck, falls ein Objekt beziehungsweise eine Ressource unter diesem
Namen bei DBpedia existiert. In der Regel stellt der Name keine eindeutige Beschrei-
bung einer Ressource dar. So konnte zum Beispiel unter dem Namen "
Berlin\ sowohl
ein Fuballclub, eine Stadt oder auch
"
Westberlin\ oder
"
Ostberlin\ gemeint sein. Mit-
tels einer Vervollstandigungsfunktion konnten dem Nutzer bei der Eingabe von Tags
eine Auswahl von zutreenden Begrien und ihren Kontexten geboten werden. Aus
diesen kann sich der Nutzer die Ressource auswahlen, die in die Projekt-Metadaten
ubernommen werden soll.
Die gefundenen URIs konnten folgendermaen im Projekt gespeichert werden. Als
Verknupfung zwischen Projekten (Subjekte) und Tags (Objekte) konnte das Pradi-
kat rdfs:seeAlso benutzt werden, womit eine relativ lose Verbindung zwischen den
beiden hergestellt werden kann.
Greift ein Nutzer nun auf ein Projekt zu, konnten ihm weitere Explorationsmog-
lichkeiten angeboten werden, indem spekulative Vorschlage zu ahnlichen Projekten
dargestellt werden. Dazu konnen URIs der zum Projekt gespeicherten Metatags an
DBpedia gesendet werden. Mittels einer SPARQL-Abfrage konnten dann ahnliche
Ressourcen abgefragt werden. Zum einen konnen Pradikate wie owl:sameAs ver-
wendet werden. Zum anderen ist es moglich abzufragen, in welche Kategorien eine
Ressource eingeordnet wird und sich eine akkumulierte Liste von Ressourcen, die
ebenfalls in diesen Kategorien vertreten sind ausliefern zu lassen. Es wird dabei davon
ausgegangen, dass Ressourcen, die in einer Kategorie eingeordnet sind, eine gewisse
Ahnlichkeit aufweisen.
Eine Beispielabfrage in SPARQL fur die Ressource "
Berlin\ ist in Abbildung 4.3
dargestellt.
1 SELECT ? r e s WHERE f
2 ? r e s skos : s u b j e c t ? category .
3 f
4 SELECT ? category WHERE f
5 <http :// dbpedia . org / r e sou r c e / Ber l in> skos : s u b j e c t ? category
6 g
7 g
8 g
Abbildung 4.3: Query zur Abfrage von ahnlichen Resourcen
10http://lookup.dbpedia.org/
67

4 Nutzung der Intelligenz der Massen
4.2.3 Dierenzierung von Work
ows
Hat man eine Liste zu seinem Problem passender Work
ows gefunden, so ist es wich-
tig, aus dieser Liste den einen passenden Work
ow ausndig zu machen, den man
wiederverwenden mochte. Work
ows unterscheiden sich in vielen Kriterien vonein-
ander. Einige dieser Kriterien konnen automatisch durch die Nutzung des Systems
durch die breite Masse erhoben und zur Bewertung herangezogen werden. Diese wa-
ren beispielsweise:
 die Anzahl von Teilnehmer eines Projekts (Popularitat),
 die Zugriszahlen eines Projekts, sowie
 die Anzahl der Vererbungen eines Projekts.
Die ersten beiden Daten konnten in Form von XML in einer globalen Datei fur diver-
se Projekte gespeichert werden (siehe Abbildung 4.6). Die Anzahl der Vererbungen
konnte mittels einer SPARQL-Abfrage aus den RDF Daten erschlossen werden.
1 <community ID="ExampleCommunity " acce s s count="17 ">
2 <areas>
3 <area ID="ExampleArea " acce s s count="12 ">
4 <projects>
5 <project ID="ExampleProject " acce s s count="3" memberscount=
"4" cop i e s count="5">
6 <ratings>
7 <ef f ic iency>1</ ef f ic iency>
8 <completeness>2</completeness>
9 <complexity>1</complexity>
10 </ ratings>
11 </projects>
12 </area>
13 </areas>
14 </community>
Abbildung 4.6: Berucksichtigung der Bewertungsinformationen in der globalen XML-
Datei
Andere Kriterien konnten durch direkte Nutzerbewertung erhoben werden:
 die Ezienz des Work
ows (bestimmbar durch Ausfuhrung),
 die Vollstandigkeit des Work
ows und
 und die Komplexitat des Work
ows.
70

4.3 Realisierung
Diese Kriterien mussten sowohl fur einen Nutzer individuell gespeichert werden, als
auch deren Mittelwert fur ein Projekt in der globalen Datei aufgefuhrt werden. (siehe
Abbildung 4.7)
1 <community ID="ExampleCommunity ">
2 <areas>
3 <area ID="ExampleArea ">
4 <projects>
5 <project ID="ExampleProject ">
6 <ratings>
7 <ef f ic iency>5</ ef f ic iency>
8 <completeness>2</completeness>
9 <complexity>1</complexity>
10 </ ratings>
11 </projects>
12 </area>
13 </areas>
14 </community>
Abbildung 4.7: Berucksichtigung der Bewertungsinformationen in der XML-Datei
des Nutzers
Anhand dieser Daten konnte dann eine Sortierung der Ergebnismenge fur den Nutzer
ermoglicht werden.
Im folgenden Kapitel wird die vollzogene Implementierung der Wiederverwendung
durch Reuse und Repurpose detailiert beschrieben sowie die Umsetzung der Explo-
rationsmoglichkeiten nach Communities und Areas naher beleuchtet.
4.3 Realisierung
In diesem Kapitel wird auf die Implementierungsdetails der folgenden zwei Funktio-
nen eingegangen:
 Die Wiederverwendung und
 Exploration aller Projekte.
71

4 Nutzung der Intelligenz der Massen
4.3.1 Wiederverwendung durch Kopieren
Das Kopieren von Projekten wurde als Grundlage zur Realisierung der Wiederver-
wendbarkeit deniert. Nach dem Erstellen einer Kopie kann diese nun angepasst
werden, ohne den Ursprungswork
ow zu verandern.
Bei Goal1 stellen Projekte Work
ows dar, die aus mehreren Workpackages bestehen.
Diese Struktur spiegelt sich auch bei der Speicherung der Projekte im Dateisystem
wider (siehe Abbildung 4.8). Die Projektstruktur, Metadaten, sowie Rollen und Rech-
te werden in einer Projekt-XML-Datei gespeichert. Die Projektstruktur besteht aus
Verweisen auf Workpackages in Form von URIs, die gleichzeitig den Pfad zu den
Workpackage-XML-Dateien innerhalb des Projektordners beschreiben.
Abbildung 4.8: Ordnerstruktur eines Projekts aus der Sicht einer Area
Die Workpackage-Dateien bestehen aus einer Schema-Denition, Nutzdaten, die bei
der Ausfuhrung der Workpackages von Nutzern eingetragen werden und den Meta-
daten. Es existieren Templates fur alle Workpackage-Arten, die beim Hinzufugen von
Workpackages zu Projekten in den Projektordner kopiert werden.
Beim Kopieren von Projekten kann der Nutzer beein
ussen, in welcher Community
und Area die Kopie gespeichert werden soll (siehe Abbildung 4.9). Das Kopieren
ist nur in die Communities beziehungsweise Areas erlaubt, die dem Nutzer gehoren.
Ferner kann ein neues Bild fur das kopierte Projekt hochgeladen und ein neuer Titel
fur jenes festgelegt werden.
Innerhalb des Prozesses wird ein physischer Kopiervorgang der Projekt-XML-Datei in
den neu erstellten Ordner der Projektkopie angestoen. Damit werden die Struktur
72

4 Nutzung der Intelligenz der Massen
1 <?xml version="1.0 " encoding="ut f 8"?>
2 <project xmlns:rdf="h t t p : //www.w3 . org /1999/02/22 rdf syntax ns#"
xmlns:dc="h t t p : // pur l . org /dc/ e lements /1.1/ " xmlns:geo="h t t p : //www.
w3 . org /2003/01/ geo/wgs84 pos#">
3 <structure>
4 <level id="Leve l 1 ">
5 <choice ends="Leve l 1 " width="1" l e f t="1">
6 <wp id="h t t p : // goa l1 . example . com/com/area/ Be i s p i e lP r o j e k t /
Adresse ingabe /0 " roles=" j everyone j " weight="1">Green</wp>
7 </choice>
8 <choice ends="Leve l 1 " width="1" l e f t="2">
9 <wp id="h t t p : // goa l1 . example . com/com/area/ Be i s p i e lP r o j e k t /
Anmeldung/0 " roles=" j everyone j " weight="1">Green</wp>
10 </choice>
11 </ level>
12 </structure>
13 <roles>
14 <role id="everyone " rights="execu te "></ role>
15 <role id=" s e l f " rights="execu te "><user>Benutzer1</user></ role>
16 </ roles>
17 <users>
18 <admin ID="Benutzer1 " /><user ID="Benutzer2 " />
19 </users>
20 <timeSpan>
21 <startDate>20091201</startDate><endDate>20100224</endDate>
22 </timeSpan>
23 <meta>
24 <rdf:RDF>
25 <rdf:Description rd f : about="p r o j e c t / p r o j e c t ">
26 <dc : t i t l e>B e i s p i e l P r o j e k t</ dc : t i t l e>
27 <dc:creator>Benutzer1</dc:creator>
28 <dc:description>Lorem ipsum do lo r s i t amet . . .</dc:description>
29 </rdf:Description>
30 <geo:Point><geo:lat>12</ geo:lat><geo:long>13</geo:long></
geo:Point>
31 </rdf:RDF>
32 <image></image>
33 <slogan>Slogan</slogan>
34 <abstract>Abstract</abstract>
35 <mission>Miss ion</mission>
36 <vision>Vis ion</vision>
37 <aims>Aims</aims>
38 <values>Value</values>
39 <guidelines>Guide l ine s</guidelines>
40 <events>Events</events>
41 <agbs>AGBs</agbs>
42 <contacts>Contacts</contacts>
43 <open>Open</open>
44 </meta>
45 <v i s ib i l i t y>Al l</ v i s ib i l i ty>
46 </project>
Abbildung 4.10: Projekt-XML vor dem Kopiervorgang
74

4.3 Realisierung
1 <?xml version="1.0 " encoding="ut f 8"?>
2 <project xmlns:rdf="h t t p : //www.w3 . org /1999/02/22 rdf syntax ns#"
xmlns:dc="h t t p : // pur l . org /dc/ e lements /1.1/ " xmlns:geo="h t t p : //www.
w3 . org /2003/01/ geo/wgs84 pos#">
3 <structure>
4 <level id="Leve l 1 ">
5 <choice ends="Leve l 1 " width="1" l e f t="1">
6 <wp id="h t t p : // goa l1 . example . com/com2/area2/ Pro j e k t kop i e /
Adresse ingabe /0 " roles=" j everyone j " weight="1">Yellow</wp>
7 </choice>
8 <choice ends="Leve l 1 " width="1" l e f t="2">
9 <wp id="h t t p : // goa l1 . example . com/com2/area2/ Pro j e k t kop i e /
Anmeldung/0 " roles=" j everyone j " weight="1">Yellow</wp>
10 </choice>
11 </ level>
12 </structure>
13 <roles>
14 <role id="everyone " rights="execu te "></ role>
15 <role id=" s e l f " rights="execu te "><user>Benutzer2</user></ role>
16 </ roles>
17 <users><admin ID="Benutzer2 " /></users>
18 <timeSpan>
19 <startDate>20100601</startDate><endDate>20100601</endDate>
20 </timeSpan>
21 <meta>
22 <rdf:RDF>
23 <rdf:Description rd f : about="p r o j e c t / p r o j e c t ">
24 <dc : t i t l e>Pro jektkop i e</ dc : t i t l e>
25 <dc:creator>Benutzer2</dc:creator>
26 <dc:description></dc:description>
27 </rdf:Description>
28 <geo:Point><geo:lat></ geo:lat><geo:long</geo:long></geo:Point>
29 </rdf:RDF>
30 <image></image>
31 <slogan></slogan>
32 <abstract></abstract>
33 <mission></mission>
34 <vision></vision>
35 <aims></aims>
36 <values></values>
37 <guidelines></guidelines>
38 <events></events>
39 <agbs></agbs>
40 <contacts></contacts>
41 <open></open>
42 </meta>
43 <v i s ib i l i t y>Community</ v i s ib i l i t y>
44 </project>
Abbildung 4.11: Projekt-XML nach dem Kopiervorgang
75

4 Nutzung der Intelligenz der Massen
4.3.2 Exploration der Projekte
Bei Goal1 sollen neben der im Konzept naher erlauterten Exploration nach Tags drei
weitere, wesentlich grundlegendere Explorationsmoglichkeiten implementiert werden:
 Die Au
istung aller Projekte,
 die Au
istung der Projekte einer Area und
 die Au
istung der eigenen Projekte des Nutzers.
Die ersten beiden Explorationsmoglichkeiten werden ahnlich implementiert.
In einer globalen XML-Datei ist die Hierarchie aller im System eingep
egten Commu-
nities, ihrer Areas sowie Projekte gespeichert. Die Struktur der Dateiordner spiegelt
diese Hierarchie in der Form /Communityname/Areaname/projektname.xml wider.
Zu jedem Projekt existiert eine eigene XML-Datei, die im Dateisystem gespeichert ist.
Diese beinhaltet neben der Projektstruktur in Form von enthaltenen Workpackages
auch Metadaten und vor allem die Nutzerrechte fur das jeweilige Projekt.
Beim Auslesen von Projekten-Dateien wird haug LINQ eingesetzt. LINQ ist eine
Komponente des .NET Frameworks, die eine SQL-ahnliche Syntax zur Abfrage von
Datenmengen unter anderem in Collections deniert. Bei der Anzeige der Projek-
tau
istung wird im einzelnen wie folgt vorgegangen:
 Schritt 1: Hole alle Communities, die innerhalb der globalen XML-Datei aufge-
listet sind.
 Schritt 2: Filtere die Communityauswahl nach Communties, in denen der aktu-
elle Nutzer Mitglieds- oder Administratorrechte hat (dazu werden Informatio-
nen aus der Communitydatei herangezogen). Hole alle Areas aus der globalen
XML-Datei, die der ausgewahlten Communty untergeordnet sind.
 Schritt 3: Filtere die Areaauswahl nach Communties, in denen der aktuelle Nut-
zer Mitglieds- oder Administratorrechte hat (es wird in der Areadatei nachge-
schlagen). Hole alle Projekte aus der globalen XML-Datei, die der ausgewahlten
Areas zugehoren.
Wie in der Abbildung 4.12 dargestellt, wird jedes Projekt in der Au
istung mit da-
zugehorigem Bild, Titel und Kurzbeschreibung dargestellt. Daruber hinaus wird sein
Fertigstellungsstatus in Form eines Fortschrittsbalken visualisiert. Ferner wird der
Name der dazugehorigen Area und Community eingeblendet. Durch deren Anklicken
kann der Nutzer direkt zu diesen navigieren. Uber einen speziellen Button in der rech-
ten oberen Ecke ist es zusatzlich moglich, Projekte anzuzeigen, bei denen man keine
76

4.3 Realisierung
Zugangs-Berechtigung hat. Durch eine groe Schalt
ache wird ein Zusatzmenu auf-
geklappt, in welchem unter anderem die Moglichkeit besteht, das aktuell angewahlte
Projekt im Sinne der Wiederverwendung zu kopieren.
Abbildung 4.12: Au
istung aller Projekte im Goal1
77

4.3 Realisierung
Abbildung 4.14: Community- und Areabaum im Dashboard eines Goal1 Nutzers
Im Dashboard existieren ebenfalls Projektau
istungen. Dabei werden zum einen ei-
gene Projekte des Nutzers, also solche, die von ihm angelegt wurden dargestellt. Zum
anderen nden sich in einer weiteren Au
istung Projekte in denen der Nutzer zwar
Mitglied, aber kein Eigentumer ist (siehe Abbildung 4.15).
Abbildung 4.15: Ubersicht der eigenen und involvierten Projekte eines Nutzers
79

5 Auswertung
Aufgaben mittels Formularen direkt zu bearbeiten und das System uber das Web er-
reichbar ist, konnen die ersten funf Kriterien der Tabelle 5.1 als gut bewertet werden.
Fur eine sehr gute Bewertung in den Kategorien Automatisierbarkeit und Struktu-
rierbarkeit steht das System allerdings den untersuchten Spezikationsprachen BPEL
und BPMN nach. Ebenso ist die Bedienung des Editors nicht ganz trivial und bei
einer sehr groen Anzahl an Aktivitaten wird auch die hier entwickelte Darstellungs-
form unubersichtlich. Jedoch wird durch ein spezielles Dashboard fur einen besseren
Uberblick uber ausstehende Aufgaben gesorgt. Das Zuganglichkeits-Kriterium kann
nicht als sehr gut bewertet werden, da es noch keinen Zugangspunkt fur mobile End-
gerate gibt. Im Sinne der Flexibilitat kann das System sehr gut bewertet werden, da
nachtragliche Anderungen und Erweiterungen eines Prozesses unterstutzt werden.
Im Zuge der Entwicklung einer Online-Community wurden zwar viele konzeptionelle
Ansatze entworfen, jedoch wurde im Zeitrahmen dieser Arbeit nur ein kleiner Teil da-
von realisiert. So mussen die Kriterien Kommunikation und Selbstdarstellung als sehr
schlecht bewertet werden, da es noch keinerlei Unterstutzung dafur in der aktuellen
Implementierung gibt. Gruppierung ist mittels des vorgestellten Community-Area-
Modells moglich, ebenso die Zuweisung von speziellen Sichtbarkeiten zur Einrichtung
von Bereichen, die nicht fur alle Benutzer des Systems zuganglich sein sollen. Durch
die geschaene Moglichkeit Projekte zu kopieren und einmal angelegte Workpackages
in weiteren Projekten einzusetzen kann man den Bereich Wiederverwendung als gut
beurteilen. Mangels der Moglichkeiten Projekte zu ltern und zu suchen, sowie der
fehlenden Darstellung von detaillierten Projektinformationen konnen die Kategorien
Exploration und Dierenzierung nicht positiv bewertet werden.
Im letzten Kapitel dieser Arbeit wird noch einmal zusammengefasst, welche Teile der
vorgestellten Konzepte implementiert wurden und welche Erweiterungsmoglichkeiten
im Rahmen dieser Thematik fur weitere Arbeiten denkbar sind.
82

6 Zusammenfassung und Ausblick
Im Rahmen dieser Arbeit wurde ein webbasiertes, communitygestutztes Work
ow-
managementsystem entwickelt. Zusammenfassend wurden folgende Funktionen im-
plementiert. Es ist moglich:
 Benutzer anzulegen,
 Communities, Areas und Projekte zu erstellen und zu explorieren,
 diese mittels Metadaten zu personalisieren,
 Communities mittels Beziehungen (Vater, Sohn, Partner) zu verknupfen,
 Sichtbarkeiten zu denieren,
 Prozesse mittels einer vorgegebenen Menge an Workpackages zu modellieren,
 deren Aktivitaten auszufuhren,
 Projekte zu favorisieren und zur Wiederverwendung zu kopieren, sowie
 eine Ubersicht uber Projekte und deren Status zu erhalten.
Jedoch stellt die Anwendung im Vergleich zur Konzeptionierung in der derzeitigen Im-
plementierung nur einen eingeschrankten Funktionsumfang zur Verfugung. Die nicht
umgesetzten Teile der beschriebenen Konzepte konnen in weiteren Arbeiten aufge-
grien und realisiert werden. Besondere Aufmerksamkeit sollte dabei den folgenden
Weiterentwicklungsmoglichkeiten geschenkt werden.
Zur Unterstutzung des Wiederverwendungsgedanken auf allen Ebenen sollte ein visu-
eller Workpackage-Editor zur Verfugung gestellt werden, um neue Workpackages zu
erstellen. Dieser sollte in der Lage sein, beliebige Aktivitaten uber einen Assistenten
auf der Webseite zu denieren. Einmal erstellte Workpackages konnten dann dem
gesamten Nutzerkreis zur Verwendung angeboten werden. Um auch bei einer sehr
rapide wachsenden Anzahl solcher Arbeitspakete die Passenden zu nden mussten
Filter- und Suchoptionen geschaen werden.
Ferner konnten sich fortfuhrende Arbeiten mit der Entwicklung von mobilen Client-
anwendungen befassen. So konnte zum Beispiel dem Nutzer die Moglichkeit geboten
83

Literaturverzeichnis
[1] Boeree, George: Abraham Maslow. Website. http://webspace.ship.edu/
cgboer/maslow.html (zuletzt abgerufen am: 01. Juni 2010).
[2] Facebook: Facebook Factsheet. Website. http://www.facebook.com/press/
info.php?factsheet (zuletzt abgerufen am: 01. Juni 2010).
[3] Forte, Andrea und Amy Bruckman: Why Do People Write for Wiki-
pedia? Incentives to Contribute to Open-Content Publishing. http://www.
andreaforte.net/ForteBruckmanWhyPeopleWrite.pdf (zuletzt abgerufen am:
01. Juni 2010).
[4] Goderis, Antoon, Ulrike Sattler, Phillip Lord und Carole Goble:
Seven Bottlenecks to Work
ow Reuse and Repurposing. Science.
[5] Green, Christopher D.: Abraham Maslow: A Brief Reminiscence. Journal
of Humanistic Psychology, 50:370{396, Oktober 2000.
[6] Howe, Jeff: The Rise of Crowdsourcing, 2006.
[7] Jensen, Carlos, John Davis und Shelly Farnham: Finding others online:
reputation systems for social online spaces. Conference on Human Factors in
Computing Systems, 2002.
[8] Kim, Amy Jo: Community Building on the Web : Secret Strategies for Successful
Online Communities. Peachpit Press, 2000.
[9] Muller, Joachim: Work
ow-based Integration. Xpert.press. Springer-Verlag,
Berlin/Heidelberg, 2005.
[10] Open Workbench Project: Open Workbench - Features. Websi-
te. http://www.openworkbench.org/index.php?option=com_content&task=
view&id=31&Itemid=41 (zuletzt abgerufen am: 01. Juni 2010).
[11] O'Reilly, Tim: What Is Web 2.0 - O'Reilly Media. Website. http://oreilly.
com/pub/a/web2/archive/what-is-web-20.html?page=2 (zuletzt abgerufen
am: 01. Juni 2010).
[12] Papsdorf, Christian und G. Gunter Vo: Wie Surfen zu Arbeit wird:
85

Selbststandigkeitserklarung
Hiermit erklaren wir, dass wir die vorliegende Arbeit selbststandig angefertigt, nicht
anderweitig zu Prufungszwecken vorgelegt und keine anderen als die angegebenen
Hilfsmittel verwendet haben. Samtliche wissentlich verwendete Textausschnitte, Zi-
tate oder Inhalte anderer Verfasser wurden ausdrucklich als solche gekennzeichnet.
Chemnitz, den 01.06.2010
Robert Krawatzeck
Michael Krug
Daniel Pouzemski
89