Webbasierte_ Lehr_und_Lernsysteme

Transcription

Zur Homepage der Publikation
Ingo Ibelings (Hrsg.)
Webbasierte Lehr- und Lernsysteme
Entwicklung/Auswahl und Einsatz
in öffentlichen und privaten Bildungseinrichtungen
Beschreibung
Name
Vorlesung
Teil von
verwendbar
bespricht
benutzt
Art
vertieft
Aufgabentext
Thema
Übung
benutzt
Lösungsansatz
Beschreibung
hat
Lösung
Name
Beschreibung
BIS-Verlag
der Carl von Ossietzky
Universität
Oldenburg
Bibliotheksund Informationssystem
der Universität
Oldenburg
2005
Das Werk ist einschließlich aller seiner Teile urheberrechtlich geschützt. Jede Verwertung außerhalb der Grenzen des Urheberrechts bedarf der Zustimmung der Herausgebenden. Dies gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Medien.
© BIS-Verlag, Oldenburg 2006
Verlag
Druck / und Informationssystem
BIS-Verlag
Verlag:/ BibliotheksVertrieb:
der CarlOldenburg
von Ossietzky Universität Oldenburg
der
Carl von Ossietzky Universität
Postfach 25 41, 26015 Oldenburg
(BIS) – Verlag
Tel.: 0441/798 2261, Telefax: 0441/798 4040
Postfach 2541, 26015 Oldenburg
e-mail:
[email protected]
Tel.: 0551/798 2261, Telefax:
0441/798-4040
e-mail: [email protected]
ISBN3-8142-0991-5
3-8142-0991-5
ISBN
3
Vorwort
Der vorliegende Seminarband entstand im Rahmen des Seminars „Web Engineering –
Entwicklung von Lehr- und Lernsystemen“ im Wintersemester 2004/05 an der Carl von
Ossietzky Universität Oldenburg. Schwerpunkt der Lehrveranstaltung war eine inhaltliche Auseinandersetzung mit den Themengebieten „Grundlagen von Lehr- und Lernsystemen“, „Systemarten des E-Learning“ und „Entwicklungsaspekte für E-LearningSysteme“.
Kaum ein Medium ist derartig vielen Änderungen und Weiterentwicklungen unterworfen wie das World Wide Web (WWW). Der ständige technologische Wandel sowie die
Anwendungsvielfalt ermöglicht breite Einsatzmöglichkeiten im beruflichen und privaten Bereich. Grundlage des Seminars war die Betrachtung öffentlicher und privater
Bildungseinrichtungen, die immer wieder periodisch wiederkehrende und recht außergewöhnliche Termine zu koordinieren und anzukündigen, Menschen anzusprechen und
zur Teilnahme zu motivieren und vor allem Informationen zu geben und Wissen zu vermitteln haben. Hinzu kommt die Verwaltung der Teilnehmerinnen und Teilnehmer und
die Selbstdarstellung der hauptund nebenamtlichen Dozentinnen und Dozenten. Die
Information über vorhandene Literatur und eine zuverlässige „Meckerecke“ runden das
Profil der Bildungseinrichtungen ab. In der Summe unterstützen diese harten Faktoren
auch die Integration neuer Mitarbeiterinnen und Mitarbeiter in die bestehende Organisation. Darüber hinaus spielen weiche Faktoren, wie z. B. die Lernatmosphäre und die
aufgebaute Stimmung eine weitere Rolle für den Erfolg der Bildungseinrichtung.
Ein vielbeachteter Schwerpunkt liegt dabei auf den Bereich webbasierter Lehr- und
Lernsysteme, die die traditionellen Lehr- und Lernformen in vielen Bereichen ergänzen bzw. abrunden. Speziell auf den Bildungsbereich zugeschnittene Webanwendungen sollen eine ganze Reihe von Voraussetzungen erfüllen. Neben den bereits genannten Anforderungen an das Profil einer Bildungseinrichtung müssen weiterhin grundlegende Lernformen wie z.B. Behaviorismus, kognitiver Behaviorismus, traditioneller
Kognitivismus und Konstruktivismus mit einfließen, andererseits gilt es, allgemeine
Lehrformen bzw. Lehrziele (kognitive, affektive und psychomotorische) näher zu betrachten. Die unterschiedlichen Zielvorstellungen des Web Engineerings bzw. Web Designs müssen daher bei der Entwicklung bzw. Auswahl und Einführung von Lehr- und
Lernsystemen immer differenziert berücksichtigt werden. Um deren professionellen
Einsatz nachhaltig zu unterstützen, ist zumindest ein minimales Grundverständnis für
die Entwicklungstechnologien unerlässlich. Die hier zusammengeführten Einzelbeiträge geben dabei erste Hilfestellungen und erläutern anhand praxisnaher Beispiele aus
dem öffentlichen und privaten Bildungswesen die begrifflichen Grundlagen. Weiterhin haben die Autoren entsprechende Handlungsempfehlungen formuliert, in welchem
Umfang eine Umsetzung der hier vorgestellten Systeme möglich ist.
Die Ergebnisse dieser Seminararbeit sollen jedoch nicht nur informieren, sondern auch
zu weiteren Diskussionen anregen. Bereits in vorangegangenen Seminaren wurde hierfür der Grundstein gelegt und ein Forum eingerichtet, um die zukünftigen Entwicklungen auch auf diesem Gebiet weiter zu beobachten und inhaltlich zu diskutieren.
Sie finden das Forum unter der URL http://www.informatik-politik.de. Auch freue ich
mich über Zuschriften an [email protected]. Da die Entwicklung und der
Einsatz webbasierter Lehr- und Lernsysteme in öffentlichen und privaten Bildungsein-
4
richtungen auch immer eine politische Komponente beinhaltet, ist die Zuordnung dieser Thematik zu dem Schwerpunkt „Informatik-Politik“ angemessen und gewollt. Ich
lade Sie daher herzlich ein, mein Vorhaben mit einem aktiven Beitrag (Vortragsfolien,
Referat, URL, ...) zu unterstützen.
Hiermit bedanke ich mich bei allen Seminarteilnehmern für die erfolgreiche Durchführung unseres Seminars „Web Engineering– Entwicklung von Lehr- und Lernsystemen“. Auch wenn die Bearbeitung dieses Seminarbandes von allen Seminarteilnehmern nachhaltig unterstützt wurde, gebührt jedoch Marco Lübke für die redaktionelle
Bearbeitung und Dirk Räder für die Korrektur der Vorlage besonderer Dank. Für die
Inhalte sind die Autoren verantwortlich, die Verantwortung für evtl. noch vorhandene
formale Fehler verbleibt jedoch beim Herausgeber.
Oldenburg, Oktober 2005
Ingo Ibelings
Inhaltsverzeichnis
Dirk Räder
1 Grundlagen der Webtechnologien
7
Marco Lübcke
2 Webserver und Webservices für Lernsysteme
23
Thilo Focke
3 Web Engineering/Web Engineering-Technologien
43
Markus Fromme
4 Vorgehensmodelle für Web-Anwendungen
63
Jens Peternel
5 Anwednungen für Einzelkurse (CBTs und WBTs)
81
Andreas gr. Austing
6 Implementation von Lehr- und Lernsystemen
99
Stefan Bitzer
7 Kosten/Nutzen von Wissensmanagementsystemen
5
115
6
INHALTSVERZEICHNIS
Kapitel 1
Grundlagen der
Webtechnologien
Dirk Räder
Inhalt
1.1
1.2
1.3
1.4
1.5
1.6
1.7
Arten von Bildungseinrichtungen . . . . .
Staatliche Bildungseinrichtungen . . . . . .
Private Bildungseinrichtungen . . . . . . . .
Dienste im Internet . . . . . . . . . . . . .
World Wide Web . . . . . . . . . . . . . .
Kommunikation . . . . . . . . . . . . . . .
Für Bildungseinrichtungen relevante Dienste
Austausch zwischen verschiedenen LMS . .
Verschiedene OpenSource-Lösungen . . .
Stud.IP . . . . . . . . . . . . . . . . . . . .
ILIAS . . . . . . . . . . . . . . . . . . . .
Moodle . . . . . . . . . . . . . . . . . . .
Claroline . . . . . . . . . . . . . . . . . . .
Manhattan Virtual Classroom . . . . . . . .
Server auf OpenSource-Basis . . . . . . .
Betriebssystem . . . . . . . . . . . . . . . .
Webserver . . . . . . . . . . . . . . . . . .
Mailserver . . . . . . . . . . . . . . . . . .
Datenbank . . . . . . . . . . . . . . . . . .
Weitere Anwendungen . . . . . . . . . . . .
OpenSource Framework . . . . . . . . . .
Nützliche Links . . . . . . . . . . . . . . .
Ausblick: Kommerzielle Systeme . . . . .
WebCT . . . . . . . . . . . . . . . . . . .
Blackboard . . . . . . . . . . . . . . . . .
Fazit . . . . . . . . . . . . . . . . . . . . .
7
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8
8
8
8
9
9
9
11
11
11
12
13
13
14
14
14
16
16
17
17
17
19
20
20
20
21
8
KAPITEL 1. GRUNDLAGEN DER WEBTECHNOLOGIEN
1.1 Arten von Bildungseinrichtungen
Wir können die meisten der in Deutschland betriebenen Bildungseinrichtungen in verschiedene Klassen einteilen, was wir nutzen, um die unterschiedlichen Anforderungen
und die vorhandenen Ressourcen besser einschätzen zu können.
Staatliche Bildungseinrichtungen
Der Staat trägt in Deutschland den größten Teil der Bildungseinrichtungen, die sich
weiter in die Bereiche allgemeinbildende Schulen, berufsbildende Schulen, universitäre Einrichtungen und weiterbildende Schulen unterteilen lassen. Um diese Einteilung
deutlicher zu machen, nennen wir einige Vertreter für die verschiedenen Teile.
Allgemeinbildende Schulen: Grund- und weiterführende Schulen (Gesamt-, Hauptund Realschulen sowie Gymnasien)
Berufsbildende Schulen: Berufsschulen und -kollegs
Universitäre Einrichtungen: Fachhochschulen und Hochschulen
Weiterbildende Schulen: Volkshochschulen
Private Bildungseinrichtungen
Neben den staatlich finanzierten Bildungseinrichtungen gibt es auch zahlreiche Einrichtungen in der freien Wirtschaft. Hier bietet sich eine ähnlich feine Gliederung wie
bei den staatlichen Bildungseinrichtungen an: Auf der einen Seite befindet sich die innerbetriebliche Weiterbildung und auf der anderen die privatwirtschaftlichen Bildungsanbieter.
Innerbetrieblich: Abteilungen in größeren Unternehmen wie ”betriebliche Weiterbildung”, ”Aus- und Fortbildung” oder ähnliche, die für die Mitarbeiter selber Bildungsmaßnahmen anbieten oder als Großkunde bei anderen Bildungsanbietern
ganze Seminare buchen.
private Bildungsanbieter: Privatuniversitäten wie Witten-Herdecke, die VW-Universität (auf neudeutsch ”Corporate Campus”) oder Fernstudienzentren wie die Studiengemeinschaft Darmstadt
1.2 Dienste im Internet
Die Dienste, die im Internet am meisten in Anspruch genommen werden, kommen
aus den Bereichen ”World Wide Web” und ”Kommunikation”. Eines der wichtigsten
Merkmale zur Unterscheidung dieser Dienste ist die Richtung, in die Informationen
1.2. DIENSTE IM INTERNET
9
fließen: Bei Diensten des World Wide Web fließen die Informationen im wesentlichen
von einem Anbieter zu vielen Nutzern, bei solchen der Kommunikation werden dagegen Informationen in mehrere Richtungen ausgetauscht.
World Wide Web
Nahezu alle Dienste im World Wide Web (WWW) werden von den Nutzern mit Hilfe von Browsern wie Firefox, Internet Explorer oder Opear abgerufen. Wir zählen zu
ihnen Suchmaschinen wie Google [wwwb] oder Yahoo [wwwd], Weblogs wie den
Schockwellenreiter [wwwa] oder auch eines der größten Lexikas im Internet: Wikipedia [wwwc]. Genauso gehören auch die Webseiten von Bildungseinrichtungen aller
Art und die in Verruf geratenen File-Sharing-Anwendungen wie Kazaa in diese Gruppe
von Diensten. Ihnen allen gemeinsam ist die Tatsache, dass ein Nutzer mit relativ wenig
Eingaben Informationen abrufen und sie beispielsweise zum Lernen verwenden kann.
Somit erhält der Nutzer auf Anforderung Informationen; diese Art der Informationsweitergabe können wir gut mit dem klassischen Frontalunterricht oder der Vorlesung
im Wortsinne vergleichen.
Kommunikation
Im Bereich der Kommunikation können wir noch genauer nach synchroner und asynchroner Kommunikation unterscheiden. Bei der synchronen Kommunikation, beispielsweise über Instant Messaging Systeme oder Chats, unterhalten sich zwei oder
mehr Personen direkt miteinander. Sie sehen die Antworten der anderen Teilnehmer
nahezu in dem Moment, in dem der andere sie abgeschickt hat. Wir können hier also von einer Telefonat mittels Tastatur und Bildschirm sprechen. Bei der asynchronen Kommunikation hingegen sehen die Teilnehmer die Antworten der anderen erst,
wenn sie sich erneut im System anmelden und die Antworten abfragen. Wir können
hier also von elektronischem Briefverkehr sprechen. Dieses Prinzip wird bei Emails,
Newsgroups und Foren verwendet.
Foren nehmen eine Sonderstellung bei den Diensten im Internet ein: Sie dienen einerseits der Kommunikation, werden aber andererseits über das World Wide Web übertragen und in Browsern angezeigt. Damit fallen sie dem Grunde nach in beide Kategorien.
Bei Überlegungen, welche Foren eingesetzt bzw. angeboten werden sollen, müssen also beide Bereiche berücksichtigt werden.
Für Bildungseinrichtungen relevante Dienste
Nachdem wir nun sowohl die verschiedenen Bildungseinrichtungen als auch die unterschiedlichen Dienste im Internet betrachtet haben, wollen wir nun klären, welche
Dienste von welcher Bildungseinrichtung sinnvoll genutzt werden können.
Zunächst einmal werden sicherlich sämtliche Bildungseinrichtungen sich selbst im Internet präsentieren wollen. Dies tun sie mit einer Webseite, auf der sie einen Überblick
10
über die Einrichtung und Interessierten Informationen über das Studienangebot, die
möglichen Abschlüsse, Immatrikulation und andere für die Einrichtung wichtige Dinge geben. Wichtig ist dabei, auch Email-Adressen anzugeben, über die Interessierte
Kontakt mit den zuständigen Mitarbeitern der Einrichtung aufnehmen können. Hier
muss über entsprechende Dienstanweisungen sicher gestellt werden, dass die Emails
im Regelfall innerhalb von 24 Stunden beantwortet werden. Ansonsten entsteht bei
Interessierten der Eindruck, dass sich die Einrichtung nicht um neue Lerner bemüht.
Außerdem ist Email das kostengünstigste Kommunikationsmittel, das heute verfügbar
ist - vor allem, wenn es darum geht, alle Interessierten oder alle Lernenden möglichst
schnell mit einem Rundschreiben zu erreichen.
Bereits eingeschriebenen Lernenden werden die Bildungseinrichtungen auch ein System zur Unterstützung des Lernprozesses zur Verfügung stellen. Solch ein Lernunterstützungssystem, kurz LÜS, ist als Ergänzung zur Präsenzlehre gedacht. Dabei unterstützt es zum einen den Dozenten, indem es ihm einen guten Teil der Kursverwaltung
abnimmt und sich um die Verteilung von Lehrmaterialien wie Skripte oder Präsentationen kümmert. Zum anderen sind LÜS als Unterstützung für die Lernenden gedacht. Ihnen wird das Finden von Materialien, Literaturempfehlungen und anderen Informationen rund um die belegten Fächer wesentlich erleichtert. Gleichzeitig bieten die meisten
LÜS auch Kommunikationsmöglichkeiten in Form von Diskussionsforen, Chats oder
internen Email-Systemen. Dies ermöglicht es den Lernenden, sofern für alle Fächer
das selbe LÜS verwendet wird, von einer Webseite aus alles, was mit ihrem momentanen Lernbedarf zu tun hat, zu erreichen und sich an zentraler Stelle zu informieren,
anstatt sich durch mehrere Seiten klicken oder in Bibliotheken nach den Handapparaten suchen zu müssen. Gute LÜS bieten auch weitere Funktionen wie Wikis, in diesem
Fall also kollaboratives Bearbeiten von Dokumenten, oder Anbindung an bestehende
Infrastrukturen an.
Wir wollen allerdings nicht nur LÜS betrachten, sondern insbesondere Lernmanagementsysteme, kurz LMS, die Kurse oder sogar ganze Studiengänge vollständig in das
Internet abbilden können. Vollständig heißt hier inklusive Projektarbeiten, Selbsttests,
Übungen und Klausuren. Auch die Benotung kann in LMS online durchgeführt werden. Damit können, wenn alle Teile eines Kurses von der rechtlichen Seite her über
das Internet stattfinden dürfen, Präsenzveranstaltungen überflüssig werden. Bedenklich
sind hier vor allem die Prüfungsleistungen, da die Dozenten nicht überprüfen können,
dass auch wirklich ihr Student vor dem Computer sitzt und die Prüfung selbständig,
ohne unerlaubte Hilfestellungen, bearbeitet.
Für den Dozenten bieten LMS neben den Funktionen von LÜS in der Regel auch Tools
zur Erstellung von Lerneinheiten, ein virtuelles Klassenzimmer und eine automatische
Benotung bei Multiple-Choice-Tests an. Wenn es sich um sehr komplexe Systeme handelt, können sie auch Freitext-Antworten nach bestimmten Schlagwörtern durchsuchen
und anhand deren Vorkommen Punkte vergeben. Dieses Verfahren betrachten wir allerdings mit einiger Skepsis, denn hier sind gute Möglichkeiten zum Betrug vorhanden:
Es kann reichen, alle Schlagwörter, die in den Lernmaterialien genannt wurden, hinzuschreiben (und sich dabei nicht zu vertippen!), um volle Punktzahl zu erreichen.
Den Lernenden können LMS, wenn ganze Veranstaltungen online stattfinden, die Wege zur Bildungseinrichtung ersparen. Dies führt zu einer wesentlich freieren Zeiteinteilung auf Seiten der Lernenden, stellt aber gleichzeitig auch spürbar höhere Anforderungen an das Selbstmanagement und die Selbstdisziplin des Lernenden. Ansonsten
bieten sie ihnen die gleichen Hilfen wie LÜS.
1.3. VERSCHIEDENE OPENSOURCE-LÖSUNGEN
11
Wie wir sehen, sind sich LÜS und LMS sehr ähnlich. So können wir LMS auch fast
immer als LÜS nutzen, wir müssen lediglich die nicht benötigten Funktionen abschalten – und können sie bei Bedarf wieder freigeben. Sind sie nicht vorhanden, weil wir
nur ein LÜS nutzen, müssen wir dagegen ein neues System implementieren und sowohl Dozenten als auch Nutzer erneut in die Benutzung einweisen. Somit können wir
die Unterscheidung, was ein LÜS und was ein LMS ist, nur schwer festlegen - sie ist
immer auch von den Anforderungen der Bildungseinrichtung abhängig.
In diesem Zusammenhang sind uns zwei weitere Dinge aufgefallen: zum einen haben
wir bei den gängigen Quellen für Open Source Software keine reinen LÜS gefunden,
die noch weiter entwickelt werden. Zum anderen konnten wir im englischen Sprachraum keine Unterscheidung zwischen LMS und LÜS ausmachen; hier herrschen Bezeichnungen wie ”Virtual Classroom” oder ”Course Management” vor.
Austausch zwischen verschiedenen LMS
Da auf dem Markt viele verschiedene LMS angeboten werden, gibt es nahezu genauso viele Formate, in denen die einzelnen Kurse und Unterrichtseinheiten gespeichert
werden. Aus diesem Grund hat das US Verteidigungsministerium eine Sammlung von
Standards entwickeln lassen, mit dem (nahezu) alle Informationen über Kurse, Unterrichtseinheiten und Lernmaterialien ausgetauscht werden können. Das so genannte
”Shareable Content Object Reference Modell” oder kurz SCORM ist im Gegensatz
zu vielen anderen Entwicklungen der US Regierung ein öffentlich verfügbares Modell. Es gliedert sich im wesentlichen in die Bestandteile ”Laufzeitumgebung”, die die
Anforderungen an die Lernmanagementsysteme definiert, das ”Modell zum Sammeln
von Inhalten”, das festlegt, wie die einzelnen Inhalte beim Speichern formatiert und
komprimiert werden müssen, um einen reibungslosen Austausch zwischen verschiedenen Applikationen zu gewährleisten und ”Sequenzen und Navigation”, das definiert,
wie SCORM-konforme Inhalte von Nutzer oder System bearbeitet und in ihnen navigiert werden kann. Der aktuellste Stand ist SCORM 2004, verabschiedet im Februar
2004 mit Ergänzungen aus Dezember 2004. Genauere Informationen über SCORM
und Download-Möglichkeiten der einzelnen Definitionen finden Sie unter [ADL04].
1.3 Verschiedene OpenSource-Lösungen
Im Bereich der OpenSource-Software (OSS) gibt es verschiedene Produkte, die als
LÜS oder LMS konzipiert wurden. Eine kleine Auswahl davon wollen wir hier betrachten. Mit einem Teil der vorgestellten LMS hat der Autor bereits Erfahrungen sammeln
können und kennt sie von Seiten der Nutzer her. Die restlichen LMS finden wir über
Suchmaschinen für OSS und in Sammlungen von OpenSource-Projekten.
Stud.IP
Das Studentische Informationsportal ist aus einem Projekt der Universität Göttingen
hervorgegangen. Es dient laut Aussage der Webseite ([GMB05]) in erster Linie der
12
Koordination und Begleitung von Veranstaltungen an Hochschulen bzw. Kursen
im außeruniversitären (Weiter-)Bildungsbereich. Die Dozenten können für ihre
Veranstaltungen aus verschiedenen Modulen wählen, die dann den Lernenden zur
Verfügung stehen. Zu den wichtigsten zählen hier die Diskussionsforen, der virtuelle
Dateiordner, Teilnehmer- und Literaturlisten, ein Wiki sowie News und Chaträume für
die jeweilige Veranstaltung. Somit bietet Stud.IP für jede Veranstaltung die wichtigsten
Kommunikationsmittel an, ohne das die selbe Ressource (beispielsweise 4 Chaträume)
von allen Veranstaltungen geteilt werden muss.
Für die Lernenden bietet Stud.IP einen Terminkalender, der mit Organizern und anderer Kalendersoftware synchronisiert werden kann, einen individuellen Stundenplan
und Zugriff auf Materialien aller jemals besuchten Veranstaltungen.
Neben den Modulen, die für den direkten Vorlesungsbetrieb wichtig sind, bietet
Stud.IP aber auch die Möglichkeit einer Literaturverwaltung und eine Raum- und
Ressourcenverwaltung mit zentraler Raumvergabe und -planung. Auch vorhandene
Webseiten von Abteilungen können an Stud.IP angebunden werden. Die Daten der
Veranstaltungs-, Personal- und Abteilungsverzeichnisse können auch als Druckversion
exportiert werden.
Um die Installation zu erleichtern und den Aufwand deutlich zu reduzieren, können
die Anmeldemechanismen von Stud.IP so eingestellt werden, dass sie die bereits
vorhandene Infrastruktur nutzen und so ein zusätzliches Nutzerverzeichnis überflüssig
machen.
Verwendung findet Stud.IP hauptsächlich im deutschsprachigen Raum, auch wenn
Übersetzungen in mehrere Sprachen zur Verfügung stehen. Dies mag daran liegen,
dass Stud.IP ein noch recht junges aber dennoch leistungs- und konkurrenzfähiges
System ist.
Hauptsächlich als Unterstützung für die Präsenzlehre gedacht, bietet Stud.IP auch
eine Anbindung an ILIAS zur Erstellung von Online-Lerneinheiten. Somit kann auch
Stud.IP als vollwertiges LMS betrachte t werden.
Ein Nachteil von OSS ist sicherlich der häufig fehlende Support durch den Vertreiber.
Bei Stud.IP bietet die Firma data-quest in Göttingen Service und Support, Schulungen,
kundenspezifische Anpassungen und Weiterentwicklungen sowie die laufende Pflege
der Software an.
ILIAS
Wir möchten ILIAS hier nur sehr kurz betrachten, da es zumindest in den Versionen
vor 3.0 eine sehr gewöhnungsbedürftige Benutzerführung hatte. In wie weit sich diese
geändert hat, läßt sich ohne aktuelle Erfahrungswerte nur schwer sagen. ILIAS ist ein
vollwertiges LMS, das in der aktuellsten Version den SCORM-Standard 1.2 unterstützt.
Laut der Webseite [Köl05] ist ILIAS das erste LMS aus dem Bereich OpenSource, das
diesen Standard unterstützt und ein entsprechendes Zertifikat vorweisen kann. Inzwischen nutzen über 140 Universitäten ILIAS als zentrales System zur Unterstützung
der Präsenzlehre, darunter die Bundeswehr-Universität Hamburg und die Hochschule Bremen. Auch im Ausland hat ILIAS Nutzer gefunden, u.a. die Iran University of
Science and Technology in Teheran, Education Nationale, L’Académedie de Bordeaux
in Frankreich, Circolo Didattico di Randazzo in Italien sowie Universitäten und Schulen aller Art in etlichen weiteren Ländern.
1.3. VERSCHIEDENE OPENSOURCE-LÖSUNGEN
13
Support und Schulungen werden durch die Qualitus GmbH, einem Partner von ILIAS,
angeboten, während die Databay AG in Aachen ILIAS-Installationen hostet. Dieses
Angebot können Interessierte nutzen, die eine Pilotanwendung ohne großen Aufwand
einsetzen möchten.
Moodle
Moodle ([Org05]) ist ein LMS, das in 53 verschiedene Sprachen übersetzt wurde und
somit nahezu auf der ganzen Welt Anwender finden kann. Die Entwickler bezeichnen es als den größten Vorteil von Moodle, das es sich sehr stark auf die sozialkonstruktionistische Pädagogik stützt. Nach den Erläuterungen auf der Webseite bedeutet dies, das die Lernenden gemeinsam, durch Chats und anderen Arten der Kommunikation, neues Wissen für die Gruppe aufbauen.
Die Bedienung von Moodle selber ist sehr intuitiv gehalten, so dass sowohl Lernende
als auch Lehrende sehr gut mit dem System klar kommen dürften. Neue Lerneinheiten
und Kurse lassen sich sowohl über das Moodle-eigene System als auch über SCORM
einbinden, allerdings ist das SCORM-Modul noch in der Entwicklung. Hier kann es
also zu verschiedenen Fehlern kommen.
Moodle versteht sich als Produkt der OpenSource-Community; daher verwundert es
nicht, dass wir auf der Webseite keine Hinweise auf Firmen mit Support- oder ServiceAngeboten gefunden haben. Allerdings erfreut sich Moodle einer sehr großen Beliebtheit, und die Betreiber der einzelnen Installationen helfen sich bei Problemen gegenseitig. Die Liste der Installationen, die auf der Webseite geführt wird, ist mit fast 2.500
Einträgen aus über 100 Ländern sehr umfangreich.
Claroline
Ursprünglich von der Universität in Louvain, Belgien, entwickelt, wächst Claroline
durch eine Gemeinschaft von Programmierern, die am 15.12.2004 die Version 1.6 Beta veröffentlicht haben. Mit 28 Sprachen bietet auch Claroline eine gute Verbreitungsmöglichkeit, hat allerdings bei über 10.000 Downloads sehr wenige Installationen, die
auf der Webseite ([oL]) genannt werden. Dies mag zum Teil an den fehlerhaften Übersetzungen liegen, die auf weitere Fehler im eigentlichen Programm schließen lassen.
Auch bei Claroline liegt eine recht geradlinige Bedienung vor, die sich bis zu einem
gewissen Grad intuitiv erschließt; die restlichen Dinge kann man sowohl als Dozent
wie auch als Lerner durch Try & Error herausfinden. Neue Lernmodule können direkt
erstellt oder in Form von SCORM 1.2-Modulen hochgeladen werden. Eine ExportFunktion für SCORM-Module existiert noch nicht; an dieser Stelle ist die OpenSourceCommunity gefordert.
Wie auch bei Moodle gibt es keine Firmen, die irgendwelche Support-Dienste anbieten, die Nutzer sind hier auf die gut funktionierenden Foren innerhalb der ClarolineWebseite angewiesen.
14
Manhattan Virtual Classroom
Manhattan Virtual Classroom ist ein Produkt des Western New England College, USA.
Wie auch die anderen vorgestellten Systeme bietet es Diskussionsforen, Chat, Download von Lernmaterialien, Verwaltung von Aufgaben oder Projekten, ein Notenbuch,
Umfragen und ein internes Email-System. Leider steht auf der Homepage ([Nar]) keine Demo-Version zur Verfügung, so dass wir uns keinen genaueren Überblick über die
Bedienbarkeit verschaffen können. Lediglich die verfügbaren Übersetzungen werden
genannt: Neben Englisch und Deutsch sind noch fünf weitere vorhanden.
1.4 Server auf OpenSource-Basis
Nachdem wir uns nun einen Überblick über mehrere OpenSource-basierte LMS verschafft haben, wollen wir auch die Systeme im Hintergrund betrachten. Ein großer
Vorteil von OSS ist die freie Verwendbarkeit: Bei jeder der im folgenden vorgestellten
Distributionen genügt es, einmal eine Kopie zu erwerben (Kauf oder Download spielt
hier keine Rolle) – die Anzahl PCs, auf denen anschließend das Betriebssystem installiert wird, ist unbegrenzt. Je nach Anbieter sind die Distributionen mehr oder weniger
umfangreich. Sie enthalten jedoch alle als Minimum verschiedene grafische Oberflächen zur Auswahl, ein oder mehrere Office-Pakete, die auch mit Dateien von Microsoft
Office umzugehen wissen, sowie verschiedene Server für Webseiten, Email, Chat und
Instant Messaging und die dafür benötigten Clients.
Betriebssystem
Das bekannteste Betriebssystem ist mit Sicherheit Microsoft Windows, was allerdings
etliche Nachteile mit sich bringt. Es fällt in den Bereich der Closed Software, die
Nutzung muss bezahlt werden und Sicherheitslücken werden zum Teil nur sehr langsam geschlossen. Außerdem muss für jeden Computer, auf dem MS Windows installiert werden soll, eine Lizenz erworben werden. Hier benötigen wir also Alternativen.
Aus dem Bereich OpenSource bieten sich die beiden Unix-Derivaten Linux und BSD
(Berkeley Software Distribution) an. Linux ist das bekanntere Betriebssystem der beiden und laut der Studie ”The Linux Marketplace”[stu] von IDC inzwischen auch ein
”Mainstream”-Produkt. Es ist in verschiedenen Distributionen erhältlich, die zum Teil
unterschiedliche Zwecke verfolgen und je nach Vertreiber, mitgelieferter Dokumentation und Installations-Support zwischen lediglich den Downloadkosten bis hin zu
einigen hundert Euro kosten. Ein weiterer Vorteil von freien Betriebssystemen ist auch
die Struktur des Supports: der Großteil wird über Mailinglisten und Foren abgewickelt,
an denen sich die Entwickler der Programme, um die es geht, zum Teil sehr rege beteiligen. Durch diesen sehr direkten Kontakt zu den Entwicklern lässt sich ein Großteil
der Probleme leichter lösen als bei Produkten, für die speziell geschulte Problemlöser in einem Callcenter sitzen und nur wenig Verständnis für die Funktionsweisen der
einzelnen Programme haben.
SuSE Linux, die in Deutschland am stärksten vertretene Distribution, richtet sich in der
1.4. SERVER AUF OPENSOURCE-BASIS
15
Version für Privatanwender an Desktop-Benutzer, die viel vom Windows-Charm behalten möchten, ohne auf die Sicherheit von Linux zu verzichten. Die Einrichtung und
Wartung wird durch ein von SuSE entwickeltes Programm, vergleichbar mit der Systemsteuerung von Windows, erledigt. Dadurch ist SuSE hervorragend für den LinuxEinsteiger geeignet. Um den Anwender bei der Installation und dem anschließenden
Betrieb des PCs zu unterstützen, liefert ihm SuSE gedruckte Handbücher mit mehreren
100 Seiten sowie 90 Tage kostenlosen Installations-Support mit, wenn er SuSE Linux
für ca. 80 Euro kauft. Nimmt er lieber die kostenlose Version zur Installation aus dem
Internet, fallen sowohl die Handbücher als auch der Installations-Support weg. Zusätzlich zur Desktop-Version sind drei Versionen für Unternehmen erhältich, zwei davon
für den Einsatz im Serverbereich und eines als Desktop-Version für die tägliche Arbeit
der Mitarbeiter. Da wir auf die Unternehmensversionen keinen Zugriff haben, können
wir hier keine Aussagen über die Leistungsfähigkeit und die Sicherheit treffen. Service
und Support laufen bei SuSE Linux zum einen über diverse Mailinglisten, zum anderen aber auch über Support-Hotlines, an denen nach Erfahrung des Autors sehr fähige
Berater sitzen, die wissen, wovon sie reden und nicht nur irgendwelche Schemata zur
Kundenberatung abarbeiten. Die Support-Hotlines werden von SuSE unter anderem
angeboten, weil es sich trotz des OpenSource-Gedanken immer noch um ein kommerzielles Produkt handelt und die zahlende Kundschaft solche Leistungen anscheinend
erwartet.
Debian Linux ist eine Distribution der Open Source Community, deren Hauptaugenmerk auf dem Einsatz von freier Software in stabilen und sicheren Versionen liegt. Installation und Administration von Debian erfordern größere Kenntnisse von Linux und
den verwendeten Programmen, da zwar ein hervorrragendes Installationsprogramm
vorhanden ist, es aber so gut wie keine Einstellungen der einzelnen Programme vornimmt. Erhältlich ist Debian im Normalfall als Download-Version, allerdings bieten
einige Händler auch fertig gebrannte CDs mit den benötigten Installationsdateien an.
Aktuell gibt es drei Versionen von Debian: die als stabil bezeichnete Version, die auch
gleichzeitig die offizielle Veröffentlichung darstellt, eine Version mit dem Status ”Testing”, in der die verschiedene Updates der einzelnen Programme ausgiebig geprüft
werden und die Version ”Unstable”. In dieser findet die Entwicklungsarbeit statt und es
stehen die neuesten, noch nicht oder zumindest nicht umfangreich gestesteten Versionen der einzelnen Programme bereit. Service und Support werden von der Community
übernommen, die sich über Foren, Mailinglisten und Newsgroups austauscht. Die Teilnehmer dort sind im allgemeinen sehr hilfsbereit, auch wenn die eine oder andere in
ihren Augen recht unnötige Frage mit der Antwort ”Lies die Anleitung” quittiert wird.
Gentoo Linux ist ebenfalls eine Distribution der Open Source Community. Sie zeichnet sich durch eine sehr große Flexibilität aus und kann für jeden Einsatzbereich verwendet werden. Da die Programme für den jeweils benutzten Rechner optimiert werden, erreicht Gentoo eine sehr hohe Performanz. Durch seine großen Auswahlmöglichkeiten und die teilweise schwierige Installation ist Gentoo sicherlich nicht dafür
geeignet, Linux einfach mal zu testen - vor allem, da die Installation aufgrund der
vielen Optimierungen langwierig ist und je nach gewünschter Software mehrere Tage
dauern kann. Service und Support werden wie auch bei Debian von der Community
übernommen, so dass kleinere Probleme in der Regel innerhalb kürzester Zeit gelöst
werden – größere werden von mehreren Personen diskutiert, so dass am Ende eine
funktionsfähige und sichere Lösung steht.
16
Free BSD ist eine Weiterentwicklung der Berkeley Software Distribution, dem Unix
der University of California, Berkeley. Es zählt zu den leistungsstärksten und sichersten Betriebssystemen, die momentan verfügbar sind. Installation und Updates sind sehr
einfach durchzuführen und bereiten genau wie der Betrieb sehr wenig Probleme. Wie
bei den Linuxen, die von der jeweiligen Community betreut und weiterentwickelt werden, findet auch bei FreeBSD der Support in Mailinglisten und Foren durch andere
FreeBSD-Nutzer und die Entwickler statt.
Open BSD existiert seit etwa zehn Jahren und wird ausschließlich von Freiwilligen
weiterentwickelt. Auch hier wird Sicherheit sehr groß geschrieben; die Basisinstallation hat in acht Jahren lediglich eine Sicherheitslücke gehabt, die über die Netzwerkanbindung ausgebeutet werden konnte. Die meisten Programme, die unter Linux,
FreeBSD oder anderen Unix- Derivaten laufen, können auch unter OpenBSD gestartet
werden.
Webserver
Der bekannteste Webserver aus dem OpenSource-Bereich ist Apache HTTPD; er bietet neben statischen Webseiten, die lediglich Informationen aus fest vorgegebenen Seiten enthalten, auch Unterstützung für dynamische Seiten, deren Inhalt anhand von Datenbanken und Benutzereingaben erstellt wird. Dabei können die dynamischen Webseiten in verschiedenen Sprachen geschrieben werden; diese werden über Module in
den Apache eingebunden. Die bekanntesten dieser Sprachen sind Perl und PHP, die
ebenfalls Open Source Software sind. Sollen die Webanwendungen in Java geschrieben werden, bietet sich Tomcat an, ein Webserver auf Basis von Java. Er wird ebenfalls
von der Apache Foundation entwickelt. Nähere Informationen zu beiden Servern finden wir unter anderem im folgenden Artikel von Marco Lübke.
Mailserver
Von Mailservern bekommen wir als Nutzer des Internet ähnlich viel mit wie von
Webservern: im Idealfall gar nichts, weil alles problemlos läuft. Wenn wir aber selber Server aufsetzen wollen, müssen wir uns ein wenig mit ihnen auseinander setzen.
Mailserver bestehen aus zwei Teilen: einem Server, der sich um den Versand kümmert
(SMTP-Server) und einen, der uns Empfangsmöglichkeiten bietet (POP3 bzw. IMAP).
Versand: Der älteste Mailserver für den Versand ist vermutlich Sendmail. Er glänzt
mit einer cryptisch anmutenden Konfiguration und ist recht empfindlich, was fehlerhafte Einstellungen angeht. Deutlich leichter zu administrieren und effizienter in der
Verarbeitung von Mails sind dagegen die heute gängigen Server Postfix, Exim und
Qmail. Alle vier sind in der Lage, neben dem reinen Versand von Mails diese auf Spam
und Virenbefall zu überprüfen und entsprechend zu kennzeichnen oder abzuweisen.
Empfang: Auch hier bietet OpenSourceSoftware zwei bekannte Alternativen an: Courier und Cyrus; beide ”sprechen” sowohl POP3 als auch IMAP. Damit überlassen sie
dem Nutzer die Entscheidung, ob er seine Mails lieber auf seinen Arbeitsplatzrechner
laden möchte oder ob er sie vollständig auf dem Server verwalten möchte. Der Autor
1.5. OPENSOURCE FRAMEWORK
17
hat sich, da er zwischen verschiedenen Betriebssystemen und Mailprogrammen wechselt, für letzteres entschieden.
Webmailer: Bekannte Webmail-Dienste sind unter anderem GMX, Gmail und Hotmail. Sie alle bieten eine Schnittstelle zwischen Email und WWW an. Im Bereich
der OpenSource-Software ist Squirrelmail eine sehr bekannte Webapplikation, die diese Schnittstelle ebenfalls bereitstellt. Dazu ist als Minimum auf der Serverseite ein
Webserver, ein IMAP-Server zum Lesen der eingegangen Mails und ein SMTP-Server
zum Versand von Emails notwendig. Die Nutzer benötigen nichts weiter als ihren Lieblingsbrowser.
Datenbank
Irgendwo müssen unsere LMS und sonstigen Applikationen, die dynamische Webseiten generieren, ihre Daten ablegen und vor allen Dingen auch effizient abrufen können.
Dazu nutzen sie Datenbanken; im OpenSource-Bereich sind das vor allem MySQL und
PostgreSQL. Jede hat ihre besonderen Vor- und Nachteile; die genauen Eigenschaften
werden auf den jeweiligen Webseiten beschrieben.
Weitere Anwendungen
Im Bereich der OSS gibt es noch sehr viele Server und Webapplikationen, die für
Bildungseinrichtungen interessante Dienste ermöglichen. Dazu gehören bespielsweise Chats, Instant Messaging, Foren und Wikis. Diese können als eigenständige Applikationen realisiert werden oder sind, je nach Umfang des LMS, bereits in dieses
integriert.
1.5 OpenSource Framework
Wir wissen jetzt, welche Betriebssysteme und welche Server wir aus dem Bereich der
OSS nutzen können und welche LMS es bereits vorgefertigt gibt. Nun wollen wir überlegen, wie man aus diesen Grundkomponenten einen Rahmen aufbauen kann, aus dem
wir durch weitere Verfeinerungen die nötige Infrastruktur einer Bildungseinrichtung
aufbauen können.
Als Grundstein für dieses Framework legen wir einen Nutzer fest. Er greift mittels
eines Browsers auf den Webserver der Bildungseinrichtung zu und kann über einen
Mailclient Emails an die Einrichtung verschicken. Der Webserver zeigt dem Nutzer, da
dieser sich noch nicht als Mitarbeiter oder Lerner der Einrichtung ausgewiesen hat, nur
die Webseite der Einrichtung an.
18
Abbildung 1.1: Grundstein des Framework
Der Nutzer hat nun alle Informationen erhalten, die er braucht, und sich bei der Bildungseinrichtung als Lerner angemeldet. Nachdem er sich auch beim Webserver angemeldet hat, zeigt dieser ihm das LMS an. Die Daten liegen in einer Datenbank, auf die
das LMS zugreift. Außerdem verfügt es über ein Webinterface zum Mailserver. Damit
ist der Nutzer in der Lage, Mails mit seiner Adresse [email protected]
zu empfangen und zu versenden.
Abbildung 1.2: Angemeldeter Nutzer
Da die Bildungseinrichtung die Kommunikation aber über mehrere Kanäle ermöglichen will, installiert sie auch einen Chatserver, in diesem Fall einen IRC-Server. Das
LMS erhält ein Webinterface zum IRC-Server, so dass die Lerner aus dem LMS heraus an den unterschiedlichen Chats teilnehmen können. Die Verantwortlichen in der
Bildungseinrichtung wissen auch, dass es für IRC weitere Clients gibt, die mit diesem
Protokoll besser umgehen können als ihr Webinterface – und dabei noch deutlich weniger Last bei der Internetanbindung produzieren. Daher geben sie auch diesen Zugang
frei, und der Nutzer kann z.B. mit dem bekannten Windows-Programm mIRC an den
Chats seiner Veranstaltungen teilnehmen. In den Chats sollen auch Projekte geplant
werden, Aufgaben und Abgabetermine festgelegt werden und einige andere Dinge, die
es sinnvoll erscheinen lassen, die einzelnen Kanäle, zumindest bei Bedarf oder auf
Wunsch der Teilnehmer, zu protokollieren. Die Protokolle werden in die Datenbank
geschrieben und über das LMS zugänglich gemacht.
1.5. OPENSOURCE FRAMEWORK
19
Abbildung 1.3: Vollständiges Framework
Damit ist es uns nun möglich, anhand der weiteren Anforderungen wie der erwarteten
Nutzerzahl, des geschätzten Datenvolumens und der Verfügbarkeit des Systems die jeweils benötigte Hard- und Software zu ermitteln. Da zumindest für die Software keine
(oder nur äußerst geringe) Kosten fällig werden, können wir zum einen in leistungsstärkere Hardware und bessere Ausfallsicherheit investieren und zum anderen immer
noch Geld sparen gegenüber einer Installation mit ClosedSource Software.
Nützliche Links
Wir haben vorhin verschiedene Programme eines Server-Systems auf Basis von OpenSourceSoftware genannt; jetzt möchten wir noch eine Übersicht über die verschiedenen
Bezugsmöglichkeiten und Informationsquellen geben. Diese Liste ist bei weitem nicht
vollständig, für eine größere Auswahl empfehlen wir
http://www.freshmeat.net und http://www.sourceforge.net als
Ausgangspunkte.
Browser, Mailclient, IRC-Client Mozilla Foundation (Mozilla Suite für alle drei
Komponenten unter einer Oberfläche, Firefox als Browser, Thunderbird als
Mailclient) http://www.mozilla.org
IRC-Client Advanced IRC Client http://airc.sourceforge.net
Betriebssysteme verschiedene Linux-Distributionen http://www.suse.de,
http://www.debian.org, http://www.gentoo.org
und BSD http://www.freebsd.org, http://www.openbsd.org
Webserver Apache http://httpd.apache.org und
Tomcat http://tomcat.apache.org
Mailserver Postfix www.postfix.org
zusammen mit Courier http://www.courier-mta.org
Datenbanken MySQL http://www.mysql.com und
PostgreSQL http://www.postgresql.org
20
Chat-Server IRC http://www.irc.org
Foren phpBB http://www.phpbb.com
Wiki Mediawiki, das System hinter Wikipedia
http://mediawiki.sourceforge.net
1.6 Ausblick: Kommerzielle Systeme
Nachdem wir uns nun über verschiedene Möglichkeiten aus dem Bereich OpenSource
informiert haben, betrachten wir als Gegenpol zwei kommerzielle LMS, die weltweite
Verbreitung gefunden haben: WebCT und Blackboard.
WebCT
WebCT ist ein vermutlich recht kostenintensives LMS, da es den Betrieb einer OracleDatenbank erfordert. Hier müssen also für ein System zwei Lizenzen eingekauft werden. Außerdem ist WebCT sehr wählerisch, was die verwendeten Browser angeht.
Nur wenige Browser stuft der Hersteller als ”vollständig unterstützt” ein. Bei anderen Browsern funktionieren einige Teile von WebCT nicht; so zeigt Konqueror (ein
OpenSource-Browser, Bestandteil des K Desktop Environment) beispielsweise die
zwingend erforderliche Navigationsleiste am linken Rand der Seite nicht an. Mit dem
aktuellen Firefox sind uns allerdings keine Einschränkungen aufgefallen; er wird von
WebCT trotzdem als ”nicht unterstützt” eingestuft. Über die Qualität des Systems
möchten wir an dieser Stelle keine genauen Aussagen treffen, da für Anfang bis Mitte
nächsten Jahres eine neue Version angekündigt wurde. Eine Untersuchung zur Nutzbarkeit der aktuellen Version (Stand: Sommersemester 2004) im Vergleich mit ILIAS
2.x verschickt der Autor gerne per Email.
Blackboard
Blackboard ist zunächst als OpenSource entwickelt worden, wurde aber nach einiger
Zeit des Wachstums in ein ClosedSource-Produkt umgewandelt und hat so einige Nutzer verloren. Auch hier sind die Lizenzen wieder kostenintensiv; aus der Webseite geht
leider nicht hervor, ob zusätzlich eine Datenbanklizenz erworben werden muss oder ob
hier eine OpenSource-Datenbank genutzt werden kann. Im Gegensatz zu WebCT unterstützt Blackboard auch SCORM, benötigt allerdings sehr viel Rechenleistung und
Arbeitsspeicher. Dementsprechend schleppend ist auch der Seitenaufbau. Frühere Versionen hatten bei Downloads erhebliche Probleme, den richtigen Dateinamen an den
Browser zu übermitteln. So hieß eine Datei ”grundlagen_webtechnologien.pdf” plötzlich ”e74842939b659b4535848ec1b729dc2d.pdf”, um ein Beispiel zu nennen. Dies
hat bei den Nutzern verständlicherweise für Frust gesorgt, vor allem wenn mehrere
Dateien heruntergeladen werden mussten und/oder die exakte Namensgebung wichtig
war.
1.7. FAZIT
21
1.7 Fazit
Wie wir gesehen haben, gibt es verschiedene Wege für eine Bildungseinrichtung, sich
im Internet zu präsentieren und den Lernenden Hilfsmittel zur Verfügung zu stellen.
Um einen sinnvollen, ausreichend gegen Angriffe abgesicherten und dabei noch kostengünstigen Weg zu wählen, sollten Produkte aus dem Bereich OpenSourceSoftware
in jedem Fall mit in die Planung einbezogen werden. Die wichtigsten Gründe dafür
sind sowohl die im Vergleich zu kommerziell vertriebener Software die geringen Kosten sowohl für die Anschaffung als auch für Updates sowie deutlich schnellere Reaktionszeiten bei neu bekannt gewordenen Sicherheitslücken. Weitere Punkte sind die
Funktionen, die die jeweiligen Lösungen zur Verfügung stellen sowie die Bedienbarkeit; hier konnten uns die OpenSource-Lösungen jeweils von sich überzeugen.
Somit empfehlen wir allen Interessierten, zunächst einmal die Anforderungen an die
jeweiligen Systeme zu formulieren: welche Funktionen müssen erfüllt werden und wie
intuitiv muss die Bedienung sein, wie viele Nutzer werden voraussichtlich gleichzeitig
aus das System zugreifen, welches Datenvolumen (Lernmaterialien, Skripte, ...) muss
verwaltet werden und welche Systeme oder Teilkomponenten davon werden von den
Mitarbeitern bereits betreut. Ebenfalls wichtige Punkte sind Integrationsmöglichkeiten
in die bereits vorhandene Infrastruktur sowie einfache Erweiterbarkeit vor allem des
LMS; gerade hier punktet vor allem Stud.IP.
Anschließend sollten sowohl die hier vorgestellten Systeme als auch weitere LMS, die
wir hier nicht erw??hnt haben, nach einem individuell erstellten Punkteraster bewertet
werden. Dieses Vorgehen sichert eine objektivere und sp??ter nachvollziebare Beurteilung, die nicht nur von mehr oder weniger aufw??ndigen Werbeseiten im Internet, auf
Fachmessen oder in Zeitschriften geleitet wurde. Im Idealfall wird auch die Zielgruppe
der Bildungseinrichtung mit in die Analyse einbezogen, um das für alle Seiten beste
System zu ermitteln.
22
Kapitel 2
Implementation von
Webservern und Webservices
für Lehr- und Lernsystemen
Marco Lübcke
Inhalt
2.1
2.2
2.3
2.4
2.5
Einleitung . . . . . . . . . . . . . . . . . . . .
Vorgehensweise . . . . . . . . . . . . . . . . .
Ausgangsbeispiele . . . . . . . . . . . . . . . .
Konsequenzen für die Bewertung der Webserver
Implementationen von Webservern . . . . . .
W3C – Jigsaw . . . . . . . . . . . . . . . . . .
Apache – HTTP-Server . . . . . . . . . . . . .
Jakarta – Tomcat . . . . . . . . . . . . . . . . .
Webservices . . . . . . . . . . . . . . . . . . .
Technik . . . . . . . . . . . . . . . . . . . . .
Spracheneinbettung . . . . . . . . . . . . . . .
Frameworks . . . . . . . . . . . . . . . . . . .
Fazit . . . . . . . . . . . . . . . . . . . . . . .
Zusammenfassung . . . . . . . . . . . . . . . .
Handlungsempfehlungen . . . . . . . . . . . .
verwendete Abkürzungen . . . . . . . . . . .
23
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
24
24
24
26
26
27
28
30
31
31
34
34
39
39
40
41
24
KAPITEL 2. WEBSERVER UND WEBSERVICES FÜR LERNSYSTEME
2.1 Einleitung
Vorgehensweise
In dieser Arbeit werden im nächsten Abschnitt zwei Ausgangsbeispiele eingeführt,
welche es erlauben, einen praxisnahen Bezug der im Folgenden vorgestellten Techniken herzustellen. Somit ist es möglich, die Anwendungen der Techniken direkt an
Hand spezieller Beispiele zu vergleichen.
Nach den Ausgangsbeispielen soll auf eine Auswahl verschiedener Webserver eingegangen werden. Bei der Auswahl wurden bereits die Kriterien der Ausgangsbeispiele
berücksichtigt. Zu jedem Webserver wird auf die dahinterstehende Organisation sowie
auf die Entwicklung und die Möglichkeiten der einzelnen Server eingegangen. Abschließen wird jeder Unterabschnitt mit einer Bewertung für die Anwendbarkeit auf
die Ausgangsbeispiele.
Im darauf folgenden Abschnitt soll die Technik von Webservices und deren Möglichkeiten diskutiert werde. Dazu werden zunächst grundlegende Aspekte der verwendeten Techniken von Webservices vorgestellt. Anschliessen folgt ein kurzer Überblick
und eine Bewertung von Frameworks, die bereits im Bereich des E-Learnings definiert
wurden. Diese erlauben es Webservices zu implementieren und E-Learning-Systeme
aufzubauen.
Abschließen wird diese Arbeit mit einem Fazit, welches u.a. eine Handlungsempfehlung für die vorgestellten Beispiele beinhaltet.
Abkürzungen sowie Literaturhinweise, die in dieser Arbeit verwendet werden, befinden sich am Ende dieser Arbeit in Form von Verzeichnissen.
Ausgangsbeispiele
Es sollen zwei Ausgangsbeispiele folgen, die unterschliedliche Anforderungen besitzen und somit verschieden Überlegungen bezüglich einer Bewertung der vorgestellten
Techniken erfordern.
Hochschule
Das erste Beispiel ist im Bereich der Universitäten oder vergleichbaren Hochschulen
angesiedelt. Die Hochschule fordert ein System, welches es Dozenten erlaubt, Lehrinhalte in Form von Lehrabschnitten oder aber in aggregierter Form, in sog. Lehrpaketen, einzustellen. Studenten bzw. Agenten sollen sich diese schließlich präsentieren lassen und an Hand der Dokumente lernen. Für die Präsentation soll auf übliche
Webtechnologien zurückgegriffen werden, um eine Plattformunabhägigkeit und einen
bestmöglichen Zugang zu gewährleisten. Die Formate der Dateien sind dabei normale Dateiformate, wie etwa pdf, jpg, ps, etc., so dass der Agent wahlfreien Zugriff
auf die Lerninhalte innerhalb eines Lehrabschnitts/-pakets besitzt. Wünschenwert wäre ein späterer Ausbau, so dass der Dozent den Lehrpfad innerhalb eines Lerhpaketes
2.1. EINLEITUNG
25
Anfoderungstyp
Anforderung
Rollen
– Dozenten – erstellt Lehrabschnitte
– Studenten – konsumiert
Kosten
– möglichst kostengünstig, am Besten Open Source
Technologie
– webbasierte Technologien
– asynchrone Kommunikation
– systemübergreifender Austausch von Informationen
Sicherheit
– Authentifizierung für Studenten & Dozenten
– Verbindung über SSL
Submodule
– Newsbereich
– Downloadbereich für Lernressourcen
– Forensystem
– Bereich für Online-Präsentation
– Wiki - Aufbau Wissendatenbank
Optional
– sequenzielle Navigation
Tabelle 2.1: Anforderungen – Universität
vorgeben kann, um so bspw. Tests zu integrieren, die es erst nach erfolgreichem Bestehen erlauben, in einen nächsten Unterlehrabschnitt zu springen. Als Möglichkeiten
dazu bieten sich Standards wie etwa [IMS04c] und [IMS04b] an. Um eine effiziente
Nutzung der erzeugten Lehrpakete zu ermöglichen, ist eine Kooperation mit anderen
Universitäten geplant, so dass ein systemübergreifender Austausch der Lehrpakete und
anderer Informationen ermöglicht werden soll.
Das System soll weiterhin eine Kommunikation auf horizontaler Ebene erlauben, so
dass sich Studenten über das System asynchron austauschen können. Um Studenten
und Dozenten eindeutig zu identifizieren, ist eine Authentifizierung unumgänglich, so
dass das System weiterhin die Möglichkeit bieten muss, neben den Lehrinhalten auch
Benutzerinformationen zu speichern. Die Authentifizierung und die Kommunikation
soll gegebenenfalls per SSL abgesichert stattfinden. Ein genaues Anforderungsprofil
ist in Tabelle 2.1 dargestellt.
Allgemeinbildende Schulen
Im Bereich der Allgemein bildenden Schulen ist das zweite Beispiel angesiedelt. Dieses System erfordert, dass Lehrer Inhalte in ein System einstellen können, die den
Lernprozess der Schüler unterstützen. Dies können z.B. Links zu anderen Internetseiten oder weiterführende Dokumente zu einem bestimmten Thema sein. Eine direkte
Interaktion zwischen dem System und den Schülern ist nicht vorgesehen, so dass auf
eine Authetifizierung seitens der Schüler verzichtet werden kann. Weiterhin soll es
möglich sein eine Art schwarzes Brett zu führen, auf dem die Schüler die neusten Informationen ihrer Schule abrufen können. Optional ist eine Zusammenarbeit mehrerer
regionaler Schulen vorgesehen, so dass das System sich mit anderen Systemen austau-
26
Anfoderungstyp
Anforderung
Rollen
– Lehrer – erstellt unterstützende Informationen
– Schüler – sind anonym
Kosten
– möglichst kostengünstig, am Besten Open Source
Technologie
– webbasierte Technologien
Sicherheit
– Authentifizierung für Lehrer
Submodule
– Newsbereich
– Downloadbereich für Lernressourcen
– Linksammlung
Optional
– systemübergreifender Austausch von Informationen
Tabelle 2.2: Anforderungen – Schule
schen können soll. Ein genaueres Anforderungsprofil ist in Tabelle 2.2 dargestellt.
Konsequenzen für die Bewertung der Webserver
An Hand der Anforderungen der Hochschule wird davon augegangen, dass eine Realisierung durch Java Enterprise Technologien (kurz J2EE) stattfinden wird, um ein Projekt in dieser Grösse bestmöglich wartbar, erweiterbar und plattformunabhängig zu
machen. Somit ist zu prüfen, in wie weit die Webserver eine entsprechende Unterstützung für die Anbindung eines Applikationsservers und Techniken zur Darstellung von
dynamisch generierten Seiten durch Servlets oder Java Server Pages (kurz JSP) bereitstellt.
Für das Schulsystem ist davon auszugehen, dass ein gängiges Open-Source ContentManagement-System (kurz CMS) verwendet wird. Die Unterstützung einer Skriptsprache, wie das gängige PHP, für die dynamische Seitengenerierung ist somit besonders
für die Bewertung der Webserver ausschlaggebend.
2.2 Implementationen von Webservern
In diesem Abschnitt wird auf verschiedene Implementierungen von Webservern eingegangen. Webserver stellen dabei einen Dienst zur Verfügung, dem das HypertextTransfer-Protokoll (HTTP) zu Grunde liegt. Damit ist es Webservern möglich, Datenströme asynchron an Klienten auszuliefern, die diese mit Hilfe von geeigneten Programmen, im Allgemeinen sog. Browsern, anzeigen können. Nachfolgend werden die
drei in ihren Disziplinen wichtigsten Webserver vorgestellt.
2.2. IMPLEMENTATIONEN VON WEBSERVERN
27
W3C – Jigsaw
Nachfolgend wird auf die Standardimplementation des HTTP-Protokolls, den Jigsaw
Webserver [Tea04], eingegangen.
Hintergrund
Das Word Wide Web Consortium [W3C05] (kurz W3C) wurde im Oktober 1994
am Messachusetts Institute of Technology, Laboratory of Computer Sience, von Tim
Berners-Lee gegründet. Dabei arbeitete er mit dem CERN [CER04] zusammen und
wurde von der DARPA [DAR04] und der europäischen Kommission unterstützt. Das
W3C ist für die Festlegung von Standards neuer Technologien für das Web verantwortlich. Dabei regt das W3C weitesgehend zur öffentlichen Diskussion an. So sind
innerhalb von zehn Jahren über 80 technische Spezifikationen vom W3C erstellt worden. Unter ihnen befinden sich namenhafte Standards wie etwa XML, XSLT, HTML,
XHTML, SMIL und SOAP.
Der HTTP Standard ist von der W3C z.Zt. in der Version 1.1 festgelegt und im RFC
2616 [RF99] definiert. Die erste Version des HTTP (Version 0.9) existiert seit 1990
und erlaubt es, Rohdaten über das Internet auszutauschen. Mit der aktuellen Version 1.1, die seit 1999 existiert, können zusätzliche Metadaten wie etwa MIME-Typen
[NF96b, NF96a] zu den Rohdaten verschickt werden. Weiterhin werden eine zusätzliche Anzahl von Methoden definiert, die es Applikationen erlauben, das Protokoll flexibler zu nutzen.
Jigsaw ist die Referenzimplementierung des W3Cs für das HTTP und ist in der Programmiersprache Java realisiert, was es ermöglicht, Jigsaw auf jeder von Java unterstützten Plattform laufen zu lassen.
Eigenschaften
Jigsaw unterstützt HTTP in der Version 1.1, SSL, PICS, ICP, sowie WebDAV. Da es
sich um eine Referenzimplementierung handelt, ist Jigsaw als Open Source frei erhältlich.
Das Modell, welches Jigsaw zu Grunde liegt, besteht aus insgesamt drei Komponenten:
Resources, Frames und Filtern. Eine Resource kann jeder Ausgabestrom
sein, der den Webserver verlässt, wobei dieser statisch oder aber dynamisch generiert
sein kann. Jeder Resource muss ein sog. Frame zugeordnet sein, der zu dem Ausgabestrom zusätzliche Metainformationen, wie bspw. Informationen, die für HTTP wichtig sind, generiert. Für die Manipulation des Ausgabestroms bieten sich sog. Filter
an. Diese können als Eingabe- und als Ausgabefilter definiert werden. Beispiele wären
eine Authentifizierung als Eingabe- und ein Ersetzungsfilter als Ausgabefilter.
Um eine Skriptsprache einzubinden, lässt sich die CGI-Schnittstelle benutzen, die es
erlaubt, eine Anfrage zunächst durch einen externen Präprozessor zu interpretieren,
der dann die Antwort generiert. Durch diese Technik lassen sich u.a. problemlos PHP-,
28
C- und Perl-Skripte in die Internetpräsentation einbinden. Da Jigsaw Java als Laufzeitmgebung benutzt, bietet sich der Einsatz von Java Technologien an. So unterstützt
Jigsaw mit Hilfe eines sog. Servlet-Wrappers Servlets und JSPs. Für eine direkte Erweiterbarkeit der Funktionalität bietet sich die Implementierung neuer Resource- und
Filterklassen sowie eine Ändrung des Jigsaw Codes an.
Um eine einfache Administrierung zu gewährleisten, wird mit dem Jigsaw Server
auch eine Anwendung namens JigAdmin ausgeliefert. Diese erlaubt es, Resourcen,
Frames, Filter und andere Server-Eigenschaften wie Authetifizierungen GUIgestützt zu administrieren.
Anwendbarkeit
Jigsaw lässt sich für die Anforderungen des Schulsystems anwenden. So bietet er die
Integration von Skriptsprachen wie PHP über die CGI-Schnittstelle, so dass ein skriptbasiertes CMS lauffähig ist. Jedoch gilt die Verwendung der CGI-Schnittstelle als nicht
sehr sicher, da Prozesse ausserhalb des Webserverprozesses angestossen werden. Ausserdem ist die Art der Integration nicht trivial, so dass eine gewisse Einarbeitung nötig
ist.
Für das Beispiel der Hochschule ist dieser Server nur bedingt geeignet, da er zwar auf
Java basiert, aber eine Servletunterstützung nur über einen sog. Wrapper möglich ist.
Dies macht die Verarbeitung unnötig langsam. Eine Anbindung an einen Applikationsserver ist nicht ohne weiteres möglich und badarf einer Erweiterung durch Filter,
Resourcen oder ähnliches.
Apache – HTTP-Server
Der wohl bekannteste Vertreter der Webserver, der Apache HTTP-Server [Fou04a]
wird nachfolgend vorgestellt.
Hintergrund
Im Februar 1995 war der meist eingesetzte Webserver der HTTP daemon von Rob McCool, entwickelt am National Center for Supercomputing Applications, University of
Illinois. Die Entwicklung und der Support wurden jedoch Mitte 1994 eingestellt, so
dass viele Webadministratoren gezwungen waren, Fehler selbst zu entfernen und Erweiterungen in Eigenregie zu schreiben. Einige dieser Webadministratoren kontaktierten sich per eMail, um ihre Änderungen auszutauschen. Kurze Zeit später kamen eine
Mailingliste sowie ein authtentifizierter Bereich zum Austauschen von Dateien hinzu;
die erste Apache Group war gegründet. 1999 gründete dieses Team die Apache Software Foundation [Fou04b], um eine organisationelle, legale Basis für die Entwicklung
von Open-Source zu bieten.
In der Version 1.3 dieses Servers wurden alle bekannten Fehler entfernt, sowie Erweiterungen, die zu der Zeit existierten, eingepflegt. So entstand die erste Version des
2.2. IMPLEMENTATIONEN VON WEBSERVERN
29
Apache HTTP Servers in der Version 0.6.2 im April 1995. Nach mehreren Versionszyklen und einer großen Anzahl von Betatests wurde schließlich Anfang Dezember 1995
die Version 1.0 vorgestellt.
Zur Zeit liegt der Apache Server in zwei Versionen vor, zum Einen in der älteren Version 1.3, die auf Grund ihrer hohen Anzahl von Installationen immer noch anständig
gepflegt wird. Die neuste Version ist die 2.0, die eine Vielzahl von neuen Eigenschaften
mitbringt, die in der Version 1.3 nur durch die Einbindung neuer Module zu erreichen
sind.
Nach einer Studie von [Net04] benutzen in dem Zeitraum zwischen Oktober und November 2004 über 67 Prozent aller Webanbieter den Apache HTTP Server, was ihn zum
meist eingesetzten Webserver überhaupt macht. Diesen Status besitzt der Open-Source
Server bereits seit der Einführung der Version 1.0.
Möglichkeiten
Die hier vorgestellten Möglichkeiten beziehen sich auf die Version 2.0 des Webservers. Neben der Unterstützung von HTTP bietet der Apache Webserver u.a. SSL, WebDAV, Kompression, LDAP- und MD5-Authetifizierung, Server-Side-Includes, CGIund Proxy-Verfahren. Weiterhin kann der Webserver durch die Anbindung zusätzlicher Module flexibel erweitert werden. So ist es möglich, die Ausgabe in Logdateien
flexibel zu gestalten, Sktiptsprachen wie PHP einzubinden oder aber Weiterleitungen
zu anderen Servern zu ermöglichen. Als Beispiel dafür wäre das mod_jk-Modul zu
nennen, welches es erlaubt, einen Apache HTTP-Server mit einem Jakarta-Tomcat zu
’verbinden’.
Anwendbarkeit
Ein sehr grosser Vorteil ist die hohen Installationszahl, so dass der Apache-Server als
sehr ausgereift und stabil gelten darf.
Für das Schulsystem würde sich dieser Webserver als am geeignetsten herausstellen,
da das Einbinden des nötigen PHP-Moduls einfach von statten geht und es dazu eine
grosse Anzahl von Dokumentationen gibt. Somit kann auf die Verwendung der CGISchnittstelle verzichtet werden. Die so erzeugte Apache-PHP-Konfiguration lässt sich
heutzutage bei nahezu jedem Webhost-Anbieter finden, so dass diese als etabliert gelten darf.
Im Bezug auf das Hochulbeispiel ist dieser Server zwar auf Grund seiner Stabilität zu
empfehlen, jedoch ist die Verwendung des erwähnten mod_jk Moduls nötig, um JSPund Servletanfragen an einen entsprechenden Container weiterzuleiten. Dieses Verfahren ist bei der zu erwartenden Bearbeitung der Anfragen als ineffizient zu werten. Eine
Anbindung an einen Applikationsserver müsste vom verwendeten Servlet-Container
aus geschehen. Der nachfolgede Webserver ist daher für das Universitätsbeispiel eher
geeignet.
30
Jakarta – Tomcat
Die Open-Source Referenzimplementation des Sun Servlet- [DC03] und JSP-Standards [MR03], der Apache Jakarta-Tomcat, wird als letzter Webserver in dieser Arbeit
vorgestellt.
Hintergrund
Die erste Version von Tomcat wurde von James Duncan Davidson, der zu jener Zeit als
Software Entwickler bei Sun [Mic04] arbeitete, als Referenzimplementierung der ersten Servlet-Spezifikation entwickelt. Mit der Ernennung zu Open-Source wurde Tomcat Teil des Jakarta Projekts der Apache Software Foundation. Das Jakarta Committee
ist dabei für die Sammlung aller Apache Projekte zuständig, die als Programmiersprache Java verwenden.
Die erste offizielle Version des Tomcats ist 3.0, der die Servlet-2.2- und die JSP-1.1Spezifikationen implementiert. Die aktuellste Version ist 5.5.4, die neben vielen Verbesserungen, die die Performance betreffen, auch die neueste Servlet-2.4- und JSP-2.0Spezifikation implementiert.
Der Begriff Tomcat rührt im übrigen daher, dass Davidson sich von den Covern von
O’Reilly Bücher inspirieren lassen hat: der Verlag verwendet für Bücher von OpenSource-Projekten Tiere als Cover. So kam Davidson auf Tomcat, was soviel wie Kater
heisst.
Möglichkeiten
Tomcat wurde hauptsächlich dazu entwickelt, Servlet- und JSP-Seiten lauffähig zu machen und so dynamische Seiten zu erzeugen. Da er HTTP in der aktuellen Version verwendet, können neben den erwähnten Technologien auch gewöhnliche HTML-Seiten
ausgeliefert werden. Mechanismen wie Authentifizierung, SSL, CGI- und ProxyFunktionen sind durch entsprechende Servlets realisiert. Weiterhin sind einige spezielle
Java Enterprise Technologien wie etwa JNDI integriert.
Eine direkte Integration, also nicht über die CGI-Schnittstelle, von Skriptsprachen wie
etwa PHP ist abhängig von der Unterstützung der Community der Skriptspache. So
existiert eine Möglichkeit, PHP direkt für die Verwendung in einem Jakarta-Tomcat zu
kompilieren. Die Installation des fertigen jar-Archivs besteht dann darin, dieses in
den Classpath des Servers aufzunehmen.
Anwendbarkeit
Für das Beispiel der Schule ist der Jakarta-Tomcat weniger geeignet, da er nur über
Umwege eine Unterstützung für PHP bietet. Daher ist eher der Einsatz des Apache zu
empfehlen, da die Verwendung von PHP mit diesem Server Standard ist.
2.3. WEBSERVICES
31
Das System der Hochschule würde direkt von der Referenzimplementierung profitieren, da zum Einen eine explizite Unterstützung der Servlet- und JSP-Standards in der
jeweils aktuellsten Version existiert und zum Anderen einige der J2EE Technologien
wie JNDI unterstützt werden. Eine Anbindung an einen Applikationsserver stellt somit
kein Problem dar. Ein weiterer Pluspunkt in diesem Zusammenhang ist die einfache
Installation von weiteren APIs und Frameworks, die lediglich als jar-Archive in den
Classpath des Servers gestellt werden müssen. So lassen sich leicht zusätzliche
Projekte wie Jakarta-Struts oder Apache-Axis (siehe Abschnitt 2.3) nutzen.
Speziell sei an dieser Stelle auf den Applikationsserver JBoss [JBo04] hingewiesen, der
das aktuelle J2EE 1.4 implementiert und als Servlet-/JSP-Web-Container den JakartaTomcat verwendet.
2.3 Webservices
Dieser Abschnitt wird zunächst auf die Techniken eingehen, die hinter dem Begriff
der Webservices stehen. Anschliessend wird kurz auf zwei APIs eingegangen, die die
Einbettung von Webservices in den Sprachen Java und PHP erlauben. Abschliessend
werden Frameworks vorgestellt, die im Bereich des E-Learning entwickelt wurden und
sich u. a. die Webservices-Technik zu Nutzen machen.
Technik
Einfach zusammengefasst kann man Webservices als Schnittstellen definieren, die es
erlauben, Methoden auf einen anderen System aufzurufen, die dann einen Rückgabewert liefern können. Somit sind Webservices vergleichbar mit Techniken wie CORBA
oder Java RMI, die es auch erlauben sog. Remote Procedure Calls (kurz RPC) auf
entfernten Systemen zu tätigen. Ein wesentlicher Unterschied liegt jedoch darin, dass
Webservices auf HTTP basieren und somit plattform- und programmiersprachenunabhängig sind. Somit sind weniger Schwierigkeiten durch die Verwendung von sog.
Firewalls im Netzwerkverbund zu erwarten, da diese im Normalfall für den HTTP
Port (80) freigeschaltet sind. Dies kann jedoch auch als Nachteil ausgelegt werden,
da dieser Port ’missbraucht’ wird, also nicht seinem ursprünglichen Zweck dient. Die
Kommunikation findet dabei unter zur Hilfenahme des XML-Standards statt, um so
maschinenlesbare Informationen auzutauschen. Durch die Verwendung von XML ergibt sich jedoch ein Nachteil: das Verschicken von Objekten über eine Textdatei ist
wesentlich inperformanter als die Verwendung von vergleichbarer Techniken, wie die
oben angesprochenen CORBA- und RMI-Techniken, die statt ASCII-Dateien binäre
Objekte verschicken.
Für die Entwicklung und Standardisierung sind verschiedene Institutionen verantwortlich. Die wichtigsten sind die W3C Webservices Activity [Haa04], die OASIS-Open
[Ope04] sowie die Webservices Interoperability [WI04].
Im Bezug auf die einzelnen verwendeten Techniken wird häufig der Web Service Technology Stack genannt. Analog zum bekannten OSI-Referenz Modell für Netzwerke
32
können die Techniken der Webservices auch in Form eines Kellers angeordnet werden,
wobei jede höhere Technologie die vorherigen Technologien benötigt. Abbildung 2.1
veranschaulicht diesen Keller.
Abbildung 2.1: Webservices Technology Stack
Die Netzwerkschicht bildet die Netzwerkinfrastruktur, die Transportschicht das Protokoll mit dem die Nachrichten geschickt werden. Das Packaging beschreibt das Verpacken der Nachrichten in ein einheitliches Format, ein Besipiel dafür wäre SOAP
(s.u.). Die Descriptionschicht in Form der WSDL (s.u.) gewährleistet den Austausch
der Webservices und erlaubt es einen Klienten genaue Auskünfte darüber zu geben,
wie die Schnittstellen des Webservices sind. Die letzte Schicht bildet der Discorveryservice, der durch UDDI (s.u.) realisiert ist und es erlaubt, Webservices in sog. Repositories bekannt zu machen und so einen optimalen Austausch zu gewährleisten. Den
genauen Zusammenhang der Techniken veranschaulicht Abbildung 2.2.
Abbildung 2.2: Webservices Technology Stack
Nachfolgend soll kurz auf die wesentlichsten Techniken eingegangen werden.
2.3. WEBSERVICES
33
WSDL
Mit der Web Service Definition Language werden die Schnittstellen des Webservices
mit Hilfe von XML beschrieben. An Hand dieser Spezifikation eines Webservices ist
es möglich mit Interpretern entsprechende Implementierungen in einer Zielsprache zu
generieren. Somit können Fehler leicht vermieden werden und auch eine dynamische
Anbindung eines Webservices zur Laufzeit ist möglich. Weitere Informationen zum
Aktuellen WSDL 1.1 Standard sind unter [EC01] zu finden.
UDDI
Universal Description, Discorvery and Integration Systeme bieten eine Sammlung von
Webservices verschiedener Anbieter. Somit wird ein Verzeichnisdienst realisiert, der es
Nutzern erlaubt, nach bestimmten ihren Anforderungen gerecht werdende Webservices
zu suchen. Dazu gliedert sich UDDI in insgesamt drei Kategorien, sog. Pages:
• White Pages sind vergleichbar mit Telefonbucheinträgen, die die Anbieter von
Webservices nach Namen sortiert in einem Namensregister halten. Neben den
Detail- werden auch Kontaktinformationen der Anbieter gespeichert.
• Yellow Pages sind mit den Gelben Seiten vergleichbar und sortiert die Anbieter
nach taxonomischen Eigenschaften. Die Einträge dieses Branchenverzeichnisses
verweisen auf die White Pages.
• Green Pages bieten Auskunft über das Geschäftmodell und -prozess des Unternehmens, sowie technische Details zu den angebotenen Webservices.
Wie in Abbildung 2.2 zu sehen, geben die Anbieter ihre Webservices über WSDL
Dateien im UDDI System bekannt. Jemand, der diesen Service nutzen möchte, kann
so die genaue Spezifikation der Schnittstelle vom UDDI System erhalten und somit
Kontakt mit dem Webservice des Anbieters aufnehmen.
SOAP
SOAP stand ursprünglich mal für Simple Object Access Protocoll. Mit der Version 1.2,
die als Recommendation bei der W3C voliegt [MG03], wurde jedoch festgelegt, dass
SOAP keine Abkürzung mehr ist, da es nicht nur für den Zugriff auf Objekte dient.
SOAP wird verwendet, um Nachrichten zwischen zwei Endpunkten eines Webservices
zu versenden. Die Nachricht wird dabei in XML verfasst und meistens mit Hilfe von
HTTP und TCP versendet (siehe auch Abbildung 2.1). Eine Nachricht besitzt dabei
immer ein body-Element und kann optional ein head-Element besitzen. Letzteres
enthält zusätzliche Informationen zu der Nachricht, wie etwa Authentifizierunginformationen oder Informationen über die Zugehörigkeit einer Transaktion. Das bodyElement schliesslich enthält die eigentliche Nachricht. Hierbei ist jedes gültige XML
mit Namensraum erlaubt.
34
Spracheneinbettung
Dieser Abschnitt soll einen sehr kurzen Überblick über ausgewählte API’s geben, die
zur Zeit für Java und die Skriptsprache PHP verfügbar sind.
Apache-AXIS
AXIS steht für Apache Extensible Interaction System und beschreibt ein System zur
Handhabung von SOAP Nachrichten. Es ist eine Weiterentwicklung des damaligen
Apache-SOAP und die dritte Generation der SOAP-Systeme von Apache.
AXIS bietet die Möglichkeit, als Standalone Server oder aber in einer bereits existierenden Umgebung wie etwa Jakarta-Tomcat (siehe Abschnitt 2.2) zu laufen. Weiterhin
bietet AXIS eine weitreichende Unterstützung von WSDL. So ist es möglich, mit AXIS
aus WSDL-Dateien entsprechende Java-Stubs zu generieren und umgekehrt. Weiterhin
werden mit der AXIS-Laufzeitumgebung auch Werkzeuge mitgeliefert, welche es erlauben, SOAP Nachrichten abzufangen, um so ein einfaches debuggen zu ermöglichen.
AXIS läuft für Java bereits sehr stabil und wird in vielen Projekten eingesetzt. Für C++
findet z.Zt. eine entsprechende Portierung statt, so dass AXIS in naher Zukunft auch
für diese Sprache lauffähig ist. Desweiteren soll an dieser Stelle nicht näher auf AXIS
eingegangen und stattdessen auf [Fou04c] verwiesen werden.
SOAP und PHP
PHP liegt zur Zeit in zwei gängigen Versionen vor. In der älteren Version 4.x wird
SOAP nicht unterstützt. Die neuste Version 5.x von PHP hingegen unterstützt SOAP
von Haus aus und stellt intern Klassen und Funktionen für die Verarbeitung von
Webservices bereit. Da es sich jedoch um eine experimentelle Erweiterung handelt,
ist Vorsicht bei der Verwendung geboten, da diese ohne Ankündigung von PHP nicht
mehr unterstützt werden könnte.
Für die ältere Version 4.x existieren ein gewisse Anzahl von Erweiterungen, die die
Unterstützung von SOAP gewährleisten. Eine dieser Erweiterung ist nuSOAP, [Aya04],
welche eine Sammlung von PHP-Klassen bietet, die konfortabel Zugriff auf SOAP und
WSDL Funktionen bieten. Weiterhin gibt es eine SOAP-Unterstützung im Rahmen des
PHP Extension and Application Repository (kurz PEAR) [PEA04]. So ist es möglich,
einen Webservices-Server oder -Client in kurzer Zeit in PHP zu realisieren.
Frameworks
Webservices bieten eine gute Möglichkeit, um Subsysteme von E-Learning-Systemen
zu verteilen. Mit der Verwendung von Webservices zur Bildung eines Gesamtsystem
spricht man von Service Architekturen. Diese sind im Bereich von Business-Lösungen
bereits zu finden, im Bereich des E-Learnings sind erste Schritte in dieser Richtung
zu verzeichnen. So sind erste Arbeiten, die sich mit dieser Materie befassen, zu finden.
2.3. WEBSERVICES
35
Ein Bereich dieser Arbeiten umfasst Frameworks für webservice-gestützte E-LearningSysteme. Drei dieser Frameworks sollen im Nachfolgenden kurz vorgestellt werden.
E-Learning Framework
Merkmale Das E-Learning Framework ist ein noch sehr junges Projekt und aus einer Zusammenarbeit der Joint Information Systems Commitee - Centre for Educational Technology Interoperability Standards (kurz JISC-CETIS), dem Department for
Education, Science and Technology in Australien (kurz DEST) und Carnegie Mellon
Learning Services Architecture Lab im Jahr 2002 ins Leben gerufen worden.
Das Framework setzt sich aus sog. Services zusammen, welche jeweils im Netzwerk
über Webservices verfügbar sein sollen. Diese Service Architektur vermeidet so die Erzeugung monolithischer Systeme und erlaubt es, bereits entwickelte Komponete wiederzuverwenden. Viele der einzelnen Services sind nicht abhängig voneinander und
erlauben es, Systeme organisationsspezifisch zusammenzustellen.
Die einzelnen Services gliedern sich in insgesamt drei Schichten, der untersten Schicht,
den Common Services, der mittleren Schicht, den Learning Domain Services und der
obersten Schicht, den Sample User Agents. Die Abbildung 2.3 veranschaulicht die Services des Frameworks, sowie ihre Einteilung in die drei Schichten.
Abbildung 2.3: E-Learning Framework
Jeder Service wird durch eine oder mehrere frei verfügbare Spezifikationen beschrieben, wodurch eine solide Grundlage geschaffen wird. Jedoch ergibt sich hieraus auch
ein Problem, da nicht für jeden identifizierten Service eine entsprechende Spezifikation
existiert. So unterscheidet das Framework Services, die bereits vollständig beschrieben
werden können, wie etwa der Group Service, als auch Services, wie der Tracking Service, die nur zum Teil von Spezifikationen abgedeckt werden. Für einige Services, wie
36
etwa für den Grading Service existieren bisher noch keine Spezifikationen. Eine genaue
Auflistung der voll- und der nur teilweise implementierten Services ist unter [SW04]
nachzuschlagen. Für die Bearbeitung der APIs der einzelnen Services sind z.Zt. gut 30
Projekte ins Leben gerufen worden.
Bewertung Das ELF ist noch sehr jung und noch nicht sehr ausgereift. Einige der
Services, viele davon in der Common Services-Schicht, sind bereits fertiggestellt. Für
viele andere Services existieren noch keine entsprechenden Spezifikationen oder aber
diese werden erst auf eine Anwendbarkeit geprüft. Daher ist dieses Framework sehr
’löchrig’ und daher noch nicht zu empfehlen. Aufgrund der Idee, nur offene Standard
und Spezifikationen zu verwenden, besitzt dieser Standard sicherlich eine gute Zukunft.
Für die in der Einleitung vorgestellten Anwendungen im Bereich der (Hoch-) Schulen
sollte auf diese Framework zunächst verzichtet werden, da es zwar alle geforderten
Funktionalitäten enthält, aber ein Grossteil davon noch nicht zur Verfügung steht.
Open Knowledge Initiative
Merkmale Die Open Knowledge Initiative (kurz OKI) wurde 2001 vom Messachusetts Institute of Technology (kurz MIT) ins Leben gerufen und wird von vielen weiteren Universitäten unterstützt. Ziel des OKI ist es eine Grundlage zu bilden, die es
gestattet, skalierbare und zuverlässige Systeme zu entwickeln. Diese sollen flexibel gemäß den Lehransprüchen gestaltet werden können. Dazu wurde OKI als Framework
entwickelt, welches es erlaubt, ein System offen und modular aufzubauen, so dass die
Bedürfnisse verschiedener Einrichtungen, von der Grösse eines Campus bis hin zu der
Grösse eines Kurses befriedigt werden können. Für die Definition des Frameworks
wurden weltweit eingesetzte Standards des IMS [IMS04a], der ADL [ADL04], sowie
der IEEE-LTSC [LTS04] verwendet.
Das in Java realisierte Framework definiert 17 sog. Open Service Interface Definitions
(kurz OSID). Diese sind in zwei Schichten des vier Schichtenmodells des OKI Standards verteilt. Abbildung 2.4 zeigt diese vier Schichten. Die unterste Schicht bildet die
Infrastruktur des Systems. Diese Subsysteme dienen lediglich der Haltung und der Sicherung der Daten. Die zweite Schicht bilden die sog. Common Services welche die
grundlegensten Funktionen, wie etwa eine Authentifizierungs-, eine Regelwerk- oder
eine Logging-API vorsieht. Dies gewährt eine Abstraktionsschicht zwischen der Infrastruktur und den Lehrsystemen, so dass eine Neuimplementierung bei einem Systemwechsel ausbleiben kann. In der dritten Schicht, der sog. Educational Services
Schicht, sind Services zu finden, die für die Unterstützung in der Lehre nötig sind.
Dies sind API’s, die z.B. das Content- oder Kurs-Management, das Assessment (Logging, Tests, etc.) oder die Kommunikation unterstützen. Die vierte Schicht letztendlich
beschreibt die Schnittstelle zum Endbenutzer und liegt ausserhalb des Fokus des OKIFrameworks. Der Austausch zwischen den Schichten findet mit Hilfe sog. Sharable
Object statt, wobei das Binding, also die Art der Kommunikation zwischen den Services, nicht explizit festgelegt ist.
2.3. WEBSERVICES
37
Abbildung 2.4: OKI – Architektur
Implementierungen Die führenden beteiligten Universitäten besitzen zum OKI
Framework bereits einige Implementierungen. So betreibt das MIT das KursManagement-System Stellar [MIT04] und die Standford University das vergleichbare System CourseWork [Uni04]. Die University of Michigan schließlich entwickelt
z.Zt. ein abgeleitetes Framework für Kollaborationssysteme namens CHEF. Jedes dieser Systeme ist als Open Source erhältlich und kann frei genutzt werden. Weiterhin
existiert ein Projekt mit den Namen Sakai [Pro04], welches sich aus Teilen der genannten Systeme, sowie anderen nicht genannten Systemen zusammensetzt. Sakai ist
Open-Source und bietet ein Portal, welches um zusätzliche Module erweitert werden
kann. Diese Module nutzen Webservices, um Dienste auf entfernte Rechner zu nutzen
und deren Ergenisse innerhalb des Portals anzuzeigen.
Bewertung Das OKI Framework bietet sehr gute Ansätze, um das System der Hochschule zu realisieren. So ist das Framework nicht nur komplett definiert und liegt in
Java vor, sondern zusätzlich sind bereits Implementierung an verschiedenen Universitäten im Betrieb und frei erhältlich. Leider bietet das Framework nicht den grossen
Umfang an Services, wie es etwa das E-Learning Framework bietet, aber eine Realisierung der im Anforderungsprofil der Hochschule genannten Dienste ist machbar. Für
das Schulsystem ist diese Framework nicht geeignet, da es in Java implementiert ist. Jedoch bieten die implementierten OSID’s gute Anhaltspunkte, um eigene Webservices
mit entsprechenden Schnittstellen in PHP zu implementieren.
38
IMS Abstract Framework
Merkmale Das IMS Abstract Framewok wurde von der IMS Global Learning Consortium entwickelt und liegt seit 2003 in der Version 1.0 vor. Es dient dazu, das Zusammenspiel der einzelnen IMS Spezifikationen zu veranschaulichen, sowie deren Entwicklung zu unterstützen. Weiterhin wird das Abstract Framework benutzt, um die
Verträglichkeit fremder Spezifikationen mit den hauseigenen zu testen.
Diese Framework ist, wie die zuvor vorgestellten Frameworks auch, serviceorientiert,
d.h. dass ein System aus verschiedenen Systemen zusammengesetzt werden kann und
somit eine Wiederverwendung einzelner Komponenten ermöglicht wird. Die Kommunikation zwischen den Komponenten basiert dabei auf XML, wobei jedoch das Binding nicht zwingend festgelegt ist. Somit kann der Verbund zweier Komponenten über
SOAP, ebXML, oder aber auch über Java RMI oder ähnliches stattfinden. Jeder Service
wird durch die verwendeten Datenstrukturen sowie durch das Verhalten in bestimmten
Zuständen definiert. Der Zugang zu einem Service findet ausschliesslich duch einen
Service Access Point (kuz SAP) statt. Das Abstract Framework besteht wie das OKI
Framework auch aus vier Schichten (siehe Abbildung 2.5).
Abbildung 2.5: Abstract Framework – Schichtenmodell
Im Einzelnen sind dies folgende Schichten:
• Infrastructure Layer: In dieser Schicht sind Services, die direkt als Infrastrukur gelten. Darunter fallen z.B. Datenbankschnittstellen, Zugriff auf das Dateisystem, etc.
• Common Services Layer: Services aus dieser Schicht bieten grundlegende
Funktionen, wie etwa die Authentifizierung, Autorisierung, Datenbankmanagement, Identifikation, etc. Diese Schicht umfasst z.Zt. 18 definierte Services.
• Application Services Layer: Diese Dienste können direkt von Applikationen
2.4. FAZIT
39
genutzt werden. Auch hier sind insgesamt 18 Komponente definiert, wie etwa
Gruppen-, Mitglieds-, Content-, Kompetenz- und Party-Management, Kollaboration, Simulation, Enterprise Services, etc.
• Application Layer: In dieser Schicht ist die Applikation definiert. Diese
kann unterschiedliche Ausprägungen haben. Beispiele dafür können LearningContent-Management-Systeme, Content-Authoring-Tools, Learning-ManagentSysteme, News-Tools etc. sein.
Weiterhin sind Komponente definiert, die sich nicht direkt einordnen lassen. Diese sind
Komponente, die ausgetauscht werden. So werden z.B. Komponente wie Gruppen, Aktivitäten, Kompetenzen, Inhalte, Glossare, etc. definiert.
Bewertung Das IMS Abstract Framework ist vom Funktionsumfang am ehesten für
das Hochschulsystem geeignet, da es alle benötigten Komponenten bis hin zum optionalen Sequencing definiert. Leider liegt das Framework nur in Form einer Spezifikation, also in schriftlicher Form, vor, so dass eine Implementierung des eigentlichen
Frameworks nötig ist.
Für das Schulsystem ist dieses Framework gut geeignet, da die benötigten Komponenten definiert sind. Da keine Implementierung des Frameworks vorliegt, ist auch hier mit
einem zusätzlichen Zeit- und Kostenaufwand für die Eigenimplementierung zu rechnen.
2.4 Fazit
Zusammenfassung
Wie diese Arbeit gezeigt hat, existieren gute Implementierungen für Webserver. Diese sind jedoch aus verschiedenen Motivationen heraus entstanden, so dass sie unterschiedlich aufgebaut sind und einen entsprechend unterschiedlichen Funktionsumfang
besitzen. Je nach Anforderungen der Applikation, die für die Lehrumgebung gewählt
wird, sind entsprechende Auswahlkriterien zu berücksichtigen. Wie der Vergleich der
drei ausgewählten Server W3C Jigsaw, Apache HTTP und Jakarta Tomcat zeigt, eignet
sich jeder für bestimmte Aufgaben: der Jigsaw ist relativ leicht zu administrieren und
bietet eine innovatives, javabasiertes System. Der Apache HTTP gilt auf Grund seiner
enorm hohen Anzahl von Installationen als sehr stabil. Eine PHP-Anbindung ist relativ
einfach zu bewerkstelligen, so dass dieser Server für PHP-gestützte Webanwendungen
die erste Wahl sein dürfte. Der Jakarta Tomcat hingegen bietet sich an bei der Implementierung sehr umfangreicher Projekte mittel J2EE. Als Referenzimplementierung
der Servlet- und JSP-Spezifikationen von Sun unterstützt dieser immer die aktuellsten
Versionen der genannten Spezifikationen.
Weiterhin hat diese Arbeit einen kurzen Überblick über die Funktionsweise und Möglichkeiten von Webservices gegeben. Es wurde festgestellt, dass im Bereich des ELearnings noch Bedarf an weiteren Anwendungen und Arbeiten gibt. So existieren
40
z.Zt. lediglich einige Frameworks, die jedoch teilweise nicht zwingend auf Webservices aufbauen, sondern deren Verwendung vorgeschlagen wird. Das hier vorgestellte
E-Learning-Framework ist z.Zt. nur teilweise definiert und implementiert, besitzt jedoch auf Grund seines Serviceumfangs Potential für die Zukunft. Das OKI Framework
hingegen ist vollständig in Form von Java Klassen und Interfaces implementiert und basiert auf internationalen Standards. Hier liegt der Nachteil in der geringen Anzahl von
sog. OSIDs. Das dritte hier vorgestellte Framework, das IMS Abstract Framework, ist
eines der ausgereiftesten, unterstützt jedoch lediglich Spezifikationen der IMS und liegt
nur in Form einer Spezifikation vor. Der Serviceumfang von gut 32 Hauptkomponenten sowie etlichen anderen nicht klassifizierten Komponenten sollte in den häufigsten
Fällen ausreichen, um ein gewünschtes System zusammenzustellen.
Handlungsempfehlungen
Nachfolgend soll zu den beiden Beispielen aus dem Einleitungsteil eine kurze Handlungsempfehlung folgen.
Hochschule
Für den Betrieb des Hochschulsystems wird der Jakarta Tomcat vorgeschlagen, da
dieser für Servlets und JSP-Seiten am geeignesten ist. In diesem Zusammenhang wird
direkt der kostenlose Applikationsserver JBoss empfohlen, der nicht nur den Jakarta
Tomcat als Web-Container benutzt, sondern auch J2EE-zertifiziert ist und somit weitere
Container für J2EE-Beans bereithält. Somit ist es möglich, das System direkt modular
und serviceorientiert aufzubauen.
Für den Aufbau des Systems wird der OKI Standard vorgschlagen, da dieser bereits
einige implementierte Systeme besitzt, auf die kostenlos zurückgegriffen werden kann.
Damit kann das Sakai Project benutzt werden, welches ein bereits funktionstüchtiges
Portalsystem bereithält. Somit muss lediglich eine Selbstimplementierung der Sonderservices erfolgen, wie etwa das News- oder das Wikisystem, wobei hier auf die Schnittstellen der OKI-API zurückgegriffen werden kann.
Allgemeinbildende Schulen
Im Einleitungsteil wurde das System so definiert, dass es PHP nutzen soll. Unter diesen Umständen ist der Betrieb eines Apache Servers zu empfehlen, da die Stabilität
und die Modularität die besten Eigenschaften dieses Servers sind. Die Installation eines PHP Systems ist mit diesem Server einfach zu bewerkstelligen, da es eine sehr gute
und umfassende Unterstützung seitens der Internet Gemeinschaft gibt. Weiterhin kann
mit relativ geringen finanziellen Aufwand auf bestehende Angebote von WebhostingAnbietern zurückgegriffen werden, da diese im Allgemeinen ein Apache System mit
PHP-Unterstützung im Programm haben. In den meisten Fällen wird dabei auch eine
Datenbankunterstützung angeboten, so dass eine persistente Datenhaltung gewährleistet ist.
2.5. VERWENDETE ABKÜRZUNGEN
41
Als Implementierung des System sind Open-Source Projekte wie PHPNuke (als
Content-Management-System) oder Media-Wiki (als Wikisystem) zu empfehlen, auf
die jedoch in dieser Arbeit nicht weiter eingegangen werden soll.
Von der Verwendung von Frameworks für den Umfang dieses System wird abgeraten,
da der Aufwand der Implementierungen sich nicht rentieren würde. Stattdessen sollte
die Implementierung kleiner in Form von direkt für den Austausch der benötigten Daten spezialisierte Webservices erfolgen. Jedoch sollte dabei beachtet werden, dass die
meisten Webhosting-Anbieter in ihren günstigen Angeboten nicht zwingend eine Unterstützung für Webservices anbieten. In diesen Fällen muss eine manueller Austauch
zwischen den Schulsystemen erfolgen.
2.5 verwendete Abkürzungen
ADL
API
AXIS
CERN
CGI
CMS
CORBA
DARPA
ebXML
ELF
GUI
HTML
HTTP
ICP
IEEE-LTSC
J2EE
JNDI
LDAP
MD5
MIME
OKI
OSID
PEAR
PICS
PHP
RMI
RPC
SMIL
SOAP
SSI
SSL
W3C
-
Advanced Distributed Learning
Application Program Interface
Apache Extensible Interaction System
Centre European pour Rechearche Nucleaire
Common Gateway Interface
Content-Management-System
Common Object Request-Broker Architecture
Defense Advanced Research Projects Agency
electronic business XML
E-Learning Framework
Graphical User Interface
HyperText Markup Language
HyperText Transfer Protocol
Integrated Communications Provider
IEEE-Learning Technology Standards Committee
Java 2 Enterprise Edition
Java Naming and Directory Interface
Lightweight Directory Access Protocol
Message Digest Algorithm #5
Multipurpose Internet Mail Extension
Open Knowledge Initiative
Open Service Interface Definition
PHP Extension and Application Repository
Platform for Internet Content Selection
Hypertext Preprocessor
Remote Methode Invocation
Remote Prcedure Call
Synchronized Media Integration Language
Simple Object Access Protocol
Server Side Includes
Secured Sockets Layer
World-Wide-Web Consortium
42
WebDAV
WSDL
UDDI
XHTML
XML
XSLT
-
Web Distributed Authoring and Versioning
Webservice Description Language
Universal Description, Discovery and Integration
Extensible Hypertext Markup Language
Extensible Markup Language
Extensible StylesheetLanguage Transformation
Kapitel 3
Web Engineering/Web
Engineering-Technologien
Thilo Focke
Inhalt
3.1
3.2
3.3
3.4
Einleitung . . . . . . . . . . . . . . . . .
Grundlagen und Grundbegriffe . . . . .
Anforderungen an E-Learning-Systeme
Problemstellung . . . . . . . . . . . . . .
Funktionale Anforderungen . . . . . . . .
Nicht-funktionale Anforderungen . . . . .
Fazit und Handlungsempfehlung . . . .
43
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
44
45
48
48
49
58
61
44 KAPITEL 3. WEB ENGINEERING/WEB ENGINEERING-TECHNOLOGIEN
3.1 Einleitung
Das Internet, im speziellen das World Wide Web (WWW), hat sich in den letzten Jahren zu einem bedeutenden Bestandteil unseres Lebens entwickelt. Das WWW tangiert
mittlerweile zahlreiche Bereiche unseres täglichen Lebens. Nach [KPR03] liegt der
Grund für diese Allgegenwärtigkeit in der Natur des WWW, die gekennzeichnet ist
durch „globale und permanente Verfügbarkeit sowie komfortablen und einheitlichen
Zugriff auf beliebige verteilte, von jedermann erstellbare Informationen in Form von
Webseiten“.
Zwar wurde das WWW ursprünglich als reines Informationsmedium konzipiert, doch
hat es sich in den letzten Jahren immer mehr zu einem Anwendungsmedium entwickelt.
Wurden in den frühen Jahren des Internet Informationen in Form von miteinander verbundenen, statischen Webseiten bereitgestellt, findet man mittlerweile vollwertige und
komplexe Softwaresysteme in Form von so genannten Web-Anwendungen vor. Dabei handelt es sich um interaktive, datenintensive und personalisierbare Dienste, die
über die verschiedensten Endgeräte in Anspruch genommen werden können. Der entscheidende Unterschied zur klassischen Softwareentwicklung ist dabei die Vielfalt der
einsetzbaren Technologien und Standards, sowie die unterschiedlichen Entwicklungsund Nutzungsplattformen. Für die Entwicklung webbasierter Softwaresysteme ist daher eine Kombination des traditionellen Software Engineering in Verbindung mit Anforderungen des WWW erforderlich.[DLWZ03]
Diese Ausarbeitung, die im Rahmen des Seminars „Web Engineering - Entwicklung
von Lehr- und Lernsystemen“ im Wintersemester 2004/2005 an der Universität Oldenburg erstellt wurde, soll zunächst eine Einführung in die Disziplin des Web Engineering
bieten und darauf aufbauend die Phase der Anforderungsanalyse im Bereich von ELearning-Systemen an Hochschulen stärker beleuchten. Dabei wird die Fragestellung
aufgegriffen, welche Anforderungen an ein solches System existieren und wie diese
dokumentiert werden können. Neben den funktionalen Anforderungen werden dabei
auch die nichtfunktionalen Anforderungen ermittelt. Für die Ermittlung der funktionalen Anforderungen wird in diesem Zusammenhang auf die „Unified Modeling Language“ in Form der so genannten Anwendungsfalldiagramme zurückgegriffen. Zum
Ende der Ausarbeitung wird neben einem Fazit auch eine Handlungsempfehlung an
den Leser ausgesprochen.
3.2. GRUNDLAGEN UND GRUNDBEGRIFFE
45
3.2 Grundlagen und Grundbegriffe
Obwohl sich das Web von seiner ursprünglich Ausrichtung als Informationsmedium zu einem Anwendungsmedium entwickelt hat und Web-Anwendungen mittlerweile vollwertige, komplexe Softwaresysteme darstellen, erinnert die heutige Ad-hocEntwicklung eben solcher Anwendungen sehr stark an Praktiken der Softwareentwicklung in den 60er Jahren. Damals erkannte man erst sehr spät, dass die Entwicklung von
Softwareanwendungen weitaus mehr erforderte als nur über Fachkenntnisse in diversen
Programmiersprachen zu verfügen. Die damals genutzten Techniken konnten mit dem
Umfang und der Komplexität der zu entwickelnden Software nicht mehr Schritt halten.
In der Folge kam es zu den ersten großen gescheiterten Software-Projekten. Erstmals
wurde der Begriff „Software Engineering“ geprägt, der sich mittlerweile zu einem Teilgebiet der Informatik entwickelt hat und sich mit der standardisierten ingenieurmäßigen Herstellung von Software und den damit verbundenen Prozessen beschäftigt.
Vergleichbar mit der damaligen Situation sieht es heute bei der Entwicklung von WebAnwendungen aus. Nach [KPR03] wird die Erstellung von Web-Anwendungen oftmals als ein einmaliges Ereignis angesehen. Sie erfolgt vielfach in einer spontanen Art
und Weise und basiert dabei zumeist auf dem Wissen, den Erfahrungen und den Entwicklungspraktiken individueller Entwickler. Weiterhin beschränkt sie sich auf Wiederverwendung im Sinne des „Copy&Paste-Paradigmas“ und ist zu guter letzt durch
unzureichende Dokumentation von Entwurfsentscheidungen gekennzeichnet.
Zwar erweist sich in vielen Fällen eine derartige Vorgehensweise als durchaus sinnvoll,
allerdings ist zu berücksichtigen, dass solche schnellen und unsauberen Entwicklungen
zu umfangreichen Qualitätsmängeln und später auch zu schwerwiegenden Problemen
bei Betrieb und Wartung führen. Die entwickelten Anwendungen sind meist stark technologieabhängig und fehleranfällig. Zudem sind sie durch unzureichende Leistungsfähigkeit, Zuverlässigkeit und Skalierbarkeit gekennzeichnet und weisen eine mangelnde
Benutzerfreundlichkeit und dadurch fehlende Akzeptanz auf (vgl. [KPR03]).
Die gängige Praxis bei der Entwicklung von Web-Anwendungen sowie die gleichzeitig
stark wachsende Komplexität und Bedeutung von Web-Anwendungen für viele Bereiche unserer Gesellschaft, insbesondere für die effiziente Abwicklung unternehmenskritischer Prozesse, gibt Anlass zu wachsender Besorgnis über diese Art der Entwicklung und die langfristige Qualität von Web-Anwendungen, die bereits einen Großteil
der heute entwickelten Individualsoftware ausmachen. Berücksichtigt man weiterhin,
dass webbasierte Softwaresysteme hochgradig vernetzt und mittlerweile allgegenwärtig sind, so lässt sich vermuten, dass der Umfang einer Web-Krise die Softwarekrise
der 60er Jahre um ein Vielfaches übertreffen könnte. Es lässt sich also sagen, dass die
Disziplin des Web Engineering einer Neuauflage der Software-Krise entgegentritt.
Web Engineering ist nicht als einmaliges Ereignis anzusehen, sondern erstreckt sich
vergleichbar zum Software Engineering über den gesamten Lebenszyklus einer Web
Anwendung. Laut [KPR03] lässt sich Web Engineering wie folgt definieren: „Web Engineering ist die Anwendung systematischer und quantifizierbarer Ansätze (Konzepte, Methoden, Techniken, Werkzeuge), um Anforderungsbeschreibung, Entwurf, Implementierung, Test, Betrieb und Wartung qualitativ hochwertiger Web-Anwendungen
kosteneffektiv durchführen zu können.“ Ähnlich definiert [DLWZ03] die Disziplin des
Web Engineering: „Web Engineering ist die methodenbasierten, werkzeugunterstützte,
quantifizierte, standardgerechte, erfahrungsnutzende und Community-bezogene Entwicklung und Wartung von webbasierten Softwaresystemen.“
Web-Anwendungen weisen im Vergleich zu traditionellen, nicht web-basierten Anwendungen eine Reihe von Merkmalen auf, die komplett fehlen oder auch besonders stark
ausgeprägt sind. Ein Beispiel für ein Merkmal, das in traditionellen Anwendungen
fehlt, sei beispielsweise die nichtlineare Navigation bei Web-Anwendungen. Die Häufigkeit von Änderungen ist ein Beispiel für ein Merkmal, das bei Web-Anwendungen
besonders stark ausgeprägt ist. Das Vorhandensein eines bestimmten Merkmals sowie
dessen Intensität sind zum Teil auch abhängig von der Art der Anwendung. So müssen
beispielsweise Web-Anwendungen wie E-Learning-Systeme mehr Augenmerk auf die
Aktualität und Konsistenz des Inhalts legen als reine Informationsanbieter.
Oftmals sind diese Charakteristika der Grund dafür, dass Konzepte, Methoden, Techniken und Werkzeuge des traditionellen Software Engineering nur in angepasster Form
zur Entwicklung von Web-Anwendungen eingesetzt werden können oder sich sogar als
gänzlich ungeeignet erweisen.
Obwohl auf den ersten Blick viele Gemeinsamkeiten mit dem klassischen Software Engineering erkennbar sind, so ist doch zu beachten, dass viele Ansätze aufgrund der besonderen Charakteristika von Web-Anwendungen angepasst oder sogar neu entwickelt
werden müssen. Dennoch können die Grundprinzipien ähnlich wie die des Software
Engineering wie folgt charakterisiert werden (vgl. [DLWZ03]):
• Klar definierte Ziele und Anforderungen
• Systematische Entwicklung einer Web-Anwendung in Phasen
• Sorgfältige Ausgestaltung dieser Phasen
• Kontinuierliche Überwachung des gesamten Entwicklungsprozesses
Laut [KPR03] ermöglicht Web Engineering somit die Planbarkeit und Wiederholbarkeit des Entwicklungsprozesses und damit auch eine kontinuierliche Weiterentwicklung von Web Anwendungen. Dadurch kann nicht nur Kostenreduktion und Risikominimierung bei der Neuentwicklung und Wartung erreicht werden, sondern auch eine
Qualitätssteigerung sowie die Messbarkeit der Qualität von Ergebnissen der einzelnen
Phasen.
Im Kontext der Lehr- und Lernsysteme beschreibt [DLWZ03] einige grundlegende
Aspekte bei der Entwicklung von E-Learning-Systemen. Dabei werden die unterschiedlichen Phasen und Bereiche der Websystem-Entwicklung und -wartung in diesem speziellen Kontext konkretisiert.
• E-Learning-Problemdefinition: Diese Phase widmet sich „dem Gesamtkonzept einer webbasierten Ausbildungsform hinsichtlich ihrer Integration in ein
didaktisches Konzept für den jeweiligen avisierten Anwenderkreis“.
3.2. GRUNDLAGEN UND GRUNDBEGRIFFE
47
• E-Learning-Anforderungsanalyse: In dieser Phase werden vor allem funktionale und nicht-funktionale Anforderungen im Kontext des E-Learnings beleuchtet. Dabei werden beispielsweise funktionale Anforderungen wie die Bereitstellungsformen der Lehrmaterialien genauso angesprochen wie plattformspezifische Anforderungen, die Fragestellungen nach den einzusetzenden Technologien
behandeln.
• E-Learning-Spezifikation: In dieser Phase werden die in der vorherigen Phase
definierten Anforderungen mittels adäquater Darstellungsmittel wie beispielsweise Anwendungsfalldiagramme spezifiziert und konkretisiert.
• E-Learning-Entwurf: Diese Phase betrachtet die zur Anwendung kommenden
Technologien im speziellen Umfeld des elektronischen Lehrens und Lernens.
• E-Learning-Implementation: Hier werden die Komponenten der Lehr- und
Lernsysteme programmiert und getestet unter Berücksichtigung der Vorgaben
des E-Learning Entwurfs.
• E-Learning-Erprobung: Laut [DLWZ03] ist diese Phase von besonderer Bedeutung, da hierbei die Bewährung des Lehr- und Lernsystems im Web überprüft
wird und für die Pflege und Erweiterung des Websystems wichtige Erfahrungen
geliefert werden.
• E-Learning-Wartung: Die Tragfähigkeit und künftige Akzeptanz bei der Anwendung von webbasierten Lehr- und Lernsystemen ist von besonderer Bedeutung. Diese Phase dient daher der Systempflege von webbasierten Lehr -und
Lernsystemen.
Im nun folgenden Abschnitt werden die Phasen „E-Learning-Anforderungsanalyse“
und „E-Learning-Spezifikation“ anhand eines konkreten Beispiels einer Hochschule verdeutlicht. Wie oben beschrieben werden in der Phase „E-LearningAnforderungsanalyse“ zunächst funktionale und nicht-funktionale Anforderungen aufgenommen und in der Phase „E-Learning-Spezifikation“ anhand der UML Anwendungsfalldiagramme modelliert.
3.3 Anforderungen an E-Learning-Systeme
Problemstellung
Nachdem im vorherigen Kapitel einige Grundlagen und Grundbegriffe zum WebEngineering angesprochen wurden, soll in diesem Abschnitt die Anforderungsanalyse und Spezifikation für E-Learning-Systeme genauer beleuchtet werden. Nach
[DLWZ03] ist die Web-Anforderungsanalyse „die Phase der Kontrolle von Anforderungen an ein zu entwickelndes Websystem hinsichtlich Korrektheit, Vollständigkeit,
Sachgerechtheit, Konsistenz, Machbarkeit und deren zweckmäßige, im Allgemeinen
computergestützte Speicherung für die ständige Nutzung, Aktualisierung und Überprüfung im Verlauf der Websystem-Entwicklung“. Im Allgemeinen spricht man auch
vom so genannten „Requirements Engineering“. Nach [KPR03] beschäftigt sich das
Requirements Engineering mit Prinzipien, Methoden und Werkzeugen zur Ermittlung,
Beschreibung, Prüfung und Verwaltung von Anforderungen in der Systementwicklung.
Nach der Aufnahme der Anforderungen erfolgt die Spezifikation. Unter der Spezifikation versteht man nach [DLWZ03] die „Formulierung der für ein erstes arbeitsfähiges System notwendigen funktionalen Anforderungen in einem Modell, welches die
anwendungsbezogenen und organisatorischen Systemkomponenten beschreibt und als
prototypische Umsetzung erste Aufgaben zur Analyse der Systemanforderungen erfüllen kann“. Der Prozess des Modellierens beim Web-Engineering ist dabei die „strukturelle, operationelle und informationelle Umsetzung von Web-Systemanforderungen in
einer dem zu entwickelnden System angemessenen und für den Entwickler und Auftraggeber interpretierbaren Form“,
Nach einer Umfrage der European Software Process Improvement Training Initiative
(ESPITI) sahen 80 Prozent der befragten Unternehmen in der Ermittlung der Anforderungen sowie der Verwaltung der Anforderungen die Hauptprobleme im Entwicklungsprozess [ESPITI]. Laut eines Berichts des Cutter Consortiums decken nur 16 Prozent
der Web-Anwendungen die Bedürfnisse der Auftraggeber voll ab, 53 Prozent der ausgelieferten Systeme hingegen haben nicht den geforderten Funktionsumfang [CC]. Anforderungen spielen für die Qualität von Web-Anwendungen eine entscheidende Rolle.
Es treten immer wieder massive Probleme mit Anforderungen auf, da sie beispielsweise unklar spezifiziert, fehlerhaft oder unvollständig sind. Die Folgen sind immens: Die
späteren Benutzer akzeptieren das System nicht, es kommt zu Fehlplanungen oder es
werden inadäquate Softwarearchitekturen in der Entwicklungsphase entworfen beziehungsweise eingesetzt.
In den folgenden Abschnitten werden die funktionalen und nicht-funktionalen Anforderungen an eine E-Learning-Plattform für eine Hochschule ermittelt. Die funktionalen Anforderungen betreffen dabei vor allem den Leistungsumfang, d.h. die Funktionen, die das E-Learning-System ausüben soll, einschließlich der zugehörigen Ein- und
Ausgaben. Die nicht-funktionalen Anforderungen betreffen vor allem die Realisierung
(Programmiersprache, Datenbankverwaltungssystem, Schnittstellen, etc.), die Einführung (Dokumentation, Schulung, etc.), die Qualität (Benutzerfreundlichkeit, Zuverlässigkeit, Wartbarkeit, etc.) sowie das Projektmanagement (Vorgehensmodell, Termine,
etc.). Zwar sind die Anforderungen an eine Hochschule weitaus komplexer als beispielsweise an eine Berufsschule, doch lassen sich die verwendeten Verfahren zur Modellierung der Anforderungen auch auf andere Bildungseinrichtungen übertragen.
3.3. ANFORDERUNGEN AN E-LEARNING-SYSTEME
49
Für die Ermittlung und Aufnahme der funktionalen Anforderungen werden die Anwendungsfalldiagramme der UML (Unified Modeling Language) verwendet. Bei der Beschreibung der nicht-funktionalen Anforderungen wird vor allem auf Qualitätsaspekte
eingegangen.
Funktionale Anforderungen
In diesem Abschnitt sollen die Arbeitsprozesse analysiert werden, die im Bereich der
Lehre an Hochschulen ablaufen. Auf Basis dieser Analyse kann anschließend festgelegt werden, welche Bereiche der hier gezeigten Abläufe eine E-Learning-Plattform
abdecken sollte. Dies ermöglicht das Formulieren von detaillierten Anforderungen an
eine solche Plattform.
Für die Darstellung der Ergebnisse einer solchen Prozessanalyse haben sich graphische
Notationen wie Anwendungsfalldiagramme bewährt. Anwendungsfalldiagramme, die
auch als „Use Case Diagramme“ bezeichnet werden sind Teil der Unified Modeling
Language (UML). Die UML ist ein Standard für die Notation für die objektorientierte
Modellierung. Sie ist eine Notation, die ein objektorientiertes System auf verschiedenste Weisen beschreibt. Wichtig ist jedoch der Hinweis, dass die UML lediglich ein
System beschreibt, nicht wie das Vorgehensmodell zur Realisierung des Systems auszusehen hat. Dazu gib es andere Verfahren, wie beispielsweise den „Rational Unified
Process“ (RUP) oder auch „eXtreme Programming“ (XP), ein Vertreter eines leichtgewichtigen (agilen) Entwicklungsprozesses.
Ausgangspunkt der Analyse ist dabei die Identifizierung der beteiligten Aktoren. Ein
Aktor stellt keine konkrete Person dar, sondern eine Rolle, die eine Gruppe von Personen innerhalb des Prozesses spielt. Es ist sowohl möglich, dass ein Aktor durch mehrere Personen realisiert wird (beispielsweise ist der Aktor Lernender typischerweise
vielfach vorhanden) als auch dass eine Person in mehreren Rollen auftritt (beispielsweise ist ein Professor typischerweise Lehrender und Prüfender). Dargestellt werden
Aktoren in den folgenden Diagrammen als stilisierte Personen („Strichmännchen“).
Einem Aktor werden die Tätigkeiten zugeordnet, die er ausführen kann. Dabei werden
die einzelnen Arbeitsschritte zu Anwendungsfällen (engl. Use Cases) zusammengefasst. Ein Anwendungsfall umfasst dabei eine Reihe von Tätigkeiten, die einem gemeinsamen Ziel dienen. Anwendungsfälle können hierarchisch gegliedert sein, um
unterschiedliche Abstraktionsniveaus auszudrücken. So kann beispielsweise ein abstrakter Anwendungsfall „Stundenplan zusammenstellen“ zerfallen in die einzelnen
Anwendungsfälle „Informationen über Veranstaltungen einholen“ und ein mehrfaches
„Veranstaltung belegen“. Diese selbst setzen sich auch wieder aus einzelnen Schritten
zusammen. Anwendungsfälle werden in ovalen Formen notiert. Sie sind verbunden mit
dem Aktor, der sie ausführt (siehe Abbildung 3.1).
Um die Integrationsaspekte deutlich zu machen, werden in den folgenden Diagrammen
weiterhin die von den Anwendungsfällen betroffenen Daten kenntlich gemacht (als
rechteckige Formen). Man unterscheidet dabei zwischen schreibenden Datenzugriffen,
die durch einen Pfeil vom Anwendungsfall zu den Daten dargestellt werden und rein
lesenden Zugriffen, also einem Abrufen der Daten, die durch einen Pfeil von den Daten auf den Anwendungsfall notiert werden. Ein Datenkasten repräsentiert gleichartige
Abbildung 3.1: Anwendungsfall „Stundenplan zusammenstellen“
Daten. Diese müssen jedoch nicht zentral abgelegt sein, sondern können an verschiedenen Stellen als Datenbanken, Listen oder Akten vorliegen. Entscheidend ist es hier, zu
sehen, welche Informationsflüsse im Rahmen der Arbeitsprozesse auftreten. Im Beispiel wäre also „Information über Veranstaltungen einholen“ ein rein lesender Zugriff
auf die Veranstaltungsdaten, wohingegen „Veranstaltung belegen“ die Anzahl der freien Plätze vermindert und daher auf diese Daten lesend und schreibend zugreift (siehe
Abbildung 3.2).
Abbildung 3.2: Anwendungsfall „Stundenplan zusammenstellen“ mit Datenabhängigkeiten
Die Aktoren an einer Hochschule zerfallen grundsätzlich in drei Gruppen: Die Lernenden, das Lehrpersonal und die Verwaltungsmitarbeiter. Diese drei Gruppen werden nun
51
im Einzelnen beleuchtet.
Die Lernenden
Die Lernenden bilden die zahlenmäßig größte Gruppe an der Hochschule. Als Zielgruppe des Lehrbetriebs kommt ihren Interessen eine besondere Bedeutung zu. Diesen Interessen kann jedoch häufig nur eingeschränkt begegnet werden. Beispiele dafür
sind die stark begrenzten Öffnungszeiten von Sekretariaten, innerhalb derer Anträge
abgegeben werden können, das Beharren auf papierbasierter Kommunikation oder das
Fehlen von zentralen Ansprechpartnern. Eine E-Learning-Plattform verspricht gerade
hier als zentrale Anlaufstelle dem Studierenden einheitliche, flexible und zeitlich unabhängige Zugangsmöglichkeiten zu den für ihn relevanten Informationen und Diensten
zu bieten. Es muss also festgestellt werden was ein Lernender typischerweise an der
Hochschule tut.
Da die Wissensvermittlung an Hochschulen in einzelne Veranstaltungen untergliedert
ist, ist die Kerntätigkeit des Lernenden das Teilnehmen an Veranstaltungen. Dies untergliedert sich in das Recherchieren, Abrufen und Durcharbeiten vorgegebener Lehrmaterialien sowie das Anfertigen eigener Materialien. Diese können den Lehrenden zur
Bewertung zur Verfügung gestellt werden.
Über die einzelne Veranstaltung hinaus muss der Lernende sein Studium organisieren.
Dazu muss er Informationen über das Lehrangebot der Hochschule einholen, Kurse
und Prüfungen entsprechend seiner Studienordnung belegen und sich über die Ergebnisse dieser Prüfung und den Stand seines Studiums informieren. Daneben gibt es eine
Reihe von reinen Verwaltungsaufgaben, an denen der Lernende zumeist als Antragssteller beteiligt ist, etwa die Verwaltung seiner Personaldaten (Adressänderung etc.),
die Umschreibung auf neue Studienordnungen/Studiengänge, die Rückmeldungen, Beurlaubungen und Freisemester sowie die Kontrolle seiner Immatrikulationsbeiträge.
Zur Bewältigung seines Studiums wird dem Lernenden eine Reihe von Diensten der
Hochschule zur Verfügung gestellt, die er als Infrastruktur nutzen kann. Diese umfassen die Nutzung der Universitätsbibliothek oder anderer Informationsquellen (Datenbanken), Zugang zu Geräten (Computer) und speziellen Räumen (Labore). Außerdem
stehen dem Lernenden auch soziale und technische Einrichtungen wie die Mensa, die
Studentenwohnheime, Kopiermöglichkeiten etc. zur Verfügung.
Gemäß der oben angegebenen Ausführungen sind die Anwendungsfälle des Lernenden
unter Abbildung 3.3 ersichtlich. Bei der Erfüllung seiner Aufgaben kommt der Lernende in Kontakt mit (eventuell externen) Informationssystemen, dem bereitgestellten
Lehrmaterial und selbst angefertigten Lehrmaterialien. Bei der Anmeldung zu Veranstaltungen beeinflusst er seine Studiendaten und mit Anträgen an die Verwaltung kann
der Lernende seine Verwaltungsdaten beeinflussen.
Abbildung 3.3: Anwendungsfälle des Lernenden
Das Lehrpersonal
Das Lehrpersonal nimmt drei verschiedene Rollen an, die des Lehrenden, des Prüfers
und des Organisators. Die Aufgabe des Lehrenden ist es, eine Veranstaltung (Vorlesung, Seminar, Exkursion, etc.) durchzuführen. Typischerweise wird zu einer Veranstaltung Lehrmaterial erstellt, das den Lernenden dann präsentiert wird. Unterlagen
zum behandelten Stoff (Vorlesungsskripte oder darüber hinausgehende Materialien)
werden an die Lernenden verteilt, bzw. es werden Hinweise zum selbstständigen Bezug
dieser Materialien gegeben. Zur Erstellung der Lehrmaterialien recherchieren die Lehrenden Informationen oder sie verwenden bereits existierende Lehrmaterialien. Daraus
ergibt sich, dass der Lehrende sowohl auf (externe) Informationssysteme zurückgreifen
muss, als auch auf eigene und fremde Lehrmaterialien (siehe Abbildung 3.4).
Eng verknüpft mit dem Vorgang des Lehrens ist der des Prüfers/Bewertens. Die Rolle des Prüfers korrigiert und bewertet eine vom Lernenden erbrachte Leistung. Der
Anwendungsfall „Korrigieren“ kennzeichnet dabei alle Tätigkeiten, die dem Lernenden eine Rückmeldung über die von ihm gemachten Fehler geben. „Bewerten“ ist der
Vorgang des Erstellens eines Urteils über die erbrachten Leistung, meist in Form von
Noten. Der Prüfer muss die von den Lernenden erstellten Lernmaterialien also einsehen
und bewerten und als Prüfungsinformationen ablegen können (siehe Abbildung 3.5).
Der dritte Aktor aus der Gruppe des Lehrpersonals ist der Organisator. Er ist dafür ver-
53
Abbildung 3.4: Anwendungsfälle des Lehrenden
antwortlich, die Veranstaltungen des Lehrpersonals zu organisieren. Dazu gehört das
Eintragen in ein zentrales Vorlesungsverzeichnis oder andere Bekanntmachungen, das
Festlegen von Räumen und Zeiten sowie das Festlegen von Kapazitäten und Zugangsvoraussetzungen. Die Anmeldungen von Lernenden zu Prüfungen und Veranstaltungen
müssen kontrolliert werden (auf Erfüllung von Zugangsvoraussetzungen etc.). Die Anwendungsfälle des Organisators sind auch aus Abbildung 3.6 ersichtlich.
In der Praxis wird man sicherlich verschiedene Realisierungen dieser Rollen (Lehrender, Prüfer, Organisator) finden. Lehr- und Prüfungstätigkeiten können von Professoren
oder wissenschaftlichen Mitarbeitern wahrgenommen werden. Diverse Aufgaben fallen zumeist schon in den Bereich der Hochschulverwaltung. So kann die Anmeldung zu
Prüfungen im zentralen Prüfungsamt erfolgen oder bei Lehrenden direkt. Die Raumbelegung kann dezentral geregelt sein, pro Fachbereich oder zentral für die gesamte
Hochschule.
Die Verwaltungsmitarbeiter
Die Verwaltung an Hochschulen folgt zumeist einer standardisierten Dezernataufteilung. Entsprechend können als Aktoren mit Bezug zur Lehre das Haushaltsdezernat,
das Personaldezernat, die technischen Betriebe (Gebäude und Raumverwaltung) sowie
das Studentensekretariat und schließlich das Prüfungsamt identifiziert werden. Weiterhin werden viele Infrastrukturdienste für die Lehrenden vom Studentenwerk organisiert, und auch die Bibliotheken haben eine eigene Verwaltung. Für die Funktionalität
einer E-Learning-Plattform sind jedoch die internen Verwaltungsvorgänge nicht rele-
Abbildung 3.5: Anwendungsfälle des Prüfers
vant, daher sind die Funktionalitäten der Verwaltungs-Aktoren nicht detailliert aufgeführt (siehe Abbildung 3.7).
55
Abbildung 3.6: Anwendungsfälle des Organisators
Verfeinerung der Anwendungsfälle
Während in den vorherigen Abschnitten die Prozesse in der Hochschule unabhängig
von unterstützten Computersystem abstrakt beschrieben wurden, muss nun der somit festgelegte Funktionsumfang einer E-Learning-Plattform mit Hilfe detaillierter Beschreibungen der identifizierten Anwendungsfälle konkretisiert werden. Zunächst einmal kann man die herausgearbeiteten Anforderungen zwischen Basis- und KomfortAnforderungen („nice to have“) unterscheiden. Basis-Anforderungen müssen von einer
E-Learning-Plattform erfüllt werden, sie decken im Allgemeinen diejenigen Arbeitsabläufe ab, die von an der Hochschule beteiligten Personen regelmäßig ausgeführt werden müssen. Ein Verzicht auf die Realisierung dieser Basis-Anforderungen innerhalb
einer E-Learning-Plattform schränkt deren Funktionsumfang wesentlich ein. Dies kann
zu großen Akzeptanzproblemen führen und sollte daher vermieden werden. KomfortAnforderungen dagegen erwachsen häufig aus weitergehenden Überlegungen zur Benutzerfreundlichkeit und sind zumeist „nice to have“. Die detaillierte Beschreibung der
Anwendungsfälle erfolgt in Form von vorstrukturierten Tabellen (Use Case Template).
Wie so eine Tabelle vom Aufbau aussieht ist aus Tabelle 3.1 ersichtlich.
Abbildung 3.7: Anwendungsfälle der Verwaltung
Nummer
Name des Anwendungsfalles
Ziel
In Kurzform wird hier das Ziel des Benutzers erläutert,
das durch Ausführung dieser Funktion erreicht werden
soll.
Vorbedingung
Viele Funktionen sind nur sinnvoll durchführbar, wenn
bestimmte Bedingungen vorliegen. Diese Bedingugnen
werden hier zusammengefasst.
Nachbedingung
Die Effekte die die Funktionalität hat, bezeichnet man
auch als Nachbedingung des Anwendungsfalles. Die Vorund Nachbedingungen reflektieren die Datenabhängigkeiten des Anwendungsfalles. Zur Prüfung vor Vorbedingungen muss ein lesender Zugriff auf die entsprechenden Daten stattfinden, die in den Nachbedingungen ausgedrückten Veränderungen im Zustand bedeuten einen
schreibenden Zugriff.
Ein Anwendungsfall kann eine Basis-Anforderung oder
eine Komfort-Anforderung darstellen.
Typ
Auslösendes Ereignis
Es sollen Informationen festgehalten werden, wie der Anwendungsfall zur Ausführung kommt. Häufig geschieht
dies aufgrund von Aufrufen durch den Benutzer, aber
auch die Kombination von Funktionen im Sinne der Benutzerfreundlichkeit kann zur Ausführung eines Anwendungsfalles führen.
57
Beschreibung
Zentrales Element der Anwendungsfalldetails ist die Beschreibung des Inhalts und des Ablaufs des Anwendungsfalles. Hier wird beschrieben, wie der Anwendungsfall
das Ziel des Benutzers verwirklichen soll.
Erweiterungen
Während in der Beschreibung der normale oder mindestens notwendige Ablauf geschildert wird, können unter Erweiterungen alternative Realisierungsmöglichkeiten oder Komfort-Erweiterungen angegeben werden.
Tabelle 3.1: Beispiel für eine Use Case Template
Gemäß der Struktur die durch Tabelle 3.1 vorgegeben wurde, können die Anwendungsfälle detailliert beschrieben werden. Eine komplette Beschreibung aller Anwendungsfälle würde den Umfang dieser Ausarbeitung sprengen, weshalb im folgenden exemplarisch der Anwendungsfall „Suche nach Materialien“ detailliert beschrieben wurde
(siehe Tabelle 3.2).
Anwendungsfall 1
Suche nach Materialien
Ziel
Vorbedingung
Suche nach Materialien in E-Learning-Plattform
-
Nachbedingung
Typ
Liste von verfügbaren Materialien erstellt
Basis-Anforderung
Auslösendes Ereignis
Beschreibung
Funktionsaufruf des Anwenders
Der Anwender sucht nach bestimmten Informationen, die
ihn interessieren. Er kann seine Anfrage strukturiert formulieren und eine Suche über alle verfügbaren Materialien oder einen ausgezeichneten Teil davon starten. Das
System startet eine entsprechende Suche in allen zugänglichen Materialdatenbanken und präsentiert die Ergebnisse als Liste. Neben einer Volltextsuche ist eine genauere
Suche auf den Metadaten für die in das System eingebundenen Materialien denkbar. So kann beispielsweise nach
Materialien zu einem Thema oder nach Materialien eines
bestimmten Dozenten gesucht werden.
Zusätzlich kann dem Lernenden ermöglicht werden, mit
der E-Learning-Plattform auf Datenbestände, die außerhalb der E-Learning-Plattform verwaltet werden, zuzugreifen.
Erweiterungen
Tabelle 3.2: Beschreibung des Anwendungsfalles „Suche nach Materialien“
Nicht-funktionale Anforderungen
Nachdem im vorherigen Kapitel definiert wurde, welchen Funktionsumfang eine ELearning-Plattform abdecken kann, sollen nun die nicht-funktionalen Anforderungen
beschrieben werden. Nicht-funktionale Anforderungen beschreiben die Qualität in der
die Funktionalitäten des Systems erbracht werden sollen. Sie ziehen sich damit orthogonal zu den funktionalen Anforderungen quer durch das gesamte Produkt. Häufig
führen Verletzungen der nicht-funktionalen Anforderungen zu geringer Benutzerakzeptanz, selbst wenn alle benötigten Funktionen realisiert wurden.
Plattformunabhängigkeit
E-Learning-Plattformen die den im Abschnitt 3.3 geforderten Funktionsumfang besitzen, sind typischerweise als Client-Server Systeme realisiert. Dabei stellt die Hochschule zentrale Server zur Verfügung, auf denen Lehrmaterialien und Verwaltungssysteme abgelegt sind und die einzelnen Benutzer greifen mit Hilfe von ClientProgrammen auf diese Server zu. Dies bedeutet, dass für die Installation der ELearning-Plattform zwei Szenarien zu beachten sind: Die zentrale Server-Installation
in der Hochschule und die Installation der Clients bei Lehrenden und Lernenden.
Für die zentrale Server-Installation spielt die verwendete Systemplattform eine eher untergeordnete Rolle, da in den meisten Hochschulrechenzentren in der Regel verschiedene Server-Betriebssysteme parallel zum Einsatz kommen. Eine E-Learning-Plattform,
die sowohl auf Windows als auch auf Unix-basierten System zum Einsatz kommen
kann, sollte überall problemlos eingesetzt werden können. Weiterhin ist es wünschenswert, dass die E-Learning-Plattform möglichst wenig weitere Anforderungen an die
Ausstattung der betreibenden Hochschule stellt. Zu berücksichtigen sind hier zum
Betrieb der E-Learning-Plattform notwendigen Middleware- und Backend-Systeme,
wie spezielle Web-Server (Apache, Internet Information Server), Application-Server,
Content-Management-Server, Datenbank-Server (Oracle, MySQL). Auf der Anwenderseite, also bei Studierenden und Lehrenden, soll der Zugriff auf die E-LearningPlattform plattformunabhängig über das Internet möglich sein. Eine Möglichkeit ist
hier, die für jedes System existierenden Webbrowser (Internet Explorer, Firefox, Opera etc.) zu nutzen. Diese Art von Clients kann jedoch keine speziellen Funktionen für
die Benutzung der E-Learning-Plattform realisieren, sie stellen nur ein Interface für
den Zugriff auf den Server dar. Ohne Online-Verbindung ist daher kein Arbeiten an
der E-Learning-Plattform möglich. Die Client-Software sollte keine Anforderungen an
sonstige installierte Programme stellen, sondern alle benötigten Komponenten enthalten.
Effizenz und Skalierbarkeit
Eine E-Learning-Plattform muss in vielerlei Hinsicht skalierbar sein. Zum einen in Bezug auf den eingesetzten Rahmen, d.h. sie soll sowohl innerhalb einer Arbeitsgruppe
als auch für die gesamte Hochschule eingesetzt werden können. Hieraus ergibt sich,
dass die Anzahl der Anwender, die auf eine E-Learning-Plattform zugreifen, mehrere tausend Personen betragen kann. Zum anderen kann die Anzahl der in der Plattform
59
abgelegten Lerneinheiten und damit die zu verwaltende Datenmenge sehr groß werden,
vorausgesetzt die Plattform wird für die gesamte Hochschule eingesetzt. Daher muss
die E-Learning-Plattform entsprechend effizient arbeiten, und es muss möglich sein,
die Speicherorte der Lerneinheiten auf eine Vielzahl von Rechnern verteilen zu können
(Clustering). Ein weiteres wichtiges Kriterium ist die Modularität einer E-LearningPlattform. Wahrscheinlich wird nur in seltenen Fällen der gesamte Funktionsumfang
einer E-Learning-Plattform an einer Hochschule benötigt werden. Häufig bieten die ELearning-Plattformen neben der Verwaltung der Lehrmaterialien auch die Möglichkeit,
Übungen, Diskussionsgruppen oder sonstige im Betrieb einer Hochschule anfallenden
Aufgaben zu realisieren. Eine skalierbare Lösung könnte hier folgendermaßen aussehen: Zur Einführung wird nur mit einer geringen Menge an Basismodulen gearbeitet,
die grundlegenden Funktionalitäten bereitstellen. In späteren Ausbauphasen können
dem System weitere Module für für z.B. Kommunikations- oder Evaluationsfunktionalitäten hinzugefügt werden. Ein solcher modularer Aufbau ermöglicht einen schrittweisen und bedarfsgerechten Einsatz innerhalb einer Hochschule, wobei sich Kosten
für den Einsatz einer E-Learning-Plattform nach der Anzahl der eingesetzten Module
richten können.
Zukunftsfähigkeit und Erweiterbarkeit
Da sich sowohl Basistechnologien, wie Betriebssysteme, Netzwerkinfrastrukturen oder
Datenbanken, als auch Medientechnologien und auch generelle Anforderungen einer
Hochschule an eine E-Learning-Plattform ändern können, ist es notwendig, dass die ELearning-Plattform ein Konzept bietet, weitere Komponenten zu integrieren. So kann
sichergestellt werden, dass die E-Learning-Plattform flexibel anpassbar und erweiterbar ist. Damit kann die Zukunftsfähigkeit und der Einsatz gesichert werden. In diesem
Zusammenhang muss bei der Auswahl der E-Learning-Plattform für eine Hochschule auch darauf geachtet werden, dass ein Hersteller ausgewählt wird, der langfristigen
Support und Updates anbietet.
Integration mit existierenden Diensten
Eine E-Learning-Plattform muss nicht alle im Zusammenhang mit der Hochschullehre
anfallenden Funktionalitäten realisieren. Vielmehr sollte die Möglichkeit der Integration mit bestehenden Systemen berücksichtigt werden, um einen reibungslosen Ablauf
der Lehrprozesse gewährleisten zu können. Solche Integrationspunkte sind beispielsweise die Zusammenarbeit mit Informations- und Verwaltungssystemen der Hochschule. Auch wäre der parallele Einsatz verschiedener E-Learning-Produkte an einer Hochschule denkbar. Für eine Kooperation mit anderen Systemen ist die Verwendung einer
standardisierten Middleware stark von Vorteil. Beim Austausch mit anderen Systemen
sollte die Plattform in der Lage sein, möglichst viele verschiedene Formate zu importieren. Eine Exportmöglichkeit für Lehrmaterial und administrative Daten sollte ebenso bestehen, um anderen Systemen das Übernehmen von in der E-Learning-Plattform
vorhandenen Daten zu ermöglichen.
Wiederverwendbarkeit
In einer E-Learning-Plattform erstellte Inhalte und andere Daten sollen in der Regel wiederverwendet werden können. Zur Steigerung der Interoperabilität zwischen
verschiedenen E-Learning-Systemen sollten Standards verwendet werden. Dabei sind
nicht nur Standards für die Kategorisierung und Beschreibung der Inhalte von Bedeutung. Auch andere Bereiche innerhalb einer Hochschule können aus dem Einsatz von Standards profitieren. Beispielsweise können Standards für die Ablage von
Studierenden-Datensätze verwendet werden, um den Austausch dieser Daten zwischen
verschiedenen System zu ermöglichen. Dadurch wird erreicht, dass die Studierendeninformationen nicht in einem proprietären Format abgelegt werden können, so dass diese
Daten zwischen verschiedenen Institutionen ausgetauscht werden können, wenn z.B.
Studierende die Hochschule wechseln wollen. Für E-Learning-Systeme existieren verschiedene Initiativen zur Entwicklung von Standards, die beschreiben, welchen Inhalt
Materialien haben, in welchen Datenformaten diese Einheiten abgelegt sind, wie sie
kombiniert und angeordnet sind. Beispiele sind IEEE ([IEE]), Global Learning Consortium ([GLC]) und ADL Scorm ([ADL04]). Eine E-Learning-Plattform, die diese
Standards unterstützt, stellt sicher, dass eine große Menge von verfügbaren Materialien problemlos und ohne Informationsverluste in die Plattform übernommen werden
können. Gleichzeitig wird einem „Verfall“ der Daten vorgebeugt, da auch der Export
in andere Systeme durch diese Standards ermöglicht wird.
Benutzerfreundlichkeit
Die Bedienung der E-Learning-Plattform sollte sich sowohl für den Studierenden als
auch für den Lehrenden möglichst benutzerfreundlich und intuitiv gestalten. Da es ein
grundlegendes Ziel der E-Learning-Plattform ist, Lehrinhalte zu verwalten, ist es vor
allem wichtig, dass die Anwender für sie relevante Informationen schnell finden können, dass die Navigation übersichtlich und nachvollziehbar ist und dass die typischen
Arbeitsabläufe gut unterstützt werden. Funktionen, die die Benutzerfreundlichkeit wesentlich beeinflussen, sind die Möglichkeit zum Einrichten/Anpassen personalisierter
Startseiten und das Vorhandensein einer durchgehenden Authentifizierung. Das bedeutet, dass der Benutzer ausgehend von seiner Identifikation gegenüber der E-LearningPlattform aus sämtliche angebotenen Dienste nutzen kann, wobei die Plattform die notwendigen Rechte und Authentifizierungen gegenüber externen Systemen (z.B. Bibliothekssystem) intern verwaltet, ohne dass der Benutzer erneut Passwörter etc. angeben
muss. Insgesamt ist ein positiver subjektiver Eindruck der Benutzer ein entscheidendes
Kriterium, um eine hohe Akzeptanz der E-Learning-Plattform bei Studierenden und
Lehrenden zu erreichen.
3.4. FAZIT UND HANDLUNGSEMPFEHLUNG
61
3.4 Fazit und Handlungsempfehlung
Zu Beginn dieser Ausarbeitung wurde die junge Disziplin des Web Engineering vorgestellt, die nach [KPR03] aufgrund der großen Technologievielfalt und der Änderungsdynamik des World Wide Web heraus geboren wurde. Die Disziplin Web Engineering
sieht unter anderem eine systematische Entwicklung von Web Anwendungen in Form
von Phasen vor. Die Phase der Web-Anforderungsanalyse spielt dabei eine besondere
Rolle, da sie bedeutende Auswirkungen auf alle folgenden Phasen wie beispielsweise
den Entwurf und die Implementation hat. Gerade im Umfeld von Web-Anwendungen
spielen die Anforderungen für die Qualität eben solcher Systeme eine entscheidende
Rolle. Werden bereits zu Beginn der Entwicklung eines Web-Systems Anforderungen unklar spezifiziert oder fehlerhaft beziehungsweise unvollständig ausgearbeitet,
so wird im schlimmsten Fall ein völlig falsches System entwickelt. Einige Umfragen
zeigen, dass viele Projekte im Web-Umfeld aufgrund unklarer Anforderungen scheiterten. Aus diesem Grund wurde in dieser Ausarbeitung diese Phase im Kontext eines
E-Learning-Systems für Hochschulen im speziellen beleuchtet, insbesondere wurden
die funktionalen und nicht-funktionalen Anforderungen an ein solches System erarbeitet.
Für die Aufnahme und Modellierung von funktionalen Anforderungen bietet die „Unified Modeling Language“ (UML) einige hervorragende Ansätze, von denen das Anwendungsfalldiagramm für die Modellierung der funktionalen Anforderungen an eine E-Learning-Plattform in dieser Arbeit ausgewählt wurde. Da in der Praxis aber
die nicht-funktionalen Anforderungen im Vergleich zu den funktionalen Anforderungen oftmals in den Hintergrund rücken, wurden im Abschnitt 3.3 auch die nichtfunktionalen Anforderungen an eine E-Learning-Plattform erörtert, wobei vor allem
qualitative Aspekte angesprochen wurden. Die nicht-funktionalen Anforderungen betreffen unter anderen auch die Realisierung (Programmiersprachen, Datenbankverwaltungssysteme, Schnittstellen, etc.), Einführung (Dokumentation, Schulung, etc.) sowie
das Projektmanagament (Vorgehensmodelle, Termine, etc.).
Da die in der Praxis oft auch bei recht überschaubaren Projekten zum Einsatz
kommende Ad-hoc Entwicklung langfristig immer zu Problemen führt, lautet meine Empfehlung an den Leser daher, der Anforderungsanalyse bei der Entwicklung
von Web-Anwendungen besondere Aufmerksamkeit zu schenken. Im Kontext der ELearning-Systeme gilt dies nicht nur für die Entwicklung von sehr komplexen Systemen für Hochschulen, sondern auch für Bildungseinrichtungen wie beispielsweise Berufsschulen. Für die Aufnahme der Anforderungen stehen mittlerweile zahlreiche ausgereifte Software-Werkzeuge wie Together (http://www.togethersoft.com),
Poseidon (http://www.gentleware.com) oder Visual Paradigm (http://www.visualparadigm.com) zur Verfügung, die eine komfortable Durchführung der Anforderungsanalyse ermöglichen und damit den Grundstein für eine erfolgreiche Durchführung
aller folgenden Phasen der Websystementwicklung bilden.
Kapitel 4
Vorgehensmodelle für
dokumentenbasierte
Web-Anwendungen
Markus Fromme
Inhalt
4.1
4.2
4.3
4.4
4.5
4.6
Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . .
Vorgehensmodelle . . . . . . . . . . . . . . . . . . . . .
Klassische Vorgehensmodelle . . . . . . . . . . . . . . . .
Vorüberlegungen zum Entwurf einer Web-Anwendung . . .
Vorgehensmodelle zur Entwicklung von Web-Anwendungen
Strukturierter Hypermedia-Entwurf . . . . . . . . . . .
Hypertext Design Model . . . . . . . . . . . . . . . . . . .
Relationship Management Methodology . . . . . . . . . .
Beispiel für RMM . . . . . . . . . . . . . . . . . . . . .
Problembeschreibung . . . . . . . . . . . . . . . . . . . .
Entwicklung anhand der RM-Methodologie . . . . . . . . .
Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Vorgehensmodelle . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
63
64
64
66
66
69
69
72
75
75
76
78
79
4.1 Einleitung
Unter Web-Systemen versteht man Softwaresysteme, die auf der Grundlage von WebTechnologien, also auf dem Internet basierenden Methoden und Verfahren, implementiert und im World Wide Web genutzt werden. Die hohe Komplexität dieser Anwendungen verlangt nach einem geordneten und organisierten Entwicklungsprozess und
nicht - wie es häufig in der Praxis zu finden ist - nach einem pragmatischen Vorgehen,
63
64
KAPITEL 4. VORGEHENSMODELLE FÜR WEB-ANWENDUNGEN
das zwar schnelle Ergebnisse liefert, aber aufgrund daraus resultierender Qualitätsmängel oft zu Problemen im Betrieb und Wartung von Systemen führt.
Das so genannte Web-Engineering beschäftigt sich mit der methodenbasierten Entwicklung und Wartung von webbasierten Softwaresystemen und verfolgt das Ziel, Prozesse für die Entwicklung von Web-Anwendungen zu erarbeiten. Dabei konzentriert
man sich hauptsächlich auf die Anpassung traditioneller Entwicklungsprozesse an die
Anforderungen von Web-Systemen, was allerdings sehr schwierig ist.
Da beispielsweise das Internet als internationaler Marktplatz für die Veröffentlichung
von Produkten fungiert, herrscht in Bezug auf die Entwicklung von Webseiten ein enormer Konkurrenzdruck, so dass Web-Systeme in einer sehr kurzen Zeit entwickelt werden müssen und folglich nur ein geringer Spielraum für systematische Entwicklungsprozesse zur Verfügung steht. Es kommt hinzu, dass sich, wie auch bei der ’normalen’
Softwareentwicklung, die Anforderungen an das zu entwickelnde System oft erst im
späteren Verlauf des Entwicklungsprozesses herausstellen. Web-Systeme unterscheiden sich allerdings auch in diesem Punkt von herkömmlicher Software, da sie wesentlich stärkeren inhaltlichen als auch technischen Veränderungen unterliegen. Neue
Anforderungen, die sich z.B. durch eine Marktveränderung ergeben, müssen schnell
eingearbeitet werden, so dass eine präzise Definition aller Anforderungen unmöglich
ist. Weiterhin muss der Kunde stärker in den eigentlichen Entwicklungsprozess einer
Web-Anwendung integriert werden, da dieser sowohl für die Beantwortung von Unklarheiten bei der Anforderungsdefinition als auch für die spätere Pflege des Systems
(z.B. der Inhalte) verantwortlich ist, und somit mit dem System vertraut sein muss.
Allein durch diese Tatsache ist eine Erarbeitung von Prototypen im eigentlichen Entwicklungsprozess zwingend erforderlich. Es kommt hinzu, dass Web-Anwendungen
meistens keine kritischen Anwendungen sind und somit der Schwerpunkt der Qualitätssicherung auf dem Inhalt und der Wartbarkeit des zu entwickelnden Systems liegt
[ELW03].
Diese Ausarbeitung wurde im Rahmen des Seminars ’Web-Engineering’ an der Universität Oldenburg erstellt und beschäftigt sich mit der Vorstellung möglicher Vorgehensmodelle und deren Methoden zur Entwicklung einer dokumentenbasierten WebAnwendung. Dabei wird ein vorgestelltes Verfahren anhand eines Beispiels aus dem
Bereich des E-Learnings vertieft.
4.2 Vorgehensmodelle
Klassische Vorgehensmodelle innerhalb der Softwareentwicklung
Bei einem Vorgehensmodell handelt es sich ”um eine abstrakte Darstellung eines
Softwareprozesses” (vgl. [Som01]), die vorgibt, in welcher Reihenfolge bestimmte
Aktivitäten innerhalb der Softwareentwicklung durchgeführt werden sollten.
4.2. VORGEHENSMODELLE
65
Sequentielles Vorgehensmodell
Das sequentielle Vorgehensmodell orientiert sich an einer Vorphase und den folgenden
vier Grundphasen: Analyse, Entwurf, Realisierung und Einführung. Die Vorphase dient
zur Projektbegründung, Definition eines Projektauftrages und zur groben Entwicklung
von Zielvorstellungen und dem Nutzenpotenzial des zu entwickelnden Systems. In der
Analyse-Phase wird zuerst in einer so genannten Ist-Analyse der aktuelle Zustand des
Systems erhoben und auf Schwachstellen hin analysiert. Anschließend kommt es zur
Entwicklung eines Soll-Konzepts, bei dem die Wünsche der späteren Anwender und
die Schwächen des aktuellen Systems zu einem Fachentwurf aufgestellt werden, d.h.
der Leistungsumfang des neuen Anwendungssystems wird festgelegt. Zum Abschluss
der Analyse-Phase werden Wirtschaftlichkeitsanalysen durchgeführt, um zu prüfen, ob
das neue System einen wirtschaftlichen Nutzen mit sich bringt. In der Entwurfs-Phase
wird aus dem Soll-Konzept der eigentliche Systementwurf abgeleitet, der als Grundlage für die eigentliche Programmspezifikation und somit auch für den eigentlichen
Programmentwurf dient. In der Realisierungs-Phase wird der erarbeitete Programmentwurf implementiert und anschließend getestet. Die Systementwicklung wird mit der
Einführung des neues Systems abgeschlossen, wobei diese mit vielen organisatorischen
Aktivitäten wie z.B. der Dokumentation des Systems, der Schulung der Anwender und
der Übergabe des finalen Produktes an den Auftraggeber verbunden ist [SH99]. Ein
bekanntes Beispiel für ein sequentielles Phasenmodell ist das Wasserfall-Modell (vgl.
Abbildung ”Wasserfall-Modell”[Bre03] auf Seite 79).
Andere Vorgehensmodelle
Neben dem sequentiellen Phasenmodell existieren noch weitere Modelle, die zur Entwicklung einer Software verwendet werden können und hier kurz vorgestellt werden
sollen (vgl. [Bol98]).
• Iteriertes Phasenmodell: Bei diesem Modell handelt es sich um eine Erweiterung
des sequentiellen Phasenmodells, bei dem Rücksprünge von einer späteren Phase
in eine frühere Phase möglich sind, um z.B. auf Designfehler oder Änderungen
in der Anforderungsdefinition reagieren zu können.
• Evolutionäre Softwareentwicklung: Hierbei handelt es sich um das so genannte
”Prototyping”, einem Vorgehensmodell in dem das zu erstellende Softwareprodukt nicht mehr in einem linearer Prozess erstellt wird. Die Software wird vielmehr in einer Folge von mehreren Entwicklungszyklen implementiert, wobei am
Ende eines jeden Zyklus eine verbesserte Version des Produktes vorliegt.
• Transformationelle Softwareentwicklung: Dieses Modell stellt ein theoretisches
Verfahren dar, in dem formal zu spezifizierende Produktdefinitionen mit Hilfe
regelbasierter Systeme automatisch in Software-Systeme transformiert werden.
• Spiralmodell: Das Spiralmodell (vgl. Abbildung ”Spiralmodell”[Bre03] auf Seite 80) wird in der Softwareentwicklung auch als inkrementelles oder interaktives Vorgehensmodell bezeichnet. Es ist eine Weiterentwicklung des WasserfallModells, wobei die Phasen mehrfach durchlaufen werden. Das Spiralmodell
66
fasst den Entwicklungsprozess als iterativen Prozess auf, wobei jeder Zyklus folgende Aktivitäten enthält: a) Festlegung von Zielen, Alternativen und Rahmenbedingungen, b) Evaluierung der Alternativen, Erkennen und Reduzieren von
Risiken, c) Realisierung und Überprüfung des Zwischenprodukts und d) Planung
der Projektfortsetzung.
Vorüberlegungen zum Entwurf einer Web-Anwendung
Die Komplexität einer Web-Anwendung verlangt es, dass man sich bereits vor dem eigentlichen Entwicklungsprozess intensiv mit dem Entwurf der Anwendung beschäftigt
und bestimmte Vorüberlegungen durchführt. So muss z.B. die Zielgruppe der Anwendung klar definiert sein. Dies ist notwendig, um z.B. das Layout und den Inhalt der
Web-Anwendung auf die Nationalität und die Sprache des Benutzers auszulegen. Dabei müssen aber ebenso soziale und kulturelle Hintergründe als auch das Alter und das
Geschlecht der Zielgruppe berücksichtigt werden. Es muss eindeutig definiert sein, ob
es sich bei einem Anwender um einen Anfänger, der klare Strukturen und einen einfachen Zugriff bevorzugt, oder um einen Experten, der möglichst schnell und gezielt auf
Informationen zugreifen möchte, handelt. Gleichzeitig muss sich der Web-Entwickler
vor Augen halten, welche Voraussetzungen er an den Standardbenutzer des Systems
stellen kann. Dies bezieht sich z.B. auf die Systemplattform als auch auf den eingesetzten Browser des Anwenders. Des Weiteren sollte man sich schon im Vorfeld Gedanken
über die Inhalte der Web-Anwendung und deren Darstellung machen. Es muss klar
sein, welchen Sinn und Zweck das Web-System erfüllen muss. So muss z.B. entschieden werden, ob es sich bei der zu entwickelnden Anwendung um eine Konsumer-Site
handelt, die den Anwender zum Kauf eines Produktes anregt, oder ob die neue Anwendung vielmehr eine Info-Site repräsentiert, die dem Anwender einen schnellen Zugriff
auf Informationen ermöglicht. Ein weiterer wichtiger Punkt, der bei einer Vorüberlegung zur Entwicklung einer Web-Anwendung beachtet werden muss, ist das Einhalten
von Copyright-Bestimmungen und anderen gesetzlichen Vorschriften. Dabei muss geprüft werden, ob die auf dem Web-Seiten dargestellten Inhalte einem Copyright unterliegen, und ob der Inhalt der Web-Anwendung gegen geltendes Recht verstößt [Bol98].
Vorgehensmodelle zur Entwicklung von Web-Anwendungen
Vorgehensmodell nach Dumke
Multimediale Systeme, dazu zählen auch dokumentenbasierte Web-Anwendungen, erfordern nach Dumke (vgl. [DLWZ03]) aufgrund ihrer besonderen Anforderungen einen
schrittweisen Entwurf, der nun beschrieben werden soll (vgl. Abbildung ”Vorgehensmodell nach Dumke” auf Seite 67).
Der Entwicklungsprozess einer Web-Anwendung beginnt mit einer Vorphase, in der
ein so genanntes Briefing stattfindet, um das Thema und die Problematik des zu entwickelnden Systems kurz zu beschreiben. Es folgt die Phase des Rohkonzepts, in der
etappenweise Inhalte, Visualisierungsformen, Programmierungsdetails und technische
Anforderungen festgelegt und in einer Abschlussdokumentation festgehalten werden.
Die anschließende Phase der Präproduktion verfolgt das Ziel, einen Prototypen zu im-
67
plementieren, benötigte Schnittstellen festzulegen, ein Konzept für die Interaktivität
zu erarbeiten und ein Storyboard für die Web-Anwendung zu definieren. Es folgt eine
Produktions-Phase, in der die multimedialen Inhalte wie z.B. Grafiken, Animationen
und Texte erstellt werden. Das eigentliche Zusammenstellen und Testen der Komponenten geschieht in einer eigens dafür vorgesehen Assemblage-Phase, wobei daraus
resultierenden Systeme in einer so genannten Mastering-Phase archiviert und in einer
anschließenden Replikationsphase nochmals komplett getestet werden.
Vorphase
Rohkonzept
Produktion
Preproduktion
Mastering
Assemblage
Replikation
Abbildung 4.1: Vorgehensmodell nach Dumke
Vorgehensmodell nach Boles
Das Vorgehensmodell des Multimedia-Softwareengineerings nach Boles (vgl. [Bol98])
basiert ebenfalls auf einer schrittweisen Entwicklung und ähnelt stark dem Modell von
Dumke, weist allerdings auch an wichtigen Stellen fundamentale Unterschiede auf.
Boles begründet das Vorgehensmodell genauso wie Dumke mit den besonderen Anforderungen und Merkmalen multimedialer Systeme. Dabei legt er den Schwerpunkt
auf die Interdisziplinarität der Entwicklergruppen und den künstlerischen, psychologischen, didaktischen und ergonomischen Aspekten, die neben den eigentlichen programmiertechnischen Tätigkeiten im Entwicklungsprozess existieren. Insgesamt besteht das Vorgehensmodell aus folgenden Phasen (vgl. Abbildung ”Vorgehensmodell
nach Boles” auf Seite 69):
• Analyse: In dieser Phase sollen Ideen gesammelt und das Umfeld der WebAnwendung abgegrenzt werden. Insgesamt beginnt die Phase mit der Klärung
von grundsätzlichen Fragen: Was soll mit dem Projekt erreicht werden? Welche
Dimension soll das Projekt annehmen? Handelt es sich um eine Neuentwicklung
oder um eine Erweiterung bereits existierender Produkte? Es erfolgt hierbei eine
Bedarfsanalyse, in der geklärt werden muss, welche Risiken existieren, und ob
Bedarf an dem zu entwickelnden Produkt besteht bzw. wie die allgemeine Marktsituation innerhalb der Anwendungsdomäne des neuen Produktes zu bewerten
ist. Weiterhin wird eine Zielgruppenanalyse durchgeführt, in der eine Beschreibung des typischen Systemanwenders erarbeitet wird. Als ein weiterer Schritt
in der Analysephase wird der Mehrwert der Anwendung bestimmt, d.h. es wird
erarbeitet, in welchen Punkten sich das zu entwickelnde Produkt von bereits auf
dem Markt existierenden Systemen unterscheidet und Vorteile besitzt.
• Definition: In dieser Phase soll ein präzise definierter Anforderungskatalog erarbeitet werden, in dem beschrieben wird, was das zu realisierende System
68
leisten soll, ohne dabei auf die technische Realisierung einzugehen. Meistens
werden hierbei folgende Aspekte berücksichtigt: Funktionalität, Performance,
Realisierungszwänge, Portabilität, Sicherheit, Korrektheit und Schnittstellen.
Weitere Realisierungsanforderungen wie Kosten, Entwicklungszeit, Informationsquellen, anfallende Dokumentationen, Meilensteinplan oder Qualitätssicherungsmaßnahmen können ebenfalls in den Anforderungskatalog aufgenommen
werden.
• Entwurf: Das Ziel dieser Phase ist die Strukturierung der Inhalte. Dazu muss z.B.
ein Informationsdesign erarbeitet werden, welches die zu präsentierenden Informationen angibt und festlegt, wie und mit welchen Mitteln diese dargestellt werden. Des Weiteren muss das Gestaltungsdesign definiert werden, d.h. das Aussehen der Anwendung wird beschrieben. Dazu wird ein so genannter Style-Guide
entwickelt, in dem Standardelemente wie z.B. Navigationsboxen und Headlines
definiert werden, die bei allen folgenden Entwicklungen und Arbeiten einzuhalten und zu berücksichtigen sind, um ein einheitliches und konsistentes Design zu
gewährleisten. Zusätzlich muss in einem didaktischen Konzept definiert werden,
wie sich der Inhalt der Web-Anwendung präsentieren soll, d.h. ob der Inhalt lediglich angezeigt werden soll oder ob sich der Anwender den Inhalt ”erarbeiten”
muss. Es wird dabei auch geklärt, wie weit sich die eigentliche Nutzung des Systems konfigurieren lässt. Zum Ende der Entwurfsphase muss noch ein Medien-,
Struktur- und Interaktionsdesign entwickelt werden, um die Strukturierung der
Inhalte zu beschreiben und anzugeben, wie der Anwender auf diese zugreifen
kann.
• Medienproduktion und -akquisition: In dieser Phase wird eine Materialrecherche durchgeführt, wobei überprüft wird, welche Materialien bereits existieren
und welche noch im Rahmen der Produktion des Web-Systems erstellt werden
müssen. Besonderes Augenmerk liegt dabei auf der Berücksichtigung von Copyrights.
• Implementierung: Parallel zur Medienproduktion/-akquisition wird mit der Implementierung des Systems begonnen, d.h. das System wird bereits programmiert, bevor alle benötigten Medien verfügbar sind. Damit das System später
auch erweiterbar ist, konzentriert sich die Programmierung neben der Entwicklung grundlegender Technologien auf die Erstellung von so genannten Templates, die dann später als Vorlage für die eigentliche Erstellung der WebAnwendung dienen.
• Test: Bereits während der Implementierung finden Tests auf inhaltlicher und
funktionaler Ebene statt. Sobald separat entwickelte Komponenten miteinander
kombiniert werden, muss ein Integrationstest durchgeführt werden, mit dem sichergestellt wird, dass die verbundenen Komponenten korrekt miteinander arbeiten. Als finaler Test bietet sich ein Systemtest an, der sicherstellt, dass das
komplette System korrekt arbeitet und alle Anforderungen erfüllt.
• Installation: In dieser Phase beginnt die Konfiguration der Hard- und Software
sowie die Produktion der Auslieferungsmedien (z.B. von CD’s). Reine OnlineAngebote werden in dieser Phase freigeschaltet. Weiterhin wird der Service und
der Support für die neu erstellten Produkte aktiviert und es wird aktiv Werbung
betrieben.
4.3. STRUKTURIERTER HYPERMEDIA-ENTWURF
69
• Evaluation: Diese Phase schließt das Vorgehensmodell ab und beinhaltet eine Bewertung des neu erstellten Web-Systems durch Nutzer, Psychologen,
Software-Ergonomen und Pädagogen. Gefundene Schwächen können in Form
des Prototyping verbessert werden.
Analyse
Definition
Medienproduktion
Entwurf
Implementierung
Installation
Test
Evaluation
Abbildung 4.2: Vorgehensmodell nach Boles
4.3 Strukturierter Hypermedia-Entwurf
Durch die objektorientierte Programmierung (OOP) gewannen immer mehr Entwicklungsstrategien und -werkzeuge an Bedeutung und hatten direkten Einfluss auf die Entwicklung von Web-Anwendungen, so dass verschiedene Vorgehensmodelle und Methoden in diesem Bereich entstanden. Während Vorgehensmodelle einen Lebenszyklus
eines Software-Systems in Form von Aktivitäten beschreiben, stellen Methoden eine
Vorschrift zur Durchführung dieser Aktivitäten und zur Repräsentation der daraus resultierenden Ergebnisse dar.
Hypertext Design Model
Das Hypertext Design Model (HDM) (vgl. [DLWZ03]) basiert auf der strukturellen
Entwicklung dokumentennorientierter Web-Systeme und unterstützt den Entwurf dieser Systeme auf zwei Ebenen:
• Entwurf der allgemeinen Nutzungsorganisation des Web-Systems bezüglich der
anwendungsbezogenen Navigationsformen, d.h. Entwicklung der erforderlichen
Navigationsstrukturen. Diese Entwicklungsform wird auch als ”authoring-inthe-large” bezeichnet.
• Entwurf der technologischen Details der im Web-System integrierten Dokumente und ihrer strukturellen Verbindungsformen, d.h Bereitstellung und Entwicklung der zugehörigen Dokumente - auch ”authoring-in-the-small” genannt.
Das HDM stellt ein Objektmodell für hierarchisch strukturierte Einheiten zur Verfügung, wobei die Modellierungstechnik stark der ER-Technik ähnelt und zusätzliche
70
strukturierende und hierarchische Einheiten enthält. Die hier vorgestellten Strukturelemente sollen anhand eines kurzen Beispiels erläutert werden, welches auf der
Abbildung ”Beispiel einer Web-Struktur”, Seite 70, basiert.
Firmen-Homepage
incl. Firmenname,
Adresse, Kontaktinfos
-----------------
Produktinfos
-----------------
-----------------
--------------------------------Bezeichnungen
Kundenwertung
Bestellservice
-----------------
Bestellauslösung
-----------------
-----------------
Beschreibung
Bestellinfos
Ranking
Bestellform
Bemerkungen
----------------Preisregelung
Abbildung 4.3: Beispiel einer Web-Struktur
Im Bereich der Dokumentenbeschreibung (authoring-in-the-small) unterscheidet man
im HDM zwischen folgenden Strukturelementen:
• Slot: Hierbei handelt es sich um eine atomare Einheit einer Informationsdarstellung. Slots können hierbei von einem einfachen Typen (z.B. Integer) oder
sogar von einem komplexen Typ (z.B. ein Video oder ein PDF-Dokument) abgeleitet sein. Bezüglich einer Web-Anwendung stellen Slots die inhaltsbezogenen
Grundkomponenten dar. Auf Webseiten könnten dies z.B. Adressangaben oder
E-Mail-Referenzen sein. Komplexere Typen können oft in Form von Produktbeschreibungen gefunden werden.
• Frame: Diese Strukturform bildet eine Aggregation von Slots als themenbezogene Präsentationseinheit. Frames entsprechen dabei nicht unbedingt einer Webseite, sondern werden vielmehr aus inhaltlicher Sicht konzipiert. Als gutes Beispiel
ließe sich hier der Kontaktinformationsteil einer Homepage nennen.
71
• Node: Ein Knoten (engl. ”node”) bildet eine Navigationseinheit, auf die in unterschiedlicher Weise (intern oder extern1 ) referenziert werden kann, wobei sich unterschiedliche Referenzierungsformen im so genannten ”node type” ausdrücken.
• Component: Werden Knoten, die eine logische Einheit bilden, zu einer Gruppe
zusammengefasst, spricht man von einer Komponente (engl. ”component”). Jede
Komponente besitzt einen ”component type”, der einfache Knoten, dynamische
Elemente und Verbindungskomponenten unterscheidet, d.h. Komponenten mit
gleichartigen Knoten und Verbindungen sind dabei vom gleichen Komponententyp. In Bezug auf Webseiten ist der Bestellservice oft eine Komponente, da sich
diese oft aus einer Bestellform, Bestellinformationen und einer Bestellauslösung
zusammensetzt.
Betrachtet man nun die Web-Struktur in ihrem Gesamtkontext (authoring-in-the-large),
lassen sich die semantischen Navigationsverläufe durch folgende Strukturelemente
modellieren:
• Entity: Hierbei werden Komponenten zu einer Gruppe zusammengefasst, die inhaltlich einem realen Objekt entsprechen. In Bezug auf Webseiten stellt eine
Bestellauslösung eine Entity dar, da sie in der Realität einem Bestellformular
entsprechen würde.
• Collection: Bei einer Kollektion (engl. ”Collection”) werden reale Objekte thematisch zu einer Menge zusammengefasst. Auf Webseiten bilden häufig Bezeichnungslisten der Produktbeschreibungen eine solche Kollektion.
• Link: Ein Link beschreibt eine Verbindung zwischen zwei unterschiedlichen Objekten, die eine Entity, eine Komponente, ein Knoten oder eine Kollektion sein
können. So genannte ”Structural links” beschreiben dabei die Verbindung von
Strukturelementen, die eine inhaltliche Verlaufsform hinsichtlich der konzipierten Navigationsstrukturen modellieren. ”Index links” beschreiben die Verlaufsform innerhalb von Kollektionen und so genannte ”Guided tour links” modellieren lineare oder zyklische Sequenzen aus Kollektionsmitgliedern, um z.B. dem
Besucher einer Webseite eine spezielle Übersicht über die Produktpalette eines
Unternehmens zu gewähren.
• Applicative scheme: Diese Strukturform verbindet zwei Objekte zu einer anwendungsbezogenen (semantischen) Einheit. Webseiten, die z.B. eine unmittelbare
Verbindung einer Produktbeschreibung mit einer Bestellauslösung realisieren,
wenden dieses Schema an.
Mit dem Hypertext Design Model wird ein struktureller Entwurf realisiert, der ein abstraktes Gebilde aus Knoten und Kanten darstellt, welches zur Implementation der eigentlichen Anwendung auf das Zielsystem abgebildet werden muss. Mit einer so genannten ”Browsing semantic”, die auf das Zielsystem abgestimmt sein muss, wird das
in HDM erstellte Gebilde in eine lauffähige Anwendung übersetzt, wobei man mit verschiedenen ”Browsing semantics” verschiedene Versionen einer Anwendung erstellen
kann, die sich durch die visuellen Möglichkeiten und das Ablaufverhalten des verwendeten Systems unterscheiden.
1 in
Bezug auf Webseiten
72
Das Hypertext Design Model trägt zur Kommunikationsverbesserung zwischen Benutzer, Analytiker, Systemdesigner und Implementierer bei. Bestehende Anwendungen
können auf Design-Methoden und Stilarten hin untersucht werden, ohne dabei Kenntnis über den Inhalt der Anwendung zu haben. Außerdem kann das Grundgerüst einer
Anwendung anhand der Strukturierungssprache auf eine andere Anwendung übertragen werden. Strukturelle Unstimmigkeiten und Fehler bei der Erstellung einer Anwendung können durch HDM vermieden werden. Weiterhin wird der Entwurfsprozess vereinfacht, da die Abstraktionsebene beim strukturellen Aufbau näher an die Anwendung
heranreicht als die Ebene der Implementierung [Bol98].
Relationship Management Methodology
Die Relationship Management Methodology (RMM) ist ein plattform-unabhängiges Modell zur Entwicklung webbasierter hypermedialer Anwendungen, welches
sich aus den folgenden sieben Entwicklungsphasen zusammensetzt (vgl. [Bol98]):
E-R-Design, Entity-Design, Navigations-Design, Konvertierungsprotokoll-Design,
Benutzerschnittstellen-Design, Laufzeitverhalten-Design und Implementierung.
Diesen sieben Phasen sind drei weitere Phasen vorangestellt, die zwar im Bereich
der Softwareentwicklung eine große Rolle spielen, aber vom RMM-Modell nicht
weiter unterstützt werden. Dabei handelt es sich um die Phasen Machbarkeitsanalyse,
Anforderungsanalyse und Systemauswahl. Der Implementierungsphase schließt sich
eine weitere, von RMM nicht direkt integrierte, Test- und Evaluationsphase an. Die
Abbildung ”Phasen des RMM-Modells” auf Seite 73 beschreibt die einzelnen Phasen,
deren Zusammenhänge und Endprodukte.
Symbole des RMM-Modells
Die RM-Methodologie stellt über das Relationship-Management-Datenmodell
(RMDM) eine grafische Notation zur Strukturierung von Hypermedia-Anwendungen
zur Verfügung, mit der auch Navigationsverläufe dargestellt werden können. RMDM
basiert dabei auf dem Entity-Relationship-Modell und besitzt eine eigene Notation, die
aus insgesamt elf Symbolen besteht und in drei Klassen eingeteilt werden kann (siehe
Abbildung ”Grundsymbole des RMM-Modells” auf Seite 74):
• E-R-Struktur-Primitive: Diese Klasse stellt Symbole zur Verfügung, die zur Modellierung der Struktur des Anwendungsgebietes hypermedialer Anwendungen
dienen. Man benutzt hierbei Entitäten, die abstrakte und physikalische Objektklassen repräsentieren, feste Eigenschaften (Attribute) besitzen und untereinander in Beziehungen (Assoziationen/Relationen) stehen können. Diese definierten
Beziehungen lassen sich in eins-zu-eins, eins-zu-viele und viele-zu-viele Beziehungen unterscheiden, wobei letztere in zwei eins-zu-viele Beziehungen aufgeteilt werden müssen.
• RMD-Struktur-Primitive: In diese Klasse fallen die so genannten Sichten (engl.
”slices”), die zur Gruppierung von Attributen einer Entität dienen. Alle Attribute
73
Abbildung 4.4: Phasen des RMM-Modells
einer Entität, die gleichzeitig präsentiert werden sollen, müssen einer Sicht zugeordnet werden. Die Einteilung von Attributen in Sichten bietet sich vor allem
dann an, wenn dem Anwender z.B. nicht alle Attribute einer Entität auf einmal
präsentiert werden sollen.
• Navigations-Primitive: In dieser Klasse werden Navigationsmechanismen definiert. Man unterscheidet dabei zwischen uni- und bidirektionalen Links, Index,
Guided Tour, indizierte Guided Tour und Gruppierung. Unidirektionale bzw. bidirektionale Links dienen dabei zur Spezifikation von Navigationen zwischen
den Sichten der einzelnen Entitäten. Ein Index stellt eine Liste von Instanzen
einer Entität dar, zu denen verzweigt werden kann. Guided-Tours modellieren
einen linearen Pfad durch eine Menge von Instanzen einer Entität, während indizierte Guided-Tours die Eigenschaften von Indizes und Guided-Tours verbinden.
Gruppierungen repräsentieren eine Auswahl, über welche andere Primitiven angesprochen werden können.
74
Abbildung 4.5: Grundsymbole der RMM-Methode
Phasen des RMM-Modells
Die Abbildung ”Phasen des RMM-Modells” auf Seite 73 hat bereits die einzelnen Phasen und deren Zusammenhänge illustriert. Wir werden nun genauer auf die einzelnen
Phasen eingehen.
Die vorausgehenden Phasen entsprechen klassischen Phasen des SoftwareEngineerings und beinhalten eine Machbarkeitsanalyse, eine Anforderungsanalyse und
eine Systemauswahl. In der Machbarkeitsanalyse werden neben der Analyse der voraussichtlichen Benutzer, Medien und Distributionskanäle vor allem anfallende Kosten
und Risiken analysiert. Während die Anforderungsdefinition die konkreten Anforderungen an die Anwendung definiert, ist die Systemauswahl für die Selektion der zugrunde liegenden Hardware des Web-Systems verantwortlich.
Die E-R-Design-Phase ist für die Modellierung der Struktur des Anwendungsgebietes, auf dem das Web-System basiert, verantwortlich. Dabei werden die grundlegenden
Entitäten mit ihren Attributen und Beziehungen bestimmt und in einem E-R-Diagramm
notiert.
In der Entity-Design-Phase werden Sichten definiert, um festzulegen, welche Informationen einer jeden Entität präsentiert und auf welche Art und Weise diese dargestellt
werden sollen. Zusätzlich werden über uni- bzw. bidirektionale Links die strukturellen Beziehungen zwischen den Sichten festgelegt. Das Endprodukt der Entity-DesignPhase ist ein erweitertes ER-Diagramm, auch ER+-Diagramm genannt, welches aus
4.4. BEISPIEL FÜR RMM
75
dem ER-Diagramm der E-R-Design-Phase abgeleitet wird, indem jede Entität mit ihrem Sichtendiagramm gefüllt wird.
Die Navigations-Design-Phase definiert die Navigationsstrukturen der Anwendung,
indem alle assoziativen Beziehungen des ER+-Diagramms analysiert und durch ein
oder mehrere RMDM-Navigations-Primitiven ersetzt werden, sofern diese zur Navigation genutzt werden sollen. Das Endprodukt der Navigations-Design-Phase ist ein
RMDM-Diagramm, welches alle zu implementierenden Navigationsstrukturen spezifiziert und aus dem ER+-Diagramm hervorgeht.
In der Konvertierungsprotokoll-Design-Phase werden mit Hilfe einer Regelbasis den
einzelnen Primitiven des RMDM-Diagramms Objekte zugeordnet, mit denen sie sich
konkret implementieren lassen. Beispielsweise lässt sich ein Index durch eine ListenBox oder eine HTML-Form realisieren.
Die Benutzerschnittstellen-Design-Phase dient der konkreten Gestaltung des Layouts
der Web-Anwendung und beinhaltet weiterhin die Gestaltung des Erscheinungsbildes
der einzelnen Knoten und Indizes sowie die Positionierung von Navigationshilfen.
In der Laufzeitverhalten-Design-Phase wird festgelegt, wie sich die Anwendung dynamisch verhalten soll, d.h. wie sie z.B. auf Benutzereingaben reagieren soll. Des
Weiteren werden zusätzliche Navigationshilfen wie z.B. History-Mechanismen oder
Backtracking-Funktionalitäten festgelegt.
In der Implementierungsphase erfolgt die eigentliche Codierung des WebSystems. Die Ergebnisse der Konvertierungsprotokoll-, Benutzerschnittstellen- und der
Laufzeitverhalten-Design-Phasen fließen direkt in diese Phase ein.
Die nachfolgende Test- und Evaluationsphase wird wie bereits erwähnt nicht direkt
vom RMM-Modell unterstützt. Allgemein lässt sich sagen, dass die entwickelte WebAnwendung auf Fehler kontrolliert werden muss, d.h. es muss sichergestellt sein, dass
die Anwendung korrekt arbeitet und alle Anforderungen erfüllt.
4.4 Beispiel für RMM
Die RM-Methodologie soll nun anhand eines kleinen Beispiels aus dem Bereich des
E-Learnings veranschaulicht werden.
Problembeschreibung
E-Learning kann als ein Lernprozess verstanden werden, der durch Informations- und
Kommunikationstechnologie unterstützt wird. Durch den Einsatz modernster Technologien besitzt das E-Learning viele Vorteile gegenüber herkömmlichen Lernmethoden:
Zeitliche und örtliche Unabhängigkeit, inhaltliche und methodische Aktualität,
ökonomischer und schneller Einsatz für unterschiedliche Zielgruppen, Vernetzung von
Personen und Organisationen und unproblematische/zielgerichtete Kommunikation.
E-Learning umfasst Informationen, Aktivitäten, Abläufe, Menschen und Techniken,
wobei die Gewichtung je nach Bedarf unterschiedlich sein kann. In akademischen
oder schulischen Umgebungen wird E-Learning heutzutage v. a. eingesetzt, damit die
Lehrenden im Rahmen ihrer Kurse Materialen wie z. B. Folien, Übungszettel und
weiterführende Literatur veröffentlichen können.
76
Im Rahmen dieses Beispiels soll eine Web-Anwendung entwickelt werden, in deren
Mittelpunkt Übungen stehen, die bestimmte Themengebieten innerhalb einer oder
mehrerer Vorlesungen vertiefen. Eine Übung lässt sich dabei immer mindestens einem
bestimmten Themengebiet und somit auch mindestens einer Vorlesung zuordnen.
Dabei besitzt jede Übung einen bestimmten Schwierigkeitsgrad (einfach, normal und
schwierig) und mindestens eine Lösung. Dem Benutzer sollen dabei verschiedene
Zugangspunkte zu der Anwendung zur Verfügung gestellt werden. Er soll wählen
können, ob ihm entweder einzelne Übungen vorlesungsspezifisch nacheinander vorgestellt werden, oder ob ihm zu einer speziellen Vorlesung oder Thematik geeignete
Übungen präsentiert werden sollen. Wählt der Benutzer Übungen aus, soll er entscheiden können, ob er beliebige oder nur einfache, normale oder schwierige Übungen
sehen möchte. Die Übungen besitzen dabei nur den reinen Aufgabentext, wobei der
Benutzer bei Bedarf noch einen Lösungsansatz anfordern kann. Der Benutzer soll sich
darüber informieren können, für welche Vorlesung bzw. welches Thema jede Übung
besonders geeignet ist. Wählt der Benutzer anfangs den Weg über die Vorlesungen
aus, soll er sich zu der gewählten Vorlesung sowohl die behandelten Themen als
auch vorlesungsspezifische Übungen anschauen können. Wählt er zu Beginn eine
bestimmte Thematik aus, sollen ihm alle Übungen angezeigt werden, die zum Erlernen
dieses Themas geeignet sind.
Entwicklung anhand der RM-Methodologie
Es wird davon ausgegangen, dass eine Machbarkeits- und Anforderungsanalyse sowie
eine Systemauswahl durchgeführt wurde. Auf den Ergebnissen dieser ”Vorbereitungsphasen” sollen nun die sieben RMM-Grundphasen angewendet werden:
• Phase 1: E-R-Design: Das ER-Diagramm der Anwendung wird in der Abbildung ”ER-Diagramm” auf Seite 77 illustriert. Als Entitäten wurden Vorlesung,
Thema, Übung und Lösung gewählt. Die im ER-Diagramm genannten Attribute
und assoziativen Beziehungen repräsentieren die in der Anforderungsdefinition
angeführten Eigenschaften und Zusammenhänge zwischen den Entitäten.
• Phase 2: Entity-Design: Die Abbildung ”Sichtendiagramm” auf Seite 77 beschreibt die Sichten der Entität Übung. Die Hauptsicht besteht dabei aus der
Beschreibung der Übung. Um die Übung verständlicher zu machen, kann von
dort zu einer anderen Sicht navigiert werden, die einen Lösungsansatz enthält.
Die anderen Entitäten besitzen nur jeweils eine Sicht, die alle Attribute umfasst.
Damit ergibt die Erweiterung der Entität Übung mit dem ”Sichtendiagramm” das
ER+-Diagramm.
• Phase 3: Navigations-Design: Die Abbildung ”RM-Diagramm” auf Seite 78
skizziert das RM-Diagramm der Anwendung. Der Benutzer erlangt dabei den
Zugang zur Anwendung über eine Gruppierung, mit der er zweischen Übungen,
Vorlesungen und Themen wählen kann. Entscheidet er sich für Übungen, kann er
über einen Übungsartenindex auswählen, ob ihm alle oder nur Übungen mit einem bestimmten Schwierigkeitsgrad angezeigt werden sollen. Dies geschieht anschließend in Form einer geführten Tour. Dabei kann er sich bei der Vorstellung
4.4. BEISPIEL FÜR RMM
77
Beschreibung
Name
Vorlesung
Teil von
verwendbar
bespricht
benutzt
Art
vertieft
Aufgabentext
Thema
Übung
benutzt
Lösungsansatz
Beschreibung
Name
hat
Lösung
Beschreibung
Abbildung 4.6: ER-Diagramm
*
Aufgabentext
Text
Lösungsansatz
Text
Abbildung 4.7: Sichtendiagramm
einer Übung mittels eines Lösungsindex über die verschiedenen Lösungen einer
Übung informieren. Des Weiteren hat er die Möglichkeit, über einen Themenund Vorlesungsindex Informationen über die involvierten Themen und Vorlesungen abzurufen, für die die Übung besonders geeignet ist. Entscheidet sich der
Benutzer für den Zugang über die Vorlesungen, kann er sich mittels eines Vorlesungsindex eine spezielle Vorlesung auswählen, über die er genauer informiert
wird und zu der er vorlesungsspezifische Übungen und Themen jeweils via einer
geführten Tour präsentiert bekommt. Bei Auswahl der Themen kann der Benutzer über einen Themenindex ein Thema auswählen, das ihm dann genauer vorgestellt wird und zu der in Form einer geführten Tour themenspezifische Übungen
angezeigt werden.
• Phase 4: Konvertierungsprotokoll-Design: Für alle Indizes und Gruppierungen
sind HTML-Listen zu verwenden. Die geführten Touren sollen mit jeweils einem
next- und einem previous-Button realisiert werden.
• Phase 5: Benutzerschnittstellen-Design: Das Design soll sehr einfach gehalten
werden. Es ist auf Übersichtlichkeit zu achten. Auf die genaue Beschreibung des
Layouts der Web-Anwendung soll an dieser Stelle verzichtet werden.
78
Art=
"einfach"
Übungsindex
Vorlesungsindex
Art=
"schwierig"
Themenindex
Art=
"normal"
Vorlesung
Übung
Vorlesungsindex
verwendbar(Ü,V)
Thema
vertieft(Ü,T)
Lösungsindex
Themenindex
hat(Ü.L)
Lösung
Abbildung 4.8: RM-Diagramm
• Phase 6: Laufzeitverhalten-Design: Bei den geführten Touren sollen die Anwender jederzeit mit Hilfe eines up-Buttons zum Ausgangsknoten der Tour zurückspringen können. Des Weiteren sind auch die Index-Seiten mit einem upButton zu versehen, über den der Knoten, von dem der Index ursprünglich angesprungen wurde, wieder erreichbar ist. Da sich die zu präsentierenden Daten
nicht sehr häufig ändern werden, können die Bildschirmseiten bereits zur Entwicklungszeit realisiert werden.
• Phase 7: Implementierung: In dieser Phase erfolgt die Entwicklung der WebAnwendung.
Es folgt nun eine intensive Test- und Evaluationsphase, in der die implementierte Anwendung auf Korrektheit überprüft und anschließend bewertet wird.
4.5 Fazit
Als Fazit dieser Ausarbeitung lässt sich festhalten, dass im Bereich der Web-SystemEntwicklung durchaus funktionierende Vorgehensmodelle existieren, die meiner Meinung nach aber nicht die Leistungsfähigkeit herkömmlicher Vorgehensmodelle des
Software-Engineerings erreichen, da ihnen eklatante Merkmale fehlen. Beispielsweise konnte ich kein Vorgehensmodell finden, welches annähernd das Potenzial und
die Flexibilität eines Spiralmodells besitzt oder eine testgetriebene Entwicklung unterstützt wie sie z.B. im Rahmen des Extreme Programmings angewendet wird, um
79
eine fehlerkorrigierende und flexible Programmierung zu ermöglichen. Dies mag vielleicht daran liegen, dass es sich beim Web-Engineering um eine sehr junge Anwendungsdisziplin handelt, die teilweise noch unerforscht und von permanenten technischen Veränderungen geprägt ist. Vielleicht kann man die Einfachheit der WebSystem-Vorgehensmodelle auch damit begründen, dass bei der Entwicklung einer WebAnwendung nicht der ingenieurmäßige Entwurf im Vordergrund steht, sondern künstlerische Aspekte eine viel bedeutendere Rolle spielen. Trotzdem darf man dabei nicht
vergessen, dass eine sehr gut gestaltete Web-Anwendung wertlos ist, wenn sie Mängel
in der Architektur aufweist und dadurch unbrauchbar wird.
Die in dieser Ausarbeitung vorgestellten Vorgehensmodelle und Methoden stellen eine gute (aber komplizierte und ungewohnte) Möglichkeit dar, Web-Systeme strukturell
zu entwerfen und zu entwickeln. Die hier intensiv vorgestellten Methoden HDM und
RMM sind beide in der Lage, die Modellierung inhaltsbezogener Navigationsstrukturen und Verlaufformen des Web-Systems zu unterstützen, wobei RMM im Gegensatz
zu HDM ein detailliertes Datenmodell verwendet und deshalb auch vorzuziehen ist.
Für den Fall, dass man eine Web-Anwendung erstellen möchte, sollte man sich an dem
Vorgehensmodell nach Boles orientieren und die Anwendung im Vorfeld mit Hilfe von
RMM strukturieren.
Ich persönlich bin mit dem Thema zufrieden und konnte viele neue und vor allem
interessante Aspekte kennen lernen. Obwohl das Thema meiner Meinung nach sehr
komplex ist, ist es mir gelungen einen kurzen Überblick über grundlegende Verfahren
und Methoden im Bereich des Web-Engineerings zu geben.
4.6 Vorgehensmodelle
Wasserfall−Modell
Anforderungs
definition
System− und
Softwareentwurf
Implementierung
Komponententest
Integration u.
Systemtest
Betrieb u.
Wartung
Abbildung 4.9: Wasserfallmodell
80
Ziele bestimmen
Randbedingungen feststellen
Risiko
Analyse
Alternativen auswerten
Risiken bestimmen und auflösen
Risiko
Analyse
Risiko
Analyse
Prototyp
Prototyp
Risiko
Analyse
REVIEW
Anforderungsplan
Lifecycle−Plan
Entwicklungs
Plan
Plan für
Integration und Test
Prototyp
Prototyp
(Simulationen, Modelle, Bnchmarks)
Betriebs
Konzept
SW
REQ
Produkt
Design
Valid. der
REQ
Detail−Design
Code
Komponenten−
Test
Design
V&V
Integr.−Test
Nächste Phase planen
Akzeptanztest
Wartung
Produkt der nächsten Ebene
entwickeln und verifizieren
Spiralmodell
Abbildung 4.10: Spiralmodell
Kapitel 5
Anwendungen zur Erstellung
und Abwicklung von
vollständigen Einzelkursen
(CBTs und WBTs)
Jens Peternel
Inhalt
5.1
5.2
5.3
5.4
5.5
Einleitung . . . . . . . . . . . . . . . .
E-Learning . . . . . . . . . . . . . . .
Begriffsdefinition . . . . . . . . . . . .
E-Learning Techniken . . . . . . . . . .
Standards und Richtlinien . . . . . . .
W3C . . . . . . . . . . . . . . . . . . .
ADL, IMS und AICC . . . . . . . . . .
Autorenwerkzeuge . . . . . . . . . . .
Professionelle Autorenwerkzeuge . . . .
WYSIWYG HTML Editoren mit PlugIns
Rapid Content Development Tools . . .
Fazit und Ausblick . . . . . . . . . . .
81
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
82
83
83
83
85
85
86
87
87
91
93
97
82
KAPITEL 5. ANWEDNUNGEN FÜR EINZELKURSE (CBTS UND WBTS)
5.1 Einleitung
Die stetige Weiterentwicklung von Internet- und Multimediatechnologien bietet auch
für den (Weiter-)Bildungsbereich eine Fülle neuer Unterrichtsmöglichkeiten. So ist es
bereits heute technisch möglich, komplette Unterrichtseinheiten, im Folgenden spreche
ich hierbei von Einzelkursen, über des Internet abzuhalten.
Die Erstellung dieser Einzelkurse ist meist Aufgabe der Lehrenden. Da diese aber i.d.R.
über keine nennenswerten Programmiererfahrungen verfügen, werden Werkzeuge benötigt, mit deren Hilfe auch so genannte Laien Einzelkurse erstellen können. Innerhalb
dieser Seminararbeit werde ich einige dieser Werkzeuge vorstellen.
Sowohl Erstellung als auch Abwicklung der oben angesprochenen Einzelkurse wird
unter dem Begriff E-Learning eingeordnet. In Kapitel 2 werde ich daher zunächst auf
den Begriff E-Learning und die Entwicklung im Bereich der E-Learning Techniken
eingehen. Anschliessend werde ich in Kapitel 3 einige wichtige Standards und Richtlinien vorstellen, deren Einhaltung sowohl für die Erstellung von Einzelkursen, als auch
für die Entwicklung von Autorenwerkzeugen erforderlich ist. In Kapitel 4 werde ich
die verschiedenen Arten von Autorenwerkzeugen und jeweils einige typische Vertreter
kurz vorstellen.
Den Abschluss dieser Seminarausarbeitung bildet eine kurze Zusammenfassung der
vorgestellten Ergebnisse, sowie eine Handlungsempfehlung bezüglich der Auswahl eines Autorenwerkzeugs.
5.2. E-LEARNING
83
5.2 E-Learning
In diesem Kapitel werde ich, wie bereits angesprochen, eine kurze Definition des ELearning Begriffs geben. Anschliessend gebe ich einen Überblick der wichtigsten ELearning Techniken.
Begriffsdefinition
Unter dem Begriff E-Learning versteht man die Unterstützung von Lehren und Lernen
durch den Einsatz von Informtions- und Kommunikationstechnologien, sowie durch
spezielle Software. Durch den Einsatz so genannter E-Learning Systeme soll das zeitund ortsunabhängige Vermitteln von Lerninhalten ermöglicht werden.
E-Learning Techniken
Überlegungen, den Computers in die Lehre mit einzubeziehen, gibt es bereits seit dem
Aufkommen der ersten Großrechner. Dieser Abschnitt bietet eine Übersicht der wichtigsten E-Learning Techniken, mit deren Hilfe computerunterstützter Unterricht verwirklicht werden soll.
CAI – Computer Aided Instruction
In den 50er und 60er Jahren des 20sten Jahrhunderts wurden erste Versuche unternommen, den Computer in die Lehre mit einzubeziehen. Die Anfänge dieses computerunterstützten Lernens stellten Computer Aided Instruction (CAI) und Computer Aided
Learning (CAL) dar.
Beide Techniken beruhen u.a. auf den Arbeiten von Burrhus F. Skinner zur programmierten Instruktion. Hierbei wird das dem Lerner zu vermittelnde Wissen in kleine
Lerneinheiten unterteilt. Diese müssen dann nacheinander vom Lerner abgearbeitet
werden. Nach jeder erfolgreich absolvierten Lerneinheit, erfolgt eine Belohnung des
Lernenden durch den Computer. Dieser übernimmt somit die Rolle eines Trainers (drill
instructor).
Aufgrund der hohen Hardware- und Telefonkosten, sowie kaum nachweisbarer Erfolge, wurde die Idee diese Technologie im schulischen Bereich einzusetzen, schnell verworfen und nur an einigen Universitäten und in Unternehmen, wie beispielweise IBM,
weiterhin verfolgt.
CBT – Computer Based Training
Durch das Aufkommen des PCs um 1980, wurde dem computerunterstützten Lernen
dann wieder größere Beachtung geschenkt. Zu dieser Zeit entwickelte sich das Compu-
84
ter Based Training, kurz CBT. Einige Aspekte dieser Technik ähnelt sehr stark denen
des CAI und CAL. So wird auch bei CBT Systemen der zu vermittelnde Lehrstoff in
kleine Lerneinheiten unterteilt, die vom Lerner nacheinander durchgearbeitet werden
müssen. Das Lerntempo wird dabei vom Lerner selbst bestimmt.
Die Vorteile von CBT Systemen gegenüber einem CAI oder CAL System bestehen im
wesentlichen in den geringeren Kosten. Darüber hinaus kann der Lehrstoff durch den
Einsatz multimedialer Elemente anschaulich und abwechslungsreich gestaltet werden.
CBT Systeme ermöglichen sowohl asynchrones als auch verteiltes Lernen. Asynchron
bedeutet hierbei, dass der Benutzer mit dem System zu einem beliebigen Zeitpunkt
arbeiten kann. Viele Systeme bieten sogar die Möglichkeit, einzelne Lerneinheiten zu
unterbrechen und zu späteren Zeitpunkten fortzuführen. Des weiteren ist der Benutzer, im Gegensatz zu CAI und CAL Systemen nur noch bedingt ortsgebunden. Einzige
Voraussetzung für die Wahl des Arbeitsplatzes ist das Vorhandensein eines multimediafähigen Computers.
Die Distribution von CBT Systemen erfolgt über Disketten, CD-Roms, DVDs oder das
Internet. Sowohl CBT Systeme als auch eventuell notwendige Aktualisierungen (updates) müssen auf jedem PC, auf dem das System laufen soll, einzeln installiert werden.
Dies liegt daran, dass sich CBTs i.d.R. nicht zentral administrieren lassen, worin ein
großer Nachteil dieser Techniken zu sehen ist. Der Einsatz eines CBT Systems in der
betriebliche Aus- und Weiterbildung ist daher nicht zu empfehlen.
Ein weiterer Nachteil von CBT Systemen besteht darin, dass der direkte Kontakt zwischen Lerner und Lehrer verloren geht. Der Lerner ist somit auf die vom CBT System
angebotenen Hilfefunktionen angewiesen.
Tele-Learning
Tele-Learning, Distance Learning und Virtual Classroom beschreiben Techniken, die
es einem Lehrer ermöglichen, seine Schüler trotz einer räumlichen Trennung zu unterrichten.
Im Prinzip stellt das Tele-Learning also lediglich eine Plattfom bereit, mittels welcher der Lehrer mit seinen Schülern kommunizieren kann. Die Schüler können so z.B.
einem Vortag ihres Lehrers folgen, in dem sie nebem dessen Bild auch eventuell vorhandene Vortragsfolien auf dem Bildschirm angezeigt bekommen.
Ist es den Schülern darüberhinaus möglich, während dieses Unterrichts Fragen an den
Lehrer zu stellen, spricht man vom so genannten virtuellen Klassenraum (Virtual Classroom).
WBT - Web Based Training
Durch die Einführung des Internet um 1990 ergaben sich eine Vielzahl neuer, für den
computerunterstützten Unterricht interessanter Kommunikationsmöglichkeiten. Dies
erforderte die Entwicklung neuer E-Learning Techniken. Eine Lösung stellte das so
5.3. STANDARDS UND RICHTLINIEN
85
genannte Web Based Training (WBT) dar. Im Grunde handelt es sich beim WBT um
eine erweiterte Version des bereits vorgestellten CBT. Die Verwendung von multimedialen Lerninhalten setzt auch hier den Einsatz einens multimediafähigen Computers
vorraus. Darüberhinaus wird ein ausreichend leistungsfähiger Internetzugang benötigt.
WBTs ermöglichen ebenso wie CBTs das asynchrone und verteilte Lernen. Sie können
aber auch für synchrones Lernen, wie es beim Tele-Learning eingesetzt wird, verwendet werden. Des weiteren können WBT Systeme explorative Lernstrategien unterstützen. Der Lerner kann somit selbstständig entscheiden, welchen Teil des Lernstoffs er
bearbeiten will und nach weiteren Informationen zu einem Thema im Internet suchen.
Ein Vorteil von WBT Systemen besteht darin, dass diese wesentlich leichter aktualisiert
werden können, da sie sich zentral administrieren lassen. Die Lernmaterialien können
somit stets auf dem neuesten Stand gehalten werden.
Als Nachteil können die anfallenden online-Kosten und die Abhängigkeit von der zur
Verfügung stehenden Bandbreite gesehen werden. Schlechte Datenraten können zu
Verzögerungen bei der Übertragung von Audio- und Videoströmen führen, was sich
wiederum negativ auf die Aufmerksamkeit und Motivation des Lernenden auswirken
kann.
5.3 Standards und Richtlinien
In diesem Kapitel werde ich einige Standards und Richtlinien vorstellen, an die sich
die meisten Hersteller von Autorenwerkzeugen zu halten versuchen. Zunächst gehe
ich auf die Authoring Tool Accessibility Guidelines des World Wide Web Consortiums
(W3C) ein. Anschliessend stelle ich kurz das SCORM-Modell der Advanced Distributed Learning Initiative (ADL) vor und gehe hiernach auf Standards des Aviation
Industry Computer Based Training Committee (AICC) ein.
W3C
Das World Wide Web Consortium (W3C) ist ein internationales Industrie-Konsortium.
Es gibt Richtlinien und Standards für die Verwendung von Techniken rund um das
World Wide Web heraus, die sowohl von Entwicklern als auch von Benutzern eingehalten werden sollten, um eine reibungslose Kommunikation im Internet zu gewährleisten.
Geführt wird das W3C dabei im wesentlichen von drei Organisationen:
• MIT Laboratory for Computer Science (LCS) aus den USA
• Institut National de Recherche en Informatique et Automatique (INRIA) aus
Frankreich
• Keio-Universität aus Japan
Weitere Informationen zum W3C sind unter http://www.w3.org/ zu finden. Im Februar
2000 gab das W3C unter dem Titel Authoring Tool Accessibility Guidelines Richtlinien
86
für den Entwurf von zugänglichen Autorenwerkzeugen heraus.
Die Authoring Tool Accessibility Guidelines werden von der Authoring Tool Accessibility Guidelines Working Group (AUWG) erstellt und vom W3C herausgegebenen. Bei
der AUWG handelt es sich um Akteure der Schlüsselindustrie sowie Behinderten- und
Forschungsorganisationen. Eine Liste der Mitglieder kann unter http://www.w3.org/WA
I/AU/members eingesehen werden.
Die Authoring Tool Accessibility Guidelines sind Teil der Web Accessibility Initiative,
kurz WAI. Diese Initiative gibt u.a. Richtlinien heraus, die für die Erstellung von zugänglichen Web Inhalten eingehalten werden müssen. Nähere Informationen zur WAI
findet man unter http://www.w3.org/WAI.
Mit der Herausgabe der Authoring Tool Accessibility Guidelines werden vom W3C
zwei Ziele verfolgt. Auf der einen Seite lassen sich mit Autorenwerkzeugen, die unter
Einhaltung dieser Richtlinien entworfen werden, zugängliche Web Inhalte erstellen.
Auf der anderen Seite wird durch die Einhaltung dieser Richtlinien sichergestellt, dass
auch die Benutzungsschnittstelle des Autorenwerkzeugs selbst zugänglich gestaltet ist.
Um Autorenwerkzeuge hinsichtlich der Authoring Tool Accessibility Guidelines
überprüfen zu können, ist vom W3C eine Checkliste erstellt worden, die unter
http://www.w 3.org/TR/2000/REC-ATAG10-20000203/atag10-chktable.html eingesehen werden kann. Die einzelnen Prüfungspunkte sind hierbei in drei Prioritätsstufen
unterteilt. Ein Autorenwerkzeug, dass alle Prüfungspunkte einer Prioritätsstufe einhält,
wird als zugänglich eingestuft und darf mit dem entsprechendem Symbol des W3C gekennzeichnet werden.
Dass auch weiterhin großes Interesse an der Erstellung von Richtlinien für den Entwurf
von Autorenwerkzeugen besteht, manifestiert sich in der Herausgabe der Authoring
Tool Accessibility Guidelines 2.0 als so genannter Working Draft im November 2004.
ADL, IMS und AICC
Mit dem Sharable Content Object Reference Model (SCORM) wird von der Advanced Distributed Learning Initiative (ADL) ein Standards herausgegeben, der einen
Austausch von Lerninhalten zwischen verschiedenen Learning Management Systems
(LMS) ermöglichen soll. Dabei arbeitet die ADL (http://www.adlnet.org) u.a. mit dem
Instructional Management Systems Project (IMS) zusammen, das an einem MetadatenStandard für Lernobjekte arbeitet.
Eine weitere Initiative, die Standards im Bereich des E-Learning herausgibt, ist das
Aviation Industry Computer Based Training Committee, kurz AICC. Dieses Komitee gibt eine Reihe von Richtlinien im Bereich der CBT Systemerstellung heraus,
wie z.B. Richtlinien für den Austausch von Elementen in CBT-Kursen oder Richtlinien zu Hardware-Voraussetzungen zur Nutzung von CBTs oder WBTs. Von AICCKonformität darf gesprochen werden, wenn ein Lernobjekt einer der AICC Richtlinien
genügt.
Die meisten Hersteller von Autorenwerkzeugen legen bei der Entwicklung ihrer Pro-
5.4. AUTORENWERKZEUGE
87
dukte großen Wert auf die Einhaltung der oben erwähnten Standards. Autorensysteme,
die diesen Standards nicht genügen, dürften auf dem heutigen Markt kaum noch Abnehmer finden.
5.4 Autorenwerkzeuge
Zur Erzeugung und Aufbereitung von Lerninhalten für Einzelkurse, wie CBTs oder
WBTs werden so genannte Autorenwerkzeuge verwendet. Viele diese Programme bieten Vorlagen für Lerninhalte, wie beispielsweise Wissenstests oder assistieren dem Benutzer beim Einbinden von Grafiken oder Animationen (z.B. Flash).
Heutige Autorensysteme können in drei Kategorien unterschieden werden (siehe Abbildung 5.1), die ich in den folgenden Abschnitten genauer beschreiben werde.
Abbildung 5.1: Drei Kategorien von Autorenwerkzeuge
Professionelle Autorenwerkzeuge
In diesem Abschnitt werde ich einige Programme vorstellen, die zur Kategorie der professionellen Autorenwerkzeuge zu zählen sind. Diese Programme zeichnen sich durch
einen hohen Funktionsumfang aus, der es dem Autor gestattet, seine Kurse beliebig zusammenzustellen. Auf der anderen Seite erfordert die Einarbeitung in diese Programme
sehr viel Zeit, wie Abbildung 5.1 zu entnehmen ist. Aus diesem Grund sind diese Programme für die schnelle Erstellung von Kursen durch ungeübte Benutzer nicht geeignet
sind. Es gibt drei Gruppen von professionellen Autorenwerkzeugen:
• Seiten orientierte Autorenwerkzeuge
• Flussdiagramm orientierte Autorenwerkzeuge
• Zeitleisten orientierte Autorenwerkzeuge
88
In den folgenden Abschnitten werde ich die besonderen Merkmale jeder Gruppe aufzeigen und jeweils einige bekannte Vertreter kurz vorstellen.
Seiten orientierte Autorenwerkzeuge
Die Seiten orientierten Autorenwerkzeuge zeichnen sich durch einen buchähnlichen
Aufbau aus. Der Autor erstellt mehrere Seiten mit Lerninhalten oder Wissenstests, die
vom späteren Anwender dann nacheinander zu durchlaufen sind. Dabei muss der Lerninhalt nicht nur aus statischem Text und einigen Grafiken bestehen. Je nach verwendetem Autorenwerkzeug werden zusätzliche Interaktionselemente angeboten, die eingefügt werden können. Zu den bekanntesten Vertretern der Seiten orientierten Autorenwerkzeuge zählen der Matchware Mediator (siehe Abbildung 5.2) und das Click2Learn
Toolbook.
Abbildung 5.2: Matchware Mediator 7 Pro
Flußdiagramm orientierte Autorenwerkzeuge
Zu den Eigenschaften der Flußdiagramm orientierten Autorenwerkzeuge zählt u.a. die
Möglichkeit, den Programmfluss der späteren Anwendung zu beeinflussen und somit
auf unterschiedliche Eingaben der Anwender zu reagieren. So ist es z.B. für einen
Wissenstest möglich, einem Anwender nach richtiger Beantwortung einer Frage zur
nächsten Frage zu navigieren oder im umgekehrten Fall Hilfestellungen zu geben.
Ein typischer Vertreter der Flussdiagramm orientierten Autorenwerkzeuge ist Macro-
89
media Authorware 7. Ich werde dieses Programm im folgenden etwas näher vorstellen.
Authorware 7 wurde speziell für die Bedürfnisse der Autoren von Lernsoftware entwickelt. Dieses Programm bietet Funktionen an, die den Aufbau und Ablauf von Einzelkursen sehr präzise festlegen. Es stehen ein Reihe von Vorlagen z.B. für die Erstellung
von Wissenstests zur Verfügung. Die Ergebnisse dieser Tests können in einer normalen
Textdatei archiviert werden. Da die mit Authorware 7 erstellten Lerninhalte den in Kapitel 3 beschriebenen Standards von ADL, IMS und AICC genügen, lassen sich diese
auch in ein Learning Management System (LMS) einbinden und dort auswerten.
Der Ablauf einer Kurseinheit, d.h. die Abfolge von erscheinenden Objekten und Aktionen kann über ein Flussdiagramm gesteuert werden (siehe Abbildung 5.3 Punkt 5).
Die Darstellung einer mittels Macromedia Authorware 7 erstellten Anwendung ist nach
Installation des Authorware Players mit einem Internet-Browser wie z.B. dem Microsoft Internet Explorer problemlos möglich. Allerding muss zur Darstellung einer
Authorware-Datei mindestens die Version des Authorware Players installiert sein, mit
der die Datei erstellt wurde. Ältere Authorware-Player unterstützen die Funktionen der
neueren Authorware-Versionen nicht. Zu den unterstützten Betriebsystemen zählen neben Microsoft Windows 98 SE / 2000 / Me / NT4 und XP auch MAC OS X.
Der Screenshot in Abbildung 5.3 gibt einen Überblick der Macromedia Authorware 7
Arbeitsumgebung, deren wichtigste Elemente im Folgenden kurz beschrieben werden.
Abbildung 5.3: Macromedia Authorware 7
1. Auf der Arbeitsfläche befinden sich alle für die Bearbeitung der Anwendung
notwendigen Werkzeuge.
90
2. Das Präsentations-Fenster bietet die Möglichkeit, die Anwendung zu Testzwecken abzuspielen.
3. Hier befindet sich die Menüleiste.
4. In der Icon-Palette befinden sich die verschiedenen im Design-Fenster platzierbaren Funktionen.
5. Im Design-Fenster kann der Programmablauf, d.h. die Abfolge der verschiedenen Objekte und Aktionen, festgelegt werden.
6. Die Bibliothek dient zum Ablegen wiederverwendbarer Objekte.
Macromedia Authorware 7 ist derzeit als Schulversion (englisch)
für 489,- Euro erhältlich. Die aktuellen Preise sind jederzeit unter
http://www.macromedia.com/de/resources/education/epl.html einsehbar.
Zeitleisten orientierte Autorenwerkzeuge
Im Gegensatz zu den Flussdiagramm orientierten Autorenwerkzeugen, wird der Ablauf
einer Anwendung durch Zeitleisten orientierte Autorenwerkzeuge nicht von Eingaben
des Anwenders abhängig gemacht, sondern folgt einem festgelegten zeitlichen Ablauf.
Zu den bekannteren Produkten dieser Gattung zählt neben Macromedia Flash MX 2004
auch der in Abbildung 5.4 dargestellte Macromedia Director MX 2004. Beide Werkzeuge sind eher ungeeignet für die Erstellung von interaktiven CBT- oder WBT-Kursen,
können aber für die Erstellung von Präsentationen von E-Learning Inhalten nützlich
sein. Diese lassen sich dann wiederum in CBT- oder WBT-Kurse einbetten. Mit dem
Macromedia Director MX 2004 lassen sich relativ plattformunabhängige, selbstständig
ablaufende Projekt erstellen. Die einzige Voraussetzung hierfür ist die Installation des
ebenfalls von Macromedia angebotenen Shockwave Players.
Die wichtigsten Elemente des Macromedia Director MX 2004 sind in Abbildung 5.4
dargestellt und werden im Folgenden kurz vorgestellt.
1. Innerhalb der Arbeitsfläche kann die Anwendung bearbeitet werden.
2. Im Drehbuch wird der zeitliche Ablauf der unterschiedlichen Inhalte der Anwendung festgelegt.
3. Eine Auflistung der verwendeten Medienelemente findet im Besetzungsfenster
statt.
4. Auf der Bühne wird die Position der Medienelemente festgelegt.
5. Im Eigenschafteninspektor lassen sich die Attribute ausgewählter Objekte
überprüfen und verändern.
6. Wichtige Werkzeuge sind in der Werkzeugpalette zu finden.
Macromedia Director MX 2004 ist derzeit als Schulversion (deutsch) für 599,- Euro
erhältlich.
91
Abbildung 5.4: Macromedia Director MX 2004
WYSIWYG HTML Editoren mit PlugIns
WYSIWYG HTML Editoren wie z.B. Mircosoft Frontpage, Marcomedia Dreamweaver oder auch Netobjects Fusion sind für die Erstellung von Internetseiten konzipiert
worden. Das Kürzel WYSIWYG steht hierbei für What You See Is What You Get und
besagt, dass ein Dokument während der Bearbeitung am Bildschirm entsprechend der
späteren Ausgabe angezeigt wird.
Für viele dieser Werkzeuge sind heutzutage Erweiterungen, so genannte PlugIns, zur
Erstellung von WBT Kursen erhältlich. Welche Funktionalitäten diese Erweiterungen
im Einzelnen bieten können, werde ich innerhalb dieses Kapitels anhand einiger für
den Macromedia Dreamweaver MX 2004 verfügbaren PlugIns aufzeigen.
Der HTML Editor Dreamweaver wird seit 1997 von der Firma Marcromedia vertrieben
(http://www.macromedia.com). Mit dem Dreamweaver MX 2004 ist bereits die siebte
Version dieses Programms erhältlich. Neben einer übersichtlichen grafischen Bearbeitung von Webseiten bietet dieses Programm Funktionen wie Farbkennzeichnung und
Autovervollständigen für HTML-Code und Skriptsprachen wie PHP und JavaScript an.
92
CourseBuilder:
Diese Erweiterung bietet über 40 Vorlagen für die Erstellung von Wissenstests, wie
z.B. multiple choice, drag and drop oder Lückentexte. Des weiteren wird durch diese
Erweiterung der Einsatz interaktiver Elemente soweit unterstützt, dass keine Kenntnisse von JavaScript erforderlich sind. Macromedia gibt weiterhin an, dass die Ergebnisse
der mit dieser Erweiterung erstellten Wissenstests von AICC kompatiblen Learn Managemant Systemen (LMS) ausgewertet werden können.
Abbildung 5.5: Macromedia Deamweaver MX 2004 mit CourseBuilder Erweiterung
Learning Site:
Mithilfe dieser Erweiterung ist es möglich verschiedene Lerninhalte zu konfigurieren
und diese zu einem Kurs innerhalb einer eigenständigen Website zusammenzuführen.
Darüber hinaus lassen sich spätere Aktivitäten von Kursteilnehmern serverseitig protokollieren (tracking) und in einer Datenbank archivieren.
SCORM RTI (Runtime Interface):
Diese Erweiterung sorgt dafür, dass die erstellten HTML Inhalte den Advanced Distributed Learning (ADL) Standards entsprechen.
93
Manifest Maker:
Mittels dieser Erweiterung wird für jede mit dem Macromedia Dreamweaver erstellte
Kurseinheit eine XML-Manifest-Datei angelegt. Diese Datei enthält Metadaten, welche die Kurseinheit gemäß den Richtlinien des International Management Systems
Global Learning (IMS) beschreiben. Auf diese Weise können alle von der Kurseinheit
benötigten Ressourcen festgehalten werden. Diese Informationen sind bei der Übertragung der Kurseinheit in ein beliebiges Learning Management System (LMS) von
großer Bedeutung.
Alle
hier
vorgestellten
Erweiterungen
werden
unter
http://www.macromedia.com/cfusion/exchange/ kostenlos angeboten. Der Preis
für Macromedia Dreamweaver MX 2004 in der Schulversion (deutsch) beträgt zur
Zeit 119,- Euro.
Rapid Content Development Tools
Um auch Personen mit geringer Programmiererfahrung die Erstellung von CBT- und
WBT-Kursen zu ermöglichen, wurden die Rapid Content Development Tools entwickelt. Diese Werkzeuge ermöglichen es dem Benutzer, durch wenige Mausklicks einen
Einzelkurs zu erstellen und anschliessend zu veröffentlichen.
Eine kürzlich von der Firma LearnChamp herausgegebene Studie vergleicht 12 aktuelle
Rapid Content Development Tools miteinander. Zu den zwölf Probanden zählten:
• author42.ASP (Hersteller: bureau42)
• Breeze (Hersteller: Macromedia)
• Content Creator (Hersteller: bitMedia)
• Dynamic PowerTrainer (Hersteller: Dynamic Media)
• Easy Prof (Hersteller: ITACA)
R (Hersteller: NIAM-TMS)
• EasyGenerator
• Idea (Hersteller: LINK & LINK)
• LearnCube (Hersteller: X-Pulse)
• Lectora 2004 (Hersteller: Trivantis)
• Lesson Creator (Hersteller: Know-how!)
• Trainersoft (Hersteller: OutStart)
• WBT-Layouter (Hersteller: engram)
Die Autorenwerkzeuge wurden anhand eines Katalog bestehend aus elf Hauptkriterien
überprüft:
94
• Features Editor
• Lerninhalte
• Interaktivität und Tests
• Fragetypen
• Sprachen
• Storyboarding und Drehbuch
• Design
• Features Kurs
• Dateiformate Import
• Dateiformate des Lerninhalts
• Integrierte Tools
Ein weiteres wichtiges Testkriterium stellte das Preis-/Leistungsverhältnis dar. Diese
Studie kann unter http://www.learnchamp.com zu einem Preis von 75,- Euro erworben
werden.
Im Folgenden werde ich zwei Vertretern der Gruppe der Rapid Content Development
Tools näher vorstellen. Zunächst stelle ich mit dem Dynamic PowerTrainer der Firma
Dynamic Media ein kommerzielles Autorenwerkzeug vor. Anschliessend gehe ich auf
ein kostenlos erhältliches Produkt der Firma 4system ein, den WBTExpress4 FREE.
Dynamic PowerTrainer 2
Von der Firma Dynamic Media wird unter http://www.dynamicpowertrainer.com der
Dynamic PowerTrainer vertrieben. Es handelt sich dabei um ein Autorenwerkzeug zur
Erstellung, Bearbeitung und Veröffentlichung von E-Learning Kursen.
Lerninhalte können entweder selbst erstellt werden, oder aus anwendungsfremden Formaten importiert werden. Der Dynamic PowerTrainer unterstützt dabei neben allen
gängigen Microsoft Office Dokumenten auch Videos oder PDF Dokumente. Es ist
möglich sowohl online- als auch offline Kurse zu erstellen. Jeder Einzelkurs läst sich
um Wissenstests erweitern, wobei vom Dynamic PowerTrainer bereits eine Vielzahl an
Vorlagen angeboten wird. Die Antworten der Lernenden lassen sich dank AICC und
SCORM Kompatibilität mit einem Learning Management System (LMS) auswerten.
Abbildung 5.6 zeigt einen Screenshot der Kurserstellung mit dem Dynamic Powertrainer.
Der Dynamic PowerTrainer ist derzeit in drei Varianten erhältlich:
Die Basic-Version bietet dem Benutzer die Möglichkeit, Kurse, Wissenstests und Lexika zu erstellen und zu editieren. Man kann diese Version als Education-Version bei
Dynamic Media zu einem Preis von 455,- Euro erwerben.
95
Abbildung 5.6: Dynamic Media - Dynamic PowerTrainer 2
Die Professional-Version bietet darüber hinaus auch die Möglichkeit, einzelne Lernsequenzen zu erstellen und zu editieren und die erstellten Inhalte dank SCORMKompatibilität auch in anderen LMS Plattformen einzusetzen. Diese Programmversion
ist in der Education-Version derzeit zu einem Preis von 1225,- Euro erhältlich.
Bei der Corporate-Version handelt es sich um eine spezielle Lösung für Unternehmen.
Sie besteht u.a. aus speziellen Verwaltungs- und Managementfunktionen im integrierten Dynamic PowerTrainer Manager und 5 Lizenzen der Professional Version. Hierzu
werden unter http://www.dynamicpowertrainer.com keine Preisangaben gemacht.
WBTExpress4 FREE
Zum Abschluss dieses Kapitels werde ich mit dem in Abbildung 5.7 dargestellten
WBTExpress4 FREE der Firma 4system (http://www.4system.com) noch ein kostenloses Autorenwerkzeug vorstellen.
Mit diesem Autorenwerkzeug lassen sich sowohl online- als auch offline-Einzelkurse
erstellen. In diese können Lerninhalte in Form von Texten, Grafiken und Animationen wie beispielweise Java Applets eingefügt weden. Darüber hinaus bietet WBTExpress4 FREE noch eine Reihe von Vorlagen für Wissentests. Nachteil dieser kostenlosen Version ist, dass sich die Testergebnisse nicht ohne weiteres auswerten lassen.
Um SCORM und AICC kompatible Einzelkurse erstellen zu können, ist es notwendig,
WBTExpress PRO zum Preis von derzeit 199,- Euro zu erwerben. Mit diesem Programm hat man die Möglichkeit, erstellte Kurse in ein Learning Managemant System
(LMS) seiner Wahl einzubinden.
4system bietet die Möglichkeit, die mit WBTExpress4 FREE erstellten Einzelkurse
96
Abbildung 5.7: 4Systems - WBTExpress4 FREE
auf einem WBTServer (siehe Abbildung 5.8) gegen eine Gebühr zu veröffentlichen.
In diesem Fall wird dann auch eine Kursverwaltung angeboten und die Ergebnisse der
Kursteilnehmer können ausgewertet werden.
Abbildung 5.8: 4Sytsmes - WBTServer
5.5. FAZIT UND AUSBLICK
97
5.5 Fazit und Ausblick
Innerhalb dieser Arbeit hab ich drei Arten von Autorenwerkzeuges vorgestellt, die prinzipiell für die Erstellung kompletter Einzelkurse verwendet werden können; die professionellen Autorenwerkzeuge, die WYSIWYG HTML Editoren und die Rapid Content
Development Tools. Grundsetzlich sollten für die Wahl eines Autorenwerkzeugs folgende Fragen beantwortet werden:
• Über welches Vorwissen (mit der Anwendung) verfügen die späteren Anwender?
• Wie hoch sind die zur Verfügung stehenden finanziellen Mittel?
• Wieviel Einarbeitungszeit steht zur Verfügung?
Man kann davon ausgehen, dass die Antworten auf diese Fragen von Bildungseinrichtung zu Bildungseinrichtung unterschiedlich ausfallen werden. Daher lässt sich keine
klare Aussage darüber treffen, welches Autorenwerkzeug in einer Bildungseinrichtung
grundsätzlich verwendet werden sollte.
Generell lässt sich allerdings folgendes sagen: das eingesetzte Autorenwerkzeug wird
in der Regel sicherlich nicht von speziell dafür geschulten Fachpersonal benutzt, sondern von den Lehrkräften der Bildungseinrichtung. Diese müssen in der Regel den
Umgang mit dem Autorenwerkzeg selbstständig erlernen, wobei die hierzu zur Verfügung stehende Zeit sicherlich begrenzt ist. Das zu verwendende Autorenwerkzeug
sollte also nach Möglichkeit schnell zu erlernen sein und darf keine fundierten Programmierkenntnisse voraussetzen. Aus diesem Grund wäre der Einsatz von professionellen Autorenwerkzeugen sicherlich nicht zu empfehlen.
Optimale Untersützung bei der Erstellung von CBT- oder WBT Kursen bieten die Rapid Content Development Tools. Der Nachteil liegt bei diesen Werkzeugen allerdings
in den hohen Anschaffungskosten.
Eine ALternative bilden Werkzeuge aus der Gruppe der WYSIWYG HTML Editoren.
Für eine Bildungseinrichtung würde ich daher vorschlagen, zunächst zu evaluieren, ob
ein solches Werkzeug bereits vorhanden ist und ob es Erweiterungen gibt, um mit diesen Werkzeugen CBT- und WBT Kurse zu erstellen. Die Vorteile liegen auf der Hand.
Zum einen ist es relativ wahrscheinlich, dass eine größere Anzahl von Lehrern der
Bildungseinrichtung bereits im Umgang dieses Werkzeugen geübt ist, was den Einarbeitungsaufwand stark reduziert. Zum Anderen sind die nötigen Erweiterungen oftmals
kostengünstig oder teilweise sogar kostenlos (vgl. Kapitel 4.2) zu erhalten, was gerade
in der heutigen Zeit der entscheidende Faktor sein könnte.
98
Kapitel 6
Implementation von Lehr- und
Lernsystemen
Andreas gr. Austing
Inhalt
6.1
6.2
6.3
6.4
Einleitung und Ausgangsfall . . . . . . . . . .
Systemarten von Lehr- und Lernsystemen . .
Reinformen . . . . . . . . . . . . . . . . . . .
Webbasierte Lernplattformen . . . . . . . . . .
Implementation von Lehr- und Lernsystemen
Dokumentformate . . . . . . . . . . . . . . . .
Skriptsprachen . . . . . . . . . . . . . . . . . .
Java-basierte Technologien . . . . . . . . . . .
Fazit . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
99
100
101
101
105
105
109
111
113
6.1 Einleitung und Ausgangsfall
Insbesondere an Hochschulen werden immer häufiger softwareunterstützte, zumeist
webbasierte Systeme eingesetzt, die es erlauben, einzelne Kurse aber auch komplette
Lehrveranstaltungen über das Internet anzubieten und abzuwickeln. Dieser neue Trend
wurde durch den Begriff e-Learning verschlagwortet.
E-Learning bezeichnet einen Überbegriff für softwareunterstüztes Lehren
und Lernen.
—Modifiziert nach [BHMH02]
Den e-Learning-Anwendungsbereich abdeckende Systeme werden als Lehr- und Lernsysteme (LLS) bezeichnet und charakterisieren sich dadurch, dass durch den Einsatz
digitaler Medien Individuen oder Gruppen zeitund ortsunabhängig Wissen und Kompetenzen erwerben (lernen) können [Min02].
99
100
KAPITEL 6. IMPLEMENTATION VON LEHR- UND LERNSYSTEMEN
Dieser Entwicklungsprozess und die dadurch resultierenden Möglichkeiten können als
Paradigmenwechsel betrachtet werden: Weg von klassischen Lernmethoden und einem
Lernen auf „Vorrat“, hin zu Kompetenzentwicklung und Wissensbeschaffung anhand
geeigneter„Wissensquellen“. Insbesondere haben sich modulare Konzepte für „hybrides“, das virtuelle mit dem realen Klassenzimmer verknüpfende, Lernen gemäß des
Schlagwortes „Blended Learning“ durchgesetzt.
Blended Learning bezeichnet Lehr- und Lernkonzepte, die eine didaktisch sinnvolle Verknüpfung von „traditionellem Klassenzimmerlernen“
und virtuellem bzw. Online Lernen auf der Basis neuer Informations- und
Kommunikationsmedien anstreben.
—Nach [MS02]
Um diese Entwicklung und die Vorteile dieser modernen Lernkonzepte weiter zu fördern, sollten sie möglichst auch außerhalb der Hochschule an mittelständischen Bildungseinrichtungen eingesetzt werden. Diesbezüglich wird der folgende konkrete Ausgangsfall angenommen.
An der berufsbildenen Schule BBS-Virtuell existieren einige Probleme, deren Schwerpunkte auf der Verwaltung und Lehre liegen und die durch den unterstützenden Einsatz
eines LLS gelöst werden sollen. Innerhalb der Schule sind bezüglich der Verwaltung
periodisch wiederkehrende und außergewöhnliche Termine zu koordinieren und anzukündigen sowie Schüler- und Lehrerdaten zu verwalten. Um den Kommunikationaustausch zwischen der Schule und Umfeld zu verbessern, möchte sich BBS-Virtuell
im Internet präsentieren. Dazu gehört die Möglichkeit, Neuigkeiten auf der Webseite
zu veröffentlichen, die Selbstdarstellung bzw. das Profil der Lehrer sowie ein Forum
zur Diskussion (Beantworten von themenbezogenen Anfragen, Diskussion, Verbesserungsvorschläge, etc.). Um die Qualität der Lehre zu verbessern soll das LLS unterstützend die eigentlichen Lehrmaterialien in angemessener Weise präsentieren und ggf.
weiterführende Informationen in Form von externen Links oder einer Literaturrecherche in einer Online-Bibliothek ermöglichen. Den Schülern soll ebenfalls Möglichkeiten
der Kollaboration z.B. über Email, Chat und Forum zur Verfügung gestellt werden, um
in der Gruppe Probleme zu lösen, angeeigentes Wissen zu vertiefen und Rücksprache
mit dem Tutor zu führen. Mittels dieser Maßnahmen erhofft sich die Berufsschule, die
Verwaltung zu vereinfachen, die Qualität der Lehre zu erhöhen, die letztendlich die
Attraktivität und den Erfolg der Einrichtung ausmachen. Dieses Vorhaben soll möglich
kostengünstig umgesetzt werden. Diesbezüglich hat sich ein Lehrer bereiterklärt das
Projekt mittels einiger Schüler in einer Arbeitsgemeinschaft umzusetzen.
Die Grundlagen zum Verständnis von LLS und die dahinterstehenden Technologien
und Techniken zur Implementierung sollen in dieser Arbeit vermittelt werden, damit
die Einführung des LLS an der Berufsschule BBS-Virtuell gelingt.
6.2 Systemarten von Lehr- und Lernsystemen
In der Literatur existieren viele Versuche, Lehr- und Lernsysteme nach einer gewissen
Methodik zu klassifizieren. Schulmeister schlägt in [Sch02] eine Einteilung nach dem
6.2. SYSTEMARTEN VON LEHR- UND LERNSYSTEMEN
101
Grad der Interaktivität vor. Im Gegensatz dazu versucht Baumgartner eine Kategorisierung in Form eines Würfelmodells vorzunehmen [BP99]. Bei diesem Modell werden
die drei allgemeinen pädagogischen Dimensionen Lernziele / Lerninhalte / Lehrstrategien gleichzeitig betrachtet und so eine eindimensionale bzw. hierarchische Kategorisierung vermieden.
Reinformen
Da jedem Lehr- und Lernsystem implizit mindestens eine Lerntheorie zu Grunde liegt,
kann dieses Merkmal auch als Klassifikationskriterium dienen. Meistens verwirklichen
diese Systeme jedoch mehrere Konzepte gleichzeitig und sind daher schwer zuzuordnen. Die möglichen Reinformen seien hier kurz genannt:
•
•
•
•
•
•
•
Tutorielle Systeme
Intelligente Tutorielle Systeme (ITS)
Hypertext-/Hypermedia-Lernsysteme
Spiele
Simulationen und Planspiele
Mikrowelten
Virtuelle Communities
Webbasierte Lernplattformen
Neben den in Abschnitt Grundlagen genannten Reinformen ist insbesondere die Klasse der webbasierten Lernplattformen1 interessant. Aufgrund des heutzutage einfachen Zugangs zum Internet ist das World Wide Web die Technologie der Wahl, um
z.B. eine größere Anzahl von Menschen in einer Lerngruppe zusammenzuschließen.
Baumgartner unterscheidet nicht zwischen einer webbasierten Lernplattform und einem Learning-Management-System:
Unter einer webbasierten Lernplattform ist eine serverseitig installierte
Software zu verstehen, die beliebige Lerninhalte über das Internet zu vermitteln hilft und die Organisation der dabei notwendigen Lernprozesse
unterstützt.
—Nach [BHMH02]
Durch diese Definition werden die folgenden Werkzeuge und Systeme ausgegrenzt:
• Clientseitige Autorenwerkzeuge sind nicht webbasierte und nicht serverseitig
installierte Autorenwerkzeuge, wie z.B. HTML-Editoren.
• Organisationslose Bildungsinhalte die keine organisierende Funktion des
Lernprozesses aufweisen (z.B. normale Webseiten) oder Bildungsinhalte, die nur
mit einem bestimmten Inhalt verknüpft sind (z.B. ein spezifisch über das WWW
angebotener Kurs).
1
Lernplattform wird im Folgenden sysnonym mit dem Begriff LLS verwendet.
102
• Reine Managementsysteme können zwar Lernprozesse administrieren, aber
keine inhaltliche Funktion im LMS wahrnehmen (z.B. Studenten- und Kursverwaltung).
• Content-Management-Systeme (CMS) können zwar Inhalte verwalten, bieten
aber in der Regel keine spezielle Steuerung des Lernprozesses an.
• Webbasierte Systeme sind Systeme, die auch für Lernzwecke verwendet werden können (z.B. Datenbanken, Applicationsharing, Instrumente zum kooperativen Arbeiten und CMS), jedoch nur eine unterstützende Form in Bezug auf
Aufgabenbereiche im e-Learning einnehmen.
Im Zusammenhang mit dem in der Einleitung beschriebenen Ausgangsfall besitzen
Learning-Management-Systeme (LMS) eine besondere Bedeutung, da diese helfen
können, einen Teil der genannten Probleme zu lösen. LMSe sind nicht nur reine Lernplattformen, um die Hauptaufgabe Förderung des Lernprozesses des Schülers zu unterstützen, sondern integrieren i.d.R. eine Vielzahl von weiteren Diensten.
Der nächste Abschnitt stellt einige LMSe konkret vor, bevor in Abschnitt 6.3 auf die
Technologien zur Entwicklung von Lernplattformen eingegangen wird.
Learning-Management-Systeme (LMS)
LMSe verwalten in einer Datenhaltung von Autoren erstellte oder zugekaufte Inhalte
(Content). Diese werden mit Unterstützung von Autorenwerkzeugen erzeugt und dann
in das LMS hochgeladen. Autorenwerkzeuge dienen dazu, dem Benutzer die Details
der Auszeichnungssprachen XML oder HTML mittels WYSIWYG-Editoren (What
You See Is What You Get) zu verbergen und so auch technisch unversierte Benutzer zu Autoren zu machen. Diese Inhalte werden dem Lerner in Kursen, für die sich
dieser ggf. einschreiben muss, zur Verfügung gestellt. Der individuelle Lernprozess
(z.B.: Welche Lernmodule wurden wie lange angeschaut? Welche Prüfungsergebnisse
wurden erreicht?) wird von dem System mitverfolgt. Des Weiteren stehen dem Lehrer
und Lerner Kommunikationswerkzeuge zur Verfügung, mit deren Hilfe sie kooperieren oder kollaborieren können. Nach [BHMH02] zeichnet sich ein LMS insbesondere
durch folgende fünf Funktionsbereiche aus:
• Präsentation von Inhalten, die über verschiedene Medien transportiert werden
können, wie z.B. Text, Grafik, Bild, Ton und Film.
• Kommunikationswerkzeuge sind Werkzeuge, über die Lehrer sowie Lerner Informationen austauschen können. Dies kann asynchron über e-Mail oder Foren
sowie synchron über Chat und Applicationsharing-Programme geschehen.
• Autorenwerkzeuge dienen zum Erstellen von Lernmaterial, Aufgaben und
Übungen, also jeglicher Art von Inhalten für die Lerner.
• Evaluations- und Bewertungshilfen können sowohl Werkzeuge für die Lehrenden zur Evaluierung des Lernerfolgs und der Wissensaneignungsstrategien
der Lernenden, als auch Hilfestellungen für die Lernenden sein.
• Administration der Lerninhalte, Kurse, des Lernfortschrittes, von Terminen,
etc.
6.2. SYSTEMARTEN VON LEHR- UND LERNSYSTEMEN
103
Die genannten Funktionsbereiche charakterisieren ein LMS. Das bedeutet jedoch
nicht, dass diese Funktionen alle implementiert oder im gleichen Umfang vorhanden
sein müssen. Ein Beispiel für ein LMS ist das an der Universität Oldenburg eingesetzte Stud.IP [GMB05]. Daneben existieren noch Blackboard [Inc05a] und WebCT
[Inc05b], um einige der bekanntesten zu nennen.
Learning-Content-Management-Systeme (LCMS)
Ein LCMS unterstützt den Autor mittels integrierter Autorentools oder vorgefertigter Templates bei der Erstellung von Lernobjekten. Diese werden möglichst detailliert mit Metadaten beschrieben und in einer Datenbank gespeichert (Ebene der Autoren). Diese Lernobjekte können kombiniert und zu ebenfalls mit Metadaten annotierten Online-Kursen und Lehrgängen zusammengesetzt und veröffentlicht werden (siehe
auch Abschnitt 6.3). Durch dieses modulare Schema können Lernobjekte erstens leicht
wieder verwendet und zweitens effizient und kostengünstig verarbeitet werden. Ein
Learning-Content-Management-System (LCMS) kombiniert die typischen Funktionen
eines LMSes mit denen eines Content-Management-Systems (CMS):
•
•
•
•
•
•
Präsentation und Publikation von Inhalten;
Aufarbeitung und Aktualisierung von Inhalten;
Management und Organisation von Inhalten;
Verteilung und Integration von Inhalten;
Verarbeitung von Inhalten (Workflow);
Widerverwendbarkeit von Inhalten.
Die Funktionsbereiche des CMSes sind jedoch speziell an die für LearningManagement-System spezifischen Anwendungsbereiche angepasst. Im Mittelpunkt
steht der Begriff des Reusable Learning Object (RLO)2 : Ein Learning Object (LO) ist
die kleinste sinnvolle Lerneinheit, in die ein Online-Kurs zerlegt werden kann. Demnach kann ein LO entweder aus einem einzelnem Bild, einer Grafik, einem Text, einer
Flash-Animation oder auch aus einer kurzen Anweisung mit einem definiertem Lernziel und einem Test zur Lernerfolgskontrolle bestehen. Wenn diese LOs mit Metadaten
versehen und zu größeren Online-Kursen kombiniert werden können, dann spricht man
von Reusable Learning Objects (RLO). Anhand dessen kann ein LCMS wie folgt definiert werden.
Ein Learning-Content-Management-System ist eine Software, die die Erstellung, Speicherung und Verwaltung von wiederverwendbaren Lernobjekten (RLO’s) sowie die Organisation und Betreuung webunterstützten
Lernens ermöglicht.
—Nach [BHMH02]
2 In der begriffswelt des e-Learning exisiterit noch keine Vereinheitlichung aller Begriffe. So wird ein
LO in der SCORM CAM Spezifikation (Abschnitt 6.3) als Asset und ein RLO als SCO bezeichnet.
104
Aufgrund dieser versprechenden Technologie statten viele vormalige LMSe ihre Systeme mit einem Modul zur Erstellung Verwaltung von RLOs aus. Beispiele sind Moodle
[Org05], ATutor [ATRCA05] und Ilias [Köl05].
Learning-Activity-Management-Systeme (LAMS)
Ein neuer Trend webbasierter LLS geht dahin, die Lernaktivitäten eines Lerners, bzw.
einer kollaborativ-tätigen Gruppe zu Unterstützen. Ein Beispiel für diese Art von Systemen ist das so genannte Learning Activity Management System (LAMS) [Int05].
Dieses System ermöglicht es, auf einfache Art und Weise Sequenzen kollaborativer
Lerntätigkeiten zu visualisieren und zu designen. Dabei bezieht es viele Funktionen
eines LMS mit ein, wie Bewertungen, Frage- und Antwortformate, Bemerkungen und
Chats.
Abbildung 6.1: LAMS International. Das System im Einsatz [Int05].
Abbildung 6.1 zeigt das System. Links im Bild ist eine Liste von vorgefertigten Aktivitäten vorhanden, die mittels Drag’n’Drop in das Arbeitsfeld gezogen werden können.
Diese Aktivitäten lassen sich unter zur Hilfenahme eines Werkzeuges zu einer Lernsequenz verbinden. Des Weiteren wird eine Umgebung zur Verfügung gestellt, mit der
sich die derzeitigen Aktivitäten und Fortschritte der Lerner verfolgen und auswerten
lassen.
Wie der Webpräsenz des Herstellers zu entnehmen ist, befindet sich das System derzeit in der Evaluationsphase. Zudem gibt es Bestrebungen, die LAMS Software gegen
Februar 2005 als Open Source zu veröffentlichen. Insgesamt stellt LAMS einen interessanten Ansatz in der Entwicklung der LMS dar, indem es die Aktivitäten der Lerner
fokussiert. Durch die anstehende Veröffentlichung des Quellcodes dürften dem Projekt
ein weiterer Entwicklungsschub bevorstehen und spätestens dann wird sich zeigen, ob
ein derartiger Ansatz sich im Einsatz an öffentlichen Bildungseinrichtungen bewährt.
6.3. IMPLEMENTATION VON LEHR- UND LERNSYSTEMEN
105
6.3 Implementation von Lehr- und Lernsystemen
Nachdem einige webasierte Lernplattformen vorgestellt wurden, soll sich nun den gängigsten Technologien zugewendet werden, um diese Art von Systemen zu implementieren. Generell gilt für dieses Kapitel, dass nur grundlegende Techniken anhand von
Anwendungsbeispielen vorgestellt werden. Für eine weitere Vertiefung des Inhalts sei
auf die Literatur am Ende jedes Abschnittes verwiesen.
Dokumentformate
In Bezug auf LCMSe besitzen die ausgewählten Dokumentformate HTML, XML und
SCORM CAM eine besondere Relevanz. Die Hypertext-Markup-Language ist ein Vorläufer von XML (eXtensible Markup Language) und wird häufig verwendet, um webbasierte Lerninhalte zu erstellen (siehe Abbildung 6.2. Daher ist dieser Abschnitt für
Lehrer in der Funktion von Autoren (Entwicklung und Veröffentlichung von Lerninhalten) interessant. Das SCORM Content-Aggregation-Model (CAM) [ADL04] bedient
sich wiederum der XML, um Inhalte von verschiedenen Dokumenten zusammenzustellen. Die folgenden Abschnitte stellen die genannten Formate vor und erläutern diese
anhand von Beispielen.
Abbildung 6.2: Sprachenentwicklung. Sprachentwicklung von SGML über HTML zu
XML. Quelle: [DLWZ03].
106
HTML
Die Hypertext Markup Language (HTML) basiert ursprünglich auf SGML (Standard
Generalized Markup Language) und liegt derzeit in der Version 4.01 vor. Die Sprache wird vom W3C (World Wide Web Consortium) standardisiert und weiterentwickelt. Neuere Versionen dieser Sprache basieren daher auf XML und dieses schlägt
sich ebenfalls in der Dokumentbezeichnung XHTML wieder. Aktuell wird an der Version 2.0 gearbeitet. Bis zur XHTML-Version 1.1 wurde nichts wesentliches am Funktionsumfang geändert. Nähere informationen zu XHTML und XML sind im folgenden
Abschnitt 6.3 beschrieben.
HTML-Dateien bestehen aus Text. Zur Textauszeichnung gibt es bestimmte Zeichen
aus dem normalen Zeichenvorrat. Der Inhalt von HTML-Dateien steht in Elementen, die durch so genannte Tags markiert werden. Fast alle HTML-Elemente werden
durch ein einleitendes und ein abschließendes Tag markiert. Der Inhalt dazwischen ist
der Gültigkeitsbereich des entsprechenden Elements. Tags werden in spitzen Klammern notiert. Listing 6.3 zeigt den Quellcode eines HTML 4.01 konformen HTMLDokumentes. Wie zu erkennen ist, ist das Dokument in zwei Abschnitte unterteilt.
Im <head>-Bereich befindet sich der Titel und optional lassen sich weitere Dateien
über den <link>-Tag einbinden sowie Metadaten anotieren. Im <body>-Bereich befindet sich der eigentliche Inhalt der Datei. Hier werden die Überschriften (<h1> / <h2>)
sowie Absätze (<p>) definiert. Des Weiteren werden Umlaute durch spezielle Sonderzeichen, wie z.B. ü durch ü ersetzt. Ebenfalls lassen sich Formeln nur schlecht
mittels weiniger Sonderzeichen darstellen.
1
2
3
4
5
6
7
8
9
10
11
<html>
<head>
< t i t l e >BBS V i r t u e l l − Fach M a t h e m a t i k< / t i t l e >
< l i n k r e l =" s t y l e s h e e t " href =" seminar_we . c s s "
type=" t e x t / c s s ">
< / head>
<body>
<h1>Fach M a t h e m a t i k< / h1>
<p>Auf d i e s e r S e i t e werden u n s e r e n Sch&uuml ; l e r n
r e g e l m&auml ; s s i g Formeln v o r g e s t e l l t und
e r k l&auml ; r t . < / p>
12
13
14
15
16
<h2> G l e i c h s e i t i g e s D r e i e c k < / h2>
<p>Die H&ouml ; he h e i n e s g l e i c h s e i t i g e n D r e i e c k s
b e r e c h n e t s i c h wie f o l g t : < / p>
<p>h = a / 2 &r a d i c ; 3 < / p>
17
18
19
20
21
<p><em> Formeln k&ouml ; nnen m i t t e l s HTML n u r s e h r
e i n g e s c h r&auml ; n k t d a r g e s t e l l t werden . < / em>< / p>
< / body>
< / html>
Literaturempfehlung: Spezifikation: [W3C05]; Einführung: [Mün01], [W3S05];
Fortgeschritten: [McC01], [Pem04].
107
XML
XML kann als Metasprache bezeichnet werden, mit der neue Markup-Sprachen definiert werden können. Es wurde vom W3C erfunden und gilt als Nachfolger von SGML.
Anhand der Auszeichnung eines XML-Dokumentes sind relativ leicht die Einflüsse aus
dem HTML-Bereich zu erkennen. Ziel bei der Entwicklung des Standards XML war
es, eine möglichst einfache und von Menschen wie auch Maschinen lesbare Sprache
zu definieren. Dies führt zwar zu Einbußen in Bezug auf die Kompaktheit der Darstellung der Daten, jedoch stehen diese Nachteile in keinem Verhältnis zu den Vorteilen
und Möglichkeiten, die diese Sprache bietet. Vom W3C wurden etliche Erweiterungen
und Hilfstechnologien rund um XML erfunden, z.B. Namespaces (Verwendung verschiedener Dokumenttypen in einem XML-Dokument), XML Schema (eine mächtigere Alternative zu DTDs), XPath (Adressierung von Knoten in einem XML-Dokument),
XQuery (SQL-ähnliche Suche in XML-Dateien) und XSL (eine Stylesheet-Sprache für
XML). Darüber hinaus hat das W3C Empfehlungen für XML-Anwendungen, das heißt
Markup-Sprachen, die auf XML basieren, veröffentlicht. Neben dem bereits erwähnten
XHTML als Neudefinition von HTML existieren Formate wie SVG (ein Vektorgrafikformat), SMIL (ein Format für Multimedia-Präsentationen), XSL-FO (eine Sprache für
das Druckseitenlayout), MathML (eine Sprache zur Darstellung von mathematischen
Formeln) oder WML (eine Seitenbeschreibungssprache für kleine, mobile Endgeräte).
Das Listing 6.3 zeigt ein XHTML Dokument. Dieses ist die Umwandlung des obigen
HTML-Dokumentes auf XML-Basis. Es werden zwei Namensräume deklariert, wobei
http://www.w3.org/1998/Math/MathML den Namensraum von MathML beschreibt, um
die Formel innerhalb des XHTML-Dokumentes korrekt darzustellen. Die Empfehlung
des W3C besteht darin, die neuere XML-Version von HTML zu benutzen.
1
2
<? xml v e r s i o n = " 1 . 0 " e n c o d i n g = "UTF−8" ? >
<? xml−s t y l e s h e e t t y p e = " t e x t / c s s " h r e f = " s e m i n a r _ w e . c s s " ?>
3
4
5
6
7
8
9
10
11
12
<html xmlns= " h t t p : / / www. w3 . o r g / 1 9 9 9 / x h t m l " l a n g = " de "
xmlns : math= " h t t p : / / www. w3 . o r g / 1 9 9 8 / Math / MathML" >
<head>
< t i t l e >BBS V i r t u e l l − Fach M a t h e m a t i k< / t i t l e >
< / head>
<body>
<h1> Fach M a t h e m a t i k< / h1>
<p>Auf d i e s e r S e i t e werden u n s e r e n ü S c h l e r n äß
r e g e l m i g Formeln v o r g e s t e l l t und ä e r k l r t . < / p>
13
14
15
16
17
18
19
20
21
22
23
24
<h2> G l e i c h s e i t i g e s D r e i e c k < / h2>
<p> Die öHhe h e i n e s g l e i c h s e i t i g e n D r e i e c k s b e r e c h n e t
s i c h wie f o l g t : < / p>
<p>
<math : math>
<math : mrow>
<math : mi>h< / math : mi>
<math : mo> = < / math : mo>
<math : m f r a c >
<math : mi>a < / math : mi>
<math : mrow>
108
25
26
27
28
29
30
31
32
33
34
35
<math : mn>2< / math : mn>
< / math : mrow>
< / math : m f r a c >
<math : m s q r t >
<math : mrow>
<math : mn>3< / math : mn>
< / math : mrow>
< / math : m s q r t >
< / math : mrow>
< / math : math>
< / p>
36
37
38
39
40
<p><em> Formeln öknnen m i t t e l s XHTML+MathML g u t
d a r g e s t e l l t werden . < / em>< / p>
< / body>
< / html>
Literaturempfehlung: Spezifikation: [W3C05]; Einführung: [GP98].
SCORM CAM
Das SCORM Content-Aggregation-Model (CAM) ist im eigentlichen Sinn kein explizites Dokumentenformat sondern spezifiziert, wie Dokumente zu einer Lerneinheit
zusammengefasst werden können, um diese in einem Learning-Management-System
mittels des SCORM Run-Time Environments (RTE) darzustellen. SCORM CAM besteht aus den drei Teilen Content-Model, Metadata-Model und Content-Packaging:
• Das Content-Model legt fest, wie verteilte, wieder verwendbare LernRessourcen zu Lerneinheiten aggregiert werden können. Dazu definiert es die
Komponenten Asset, Shareable Content Objects (SCO) und Content Aggregation.
• Mittels des Meta-Data Model erhalten alle Content-Model-Komponenten eine
genau spezifizierte Metadaten-Beschreibung ihrer individuellen Eigenschaften,
wie Thema, Autor, Inhalt, Grad der Interaktivität etc.
• Das Content Packaging u.a.: ein Manifest, welches Metadaten über das Package
selbst enthält, wie ein XML-basiertes Manifest zu erzeugen ist und Richtlinien
für das Packen des Manifests sowie aller physischen Dateien in z.B. eine ZIPDatei.
Betrachtet man die verwendeten Technologien zur Spezifikation dieses Standards, so
ist es interessant festzustellen, das dieser fast komplett mittels XML umgesetzt ist.
Listing 6.3 zeigt ein SCORM CAM Content-Packaging Manifest, mit dem sich die
Anordung von Dokumenten (Resourcen) ähnlich wie in einem Inhaltsverzeichnis organisieren läßt. Als Basis für die Resourcen wurden die beiden vorherigen Dokumente
gewählt.
1
<? xml v e r s i o n = " 1 . 0 " e n c o d i n g = "UTF−8" s t a n d a l o n e = " y e s " ? >
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
109
< m a n i f e s t i d e n t i f i e r = " s e m i n a r _ w e " v e r s i o n = " v0 . 1 "
xmlns= " h t t p : / / www. i m s g l o b a l . o r g / x s d / imscp_v1p1 " >
<metadata>
<schema>ADL SCORM< / schema >
< s c h e m a v e r s i o n >CAM 1 . 3 < / s c h e m a v e r s i o n >
</ metadata>
<organizations>
< o r g a n i z a t i o n i d e n t i f i e r = "AG_TOC" >
< t i t l e > L e r n e i n h e i t M a t h e m a t i k< / t i t l e >
<item i d e n t i f i e r =" item1 " i d e n t i f i e r r e f =" res1 ">
< t i t l e > M a t h e m a t i k Formeln i n HTML< / t i t l e >
< / item >
<item i d e n t i f i e r =" item2 " i d e n t i f i e r r e f =" r e s 2 ">
< t i t l e > M a t h e m a t i k Formeln i n XHTML< / t i t l e >
< / item >
</ organization>
</ organizations >
<resources >
< r e s o u r c e i d e n t i f i e r =" r e s 1 " h r e f =" seminar_we . html "
xml:base=" p r e s e r v e " type =" Asset " / >
< r e s o u r c e i d e n t i f i e r = " r e s 2 " h r e f = " s e m i n a r _ w e . xml "
xml:base=" p r e s e r v e " type =" Asset " / >
</ resources >
< / m a n i f e s t>
Hat man mittels eines Autorensystems oder per Hand mehrere Lernresourcen z.B. in
XHTML erstellt, so kann man diese mittels des Manifestes (imsmanifest.xml) organisieren. Hierzu legt man die zuletzt genannte Datei im selben Ordner des Dateisystems
ab und spezifiziert im <resources>-Abschnitt die relative URI zu den Resourcen. Danach folgt das Inhaltsverzeichnis im <oorganisation>-Abschnitt. Hat man diese Schritte
erledigt, so packt man das komplette Verzeichnis in eine zip-Datei und kann diese in
ein LCMS wie z.B. ATutor importieren.
Skriptsprachen
Da sich mittels HTML alleine keine dynamisch generierten Inhalte erzeugen lassen,
wird irgendeine Form von Scriptsprache benötigt. Diese werden oft zur Programmierung von Web-Applikationen eingesetzt, da mit relativ wenig Aufwand schnell gute
Ergebnisse erzielt werden konnen. Es gibt einige Skriptsprachen, die speziell für die
Entwicklung von Web-Applikationen entwickelt wurden, zum Beispiel PHP, ASP (beide serverseitig), JavaScript oder VBScript (beide clientseitig). Darüber hinaus existiert
die aus der UNIX-Welt bekannte Scriptsprache Perl, die aufgrund ihrer Textfunktionen
ebenfalls gut in webbasierten Anwendungen einsetzbar ist.
Die meisten freien webbasierten Lernplattformen, wie z.B. Stud.IP und Ilias sind mittels PHP umgesetzt. Die rekursive Abkürzung steht für PHP Hypertext Preprocessor.
Das Konzept dahinter ist, dass PHP-Code ähnlich wie JavaScript direkt in HTMLDateien an einer dafür geeigneten Stelle notiert werden kann. Wenn die HTML-Datei
110
dann im Web abgelegt ist und von einem Web-Browser aufgerufen wird, erkennt der
Web-Server, der die Datei zum Browser übermittelt, dass es sich nicht um eine gewöhnliche HTML-Datei handelt, sondern um eine HTML-Datei mit eingebettetem PHPCode. Eine solche Datei lässt er dann zunächst vom server-seitig installierten PHPInterpreter verarbeiten. Dieser liest in der HTML-Datei die PHP-Code-Passagen aus,
führt den Code aus und erzeugt daraus den endgültigen HTML-Code, der schließlich
an den Browser gesendet wird. Aufgrund der Einfachheit dieser Sprache und des frei
verfügbaren Quellcodes der genannten LMSe lassen sich relativ leicht Änderungen an
diesen vornehmen bzw. Erweiterungen für spezifische Anforderungen entwicklen. Ein
Beispiel zur Demonstration des Zugriffs auf eine Datenbank ist in Listing 6.3 zu finden.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
< html >
<head >
< t i t l e > K u r s t e i l n e h m e r l i s t e </ t i t l e >
</ head >
<body >
<table >
<th >
<td >
T e i l n e h m e r d e s S e m i n a r s Web E n g i n e e r i n g
</ t d >
</ t h >
<?
$ l i n k = mysql_connect (
" localhost " ,
" user " ,
" password " ) ;
mysql_select_db ( " BBSVirtuell " ) ;
$ r e s u l t = mysql_query (
" s e l e c t ∗ from T e i l n e h m e r where Kurs = ’we ’ " ) ;
while ( $ l i n e = mysql_fetch_array ( $ r e s u l t ) ) {
echo " < t r > " ;
foreach ( $ l i n e as $value ) {
echo " < t d > " . $ v a l u e . " </ t d > " ;
}
echo " </ t r > " ;
}
mysql_free_result ( $result );
mysql_close ( $link ) ;
?>
</ t a b l e >
</ body >
</ html >
Nachteile von Skriptsprachen sind die zumeist fehlende Typsicherheit der Variablen,
schlechte Möglichkeiten des Debuggings und Testens und die nicht immer gegebene
Skalierbarkeit von Anwendungen. Wenn es auf Ausfallsicherheit, große Benutzermengen oder Wartbarkeit ankommt, sollte besser eine richtige Programmiersprache wie
Java in Betracht gezogen werden.
111
Java-basierte Technologien
Java bietet eine Vielzahl APIs an, um flexible und skalierbare Komponenten professionell zu erstellen. Eine Auswahl dieser APIs im Folgenden kurz dargestellt.
Applets
Java-Applets können als kleine und abgesicherte Java-Applikationen betrachtet werden, die in einem Browser mittels Applet-Viewer angezeigt werden können. Hierfür
benötigt man eine Java-Laufzeitumgebung. Ein Applet ist kein eigenständiges Programm und besitzt daher keine Main-Methode. Alle Ein-und Ausgaben müssen daher
durch die grafische Benutzerschnittstelle des Applets realisiert werden. Des Weiteren
wird ein Applet im Browser nach dem Sandkastenprinzip (Sandbox) abgearbeitet. Das
bedeutet, es hat keine Rechte, auf Resourcen (wie z.B. Dateien etc.) des Clients zuzugreifen. Listing 6.3 zeigt ein Beispiel für ein Applet.
1
2
import j a v a . a p p l e t . A p p l e t ;
import j a v a . awt . G r a p h i c s ;
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
public c l a s s Simple extends Applet {
StringBuffer buffer ;
public void i n i t ( ) {
b u f f e r = new S t r i n g B u f f e r ( ) ;
addItem ( " i n i t i a l i z i n g . . . " ) ;
}
public void s t a r t ( ) {
addItem ( " s t a r t i n g . . . " ) ;
}
public void s t o p ( ) {
addItem ( " s t o p p i n g . . . " ) ;
}
public void d e s t r o y ( ) {
addItem ( " p r e p a r i n g f o r unloading . . . " ) ;
}
v o i d a d d I t e m ( S t r i n g newWord ) {
System . o u t . p r i n t l n ( newWord ) ;
b u f f e r . append ( newWord ) ;
repaint ();
}
public void p a i n t ( Graphics g ) {
g . d r a w R e c t ( 0 , 0 , s i z e ( ) . w i d t h −1 , s i z e ( ) . h e i g h t − 1 ) ;
g . drawString ( buffer . toString () , 5 , 15);
}
}
Im Browser können verschiedene Ereignisse ausgelöst werden, wie Webseite aufrufen, Fenster minimieren, Fenster maximieren, Webseite verlassen, nachdenen ein JavaApplet seinen Zustand ändert. Diese Zustandsänderungen schlagen sich in Funktions-
112
aufrufen der Applet-Klasse wieder: Wird die Webseite aufgerufen, auf der sich das
Applet befindet, wird dieses zunächst initialisiert init() und danach gestartet start().
Minimiert man nun das Fenster, so wird das Applet gestoppt stop(), maximiert man es,
wird es wieder gestartet start(). Verlässt man die Webseite, so wird das Applet wiederrum gestoppt stop() und schließlich aus dem Speicher gelöscht destroy().
Mit Hilfe dieser Methoden ist es im Kontext der LMSe möglich, die genaue Aufenthaltsdauer eines Lerners auf einer Webseite zu ermitteln. Anhand dessen läßt sich nachvollziehen, was für ein Zeitaufwand an einer bestimmten Lernresource betrieben wurde. Dieses Verfahren wird auch als Benutzer-Tracking bezeichnet.
Servlets und Java Server Pages
Im Gegensatz zu Java-Applets werden Java-Servlets und Java Server Pages serverseitig
abgearbeitet. Ein Servlet ist eine Java-Klasse, die die Möglichkeiten des Servers mittels
eines Request-Response Modells erweitert. Der Server, in dem das Servlet initialisiert,
gestartet und zerstört wird, wird als Servlet-Engine bezeichnet. Obwohl Servlets jeder Art von Request beantworten können, werden sie zumeist benutzt, um Anfragen
an einen Webserver über das HTTP Protokoll zu beantworten. Hierzu existieren die
Klasse HttpServlet, dessen Methoden doGet() und doPost() HTTP-spezifische Dienste
beantworten können. Eine bekannte HTTPServlet-Engine ist der Webserver Tomcat.
Java Server Pages (JSP) stellen einen Mechanismus zu Verfügung, um statische und
dynamische Webinhalte, ähnlich wie in PHP, einfach zu erstellen. Hierzu werden drei
Mechanismen zur Verfügung gestellt. Die wichtigste Funktion ist eine Sprache zur
Entwicklung von JSP-Seiten. Dies sind textbasierte Dokumente, die beschreiben, wie
ein Request verarbeitet und eine Antwort aussehen soll. An dieser Stelle erkännt man
die Ähnlichkeit zu Servlets, denn aus einer JSP-Seite wird von der Servlet-Engine dynamisch ein HTTPServlet generiert und abgearbeitet. Des Weiteren stellt die JSP API
eine sogenannte Expression-Language zur Verfügung, um auf serverseitige Objekte zuzugreifen. Als letzte wichtige Funktion ist die Möglichkeit zu nennen, Erweiterungen
zu JSPs in sogenannten Tag-Libraries zu erstellen.
Weitere Technologien
Dieser Abschnitt soll kurz weitereführende Technologien vorstellen, die in der JavaWelt auch unter Enterprise-Technologien bekannt sind. Hierzu gehören die zuvor vorgestellten Java-Servlets und JSPs und werden daher hier nicht näher berücksichtigt.
• JDBC: JDBC ist eine API zur Arbeit mit relationalen Datenbank-Systemen.
Diese erlaubt Java-Programmen SQL-Querys und Update-Statements zu einem
Datenbank-System zu schicken und ermöglicht es, durch die erhaltene Ergebnisliste zu iterieren. Des Weiteren kann man Metadaten über die Tabellen und
6.4. FAZIT
•
•
•
•
113
Datenbank an sich abfragen.
RMI: Das Kürzel RMI steht für Remote Method Invocation und ist ein
Programm-Modell, welches einem Client erlaubt, Methoden auf Objekten, die
auf einem entfernten Server liegen, aufzurufen. Dies geschieht in der gleichen
Syntax, wie es auch bei lokalen Methodenaufrufen der Fall ist. Aufgrund dessen
ist diese Technologie einfach zu nutzen.
IDL: RMI ist eine Löung für verteilte Objekte, die gut in Umgebungen funktioniert, wo Client und Server in Java geschrieben sind. Es funktioniert nicht in
heterogenen Umgebungen, wo Client und Server in unterschiedlichen Sprachen
implementiert sind. Hierfür existiert Java IDL, eine auf dem Standard CORBA
(Common Object Request Broker Architecture) basierte Lösung für dieses Problem.
JNDI: Das Java Naminig and Directory Interface ist die Schnittstelle im Umgang
mit Netzwerk Namens- und Verzeichnisdiensten. Es erlaubt Java Programmen
diese Dienste zu nutzen und Daten und Objekte anhand eines Namens aufzufinden und zu durchsuchen/benutzen.
EJB: Enterprise JavaBeans ist ein Komponenten-Modell für Einheiten von Businesslogik und -daten. In Thin-Client Modellen wird die Business-Logik in einen
extra Server der Mittelschicht ausgelagert, was einige Vorteile in Bezug auf die
Architektur ermöglicht. Das Entwickeln dieser Mittelschicht ist ein komplizierter Prozess, da dieser Quellcode mit Code zum Umgang mit Transaktionen, Sicherheit und Netzwerken gemischt werden muss. Das High-Level EJB-Modell
separiert die Businesslogik von den übrigen Aufgaben, sofern man sich an das
vorgegebene Framework hält.
6.4 Fazit
Diese Arbeit hat zunächst die grundlegenden Begriffe e-Learning und e-LearningSystem bzw. Lehr- und Lehrsystem erläutert und entsprechende Typen genannt. Um
gemäß des Ausgangsfalls eine Handlungsempfehlung auszusprechen, spielen webbasierte Lernplattformen, oder auch Learning-Management-Systeme (inklusive ihrer unterschiedlichen Ausprägungen LMS, LCMS, LAMS) genannt, eine große Rolle. Als
Handlungsempfehlung kann als erstes in Bezug auf die BBS-Virtuell festgehalten werden, dass es sich nicht lohnt, eine eigene Implementierung des gewünschten Systems
vorzunehmen, da dieses zu viel Arbeitsaufwand in Anspruch nimmt und gute, funktionstüchtige und kostengünstige Alternativen auf dem Markt existieren. Stattdessen ist
es sinnvoller, eine Evaluation mit anschließender Auswahl eines Systems durchzuführen.
Bezüglich der BBS-Virtuell ist das freie LCMS ATutor zu empfehlen. Dieses
ermöglicht den Import von standardisierten Lernmodulen und bietet umfassende
Kommunikations- und Informationsdienste. Um dieses System zu installieren, wird
ein sogenanntes LAMP-System (Linux, Apache, MySQL, PHP) auf einen Rechner
mit durchgehender Verbindung zum Internet benötigt, der aus Sicherheitsgründen vom
114
internen Netzwerk der Verwaltung getrennt sein sollte. Nach der Installation der Lernplattform ist eine Integration der Schüler-/Lehrerdaten aus den Verwaltungsdaten in
die MySQL-Datenbank ATutors von nöten. Hierbei sollten nur nicht sicherheitskritische Daten wie Vorname und Nachname berücksichtigt werden. Aus diesen Daten
kann ebenfalls ein Loginname und ein Passwort automatisch generiert werden, sodass
es möglich ist, sich an dem System anzumelden. Als letzter Schritt der Installation ist
optional eine Anpassung des Layouts an das Cooperate Design der Schule möglich.
Für den Installationsvorgang und die gegebenenfalls benötigte Anpassung des Systems
bieten die in Kapitel 6.3 vorgestellten Technologien eine Grundlage. In diesem Kapitel
spielt Abschnitt 6.3 eine besondere Rolle. Denn ist das System lauffähig fehlen die
Inhalte, die letztlich über die Annahme und damit den Erflog des Systems bei Schülern
und Lehrern entscheiden. Mit etwas Einarbeitung in die XML-basierten Technologien
und einem guten Editor sollte es auch technisch unversierten Benutzern möglich sein,
Lerninhalte zu erstellen und diese in das System einzupflegen. Nach diesen Schritten
kann das eingeführte System in den produktiven Betrieb gehen und dazu beitragen, die
kommunikativen und organisatorischen Probleme der berufsbildenen Schule zu lösen
und somit die Qualität der Lehre zu verbessern.
Kapitel 7
Kosten und Nutzen von
Wissensmanagementsystemen
für öffentliche
Bildungseinrichtungen anhand
des Beispiels „Berufsbildende
Schulen“
Stefan Bitzer
Inhalt
7.1
Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Zielsetzung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . 116
Begriffserklärungen . . . . . . . . . . . . . . . . . . . . . . . . . 117
7.2
Wissensmanagement in Bildungseinrichtungen . . . . . . . . . 118
Schulen als soziale Organisationen . . . . . . . . . . . . . . . . . 118
Grundvoraussetzungen an den Berufsbildenden Schulen . . . . . . 119
Gründe für den Einsatz von Wissensmanagementsystemen . . . . . 119
Funktionen eines Wissensmanagementsystems . . . . . . . . . . . 120
Motivation der Teilnehmer . . . . . . . . . . . . . . . . . . . . . . 124
Kosten eines Wissensmanagementsystems . . . . . . . . . . . . . 126
7.3
Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
115
116KAPITEL 7. KOSTEN/NUTZEN VON WISSENSMANAGEMENTSYSTEMEN
7.1 Einleitung
Problemstellung: Öffentliche Bildungseinrichtungen und Wissensmanagement
Die öffentlichen Bildungseinrichtungen werden heutzutage mit einer stetig anwachsenden Ausstattung an digitalen Medien konfrontiert. Neben Universitäten sind mittlerweile durch umfangreiche Ausstattungsinitiativen wie zum Beispiel der vom Bundesministerium für Bildung und Forschung (BMBF) und der Deutschen Telekom ins
Leben gerufenen Kampagne „Schulen ans Netz“, auch Schulen und Volkshochschulen
mit Computern und Internetzugängen ausgestattet (vgl. [Sch05]). Die Materialien der
Lehrkräfte und Dozenten sowie Hausarbeiten in von Schülern und Studenten digitalisierter Form wachsen immer weiter an. Gerade an öffentlichen Schulen und Volkshochschulen fehlt es jedoch häufig an einer geeigneten organisatorischen und technischen
Möglichkeit, diese Materialien sinnvoll zu archivieren und zu nutzen. Ein Management
der Wissenssammlung und des Wissensaustauschs ist erforderlich.
Während in der Wirtschaft „Wissensmanagement“ in aller Munde ist, wird im öffentlichen Bildungssektor die Nutzung dieses neuen Potenzials noch weitest gehend ausgeklammert. In Unternehmen hat sich mit dem Wissensmanagement ein organisatorisches Konzept entwickelt, um die Wissensnutzung zu optimieren. Die dafür entwickelten informations- und kommunikationstechnischen Werkzeuge lassen sich aber aufgrund verschiedener Faktoren nicht so einfach auf den öffentlichen Bildungsbereich
übertragen. Spätestens seit der Veröffentlichung der neuesten Ergebnisse der PISAStudie wird deutlich, dass eine breite Verteilung und Nutzbarkeit des individuellen
Fach- und Methodenwissens notwendig ist. Insbesondere Schulen als Bildungs- und
Lerneinrichtungen sind geradezu prädestiniert für die Erforschung der Wissenspotenziale und deren systematische Bereitstellung. Deutschland belegt leider mit 21% den
letzten Platz in der PISA-Studie bezüglich des Schüleranteils mit regelmäßiger schulischer Computernutzung. Der OECD-Durchschnitt liegt bei 39% (vgl. [Pis03])(siehe
Abb. 7.1). Es besteht also dringender Nachholbedarf in diesem Bereich.
Zielsetzung der Arbeit
Diese Arbeit beschäftigt sich mit dem Einsatz von Wissensmanagementsystemen an
öffentlichen Bildungseinrichtungen. Es soll aufgezeigt werden, welche Kosten und
Nutzen bei Einführung eines Wissensmanagementsystems an Berufsbildenden Schulen
anfallen, welche Besonderheiten beachtet werden müssen und welche Faktoren möglicherweise zu Problemen führen können. Es wird untersucht, welche Funktionen als
sinnvoll erachtet werden und welche Funktionalitäten eigentlich nicht notwendig sind.
7.1. EINLEITUNG
117
Abbildung 7.1: Schulische Computernutzung in Prozent
Begriffserklärungen: Wissensmanagement, Wissensmanagementsysteme
Im folgendem soll eine kurze Definition der wichtigsten Begriffe dieser Arbeit gegeben
werden. Wissensmanagement: Der Begriff Wissensmanagement wird im Zusammenhang mit Unternehmen in den Wirtschaftswissenschaften vielfach verschieden benutzt.
Eine relativ allgemeine Definition, und damit im Zusammenhang mit Bildungseinrichtungen brauchbar, von Wissensmanagement ist:
„Beim Wissensmanagement geht es um die Handhabung von Wissen; der
Begriff ist also anwendungsorientiert und multidisziplinär zu verstehen.
Wissensmanagement wird als Komplex von Steuerungsaufgaben verstanden, der alle Prozesse, Methoden und Strukturen einer Organisation umfasst, die sich mit Wissen befassen.“ (vgl. [Brü04])
Wissensmanagementsysteme: Ein Wissensmanagementsystem bildet die informationstechnische Unterstützung des Wissensmanagements. Da sich Wissensmanagement
mit der Handhabung und Verwendung von Wissen beschäftigt, ist ein Wissensmanagementsystem eine Software, die dieses Vorhaben ermöglichen und vereinfachen
soll. Grundsätzlich muss ein Wissensmanagementsystem folgende Ziele erfüllen (vgl.
[Ort02]):
• Systematischer Zugriff auf Wissen
• Systematische Nutzung von Wissen
• Teilung von Wissen, d.h. Wissenstransfer zwischen einzelnen Personen oder
Gruppen
• Zielgerichtete Entwicklung von Wissen
• Bewahrung von Wissen
• Entsorgung von unbrauchbarem Wissen
7.2 Wissensmanagement in Bildungseinrichtungen anhand des Beispiels „Berufsbildende Schulen“
Schulen als soziale Organisationen
Um die Rahmenbedingungen für ein Wissensmanagementsystem in Schulen besser zu
begreifen, muss man die spezifischen Bedingungen von Schulen als komplexe soziale
Organisationen verstehen. Dazu ist ein kurzer Blick in die Organisationstheorie notwendig.
Der von Cohen geprägte Begriff einer Organisation als Mülltonne („Garbage Can“)
lässt sich auch auf Schulen übertragen. Merkmale dieses Organisationstyps sind unter anderem unklare Ziele, unklare Verfahren, d.h. die ablaufenden Prozesse sind dem
Mitarbeiter häufig unklar, sowie zeitlich und inhaltlich schwankende Beteiligung. In
der „Mülltonne“ kommen unsortiert verschiedene Elemente vor, z.B. Probleme, fertige
Problemlösungen, Alternativen, Organisationsmitglieder mit wechselnden Zielen usw.
Dabei herrscht in der Mülltonne eine hohe Dynamik; Elemente kommen neu dazu,
vermischen sich und verschwinden (vgl. [Bre02]).
Das Schulsystem lässt sich als eine hierarchisch geordnete Bildungsverwaltung (äußere
Organisation) mit einer ausgeprägten Binnendifferenzierung (innere Organisation) beschreiben, die sich in verschiedenen Schulformen, Schulzweigen, Klassen und Kursen
ausdrückt (vgl. [Rol98]). Die Schule unterteilt sich in ein pädagogisches und ein administratives Teilsystem. Das pädagogische Teilsystem gliedert sich wiederum in Schulform, Fächergruppen usw. auf, während sich das administrative Teilsystem in Schulleitung, Stufenleitung usw. unterteilt. Trotz der grundsätzlich hierarchischen Struktur
gibt es nur eine eingeschränkte Kontrolle der Lehrkräfte. Erfolg oder Misserfolg eines
Lehrers sind schwer zu bestimmen und die Aufsichtsspanne ist mit einem Vorgesetzten
auf 50 Lehrer im Vergleich zu Unternehmen sehr gering. Von einigen Ausnahmen wie
Fachgruppen abgesehen, gibt es in der Schule kaum Organisationsstrukturen, die zwischen Kolleginnen und Kollegen vermitteln. Gleiches gilt für den Austausch zwischen
Schulen. Meist findet dieser nicht einmal mehr in derselben Kommune statt.
Grob resümierend lässt sich für Schulen sagen, dass viele Subsysteme bestehen, die
Kooperation innerhalb und zwischen einzelnen Schulen eher gering ist und eine hohe
Fluktuation seitens der Mitglieder vorherrscht.
7.2. WISSENSMANAGEMENT IN BILDUNGSEINRICHTUNGEN
119
Grundvoraussetzungen an den Berufsbildenden Schulen
Da in dieser Arbeit die Kosten und Nutzen eines Wissensmanagementsystems anhand
des Beispiels „Berufsbildende Schulen“ erarbeitet werden sollen, ist es konsequent,
die speziellen Grundvorrausetzungen in dieser Schulform zu analysieren. Dazu gilt es,
dass künftige Einsatzfeld des Systems genauer zu betrachten.
Die Berufsbildenden Schulen sind Teil der öffentlichen Bildungssystems. Laut Aussage des Bundesministeriums für Bildung und Forschung gibt es zurzeit 9850 Berufsbildende Schulen in Deutschland (vgl. [Bun04]). Sie dienen in erster Linie nicht der
Allgemeinbildung, sondern bieten eine berufsbezogene und praktische Lehre an. Die
Berufsbildenden Schulen gliedern sich typenhaft in fünf Bereiche auf:
• Berufsschule (berufsbegleitende Teilzeit-Pflichtschule für Auszubildende)
• Berufsaufbauschule (Teilzeitschule, die zur Fachschulreife oder Zugang zur Sekundarstufe II führt)
• Berufsfachschule (Vollzeitschule, die die praktische Berufsausbildung ersetzt)
• Fachschule (zur Erlangung der Fachhochschulreife nach einer Ausbildung; 2jährige Vollzeitschule)
• Berufliches Gymnasium (führt zur allgemeinen Hochschulreife)
Diese fünf verschiedenen Bereiche führen zu einem breit gefächerten Altersspektrum
bei den Schülern. Das Alter liegt im Durchschnitt zwischen 15 und 21 Jahren, wobei die Schüler meist zwischen einem (z.B. Berufsgrundbildungsjahr) und drei Jahren
(z.B. technisches Gymnasium) an der Schule verweilen. Ebenso wie das Altersspektrum ist auch Bildungsspektrum stark differenziert. Während einige Schüler lediglich
die Hauptschule besucht haben und nun das Berufsgrundbildungsjahr absolvieren, haben andere Schüler die Sekundarstufe 1 an einem normalen Gymnasium absolviert.
Bundesweit sind 95% alle Berufsbildenden Schulen mit insgesamt etwa 265 000 Computern ausgestattet. Durchschnittlich steht ein Computer für neun Schüler zur Verfügung, welches den Spitzenwert unter den Schulsystemen markiert (Grundschulen kommen auf 15 Schüler pro Rechner) (vgl. [Bun04]).
Gründe für den Einsatz von Wissensmanagementsystemen an Berufsbildenden Schulen
Der Hauptgrund, der Wissensmanagement auch für Schulen zu einem Thema gemacht
hat, ist die starke Entwicklung der Informations- und Kommunikationstechnologie.
Diese Entwicklung stellt erst die Vorraussetzung für den Einsatz eines Wissensmanagementsystems an Schulen, ist jedoch weder ein Grund für noch gegen eine Einführung.
Denn nur weil etwas theoretisch möglich ist, ist es praktisch noch lange nicht sinnvoll.
Was spricht also für einen solchen Einsatz?
Das Ziel eines Wissensmanagementsystems an einer Berufsbildenden Schule kann primär nur im Organisationszweck begründet sein. Dieser ist an einer Berufsbildenden
Schule die Vermittlung von fachbezogenem Wissen an Schüler. Die Erfüllung des Organisationszwecks durch eine solche Software an Schulen sieht Breiter in „der Verbesserung der Unterrichtsqualität durch den Einsatz digitaler Medien“ (vgl. [Bre02]). Man
kann jedoch sagen, dass ein Wissensmanagementsystem mehr dazu beitragen kann, als
die Verbesserung der Unterrichtsqualität. Es kann auch die Qualität der Hausarbeiten
verbessert werden, welches wiederum zur einer Steigerung des Schülerwissens führt
und somit auch direkt zum Organisationsziel beiträgt. Doch was im Speziellen kann
ein Wissensmanagementsystem zur Verbesserung des Unterrichts beitragen oder wie
kann es die Qualität der Hausarbeiten verbessern? Dazu schaue ich mir im folgenden
Abschnitt die allgemeinen Funktionen eines Systems im Hinblick auf Berufsbildende
Schulen an.
Funktionen eines Wissensmanagementsystems im Hinblick auf Berufsbildende Schulen
Im folgenden Kapitel werden die allgemeinen Funktionen eines Wissensmanagementsystems, ihr Nutzen und mögliche Anwendungsbeispiele für Berufsbildende Schulen
untersucht. Manche der hier aufgelisteten Funktionen greifen ineinander über, bzw.
überschneiden sich.
Diskussion
Die Diskussion ist eine Grundfunktion, die ein Wissensmanagementsystem erfüllen
sollte. Eine Diskussion soll dem kreativen Austausch von Wissen dienen (vgl. [Alta]).
Diese kann unterschiedlich im Programm implementiert sein. Einerseits kann eine Diskussion in Form eines Forums geführt werden. Es können dort verschiedene Unterdiskussionen geführt werden. Für diese Diskussionen können Gruppen und Berechtigungen gesetzt werden. Diese Funktion ist für GruppenProjektarbeiten sehr praktisch.
Die Kommunikation innerhalb der Gruppe kann so deutlich verbessert werden, die
Gruppe kann zeitversetzt arbeiten und sich immer über das Forum über den neusten
Stand austauschen. Ein weiteres reizvolles Anwendungsbeispiel wäre ein Bereich nur
für Lehrkörper, indem sie Unterrichtsideen austauschen und diskutieren können und
sich Hilfestellungen mit Problemschülern leisten können.
Fachbezogene Foren sind besonders für Schüler von Vorteil. In einem MathematikForum kann bei Problemen untereinander Hilfe gesucht und auf bereits vorhandene
Lösungen zurückgegriffen werden, Klausuraufgabenbeispiele können angeschaut und
ausgetauscht werden und eine bessere Vorbereitung auf Unterricht und Klausur ist
möglich.
Hier liegt speziell für Lehrkörper auch ein kleines Problem. Hausaufgabenlösungen
können von Schülern im Forum eingestellt werden und sind damit für andere Schüler leicht zugänglich. Ein Austausch von Lösungen war bereits vor Einführung eines
Wissensmanagementsystems möglich, z.B. durch einfaches Abschreiben oder Kopieren oder durch Verschicken der Lösungen per Email, nun wird dies deutlich einfa-
121
cher. Der Schüler sucht lediglich im Forum nach Lösungen und muss nicht einmal den
Schüler kennen, von dem er die Lösungen kopiert. Ebenso wie bei den Hausaufgaben
existiert dieses Problem bei Klausuren. Häufig verwendet ein Lehrer dieselbe oder nur
schwach abgewandelte Klausur über Jahre hinweg. Schreibt ein Schüler diese Klausur einmal auf und stellt sie im Forum bereit, können Schüler über eine längere Zeit
hinweg darauf zugreifen und der Lehrer wird gezwungen, seine Klausur neu zu konzipieren. Dies ist im Sinne seines Lehrauftrags, jedoch wird diese Mehrarbeit für den
Lehrer seine Motivation bezüglich des Wissensmanagementsystems senken. Die Veröffentlichung von Klausuren könnte man manuell verhindert, indem eine Person das
Forum regelmäßig nach nicht gewünschten Einträgen durchsucht.
Eine andere Möglichkeit der Diskussion bietet der Realtime Chat. Damit ist die zeitlich
synchrone Unterhaltung im Wissensmanagementsystem gemeint. Im Verlauf des Chats
aufkommende Fragen können sofort beantwortet und diskutiert werden. Dies führt zu
einer deutlich schnelleren Problemlösung, als es durch einen Emailverkehr möglich
wäre und mehrere Personen können sich zeitgleich einbringen. Nachteil im Gegensatz zur Forums-Diskussion ist, dass der Chat im Normalfall nicht gespeichert wird.
Lösungen und Ansätze gehen wieder verloren, falls sie nicht mitprotokolliert werden.
Wie auch im Forum kann auch der Chat themenartig unterteilt werden. Sinnvoll wäre
eine Aufteilung nach Fachrichtungen.
Blackboard
Beim Blackboard handelt es sich um ein virtuelles Schwarzes Brett. Es können Nachrichten für alle oder nur für bestimmte Personen hinterlassen werden. Dies kann vielfältig genutzt werden. Angefangen von allgemeinen Schulankündigungen (z.B. Bekanntmachung eines Schulfests, Aufruf zu einer Demonstration) bis hin zu Gruppenankündigungen oder einem aktuellen Vertretungsplan. Für einen Kurs kann eine Gruppe
eingerichtet werden und dann speziell für die eingetragenen Kursteilnehmer Nachrichten hinterlassen werden. Anwendungsbeispiele hierfür wären Mitteilungen über kurzfristige Raum-Änderungen, Unterrichtsausfall oder die Mitnahme von erforderlichem
Lernmaterial.
Bei der Einrichtung der Rechte muss darauf geachtet werden, dass nicht jeder Teilnehmer Nachrichten an alle Nutzer schicken kann. Eine mögliche Rechteaufteilung wäre,
dass nur bestimmte Schüler, z.B. Stufen- oder Schulsprecher, allgemeine Schulmitteilungen senden dürfen. Ansonsten sind diese Mitteilungen der Schulleitung und ausgewählten Lehrern vorbehalten. Damit kann die Gefahr eines Missbrauchs des Schwarzen
Bretts, z.B. die Falsch-Ankündigung eines Unterrichtsausfalls, minimiert werden.
Presse
Diese Funktion ist für die Verteilung von relevanter Presse innerhalb bzw. durch das
Wissensmanagementsystem zuständig. In diesem Bereich werden alle Arten von Presseberichten gesammelt. Sämtliche Teilnehmer des Wissensmanagementsystems, in unserem Fall also alle teilnehmenden Lehrer und Schüler, werden dadurch mit relevanten
Inhalten aus Zeitungen, Zeitschriften und Magazinen versorgt. Schülerzeitungen könn-
ten auf diesem Weg verteilt werden, ohne dass Druckkosten entstehen würden.
Dieser Bereich lässt sich vielfach in Berufsbildenden Schulen nutzen. Im Bereich Politik könnte z.B. eine Aufgabenstellung lauten, dass die Schüler sich alle Artikel zu
einem Thema über mehrere Wochen durchlesen sollen. Man kann nachher feststellen,
welcher User sich welche Dokumente angeschaut hat. So lässt sich von Anfang an sicherstellen, dass alle Schüler Zugriff zu denselben Artikeln haben und außerdem einen
gewissen Druck auf Schüler ausüben, da nachgewiesen werden kann, ob der Artikel
abgerufen wurde.
Virtuelle Bibliothek
Bei der virtuellen Bibliothek handelt es sich um eine Form von Dokumentenmanagement. Es werden alle vorhandenen Bücher, Fachzeitschriften, Veröffentlichungen und
andere relevante Unterlagen gespeichert. Diese können von den Schülern und Lehrern
entweder direkt in digitaler Form abgerufen werden oder sie erfahren den Standort
des jeweiligen Dokuments. Relevante Unterlagen und Veröffentlichungen könnten bei
Lehrern z.B. Formelsammlungen oder unterrichtsbegleitende Materialien sein und bei
Schülern z.B. Projektberichte und ausgewählte Referate. Im Gegensatz zur Knowledge
Base veröffentlichen in der Virtuellen Bibliothek nur wenige verantwortliche Personen
die Inhalte, auf die alle oder nur bestimmte Gruppen von Mitarbeitern Zugriff haben.
Diese Gruppen können z.B. in einem Berechtigungssystem eingestellt werden. So wird
der unerlaubte Einblick in entsprechende Unterlagen verhindert. Dies ist sinnvoll bei
Materialien, die nur für die Lehrkörper gedacht sind.
Des Weiteren kann die Dauer der Veröffentlichung gewählt werden, so dass ein Dokument nach einer vorher definierten Zeit nicht mehr aufgerufen werden kann oder
archiviert wird. Der zeitlich begrenzte Zugriff ist vor allem dann sinnvoll, wenn Schülern nur periodenweise die Nutzung bestimmter Dokumente gestattet werden soll.
Knowledge Base
Die Knowledge Base stellt eine Art themen-gesteuertern Informationspool im Wissensmanagementsystem dar (vgl. [Altb]). Mit themen-gesteuert ist gemeint, dass die
Informationen nach Themen strukturiert und aufgebaut sind. In Unternehmen dient die
Knowledge Base den Mitarbeitern dazu, gesammelte Erfahrungen, Berichte und entworfenen Konzepte zu sichern und allen Mitarbeitern im Intranet zugänglich zu machen.
Analog dazu kann die Knowledge Base in Berufsbildenden Schulen verstanden werden. Die Funktionsweise ist grundsätzlich ähnlich wie bei der oben beschriebenen virtuellen Bibliothek. Da hier jedoch sämtliche Teilnehmer Daten bzw. Dokumente aller
Art einstellen können, ist die Datenmenge deutlich größer und von anderer Qualität
als bei einer virtuellen Bibliothek. Der Anteil von unbrauchbaren oder doppelten Beiträgen ist viel ausgeprägter. Gerade in einer großen Datenmenge ist eine gute Struktur
wichtig, um noch schnell und einfach gewünschte Dokumente finden zu können.
123
Der Reiz der Knowledge Base, dass jeder seine Erfahrungen und Dokumente problemlos einstellen kann und so ein enormer Wissenspool entsteht, stellt bei den Berufsbildenden Schulen gleichzeitig ein Problem dar. Es wird an junge Schüler ein hoher
Anspruch gestellt. Zum einem sollten die eingestellten Daten qualitativ brauchbar und
zum anderen muss Einordnung in die Struktur korrekt sein. Denn trifft ein Nutzer bei
seiner Suche in der Knowledge Base häufig auf unbrauchbares oder ungewolltes Material, verliert er schnell die Lust an der Nutzung dieser Programmfunktion.
Yellow Pages
Wie der Begriff “Yellow Pages“ andeutet, handelt es sich hierbei um eine Art Gelbe
Seiten oder Kontaktverzeichnis für das Wissensmanagementsystem. Programmteilnehmer werden mit individuellen Kompetenzen, Projekterfahrungen und Arbeitsschwerpunkten versehen und so gespeichert. Ruft man eine bestimmte Person auf, werden
die dazugehörigen Informationen angezeigt. Neben den oben genannten Informationen
können in diesem Kontaktverzeichnis weitere nützliche Daten gespeichert werden, wie
z.B. ein Bild der Person, Sprechstundenzeiten, Email-Adresse und Telefonnummer,
wenn gewünscht. Personen können nun nicht nur durch ihren Namen gesucht, sondern
auch nach ihren Kompetenzen ausgewählt werden.
Gerade aufgrund der hohen Schülerfluktuation bei den Berufsbildenden Schulen ist
dies eine praktische Funktion. Neue Schüler können so unkompliziert herausfinden,
wer Vertrauenslehrer ist, wer Koordinator für die Wahlpflichtfächer ist, welcher Lehrer
welche Fächer und AG’s unterrichtet und anschließend per Email mit ihnen Kontakt
aufnehmen.
Überlegungen müssen angestellt werden, ob diese Yellow Pages für alle Teilnehmer
eingerichtet werden, also für Lehrer und Schüler, oder lediglich für Lehrer. Speziell bei
den Schülern kommt es bei dieser Funktion zu Problemen. Da die Kompetenzen von
der jeweiligen Person selbst eingetragen werden, kann sich jede Person jegliche Art
von Kompetenzen geben. Ein Schüler kann sich als Mathematik-Profi ausgegeben, hat
aber in der Realität große fachliche Lücken und gibt Hilfesuchenden Schülern falsche
oder unsinnige Antworten. Der komplementäre Fall wäre, dass ein Schüler fachlich
sehr bewandert ist und dies in seinem Profil angibt. Daraufhin wird er andauernd mit
vielen Anfragen konfrontiert, so dass er diese nicht mehr beantworten kann oder will.
Beide Fälle bringen den Beteiligten lediglich Frust und keinen Nutzen. Der Idealfall
wäre eine unter den Schülern ausgewogene Kompetenzverteilung, so dass im Durchschnitt jeder Schüler jedem hilft. Da dies in der Realität wohl nicht zu erwarten ist,
wäre es sinnvoller, die Yellow Pages nur für die Lehrer einzurichten und diese für alle
zugänglich zu machen.
Projekte
Die Funktion Projekte ist für ein wissensbasiertes Projektmanagement gedacht. Hier
können sich Projektteams einerseits in einem Groupwarebereich organisieren und andererseits in einem individuellen Bereich arbeiten. Zu den Groupware-Funktionalitäten
zählen unter anderem ein für alle Mitglieder einsehbarer Teamkalender, Email, Res-
sourcenverwaltung und Aktivitätenplanung. Im individuellen Projektbereich können
persönliche Dokumentationen abgelegt werden, die in einem Projekt entstehen, wie
Protokolle, Meilensteine, Berichte aller Art und Präsentationen. So soll gewährleistet
sein, dass alle Mitglieder verteilt Arbeiten können und trotzdem einen schnellen Zugang zu allen projektrelevanten Informationen und Terminen haben.
Wie hoch die Anzahl und Ausprägung von Projekten an Berufsbildenden Schulen in
der Realität ist, variiert sicherlich von Schule zu Schule. Allgemein kann man aber von
einer geringen Projekt-Intensitität an Berufsbildenden Schulen ausgehen, womit diese Funktionalität sicherlich seltener und in abgespeckter Form genutzt werden würde.
Während Teamkalender und Aktivitätenplanung durchaus sinnvoll sein können, sind
Ressourcenverwaltung und Meilensteine überflüssige Funktionen für kleine und unaufwändige Projekte. Es wäre eine Funktionsüberfrachtung und damit der Nutzung nicht
zuträglich.
Glossar
Bei einem Glossar handelt es sich um ein alphabetisch geordnetes Stichwortverzeichnis
mit jeweils kurzen Erläuterungen. Die im Glossar enthaltenen Informationen können
ganz verschiedener Natur sein. Zu einem Buchautor können die bekanntesten Werke
und Lebenszeit genannt werden, zu Grammatik- und Mathematik-Fachwörtern eine
kurze Beschreibung mit Beispiel, zu Kunststilen die Zeiten und wichtigsten Maler. Bei
kleineren aufkommenden Fragen kann dort schnell und gezielt nachgeschaut werden.
Motivation der Teilnehmer
„Im Mittelpunkt des Wissensmanagements steht der Mitarbeiter, ohne dessen aktive
Teilnahme Wissensmanagement nicht funktionieren kann“ [Sta04]. Was Staiger für
Unternehmen formuliert hat, gilt ebenso für öffentliche Bildungseinrichtungen. Damit
ein Teilnehmer an einem Wissensmanagementsystem partizipiert, muss der Teilnehmer
motiviert sein. Die besten Funktionen eines Systems sind nutzlos, wenn diese nicht genutzt werden oder für den Anwender zu kompliziert sind.
Generell gibt es zwei Möglichkeiten Teilnehmer zur Nutzung eines Systems zu motivieren(vgl. [Sta04]). Einerseits Bestrafung von „wissensmanagementsystemfeindlichen Verhalten“ (z.B. Boykottierung des Programms) oder Belohnung von „wissensmanagementsystemfreundlichen Verhalten“ (z.B. häufige Nutzung und Unterstützung
des Programms). Da Bestrafung fast immer Demotivation zur Folge hat, muss der Teilnehmer belohnt werden. Die motivierende Belohnung kann an einer Berufsbildenden
Schule vielfältig aussehen. Für Schüler und Lehrer kann dies Arbeitsvereinfachung,
Zeitersparnis und mehr Spaß an der Arbeit sein.
Die Motivation der Teilnehmer steigt, je geringer der persönliche Aufwand und je höher der persönliche Nutzen. Bei der Untersuchung der Motivation muss aufgrund der
verschiedenen Vorraussetzungen und Präferenzen bei Schülern und Lehrern unterschieden werden.
125
Der persönliche Aufwand für Schüler hängt von zwei Faktoren ab. Der erste Aufwand
ist, sich Zugang zum System zu beschaffen. Der Zugang ist einmal von privaten Rechnern per Internet sowie von Schulrechnern aus möglich. Beide Zugangsmöglichkeiten
sind bei Berufsbildenden Schulen im Vergleich zu anderen Schulen wie Grundschulen
sehr gut gegeben. Aufgrund des hohen Altersdurchschnitts haben viele Schüler privat
ein Rechner oder einen Rechnerzugang und die Berufsbildenden Schulen bieten eine
hohe Computeranzahl pro Schüler. Der zweite Aufwandsfaktor ist die Einarbeitung
und Nutzung des Systems. Die Pisastudie 2003 (vgl. [Pis03]) besagt für 15 Jährige,
dass Schüler und Schülerinnen grundsätzlich stark am Computer interessiert sind, aber
eher geringe Kompetenzen in diesem Bereich aufweisen. Ähnliches kann man für die
gesamte Schülerschaft an den Berufsbildenden Schulen annehmen. Die allgemeine Bereitschaft der Schüler zur Nutzung eines Wissensmanagementsystems ist also vorhanden. Das System muss aber möglichst simpel zu bedienen sein und, um die Motivation
zu erhalten, möglichst früh zu einem positiven Nutzen für den Benutzer führen. Um
Einarbeitungs- und Pflegezeit für das System gering zu halten, sollte die Bedienung
intuitiv erfolgen und nur wirklich genutzte Funktionen implementiert sein.
Der Nutzen für Schüler durch ein Wissensmanagementsystem kann unterschiedlich
ausfallen. Einmal kann der Nutzen im Zusammenhang mit Lernen und einmal Allgemein entstehen. Allgemeiner Nutzen ist z.B., dass der Schüler Hausarbeiten oder Projekte über die Software beim Lehrer abgeben kann und dies nicht persönlich machen
muss oder er kann den Vertretungsplan bereits zuhause abrufen und erfährt so frühzeitig einen möglichen Unterrichtsausfall. Dies sind Vorteile, die mit dem Lernvorgang an
sich nichts zu tun haben. Vorteile im Lern-Zusammenhang sind, dass der Schüler Probleme, unabhängig davon ob diese bei Hausarbeiten oder bei einer Klausurvorbereitung
auftreten, bequem online diskutieren und nachschlagen kann. Ein weiterer Vorteil ist
die Verbesserung der Zusammenarbeit in einem Projekt. Im besten Fall wird durch das
System die Lust am Lernen gesteigert.
Auch bei den Lehrern sind die Grundvorrausetzungen gut. Die meisten Lehrer haben
privat einen Rechner mit Internetzugang oder haben ansonsten in der Schule die Möglichkeit, auf das Softwaresystem zuzugreifen.
Der messbare persönliche Nutzen fällt für die Lehrer geringer aus. Durch den Austausch von Unterrichtskonzepten und Ideen kann die Unterrichtsvorbereitung verbessert und Zeit eingespart werden. Die Diskussion und der Austausch unter den Lehrern
kann zu einer Verbesserung der Unterrichts führen. Da Lehrer aber verbeamtet sind,
eine Verbesserung der Unterichtsqualität nur schwer messbar ist und, wie in Abschnitt
2.1 beschrieben, eine Kontrolle der Lehrer praktisch nicht vorhanden ist, fällt der Druck
von außen auf die Lehrer für eine Verbesserung des Unterrichts gering aus. Es muss
im persönlichen Anliegen des Lehrers liegen, seinen Unterricht zu verbessern, damit
dieses einen Nutzen für ihn darstellt.
Kosten eines Wissensmanagementsystems
Einmalige Kosten für ein OpenSourceWissensmanagementsystem
Die Kosten, die bei der Einführung eines Wissensmanagementsystems an einer Berufsbildenden Schule anfallen, kann man in einmalige und laufende Kosten unterteilen. Die
einmaligen Kosten setzen sich zusammen aus den Kosten für die Hardware, die Software und die Personalkosten für die Installation und Einführung des Systems.
Softwarekosten können durch die Nutzung eines OpenSourceWissensmanagementsystems vermieden werden. Dies wird in dieser Arbeit vorausgesetzt. Somit fallen nur
noch Hard- und Personalkosten an.
Die Hardwarekosten für ein solches System bestehen aus den Kosten für den Server,
die Clients und Netzwerkkosten. Da in den Schulen bereits in fast allen Fällen ein
schulinternes Netzwerk mit angeschlossenen Rechnern besteht, fallen als Client und
Netzwerkkosten lediglich die Internetkosten an. Diese hängen stark von der gewünschten äußerschulischen Nutz- und Erreichbarkeit ab. Soll die Software für eine größere
Schüleranzahl von außen verfügbar sein, reicht eine ISDN-Anbindung für den Server
nicht aus. Besonders für große Schulen ist eine Standleitung sinnvoll. Als Server kann
für die meisten Wissensmanagementsysteme ein bereits vorhandener Rechner benutzt
und umgebaut werden.
Als einmalige Personalkosten fallen die Arbeitszeit für die Installation und Einführung
des Systems an. Denkbar ist hier, dass ein Lehrer oder am besten ein kleines Team von
Lehrern dies ehrenamtlich übernimmt und keine eigentlichen Kosten entstehen. Der
genaue Zeitaufwand hängt von der Qualifikation der Personen und des Systemumfangs
ab und kann von daher für diese Arbeit nur schlecht geschätzt werden. Das alleinige
Aufsetzen der Software reicht aber nicht aus. Es müssen Benutzer eingegeben werden,
Foren eingerichtet und ein Grunddatenstamm in das System übertragen werden. Diese
benötigte Arbeitszeit geht in die laufenden Kosten über.
Laufende Kosten bei Nutzung eines Open-Source-Systems
Der größte Posten bei den laufenden Kosten ist das Personal. Je stärker ein Wissensmanagementsystem genutzt wird, desto mehr Nutzen können die Teilnehmer daraus
ziehen und umso größer wird die Motivation, selbst daran aktiv teilzunehmen. Eine
intensive Nutzung erfordert aber auch eine sorgsame Pflege des Systems. Besonders in
der Anfangszeit reicht es nicht aus, wenn der Systemadministrator einmal pro Woche
das System überprüft. Der Support für das System umfasst mehr. Die Virtuelle Bibliothek, die Diskussionen, die Knowledge Base usw. müssen unter anderem gepflegt und
von falschen Einträgen gesäubert werden. Nutzeranfragen müssen beantwortet und im
Falle eines Softwareproblems oder gar eines Systemabsturzes müssen diese Fehler behoben werden. Dies kann sehr zeitintensiv werden, da bei einem Open-Source-System
seitens der Hersteller im Gegensatz zu kommerzieller Software nur ein eingeschränkter
Support gegeben ist.
Die restlichen laufenden Kosten sind gering zu bewerten. Die Stromkosten für den
7.3. FAZIT
127
Server sind vernachlässigbar. Bleiben noch die monatlichen Kosten für die Internetanbindung.
7.3 Fazit
Ob die Einführung eines Wissensmanagementsystems an einer Berufsbildenden Schule sinnvoll und von Erfolg gekrönt ist, hängt ganz entscheidend von der Motivation und
Bereitschaft der Teilnehmer ab, und hier im Besonderen von den Lehrern. Den in Abschnitt 2.4 und 2.5 beschriebenen Nutzen und Vorteilen stehen Nachteile und Aufwand
gegenüber. Der Austausch von Hausaufgaben und Klausuren unter den Schülern durch
die Software könnte die Lehrer stören. Ein Appell an das Gewissen der Schüler, doch
bitte nicht die Hausaufgaben zu kopieren, da diese zu Lernen-Zwecken gedacht sind,
werden meines Erachtens in der Realität nur bei wenigen Teilnehmern fruchten. Auch
das zeitaufwendige Durchforsten des Systems nach gespeicherten Hausaufgaben kann
dieses Problem nicht endgültig lösen. Eine andere Möglichkeit wäre den Publizierern
der Hausaufgaben mit Sanktionen zu drohen. Dieser lässt sich leicht identifizieren, da
sich jeder Benutzer einloggen muss. Zu Bedenken ist, dass Bestrafung wiederum zur
Demotivation der Nutzer führt und damit für das Wissensmanagementsystem schädlich ist. Letztendlich sind diese „moralischen“ Probleme aber nicht über zu bewerten.
Das Kopieren von Hausaufgaben und Klausuren gab und gibt es auch ohne ein solches
Softwaresystem.
Resümierend bin ich der Meinung, dass ein OpenSourceWissensmanagementsystem
für Berufsbildende Schulen gut geeignet ist. Der Nutzen durch ein solches System
überwiegt meinem Erachten nach die Kosten. Wichtig ist, die Software nicht mit überflüssigen Funktionen zu überfrachten und sie leicht verständlich und übersichtlich zu
gestalten. In der Anfangszeit müssen die Lehrer probieren, die Schüler zur Teilnahme zu motivieren und sie von den Vorteilen zu überzeugen. Wird das System einmal
erfolgreich genutzt, kommt die weitere Motivation von selbst. Positiver Nebeneffekt
ist der Umgang der Schüler mit Computern, welcher in der aktuellen PISA-Studie als
zu gering bemängelt wird [Pis03]. In dieser Kategorie belegt Deutschland den letzten
Platz.
Die Altersstruktur der Schüler und die Computerausstattung an den Schulen selbst bieten eine gute Grundlage für die Einführung eines solchen Systems. Zu beachten ist
allerdings, dass nicht alle Schüler die Möglichkeit haben, von zuhause per Internet auf
die Plattform zuzugreifen. Das Wissensmanagementsystem muss also als Ergänzung
dienen. Schüler ohne Internetzugang dürfen nicht benachteiligt werden und es muss
immer die Möglichkeit vorhanden sein, auch ohne privaten Zugang die gestellten Aufgaben und Herausforderungen lösen zu können. Ein weiterer problematischer Punkt ist
die bunte Zusammensetzung der Schüler. Einige absolvieren dort ihr Abitur, andere lediglich ihr Berufsgrundbildungsjahr. Sie haben einen unterschiedlichen Bildungsstand,
Präferenzen und Lernmotivation. Schüler die die Schule nur kurz besuchen, haben eine
deutlich geringe Motivation sich in das Softwaresystem einzuarbeiten als „Langzeitschüler“. Für ehemalige Hauptschüler ist der Einarbeitungsaufwand deutlich höher als
für Gymnasiasten. All diese Faktoren muss man bei der Einführung und Nutzung eines
Softwaresystems bedenken. Was eine solche Konstellation in der Realität für ein Wissensmanagementsystem bedeutet, lässt sich nur durch ein Testprojekt herausfinden.
Abbildungsverzeichnis
1.1
Grundstein des Framework . . . . . . . . . . . . . . . . . . . . . . .
18
1.2
Angemeldeter Nutzer . . . . . . . . . . . . . . . . . . . . . . . . . .
18
1.3
Vollständiges Framework . . . . . . . . . . . . . . . . . . . . . . . .
19
2.1
Webservices Technology Stack . . . . . . . . . . . . . . . . . . . . .
32
2.2
Webservices Technology Stack . . . . . . . . . . . . . . . . . . . . .
32
2.3
E-Learning Framework . . . . . . . . . . . . . . . . . . . . . . . . .
35
2.4
OKI – Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
2.5
Abstract Framework – Schichtenmodell . . . . . . . . . . . . . . . .
38
3.1
Anwendungsfall „Stundenplan zusammenstellen“ . . . . . . . . . . .
50
3.2
Anw.-Fall „Stundenplan zusammenstellen“ mit Datenabhängigkeiten .
50
3.3
Anwendungsfälle des Lernenden . . . . . . . . . . . . . . . . . . . .
52
3.4
Anwendungsfälle des Lehrenden . . . . . . . . . . . . . . . . . . . .
53
3.5
Anwendungsfälle des Prüfers
54
3.6
Anwendungsfälle des Organisators
3.7
Anwendungsfälle der Verwaltung
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
55
. . . . . . . . . . . . . . . . . . .
56
4.1
Vorgehensmodell nach Dumke . . . . . . . . . . . . . . . . . . . . .
67
4.2
Vorgehensmodell nach Boles . . . . . . . . . . . . . . . . . . . . . .
69
4.3
Beispiel einer Web-Struktur . . . . . . . . . . . . . . . . . . . . . . .
70
4.4
Phasen des RMM-Modells . . . . . . . . . . . . . . . . . . . . . . .
73
129
130
ABBILDUNGSVERZEICHNIS
4.5
Grundsymbole der RMM-Methode . . . . . . . . . . . . . . . . . . .
74
4.6
ER-Diagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
4.7
Sichtendiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
4.8
RM-Diagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
4.9
Wasserfallmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
4.10 Spiralmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
5.1
Drei Kategorien von Autorenwerkzeuge . . . . . . . . . . . . . . . .
87
5.2
Matchware Mediator 7 Pro . . . . . . . . . . . . . . . . . . . . . . .
88
5.3
Macromedia Authorware 7 . . . . . . . . . . . . . . . . . . . . . . .
89
5.4
Macromedia Director MX 2004 . . . . . . . . . . . . . . . . . . . .
91
5.5
Macromedia Deamweaver MX 2004 mit CourseBuilder Erweiterung .
92
5.6
Dynamic Media - Dynamic PowerTrainer 2 . . . . . . . . . . . . . .
95
5.7
4Systems - WBTExpress4 FREE . . . . . . . . . . . . . . . . . . . .
96
5.8
4Sytsmes - WBTServer . . . . . . . . . . . . . . . . . . . . . . . . .
96
6.1
LAMS International . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
6.2
Sprachenentwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . 105
7.1
Schulische Computernutzung in Prozent . . . . . . . . . . . . . . . . 117
Tabellenverzeichnis
2.1
Anforderungen – Universität . . . . . . . . . . . . . . . . . . . . . .
25
2.2
Anforderungen – Schule . . . . . . . . . . . . . . . . . . . . . . . .
26
3.1
Beispiel für eine Use Case Template . . . . . . . . . . . . . . . . . .
57
3.2
Beschreibung des Anwendungsfalles „Suche nach Materialien“
57
131
. . .
132
TABELLENVERZEICHNIS
Literaturverzeichnis
[ADL04] ADL: Sharable Content Object Reference Model (SCORM) : Overview.
Standard 2nd ed., Advanced Distributed Learning (ADL), 2004.
http://www.adlnet.org/.
[Alta]
A LTAVIER: Produktbroschüren zum Knowledge Café.
http://www.altavier.de. Letzter Zugriff am 13.10.2005.
[Altb]
A LTAVIER: WM-Einführung.
WM-Einführung. Letzter Zugriff am 25.01.2005.
[ATRCA05] (ATRC) A DAPTIVE T ECHNOLOGY R ESOURCE C ENTRE: ATutor.
http://www.atutor.ca/, 2005.
[Aya04] AYALA , D IETRICH: NuSOAP.
http://dietrich.ganx4.com/nusaop, Mär 2004. Letzter Zugriff am 06.01.2005.
[BHMH02] BAUMGARTNER , P ETER, H ARTMUT H ÄFELE und KORNELIA M AIER H ÄFELE: Auswahl von Lernplattformen : Marktübersicht - Funktionen Fachbegriffe. Studienverlag, 2002. INF 033 CL 2391.
[Bol98] B OLES , D IETRICH: Multimedia-Systeme. Technischer Bericht, Universität
Oldenburg,
Skript-Multimedia.pdf, 1998.
[BP99] BAUMGARTNER , P ETER und S ABINE PAYR: Lernen mit Software. Studienverlag, 2nd Auflage, 1999. INF 033 CE 1904,2.
[Bre02] B REITER , A.: Wissensmanagementsysteme in Schulen oder: Wie bringe ich
Ordnung ins Chaos.
www.medienpaed.com/02-2/breiter1.pdf, 2002.
Letzter Zugriff am
25.01.2005.
[Bre03] B REMEN , U NIVERSITÄT: Software-Analysemethoden. Technischer Bericht,
Universität Bremen,
http://www.informatik.uni-bremen.de/agbs/lehre/ss03/swa/, 2003. Letzter
Zugriff am 06.01.2005, 14:00.
[Brü04] B RÜCHER , H.: Leitfaden Wissensmanagement, 2004. Zürich.
[Bun04] B UNDESMINISTERIUM
der Schulen.
FÜR
B ILDUNG
133
UND
F ORSCHUNG: IT-Ausstattung
LITERATURVERZEICHNIS
134
http://www.bmbf.de/pub/it-ausstattung_der_schulen_2004.pdf, 2004. Letzter
Zugriff am 25.01.2005.
[CC]
C ONSORTIUM C UTTER.
http://www.cutter.com, Letzter Zugriff am 17.01.2005.
[CER04] CERN: CERN.
http://www.cern.ch/, 2004. Letzter Zugriff am 06.01.2005.
[DAR04] DARPA: Defense Advanced Research Projects Agency – Home.
http://www.darpa.mil, Nov 2004. Letzter Zugriff am 06.01.2005.
[DC03] DANNY C OWARD , Y UTAKA YOSHIDA: JavaTM Servlet Specification Version 2.4. Technischer Bericht 2.4, Sun Microsystems, 4150 Network
Circle,Santa Clara, CA 95054, USA, Nov 2003.
[DLWZ03] D UMKE , R EINER, M ATHIAS L OTHER, C ORNELIUS W ILLE und F RITZ
Z BROG: Web Engineering. Pearson Studium, 1 Auflage, 2003.
[EC01] E RIK C HRISTENSEN , F RANCISCO C URBERA , G REG M EREDITH: W3C
Web Service Definition Language (WSDL).
http://www.w3c.org/TR/wsdl, Mär 2001. Letzter Zugriff am 06.01.2005.
[ELW03] E NGELS , G REGOR, M ARC L OHMANN und A NNIKA WAGNER: Prozess der
Entwicklung von Web-Anwendungen. Technischer Bericht, Universität Paderborn,
ProzessWebanwendungen-2003-07-30-d-Final-1.pdf, 2003.
[ESPITI] I NITIATIVE E UROPEAN S OFTWARE P ROCESS I MPROVEMENT T RAINING.
http://www.esi.es/VASIE/Reports/All/11000/Download.html, Letzter Zugriff
am 17.01.2005.
[Fou04a] F OUNDATION , A PACHE S OFTWARE: Apache HTTP Server Project.
http://httpd.apache.org/, 2004. Letzter Zugriff am 06.01.2005.
[Fou04b] F OUNDATION , A PACHE S OFTWARE: Apache Software Foundation.
http://www.apache.org/, 2004. Letzter Zugriff am 06.01.2005.
[Fou04c] F OUNDATION , A PACHE S OFTWARE: Apache Web Services Project – AXIS.
http://ws.apache.org/axis/, 2004. Letzter Zugriff am 06.01.2005.
[Fre]
F REIBICHLER , H ANS: Autorenwerkzeuge für Learning Content.
http://www.fts-heidelberg.de/k-5-3.pdf. Letzter Zugriff am 20.02.2005.
[GLC]
C ONSORTIUM G LOBAL L EARNING.
http://www.imsglobal.org, Letzter Zugriff am 17.01.2005.
[GMB05] GMBH, DATA Q UEST: Stud.IP.
http://www.studip.de/, 2005.
[GP98] G OLDFARB , C HARLES F. und PAUL P RESCOD: The XML Handbook. Prentice Hall, 1998.
[Haa04] H AAS , H UGO: W3C Webservices Activity.
http://www.w3c.org/2002/ws, Nov 2004. Letzter Zugriff am 06.01.2005.
[Hae]
H AEFELE , H ARTMUT: Autorenwerkzeuge für Learning Content.
Learning-Content-Autorenwerkzeuge.pdf. Retrieved 2005-02-20.
[IEE]
IEEE.
http://www.ieee.org, Letzter Zugriff am 17.01.2005.
135
[IMS04a] IMS: IMS Global Learning Consortium.
http://www.imsglobal.org/, Nov 2004. Letzter Zugriff am 06.01.2005.
[IMS04b] IMS: IMS Question & Test Interoperability Specification.
http://www.imsglobal.org/question/index.cfm, Okt 2004. Letzter Zugriff am
06.01.2005.
[IMS04c] IMS: IMS Simple Sequencing Specification.
http://www.imsglobal.org/simplesequencing/index.cfm, Okt 2004. Letzter
Zugriff am 06.01.2005.
[Inc05a] I NC ., B LACKBOARD: Blackboard.
http://www.blackboard.com/, 2005.
[Inc05b] I NC ., W EB CT: WebCT.
http://www.webct.com/, 2005.
[Int05]
I NTERNATIONAL , LAMS: Learning Activity Management System (LAMS).
http://www.lamsinternational.com/, 2005.
[JBo04] JB OSS: JBoss Professional Open Source Company.
http://www.jboss.org, 2004. Letzter Zugriff am 06.01.2005.
[KPR03] K APPEL , G ERTI, B IRGIT P RÖLL und S IEGFRIED R EICH: Web Engineering.
Dpunkt Verlag, 2003.
[Köl05] KÖLN , U NIVERSITÄT: Ilias.
http://www.ilias.uni-koeln.de/, 2005.
[LTS04] LTSC, IEEE: IEEE Learning Technology Standards Committee.
http://ltsc.ieee.org, 2004. Letzter Zugriff am 06.01.2005.
[McC01] M C C ARRON , S HANE: XHTML Modules and Markup Languages.
http://www.w3.org/MarkUp/Guide/xhtml-m12n-tutorial/, 2001.
[MG03] M ARTIN G UDGIN , M ARC H ADLEY, N OAH M ENDELSOHN: W3C SOAP
Version 1.2 Part1: Messaging Framework.
http://www.w3c.org/TR/soap12-part1, 2003. Letzter Zugriff am 06.01.2005.
[Mic04] M ICROSYSTEMS , S UN: Sun Microsystems.
http://www.sun.com, Nov 2004. Letzter Zugriff am 06.01.2005.
[Min02] M INASS , E RIK: Dimensionen des E-Learning: Neue Blickwinkel und Hintergründe für das Lernen mit dem Computer. Kilchberg: SmartBooks, 2002.
[MIT04] MIT: Stellar Course Management System.
http://stellar.mit.edu, 2004. Letzter Zugriff am 06.01.2005.
136
[MR03] M ARK ROTH , E DUARDO P ELEGRÍ -L LOPART: Java Server PagesTM Specification Version 2.0. Technischer Bericht 2.0, Sun Microsystems, 4150 Network Circle,Santa Clara, CA 95054, USA, Nov 2003.
[MS02] M AYR , P ETER und S ABINE S EUFERT: Fachlexikon e-le@rning : Wegweiser
durch das e-Vokabular. managerSeminare, 2002.
[Müh01] M ÜHLHÄUSER , P ROF. D R . M AX: Web-Based Training (in German). In:
B ECK , U. und W. S OMMER (Herausgeber): Learntec 2001, Seiten 191–201.
Learntec 2001, Holler Karlsruhe, 2001.
[Mün01] M ÜNZ , S TEFAN: SelfHTML - HTML-Dateien selbst erstellen.
http://de.selfhtml.org/, 2001.
[Nar]
NARMONTAS , S TEVE: Manhatten-LMS.
http://manhattan.sourceforge.net/. Letzter Zugriff am 10.10.2005.
[Net04] N ETCRAFT: Web Server Survey Archives.
http://news.netcraft.com/archives/web_server_survey.html, Nov 2004. Letzter Zugriff am 19.11.2004.
[NF96a] N. F REED , N. B ORENSTEIN: RFC 2046 – Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types.
http://www.ietf.org/rfc/rfc2046.txt, Nov 1996.
Letzter Zugriff am
06.01.2005.
[NF96b] N. F REED , N.B ORENSTEIN: RFC2045 – Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies.
http://www.ietf.org/rfc/rfc2045.txt, Nov 1996.
Letzter Zugriff am
06.01.2005.
[oL]
L OUVAIN , C ATHOLIC U NIVERSITY OF: Claroline LMS.
http://www.claroline.net. Letzter Zugriff am 10.10.2005.
[Ope04] O PEN , OASIS: OASIS Open.
http://www.oasis-open.org, Nov 2004. Letzter Zugriff am 06.01.2005.
[Org05] O RGANISATION , M OODLE: Moodle.
http://www.moodle.org/, 2005.
[Ort02] O RTNER , J.: Barrieren des Wissensmanagement, ?Anwendungsorientiertes
Wissensmanagement: Ans?tze und Fall- studien aus der betrieblichen und
der universit?ren Praxis?, Wiesbaden 2002. In: Anwendungsorientiertes Wissensmanagement: Ansätze und Fallstudien aus der betrieblichen und der universitären Praxis, Kapitel Barriere des Wissensmanagement. M. Bornemann;
M. Sammer, 2002.
[PEA04] PEAR: PHP Extension and Application Repository.
http://pear.php.net, Aug 2004. Letzter Zugriff am 06.01.2005.
[Pem04] P EMBERTON , S TEVEN: XML Events for HTML Authors.
http://www.w3.org/MarkUp/2004/xmlevents-for-html-authors, 2004.
137
[Pis03] P ISA: Pisa 2003 - Zusammenfassung.
http://pisa.ipn.uni-kiel.de/Ergebnisse_PISA_2003.pdf, 2003. Letzter Zugriff
am 25.01.2005.
[Pro04] P ROJECT, S AKAI: Sakai Project.
http://www.sakaiproject.org, 2004. Letzter Zugriff am 06.01.2005.
[RF99] R. F IELDING , J. G ETTYS , J. M OGUL: RFC2616 – Hypertext Transfer Protocol – HTTP/1.1.
http://www.ietf.org/rfc/rfc2616.txt, Jun 1999. Letzter Zugriff am 06.01.2005.
[Rol98] ROLFF , H.-G.: Manual Schulentwicklung – Handlungskonzepte zur pädagogischen Schulentwicklungsberatung, 1998. Basel.
[Sch97] S CHULMEISTER , P ROF. D R . ROLF: Grundlagen hypermedialer Lernsysteme. Oldenbourg, 1997.
[Sch02] S CHULMEISTER , ROLF: Grundlagen hypermedialer Lernsysteme : Theorie Didaktik - Design. Oldenbourg, 2002. INF 836 CC 8189,3.
[Sch05] S CHULEN -A NS -N ETZ E .V.: Schulen-Ans-Netz Histortie.
http://www.schulen-ans-netz.de/san/historie/index.php, 2005. Letzter Zugriff
am 13.10.2005.
[SH99] S TAHLKNECHT, P ETER und U LRICH H ASENKAMP: Einführung in die Wirtschaftsinformatik. Springer-Verlag, 9 Auflage, 1999.
[Som01] S OMMERVILLE , I AN: Software Engineering.
International Computer
Sciences Series. Addison-Wesley, Harlow, UK, 6 Auflage, 2001.
[Sta04] S TAIGER , M.: Anreizsysteme im Wissensmanagement. In: Wissensmanagement komplex: Perspektiven und soziale Praxis. Wyssusek, B., 2004.
[stu]
OSDL-Linux-Market.
http://www.osdl.org/docs/linux_market_overview.pdf.
[SW04] S COTT W ILSON , K ERRY B LINCO , DANIEL R EHAK: An e.Learning Framework – A Summary.
http://www.jisc.ac.uk/uploaded_documents/Altilab04-ELF.pdf, Jul 2004.
Letzter Zugriff am 06.01.2005.
[Tea04] T EAM , J IGSAW: Jigsaw - W3C’s Server.
http://www.w3.org/Jigsaw/, Nov 2004. Letzter Zugriff am 06.01.2005.
[Uni04] U NIVERSITY, S TANFORD: Stanford University Course Work.
http://coursework.stanford.edu, 2004. Letzter Zugriff am 06.01.2005.
[W3C05] World Wide Web Consortium (W3C).
http://www.w3c.org/, 2005.
[W3S05] W3 Schools - Full Web Building Tutorials.
http://www.w3schools.com/, 2005.
[WI04] WS-I: Web Services Interoperability Organization.
http://www.ws-i.org, Nov 2004. Letzter Zugriff am 06.01.2005.
138
[wwwa] Der Schockwellenreiter.
http://www.schockwellenreiter.de/. Letzter Zugriff am 10.10.2005.
[wwwb] Google.
http://www.google.de.
[wwwc] Wikipedia.
http://de.wikipedia.org.
[wwwd] Yahoo.
http://www.yahoo.de.
Zusammenfassung
Der vorliegende Seminarband entstand im Rahmen des Seminars „Web Engineering –
Entwicklung von Lehr- und Lernsystemen“ im Wintersemester 2004/05 an der Carl
von Ossietzky Universität Oldenburg. Schwerpunkt der Lehrveranstaltung war eine
inhaltliche Auseinandersetzung mit den Themengebieten Grundlagen von Lehr- und
Lernsystemen, Systemarten des E-Learning und Entwicklungsaspekte für E-LearningSysteme.
Die unterschiedlichen Zielvorstellungen des Web Engineerings bzw. Web Designs müssen bei der Entwicklung, Auswahl und Einführung webbasierter Lehrund Lernsysteme immer differenziert berücksichtigt werden. Um den professionellen Einsatz nachhaltig zu unterstützen, ist zumindest ein minimales Grundverständnis für die Entwicklungstechnologien unerlässlich. Die hier zusammengeführten Einzelbeiträge geben dabei erste Hilfestellungen und sollen unter der URL
http://www.informatik-politik.de zu weiteren Diskussionen anregen. Ich lade Sie daher herzlich ein, mein Vorhaben mit einem aktiven Beitrag (Vortragsfolien, Referat,
URL, ...) zu unterstützen.
Abstract
This turorial transcript originates from the seminar: „Web Engineering – Development of Teaching- and Learning Systems“ in winter semester 2004/2005 at Carl-vonOssietzky University of Oldenburg. Focus of the tutorial was a discussion in contents
on the topic of fundamentals of development of teaching- and learning systems, types
of E-Learning and development aspects for E-Learning systems.
The different general targets of web engineering respectively web design have to be
considered in detail when it comes to development, choice and implementation. To
support a professional insertion effectively a minimal basic understanding of development technologies is necessary. The chosen articles are meant as a support to the topic
and as an inspiration to discuss issues on http://www.informatik-politik.de as well. You
are cordially invited to support my project with an active contribution (article, presentation foils, paper, URL etc)
ISBN 3-8142-0991-5

Webbasierte_ Lehr_und_Lernsysteme

Transcription

Documents pareils

bluepage-systemanforderungen_de

Traffic Control Sys.

Stellenausschreibung - ZDV - Johannes Gutenberg

Apache 866/2

Webservices - Department of Information Systems

Den Apache2 Webserver absichern - Digital

Medieninformation

Produkt - Messe Stuttgart

TypingMaster für LMS Setup Guide

Webserver Fall (W1/W2)