Document [original]

Dissertation

Spezifikation und Entwicklung

universit¨

arer Lern- und

Arbeitsumgebungen

Dipl. Wirt.-Inform. Alexander Roth

Schriftliche Arbeit zur Erlangung des akademischen Grades

doctor rerum politicarum (dr. rer. pol.)

im Fach Wirtschaftsinformatik

eingereicht an der

Fakult¨

at f¨

ur Wirtschaftswissenschaften der

Universit¨

at Paderborn

Paderborn, im August 2008

Gutachter:

1. Prof. Dr. Leena Suhl

2. Prof. Dr. Ludwig Nastansky

F¨

ur Anke und Henrike

Zusammenfassung

Universit¨

aten der Wissensgesellschaft stehen derzeit unter immensen Druck, mehr Wis-

sen und Handlungskompetenz schneller an eine gr¨

oßere und zunehmend inhomogener

werdende Zielgruppe zu vermitteln. Daher m¨

ussen zum einen die Kernprozesse der Wis-

sensorganisation effizienter und effektiver gestaltet werden, zum anderen m¨

ussen Lehr-

und Lernprozesse die Schl¨

usselkompetenzen heutiger Wissensarbeiter f¨

ordern, um Stu-

dierende auf den Arbeitsmarkt vorzubereiten.

Geleitet von der Fragestellung, wie die daraus resultierenden neuen Anforderungen

durch universit¨

are IT-Infrastrukturen unterst¨

utzt werden k¨

onnen, wird in dieser Thesis

eine Alternative zu den klassischen monolithischen Lernplattformen aufgezeigt: Eine

komponentenorientierte Systemarchitektur mit einem Kern zur Unterst¨

utzung zentraler

Dienste, auf den neue Anwendungen sowohl f¨

ur klassisches E-Learning als auch f¨

selbstorganisierte und kooperative Szenarien medienbruchfrei aufgesetzt werden k¨

onnen.

Die vorliegende Arbeit fokussiert dabei die interdependente Spezifikation und Ent-

wicklung der zentralen Plattform und der darauf basierenden Anwendungen. Dazu wer-

den drei Ziele erarbeitet: (1) Definition einer kontrollierten Sprache (Normsprache) zur

Verbesserung der hochschulweiten Spezifikation von Lern- und Arbeitsszenarien. (2)

Konzeption einer komponentenorientierten Rahmenarchitektur, die f¨

ur verschiedenste

(verteilte) E-Learning-Anwendungen eine geeignete Standardplattform darstellt und die

in die vorhandene universit¨

are IT-Infrastruktur integriert ist. (3) Konstruktion eines

methodischen Vorgehens zur Realisierung von Standardplattform und darauf basieren-

der E-Learning-Anwendungen unter Ber¨

ucksichtigung des gew¨

ahlten normsprachlichen

Ansatzes und der konzipierten Rahmenarchitektur.

Zuletzt wird beschrieben, wie dieser Ansatz durch die ko-aktive Lern- und Arbeits-

plattform koaLA an der Universit¨

at Paderborn erfolgreich in die Praxis umgesetzt wurde.

Abstract

The universities within today’s knowledge society face enormous pressure to impart more

knowledge and operational competence in less time to a target group that grows larger

and more inhomogeneous. Therefore the core processes of knowledge organisation have

to become more effective and efficient. In order to prepare students for the job market,

also the methods of teaching and learning must encourage the core competencies that

are necessary for today’s knowledge workers.

Addressing the issue of how university IT-infrastructures can support the resulting

new requirements, this thesis presents an alternative to the classic monolithic learning

platforms: A component-oriented system architecture with a server core that not only

facilitates central functions but which can also be complemented with new services for

traditional e-learning and also for self-organised and cooperative scenarios. This thesis

thereby focuses on the interdependent specification and development of this central plat-

form and the belonging applications. For that purpose three objectives are identified: (1)

Defining a controlled language that — within the whole university – improves specifica-

tion of learning and working scenarios. (2) Conceptual design of a component-orientated

architectural framework, which functions as a standard platform for a variety of shared e-

learning applications and is also integrated into the existing university IT-infrastructure.

(3) Developing a methodical approach for implementing the standard platform and the

belonging applications in accordance with the chosen controlled language approach and

the architectural framework.

The last part of this thesis describes the successful implementation of this approach

in the cooperative learning and working platform koaLA at the university of Paderborn.

vii

viii

Danksagung

Die vorliegende Thesis entstand w¨

ahrend meiner Zeit als wissenschaftlicher Mitarbeiter

am DS&OR-Lab der Universit¨

at Paderborn, in der ich in verschiedenen Verbundpro-

jekten und Arbeitsgruppen im Bereich neuer Medien in der Bildung sowie in Projekten

zur IT-Infrastrukturentwicklung an Hochschulen mitgewirkt habe. Mein eigenes Pro-

jekt ”Promotion“ wurde dabei durch die fachliche und freundschaftliche Unterst¨

utzung

verschiedener Personen erm¨

oglicht, denen ich an dieser Stelle daf¨

ur danken m¨

ochte.

Allen voran gilt mein Dank Prof. Dr. Leena Suhl f¨

ur die Gelegenheit zur Promotion

und f¨

ur die Betreuung dieser Arbeit. Ihre grunds¨

atzliche Unterst¨

utzung meines Vorha-

bens, die mir dazu ¨

uberlassenen Freir¨

aume und ihre stets f¨

orderlichen Anmerkungen

haben entscheidend zum Gelingen beigetragen. Prof. Dr. Ludwig Nastansky danke ich

f¨

ur die freundliche ¨

Ubernahme des Zweitgutachtens.

Ganz großer Dank geb¨

uhrt Prof. Dr. Thorsten Hampel, der meine Arbeit lange Zeit

durch anregende Diskussionen, Denkanst¨

osse und auch dar¨

uber hinaus gef¨

ordert und ge-

pr¨

agt hat. Die Zusammenarbeit mit ihm und seinem Team war mir stets ein Vergn¨

ugen.

Bedanken m¨

ochte ich mich auch bei allen Mitarbeitern des Locomotion-Projektes, die

dazu beigetragen haben, die aus dieser Arbeit hervorgegangene koaLA-Lernumgebung

erfolgreich zu einem hochschulweiten Angebot auszuweiten. Stellvertretend seien hier

namentlich Dr. Gudrun Oevel, Andreas Brennecke und Ren´e Sprotte genannt.

In meinen Dank einschließen m¨

ochte ich auch meine aktuellen und ehemaligen Kolle-

gen am DS&OR-Lab f¨

ur die freundliche Atmosph¨

are und die st¨

andige Bereitschaft zum

Erfahrungsaustausch zum Thema Promotion. Vielen Dank an Dr. Markus Toschlaeger

f¨

ur seine wertvollen Tipps zum Aufbau der Arbeit.

Dr. Claus Biederbick und Ren´e Sprotte haben mich durch Korrekturlesen und ¨

uberaus

konstruktiven Anmerkungen bei der finalen Revision der Arbeit unterst¨

utzt. F¨

ur diesen

nicht selbstverst¨

andlichen Freundschaftsdienst bedanke ich mich herzlich.

Besonderen Dank schulde ich meiner Familie. Meine Frau Anke hat hierf¨

ur nicht nur

auf unz¨

ahlige gemeinsame Stunden verzichtet, sondern mir dar¨

uber hinaus immer den

n¨

otigen R¨

uckhalt gegeben und mich motiviert. Auch meine Mutter hat mich durch

Korrekturlesen unterst¨

utzt.

Nicht nur meiner Mutter, sondern ebenfalls meinem Vater geb¨

uhrt letztendlich mein

gr¨

oßter Dank: Meine Eltern haben meine gesamte Ausbildung bis zur Promotion im-

merw¨

ahrend und vorbehaltlos unterst¨

utzt. Ohne sie w¨

are all dies nicht m¨

oglich gewesen.

Danke!

Paderborn, im August 2008 Alexander Roth

Inhaltsverzeichnis

Abbildungsverzeichnis xvi

Tabellenverzeichnis xvii

Abk¨

urzungsverzeichnis xix

1. Einleitung 1

1.1. Szenario: Wissensgesellschaft und Hochschulbildung . . . . . . . . . . . . 1

1.2. Motivation der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3. Problembeschreibung und Zielsetzung der Arbeit . . . . . . . . . . . . . . 7

1.4. Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.5. Wissenschaftlicher Beitrag . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2. Beschreibung des Problembereichs und der Einflussfaktoren 15

2.1. E-Learning an deutschen Hochschulen . . . . . . . . . . . . . . . . . . . . 15

2.1.1. Nationale Bildungspolitik und F¨

ordermaßnahmen . . . . . . . . . . 15

2.1.2. Zielgerichteter Einsatz von IuK-Technologien an Hochschulen . . . 18

2.1.3. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.2. Das elektronisch unterst¨

utzte Lernen . . . . . . . . . . . . . . . . . . . . . 31

2.2.1. Begriffliche Einordnung . . . . . . . . . . . . . . . . . . . . . . . . 31

2.2.2. Formen des E-Learnings . . . . . . . . . . . . . . . . . . . . . . . . 32

2.2.3. Technologien virtueller Lernumgebungen . . . . . . . . . . . . . . . 35

2.2.4. Standards und aktuelle Integrationsans¨

atze . . . . . . . . . . . . . 36

2.2.5. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

2.3. Neue technologische und inhaltliche Trends im World Wide Web . . . . . 49

2.3.1. Der Begriff des Web 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 49

2.3.2. Benutzergenerierte Inhalte und soziale Strukturen . . . . . . . . . 50

2.3.3. Technologische Trends . . . . . . . . . . . . . . . . . . . . . . . . . 53

2.3.4. Die Auswirkungen des Web 2.0 auf das E-Learning . . . . . . . . . 56

2.4. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

3. Terminologiebasierte Spezifizierung von Lernumgebungen 65

3.1. Terminologiebasierte Softwareentwicklung . . . . . . . . . . . . . . . . . . 66

3.1.1. Effekte und Defekte nat¨

urlicher Sprachen . . . . . . . . . . . . . . 66

3.1.2. Normsprachen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

3.1.3. Normsprachliche Entwicklung von Software . . . . . . . . . . . . . 76

3.2. Die Wissensraummetapher als konstruierende Semantik f¨

ur Lernumge-

bungen...................................... 79

3.2.1. Lerntheoretische und koginitionspsychologische Grundlagen . . . . 79

3.2.2. Wissensr¨

aume als konstruierender Theoriebestandteil . . . . . . . . 88

3.2.3. Technisierung virtueller Wissensr¨

aume . . . . . . . . . . . . . . . . 94

3.3. Normsprachliche Spezifizierung kooperativer Lernumgebungen . . . . . . . 96

3.3.1. Das normsprachliche Lexikon . . . . . . . . . . . . . . . . . . . . . 97

3.3.2. Statische Sicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

3.3.3. Funktionale Sicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

3.3.4. Dynamische Sicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

3.4. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

4. Eine Rahmenarchitektur f¨

ur universit¨

ares E-Learning 113

4.1. Komponentenarchitekturen . . . . . . . . . . . . . . . . . . . . . . . . . . 114

4.1.1. Begriffsdefinitionen . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

4.1.2. Verteilte Informationsverarbeitung auf Basis von Middleware . . . 120

4.1.3. Entwurfsprinzipien von Komponentenarchitekturen . . . . . . . . . 123

4.1.4. Exkurs: Hochverf¨

ugbarkeit einer komponentenbasierten Infrastruk-

tur....................................125

4.1.5. Frameworks als semantische Referenzsysteme bei der Komponen-

tenentwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

4.2. Eine Rahmenarchitektur f¨

ur verteilte Lern- und Arbeitsumgebungen . . . 135

4.2.1. Schichtenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

4.2.2. Die Produktstandardarchitektur . . . . . . . . . . . . . . . . . . . 142

4.2.3. Die Produktarchitektur . . . . . . . . . . . . . . . . . . . . . . . . 147

4.2.4. Verteilung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

4.2.5. Integration in eine universit¨

are IT-Infrastruktur . . . . . . . . . . . 152

4.2.6. Anbindung an interne und externe Content-Provider . . . . . . . . 157

4.2.7. Erweiterte Benutzungsschnittstellen . . . . . . . . . . . . . . . . . 162

4.3. Proaktive Wiederverwendung von Komponenten . . . . . . . . . . . . . . 168

4.3.1. Softwareproduktlinien . . . . . . . . . . . . . . . . . . . . . . . . . 169

4.3.2. Separate Plattform- und Produktentwicklung . . . . . . . . . . . . 170

4.3.3. Anwendbarkeit des Produktlinien-orientierten Vorgehens . . . . . . 172

5. Entwicklungsmethodik komponentenbasierter Lernumgebungen 175

5.1. Grundlagen der methodischen Entwicklung . . . . . . . . . . . . . . . . . 175

5.1.1. Begriffsdefinition einer Methode . . . . . . . . . . . . . . . . . . . 175

5.1.2. Bestandteile eines methodischen Vorgehens . . . . . . . . . . . . . 177

5.1.3. Entwicklungsschemata von Vorgehensmodellen . . . . . . . . . . . 180

5.1.4. Entscheidungshilfe zur Auswahl der Prozesssteuerung f¨

ur die Soft-

wareentwicklung im universit¨

aren Kontext . . . . . . . . . . . . . . 183

5.2. Referenzmodelle zur Entwicklung von E-Learning-Komponenten . . . . . 185

5.2.1. Didaktisch-orientierte Modelle . . . . . . . . . . . . . . . . . . . . 185

5.2.2. Vorgehensmodelle f¨

ur die Web-Entwicklung . . . . . . . . . . . . . 187

xii

5.2.3. Hybride Modelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

5.2.4. Zusammenfassung und Bewertung . . . . . . . . . . . . . . . . . . 193

5.3. Konzeption der Methode auf Basis der DIN-PAS 1032-1:2004 . . . . . . . 195

5.3.1. Das Metaobjektmodell . . . . . . . . . . . . . . . . . . . . . . . . . 195

5.3.2. Vorgehen zur Anwendungsentwicklung . . . . . . . . . . . . . . . . 196

5.3.3. Vorgehen zur Entwicklung der Standardplattform . . . . . . . . . . 201

5.3.4. Empfehlung einer Ablaufreihenfolge . . . . . . . . . . . . . . . . . 205

5.4. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

6. koaLA – Integrierte Lern- und Arbeitswelten f¨

ur die Universit¨

at 2.0 209

6.1. Die Unterst¨

utzung formaler und informeller Lernkontexte . . . . . . . . . 209

6.1.1. Konfigurierbare Wissensr¨

aume ....................210

6.1.2. Flexible Gruppenstrukturen . . . . . . . . . . . . . . . . . . . . . . 213

6.1.3. Soziale Netzwerke . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

6.2. Die Systemarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216

6.3. Integration in die hochschulweite IT-Infrastruktur . . . . . . . . . . . . . 217

6.4. Die hochschulweite Einf¨

uhrung von koaLA . . . . . . . . . . . . . . . . . . 220

6.5. Erfahrungen aus der Pilotbetriebsphase . . . . . . . . . . . . . . . . . . . 221

7. Schlussbetrachtung 223

7.1. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

7.2. Kritische W¨

urdigung..............................224

7.2.1. Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

7.2.2. Risiken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

7.2.3. Erfolgsfaktoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

7.3. Ausblick.....................................228

7.4. Fazit.......................................229

Literaturverzeichnis 231

A. Anhang 253

A.1. Anfragesprachen f¨

ur Content-Repositories . . . . . . . . . . . . . . . . . . 253

A.1.1. XQuery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

A.1.2.CQL...................................253

A.1.3.VSQL ..................................254

A.2. Geschehnis-Pr¨

adikatoren der Terminologie . . . . . . . . . . . . . . . . . . 255

A.3. Ding-Pr¨

adikatoren der Terminologie . . . . . . . . . . . . . . . . . . . . . 256

A.4. Alfresco-Modell zur Verwaltung eines Weblogs . . . . . . . . . . . . . . . . 257

A.5. Beschreibungsmodell der konzipierten Methode . . . . . . . . . . . . . . . 259

A.5.1. Vorgehen zur Plattformentwicklung . . . . . . . . . . . . . . . . . . 259

A.5.2. Vorgehen zur Anwendungsentwicklung . . . . . . . . . . . . . . . . 266

xiii

xiv

Abbildungsverzeichnis

1.1. Nutzenpotenziale eines systematischen Ansatzes in der Praxis . . . . . . . 11

2.1. Fragmentierte Prozesse in Lehre und Verwaltung . . . . . . . . . . . . . . 23

2.2. Reorganisation und IT-Unterst¨

utzung . . . . . . . . . . . . . . . . . . . . 30

2.3. Distance Learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.4. Spezifikationen und Standards im E-Learning . . . . . . . . . . . . . . . . 39

2.5. Frameworks und Referenzarchitekturen . . . . . . . . . . . . . . . . . . . . 44

2.6. Wachstum der Blogosph¨

are .......................... 51

3.1. Begriffsmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

3.2. Klassifikation normsprachlicher Wortarten . . . . . . . . . . . . . . . . . . 72

3.3. Zweigeteilter Fachentwurf auf Basis einer Normsprache . . . . . . . . . . . 77

3.4. Kognitivistisches Grundmodell menschlicher Informationsverarbeitung . . 80

3.5. Formen der Wissensumwandlung . . . . . . . . . . . . . . . . . . . . . . . 87

3.6. Wissensraumstrukturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

3.7. Objektintegration durch Generalisierung . . . . . . . . . . . . . . . . . . . 91

3.8. Objektmodell virtueller Wissensr¨

aume.................... 95

3.9. Spezifikationsebenen universit¨

arer Lern- und Arbeitsumgebungen . . . . . 97

3.10. Informationsmodell des Learning Designs . . . . . . . . . . . . . . . . . . 99

3.11. Die Basis-Dingpr¨

adikatoren der Terminologie . . . . . . . . . . . . . . . . 100

3.12. Die Basis-Geschehnispr¨

adikatoren der Terminologie . . . . . . . . . . . . . 101

3.13. Statische Raum- und Gruppenstruktur f¨

ur Kurse . . . . . . . . . . . . . . 104

3.14. Spezifizierung am Beispiel von Think-Pair-Share . . . . . . . . . . . . . . 105

4.1. Eine Fachkomponente in UML-Notation . . . . . . . . . . . . . . . . . . . 117

4.2. Metamodell f¨

ur Dienste und Komponenten . . . . . . . . . . . . . . . . . 118

4.3. Funktionsweise von Web-Services . . . . . . . . . . . . . . . . . . . . . . . 120

4.4. Gerichtete Abh¨

angigkeiten in einer Komponentenarchitektur . . . . . . . 125

4.5. Zeitverlauf des Systemzustandes . . . . . . . . . . . . . . . . . . . . . . . 126

4.6. Verf¨

ugbarkeit von Systemkomponenten . . . . . . . . . . . . . . . . . . . . 129

4.7. Variationspunkte von Groupware-Frameworks . . . . . . . . . . . . . . . . 132

4.8. Abh¨

angigkeiten zwischen verschiedenen Dienst-Klassifizierungen . . . . . 136

4.9. Infrastruktur und Basisdienste . . . . . . . . . . . . . . . . . . . . . . . . 137

4.10. Kooperationsdienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

4.11. E-Learning-spezifische Dienste . . . . . . . . . . . . . . . . . . . . . . . . 141

4.12. Spezifikationsraum f¨

ur kooperative Lern- und Arbeitskontexte . . . . . . . 142

4.13. Aspektorientierte Umsetzung der Wissensraummetapher . . . . . . . . . . 144

4.14. Composites als geteilte Modelle . . . . . . . . . . . . . . . . . . . . . . . . 145

4.15. Fabrikmethode zur Instanzierung von Klassen . . . . . . . . . . . . . . . . 150

4.16. M¨

ogliche Verteilung der Architekturkomponenten . . . . . . . . . . . . . . 152

4.17. Interoperability Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

4.18. Die Messagebus-Schnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . 155

4.19. Die Z39.50-Schnittstelle in der Rahmenarchitektur . . . . . . . . . . . . . 157

4.20. Die SQI-Schnittstelle der Produktstandardarchitektur . . . . . . . . . . . 159

4.21. Komponentenstruktur der SQI-Schnittstelle . . . . . . . . . . . . . . . . . 161

4.22. Model-View-Controller-Konzept der AJAX-Schnittstelle . . . . . . . . . . 163

4.23. Client-Gateway-Server-Prinzip der Schnittstelle f¨

ur mobile Endger¨

ate . . . 165

4.24. Die WAP-Schnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

4.25. Portlet-Zugriff ¨

uber SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

4.26. Entwicklung von Produktstandardplattform und Produkt . . . . . . . . . 171

4.27. Ausschnitt Featuremodell . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

5.1. Konzepte eines methodischen Vorgehens . . . . . . . . . . . . . . . . . . . 177

5.2. Prozessarchitektur phasenorientierter Vorgehensmodelle . . . . . . . . . . 180

5.3. Inkrementelle Vorgehensmodelle . . . . . . . . . . . . . . . . . . . . . . . . 183

5.4. Evolution¨

ares Prozessmodell des Instructional System Design . . . . . . . 186

5.5. Prozessarchitektur der DIN PAS 1032-1:2004 . . . . . . . . . . . . . . . . 193

5.6. Das Metaobjektmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

5.7. Prozessarchitektur der konzipierten Methode . . . . . . . . . . . . . . . . 202

5.8. Beziehungen zwischen den Phasen der konzipierten Methode . . . . . . . . 206

6.1. Einf¨

ugen aus der Zwischenablage in den eigenen Arbeitsraum . . . . . . . 210

6.2. Kombination konfigurierbarer Komponenten . . . . . . . . . . . . . . . . . 212

6.3. Kommunikationsm¨

oglichkeiten f¨

ur Gruppen . . . . . . . . . . . . . . . . . 213

6.4. Moderierte ¨

Ubungsgruppen im Rahmen einer Veranstaltung . . . . . . . . 214

6.5. Profil einer koaLA-Benutzerin . . . . . . . . . . . . . . . . . . . . . . . . . 215

6.6. Die Web 2.0-Architektur der Lern- und Arbeitsumgebung koaLA . . . . . 217

6.7. In Kursr¨

aume eingebettete Seminarapparate der Bibliothek . . . . . . . . 218

6.8. Umsetzung eines Fachglossars als Wiki . . . . . . . . . . . . . . . . . . . . 219

6.9. Einsatz von Weblogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

A.1. Basis-Geschehnispr¨

adikatoren der Terminologie . . . . . . . . . . . . . . . 255

A.2. Basis-Dingpr¨

adikatoren der Terminologie . . . . . . . . . . . . . . . . . . . 256

xvi

Tabellenverzeichnis

2.1. E-Learning-Paradigmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.2. Anwendungstypen multimedialer Lernsysteme . . . . . . . . . . . . . . . . 37

3.1. Zusammenfassung der in dieser Arbeit verwendeten Satzmuster . . . . . . 110

4.1. Vor- und Nachteile einer Funktionsintegration . . . . . . . . . . . . . . . . 122

4.2. Beispiele aktueller Groupware-Frameworks . . . . . . . . . . . . . . . . . . 134

4.3. Gemeinsame Nutzungsszenarien von Verwaltungs- und Lernsystemen . . . 154

4.4. Basisfunktionen des Z39.50 Protokoll . . . . . . . . . . . . . . . . . . . . . 156

5.1. Elemente g¨

angiger ISD-Modelle . . . . . . . . . . . . . . . . . . . . . . . . 187

5.2. Methoden zur Entwicklung von Web-Anwendungen . . . . . . . . . . . . . 191

xvii

xviii

Abk¨

urzungsverzeichnis

AJAX Asynchronous Javascript And XML

ANSI American National Standards Institute

AOP Aspektorientierte Programmierung

API Application Programming Interface

ASP Application Service Providing

BMBF Bundesministerium f¨

ur Bildung und Forschung

CBT Computer Based Training

CDL Component Definition Language

CEN Centre de European Normalisation

CIM Collaboration Information Management

CMI Computer Managed Instruction

CMS Content Management System

COM Component Object Model

COAL Client Object Access Layer

CoP Community of Practice

CORBA Common Object Request Broker Architecture

CQL Common Query Language

CSCL Computer Supported Cooperative Learning

CSE Campus Source Engine

CSCW Computer Supported Cooperative Work

CSS Cascading Style Sheet

DCOM Distributed Component Object Model

DIN Deutsches Institut f¨

ur Normung

DIN PAS DIN Public Available Specification

DOM Document Object Model

DRI Digital Repositories Interoperability

ECTS European Credit Transfer System

EJB Enterprise Java Bean

ELF E-Learning Framework

ELM Essener-Lern-Modell

EML Educational Modeling Language

ERM Entity Relationship Model

EU Europ¨

aische Union

EUR Euro

F&E / FuE Forschung und Entwicklung

FTP File Transfer Protocol

GPRS General Packet Radio Service

xix

GSM Global System for Mobile Communications

HDM Hypertext Design Model

HIS Hochschul-Informations-Systeme GmbH

HIS LSF HIS-Portal f¨

ur Lehre, Studium und Forschung

HTML Hyptertext Markup Language

HTTP Hyptertext Transfer Protocol

IAF IMS Abstract Framework

ID/ISD Instructional Systems Design

IDE Integrated Development Environment

IEC International Electrotechnical Commission

IEEE Institute of Electrical and Electronics Engineers

IFRS International Financial Reporting Standard

IT Informationstechnik

IKT / IuK Informations- und Kommunikationstechnik

IP Internet Protocol

ISO International Organization for Standardization

J2EE Java 2 Enterprise Edition

JDBC Java Database Connectivity

JISC Joint Information Service Committee

JNDI Java Naming and Directory Interface

JRE Java Runtime Environment

JVM Java Virtual Machine

LD Learning Design

LDAP Lightweight Directory Access Protocol

LMOS Learning Management Operating System

LMS Learning Management System

LOM Learning Object Metadata

LTSA Learning Technology Systems Architecture

MIME Multipurpose Internet Mail Extensions

MIT Massachusetts Institute of Technology

MMOG Massive Multiplayer Online Game

MOM Message Oriented Middleware

MOO MUD Object Oriented

MTBF Mean Time Between Failures

MTTR Mean Time to Repair

MUD Multi User Dungeon

MVC Model-View-Controller

NMB Neue Medien in der Bildung

OAI Object Action Interaction-Modell

ODBC Open Database Connectivity

OKI Open Knowledge Initiative

OO Object Oriented

ORM Objektrelationales Mapping

OSI Open Systems Interconnection (Reference Model)

OSID Open Source Interface Definition

PAPI Public and Private Information for Learners

PKI Public Key Infrastructure

PLE Personal Learning Environment

QM Qualit¨

atsmanagement

QS Qualit¨

atssicherung

QTI Question and Test Interoperability

REST Representational State Transfer

RMI Remote Method Invocation

RMM Relationship Management Methodology

RPC Remote Procedure Call

RSS Real Simple Syndication

SaaS Software as a Service

SCORM Sharable Content Object Reference Model

SHDM Semantic Hypermedia Design Method

SOA Serviceorientierte Architektur

SOAP Simple Object Access Protocol

SPL Softwareproduktlinie

SQI Simple Query Interface

SSL Secure Socket Layer

SW Software

SWE Software-Engineering

TAOS Terminologie-basierter Ansatz f¨

ur die Objektorientierte Spezifikation

TBF Time Between Failure

TTR Time to Repair

UDDI Universal Description, Discovery and Integration

UI User Interface

UML Unified Modelling Language

UMTS Universal Mobile Telecommunications Systems

URL Uniform Resource Locator

US-GAAP Generally Accepted Accounting Principles in the United States

VoIP Voice over IP

VORMS Virtual Operations Research/Management Science

VSQL Very Simple Query Language

WAP Wireless Application Protocol

WBT Web Based Training

WebDAV Web Based distributed Authoring and Versioning

WebML Web Modeling Language

WLAN Wireless Local Area Network

WSDL Web Service Description Language

WSDM Web Site Design Method

WWW World Wide Web

XML Extended Markup Language

XQuery XML Query

xxi

xxii

1. Einleitung

1.1. Szenario: Wissensgesellschaft und Hochschulbildung

Mit dem Ziel, gesellschaftlichen Wandel in große Zusammenh¨

ange und langfristige Rich-

tungen einzuordnen, werden in den Sozial- und Wirtschaftswissenschaften Zyklen und

Megatrends beschrieben, die die treibenden Kr¨

afte in einen gemeinsamen Kontext setzen.

Nach der physischen Verkopplung menschlicher und maschineller Arbeit auf der Ebene

der Elementarfaktoren (industrielle Revolution, seit 1790) sowie deren gesellschaftliche

Verarbeitung (Postmoderne, seit 1940) ist in der Informationsgesellschaft seit 1980 ei-

ne Verkopplung des dispositiven Faktors mit der Informationstechnologie festzustellen

(vgl. [J¨

an04a], S. 5f.): Zeitnah generierte Informationen in unternehmensinternen Daten-

banken waren kennzeichnend f¨

ur diese Epoche und hatten einen immer gr¨

oßeren Einfluss

auf das F¨

uhren und Steuern von Organisationen.

Seit Mitte der 90er Jahre f¨

uhrt der omnipr¨

asente Zugang zum weltweiten Datennetz

Internet zu einer allgemeinen Informations¨

uberflutung (quantitativen Schock (s. [Lei01],

S. 14). Beitr¨

age aus unterschiedlichsten Quellen treten in einen internationalen, technisch

vernetzten Pool von Informationsangeboten. Gerade die Idee, beliebige Wissensquellen

logisch zu verkn¨

upfen, begr¨

undet die M¨

achtigkeit und Qualit¨

at des Internets sowie seinen

weltweiten Erfolg in vergleichsweise kurzer Zeit (vgl. [BLF99], auch [BL99]).

Durch die Aufhebung technischer Barrieren ist jeder mit Zugang zum Internet in der

Lage zu Publizieren. Hierdurch wird wiederum die beschleunigte Generierung neuer, the-

matisch zunehmend spezialisierter Information durch eine unkontrolliert steigende Zahl

von ”Wissens-Schaffenden“ gef¨

ordert (vgl. [Lei01], S. 23). W¨

ahrend einst Intermedi¨

are

wie Hochschulen und Medien zwischen Informationsproduzenten und -konsumenten ver-

mittelten, verschwimmen mit der Inflation der Produzenten die Grenzen zwischen den

beiden Segmenten zunehmend. Dieses Ph¨

anomen markiert das Ende der Informationsge-

sellschaft, in der anfangs Informationen organisatorisch und technisch noch weitgehend

isoliert und durch die Zugriffsberechtigten beherrschbar waren, und den Beginn der Wis-

sensgesellschaft1.

Die Wissensgesellschaft ist charakterisiert durch eine Aufwertung des Wissens im

okonomischen Kontext: Auf Unternehmensebene wird dieser ”vierte Produktionsfak-

tor“ (s. [J¨

an04a], S. 129ff.) als die zentrale Voraussetzung f¨

ur Wettbewerbsf¨

ahigkeit

in einem zunehmend h¨

arter umk¨

ampften internationalen Marktumfeld wahrgenommen

(vgl. [Sch00b], S. 19, [NT01], S. 1, [Lei01], S. 6).

1Eingef¨

uhrt wurde der Begriff der Wissensgesellschaft in der amerikanischen Soziologie als Knowledge

Society zwar schon in den 60er Jahren (s. [Lan66], S. 650), jedoch erst in j¨

ungster Zeit erlangte er

die heutige Bedeutung. Seine Verwendung ist uneinheitlich. So wird h¨

aufig nicht zwischen Wissens-

und Informationsgesellschaft differenziert, obgleich schon die Abgrenzung des Begriffs ”Wissen“ ge-

gen¨

uber ”Information“ die Problematik dieser Unsch¨

arfe deutlich macht (vgl. hierzu bspw. [PRR03],

S. 15f.).

1. Einleitung

Als Ausgangspunkt ist eine Spirale des Wissenswachstums zu konstantieren: Gem¨

aß der

Erkenntnis, dass Wissen zu einem Wettbewerbsvorteil werden kann, erh¨

ohen sich die

Bem¨

uhungen, die neuen technischen M¨

oglichkeiten der Kommunikation und Informati-

onsverarbeitung zum Zwecke eines verbesserten Managements des Erfolgsfaktors Wis-

sen auszunutzen. Dies erm¨

oglicht ein produktiveres und effizienteres Management des

Wissens, also dessen verbesserte Identifikation, Nutzung, Bewahrung, Verteilung etc.2

Insbesondere die h¨

ohere Arbeitsteilung und Spezialisierung (vgl. [Lei01], S. 17) setzt eine

große produktive Kraft frei, denn mit dem verbesserten Zugang zu Informationen durch

das Fallen von Kommunikationsbarrieren positionieren sich Wissensproduzenten indi-

vidueller. Der resultierende Quantit¨

atsschub im Wissensbestand und der verf¨

ugbaren

Informationen stellt wiederum einen Treiber dar f¨

ur das stetige Bem¨

uhen, Organisation

und Instrumente der Informationsverarbeitung zu verbessern, u.s.w. Diese Dynamik des

Wissenswachstums senkt die zeitliche Dauer, in der Erkenntnisse noch als relevant und

aktuell angesehen werden (verringerte Halbwertszeit des Wissens).

Daher ist die Spirale des Wissenswachstums im Unternehmensbereich gleichbedeu-

tend mit einem radikal gestiegenen Innovationstempo und -druck. So wird behaup-

tet, ein Internetjahr entspreche im Ergebnis drei Jahren in der Industriegesellschaft

(vgl. [Lei01], S. 11). Dies impliziert verk¨

urzte Produktzyklen und einen zunehmenden

Time-to-Market-Druck im globalen Wettbewerb. F¨

ur gr¨

oßere US-Unternehmen ist ei-

ne durchschnittliche Rate von einem neuen Produkt pro Tag mittlerweile Standard

(vgl. [Tap97], S. 60). Der Bedeutung von Wissen im Bereich Produktinnovation tragen

auch die internationalen Bilanzierungsregeln (US-GAAP, IFRS) Rechnung. Hier sind die

Forschungs- und Entwicklungsausgaben als Verm¨

ogenswerte zu bilanzieren. Seit 2005 ist

dies auch f¨

ur in Deutschland sitzende, b¨

orsennotierte Konzerne bindend, deren Ausgaben

f¨

ur FuE-Aktivit¨

aten das Budget der ¨

offentlich gef¨

orderten Forschung um ein Vielfaches

ubersteigen (vgl. [BMB04a], S. 175, [Lei01], S. 19).

Spezifisch f¨

ur die Unternehmen im Zeitalter der Wissensgesellschaft ist weiterhin ei-

ne zunehmende Prozessorientierung. Der seit vielen Jahrzehnten (vgl. [J¨

an04a], S. 8)

zu beobachtende Trend zur internationalen Verflechtung wirtschaftlicher Aktivit¨

at fin-

det in elektronischen Netzwerken einen bedeutenden Katalysator: Die IT-gest¨

utzte,

grenz¨

uberschreitende Kommunikation ohne signifikanten Zeit- und Kostenaufwand re-

duziert die Transaktionskosten, insbesondere f¨

ur Abstimmung, Absicherung, Planung

und Abschluss von Gesch¨

aften. Die Informations- und Kommunikationstechnik (IKT)

erleichtert es international wettbewerbsf¨

ahigen Unternehmen, sich auch in ausl¨

andischen

Absatzm¨

arkten zu positionieren.

Die Existenzberechtigung statischer Strukturen der Industriegesellschaft wird durch die-

sen Wandel in Frage gestellt (vgl. [Hau02], S. 6). Hiervon betroffen sind neben den Unter-

nehmen auch die Prozesse innerhalb der Betriebe. W¨

ahrend in der Industriegesellschaft

der eigenst¨

andigen Optimierung aller unternehmensinternen Abl¨

aufe noch eine zentra-

le Aufmerksamkeit zukam, sind Betriebe nun gezwungen, sich auf ihre Kernprozesse zu

konzentrieren (vgl. [J¨

an04a], S. 1) und ¨

uber Outsourcing g¨

unstigere Dienstleistungen und

2Nach den Kernprozessen des Wissensmanagements, vgl. [PRR03], S. 28.

1.1. Szenario: Wissensgesellschaft und Hochschulbildung

G¨

uter von Dritten in ihre Wertsch¨

opfungskette zu integrieren (vgl. [J¨

an04a], S. 7). Die

damit verbundene Fragmentierung der Unternehmensprozesse ist zu einem pr¨

agenden

Attribut der Wissensgesellschaft geworden. Ergebnisorientierte Meta-Information zu ein-

zelnen Prozessen (Zeit-, Mengen-, Qualit¨

ats- und Kostenziffern f¨

ur Input und Output)

r¨

ucken in diesem Kontext f¨

ur die Entscheidungstr¨

ager in den Vordergrund.

Diese Prozesssicht f¨

uhrt mehr und mehr zu einer Abstraktion vom ausf¨

uhrenden Mit-

arbeiter, dessen individuelle Arbeitsleistung austauschbarer wird (vgl. [FH96], S. 240).

Zun¨

achst nicht davon betroffen sind flexible, hochqualifizierte Angestellte (vgl. [FH96],

S. 242). Die Folge ist ein Auseinanderklaffen der Schere zwischen solchen Knowledge

Workern einerseits und ausf¨

uhrenden Mitarbeitern andererseits. Nach [Sch05], S. 1, se-

hen sich jedoch auch zunehmend Knowledge Worker dem Trend zum Offshoring3aus-

gesetzt: ”offshoring moves higher up the skills ladder“. So sei mittlerweile auch zu be-

obachten, dass auch FuE-Leistungen – gemeinhin den klassischen Kernprozessen der Un-

ternehmen zugerechnet – geographisch ausgelagert (Off-Shoring, z. B. [SAP02]) oder gar

vollst¨

andig externalisiert und international eingekauft werden (Outsourcing, vgl. [Sch05],

S. 5).

Die neuen Herausforderungen der Wissensgesellschaft verst¨

arkend, wird durch die ho-

he Mobilit¨

at des Wirtschaftsfaktors Wissen der Wettbewerb der nationalen Standorte

auch zu einem Wettbewerb um soziales Kapital (vgl. [Sch05], S. 6). Dies gilt insbesondere

innerhalb des Kreises hoch entwickelter Industrienationen, wo niedrige Geburtenraten

langfristig als Katalysatoren dieser Entwicklung wirken. Als Beispiel f¨

ur die Folgen des

Wettbewerbs um soziales Kapital kann der Exodus wissenschaftlichen Talents in Rich-

tung USA angef¨

uhrt werden (transatlantischer Brain Drain, vgl. [Bue01], S. 7).

Der Intensivierung des Wettbewerbs auf dem Arbeitsmarkt Rechnung tragend, werden

individuelle und private – allgemein formuliert: dezentrale – Bildungsstrategien bedeut-

samer, w¨

ahrend die zentrale Definition von Curricula zunehmend schwieriger wird. Dies

ist nicht zuletzt dadurch bedingt, dass sich das Generieren von Wissen wie beschrieben

zunehmend von ¨

offentlichen in den privaten Bereich verlagert. Diese Privatisierung der

Bildung i. w. S. ist ein Katalysator f¨

ur das Entstehen eines Knowledge Gap ”zwischen

wissensnahen (sozial bevorteilten) und wissensfernen (sozial deprivierten) Gruppen“,

s. [Rog04], S. 54).

Als Gegensatz zur Kontinuit¨

at einstiger Erwerbskarrieren (Lebensberufe) in der Agrar-

und Industriegesellschaft ist die Halbwertszeit eines typischen Berufsprofils in der Wis-

sensgesellschaft ebenso kurz wie die Anforderung im Alltag des Berufsinhabers kurzlebig

sind: Vor dem Hintergrund wissensbasierter T¨

atigkeiten wird der Mitarbeiter zum Wis-

sensarbeiter, der in der Lage ist, in seinem Arbeitsumfeld seine Aufgaben selbst zu

identifizieren und zu organisieren, relevantes Wissen zu kommunizieren und anzuwen-

den (vgl. [Hei03]). W¨

ahrend fr¨

uher die Allgemeinbildung im Vordergrund stand, werden

heute also die spezifischen Kompetenzen der Wissensarbeiter nachgefragt (vgl. [BLK03]

und [Dav05], S. 25ff.):

3Der Begriff Offshoring steht f¨

ur eine Form der Auslandsverlagerung unternehmerischer Funktionen

und Prozesse aufgrund dort vorherrschender g¨

unstigerer Rahmenbedingungen wie Arbeitskosten.

1. Einleitung

Handlungskompetenz Im Einzelnen umfasst die Handlungskompetenz die Teilkompe-

tenzen Fach-/Methodenkompetenz, Personalkompetenz und Sozialkompetenz (vgl.

[BLK01], S. 20, [Rau04], S. 8ff.), wobei die Fach-/Methodenkompetenz die F¨

ahigkeit

darstellt, erlerntes Fachwissen zielorientiert zu nutzen. Die Personalkompetenz

hingegen formuliert die Ebene von ethischen Werten, Selbst¨

andigkeit und Kri-

tikf¨

ahigkeit. Der Bereich der Sozialkompetenz umfasst die F¨

ahigkeit, in einem so-

zialen Gef¨

uge zu agieren, Verantwortung zu ¨

ubernehmen und sich solidarisch zu

verhalten. Somit bildet die Handlungskompetenz eine Grundlage f¨

ur ein Individu-

um, in beruflichen, gesellschaftlichen und privaten Situationen handlungsf¨

ahig zu

sein.

Medienkompetenz Eingebettet in den gesetzten Rahmen der ¨

ubergeordneten Hand-

lungskompetenz wird die Medienkompetenz beispielhaft von B¨

onkost f¨

ur die Nut-

zung von digitalen Technologien durch vier Qualifikationen definiert: Medienkritik,

Medienkunde, Mediennutzung und -gestaltung (vgl. [B¨

on04] und [Baa99], S. 34).

W¨

ahrend die Medienkritik und die Medienkunde beide die Ebene der Vermittlung

betrachten, fokussieren die Dimensionen der Mediennutzung und Mediengestal-

tung die Ebene der Zielorientierung im Rahmen der Lern- und Methodenkom-

petenz, die f¨

ur die Initiierung und Ausf¨

uhrung von Handlungen der Individuen

verantwortlich ist (vgl. [Baa99], S. 34).

Lernkompetenz Dar¨

uber hinaus bedarf es aber auch einer Handlungskompetenz f¨

ur den

Lernprozess, um das Lernen in einer Wissensgesellschaft langfristig gew¨

ahrleisten

zu k¨

onnen. ”Lernen erfordert zum einen selbstgesteuerte, aktive Wissenskonstruk-

tion und ist zum anderen ein sozialer, interaktiver Prozess“ [MK01], S. 10f. Da-

her ist neben der Sozialkompetenz und der Medienkompetenz die Kompetenz zur

Selbststeuerung zentral. Hierf¨

ur sind vor allem metakognitive F¨

ahigkeiten erfor-

derlich, um (1) das Lernen vorzubereiten, (2) die Lernhandlung durchzuf¨

uhren, (3)

das Lernen zu regulieren, (4) die Lernleistung zu bewerten und (5) die Motivation

und Konzentration aufrechtzuerhalten (vgl. ebenda, S. 11).

Kompetenz zum Wissensmanagement Die Kompetenz zum Wissensmanagement

formuliert die F¨

ahigkeit, die derzeit stetig wachsenden Informationsfluten nach

Inhalt, Bedeutung und Nutzen zu selektieren, zu bewerten und f¨

ur die Wissens-

bildung nutzbar aufzuarbeiten (vgl. [RRM97], S. 194f.). Durch eine Integration

von Arbeits- und Lernprozessen schafft ein individuelles Wissensmanagement den

Rahmen f¨

ur eine pragmatische Wissensarbeit, die es dem Individuum erm¨

oglicht,

Expertise zu erlangen. Die Kombination von Wissenswerkzeugen und der F¨

ahig-

keit, diese zielorientiert einzusetzen, hat daher f¨

ur den Einzelnen ein gewaltiges

Potenzial (vgl. [J¨

an04a], S. 6; vgl. auch [HM97], S. 11 und [RRM97], S. 61).

Unsicherheit bez¨

uglich dessen, was zuk¨

unftig dar¨

uber hinaus an spezifischen Kompeten-

zen gefragt sein wird, ist ein inh¨

arentes Merkmal der Wissensgesellschaft. Diese Unsicher-

heit impliziert f¨

ur den Einzelnen die permanente Notwendigkeit, den Status des Lernen-

den niemals zu verlassen und sich dem lebenslangen Lernen (vgl. [BLK01], [Lei01], S. 16)

zu verschreiben. Gesellschaftliche Teilhabe und Chancengleichheit kann daher zuk¨

unftig

1.1. Szenario: Wissensgesellschaft und Hochschulbildung

nicht mehr allein durch ein staatliches Bildungssystem gesichert werden; das Individu-

um selbst ist f¨

ur den Erwerb der in der Wissensgesellschaft erforderlichen Kompetenzen

verantwortlich (vgl. [RRM01], S. 11).

Trotzdem f¨

uhrt die Notwendigkeit des lebenslangen Lernens zu einem grunds¨

atzlich

ver¨

anderten Verst¨

andnis von institutioneller Bildung, da es zum Grundprinzip werden

muss, an dem sich Angebot und Nachfrage in s¨

amtlichen Lernkontexten ausrichten (vgl.

[KdE00], S. 308, [Keh01], S. 125). Dabei muss Bildung, die im prim¨

aren Bildungssektor

der Schulbildung, aber vor allem im sekund¨

aren und terti¨

aren Bildungssektor der Aus-,

Fort-, und Weiterbildung gef¨

ordert wird, den Lernenden dazu bef¨

ahigen, am ¨

offentlichen

Leben partizipieren zu k¨

onnen. Das Bildungsziel sollte also eine fach¨

ubergreifende Lern-

kompetenz sein (vgl. [MK01], S. 4). Daf¨

ur werden neue Lehr- und Lernformen und neue

Wissensinhalte ben¨

otigt, die ”st¨

arker als je zuvor von externen Themen, Fragestellun-

gen und Probleml¨

osungsm¨

oglichkeiten bestimmt sind und nicht mehr den konventio-

nellen Paradigmen akademischer Disziplinen und Fachkulturen entsprechen“ [Keh01],

S. 125. Dies impliziert auch konzeptuelle Ver¨

anderungen bei der Hochschulbildung, die

in ihrer traditionellen Form oftmals zu statisch und unflexibel ist, um schnell auf neue

Arbeitsanforderungen und ver¨

anderte Entwicklungen reagieren zu k¨

onnen (vgl. [KdE00],

S. 308). In diesem Kontext wird der Hochschule als ”[...] Teil der Aus- und Weiterbildung

zum einen eine neue Bedeutung als St¨

atten der Wissensproduktion und -distribution

beigemessen“ (vgl. [Keh01], S. 123), zum anderen sollen durch die Hochschulbildung

in st¨

arkerem Maße als zuvor ¨

ubertragbare F¨

ahigkeiten und Fertigkeiten vermittelt wer-

den, die f¨

ur unterschiedlichste T¨

atigkeitsbereiche Schl¨

usselkompetenzen herstellen. Diese

neue Anforderung an Hochschulbildung geht deutlich ¨

uber die bisherige Vermittlung von

disziplin¨

ar strukturierten (Fach-)Wissen und den dazu geh¨

origen Methodenkenntnissen

hinaus (vgl. [Keh01], S. 126).

Im bildungspolitischen Kontext greift die Bologna-Erkl¨

arung4das Thema ”Lebenslan-

ges Lernen“ explizit auf, wonach Universit¨

aten im europ¨

aischen Bildungsraum offener

gestaltet werden sollen: Allen Altersklassen und jedem Vorbildungsstand soll Zutritt zu

universit¨

arer Bildung erm¨

oglicht werden. Dazu sollen bis zum Jahre 2010 neue Studien-

strukturen durchl¨

assiger und beweglicher als bisher gestaltet werden, im biographischen

Bereich, wie auch im strukturellen Bereich5.

4Auf der Grundlage einer Vereinbarung des Jahres 1998 (Sorbonne-Erkl¨

arung) zwischen den Bildungs-

ministern Frankreichs, Deutschlands, Italiens und Großbritannien erwuchs ein Jahr sp¨

ater eine Er-

kl¨

arung der Bildungsminister, die von Vertretern aus 29 europ¨

aischen L¨

andern am 19. Juni 1999 in

Bologna unterzeichnet wurde. Die Vorbereitung und Umsetzung dieser Erkl¨

arung wird als Bologna-

Prozess bezeichnet.

5Im Einzelnen sollen sechs Aktionsschwerpunkte umgesetzt werden (vgl. [LW05], S. 7): (1) Einf¨

uhrung

eines Systems leicht verst¨

andlicher und vergleichbarer Hochschulabschl¨

usse, (2) Einf¨

uhrung eines

Systems, das sich im Wesentlichen auf zwei Hauptzyklen (Bachelor/Master) st¨

utzt, wobei bereits

der erste Zyklus eine f¨

ur den europ¨

aischen Arbeitsmarkt relevante Qualifikationsebene attestiert,

(3) Einf¨

uhrung eines Systems zur Akkumulierung und zur Anrechnung/¨

Ubertragung von Studien-

leistungen (European Credit Transfer Systems, ECTS), (4) Mobilit¨

at von Studierenden, Lehrkr¨

aften

und Forschern, (5) Zusammenarbeit bei der Qualit¨

atssicherung und (6) eine europ¨

aische Dimension

der Hochschulbildung.

1. Einleitung

Vor diesem Hintergrund entstehen v¨

ollig neue Anforderungen an Bildungseinrichtungen,

denen es sich zu stellen gilt: Es muss mehr Wissen und Handlungskompetenz schneller

an eine gr¨

oßere und zunehmend inhomogener werdende Zielgruppe vermittelt werden.

Daher muss zum einen Wissen effizienter und effektiver vermittelt werden, zum anderen

m¨

ussen Lehr- und Lernprozesse den o. a. Anforderungen gerecht werden.

1.2. Motivation der Arbeit

Neue Medien k¨

onnen die Hochschullehre nachweislich verbessern (vgl. [Bau03a] und

[RB04]). Lange Zeit wurde ihr Einsatz mit einem Anspruch auf h¨

ochste Produktqualit¨

verbunden, die Alltagstauglichkeit jedoch vernachl¨

assigt. Beispielsweise wurde der in der

E-Learning-Szene renommierte Wissenschaftspreis Medidaprix bislang fast ausschließlich

an Projekte vergeben, die ein gutes didaktisches Modell medial sehr aufw¨

andig umgesetzt

haben. Ein Vergabekriterium war u. a. die isolierte Lauff¨

ahigkeit. Prozesse der Organi-

sationsentwicklung an Hochschulen wurden nicht ber¨

ucksichtigt (vgl. [BP04])6. Solche

abgeschlossenen virtuellen Lernarrangements von besonders hoher Qualit¨

at befriedigen

jedoch nicht die Bed¨

urfnisse einer alltagstauglichen, unproblematischen Nutzung von

Medien an deutschen Hochschulen, bei der das Kosten-Nutzen-Verh¨

altnis und die Ein-

bindung in die jeweils vorhandene IT-Infrastruktur im Vordergrund stehen.

Angebracht ist vielmehr eine Abkehr von der Produktorientierung einzelner Lehr-

st¨

uhle und Fachbereiche hin zu einer Dienstorientierung f¨

ur eine bedarfsgerechte Me-

diennutzung f¨

ur eine ganze Hochschule. Dies erfordert die Implementierung zentraler

Unterst¨

utzungsprozesse und Basisdienste, die hochschulweit in fachbereichsspezifische

Prozesse und Plattformen eingebettet werden k¨

onnen.

Neben den großen Strukturver¨

anderungen, die durch die Bologna-Reform induziert

sind, geht es derzeit und zuk¨

unftig also ebenfalls darum, ”die Leistungsstrukturen von

Hochschulen mit Hilfe eines bed¨

urfnisorientierten Medieneinsatzes ebenso behutsam wie

konsequent zum Nutzen aller Beteiligten sukzessive umzumodeln“ [Ede02], S. 19. Zumin-

dest dann, wenn man die vorhandene didaktische Vielfalt nicht durch den Kauf einer

zentralen Lernplattform eind¨

ammen will, sondern E-Learning als Unterst¨

utzung indivi-

dueller Lehr- und Lernprozesse versteht, das – wenn es gut umgesetzt wird – durchaus

eine strategische Relevanz erlangen kann7.

Aus technischer Sicht bedarf es dazu einer Infrastruktur, die es erlaubt, individuelle

Lernwerkzeuge medienbruchfrei in die Kernprozesse der Wissensorganisation und der

Modul- und Pr¨

ufungsverwaltung zu integrieren, um damit zum einen den Aufwand

der Dozierenden f¨

ur eine effektive Computerunterst¨

utzung der Lehre minimieren zu

k¨

onnen, und zum anderen durch Systemkonvergenzen didaktische Mehrwerte zu schaffen,

die durch isolierte Lernwerkzeuge nicht umgesetzt werden k¨

onnen. Die Lernwerkzeuge

6Der Medidaprix teilte sich erst zwischen 2005 und 2008 in zwei Preiskategorien ”Digitale Medien in

der Hochschullehre“ und ”Hochschulentwicklung mit Digitalen Medien“. F¨

ur 2008 wurden die beiden

Projektlinien zusammengef¨

uhrt.

7Zum Beispiel der Einsatz von E-Learning zur Wissenschaftsentwicklung (E-Learning als Forschungsge-

genstand), zur Schaffung eines flexiblen Zugangs zu hochschulischen Bildungsangeboten f¨

ur Externe,

zur St¨

arkung der (inter-)nationalen Wettbewerbsf¨

ahigkeit etc. (vgl. [Hop05a], S. 108ff.).

1.3. Problembeschreibung und Zielsetzung der Arbeit

m¨

ussen dazu ¨

uber einen gemeinsamen Dienstekern, der technischen Werkzeugen als Ba-

sis und Integrationsplattform dient, zentrale Funktionalit¨

at unterst¨

utzen (vgl. ebenda).

Hierzu m¨

ussen Probleme der Wiederverwendbarkeit gel¨

ost werden, die bei der Entwick-

lung monolithischer Lernplattformen bislang nicht angegangen wurden.

Dar¨

uber hinaus verlangt es die Losl¨

osung von der an einzelnen und isolierten Systemen

orientierten Herangehensweise in der Entwicklung von E-Learning-Komponenten. Die-

se sollte zwischen und innerhalb der einzelnen Funktionsbereichen (Lehre, Verwaltung,

Forschung) abgestimmt sein, bspw. im Rahmen eines institutionalisierten hochschul-

weiten Architekturmanagements, welches nicht nur eine Technologiestrategie impliziert,

sondern auch ein definiertes Vorgehensmodell f¨

ur die Entwicklung und Erweiterung der

IT-Infrastruktur durch E-Learning-Werkzeuge.

Die Transformation von einer verteilten kooperativen IT-Versorgung hin zu einer in-

tegrierten Informationsversorgung an Hochschulen bedingt demnach eine strukturierte

Herangehensweise, die sowohl strategische als auch organisatorische und softwaretechni-

sche Aspekte umfasst.

1.3. Problembeschreibung und Zielsetzung der Arbeit

Drei wichtige Herausforderungen hochschulweiter E-Learning-Infrastrukturen sollen an

dieser Stelle n¨

aher beschrieben werden, um daran die konkrete Zielsetzung dieser Arbeit

auszurichten.

Verbesserung der Kommunikation Eine Abstimmung der Medienentwicklung zwi-

schen und innerhalb der Fach- und Funktionsbereiche einer Hochschule funktioniert nur

dann gut, wenn die Kommunikation zwischen Anwendern, Softwareentwicklern, Medi-

endesignern und Didaktikern nicht gest¨

ort ist (vgl. bspw. [GS96], S. 3, [PR04], S. 288f.,

[FP04]). Eine h¨

aufig auftretende St¨

orung liegt bspw. in den unterschiedlichen Blickwin-

keln bzw. unterschiedlich interpretierten Begriffen, die von diesen Gruppen zur Formulie-

rung von Anforderungen benutzt werden (vgl. [Ort95], S. 148f., [Hel97], S. 90f.). So kann

zum Beispiel ein einfaches aber elementares organisatorisches Konzept wie eine ”Ver-

anstaltung“ an verschiedenen Fachbereichen oder in verschiedenen Pr¨

ufungsordnungen

eine grundlegend unterschiedliche Bedeutung haben.

Doch nicht nur die unterschiedlichen Intentionen fachlicher Bezeichnungen bedeuten

eine St¨

orungsursache. Insbesondere der Bruch zwischen der pr¨

aformalen Fachsprache

der Anwender und der zur Spezifikation und Entwicklung genutzten formalen Sprachen

stellt eine Quelle f¨

ur Missverst¨

andnisse dar, da die vom Entwickler h¨

aufig verwendeten

k¨

unstlichen Sprachen und Diagrammmethoden von den Anwendern nicht gelesen und

ein gemeinsames Verst¨

andnis von Sachverhalten somit nur schlecht ¨

uberpr¨

uft werden

kann. Die Systemanalyse ist demnach ”nur ein Durchgangsmedium, denn prim¨

ares Aus-

drucksmittel unserer Gedankenwelt sind Begriffe“ [Hel97], S. 90. Das eigentliche Pro-

blem, das durch das Abbilden der Fachsprachen auf formale Beschreibungssprachen

nach dem Konzept einer Interpretationssemantik (Verbalisierung, vgl. [Ort98]) entsteht,

ist der Mangel an einer objektorientierten Spezifikation von Fachkonzepten auf der

1. Einleitung

Grundlage einer Rekonstruktion von allen gemeinsam verst¨

andlichen Fachbegriffen bzw.

-konzepten. Entwicklungsergebnisse k¨

onnen somit zwar immer noch im Hinblick auf

ihre Struktur ¨

uberpr¨

uft werden, jedoch nicht mehr auf ihre Anforderungsgerechtigkeit

(vgl. ebenda). Daraus resultiert eine im universit¨

aren E-Learning h¨

aufig anzutreffende

Prototyp-orientierte Softwareentwicklung, die sehr zeitintensiv ist. Eine bessere L¨

osung

stellt jedoch eine normsprachliche Softwareentwicklung dar, bei der bereits f¨

ur die Anfor-

derungsbeschreibung gemeinsam verstandene und rekonstruierte Fachbegriffe verwendet

werden, die eine eindeutige Zuordnung zu den in der Entwicklung verwendeten Fachob-

jekten besitzen (vgl. [Hel97], [Sch97a], [Ort00], [HR05], [RH05]).

Erstes Ziel dieser Arbeit ist daher die Konstruktion einer kontrollierten Sprache zur

Spezifizierung universit¨

arer Lern- und Arbeitsumgebungen, bestehend aus einer Samm-

lung von Fachbegriffen (Terminologie) und einer eingeschr¨

ankten Grammatik (Satzbau-

regeln). Diese so genannte Normsprache muss alle notwendigen Aspekte der Anforde-

rungsbeschreibung formal korrekt abdecken k¨

onnen.

Komponentenorientierte Entwicklung Die technischen Realisierungen eines integrier-

ten Informationsmanagements an Hochschulen basieren bereits zunehmend auf dem

Konzept einer serviceorientierten Architektur (vgl. [MMF07], S. 19). Erste Implemen-

tierungen fokussieren dabei insbesondere die Integration von Lernmanagement in insti-

tutionale Kontexte ¨

uber offene Schnittstellen (siehe S. 46; vgl. hierzu auch [DEH+02],

[BCG03], [XYES03], [RSS04], [RHG05], [GR07], [JHM07]). Dabei wird oftmals das soft-

waretechnische Prinzip der Refaktorierung (Refactoring, vgl. [FBB+99] u. [KZ02]) ange-

wandt, also bestehende Systemstrukturen weiterentwickelt und z. B. vorhandene Schnitt-

stellen so transformiert, dass sie den Standards der Komponentenarchitektur entsprechen

und somit in die serviceorientierte Architektur integriert werden k¨

onnen8. Diese L¨

osung

ist f¨

ur den ¨

Ubergang hin zu einer dienstorientierten IT-Infrastruktur sicherlich geeignet.

F¨

ur neu zu entwickelnde virtuelle Lern- und Arbeitsumgebungen stellt dieser Weg – also

die Entwicklung als monolithisches System und sp¨

atere Transformation von Schnittstel-

len – aber eine teure und schwer wartbare L¨

osung dar, weil eine system¨

ubergreifende

Semantik mit internen Systemstrukturen im Einklang gehalten werden muss.

Neue Lerntechnologien sollten dann besser von Grund auf komponentenorientiert

entwickelt werden, um eine leichte Wiederverwendbarkeit in verschiedenen Szenarien

gew¨

ahrleisten zu k¨

onnen.

Dies bedingt allerdings neben dem Einhalten von Standards ein ingenieurm¨

aßiges Vor-

gehen bei der Softwareentwicklung von Lehr-/Lernsystemen, dass im Allgemeinen bis-

lang nicht ¨

ublich ist. Untersuchungen von Harrer und Martens haben diesbzgl. gezeigt,

dass komplexere Lehr-/Lernsysteme h¨

aufig entsprechend der Fachdom¨

ane oder orientiert

8Harrer diskutiert die Technik des Refaktorierens im Kontext von Lehr-/Lernsystemen in [Har03].

Bazijanec et al. beschreiben in [BGKT07], S.47ff., die damit verbundenen Herausforderungen aus

organisatorischer Sicht. Demnach kann es den Verantwortlichen dezentral betriebener Systeme letzt-

endlich sogar zu negativen Anreizen im Hinblick auf eine Integration kommen, wenn trotz dem

Mehraufwand der Refaktorierung Funktionen einzelner Systeme wegfallen, wenn diese nicht in ein

Gesamtkonzept ¨

ubernommen werden.

1.3. Problembeschreibung und Zielsetzung der Arbeit

an einem kognitiven/p¨

adagogischen Ansatz konzipiert werden, ohne softwaretechnischen

Anforderungen wie Architekturdetails, Systemschnittstellen oder Erweiterbarkeit Rech-

nung zu tragen (vgl. [HM05], S. 179). Diese werden zugunsten von kurzfristigen Projekt-

zielen und isolierten Softwareprodukten vernachl¨

assigt, was zu Problemen und Kosten

bei der Entwicklung bzw. Weiterentwicklung f¨

uhrt (vgl. hierzu auch [B¨

ol02], S. 10):

âDie Entwicklung von E-Learning-spezifischen Funktionen beginnt im Wesentlichen

wieder bei Null. Funktionalit¨

at, die in anderen Lernsystemen bereits vorhanden ist,

wird wieder neu implementiert. Die Folge sind lange Entwicklungszeiten und hohe

Kosten.

âDer Beginn bei Null f¨

uhrt auch dazu, dass der Aufwand, der f¨

ur die Neuimplemen-

tierung von Basisfunktionen eingesetzt werden muss, an anderen Stellen oftmals

fehlt, z. B. f¨

ur die Qualit¨

atssicherung. Mangelhafte Dokumentation, wiederkehren-

de Fehler in Basisfunktionen und – wenn ¨

uberhaupt – nur unzureichende Tests

sind das Ergebnis, so dass die Qualit¨

at einer Software h¨

aufig erst in der zweiten

oder dritten Version einen akzeptablen Stand erreicht.

âIm Lebenszyklus einer Software kann sich dessen Umfeld mehrmals ver¨

andern, so

dass der Bedarf an Wartung bzw. Weiterentwicklung gegeben ist. Bei der Neu-

entwicklung eines Systems sollte also dessen leichte Wartbarkeit und Erweiter-

barkeit ein wichtiges Kriterium sein. Dies erfordert jedoch einen h¨

oheren konzep-

tuellen Aufwand, der in der Praxis h¨

aufig zu Gunsten kurzfristiger Projektziele

vernachl¨

assigt wird. Hohe Kosten f¨

ur Wartung und Weiterentwicklung sind dann

”vorprogrammiert“.

Es stellt sich damit die Frage, warum die Entwicklung von Lernsystemen im univer-

sit¨

aren Kontext nicht ”baukastenorientiert“ auf Basis von Fachkomponenten9erfolgt. E-

Learning-spezifische Funktionen k¨

onnen – in Komponenten gekapselt – bei der Entwick-

lung neuer Lernumgebungen wiederverwendet werden, was Zeit und Kosten einer Neu-

entwicklung verringern und somit Ressourcen freigeben w¨

urde f¨

ur Qualit¨

atssicherung,

konzeptuelle Vor¨

uberlegungen und zur Erstellung eines dom¨

anenspezifischen Modells zur

Kommunikation und Anforderungsanalyse. Die normsprachliche Entwicklung von Kom-

ponenten auf Grundlage eines dom¨

anenspezifischen, semantischen Modells garantiert

dar¨

uber hinaus einen deutlich h¨

oheren Integrationsgrad10.

In der Praxis scheint die Wiederverwendung von Systemen, Systemkomponenten oder

Systemmodellen im E-Learning bislang jedoch kaum gegl¨

uckt (vgl. [HM05]). Die Ursa-

che hierf¨

ur kann zum einen daran liegen, dass es Kosten verursacht, Projektergebnisse

parametrisierbar und flexibel zu halten. Insbesondere in universit¨

aren Organisations-

strukturen mit bislang h¨

aufig fehlenden Verrechnungsm¨

oglichkeiten f¨

ur intern erbrachte

Dienstleistungen (vgl. [FB06], S. 66) scheint erst einmal unklar, wer f¨

ur diese Kosten

aufkommen soll.

9In der Literatur finden sich viele Bezeichnungen, z. B. Business Objects, Anwendungselemente oder

Application Objects. Im weiteren Verlauf dieser Arbeit wird jedoch der Begriff Komponente oder

Fachkomponente verwendet. Eine genauere Definition folgt in Kapitel 4.

10Zur Forderung nach semantischer Angemessenheit in Komponentenarchitekturen schreibt Frank

in [Fra94], S. 28: ”Keine Komponente sollte gen¨

otigt sein, die Semantik von [empfangenen] Daten

m¨

uhsam und unter Risiko zu rekonstruieren. Je mehr ein System dieser Forderung gen¨

ugt, desto

h¨

oher ist sein Integrationsniveau“.

1. Einleitung

Zum anderen ist die Ber¨

ucksichtigung der Wiederverwendbarkeit im Softwareentwurf ge-

nerell auch eine konzeptuelle Herausforderung: Entscheidend ist die Wahl des richtigen

Abstraktionsgrades einer Systemkomponente, damit sie f¨

ur unterschiedliche Einsatz-

szenarien passend konfiguriert werden kann11. Dar¨

uber hinaus besteht in heterogenen

Architekturen auch die Gefahr des so genannten architectural mismatch, wenn trotz des

komponentenorientierten Ansatzes die gew¨

ahlte Systemarchitektur mit der Architektur

der zu nutzenden Komponente nicht harmoniert (vgl. [GAO95])12. Ein weiteres Hemm-

nis ist sicherlich das derzeitige Fehlen eines externen Komponentenmarktes.

Erkl¨

artes zweites Ziel dieser Arbeit ist daher die Verbesserung des softwaretechnischen

Vorgehens bei der Entwicklung universit¨

arer Lern- und Arbeitsumgebungen. Zu diesem

Zweck soll eine Rahmenarchitektur f¨

ur komponentenbasierte virtuelle Lern- und Ar-

beitsumgebungen spezifiziert werden, die dem besonderen universit¨

aren Umfeld gerecht

wird. Die zu spezifizierende Rahmenarchitektur muss dabei technologie- und plattform-

unabh¨

angig sein, damit von ihr in der Praxis konkrete Architekturen abgeleitet werden

k¨

onnen. Um einen Leitliniencharakter zu gew¨

ahrleisten, sollen notwendige Komponen-

ten der E-Learning-Infrastruktur, deren Aufgaben, Zusammenwirken und Systemgrenzen

beschrieben werden sowie die generelle Integration in das universit¨

are Umsystem.

Strukturiertes Vorgehen Die Erweiterung einer konkreten komponentenorientierten

Architektur um darauf aufbauende Lern- und Arbeitswerkzeuge ist eine wiederkehrende

Aufgabe an einer Universit¨

at der Wissensgesellschaft. Insbesondere aus ¨

okonomischen

Gr¨

unden, aber auch im Sinne einer verbesserten Transparenz und Prozess- und Soft-

warequalit¨

at, sollte diese Aufgabe methodisch fundiert angegangen werden.

Aus diesem Grund ist das dritte Ziel dieser Arbeit die Konstruktion eines entspre-

chenden methodischen Vorgehens, das sowohl die o. g. normsprachliche Anforderungsbe-

schreibung als auch die komponentenorientierte Umsetzung im Sinne der zu spezifizie-

renden Rahmenarchitektur als ganzheitlichen Ansatz umfasst.

Abbildung 1.1 fasst die Nutzenpotenziale des hier skizzierten systematischen Ansatzes

aus softwaretechnischer Sicht noch einmal zusammen.

11Der Abstraktionsgrad kann auf zwei Arten gew¨

ahlt werden (vgl. [B¨

ol02], S. 12): (1) Parameter und

Abstraktionen k¨

onnen nach bestem Wissen spekulativ in die Komponenten und Frameworks einge-

baut werden. Dabei besteht aber immer die Gefahr, wichtige Parameter und Abstraktionen verges-

sen zu haben bzw. zu viele unwichtige Parameter und Abstraktionen eingebaut zu haben, was eine

Wiederverwendung verkompliziert. (2) Parameter und Abstraktionen k¨

onnen bei Bedarf eingebaut

werden. Dieser Ansatz impliziert allerdings h¨

aufig umfangreiche ¨

Anderungen an der Architektur von

Frameworks und Komponenten und kann daher zur raschen Degeneration f¨

uhren.

12Durch die ¨

Offnung von Komponentenschnittstellen als Dienst wird dieses Argument abgeschw¨

acht.

Allerdings kann es auch in SOAs zu Inkompatibilit¨

aten kommen, z. B. durch die Verwendung unter-

schiedlicher Protokolle wie REST oder SOAP oder verschiedener Message-Bus-Systeme.

1.4. Aufbau der Arbeit

Kosten

Zeit

Qualität

klassischer

Entwicklungsansatz

systematische

Entwicklung

Kostenreduktion, z. B. durch:

– Zeitreduktion im SW-Entwicklungsprozess

– Vermeidung von Fehlern durch auf den

Problembereich zugeschnittene Modelle,

Methoden und Prototypen

– Einsparung von Mehrfacherfassungen und

Medienbrüchen durch höhere Integration

Zeitreduktion, z. B. durch:

– eﬀektivere Kommunikation zwischen

SW-Designern u. Stakeholdern

– vereinfachte objektorientierte Analyse

durch vorgegebene Terminologie

– größere Wiederverwendung von

Medienfunktionen an Objekten

Qualitätssteigerung, z. B. durch:

– verbesserte Integration durch einheitliche

Semantik in SW-Komponenten

– frühere Bereitstellung funktionierender

Prototypen im Entwicklungsprozess

– Möglichkeiten zur schnellen Interaktion an

allen verfügbaren Informationsobjekten

Abbildung 1.1.: Nutzenpotenziale eines systematischen Ansatzes in der Praxis

1.4. Aufbau der Arbeit

Der Hauptteil der Arbeit gliedert sich in acht Kapitel. Der Grundaufriss besteht aus

einem Grundlagenteil (Kapitel 2), einem Hauptteil (Kapitel 3-5) und einem Schlussteil

(Kapitel 6-7).

Im Anschluss an das vorliegende einleitende erste Kapitel wird im zweiten Kapitel

der Problembereich und sein Umsystem n¨

aher erl¨

autert. Dabei stehen das universit¨

are

E-Learning zusammen mit der organisatorischen und technischen IT-Infrastrukturent-

wicklung an deutschen Hochschulen im zentralen Fokus. Ihre Einflussfaktoren sind zum

einen die aktuellen Trends im E-Learning, zum anderen die Evolution des Internets

(”Web 2.0“). Beide Einflussrichtungen werden beschrieben, Trends werden herausge-

stellt und ihre Auswirkungen auf das universit¨

are E-Learning erl¨

autert. Aus Gr¨

unden

der besseren Lesbarkeit werden die theoretischen Grundlagen des L¨

osungsansatzes –

terminologiebasierte Softwareentwicklung, komponentenorientierte Architekturen und

Methoden-Engineering – nicht in Kapitel 2 mit aufgenommen, sondern in den entspre-

chenden Kapiteln vorgestellt, in denen sie auch weiter ausgef¨

uhrt werden.

In Kapitel 3 soll das erste Teilziel erarbeitet werden: Nach einer theoretischen Fundie-

rung zu Normsprachen und terminologiebasierter Softwareentwicklung wird die Meta-

pher virtueller Wissensr¨

aume als semantisches Bezugssystem vorgestellt, auf das der in

dieser Arbeit beschriebene Softwareentwicklungsprozess beruht. Die Nutzung der Ter-

minologie zur Spezifizierung und Implementierung von Lehr-/ Lerntechnologien wird im

dritten Unterkapitel erkl¨

art.

1. Einleitung

Das zweite Teilziel, die Spezifizierung einer Rahmenarchitektur f¨

ur komponentenbasierte

Lehr-/Lernumgebungen, ist Thema des Kapitels 4. Zur theoretischen Fundierung wird

zuerst der Architekturbegriff erkl¨

art, um diesen dann im Kontext universit¨

arer Informa-

tionsarchitekturen weiter auszuf¨

uhren. Die gemeinsame Betrachtung von der Entwick-

lung wiederverwendbarer Komponenten und der Entwicklung von darauf basierenden

konkreten Anwendungen in einem Vorgehensmodell wird aus technischer Sicht konkre-

tisiert. Letztendlich stellt die Spezifizierung einer solchen Architektur f¨

ur universit¨

ares

E-Learning den Hauptteil des Kapitels, indem ben¨

otigte Komponenten und das Zusam-

menspiel von Komponenten beschrieben werden.

Um eine Systematik bei der Softwareentwicklung sowohl auf Basis der Wissensraum-

metapher als auch auf Basis eines Produktfamilien-basierten Ansatzes gew¨

ahrleisten zu

k¨

onnen, wird in Kapitel 5 eine entsprechende Methode konstruiert. Im Wesentlichen

wird ein Vorgehensmodell hergeleitet und das Metamodell der Methode sowie das dazu

geh¨

orende Rollenmodell und eine Techniksammlung beschrieben.

In Kapitel 6 wird die praktische Anwendung des in dieser Arbeit erarbeiteten An-

satz am Beispiel der an der Universit¨

at Paderborn hochschulweit eingef¨

uhrten Lern-

und Arbeitsplattform koaLA geschildert. Es werden beispielhaft wissensraumbasierte

Komponenten beschrieben, wie auch deren Integration in die universit¨

are Informations-

architektur oder externen Content-Netzwerken. Insbesondere wird auf die Umsetzung

der in Kapitel 2.3 aufgezeigten neuen Einfl¨

usse des Web 2.0 auf das E-Learning – spezi-

ell der Einbindung benutzergenerierten Contents und soziale Kontakte in Lernszenarien

– eingegangen.

Die Arbeit schließt mit einer kritischen W¨

urdigung der Arbeit und einen Ausblick.

1.5. Wissenschaftlicher Beitrag

Der Bereich E-Learning umfasst im Kontext der Wirtschaftsinformatik nicht nur den

Prozess des Wissenserwerbs im engeren Sinn. Dar¨

uber hinaus bed¨

urfen die Konstruktion,

Kommunikation und Evaluation von Wissen einer angemessenen Unterst¨

utzung durch

Informationssysteme. Speziell die Modernisierung universit¨

arer IT-Infrastrukturen zur

alltagstauglichen Unterst¨

utzung eines integrierten Informationsmanagements in Lehre

und Verwaltung wird mit zunehmenden Leidensdruck durch steigende Studierendenzah-

len und Serviceanspr¨

uche sowie der Einf¨

uhrung konsekutiver Studieng¨

ange immer mehr

zu einem neuen Anwendungsgebiet der Wirtschaftsinformatik13.

Diesem Kontext ist auch die vorliegende Dissertationsschrift zuzuordnen. Es soll ein

systematisches Vorgehen zu Entwurf und Entwicklung komponentenorientierter, inte-

grierter Lern- und Arbeitswerkzeuge konzipiert werden, das durch eine auf die Problem-

stellung angepasste Softwarerahmenarchitektur unterst¨

utzt wird. Dadurch soll einerseits

technologiestarken Lehreinheiten eine effiziente Entwicklung individueller Lernumgebun-

gen zu Forschungszwecken und als Profilierungsm¨

oglichkeit geboten werden, andererseits

13Dies belegen die steigenden Zahlen der wissenschaftlichen Ver¨

offentlichungen in diesem Bereich und

die Ber¨

ucksichtigung von E-Learning und integrierten Campus-Management-Systeme auf Fachkon-

ferenzen, bspw. der 9. Internationalen Tagung Wirtschaftsinformatik 2009 (Track 32 und 33).

1.5. Wissenschaftlicher Beitrag

denjenigen Lehreinheiten, die dies aus eigener Kraft respektive fehlenden Ressourcen

nicht stemmen k¨

onnen, eine niedrigschwellige, konfigurierbare E-Learning-Umgebung

zur Verf¨

ugung gestellt werden.

Dabei ergeben sich nach dem Kenntnisstand des Autors wissenschaftliche Neuerungen

gleich an mehreren Stellen:

1. Das Konzept der normsprachlichen Entwicklung von Informationssystemen wurde

bisher nicht auf das in dieser Arbeit behandelte Anwendungsgebiet angewandt.

2. Es gibt bislang kein Vorgehensmodell zur Entwicklung von Lernumgebungen, wel-

ches auf die Umsetzung mehrerer integrierter Werkzeuge ausgerichtet ist. Bisherige

Ans¨

atze fokussieren ausschließlich die Implementierung monolithischer Plattfor-

men.

3. Ebenso gibt es bislang keine Rahmenarchitektur f¨

ur hochschulweites E-Learning,

die einen zentralen Dienstekern als Basis und Integrationsplattform vorsieht.

4. Die Umsetzung und die hochschulweite Einf¨

uhrung einer offenen Komponentenar-

chitektur f¨

ur E-Learning ist ein im deutschsprachigen Raum bisher selten realisier-

tes Anwendungsbeispiel.

Nach Meinung des Autors handelt es sich demnach um eine sowohl theoretisch als auch

praktisch h¨

ochst relevante Problemstellung, die es in den n¨

achsten Kapiteln bestm¨

oglich

zu l¨

osen gilt.

1. Einleitung

2. Beschreibung des Problembereichs

und der Einflussfaktoren

In diesem Kapitel wird auf das in der Einleitung umrissene Problemfeld detaillierter

eingegangen und gegen¨

uber verschiedenen anderen Handlungsfeldern und Forschungs-

bereichen abgegrenzt. Dazu wird zun¨

achst die Motivation zur Auseinandersetzung mit

neuen Medien an Hochschulen erkl¨

art, sowie die derzeitigen Rahmenbedingungen f¨

ur ih-

ren alltagstauglichen und effizienten Einsatz (2.1). F¨

ur das Verst¨

andnis des Problemfelds

von entscheidender Bedeutung sind die aktuellen Entwicklungen im Bereich des compu-

terunterst¨

utzten Lernens. Daher gibt Abschnitt 2.2 einen kurzen Gesamt¨

uberblick ¨

uber

Begriffe und Konzepte des E-Learnings, um im Anschluss daran die derzeitigen Stan-

dardisierungsbestrebungen speziell im Bereich der Softwarearchitekturen von Lernum-

gebungen einzuordnen. Neue technologische und soziologische Trends des so genannten

Web 2.0 beeinflussen diese Entwicklungen ebenfalls sehr stark. Abschnitt 2.3 beschreibt

diese Trends und zeigt daran Verbesserungspotenziale auf, die bei der (Re-)Konzeption

universit¨

arer Lern- und Arbeitsumgebungen angemessen ber¨

ucksichtigt werden m¨

ussen.

Eine Zusammenfassung schließt die Konkretisierung des Problemfelds ab (2.4).

2.1. E-Learning an deutschen Hochschulen

2.1.1. Nationale Bildungspolitik und F¨

ordermaßnahmen

Um den Strukturwandel im deutschen Bildungsbereich voranzutreiben, der durch die

Globalisierung und die IuK-Techniken induziert ist, initiierten der Bund und die L¨

ander

um das Jahr 2000 umfangreiche Forschungs-, Entwicklungs- und Pilotmaßnahmen. Le-

benslanges Lernen sollte damit nachhaltig f¨

ur alle Menschen gef¨

ordert und Bildungs-

strukturen zukunftsorientiert angepasst werden. Dabei sollten einzelne Modellversuche

und Pilotprojekte als Leuchtt¨

urme eine exemplarische Umsetzung des hochkomplexen

Konzeptes des lebenslangen Lernens im Kleinen aufzeigen. Entsprechende F¨

orderpro-

gramme sollten diese neuen Erkenntnisse in die Breite tragen. Die schwerpunktm¨

aßige

Zielsetzung dieser F¨

orderprogramme bestand dabei aus den drei Aspekten Vernetzung,

Infrastrukturausbau und einer neuen Funktionszuweisung f¨

ur Schulen und Hochschulen1:

1Im Weiteren dieser Arbeit wird der Fokus prim¨

ar auf die Hochschulbildung gelegt.

2. Beschreibung des Problembereichs und der Einflussfaktoren

Vernetzung Auf regionaler und ¨

uberregionaler Ebene wurden bildungsbereichs- und

-tr¨

ager¨

ubergreifende Kooperationsverb¨

unde gef¨

ordert. Diese bestanden neben ¨

offentlich-

en Schulen, Hochschulen und Bibliotheken auch aus kommerziellen Weiterbildungsein-

richtungen und Herstellern von Lernsoftware und -inhalten. Somit sollte zum einen der

Markt an Bildungsanbietern und -interessenten f¨

ur alle transparent und stimuliert, zum

anderen aber auch formale und informelle Lernorte miteinander verkn¨

upft werden.

Infrastrukturausbau Zusammen mit der deutschen Telekom gr¨

undete das Bundesmi-

nisterium f¨

ur Bildung und Forschung (BMBF) den Verein ”Schulen ans Netz“ mit dem

Ziel, alle allgemein bildenden Schulen in Deutschland mit einem Internetanschluss aus-

zustatten und die Medienkompetenz von Sch¨

ulern und Lehrern zu f¨

ordern2. Im Hoch-

schulsektor wurde an vielen Universit¨

aten sowohl die interne Vernetzung durch Funknetz

gef¨

ordert3als auch die Vernetzung der Universit¨

aten untereinander durch das deutsche

Forschungsnetz auf 100 Gigabit ausgeweitet.

Neue Funktionszuweisung an Hochschulen Mit dem Hochschulrahmengesetz von 1998

wurde die universit¨

are Weiterbildung als gleichrangig neben Forschung und Lehre ge-

stellt (§2 Abs. 1 HRG). Gleichzeitig wurden die Hochschulen aufgefordert, ihre Angebote

des lebenslangen Lernens zu verbessern und anzupassen4. Durch die Modularisierung der

Angebote sowie die Ausweitung der Autonomie und Flexibilit¨

at der Hochschulen sollten

die M¨

oglichkeiten daf¨

ur geschaffen werden5. Die Umsetzung an den Hochschulen gestal-

tete sich jedoch als schwierig, konnten Dozierende ihre Weiterbildungsaktivit¨

aten nicht

auf das regul¨

are Lehrdeputat anrechnen lassen6. Als Konsequenz daraus entstanden an

vielen Universit¨

aten zentrale Weiterbildungseinrichtungen, welche die hochschulischen

Angebote (zumeist durchgef¨

uhrt durch f¨

ur diese Zwecke gegr¨

undeten An-Institute) seit-

dem initiieren und koordinieren. Weiterhin wurden an vielen Universit¨

aten mittlerweile

die M¨

oglichkeiten der Gasth¨

orerschaft ausgeweitet und es werden Seniorenkollegs ange-

boten (vgl. [SSW+06], S. 89ff., S.313).

Bei der F¨

orderung von Inhalten f¨

ur Hochschulen setzte das BMBF auf sein Programm

2Ende 2001 waren alle Schulen mit einem Internetanschluss ausgestattet. Ende 2006 sind mehr als

20.000 Schulen (von rund 34.000) mit modernen Breitbandanschl¨

ussen ausgestattet.

3Im F¨

orderprogramm Neue Medien in der Bildung wurden vom BMBF 41 WLAN-Projekte

(F¨

ordersumme ¨

uber 5 Mio. EUR, Laufzeit 4 Monate) und 25 Notebook-University-Projekte

(F¨

ordersumme ca. 26 Mio. EUR, Laufzeit 14-20 Monate) unterst¨

utzt.

4Allerdings wurden diese Forderungen nie weiter konkretisiert, womit das Problem und die L¨

osung der

Umsetzung lebenslangen Lernens eigentlich nur von der politischen Ebene auf die der Hochschulen

durchgereicht wurde (vgl. [Keh01], S. 129ff.).

5Erste Evaluationen haben jedoch ergeben, dass aufgrund der festgelegten Modulstrukturen und der

strafferen Organisation zum einen die inhaltlichen Gestaltungsspielr¨

aume f¨

ur Lehrende kleiner wer-

den (also auch die M¨

oglichkeit, auf neue Themen schnell und flexibel reagieren zu k¨

onnen), zum

anderen die M¨

oglichkeiten f¨

ur Praktika, Nebent¨

atigkeiten und Auslandsaufenthalte einschr¨

anken,

sofern sie nicht laut Pr¨

ufungsordnung verbindlich vorgesehen sind (vgl. [JG07]).

6Kehm nennt in [Keh01], S. 130, noch weitere Gr¨

unde: Zum einen war eine Nachfrage nach universit¨

arer

Weiterbildung zu dem Zeitpunkt nicht hinreichend konkret, zum anderen hatte die wissenschaftliche

Weiterbildung nur einen marginalen Stellenwert in der durch Forschung gepr¨

agten traditionellen

Werthierarchie.

2.1. E-Learning an deutschen Hochschulen

Neue Medien in der Bildung7(vgl. [BMB00]). Durch den Aufbau und der Nutzung

multimedialer Informationsquellen f¨

ur Dozierende und Studierende sollten die ”Neuen

Medien“ auf breiter Front Einzug in die Weiterbildung halten. Dazu wurden insgesamt

100 ausgew¨

ahlte Projekte (E-Learning-Arrangements) gef¨

ordert, deren Aufgabe im We-

sentlichen die Bereitstellung von Inhalten war (Content-Projekte) und die gleichzeitig die

neue Lehr- und Lernkultur implementieren sollten: Informelles, selbstgesteuertes Lernen,

in Verbindung mit Lernberatung und Motivierung.

Da die oben genannten Infrastrukturprojekte (WLAN- und Notebook-University) aber

in erster Linie auf die Anpassung der technischen und organisatorischen Vernetzung der

universit¨

aren Infrastruktur abzielten und weniger auf die Bereitstellung von Lernum-

gebungen f¨

ur die neuen Inhalte, entstanden in den Content-Projekten sozusagen als

Nebenprodukt sehr viele Individuall¨

osungen8, welche noch Jahre sp¨

ater den heutigen

Heterogenit¨

atsgrad der universit¨

aren IT-Landschaften stark beeinflussen. Dieser Effekt

wurde noch durch mehrere Faktoren verst¨

arkt: Erstens wurden die Content-Projekte

nur als Verbundprojekte mit einer Spannbreite von zwei bis 17 Kooperationspartnern

gef¨

ordert, was eine stattliche Zahl von 540 Einzelprojekten ergab (vgl. [Bau03a], S. 5).

Dies f¨

uhrte innerhalb der beteiligten Universit¨

aten zu einem unsystematischen Neben-

einander von Aktivit¨

aten im selben Feld, da es zweitens nur in seltenen F¨

allen hoch-

schulweite Strategien und Pl¨

ane gab. Als dritter verst¨

arkender Faktor wirkte zu diesem

Zeitpunkt das Nicht-Vorhandensein von Standards f¨

ur Lernumgebungen und -inhalte9.

Nicht zuletzt befand sich die Forschung zu diesem Thema auf ihrem H¨

ohepunkt, so dass

selbst innerhalb von Verbundprojekten die beteiligten Partner verschiedene L¨

osungen

konzipierten, implementierten und evaluierten (s. [RS05], S. 146ff.).

Bei Nachhaltigkeits¨

uberlegungen zu einer hochschulweiten Ausweitung der E-Learning-

Angebote auf alle Lehrenden und Studierenden ergab sich durch die ansteigende Zahl

der Nutzerinnen und Nutzer ein Skalierungsproblem10, das mit den damaligen isolier-

ten Strukturen nicht mehr bew¨

altigt werden konnte: Interne Strukturen und Aufga-

ben m¨

ussen dazu entsprechend angepasst und ¨

ubergreifend aufgebaut werden11 (vgl.

[Kub04], S. 2). Ein f¨

ur den nachhaltigen Einsatz notwendiger Schritt ist dabei der Auf-

bau einer organisatorischen und technischen Vernetzung in den Hochschulen und den in

ihrem Umfeld etablierten Einrichtungen (vgl. ebd., vgl. [Sch04a], S. 1).

Da die initialen F¨

ordermaßnahmen hierzu nicht ausreichten, wurde der F¨

orderschwer-

punkt ”Neue Medien in der Bildung“ um ”Maßnahmen der Strukturentwicklung“ im

Jahr 2004 ausgeweitet, die bis zum Jahr 2008 die ”systematische und professionelle

Produktion und Nutzung digitaler Lehrmaterialien jenseits von Drittmitteln finanzierten

7F¨

orderinitiative ”Einsatz Neuer Medien in der Hochschullehre“, F¨

ordersumme ca. 180 Mio. EUR.

8Aus dem Audit-Bericht: ”Fast alle Projekte haben Lehr-/Lerneinheiten produziert (94 %), w¨

ahrend

der Anteil derjenigen Projekte, die (auch) Produkte im Bereich der Wissensressourcen und Tools

entwickelt haben, etwas mehr als die H¨

alfte ausmacht (55 bzw. 52 %)“, [Bau03a], S. 8.

”Learning Management Systems have evolved so far, but they have each developed independently and

despite the similarities in their feature sets, no interoperability exists between them. Furthermore,

they do not integrate with other third-party systems“ [BCG03].

10Sowohl organisatorisch als auch technisch, denn die meisten Anwendungen waren zumeist auf einen

lehrstuhlinternen Einsatz ausgerichtet (Datenmodell, didaktisches Modell).

11Aufgaben wie Betrieb, technischer Service und Support, Qualifizierung und p¨

adagogischer Sup-

port, Content-Entwicklung, curriculare Integration, Verwaltungsintegration, Marketing sowie Qua-

lit¨

atssicherung und -entwicklung m¨

ussen hochschulweit organisiert werden (vgl. [Kub04], S. 2).

2. Beschreibung des Problembereichs und der Einflussfaktoren

und zeitlich befristeten Projekten und ¨

uber das Engagement von einzelnen Pionieren

hinausgehend“ etablieren soll [Sch04a]. Erstmalig liegt dabei der Fokus nicht mehr nur

auf dem Lehren und Lernen, sondern auf der Umsetzung von Integrationspotenzialen

und Prozessverbesserungen an den jeweiligen Universit¨

aten12 (vgl. ebd.).

2.1.2. Zielgerichteter Einsatz von IuK-Technologien an Hochschulen

Die Erwartungen, die von Politik, Gesellschaft und Wirtschaft an Hochschulen gerichtet

werden, umfassen unter anderem die Etablierung einer den Problemstellungen der Wis-

sensgesellschaft angemessenen Lehr-/Lernkultur sowie eine Verbesserung der Effizienz

der Hochschulen bei der Wahrnehmung ihrer (Weiter-) Bildungsaufgaben13.

In Abschnitt 2.1.2.1 wird die Vielf¨

altigkeit der Anforderungen an konstruktivistisch

gepr¨

agte virtuelle Lern- und Arbeitsumgebungen theoretisch aufgezeigt und den ideal-

typischen Potenzialen des Einsatzes von Multimedia und IuK-Technologie in der Lehre

gegen¨

uber gestellt.

Ein zielgerichteter IKT-Einsatz in der Hochschullehre tr¨

agt dar¨

uber hinaus die Poten-

ziale in sich, gerade durch die Vernetzung von Technologien ¨

uber die Grenzen verschie-

dener Einsatzfelder hinweg, wie E-Learning, E-Science, E-Government und der Digitalen

Bibliothek, Synergieeffekte zu erzielen und zur Effizienzverbesserung von Lehre und Ver-

waltung beizutragen. Abschnitt 2.1.2.2 zeigt diese Potenziale auf.

Zur Implementierung und zum Betrieb einer IT-Infrastruktur, die den gestiegenen

Anforderungen gerecht wird, bedarf es an den meisten Hochschulen auch weitreichender

Anderungen organisatorischer Art, um die neuen Angebote kostendeckend und alltags-

tauglich nachhalten zu k¨

onnen (Abschnitt 2.1.2.3). Entsprechend wichtige informations-

technische Maßnahmen werden in Abschnitt 2.1.2.4 vorgestellt.

2.1.2.1. Neue Medien in der Hochschullehre

In Deutschland kann man r¨

uckblickend zwei große ”Wellen“ von technologischer Un-

terst¨

utzung des Lehrens und Lernens ausmachen. Die erste bildungstechnologische Welle

setzte bereits Mitte der 1960er Jahre ein. Zu der Zeit wurde versucht, mit so genannten

Lernautomaten bessere Lernerfolge zu realisieren. Dabei wurden die behavioristischen

lernpsychologischen Konzepte von B. F. Skinner angewandt, um ¨

uber computergesteu-

erte R¨

uckmeldungen in Frage-Antwort-Mustern das Verhalten des Lernenden respektive

seine Antworten zu beeinflussen. Da diese Programme eine vorprogrammierte Sequenz

von Lernschritten abarbeiten, werden solche Anwendungen auch als programmierte In-

struktion bezeichnet14.

12In einer zweiten F¨

orderlinie wird zwar auch die Verstetigung von E-Learning-Angeboten in hoch-

schul¨

ubergreifenden Netzwerken gef¨

ordert. Aber auch diese sind – trotz ihrer Verankerung an ein-

zelnen Instituten und Fachbereichen – letztlich auf das Backbone der gesamten Hochschulstruktur

angewiesen (vgl. [EKW05], S. 1).

13Kehm geht in [Keh01] genauer auf die Erwartungen an Hochschulen in diesem Kontext ein und

z¨

ahlt neben den hier genannten Aspekten auch die Schaffung eines flexiblen und offenen Zugang zur

Hochschulbildung, Modularisierung und Nachfrageorientierung hinzu (S. 131).

14N. Crowder f¨

uhrte sp¨

ater Verzweigungen in den Sequenzen ein, um in Abh¨

angigkeit von der Art des

Fehlers nicht den gleichen Lerninhalt erneut, sondern alternative Darstellungen anzubieten.

2.1. E-Learning an deutschen Hochschulen

Diese Methodik stieß jedoch auf viel Kritik: Die stereotype Aneinanderreihung von Infor-

mationseinheiten und Pr¨

ufungsfragen ist f¨

ur Lernende oft demotivierend und f¨

uhrt nur

zu m¨

aßiger Akzeptanz, wenn nicht sogar Ablehnung. Zudem kann ein tieferes Verst¨

andnis

der Lerninhalte kaum erschlossen werden, weswegen die Anwendungen vielfach auf reines

Faktenwissen beschr¨

ankt blieben (vgl. [Ker01], S. 65).

Die zweite Welle wurde in den 1990er Jahren initiiert, als die Bearbeitung von Gra-

fiken und die Wiedergabe von Audio und Video sowie Animationen auf dem Computer

f¨

ur jedermann m¨

oglich wurden und Zug¨

ange zum Internet allgemein vorhanden wa-

ren15. Im Vergleich zu traditionellen Medien verf¨

ugen digitale Medien ¨

uber erweiter-

te Darstellungs-, Kommunikations- und Aktualisierungsm¨

oglichkeiten. Dadurch wurde

ihnen gerade f¨

ur die Hochschulbildung neue Qualit¨

aten des Lehrens und Lernens so-

wie Kosteneinsparungen zugewiesen, was zun¨

achst an idealtypischen Potenzialen festge-

macht wurde16:

”Richness“ Reichhaltigkeit in Darstellungsformen (Text, Bild, Ton, Animation, Vi-

deo etc.), Navigationsm¨

oglichkeiten (Hyperlinks, Sitemaps, Themenlisten, Histo-

ry, Bookmarks etc.), Hilfe-Angebote (Hilfe-Seiten, Glossar, Weblinks, integrierte

virtuelle Tutoren etc.), Vermittlungsmethoden (individuelles, problemorientiertes,

selbstgesteuertes, entdeckendes Lernen, Gruppenarbeit etc.) und Einsatzgebiete

(zur Motivation, erg¨

anzend als Informationsquelle, in Selbstlernphasen, zur Vor-

/Nachbereitung, zur Vertiefung etc.)

”Communication“ Interaktivit¨

at zwischen Nutzern und Anwendung (verschiedene For-

men der Benutzungsschnittstelle), mit multimedialen Inhalten (dialektisches Ver-

kn¨

upfen von Kognition und Aktion) und soziale Interaktion (synchrone und asyn-

chrone Kommunikation, soziale Vernetzung, Awareness)

”Suitableness“ Adaptivit¨

at mit den Komponenten, Adaption an individuelle Voraus-

setzungen und Ver¨

anderungen (Anpassung der Lerninhalte an Lernvoraussetzun-

gen, Lerntyp, Lerntempo etc.), Adaptierbarkeit der Inhalte des Systems (sinnvolle,

spezifische Einbindung der Darstellungsformen) sowie Adaptierbarkeit an organi-

satorische Besonderheiten (Anpassung an das Curriculum, das Lernumfeld, die

Zielgruppe, den aktuellen Bedarf etc.)

”Independence“ Ortsunabh¨

angigkeit und zeitliche Unabh¨

angigkeit (Selbstbestimmung

der Lernzeiten, Anpassung an den eigenen Lernrhythmus, Selbsteinteilung der

Stoffmenge etc.). Die Ortsunabh¨

angigkeit (Alokalit¨

at) von Lernen mit digitalen

15In der Zwischenzeit fanden Versuche statt, durch so genannte intelligente tutorielle Systemen den

individuellen Kompetenz- und Wissensstand von Lernenden zu diagnostizieren und mit einem ”idea-

len Modell der Expertise“ zu vergleichen, um Inhalte und Art der Vermittlung f¨

ur den Lernprozess

vorzuschlagen. Dieser Ansatz ist jedoch bis heute noch nicht in vertretbarem Aufwand allgemein,

d. h. dom¨

anenunspezifisch, umzusetzen.

16Obwohl diese Potenziale in der Literatur oftmals zusammen genannt werden, schließen sie sich in der

Praxis u. U. wechselseitig aus. Ein Beispiel ist die Zeitabh¨

angigkeit bei sozialen und kommunikativen

Szenarien. Eine ¨

Ubersicht ¨

uber die Limitierungen bei computerunterst¨

utztem Lernen bietet [Kal03],

S. 58ff.

2. Beschreibung des Problembereichs und der Einflussfaktoren

Medien wird mit Begriffen wie ”in-placE-Learning“ oder ”self-placed-learning“ um-

schrieben

”Broadcast“ Globalit¨

at und Wirtschaftlichkeit bei der Informationsbereitstellung (welt-

weite Bereitstellung, gleichzeitige Nutzung, Wissensmanagement etc.) und den In-

formationszugriff.

Diese Potenziale der neuen digitalen Medien entfachten in der Hochschuldidaktik die

Diskussion ¨

uber alternative Lehr-/Lernformen und regen – auch noch mehr als zehn

Jahre sp¨

ater – zur Entwicklung und Erprobung neuer didaktischer Konzepte an (vgl.

[Sch01b], [SW04], [BD05], [Bau06b], [D¨

ur06], [O’H07]).

Im Fokus stehen dabei selbstorganisiertes Lernen und konstruktivistisch gepr¨

agte

Lernformen, bei denen die eigenst¨

andige Erarbeitung der Inhalte durch den Studieren-

den (Konstruktion) und dessen kognitive bzw. konstruktive Aktivit¨

at im Mittelpunkt

didaktischer ¨

Uberlegungen stehen. Studierende sollen dabei insbesondere zum selbstge-

steuertem Lernen angeleitet werden. Sie sollen Methoden und F¨

ahigkeiten beherrschen

lernen, um kontinuierlich zu lernen, eigene Wissens- und Kompetenzl¨

ucken zu identifi-

zieren, M¨

oglichkeiten zu nutzen, diese zu f¨

ullen und eigene Fortschritte zu verfolgen.

Um den im vorigen Abschnitt skizzierten Strukturwandel in der Hochschulbildung vor-

anzutreiben und um parallel dazu die hier skizzierten idealtypischen Potenziale neuer

Medien f¨

ur Bereiche des Lehrens und Lernens in der Breite umzusetzen, f¨

orderte das

BMBF in den Jahren 2001-2003 im Rahmen des F¨

orderprogramms ”Neue Medien in der

Bildung“ einhundert Projektverb¨

unde (mit insgesamt 541 Einzelprojekten) an deutschen

Hochschulen. Sie sollten virtuelle Studienangebote, virtuelle Lernumgebungen und ent-

sprechende Lern- und Betreuungswerkzeuge f¨

ur verschiedene Fachbereiche entwickeln

und evaluieren (vgl. [BMB00], S. 8ff.). Hochschulpolitische Ziele waren dabei u. a. die

Verbesserung der Qualit¨

at der Hochschullehre, die Erh¨

ohung der Selbst- bzw. Fernstu-

dienanteile und die Entwicklung neuer Lehr-/Lernformen, die Pr¨

asenz- und Online-Lehre

kombinieren sollten17.

Diese F¨

orderinitiative hat zwar keine Revolution der Hochschullehre ausgel¨

ost, aber

grundlegende ¨

Anderungen aufgezeigt, mit denen das Postulat ”Lehrverbesserung“ ein-

gel¨

ost werden konnte (vgl. [Bau03a] und [RB04]). Grunds¨

atzlich wurde durch die neuen

Lernangebote, -umgebungen und -werkzeuge eine kritische Masse an praxistauglichen

Medienprodukten erzeugt (s. [BMB04b]). In einer empirischen Studie ¨

uber die Nutzung

dieser Medienprodukte wurde festgestellt, dass ihr Einsatz vorwiegend in so genann-

ten Blended Learning-Szenarien – auch als Crossmedia-Lernen bzw. Hybrides Lernen

oder Methoden-Mix bezeichnet – erfolgte und somit zu einer Koexistenz traditioneller

und innovativer Lehrstrukturen f¨

uhrte: Neue Inhalte und Methoden erg¨

anzen in diesen

F¨

allen Althergebrachtes (Anreicherungskonzept18). Erkl¨

artes Ziel ist es dabei, durch ei-

ne didaktisch sinnvolle Verkn¨

upfung von traditionellen Lernkonzepten und -medien mit

virtuellem bzw. Online-Lernen ein m¨

oglichst optimales Lernarrangement zu schaffen.

17Weitere hochschulpolitische Ziele waren die Schaffung neuer Fern- und Weiterbildungsangebote sowie

die Herstellung internationaler Wettbewerbsf¨

ahigkeit (vgl. [BMB00], S. 15).

18Weiterf¨

uhrende Quellen zu den Konzepten des Blended Learnings sind [RR03], [Vol04], [SSB04] und

[Rei05a].

2.1. E-Learning an deutschen Hochschulen

Zum Teil kann aber auch von einer qualitativen Verbesserung der Lehre im Sinne einer

neuen Lehr-/Lernkultur gesprochen werden. Neben einer ¨

uberwiegend darstellungsorien-

tierten Nutzung neuer Medien wurden im geringeren Umfang auch offenere, explorative

Lehr-/Lernformen realisiert. Diese stellen die Bed¨

urfnisse der Studierenden st¨

arker in

den Mittelpunkt und unterst¨

utzen ein selbstorganisiertes Lernen und z. T. auch explizit

Partner- und Gruppenarbeit.

Die Zunahme der Partner- und Gruppenarbeit im Vergleich zu traditionellen Ver-

anstaltungsformen steht in den F¨

orderprojekten offensichtlich in Zusammenhang mit

der Nutzung telemedialer Anwendungen, die neue Formen der Interaktivit¨

at zwischen

Lehrenden und Lernenden aber auch zwischen Lernenden untereinander unterst¨

utzen.

In Kombination mit multimedialen Anwendungen k¨

onnen unterschiedliche Veranstal-

tungsformen und Lehr-/Lernmethoden19 virtualisiert werden. Eine ¨

Ubersicht ¨

uber die

am h¨

aufigsten eingesetzten Typen multimedialer Anwendungen und ihre Haupteinsatz-

gebiete ist in Tabelle 2.2 gegeben.

In einem res¨

umierenden Audit des F¨

orderprogramms (vgl. [Bau03a]) wurde neben einer

generell positiven Resonanz – die E-Learning-Community in Deutschland wurde gest¨

arkt

und neue Medien in der Hochschullehre in die Breite getragen – auch einige Kritik ge¨

ubt.

So wurde von den Experten mehrfach bem¨

angelt, dass große Potenziale neuer Medien

in den im F¨

orderprogramm gestalteten Lehr- und Lernsituationen ungenutzt blieben.

Die meisten Medienprodukte boten oft nur darstellende Lernformen an und setzten

die Integration in p¨

adagogisch wichtige Interaktions- und Kommunikationsprozesse nur

l¨

ucken- oder mangelhaft um (vgl. auch [RB04], S. 436). Informationstechnisch gesehen

bieten digitale Medien das Potenzial, Informationsobjekte zu Objekten der Manipula-

tion zu machen und dadurch den neuen Anforderungen nach mehr selbstbestimmten,

aber auch kooperativ organisierten Wissenserwerb in Lernszenarien nachzukommen.

Große Einschr¨

ankungen bzgl. der Kommunikation und Interaktion traten in den im

F¨

orderprogramm neu geschaffenen Lernsysteme aber auf Ebene der Informationstr¨

ager

auf: Viele Systeme betten die Inhalte ein und begrenzen somit durch die feste Verbindung

von Information und Tr¨

ager Zugriffe und Manipulationen. Die Benutzer k¨

onnen also nur

in dem durch das System vorgegebenen Rechte- und Funktionsrahmen auf die Inhalte

zugreifen. Klassische Lernsysteme, die dabei ein festes Rollenmodell von Autoren und

Lernenden implementieren, erlauben zumeist keine direkte Manipulation von Inhalten

durch Lernende. Wenn die somit gesetzten Grenzen f¨

ur bestimmte Benutzergruppen nur

die reaktive Betrachtung, nicht aber die aktive Manipulation zulassen, k¨

onnen weitere

Bearbeitungsschritte nur nach dem Transfer der Inhalte in ein neues Werkzeug realisiert

werden (vgl. [Now05], S. 62). Dadurch werden Medienbr¨

uche erzwungen, die dem Benut-

zer die selbstbestimmte Interaktion mit Materialien erschweren. Analog dazu wird die

Kommunikation ¨

uber Inhalte in kooperativen Szenarien aufw¨

andiger und dadurch auch

komplexer, wenn sie nicht an den Informationsobjekten direkt, sondern ¨

uber nebenste-

19Die Studie von Rinn und Bett z¨

ahlte im Jahr 2004 Skripte, ¨

Ubung, Problembasiertes Lernen, Vor-

trag/Vorlesung und den Dialog zwischen Lehrenden und Lernenden zu den am h¨

aufigsten virtua-

lisierten Szenarien. Danach folgten Seminar, Fallstudie, Projektarbeit, Praktikum, Handapparat/

Bibliothek, Planspiel und die Betreuung von Arbeiten (vgl. [RB04], S. 435).

2. Beschreibung des Problembereichs und der Einflussfaktoren

hende, in sich eigenst¨

andige Technologien, wie Chat, Mailsysteme und Foren, stattfinden

muss. Die Interaktion und Kommunikation wird dann unn¨

otigerweise gebremst, da f¨

Inhalt und Kommunikation jeweils getrennte Kommunikationskan¨

ale verwendet wer-

den m¨

ussen. Keil charakterisiert diese Situation als ”langsame Interaktion“ (s. [KS05a],

S. 16).

Weiterhin kritisierten die Experten, waren die geschaffenen Angebote sehr von organi-

satorischen Strukturen und der Prozesssicht der Lehrenden gepr¨

agt. Informelle Struktu-

ren (bspw. veranstaltungs¨

ubergreifende Lerngruppen) und Anforderungen von Studie-

renden wurden oftmals nicht ber¨

ucksichtigt.

Der zweite große Kritikpunkt war die mangelnde Sorge um die Nachhaltigkeit der

entwickelten Medienprodukte in den einzelnen Projekten. Die von der Bildungspolitik

gesch¨

urten Erwartungen an einen Markt f¨

ur universit¨

are Lerninhalte wurden entt¨

auscht.

Die Nachfrage von Externen oder von anderen Dozierenden gegen ein Entgeld blieb

uber den Zeitraum der F¨

orderung gering, so dass viele Projekte nach ihrem Wegfall ihre

Angebote nicht mehr kostendeckend betreiben konnten.

Auch wurde die Ausnutzung von Skaleneffekten durch die h¨

aufig mangelnde ¨

Uber-

tragbarkeit der entwickelten bzw. eingesetzten Werkzeuge (Software) auf andere Fach-

bereiche verhindert. Die Ausgaben f¨

ur Betrieb, Wartung und Weiterentwicklung der

geschaffenen L¨

osungen mussten daher oftmals im vollen Umfang von den Lehrst¨

uhlen

allein getragen werden. Zu den Betriebs- und Wartungskosten der eigentlichen Software

hielt zus¨

atzlich der eigenverantwortliche Betrieb von Basisdiensten wie Webserver, Mail-

server, Chatserver, Verzeichnisdienst, Datenbank und -sicherung sowie Betriebssysteme

die Kosten hoch, wenn keine Integration in die universit¨

are IT-Infrastruktur erfolgt war.

Daneben bedeutet auch eine solche ”Nicht-Integration“ f¨

ur den Betrieb immer Doppel-

erfassungen von Daten durch Medienbr¨

uche.

Die Expertenkommission regte im Audit des NMB-F¨

orderprogramms daher ein an-

schließendes F¨

orderprogramm an, in welchem die Rahmenbedingungen f¨

ur eine nachhal-

tige mediengest¨

utzte Lehre an Hochschulen weiterentwickelt werden kann. Dies betrifft

sowohl die Vermeidung von Medienbr¨

uchen im gesamten Lehr- und Verwaltungspro-

zess der Hochschulen als auch die Integration der mediengest¨

utzten Angebote in die

strategische Profilbildung der Hochschulen, L¨

ander und der gesamten Bundesrepublik

Deutschland.

2.1.2.2. Heterogene Prozess- und Systemstrukturen

Das BMBF schrieb daraufhin 2004 eine neue F¨

orderung aus zur ”Entwicklung und Er-

probung von Maßnahmen der Strukturentwicklung zur Etablierung von E-Learning in

der Hochschullehre im Rahmen des F¨

orderschwerpunkts Neue Medien in der Bildung“

(s. [Sch04a]). Eine erfolgreiche und IT-gest¨

utzte Modernisierung von Lehren, Lernen

und Pr¨

ufen an Hochschulen und die systematische Erschließung des diesbez¨

uglich in den

Hochschulen vorhandenen Innovationspotenzials sind organisationsneutral, d. h. ohne

Strukturver¨

anderungen, nicht zu erreichen. Mit dem F¨

orderprogramm soll eine ”An-

schubfinanzierung“ zur beschleunigten Entwicklung und Erprobung von Organisations-

modellen geleistet werden, die – insbesondere mit den Medienentwicklungskonzepten der

2.1. E-Learning an deutschen Hochschulen

einzelnen Hochschulen – zu einer verst¨

arkten Nutzung von E-Learning und E-Teaching

f¨

uhren und somit die Qualit¨

at und Effizienz von Lehren, Lernen und Pr¨

ufen zu erh¨

ohen.

Dabei sei die hochschulweite Integration von E-Learning als strategische Aufgabe f¨

ur die

Hochschulentwicklung insgesamt anzusehen.

SYSTEME

ORGANISATIONS-

EINHEITEN

ORGANISATIONS-

EINHEITEN

Forschung- und Lehre Administration

Wissens-

produktion,

-erschließung,

-vermittlung,

-archivierung

Prüfungs -

planung,

-ankündigung,

-anmeldung

Immatri-

kulation

Leistungs-

kontrolle,

Prüfungs-

korrektur

Archivierung,

Statistik,

Evaluation Beratung Exmatri-

kulation

Grund-

auftrag

"Lehre"

Noten-

verwaltung

Prüfungs-

management

elektronisches

Vorlesungs-

verzeichnis

Kursan- u.

Abmeldungen

Studierenden-

verwaltung

Dokumenten-

server

Übungs-

programme

Animationen,

Simulationen

Informations-

systeme

Qualitäts-

sicherung

Raum- und

Zeitplanung

Bibliotheks-

kataloge WBTs CSCW/L etc.

etc.

Universitäts-

bibliothek Lehrstühle Lehrende Rechenzentrum

Zentrale

Studienberatung Hochschuldidaktik Arbeits-

gemeinschaften etc.

Lehrstühle

Lehrende Akademisches

Auslandsamt

Zentrale

Studienberatung

Prüfungs-

sekretariate

Studenten-

sekretariate

Rechenzentrum

etc.

Studierende

Abbildung 2.1.: Das Hochschulstudium, hier dargestellt als Prozess, ist mit sei-

nen beiden Kernbereichen Wissensorganisation und Modul- und

Pr¨

ufungsverwaltung sowohl organisatorisch als auch informationstech-

nisch stark fragmentiert.

Im Folgenden wird die Hochschullehre als Prozesskette gesehen, die durch die Berei-

che Kernprozesse (Lehre und Forschung), direkte Supportprozesse (z. B. Raumplanung,

Pr¨

ufungsabwicklung) und indirekte Supportprozesse (z. B. Schl¨

usselverwaltung, Haus-

halts- u. Personalprozesse) unterst¨

utzt wird (vgl. [BGKT07], S. 44ff.)20. In diesen bei-

den Bereichen werden heute eine Vielzahl multi- und telemedialer Anwendungen einge-

setzt, die zum gr¨

oßten Teil Insell¨

osungen darstellen. Der Einsatz dieser Systeme erfolgt

durch verschiedene Organisationseinheiten, die in unterschiedlichen Verantwortungsbe-

reichen auf unterschiedlichen Ebenen angesiedelt sind. Diese Situation f¨

uhrt dazu, dass

die Transparenz des Gesamtprozesses stark erschwert wird und der gesamte Prozess

durch eine hohe Anzahl Schnittstellen zwischen den Beteiligten, den Produkten und

Organisationseinheiten gekennzeichnet ist. Abbildung 2.1 beschreibt diesen Sachverhalt

grafisch.

Innerhalb von Hochschulen wird immer noch differenziert nach Verwaltung, Forschung

20Vgl. hierzu Abbildung 2.1: Die Prozessschritte laufen dabei typischerweise nicht sequentiell, sondern

in starkem Maße parallel und studienbegleitend ab.

2. Beschreibung des Problembereichs und der Einflussfaktoren

und Lehre sowie nach Fachbereichen, Querschnittszentren und Dienstleistern. Weick

f¨

uhrt in [Wei76] an, dass zwischen diesen einzelnen Organisationseinheiten zwar lockere

Verbindungen bestehen, sie sich aber auch durch einen hohen Autonomiegrad auszeich-

nen21. Dieser Umstand zieht zum einen ineffiziente Prozesse nach sich, da die in der

Administration zust¨

andigen Ansprechpartner f¨

ur – aus Sicht der Lehrenden zusammen-

geh¨

orende – Abl¨

aufe stark verteilt sind (vgl. [DEH+02], S. 3f.). F¨

ur Studierende einer

Hochschule ergeben sich dieselben Probleme im versch¨

arften Maße. Auch sie sind mit

mehreren Ansprechpartnern konfrontiert und m¨

ussen sich nach deren Kommunikations-

anforderungen richten, die ggf. nach den Traditionen des jeweiligen Faches bzw. einzelner

Lehrst¨

uhle variieren.

Zum anderen bedeutet die starke organisatorische Fragmentierung im Zusammen-

spiel mit einem hohen Autonomiegrad f¨

ur Strukturver¨

anderungen eine geringe Steuer-

barkeit und Berechenbarkeit der Einzelelemente, aber auch des Gesamtsystems. Steue-

rungsversuche bez¨

uglich einzelner Organisationseinheiten wirken sich nicht notwendiger-

weise auf die gesamte Organisation aus (vgl. [Kub04], S. 9ff.). Technische Innovationen

und Prozess¨

anderungen werden dann dadurch gehemmt, dass jedes mal auf technische,

p¨

adagogische und verwaltungsbezogene Aspekte der einzelnen Subsysteme R¨

ucksicht

genommen werden muss (vgl. ebd. S. 9ff.).

Aus informationstechnischer Sicht ergeben sich durch die an Hochschulen vorherr-

schenden heterogenen IT-Infrastrukturen große Effizienzpotenziale bzgl. der Unterst¨

ut-

zung aller administrativen Prozesse, aber auch aller im Wissenschaftsbetrieb anfallenden

Prozesse der Verarbeitung von Wissen, sei es in Lehr- und Lernprozessen, in der For-

schung und Entwicklung sowie bei der Kommunikation und Publikation: Studierenden-

und Pr¨

ufungsdaten, Lehrveranstaltungen und R¨

aume sowie deren Belegungen werden

oftmals redundant gehalten und m¨

ussen in verschiedenen Systemen mehrfach erfasst

und manuell abgeglichen werden. Auch der Austausch und die gemeinsame Bearbei-

tung von Dokumenten und Daten, der Zugriff auf Online-Publikationen etc. unterliegt

an den meisten Hochschulen noch immer den Restriktionen von fachbereichsspezifischen

Rollen, Rechten und Systemgrenzen. Zudem existieren f¨

ur verschiedene Systeme h¨

aufig

unterschiedliche Benutzer-IDs zur Authentifizierung, so dass nicht nur ein Mehraufwand

seitens der Dozierenden vorhanden ist, sondern auch die Studierenden mit einer Viel-

zahl an Logins und Passw¨

ortern, Benutzungsschnittstellen und Mehrfacherfassungen von

Daten22 f¨

ur und in verschiedenen Systemen konfrontiert sind.

In der Anwendung der Dienste bedeutet dies sowohl f¨

ur das Personal als auch f¨

die Studierenden einer Hochschule einen unn¨

otigen Mehraufwand und ungewollte Ver-

z¨

ogerungen bei allt¨

aglich wiederkehrenden Nutzungsszenarien. Um die Prozesse zu op-

timieren und somit gleichzeitig auch geeignete Rahmenbedingungen f¨

ur den nachhalti-

gen Einsatz von neuen Medien in der Hochschullehre zu schaffen, muss die bestehende

21Cohen et al. bezeichnen ein solches lose gekoppeltes System autonomer Einheiten in [CMO72] als

garbage can: Dadurch, dass viele Leute verschiedene Dinge hinein tun, ergibt sich f¨

ur jeden Be-

trachter immer wieder ein anderes Bild. Als Ergebnis einer solchen ”organisierten Anarchie“ sind

den Mitarbeitern die Ziele und Verfahren des Gesamtsystems oft unklar, bzw. m¨

ussen erst h¨

aufig in

Folge von Handlungen (re-)konstruiert werden, statt sie a priori setzen zu k¨

onnen (vgl. [CMO72],

S. 2).

22Bspw. Benutzerprofile und Kursbuchungen und -abmeldungen.

2.1. E-Learning an deutschen Hochschulen

Fragmentierung in den beiden Kernbereichen sowohl organisatorisch als auch informati-

onstechnisch beseitigt werden.

2.1.2.3. Organisatorische Maßnahmen

Mit der Einf¨

uhrung und dem nachhaltigen Betrieb neuer Technologien in der Hochschul-

lehre ist eine Menge an Aufgaben und Ressourcen verbunden. Darunter fallen beispiels-

weise Angebote zur kostendeckenden Produktion, Nutzung und Verarbeitung von Medi-

en, sowie zur Kompetenzentwicklung, p¨

adagogischem Support und Projektmanagement.

Nicht zuletzt bedarf es – motiviert durch eine Defragmentierung der Systemlandschaft –

einer entsprechend großen Umstellung respektive Erweiterung der IT-Infrastruktur und

des technischen Betriebs und Supports. Eine Skalierung solcher integrierten Dienste und

Services auf einen hochschulweiten Einsatz bedingt neue Formen der Organisation und

Zusammenarbeit: Eine enge Kooperation und Koordination aller Dienste-Erbringer und

Serviceleister ist eine Voraussetzung, die zun¨

achst einmal schrittweise entwickelt und auf-

gebaut werden muss23. Aus diesem Grund ist ein umfassendes Change-Management er-

forderlich, um die existierenden fragmentierten Akteurskonstellationen hin zu effiziente-

ren Organisationsstrukturen zu ¨

uberf¨

uhren, mit denen ein breites Spektrum an kunden-

und serviceorientierten IuK-Angeboten und -diensten f¨

ur neue Medien in der Lehre zur

Verf¨

ugung gestellt werden kann. Kubicek f¨

uhrt in [Kub04], S. 16f., die m¨

oglichen Optio-

nen auf:

âGr¨

undung einer neuen Einrichtung

âErweiterung des Aufgabenbereichs bestehender Einrichtungen

âAuslagerung bzw. Ausgliederung aus der Hochschule

âNutzung externer Dienstleister oder ¨

ubergreifende Kompetenzzentren

âInstituts¨

ubergreifende Definition von Arbeitsabl¨

aufen und Verantwortlichkeiten.

Innerhalb des akademischen Bereichs gilt es, die an einer Hochschule vorhandenen unter-

schiedlichen didaktischen und technischen Ans¨

atze in ein Gesamtkonzept zu integrieren

(vgl. [AMM06], [Bre04], S. 14, [Deg04], S. 3, [EKW05], S. 1 u. 3f., [Hop05a], [Wan07]).

Bew¨

ahrt hat sich dabei die Verschr¨

ankung von Top-Down-Elementen mit Bottom-Up-

Initiativen (vgl. [AMM06]). Weiterhin m¨

ussen Anreizstrukturen geschaffen werden, um

sowohl das Engagement von Pionieren und didaktische Innovatoren beizubehalten als

auch die ¨

Anderungsbereitschaft an der Basis zu stimulieren und andere Dozierende als

neue Akteure zu gewinnen24.

23Neben der o. g. geringen Steuerbarkeit autonomer Organisationseinheiten z¨

ahlt Fischer in [FB06],

S. 66, noch eine fehlende Internalisierung von Kundenorientierung und des Service-Gedankens

bei vielen an der Hochschule Besch¨

aftigten zu den Herausforderungen, sowie fehlende Verrech-

nungsm¨

oglichkeiten f¨

ur erbrachte Dienstleistungen und untransparente Leistungsspektren beteiligter

Einheiten. Degkwitz und Schirmbacher f¨

uhren in [DS07], S. 21, dar¨

uber hinaus noch die hohe Spezia-

lisierung von Hochschulangeh¨

origen im akademische Bereich mit einem wissenschaftlichen Anspruch

an, der eine bereichs¨

ubergreifende Prozesssicht einschr¨

ankt.

24Beispielsweise kann die Leistung einzelner ¨

offentlich anerkannt und den jeweiligen Projekten eine

Vorbildfunktion zugesprochen werden. Dar¨

uber hinaus bieten hochschulinterne F¨

orderprogramme

oder Pilotprojekte finanzielle Anreize.

2. Beschreibung des Problembereichs und der Einflussfaktoren

Top-down Maßnahmen zur Integration von dezentral betriebenen IT-Diensten in eine

universit¨

are Informationsarchitektur mit einer zentralen Technologie- und Architektur-

strategie und definierten Architekturprinzipien25 w¨

urden hier nicht nur einen Effizi-

enzgewinn bedeuten. Sie w¨

urden auch eine große Handlungssicherheit f¨

ur die Akteure

herstellen, welche im Rahmen ihrer Lehre auch Individualsoftware und fachspezifischen

L¨

osungen einsetzen, die nicht zentral betrieben werden k¨

onnen/sollen. Solche Leitungs-

entscheidungen zur strategischen Ausrichtung w¨

urden E-Learning-Aktivit¨

aten an der

”Basis“ rahmen und fokussieren (zum sog. Gegenstromverfahren s. [Hop05a], S. 167; vgl.

auch [Ker04a]) und unterst¨

utzen somit den Pioniergeist von Entwicklern und didakti-

schen Innovatoren, wenn sie ihre Errungenschaften systematisch mit anderen Akteuren

vernetzen k¨

onnen26.

2.1.2.4. Informationstechnische Maßnahmen

Aus informationstechnischer Sicht bedeutet die Zusammenf¨

uhrung der verschiedenen

IT-Anwendungen zu einem verbundenen Informationsangebot den ¨

Ubergang von einer

verteilten kooperativen IT-Versorgung hin zu einer integrierten Informationsversorgung.

Dabei bedarf es einer Integration von Anwendungen, ohne die vorhandene Vielfalt an

didaktischen Arrangements einzuschr¨

anken.

Die Grundlage dazu bildet ein ¨

ubergreifendes Identit¨

ats- und Rechtemanagement

(vgl. [HSWH07]). Dies konsolidiert die oftmals dezentral und redundant vorgehaltenen

Benutzerverwaltungen und bildet sie in einem zentralen System ab. S¨

amtliche Aufga-

ben, die mit dem Anlegen, ¨

Andern und Sperren von Benutzerkonten in Verbindung

stehen, k¨

onnen somit zusammengefasst werden. Dadurch k¨

onnen sowohl Mehrfacherfas-

sungen von Benutzerdaten vermieden, Login-Routinen von Benutzern reduziert, aber

auch die Gefahr von Dateninkonsistenzen verringert werden27. Bei diesem Integrations-

schritt kann nach zwei Strategien vorgegangen werden (vgl. [Pus04], S. 89f.):

âAufbau einer zentralen Benutzerverwaltung ¨

uber ein einheitliches Mitarbeiter- und

Organisationsdatenmanagement und Abl¨

ose aller dezentralen Datenbest¨

ande28.

Hierbei muss jedoch ein universit¨

atsweit einheitliches Kriterium zur Identifikation

der Benutzer eingef¨

uhrt werden.

25Die Technologiestrategie legt Leitlinien f¨

ur die Entwicklung der IT-Basisinfrastruktur fest und hat da-

her direkten Einfluss auf alle zu entwickelnden IT-Architekturen. Die Architekturstratgie beschreibt

den Zielzustand inkl. des Weges zu seiner Erreichung, und unter Architekturprinzipien versteht man

alle architekturbezogenen Grunds¨

atze und ¨

ubergreifende Standardisierungen, die f¨

ur alle Weiterent-

wicklungen gelten (vgl. [Der03]).

26Zur Schaffung von Anreizstrukturen f¨

ur das Engagement von Hochschullehrenden s. [ES04], [EKW05],

S. 4, [ZR05], S. 45 und [AMM06]. Dar¨

uber hinaus beschreibt Moog in [Moo05], S. 84ff., m¨

ogliche

Konzepte der IT-Versorgung.

27Puschmann f¨

uhrt in [Pus04], S. 81f., noch weitere Gr¨

unde an: Weniger Passwort¨

anderungen, Redukti-

on des Administrationsaufwandes bei der Wiederherstellung von Zug¨

angen aufgrund verlorener oder

vergessener Passw¨

orter etc.

28Als Standard f¨

ur die Speicherung hat sich der OSI-Standard X.500 etabliert. Eine Benutzerkennung

wird in einem solchen Verzeichnis als Objekt mit zugeordneten Attributen in einer Baumstruktur

organisiert (vgl. [KL03], S. 15ff.). Als ¨

Ubertragungsprotokoll von Benutzerdaten hat sich das Light-

weight Directory Access Protocol (LDAP) etabliert und als Quasi-Standard durchgesetzt ( [KL03],

S. 29ff.).

2.1. E-Learning an deutschen Hochschulen

âAufbau eines zentralen Systems zum Verwalten eines Mappings zwischen den un-

terschiedlichen Benutzernamen und Passw¨

ortern der verschiedenen Systeme. Dabei

wird an einer dezentralen Benutzerverwaltung festgehalten.

Die Einf¨

uhrung eines Verfahrens zum Single Sign-On sorgt in diesem Rahmen f¨

ur eine

system¨

ubergreifende Authentifizierung. Somit ist f¨

ur den Anwender nur eine einmalige

Interaktion zur Anmeldung erforderlich. Beim Wechsel zwischen verschiedenen Systemen

ubernimmt das Verfahren ¨

uber eine bestimmte Zeitspanne alle notwendigen Authentifi-

zierungsschritte gegen¨

uber anderen Systemen selbst¨

andig. Es sorgt also daf¨

ur, dass eine

best¨

atigte Identit¨

at automatisch an andere Systeme weitergegeben wird. Diese Systeme

vertrauen auf die best¨

atigte Identit¨

at des Single Sign-On-Systems und f¨

uhren damit keine

erneute Authentifizierung durch, sondern evaluieren in einem nachgelagertem Autorisie-

rungsprozess nur noch die Zugriffsberechtigungen. Auch hier existieren unterschiedliche

Mechanismen:

âDer Benutzer meldet sich auf einem sicheren Kommunikationskanal an einem zen-

tralen Dienst (Ticketsystem) an und erh¨

alt ein Ticket mit begrenzter Lebensdauer,

das ihm den Zugang zu allen Applikationen garantiert. In den meisten F¨

allen muss

in das zu integrierende System noch eine zus¨

atzliche Softwareschicht zur Verifika-

tion von Tickets eingebaut werden.

âEin weiteres Verfahren, das haupts¨

achlich bei der Integration von Backend-Syste-

men eingesetzt wird, ist die zertifikatsbasierte Public Key Infrastructure (PKI) f¨

die sichere und verbindliche Kommunikation und Transaktion ¨

uber offene Netze.

Zwischen den integrierten Systemen wird eine Vertrauensstellung durch Austausch

der ¨

offentlichen Zertifikate hergestellt. Die ¨

Uberpr¨

ufung der Identit¨

aten erfolgt

nach dem Prinzip der digitalen Signatur (vgl. [Ert01], S. 93ff.).

Auf dieser Basis lassen sich die Rollen und Rechte aller Personen auf dem Campus

festlegen, d. h. wer in welchen Bereichen welche Rechte besitzt. Die Rechte sind an die

Anwendungen und Werkzeuge weiterzugeben, die in diesem Rahmen eingebunden sind.

Somit kann eine solche Diensteinfrastruktur als ”organisatorischer Kit“ zur Einbettung

mediengest¨

utzter Lehr- und Lernprozesse in einen institutionellen Kontext dienen (vgl.

[Ker04b], [KS05a], S. 25).

Ausschlaggebend f¨

ur die Nutzerakzeptanz und nachhaltige Nutzung von Werkzeugen

f¨

ur die mediengest¨

utzte Lehre ist dabei ihre Anbindung an Systeme der Hochschulver-

waltung zur Lehr- und Veranstaltungsplanung sowie der Pr¨

ufungsverwaltung. Nur mit

einer geeignet integrierten L¨

osung, die ein manuelles Abgleichen der Kurs-, Belegungs-

und Strukturdaten vermeidet und dadurch zur Verbesserung der Wirtschaftlichkeit der

eigenen Verwaltung als auch des Service f¨

ur Studierende beitr¨

agt, kann die Organisa-

tion der Lehre erleichtert und so Kapazit¨

aten des Lehrpersonals f¨

ur die Lehrinhalte

und deren didaktische Aufbereitung freigesetzt werden (vgl. [DEH+02], S. 1ff., [Kub04],

S. 12f., [RS05], [MJ05], S. 21). Dabei sind die Daten der Veranstaltungsverwaltung zu

ubernehmen bzw. die Erstellung des kommentierten Vorlesungsverzeichnisses zu un-

terst¨

utzen, sowie die Anbindung an Pr¨

ufungsverwaltungs- und Abrechnungssysteme,

um damit die Erstellung von Statistiken zu erleichtern (vgl. [Kub04], S. 13). Solch eine

2. Beschreibung des Problembereichs und der Einflussfaktoren

Kopplung von Verwaltungssystemen und Lernsystemen kann auf verschiedenen Kom-

munikationsparadigmen beruhen, welche den Komplexit¨

atsgrad der Schnittstellenimple-

mentierung stark beeinflussen29.

Ebenso wie die Kopplung von Lernsystemen mit Veranstaltungssystemen muss auch

die Kopplung von Lerntechnologien untereinander erfolgen, um Medienbr¨

uche in Lern-

prozessen selbst aufzul¨

osen. Kerres unterstreicht in [KNW03], S. 92f., dass Lehren und

Lernen komplexe Aktivit¨

aten sind, f¨

ur die in einem Lernsystem unterschiedliche Tech-

nologien ben¨

otigt werden, um diese Aktivit¨

aten angemessen unterst¨

utzen zu k¨

onnen.

Softwarel¨

osungen im Bereich des computerunterst¨

utzenden Lernens implementieren zu-

meist bestimmte lerntheoretische bzw. didaktische Paradigmen und sind dadurch auf

bestimmte Szenarien des Lernens und Arbeitens hin ausgerichtet. Die Lern- und Ar-

beitsszenarien an Hochschulen sind jedoch vielf¨

altig, und analog dazu sind es auch die

Anforderungen an ihre Softwareunterst¨

utzung: ”Virtual classrooms should be more fle-

xible than their physical counterparts rather than less so. Do you teach art history?

Then you need an image annotation tool. But probably a different one than the image

annotation tool needed to teach histology. Foreign language teachers may want voice

discussion boards to check student accents. Writing teachers should have peer editing

tools. History teachers should habe interactive maps. And so on“ [FM06].

Die Idee, dass eine virtuelle Lernumgebung nicht als eine geschlossenes System, son-

dern als eine Menge gekoppelter Technologien konzipiert werden muss, die sich (nur)

f¨

ur ihre Benutzer als ”eine“ Plattform darstellt, ist inzwischen in der Scientific Commu-

nity weit verbreitet (vgl. bspw. [Ker04b], [Sch04b], [SW04], [RHS05], [FM06], [Lam07],

[Kei07]). Dieser Ansatz beeinflusst daher sehr stark die aktuellen Entwicklungen neuer

Architekturmodelle f¨

ur integrierte virtuelle Lernumgebungen, auf die in Abschnitt 2.2

n¨

aher eingegangen wird.

Eine weitere wichtige Maßnahme ist die Integration von Bibliotheksdiensten f¨

ur eine

medienbruchfreie und durchg¨

angige Verwaltung digitaler Informationsstrukturen. Die

Anbindung von Lerntechnologien an eine digitale Bibliothek bedeutet in diesem Fall ei-

ne Menge an Systemkonvergenzen: Dokumente k¨

onnen ¨

uber die Lernsysteme innerhalb

der digitalen Bibliothek gefunden und in Kurskontexte und Lernszenarien eingebettet

werden, fertige Kursbestandteile k¨

onnen dann ohne erzwungene Medienbr¨

uche in der

digitalen Bibliothek archiviert und eigens erstellte Dokumente dort publiziert werden

(vgl. [BHH+06]).

Nachdem die vorhandenen Werkzeuge auf Basis eines ¨

ubergreifenden Identit¨

ats- und

Rechtemanagements in eine gemeinsame Infrastruktur integriert wurden, k¨

onnen ein-

zelne Funktionen mit in eine gemeinsame Darstellungsschicht aufgenommen werden,

die dadurch als zentraler Einstiegs- und Informationspunkt dienen kann. Zwar haben

die meisten deutschen Hochschulen bereits zentrale Webseiten, auf der Dienste sowie

wichtige Informationen f¨

ur bestimmte Zielgruppen wie Studierende, Lehrende, Verwal-

tungsmitarbeiter und externe Besucher geb¨

undelt angeboten werden. Auf Grundlage der

beschriebenen informationstechnischen Maßnahmen lassen sich dar¨

uber hinaus jedoch

29Die einzelnen Integrationsebenen und dieser Komplexit¨

atszusammenhang wird in dieser Arbeit auf

S. 118f. beschrieben.

2.1. E-Learning an deutschen Hochschulen

personalisierte Hochschulportale realisieren, die Benutzern eine pers¨

onliche, individuali-

sierte Sicht auf die Dienste und Informationen bieten k¨

onnen, f¨

ur die sie als Person und

durch die ihnen zugeordneten Rollen autorisiert sind (vgl. [A+07]).

2.1.3. Zusammenfassung

Der effiziente und effektive Umgang mit den quantitativ stark gewachsenen Informati-

onsmengen fordert von den Berufst¨

atigen in der heutigen Wissensgesellschaft Kompeten-

zen und individuelle Bildungsstrategien, die das staatliche Bildungssystem bislang nur

ungen¨

ugend unterst¨

utzen konnte. Die darauf bezogenen aktuellen Bildungsreformen im-

plizieren konzeptuelle Ver¨

anderungen bei der Hochschulbildung, die grunds¨

atzlich sind

f¨

ur die forschungsorientierten und disziplin¨

aren Paradigmen, aus denen das an Univer-

sit¨

aten traditionell vermittelte Wissen generiert und in denen es organisiert ist. Neben

einer neuen Bedeutungszuweisung der akademischen Forschung zur Generierung neuen

Wissens und einem als gleichrangig neben Forschung und Lehre gestellten universit¨

aren

Weiterbildungsauftrag werden Hochschulen insbesondere dazu angehalten, die f¨

ur die

Wissensarbeit notwendigen Kompetenzen durch neue Lehr- und Lernformen sowie pra-

xisrelevantere Fragestellungen und L¨

osungsans¨

atzen zu vermitteln.

Hierzu wurden u. a. Neue Medien in die Hochschullehre eingef¨

uhrt, denen durch er-

weiterte Darstellungs-, Kommunikations- und Aktualisierungsm¨

oglichkeiten neue Qua-

lit¨

aten des Lehrens und Lernens zugesprochen wurden. Gezielte F¨

ordermaßnahmen des

Bundes sollten diese in die Breite tragen. Dabei f¨

uhrte die Schwerpunktsetzung auf hoch-

schul¨

ubergreifende Verbundprojekte in Kombination mit fehlenden hochschulinternen

E-Learning-Strategien und fehlenden Lerntechnologiestandards jedoch an vielen Univer-

sit¨

aten zu heterogenen Infrastrukturen, die aus vielen Insell¨

osungen und unkonsolidier-

ten, fragmentierten Prozessabl¨

aufen bestehen.

Ein fl¨

achendeckender effizienter und alltagstauglicher Einsatz von E-Learning an Pr¨

senzhochschulen erfordert daher eine Ressourcenallokation sowohl aus organisatorischer

als auch aus informationstechnischer Sicht. Die folgenden drei Ziele finden sich aus die-

sem Grund in den meisten aktuellen Medienentwicklungsstrategien deutscher Hochschu-

len wieder:

âRealisierung effizienter Organisationsstrukturen, mit denen ein breites Spektrum

an kunden- und serviceorientierten IuK-Angebot und -diensten f¨

ur neue Medien

in der Lehre zur Verf¨

ugung steht

âOptimierung des personellen und finanziellen Ressourceneinsatzes durch B¨

undel-

ung von Ausstattungen, Investitionen und Kompetenzen sowie Schaffung von Frei-

r¨

aumen f¨

ur Innovationen und nachhaltige Weiterentwicklung durch h¨

ohere Kos-

teneffizienz und Synergie aller laufenden IuK-Prozesse

âEntwicklung einer attraktiven Infrastruktur f¨

ur multimediales Lehren und Lernen,

die den Anforderungen der Wissensgesellschaft gen¨

ugt sowie national und interna-

tional wettbewerbsf¨

ahig ist.

2. Beschreibung des Problembereichs und der Einflussfaktoren

Eine f¨

ur multimediales Lehren und Lernen attraktive Infrastruktur muss dabei Me-

dienbr¨

uche auf zwei Ebenen aufheben, ohne die vorhandene Vielfalt an didaktischen

Arrangements einzuschr¨

anken (vgl. [RH07]):

1. Die Administrations- und Dispositionssysteme in der Hochschulverwaltung m¨

ussen

Schnittstellen anbieten, um Einsparungen zus¨

atzlichen Aufwands f¨

ur den Betrieb

der in der Lehre eingesetzten Informationssysteme und Werkzeuge zu erm¨

oglichen

2. unterschiedliche Elemente und spezialisierte Einzelwerkzeuge m¨

ussen auf einfa-

chem Weg zu einer hybriden Lernumgebung integriert werden k¨

onnen, welche ver-

schiedenste, individuelle p¨

adagogische und organisatorische Anforderungen von

Lehrveranstaltungsformaten und selbstorganisiertem Lernen angemessen unter-

st¨

utzen k¨

onnen.

Im Gegensatz zu Hochschulverwaltungssystemen, die hierzu nur Schnittstellen zu ei-

ner kleinen Untermenge ihrer Funktionen nach Außen ¨

offnen brauchen, impliziert dieser

Trend f¨

ur Lerntechnologien jedoch die Umstellung ihrer Softwarearchitektur vom mo-

nolithischen System hin zur offenen Architektur und somit einen Fokuswechsel vom

Funktionsumfang zur Integrationsf¨

ahigkeit. Des Weiteren muss eine gezielte konzep-

tionelle und technische Konvergenz von Lernwerkzeugen dahingehend erreicht werden,

dass Benutzern die selbstbestimmte Interaktion mit Inhalten ¨

uber Systemgrenzen hin-

weg erm¨

oglicht wird.

In Abb. 2.2 sind noch einmal die in diesem Abschnitt erarbeiteten Handlungsfelder auf-

gez¨

ahlt, in denen an Universit¨

aten aktiv an der Schaffung einer attraktiven Infrastruktur

f¨

ur E-Learning gearbeitet werden muss.

Technologie

Betriebs- u.

Support-Strukturen Skalierung integrierter Dienste auf

einen hochschulweiten Einsatz

Technologie

Prozess Einbettung von Lernumgebungen

in institutionale Kontexte

Applikationen

Lerntechnologie-bezogene Dienste

Basisdienste

Infrastruktur

Bereitstellung integrierter

Lernumgebungen

...

Interne Weiterbildungsmaßnahmen

Hochschulportal

Sonstige Single Sign-On

konsolidierte Benutzerverwaltung

Aufbau eines zentralen Identitäts-

und Rechtemanagements

Top-Down-Definition von Arbeitsab-

läufen und Verantwortlichkeiten

Out-Sourcing

Erweiterung von bestehender

Zuständigkeiten

Neue organisatorische Einrichtung

Schaﬀung eﬃzienterer

Organisationsstrukturen

Bottom-Up-Elemente

Top-Down-Elemente

Erarbeitung einer hochschulweiten

Medien-/E-Learning-Strategie

Handlungsfelder

Abbildung 2.2.: Reorganisation und IT-Unterst¨

utzung zur Schaffung einer attraktiven

universit¨

aren Infrastruktur f¨

ur E-Learning

2.2. Das elektronisch unterst¨

utzte Lernen

2.2. Das elektronisch unterst¨

utzte Lernen

2.2.1. Begriffliche Einordnung

Bis etwa 1995 f¨

allt E-Learning praktisch mit Computer-based-Training (CBT)30 zusam-

men. Kennzeichnend f¨

ur ein CBT ist, dass das Lernsystem und das Kursmaterial lokal

auf dem Rechner des Anwenders installiert ist (vgl. [BBSS01], S. 289).

Multimediale Elemente, die durch die zunehmende Leistungsf¨

ahigkeit der Computer in

den 1990er Jahren erm¨

oglicht wurden, markieren eine Ausbaustufe (Multimedia-CBTs).

Aber selbst in diesem Szenario erg¨

anzt die neue Lernform die konventionelle, papierba-

sierte Fernlehre (Distance Learning, s. u.) lediglich auf einer medialen Ebene und nicht in

einer grunds¨

atzlichen Art und Weise. Weiterhin gilt die These, dass mit dem Ansprechen

vieler Sinnesorgane (H¨

oren und Sehen) durch Multimedia generelle Erfolgsverbesserun-

gen beim Lernprozess erzielt werden, mittlerweile als widerlegt (vgl. [Reg04]).

Trotz anf¨

anglicher Euphorie um das CBT leidet das Konzept in der Praxis oftmals an

mangelnder Akzeptanz und Motivation bei den Anwendern (s. [MG05], S. 161). In Ver-

bindung mit der administrativen Ineffizienz der Datentr¨

agergebundenheit, der dadurch

erschwerten Distribution lerninhaltlicher Aktualisierungen sowie der zwangsl¨

aufigen so-

zialen Isolation der Lernenden31 ergibt sich, dass CBTs in der reinen Form von ei-

ner ehemaligen Dominanz auf dem E-Learning Markt im Weiterbildungssektor zu einer

Randerscheinung geworden sind (vgl. [SM02], S. 26 u. [SKRS01], S. 21).

Das Web-based-Training (WBT), ein unmittelbar auf der Internettechnologie aufset-

zendes Konzept, adressiert wichtige Schwachstellen des CBTs. Es handelt sich bei einem

WBT um ein ¨

uber Server bereitgestelltes und administriertes Lernsystem, mit dem der

Anwender ¨

uber eine zumeist browserbasierte Benutzungsoberfl¨

ache in Interaktion tritt.

Inhaltlich profitieren WBTs von einer gr¨

oßtm¨

oglichen Aktualit¨

at und von einem Aus-

bruch aus der Isolation des Lerners in eine Welt der ”explorativen und kommunikativen“

Erfahrung (vgl. [MG05], S. 189):

âDie kommunikative Ebene wird durch die Einbindung von internetbasierter Mensch-

zu-Mensch-Interaktion erschlossen, klassischerweise ¨

uber Foren, Email und Chat32.

âDie explorative Erfahrung wird z. B. durch hypermediale Lernsysteme als Spezial-

form des WBT gew¨

ahrleistet. Anstelle der festen Definitionen eines vorgegebenen

Lernweges durch die Inhalte nutzen sie das Hypertextkonzept, um dem Anwender

30Der Mitte der achtziger Jahre eingef¨

uhrte Begriff CBT wurde im Allgemeinen als Umschreibung

f¨

ur die Wissensvermittlung per Computer verstanden (vgl. [Bau06a], S. 11). Mit dem WWW hat

die Wissensvermittlung eine neue Dimension erreicht. Somit dient der Ausdruck CBT mittlerweile

der Abgrenzung gegen¨

uber webbasierter Wissensvermittlung. Als Synonyme werden die Begriffe

Computer Aided/Assisted Learning (CAL) oder Computerunterst¨

utztes Lernen (CUL) verwendet.

31Neben dem fehlenden Kontakt zu weiteren Lernenden fehlt auch oftmals eine individuelle Betreuung

durch Lehrende.

32Kritisch ist hierzu anzumerken, dass der Terminus WBT heute noch ¨

uberwiegend mit der Mensch-

System-Kommunikation assoziiert wird. Dies liegt daran, dass der Ebene der Kommunikation in den

Anfangszeiten der WBTs einen geringeren Stellenwert eingenommen hat. Dies ¨

andert sich jedoch

sp¨

atestens seit der Fokussierung auf benutzergenerierte Inhalte und Kooperationsunterst¨

utzung.

2. Beschreibung des Problembereichs und der Einflussfaktoren

ein eigenst¨

andiges und flexibles ”Erforschen“ zu erm¨

oglichen. Die damit einherge-

hende mangelnde Sequenzialit¨

at bedingt andererseits auch h¨

ohere Anspr¨

uche an

den Lernenden und birgt die Gefahr der kognitiven ¨

Uberlastung (cognitive over-

load) und Desorientierung (Lost in Hyperspace, vgl. [Ter02]).

E-Learning, Synonym f¨

ur multimediales Lernen und Telelernen, wird in der Regel als

Oberbegriff f¨

ur alle Varianten von Lernangeboten verwendet, in denen neue Medien eine

Rolle spielen. Die große Abdeckung des Begriffs wird durch die folgende Definition ver-

anschaulicht: ”E-Learning ist eine durch Informations- und Kommunikationstechnologie

unterst¨

utzte Form des Lernens“ [BBSS01], S. 35. Es umfasst somit sowohl das Online-

Lernen ¨

uber das Intra- oder Internet in Form von Web-Based-Trainings als auch die

Computer-Based-Trainings. Zudem k¨

onnen auch noch differenziertere Technologien und

Paradigmen eingesetzt werden, die in verschiedenen Formen des E-Learnings m¨

unden

(s. n¨

achster Abschnitt).

Zum Distance Learning z¨

ahlen alle Bildungsmaßnahmen, die ¨

uber eine r¨

aumliche Dis-

tanz abgehalten werden. Distance Learning ist gleichzusetzen mit dem deutschen Begriff

Fernunterricht und umfasst sowohl das E-Learning, das Online-Lernen (WBT) und das

CBT als auch traditionelle papierbasierte Formen und Bildungsfernsehen.

Distance Learning

E-Learning

...

CBT

WBT

Abbildung 2.3.: Untermengen des Distance Learnings

2.2.2. Formen des E-Learnings

In Theorie und Praxis sind unz¨

ahlig viele Auspr¨

agungen von E-Learning zu finden.

Bislang hat sich in der Literatur jedoch noch kein einheitlicher Ordnungsrahmen zur

Kategorisierung dieser Varianten durchgesetzt. Autoren ziehen zur Unterscheidung die

verschiedensten Strukturmerkmale heran, wie beispielsweise die Notwendigkeit einer Ver-

bindung zum Internet (vgl. [Kol96], S. 50), die Merkmale Raum und Zeit (vgl. [Alb03],

S. 36f.), Funktionen der Medien und Sicht des Lernenden (vgl. [RR03], S. 33ff.), oder

das Maß an Selbstregulation33. Ley und Schachner unterscheiden in [LS04] anhand des

33Die Selbstregulation bezeichnet das Ausmaß an Freiheitsgraden des Lerners auf mehreren Merkmals-

dimensionen, wie z. B. Ausmaß der Vertiefung, Ort und Dauer des Lernens, Art der Medien und

Sequenz der Inhalte, Auswahl von Beispielen und Inanspruchnahme von Hilfen sowie Lerntechniken

und -strategien (vgl. [Nie01], S. 117ff.).

2.2. Das elektronisch unterst¨

utzte Lernen

Paradigma Fokus Gestaltungsaspekte Beispiele

E-Training Content Instruktionales Design CBT, WBT

E-Mentoring,

E-Tutoring

Feedback Interaktion Lernender-

Lehrender

Hybrid Learning

E-Collaboration Interaktion Gestalten von Kommu-

nikationsr¨

aumen

Communities of Practice

Ad-hoc-Lernen Prozess Prozessanalyse, Lern-

bedarf

Just in time-Lernmodule

Wissensmanage-

ment

Dokumente Learning Objects, Su-

che, Metadaten

Learning by Google

Personal Publishing Experten Publikationsplattform Wiki, Weblog

Tabelle 2.1.: Unterscheidung von E-Learning-Paradigmen nach dem Merkmal der Selbst-

regulation (aus: [LS04])

mehrdimensionalen Kriteriums der Selbstregulation sechs Paradigmen, die im Folgen-

den als Beispiel eines m¨

oglichst vollst¨

andigen Ordnungsrahmens skizziert werden (s. auch

Tabelle 2.1).

2.2.2.1. E-Training

Im Mittelpunkt des E-Trainings stehen Inhalte (Content), die weitestgehend Grundla-

genwissen darstellen und mittels Instruktion vermittelt werden sollen. Die Durchf¨

uhrung

kann isoliert oder als Bestandteil eines Blended Learning-Mixes erfolgen. Der Lernende

interagiert dabei ausschließlich mit dem Medium, wobei der Grad der Interaktionsfreiheit

je nach System variieren kann.

E-Trainings werden klassischerweise durch CBTs und WBTs implementiert. Bestand-

teile der Anwendungen sind Interaktionen in Form von Fragen und Feedback, Lernmo-

dule zum Vermitteln von Inhalten und Testmodule zur Evaluation des Lernfortschritts

(vgl. [SM02], S. 26). Als konkrete Auspr¨

agungen sind ”Drill&Practice Software“ und

”Tutorielle Systeme“ zu nennen, bei denen der Lernende eigenverantwortlich und zu

individuell gew¨

ahlten Zeiten lernen kann (asynchrones Lernen).

2.2.2.2. E-Teaching

Dieses Paradigma schließt die betreuende Begleitung von Lernenden durch eine Lehr-

person als soziale Komponente mit in den Lernprozess ein. Auf diese Weise kann der

Betreuer als reiner Ratgeber oder motivierend agieren, indem er nur auf Anfragen von

Lernenden reagiert oder die Lernenden zu einem Dialog auffordert (vgl. [SM02], S. 44f.).

Diese Betreuung kann synchron (z. B. Chat) oder asynchron (z. B. E-Mail) erfolgen.

Entsprechende Technologien sind in die Lernumgebung mit einzubinden.

2. Beschreibung des Problembereichs und der Einflussfaktoren

2.2.2.3. E-Collaboration

Soziale Lerntheorien gehen davon aus, dass Lernen ein selbstorganisierter und selbst-

steuernder Prozess von Personengruppen ist, in dem zwar ein f¨

ur das selbststeuernde

Lernen f¨

orderndes Umfeld geschaffen werden kann, Lerngruppen aber nicht von Au-

ßen organisiert werden k¨

onnen oder sollen (vgl. [NRP00], S. 5). Bei dieser Form des

E-Learnings arbeiten die Anwender daher in kleinen Gruppen zusammen an gemeinsa-

men Zielen und Lernen dabei von- und miteinander durch gemeinsames Erschließen von

Wissen. Die externe Anleitung nimmt hierbei ab, wohin dagegen soziale Aspekte st¨

arker

gef¨

ordert werden sollen wie kulturelle Voraussetzungen, soziale Kontakte und die Aner-

kennung von Selbstreferenz und -reflexion. Konzepte wir Knowledge Communities oder

Communities of Practice (CoPs, vgl. hierzu [AP00], [Wen98b] und [WS01]) verfolgen

diesen kooperativen Ansatz. Technisch kommen dabei CSCW/L-Werkzeuge (Computer

Supported Cooperative Work/Learning) zum Einsatz, die vor allem das Bearbeiten von

Dokumenten in Gruppen, Versionierung und Kommunikation unterst¨

utzen.

2.2.2.4. Ad-hoc-Lernen

Zentrales Merkmal dieses Paradigmas ist die Bedarfsorientierung: Kenntnisse und F¨

ahig-

keiten werden erst dann neu angeeignet bzw. vertieft, wenn diese ben¨

otigt werden (vgl.

hierzu Learning on Demand bzw. Just-in-Time-Training in [SM02], S. 76f.). Der Lern-

prozess ist dabei so zu unterst¨

utzen, dass er sich an individuell gew¨

ahlten Lernzielen

flexibel ausrichten kann34. Das dabei zu ber¨

ucksichtigende Spektrum erstreckt sich dabei

von der kontinuierlichen Suche nach Informationen (bspw. Nutzung von Suchmaschinen)

hin zu klassischen Schulungen (vgl. [LL04]).

2.2.2.5. Wissensmanagement

Ausgangspunkt eines pers¨

onlichen Wissensmanagements ist die Reflexion individueller

Denkweisen und Handlungen in dem pers¨

onlichen Arbeits- oder Lernbereich, die zur Ver-

besserung der eigenen Effizienz und der partizipierenden Mitarbeitenden oder -lernenden

f¨

uhren k¨

onnen. Methodische Ans¨

atze des Wissensmanagements implementieren dabei

mit Planungs-, Durchf¨

uhrungs- und Kontrollelementen oftmals einen Management-Re-

gelkreis. Die Kernprozesse des Wissensmanagements sind nach [PRR03], S. 28ff., die

Identifizierung, der Erwerb, die Entwicklung, (Ver-) Teilung, Nutzung und Bewahrung

von Wissen35.

Beim pers¨

onlichen Wissensmanagement erfolgt das Lernen weitestgehend autonom

und selbstgesteuert. Neben der Informationssuche im Intra-/Internet ( ”Learning by

Google“) k¨

onnen in diesem Zusammenhang vor allem Instrumente eingesetzt werden,

welche Kreativit¨

atstechniken (Mind-Maps/Topic-Maps) und/oder semantisches Arran-

gieren von Informationen unterst¨

utzen.

34Im betrieblichen Umfeld bedeutet dies beispielsweise, dass die Vorg¨

ange zur Weiterbildung von Mit-

arbeitern an Stellen zu koppeln sind, also idealerweise arbeitsintegriert stattfinden.

35Coenen hat in [Coe02], S. 19ff., die Bausteine des Wissensmanagements an die Besonderheiten des

Wissensmanagements von Lernenden an einer Universit¨

at angepasst und erweitert; insbesondere

hat er dabei einzelne Bausteine detaillierter betrachtet und mit den beiden zus¨

atzlichen Bausteinen

Wissensdemonstration und -diagnose universit¨

are Prozesse wie Leistungspr¨

ufung und Zertifizierung

abgebildet.

2.2. Das elektronisch unterst¨

utzte Lernen

2.2.2.6. Personal Publishing

Neue Werkzeuge wie Weblogs und Wikis entfernen technische Barrieren, um online zu

Schreiben und zu Ver¨

offentlichen. Ein jeder kann heutzutage ¨

uber Web-Dienste und

Personal Publishing-Systeme wie Weblogs eigene Inhalte generieren und (ver-)teilen,

mit Metadaten auszeichnen und dar¨

uber auch soziale Kontakte und Netzwerke aufbau-

en (vgl. [Mos06], S. 99). Im Mittelpunkt des Personal Publishing stehen Wissenstr¨

ager,

die ihr eigenes Wissen, ihre eigenen Erkenntnisse und Ansichten als so genannten Micro-

content36 verfassen und publizieren. Durch Formen der Kommentierung k¨

onnen diese

Inhalte in einer Gemeinschaft aktiv diskutiert und semantisch strukturiert werden. So-

mit bleibt das Wissen nicht tr¨

age, sondern kann sich im Dialog entwickeln. Diese und

weitere lerntheoretische Aspekte werden in dieser Arbeit ab S. 79ff. behandelt.

2.2.2.7. Blended Learning

Eine Vermischung der hier vorgestellten Paradigmen, Formen und Konzepte des compu-

terunterst¨

utzten Lernens untereinander, aber auch mit Methoden des Pr¨

asenzlernens ist

Ausgangspunkt f¨

ur das Blended Learning. Als eine Form des hybriden Lernens37 steht

es f¨

ur einen Methodenmix, in dem s¨

amtliche didaktische Instrumente – Fernunterricht

oder Face-to-Face, elektronisch oder nicht-elektronisch, individuell oder kooperativ etc.

– zu einem integrierten p¨

adagogischen Gesamtkonzept zusammengef¨

ugt werden k¨

onnen

(vgl. [BBSS01], S. 217, [Rep02]). Somit soll der Lernprozess an sich beg¨

unstigt sowie ver-

schiedenen Lerntypen und Lebenssituationen individuell gerecht werden. Dabei k¨

onnen

auch solche Lernformen Ber¨

ucksichtigung finden, die zun¨

achst antiquiert erscheinen, et-

wa statische Ressourcen wie reine Texte oder CBTs (vgl. [BBSS01], S. 224).

2.2.3. Technologien virtueller Lernumgebungen

Informationsarchitekturen virtueller Lernumgebungen, wie sie in Hochschulen eingesetzt

werden, bestehen aus verschiedensten Technologien. Diese k¨

onnen in drei Klassen Basis-

technologien, Lerntechnologien und Lernsystemen eingeordnet werden, die aufeinander

aufbauen (vgl. [BBSS01], S. 208ff.). Dabei ergibt sich die Funktionalit¨

at der h¨

oheren

Klasse jeweils durch die Integration und Nutzung von Technologien der darunter liegen-

den Klassen38.

Auf der untersten Ebene befinden sich Informations- und Kommunikationssysteme, die

bzgl. ihrer Anwendung und Integration grunds¨

atzlich indifferent sind und nicht auf den

Bereich elektronisch vermittelten Lernens ausgerichtet. Diese so genannten Basistech-

nologien bilden die Grundlage ¨

ubergeordneter Technologien und Anwendungssystemen

(vgl. [BBSS01], S. 208, [Nie04], S. 254ff.). Zu ihnen z¨

ahlen haupts¨

achlich Technologien

36Mosel beschreibt den Begriff in [Mos06] wie folgt: ”Important (formal) aspects of microcontent are

that it is referable, can be machine-readable through metadata [. . . ] and is generally focused on one

or few single ideas or topics“.

37Ebenfalls eine Bezeichnung f¨

ur die Kombination unterschiedlicher Lernformen, wobei sich ein opti-

maler Mix auf unterschiedliche Perspektiven beziehen kann, z. B. Technologie-Mix, Methoden-Mix

etc. (vgl. [SM02], S. 23f.).

38Das Konzept dieser Mehrschicht-Architekturen wird ausf¨

uhrlicher in Kapitel 4 vorgestellt.

2. Beschreibung des Problembereichs und der Einflussfaktoren

f¨

ur die Funktionsbereiche Kommunikation (bspw. E-Mail/Chat/VoIP), Informations-

beschaffung (z. B. Suchmaschinen), Administration, Produktion und Evaluation. Aber

auch hardwareseitige bzw. hardwarenahe Technologien wie bspw. Internetzugang und

Systemsoftware sind auf dieser Ebene einzuordnen.

Die Funktionen von Lerntechnologien sind speziell f¨

ur den Lernbereich entwickelt und

orientieren sich an bestimmten Lernprozessen. Hierbei werden Basistechnologien auf die

Dom¨

ane des elektronisch unterst¨

utzten Lernens angewendet und stellen beispielsweise

Hilfs- und Kommunikationswerkzeuge, Tools zur Kooperation oder Kursadministration,

spezielle Suchmaschinen und Programme zur Medienproduktion (z. B. Grafik-, Audio-

und Video-Bearbeitungsprogramme) dar. Die Menge an Anwendungsgebieten scheint

unendlich groß, so dass die in der Tabelle 2.2 aufgef¨

uhrten Typen multimedialer Lern-

technologien nur einen kleinen, aber wichtigen Ausschnitt davon abbilden.

W¨

ahrend die Integration von Basistechnologien zu einer Lerntechnologie durch die

Festlegung auf einen spezifischen Anwendungsbereich bestimmt wird, ist die Integrati-

on von Lerntechnologien zu einem Lernsystem39 vor allem durch die Konkretisierung

des Anwendungskontextes mit Hilfe von Daten und Inhalten gekennzeichnet, die so-

wohl Inhalte beinhalten, als auch didaktische Konzepte und Methoden implementieren

(vgl. [Nie04], S. 253). Jede in der Praxis eingesetzte E-Learning-Anwendung respektive

Kombination von Anwendungen stellt somit in sich und mit seiner Umwelt ein Lernsys-

tem dar.

2.2.4. Standards und aktuelle Integrationsans¨

atze

Ein virtuelles Lernsystem respektive eine virtuelle Lernumgebung besteht aus einer oder

mehr Lerntechnologien, die im Sinne einer bestimmten Didaktik kombiniert und genutzt

werden k¨

onnen. Unter dem Gesichtspunkt der Interoperabilit¨

at haben sich im E-Learning

bestimmte Spezifikationen, Normen und Standards40 durchgesetzt, die beschreiben, wie

verschiedene Lerntechnologien sowohl innerhalb virtueller Lernumgebungen als auch um-

gebungs¨

ubergreifend miteinander operieren k¨

onnen. Erst unter diesen Voraussetzungen

rentiert sich bspw. die mit hohen Kosten verbundene Erstellung von WBTs41.

Im Folgenden werden Spezifikationen, Normen und Standards klassifiziert, die auf die

Entwicklung von Lerntechnologien und -systemen angewendet werden k¨

onnen. Mittler-

weile weiten sich die Standardisierungsbem¨

uhungen auf den Bereich der didaktischen

und methodischen Gestaltung von virtuellen Lernszenarien aus (vgl. [AKTZ04], S. 217).

39In dieser Arbeit wird der Begriff Lernumgebung als Synonym zum Lernsystem verwendet.

40Spezifikationen spiegeln dabei erste Harmonisierungen in kleineren Anwendungsgemeinschaften und

k¨

onnen als Vorstufen der Normen gesehen werden, welche wiederum Spezifikationen innerhalb

gr¨

oßerer Gemeinschaften vereinbaren. Eine Norm ist in der deutschen Sprache eher ein Regelwerk,

w¨

ahrend ein Standard eher eine Qualit¨

atsaussage darstellt, also bspw. wie eine Norm umzusetzen

ist (vgl. [Lin04], S. 341ff.). Das British Standards Institute liefert auf ihrer Webseite eine klarere De-

finition eines Standards: ”document, established by consensus and approved by a recognized body,

that provides, for common and repeated use, rules, guidelines or characteristics for activities or their

results, aimed at the achievment of the optimum degree of order in a given context.“

41Die Herstellungskosten f¨

ur eine Stunde interaktiven, didaktisch aufbereiteten Content reichen von

2.000 bis zu 20.000 Euro und mehr, je nach Grad der Multimedialit¨

at und des Themengebietes

(vgl. [H¨

af02]).

2.2. Das elektronisch unterst¨

utzte Lernen

Anwendungstyp Merkmale Haupteinsatzgebiete

Ubungsprogramm sequentielle Abfrage von Bekanntem,

bzw. Feststellung von Defiziten mit

Feedback

Ubungs- u. Anwendungs-

zwecke (deklarative Lern-

ziele)

Animation & Simula-

tion

Abbildung komplexer dynamischer

Zusammenh¨

ange in einem (inter-

aktiven) Modell, u. U. mit der

M¨

oglichkeit, die Auswirkung von

Parameter- u. Variablenmanipulation

zu beobachten

exploratives Lernen, lear-

ning by doing (prozedura-

le Lernziele), 3D-Modelle

computerunterst¨

utzte

Planspiele

meist in Form von Wirtschafts-,

Sozial- oder Natur-Simulationen, in

denen der Teilnehmer selbst Teil der

Simulation ist; bis hin zu Mikrowel-

ten, in denen der Lernen einen Rea-

lit¨

atsbereich selbst modelliert

Unterst¨

utzung eines Ver-

st¨

andnisses f¨

ur Zusam-

menh¨

ange (vernetztes

Denken); Aufbau und

Handelssimulation

Hypermediale Infosys-

teme

elektronisches Handbuch (Indexsys-

tem, Lexikon) mit Suchfunktion und

oft hypermedialen Elementen

geordnete Informations-

pr¨

asentation (deklarative

Lernziele)

Tutorials, guided tours angeleitetes Lernen durch im Pro-

gramm festgelegte Lernwege, die Rei-

henfolge der Lerninhalte kann jedoch

innerhalb eines gewissen Rahmens

selbst bestimmt werden

Einf¨

uhrung in neue Wis-

sensgebiete und in die Be-

dienung von Programmen

intelligente tutorielle

Systeme

interaktive Unterst¨

utzung des

Lernenden beim Aneignen von

Neuem durch a) Feedback, dass

uber ”falsch/richtig“ hinausgeht, b)

systemgesteuerte Auswahl des als

n¨

achstes zu pr¨

asentierenden Inhalts

in Abh¨

angigkeit von der L¨

osung der

vorausgehenden Aufgabe durch den

Lerner sowie sonstiger Einsch¨

atzung

des Lernenden (z. B. hinsichtlich

Vorwissen, F¨

ahigkeiten)

Vertiefung des Wissens

(deklarative Lernziele),

adaptive Informations-

systeme, Datenbanken

WBTs ohne/mit direk-

ter sozialer Interakti-

Lern- und Informationssysteme, die

ggf. eine Vernetzung mehrerer Ler-

ner erm¨

oglicht. Zur Verf¨

ugung stehen

k¨

onnen Chat, Whiteboard, Applicati-

on Sharing und Video-Conferencing

soziale Interaktion in

virtuellen Seminaren,

netzbasierte globa-

le Zusammenarbeit

(CSCL/W), virtuelle

Klassenr¨

aume

Tabelle 2.2.: Beispiele f¨

ur Anwendungstypen multimedialer Lernsysteme (in Anlehnung

an [Kal03], S. 66)

2. Beschreibung des Problembereichs und der Einflussfaktoren

2.2.4.1. Klassifikation von Spezifikationen und Standards

Euler und Seufert haben in [ES05], S. 458, vier Klassen von Standards bzw. Spezifikatio-

nen unterschieden in Technologie-, Prozess-, Lerntechnologie- und QM-/QS-Standards.

Diese Kategorisierung wird in diesem Abschnitt noch erg¨

anzt um eine Klasse, die spe-

zifizierte Frameworks und Referenzmodelle enth¨

alt, die zum Softwareentwurf von Lern-

systemen und -technologien verwendet werden k¨

onnen (vgl. Abb. 2.4):

âBei den Technologiestandards handelt es sich um Standards f¨

ur Basistechnologien,

auf die bei der Entwicklung und beim Betrieb von Lerntechnologien zur¨

uckgegriffen

werden kann. Diese Kategorie umfasst unter anderem Webtechnologien, Protokol-

le oder ¨

Ubertragungsformate wie Extensible Markup Language (XML) oder Real

Simple Syndication (RSS), aber auch Audio- und Videoformate.

âLerntechnologiestandards/-spezifikationen betreffen die Komponenten computer-

gest¨

utzer Lernszenarien (z. B. Inhalte, Methoden, Benutzermodelle) und zielen auf

Interoperabilit¨

at und Wiederverwendbarkeit von Lernumgebungen und -inhalten

ab. Soweit sie auf quelloffenen Dateiformaten basieren, verhindern sie die Bindung

von Nutzern an einzelne Plattformen (Locked-In) und sind Voraussetzung f¨

ur einen

Wettbewerb unter den Systemherstellern und f¨

ur wettbewerbsf¨

ahige Open-Source-

Produkte.

âArchitekturspezifische Frameworks und Referenzmodelle zielen auf ein gemeinsa-

mes Verst¨

andnis bzgl. der Informations- und Softwarearchitektur von Lernsyste-

men und -technologien ab. In diesem Rahmen werden von verschiedenen Stan-

dardisierungsgremien aktuell die in der E-Learning-Dom¨

ane gel¨

aufigsten Prozes-

se und Dienste definiert, abstrakte (formale) Modelle vom Anwendungsverhalten

und gemeinsame Datenstrukturen festgelegt, sowie gemeinsame Schnittstellende-

finitionen und Infrastrukturen verabschiedet. Das Ziel dabei ist zum einen eine

Kostenreduktion bei der Modellerstellung beim Entwurf und der Implementierung

von E-Learning-Software durch Wiederverwendung, zum anderen die generelle Be-

schreibung von Lernsystemen und -technologien als Standard.

âNach [ES05] bilden QM- und QS-Standards den Rahmen f¨

ur den Einsatz von Stan-

dards in Organisationen, jedoch haben sich im Bereich von Qualit¨

atsmanagement

und -sicherung bisher noch keine Standards durchsetzen k¨

onnen42. Internationale

Standardisierungsbestrebungen stellen aber bereits ein Rahmenwerk f¨

ur die indi-

viduelle Qualit¨

atssicherung bereit. Von deutscher Seite wurde ein Referenzmodell

und Referenzkriterien eingebracht (DIN PAS 1031-1, vgl. [DIN04a] und [EGHP05],

S. 59), welche Prozesse der Planung, Entwicklung, Durchf¨

uhrung und Evaluation

von Bildungsprozessen und Bildungsangeboten unter besonderer Ber¨

ucksichtigung

von E-Learning beschreiben.

42Zwar gibt es Normen wie die ISO 9000:2000 (http://www.quality.de/lexikon/iso 9000 2000.htm,

letzter Zugriff: 31.07.08), dennoch ist diese nicht f¨

ur alle Qualit¨

atsziele respektive alle Organisati-

onsarten geeignet und eben kein Standard (vgl. [EGHP05], S. 57).

2.2. Das elektronisch unterst¨

utzte Lernen

Technologie

SGML, XML, ...

GPRS, UMTS, ...

MPEG-x, ...

HTTP, TCP/IP, ...

Prozesss

E-Business-Standards

(z. B. EBXML, OASIS)

Schulstandards (z. B. School Interoperability

Framework),

Curriculumstandards (z. B. ECTS)

Architektur

Frameworks

ELF, IMS AF

Referenzmodelle

IEEE LTSC, OKI

Qualitätsmanagement und -sicherung

Prozessorientierung

ISO 9000:2000,

EFQM, DIN

Referenzmodell

Produktorientierung

Kriterienkatalog

(dmmv, ASTD), DIN

Referenzkriterien

Lerntechnologie

Content

Metadata

LOM, DC

Content

Packaging

IMS Content

Packaging, Simple

Sequenzing, QTI

Content

Communication

IMS SCORM

Learner Profile

IMS LIP, IEEE

PAPI

Learning Design

IMS LD, DIN

Didaktisches

Objektmodell

Abbildung 2.4.: Spezifikationen und Standards im E-Learning

âLernumgebungen werden zumeist in bestimmten organisatorischen Kontexten be-

trieben, wie in Hochschulen, in Unternehmen oder zur Unterst¨

utzung kommerzi-

eller Weiterbildung ¨

uber Internetportale. Insofern sind auch Standards relevant,

die f¨

ur verwandte Prozesse und Systeme entwickelt wurden. Dazu geh¨

oren Pro-

zessstandards bestimmter Bildungssysteme43, aber auch aus dem Bereich des E-

Business44.

Auf den folgenden Seiten werden die beiden f¨

ur das Forschungsumfeld dieser Arbeit

besonders interessanten Kategorien Lerntechnologiestandards und Architekturspezifische

Frameworks und Referenzmodelle noch einmal ausf¨

uhrlicher behandelt.

2.2.4.2. Lerntechnologiestandards

Die f¨

ur den Bereich des E-Learnings spezifischen Lerntechnologiestandards, die die Si-

cherstellung der Interoperabilit¨

at und Wiederverwendbarkeit virtueller Lernressourcen

f¨

ur Lehrende, Lernende und Entwickler fokussieren, werden durch ein Kooperations-

netzwerk von Standardisierungsgremien und -projekten spezifiziert. Verschiedene Vari-

anten dieser Spezifikationen werden von Normungsinstitutionen wie der internationalen

43Eine Spezifikation zu diesem Zweck ist die Schools Interoperability Framework Implementation Spe-

cification (SIF), die Bereiche der Pr¨

ufungsverwaltung, Studentenadministration und Studentenin-

formation koordiniert (vgl. [SIF07]).

44Zum Beispiel die Electronic Business using XML (ebXML, s. http://www.ebxml.org/), deren Ziel

eine Standardisierung von Daten¨

ubertragungsschnittstellen im gegenseitigen elektronischen Daten-

austausch im Kontext verschiedenster Gesch¨

aftsprozesse darstellt.

2. Beschreibung des Problembereichs und der Einflussfaktoren

ISO/IEC/JTC145, der europ¨

aischen CEN/ISSS46 oder dem Deutschen Institut f¨

ur Nor-

mung e. V. (DIN) harmonisiert, autorisiert und herausgegeben.

Die wichtigsten Standardisierungsgremien und -projekte sind:

IEEE LTSC Das Learning Technology Standards Committee der IEEE entwickelt auf

Basis einer Systemarchitektur Learning Technology Systems Architecture (LTSA,

siehe S. 44) abstrakt-konzeptuelle Spezifikationen f¨

ur verschiedene Teilbereiche des

E-Learnings. Sie besteht aus Arbeitsgruppen, die – aufgeteilt auf verschiedene The-

menbereiche – Spezifikationen der verschiedenen Konsortien pr¨

ufen und Standards

verabschieden bzw. Vorschl¨

age f¨

ur amerikanische und internationale Standards bei

ANSI oder ISO einreichen.

IMS Seit seiner Aufstellung als Educom-Projekt in 1997 hat das stark auf amerikanische

Bildungsverh¨

altnisse ausgerichtete Instruction Managed Systems Global Learning

Consortium Zulauf von den gr¨

oßten Lerntechnologielieferanten, -verlagen und -

endnutzern bekommen. Es stellt z. Zt. im Bereich der Interoperabilit¨

at das fortge-

schrittenste Projekt dar. Die praxis- und anwendungsorientierteren Spezifikationen

des Instructional Management Systems-Projekt orientieren sich gr¨

oßtenteils an den

Modellen der LTSC, beinhalten jedoch auch L¨

osungsvorschl¨

age zur Implementie-

rung sowie detaillierte Vorgehensrichtlinien (vgl. [Paw01], S. 97). IMS-Konzepte

wie das Learning Design (S. 43) sind zwar – Stand heute – noch in wenigen bis kei-

nen Produktivsystemen integriert, werden aber von vielen Herstellern aufmerksam

verfolgt und im akademischen Bereich47 experimentell verwendet (vgl. [WK07]).

ADLNet Die Anwendungsgemeinschaft Advanced Distributed Learning Network sollte

– gesponsort von der Amerikanischen Regierung – im großen Umfang die Ent-

wicklung von dynamischer und rentabler Lernsoftware vorantreiben sowie deren

Hersteller dazu bewegen, die Anforderungen der Belegschaft von Milit¨

ar und staat-

lichen Einrichtungen an Erziehung und Training zu ber¨

ucksichtigen. Das ADLNet

ist bekannt f¨

ur seine Empfehlung des Sharable Content Object Reference Model

(SCORM, S. 42), mit denen die US-Milit¨

ars untereinander alle Lerninhalte nut-

zen, austauschen, nachverfolgen und wieder verwenden k¨

onnen.

45Die International Standards Organization ist ein Netzwerk von nationalen Standardisierungsinstitu-

ten aus 140 L¨

andern, das mit internationalen Organisationen, Regierungen, der Industrie, Herstellern

und Verbrauchern zusammenarbeitet. In der International Electrotechnical Commission (IEC) ar-

beitet das Joint Technical Committee 1, Subcommittee 36 (JTC1/SC36) an internationalen Normen

im Umfeld E-Learning, Erziehung und Training.

46Das Centre de European Normalisation/the Information Society Standardisation System

(CEN/ISSS) erhielt im Jahre 1999 von der Europ¨

aischen Union das Mandat, einen Arbeitsplan

f¨

ur Interoperabilit¨

at im E-Learning f¨

ur Europa zu erarbeiten und ist somit Tr¨

ager der Normierungs-

aktivit¨

aten in Europa. Das erkl¨

arte Ziel ist dabei die Sicherstellung, dass jeder Standard europ¨

aische

Anforderungen ber¨

ucksichtigt.

47Vorreiter ist hierbei die Open University Netherlands (OUNL), aus dessen entwickelter Educational

Modeling Language (EML, vgl. [Kop01]) bei der IMS das Tr¨

agerformat Learning Design (IMS LD)

erwachsen ist.

2.2. Das elektronisch unterst¨

utzte Lernen

ARIADNE Die Association of Remote Instructional Authoring and Distributon Net-

works for Europe entstand aus einem F¨

orderprogramm der Europ¨

aischen Union

und hat einen europ¨

aischen Wissenspool virtueller Lernressourcen aufgebaut und

entsprechende Entwicklungswerkzeuge zur Verf¨

ugung gestellt. Neben der Entwick-

lungsarbeit nimmt das Projekt auch Einfluss auf Standardisierungsbestrebungen48.

AICC Das Aviation Industry CBT Committee stellt Richtlinien f¨

ur die Entwicklung

und Evaluation von E-Learning-Technologien im Bereich der Luftfahrt auf. Diese

AICC Guidelines and Recommendations (AGRs) beschreiben die Anforderungen

an Struktur und Interoperabilit¨

at in Bezug auf Bildungsprodukte mit definierten

Lernzielen und werden an die Arbeitsgruppe 11 des IEEE LTSC f¨

ur Computer

Managed Instruction (CMI) weitergereicht.

Die Spezifikationen und Standards, die von den o. g. Konsortien und Projekten erarbei-

tet wurden, fokussieren jeweils unterschiedliche Ebenen der Standardisierung. In An-

lehnung an [ES05] lassen sich demnach Standards bezogen auf Inhalteverwaltung und

-distribution, Lernmanagement, Lernerprofile und Didaktik unterscheiden, die im Fol-

genden kurz skizziert werden.

Content Metadata Inhaltliche Standards haben das Ziel, die system- und anwendungs-

unabh¨

angige Sicherstellung der Wiederverwendbarkeit, Anpassbarkeit und Rekombinier-

barkeit von Lernressourcen zu gew¨

ahrleisten. Dazu werden die Lernressourcen mit Hilfe

von Metadaten beschrieben. Um passende Lerninhalte aufzufinden und diese in ande-

ren Lernszenarien wieder zu verwenden, k¨

onnen die Beschreibungen von Entwicklern

oder Lehrenden durchsucht werden. Des Weiteren k¨

onnen Lernressourcen dadurch in

Weiterbildungsdatenbanken strukturiert abgelegt werden, was neue Vertriebswege und

Marketingkan¨

ale erm¨

oglicht (vgl. [ES05], S. 459). Der in diesem Bereich am meisten ver-

breitete Standard ist die Learning Object Metadata (LOM). Die Wiederverwendbarkeit

auf Basis von Metadaten h¨

angt maßgeblich davon ab, ob die Lernressourcen angemessen

mit Klassifikationen und Schlagworten beschrieben wurden. Weitere Standards: Dublin

Core zur Beschreibung von Dokumenten und anderen Online-Ressourcen, SQI (Simple

Query Interface) als Schnittstellenspezifikation zur Konfiguration und ¨

Ubertragung von

Anfragen an Lernrepositories.

Content Packaging Spezifikationen zum Content Packaging beschreiben Kursstruktu-

ren in standardisierter Form (Packages), die ihrerseits wieder Lerninhalte referenzieren

k¨

onnen. Die Packages umfassen neben den Dateien der Lerninhalte auch ein Manifest,

welches Metadaten, die Struktur einzelner Einheiten und den Verweis auf die Ressour-

cen enth¨

alt. Weiterhin umfassen die Spezifikationen auch Regeln f¨

ur die Auslieferung

der Inhalte und Aspekte der Evaluation. Beispiele: IMS Content Packaging, IMS Simple

Sequenzing.

48In diesem Zusammenhang hat der Verband sein entworfenes Metadaten-Schema zur Beschreibung von

Lerninhalten mit den Spezifikationen der IMS abgestimmt und zusammen an die IEEE weitergelei-

tet. Seitdem ist die Arbeitsgruppe 12 des LTSC zust¨

andig f¨

ur weitere Spezifikationen der Learning

Object’s Metadata (LOM).

2. Beschreibung des Problembereichs und der Einflussfaktoren

Learning Management Management-Standards behandeln die Interoperabilit¨

at admi-

nistrativer Systeme (z. B. Lernmanagementsysteme) und Lernressourcen. In diesem Zu-

sammenhang ist SCORM hervorzuheben, das als Referenzmodell zur Integration unter-

schiedlicher Lerntechnologiestandards zunehmend an Verbreitung gewinnt (vgl. [ES05],

S. 463)49. SCORM besteht seit der Version ”SCORM-2004“ aus drei wesentlichen Kom-

ponenten:

Content Aggregation Model (CAM) beschreibt die Verwendung von Ressourcen als

Packages, sowie ihre strukturisierte Ablage in Organisations. In Analogie zum

Content Packaging (s. o.) werden die Ressourcen und das Paket via Metadaten im

XML-Format beschrieben.

Runtime Environment (RTE) Um die Definition von Lernzielen zu erm¨

oglichen, Lern-

fortschritte zu dokumentieren und eine Adaption von Darstellung und Inhalten

an bestimmte Lernpr¨

aferenzen des Benutzers zu unterst¨

utzen, stellt die RTE eine

Schnittstellendefinition zwischen dem Lernmanagementsystem und einzelnen Ler-

neinheiten zur Verf¨

ugung. Diese enth¨

alt einen Startmechanismus (Launch), eine

gemeinsam zu nutzende Funktionsschnittstelle (API) zur Kommunikation zwischen

LMS und Lerninhalt, sowie eine Spezifikation des Datenaustauschs zwischen LMS

und Lerninhalt.

Sequenzing & Navigation (SN) Die SN-Spezifikation beschreibt so genannte Aktivi-

t¨

atenb¨

aume, die alle m¨

oglichen Sequenzen zur Darstellung von Lerninhalten in

Abh¨

angigkeit von Aktionen des Benutzers definieren.

Eine maßgebliche Schw¨

ache von SCORM ist die noch fehlende Integration didaktischer

Konzepte. Trotz dessen kann die Verwendung von SCORM zu einer Verbesserung der

Investitionssicherheit an Hochschulen f¨

uhren (vgl. [ES05], S. 465). Weitere Beispiele in

dieser Kategorie: Die Spezifikation Computer Managed Instruction (CMI) zum Aus-

tausch und zur Kombination und Administration von Kursen ¨

uber Lerntechnologien

hinweg soll zentrale Administrations- und Steuerungssysteme erm¨

oglichen. Ein weiterer

Standard ist die Question and Test Interoperability (QTI), welcher sich mit der Aus-

tauschbarkeit von Lernerfolgs¨

uberpr¨

ufungen befasst.

Learner Profile Aktorenorientierte Standards unterst¨

utzen die Erfassung und konsis-

tente Nutzung von Daten ¨

uber Lernende und Lernprozesse. Diese Daten k¨

onnen dann

zur Anpassung einer Lernumgebung, oder aber auch zur Unterst¨

utzung organisatori-

scher Prozesse (Klausuranmeldungen, Einreichung von Bewerberprofilen, Anlegen von

Personalstammdaten) genutzt werden (vgl. [ES05], S. 461). Auf dem Gebiet der aktore-

norientierten Standards gibt es zwei konkurrierende Ans¨

atze: Das Learner Information

Package (IMS LIP) und Public and Private Information for Learners (IEEE PAPI).

Durch die Etablierung des LIP als nationalen Standard in Großbritannien zeichnet sich

49Ein Grund daf¨

ur ist sicherlich, dass sich die maßgeblichen Standardisierungsgremien (u. a. IEEE, IMS

und AICC) an der Entwicklung dieses Standards mit beteiligt haben.

2.2. Das elektronisch unterst¨

utzte Lernen

eine h¨

ohere Verbreitung und Akzeptanz f¨

ur diesen Standard ab. IMS LIP umfasst un-

terschiedliche Kategorien, mit denen die Zielsetzungen, Aktivit¨

aten, formale und in-

formale Lernerfahrungen, Pr¨

aferenzen oder auch Zugangsm¨

oglichkeiten eines Lernenden

beschrieben werden k¨

onnen. Daten ¨

uber den Lernenden k¨

onnen somit sukzessive erg¨

anzt

und fortgeschrieben und somit auch f¨

ur informelles Lernen im Rahmen des lebenslangen

Lernens genutzt werden50.

Didaktische Standards Zielsetzung didaktischer Standards ist eine Beschreibung di-

daktischer Konzepte und Methoden, die die Entwicklung und Implementierung von

Lerntechnologien betreffen. Insbesondere adressieren sie die Darstellung didaktischer

Methoden sowie die Zuordnung von Lernressourcen zu didaktischen Kontexten, die

durch die derzeitigen Metadatenstandards wie LOM nicht ad¨

aquat repr¨

asentiert wer-

den (vgl. [Bau06b]).

Auf Basis der Educational Modeling Language (EML) wurde die Spezifikation des

Learning Designs (IMS LD, vgl. [IMS03b]) entwickelt, die bereits international vie-

le Anh¨

anger gefunden hat. Sie beschreibt ein Aktivit¨

aten-orientiertes Metamodell zur

p¨

adagogischen Modellierung von Lernumgebungen, das die Ausstattung und den Ablauf

von didaktischen Szenarien umfasst. Da es nur Informationen auf Ebene der Prozess-

steuerung enth¨

alt und keine ¨

uber die ihnen zugrunde liegenden p¨

adagogischen Ans¨

atze,

ist IMS LD in diesem Sinne didaktisch neutral (vgl. [Bau06b], S. 241). Trotzdem st¨

oßt

die Modellierung didaktischer Konzepte auch auf Widerst¨

ande. Das liegt daran, dass

didaktische Standards oft als ”. . . Vereinheitlichung der Didaktik oder Einschr¨

ankung

der didaktischen Freiheit“ [ES05], S. 466, verstanden werden.

Eine weitere Spezifikation ist die DIN PAS 1032-2:2004, welche ein didaktisches Ob-

jektmodell zur Modellierung und Beschreibung didaktischer Szenarien definiert (vgl.

[DIN04b]).

2.2.4.3. Architekturspezifikationen

Ein Framework liefert ein Vokabular, mit dem sich wiederkehrende Konzepte und in-

tegrierende Umgebungen modellieren lassen. Analog zum Entwurfsmuster-Konzept in

der Softwareentwicklung (vgl. [GHJV96]) ist der vorrangige Fokus von Architektur-

frameworks daher nicht technischer Art, sondern auf ein gemeinsames Verst¨

andnis von

architektonischen Sachverhalten auf der Basis eines gemeinsamen Vokabulars ausgelegt.

Architekturframeworks im E-Learning zielen also nicht auf die Entwicklung eines ge-

nerischen Lernsystems oder -technologie ab, sondern sie bieten allgemeine Definitionen

von Komponenten an, die im Rahmen unterschiedlicher organisatorischer Ziele und Be-

dingungen dazu genutzt werden k¨

onnen, passende Systeme und Technologien f¨

ur die

E-Learning-Dom¨

ane zu entwickeln. Auf der Basis einer Auswahl von in einem oder meh-

reren Frameworks definierten Komponenten beschreibt eine Referenzarchitektur eine

bestimmte Klasse von Lernsystemen oder -technologien idealtypisch. Weiterhin umfasst

eine Referenzarchitektur Beschreibungen oder Regeln ¨

uber das idealtypische Zusammen-

spiel dieser Komponenten im Hinblick auf die speziellen Anforderungen dieser Klasse.

50Hierbei ist allerdings zu beachten, dass sich solche Standards langfristig erst dann in der Breite

durchsetzen werden, wenn entsprechende Sicherheitskonzepte bez¨

uglich der Nutzerdaten bereitge-

stellt werden (vgl. [ES05], S. 463).

2. Beschreibung des Problembereichs und der Einflussfaktoren

Prozesse und Dienste

Abstraktes Modell von

Verhalten und Daten

Anwendung

Daten

Funktions-

schnittstelle

Daten-

repräsentation

Web Service

Messaging

Framework

Referenzarchitektur

Softwaredesign

gemeinsames Verständnis

geläufiger Prozesse

gemeinsames formales

Modell

übereinstimmende

Datenstruktur (z. B. XML)

übereinstimmende

Service-Schnittstellen

gemeinsame Infrastruktur

(z. B. HTTP)

Abbildung 2.5.: Die Rolle von Frameworks und Referenzarchitekturen in Spezifikations-

vereinbarungen, in Anlehnung an [WBR04], S. 15.

Durch diese Referenzfunktion k¨

onnen von einer allgemeinen Referenzarchitektur spe-

zielle Entwurfsmodelle, ein so genanntes Softwaredesign, f¨

ur die konkrete Umsetzung

eines Systems oder einer Technologie abgeleitet werden. Auf den folgenden Seiten wer-

den mehrere Architekturmodelle vorgestellt, die f¨

ur die Dom¨

ane E-Learning wegweisend

sind, da an ihnen mehrere Standardisierungsprojekte mitgewirkt haben51.

Learning Technology Systems Architecture (LTSA) Die LTSA wurde innerhalb der

IEEE LTSC durch die Arbeitsgruppe 1 entwickelt. Die Spezifikation beschreibt Lern-

systeme auf einem sehr abstrakten Niveau, das weder Vorschl¨

age zur Implementierung

umfasst, noch von p¨

adagogischen Konzepten abh¨

angig ist. ”This Standard (1) provides

a framework for understanding existing and future systems, (2) promotes interopera-

bility and portability by identifying critical system interfaces, and (3) incorporates a

technical horizon (applicability) of at least 5-10 years while remaining adaptable to

new technologies and learning technology systems“ ( [IEE01], S. 7). Das Architekturfra-

mework umfasst demnach keinerlei Implementierungsrichtlinien und keine bestimmten

Auspr¨

agungen seiner Komponenten, womit die Nutzung als Referenzarchitektur ausge-

schlossen ist. Es bietet allerdings einen Bezugsrahmen f¨

ur weitere Standardspezifikatio-

nen und Referenzarchitekturen von Lerntechnologien, wie bspw. von Tyler in [Tyl03]

skizziert.

Die LTSA definiert f¨

unf Architekturebenen, von denen nur die dritte Ebene f¨

ur den

Standard maßgeblich ist und im Rahmen der Spezifikation n¨

aher beschrieben wird.

Sie beschreibt aktive Systemkomponenten/Teilsysteme (process), Informationsfl¨

usse zwi-

schen Komponenten (flows) sowie Funktionen zur Persistierung von Informationen (sto-

res) (vgl. [IEE01], S. 21ff.). Andere Ebenen wie Entwurfsfunktionen, Anwendersichten

und Implementierungsvorschl¨

age bleiben unspezifisch.

51Andere Arbeiten in diesem Bereich werden aufgrund ihrer Spezialisierung auf bestimmte didakti-

sche Konzepte – insbesondere auf intelligente tutorielle Systeme – an dieser Stelle nicht weiter

ber¨

ucksichtigt (z. B. [IM94], [MTH98]), [HD02], [HM05] etc.).

2.2. Das elektronisch unterst¨

utzte Lernen

E-Learning Framework (ELF) Das E-Learning Framework (ELF) des englischen Joint

Information Service Committee (JISC) und des australischen Department of Education,

Science and Training (DEST) basiert auf einer Sammlung verteilter Dienste, die zur

Umsetzung von Lernsystemen, E-Learning-Portalen und anderen, insbesondere dienst-

orientierten Informationsarchitekturen unterst¨

utzend eingesetzt werden k¨

onnen: ”The

ultimate aim of the Framework is, for each identified service, to be able to reference an

open specification or standard that can be used to implement the service, and also to be

able to provide open-source implementation toolkits such as Java and C# code libraries

to assist developers“ [JIS08].

Jeder Dienst wird dabei mit Hilfe einer Servicespezifikation beschrieben, die mindes-

tens folgende Information bereitstellen (vgl. [CET05], ServiceSpecification):

1. Eine Beschreibung des Dienstes und seine Rolle innerhalb des Frameworks

2. Eine Menge an Schnittstellendefinitionen oder Empfehlungen entsprechender Spe-

zifikationen

3. Eine Menge an Datentyp-Definitionen oder Empfehlungen entsprechender Spezifi-

kationen

4. Unterst¨

utzung der Implementierungstechnologie wie z. B. Java-Schnittstellen und

-Klassen f¨

ur J2EE, COM-Schnittstellen und -Klassen f¨

ur .net oder WSDL-Schnitt-

stellen und XML-Schemata f¨

ur eine Web-Service-Implementierung.

Die Dienste sind in vier Schichten unterteilt:

User Agents interagieren direkt mit dem Anwender, wie beispielsweise Autorenwerk-

zeuge und Portale. User Agents k¨

onnen entweder sehr kompakt sein und sich auf

einen bestimmten Bereich fokussieren, oder mehrere Prozesse umspannen, die in

einem einheitlichen Arbeitsfluss dargestellt werden und so homogen erscheinen.

Application Services beinhalten Funktionen, die von User Agents ben¨

otigt werden. Bei-

spiele daf¨

ur sind das Abfragen von Benutzerinformationen oder die Speicherung

von Daten. Die Hauptanforderungen an Application Services ist einerseits die Of-

fenlegung ihrer Funktionalit¨

at, um von beliebigen User Agents oder anderen Ap-

plication Services wieder verwendet werden zu k¨

onnen. Und andererseits die Be-

reitstellung einer Standardschnittstelle f¨

ur die Wiederverwendbarkeit.

Common Services bieten nicht-bildungsspezifische Funktionen, die jedoch Grundlage

f¨

ur die Ausf¨

uhrung der Application Services und der User Agents sind und ur-

spr¨

unglich gemeinsame Funktionen sowie Daten anderer Services beinhalten.

Infrastructure beschreibt die zugrunde liegenden Ressourcen, die f¨

ur eine Implementie-

rung vorausgesetzt werden. Diese werden jedoch im Rahmen der Konzeption des

ELF nicht weiter definiert.

Da das E-Learning-Framework f¨

ur viele Dienste auch Funktionsschnittstellen und Da-

tenrepr¨

asentation spezifiziert und auch Implementierungen und Werkzeuge bereit h¨

alt,

hat es – im Gegensatz zur LTSA – nach obiger Definition viele Qualit¨

aten einer Refe-

renzarchitektur.

2. Beschreibung des Problembereichs und der Einflussfaktoren

IMS Abstract Framework (IAF) Das IAF stellt f¨

ur das IMS Global Learning Consor-

tium einen definierten Kontext dar, innerhalb dessen es Lerntechnologien spezifizieren

kann. Es enth¨

alt neben einer technischen Beschreibung einer serviceorientierten Multi-

Tier-Architektur52 eine abstrakte Darstellung von den Diensten53, mit denen Lernsyste-

me im weitesten Sinne konstruiert werden k¨

onnen (vgl. [A+03]). Genau wie das ELF legt

auch das IAF den Fokus auf ein gemeinsames Verst¨

andnis von architektonischen Sach-

verhalten auf Basis eines gemeinsamen Vokabulars, insbesondere auf Infrastrukturen f¨

verteilte Lernsysteme (vgl. ebd.). Insoweit deckt das Framework die m¨

ogliche Bandbreite

an Architekturen verteilter Lernsysteme ab, die mit dem Satz an spezifizierten Diensten

entwickelt werden k¨

onnen.

Ein abstraktes Modell von Verhalten und Daten wird durch die Verweise auf be-

stimmte IMS Spezifikationen zu Diensten und Datenstrukturen aufgebaut, die zur De-

taillierung des Frameworks genutzt werden. Des Weiteren werden L¨

osungsvorschl¨

age zu

Implementierungsaspekten gemacht, z. B. zu Transportmechanismen zum Austausch von

XML-Dokumenten.

Genau wie beim ELF muss zur Ableitung einer Referenzarchitektur eine Auswahl von

spezifizierten Diensten auf eine Anwendungsklasse bezogen adaptiert werden (domain

profiling). Anderson et al. z¨

ahlen dazu in [A+03] (1) die Identifikation anforderungs-

gerechter Spezifikationen, (2) die Verfeinerung der Spezifikation durch anwendungsbe-

dingte Einschr¨

ankungen des Datenmodells und anwendungsbezogene Erweiterungen der

Spezifikation und (3) die Validierung und Zertifizierung der abgeleiteten Referenzarchi-

tektur gegen¨

uber den originalen Spezifikationen.

Open Knowledge Initiative (OKI) Die Open Knowledge Initiative (OKI) ist ein Pro-

jekt zur Spezifikation eines Referenzmodells f¨

ur universit¨

are Lernsysteme im amerikani-

schen Raum, das urspr¨

unglich vom Massachusetts Institute of Technology (MIT) initiiert

wurde54. Das Ziel ist die Definition von offenen Schnittstellen (Open Source Interface De-

finitions, OSIDs) zu fundamentalen Diensten der universit¨

aren Informationsarchitektur,

durch die sowohl Lerntechnologien untereinander als auch mit universit¨

aren Adminis-

trationssystemen und anderen akademischen Systemen (z. B. Bibliothekssystemen und

Digitalen Repositories) kommunizieren k¨

onnen. Eine OSID gilt dabei als zweiseitige Ver-

einbarung zwischen Dienstanbietern (Server) und Dienstnutzern (Clients). Implementie-

ren beide Parteien diese Schnittstellenspezifikation, kann eine Interoperabilit¨

at bzw. eine

Portabilit¨

at von Anwendungsfunktionen gew¨

ahrleistet werden.

52Strukturierungsprinzip f¨

ur Softwarearchitekturen, wobei einzelne Aspekte des Systems konzeptionell

in einer Schicht (engl. tier) zugeordnet werden.

53In Analogie zum ELF sind die Dienste auf die Schichten Application Layer,Application Services

Layer,Common Services Layer und Infrastructure Layer verteilt.

54Die Spezifikation werden von Herstellern wie beispielsweise Apple Computer, Cisco Systems, Mi-

crosoft, Moodle, IMS Global Learning Consortium und Universit¨

aten wie das MIT, die Califor-

nia State University und die Open University of Catalonia adaptiert. Mehr Informationen unter

http://www.okiproject.org. Letzter Zugriff: 31.07.2008.

2.2. Das elektronisch unterst¨

utzte Lernen

Setzt sich die Referenzarchitektur auf dem amerikanischen Ausbildungsmarkt durch55,

k¨

onnen neue Komponenten sehr leicht in die dortigen universit¨

aren Informationsar-

chitekturen eingebunden werden, wobei ein initialer Installations- und Konfigurations-

aufwand nicht notwendigerweise reduziert wird; die Kosteneinsparungen sollen sich je-

doch im Betrieb durch verringerte Wartungs- und Weiterentwicklungskosten ergeben

(vgl. [BCG03]).

Campus Source Engine (CSE) Die deutsche Open Source-Initiative CampusSource56

entwirft auf Basis einer eigenen Referenzarchitektur (vgl. [SVS03] und [GMS03]) seit

2003 eine Softwaredesign namens CampusSource Engine (CSE) zur Koppelung ihrer

Plattform- und Werkzeugb¨

orse an die universit¨

are Diensteinfrastruktur. Die Referenz-

architektur besteht auch in diesem Beispiel aus der Spezifikation einer mehrschichtigen57,

dienstorientierten Architektur, sowie aus einer abstrakten Beschreibung von Diensten58.

Die CSE wurde unter zwei Zielsetzungen entworfen (vgl. [S+04]). Zum einen zur De-

finition und Implementierung einer einheitlichen Schnittstelle der bei CampusSource

verf¨

ugbaren E-Learning-Plattformen zu Datenbest¨

anden von Verwaltungssoftware der

Firma Hochschul-Informations-Systeme GmbH (HIS)59. Zum anderen, um eine ziel-

gerichtete Konvergenz der verf¨

ugbaren Systeme und Werkzeuge in CampusSource zu

erlangen, damit f¨

ur Anwender die M¨

oglichkeit besteht, aus einer Vielzahl von Funktio-

nen eine auf ihre individuellen Bed¨

urfnisse abgestimmte Plattformen zusammenzustellen

(vgl. ebd.).

Zum Zeitpunkt der Fertigstellung dieser Arbeit existiert bereits ein Teil der CSE als

ereignisgesteuerte, Nachrichten-orientierte Integrationsplattform, die Schnittstellen zum

Datenabgleich zwischen HIS LSF60 und den CampusSource-Plattformen61 implemen-

tiert.

55Stand August 2006 gab es bereits 31 unterschiedliche Anbieter und Implementierungen, die diese

Spezifikationen ber¨

ucksichtigen und somit interoperabel sind (vgl. [OKI06]).

56CampusSource wurde 1999 zur Verstetigung quelloffener Lernplattformen gegr¨

undet. Ihr Portfolio

enth¨

alt derzeit 19 E-Learning-Anwendungen, sowohl umfangreiche Lernmanagementsysteme als auch

kleinere Werkzeuge (siehe http://www.campussource.de).

57Six et al. unterscheiden hier Web-Schicht, Applikations-Schicht, lokale Datenhaltungsschicht und zen-

trale Basisdienste (vgl. [SVS03]).

58Es werden Allgemeine Dienste (Security Service, Directory Service und UI Service) und spezielle

Dienste (Course Service, Exercise Service, Exam Service, StudyRecord Service) unterschieden. Die

Aufz¨

ahlung wird aber ausdr¨

ucklich als beispielhaft und nicht vollst¨

andig deklariert (vgl. [GMS03],

S. 11f.).

59Die Software der HIS ist im Bereich der Verwaltungen der Hochschulen in NRW als Standard etabliert.

60Das Modul Lehre, Studium, Forschung (LSF) dient als Studieninformations-, Studienberatungs- und

Planungssystem f¨

ur verschiedene Nutzerkreise (Studierende, Lehrpersonal, Administratoren, Raum-

planer).

61Beim Stand der Fertigstellung dieser Thesis sind dies ILIAS, CLIX, EWS II, metacoon, Moodle,

OpenUSS und Stud.IP (vgl. [Pos07]).

2. Beschreibung des Problembereichs und der Einflussfaktoren

2.2.5. Zusammenfassung

Das computerunterst¨

utzte Lernen hat durch die st¨

andig zunehmende Vernetzung und

Nutzung von Informations- und Kommunikationssystemen neue Gestaltungsm¨

oglichkei-

ten hinzugewonnen. Stellte Ende der 1990er Jahre noch die durch WBTs verbesserte

Distribution von Lerninhalten und die explorative Erfahrungen mit Hypermedia das

Maß der Dinge dar, sind in den letzten Jahren neue E-Learning-Paradigmen hinzuge-

kommen, die bspw. soziale Aspekte bei der Kooperation, eine bessere Integration von

Lern- in Arbeitsprozesse, die Selbstorganisation beim Wissensmanagement oder den di-

rekten Austausch mit Experten in einen neuen Fokus r¨

ucken.

Die bisher getrennten Pr¨

asenz- und Fernunterrichtsformen konvergieren durch Blen-

ded Learning Ans¨

atze zu hybriden Unterrichtsmodellen, ebenso verschmelzen Theorien

von Bildung und Wissen zu neuen p¨

adagogischen Anwendungsfeldern von Wissensma-

nagement (vgl. [Rei05b]). Diese Aufweichung von Grenzen bisher getrennter Konzepte

schl¨

agt sich auch in der Nutzung von Technologien f¨

ur das Lernen nieder; zu den bislang

spezialisierten Lerntechnologien (vgl. Tabelle 2.2) werden zus¨

atzlich Basistechnologien

zur synchronen und asynchronen Kommunikation und Kollaboration verwendet. Dies

m¨

undet in neuen Anforderungen zur Integration von Lernumgebungen in heterogene In-

formationsarchitekturen, um Lern- und Arbeitsprozesse medienbruchfrei ¨

uber System-

und Technologiegrenzen hinweg zu unterst¨

utzen.

Dieser neue Fokuswechsel, von den funktionsm¨

achtigen aber monolithischen Lernsyste-

men hin zu dienstorientierten, offenen IT-Infrastrukturen mit interoperablen Lernwerk-

zeugen l¨

asst sich auch an den aktuellen Standardisierungsbestrebungen im E-Learning

belegen: Wurden zun¨

achst haupts¨

achlich Standards zur Inhalteverwaltung und -distri-

bution erarbeitet, zielten die Bestrebungen der letzten Jahre schwerpunktm¨

aßig darauf

ab, Lerner- und Lernprozessdaten zu spezifizieren, um die Kombination von Lerntech-

nologien innerhalb eines Lernsystems zu erleichtern62.

Besonders klar erkennbar l¨

asst sich der Wechsel an den neueren Spezifikationen von

Referenzarchitekturen f¨

ur Lernumgebungen ablesen, die allesamt komponentenbasierte,

dienstorientierte Multi-Tier-Architekturen beschreiben. Erste Implementierungen von

OSIDS oder die CampusSource Engine zeigen den erfolgreichen Einsatz speziell im

universit¨

aren Bereich, da somit der ¨

Ubergang von einer verteilten kooperativen IT-

Versorgung hin zu einer integrierten Informationsversorgung gef¨

ordert wird, ohne die

an Hochschulen vorhandene Vielfalt an didaktischen Arrangements einzuschr¨

anken.

62Zwar zielen die Standards immer noch auf formale, institutionalisierte Lern- und Bildungsprozesse ab,

werden aber nach Klebl nicht an Bedeutung verlieren, da auch das informelle Lernen auf Kompeten-

zen und ein bestimmtes Maß an Grundkenntnissen in einem Wissensbereich beruht, die in formalen

Bildungsprozessen erworben wurden (vgl. [WK07]).

2.3. Neue technologische und inhaltliche Trends im World Wide Web

2.3. Neue technologische und inhaltliche Trends im

World Wide Web

Neben aktuellen Trends im E-Learning hat die Evolution des World Wide Webs einen

großen Einfluss auf die computergest¨

utzte Hochschullehre, sowohl aus technologischer

als auch aus didaktischer Sicht. Im Folgenden sollen diese Weiterentwicklung und ihre

Potenziale n¨

aher beschrieben werden.

2.3.1. Der Begriff des Web 2.0

Das Zerplatzen der Dot-Com-Blase im Herbst 2001 bedeutete nicht das Ende des World

Wide Web, sondern einen Wendepunkt. ¨

Ublicherweise markiert eine solche Marktberei-

nigung eine Phase, in der sich neue Technologien durchgesetzt haben und nun aus der

okonomischen Perspektive betrachtet werden (Slope of enlightenment, vgl. [FL05]). Drei

Jahre sp¨

ater wurde der Begriff ”Web 2.0“ allgemein eingef¨

uhrt, um die Konzepte und

Anwendungen zu beschreiben, welche das Web in der Zeit nach diesem Wendepunkt

wichtiger machten als zuvor63. Danach beschreibt der Begriff keine technologische Inno-

vation oder Revolution webbasierter Anwendungen, sondern vielmehr einen neuen Evo-

lutionsabschnitt des Internets. Obwohl dieser Abschnitt durch technische Neuerungen

fixiert werden kann, liegt die Wurzel der Ver¨

anderung in einer neuen Verhaltensstruktur

der Internetbenutzer, die sich ¨

uber die Jahre der Onlinepr¨

asenz auf einer gesellschaftli-

chen Entwicklungsebene gebildet hat.

Nach Tim O’Reilly nutzen Angebote des ”neuen“ World Wide Webs daher die ”kol-

lektive Intelligenz“ ihrer Nutzer (vgl. [O’R05]): Suchresultate k¨

onnen durch Ber¨

ucksich-

tigung von Benutzeraktivit¨

aten verbessert werden, kollaborative Spam-Filter lernen aus

den Einstufungen ihrer gesamten Benutzer und funktionieren somit besser als solche,

welche nur die Nachricht an sich analysieren. Das gemeinsame Verschlagworten (”Tag-

gen“) von Inhalten mit teils ¨

uberlappenden Assoziationen f¨

uhrt zu M¨

oglichkeiten, diese

entlang logischer Wege wieder aufzufinden.

So genannte Social Software unterst¨

utzt im Web zum einen das Publizieren von ei-

genen Inhalten, zum anderen unterst¨

utzt sie den Aufbau vernetzter sozialer Strukturen

durch Nutzerbeteiligung. Auf den folgenden Seiten werden diese neuen Werkzeuge und

ihre Nutzungsm¨

oglichkeiten vorgestellt, sowie die Implikationen, die sie f¨

ur das compu-

tergest¨

utzte Lernen haben.

63Zwar wurde der Begriff Web 2.0 bereits 1999 in einem Aufsatz von Darcy DiNucci verwendet, in dem

er aktuelle technologische Entwicklungen des Internets beschreibt (vgl. [DiN99]), wirklich gepr¨

agt

wurde er mit seiner heutigen Bedeutung jedoch erst im Jahre 2005 von Tim O’Reilly mit seinem

Artikel ”What is Web 2.0“ (vgl. [O’R05]).

2. Beschreibung des Problembereichs und der Einflussfaktoren

2.3.2. Benutzergenerierte Inhalte und soziale Strukturen

2.3.2.1. User Generated Content – Vom Konsumenten zum Produzenten

Weblogs Weblogs (oder kurz: Blogs) sind die fundamentalen Vertreter der sozialen

Software, die aktuell das Erscheinungsbild des Internets revolutionieren und einen wich-

tigen Eckpfeiler des heutigen World Wide Webs ausmachen. Unter dem Begriff Weblog

wird in seinen verschiedensten Formen nach eine Auspr¨

agung von Internet-Publikation

verstanden, deren inhaltliche Bandbreite von pers¨

onlichen Gedanken und privaten Din-

gen des Lebens bis hin zu journalistischen Beitr¨

agen professioneller Nachrichtendienste

reicht. Grunds¨

atzlich steht der Begriff Weblog f¨

ur die drei folgenden zentralen Ideen:

âDie Erzeugung und das vereinfachte Einstellen von Inhalten mit Hilfe eines Content-

Management-Systems (CMS)

âEine zeitliche Einordnung durch eine chronologische Darstellung, sowie die Zusam-

menfassung ¨

ahnlicher Inhalte durch Kategorisierung

âEinbezug der Leser durch Kommentar- und Verkn¨

upfungsfunktionen direkt am

Beitrag selbst. Durch Automatismen kann auf Eintr¨

age anderer Weblogs, die sich

auf diesen Beitrag beziehen, am Beitrag selbst verwiesen werden.

Heute existieren viele Blog-Hosting-Anbieter, ¨

uber die sich kostenlose Weblogs in weni-

gen Schritten und ohne jegliche Kenntnisse in Web-Design oder -Programmierung ein-

richten lassen. Professionelle, einfach zu betreibende Weblog-Systeme sind auch durch

die Open Source-Community entstanden. Auf die freie Verf¨

ugbarkeit dieser Systeme und

ihrer leichten Bedienung begr¨

undet fanden Weblogs im World Wide Web eine starke

Verbreitung (vgl. Abb. 2.6). Durch zahlreiche thematische und soziale Verkn¨

upfungs-

m¨

oglichkeiten64 zwischen einzelnen Weblogs untereinander ist mittlerweile ein stark in-

teraktives, soziales Netzwerk entstanden. Seit Ende der 1990er w¨

achst diese so genannte

Blogosph¨

are65 exponentiell an.

Wikis Ebenfalls zur sozialen Software geh¨

oren Wikis, die gegen¨

uber klassischen Tech-

nologien des Informationsmanagements ein Potenzial f¨

ur soziale Prozesse bereitstellen.

Das erste dokumentierte Wiki wurde im Fr¨

uhjahr 1995 durch Ward Cunningham, einem

Software-Designer aus Portland, betrieben, um zusammen mit Entwicklern aus aller

Welt eine Datenbank f¨

ur Entwurfsmuster aufzubauen66.

In Analogie zu Weblogs basieren Wikis ebenfalls auf einem spezialisierten CMS. Der

Fokus liegt hierbei auf der kooperativen Erstellung von Hypertexten, wobei keinerlei

Kenntnisse in Web-Design oder -Programmierung ben¨

otigt werden. Mit Hilfe einer ein-

fachen Syntax kann jeder Benutzer – meistens ohne vorherige Anmeldung am System

64Verkn¨

upfungen zwischen Weblogs k¨

onnen ¨

uber die Trackeback/Ping-Funktion (s. S. 53) geschaffen

werden, als auch ¨

uber eine Auflistung der vom Autor eines Weblogs selbst gelesenen Weblogs, der

so genannten Blogroll.

65Die Blogosph¨

are kennzeichnet die Gesamtheit der Weblogs. Es ist ein Kunstwort aus der Abk¨

urzung

Blog und Sph¨

are (Gesellschafts- bzw. Wirkungskreis).

66Das Wiki ist unter http://c2.com/cgi/wiki online. Letzter Zugriff: 31.07.2008.

2.3. Neue technologische und inhaltliche Trends im World Wide Web

Abbildung 2.6.: Stetiges Wachstum der in der Blogosph¨

are (Quelle:

http://technorati.com/weblog/)

– einen vorhandenen Text editieren, verbessern, erg¨

anzen und mit weiteren Seiten ver-

kn¨

upfen. Da ein Wiki f¨

ur jeden Text eine Historie speichert, in der alle ¨

Anderungen seit

der ersten Version aufgezeichnet werden, k¨

onnen Inhalte durch diesen offenen Ansatz

nicht dauerhaft besch¨

adigt werden.

Durch eine kooperative Verschlagwortung von Artikeln automatisch ein Kategorien-

system aufgebaut, das ein kontrolliertes, strukturiertes Vokabular f¨

ur die Erschließung

und die Verschlagwortung weiterer Inhalte zur Verf¨

ugung stellt.

Das wichtigste Gestaltungselement sind Hypertext-Verkn¨

upfungen zur referenziellen

Vernetzung der Lemmata. Externe Verweise f¨

uhren dabei zumeist zu Quellen, die entwe-

der weiterf¨

uhrende Informationen bereitstellen oder die im Artikel gemachten Aussagen

belegen. Der Verweis auf einen nicht existierenden Wiki-Inhalt birgt keinen Fehler, son-

dern eine M¨

oglichkeit, den fehlenden Inhalt sofort zu erfassen.

Eine ¨

Ubersicht ¨

uber die Bandbreite an Nutzungsm¨

oglichkeiten liefert das Wikiver-

zeichnis67.

67Siehe http://www.wikiservice.at/gruender/wiki.cgi?WikiVerzeichnis. Letzter Zugriff:

31.07.2008.

2. Beschreibung des Problembereichs und der Einflussfaktoren

Podcasts Als Podcasting wird im Allgemeinen das Produzieren, Anbieten und ¨

Uber-

tragen von Audio- und Videodateien bezeichnet68. Podcasts sind Sendungen bzw. Serien

von Sendungen und k¨

onnen ¨

ahnlich wie News oder Blogbeitr¨

age per RSS-Feed abonniert

werden (siehe Abschnitt 2.3.3.1). Dies erm¨

oglicht es, neue Folgen automatisch aus dem

Web zu laden. Somit steckt keine neue Technologie hinter diesem Begriff, sondern wiede-

rum eine neues Nutzungskonzept bereits vorhandener Technologien. Da die Produktion

von Audio- bzw. Videodateien auf aktuellen Multimedia-Computern f¨

ur viele Anwender

oftmals schon mit darauf vorinstallierten Software einfach m¨

oglich ist und eine einfache

Ver¨

offentlichung der Dateien als Informationsangebot ¨

uber Plattformen wie podcast.de,

podster.de oder Apples iTunes kostenlos erfolgen kann, existieren neben professionellen

Angeboten von bspw. WDR und BBC auch eine Vielzahl individueller Audio-Tageb¨

ucher

und Videoserien mit thematischen Schwerpunkten69. Ohne großen Aufwand kann sich

jedermann mit Netzzugang aus dem weltweiten Angebot an Podcasts ein individuelles,

auf die pers¨

onlichen Interessen abgestimmtes Audio- oder Videoprogramm abonnieren,

das sich bei neuen Folgen automatisch aktualisiert.

Gemeinschaftliches Indexieren Eine besondere Form der semantischen Verkn¨

upfung

von Inhalten ist das Social Tagging70. Diese personengebundene Verschlagwortung von

Inhalten durch Tags (Deskriptoren) stellt im Gegensatz zur formalen Semantik der Idee

des klassischen Semantic Webs71 eine bewusst unreglementierte Generierung von Me-

tadaten dar. Nach kurzer Zeit bildet sich ¨

uber die Gesamtheit aller Nutzer somit meist

ein Schlagwortsystem mit einem Kernbestand an Begriffen, der f¨

ur eine gezielte Suche

nach Inhalten brauchbar ist.

Die durch gemeinschaftliches Indexieren nach dem ”bottom-up“-Prinzip erstellte

Sammlung von Tags wird neusprachlich Folksonomy genannt72. Als lebendiges, offenes

und kollaboratives Kategoriensystem hat eine Folksonomy auch soziale Aspekte: ¨

Uber

die Personengebundenheit ihrer Schlagw¨

orter k¨

onnen Benutzer Nutzer mit ¨

ahnlichen

Interessenslagen und pers¨

onlichen Strukturen ausfindig machen, und dar¨

uber wiederum

an weitere f¨

ur sie interessante Inhalte gelangen.

Die Schlagw¨

orter einer Folksonomy werden oft in so genannten Tag Clouds zusam-

mengefasst, in denen die Begriffe visualisiert werden. Die Schriftgr¨

oße der einzelnen

Schlagw¨

orter variiert proportional zu ihrer H¨

aufigkeit (vgl. [M¨

ol05], S. 155).

Die ¨

offentliche Verschlagwortung pers¨

onlicher Lesezeichen im Web stellt die derzeit

am meisten genutzte Form des Social Taggings dar, das so genannte Social Bookmar-

king. Spezialisierte Dienste wie del.icio.us oder furl.net unterst¨

utzen diese Speicherung

und Auszeichnung von Hyperlinks und erm¨

oglichen dar¨

uber eine Suche nach Inhalten

im Netz, deren Relevanz durch das Kollektiv im Allgemeinen und das Individuum im

Besonderen bestimmt wird (vgl. [Alb07], S. 91f.).

68Abgeleitet von den Begriffen Broadcasting und Apples iPod wird Podcasting h¨

aufig jedoch nur auf

die Verbreitung von Audiodateien bezogen.

69Bspw. Nachrichten und Politik, Musik, Wirtschaft, Humor, Sport oder Technik.

70Auch Collaborative Tagging oder schlicht ”gemeinschaftliches Indexieren“ genannt.

71Auszeichnung von Inhalten durch maschinenlesbare semantische Informationen, die durch Taxonomi-

en und Ontologien formal strukturiert sind.

72Ein Neologismus aus den englischen Begriffen folk und taxonomy, der zur¨

uckzuf¨

uhren ist auf Thomas

Vander Wal.

2.3. Neue technologische und inhaltliche Trends im World Wide Web

Soziale Netzwerke und Online Communities Die Interaktion auf und mit sozialen

Netzstrukturen ist eine fundamentale Auspr¨

agung des Web 2.0. Nach O´ Murchu et al.

haben soziale Netzwerke als Vorstufe virtueller Communities die Aufgabe, Menschen zu

verbinden und Informationen ¨

uber diese in den Nutzerprofilen zu geben: ”A social net-

working site (SNS) connects and presents people based on information gathered about

them, as stored in their user profiles“ [OBD04], S. 2. Im Web erstellen die Nutzer eines

sozialen Netzwerkes ein ausf¨

uhrliches Profil, in dem sie ihre Interessen und Schwerpunkte

sowie M¨

oglichkeiten zur Kontaktaufnahme preisgeben. Im Sinne des Social Networkings

spiegelt dieses Profil – im Gegensatz zum allgemein ¨

ublichen Avatar in Communities –

die Pers¨

onlichkeit des Nutzers so exakt wie m¨

oglich wider. Anonymit¨

at ist beim Aufbau

sozialer Strukturen nicht erw¨

unscht. So k¨

onnen Teilnehmer untereinander durch geeig-

nete Funktionen der technischen Plattform ihren Kontakt zu anderen Teilnehmern oder

auch Gruppen best¨

atigen und Kontakte anderer verfolgen. Es lassen sich somit zielge-

richtet sowohl gesch¨

aftliche Beziehungen als auch Freundschaften pflegen, das Auffinden

von Menschen mit gemeinsamen Interessen wird erleichtert.

Virtuelle soziale Netzwerke und Online-Gemeinschaften funktionieren nach Manuel

Castells aufgrund zweier Merkmale: Erstens die freie horizontale Kommunikation (n:m-

Kommunikation) und zweitens die ”selbstgesteuerte Vernetzung“ der eigenen Person,

um ein Netzwerk im Netz zu bilden (vgl. [Cas05], S. 66). Es entsteht somit eine Selbst-

Ver¨

offentlichung,Selbst-Organisation und Selbst-Vernetzung im Internet (vgl. ebd.).

2.3.3. Technologische Trends

2.3.3.1. Neue Mechanismen zur semantischen Verkn¨

upfung von Inhalten

Die Blogosph¨

are bildet sich autonom als hoch vernetzte Struktur um Micro-Contents,

erstellt von unz¨

ahligen, unabh¨

angig voneinander agierenden Autoren. Ein ”Innen“ und

”Außen“ gibt es nicht mehr: Externe Inhalte von ”Außen“ werden aggregiert und in-

nerhalb einer pers¨

onlichen Arbeitsumgebung verf¨

ugbar gemacht. Vom Benutzer selbst

erstellte Inhalte sind sofort f¨

ur alle verf¨

ugbar. Die Netzstrukturen des Webs erm¨

oglicht

somit ein kooperatives Publizieren und eine semantische Verflechtung. Aus technischer

Sicht werden hierzu bestimmte standardisierte technische Funktionen – Trackbacks,

Pingbacks und Permalinks:

Trackbacks Als Trackback bezeichnet man eine Funktion, mit der sich Weblogs gegen-

seitig ¨

uber Reaktionen und Kommentare auf Eintr¨

age untereinander austauschen

k¨

onnen. Hierdurch entstehen unter anderem die wichtigen und typischen sozia-

len und semantischen Verlinkungen und Interaktionen der Blogosph¨

are: Blogger

k¨

onnen sich in ihren eigenen Weblogs direkt auf Beitr¨

age anderer beziehen, was

als Reaktion direkt am Ausgangsbeitrag sichtbar wird. Somit ist die direkte Res-

ponsivit¨

at von Trackbacks ein charakteristisches Element vieler Blogs.

Pingbacks Pingbacks funktionieren analog zu Trackbacks. Mit dem Unterschied, dass

alle in einem Beitrag aufgef¨

uhrten Links automatisch angepingt, also benachrich-

tigt werden. Hinter den Ping-Links m¨

ussen Pingback-f¨

ahige Server stehen, um das

2. Beschreibung des Problembereichs und der Einflussfaktoren

Signal empfangen und verarbeiten k¨

onnen, um ihrerseits eine Verlinkung vorneh-

men zu k¨

onnen. ¨

Ublich ist auch der Einsatz von Pingbacks an Weblog-Portalen,

um die Beitr¨

age zu verbreiten oder zu vernetzen.

Permalinks Lange Zeit waren Weblogs wie Webseiten meist nur als solche referenzier-

bar, so dass verlinkte Beitr¨

age immer tiefer auf eine Seite nach unten wanderten

oder durch nachfolgende ersetzt wurden. Permalinks bezeichnen Verweise auf ei-

ne Webseite oder einen Artikel, die f¨

ur einen m¨

oglichst langen Zeitraum g¨

ultig

bleiben. Diese Links werden meist von Weblogsystemen nach einem bestimmten

Muster automatisch erstellt und den neuen Beitr¨

agen zugewiesen.

Verbreitung und Verdichtung von Inhalten Durch die st¨

andig zunehmende Zahl au-

tonomer Inhalte-Anbieter im Internet und die damit einhergehende Dezentralisierung

von Informationen bedarf es alltagstauglicher Technologien, um Inhalte menschen- und

maschinenlesbar auszuzeichnen und um sie serverseitig auf Portalen oder clientseitig

in sog. Newsreadern individuell zusammenf¨

uhren zu k¨

onnen. Die L¨

osung ist ein stan-

dardisiertes, XML-basiertes Datenformat RSS (Real Simple Syndication), das Anbieter

zus¨

atzlich zum Inhalt vorhalten k¨

onnen: ”RSS (which stands for RDF Site Summary,

but often refered to as Really Simple Syndication) is a computer-generated data-file for-

mat that sites use to communicate their contents to other sites and applications. Using

a really simple definition structure (thus the name,) RSS makes it easy for developers

to extract and integrate data from other sources into their own“ [Spo07].

RSS oder auch Atom-Feeds sind XML-basierte Metadatenformate, die sich besonders

gut zur Syndizierung73 von Micro Content (also kleinsten Informationseinheiten) eig-

nen. Beide werden serverseitig in Form eines Daten-Feeds ver¨

offentlicht, um clientseitig

uberwacht zu werden.

Durch ihr maschinenlesbares Format k¨

onnen RSS-Daten automatisch weiterverarbeitet,

gefiltert, sortiert und in andere Umgebungen integriert werden. Beispielsweise bieten

Suchdienste darauf basierend neu zusammengesetzte RSS-Feeds zu einem bestimmten

Stichwort an, die automatisch bei neuen oder ge¨

anderten Beitr¨

agen aktualisiert wer-

den, und somit bedeutend aktueller sind als klassische Suchdienste, die mit Hilfe von

Webcrawlern Webseiten zun¨

achst durchsuchen und analysieren m¨

ussen.

Am H¨

aufigsten findet die Syndikation ihre Anwendung aber in der Aggregation, also

in der Sammlung von Feeds in einer daf¨

ur spezialisierten Anwendung74. Somit kann eine

große Anzahl von sich ¨

andernden Webseiten zentral und automatisiert verfolgt werden.

2.3.3.2. Mash-Ups mit offenen APIs und Web-Services

Ein Kennzeichen des Web 2.0 ist die Verbreitung von Teilfunktionalit¨

at komplexerer

(Web-)Anwendungen oder auch einzelnen Diensten als leichtgewichtige Web-Applikation

auf Basis von Standards wie Web-Services ¨

uber SOAP (vgl. Abschnitt 4.1.1.3). Software

as a Service (kurz: SaaS) heißt dieses neue Konzept, bei dem es sich – der Name sagt

73Syndikation bezeichnet die ¨

Uberlassung lizensierter Inhalte zur Weiterverwendung.

74Aggregatoren oder News- bzw. Feedreader genannt.

2.3. Neue technologische und inhaltliche Trends im World Wide Web

es schon – also nicht um eine neue Software-Kategorie geht, sondern vielmehr um die

Bereitstellung bekannter Funktionalit¨

at.

In Unternehmenskontexten liegt bei der Nutzung von SaaS der Hauptvorteil darin, auf

sich schnell ¨

andernde Gesch¨

aftsprozesse entsprechend flexibel reagieren und ben¨

otigte

neue Funktionen schnell zur Verf¨

ugung zu haben. Aber nicht nur professionelle Nut-

zer und Firmenkunden k¨

onnen von diesen Diensten profitieren: Durch die Einbindung

von Online-Werbung und Affilitate-Programmen auf der eigenen Webseite kann auch

der ”einfache Internetanwender“ die Angebote von Google, Amazon, ebay und Co. als

Verdienstm¨

oglichkeit nutzen. Implementierungen dieser Schnittstellen werden von den

Dienste-Anbietern meistens oft auch in mehreren Programmiersprachen bereitgestellt,

damit der Kunde die Funktion in eigenen Anwendungen nutzen kann75.

Von einem Mashup76 spricht man, wenn zwei oder auch oft mehrere Datenquellen

externer Anbieter ¨

uber offene Schnittstellen auf einer Webseite zusammengebracht wer-

den. Andere Methoden der Einbindung sind RSS-Feeds oder Javascript. Der Anwen-

dungsbereich bei Mashups liegt also in der Entwicklung neuer Dienste durch die Zu-

sammenf¨

uhrung und nahtlose (Re-)Kombination bereits bestehender Inhalte anderer

Anbieter ¨

uber offene Schnittstellen (vgl. [Alb07], S. 133)77. Das Prinzip der Verdichtung

von Informationen durch Kontextualisierung findet auch hier Anwendung, und so werden

Mashups zu einem der wichtigsten Merkmale des Web 2.0.

2.3.3.3. Rich Client Applications

Im Laufe der letzten zehn Jahre ist die Anzahl der Techniken, die das Web dynamischer

machen sollen, stetig gestiegen. Anders als dynamisches HTML (DHTML) und Flash,

welches die Darstellung von Webseiten beleben soll, setzt AJAX (kurz f¨

ur: Asynchronous

Javascript And XML) bei der Kommunikation zwischen Browser und Webserver an und

tauscht zwischen ihnen asynchron XML-Nachrichten aus. AJAX kann immer an den

Stellen eingesetzt werden, wenn die Verarbeitungslogik von Benutzereingaben nicht auf

zu große Datenmengen oder zu komplexe Funktionen zugreifen muss. Effektiv ist es also

vor allem f¨

ur komfortable Web-Anwendungen mit einem hohen Interaktionsgrad. Der

Browser schickt die eingegebenen Daten im Hintergrund an den Server, ohne Zutun

des Benutzers. Im Gegensatz zum klassischen Ansatz, der erst auf ein ”Submit“ des

Formulars die Daten an den Server sendet. Dieser verarbeitet die Daten und schickt eine

Nachricht, die das Ergebnis der aufw¨

andigen Pr¨

ufung enth¨

alt, an den Browser zur¨

uck.

Die f¨

ur dieses Vorgehen angewendeten Technologien gibt es seit einigen Jahren78. Neu

75Auf das Konzept der Funktionsintegration wird im Abschnitt 4.1.1.3 noch einmal detaillierter einge-

gangen.

76Der Begriff Mashup kommt urspr¨

unglich aus der Musik und bezieht sich auf die Mischung der Musik

eines Songs mit dem Gesang eines anderen Songs, um daraus einen neuen Song zu produzieren

(vgl. [Alb07], S. 132).

77Sofern die Datenstr¨

ome zug¨

anglich, verwertbar und lizenzrechtlich verwendbar sind.

78Im Einzelnen handelt es sich um (vgl. [GGA06], S. 5): (1) standardgerechte Pr¨

asentation mit XHTML

und CSS, (2) dynamische Anzeigen und Interaktivit¨

at mittels des Document Object Model, kurz

DOM, (3) Datenaustausch und -manipulation mit XML und XSLT, (4) asynchrone Datenabfra-

ge unter der Verwendung des XMLHttpRequest-Objektes oder XMLHTTP sowie dem Bindeglied

Javascript.

2. Beschreibung des Problembereichs und der Einflussfaktoren

ist allenfalls das breite Verst¨

andnis bei Entwicklern, dass in komfortablen Applikationen

die Kommunikation zwischen Browser und Server nicht zwangsl¨

aufig auf benutzeraus-

gel¨

oste Ereignisse beschr¨

ankt ist. Durch diesen Paradigmenwechsel gleicht sich die Be-

dienbarkeit von Web-Anwendungen immer mehr dem Verhalten ”nativer“ Applikationen

an79. Weiterhin tr¨

agt die Verbreitung von AJAX zum Entstehen besserer Bibliotheken

sowohl auf Server- als auch auf Client-Seite bei, die ihrerseits die Entwicklung komfor-

tabler Anwendungen einfacher machen.

2.3.4. Die Auswirkungen des Web 2.0 auf das E-Learning

Das Web 2.0 stellt einen grunds¨

atzlichen Wandel in der Wahrnehmung und in der Nut-

zung des Internets dar, der zum einen f¨

ur die Planung und Konzeption des didakti-

schen Designs von E-Learning bedeutsam ist, zum anderen auch Ver¨

anderungen an der

technischen Konzeption und am Aufbau von virtuellen Lernumgebungen impliziert. Die

Aufweichung der Grenzen zwischen Autoren und Konsumenten, zwischen der Zentra-

lisierung und Dezentralisierung von Inhalten und Diensten sowie die ¨

Offnung von Pri-

vatsph¨

aren bedeuten analoge Ver¨

anderungen f¨

ur die Grenzen des klassischen E-Learnings

(vgl. [Ker07]):

Lerner werden zu Mitautoren von Lernangeboten. In vielen virtuellen Lernumgebun-

gen wurde bei der Umsetzung die Wissensbildung nur als Rezeptionsprozess be-

griffen, als Folge von Faktenlernen und Routinen (vgl. [Man04], S. 19). Die klas-

sische Rolleneinteilung erlaubt es nur dem Autor/Tutor bzw. didaktischen De-

signer, Lernmaterialien aufzubereiten und einzustellen80. Mit neuen Werkzeugen

wie kooperativen Wissensr¨

aumen, Wikis, Annotationen an und in Informationsob-

jekten81 und Social Bookmarks k¨

onnen Lernende selbst die Lerninhalte aktiv mit

gestalten und ihre Lernwege durch eigene semantische Verkn¨

upfungen strukturie-

ren, diese mit anderen Kommilitonen austauschen und diskutieren. Dadurch kann

ein neuartiger komplexer, vernetzter Umgang mit Informationen und darauf auf-

bauendem Wissen ebenso erlernt werden, wie die kritische, wertende Betrachtung

von Informationen und die Akzeptanz unterschiedlicher Sichtweisen auf Themen

und verschiedene Weltanschauungen (vgl. [Erp06], S. 20ff.).

Lernen wird ubiquit¨

ar, Lernumgebungen mobil. Notebook-Universit¨

aten82 bieten

Infrastrukturen, in denen mobile Endger¨

ate als Wissenswerkzeuge eine ”wirkli-

che“ Vernetzung der Lernorte auf dem Campus (on campus) und außerhalb des

”Basically, what AJAX means is “Javascript now works”. And that in turn means that web-based

applications can now be made to work much more like desktop ones“ Paul Graham, November 2005.

80Und dies geschah meist auch noch ohne Ber¨

ucksichtigung individueller Lernerinteressen und statisch

mit einer einseitigen Sichtweise (vgl. [Erp06], S. 20ff.).

81Annotationen k¨

onnen sich dabei nicht nur auf reinen Text beziehen, wie z. B. ein Kommentar in

einem Weblog, sondern auch direkt auf Bild- oder Videoausschnitte wie bspw. bei dem Fotodienst

http://www.flickr.com.

82Eine ”[. . . ] Organisationsform der Hochschule, in der der Einsatz mobiler Rechner sowie die verst¨

arkte

Nutzung moderner Kommunikationstechniken und -m¨

oglichkeiten sowohl auf Seite der Lehrenden

als auch auf Seiten der Studierenden integrativer Bestandteil der allt¨

aglichen Ausbildung ist. In

Abgrenzung zum Begriff der Virtuellen Universit¨

at zielt die Notebook-University prim¨

ar auf die

mobile (oder ubiquit¨

are) Nutzung moderner Informations- und Kommunikationstechnologien in

Pr¨

asenzhochschulen [. . . ]“ ab (vgl. [Bau03a], S. 35ff.).

2.3. Neue technologische und inhaltliche Trends im World Wide Web

Campus (off campus) erlauben. Viele Lernaktivit¨

aten sind daher nicht mehr an

einen festen Lernort gekoppelt, sondern k¨

onnen bspw. im Seminarraum, in der

Mensa/Cafeteria, im Praktikumsbetrieb, vom Wohnheim oder zu Hause aus und

sogar unterwegs auf dem Weg zur Uni oder ins Wochenende via iPod, Handy oder

Notebook stattfinden (vgl. [Ker04b]). Die durchg¨

angige Verf¨

ugbarkeit digitaler In-

formationen an allen Orten, an denen Lehrende und Lernende mit Wissen arbeiten,

ist dadurch m¨

oglich (Ubiquit¨

at).

Lernen wird zu einer ¨

offentlichen Aktivit¨

at. In konstruktivistisch gepr¨

agten Lernan-

s¨

atzen steht nicht mehr der instruierende Lehrende im Vordergrund, sondern der

aktiv Lernende. Dieser verharrt nicht mehr in einer rezeptiven Lernhaltung, son-

dern ist maßgeblich an der Steuerung des Lerngeschehens durch Aktivit¨

aten be-

teiligt, in denen gleichzeitig Leistungen erbracht werden, die ¨

offentlich sichtbar

sind (vgl. hierzu [Ede00], S. 287). Soziale Software erm¨

oglicht in diesem Kontext

offentlich nachvollziehbare Interaktionen ihrer Benutzer, wie die Ver¨

offentlichung

von Informationen, Informationsmanagement und Austausch von Inhalten auf ko-

operativen Wegen (bspw. ¨

uber Diskussionsbeitr¨

age, Portfolios, Beitr¨

age in Weblogs

oder Wikis; vgl. [Ric06], S. 8).

Im Folgenden soll kurz auf die Potenziale sozialer Software aus didaktischer Sicht einge-

gangen werden, bevor der Einfluss des Web 2.0 auf die technische Umsetzung virtueller

Lernumgebungen skizziert wird.

2.3.4.1. Potenziale sozialer Software f¨

ur das E-Learning

Das Web 2.0 bietet Potenziale f¨

ur das Lernen und den Kompetenzerwerb. Schmidt nennt

in [Sch06] dazu drei wichtige Aspekte:

1. Auf- und Ausbau eines pers¨

onlichen Informationsmanagements: Informationen

und Wissen k¨

onnen produziert und rezipiert, gesammelt und semantisch neu struk-

turiert werden.

2. Auf- und Ausbau eines pers¨

onlichen Beziehungsmanagements: Zu anderen Wissen-

str¨

agern k¨

onnen Kontakte ¨

uber ein soziales Netz aufgebaut und nachhaltig gepflegt

werden.

3. Auf- und Ausbau eines Identit¨

atsmanagements. Durch das Publizieren von eigenen

Inhalten und Ansichten und dem Auseinandersetzen mit dem kritischen Feedback

der Leserschaft kann man mit der Zeit eine eigene digitale Identit¨

at/Reputation

entwickeln. Dazu geh¨

ort auch die Reflexion seiner selbst.

Genau diese drei Begriffe stehen auch f¨

ur ”die Auseinandersetzung des Einzelnen mit

der gegenst¨

andlichen sozialen Umwelt ebenso wie mit sich selbst, dem individuellen

Wissen und K¨

onnen und den eigenen Einstellungen und Werten“ ( [Rei07], S. 11), was

letztendlich die Voraussetzung daf¨

ur ist, Kompetenzen zu entwickeln, die zum Handeln

und Probleml¨

osen bef¨

ahigen (vgl. ebd.).

Unter diesen Aspekten werden im Folgenden die Potenziale einzelner Werkzeuge und

Dienste f¨

ur das E-Learning beschrieben.

2. Beschreibung des Problembereichs und der Einflussfaktoren

Weblogs Weblogs sind die derzeit im Web am weitesten verbreitete und angenommene

Technologie, mit der aktives Schreiben und Lesen praktiziert wird. In einer Lernumge-

bung ergeben sich durch Weblogs Interaktions- und Kommunikationsm¨

oglichkeiten zwi-

schen Lernenden untereinander sowie zwischen Lehrenden und Lernenden (vgl. [Ric06],

S. 8). Sie erm¨

oglichen ein selbst¨

andiges, problemorientiertes, exploratives als auch akti-

ves und kooperatives Lernen und bieten den Lehrenden eine transparente M¨

oglichkeit

der Betreuung. F¨

ur den didaktischen Einsatz sehen Beuschel und Draheim verschiedene

Medienmerkmale eines Weblogs, die bei richtiger Anleitung zum Tragen kommen k¨

onnen

(vgl. [BD05], S. 228ff.):

Explorationsmedium Die hochgradige Vernetztheit der Blogosph¨

are bietet f¨

ur die Online-

Recherche ein Potenzial f¨

ur selbstorganisiertes und exploratives Lernen. Des Wei-

teren kann die kompetente Einsch¨

atzung der Glaubw¨

urdigkeit einer Information

als wichtiger Bestandteil von Medienkompetenz erachtet werden.

Reflexives Medium Informationen in der Blogosph¨

are sind direkt Kritiken, Verbesse-

rungen und Erweiterungen ausgesetzt, welche die Inhalte ver¨

andern, aktualisieren

oder erweitern k¨

onnen. Dadurch wird eine diskursive Art des Schreibens gef¨

ordert

und ausgebildet; Studierende kommentieren die Beitr¨

age anderer und k¨

onnen ler-

nen Kritik anzunehmen (vgl. [Ora02])83.

Soziales Medium Erfahrungen der Studierenden aus Diskussionen in Weblogs k¨

onnen

das Verst¨

andnis f¨

ur die soziale Konstruktion von Informationen unterst¨

utzen (vgl.

[Ora03]).

Medium subjektiver Entwicklung Beim Bloggen kann die F¨

ahigkeit zur Selbstorgani-

sation und das Lernmanagement gest¨

arkt und ein kompetente Umgang mit Tex-

ten und fachlichen Ausdr¨

ucken erlernt werden. Schreibblockaden k¨

onnen abgebaut

werden (vgl. [BD05], S. 229).

In Lernumgebungen eingesetzt, k¨

onnen Weblogs verschiedenste Unterst¨

utzungsfunktio-

nen ¨

ubernehmen. Richardson nennt in [Ric06], S. 40ff., m¨

ogliche Einsatzgebiete, wie zum

Beispiel als reflexives Journal f¨

ur Lehrer zur Kommunikation, f¨

ur Feedbacks, sowie zur

Strukturierung und Reflexion von Lerneinheiten. Weiterhin schl¨

agt er Weblogs f¨

ur Klas-

senr¨

aume, beziehungsweise Kursgruppen oder Projektgruppen vor, welche f¨

ur die Orga-

nisation des Unterrichtsablaufs, zur Gruppenkommunikation und Gruppenarbeit dienen

k¨

onnen. Zus¨

atzlich empfiehlt Richardson individuelle Weblogs f¨

ur jeden Lernenden, f¨

eigenst¨

andige Lernprozesse, Ablage und Arbeitsumgebung (vgl. [Ric06], S. 40ff.). Eine

dar¨

uber hinausgehende ¨

Ubersicht der Einsatzfelder von Weblogs in der Bildung stellt

Leslie in [Les03] vor.

83In diesem Zusammenhang sieht R¨

osch (zitiert in [K¨

os05]) Potenziale von Weblogs f¨

ur wissenschaftli-

ches Arbeiten, n¨

amlich 1) als Quelle f¨

ur neue Ideen, 2) als Informationsfilter, 3) als Verbreitungsmedi-

um und 4) als Testumgebung, um f¨

ur Thesen und Theorien die Reaktionen der Scientific Community

zu bekommen. Die dabei entstehende ”echtere, spontanere und unmittelbarere Wissenschaftskom-

munikation“ (Baumgartner in [K¨

os05]) kann dabei Entwicklungsprozesse vorantreiben. Hemmend

kann sich allerdings die Publikation unsicherer Ergebnisse in einem ¨

offentlichen Raum auswirken:

Wissenschaftler publizieren in der Regel erst dann, wenn sichere Ergebnisse vorliegen.

2.3. Neue technologische und inhaltliche Trends im World Wide Web

Wikis F¨

ur einen Einsatz in virtuellen Lernumgebungen bieten Wikis zwei vorrangige

Funktionen. Zum einen k¨

onnen sie als Informationsquelle dienen, zum anderen als Orte

kooperativer Wissensarbeit (vgl. [Mit06], S. 119).

Im Internet existiert eine Vielzahl virtueller Enzyklop¨

adien, die bei der Recherche in

einem Probleml¨

oseprozess als wichtige Informationsquelle dienen k¨

onnen. Ihr Einsatz

ist jedoch im Bildungsbereich umstritten, da Inhalte nicht zwangsl¨

aufig von renom-

mierten Experten verfasst wurden und eine nachvollziehbare Quelle nicht grunds¨

atzlich

gegeben ist84. Unter dem Gesichtspunkt des kritischen und reflexiven Umgangs mit In-

formationen k¨

onnen Lernende jedoch aktiv an Wikis teilnehmen und ihren Beitrag zur

Qualit¨

atssicherung durch Verbesserungen leisten. Ab diesem Punkt nehmen sie selber an

offentlichen Kommunikationsprozessen teil und k¨

onnen wertvolle Erfahrungen durch In-

teraktion mit der dahinter stehenden Gemeinschaft erlangen. Sie sind ihrerseits Lob und

Kritik ausgesetzt und erlangen in Analogie zu den Weblogs dadurch soziale Kompetenz.

Als Orte kooperativer Wissensarbeit kann ein Wiki eine Plattform zur Ideenfindung,

f¨

ur Gruppenarbeiten, Archivierung oder Pr¨

asentation von Ergebnissen darstellen. Dabei

sind selbst Kooperationen mit anderen Kursgruppen oder Lernumgebungen m¨

oglich (vgl.

[Mit06], S. 125).

F¨

ur den didaktischen Einsatz sehen Thelen und Gruber folgende Merkmale (vgl.

[TG03], S. 359f.):

F¨

orderung eines wissenschaftlichen Schreibstils Die aktive und kritische Auseinander-

setzung mit bereits erstellten, wissenschaftlich gut formulierten Texten in einer

Umgebung von kritisch korrigierenden Autoren kann den eigenen Schreibstil posi-

tiv beeinflussen.

Schaffung eines ”Mikrokosmos“ f¨

ur wissenschaftliche Prozesse Wissenschaftliches

Arbeiten ist grunds¨

atzlich ein kooperativer, sozialer Prozess. Wiki-Technologien

k¨

onnen hierbei einen Ort f¨

ur wissenschaftliches, kooperatives Arbeiten innerhalb

einer Lernumgebung darstellen.

Revisionskontrolle von Arbeitsgruppen Das kooperative Verfassen wissenschaftlicher

Arbeiten kann innerhalb eines Wikis strukturiert und dokumentiert ablaufen, da

Ver¨

anderungen anhand von Revisionskontrollen des Wikis aufgezeichnet werden.

Lehrende und Lernende k¨

onnen dadurch Gedankeng¨

ange sowie gest¨

orte Arbeits-

abl¨

aufe transparent nachvollziehen.

Kooperationen ¨

uber Distanzen Wikis eignen sich f¨

ur den Einsatz bei Seminar- oder

Hausarbeiten, da kooperatives Arbeiten auch ortsunabh¨

angig realisiert werden

kann. Dabei verlieren Hausarbeiten ihren isolierenden Charakter und Hypothesen

k¨

onnen schon fr¨

uhzeitig in der Gemeinschaft diskutiert werden.

84Mitchell stellt beispielhaft die Frage, ob man Wikipedia vertrauen kann und ob Wikipedia als legitime

Quelle innerhalb wissenschaftlicher Ausarbeitungen akzeptiert werden kann (vgl. [Mit06], S. 121).

Thelen und Gruber merken hierzu kritisch an, dass durch das gemeinschaftliche Editieren in Wikis

wichtige Metainformationen ¨

uber die Autoren verloren gingen, die f¨

ur ein kritisches Interpretieren

der Aussagen vonn¨

oten sind (vgl. [TG03], S. 358).

2. Beschreibung des Problembereichs und der Einflussfaktoren

Zusammenfassend bieten Wikis Unterst¨

utzungsfunktionen f¨

ur ein kooperatives, selbst-

gesteuertes, aktives und kritisches Lernen. Dabei k¨

onnen Erkenntnisse strukturiert und

wissenschaftlich ¨

uberarbeitet dargestellt werden, wobei eine kritische Betrachtung und

die Editierm¨

oglichkeiten einer dahinter stehenden Gemeinschaft Qualit¨

atsaspekte rea-

lisieren. Wikis sind dazu geeignet, erarbeitete Informationen aufzubewahren, die durch

eine Gemeinschaft aktuell gehalten und erweitert werden k¨

onnen.

Weitere Technologien Richardson nennt in [Ric06], S. 8f., weitere Web 2.0-Technolo-

gien, die Potenziale f¨

ur den Einsatz in der Lehre haben, wie Tagging/Social Bookmarking

und Podcasts.

Das semantische Strukturieren von Inhalten durch Verschlagwortung f¨

ordert beim

Lernenden ein zielgerichtetes, selbstorganisiertes Lernen. Weiterhin haben Lehrende

die M¨

oglichkeit, Lernwege anhand der vergebenen Schlagworte nachzuvollziehen (vgl.

[Ric06], S. 93).

Werden f¨

ur Lerngemeinschaften bestimmte Indizierungskonventionen vereinbart, kann

innerhalb vernetzter Lernumgebungen eine kooperativ gepflegte Kollektion hochgra-

dig strukturierter und indizierter Verweise auf interne und externe Informationsquel-

len entstehen, die ¨

uber Newsfeeds strukturiert abrufbar sind. Hier¨

uber k¨

onnen koope-

rative Informationsrecherchen und Informationstausch, kombiniert mit Speicher- und

Exportm¨

oglichkeiten realisiert werden (vgl. [Ric06], S. 98)85.

Dar¨

uber hinaus wird das Auffinden und Herstellen sozialer Kontakte zwischen Ler-

nenden mit gleicher Interessenbasis deutlich vereinfacht. Baumgartner sieht diesbzgl.

bei großen Bildungsinstituten mit mehreren tausend Eingeschriebenen eine wertvolle

Unterst¨

utzungsmaßnahme, da Kontakte zwischen Personen mit gleich gelagerten Inte-

ressen am ganzen (virtuellen) Campus – unabh¨

angig von den gerade besuchten Kursen

– hergestellt werden k¨

onnen (vgl. [Bau06c]).

Audio- und Video-Podcasts werden in der Lehre bereits h¨

aufiger eingesetzt, meist in

Form von Vorlesungsaufzeichnungen (vgl. [Lit07]). Die Treiber daf¨

ur sind einerseits die

wachsenden Studierendenzahlen und die daraus resultierenden ¨

uberf¨

ullten H¨

ors¨

ale, an-

dererseits die Nachfrage nach ortsunabh¨

angigen und zeitlich flexiblen Blended-Learning-

Arrangements, die auf Medien- und Methodenmixen beruhen (vgl. [AWKL06]). Bekannte

Beispiele sind hierf¨

ur die Podcasting-Plattform f¨

ur deutsche Hochschulen podcampus.de

und iTunes U, ein Bereich im iTunes Store von Apple, in dem Vorlesungsaufzeichnun-

gen und weitere Inhalte wie Sprachkurse, Labordemonstrationen bis hin zu F¨

uhrungen

uber das Hochschulgel¨

ande kostenlos von bekannten US-Universit¨

aten zur Verf¨

ugung

gestellt werden. Gegen¨

uber der reinen Nutzung von Podcasts als weiteren Distributions-

weg f¨

ur Lerninhalte gibt es – wie bei den Weblogs – auch didaktische Ans¨

atze, in denen

Studierende zur Produktion eigener Podcasts motiviert werden (vgl. [Lit07]).

85Der freie Internet-Dienst CiteULike.org hilft bspw. in diesem Zusammenhang Akademikern weltweit,

ihre gelesenen wissenschaftlichen Artikel mit anderen zu teilen, zu speichern und zu organisieren.

Weitere Beispiele sind die Social Bookmarking-Dienste der University of Pennsylvania (http://tags.

library.upenn.edu/) und der Harvard Law School (http://h2obeta.law.harvard.edu/home.do).

Letzter Zugriff: 31.07.2008.

2.3. Neue technologische und inhaltliche Trends im World Wide Web

2.3.4.2. Technische Implikationen auf virtuelle Lernumgebungen

Die Ber¨

ucksichtigung von modernen Technologien und neuem Nutzerverhalten des Web

2.0 aus didaktischer Sicht hat folglich auch große technische Implikationen auf die Kon-

zeption und Entwicklung virtueller Lernumgebungen, die in diesem Abschnitt skizziert

werden sollen.

Benutzergenerierte Inhalte und Interaktion Durch die Integration von Werkzeugen

wie Weblogs und Wikis in virtuellen Lernumgebungen sowie M¨

oglichkeiten, fremde In-

halte zusammen mit eigenen Materialien in selbstorganisierten Wissensr¨

aumen struktu-

rieren zu k¨

onnen, k¨

onnen insbesondere konstruktivistische Ans¨

atze unterst¨

utzt werden,

die das Lernen wieder st¨

arker als Produktions- und nicht als Rezeptionsprozess begreifen.

Dazu m¨

ussen Erstellungs- und Verwaltungsfunktionen sowohl f¨

ur klassische, durch Meta-

daten formal strukturierte und standardisierte Lernobjekte angeboten werden als auch

f¨

ur benutzergenerierte Inhalte mit niedriger struktureller Komplexit¨

at (Microcontent,

s. [Ale06], [Ker07]), wie Weblog-Posts, Wiki-Eintr¨

age oder kommentierte Hyperlinks zu

externen Inhalten. Zus¨

atzlich bedarf es einem Angebot von Medienfunktionen86 zur In-

teraktion sowohl mit klassischen Lernobjekten als auch mit Microcontent, um neben

darstellenden und problemorientierten Lehrformen auch ein selbstorganisiertes Lernen

nach konstruktivistischen Ans¨

atzen unterst¨

utzen zu k¨

onnen (aktives bzw. ko-aktives Ler-

nen, vgl. hierzu [Hes04] und [Kei07]).

Eine werkzeug¨

ubergreifende freie Kombinierbarkeit und Wiederverwendbarkeit von

Inhalten und somit auch eine durchg¨

angige und medienbruchfreie Verf¨

ugbarkeit w¨

ahrend

des Lernprozesses innerhalb einer virtuellen Lernumgebung impliziert eine konzeptionel-

le und technologische Generalisierung als Informationsobjekte, unabh¨

angig von Format,

Herkunft und Granularit¨

at. Zack beschreibt in [Zac99], S. 48, ein solches Konzept und

spricht dabei von einer so genannten knowledge unit ”[. . . ] as formally defined, atomic

packet of knowledge that can be labeled, indexed, stored, retrieved and manipulated.

The format, size, and content of knowledge units may vary, depending on the type of ex-

plicit knowledge being stored and the context of its use.“ Seine Definition ber¨

ucksichtigt

dabei schon die Benutzung von Informationsobjekten in verschiedenen Kontexten, was

ein weiteres wichtiges Moment der semantischen Interoperabilit¨

at ist: Durch eine strikte

Trennung von Attributen und Inhalten kann das MVC-Entwicklungsmuster (Model View

Controller, vgl. [BMRS96]) auf Informationsobjekte respektive Strukturen von Informa-

tionsobjekten angewendet werden, was eine Wiederverwendung bzw. Weiterbearbeitung

von Inhalten in verschiedenen Sichten mit jeweils eigenen responsiven Eigenschaften

erm¨

oglicht (vgl. [Kei07]). Eine Sicht wertet dabei jeweils unterschiedliche Attribute ei-

nes Objekts aus, ¨

andert aber nicht das eigentliche Objekt.

Ein Beispiel daf¨

ur findet sich in [RHS05]: Multimediale Lerninhalte des virtuellen Stu-

dienfachs VORMS87 k¨

onnen durch Umsetzung dieses Konzeptes lernnetz¨

ubergreifend

86Hampel unterscheidet diesbzgl. in [Ham02], S. 44ff. vier individuelle (Erzeugen, L¨

oschen, Arrangieren

und Verkn¨

upfen) und drei kooperative Medienfunktionen (¨

Ubertragen, Zugreifen und Synchronisie-

ren).

87Das virtuelle Studienfach Operations Research/Management Science (VORMS) wurde 2000 als Ver-

bundprojekt im F¨

orderprogramm Neue Medien in der Bildung des BMBF initiiert. Sieben Lehrst¨

uhle

2. Beschreibung des Problembereichs und der Einflussfaktoren

sowohl miteinander als auch mit beliebigen benutzergenerierten Inhalten kombiniert

werden. Spezialisierte Lernplattformen und Werkzeuge beschreiben verschiedene Sich-

ten auf diese Informationen. Die Losl¨

osung von den durch LMML (Learning Material

Markup Language, vgl. [SF01]) und LOM erzeugten – f¨

ur die Erstellung rein virtueller

Kurse durchaus notwendigen – semantischen Abh¨

angigkeiten und Hierarchien ist dabei

eine grundlegende Voraussetzung f¨

ur die freie Kombinierbarkeit und Wiederverwend-

barkeit von Lernobjekten in selbstadministrierten virtuellen Wissensr¨

aumen unter dem

Blickwinkel des selbstorganisierten Lernens. Durch die Generalisierung als Informati-

onsobjekt konnten in diesem Fall verschiedene Aggregationsstufen von Lernnetzen sowie

benutzergenerierte Inhalte gleich behandelt und referenziert werden, was zu einer neuen

Qualit¨

at der semantischen Objektstrukturen und vielf¨

altigen Kommunikations- und In-

teraktionsmechanismen f¨

uhrte. Hierbei wurden Medienbr¨

uche zwischen Lernwerkzeugen

gezielt reduziert, indem Medien- und Kommunikationsfunktionen im Zuge der Genera-

lisierung direkt an Informationsobjekten verankert wurden (vgl. hierzu auch [SHB04]).

Auf diese Art und Weise sind synchrone wie asynchrone Interaktions- und Kommu-

nikationsmechanismen unmittelbar mit den semantischen Strukturen der im virtuellen

Studienfach VORMS eingesetzten Lernumgebungen verkn¨

upft und stehen nicht – wie

in den meisten Systemen als erhebliches Defizit empfunden – weitgehend isoliert neben

den eigentlichen Wissensstrukturen.

Offene Schnittstellen f¨

ur Werkzeuge und Inhalte Die heutige Nutzung des Webs als

Plattform basiert nicht mehr nur auf Web-Browsern, sondern auf vielen Diensten und

Praktiken, wie Peer-to-Peer-Netzwerke, spezielle Dienste f¨

ur Foto- und Videospeicherung

und -streaming, Chat und Videoconferencing, Web-Services, mobile Szenarios usw.

Um den Anspr¨

uchen der Benutzer gerecht zu werden, die ihre eigene Auswahl und

Konfiguration an generischen Werkzeugen f¨

ur ihre t¨

agliche Wissensarbeit nutzen – bspw.

zur Bearbeitung von Dokumenten, zur Kommunikation oder Kontaktpflege – sollte ei-

ne moderne Lernplattform nicht mehr als Insell¨

osung im Netz implementiert werden,

sondern offene Schnittstellen zu entsprechenden popul¨

aren Web-Diensten, Werkzeugen

und Endger¨

aten anbieten (vgl. [Wil06], [Ker07])88. Somit werden Benutzer in die Lage

versetzt, ihre eigene, ganz pers¨

onliche Lernumgebung (PLE, Personal Learning Environ-

ment, vgl. ebd.) aus den Bildungsangeboten, (Kommunikations-)Werkzeugen, Aggrega-

toren, Web-Diensten und Endger¨

aten zusammenzustellen und aufeinander abzustimmen.

Kerres schreibt dazu in [Ker07]: ”For the user, this personal learning environment is not

a separate space on the internet, it is an essential part of the users workspace. It should

be highly integrated with the users’ framework of tools for his/her personal use of the

internet“.

an sechs deutschen Hochschulen haben in der dreij¨

ahrigen Projektlaufzeit Lehrangebote mit verschie-

denen inhaltlichen Schwerpunkten gem¨

aß ihrer Kernkompetenz didaktisch und elektronisch aufbe-

reitet: http://www.vorms.org.

”Die Aufforderung, mit einem zum Beispiel in der Lernplattform inkludierten Diskussionsforum, Blog-

, Chat- oder Konferenztool zu arbeiten, erscheint so als ob wir von den Studierenden fordern w¨

urden,

sie m¨

ussten ihre Mitschriften auf kariertem Papier mit Bleistiften der St¨

arke HB mitschreiben und

anschließend in Ordnern der Marke X archivieren“ [Ker06].

2.4. Zusammenfassung

Beispielhaft daf¨

ur ist die Kompatibilit¨

at von Podcasts mit portablen (videof¨

ahigen) Mu-

sikabspielger¨

aten und ihr bequemes Abonnement- und Auslieferungsmodell, das sich un-

ter dem Aspekt einer verbesserten Lernerzentrierung von der herk¨

ommlichen Bereitstel-

lung von Audio- und Videoinhalten in geschlossenen Plattformen deutlich unterscheidet

(vgl. [Lit07]).

Weitere hoch integrative Technologien, mit denen offene Lernumgebungen umgesetzt

werden k¨

onnen, sind bspw. die auf S. 54ff. vorgestellten RSS-Feeds, offene Program-

mierschnittstellen und Mashups. Bei der Zusammenstellung und Konfiguration einer

solchen pers¨

onlichen Lernumgebung kann der Benutzer dann Aggregations-Dienste oder

Browser-Erweiterungen zu Hilfe nehmen89.

Aus Sicht der Implementierung und Bereitstellung virtueller Lernumgebungen impli-

ziert dieser Ansatz einen Fokuswechsel weg vom Funktionsumfang einer Insell¨

osung hin

zu einer offenen Infrastruktur: ”A PLE is personally constructed and discovered – you

don’t provide a PLE like you provide the VLE. Its not a box. Working with PLEs is

about tailoring the infrastructure to be supportive“ [Wil06], vgl. hierzu auch [KS05a]

und [FM06]90.

Die hochintegrativen Technologien brauchen in einer solchen offenen Infrastruktur

nicht nur einseitig angeboten werden, sondern k¨

onnen genau so gut dazu genutzt werden,

externe Inhalte und Funktionen anderer Plattformen einzubinden und somit den Daten-

und Funktionsumfang virtueller Lernumgebungen zu erweitern. So k¨

onnen zum Bei-

spiel Schnittstellen zu externen Inhalten wie virtuellen Bibliotheken, digitalen Verlags-

archiven oder anderen Content-Repositories91 technisch umgesetzt werden (vgl. bspw.

[BHH+06]), ebenso wie Funktionen zur Hot-Spot-Annotation auf Bildern und Grafiken,

die von externen Plattformen via Mashup in die Infrastruktur eingebunden werden.

2.4. Zusammenfassung

Um den neuen Anforderungen der Wissensgesellschaft und des lebenslangen Lernens

– manifestiert durch Studienreformen, Internationalisierung, Qualit¨

atsentwicklung und

der Immatrikulation von Angeh¨

origen einer Generation, die mit neuen Medien und Tech-

nologien groß geworden ist (digital natives) – wirksam begegnen zu k¨

onnen, bedarf

es es eines soliden alltagstauglichen und breitenwirksamen Einsatz von computerun-

terst¨

utztem Lernen.

E-Learning birgt viele Potenziale f¨

ur die Vermittlung von Handlungskompetenz, ak-

tuellen Inhalten und problemorientierten Lernen. Insbesondere Web 2.0-Werkzeuge wie

Wikis, Blogs und soziale Netzwerke sind durch ihren Fokus auf Interaktivit¨

at und Par-

tizipation sowie auf das soziale Feedback geradezu pr¨

adestiniert f¨

ur informelles Lernen,

pers¨

onliche Wissensorganisation und kooperative Szenarien.

89Beispielsweise iGoogle (http://www.google.de/ig), suprglu.com oder greasepot.net.

90Feldstein pr¨

agte in der amerikanischen Szene den Begriff Learning Management Operation System

(LMOS) als Bezeichnung f¨

ur eine solche offene, technische Infrastruktur.

91So bietet beispielsweise das europ¨

aische Ariadne Knowledge Pool System, das auf einem Netzwerk von

verteilten Lernobjekt-Repositories mit Inhalten und Metadaten basiert (s. http://www.ariadne-eu.

org/), zu jedem ihrer Knoten synchrone und asynchrone SQI-Schnittstellen (Simple Query Interface)

an, zum Suchen und Auslesen von Inhalten. Der weltweite Pendant dazu ist das Global Learning

Objects Brokered Exchange (GLOBE, s. http://globe.edna.edu.au/).

2. Beschreibung des Problembereichs und der Einflussfaktoren

Die an vielen Universit¨

aten vorhandene, verteilte kooperative IT-Versorgung von Ler-

numgebungen und Basistechnologien stellt jedoch zumeist keine attraktive Infrastruktur

f¨

ur multimediales Lehren und Lernen dar: Dem zus¨

atzlichen Aufwand f¨

ur mehrfache

Datenerfassung in Kombination mit Kosten f¨

ur die Inhalteerstellung stehen oft nicht

gen¨

ugend Kosten- oder zumindest Zeiteinsparungen gegen¨

uber, um Dozierende zum

Einsatz der neuen Medien in der Lehre zu motivieren92. Medienbr¨

uche werden durch

monolithische Lernmanagementsysteme und propriet¨

are Applikationen eher erzwungen,

als das die einzelnen Lerninhalte durchg¨

angig und system¨

ubergreifend in Lernprozessen

verf¨

ugbar w¨

aren. Auch die Einbettung mediengest¨

utzter Lehr- und Lernprozesse in in-

stitutionale Kontexte wird durch propriet¨

are Schnittstellen erschwert, sodass dadurch

h¨

ohere Entwicklungs-, Wartungs- und Prozesskosten entstehen. Hier besteht Handlungs-

bedarf.

92Optimistische Sch¨

atzungen gingen 2004 davon aus, dass zu dem Zeitpunkt nur 5 % aller Hochschul-

lehrenden neue Medien in der Lehre einsetzen (vgl. [CB04], S. 10).

3. Terminologiebasierte Spezifizierung

von Lernumgebungen

Werden universit¨

are E-Learning-Werkzeuge individuell entwickelt, ist die Abstimmung

zwischen Anwendern, Didaktikern, Mediendesignern und Programmierern essenziell, um

ein gemeinsames Verst¨

andnis f¨

ur die Aufgabenstellung sicherzustellen. In Unterkapitel

1.3 wurde die Kommunikation zwischen den Projektbeteiligten jedoch als oftmals gest¨

ort

charakterisiert: Schwierig sind zum einen die unterschiedlichen Blickwinkel und Inten-

tionen von Begriffen und Konzepten, zum anderen der Bruch zwischen der pr¨

aformalen

Alltagssprache der Anwender und der zur Spezifikation h¨

aufig genutzten formalen k¨

unst-

lichen Sprachen und Diagrammmethoden.

In diesem Kapitel wird ein normsprachlicher Ansatz zur Spezifikation erarbeitet mit

dem Ziel, ein alltagstaugliches Werkzeug zur Anforderungsbeschreibung universit¨

arer

Lernumgebungen zu schaffen, das zur Verbesserung der Kommunikation beitr¨

agt und

mit dem dadurch zeitintensive prototypische Entwicklungen oder gar kostenintensive

Fehlentwicklungen deutlich reduziert werden k¨

onnen.

Zun¨

achst wird das Konzept der terminologiebasierten Softwareentwicklung eingef¨

uhrt

(3.1). Dazu wird die Problemstellung durch eine genauere Betrachtung m¨

oglicher Kom-

munikationsst¨

orungen konkretisiert und Normsprachen als ein Hilfsmittel vorgestellt, an

denen sich Kommunikation st¨

orungsfrei ausrichten kann. Dar¨

uber hinaus wird erl¨

autert,

wie eine Normsprache im Softwareentwicklungsprozess eingesetzt werden kann.

Im Abschnitt 3.2 wird die Wissensraummetapher als ein semantisches Bezugssystem

hergeleitet, dessen Konstrukte zur Beschreibung von Lern- und Arbeitsszenarien verwen-

det werden k¨

onnen. Es wird begr¨

undet, dass diese Metapher sowohl aus lerntheoretischer

als auch aus kognitionspsychologischer Sicht dazu geeignet ist.

Auf Basis der Wissensraummetapher wird in 3.3 der terminologiebasierte Ansatz

f¨

ur die objektorientierte Spezifikation von Schienmann (TAOS, vgl. [Sch95]) zur norm-

sprachlichen Beschreibung von Lern- und Arbeitsszenarien angewendet. Dazu wird eine

Terminologie von Begriffen vorgestellt, die neben den Konstrukten der Wissensraum-

metapher auch organisatorische und systemtechnische Konzepte umfasst. Auf dieser

Grundlage werden die zur Spezifizierung notwendigen Satzmuster konstruiert und ih-

re Anwendbarkeit zur Beschreibung statischer, funktionaler und dynamischer Aspekte

von Lernumgebungen demonstriert.

Das Kapitel schließt mit einer Zusammenfassung.

3. Terminologiebasierte Spezifizierung von Lernumgebungen

3.1. Terminologiebasierte Softwareentwicklung

Terminologiebasierung ist zu verstehen als eine Untersuchung nat¨

urlichsprachlicher ¨

Au-

ßerungen in Hinsicht auf ihre Intention oder Kommunikation im Anwendungsbereich.

Diese werden schrittweise und kontrolliert in intersubektiv begr¨

undete Aussagen auf

Basis einer normierten Fachsprache ¨

uberf¨

uhrt. Der wesentliche Punkt dabei ist, dass

informationsverarbeitende Handlungen im Anwendungssystem auf Fachbegriffen bzw.

Fachkonzepten basieren, die zum konstruierenden Bestand der Theorie eines Fachbe-

reichs geh¨

oren. Diese Fachbegriffe sind System-Designern und -Entwicklern nicht un-

mittelbar einsichtig, wohl aber dem Anwender aus dem Fachbereich, was einen sprach-

kritischen Rekonstruktionsprozess notwendig macht, der in der terminologiebasierten

Softwareentwicklung als Teil eines Entwicklungssystems verwaltet wird (vgl. [Ort95],

S. 148, [Sch97a], S. 11).

In diesem Abschnitt soll der terminologiebasierte Entwicklungsansatz n¨

aher erkl¨

art

werden. Zuerst werden jedoch die genannten Kommunikationsst¨

orungen n¨

aher spezifi-

ziert, um dadurch das Problemverst¨

andnis zu st¨

arken.

3.1.1. Effekte und Defekte nat¨

urlicher Sprachen

Das Ermitteln von Anforderungen, Zielen und Rahmenbedingungen, auf deren Grund-

lage das sp¨

atere System entwickelt wird, geschieht zumeist unter Zuhilfenahme von Er-

mittlungstechniken wie Interviews, Dokumentenanalyse und Beobachtungen etc. und

dem damit verbundenen Konsultieren von ”fachlich kompetenten Quellen“ (vgl. [Rup07],

S. 108)1. Neben weiteren Anforderungsquellen wie Dokumente und bereits existierende

Systeme, stellen diese Stakeholder2eine Quelle f¨

ur Aussagen ¨

uber das zu entwickelnde

System dar (vgl. [Poh07], S. 314).

Die Kommunikation zwischen Systemanalysten und Stakeholdern verl¨

auft meistens

nat¨

urlichsprachlich, da nat¨

urliche Sprachen den Befragten i. d. R. besser verst¨

andlich

sind als die formalen Diagramm- oder Beschreibungssprachen, die seitens der Software-

entwickler zur Spezifikation des Systems genutzt werden. Jedoch weisen nat¨

urliche Spra-

chen zwei grunds¨

atzliche Aspekte auf, die zum Teil große Abweichungen gegen¨

uber einer

pr¨

azisen, einfachen Formulierung von Aussagen bedingen: Spracheffekte und Sprachde-

fekte.

3.1.1.1. Sprachliche Effekte

Eine nat¨

urliche Sprache ist immer Ausdrucksmittel der pers¨

onlichen Wirklichkeit ei-

nes jeden Individuums. Ausgangspunkt daf¨

ur ist die Annahme, dass jeder Mensch die

Welt anders wahrnimmt (selektive Wahrnehmung). Bei sprachlichen und schriftlichen

Außerungen muss ein Individuum zun¨

achst geistig eine vollst¨

andige Repr¨

asentation f¨

1Mehr Informationen zu Methoden der Anforderungsermittlung und Erhebungstechniken sind zu fin-

den in [RR99], S. 82ff., [Sch02], S. 196ff., [Poh07], S. 323ff., [Tha02], S. 91ff. und [Rup07], S. 115ff.

”Many people and organizations are interested in the construction of a software system. We call these

stakeholders: The customer, the end users, the developers, the project manager, the maintainers,

and even those who market the system are a few examples“ [BCK03], S. 6.

3.1. Terminologiebasierte Softwareentwicklung

den zu ¨

außernden Aspekt auf Grundlage seiner pers¨

onlichen Wirklichkeit herstellen (Tie-

fenstruktur, vgl. [SOP01], S. 7). Ausgehend von dieser Repr¨

asentation bildet es dann

ein sprachliches Konstrukt (Oberfl¨

achenstruktur), welches es ¨

außert oder niederschreibt.

Dieses durchlief zu dem Zeitpunkt, an dem es ge¨

außert oder niedergeschrieben wird,

bereits ein oder mehrere Transformationsprozesse. So genannte Darstellungstransforma-

tionen werden durchgef¨

uhrt, wenn die pers¨

onliche Wirklichkeit mithilfe von Sprache

ausgedr¨

uckt wird (vgl. ebd.). Hierbei lassen sich drei verschiedene Transformations-

arten unterscheiden, durch die Informationsverluste oder Falschaussagen bei der An-

forderungserhebung entstehen k¨

onnen: Tilgung,Generalisierung und Verzerrung. Diese

Transformationen haben wiederum sprachliche Effekte zur Folge, anhand deren sie der

Analyst im Rahmen einer grammatikalischen und semantischen Analyse erkennen und

ggf. beheben kann3.

Tilgung mithilfe der Tilgung wird die Komplexit¨

at der Realit¨

at auf ein Ausmaß re-

duziert, mit dem der Mensch umgehen kann. Es findet eine Selektion statt, bei der

die Wahrnehmung nur auf einen relevanten Ausschnitt der Wirklichkeit gelenkt wird

(vgl. [Rup07], S. 143). Wichtige Anforderungen k¨

onnen dabei verloren gehen. Die sprach-

lichen Effekte der Tilgung sind:

Unvollst¨

andig spezifizierte Prozessw¨

orter sind Verben, Adjektive oder Adverbien, die

durch mehr als ein Substantiv beschrieben werden m¨

ussen, um als vollst¨

andig

angesehen werden zu k¨

onnen (vgl. [Rup07], S. 148).

Unvollst¨

andige Vergleiche und Steigerungen liegen vor, wenn keine Bezugspunkte an-

gegeben sind. Außerdem m¨

ussen Vergleiche und Steigerungen immer messbar sein

(vgl. [Rup07], S. 151).

Modaloperatoren der Notwendigkeit sind Begriffe wie m¨

ussen oder sollte, bei denen

Forderungen an das Verhalten des sp¨

ateren Systems gestellt werden (vgl. ebd.,

S. 153). Hier gilt es zu beachten, dass nicht nur das Normalverhalten beschrieben

wird, sondern auch das Ausnahmeverhalten (vgl. ebd.). Ein Begriff wie sollte impli-

ziert immer das m¨

ogliche Vorhandensein einer Ausnahme: ”Das System sollte die

Zulassung pr¨

ufen“. Was passiert jedoch, wenn eine ¨

Uberpr¨

ufung aus technischem

Grund nicht m¨

oglich ist? F¨

ur diesen Fall gilt es eine Ausnahme zu definieren.

Implizite Annahmen sind Fakten, die ”erfahrenen Anwendern v¨

ollig selbstverst¨

andlich

sind, sodass [. . . ] sie bei der Erhebung von Anforderungen gar nicht mehr kom-

muniziert werden“ ( [Rup07], S. 154). Diese Annahmen gilt es auf jeden Fall zu

dokumentieren, da ein wenig erfahrener Anwender diese nicht unbedingt f¨

ur selbst-

verst¨

andlich halten muss und bei der Implementierung falsch getroffene Annahmen

die korrekte Funktionalit¨

at des Systems beeintr¨

achtigen k¨

onnen (vgl. [SOP01],

S. 10).

3Eine Methodensammlung zur Aufdeckung und Behebung dieser Defizite stellt bspw. das SOPHIST-

REgelwerk dar (vgl. [SOP01]).

3. Terminologiebasierte Spezifizierung von Lernumgebungen

Generalisierung Bei der Generalisierung werden ”Elemente oder Teile eines pers¨

on-

lichen Modells von der urspr¨

unglichen Erfahrung abgel¨

ost [. . . ], um dann die gesamte

Kategorie, von der diese Erfahrung ein Beispiel darstellt, zu verk¨

orpern“ [BG94], S. 35.

Durch diese Verallgemeinerung k¨

onnen wichtige Sonder- und Fehlerf¨

alle h¨

aufig ¨

ubersehen

werden (vgl. [Rup07], S. 157). Die sprachlichen Effekte der Generalisierung sind:

Universalquantoren wie immer,alle oder nie spezifizieren H¨

aufigkeiten und treffen so-

mit eine Aussage ¨

uber das Verhalten von einer Menge von Objekten (vgl. [Rup07],

S. 157). Die Gefahr besteht in der Verallgemeinerung und der Nichtbeachtung von

Ausnahmen. Das festgelegte Verhalten muss nicht zwangsl¨

aufig auf alle Objekte

der Menge zutreffen.

Unvollst¨

andig spezifizierte Bedingungen liegen vor, wenn nicht alle m¨

oglichen Verhal-

ten eines solchen Konstruktes (wenn ... dann ...) definiert werden. H¨

aufig wird

vergessen zu spezifizieren, was passiert, wenn die Bedingung nicht eintritt (vgl.

[SOP01], S. 15).

Substantive ohne Bezugsindex sind ¨

ahnlich wie unvollst¨

andige Prozessw¨

orter nicht aus-

reichend beschrieben.

Verzerrung Die Verzerrung schließlich erm¨

oglicht es dem Menschen, die Realit¨

at auf

Grundlage von gemachten Erfahrungen zu ver¨

andern (vgl. [BG94], S. 37). Hierdurch

kann ein f¨

ur einen neutralen Betrachter verzerrtes Bild der Realit¨

at entstehen, da die

Realit¨

at und Erfahrung umgestaltet oder sogar verf¨

alscht werden kann (vgl. [Rup07],

S. 143, S. 162). Besonders die Verzerrung ist f¨

ur den Analysten problematisch, weil er

nicht beurteilen kann, ob die ihm dargelegte Formulierung des Stakeholders richtig oder

verzerrt sind. Die sprachlichen Effekte der Verzerrung sind:

Nominalisierung stellt eine ”komplexe Transformation dar, die ein Verb aus der Tiefen-

struktur in ein Substantiv der Oberfl¨

achenstruktur verwandelt“ [Rup07], S. 163.

Diese Substantive stehen dann h¨

aufig repr¨

asentativ f¨

ur einen urspr¨

unglich umfang-

reicheren Prozess. Ein Informationsverlust ist vorprogrammiert.

Funktionsgef¨

uge sind ”Kombinationen aus inhaltsarmen Verben (machen, k¨

onnen, ha-

ben, sein, ...) und sinngebenden Substantiven“ [Rup07], S. 165. Das Problem bei

diesen Konstrukten ist die mangelhafte Pr¨

azisierungsf¨

ahigkeit dieser Verben. Sie

beschreiben den Prozess nicht ausreichend.

Doch nicht nur die Anwendung der Sprache als Ausdrucksmittel der individuellen Wirk-

lichkeit, sondern auch die Sprache an sich kann Defizite aufweisen, die St¨

orungen in der

Kommunikation hervorrufen k¨

onnen.

3.1.1.2. Sprachdefekte

Zur Erkl¨

arung von Sprachdefekten wird zun¨

achst einmal ein Begriffsmodell hergeleitet:

Begriffe sind eine abstrakte, gedankliche Darstellung der wesentlichen Merkmale von

Dingen. Sie sind Mittel des gedanklichen Ordnens (Begreifens) und werden darum auch

3.1. Terminologiebasierte Softwareentwicklung

zur Kommunikation zwischen Menschen eingesetzt (vgl. [Bro04], S. 231). Nach [Ort97]

hat ein Begriff neben seiner Bezeichnung zur Identifizierung (Begriffswort, Benennung)

eine Intension (Begriffsinhalt, Schema) und eine Extension (Begriffsauspr¨

agung, Be-

griffsumfang). Die Ebene der Intension definiert durch eine Menge von Kriterien das

Schema eines Begriffes, anhand dessen entschieden werden kann, ob ein bestimmtes Ob-

jekt unter einen Begriff f¨

allt oder nicht. Komplement¨

ar dazu repr¨

asentiert die Extension

eines Begriffes die Gesamtheit aller Objekte, die genau diesem Begriff zugeordnet wer-

den k¨

onnen. Ortner unterscheidet dabei zwei Ebenen der Extension: (1) Konkrete oder

abstrakte Gegenst¨

ande, die unter den Begriff fallen, (2) singul¨

are softwaretechnische

Abbildungen oder Beschreibungen der Gegenst¨

ande (vgl. Abb. 3.1).

Begriﬀswort

(Bezeichner)

Intension

(Schema)

Attribute, Fähigkeiten, ...

Extension I

(Ausprägungen)

Gegenstände des

Anwendungsbereichs

Extension II

(Ausprägungen)

Softwaretechnische

Repräsentanten

Abbildung 3.1.: Begriffsmodell (eigene Darstellung in Anlehnung an [Ort97], S. 84f.,

[Sch97a], S. 143).

Da bei nat¨

urlichsprachlicher Kommunikation die Intension und Extension der verwende-

ten Begriffe von der individuellen gedanklichen Darstellung aller Beteiligter abh¨

angig ist,

kann es bei Anforderungserhebungen und Systemanalysen zu Kommunikationsst¨

orungen

kommen: Die Zuordnung zwischen der Intension des Systemanalysten und den von den

Stakeholdern verwendeten Begriffsbezeichnungen bzw. den Begriffsbezeichnungen und

ihrer Extension ist nicht in jedem Fall eindeutig. Dadurch k¨

onnen verschiedene Sprach-

defekte entstehen (vgl. [Ort93]):

âAls Synonyme werden Begriffe mit identischer Intension und Extension bezeich-

net, deren Bezeichner dadurch gegeneinander ausgetauscht werden k¨

onnen. Der

Gebrauch synonymer Begriffe ist dann unproblematisch, wenn allen Beteiligten

diese Eigenschaft bekannt ist.

âHomonyme sind Begriffe, die verschiedene Intensionen und Extensionen haben, je-

doch einen gemeinsamen Bezeichner besitzen. Dies kann zu schweren Missverst¨

and-

nissen f¨

uhren, sodass bei der Anforderungserhebung in solchen F¨

allen ein Kontext

angegeben werden muss, damit die Bezeichner unterschieden werden k¨

onnen.

âEine ¨

Aquipollenz meint die unterschiedliche Bezeichnung eines Objektes (Exten-

sion) aufgrund unterschiedlicher Blickwinkel (Intension).

âVon Vagheit spricht man, wenn zwischen Begriffen keine inhaltlich (intensional)

klare Abgrenzung vorhanden ist und dadurch die Zuordnung von Objekten zu Be-

griffen unklar ist. Durch eine Pr¨

azisierung der Intension k¨

onnen Vagheiten beseitigt

werden.

3. Terminologiebasierte Spezifizierung von Lernumgebungen

Insgesamt h¨

angt die H¨

aufigkeit des Auftretens und die Bandbreite der sprachlichen Ef-

fekte und Defekte bei der Anforderungsanalyse tendenziell von der verwendeten Erhe-

bungstechnik ab. Im Rahmen von Interviews oder Selbstaufschreibungen sind eher un-

strukturierte, verk¨

urzte oder ad-hoc formulierte Aussagen zu erwarten (vgl. [Leh98b]).

Gew¨

unscht sind jedoch einfache, aber pr¨

azise Formulierungen von intersubjektiven Aus-

sagen, die von allen am Anforderungsprozess beteiligten Personen gleichermaßen ver-

standen werden.

3.1.2. Normsprachen

So genannte kontrollierte Sprachen4wie zum Beispiel ASD Simplified Technical Eng-

lish (ASD-STE100, vgl. [ASD07]) oder das Siemens DokumentationsDeutsch (SDD,

vgl. [Sch96]) sind Teilmengen nat¨

urlicher Sprachen. Durch Vereinfachungen5soll sprach-

lichen Effekten vorgebeugt und Sprachdefekte behoben und so f¨

ur mehr Eindeutigkeit in

Wortwahl und Satzbau, Konsistenz im Ausdruck und f¨

ur eine bessere Verst¨

andlichkeit

gesorgt werden (vgl. [G¨

op07]).

Normsprachen sind spezielle kontrollierte Sprachen. Sie haben ihren Ursprung in der

konstruktiven Wissenschaftstheorie6und werden durch eine methodische Rekonstruktion

der in einem Anwendungsbereich gesprochenen nat¨

urlichen (Fach-)Sprache entwickelt.

Die Rekonstruktion umfasst die Kl¨

arung der Bedeutung von W¨

ortern, ihre eindeutige

Definition sowie ihre Beziehungen untereinander und Regeln f¨

ur ihren Gebrauch. Da-

durch werden vage und homogene Bezeichnungen entfernt und synonyme Bezeichnun-

gen nur in kontrollierter Form zugelassen werden (vgl. [Sch97a], S. 15, [Ort00], [Leh98a],

S. 366; vgl. hierzu auch Abschnitt 4.1.3).

Das Vokabular einer Normsprache setzt sich zu einem Teil aus allgemeinen, themen-

invarianten (sachgebietinvarianten) W¨

ortern zusammen, die f¨

ur die Repr¨

asentation von

normsprachlichen Aussagen ben¨

otigt werden (vgl. [Lor00], S. 29ff., [Ort95], S. 153f.). Die-

se so genannten Strukturw¨

orter (syn. Partikel) stehen f¨

ur Beziehungen und Beziehungs-

eigenschaften zwischen Gegenst¨

anden eines Realit¨

atsausschnitts. Sie nehmen daher bei

der Aussagenbildung eine syntagmatische, strukturierende Bedeutung ein. Dazu geh¨

oren

W¨

orter wie Artikel, Pronomen (Determinans) oder Pr¨

apositionen.

Der zweite Teil des Normsprachenvokabulars definiert Taxonomien von Themen- oder

Fachw¨

ortern, die zur Bezeichnung von Gegenst¨

anden eines Realit¨

atsausschnitts verwen-

det werden (vgl. ebd.). Diese umfassen beispielsweise Verben, Substantive, Adjektive

und Adverbien (vgl. [Sch97a], S. 148f.). Anteilsm¨

aßig wird die Menge an Fachw¨

ortern

gegen¨

uber einer relativ fixen Menge von Strukturw¨

ortern im Rahmen von Anpassun-

gen und Erweiterungen einer Normsprache zunehmen, so dass hierf¨

ur ein kontrollierter

Prozess einzuplanen ist (vgl. [Ort95], S. 156)7.

4Die deutsche Bezeichnung kontrollierte Sprache ist auf einen ¨

Ubersetzungsfehler zur¨

uckzuf¨

uhren: Das

englische Verb to control bedeutet nicht kontrollieren, sondern vielmehr steuern oder regeln. Eine

Controlled Language ist also eine geregelte Sprache (vgl. [G¨

op07]).

5Darunter z¨

ahlen bspw. eingeschr¨

ankter Wortschatz, eingeschr¨

ankte Grammatik, Regeln f¨

ur die Kon-

struktion von S¨

atzen (so genannte Satzbaupl¨

ane), evtl. Formatierungsbeschr¨

ankungen etc.

6Kamlah und Lorenzen schlagen in [KL96] die Einf¨

uhrung einer Orthosprache (gr.: orthos, richtig)

in allen Fachwissenschaften vor, mit der eindeutige und pr¨

azise Aussagen methodisch und zirkel-

frei formuliert werden k¨

onnen. Darauf basierend f¨

uhrte Schienmann in [Sch97a], S. 15, dann die

Bezeichnung Normsprache ein.

7Dazu Hellmuth in [Hel97], S. 43: ”Terminologiemanagement darf dabei jedoch nicht als einmaliger

3.1. Terminologiebasierte Softwareentwicklung

Um g¨

ultige Aussagen zu bilden und somit auf Basis des vorhandenen Vokabulars weitere

Fachbegriffe rekonstruieren zu k¨

onnen, bedarf es neben dem Vokabular noch einer forma-

len Grammatik mit semantischen Regeln, aus der so genannte Satzbaupl¨

ane abgeleitet

und definiert werden k¨

onnen8.

An dieser Stelle sollen die genannten Elemente einer Normsprache – Themen- und

Fachw¨

orter, Strukturw¨

orter und formale Grammatik – n¨

aher erl¨

autert werden, da sie

die Grundlage f¨

ur das Verst¨

andnis der in einem sp¨

ateren Abschnitt des Kapitels kon-

struierten Normsprache bilden.

Themen- und Fachw¨

orter Themen- und Fachw¨

orter werden in einer Normsprache

zun¨

achst zum Aufbau des Vokabulars verwendet, indem neue Begriffe formal durch be-

reits bestehende Begriffe rekonstruiert werden, wie bspw. durch die Aussage Student ε

(”ist“) Person. Die Aussage definiert eine intensionale Beziehung zwischen der Menge

der Studenten und der Menge der Personen. Diese auf Basis von Pr¨

adikatenlogik und

expliziten Definitionen untereinander abgegrenzten Pr¨

adikatoren heißen Termini. Eine

Terminologie umfasst sowohl Termini als auch die dazu geh¨

origen Pr¨

adikatorenregeln

und Definitionen und stellt damit den materiellen Teil einer Normsprache dar (vgl.

[Sch97a], S. 124).

Mithilfe dieser Termini k¨

onnen dann Aussagen zu dem Anwendungsbereich formu-

liert werden, den das sp¨

atere System unterst¨

utzen soll. Damit diese Aussagen sich auf

einen konkreten Realit¨

atsausschnitt beziehen k¨

onnen, m¨

ussen konkrete Objekte durch

Eigennamen oder (deiktische) Kennzeichnungen9benannt werden k¨

onnen. Dazu wird

eine Unterscheidung zwischen Nominatoren (bspw. ”Meier“) und Pr¨

adikatoren (bspw.

”Student“) gemacht:

oNat¨

urliche Sprache: [Meier ist ein Student.]

oNormsprache: [Meier |ε|Student]

oSatzbauplan: [N|ε|Q]

(3.1)

W¨

ahrend konkrete Objekte durch Nominatoren (N) benannt werden k¨

onnen, charak-

terisieren Pr¨

adikatoren im Unterschied dazu ihre Eigenschaften. Sie stellen also ihren

Begriffsbezeichner und nehmen somit auf intensionaler Ebene eine ordnende Funktion

ein, da mittels dieser Bezeichner eine Menge an Objekten gleichgesetzt und von anderen

gleichgesetzten Objekten unterschieden werden k¨

onnen (vgl. [Lor00], S. 29).

Schritt angesehen werden, sondern muß sich vielmehr als ein methodisch kontrollierter und auch

permanenter Prozeß der Verst¨

andigung auf unterschiedlichen Ebenen und zu unterschiedlichen Pha-

sen des Produktentstehungsprozesses verstehen“.

8In einer Normsprache get¨

atigte Aussagen sind daher allein schon aufgrund ihrer Form g¨

ultig, un-

abh¨

angig vom verwendeten Fachvokabular (vgl. [Leh98a], S. 366).

”Deiktische Kennzeichnungen sind sprachliche Ausdr¨

ucke, welche ihre benennende Funktion erst durch

den Bezug auf die jeweilige Sprechsituation erhalten. In Aussagen wird die Kontextabh¨

angigkeit

deutlich an der Verwendung von Demontrativpronomen oder Indikatoren wie dies,je-

nes,heute morgenoder dort dr¨

uben“ [Sch97a], S. 151. Sie sollten aufgrund ihrer Kon-

textabh¨

angigkeit jedoch m¨

oglichst vermieden werden (vgl. ebd.).

3. Terminologiebasierte Spezifizierung von Lernumgebungen

Wörter

Eigennamen

(N)

Prädikatoren Partikel

(¬, ε, σ, τ, ...)

Kasusmorpheme, Lokalprä-

positionen

Eigenprädikatoren Apprädikatoren

Geschehnis-

prädikatoren

(P)

Dingprä-

dikatoren

(Q)

Geschehnis-

Apprädikatoren

(p)

Ding-Apprä-

dikatoren

(q)

Abbildung 3.2.: Klassifikation von normsprachlichen Wortarten nach Lorenz (eigene

Darstellung, in Anlehnung an [Lor00], S. 52).

In der Klassifizierung nach Lorenzen (vgl. ebd., S. 29ff.) werden dar¨

uber hinaus Pr¨

adika-

toren in Dingpr¨

adikatoren (Q) und Ding-Appr¨

adikatoren (q) zur Bezeichnungen und Be-

schreibung von Gegenst¨

anden unterschieden, sowie in Geschehnispr¨

adikatoren (P) und

Geschehnis-Appr¨

adikatoren (p) zur Bezeichnung und Beschreibung von Aktivit¨

aten10.

Demnach geben die Pr¨

adikatoren die prim¨

are Ordnung von Gegenst¨

anden und Akti-

vit¨

aten einer Dom¨

ane wieder, Appr¨

adikatoren charakterisieren sie. Diese Klassifikation

lehnt sich an eine klassische Trennung von Wortarten in Substantive, Verben, Adjektive

und Adverbien an (vgl. ebd., S. 52)11. Somit k¨

onnen auch reichhaltigere umgangssprach-

liche Aussagen in einer Normsprache modelliert werden:

oNat¨

urliche Sprache: [M¨

uller legt computergest¨

utzt einen neuen

Kurs an.]

oNormsprache: [M¨

uller |π|computergest¨

utzt anlegen |

neu Kurs]

oSatzbauplan: [N|π|pP |qQ] mit Tatkopula π(lies: tut)

(3.2)

Durch die Pr¨

adikatoren und Nominatoren einer Normsprache ist die M¨

oglichkeit einer

konkreten Gegenstandseinteilung von Dingen, Eigenschaften und Geschehnissen einer

Dom¨

ane gegeben. Somit lassen sich Ordnungs- und Teilungs-/Verbindungsaussagen for-

mulieren, aus denen man den Aufbau und die Struktur eines Systems rekonstruieren

kann. Aussagen zu Geschehnissen k¨

onnen sich analog dazu auf Operationen (F¨

ahigkeiten,

10Da im weiteren Verlauf dieser Arbeit bzgl. der Satzbaupl¨

ane auf die Arbeit [Sch97a] von Schienmann

verwiesen wird, werden im Folgenden auch seine Variablenbezeichner verwendet.

11Schienmann weist in [Sch97a], S. 155, jedoch darauf hin, dass Aktivit¨

aten einer Normsprache unter

semantischen Gesichtspunkten nicht immer nur durch umgangssprachliche Verben beschrieben wer-

den m¨

ussen, sondern auch Konstrukte wie ”Kursanlegen“ oder ”Kurs anlegen“ verwendet werden

k¨

onnen.

3.1. Terminologiebasierte Softwareentwicklung

Methoden) mit Objekten und das Systemverhalten beziehen (vgl. [Ort95], S. 155). Eine

solche Einteilung ist als grundlegendes L¨

osungsprinzip in vielen softwaretechnischen Me-

thoden implizit12, im Kontext einer an eine nat¨

urliche Sprache angelehnte Normsprache

jedoch zun¨

achst einmal unabh¨

angig von einem bestimmten softwaretechnischen Paradig-

ma. Damit dar¨

uber hinaus aber auch eine Korrektheit von Teilen des Entwurfs und der

Entwicklungsresultate beweisbar und dadurch verifizierbar wird, werden sowohl in den

Strukturbedingungen des Entwicklungssystem (formal) als auch bei der Rekonstruktion

der Themen- und Fachw¨

orter (thematisch) logische Konstrukte angewandt.

Eine Normsprache muss nach Ortner drei Intensionen des Wahrheitswertbegriffes adres-

sieren (vgl. [Ort95], S. 150; vgl. dazu auch [Sch97a], S. 93):

âEine Aussage ist formal wahr, wenn sie eine zugelassene Satzstruktur (Satzbau-

plan) erf¨

ullt (formal-logischer Wahrheitswertbegriff)

âEine Aussage ist thematisch wahr, wenn sie nur auf definierten (rekonstruierten)

Themenw¨

orter basiert (terminologischer Wahrheitswertbegriff)

âEine Aussage ist empirisch oder faktisch wahr, wenn die Aussage dem zu model-

lierenden Realit¨

atsausschnitt auch tats¨

achlich entspricht (empirischer Wahrheits-

wertbegriff).

Eine g¨

ultige normsprachliche Aussage, die empirisch oder faktisch wahr ist, ist da-

mit implizit sowohl thematisch wahr als auch formal (vgl. ebd.; vgl. auch [Sch97a],

S. 124ff.). Da das empirische oder faktische Wahrheitskriterium in diesem Kontext die

Ubereinstimmung einer Modellinstanz (bspw. Auspr¨

agung des Datenschemas) mit der

Realit¨

at betrifft, verbleibt f¨

ur die Formalisierung der Logik in einer Normsprache – wie

oben bereits angedeutet – zum einen das Entwicklungssystem selbst, als auch das zum

Entwurf verwendete Vokabular an Fachw¨

ortern. Daher werden logische Konstrukte (1)

zur Aussagenbildung (grammatische Partikel) und (2) zur Rekonstruktion des Vokabu-

lars (logische Partikel) unterschieden.

Grammatische Partikel Die Grammatik einer Normsprache ist Teil des Entwicklungs-

systems. Daher muss sie sprachliche M¨

oglichkeiten bieten, ein System durch Aussagen

zur Struktur (Attribute und Beziehungen), Funktionalit¨

at (F¨

ahigkeiten und Interaktio-

nen) und Dynamik (Zust¨

anden und Reihenfolgen) eines Problembereichs zu spezifizieren

(vgl. [Sch97a], S. 51f.). Dies ist durch die alleinige Nutzung von Fachw¨

ortern nicht pr¨

azise

genug m¨

oglich, weshalb das Vokabular einer Normsprache dar¨

uber hinaus weitere Hilfs-

konstrukte umfassen muss.

12Beispielsweise die Einteilung nach Objekten, Attributen und Operationen beim objektorientierten

Paradigma, im relationalen Datenbankentwurf die Gegenstandseinteilung nach Entities und Relati-

ons oder beim Entwurf von Expertensystemen eine Gegenstandseinteilung nach Fakten, Regeln und

Schlussarten.

3. Terminologiebasierte Spezifizierung von Lernumgebungen

Insbesondere Hilfsverben wie sein,haben und werden k¨

onnen in Ordnungs-, Teilungs-/

Verbindungs- und Geschehnisaussagen als Kopulae13 das Subjekt mit Pr¨

adikatoren ver-

binden:

Kopula Affirmativ Negativ

oSeinskopula ε(lies: ist)ε0(lies: ist nicht)

oTatkopula π(lies: tut)π0(lies: tut nicht)

oF¨

ahigkeitskopula γ(lies: kann)γ0(lies: kann nicht)

oWiderfahrniskopula τ(lies: wird)τ0(lies: wird nicht)

oTeilungskopula σ(lies: hat)σ0(lies: hat nicht)

oBerechtigungskopula ϑ(lies: darf )ϑ0(lies: darf nicht)

(3.3)

Mit diesen Kopulae lassen sich Aussagen bilden wie [607080 |ε|Matrikelnummer],

[Meier |σ|607080], oder [M¨

uller |ϑ0|benoten |Meier]. Weiterhin k¨

onnen Pr¨

apo-

sitionen wie aus,nach,mit und Determinans wie der,die,das als Mittel zur pr¨

azisen

Aussagenformulierung vonn¨

oten sein.

Logische Partikel Die Beziehungen zwischen Themen- und Fachw¨

ortern untereinan-

der m¨

ussen so pr¨

azise beschrieben werden k¨

onnen, dass sich allein durch ihre Verwen-

dung Aussagen als thematisch wahr oder falsch beweisen lassen. Zur logischen Abgren-

zung oder zur expliziten Definition von Begriffen werden Junktoren und Quantoren der

Pr¨

adikatenlogik genutzt:

oNegator: ¬(lies: nicht)

oKonjunktor: ∧(lies: und)

oAdjunktor: ∨(lies: oder)

oSubjunktor: →(lies: wenn, dann)

o¨

Aquijunktor: ↔(lies: genau dann, wenn)

sowie

oEinsquantor: ∃(lies: es gilt f¨

ur ein)

oAllquantor: ∀(lies: es gilt f¨

ur alle)

(3.4)

Um beispielsweise auszudr¨

ucken, dass Studenten nicht mehr als zehn Kurse belegen

d¨

urfen, kann man folgende Aussage formulieren:

∀x ε Student ≤10

∃y ε Kurs (x|π|belegen |y) (3.5)

Ebenso kann durch die Festlegung semantischer Merkmale mithilfe von Konjunktoren

die Intension des Pr¨

adikators Student im Lexikon bestimmt werden:

x ε Student def

=x ε Person ∧ ∃ m(x|hat Matrikelnummer |m) (3.6)

∧ ∃ s(x|ist eingeschrieben |s). . .

f¨

ur m ∈Matrikelnummer, s ∈Studiengang, . . .

Ein Student ist demnach eine Person, die eine Matrikelnummer hat und in einem Stu-

diengang eingeschrieben ist.

13Das Hilfsverb wird hierbei als eigenst¨

andiges Verb verwendet, vgl. bspw. 3.7 oder 3.9.

3.1. Terminologiebasierte Softwareentwicklung

3.1.2.1. Satzbaupl¨

ane

Satzbaupl¨

ane beschreiben die grammatische Struktur von normsprachlichen S¨

atzen, mit

denen umgangssprachliche Aussagen rekonstruiert werden k¨

onnen. Mit diesen Mustern

ist eine bestimmte Grundbedeutung von S¨

atzen verbunden, die sich an der Einteilung

eines gew¨

ahlten Spezifikationsrahmens im Softwareentwurf orientieren muss.

In den oben angef¨

uhrten Beispielen wurden bereits solche Satzbaupl¨

ane vorgestellt. So

beschreibt (3.1) das normsprachliches Satzmuster f¨

ur die elementare Dingpr¨

adikation,

durch die ein durch den Nominator N in der Subjektstellung bezeichnetes konkretes

Objekt einer Menge von Objekten auf extensionaler Begriffsebene zugeordnet wird. Sol-

che Aussagen, die eine Auspr¨

agung eines Schemas beschreiben, bezeichnet Ortner als

singul¨

are Aussagen. F¨

ur die Rekonstruktion von Fachbegriffen durch vorhandenes Voka-

bular und somit f¨

ur die Entwicklung eines konzeptuellen Schemas essentiell sind dar¨

uber

hinaus auch allgemeine Aussagen, die semantische Beziehungen zwischen Pr¨

adikatoren

n¨

aher beschreiben. Dazu kann das in (3.1) beschriebene Satzbaumuster verallgemeinert

werden, um auch umgangssprachliche Aussagen zu Generalisierungsbeziehungen rekon-

struieren zu k¨

onnen:

[N1|ε|N2] (3.7)

Ein Nominator kann hierbei in singul¨

aren Aussagen weiterhin zur Bezeichnung eines

konkreten Objektes herangezogen werden, dar¨

uber hinausgehend aber auch einen Be-

griff bezeichnen, wonach ”’Student’ ε’Person’“ eine ebenso g¨

ultige Aussage ist wie

”Meier ε’Student’“14.

Analog zu (3.7) kann auch ein Satzmuster zur Beschreibung von Kompositionsbezie-

hungen in singul¨

aren oder in allgemeinen Aussagen aufgebaut werden:

[N1|σ|N2] (3.8)

Als Beispiel mag die Aussage ”Kurs σTeilnehmergruppe“ dienen.

Die Satzbaupl¨

ane (3.7) und (3.8) erm¨

oglichen die Rekonstruktion der statischen Struk-

tur einer Dom¨

ane, der Satzbauplan in (3.2) bezieht sich im Gegensatz dazu auf die Be-

schreibung von Verhalten eines Systems innerhalb dieser Dom¨

ane, also Interaktionen

zwischen Instanzen des konzeptuellen Schemas. Um komplexere Satzstrukturen zu Ver-

haltensaussagen rekonstruieren zu k¨

onnen, kann das Satzmuster um indirekte Objekte

erweitert werden:

[N|π|pP |q1Q1|q2QF all

2|. . . |qnQF all

n] (3.9)

Indirekten Objekten werden in Normsprachen so genannte Kasusmorpheme beigestellt,

die den jeweiligen Fall des Objektes anzeigen (vgl. [Lor00], S. 46f.)15.

14Die Hochkommata dienen in diesem Fall nur der Verdeutlichung der erweiterten Nominatorenfunktion

und k¨

onnen auch weggelassen werden.

15Nach Lorenzen lassen sich mindestens drei F¨

alle unterscheiden: 1) indirektes Objekt als Hilfsmit-

tel (Mittelfall): ”Student |π|belegen |Kurs |mit-OnlineAnmeldung“, 2) indirektes Objekt als

Ergebnis der Ausf¨

uhrung (Werkfall): ”Dozent |π|¨

uberf¨

uhren |Anmeldung |zu-Zulassung“,

und 3) indirektes Objekt benennt Ziel der Handlung (Gebefall): ”Dozent |π|¨

uberreichen |

Teilnahmebest¨

atigung |an-Student“ (vgl. [Lor00], S. 46f)

3. Terminologiebasierte Spezifizierung von Lernumgebungen

Ein Beispiel:

[Schulz |π|alphabetisch hinzuf¨

ugen |neu Anmeldungen |aktuell in-Anmeldeliste]

Als letztes Beispiel f¨

ur Satzmuster soll an dieser Stelle noch die Modellierung von Aus-

sagen mit einem Ding-Appr¨

adikator vorgestellt werden, in denen kein Ding-Pr¨

adikator

angegeben ist. Hierzu f¨

uhrt Lorenz den Leerp¨

adikator mit dem Symbol oein, der in

Aussagen beliebige Pr¨

adikatoren ersetzen kann. In der folgenden Aussage bezeichnet

”W3045“ einen Kurs:

oNat¨

urliche Sprache: [W3045 ist voll.]

oNormsprache: [W3045 |ε|voll]

oSatzbauplan: [N|ε|qo]

(3.10)

Der Leerpr¨

adikator kann hier verwendet werden, um den Ding-Pr¨

adikator wie in der

nat¨

urlichsprachlichen Aussage auszusparen, den appr¨

adikativen Charakter eines Objek-

tes aber wiederzugeben. Da der Leerpr¨

adikator jedoch – wie der Name schon sagt –

keinerlei Intension besitzt, w¨

urde die Aussage von dem Kontext abh¨

angig sein, aus dem

hervorgeht, dass ”W3045“ einen Kurs bezeichnet. Besser daher die Modellierung mit

[N|ε|qQ], also ”W3045 |ε|voll Kurs“.

3.1.3. Normsprachliche Entwicklung von Software

Auf Basis einer Normsprache mit ihren inhaltlich (fachlich) definierten, normierten Ter-

mini k¨

onnen Systemanforderungen in einem Anwendungsgebiet pr¨

azise beschrieben wer-

den, ohne spezielle Architekturkonzepte oder Entwicklungsans¨

atze in der Auspr¨

agung

von Diagramm- und Beschreibungssprachen ber¨

ucksichtigen zu m¨

ussen. Somit kann

zun¨

achst zusammen mit den Anwendern/Fachexperten ein methodenneutraler Fachent-

wurf der Software erarbeitet werden, der bzgl. seiner Implementierung noch keinen spe-

zifischen softwaretechnischen L¨

osungsansatz zu erkennen gibt. Dieser erste Fachentwurf

kann dann anschließend – ohne Beteiligung der Benutzer – softwaretechnisch geplant

(bzw. methodenspezifisch in andere formale Sprachen transformiert) und umgesetzt wer-

den (vgl. [Ort98]). Im Folgenden soll der Ablauf dieses zweigeteilten Fachentwurfs, der

in Abbildung 3.3 skizziert ist, erl¨

autert werden.

3.1.3.1. Methodeninvarianter Teil des Fachentwurfs

Der Aufbau eines normsprachlichen Entwicklungssystems f¨

ur eine Dom¨

ane ist iterativ

und evolution¨

ar. Mit jedem neuen Softwareprojekt werden das Vokabular und die seman-

tischen Beziehungen weiter ausgebaut. Neben der Aussagensammlung selbst geh¨

ort ihre

grammatikalische Normierung sowie ihre terminologische Rekonstruktion zum ersten,

dem methodenneutralen Teil des Fachentwurfs:

3.1. Terminologiebasierte Softwareentwicklung

Normsprachliches Entwicklungssystem

Lexikon & Grammatik

Methodeninvarianter Teil des Fachentwurfs

Methodenspezifischer Teil des Fachentwurfs

Methodenspezifisches Entwicklungssystem

Methoden-

spezifischer

Fachentwurf

Entwurfsparadigmen, Diagrammsprachen, etc.

Rekonstruktion

Natürlich-

sprachliche

Aussagen

Normsprach-

licher Fach-

entwurf

Spezifikation

Aussagen

zuordnen

Modelle

Prüfen

Modelle

konstruieren

Wörter

definieren

Aussagen

normieren

Aussagen

sammeln

Abbildung 3.3.: Zweigeteilter Fachentwurf auf Basis einer Normsprache (eigene Darstel-

lung).

Aussagennormierung Um syntaktisch normierte, methodenneutrale Aussagen zu er-

halten, muss in einem ersten Schritt die Kontextfreiheit jeder Aussage gew¨

ahrleistet

werden. Lehmann schl¨

agt dazu in [Leh98b] die Substitution der Pronomen durch ent-

sprechende Substantive vor. In einem weiteren Schritt sollten komplexe Aussagen in

einzelne und mehrdeutige in eindeutige Aussagen ¨

uberf¨

uhrt werden. Zur Identifikation

des ausf¨

uhrenden Objektes sollte man passiv formulierte Aussagen durch aktiv formu-

lierte ersetzen (vgl. ebd.). Nachdem man die Substantive und Verben in eine normierte

Form gebracht hat, lassen sich Satzlogik ¨

uberpr¨

ufen und redundante Aussagen entfernen.

Terminologische Rekonstruktion Bei diesem Schritt werden die o. g. Zuordnungspro-

bleme von Begriffen und Benennungen beseitigt. Dazu k¨

onnen auch neue Begriffe ein-

gef¨

uhrt werden. Weiterhin werden eindeutige Begriffsbedeutungen und semantische Be-

ziehungen (Generalisierungshierarchien, Kompositionsbeziehungen etc.) zwischen den

Begriffen sowie zwischen den Begriffen und Benennungen festgelegt. Lehmann empfiehlt

dazu folgendes Vorgehen (vgl. ebd.): Identifizierung aller potenziellen Fachbegriffe und

3. Terminologiebasierte Spezifizierung von Lernumgebungen

Normierung ihrer Flexion16. Eine Stoppwortliste17 kann dazu verwendet werden, um

semantisch unbedeutende W¨

orter herauszufiltern. Die verbleibenden Fachbegriffskan-

didaten werden dann durch explizite Definition auf Basis vorhandener Begriffe rekon-

struiert und dem Lexikon hinzugef¨

ugt. Eine zentrale Forderung bei der Rekonstruktion

ist die Wahrung einer gr¨

oßtm¨

oglichen Kontextunabh¨

angigkeit und die Anwendungsneu-

tralit¨

at der definierten Fachw¨

orter: W¨

orter der Normsprache sollen im Gegensatz zu

W¨

ortern nat¨

urlicher Sprache nicht erst im Anwendungskontext eine bestimmte Bedeu-

tung annehmen, sondern als Terminologie immer die selbe festgelegte Semantik besitzen

(vgl. [Lor00], S. 39, [Ort95], S. 156).

3.1.3.2. Methodenspezifische Spezifikation auf Basis normsprachlicher Aussagen

Dieser zweite Teil des Fachentwurfes basiert auf den fachlich relevanten, genormten Aus-

sagen und Definitionen des ersten Teils. Diese werden nun schrittweise in methodenspe-

zifische Diagramm- und Beschreibungssprachen transformiert, bevor sie mit einer Pro-

grammiersprache umgesetzt werden: Zun¨

achst werden die normsprachlichen Aussagen

den relevanten Definitionen anwendungssystemtypischen Architektursichten18 und den

darin verorteten Aspekten19 zugeordnet (vgl. [Leh98b], [Sch97a], S. 171f.). Der Anwen-

dungstyp wird in vielen F¨

allen bereits – explizit oder implizit – vorgegeben sein. Sollte

dies nicht so sein, so bieten die Problemstellung und die Anforderungen aus dem ersten

Teil des Fachentwurfs eine gute Entscheidungsgrundlage zur Abw¨

agung der in Frage

kommenden Optionen. Durch diese Strukturierung wird das Modellierungsproblem ver-

einfacht. Im Zweifelsfall empfiehlt Lehmann eine Mehrfachzuordnung von Aussagen20.

Um den Aussagen entsprechenden Diagramm- oder formalen Sprachkonstrukten zu-

ordnen zu k¨

onnen, m¨

ussen diese klassifiziert werden. Schienmann beschreibt in [Sch97a],

S. 171, ein solches Klassifikationsschema mit der Einteilung in Aussagen zu Attributen,

Beziehungen, Funktionalit¨

at, Berechtigungen, Aktivit¨

aten und Zust¨

anden. So klassifi-

zierte normsprachliche Aussagen k¨

onnen einem entsprechenden Diagramm- oder forma-

len Sprachkonstrukt zugeordnet und entsprechend syntaktisch normiert und umgesetzt

16Flexion beschreibt die Beugung von W¨

ortern (Konjugation oder Deklination), bspw. durch

Ver¨

anderung des Wortstammes oder das Anh¨

angen von Wortendungen. Zur Flexion z¨

ahlen auch

Steigerungsformen wie Komparativ und Superlativ. Zwar spielt die Flexion zumeist auf syntakti-

scher Ebene eine Rolle, Plural und Genus haben jedoch oft auch eine semantische Bedeutung. Das

k¨

onnte eine Erkl¨

arung sein, warum Lehmann ihre Normierung nicht zur grammatikalischen, sondern

zur terminologischen Aussagentransformation z¨

ahlt.

17Stoppw¨

orter nennt man im Information-Retrieval W¨

orter, die bei einer Volltextindexierung nicht

beachtet werden, da sie vor allem syntaktische Funktionen ¨

ubernehmen und daher keine semantische

Bedeutung haben. Gepr¨

agt wurde der Begriff durch die Abhandlung von Hans Peter Luhn ¨

uber die

erste Implementierung eines Algorithmus zur Satzextraktion (vgl. [Luh58]).

18Die wesentlichen Sichten sind oftmals Statik (data viel,type view oder informational aspect), Funk-

tionalit¨

at (process view,mechanism,algorithm oder functional aspect) und die Dynamik (control

view,time view,state view oder behavioral view).

19Aspekte sind alle eigenst¨

andigen Anforderungen (concerns), die funktionale Anforderungen betreffen

und sich einfach kapseln lassen, und System-Level-Concerns, die technische Randbedingungen dar-

stellen und nicht so einfach gekapselt werden k¨

onnen, da sie viele Teile eines Systems betreffen, wie

bspw. das Logging oder auch entsprechende fachliche Belange.

20Solche miteinander verwobenen Anforderungen werden auch als crosscutting concerns bezeichnet,

denn sie ”schneiden“ quer durch logische Schichten des Systems. Siehe dazu auch S. 143.

3.2. Die Wissensraummetapher als konstruierende Semantik f¨

ur Lernumgebungen

werden. Einzelne methodenspezifischen Konstrukte werden abschließend zu vollst¨

andi-

gen Diagrammen und Beschreibungen zusammengesetzt und auf Vollst¨

andigkeit und

Widerspruchsfreiheit ¨

uberpr¨

uft.

3.2. Die Wissensraummetapher als konstruierende

Semantik f¨

ur Lernumgebungen

Die Entwicklung virtueller Lernumgebungen ist ein interdisziplin¨

ares Gebiet, das auf eine

Vielzahl von Theorien innerhalb verschiedener Fachbereiche zugreifen kann (vgl. [Blu98],

S. 93ff.). Auf den folgenden Seiten soll hergeleitet werden, warum die in dieser Arbeit

verwendete Wissensraummetapher als semantisches Bezugssystem einen konstruierenden

Charakter f¨

ur die Dom¨

ane des computergest¨

utzten Lernen und Arbeitens hat und somit

als grundlegende Terminologie zur Entwicklung eingesetzt werden kann. Zun¨

achst wer-

den Theorien der P¨

adagogik und der Koginitionspsychologie aufgef¨

uhrt, um die grund-

legenden Gestaltungsaspekte von Lernumgebungen zu identifizieren.

Anhand dieser Theorien wird das Wissensraumkonzept schließlich eingeordnet und

n¨

aher beschrieben.

3.2.1. Lerntheoretische und koginitionspsychologische Grundlagen

Als Leitbild oder Paradigma f¨

ur die Theorienbildung und Gestaltung von Lernarrange-

ments sind besonders drei fundamentale Orientierungsrichtungen von Relevanz: Der aus

dem Reiz-Reaktionslernen hervorgegangene Behaviorismus, der Kognitivismus und der

Konstruktivismus (vgl. bspw. [THH+96], S. 42, [BP94], S. 110ff. und [Ste00], S. 818).

3.2.1.1. Behaviorismus

Die Werke des russischen Physiologen Pawlow ¨

uber das Reiz-Reaktionsverhalten von

Hunden (klassisches Konditionieren) inspirierten den Amerikaner Watson im Jahr 1913

zu seiner Abhandlung ”Psychologie, wie der Behaviorist sie sieht“. Genau wie Pawlow

ging Watson davon aus, dass ein konditionierter Reiz durch einen unkonditionierten er-

setzt werden kann, wenn beide oft genug zusammen eingesetzt werden. Damit wurden

Lernen und Reizsubstitution gleichgesetzt und der Begriff des Behaviorismus als objekti-

ve, psychologische Lerntheorie gepr¨

agt (vgl. [Kli93], S. 17, [Ede00], S. 67). Etwa zeitgleich

mit Pawlow entwickelte der Amerikaner Thorndike – ebenfalls auf Basis von Tierversu-

chen – das Prinzip der Verst¨

arkungstheorien, wobei der Erfolg einer Reaktion dar¨

uber

entscheidet, ob die Reaktion in Zukunft h¨

aufiger gew¨

ahlt wird (vgl. [Ede00], S. 65f.). Die-

se Theorie lieferte einen wesentlichen Beitrag zur behavioristischen Lernauffassung, der

auch in der heutigen Zeit zum Teil noch maßgeblich ist21. Um 1930 beschrieb Skinner, ein

weiterer amerikanischer Wissenschaftler, den Begriff der operanten Konditionierung. An-

ders als Thorndike wartete Skinner nicht auf zuf¨

allige Verhaltensweisen der Probanden,

21Beispielsweise fußt der didaktische Ansatz des Drill&Practice beim computergest¨

utzten Lernen auf

dem ”¨

Ubungsgesetz“ von Thorndike. Dieses Gesetz besagt, dass kurze zeitliche Abfolgen von Reiz-

Reaktionsverbindungen das Behalten besonders st¨

arken (vgl. [Kli93], S. 17f.).

3. Terminologiebasierte Spezifizierung von Lernumgebungen

Input

(Reiz)

Informations-

verarbeitung

Informations-

speicherung

Ouput

(Leistung)

Aneignung Speicherung Abruf

Abbildung 3.4.: Kognitivistisches Grundmodell der menschlichen Informationsverarbei-

tung (aus: [Ede00], S. 165).

sondern versuchte eine Steuerung, indem er richtige Verhaltens¨

anderungen verst¨

arkt und

falsche nicht (vgl. [Ste00], S. 819). Die Arbeiten von Skinner stellen einen wichtigen Be-

standteil der behavioristischen Theorie, die vorwiegend dem programmierten Unterricht

der 60er Jahre zugrunde gelegt wurden (vgl. ebd.).

Wenngleich der Behaviorismus als Grundlage f¨

ur die Gestaltung vieler Lernarrange-

ments diente22, liegt aus heutiger Sicht die Hauptkritik an der fehlenden Bezugnahme auf

h¨

oherwertige kognitive Lehrziele hinsichtlich des Leistungsniveaus. Es ist zwar notwen-

dig, Faktenwissen und Wissen ¨

uber Prozeduren oder Prinzipien aus dem Ged¨

achtnis ab-

rufen und verbal wiedergeben zu k¨

onnen. Zur Verbesserung der Probleml¨

osef¨

ahigkeiten

von Lernenden sind jedoch h¨

ohere Lehrziele23 wie das Verstehen von Informationen, das

Anwenden der Regeln und Prinzipien sowie Analyse- und Synthesef¨

ahigkeiten notwen-

dig, um korrekte (d. h. im jeweiligen Kontext funktionsf¨

ahige) und konsistente Modelle

des Problembereichs bilden zu k¨

onnen. Durch behavioristische Ans¨

atze kann lediglich

die Wiedergabe von Informationen gepr¨

uft werden. Lernprozesse, die kein beobachtba-

res Verhalten bei dem Lernenden ausl¨

osen, k¨

onnen behavioristisch nicht erkl¨

art werden

(vgl. [Has95], S. 164). Betrachtet wird einzig die Ver¨

anderung des Inputs (Stimulation)

zum Output (Response) als einzige Variable, um einen Lernerfolg zu definieren. Die-

se Sichtweise eignet sich nicht f¨

ur Lernprozesse, die komplexere Zusammenh¨

ange als

Grundlage haben. Allerdings werden einfach strukturierte Prozesse nach wie vor oftmals

behavioristisch konstruiert (vgl. [Ste00], S. 819).

3.2.1.2. Koginitivismus

Im Gegensatz zum Behaviorismus, bei dem ¨

außere Reize ein Individuum steuern, wird

im Kognitivismus (lat. cognoscere: erkennen) der Lernende als Individuum verstan-

den, das ¨

außere Reize aktiv und selbst¨

andig verarbeitet (vgl. [THH+96], S. 43, [G¨

ul01],

S. 81). Der Fokus bei kognitiven Lerntheorien liegt auf den koginitionspsychologischen

Annahmen der menschlichen Informationsverarbeitungsf¨

ahigkeit, dessen Grundmodell

in Abb. 3.4 skizziert ist. In dem Grundmodell werden drei Bereiche angenommen, die

22Neben dem Drill&Practice sind als weitere Beispiele der programmierte Unterricht der 60er Jahre zu

nennen, ebenso wie Tutorials, Simulatoren und Ans¨

atze des Instructional Designs.

23Die Arbeitsgruppe um Bloom formuliert in [BEF+56] ein Schema zur Klassifikation von Lehrzielen

auf unterschiedlichen Leistungsniveaus.

3.2. Die Wissensraummetapher als konstruierende Semantik f¨

ur Lernumgebungen

jeweils untereinander in einem Kontext stehen und interagieren. In der ersten Phase der

Aneignung findet das eigentliche Lernen im engeren Sinne statt. Dabei werden Außenrei-

ze vom Individuum aktiv unter Ber¨

ucksichtigung fr¨

uherer Erfahrungen wahrgenommen

(selektive Wahrnehmung). Diese gefilterten Informationen werden in einem so genannten

Kurzzeitspeicher zusammen mit vorhandenen Informationen aus dem Langzeitspeicher

aktiviert24.

In einer zweiten Phase k¨

onnen in ihrer Bedeutung ¨

ubereinstimmende oder assoziier-

te Informationen durch Wiederholung und Ausarbeitung – dies wird durch die dritte

Phase Abruf repr¨

asentiert – aus dem Kurz- in den Langzeitspeicher ¨

ubernommen wer-

den25. Dadurch entstehen so genannte mentale Modelle, also vereinfachte, subjektive

Repr¨

asentationen der Realit¨

at, die die Grundlage f¨

ur das Verst¨

andnis von Sachverhal-

ten bilden (vgl. [GS83] und [JL83]). Diese individuellen Denkmodelle werden mit zu-

nehmenden Verst¨

andnis eines Sachverhaltes elaboriert und angepasst und sind dadurch

dynamisch.

Lernen geht in kognitivistischen Lerntheorien daher einher mit der Ver¨

anderung kog-

nitiver Strukturen und Prozesse. Demnach ist entscheidend, wie Lernende mit einem

Lernangebot umgehen, d. h. welche kognitiven Operationen ausgef¨

uhrt werden und ob

sich diese zu effektivem Lernen, also zum Aufbau von Wissen eignen (vgl. [Ker01],

S. 66, [Hes04], S. 17ff.). Die Annahme, dass verschiedene Wissenstypen in unterschiedli-

chen Subsystemen des Ged¨

achtnisses gespeichert werden und es demnach jeweils andere

Prozesse erfordert, um Wissen in dem entsprechenden System dauerhaft zu verankern

bzw. abzurufen, ist der Ausgangspunkt der Theorien: ”One can communicate verbally

one’s declarative knowledge, but not one’s procedural knowledge. Declarative knowledge

seems to be possessed in an all-or-nothing manner whereas procedural knowledge seems

to be something that can be partially possessed. One acquires declarative knowledge

suddenly by being told whereas one acquires procedural knowledge by performing the

skill“ [And76], S. 117ff.

Ansatzpunkt didaktischer ¨

Uberlegungen ist daher vor allem die Klassifikation der

Lehr-Lerninhalte, um daran die f¨

ur die Verarbeitung notwendigen Prozesse abzuleiten.

Unter Ber¨

ucksichtigung des Vorwissens der Lernenden werden dann kognitive Konzep-

te wie Lernzielkataloge definiert und zur Grundlage instruktionaler Systeme gemacht

(vgl. [Sch01b], S. 73).

Die Theorie der Kognition hat zwei wichtige p¨

adagogisch-methodische Konzepte her-

vorgebracht: Beim explorativen Lernen (entdeckenden Lernen) stehen Lernarrangements

oder -anwendungen im Zentrum der Betrachtung, die eigenst¨

andiges Lernen motivieren

sollen, insbesondere einen definierten Anregungsgehalt zur Initiierung von selbstgere-

gelten Lernaktivit¨

aten aufweisen (vgl. [Ker01], S. 219ff.). Statt alle relevanten Informa-

tionen vorstrukturiert zu pr¨

asentieren zu bekommen, muss der Lernende diese zun¨

achst

24Dieses Ged¨

achtnismodell mit einem Kurzzeitged¨

achtnis als Zwischenspeicher wurde von Atkinson und

Shiffrin vorgeschlagen und ist weit verbreitet (vgl. [Ede00], S. 253).

25Dieser Anpassungsprozess wurde von Piaget als kognitive Assimilation bezeichnet. Sie kommt dann

zustande, ”wenn ein kognitiv aktiver Organismus eine Erfahrung in die konzeptuelle Struktur ein-

passt, ¨

uber die er jeweils verf¨

ugt“ [Gla94], S. 28. Wird das Ziel nicht erreicht, kann die sich ergebende

St¨

orung zu einer Akkomodation f¨

uhren (vgl. ebd., S. 33).

3. Terminologiebasierte Spezifizierung von Lernumgebungen

finden, priorisieren und neu ordnen, bevor er daraus Regeln ableiten und Probleme l¨

osen

kann. Somit wird auch ein st¨

arkerer Wert auf Metakognition gelegt, also das ”Wissen des

Lernenden ¨

uber die eigenen kognitiven Prozesse und deren Bedingungen“ [WKH+93],

S. 210. Entdeckendes Lernen ist auch gut mit konstruktivistischen Theorien vereinbar,

die im Folgenden noch vorgestellt werden.

Eine spezielle Form des entdeckenden Lernens ist das Lernen mit Welten (Simulationen).

Hier bewegt sich der Lernende in einer beschr¨

ankten Umgebung, in der er bestimmte

Gesetze ausprobieren, mit vielf¨

altigen Perspektivwechseln arbeiten und Objekte kon-

struieren kann (vgl. [Sch01b], S. 50ff.).

Im Zusammenhang mit der Forschung zur K¨

unstlichen Intelligenz ist in den 80er Jah-

ren der Versuch einer Anpassung des Lernangebotes an den aktuellen Wissensstand der

Lernenden durch so genannte Intelligente Tutorielle Systeme eingef¨

uhrt worden. Da-

bei ist es das Ziel, aus Benutzereingaben ein Kompetenzprofil abzuleiten und durch die

Gegen¨

uberstellung eines ”korrekten“ Modells der Expertise die Kompetenzdefizite zu

diagnostizieren. Auf dieser Basis sollte das Lernangebot auf die aktuellen kognitiven

Lernprozesse besser angepasst werden als konventionelle CBT-Programme mit fest de-

finierten Lernwegen.

Gegen¨

uber dem Behaviorismus wenden sich kognitivistische Theorien mehr den inneren

Vorg¨

angen beim Lernen zu. Die im Rahmen des Kognitivismus entwickelten methodi-

schen Konzepte wie Mikrowelten oder exploratives Lernen lassen sich daher gut mit

konstruktivistischen Ans¨

atzen vereinbaren. Andererseits wird dem Kognitivismus unter-

stellt, einen zu großen Augenmerk auf Methoden der k¨

unstlichen Intelligenz zu legen.

Ein weiterer Kritikpunkt aus konstruktivistischer Sicht ist sein philosophischer Objekti-

vismus, der aussagt, dass die Welt sich ohne das Subjekt konstruieren lasse. Es gibt im

Kognitivismus also keine konstruierte Wahrheit. Wissen wird als etwas aufgefasst, das

extern und unabh¨

angig vom Bewusstsein existiert (vgl. [Blu98], S. 113f.). Damit grenzt

sich die Theorie haupts¨

achlich vom Konstruktivismus ab.

3.2.1.3. Partial-Theorien des Lernens

Auf Basis des vorgestellten kognitionspsychologischen Grundmodells haben sich weiter-

hin einige Partial-Theorien des Lernens entwickelt, die aus ganz unterschiedlichen, mal

wahrnehmungs- und motivationspsychologischen, mal informationstheoretischen Rich-

tungen kommen und meist kleinere, isolierte Gestaltungsaspekte von Lernumgebun-

gen betreffen (vgl. [Sch97b], S. 86). Oftmals beziehen sie sich auf die Informationsre-

pr¨

asentation, wie beispielsweise die Visualisierung, Strukturierung und Granularit¨

at.

Ein Beispiel daf¨

ur ist die Dual-coding Theorie, die auf der Annahme gr¨

undet, dass

es zwei voneinander getrennte kognitive Kodierungssysteme f¨

ur die Aufnahme und Ver-

arbeitung verbaler und visueller Informationen gibt. Die Verarbeitung von sprachlichen

Informationen verl¨

auft sequentiell, w¨

ahrend nicht-verbale Informationen (imaginal, bild-

lich oder visuell-r¨

aumlich) gleichzeitig zur Verarbeitung zur Verf¨

ugung stehen. Demnach

3.2. Die Wissensraummetapher als konstruierende Semantik f¨

ur Lernumgebungen

ist die Aktivierung der Systeme von der Art des Reizes abh¨

angig; eine doppelte Codie-

rung, die beide Systeme aktiviert, erh¨

oht nach dieser Theorie die Behaltenswahrschein-

lichkeit (vgl. [Blu98], S. 98). Die Dual-coding Theorie wird daher h¨

aufig zur Begr¨

undung

eines Multimedia-Einsatzes herbeigezogen (vgl. [Sch97b], S. 88).

Interessant im Zusammenhang mit Hypermedia-Systemen ist die Theorie der kogni-

tiven Plausibilit¨

at, die davon ausgeht, dass in Analogie zu den vernetzten Strukturen

mentaler Modelle direkt auf die Lernf¨

orderlichkeit von Hypermedia geschlossen werden

kann, also die Strukturgleichheit von Text und Denken koginitiven Lernerfolg impliziert.

Blumstengel macht dazu in [Blu98], S. 103, auf die starke Vereinfachung dieser Theorie

aufmerksam: Hypermedia-Netzwerke liegen zwar nicht linear vor, werden aber in jedem

Fall linear gelesen. Ein positiver Effekt ist in diesem Zusammenhang aber in jedem Fall

die M¨

oglichkeit, aufgrund der vernetzten Struktur unterschiedliche Lernwege anbieten

zu k¨

onnen (vgl. ebd.).

3.2.1.4. Konstruktivismus

Ahnlich wie der Kognitivismus, betrachten konstruktivistische Lerntheorien den inter-

nen Prozess des Verstehens und Verarbeitens von Informationen. Jedoch r¨

aumt der Kon-

struktivismus der individuellen Wahrnehmung, Interpretation und Konstruktion inner-

halb des Verarbeitungsprozesses eine deutlich h¨

ohere Bedeutung zu als der Kognitivis-

mus. Hiernach werden beim Lernen koginitive Strukturen modifiziert, indem individuel-

le Konstrukte aufgebaut, verkn¨

upft, reorganisiert und modifiziert werden (vgl. [Kli93],

S. 134).

Wenngleich der Kognitivismus und der Konstruktivismus grunds¨

atzlich die gleiche

Sichtweise vom aktiv lernenden Individuum vertreten, unterscheiden sie sich fundamen-

tal in der Sichtweise der Instruktion: Die Auffassung, dass Wissen nur ein individuelles

Konstrukt ist, das nicht extern bestimmt werden kann, macht die Instruktion als ”Ver-

mittlung von Wissen“ streng genommen unm¨

oglich. Danach d¨

urfte ausschließlich selbst-

gesteuertes, kollektives Lernen erlaubt sein (radikaler Konstruktivismus, vgl. [THH+96],

S. 47).

Mittlerweile hat sich eine gem¨

aßigte Zwischenposition formuliert, die ”[. . . ] vom Kon-

struktivismus die Einsicht in die Bedeutung von handelndem Lernen in komplexen Situa-

tionen und Problemr¨

aumen [. . . ]“ ¨

ubernimmt (vgl. [Wei93], S. 13). Gleichzeitig wird aber

angenommen, dass Lernende hierf¨

ur ad¨

aquate, individuelle mentale Modelle oder andere

elaborierte Strukturen brauchen, deren Erwerb sich durch Instruktion – also der explizi-

ten Darstellung und Organisation des ben¨

otigten Wissens – erleichtern l¨

asst. Gem¨

aßigte

Vorstellungen erlauben daher die Instruktion, um den individuellen Konstruktionspro-

zess anzuregen und zu unterst¨

utzen26. Der Lehrende ist dabei f¨

ur die Aktivierung eines

nat¨

urlichen Lernprozesses verantwortlich und f¨

ordert im Weiteren die Metakoginition

und Multiperspektivit¨

at (vgl. [Kli93], S. 253).

26Obwohl dieser so genannte gem¨

aßigte Konstruktivismus sicherlich eine geeignete Basis f¨

ur das Er-

langen von prozeduralem Wissen innerhalb eines universit¨

aren, allgemeiner gesagt instruierenden

Umfelds darstellt, spiegelt aber gerade die radikale Sichtweise h¨

aufig die Situation wider, die ein

Lernender beim lebenslangen Lernen vorfindet: Alleinorganisierend und ohne Instruktion einer Lehr-

kraft.

3. Terminologiebasierte Spezifizierung von Lernumgebungen

Unter der Annahme, dass das Erkennen nicht nur in einem Kontext stattfindet, sondern

auch mit den Elementen des Kontextes, betonen Theorien des situierten Lernens (si-

tuated cognition) die soziale Eingebundenheit von Lernprozessen. Demnach sollen die in

konstruktivistisch gestalteten Lernsituationen formulierten Aufgaben in Anwendungssi-

tuationen eingebettet werden, die reale Arbeits- und Lebenssituationen widerspiegeln.

Dies soll eine konkrete Assoziation und Transformation des Gelernten in reale Problem-

stellungen und somit auch in eine soziale Umwelt erm¨

oglichen (vgl. [Ede00], S. 287).

Betont werden dabei insbesondere soziale Aspekte des Lernens, das sich im kommunika-

tiven Austausch zwischen Experten und Lerner vollzieht: ”Wissen kann nicht ¨

ubermittelt

werden, sondern es wird in Interaktionen zwischen Experten und Lernenden – in authen-

tischen Situationen – jeweils neu konstruiert und ausgehandelt“ [Ker01], S. 80.

Daraus lassen sich drei Ans¨

atze f¨

ur die Differenzierung alternativer Lernumgebungen

und f¨

ur ihren Entwurf und Entwicklung ableiten (vgl. [Sch97b], S. 81):

1. Das Lernen als Lehrlingsverh¨

altnis (cognitive apprenticeship), wobei die Experten-

rolle entweder durch das System oder durch Dom¨

anenspezialisten eingenommen

werden. Im Kontext eines authentischen Problems wird zun¨

achst (eine modell-

hafte) Vorstellung der Vorgehensweise gezeigt, die ein Experte anwenden w¨

urde.

Anschließend hat der Lernende durch Beobachtung und Nachahmung ¨

ahnliche

konkrete Probleme zu l¨

osen. Das System unterst¨

utzt durch R¨

uckmeldungen und

Hilfestellungen, die – abh¨

angig vom Wissensstand des Lernenden – schrittweise

ausgeblendet werden k¨

onnen.

2. Das Lernen als kommunikatives Handeln in Wissensgemeinschaften (communities

of practice, CoPs): ”A CoP defines itself along three dimensions: its joint enterprise

as understood and continually renegotiated by its members, the relationships of

mutual engagement that bind members together into a social entity, the shared

repertoire of communal ressources (routines, sensibilities, artefacts, vocabulary,

styles, etc.) that members have developed over time“ [Wen98a], S. 2. Hier geht es

darum, selbstorganisiertes und -gesteuertes Lernen in einem sozialen Umfeld zu

erm¨

oglichen, aber Lerngruppen im Sinne der Community of Practice nicht von au-

ßen zu organisieren (vgl. [McD99]). Nach Probst muss in diesem Sinne ein Kontext

f¨

ur selbstorganisierte Gruppen geschaffen werden, d. h. kulturelle Voraussetzungen

zu garantieren, Zeit zur Verf¨

ugung zu stellen, Kontakte zu f¨

ordern, Selbstreferenz

und Reflektion anzuerkennen, spezifische Geschichten und Sprachspiele zu tolerie-

ren (vgl. [Pro87]).

3. Das Lernen mit kognitionsf¨

ordernden Werkzeugen (cognitive tools). Dies sind in-

teraktive multimediale Softwareanwendungen, welche eine direkte Manipulation

von Objekten zulassen, die bestimmte Sachverhalte repr¨

asentieren [Epp01]. Man

kann sie bspw. kopieren, duplizieren oder transformieren, wodurch der kogniti-

ve Verarbeitungsprozess verst¨

arkt, erweitert oder unterst¨

utzt wird. Anhand des

spielerischen oder explorativen Umgangs mit den Werkzeugen wird der Lernende

bei der Konstruktion der eigenen gedanklichen Konzepte unterst¨

utzt. Zur Klasse

der kognitiven Werkzeuge z¨

ahlen beispielsweise Kommunikationswerkzeuge, Sha-

red Applications und Workspaces, die eine gemeinsame synchrone und asynchrone

3.2. Die Wissensraummetapher als konstruierende Semantik f¨

ur Lernumgebungen

Bearbeitung von Dokumenten erm¨

oglichen, so genannte Conceptmanager bspw.

zum Erstellen von MindMaps sowie ”P¨

adagogische Agenten“, die – konfigurierbar

– beim Lernen anleiten und zum Beispiel durch Informationsrecherche unterst¨

utzen

k¨

onnen. Eine umfangreiche Beispielsammlung von kognitionsf¨

ordernden Werkzeu-

gen findet sich bei Schulmeister in [Sch97b], S. 341ff. Prinzipiell kann jedoch jedes

Mediensystem, das neben der Wiedergabe auch die Bearbeitung und Speicherung

von Informationen erm¨

oglicht, als kognitionsf¨

orderndes Werkzeug f¨

ur Lernakti-

vit¨

aten angesehen werden, wenn der Lernprozess an sich dadurch gef¨

ordert wird

(vgl. [Ker01], S. 247). Einfachste Unterst¨

utzungsfunktionen sind bspw. das Unter-

streichen oder Hervorheben von Textstellen, Annotationen an Objekten oder das

Verkn¨

upfen von Objekten durch Zeiger.

3.2.1.5. Ein strukturgenetischer Wissensbegriff

Sowohl die kognitivistische als auch die konstruktivistische Auffassung des Lernpro-

zesses geht von einer Ver¨

anderung kognitiver Strukturen beim Lernenden aus. Erstere

vernachl¨

assigt jedoch die internen Verarbeitungprozeduren, wohingegen aus konstrukti-

vistischer Sicht die M¨

oglichkeit der Wissensweitergabe und die Wissensaufnahme, also

ein Wissenstransfer, nicht Bestandteil der Theorie ist. Die postulierte Verankerung der

Wahrnehmung in individuelle, situative und soziale Kontexte l¨

asst jedoch einen Wis-

sensbegriff notwendig erscheinen, der auf einer erweiterten Grundlage basiert. Er muss

uber die Personengebundenheit hinaus eine Objektivierung von Wissen umfassen, damit

es ¨

offentlich gemacht und Kommunikation zwischen Menschen daran ausgerichtet wer-

den kann. Um dieses erkl¨

aren, m¨

ussen demnach zwei ¨

ubergeordnete Formen von Wissen

unterschieden werden: (1) Personengebundenes Wissen, das auf dynamischen kogniti-

ven Strukturen eines Individuums beruht und nur individuell zug¨

anglich ist, und (2)

offentliches Wissen, das durch vereinbarte Regeln systematisch verbalisiert und explizit

artikuliert werden kann.

Der ungarische Wissenschaftler Polanyi f¨

uhrte diesbzgl. in [Pol66] erstmalig den Begriff

tacit knowing ein, aus dem sich in anschließenden Diskussionen der Term tacit know-

ledge (implizites Wissen) entwickelte und der eine Art von Wissen beschreibt, dass sehr

schwierig zu artikulieren, sehr spezifisch und außerdem von pers¨

onlichen F¨

ahigkeiten und

Erfahrungen eines Individuums abh¨

angig ist: ”We know more than we can tell“ [Pol66],

S. 4. Beispiele f¨

ur implizites Wissen sind Eindr¨

ucke ¨

uber die Kultur einer Lerngruppe

oder das ”Bauchgef¨

uhl“ ¨

uber den Umfang einer gestellten Aufgabe.

Der komplement¨

are Part, das explizite Wissen (explicit knowledge, vgl. [Pol85]) ist

leichter kommunizierbar und kann verbal oder mittels Symbolsystemen weitergegeben

werden, z. B. in Form von Daten, Informationen oder Dokumenten. Beispiele sind die in

einer Vorlesung vermittelten Methoden und Formeln oder die zu erreichenden Punkte

einer vollst¨

andig gel¨

osten ¨

Ubungsaufgabe. Auch eine Normsprache f¨

allt in diese Klassi-

fikation27.

27Wobei man bei diesem Beispiel expliziten Wissens noch einmal zwischen dem kollektiven Wissen

um die Bedeutung der Begriffe einer Normsprache und dem formalisierten Wissen um die per

Aussagenlogik definierten semantischen Beziehungen und Regeln des Vokabulars unterscheiden kann.

3. Terminologiebasierte Spezifizierung von Lernumgebungen

Diese Klassifikation von Wissen hat sich in der Wissenschaft zur Erkl¨

arung der Gene-

rierung neuen Wissens durchgesetzt (vgl. [Non91], [NT97], [Sve98], S. 98, [Sch00a], S.30

und [Br¨

a03], S. 29). Nicht zuletzt dadurch, dass ein solches strukturgenetisches Wissens-

verst¨

andnis ein hohes Integrationspotenzial aufweist zwischen Lerntheorien und Theori-

en des Wissensmanagements (vgl. [SR01]): Explizites Wissen kann zum Gegenstand von

Planung, Steuerung und Kontrolle werden und somit den Forderungen eines wirtschaft-

lich orientierten Managements gen¨

ugen (bspw. [NT97] oder [PRR03]). Dar¨

uber hinaus

ist es ebenfalls kompatibel zur Auffassung des Lernens als kognitionsver¨

andernden Pro-

zess, der Grundlage des Kognitivismus und Konstruktivismus ist.

Nonaka und Takeuchi beschreiben in [NT97] auf diesem Wissensverst¨

andnis aufbau-

end eine Theorie, wie pers¨

onliche Kenntnisse geteilt und in einen sozialen Kontext28

eingebracht werden k¨

onnen, um schließlich neues verf¨

ugbares Wissen zu produzieren,

aus dem wiederum jeder Einzelne individuelles Wissen ableiten kann. Diese Theorie soll

an dieser Stelle kurz wiedergegeben werden, da sie u. a. Aufschluss dar¨

uber geben kann,

wie Lernen in selbstorganisierten Gruppen stattfinden kann und konkrete Handlungsfel-

der aufzeigt, auf denen eine virtuelle Umgebung diese Prozesse unterst¨

utzen kann29.

Ihr Modell besteht in der Hauptsache aus vier Formen der Wissensumwandlung zwischen

implizitem und explizitem Wissen, n¨

amlich Sozialisation, Externalisierung, Kombination

und Internalisierung:

Sozialisation Wandlung von implizitem zu implizitem Wissen auf nonverbaler Ebene

durch Beobachtung und Nachahmung. Hierdurch k¨

onnen mentale Modelle und

Fertigkeiten entstehen. Dies geht vor allem durch den Aufbau physischer N¨

ahe und

direkter Interaktionen, wodurch ein Interaktionsfeld aufgebaut wird (vgl. [SM02],

S. 129f., [NT97], S. 85).

Externalisierung Wandlung von implizitem zu explizitem Wissen durch die Objektivie-

rung impliziten Wissens mithilfe von Modellen, Metaphern, Analogien und Hy-

pothesen. Dadurch wird bisher nicht artikulierbares Wissen soweit aufbereitet,

dass es kommuniziert und weitergegeben werden kann. Dieser Prozess wird opti-

mal durch Dialog, Interaktion und kollektiver Reflexion vorangetrieben, indem die

Beteiligten bspw. versuchen, ein gemeinsames Konzept zu konstruieren. Insbeson-

dere bei Konzepten, bei deren Entwicklung Deduktion und Induktion miteinander

verkn¨

upft werden (vgl. [NT97], S. 77ff.).

Kombination Wandlung von explizitem zu explizitem Wissen auf Ebene der Daten, In-

formationen und Dokumente. Durch Neustrukturierung und Verkn¨

upfungen dieser

Informationen untereinander entsteht aktualisiertes oder neues explizites Wissen,

bspw. durch ¨

Ubertragung von Erkenntnissen auf ein anderes Fachgebiet.

28Nonaka und Takeushi erkl¨

aren ihre Theorie im sozialen Kontext einer Organisation. Sie kann jedoch

ebenso gut auf Lerngruppen respektive Wissensgemeinschaften im Allgemeinen bezogen werden.

Aktuelle lerntheoretische Ans¨

atze wie die verteilte Kognition teilen mit der Theorie von Nonaka und

Takeushi den Gedanken, dass das Wissen in einer Lerngruppe nicht in identischer Form bei allen

Lernern vorliegt, sondern auf alle Lerner einer (nicht disjunkten) Gruppe verteilt ist (vgl. [KM07]).

29Die M¨

oglichkeiten und Grenzen von Interventionen auf solch fragile soziale Konstrukte wie selbstor-

ganisierte Wissensgemeinschaften zeigt Romhard mithilfe dieses Modells in [Rom02], S. 53ff.

3.2. Die Wissensraummetapher als konstruierende Semantik f¨

ur Lernumgebungen

Internalisierung Wandlung von explizitem zu implizitem Wissen durch Lernen und dem

Machen eigener Erfahrungen. Diese Transformation ¨

ahnelt der Sozialisation, nur

dass die externen Informationen in einer konkreten, artikulierten und expliziten

Form vorliegen. Durch einen Austausch innerhalb sozialer Kontexte wie Lerngrup-

pen oder ganze Unternehmungen kann hierdurch kollektives Wissen geschaffen

werden, basierend auf gemeinsamen mentalen Modellen und gemeinsames Know-

how.

Das Wissen wird also zun¨

achst jeweils individuell erzeugt, kann aber zur Nutzbarma-

chung mithilfe geeigneter Mechanismen explizit gemacht und ausgetauscht werden. Die

vier Formen der Wissensumwandlung ergeben in ihrer Kombination den Effekt einer

Spirale (vgl. Abb. 3.5), welche die Dynamik der Evolution einer Wissensgemeinschaft

hinsichtlich ihrer Gemeinschaftskultur und ihres kollektiven Wissens beschreibt.

!"#$!%!&'(

)!(('* +,%!-$!(!'./*0 12&'.*-$!(!'./*0

3*&'.*-$!(!'./*0 4,"5!*-&!,*

!"#$!%!&'(

)!(('*

'2#$!%!&'(

)!(('*

'2#$!%!&'(

)!(('*

6,*

Abbildung 06: Vier Formen der Wissensumwandlung und die Wissensspirale

(Güldenberg 2001 S.233) (vgl. auch Nonaka/Takeuchi 1997 S.75 und S.84)

"#$!%&'()*!+,&-!./*!0/*121!#*-!312)#45,!-,)!6/7,18,'1(,/*!18'!),*)!91*-8#*:!./*!,$;8,7,()$!

7#! ,$;8,7,()$! 9,'')*! :)*1**(<! =),! -)&! ),*! %&>15&#*:'1#'(1#'45! '(1((>,*-)(! 1#'! -)$! $)*(18)!

?/-)88)! #*-! ()45*,'45)! @)&(,:2),()*! )*('()5)*A! B)&*)*! >,*-)(! 5,)&=),! 1#>! */*.)&=18)&! %=)*)!

-#&45!C)/=145()*!#*-!014515$)*!'(1((A!%,*)!'/845)!D&(!-)'!B)&*)*'!>,*-)(!7#$!C),';,)8!,*!

-)&!C)&#>'1#'=,8-#*:!'(1((<!+)**!),*!D#'7#=,8-)*-)&!7#'1$$)*!$,(!-)$!?),'()&!1&=),()(!#*-!

-)'')*!C)&#>')&>15&#*:)*!#*-!E1*-8#*:'2/$;)()*7)*!,*!-)&!F&1G,'!)&>H5&(!#*-!-1&1#'!8)&*(A!

I.:8A!0/*121J312)#45,!KLLM!6AMNO!!

P,)! %G()&*18,',)&#*:! ,'(! ),*)! +),()&)! D&(! -)&! 9,'')*'#$+1*-8#*:<! -,)! ./*! 0/*121! #*-!

312)#45,! :)*1**(! +,&-A! C),! ,5&! +,&-! -#&45! D&(,2#81(,/*! ,$;8,7,()'! ,*! )G;8,7,()'! 9,'')*!

:)+1*-)8(<!-A!5A!,$;8,7,()'!9,'')*!+,&-!7#!?/-)88)*<!?)(1;5)&*<!D*18/:,)*!/-)&!EQ;/(5)')*!

.)&1&=),()(A! P,)')&! F&/7)''! +,&-! $),'()*'! -#&45! P,18/:<! R*()&12(,/*! #*-! S)>8)G,/*!

./&1*:)(&,)=)*<! ,*-)$! -,)! C)(),8,:()*! .)&'#45)*! ),*! :)$),*'1$)'! T/*7);(! 7#! 2/*'(&#,)&)*A!

I.:8A! 0/*121J312)#45,! KLLM! 6AMMO! P,)! %G()&*18,',)&#*:! ,'(! -)&! ),:)*(8,45)! 6458U'')8! 7#&!

9,'')*''451>>#*:<!-1!,$;8,7,()'!9,'')*!7#!)G;8,7,()*!T/*7);()*!:)+1*-)8(!+,&-<!+/=),!-#&45!

')V#)*7,)88)*!W)=&1#45!./*!?)(1;5)&*<!D*18/:,)*!#*-!?/-)88)*!),*)!)>>,7,)*()!#*-!)>>)2(,.)!

implizites Wissen explities Wissen

explizites

Wissen

implizites

Wissen

von

innerlich äußerlich

individuell Sozial/kollektiv

Ich

Wir

Abbildung 3.5.: Vier Formen der Wissensumwandlung (eigene Darstellung in Anlehnung

an [NT97], S. 84 und [Rom02], S. 64).

3. Terminologiebasierte Spezifizierung von Lernumgebungen

3.2.2. Wissensr¨

aume als konstruierender Theoriebestandteil

”Knowledge needs a physical context if its to be created [. . . ]“ [NTK01], S. 22. Nonaka

et al. begr¨

unden damit das Konzept des ba30. W¨

ortlich ¨

ubersetzt bedeutet ”ba“ Ort;

dieser Ort ist jedoch nicht nur im physischen, sondern ebenso im virtuellen und menta-

len Sinne gemeint. Ein Ort im physischen Sinn kann ganz klassisch als real existierender

Raum angesehen werden. Dieser wird auf virtueller Ebene erg¨

anzt durch bspw. virtuel-

le Kontakte, Nachrichten und Mitteilungen oder Dokumenten und auf mentaler Ebene

zum Beispiel durch geteilte Erfahrungen und gemeinsame Ideen. Das ba ist dabei in ste-

tigem Wandel: Es ist immer offen und kann durch die Beteiligten nach Belieben betreten

und verlassen werden, was ihm einen Ad-hoc-Charakter verleiht (vgl. [Ren03], S. 100f.).

Im Zentrum des Konzeptes steht dabei nicht nur der Austausch von Wissen, sondern

vor allem die Generierung von Wissen. Implizites Wissen kann durch Externalisierung

in gemeinsame Handlungsr¨

aume eingebracht und dort kombiniert werden. Von diesem

Gruppenwissen kann durch Internalisierung neues individuelles Wissen erzeugt werden

(vgl. Abb. 3.5). Zusammengefasst stellt das ba also einen Bezugsrahmen bereit, auf den

sich die Beteiligten beziehen k¨

onnen und innerhalb dessen sie durch Interaktion Wissen

entwickeln und generieren k¨

onnen.

Virtuelle Wissensr¨

aume implementieren diesen Bezugsrahmen. Sie schaffen eine Um-

gebung, die durch die Beteiligten gestaltet und weiterentwickelt werden kann, eben-

so wie das in ihr enthaltene Wissen. Die Nutzung der Raum-Metapher in computer-

gest¨

utzten kooperativen Arbeits- und Lernumgebungen ist h¨

aufig intuitiv verst¨

andlich,

da sich virtuelle R¨

aume durch dieselben Eigenschaften auszeichnen wie reale (vgl. hier-

zu [GR98], [PSBWW99] und [Ham02]):

âEin virtueller Raum ist persistent und hat feste Grenzen

âDer virtuelle Raum dient sowohl als Strukturierungsinstrument f¨

ur die in ihm

enthaltenen Objekte, wie z. B. Dokumente oder Personen, als auch als Ort der

Arbeit mit diesen Objekten (Handlungsraum)

âVirtuelle R¨

aume sind aufgrund ihrer Strukturierbarkeit an pers¨

onliche oder grup-

penspezifische Vorlieben und verschiedenste Arbeitssituationen anpassbar

âInnerhalb eines virtuellen Raums ist sich eine Person allen anderen Mitbenutzern in

diesem Raum bewusst und kann etwas ¨

uber die Aktivit¨

at dieser Personen erfahren

bzw. mit ihnen in Verbindung treten (Awareness)

âDer virtuelle Raum bietet sowohl die M¨

oglichkeit, den Zugang zum Raum selbst

als auch den Zugang zu den im Raum enthaltenen Objekte einzuschr¨

anken (vgl.

hierzu insbesondere [Ham04]).

Im Folgenden sollen einzelne Aspekte virtueller R¨

aume – Strukturierung, kognitive Un-

terst¨

utzung und soziale Aspekte – n¨

aher erkl¨

art werden.

30Seinen Ursprung hat das Konzept des ”ba“ in der japanischen Philosophie und ist nach einigen Wei-

terentwicklungen Grundlage einiger Arbeiten zum Wissensmanagement geworden (neben [NTK01]

vgl. bspw. [KIN00], S. 176ff. und [Ren03], S. 100ff.).

3.2. Die Wissensraummetapher als konstruierende Semantik f¨

ur Lernumgebungen

3.2.2.1. Semantische Strukturierung von R¨

aumen und Informationen

R¨

aumliche Anordnung geh¨

ort zu den m¨

achtigsten Interventionsfeldern der Wissensor-

ganisation: Der Raum kanalisiert Kommunikation und erm¨

oglicht oder beschr¨

ankt die

Strukturierung, Verteilung und Vermittlung von Informationen (vgl. [Roe02], S. 95). So-

mit ist er in der Lage, verschiedene Arbeits- und Lernkontexte herzustellen, indem unter-

schiedliche Sichten auf Informationen ausgestaltet werden (vgl. [Zac99]). Dar¨

uber hinaus

dienen geeignete semantische Informationsstrukturen auf lange Sicht auch dem Erinnern

(vgl. [Ham02], S. 26).

Die Persistenzschichten raumbasierter CSCW/L-Anwendungen verwalten daher i. d. R.

nicht nur die Inhalte (Content) an sich, sondern m¨

ussen auch objektrelationale Struk-

turen abbilden und Funktionen zu ihrer Verwaltung. Persistente Strukturen lassen sich

sowohl ¨

uber R¨

aume als auch ¨

uber Informationen respektive Informationsobjekte (know-

ledge units) bilden: ”The repository structure also includes the schemes for linking and

cross-referencing knowledge units. These links may represent concepual associations, or-

dered sequences, causality or other relationships depending on the type of knowledge

being stored.“ [Zac99], S. 46.

Wie reale R¨

aume auch, k¨

onnen ihre virtuellen Pedanten T¨

uren zu benachbarten

R¨

aumen oder Unterr¨

aumen haben. Anders als in der Realit¨

at, k¨

onnen in einer vir-

tuellen Umgebung sogar T¨

uren eingesetzt werden, die als Hyperlink auf entferntere

R¨

aume verweisen. Benutzer k¨

onnen sich ¨

uber diese Verkn¨

upfungen – entsprechende Zu-

trittsrechte vorausgesetzt – in diesen Raumstrukturen bewegen. Somit k¨

onnen virtuelle

R¨

aume grundlegend frei entlang einer semantischen Struktur oder eines didaktischen

Konzepts miteinander verbunden werden. Diese Verkn¨

upfbarkeit virtueller R¨

aume bil-

det ein zentrales Gestaltungselement f¨

ur Lern- und Arbeitsumgebungen, da durch sie

raum¨

ubergreifende, kontextbezogene semantische Aufbau- und organisatorische Ablauf-

strukturen nachgebildet bzw. konstruiert werden k¨

onnen, die f¨

ur die Arbeit und das

Lernen von Einzelnen und Gruppen gleichermaßen von Nutzen sind.

Abbildung 3.6 veranschaulicht dieses am Beispiel individueller Sichten f¨

ur Student

und Dozent: ¨

Uber hierarchische Raumkonstrukte werden zwei unterschiedliche Makro-

strukturen konstruiert, die ¨

uber Hyperlinks auf verschiedene Einstiegspunkte in die Mi-

krostruktur (hier: Einfacher Raumkomplex einer Lehrveranstaltung) verweisen. Die Ma-

krostrukturen werden in diesem Fall durch das System selbst oder ¨

uber einen Admi-

nistrator zentral verwaltet; die Kursraumstruktur kann durch den Dozenten selbst frei

gestaltet werden. Virtuelle R¨

aume k¨

onnen somit also eine semantische, logische und zeit-

liche Gruppierung einer Anzahl von Objekten, Personen und strukturellen Beziehungen

darstellen (vgl. [RHS05]).

Den Aufbau virtueller Raumkomplexe kann der Benutzer selbst vornehmen, indem

er Unterr¨

aume oder T¨

uren einf¨

ugt; er kann allerdings auch durch einen Administrator

ubernommen oder nach einem vom System vorgegebenen ”Bauplan“ automatisch vorge-

nommen werden. Dar¨

uber lassen sich – wie im Beispiel gezeigt – Anordnungen virtueller

R¨

aume beschreiben, also auch bestimmte Sichten auf verschiedene Wissensorganisatio-

nen vorstrukturieren. In der Benutzungsoberfl¨

ache kann die Wahrnehmung der Benutzer

dann dahingehend gesteuert werden, dass diese in einer derartig aufbereiteten Sicht die

3. Terminologiebasierte Spezifizierung von Lernumgebungen

Aufbau- und Ablaufstrukturen von didaktischen Szenarien bis hin zu vollst¨

andigen Lehr-

veranstaltungsformen problemlos erkennen k¨

onnen31.

Die didaktische Spannweite dieses Ansatzes ist weitreichend und umfasst theoretisch

die gesamte Skala der Selbstkontrolle: Je nach rechte- oder sichtenspezifischer Ein-

schr¨

ankung k¨

onnen somit verschiedenste Szenarien umgesetzt werden, bspw. ein frei

gestaltbares Jour Fixe-Konzept (vgl. [HKSE03]), eine ablauforganisatorisch strikt vor-

definierte erw¨

agungsdidaktische Pyramidendiskussion (vgl. [HH05]) oder einfach nur die

Bereitstellung von Materialien einer Lehrveranstaltung zum Herunterladen.

Hyperstrukturen k¨

onnen nicht nur R¨

aume, sondern auch Informationsobjekte mit-

einander auf verschiedene Art und Weise in Beziehung zueinander setzen. So genannte

Links (shadow objects) bieten Verkn¨

upfungen zu einzelnen Objekten und Dokumenten,

unabh¨

angig ihrer umgebenden Raumstruktur. Dadurch wird eine mehrfache logische

Pr¨

asenz von Informationen trotz einer (nicht zwangsl¨

aufigen) physikalischen Einmalig-

keit erm¨

oglicht, wie sie f¨

ur Redundanz von Informationen bzw. Wissen in unterschied-

lichen semantischen und didaktischen Kontexten notwendig ist (vgl. hierzu [NT97],

S. 188ff.). Eine zweite M¨

oglichkeit der Referenzierung von Objekten kann auch durch

dynamische Attribut-Zeiger erfolgen, sowohl ein- als auch mehrdimensional32.

Seite 6 Einführung des Systems koaLA (ko-aktive Lern- und Arbeitsumgebung)

Abbildung 2: Virtuelle Wissensräume haben eine Mikrostruktur, in der Wissensobjekte intern organi-

siert werden können. Durch raumübergreifende Verlinkung und Freigabe von Wissensobjekten können

diese internen Strukturen miteinander verknüpft werden. Gänge können Räume zu Clustern verbinden,

wohingegen rollenspezifische Sichten diese Räume in verschiedenen Kontexten verfügbar machen und

somit Makrostrukturen definieren.

Durch die konzeptionelle und mittels Protokolladaptern umgesetzte technologische Generalisie-

rung von Informationsträgern (also den Wissensobjekten) ist die grundlegende Voraussetzung

für die geforderte szenarienübergreifende freie Kombinierbarkeit und Wiederverwendbarkeit

von Informationen gegeben, und somit auch eine durchgängige und medienbruchfreie Verfüg-

barkeit während des Lernprozesses innerhalb der hybriden Lernumgebung.

Prinzipiell können Informationen somit aus den in Systemkomponenten vorgegeben semanti-

schen Kontexten/Mikrostrukturen herausgelöst und in anderen Kontexten semantisch neu struk-

turiert werden. Wie in Abbildung 3 gezeigt, können multimediale Lern- und Kommunikations-

inhalte durch die Studierenden und Dozierenden ohne großen Aufwand sogar lernnetz- und

plattformübergreifend kombiniert werden.

Abbildung 3.6.: Wissensraumstrukturen

31Abh¨

angig von der Implementierung der Benutzungsschnittstelle kann die Raum-Metapher dabei auch

in der grafischen Oberfl¨

ache der Komponenten zum Ausdruck kommen, sie muss es aber nicht.

32Im mehrdimensionalen Fall – also mehrere Referenzen pro Objekt-Attribut – lassen sich entsprechende

Konstrukte wie Queues, Stacks oder auch einfache Arrays als Attributwert anwenden.

3.2. Die Wissensraummetapher als konstruierende Semantik f¨

ur Lernumgebungen

3.2.2.2. Generalisierung von Informationstr¨

agern

Durch eine Generalisierung als Informationsobjekt33 k¨

onnen Informationen verschie-

denster Quellen und Medienformate in den virtuellen Handlungs- und Wahrnehmungs-

raum der Teilnehmer eingebunden und miteinander verkn¨

upft werden. Ein Informati-

onsobjekt kann also ein Textdokument, ein Videofilm, ein Forenbeitrag oder auch der

Abschnitt eines Lernweges sein, dessen Lernobjekte in externen Lernumgebungen vor-

gehalten werden34.

Es ergeben sich somit Potenziale hinsichtlich der Schaffung von Wissen, da ¨

uber diese

Generalisierung Informationen unabh¨

angig ihrer Herkunft und ihres Formats semantisch

kombiniert und (re-)strukturiert werden k¨

onnen. Auf individueller Ebene wird die Ex-

ternalisierung mentaler Modelle unterst¨

utzt, auf kooperativer Ebene die Wissenstrans-

formation ”Kombination“ (vgl. Abb. 3.7).

WBT Fallstudien Wiki

Internet

Intranet + Verzeichnisdienst

virtueller Wissensraum

Abbildung 3.7.: Durch Generalisierung k¨

onnen Informationen unabh¨

angig von Herkunft

und Format zur Externalisierung mentaler Konzepte und zur Kombina-

tion expliziten Wissens in Gruppen genutzt werden.

33Vgl. hierzu die Definition von Zack, die in dieser Arbeit bereits auf S. 61 angef¨

uhrt wurde.

34Lernobjekte werden so aus vorgegebenen Lernnetzen und Aggregationsebenen herausgel¨

ost und in

virtuellen R¨

aumen zu einem Objekt der Konstruktion. Eine solche Integration externer Lernplatt-

formen in den virtuellen Wissensraum wird in [RHS05] beschrieben.

3. Terminologiebasierte Spezifizierung von Lernumgebungen

3.2.2.3. Medienfunktionen und Rechtemanagement

Virtuelle R¨

aume dienen also – wie dargelegt – als Instrument, um Wissen zu struktu-

rieren und individuelle und kollektive Lernprozesse durch die Schaffung semantischer

Kontexte zu f¨

ordern. Daneben haben sie aber auch noch eine zweite wichtige Funk-

tion (vgl. [PSBWW99], S. 108, [Ham02], S. S. 41ff.): Sie bieten als ”Ort der Arbeit“

einen Handlungsraum (activity space) f¨

ur die direkte Manipulation von Objekten (vgl.

[Shn83])35. Dadurch k¨

onnen Eigenaktivit¨

at und konstruktives, selbstbestimmtes Vor-

gehen unterst¨

utzt oder Kooperation und Wissenstausch erm¨

oglicht werden, was interne

Verarbeitungsprozesse nicht nur beim Einzelnen, sondern auch in der Gruppe beg¨

unstigt

(verteilte Kognition, vgl. [Wes01], S. 196, [Ker01], S. 166, [Hes04], S. 16, [KM07]). Bei-

spielsweise k¨

onnen Lerner gemeinsam eine explizite Repr¨

asentation des verteilten Wis-

sens einer Gruppe in Form von Diagrammen oder Begriffsgraphen aufbauen. Dazu

m¨

ussen sie technisch in die Lage versetzt werden, eigene Objekte zu erzeugen, Ver-

kn¨

upfungen zwischen Objekten zu erstellen, diese zu arrangieren und zu transportieren.

Die Handlungen der Lernenden an und mit Objekten m¨

ussen zudem synchronisierbar

sein.

Hampel beschreibt dazu in [Ham02], S. 41ff., eine Reihe prim¨

arer Medienfunktionen

auf Objekten, die – entweder individuell oder kooperativ ausgef¨

uhrt – zugunsten interner

Verarbeitungsprozesse (kognitive Operationen) wirken k¨

onnen:

Erzeugen M¨

oglichkeiten des Entwurfs von Zeichen, wie bspw. Schreiben, Anfertigen

von Skizzen und Konstruieren von Modellen. Wichtig hierbei ist die dauerhafte

Persistenz der erstellten Objekte im Handlungsraum f¨

ur die Zeit des Lernprozesses.

L¨

oschen Erzeugte Objekte m¨

ussen wieder gezielt aus dem Wahrnehmungsfeld des Be-

nutzers entfernt werden k¨

onnen, bspw. bei veralteten oder redundanten Informa-

tionen.

Arrangieren bedeutet das ”In-Beziehung-Setzen“ verschiedener Objekte miteinander,

um Zusammenh¨

ange im Wahrnehmungsfeld aufzunehmen. Objekte k¨

onnen dazu

r¨

aumlich gruppiert werden.

Verkn¨

upfen Objekte k¨

onnen auch – unabh¨

angig ihres r¨

aumlichen Kontextes – auch ¨

uber

Attribute (z. B. gemeinsame Tags) miteinander verkn¨

upft werden.

Ubertragen Aktiver Austausch von Objekten zwischen Benutzern durch direkte Wei-

tergabe.

Zugreifen Zugriff auf Materialien ohne Einwirkung eines Bereitstellers, bspw. auf ein in

einem Raum abgelegtes Objekt.

Synchronisation Abgleichen bzw. Aktualisieren von Darstellungen auf R¨

aume und Ob-

jekte, um R¨

uckmeldungen ¨

uber Handlungen an Objekten und gegenseitige Wahr-

nehmung von Kooperationspartnern zu erlangen.

35Konstruktivisten kn¨

upfen hohe Erwartungen an Methoden der direkten Manipulation von Objekten,

da sie dem Paradigma folgen, Lernen nicht vom Tun zu trennen (vgl. [Sch97b], S. 341).

3.2. Die Wissensraummetapher als konstruierende Semantik f¨

ur Lernumgebungen

Ein f¨

ur die Restrukturierung von Informationstr¨

agern besonders wichtiges Werkzeug

ist eine Zwischenablage, im Kontext virtueller Wissensr¨

aume auch manchmal als Ruck-

sack paraphrasiert. Objekte k¨

onnen – entsprechende Zugriffsrechte vorausgesetzt – als

Original, Kopie oder Verkn¨

upfung von einer Umgebung in einen anderen bzw. einen

weiteren Kontext ¨

ubertragen werden, indem sie in die Zwischenablage aufgenommen

und am Zielort abgelegt werden. Auf diese Art k¨

onnen Objekte bspw. von individuel-

len Wissensr¨

aumen in kooperative eingebracht werden oder vice versa. Eine M¨

oglichkeit

zur Unterstrukturierung dieses persistenten Zwischenspeichers versetzt den Benutzer in

die Lage, Informationen bereits im Moment der Aufnahme zu kontextualisieren. Diese

Informationen k¨

onnen dann in andere R¨

aume – als einzelnes Objekt oder als Struktur –

ubertragen und somit in individuelle oder kooperative Lernszenarien (wieder) verwendet

werden (vgl. hierzu auch Abb. 6.1).

Der Zugriff auf virtuelle R¨

aume und die in ihnen gespeicherten Objekte muss gezielt

eingeschr¨

ankt werden k¨

onnen. Ein ¨

ubliches Vorgehen ist das Arbeiten mit Benutzergrup-

pen und Rollen, an die bestimmte Rechte gebunden werden. Auf diese Weise k¨

onnen

f¨

ur eine Gruppe von Nutzern bzw. Lernenden abgestufte Zugriffsrechte auf virtuelle

Lernr¨

aume und darin enthaltene Materialien eindeutig definiert und gegen¨

uber anderen

Nutzern abgegrenzt werden, so dass ein hochflexibles Zugriffsrechtesystem umgesetzt

werden kann. Dabei lassen sich die Rechtestrukturen zentralen Kategorien zuordnen

(vgl. [Ham04]):

âVererbung von Rechten durch eine gegebene Gruppenstruktur

âTransfer (Delegation) des Rechts, explizit neue Rechte setzen zu d¨

urfen

âVererbung und Ableitung von Rechten durch a) die Umgebung oder b) einem fixen

Referenzobjekt.

Damit sind die Grundelemente zur Einschr¨

ankung virtueller Wissensr¨

aumen gegeben,

mit denen rollenspezifische Sichten auf Lernszenarien implementiert werden k¨

onnen.

3.2.2.4. Gegenseitige Wahrnehmung

Virtuelle R¨

aume sollten mit Mechanismen ausgestattet sein, die es den Lernenden erm¨

og-

lichen, Anwesenheit und Aktivit¨

aten anderer Lernender wahrzunehmen und mit ihnen

in Kontakt zu treten. Neben der Anwesenheit anderer Nutzer im Raum ist eine zeitnahe

Visualisierung von Handlungen an R¨

aumen und Materialien wichtig. Die Auswirkungen

des Erstellens, L¨

oschens von R¨

aumen sowie des Verschiebens, Kopierens, r¨

aumlichen

Arrangierens und L¨

oschens von Objekten sind in kooperativen Szenarien schnell f¨

ur alle

Anwesenden anzupassen. Dies kann synchron erfolgen, aber auch asynchron. So macht

es bspw. Sinn, neue Materialien hervorzuheben (graphisch z. B. durch eigene Farbe oder

ein Symbol), Ver¨

anderungen an Materialien k¨

onnen geeignet in Attributen kenntlich ge-

macht werden. Auf neue Annotationen an Materialien kann durch ad¨

aquate Darstellung

der Materialien selbst hingewiesen werden. Diskussionsbeitr¨

age m¨

ussen einem Mitglied

zugeordnet werden k¨

onnen, das diese verfasst hat. Ebenso sind neue Beitr¨

age in geeigne-

ter Form zu kennzeichnen. Wenn es f¨

ur die Nutzer in einer virtuellen Arbeitsumgebung

3. Terminologiebasierte Spezifizierung von Lernumgebungen

verschiedene Benutzerrollen gibt, so sind diese an der Darstellung der Benutzer zu ver-

deutlichen (vgl. [Ham02], S. 121f.).

Ein interessante Idee f¨

ur asynchrone Wahrnehmung liefert das COMETS-Projekt an

der Freien Universit¨

at Berlin (vgl. [Rad05]): Die Idee von COMETS liegt darin, Lernende

miteinander zu vernetzen, die sich im gleichen Arbeits- oder Lernkontext befinden oder –

und das ist das besondere – k¨

urzlich befunden haben. Durch ein ”Schweifmodell“ werden

Nutzer sichtbar, die einen bestimmten Kontext k¨

urzlich zuvor besucht haben und somit

noch als Hilfesteller dienen k¨

onnen. Dabei regelt jeder Nutzer seine ”Schweifl¨

ange“ selbst

und bestimmt damit, f¨

ur welchen Zeitraum er f¨

ur diesen Kontext Ansprechpartner sein

m¨

ochte.

3.2.3. Technisierung virtueller Wissensr¨

aume

Die Metapher des kooperativen virtuellen Wissensraums ist auf raumbasierte Spieleum-

gebungen im Netz zur¨

uckzuf¨

uhren, den so genannten Multi User Dungeons (MUDs) der

80er Jahre (vgl. [LAGS99]). Ein MUD besteht aus miteinander verbundenen R¨

aumen,

die Objekte enthalten, die mit einer Vielzahl von Eigenschaften ausgestattet sind. Be-

nutzer konnten sich innerhalb dieser R¨

aume bewegen und die Objekte betrachten und

manipulieren. Durch die Interaktion seiner Benutzer mit anderen Benutzern, Objek-

ten und R¨

aumen ist ein MUD ein hochgradig interaktives, sich st¨

andig ver¨

anderndes

System. Ein hierarchisches Rechtemanagement erm¨

oglichte es dem Administrator eines

MUDs, bestimmte Benutzer mit der F¨

ahigkeit auszustatten, neue R¨

aume und Objekte

zu erschaffen. Auf diese Weise wurden die Benutzer in die Ausgestaltung der virtuellen

Welt mit einbezogen, was eine st¨

arkere Beziehung der Benutzer zu ihren Avataren, den

R¨

aumen und Objekten im MUD schaffte.

War die Benutzungsschnittstelle der MUDs noch textbasiert – bspw. bef¨

ordert das

Kommando @join <Benutzer> den eigenen Avatar direkt in den Raum, in dem sich

auch <Benutzer> aufh¨

alt – fanden sie mit den MOOs (MUD Object Oriented) ihre

objektorientierte Umsetzung und mit ihnen auch zu graphischen Oberfl¨

achen. Somit sind

MUDs quasi die Vorl¨

aufer der heutigen Massive Multiplayer Online Games (MMOGs)

und haben die Grundlage zur Erschaffung von reich ausgearbeiteten Rollenspiel- und

anderen virtuellen Welten wie Second Life36 gelegt.

Analog dazu sind im Groupware-Bereich Anwendungen der Systemklasse Shared In-

formation Space entstanden, die ebenfalls ”der verteilten Nutzung von Informationen

dienen, und bei denen gemeinsame Informationsbest¨

ande als eine wesentliche Kompo-

nente der Kommunikations-, Kooperations- und Koordinationsunterst¨

utzung zu betrach-

ten sind“ [F+02], S. 247f.

Die Datenspeicherung ist in beiden F¨

allen persistent, erstreckt sich auf strukturierte

sowie unstrukturierte Informationen und stellt außerdem geeignete Zugriffsmechanismen

bereit. In der Regel basieren ihre Datenmodelle auf wenigen, zentralen Objekten (vgl.

Abb. 3.8):

36Second Life ist eine Online-3D-Infrastruktur f¨

ur von Benutzern selbst gestaltete virtuelle Welten,

in der sie als Avatare mit anderen Benutzern interagieren und sogar Handel betreiben k¨

onnen.

Derzeit sind ¨

uber 11 Millionen Nutzerkonten registriert. Die deutsche Webseite ist unter http:

//de.secondlife.com zu erreichen. Letzter Zugriff: 31.07.2008.

3.2. Die Wissensraummetapher als konstruierende Semantik f¨

ur Lernumgebungen

+setInhalt

+getInhalt

Dokument

+setAttribut

+getAttribut

+setBerechtigung

+getBerechtigung

+getUmgebung

+bewegeObjekt

+getObjektID

Objekt

+einfügenObjekt

+entferneObjekt

+getInventar

Comtainer

+getBenutzer

+chat

Raum

Ausgang

+setZiel

+getZiel

Verweis

+addMitglied

+getMitglieder

+istMitglied

Gruppe

+setPasswort

+getStatus

+getGruppen

Benutzer

1 1

Abbildung 3.8.: Objektmodell der Wissensraummetapher nach [Ham02].

âDas zentrale Element Objekt stellt Hauptattribute und generische Medienfunktio-

nen wie Erzeugen, L¨

oschen, Verkn¨

upfen, etc. bereit. Es besitzt auch Funktionen,

um Attribute zu setzen und auszulesen, Berechtigungen zu setzen und zu pr¨

ufen

und Informationen ¨

uber die Umgebung abzufragen. Damit bildet es den Ausgangs-

punkt f¨

ur alle weiteren Klassen, die alle diese Grundeigenschaften und -funktionen

erben.

âEin Dokument wird bspw. um die M¨

oglichkeit der Inhaltsverwaltung von Doku-

menten erweitert, wie das Setzen und Auslesen des Inhalts, und bspw. einer Ver-

sionierung.

âContainer und R¨aume fassen Objekte zusammen. W¨

ahrend ein Container Doku-

mente enthalten kann, k¨

onnen sich in einem Raum als Spezialisierung eines Contai-

ners auch Nutzer aufhalten. Es besteht bei beiden Typen die M¨

oglichkeit, Objekte

hinzuzuf¨

ugen und den Inhalt des Containers sowie seine Umgebung zu erfragen.

âEine Besonderheit im Modell von Hampel ist, dass das Benutzer-Objekt vom

Container abgeleitet wird. So tr¨

agt es einerseits als Objekt Berechtigungen und

Attribute, kann gleichzeitig als Container beliebige Objekte bzw. Dokumente oder

auch einfach nur Verweise auf Dokumente mit sich f¨

uhren (inventory).

âEine Gruppe ist von Objekt abgeleitet und f¨

ur die Verwaltung der Teilnehmer einer

Nutzergruppe zust¨

andig. Es werden Berechtigungen geb¨

undelt und Zugriffsstruk-

turen verwaltet.

3. Terminologiebasierte Spezifizierung von Lernumgebungen

âEine Verkn¨

upfung auf eine interne oder externe Ressource kann durch einen Verweis

gekapselt werden. Verweise werden als bidirektionale Objekte verwaltet, sie k¨

onnen

also auch zur¨

uckverfolgt werden und Attribute tragen. Die Klasse Ausgang ist eine

Spezialisierung eines Verweises und sorgt daf¨

ur, dass R¨

aume persistent miteinan-

der verbunden werden k¨

onnen und die Nutzer durch den so entstandenen Korridor

entlang ihrer gesetzten Berechtigungen wandern k¨

onnen37.

Essentiell f¨

ur die Implementierung von Lernumgebungen auf Basis der Wissensraumme-

tapher sind Objektframeworks, die einen Zugriff auf diese persistenten Strukturen ¨

uber

eine objektorientierte Programmierschnittstelle erlauben. Ein solches Framework ist da-

bei nicht als bloße Zusammenstellung von Klassen und Funktionen zu verstehen, sondern

als ein System wiederverwendbarer Designergebnisse. Schon der Entwurf der Lern- und

Arbeitsszenarien kann sich des im Framework verankerten Objektmodells bedienen und

ist somit als Ableitung eines konkreten Designs aus abstrakteren Strukturen zu sehen.

Damit solche Systeme als grundlegend in einer heterogenen Umgebung dienen k¨

onnen,

wird der Gedanke von angepassten ”Sichten“ auf virtuelle Wissensr¨

aume und Objek-

te selbst bei der Integration standardisierter Internet-Protokolle konsequent fortgesetzt:

G¨

angige Kommunikations- und Infrastrukturprotokolle wie WebDAV, FTP, RSS, Instant

Messaging oder Mail-Protokolle werden dabei innerhalb eines Raumes zusammengef¨

uhrt.

Diese direkte Verankerung von Medien- und Kommunikationsfunktionen in semanti-

schen Strukturen verringert zum einen Medienbr¨

uche, kann zum anderen aber zu einer

v¨

ollig neuen Qualit¨

at medialer Integration von Semantik und Kommunikation f¨

uhren

(vgl. [SHB04]).

Eine weitergehende Betrachtung von Objektframeworks zur Entwicklung von Lern- und

Arbeitsumgebungen erfolgt im Kontext der zu konzipierenden Softwarearchitektur in

Abschnitt 4.1.5.3.

3.3. Normsprachliche Spezifizierung kooperativer

Lernumgebungen

In diesem Abschnitt wird beschrieben, wie Lern- und Arbeitsszenarien auf Grundla-

ge der Wissensraummetapher materialsprachlich spezifiziert und mithilfe einer wissens-

raumbasierten Klassenbibliothek (oder Framework) bzw. eines entsprechenden Modells

von Proxy-Objekten softwaretechnisch umgesetzt werden kann.

Dazu wird zuerst eine Taxonomie von Eigenpr¨

adikatoren vorgestellt, die eine erste Ba-

sis f¨

ur die Bildung normsprachlicher Aussagen zur Beschreibung von Lern- und Arbeit-

sumgebungen im universit¨

aren Kontext darstellt. Sie enth¨

alt die Bezeichner von Konzep-

ten der vier Spezifikationsebenen Begriffe, P¨

adagogik, (SW-)Technik und Schnittstellen

(vgl. Abb. 3.9).

37Eine Klasse von diesem Typ erm¨

oglicht die semantische Vernetzung von R¨

aumen, ist aber nicht immer

vorhanden. Daher k¨

onnen in den meisten Systemen R¨

aume analog zu einer Verzeichnisstruktur nur

hierarchisch angeordnet werden.

3.3. Normsprachliche Spezifizierung kooperativer Lernumgebungen

Begriﬀsebene

Pädagogische Konzepte, Begriﬀe der universitären

Organisation und technologischer Infrastrukturen

Pädagogische Ebene

Rollen, Werkzeuggebrauch und Interaktion mit

Medien, Ablaufreihenfolgen, Ergebnisse

Technische Ebene

Basiskonzepte wie Nummern, Namen,

Verwaltungselemente und Zeitangaben; Daten und

Datentypen; Rechtemanagement; Objekttypen und -

eigenschaften; Attribute und Beziehungen

Schnittstellenebene

Funktionen, Parameter und Resultate

Abbildung 3.9.: Spezifikationsebenen universit¨

arer Lern- und Arbeitsumgebungen (eige-

ne Darstellung).

Ein wichtiger Bestandteil dieser Terminologie sind die Konzepte der Wissensraummeta-

pher nach Hampel (vgl. [Ham02], S. 193ff.), mit deren Hilfe große Teile der Persistenz und

der Interaktion mit Medien rekonstruiert werden k¨

onnen. Satzmuster und Beispiele f¨

diese normsprachliche Rekonstruktion werden im darauf folgenden Abschnitt vorgestellt.

Dabei wird – in Anlehnung an [Sch97a] – die Spezifikation unter den drei wesentlichen

Perspektiven Statik, Funktionalit¨

at und Dynamik erkl¨

art38.

Zuletzt werden noch wichtige implementierungsspezifische Aspekte erl¨

autert, bevor

eine Zusammenfassung das Kapitel abschließt.

3.3.1. Das normsprachliche Lexikon

In der Abbildung 3.2 wurden bereits die Wortarten gegeneinander abgegrenzt, die bei

der normsprachlichen Schemaerstellung verwendet werden k¨

onnen: Ding- und Gescheh-

nispr¨

adikatoren, Ding- und Geschehnisappr¨

adikatoren sowie Partikel wie Pr¨

apositionen,

Demonstrativpronomen usw. F¨

ur die Rekonstruktion und Beschreibung von dom¨

anen-

und anwendungsspezifischen Konzepten sind in erster Linie die Eigenpr¨

adikatoren mit in

das Lexikon aufzunehmen. Also Substantive und T¨

atigkeitsbeschreibungen wie Verben

oder ¨

Ahnliches. Dar¨

uber hinaus werden Appr¨

adikatoren (also Adjektive und Adver-

bien) f¨

ur die Rekonstruktion von Zust¨

anden und Zustands¨

uberg¨

angen von Konzepten

ben¨

otigt. I. d. R. ist dies jedoch eher anwendungs- als dom¨

anenspezifisch. Im Kontext

des Lexikons werden daher nur wenige Appr¨

adikatoren behandelt39. Auf Pr¨

apositionen,

bestimmte und unbestimmte Artikel usw. wird im Lexikon ganz verzichtet, da diese im

Regelfall keiner weiteren Erkl¨

arung bed¨

urfen.

38Die Unterscheidung der drei wichtigsten Aspekte der Modellierung von Softwaresystemen – Daten,

Funktion, und zeitliches Verhalten – wird in nahezu allen verbreiteten objektorientierten Analyse-

und Entwurfsmethoden vorgenommen und durch spezielle Techniken unterst¨

utzt.

39Speziell sind dies verschiedene Stati wie eingeloggt,authentifiziert,angemeldet,registriert oder zuge-

lassen.

3. Terminologiebasierte Spezifizierung von Lernumgebungen

3.3.1.1. Dingpr¨

adikatoren des universit¨

aren Lernens und Arbeitens

Das Begriffssystem der Dom¨

ane ”universit¨

ares E-Learning“ enth¨

alt Konzepte der vier

Spezifizierungsebenen Begriffe, P¨

adagogik, (SW-) Technik und Schnittstellen, mit de-

nen Anforderungen aus Sicht der Projektbeteiligten formuliert werden k¨

onnen (vgl.

Abb. 3.9).

Begriffsebene Universit¨

are Lern- und Arbeitsszenarien sind begrifflich eingebettet in

hochschulische Organisationskonzepte und in eine technische Infrastruktur. Dem ent-

sprechend geh¨

oren grundlegende Organisations- und Technologiekonzepte wie verschie-

dene Organisationseinheiten und Typen von Mitarbeitern dazu. Ebenso Technologien

wie Lernobjekte und verschiedene Lernwerkzeuge, wie bspw. ein Whiteboard oder ein

Mail −Client.

P¨

adagogische Ebene Zur grundlegenden Beschreibung didaktischer Szenarien wur-

den die Konzepte des IMS Learning Designs (IMS LD, s. S. 43) mit in die Taxonomie

ubernommen. Die IMS-Spezifikation hat den Anspruch, vollst¨

andige didaktische Ar-

rangements innerhalb einer definierten Umgebung mitsamt ihren Rollen, Aktivit¨

aten,

den verwendeten Lehr-/Lernmaterialien und den erzielten Ergebnissen XML-basiert

abzubilden. Didaktische Methoden (Szenarien) werden im Learning Design analog zu

einem Theaterspiel (play) in ein oder mehrere sequentiell aufeinander folgende Akte

(acts) aufgeteilt, in denen die Personen in bestimmten Rollen (roles/role-parts) Hand-

lungen (activities) vornehmen. Nach dem in Abbildung 3.10 dargestellten Informati-

onsmodell des IMS LD l¨

asst sich das Kernkonzept der Spezifikation daher formulie-

ren als ”Personen f¨

uhren in unterschiedlichen Rollen Aktivit¨

aten in bestimmten (Lern-

) Umgebungen durch“. In Anlehnung daran wurden die einzelnen Konzepte Person,

Rolle,Aktivit¨at und Umgebung in das Lexikon aufgenommen. Weiterhin wurde die

Klassifizierung als Lernaktivit¨at und Unterst¨utzungsaktivit¨at sowie mit dem Kon-

zept der Aktivit¨atsstruktur die M¨

oglichkeit zur Strukturierung von Aktivit¨

aten durch

Teil-Aktivit¨

aten ¨

ubernommen. Die f¨

ur die Anwendung dieser Konzepte ben¨

otigten Satz-

muster zur Formulierung von Spezialisierungen, Kompositionen und T¨

atigkeitsaussagen

werden in den weiteren Abschnitten dieses Kapitels vorgestellt.

Basiskonzepte Zur Beschreibung informationstechnischer Aspekte wie die Verwaltung

von Objekten und Daten im Allgemeinen werden in der Terminologie Basiskonzepte

wie Nummern,Namen,Verwaltungselemente und Zeitangaben definiert. Dar¨

uber hin-

aus erfolgt die persistente Abbildung von Objekten der zu implementierenden Lern- und

Arbeitsumgebungen ¨

uber die bereits vorgestellten Basisobjekte der Wissensraummeta-

pher (vgl. Abschnitt 3.2.2): Dokument,Objekt,Container und R¨

aume,Benutzer und

Gruppen sowie Verweise wie Verkn¨

upfungen und Ausg¨

ange. Konzepte des universit¨

aren

E-Learnings sollten – wenn m¨

oglich – auf Basis dieser Begriffe normsprachlich durch

Spezialisierung und Komposition rekonstruiert werden.

3.3. Normsprachliche Spezifizierung kooperativer Lernumgebungen

learning design

condition

property

person

role

learner

staﬀ

method

play

act

role-part

notification

learning

activity

learning

objective

prerequisite

support

activity

structure

outcome

environment

learning

object service

global

elements

«use»

1..*

performs >

< triggers

1..*

creates > *

1..* *

using >

designed towards > *

Abbildung 3.10.: Das Informationsmodell des IMS LD (aus: [IMS03b]).

Dabei k¨

onnen Konzepte des Learning Designs mit Konzepten der Wissensraummetapher

kombiniert bzw. abgebildet werden. Bspw. k¨

onnen Rollen durch Gruppen umgesetzt,

Wissensr¨

aume als Lernumgebung gestaltet und Aktivit¨

atsstrukturen durch Medienfunk-

tionen unterst¨

utzt werden.

Schnittstellen In dieser Arbeit wurde bereits auf S. 26ff. die Wichtigkeit der Integra-

tion moderner Lernumgebungen in die umgebende IT-Infrastruktur herausgestellt. Eine

Anforderung an die zu erstellende Normsprache ist daher die Beschreibungsf¨

ahigkeit von

funktionalen Schnittstellen zwischen Systemen, genauer, mit welchen Parametern eine

Operation von einem Klassifizierer (Klasse oder Komponente) aufgerufen werden kann

und welche Resultate zur¨

uckgegeben werden. Dabei soll die Normsprache jedoch nur ei-

ne Erg¨

anzung zu existierenden technischen Beschreibungssprachen von Schnittstellen40

darstellen und diese nicht ersetzen. Die Kommunikation des Systemanalysten mit den

Endanwendern verl¨

auft meistens nicht auf einem solch technischen Niveau, so dass diese

grundlegende Beschreibung von (entfernten) Funktionsaufrufen in der Regel ausreicht.

40Bspw. die Web Service Description Language (WSDL) oder die Component Definition Language

(CDL).

3. Terminologiebasierte Spezifizierung von Lernumgebungen

Ding

Basis Person

Organisations-

einheit

Angestellter

Bibliothek

Mitarbeiter

Lehre

Gastdozent

Nummer

Name

Objekt

Ressource

Rolle

Status

Aktion

Kursteilnehmer

Dozent

Tutor

Arbeitsraum

Container

Raum

Benutzer

Dokument

Externer

Verweis

Gruppe

Verknüpfung

Ausgang

Abbildung 3.11.: Die Basis-Dingpr¨

adikatoren (Q) der Terminologie (Ausschnitt: Objekte

der Wissensraummetapher, vgl. Anhang S. 256)

3.3.1.2. Geschehnispr¨

adikatoren

Aktivit¨

aten k¨

onnen normsprachlich durch Geschehnispr¨

adikatoren ausgedr¨

uckt werden.

In Kombination mit einer entsprechenden Kopulae k¨

onnen damit sowohl Verhaltensaus-

sagen als auch Aussagen zu Bef¨

ahigungen und Berechtigungen von handelnden Subjek-

ten gemacht werden (vgl. Abb. 3.3). Durch Satzmuster zur Komposition k¨

onnen ver-

schiedene Aktivit¨

aten Instanzen des vorgestellten Konzepts der Aktivit¨

atsstruktur zu-

geordnet werden, das somit eine beliebig tiefe Hierarchie beschreiben kann. Sp¨

ater in

diesem Kapitel wird noch gezeigt werden, wie zeitliche und/oder kausale Beziehungen

zwischen (Teil-) Aktivit¨

aten zur Beschreibung von sequentiellen, parallelen und alterna-

tiven Ablaufreihenfolgen abgebildet werden k¨

onnen.

Die bereits vorgestellten prim¨

aren Medienfunktionen (S. 92) bilden einen großen Teil

der Aktivit¨

aten, n¨

amlich Interaktionen von Benutzern mit den Informationsobjekten.

Ebenfalls in den Bereich der Interaktion fallend erg¨

anzen aufrufen und zur¨

uckgeben die

Dingpr¨

adikatoren zur Schnittstellenbeschreibung zwischen zwei Komponenten.

Weiterhin sind Dingpr¨

adikatoren zur Beschreibung

âder Durchf¨

uhrung von in sich abgeschlossenen Szenarien (beginnen, abbrechen, ab-

schließen)

âvon Benutzereingaben (eingeben, aufrufen, registrieren, etc.)

100

3.3. Normsprachliche Spezifizierung kooperativer Lernumgebungen

erzeugen

tun

interagieren

anlegen

hochladen

durchführen

beginnen

abbrechen

abschließen

ausgeben

anzeigen

bereitstellen

belegen

drucken

verwalten

auswählen

suchen

hinzufügen

sortieren

schreiben

antworten

ausschließen

bedienen

aufrufen

registrieren

anmelden

authenti-

fizieren

abmeldenzurückgeben

Abbildung 3.12.: Die Basis-Geschehnispr¨

adikatoren (P) der Terminologie

(Ausschnitt, vgl. Anhang S. 255)

âvon Systemausgaben als Antwortverhalten auf Benutzereingaben (anzeigen, dru-

cken, etc.) und

âvon m¨

oglichen Verwaltungst¨

atigkeiten (suchen, hinzuf¨

ugen, sortieren, etc.).

Die Abbildungen 3.11 und 3.12 geben noch einmal einen ¨

Uberblick ¨

uber die Konzepte.

3.3.2. Statische Sicht

Die statische Sicht41 umfasst die Spezifikation der statischen, d. h. ¨

uber die Zeit un-

ver¨

anderlichen Teile des grundlegenden Informationsmodells. Dazu werden Klassen von

Objekten beschrieben, ihre Attribute und G¨

ultigkeitsbereiche, sowie ihre strukturellen

Beziehungen zueinander. In diesem Abschnitt werden diese statischen Aspekte aufgegrif-

fen und gezeigt, welche Grammatik, insbesondere welche Satzbaupl¨

ane dazu ben¨

otigt

werden, um relevante Konzepte (Pr¨

adikatoren) eines Anwendungsbereiches sowie die

semantischen Beziehungen zwischen ihnen definieren zu k¨

onnen.

Statische Beziehungen zwischen den Pr¨

adikatoren sind bspw. Kompositionen, Relatio-

nen, Vererbungsbeziehungen, Existenzabh¨

angigkeiten und Zuordnungen von konkreten

Objekten zu einer Menge von Objekten. Einige Beispiele zur Modellierung wurden be-

reits in Kapitel 4.1 gegeben, auf die im Folgenden weiter aufgebaut wird.

3.3.2.1. Kompositionen

Kompositionen (composite aggregations) beschreiben Ganzes-Teil-Beziehungen, bei der

die Instanz eines systemhaften Ganzen durch die Instanzen seiner Teile definiert wird.

Hier¨

uber lassen sich bspw. komplexere Objektstrukturen konstruieren, die sich aus ver-

schiedenen einfachen Typen zusammensetzen. Aber auch einfache Inklusionsbeziehungen

wie Zugeh¨

origkeiten sind dar¨

uber beschreibbar. Nach [Sch97a], S. 226, lassen sich f¨

unf

41In der Literatur auch oft als Datensicht oder Struktursicht bezeichnet.

101

3. Terminologiebasierte Spezifizierung von Lernumgebungen

Kompositionstypen unterscheiden: Ganzheit, Kollektion, Beh¨

altnis, Verschmelzung und

Zuordnung. Um eine Spezifikation auf Basis der Normsprache entsprechend differenziert

vornehmen zu k¨

onnen, lautet das Satzmuster f¨

ur Aussagen zu Ganzes-Teil-Beziehungen

in Erweiterung zu 3.8:

[N1|σKompositionstyp |N2] (3.11)

Somit lassen sich bspw. Unterstrukturen, Mitgliedschaften und Umgebungen beschrei-

ben:

oKursraum σGanzheit Materialpool

oGruppe σKollektion Gruppenmitglied

oRaum σBeh¨altnis Benutzer, Container,

Dokument, Verweis

(3.12)

Die Definition einer Gruppe sieht vor, dass sie sowohl aus Benutzern (Gruppenmitglie-

dern) als auch aus Gruppen (Untergruppen) bestehen kann. Dabei sollen alle Mitglieder

von Untergruppen zwangsl¨

aufig auch Mitglied in den entsprechenden Obergruppen sein.

Auf dieser Forderung baut ein Teil des dynamischen Rechtemanagements (S. 107) auf,

weshalb sie an dieser Stelle normsprachlich definiert werden soll:

∀x, y ε Gruppe, z ε Benutzer ( (3.13)

(x σKollektion y)∧(y σKollektion z)→x σKollektion z)

Partivative Beziehungen k¨

onnen so stark sein, dass ein Teil ohne das dazugeh¨

orende

Ganze alleine nicht existieren kann. Zum Beispiel kann es kein Gruppenmitglied ohne

die dazugeh¨

orende Gruppe geben. Aber auch der Inhalt eines Raums kann u. U. exis-

tenziell von seiner Umgebung abh¨

angig sein. Daher kann eine normsprachliche Existenz-

abh¨

angigkeit nicht per se zwischen zwei Pr¨

adikatoren definiert werden, sondern muss

auch die Beziehung (Konnexion) umfassen, welche die Abh¨

angigkeit begr¨

undet. Eine

existenzielle Abh¨

angigkeit von den Objekten in einem Raum zum Raum selbst kann so

beschrieben werden:

∀x ε Raum, y ε {Container, Dokument, V erweis}( (3.14)

x ε existieren ∧xσBeh¨altnisy→y ε existieren )

Demnach soll der Inhalt eines Raums gel¨

oscht werden, wenn auch der Raum gel¨

oscht

wird. Benutzer, die sich in einem Raum aufhalten k¨

onnen, sind in dieser Aussage (und

somit auch in der L¨

oschung) nicht eingeschlossen.

Ist es notwendig, eine Beziehung zwischen zwei Pr¨

adikatoren n¨

aher zu beschreiben,

sie also als eigenst¨

andige Entit¨

at behandeln zu m¨

ussen, k¨

onnen dazu so genannte Rela-

toren verwendet werden (vgl. [Sch97a], S. 205). Hierdurch werden Beziehungen zwischen

konkreten Auspr¨

agungen spezifischer Pr¨

adikatoren als eigenst¨

andige konkrete Objekte

unter einem neuen Pr¨

adikator (Relator) zusammengefasst. Seine Instanzen sind dabei

existenziell abh¨

angig von den durch die ihn verbundenen Objekten.

Im vorgestellten Objektmodell der Wissensraummetapher k¨

onnen Relatoren beispiels-

weise die Verkn¨

upfungsm¨

oglichkeiten von R¨

aumen mittels T¨

uren respektive Ausg¨

angen

102

3.3. Normsprachliche Spezifizierung kooperativer Lernumgebungen

darstellen. Der Relator ”Ausgang“ kann danach wie folgt beschrieben werden:

Quelle, Ziel ε Raum

Ausgang(Quelle, Ziel )(3.15)

Ein Ausgang beschreibt also eine gerichtete Verbindung zwischen zwei R¨

aumen (Quelle

und Ziel). Mithilfe dieses neuen Pr¨

adikators k¨

onnen dann Aussagen ¨

uber Raumstruk-

turen get¨

atigt werden, die an weitere Verbindungen zwischen Objekten gekoppelt sind:

”Jede Person, die Mitglied in einer Gruppe ist, hat in ihrem pers¨

onlichen Arbeitsraum

einen Ausgang zu dem entsprechenden Gruppenarbeitsraum“ kann man normsprachlich

mit den Satzbaupl¨

anen 3.8 und 3.11 wie folgt ausdr¨

ucken:

∀a ε Person, b, d ε Arbeitsraum, c ε Gruppe ( (3.16)

[a|σ|b]∧[c|σKollektion |a]∧[c|σ|d]

→[b|σBeh¨altnis |Ausgang(b, d) ] )

Das Konzept der Komposition ist nicht nur auf Ding-Pr¨

adikatoren beschr¨

ankt. Es

kann – auf Geschehnis-Pr¨

adikatoren angewendet – auch die Zerlegung von Aktivit¨

aten

in einzelne T¨

atigkeiten beschreiben. In Kombination mit definierten Ablaufreihenfolgen

lassen sich damit sehr gut komplexere Lernszenarien definieren (vgl. Abb. 3.14).

3.3.2.2. Spezialisierung

Neben der Komposition ist das Konzept der Spezialisierung sehr wichtig, um das stati-

sche Modell eines Anwendungsbereiches zu konstruieren. Die Spezialisierung verbindet

zwei Pr¨

adikatoren vom selben Typ, wobei einer eine Unterklasse vom anderen ist. Mit

anderen Worten: Der zweite Begriff ist generischer oder abstrakter als der erste. Somit

l¨

asst sich eine begriffliche Unter-/¨

Uberordnung von Pr¨

adikatoren festlegen, bei der die

unter einem Oberbegriff inkludierten Spezialisierungen dessen Eigenschaften und Bezie-

hungen erben. Das dazugeh¨

orige Satzmuster wurde mit 3.7 bereits vorgestellt, soll an

dieser Stelle aber noch einmal verfeinert werden, um verschiedene Arten der Inklusion

ausdr¨

ucken zu k¨

onnen:

[N1|εInklusionstyp |N2] (3.17)

Somit lassen sich bspw. statische Art/Gattungs-Beziehungen und dynamische Rollenbe-

ziehungen definieren (vgl. [Sch97a], S. 224f.):

oFakult¨

at εArt Organisationseinheit

oGruppenadministrator εRolle Person (3.18)

Generelle Aussagen zu diesen Inklusionsbeziehungen sind bspw.

”∀x(x ε Fakult¨at →x εArt Organisationseinheit)“ oder

”∀xεPerson, y ε Gruppe (x π anlegen y →Gruppenadministrator(x, y)εRolle x)“ mit

dem Relator Gruppenadministrator(Person, Gruppe).

Abbildung 3.13 stellt die Umsetzung einer statischen Struktur in Programmcode noch

einmal grafisch dar.

103

3. Terminologiebasierte Spezifizierung von Lernumgebungen

Normsprachliche Spezifizierung Umsetzung im Zielsystem

Kurs

Betreuer-

gruppe

Teilnehmer-

gruppe

Gruppe

εε

Kursraum

Lernraum

geschützter

Bereich

σσ

Arbeitsraum

Ausgang

Ziel Quelle

$kurs = steam_factory::create_group(

"Kurs", null);

$teilnehmer = steam_factory::create_group(

"Teilnehmer", $kurs);

$betreuer = steam_factory::create_group(

"Betreuer", $kurs);

$geschuetzter_bereich =

$betreuer->get_workroom();

$lernraum = $teilnehmer->get_workroom();

steam_factory::create_exit(

$kurs, $geschuetzter_bereich);

steam_factory::create_exit(

$kurs, $lernraum);

steam_factory::create_exit(

$geschutzter_bereich, $lernraum);

Kursraum

Lernraum

geschützter

Bereich

Teilnehmer

Betreuer

Abbildung 3.13.: Spezifizierung und Implementierung einer statischen Raum- und Grup-

penstruktur f¨

ur Kurse.

3.3.2.3. Attribute

Begriffe typisieren konkrete oder abstrakte Objekte mit gleichen Merkmalen (Attribu-

ten). Dabei k¨

onnen sich die Objekte eines Typs durch verschiedene Merkmalsauspr¨

agun-

gen voneinander unterscheiden. Mithilfe der Normsprache m¨

ussen deshalb (1) allgemeine

Aussagen formuliert werden k¨

onnen, welche die Zuordnung von Attributen zu Objekt-

typen ausdr¨

ucken, und (2) singul¨

are Aussagen zu den Merkmalsauspr¨

agungen konkreter

Objektinstanzen. Das folgende Satzmuster beschreibt die schematische Zuordnung eines

Attributes Q2zu Instanzen des Objekttyps Q1mit Σ f¨

ur ”haben“. Mehrere Attribute

k¨

onnen in einem Satz mit Kommata angeh¨

angt werden:

oNat¨

urliche Sprache: [Studenten haben eine Matrikelnummer.]

oNormsprache: [Student |Σ|Matrikelnummer]

oSatzbauplan: [Q1|Σ|Q2, . . . Qn]

(3.19)

Dabei ist das Attribut Q2(hier: Matrikelnummer) ein eigenst¨

andiger Pr¨

adikator, der in

Aussagen zur konkreten Auspr¨

agungen herangezogen werden kann:

oNat¨

urliche Sprache: [Der Student M¨

uller hat die Matrikelnummer 123456.]

oNormsprache: [(M¨

uller |ε|Student)σ(123456 |ε|Matrikelnummer)]

oSatzbauplan (kurz): [N1|σ|(N2|ε|Q1)]

(3.20)

104

3.3. Normsprachliche Spezifizierung kooperativer Lernumgebungen

Lösungsvorschlag

erarbeiten

Diskussion der Lösungs-

vorschläge

Präsention vorbereiten Lösungsvorschlag erarbeiten

präsentieren diskutieren

Lösungsvorschlag 1

Think-Pair-Share

! !

Problemstellung 1

Problemstellung 2

Eigener

Arbeitsraum Kursraum

Kursraum

Lernraum

Präsentation

Hilfestellung bei Fragen

! !

moderieren

Betreuer "

Betreuer

Teilnehmer "

Teilnehmerpaar

alle Teilnehmer

Abbildung 3.14.: Spezifizierung der funktionalen Sicht am Beispiel des didaktischen Sze-

narios Think-Pair-Share.

3.3.3. Funktionale Sicht

Die im vorhergehenden Abschnitt beschriebenen Satzbaupl¨

ane erm¨

oglichen die Rekon-

struktion der statischen Struktur eines Anwendungsbereichs, d. h. die Definition rele-

vanter Konzepte sowie deren semantische Beziehungen zueinander. Aus funktionaler

Sicht werden im Folgenden M¨

oglichkeiten zur Beschreibung des Verhaltens eines Sys-

tems innerhalb dieses Anwendungsbereichs aufgezeigt, also beobachtbare Interaktionen

zwischen Instanzen dieser Konzepte. Dabei stehen insbesondere die normsprachliche

Beschreibung der Handlungsf¨

ahigkeit von Objekten, sowie Handlungskontexte mit Vor-

und Nachbedingungen im Fokus.

105

3. Terminologiebasierte Spezifizierung von Lernumgebungen

3.3.3.1. Bef¨

ahigungen

Die im Objektmodell definierten Methoden beschreiben die unterste Verfeinerungsschran-

ke elementarer Handlungen (Teilhandlungen). Auf dieser Basis k¨

onnen mithilfe der im

vorigen Abschnitt vorgestellten Komposition komplexere Aktivit¨

atsstrukturen beschrie-

ben werden42, die der Rekonstruktion von Handlungsabl¨

aufen dienen. Ein entsprechen-

des Satzmuster dazu wurde bereits einleitend mit 3.9 vorgestellt. Beispiele sind:

o[Benutzer |π|annotieren |Antwort |an −Forenbeitrag]

(3.21)

Anhand dieser Aussagen lassen sich die typspezifischen F¨

ahigkeiten von Objekten ab-

leiten, wobei die beschriebene F¨

ahigkeit i. d. R. dem unmittelbar durch die Handlung

betroffenem Objekt zugeschrieben wird (vgl. [Sch97a], S. 244f.)43. Direktes Objekt der

Handlung annotieren ist bspw. ein Objekt vom Typ Antwort. Als Ergebnis der Handlung

wird dieses Objekt an einen Forenbeitrag ”angeheftet“. Werden im Zielsystem Merkmale

von Antworten als Attribute des Objekttyps Antwort verwaltet, so sollte – falls andere

Designentscheidungen nicht dagegen sprechen – der ver¨

anderte Zustand des ”angeheftet-

seins“ sowie die dazugeh¨

orige Zustands-ver¨

andernde Methode dem Typ Antwort zuge-

ordnet werden. Gleiches gilt f¨

ur das Arrangieren von Dokumenten, das Schreiben von

Wikibeitr¨

agen und das Einladen von Benutzern.

An den Beispielen l¨

asst sich weiterhin gut erkennen, dass Aussagen nach diesem Mus-

ter nicht nur das handelnde Subjekt und das direkte Handlungsobjekt definieren k¨

onnen,

sondern dar¨

uber hinaus auch den Handlungsraum, Hilfsmittel, und weitere indirekte Ob-

jekte. Alles gemeinsam charakterisiert die Handlungssituation.

3.3.3.2. Berechtigungen

Die in Abschnitt 3.2.3 vorgestellten Plattformen nutzen keine statischen Rollen, die

auf ein bestimmtes Anwendungsszenario zugeschnitten sind, sondern ein offenes und fle-

xibles, objektbezogenes Rechtemanagement, das auf eine Situation hin angepasst werden

kann. Dies kommt der Tatsache entgegen, dass sich Benutzer und Objekte in verschiede-

nen kooperativen Szenarien zumeist nicht durch ihre allgemeinen Handlungsf¨

ahigkeiten

unterscheiden, wohl aber durch verschiedene Berechtigungen, diese Handlungen durch-

zuf¨

uhren. Zum Beispiel ist ein Student grunds¨

atzlich dazu f¨

ahig, den gemeinsamen Do-

kumentenpool zu einem Lernszenario einzusehen. Er bekommt das Leserecht auf die dort

abgelegten Dokumente in diesem Fall aber erst, nachdem er selbst seinen Beitrag in den

Pool hochgeladen hat (vgl. [RHS06]).

42Bspw. ”DokumentLesen σGanzheit Dokument¨

Offnen, InhaltAusgeben, InhaltLesen“.

43Die Zuordnung von F¨

ahigkeiten zu Objekttypen bspw. in der Form von Objektmethoden ist jedoch

vorrangig Teil des methodenspezifischen Entwicklungssystems und daher abh¨

angig von den verwen-

deten Entwurfsmethoden und -paradigmen. Sie soll aus diesem Grund hier nicht n¨

aher behandelt

werden.

106

3.3. Normsprachliche Spezifizierung kooperativer Lernumgebungen

Um solche statischen und dynamischen Berechtigungen normsprachlich rekonstruieren

zu k¨

onnen, wird im Folgenden ein Satzmuster vorgestellt, dass auf der in der Aufstellung

3.3 einleitend bereits erw¨

ahnten Berechtigungskopula basiert.

oNat¨

urliche Sprache: [Der Student darf den Dokumentenpool nicht lesen.]

oNormsprache: [Student |ϑ0|lesen |Dokumentenpool]

oSatzbauplan: [N1|ϑ|P|N2]

(3.22)

Die einzelnen Berechtigungen – also Lesen, Schreiben/L¨

oschen, Ausf¨

uhren, Annotieren,

etc. – k¨

onnen dann als Relatoren definiert werden, damit sie als jeweils eigenst¨

andiges

Recht in normsprachlichen Aussagen verwendet werden k¨

onnen: [N1|σ|Leserecht |

auf −N2], oder kurz:

Leserecht(Benutzer/Gruppe, Objekt),mit

∀x ε (Benutzer ∨Gruppe), y ε Objekt(Leserecht(x, y )↔x ϑ lesen y)(3.23)

Hiermit k¨

onnen allgemeine Aussagen zu den Rechten bestimmter Rollen der Anwendung

get¨

atigt werden. Singul¨

are Aussagen definieren dar¨

uber hinaus eine objektbezogene Ac-

cess Control List (ACL, vgl. hierzu [Lam74], S. 20, und [GB98]). Also eine zweidimen-

sional angeordnete Matrix mit f:B×tund B ε (Benutzer ∨Gruppe), t ε tun und einer

Funktion

f(Benutzer, tun) = erlaubt, wenn Benutzer ∈ACL f¨

ur tun

nicht erlaubt, wenn Benutzer /∈ACL f¨

ur tun.

Die Gesamtheit der Rechte eines Benutzers oder einer Gruppe an einem Objekt wird

in Analogie zu den einzelnen eigenst¨

andigen Rechten normsprachlich mit dem zwei-

stelligen Relator Zugriffsrecht(Benutzer/Gruppe, Objekt) ausgedr¨

uckt, welcher f¨

ur die

Modellierung dynamischer Aspekte – insbesondere Rechtevererbung und -weitergabe –

ben¨

otigt wird. Ohne die Argumente wird der Pr¨

adiktor ”Zugriffsrecht“ nicht auf die

Rechte einzelner Benutzer oder Gruppen beschr¨

ankt, sondern repr¨

asentiert alle definier-

ten Zugriffsrechte eines Objektes. Er kann dann als Objektattribut verwendet werden:

Objekt ΣZugriffsrecht.

Auf den dynamischen Teil eines flexiblen Rechtemanagements f¨

ur kooperative virtuelle

Umgebungen wird im folgenden Abschnitt Dynamische Sicht n¨

aher eingegangen.

3.3.4. Dynamische Sicht

3.3.4.1. Rechtevererbung und -weitergabe

Mit dem Satzmuster 3.22 k¨

onnen Zugriffsbeziehungen zwischen Objekttypen und ihren

Instanzen definiert werden, die statisch bspw. durch eine Rollenzugeh¨

origkeit erlangt

werden kann. In der praktischen Anwendung von Lern- und Arbeitsumgebungen haben

Rechtestrukturen dar¨

uber hinaus auch dynamischen Charakter. So m¨

ussen objektbe-

zogene Zugriffsrechte angepasst werden, wenn ein Dokument von einem zum anderen

Benutzer weitergegeben oder von einem privaten in einen Gruppenarbeitsraum bewegt

wird. Wie einleitend auf S. 93 schon erw¨

ahnt, unterscheidet Hampel diesbzgl. in [Ham04],

107

3. Terminologiebasierte Spezifizierung von Lernumgebungen

S. 17, (1) die Erlangung von Zugriffsrechten ¨

uber eine soziale Gruppenstruktur, (2) die

Ubertragung von Rechten eines anderen Benutzers (Delegation) und (3) der Ableitung

von Rechten eines Objekts durch seine Umgebung44.

Die Ableitung von Zugriffsrechten ¨

uber die Mitgliedschaft in einer Gruppe kann mit

der Regel 3.14 und dem Satzmuster 3.22 wie folgt definiert werden:

∀x εGruppe, y εBenutzer, z εObjekt(

(x σ Zugriffsrecht auf −z)∧(x σKollektion y)→

(y σ Zugriffsrecht(x, z)auf −z))

(3.24)

In vielen Umgebungen ist zun¨

achst einmal der ”Eigent¨

umer“ bzw. der ”Erzeuger“ ei-

nes Objektes zust¨

andig f¨

ur dessen Verwaltung. Dazu ist er i. d. R. im Besitz aller Rechte

auf das Objekt. Alle in Abschnitt 4.2.3 vorgestellten Plattformen erlauben jedoch die De-

legation der Verantwortung f¨

ur ein Objekt durch das Einr¨

aumen entsprechender Rechte

f¨

ur einzelne Benutzer oder ganze Gruppen. Dieses Recht, anderen Rechte an ein Ob-

jekt einzur¨

aumen, wird hier unter dem Relator ”Sanktionsrecht“ (aus dem Englischen:

sanction right, vgl. [Ham04], S. 22) verstanden. Analog zu allen ¨

ubrigen Rechten (vgl.

Definition 3.23) beruht die Rekonstruktion des Sanktionsrechts normsprachlich auf einer

Bisubjunktion:

Sanktionsrecht(Benutzer/Gruppe, Objekt),mit

∀x ε (Benutzer ∨Gruppe), y ε Objekt, y σ (z ε Zugriffsrecht)

(Sanktionsrecht(x, y )↔x ϑ weitergeben z)

(3.25)

Abschließend ist die ¨

Ubernahme von Zugriffsrechten von Objekten ¨

uber ihre Umge-

bung zu regeln. Dass ein Dokument grunds¨

atzlich erst einmal die Zugriffsrechte seines

ihn umgebenden Containers erbt, wird etwa durch die folgende Aussage behauptet:

∀a ε Dokument, b ε Container (3.26)

((b σBeh¨altnis a)∧(b σ(c ε Zugriffsrecht)) →a σ (c ε Zugriffsrecht))

3.3.4.2. Aktivit¨

aten

Um komplexe Verl¨

aufe von einzelnen Funktionen oder ganzen Prozessketten unter Be-

r¨

ucksichtigung von Reihenfolgen, Nebenl¨

aufigkeiten und alternativen Entscheidungswe-

gen rekonstruieren zu k¨

onnen, m¨

ussen normsprachliche Aussagen dazu in ein kausales

Ordnungsschema eingebunden werden.

Schienmann f¨

uhrt dazu in [Sch97a], S. 277ff., nach [Lor00] zun¨

achst einen konstruk-

tiven Subjunktor →cein, der eine strikte Sequenzialit¨

at zwischen dem Vordersatz und

dem Hintersatz in einem Bedingungssatz fordert: A→cB6=¬A∨B. Somit kann

eine Sequenz von Geschehnissen auf Schemaebene dargestellt werden als A→cB, wo-

bei die Großbuchstaben zur Bezeichnung von Geschehnissen dienen. Steht Abspw. f¨

”Benutzer π gr¨unden Gruppe“ und Bf¨

ur ”Benutzer π einladen Benutzer in−Gruppe“,

44Hampel schließt zus¨

atzlich den Zeitpunkt der Erbschaft als Klassifikationsmerkmal mit ein, also ob

ein Objekt die Rechte bspw. beim Erzeugen, Bewegen, oder der Bildung einer neuen Gruppe erlangt.

Dies soll jedoch f¨

ur ein Satzmuster an dieser Stelle keinen Unterschied machen.

108

3.3. Normsprachliche Spezifizierung kooperativer Lernumgebungen

dann wird mit dem Bedingungssatz ein kausaler Zusammenhang definiert, dass eine In-

stanz vom Geschehnistyp A(a) erst passiert sein muss, bevor eine Instanz von B (b)

ablaufen kann. Erst wenn ein Benutzer eine Gruppe gegr¨

undet hat, kann er dazu andere

Benutzer als Mitglieder einladen.

Wenn Geschehnisse nicht in einer kausalen Beziehung zueinander stehen, k¨

onnen sie

parallel ablaufen (vgl. ebd.). Die Konjunktion A→c(B∧C)→cDdr¨

uckt eine Paral-

lelverzweigung von A nach B und C aus, die wieder vor D zusammengef¨

uhrt wird.

In Analogie dazu k¨

onnen alternative Entscheidungswege logisch mithilfe einer Dis-

junktion A→c(B∨C)→cDmodelliert werden. Anstelle einer Parallelverzweigung

k¨

onnen hier entweder b oder c als Instanzen der Geschehnisaussagen B oder C ausgef¨

uhrt

werden, um eine Instanz von D aktualisieren zu k¨

onnen.

3.3.4.3. Zust¨

ande und Zustands¨

uberg¨

ange

Zuletzt werden M¨

oglichkeiten geschaffen, das Verhalten beliebiger Pr¨

adikatoren norm-

sprachlich zu rekonstruieren. Dies ist notwendig, um Aussagen zum Systemverhalten –

also wie verh¨

alt sich das System in einem bestimmten Zustand beim Eintreffen bestimm-

ter Ereignisse – festzuhalten.

In der UML spezifiziert man dieses Verhalten mit Zust¨

anden, die ein Objekttyp einneh-

men kann und ¨

Uberg¨

angen zwischen den Zust¨

anden, die durch Ereignisse initiiert werden

k¨

onnen. Dabei k¨

onnen Attribute eines Pr¨

adikators als Zustandsvariablen definiert wer-

den, deren endliche Menge von zul¨

assigen Werten die m¨

oglichen Zustandsauspr¨

agungen

beschreiben.

Normsprachlich werden diese Auspr¨

agungen durch Ding-Appr¨

adikatoren (q), also Ad-

jektiven ausgedr¨

uckt. Die m¨

oglichen Zust¨

ande eines Pr¨

adikators bildet daher die Menge

alternativer Appr¨

adikatoren, was durch die folgende disjunktive Pr¨

adikatorenregel mit

den Satzmustern 3.1 und 3.20 dargestellt wird:

(x ε Q1)∧(Q1ΣQ2)→xσ(q1ε Q2)∨xσ(q2ε Q2)∨. . . ∨xσ(qnε Q2) (3.27)

Eine Ver¨

anderung des Zustands von Pr¨

adikator Q1durch Eintreten eines Ereignisses

(Geschehnisaussage G(x) nach Satzmuster 3.9) bedeutet demnach eine ¨

Anderung des

Attributwerts Q2von einem Appr¨

adikator qa, der den Ausgangszustand beschreibt, hin

zu einem Appr¨

adikator qz, welcher den Zielzustand definiert. Normsprachliche Aussagen

zu Zustandswechseln folgen daher dem Muster:

∀xεQ1(x σ(qaε Q2)∧G(x)→x σ(qzε Q2)) (3.28)

109

3. Terminologiebasierte Spezifizierung von Lernumgebungen

Konzept Satzmuster Nr.

Verhaltensaussagen [N|π|pP |q1Q1|q2QF all

2|...|qnQF all

n] 3.9

Komposition [N1|σKompositionstyp |N2] 3.11

Spezialisierung [N1|εInklusionstyp |N2] 3.17

Attributierung [Q1|Σ|Q2,...Qn] 3.19

Merkmalsauspr¨

agung [N1|σ|(N2|ε|Q1)] 3.20

Berechtigungen [N1|ϑ|P|N2] 3.22

Tabelle 3.1.: Zusammenfassung der in dieser Arbeit verwendeten Satzmuster

3.4. Zusammenfassung

Mit diesem Kapitel wurde eine terminologiebasierte Entwicklung von Softwarekompo-

nenten f¨

ur virtuelle Lehr- und Lernumgebungen beschrieben. Daf¨

ur wurde zun¨

achst die

terminologiebasierte Softwareentwicklung erl¨

autert und Normsprachen als ein Konzept

der Anforderungserhebung vorgestellt, das den Vorteil besitzt, unabh¨

angig vom Entwick-

lungssystem formal g¨

ultige Aussagen formulieren zu k¨

onnen. Um statische Strukturen

und Medienfunktionen von und in Lern- und Arbeitsszenarien grundlegend beschreiben

zu k¨

onnen, wurde die Wissensraummetapher als konstruierender Teil von Lerntheorien

und Theorien des Wissensmanagements eingef¨

uhrt. Darauf aufbauend wurde eine Ter-

minologie zur Beschreibung von Sachverhalten in der Dom¨

ane des kooperativen Lernens

und Arbeitens entwickelt (Abb. 3.11, Abb. 3.12), sowie logische Regeln und Satzmuster

zur Bildung formal g¨

ultiger Aussagen abgeleitet (Tab. 3.1). Damit ist der methodenin-

variante Teil eines materialsprachlichen Softwareentwurfs umfassend behandelt.

Das hier erarbeitete terminologiebasierte Vorgehen zur Entwicklung softwaregest¨

utz-

ter Lern- und Arbeitsszenarien bietet gegen¨

uber herk¨

ommlichen Softwareentwicklungs-

ans¨

atzen einige Erleichterungen: Anstatt ein neues semantisches Datenmodell des zu

unterst¨

utzenden (Teil-)Problembereichs zu entwerfen, die grunds¨

atzliche Datenstruktur

daf¨

ur festzulegen und das so entstandene konzeptionelle Schema mit bereits bestehen-

den Schemata einer zu erweiternden Lern- oder Arbeitsplattform abzugleichen, wird

das zu unterst¨

utzende Szenario normsprachlich rekonstruiert. Da die in diesem Kapitel

vorgestellte Terminologie dazu die Bezeichner grunds¨

atzlicher Elemente, Funktionen und

Konzepte virtueller Wissensr¨

aume umfasst, k¨

onnen die normsprachlichen Aussagen mit-

hilfe von CSCW-/L-Plattformen umgesetzt werden, die auf dieser Metapher basieren und

entsprechende objektorientierte Programmierschnittstellen anbieten. Die Vorteile dieses

Vorgehens sind daher vielschichtig:

âDen am Anfang des Kapitels vorgestellten sprachlichen Effekten und Defekten

wird bei der Anforderungserhebung durch das definierte Vokabular und durch kon-

trollierte Satzmuster entgegen gewirkt. Dadurch kann sich die Kommunikation in

heterogenen Projektteams verbessern und Anforderungen an virtuellen Lern- und

Arbeitsszenarien k¨

onnen eindeutiger formuliert werden.

âAnstatt ein neuartiges Begriffs- respektive Objektmodell f¨

ur einen Problembe-

reich neu konstruieren zu m¨

ussen, k¨

onnen – mit deutlich weniger Aufwand – neue

110

3.4. Zusammenfassung

Konzepte auf Basis des durch die Terminologie beschriebenen Dom¨

anenmodells

rekonstruiert werden. Das reduziert nicht nur den Aufwand f¨

ur den Fachentwurf.

Eine Wiederverwendung von Konzepten auf Entwurfsebene sorgt dar¨

uber hinaus

auch f¨

ur eine einheitliche und stabile Gesamtarchitektur (vgl. [Fra94], S. 28).

âDie Persistierung von Objektstrukturen und -zust¨

anden sowie der lesende und

schreibende Zugriff auf Objektdaten wird bei diesem Vorgehen durch ein CSCW/L-

Objektrahmenwerk ¨

ubernommen. Durch die Ber¨

ucksichtigung der Wissensraum-

metapher in der Terminologie ist das semantische Datenmodell der zu unterst¨

ut-

zenden Szenarien also nicht mehr l¨

anger ein fester Bestandteil der Anwendungsent-

wicklung. Anwendungen k¨

onnen i. d. R. entwickelt, gewartet und erweitert werden,

ohne Datenstrukturen oder Persistierungsmethoden ver¨

andern zu m¨

ussen45.

âGrunds¨

atzlich ist eine terminologiebasierte Entwicklung auf Basis der hier vor-

gestellten Normsprache zwar auf objektorientierte Konzepte in der Zielsprache

(Programmiersprache) angewiesen, ansonsten jedoch neutral bzgl. der zur Ent-

wicklung eingesetzten Technologie. Bspw. k¨

onnen sowohl klientenseitige Desktop-

Anwendungen als auch serverseitige Web-Anwendungen in OO-Programmierspra-

chen oder -Skriptsprachen implementiert werden.

âDurch die Technisierung der Wissensraummetapher ¨

uber objektorientierte Klas-

senbibliotheken stehen in der Zielsprache i. d. R. die gleichen Konzepte wie in der

Normsprache zur Verf¨

ugung (vgl. [HR05]). Dies erlaubt einerseits das leichtere

Programmieren auf einem h¨

oheren Abstraktionsgrad, andererseits die fachgerechte

Realisierung von Lernszenarien, da es keinen Bruch in den verwendeten Konzepten

gibt.

45Dazu Coad in [Coa91]: ”Why not buy a set of OOA (Object-Oriented Analysis)/OOD (Object-

Oriented Design) diagrams and a repository with an initial set of business rules, attributes, and

services? Customizing could then be done at the specification level or the design level and the

organization could then generate unique code for its needs“.

111

3. Terminologiebasierte Spezifizierung von Lernumgebungen

112

4. Eine Rahmenarchitektur f¨

universit¨

ares E-Learning

Unter Ber¨

ucksichtigung der in Kapitel 2 beschriebenen Herausforderungen eines inte-

grierten Informationsmanagements an Hochschulen und dem bereits in Kapitel 3 vorge-

stellten normsprachlichen Ansatz zur Spezifizierung von Lernszenarien ist im Folgenden

als erkl¨

artes zweites Ziel der Arbeit die Spezifikation einer Rahmenarchitektur f¨

ur kom-

ponentenbasierte Lern- und Arbeitsumgebungen zu erarbeiten. Dazu sollen zum einen

allgemeine Entwurfsprinzipien von Komponentenarchitekturen herausgearbeitet, zum

anderen der statische Teil der Rahmenarchitektur durch Art, Struktur und Zusammen-

wirken der Softwarebausteine beschrieben werden. Von der fachlichen Funktionalit¨

at und

der Datenarchitektur wird abstrahiert und eine Abbildung der Softwarekomponenten

auf eine IT-Basisinfrastruktur nur im Rahmen einer m¨

oglichen Komponentenverteilung

diskutiert. Durch diese Abstraktion soll die konzipierte Rahmenarchitektur den Anwen-

dungsbereich verteilter universit¨

arer Lern- und Arbeitsumgebungen m¨

oglichst generisch

wiedergeben, um einen Leitliniencharakter zu gew¨

ahrleisten.

Wie in Kapitel 1 er¨

ortert, soll bei der Konzeption die Losl¨

osung von der an einzelnen

Systemen orientierten Herangehensweise in der Softwareentwicklung im Vordergrund ste-

hen. Aus diesem Grund wird eine architekturzentrierte Konzeption angestrebt, bei der es

darum geht, eine einheitliche Plattform zu schaffen, die f¨

ur verschiedenste Anwendungen

in der Dom¨

ane des universit¨

aren E-Learnings eine geeignete Basis darstellt.

Diese Sichtweise impliziert eine separate Betrachtung von einer Produktstandardarchi-

tektur1mit gut wiederverwendbaren Softwarekomponenten und den darauf basierenden

Produktarchitekturen, welche die Standardarchitektur um anwendungsspezifische und

daher weniger gut wiederverwendbare Komponenten erweitern.

Die proaktive Wiederverwendung von Komponenten soll sich auch im dynamischen

Teil der Rahmenarchitektur wieder finden, die nach Dern neben den Entwurfsprinzipi-

en das Entwicklungsmodell einer Anwendungsarchitektur definiert (vgl. [Der03], S. 19ff.).

Dazu wird eine Softwareproduktlinien-orientierte Vorgehensweise beschrieben, die in das

Prozessmodell der in Kapitel 6 zu konzipierenden Methodik mit einfließt.

In diesem Kapitel werden zun¨

achst grundlegende technische Konzepte und Prinzipien zur

Umsetzung und zum Aufbau von komponentenbasierten IT-Architekturen beschrieben

(4.1). Darauf basierend folgt in Abschnitt 4.2 eine Konstruktion der Rahmenarchitektur

durch die Identifikation notwendiger Dienste im Kontext eines Schichtmodells, sowie die

Abgrenzung von Standard- und Produktarchitektur. Weitere Aspekte, n¨

amlich die Ver-

teilung der Komponenten auf Laufzeitumgebungen, sowie die aus verschiedenen Einsatz-

1Im weiteren Verlauf dieser Arbeit wird die Produktstandardarchitektur auch als ”Plattform“ bezeich-

net.

113

4. Eine Rahmenarchitektur f¨

ur universit¨

ares E-Learning

szenarien abgeleiteten Erweiterungen erg¨

anzen die Architektur. Das Kapitel schließt mit

einer Beschreibung der Anwendungsm¨

oglichkeit eines Softwareproduktlinien-orientierten

Entwicklungsmodells auf die konzipierte Rahmenarchitektur (4.3).

4.1. Komponentenarchitekturen

Bei der Entwicklung integrierter virtueller Lernumgebungen im universit¨

aren Bereich

kann grunds¨

atzlich nach verschiedenen Strategien vorgegangen werden (in Anlehnung

an [Ort00] und [Bru04]):

âEs wird eine Standardsoftware verwendet, die durch Customizing an didaktische

und organisatorische Anforderungen angepasst werden kann2

âEs wird eine Standardsoftware ausgew¨

ahlt und das didaktische und organisatori-

sche Vorgehen wird an die Software angepasst

âDie Entwicklung der Lernumgebung erfolgt auf Basis eines Frameworks. Dazu wer-

den vorgefertigte Module des Frameworks konfiguriert und zu einem Gesamtsystem

zusammengefasst3

âSpezialisierte Fach-Komponenten werden innerhalb einer Softwarearchitektur mit-

einander kombiniert, um individuelle neue Anwendungsl¨

osungen oder neue Kom-

ponenten umzusetzen (vgl. [RH05]).

Wurde die letztgenannte Strategie in den vorhergehenden Kapiteln bislang nur mit

dem Argument eines integrierten Informationsmanagements motiviert, l¨

asst sich an die-

ser Stelle im direkten Vergleich alternativer Strategien noch anmerken, dass nur unter

dieser Strategie hochschulinterne Eigenentwicklungen integrierter E-Learning-Werkzeuge,

die f¨

ur einen hochschulweiten Einsatz gedacht sind, ¨

okonomisch vertretbar sind: Mit

einer komponentenorientierten Architektur k¨

onnen Entwicklungskosten durch die Wie-

derverwendung bereits etablierter Dienste eingespart werden. Vor allem jedoch Kosten

f¨

ur Wartung und Weiterentwicklung, wenn proaktiv Integration und Modularisierung

betrieben wird.

Im Folgenden sollen Komponentenarchitekturen n¨

aher ausgef¨

uhrt werden, um damit

ein grundlegendes Verst¨

andnis f¨

ur die zu konzipierende Rahmenarchitektur zu schaf-

fen. Allgemeine Entwurfsprinzipien und Hinweise zur hochverf¨

ugbaren Anordnung von

Komponenten z¨

ahlen zum Entwicklungsmodell und somit zum dynamischen Teil der

Rahmenarchitektur, und werden daher ebenfalls behandelt.

2Standard-Plattformen gibt es im E-Learning sowohl im Open Source-Umfeld (bspw. moodle, Ilias,

openUSS) als auch auf dem kommerziellen Markt (bspw. Clix, Blackboard/WebCT). Vgl. dazu

[GL05] f¨

ur eine Untersuchung der Adaptierbarkeit von Open Source-Lernplattformen.

3Kerres beschreibt diese Art der Entwicklung konfigurierbarer Lern- und Arbeitsumgebungen beispiel-

haft in [Ker06] anhand des Content Management Systems Drupal (http://www.drupal.org/).

114

4.1. Komponentenarchitekturen

4.1.1. Begriffsdefinitionen

4.1.1.1. Der Architekturbegriff

Der Begriff der Architektur wird in der IT immer dann verwendet, wenn die Struktur

und das Zusammenwirken von Informationssystemen oder einzelnen Hardware-/Soft-

warekomponenten beschrieben werden soll. Eine ”IT-Architektur kann [. . . ] als Struktur

bzw. Zusammenhang zwischen diversen Komponenten verstanden werden“ [Sch04c], S. 8.

Bass et al. konkretisieren diese Aussage: ”The architectural view of a system is abstract,

distilling away details of implementation, algorithm, and data representation and con-

centrating on the behavior and interaction of “black box” elements“ [BCK03], S. 3.

Andere Definitionen implizieren dar¨

uber hinaus auch die der Architektur zugrunde

liegenden Prinzipien, nach denen Entwurfsentscheidungen getroffen werden: Nach Ma-

sak ist eine Architektur ”[. . . ] eine formale Beschreibung eines Systems, ein detaillierter

Plan des Systems und seiner Komponenten, die Struktur der Komponenten, ihre Wech-

selwirkungen, ihre Prinzipien und Richtlinien, die ihren Entwurf, ihre Entwicklung und

Implementierung steuern“ [Mas05], S. 9. Das IEEE hat mit dem ANSI/IEEE-Standard

1471-2000 eine Handlungsempfehlung f¨

ur das Beschreiben von Architekturen auf dem

Gebiet der softwareintensiven Systeme4erarbeitet. Daf¨

ur wird eine Architektur als ”[. . . ]

the fundamental organization of a system embodied in its components, their relation-

ships to each others and to the environment and the principles guiding its design and

evolution“ definiert (s. [S+00], S. 9). Die Verwendung des Ausdrucks fundamental orga-

nization beschreibt in dieser Begriffsdefinition grundlegende, einheitliche Prinzipien und

Konzepte, w¨

ahrend system repr¨

asentativ f¨

ur Applikationen, Plattformen oder Unterneh-

men selbst verwendet wird. Als Architekturumgebung (environment) wird hingegen der

entwicklungsgem¨

aße, operative oder programmatische Kontext des Systems verstanden

(vgl. [Hil00], S. 10).

Die Definitionen lassen erkennen, dass es sich bei Architekturen im Bereich der soft-

wareintensiven Systeme um komplexe Gebilde handelt, welche die Interaktionen ihrer

Teilsysteme und die Teilsysteme selbst (im Weiteren als Komponenten bezeichnet) ab-

strakt beschreiben und organisieren. Weiterhin bietet eine Architektur Prinzipien zur

Weiterentwicklung und Gestaltung der Architektur selbst (vgl. S. 123ff.)5.

Eine Rahmenarchitektur beschreibt ein idealtypisches Muster f¨

ur eine bestimmte Klas-

se von Architekturen. Auf Basis dieses allgemeinen Musters k¨

onnen speziellere Modelle

mit geringeren Kosten konstruiert werden. Dar¨

uber hinaus kann eine Rahmenarchitek-

tur auch als Vergleichsobjekt f¨

ur andere Modelle dienen, die den gleichen Sachverhalt

beschreiben. Eine Abgrenzung zu abstrakteren Rahmenarchitekturen und zum Software-

design wurde bereits auf S. 43ff. vorgenommen.

4S¨

amtliche Systeme, bei denen Software essentiellen Einfluss auf Design, Konstruktion, Einsatz und

Evolution des Systems in seiner Gesamtheit aus¨

ubt (vgl. [LMW05], S. 47).

5Dern spricht daher in seiner Definition einer Softwarearchitektur diesbzgl. von einem statischen

(Struktur) und einem dynamischen Teil (Entwicklungssystem, vgl. [Der03], S. 18). In dieser Arbeit

wird unter dem Architekturbegriff der von ihm als statisch deklarierte Teil verstanden.

115

4. Eine Rahmenarchitektur f¨

ur universit¨

ares E-Learning

4.1.1.2. Der Komponentenbegriff

Vor dem Hintergrund einer komponentenbasierten Architektur kapseln Komponenten lo-

gisch zusammenh¨

angende Funktionen eines Systems, um die Wiederverwendbarkeit und

den Gesamt¨

uberblick ¨

uber die Systemstruktur zu erleichtern. Vor allem in der Entwick-

lung von verteilten Systemen wird auf das Konzept der komponentenbasierten Anwen-

dungsentwicklung zur¨

uckgegriffen, um sie an verschiedenen Standorten ablegen und mit

einer einheitlichen Zugriffsschnittstelle ausstatten zu k¨

onnen (vgl. [RHQ+04], S. 144).

Zudem kann ein bestehendes System durch den Austausch einer Komponente in sei-

ner Funktionalit¨

at erweitert werden, da das Interface zur Kommunikation mit anderen

Teilen des Systems nicht oder nur wenig modifiziert wird (vgl. [RHQ+04], S. 4).

Obwohl das Konzept komponentenorientierter Softwarearchitekturen nunmehr ¨

uber

30 Jahre alt ist und entsprechende Technologien wie COM+ und Enterprise Java Be-

ans (EJB) bereits seit mehreren Jahren produktiv in der Softwareentwicklung eingesetzt

werden, ist eine einheitliche Definition des Komponentenbegriffs in der Literatur nicht

existent (vgl. [Tur99]). Eine vielzitierte Definition einer Komponente wurde von Szy-

perski und Pfister gegeben (vgl. [SP97]): ”A software component is a unit of compo-

sition with contractually specified interfaces and explicit context dependencies only. A

software component can be deployed independendly and is subject to composition by

third parties“.

Andere Definitionen des Komponentenbegriffs betonen neben der kompositorischen

Wiederverwendung noch das Kriterium der Abgeschlossenheit, wenn ihr ihre Bestand-

teile6eindeutig zuordenbar sind, so dass die Komponente als Ganzes klar von anderen

Komponenten abgegrenzt werden kann. Idealerweise ist eine klare Trennung der Kom-

ponenten deswegen angestrebt, um diese einzeln entwickeln und sp¨

ater zusammenf¨

ugen

zu k¨

onnen (vgl. [JN05], S. 6f.)7.

In dieser Arbeit wird unter einer Komponente demnach ein modularer Architekturteil

verstanden, der seinen internen koh¨

arenten Funktionsumfang transparent kapselt und

so vor dem Nutzer verbirgt. Die darin eingeschlossenen Artefakte bieten im Ganzen eine

klar definierte Funktionalit¨

at an8. Durch ihre Abgeschlossenheit ist eine Komponente

ein eigenst¨

andiges System. Dabei kann der Funktionsumfang jedoch auch auf der Nut-

zung von anderen Komponenten basieren. Abbildung 4.1 stellt die Eigenschaften einer

Komponente in der Unified Modelling Language (UML) dar.

6Nach Ackermann et al. z¨

ahlen zu diesen (Software-)Artefakten der ausf¨

uhrbare Code, darin verankerte

Grafiken, Textkonstanten usw., die einen initialen Zustand der Komponente beschreibenden Daten,

z. B. Voreinstellungen oder Parameter, sowie Spezifikation, (Anwender-) Dokumentation und (auto-

matisierte) Tests (vgl. [A+02], S. 1). Dazu Rupp in [RHQ+04], S. 144.: ”Auf der technischen Seite

besteht eine Komponente aus einer Reihe von interagierenden Klassen, die gemeinsam Aufgaben

erf¨

ullen und diese nach außen durch eine klar definierte Schnittstelle anbieten“.

7Eine klare Abgrenzung ist in der Praxis jedoch schwierig, wenn ein Problembereich sich nur

schwer oder ¨

uberhaupt nicht separieren l¨

asst (crosscutting concerns), bspw. Instanz-, Logging-,

Distributions- und Transaktions-Management (vgl. [JN05]).

8Von einer Fachkomponente spricht man, wenn eine Komponente eine bestimmte Menge von Funk-

tionen einer bestimmten fachlichen Anwendungsdom¨

ane anbietet (vgl. [A+02], S. 1). Dazu Herzum

in [HS00]: ”A business component is the software implementation of an autonomous business con-

cept or business process.“ Andresen in [And03] , S. 18: ”Das Wissen einer Software-Komponente

repr¨

asentiert ein Konzept eines Gesch¨

aftsfeldes“.

116

4.1. Komponentenarchitekturen

«artifacts»

teilnehmer.jar

«component»

Teilnehmerverwaltung

«realization»

Teilnehmer

Verwaltungsmetadaten

«provided interfaces»

Sortierter Zugriff

Wahlfreier Zugriff

«required interfaced»

Speichermedium

Abbildung 4.1.: Eine Fachkomponente in UML-Notation

Karlsson klassifiziert in [Kar95], S.12ff. wiederbenutzbare Komponenten nach drei Krite-

rien, welche im weiteren Verlauf dieses Kapitels zur Beschreibung der Komponentenarten

verwendet werden:

Umfang der Wiederverwendbarkeit Zu unterscheiden sind dabei die Kategorien ”gene-

ral“, ”domain“ und ”product-line“. Generische Komponenten sind bspw. Schalt-

fl¨

achen f¨

ur Benutzungsschnittstellen. Der Kategorie ”domain“ sind

Komponenten zuzuordnen, die spezifisch f¨

ur eine Anwendungsdom¨

ane sind und

die Kategorie ”product-line“ umfasst Komponenten, die sich auf eine Produktlinie

beziehen.

Ziel der Wiederverwendung Dieses Kriterium unterscheidet, ob eine Komponente f¨

den internen Gebrauch oder (auch) f¨

ur die externe Vermarktung gedacht ist.

Komponentengranularit¨

at Das Kriterium gibt an, ob eine Komponente eine geringe

oder hohe Granularit¨

at aufweist.

Komponenten sind immer Teil einer Softwarearchitektur, welche eine Laufzeitumgebung

f¨

ur Instanzen dieser Komponenten bietet und Interaktionen sowohl zwischen ihnen und

Instanzen anderer Komponenten regelt als auch mit der Infrastruktur selbst. Daher

implementieren Komponenten von der Softwarearchitektur vorgegebenen Schnittstellen

bzw. gen¨

ugen einem bestimmten Komponentenmodell.

117

4. Eine Rahmenarchitektur f¨

ur universit¨

ares E-Learning

4.1.1.3. Eine serviceorientierte Architektur (SOA)

Serviceorientierte Architekturen stellen eine Fortf¨

uhrung der komponentenorientierten

Architekturen dar (vgl. [Tur99], [Ort00], [Sch01a], [And03]9).

In diesem Kontext wird das Konzept des Dienstes (Web-Service) eingef¨

uhrt, das durch

folgende Eigenschaften charakterisiert ist: (1) Ein Web-Service kann mit seiner Dienstbe-

schreibung bei einem Dienstverzeichnis (Registry) registriert werden und ist dar¨

uber lo-

kalisierbar. (2) Web-Services unterst¨

utzen lose gekoppelte Verbindungen. Das bedeutet,

dass Dienste durch andere Dienste mit gleicher Funktionalit¨

at ersetzt werden k¨

onnen.

Gleichzeitig k¨

onnen gleichartige Dienste mehrfach gestartet werden. Das erh¨

oht die Ska-

lierbarkeit ebenso wie die Ausfallsicherheit. Dienste kapseln (analog zu den Komponen-

ten) also bestimmte Funktionen in einer internen Struktur und bieten nach außen wohl

definierte Schnittstellen an, welche ¨

uber das Netzwerk angesprochen werden k¨

onnen.

Durch die klar definierten Schnittstellen der Services wird eine maximale Entkopplung

erreicht, die externe Einfl¨

usse so stark verringert, dass Dienste selbst zur Laufzeit dyna-

misch hinzugebunden oder ausgetauscht werden k¨

onnen.

Anwendungen funktionieren in SOAs als Zusammensetzung von verschiedenen Diens-

ten, die unabh¨

angig von der Anwendung und den IT-Plattformen, auf denen sie laufen,

eingesetzt werden k¨

onnen. Da die einzelnen Services als separate Bausteine verf¨

ugbar

sind, k¨

onnen diese auf verschiedene Art und Weise gruppiert und integriert werden, um

so v¨

ollig neue Funktionalit¨

at zu erstellen. Sie sollen es erm¨

oglichen, jegliche softwaretech-

nische Anforderung in k¨

urzester Zeit in bestehende Systemlandschaften zu integrieren.

Nach Sommerville k¨

onnen Web-Services durch Komponenten auf unterschiedlichen

Abstraktionsebenen implementiert werden: Eine Komponente kann im Extremfall als

vollst¨

andige Systemabstraktion auftreten und somit ein in sich geschlossenes System mit

einer Vielzahl an Diensten repr¨

asentieren. Eine Komponente kann aber auch nur eine

einzelne Funktion implementieren, somit w¨

urde ein Dienst gleichzeitig eine Komponente

repr¨

asentieren (vgl. [Som07], S. 321). Abbildung 4.2 stellt diese Zusammenh¨

ange in einem

Metamodell dar.

Component

name

Provided

Port

Required

Port

mode

Port

name

Service

name

Protocol

Operation

name

Parameter

name

Type

name

Exception XSD

provided

required exception

return type

type

Abbildung 4.2.: Metamodell f¨

ur Dienste und Komponenten (in Anlehnung an [V¨

ol06]).

9Dar¨

uber hinaus beschreiben Roth und Hampel in [RH05] die Umsetzung von E-Learning-Software als

komponentenorientierte Anwendung.

118

4.1. Komponentenarchitekturen

Dienste sind ein wesentlicher Bestandteil bei der modernen Architekturentwicklung, da

sie zun¨

achst unabh¨

angig einer bestimmten Programmiersprache und Plattform von der

tats¨

achlichen Implementierung von Funktionalit¨

at abstrahieren und somit im Gegensatz

zu rein komponentenorientierten Architekturen flexibler einsetzbar sind (vgl. [Bec03],

S. 4f.; vgl. auch [Tur03],S. 3ff.). Als Kommunikationsprotokoll zum Nachrichtenaustausch

zwischen Diensten k¨

onnen Basisprotokolle wie bspw. HTTP oder SMTP genutzt wer-

den. Die Nutzung der Dienste erfordert dar¨

uber hinausgehend drei Standards: (1) zur

Beschreibung von Diensten, (2) zum Suchen und Finden von Diensten in verteilten Um-

gebungen und (3) zur ¨

Ubermittlung von Parametern bzw. Ergebnissen:

WSDL Die Web Service Description Language (WSDL) ist eine Metasprache, mit der

Dienste XML-basierend beschrieben werden k¨

onnen, insbesondere welche Funk-

tionalit¨

aten der Web-Service ¨

uber welche Objekte mit welchen Parametern bereit-

stellt10. Neben diesen Strukturen und Datentypen definiert eine solche Dienstbe-

schreibung vor allem das Mapping zwischen den Parametern und den zugeh¨

origen

SOAP-Datentypen sowie das Binding an unterliegende Protokolle.

UDDI Mit Hilfe der Universal Description, Discovery and Integration (UDDI) als eine

Art Verzeichnis k¨

onnen Dienste auf einheitliche Weise beschrieben, aufgefunden

und integriert werden. Informationen im UDDI-Verzeichnis k¨

onnen auf verschie-

dene Arten abgerufen werden. Das Verzeichnis ist dazu dreigeteilt: Die White

Pages enthalten Adressen und Kontaktinformationen eines Dienstanbieters. Die

Yellow Pages werden benutzt, um Dienstanbieter zu klassifizieren und zu katego-

risieren. Auf diese Weise entsteht eine Art Branchenbuch. Schließlich enthalten die

Green-Pages noch technische Beschreibungen zu den angebotenen Web-Services.

Der Zugriff auf das Verzeichnis erfolgt ¨

uber eine SOAP-Schnittstelle. Je mehr Web-

Services existieren und f¨

ur verschiedene Zwecke genutzt werden, desto interessanter

wird der Gedanke, UDDI einzusetzen (vgl. [Kla04], S. 4).

SOAP Das vormals genannte Simple Object Access Protocol definiert ein Rahmenwerk11,

mit dem Dienste untereinander Nachrichten austauschen k¨

onnen. Dazu werden

die auszutauschenden Daten als SOAP-Nachricht in einen so genannten SOAP-

Umschlag (Envelope) verpackt, in dessen Header-Element Meta-Informationen

zum Routing, zur Verschl¨

usselung oder zur Transaktionsidentifizierung unterge-

bracht werden k¨

onnen. Der Transport der Nachricht basiert ¨

uber o. g. Basispro-

tokolle wie HTTP und ist dadurch auch f¨

ur den Einsatz in st¨

arker gesicherten

Netzwerken geeignet, in denen Firewalls nur Ports f¨

ur Basisdienste durchl¨

assig

gestalten. Nicht so umfangreiche und dadurch leichtgewichtigere Alternativen zum

SOAP-Standard sind XML-RPC und REST (Representational State Transfer)12.

10Ein Vorteil bei WSDL ist die Lesbarkeit beim Entwickler w¨

ahrend der Entwicklungsphase durch die

klare Strukturierung des XML-Formats.

11Das SOAP-Rahmenwerk umfasst Regeln f¨

ur das Nachrichtendesign, Regeln zur Abbildung und Inter-

pretation von Daten, sowie Regeln f¨

ur entfernte Prozessaufrufe mittels SOAP.

12Weitere Informationen zu XML-RPC finden sich im Internet unter http://www.xmlrpc.com/. Letzter

Zugriff: 31.07.2008.Eine ausf¨

uhrliche Beschreibung zu REST findet sich in der Dissertation von

Fielding (vgl. [Fie00]).

119

4. Eine Rahmenarchitektur f¨

ur universit¨

ares E-Learning

Abbildung 4.3 veranschaulicht das Zusammenspiel der drei genannten Web-Service-

Standards bei entfernten Funktionsaufrufen. Ob der Einsatz von Web-Services sinnvoll

ist, muss im Einzelfall gepr¨

uft werden (vgl. [Wie03], S. 22f.). Derzeitig fehlende Stan-

dards bei den so genannten Web-Services Add-Ons, also Erweiterungen bspw. zur In-

tegrit¨

at, Transaktionssicherheit oder Authentifizierung, k¨

onnen dagegen sprechen. Vor

allem bedingt die Nutzung von Web-Services in stark gekoppelten komponentenorien-

tierten Architekturen einen hohen Overhead an ¨

Ubertragungsvolumen und Rechenleis-

tung, insbesondere bei wenig Austauschdaten13. Aufgrund des flexiblen Aufbaus k¨

onnen

jedoch komplexere Datenstrukturen in einer SOAP-Nachricht ausgetauscht werden, wo-

hingegen in stark gekoppelten Systemen mehrere Anfragen n¨

otig w¨

aren. In diesen F¨

allen

w¨

urde ein besseres Nutzlastverh¨

altnis und ein verh¨

altnism¨

aßig geringerer Kommunika-

tionsaufwand erzielt werden.

Einführung Portalsysteme 26

Die technologische Basis von Portalsystemen

Die zugrunde liegenden Web-Service Standards werden im weiteren Verlauf der Arbeit noch

erläutert. Im nächsten Schritt stellt sich die Frage: Wie funktioniert grundsätzlich ein Web-

Service? Ein sog. „Service Provider“ bietet einen Web-Service an, beschreibt ihn mit WSDL

und veröffentlicht ihn im UDDI-Verzeichnis. Dieser Web-Service kann nun über bestimmte

Mechanismen von einem sog. „Service Consumer“ gefunden und anschließend beim Provider

abgerufen werden. Die Kommunikation erfolgt bei allen Beteiligten mit SOAP. Eine grafi-

sche Darstellung der Kommunikation gibt dabei folgende Abbildung:

Abbildung 2.13: Funktionsweise von Web-Services (eigene Darstellung nach [Nagl 03], S. 7)

Web-Services sind ein wesentlicher Bestandteil bei der Portalentwicklung, da sie bedeutende

Vorteile aufweisen können. Sie nutzen den XML-Standard und sind somit unabhängig in Be-

zug auf die Programmiersprache und die verwendete Plattform. Da sie nur offene Standards

verwenden, fallen keine Lizenzkosten in diesem Bereich an. Web-Services basieren auf ser-

viceorientierten Architekturen. Sie können so als Bindeglied zwischen heterogenen Anwen-

dungen fungieren. Im Gegensatz zu komponentenorientierten Architekturen abstrahieren sie

von der tatsächlichen Implementierung und sind so flexibler einzusetzen (vgl. [Beck 2003],

S.4f.; vgl. auch [Turau 03], S. 3ff.). Gerade durch diese Vorteile nimmt die Nutzung von

Web-Services als Middleware zu. Web-Services nutzen HTTP als Übertragungsprotokoll. Der

Einsatz anderer Basisprotokolle wie z.B. SMTP ist aber auch möglich. Die Entwicklung von

Web-Services ist einfach, da diese Technologie in Integrated Development Environments

(IDEs) integriert ist. Auf Knopfdruck können zu Businessfunktionen alle Beschreibungen

erstellt werden, die für die Bereitstellung der Funktionalität als Web-Service erforderlich sind.

Verzeichnis

(UDDI)

Service

provider

Service

consumer

(1) Service-Beschreibung in WSDL

(2) Verzeichnisanfragen

(3) Anfrage-Antworten in WSDL

(4) XML Service Anfrage auf Basis WSDL

(5) XML Service Antwort auf Basis WSDL

(1)

(4)

(5)

(3)

(2)

SOAP Messages

Abbildung 4.3.: Funktionsweise von Web-Services (eigene Darstellung nach [Nag03],

S. 7).

4.1.2. Verteilte Informationsverarbeitung auf Basis von Middleware

Bei der kombinierten Nutzung verschiedener Komponenten einer Architektur k¨

onnen

zwei Kommunikationsparadigmen unterschieden werden, die den Verhaltensablauf der

Interaktion beschreiben und entscheidend f¨

ur die Flexibilit¨

at der Komponenten-Schnitt-

stellen sind: Bei der synchronen Kommunikation muss der Sender einer Nachricht auf die

Antwort des Empf¨

angers warten, um mit der Verarbeitung fortzufahren. Im Gegensatz

dazu wird die Kommunikation zwischen Applikationen als asynchron bezeichnet, wenn

13Beispiel: Zur Versendung von Wahr/Falsch-Werten muss zun¨

achst ein XML-Dokument gebaut und

validiert werden. Durch die f¨

ur den Versand ben¨

otigten Metadaten werden oftmals mehrere hundert

Bytes ben¨

otigt. In stark gekoppelten Systemen reicht f¨

ur diese Information ein einziges Bit aus.

120

4.1. Komponentenarchitekturen

der Sender nach Versand einer Nachricht direkt mit der Verarbeitung fortfahren kann,

w¨

ahrend der Empf¨

anger die Nachricht entweder sofort verarbeitet, oder in einem Puffer

vorh¨

alt und erst bei Bedarf die Verarbeitung vornimmt. Synchrone und asynchrone

Kommunikation schließen sich nicht gegenseitig aus, in der Regel sieht eine wohldefinierte

Informationsarchitektur die Verwendung beider Paradigmen vor.

Innerhalb der funktionalen Integration von Komponenten kann man zwischen verschie-

denen Ans¨

atze unterscheiden, die auf einem bestimmten Kommunikationsparadigma

beruhen und den Punkt des Zugriffs auf einen zu integrierenden Baustein definieren:

(1) Integration ¨

uber entfernte Funktionsaufrufe, (2) Integration ¨

uber verteilte Objekte

und (3) synchrone und asynchrone nachrichtenbasierte Kommunikation (vgl. [OWZ+05],

S. 43ff., [RHG05], S. 70f.).

4.1.2.1. Remote Procedure Calls

Die Integration ¨

uber entfernte Funktionsaufrufe (sog. Remote Procedure Calls, RPCs)

stellt die ¨

alteste Form der funktionalen Integration dar und basiert dabei auf dem syn-

chronen Kommunikationsparadigma. Dazu ruft eine Komponente in einem entfernten

System/einer anderen Komponente eine Funktion auf und ¨

ubergibt dabei die ben¨

otigten

Daten als Aufrufargument. Die Anzahl der Argumente sowie die verwendeten Datenty-

pen werden durch die Signatur der Funktion definiert14. Die Funktion wird meist vom

Empf¨

anger als Teil einer Schnittstelle (Application Programming Interface, API) zur

Verf¨

ugung gestellt. RPCs erlauben somit einer Komponente, Funktionen entfernter Sys-

teme f¨

ur die Bew¨

altigung der eigenen Aufgaben in Anspruch zu nehmen. Auf dem glei-

chen Weg k¨

onnen allerdings auch g¨

anzlich neue Softwarebausteine geschaffen werden.

Hierzu werden mehrere entfernte Funktionsaufrufe durch eine anwendungs¨

ubergreifende

Funktion zusammengefasst, die eigenst¨

andig aufgerufen werden kann.

4.1.2.2. Verteilte Objekte

RPCs stellen bei verteilten Objekten die Basistechnologie dar, um ¨

uber standardisierte

Schnittstellen und Protokolle miteinander zu kommunizieren. Bei solchen objektorien-

tierten Zugriffen auf Fremdanwendungen kann eine Kommunikation zwischen Systemen

nur dann stattfinden, wenn sie eine gemeinsame verteilte Objektschnittstellenarchitek-

tur unterst¨

utzen. In diesem Bereich sind die Standardisierungen durch das Component

Object Model (COM) und die Common Object Request Broker Architecture (CORBA)

am h¨

aufigsten anzutreffen. Auch hier ist eine enge Bindung der integrierten Systeme

gegeben, da sowohl das Objektmodell als auch die Objektschnittstellenarchitektur ge-

meinsam verwendet werden m¨

ussen.

14Schnittstellenbasierte Kommunikation bindet dadurch die aufrufende Komponente st¨

arker an das

entfernte System. Wird die Signatur der Funktion in der angebotenen Schnittstelle ge¨

andert, muss die

aufrufende Komponente ebenfalls angepasst werden, was zu erheblichen Aufw¨

anden f¨

uhren kann (vgl.

[OWZ+05], S. 65). Außerdem ist die aufrufende Komponente auf die Verf¨

ugbarkeit des entfernten

Systems angewiesen.

121

4. Eine Rahmenarchitektur f¨

ur universit¨

ares E-Learning

4.1.2.3. Message oriented Middleware

Nachrichten-orientierte Middleware (Message oriented Middleware, MOM) erfordert im

Gegensatz zu den RPCs keine enge Bindung zwischen integrierten Systemen, da Nach-

richtendienste die ¨

Ubermittlung von kleinen Datens¨

atzen vornehmen. Somit braucht

die rufende Komponente nicht blockiert werden, w¨

ahrend sie auf das Ergebnis des

Funktionsaufrufs wartet. Mit der Interprozesskommunikation (IPC) und dem Messa-

ge Queuing (MQ) k¨

onnen zwei Kommunikationsparadigmen unterschieden werden. Bei

IPC m¨

ussen zum Nachrichtentausch beide Prozesse gleichzeitig aktiv sein, w¨

ahrend beim

Message-Queue-Modell vor allem Warteschlangen (Message Queues) zum Einsatz kom-

men, die Nachrichten speichern und bei Bedarf oder Verf¨

ugbarkeit weiterleiten15. Mes-

sage Broker erweitern das Konzept der Nachrichten-orientierten ¨

Ubermittlung von In-

formationen, indem sie einen zentralen Server als Steuerungseinheit bereitstellen, der

zus¨

atzlich zur Kommunikation auch eine Transformation von Nachrichten vornehmen

kann. Dar¨

uber hinaus existieren noch Transaktionsmonitore und Applikationsserver, die

zur Transaktions-orientierten Middleware z¨

ahlen. Beide Softwarekomponenten beziehen

sich auf Transaktionen, also abgeschlossene Aufgabeneinheiten mit definiertem Beginn

und Ende. Die abzuarbeitenden Aufgaben innerhalb einer Transaktion k¨

onnen unter-

schiedlichster Natur sein und beispielsweise Applikations- und Datenbankzugriffe, das

Absetzen von Nachrichten oder den Aufruf verteilter Objekte umfassen.

Bezogen auf eine universit¨

are Informationsarchitektur k¨

onnen zum Beispiel durch eine

solche Funktionsintegration die Informationen eines neu angelegten Kurses im Adminis-

trationssystem ¨

uber eine Warteschlange automatisch an Lernplattformen weitergelei-

tet werden, wenn diese Nachrichten vom Typ ”Kurs angelegt“ abonniert haben. Die

Ubermittlung ist dabei eine Folge von Funktionsaufrufen. Middleware-Produkte k¨

onnen

hierbei die Steuerung ¨

ubernehmen. Die Vor- und Nachteile einer Funktionsintegration

sind in Tabelle 4.1 zusammengefasst.

Vorteile Nachteile

oWeites Spektrum l¨

osbarer Integrationspro-

bleme (einschließlich Pr¨

asentations- und

Datenintegration)

oHohe Wiederverwendbarkeit der Software-

komponenten

oRelativ hohe Komplexit¨

at, Lernkurve

oModifikation der Anwendungen notwendig

oZugriff auf Logik kann schwierig sein, wenn

Informationen aus dem Quellcode oder der

API Spezifikation fehlen

Tabelle 4.1.: Vor- und Nachteile einer Funktionsintegration nach [Kai01].

15Beispiele f¨

ur Message Queuing Produkte sind IBM MQ Series, Microsoft MSMQ oder Tibco Rende-

vous.

122

4.1. Komponentenarchitekturen

4.1.3. Entwurfsprinzipien von Komponentenarchitekturen

Prinzipien beschreiben Leitkriterien, denen ein Entwurf folgen sollte. Sie bilden ”den

gemeinsamen, verbindlichen Hintergrund, den die Zerlegung und Aufteilung in Ein-

zelkomponenten ben¨

otigt“ [BV03], S. 42. Im Gegensatz zu Entwurfsmustern beschrei-

ben Prinzipien nicht die betroffenen Komponenten oder deren Gestaltung in einem

Systemkonzept, sondern legen grundlegende Eigenschaften einer Architektur fest. Ein

Entwurfsmuster kann auf verschiedenen Prinzipien beruhen. Auch Heuristiken sind ein

Beispiel f¨

ur Prinzipien, die sich in der Praxis bew¨

ahrt haben und als generelle Richtli-

nien in die Architekturplanung einfließen (vgl. [Ham05b], S. 72). Ein bekanntes Beispiel

ist der Architekturgrundsatz Separation of Concerns (Trennung der Zust¨

andigkeiten)

von Dijkstra. Der Grundsatz genießt in der Softwareentwicklung besondere Bedeutung,

kann aber auch auf die IT-Architektur angewandt werden. Er besagt, dass ein System

so strukturiert sein sollte, dass Zust¨

andigkeiten innerhalb des Gesamtsystems separiert

und eindeutigen Teilsystemen oder Komponenten zugeordnet werden k¨

onnen (vgl. ebd.).

In der Systemarchitektur legt dieses Prinzip den Grundstein f¨

ur den Aufbau verteilter

IT-Infrastrukturen.

Der Entwurf und die Verteilung von Komponentenarchitekturen beruht in Anlehnung

an Dyson and Longshaw auf vier wesentlichen Prinzipien (vgl. [DL04], S. 91ff.): Re-

dundanz (Redundancy), Funktionale Identit¨

at (Functionally-Identical Elements), einfach

gerichtete Abh¨

angigkeiten (One-Way Dependencies) und Standardprotokolle (Standard

Protocols). Diese sollen im Folgenden erkl¨

art werden.

4.1.3.1. Redundanz

Das Prinzip der Redundanz l¨

asst sich recht einfach beschreiben: ”Add more capacity than

you normally need, then use this capacity in abnormal situations such as when things

fail or when there is more load on the system as usual“ [DL04], S. 92. Die Ziele, die mit

dem Prinzip der Redundanz verfolgt werden, sind die Erh¨

ohung der Verf¨

ugbarkeit und

die Sicherstellung einer ausreichenden Performance des Systems. Redundanz kann in ei-

ner Architektur in zwei unterschiedlichen Erscheinungsformen auftreten: Vervielf¨

altigung

(duplication) und/oder durch ¨

Uberkapazit¨

at (over-capacity). Durch Vervielf¨

altigung ein-

zelner Komponenten wird in einem Fehlerfall die Fortf¨

uhrung des Dienstes durch ein an-

deres Element garantiert, sodass ein Ausfall nicht bemerkbar ist. Im extremsten Fall wird

das ganze System dupliziert16.¨

Uberkapazit¨

aten dienen vornehmlich der Abschw¨

achung

von so genannten Lastspitzen, die ein System in Gefahr bringen k¨

onnen. ¨

Ublicherweise

werden ¨

Uberkapazit¨

aten in Form von Sicherheitsfaktoren bei der Bedarfsermittlung von

Ressourcen ber¨

ucksichtigt, z. B. bei der Bestimmung des Hauptspeicherbedarfs f¨

ur einen

Datenbankserver oder der ben¨

otigten Bandbreite einer Internet-Verbindung. Sie die-

nen auch als Absicherung sp¨

aterer Ausbaustufen und Erweiterungen. Die Entscheidung

f¨

ur die Umsetzung einer Redundanz ist f¨

ur jeden Einzelfall durch eine Kosten-Nutzen-

Analyse zu bewerten. ”By definition, the extra capacity introduced [by redundancy]

won’t normally be required but does need to be paid for“ [DL04], S. 92.

16Die Ermittlung der Komponenten in einem System, die redundant ausgelegt werden sollten, wird

durch eine Schwachstellenanalyse (single point of failure analysis) durchgef¨

uhrt.

123

4. Eine Rahmenarchitektur f¨

ur universit¨

ares E-Learning

4.1.3.2. Funktionale Identit¨

Das Prinzip der Funktionalen Identit¨

at besagt, dass duplizierte Komponenten den glei-

chen Umfang an Funktionen bereitstellen m¨

ussen. Dies bedeutet jedoch nicht, dass auch

ihre nicht-funktionalen Eigenschaften (Verf¨

ugbarkeit, Performance, etc.) identisch aus-

gepr¨

agt seien m¨

ussen. Aus Kostengr¨

unden erscheint es in vielen F¨

allen nicht sinnvoll,

gerade teure Spezialkomponenten mehrfach auszulegen. Hier w¨

urde es sich anbieten, f¨

den w¨

ahrend eines Ausfalls ¨

uberschaubaren Zeitraum eine kosteng¨

unstigere Komponente

mit einer geringeren garantierten Verf¨

ugbarkeit einzusetzen. Es gibt jedoch Situationen,

in denen bei einem Ausfall in jedem Fall identische Komponenten bereitstehen m¨

ussen,

da nicht garantiert werden kann, wie lange die Wiederherstellung des urspr¨

unglichen

Systems andauern wird und w¨

ahrend dieser Zeit eine gleichwertige Dienstqualit¨

at si-

chergestellt werden muss. Dies gilt im Allgemeinen f¨

ur gesch¨

aftskritische Anwendungen.

Die Funktionale Integrit¨

at bietet damit gewisse Freiheitsgrade beim Architekturdesign.

Hierbei gilt es jedoch zu ber¨

ucksichtigen: ”When we add redundancy through the use

of duplications we need to be sure that the duplicate elements are all functional iden-

tical, but we have the option of varying the non-functional characteristics based on the

circumstances“ [DL04], S. 92.

4.1.3.3. Einfach gerichtete Abh¨

angigkeiten

In einer verteilten Architektur sind es keineswegs einzelne Elemente, mit denen nicht-

funktionale Anforderungen wie Skalierbarkeit, Flexibilit¨

at etc. erf¨

ullt werden, sondern

das systematische Zusammenspiel mehrerer dieser Komponenten. Jedoch kann gerade

das Zusammenwirken unterschiedlicher Elemente in einer Architektur die Weiterent-

wicklung des Gesamtsystems hemmen (vgl. [DL04], S. 210). Die enge Kopplung zwi-

schen den Architekturelementen erschwert die Durchf¨

uhrung von notwendig gewordenen

Anderungen an einer einzelnen Komponente. Die Abh¨

angigkeiten zu anderen Kompo-

nenten sind oft so vielz¨

ahlig, dass Ver¨

anderungen an einem Element zus¨

atzliche Maß-

nahmen an anderer Stelle bedingen. Dies l¨

asst sich an einem Beispiel aus Abbildung 4.4

verdeutlichen. Die Abh¨

angigkeiten zwischen den Komponenten A, B und C, in der Abbil-

dung dargestellt als schwarze Linien, sind jeweils doppelt gerichtet, hin zum Nachfolger

und von diesem wieder zur¨

uck (two way dependencies). Ein Austausch oder Update

der Komponente B durch die Komponente D w¨

are eine sehr zeitintensive und risiko-

behaftete Maßnahme. Es m¨

usste sichergestellt werden, dass die neue Variante D mit

A aber auch mit C zusammenarbeitet (gestrichelte Pfeile). In beide Richtungen sind

Tests durchzuf¨

uhren und unter Umst¨

anden sind an beiden betroffenen Komponenten

Maßnahmen einzuplanen. So kann es sein, dass C nur mit D zusammenarbeitet, wenn C

auf die neueste Version aktualisiert wird. Werden die Tests nicht umfassend und genau

durchgef¨

uhrt, so besteht das Risiko, dass Probleme erst sp¨

ater im produktiven Betrieb

bemerkt werden. Die Komplexit¨

at steigt mit der Anzahl der Abh¨

angigkeiten die auf eine

Komponente wirken.

Nach Dyson und Longshaw sollten doppelt gerichtete Abh¨

angigkeiten zwischen einzelnen

Komponenten vermieden und das Prinzip der einfach gerichteten Abh¨

angigkeit (One-

Way-Depenencies) verfolgt werden. Der Austausch einer Komponente B durch D kann

124

4.1. Komponentenarchitekturen

A B C

Two-way dependency One-way dependency

Abbildung 4.4.: Gerichtete Abh¨

angigkeiten in einer Komponentenarchitektur

dann wesentlich einfacher vollzogen werden, da nur ¨

uberpr¨

uft werden muss, ob D mit

A zusammenarbeitet. Die Komponente C bleibt in diesem Fall unber¨

uhrt. Die Testsze-

narien sind weniger umfangreich und die Folgen besser zu ¨

uberblicken. Die Architektur

kann flexibler und mit weniger Aufwand erweitert werden.

4.1.3.4. Einsatz von Standardprotokollen

Ist die Architektur nach dem Prinzip der einfach gerichteten Abh¨

angigkeit durchg¨

angig

konzipiert, dann kann durch den Einsatz von Standardprotokollen zus¨

atzliche Flexibi-

lit¨

at gewonnen werden. Kommunizieren die Komponenten ¨

uber Standardprotokolle wie

z. B. HTTP, SOAP etc., dann k¨

onnen sie bei Bedarf ausgetauscht werden und durch ein

anderes Produkt mit gleicher Funktionalit¨

at aber besseren nicht-funktionalen Charakte-

ristiken ersetzt werden. Dyson und Longshaw lehnen die Verwendung von propriet¨

aren

Protokollen ab: ”The use of native protocols introduces a hard dependency that can make

the replacement of a system element very difficult or even effectively impossible“ [DL04],

S. 213.

4.1.4. Exkurs: Hochverf¨

ugbarkeit einer komponentenbasierten

Infrastruktur

Nach F¨

arber kann sich eine (System-) Komponente in den Zust¨

anden verf¨

ugbar (funk-

tionst¨

uchtig) oder ausgefallen (nicht funktionst¨

uchtig) befinden (vgl. [F¨

ar94]). Im aus-

gefallenen Zustand findet in der Regel eine Reparatur der Komponente statt, die den

Ubergang in den Zustand verf¨

ugbar wieder erm¨

oglicht (vgl. [Hel05]). Im weiteren Ver-

lauf wird die Dauer der Verf¨

ugbarkeit eines Systems mit V(t) bezeichnet und die der

Nicht-Verf¨

ugbarkeit mit N(t). Durch geplante und ungeplante Ausfallzeiten eines Sys-

tems findet ¨

uber einen betrachteten Zeitverlauf ein mehr oder weniger h¨

aufiger Wechsel

zwischen den Zust¨

anden statt. Im Verlauf der Zeit setzt sich der Systemzustand einer

Komponente aus Zyklen von Zeitabschnitten der Verf¨

ugbarkeit und Nicht-Verf¨

ugbarkeit

zusammen. Die Zeitabschnitte zu denen ein System verf¨

ugbar ist, werden als Time Bet-

ween Failure (TBF) und die Zeitabschnitte der Nicht-Verf¨

ugbarkeit als Time to Repair

(TTR) bezeichnet. Die nachfolgende Abbildung stellt im zeitlichen Verlauf den Wech-

sel der Zust¨

ande eines Systems exemplarisch dar. Wird ein gen¨

ugend langer Zeitraum

betrachtet, so lassen sich hieraus zwei wichtige Kennzahlen ermitteln, mit denen die

125

4. Eine Rahmenarchitektur f¨

ur universit¨

ares E-Learning

vavava

Zyklus 1 Zyklus 2 Zyklus 3 Zyklus 4

TBF TBF TBF TBFTTR TTR TTR TTR

Abbildung 4.5.: Zeitverlauf des Systemzustandes (eigene Darstellung nach [F¨

ar94])

Verf¨

ugbarkeit eines Systems bestimmt werden kann. Die durchschnittliche Verf¨

ugbar-

keitsdauer (Mean Time between Failures, MTBF) wird als arithmetisches Mittel aus der

Summe aller Zeitabschnitte, zu denen eine Komponente verf¨

ugbar war und der Anzahl

der beobachteten Zyklen gebildet. Ein Zyklus wird dabei durch eine Folge der ¨

Uberg¨

ange

V(t) nach N(t) nach V(t) gebildet. In gleicher Weise l¨

asst sich die mittlere Dauer der

Ausfallzeit (Mean Time to Repair, MTTR) bestimmen. Sie ist das arithmetische Mittel

aus der Summe aller Zeitabschnitte, zu denen eine Komponente ausgefallen ist, und der

Anzahl gemessener Zyklen.

Es gilt:

MTBF =PTBF

Z(4.1)

und

MTT R =PTTR

Z,(4.2)

wobei Z die Anzahl der in einem Zeitraum beobachteten Zyklen ist. ”Die Verf¨

ugbarkeit

eines Systems oder einer Systemkomponente ist definiert als prozentualer Zeitanteil, in

dem dieses System bzw. die Komponente fehlerfrei funktioniert“ [Hel05], S. 36. Aus den

beiden Kennzahlen MTBF und MTTR kann nun die prozentuale Verf¨

ugbarkeit (V) eines

Systems mathematisch bestimmt werden.

F¨

ur die Verf¨

ugbarkeit eines Systems gilt:

V=MTBF

MTBF +MTT R (4.3)

Die Nicht-Verf¨

ugbarkeit (N) eines Systems kann wie folgt bestimmt werden:

N= 1 −V= 1 −MTBF

MTBF +MTT R =MT TR

MTBF +MTT R (4.4)

Die Gleichungen zeigen, dass durch die Erh¨

ohung der MTBF und Reduzierung der MT-

TR die Verf¨

ugbarkeit einer Systemkomponente erh¨

oht werden kann. M¨

ogliche Maßnah-

men zur Verbesserung der MTBF sind die Optimierung der Software- oder Hardwa-

rekomponenten eines Systems. Dadurch wird zwar die Qualit¨

at einer einzelnen Kom-

ponente verbessert, jedoch f¨

uhrt dies nur zu einem gewissen Grad an Ausfallsicherheit

126

4.1. Komponentenarchitekturen

und Verf¨

ugbarkeit. Hinzu kommt, dass Ausf¨

alle keineswegs zeitlich gleich verteilt sind

(vgl. [Hel05], S. 39). Bei neuen Systemen kann es zu so genannten Fr¨

uhausf¨

allen kom-

men, die z. B. auf eine fehlerhafte Konfiguration oder eine funktionale St¨

orung an der

Komponente, die nur unter ganz bestimmten Bedingungen auftritt, zur¨

uckzuf¨

uhren sind.

Die Anzahl der Fr¨

uhausf¨

alle k¨

onnen durch umfangreiche Testszenarien, die insbesonde-

re unter Last durchgef¨

uhrt werden sollten, deutlich reduziert werden. Danach folgt eine

Phase der statistischen Ausf¨

alle. Zur Beurteilung des Ausfallrisikos w¨

ahrend dieser Pha-

se kann auf die ermittelten Angaben des Herstellers zur¨

uckgegriffen werden, sofern diese

zur Verf¨

ugung stehen. Viele Hersteller k¨

onnen aus Erfahrungswerten oder Langzeittests

die MTBF bzw. die Verf¨

ugbarkeit einer Komponente belegen. Durch Alterung und Ver-

schleiß kann es in einer sp¨

ateren Phase wiederum vermehrt zu Fehlern kommen. Dies

gilt besonders f¨

ur Bauteile mit einem hohen mechanischen Anteil, wie z. B. Festplatten

oder L¨

ufter.

Ein komplexes System wie eine universit¨

are IT-Infrastruktur besteht jedoch nicht nur

aus einer einzigen Komponente, sondern aus einer ganzen Reihe von Systemkompo-

nenten, die in ihrer Zuverl¨

assigkeit und Verf¨

ugbarkeit unterschiedlich ausgepr¨

agt sein

k¨

onnen. Hierbei gilt es zu beachten, dass eine Leistung von diesen Komponenten ge-

meinschaftlich als verteiltes System erbracht wird.

Ein wesentlicher Faktor f¨

ur die Verf¨

ugbarkeit des Gesamtsystems ist dessen Architek-

tur, d. h. die Strukturierung der Einzelkomponenten. In Abh¨

angigkeit von der Anord-

nung der Komponenten kann die Gesamtverf¨

ugbarkeit eines Systems deutlich von den

Verf¨

ugbarkeiten der Einzelkomponenten abweichen. Mit der Serien- und Parallelschal-

tung werden zwei Anordnungsvarianten unterschieden, auf denen die Formeln f¨

ur die Be-

rechnung der Verf¨

ugbarkeit von Gesamtsystemen beruhen. In der Serienschaltung sind

Systemkomponenten in Reihe geschaltet und damit voneinander abh¨

angig. Ein System,

dass nur aus seriell angeordneten Elementen besteht ist nur verf¨

ugbar, wenn alle Ein-

zelkomponenten verf¨

ugbar sind. Dementsprechend ergibt sich die Gesamtverf¨

ugbarkeit

(Vg) als Produkt aus den Einzelverf¨

ugbarkeiten (Vi). In einer Serienschaltung von n

Einzelkomponenten gilt:

Vg=

i=1

Vi(4.5)

bzw. f¨

ur N << 1

Vg= 1 −Ng=

i=1

(1 −Ni) = 1 −

i=1

Ni(4.6)

”Die Fehlerquote eines Systems, das aus mehreren in Serie geschalteten Elementen be-

steht, steigt demnach mit der Zahl der Elemente. Betrachtet man hierf¨

ur nun die f¨

die Sicherheit relevanten Elemente, so arbeitet ein solches System nur dann sicher, wenn

alle Einzelkomponenten richtig arbeiten“ [Hel05], S. 40f. Durch Serienschaltungen wird

die Ausfallzeit und Ausfallwahrscheinlichkeit des Gesamtsystems gr¨

oßer als die der Ein-

zelkomponenten (vgl. [Hel05], S. 41; Abb. 4.6, Variante 1). In einem Architekturkonzept

m¨

ussen Serienschaltungen zu Erh¨

ohung der Gesamtverf¨

ugbarkeit bzw. zur Verringerung

127

4. Eine Rahmenarchitektur f¨

ur universit¨

ares E-Learning

der Ausfallwahrscheinlichkeit kompensiert werden. Erreicht werden kann dies durch die

Parallelschaltung von Komponenten. Hierbei werden die Systemkomponenten parallel

auf einer Ebene zusammengeschaltet und erg¨

anzen sich somit redundant (vgl. Abb. 4.6,

Variante 2). Solange eine Komponente in diesem Verbund zur Verf¨

ugung steht, kann

die Funktionalit¨

at erbracht werden. Die Komponenten sind im Gegensatz zu einer Seri-

enschaltung unabh¨

angig voneinander. Die Gesamtausfallzeit einer Parallelschaltung ist

das Produkt aus den Einzelausfallzeiten, so dass f¨

ur die Gesamtverf¨

ugbarkeit gilt:

Vg= 1 −Ng= 1 −

i=1

Nija (4.7)

”Durch die redundante Anordnung wird zwar die Fehlerwahrscheinlichkeit im System

aufgrund der gr¨

oßeren Zahl von Elementen erh¨

oht. Doch durch die Art der Verkn¨

upfung

sinkt die Wahrscheinlichkeit eines Ausfalls des Gesamtsystems betr¨

achtlich [. . . ]“ [Hel05],

S. 41.

Die vorgestellten mathematischen Formeln k¨

onnen Hinweise zur Bewertung der Anord-

nung von Komponenten innerhalb einer Architektur liefern und erm¨

oglichen so eine

zumindest theoretische Ermittlung der Verf¨

ugbarkeit eines Gesamtsystems. Die Abbil-

dung 4.6 stellt drei Entwurfsentscheidungen gegen¨

uber und beurteilt deren Auswirkung

auf die Verf¨

ugbarkeit des Gesamtsystems. Es wird angenommen, dass die Komponente

A mit einer Verf¨

ugbarkeit von 99,9 Prozent angegeben wird und die Komponente B mit

99,0 Prozent. In der zweiten und dritten Variante werden beide Komponenten jeweils

durch Elemente mit identischen Verf¨

ugbarkeiten ausgetauscht.

F¨

ur die Implementierung verteilter Architekturen sind die Anforderungen der System-

komponenten so vorzunehmen, dass die Verf¨

ugbarkeit des Gesamtsystems erh¨

oht wird.

Die Einordnung von Diensten in eine Verf¨

ugbarkeitsklasse kann mit den oben beschrie-

benen Formeln zumindest theoretisch abgestimmt werden. Ebenso lassen sich die Aus-

wirkungen durch die Hinzu- oder Wegnahme einer Komponente auf die Verf¨

ugbarkeit

des Gesamtsystems bestimmen. Um der Komplexit¨

at eines großen Systems in der Pra-

xis vollst¨

andig gerecht zu werden, m¨

ussen jedoch weitere Aspekte ber¨

ucksichtigt werden

(vgl. hierzu [Hel05], S. 44).

4.1.5. Frameworks als semantische Referenzsysteme bei der

Komponentenentwicklung

Neben der in Abschnitt 4.1.2.3 beschriebenen Funktionsintegration durch Middleware-

Konzepte und Web-Services, die prim¨

ar die Wiederverwendung von Programmcode –

also die Portabilit¨

at einer Komponente – fokussiert, ist der Integrationserfolg von An-

wendungssystemen und Komponenten auch stark von der Interoperabilit¨

at abh¨

angig:

Damit die Daten von mehreren Systemen korrekt verstanden werden k¨

onnen, muss Ei-

nigkeit ¨

uber Syntax und Semantik der ausgetauschten Daten herrschen.

128

4.1. Komponentenarchitekturen

Gestaltungstechniken zur Konzeption von Mitarbeiterportalen 154

Überlegungen zur Hochverfügbarkeit einer Portalarchitektur

kann die Funktionalität erbracht werden. Die Komponenten sind im Gegensatz zu einer Se-

rienschaltung unabhängig voneinander. Die Gesamtausfallzeit einer Parallelschaltung ist das

Produkt aus den Einzelausfallzeiten, so dass für die Gesamtverfügbarkeit gilt:

"="=

igg NNV

„Durch eine redundante Anordnung wird zwar die Fehlerwahrscheinlichkeit im System auf-

grund der größeren Zahl von Elementen erhöht. Doch durch die Art der Verknüpfung sinkt

die Wahrscheinlichkeit eines Ausfalls des Gesamtsystems beträchtlich […]“ ([Held 05], S.

41).

Die vorgestellten mathematischen Formeln können Hinweise zur Bewertung der Anordnung

von Komponenten innerhalb einer Architektur liefern und ermöglichen so eine zumindest

theoretische Ermittlung der Verfügbarkeit eines Gesamtsystems. Das folgende Beispiel stellt

drei Entwurfsentscheidungen gegenüber und beurteilt deren Auswirkung auf die Verfügbar-

keit des Gesamtsystems. Es wird angenommen, dass die Komponente A mit einer Verfügbar-

keit von 99,9 Prozent angegeben wird und die Komponente B mit 99,0 Prozent. In der zwei-

ten und dritten Variante werden beide Komponenten jeweils durch Elemente mit identischen

Verfügbarkeiten ausgetauscht.

Abbildung 5.3: Bestimmung der Verfügbarkeit bei unterschiedlicher Anordnung

der Einzelkomponenten (eigene Darstellung in Anlehnung an [Held 05])

Variante 1

Variante 2

Variante 3

Vg = V(A) ! V(B)

= 0,999 ! 0,99

= 0,989001 = 98,89 %

" 97 h Ausfallzeit im Jahr

Vg = 1- NA1B1 ! NA2B2

= 1 - (1 - V(A1) ! V(B1)) ! (1 - V(A2) ! V(B1)

= 1 – (1 - 0,999 ! 0,99) ! (1 - 0,999 ! 0,99)

= 0,999879 = 99,9879 %

" 1,1 h " 64 min Ausfallzeit im Jahr

Vg = V(Ag) ! V(Bg)

= (1 - (1- 0,999)!) ! (1 – (1-0,99)!)

= 0,999899 = 99,9899 %

" 0,88 h " 53 min Ausfallzeit im Jahr

Anordnung

Berechnung

Abbildung 4.6.: Bestimmung der Verf¨

ugbarkeit bei unterschiedlicher Anordnung der

Einzelkomponenten (eigene Darstellung in Anlehnung an [Hel05]).

W¨

ahrend die Syntax zum einen durch die Dienstbeschreibung, zum anderen durch das

zur Kommunikation verwendete Rahmenwerk (bspw. SOAP) vorgegeben wird, kann die

semantische Verbindung zwischen Systemen auf Basis neutraler bzw. genormter Aus-

tauschformate erfolgen. Dies ist oftmals dann notwendig, wenn die Systeme auf unter-

schiedlichen und getrennten Daten- und Speicherungsstrukturen basieren. Daten m¨

ussen

dann vom Quellsystem ¨

uber einen Pre-Prozessor in das Austauschformat und nach der

Kommunikation im Zielsystem ¨

uber einen Post-Prozessor in das Zielformat umgewandelt

werden. Neben dem Aufwand der Modellierung stellt hierbei insbesondere die Integrit¨

ats-

und Konsistenzsicherung eine Herausforderung dar, die nur durch eine ¨

ubergreifende und

ganzheitliche Betrachtungsweise gel¨

ost werden kann (vgl. [Hel97], S. 38).

Wird die Semantik der in der Architektur verwendeten Konstrukte jedoch systemweit

in eindeutiger Weise festgelegt, entsteht ein gemeinsames semantisches Referenzsystem

mit einer allgemeinen f¨

ur alle Anwendungen g¨

ultigen Daten- und Speicherungsstruk-

tur17. Die Standardisierung erfolgt daher nicht mehr auf Ebene der Formate, sondern auf

Ebene der Inhalte (vgl. ebd., S. 39). Der Beitrag zum Integrationsniveau ist offensicht-

17Unter Umst¨

anden sind dazu Konvertierungen der Zeichens¨

atze (EBCDIC, ASCII, Unicode, etc.) und

des Datenbankschemas notwendig. Middleware-Produkte k¨

onnen diese Aufgabe durch die Kapselung

einer Reihe von standardisierten Funktionen jedoch unterst¨

utzen und so einen plattform- und tech-

nologie¨

ubergreifenden Zugriff zu erlauben. Neben nativen (anbieterspezifischen) Datenbankschnitt-

stellen sind hier insbesondere sog. Call-Level Schnittstellen (Call-Level Interfaces, CLI) wie ODBC

und JDBC zu nennen.

129

4. Eine Rahmenarchitektur f¨

ur universit¨

ares E-Learning

lich: ”Komponenten, die miteinander kommunizieren oder kooperieren wollen, k¨

onnen

dies mit geringerem Aufwand und zugleich auf einem h¨

oheren Sicherheitsniveau tun,

wenn sie dazu in eindeutiger Weise auf Konstrukte verweisen k¨

onnen, deren Bedeutung

systemweit bekannt ist“ [Fra94], S. 32.

Der Aufbau eines solchen integrierten semantischen Modells kann entweder sche-

mabasiert erfolgen, bspw. auf Grundlage von Fach-Referenzmodellen, Branchen- oder

dom¨

anenspezifischen Datenmodellen oder terminologiebasiert auf der Basis einer rekon-

struierten Fachsprache eines Anwendungsgebietes (Domain-Specific Language).

4.1.5.1. Datenschema-basierte Integration

Die weite Verbreitung relationaler Datenbanksysteme nach der ANSI-SPARC-Architek-

tur18 hat dazu gef¨

uhrt, dass verteilte Systeme in den meisten F¨

allen ¨

uber ein dom¨

nenweites, anwendungs¨

ubergreifendes Datenschema zusammengef¨

uhrt werden. Ein sol-

ches Schema legt bei relationalen Datenbanken die Tabellen und ihre Attribute sowie

Existenz- und Eindeutigkeitsbeziehungen fest.

Mit zunehmender Spezialisierung und funktionalen Erweiterungen der Anwendungen

in der Dom¨

ane steigt jedoch der Aufwand f¨

ur die Administration und Konsistenthal-

tung, da das konzeptuelle Schema zwar ”ein gigantisches Entwicklungsergebnis auf der

Anwendungsseite der Systeme darstellt“, aber nicht zum Entwicklungssystem respektive

Entwicklungssprache an sich gez¨

ahlt werden kann (vgl. [Ort00], S. 3). Es herrscht dann

meist eine mehr oder weniger stark ausgepr¨

agte Trennung von Daten- und Objektschicht

vor19. Die Datenschicht stellt Funktionen zur Kontrolle und zur persistenten Speicherung

der im System vorhandenen Informationen zur Verf¨

ugung. Die Objektschicht erm¨

oglicht

das Kontrollieren und Modifizieren der in der Persistenzschicht vorhandenen Daten.

Durch diese Differenzierung von Datenbank- und Anwendungsentwicklung sind das

Design und die Pflege des zu entwickelnden (komplexen) Systems nur erschwert m¨

oglich

oder mit hohen Kosten verbunden: Die Konsistenz des konzeptionellen Datenschemas

muss zu jeder Zeit ¨

uber alle Komponenten und Anwendungen hinweg aufrecht erhalten

werden (vgl. [Oes04], [Ort00]).

Schienmann z¨

ahlt in [Sch97a] weitere Defizite der Schema-basierten Integration auf,

wie bspw. eine unzureichende Unterst¨

utzung der Modellierung globaler Systemdynami-

ken und objekt¨

ubergreifender Funktionalit¨

at sowie die beschr¨

ankten M¨

oglichkeiten der

Wiederverwendung fr¨

uherer Entwicklungsergebnisse.

4.1.5.2. Terminologiebasierte Entwicklung mit Objektframeworks

Die terminologiebasierte Integration von Systemen basiert zwar ebenfalls auf Daten-

bank- und Komponententechnologien, denn auch Termini sind – modellierungstechnisch

18Die Architektur wurde 1975 vom Standards Planning and Requirements Committee (SPARC) des

American National Standards Institute (ANSI) beschrieben und garantiert durch eine Trennung

verschiedener Beschreibungsebenen von Datenbankschemata (externe, konzeptuelle, und interne/

physische Ebene) eine physische und logische Datenunabh¨

angigkeit.

19Objektrelationales Mapping (O/R-M oder ORM) erlaubt zwar zum Zeitpunkt der Entwicklung eine

objektorientierte Sicht auf ein relationales Datenbankschema. Der Aufwand f¨

ur den Aufbau, die

Administration und Weiterentwicklung des Datenschematas wird dadurch aber nicht gemindert.

130

4.1. Komponentenarchitekturen

gesehen – als ”Schemata“ (sprachliche Repr¨

asentation von Typen) aufzufassen. Anders

als ein konzeptionelles Datenschema z¨

ahlt eine Terminologie jedoch zum Entwicklungs-

system und unterliegt dar¨

uber hinaus auch keinen strukturellen Beschr¨

ankungen durch

eine Tabellen-orientierte Sichtweise (vgl. [Ort00]). Als Entwicklungssprache kann eine

Terminologie mit geringerem Aufwand beispielsweise in Form eines Objektmodells orga-

nisiert und separat vom Anwendungsbetrieb – also verwendungsneutraler – administriert

werden. Eine Abbildung des Gegenstandsbereiches der zu entwickelnden Anwendungen

erfolgt dann durch die Rekonstruktion neuer Elemente mittels existierender Termini

(siehe Unterkapitel 3.1).

Eine terminologiebasierte Komponentenentwicklung kann softwaretechnisch durch ein

objektorientiertes Framework unterst¨

utzt werden, welches Wissen und Expertise in ei-

nem bestimmten Problembereich kapselt (domain framework, vgl. [Mat96], S. 57). Dieses

Konzept wird seit den sp¨

aten 80er Jahren eingesetzt, um ein dom¨

anenspezifisches ob-

jektorientiertes Design wieder zu verwenden und gleichzeitig Aspekte der Datenhaltung

von der Anwendungsentwicklung zu separieren. Das Framework bietet daf¨

ur in der Regel

ein dom¨

anenspezifisches Objektmodell generischer Klassen, auf das ¨

uber Programmier-

schnittstellen zugegriffen und anwendungsspezifisch erweitert werden kann.

Die theoretischen Vorteile gegen¨

uber der Datenschema-basierten Integration haben

sich in der Praxis l¨

angst best¨

atigt: ”In addition to the intuitive appeal of the framework

concept and its simplicity from an abstract perspective, experience has shown that fra-

mework projects can indeed result in increased reusability and decreased development

effort“ [Bos00], S. 241, vgl. hierzu auch [MN96].

In Kapitel 3 wurde das dom¨

anenspezifische Objektmodell der Wissensraummetapher

bereits vorgestellt. Es wurde beschrieben, wie man mit diesem semantischen Bezugs-

system Lern- und Arbeitsszenarien modellieren kann, ohne an ein festes Datenschema

gebunden zu sein. Die technische Umsetzung mithilfe von Objektframeworks wurde in

Abschnitt 3.2.3 ebenfalls aufgezeigt. Im Folgenden soll die spezielle Systemklasse dieser

Frameworks f¨

ur kooperatives Lernen und Arbeiten n¨

aher beschrieben werden, um damit

die Grundlage f¨

ur das Verst¨

andnis der Dienste der zu konzipierenden Rahmenarchitek-

tur zu legen. Um dabei von bestimmten Technologien und Produkten zu abstrahieren,

sollen prim¨

ar die Variationspunkte der Frameworks skizziert werden.

4.1.5.3. Objektframeworks f¨

ur CSCW/L-Systeme

Dom¨

anenspezifische Objektframeworks, die zur terminologiebasierten Entwicklung vir-

tueller Umgebungen f¨

ur kooperatives Lernen und Arbeiten herangezogen werden k¨

onnen,

erfordern eine integrierte Kommunikation und eine sehr grundlegende Contentverwal-

tung. So genannte Groupware-Frameworks erf¨

ullen diese Anforderungen. Auf Basis ei-

nes zumeist generischen Objektmodells unterst¨

utzen sie eine Bandbreite von Inhalts-,

Gruppen- und Prozessstrukturen ¨

uber offene Schnittstellen, mit denen verteilte koope-

rative Anwendungen erstellt werden k¨

onnen (vgl. [RG93]). Um eine klare Trennung

(one-way-dependency, S. 124) zwischen dem Dom¨

anenmodell und dem Speichermodell zu

131

4. Eine Rahmenarchitektur f¨

ur universit¨

ares E-Learning

Verteilung

ZugriﬀInfrastruktur

Synchroni-

sation

Neben-

läufigkeit

Client-Server Peer-to-Peer

Nachrichten

gemeinsame

Objekte

zentralisiert

asymetrisch

semi-repliziert

repliziert

Konflikt-

vermeidung

Konflikte entdecken

und auflösen Transaktionen

Nachrichten-

verarbeitung

Zugriﬀ über

Dienste

TCP

UDP

HTTP

Abbildung 4.7.: Variationspunkte von Groupware-Frameworks nach [GTA05].

erreichen, werden in Groupware-Frameworks Repositories eingesetzt, die eine Anfrage-

orientierte Schnittstelle implementieren. Somit k¨

onnen Objekte ¨

uber das Repository

dom¨

anenspezifisch angefragt werden, die dazu notwendigen Datenbankzugriffe gesche-

hen durch das Repository gekapselt im Hintergrund20.

Guicking et al. haben in [GTA05] die Variationspunkte synchroner Groupware-Frame-

works analysiert und f¨

unf essentielle Aspekte identifiziert, in denen sich einzelne Frame-

works in puncto Softwarearchitektur und Funktion voneinander unterscheiden k¨

onnen

(vgl. auch Abb. 4.7):

Infrastruktur Die Anbindung an eine technische Infrastruktur erfordert bestimmte grund-

legende Schnittstellen zu Transport- und Kommunikationsprotokollen. Darauf k¨

on-

nen anwendungsnahe Protokolle aufsetzen, wie bspw. SOAP oder propriet¨

are Pro-

tokolle wie COAL21.

Verteilung Die Verteilung der Architektur kann entweder nach dem Client-Server- oder

nach dem Peer-to-Peer-Prinzip erfolgen. Jedes Prinzip hat seine Vor- und Nachtei-

le. W¨

ahrend das Client-Server-Prinzip deutlich weniger komplex ist und Aspekte

wie Konsistenz und die Behandlung von Latecomers22 vereinfacht, vermeidet Peer-

to-Peer den Server als Single-Point-of-Failure und ”Flaschenhals“. Dar¨

uber hinaus

bietet sich das Client-Server-Prinzip an, wenn eine Integration in eine heteroge-

ne Anwendungslandschaft gefordert ist oder mit verschiedenen Benutzungsober-

20Obwohl zu diesem Zweck objektorientierte Datenbanksysteme genutzt werden k¨

onnen, basieren viele

Groupware-Frameworks h¨

aufig noch auf relationalen Datenbankmanagementsystemen.

21Das Groupware-Framework sTeam nutzt das COAL-Protokoll (Client Object Access Layer, vgl.

[Ham02], S. 192) zur Kommunikation zwischen Server und clientseitigen Bibliotheken. Im Gegensatz

zu standardisierten XML-basierten Protokollen wie SOAP weist das propriet¨

are COAL deutliche

Geschwindigkeitsvorteile auf.

22Benutzer, die erst sp¨

ater zu einer Sitzung hinzustoßen, m¨

ussen den aktuellen gemeinsamen Bearbei-

tungsstand nachvollziehen k¨

onnen (”What has happened here?“).

132

4.1. Komponentenarchitekturen

fl¨

achen auf die Anwendungen zugegriffen werden soll (mobile Endger¨

ate, Portale,

etc.). Denkbar ist auch ein hybrides Konzept, bei denen ein Server einen Teil der

Kommunikation zwischen den Clienten steuert, ein anderer Teil wie Audio- oder

Videochat ¨

uber eine Peer-to-Peer-Verteilung abgewickelt wird.

Zugriff Das kooperative Arbeiten und Lernen richtet sich an Inhalten und Struktu-

ren aus, die dem gemeinsamen Zugriff unterliegen. Neben der Behandlung daraus

m¨

oglicherweise resultierender Inkonsistenzen und Konflikte (s. u.) muss auch jeder

Teilnehmer einer kooperativen Sitzung den gemeinsamen Arbeitsstand im Zugriff

haben. Typische Verteilungsstrategien f¨

ur gemeinsame Objekte sind zentriert oder

repliziert (vgl. ebd.). Die Anwendungsm¨

oglichkeiten sind dabei durch die Vertei-

lung der Architektur gepr¨

agt. Eine replizierte Strategie setzt eine Anzahl koope-

rativer Instanzen einer Applikation voraus, die ¨

uber das Netz eigenverantwortlich

uber einen gemeinsamen Datenbus kommunizieren. Eine zentrale Verteilung ist da-

gegen durch einen zentralen Prozess gepr¨

agt, der die Kommunikation zwischen den

Instanzen steuert. Daneben k¨

onnen moderne Rich-Client-Architekturen durchaus

auch hybride Verteilungsstrategien implementieren und einen Teil der Kommuni-

kation mit anderen Clients eigenverantwortlich steuern. Damit die Realisierung der

Objektverteilung nicht zum Bestandteil der Anwendungsentwicklung wird, muss

das Framework hierzu eine entsprechende Abstraktion bieten.

Synchronisierung Bei der Herstellung des gemeinsamen Arbeitszustands durch den Ab-

gleich gemeinsamer Objekte k¨

onnen Konflikte auftreten, die entweder vermieden

oder aber entdeckt und aufgel¨

ost werden m¨

ussen. In diesem Zusammenhang sichern

Transaktionen die Bewahrung eines konsistenten Zustands im Konfliktfall. Danach

wird der Zustand nur aktualisiert, wenn keine Konflikte bei der Synchronisation

aufgetreten sind.

Nebenl¨

aufigkeit Abh¨

angig von der Objektverteilung muss das Framework sowohl gleich-

zeitige Nachrichten¨

ubermittlung als auch die nebenl¨

aufige Ausf¨

uhrung von Diens-

ten potenziell unterst¨

utzen. Dazu m¨

ussen sowohl die Zugriffe auf Ressourcen der

Infrastruktur koordiniert werden als auch das Zusammenspiel verteilter Kompo-

nenten, ohne nicht-funktionale Aspekte wie Performance, Robustheit und Skalier-

barkeit negativ zu beeintr¨

achtigen.

Dar¨

uber hinaus unterscheiden sich die auf dem kommerziellen und freien Markt vor-

handenen Produkte zum Teil deutlich im Funktionsumfang. Die meisten Groupware-

Frameworks werden mit einer Webschnittstelle ausgeliefert, die bereits verschiedene Ko-

operationsdienste wie Gruppen- und Dokumentenmanagement, Chat und Wikis imple-

mentieren. Zu manchen Frameworks existiert bereits eine abgestimmte Produktlinie23.

23Die Hyperwave AG bietet bspw. auf Basis des Hyperwave Information Servers IS/6 eine ganzheitliche

Infrastruktur zum Collaboration Information Management (CIM) an, bestehend aus Produkten zum

Wissensmanagement, Teamr¨

aumen, E-Learning, E-Conferencing und zum Records Management. Die

Lotus-Produktlinie von IBM unterst¨

utzt sogar noch weitere Anwendungsfelder.

133

4. Eine Rahmenarchitektur f¨

ur universit¨

ares E-Learning

In der Literatur finden sich ausf¨

uhrliche Analysen und Gegen¨

uberstellungen von Group-

ware-Frameworks (bspw. [Ham02], S. 176ff., [GTA05], S. 51ff.). An dieser Stelle sollen

daher mit der Tabelle 4.2 nur die bestehenden Aufstellungen um aktuelle Produkte

erg¨

anzt werden. Eine Gegen¨

uberstellung der Produkte ist nicht Bestandteil dieser Ar-

beit, kann jedoch prinzipiell ¨

uber die in diesem Abschnitt gelisteten Variationspunkte

vorgenommen und – als Entscheidungsgrundlage f¨

ur eine Softwareauswahl – konkreten

Anforderungen gegen¨

uber gestellt werden.

Produkt Hersteller Weblink

Alfresco Enterprise CMS Alfresco Soft-

ware, Inc.

http://www.alfresco.com/

Citadel Groupware Server Uncensored

Communicati-

ons Group

http/www.citadel.org/

Clearspace Jive Sofware http://www.jivesoftware.

com/

Confluence Atlassian http://www.atlassian.com/

software/confluence/

DyCE go4teams

GmbH

http://www.go4teams.com/

Hyperwave IS Hyperwave AG http://www.hyperwave.com/

d/products/is6/

Lotus IBM http://www.ibm.com/

software/de/lotus/

Open sTeam Heinz Nixdorf

Institut

http://www.open-steam.

org/

Open-Xchange Open X-

Change GmbH

http://www.open-xchange.

com/

Scalix Xandros Cor-

poration

http://de.scalix.com/

SharePoint Services Microsoft http://office.

microsoft.com/de-ch/

sharepointtechnology/

teamXchange VIPcom GmbH http://www.vipcomag.de/

teamxchange/

Tabelle 4.2.: Beispiele aktueller Groupware-Frameworks (ohne Anspruch auf

Vollst¨

andigkeit).

134

4.2. Eine Rahmenarchitektur f¨

ur verteilte Lern- und Arbeitsumgebungen

4.2. Eine Rahmenarchitektur f¨

ur verteilte Lern- und

Arbeitsumgebungen

Nachdem in den vorangegangenen Unterkapiteln die notwendigen Grundlagen gelegt und

entsprechende Architekturprinzipien aufgezeigt wurden, kann im Folgenden die eigent-

liche Konzeption einer Produktlinien-orientierten Rahmenarchitektur f¨

ur universit¨

ares

E-Learning durchgef¨

uhrt werden.

Dabei wird die Idee der in Abschnitt 2.2.4.3 vorgestellten komponentenorientierten E-

Learning-Architekturen weiter konkretisiert. Die zwei wichtigsten Spezialisierungen ge-

gen¨

uber abstrakten Rahmenarchitekturen wie IEEE LTSA, ELF oder IAF (s. Abschnitt

2.2.4.3) sind (1) die Nutzung eines technischen CSCW/L-Rahmenwerks zur Abdeckung

der Basisdienste und (2) eine Zweiteilung der Rahmenarchitektur in Produktstandard-

und darauf aufbauender Produktarchitektur.

Diese Konkretisierungen werden in diesem Unterkapitel herausgearbeitet und um

Aspekte des universit¨

aren Anwendungskontextes verfeinert. Somit wird eine Rahmenar-

chitektur geschaffen, die konkret auf den universit¨

aren Einsatz ausgerichtet ist.

4.2.1. Schichtenmodell

Grundlegend f¨

ur die Einordnung von Standardprodukt- und Produktarchitektur ist eine

logische Systemarchitektur, die in diesem Abschnitt anhand eines Schichtmodells kon-

struiert werden soll. Dabei wird nach dem OSI-Modell zwischen Diensten,Schnittstellen

und Protokollen unterschieden: Die Gesamtheit der Dienste definiert den Funktionsum-

fang einer Schicht, eine Schnittstelle, wie auf einen Dienst zugegriffen werden kann und

ein Protokoll definiert das Format und die Bedeutung der zu ¨

ubertragenen Informatio-

nen.

Nach [Kar95], S. 12ff., k¨

onnen Dienste nach ihrer Wiederverwendbarkeit in die drei

Klassen ”Allgemeine Dienste“, ”Dom¨

anen-spezifische Dienste“ und ”Produktlinien-spe-

zifische Dienste“ eingeordnet werden. In dieser Arbeit werden Allgemeine Dienste als Teil

der Infrastruktur aufgefasst (Basistechnologien und Registrierungsdienste, vgl. Abb. 4.9).

Eine verteilte Komponentenarchitektur f¨

ur universit¨

ares E-Learning l¨

asst sich dem-

nach durch vier Schichten repr¨

asentieren: Infrastrukturschicht, spezifische Dienste der

Dom¨

ane ”Kooperatives Lernen und Arbeiten“ (Kooperationsdienste) sowie Produktlinien-

spezifische Dienste hinsichtlich des universit¨

aren E-Learnings (E-Learning-spezifische

Dienste). Obenauf liegt die Anwendungsschicht, die auf den Diensten basierende Be-

nutzungsschnittstellen f¨

ur bestimmte Anwendungszwecke des universit¨

aren E-Learnings

umfasst. Die untersten drei Schichten stellen Dienste zur Verf¨

ugung, die sowohl inner-

halb einer Schicht als auch von den dar¨

uber liegenden Schichten genutzt werden k¨

onnen.

Die Dienste sollten dabei den Entwurfsprinzipien komponentenorientierter Architektu-

ren entsprechen, insbesondere sollten die Dienste einer Schicht einfach gerichtete Abh¨

an-

gigkeiten zueinander aufweisen und Standardprotokolle nutzen (vgl. Abschnitt 4.1.3).

Abbildung 4.8 stellt diesen Zusammenhang als UML-Komponentendiagramm dar.

135

4. Eine Rahmenarchitektur f¨

ur universit¨

ares E-Learning

Anwendungs-

schicht

E-Learning-

spezifische

Dienste

Kooperations-

dienste

Infrastruktur

Benutzer

Rahmen-

architektur

Abbildung 4.8.: Abh¨

angigkeiten zwischen verschiedenen Dienst-Klassifizierungen

4.2.1.1. Infrastruktur

Die Netzwerk- und Transportschicht bildet die Basis jeder verteilten Komponentenar-

chitektur. Durch die Nutzung von Netzwerkprotokollen werden Transaktions- und Kom-

munikationsdienste f¨

ur Dienste aller Schichten zur Verf¨

ugung gestellt. Die Kommuni-

kation zwischen zwei Komponenten kann dabei in vielf¨

altiger Art und Weise erfolgen,

bspw. direkt ¨

uber infrastrukturgebundene Transportprotokolle oder ¨

uber darauf aufbau-

ende XML-basierte Nachrichteninfrastrukturen, die einen umfangreichen Transport- und

Kommunikationsservice anbieten24.

Neben den Transportprotokollen sind in dieser Schicht auch komplexere Basistechnolo-

gien wie die Dienste eines Zertifikatsservers, Verzeichnisdienstes oder eines Mail-Servers

zu verorten. Auch protokollnahe synchrone Kommunikationsdienste wie Instant Mes-

saging, Audio- und Videochat k¨

onnen zu den komplexen Diensten einer Infrastruktur

gez¨

ahlt werden.

Ein wichtiger Aspekt einer komponentenorientierten Architektur ist die M¨

oglichkeit zur

losen Kopplung von Komponenten. In der konkreten Umsetzung auf verschiedenen Ebe-

nen der Architektur h¨

angt die Modularisierung stark von der verwendeten Technologie

ab. In den meisten F¨

allen sieht das Konzept jedoch vor, eine Komponente gegen einen

symbolischen Namen aufzul¨

osen. Weit verbreitet ist das Entwurfsmuster Dependency

Injection, bei dem die Aufl¨

osung dieser Abh¨

angigkeiten von Frameworks ¨

ubernommen

und zur Laufzeit in ein aufrufendes Objekt hineininjiziert werden. Hierzu werden in der

Infrastruktur Registrierungsdienste ben¨

otigt, die Komponenten mitsamt ihren symboli-

schen Namen verzeichnen und aufl¨

osen k¨

onnen25.

24SOAP-Frameworks bspw. bieten die Verpackung in XML-Umschl¨

age (envelope) an, einen verl¨

asslichen

Datentransport, Publish- und Subscribe-Mechanismen, Nutzung von ”HTTP-GET“- und ”HTTP-

POST“-Mechanismen etc.

25Abh¨

angig vom Softwaredesign und den eingesetzten Technologien k¨

onnen dies innerhalb der glei-

chen Softwarearchitektur durchaus unterschiedliche Mechanismen sein. Registrierungsdienste einer

m¨

oglichen javabasierten Webarchitektur sind bspw. das Java Naming and Directory Interface (JN-

136

4.2. Eine Rahmenarchitektur f¨

ur verteilte Lern- und Arbeitsumgebungen

Infrastruktur

Netzwerk- und

Transportschicht

physikalische

Schicht

Netzwerk-

protokolle

Transport-

protokolle

Basis-

technologien

Audiochat Videochat

Verzeichnis-

dienst

Zertifikats-

dienst

Maildienst

Instant

Messaging

Laufzeitumgebung

Betriebs-

system

Sprachen-spez.

Runtime

Application-

server

Application-

framework

Middleware

Registrierungs-

dienste

Sprachenspez.

Registrierung

Frameworkspez.

Registrierung

Anwendungsspez.

Registrierung

...

Abbildung 4.9.: Infrastruktur und Basisdienste

Die ausf¨

uhrende Komponente der Infrastruktur ist die Laufzeitumgebung, die den An-

wendungskomponenten grunds¨

atzliche Funktionen wie Schreiben und Lesen von Da-

teien, Steuerung von Ein- und Ausgabeger¨

aten, Garbage Collector und ¨

Ahnliches zur

Verf¨

ugung stellt. Sie kann – je nach eingesetzter Technologie – den Architekturstack

entlang spezifiziert werden. Neben der Laufzeitumgebung der eingesetzten Sprache26

k¨

onnen so auch Application Server und Programmierframeworks die Laufzeitumgebung

mit definieren.

4.2.1.2. Kooperationsdienste

Spezifische Dienste der Dom¨

ane des kooperativen Arbeitens und Lernens sind n¨

otig, um

den gemeinschaftlichen Zugriff auf Wissensobjekte unterst¨

utzen zu k¨

onnen. Beispiels-

weise Dienste zum entfernten Zugriff auf Objekte, zur Unterst¨

utzung von Zugriffs- und

Versionskontrolle, Dienste zur Notifikation und Unterst¨

utzung der Awareness. Insbe-

sondere geh¨

oren Dienste zur Bereitstellung und Verwaltung virtueller Wissensr¨

aume zu

dieser Klasse. Groupware-Frameworks wie die in Abschnitt 3.2.3 vorgestellten Systeme

implementieren diese Dienste.

DI) als Teil des Java Enterprise Standards, die Service Registry der Open Services Gateway Initiative

(OSGi) zur Nutzung in Application Frameworks wie Spring, oder anwendungsbezogene Modulari-

sierungskonzepte wie die Public Service API des Enterprise CMS Alfresco.

26Gemeint ist hier bspw. das Java Runtime Environment (JRE), bestehend aus den Java Klassenbi-

bliotheken und der Java Virtual Machine (JVM), ein PHP-Interpreter als Webserver-Modul oder

f¨

ur die Konsole oder Microsofts Common Language Runtime (CLR) f¨

ur C#, Visual Basic.NET und

C++.NET.

137

4. Eine Rahmenarchitektur f¨

ur universit¨

ares E-Learning

Kooperative Dienste k¨

onnen in unterschiedlichsten Anwendungsfeldern des kooperati-

ven Arbeitens und Lernens verwendet werden, bspw. zur Unterst¨

utzung des Wissensma-

nagements in F&E-Projekten, virtuellen Communities of Practice oder eben auch des

universit¨

aren E-Learnings (vgl. hierzu [PRH06], [HRKK05] und [RS05]).

Komponenten, die dom¨

anenspezifische Dienste des kooperativen Arbeitens und Ler-

nens implementieren, k¨

onnen den Kategorien Objektmanagement,Benutzermanagement,

Kommunikation und unterst¨

utzende Dienste zugeordnet werden.

Objektmanagement Das kooperative Arbeiten und Lernen auf Basis gemeinsam ge-

nutzter Artefakte impliziert architektonisch die persistente Verwaltung von Objekten.

Dieses Objektmanagement umfasst Dienste zur Sicherung eines konsistenten Datenzu-

stands sowohl in der Persistenzschicht als auch zur Laufzeit (Persistenzmanager,Ob-

jektmanager), die Sicherung der Konsistenz auch bei nebenl¨

aufigem Zugriff (Locking,

Versionskontrolle), sowie die Zugriffskontrolle und ein internes Benachrichtigungssys-

tem, das Zustands¨

anderungen an Objekten registriert und bei entsprechender Konfigu-

ration andere Dienste dar¨

uber in Kenntnis setzen kann. Letzteres ist insbesondere f¨

das synchrone Arbeiten essentiell, um Benutzer ¨

uber Aktivit¨

aten anderer Benutzer zu

informieren (vgl. [HPD05]). Dienste zur Archivierung und Paketierung unterst¨

utzen die

Langzeitaufbewahrung sowie den Export zur ¨

Ubertragung der Daten in externe Systeme.

Benutzermanagement Das Benutzermanagement deckt die Verwaltung von Benutzern

und hierarchischen Benutzergruppenstrukturen ab. Ein Rollenmanager kann dabei die

explizite Zuweisung von Funktionsrechten zu Benutzern vornehmen und so verschiedene

Akteure definieren, die mit dem System interagieren k¨

onnen. Dar¨

uber hinaus wird ei-

ne Komponente zur Authentifizierung ben¨

otigt, die Anmeldedaten verifiziert27 und bei

Erfolg eine Sitzung28 initiiert. Um die Verwaltung von Sitzungen zur Laufzeit k¨

ummert

sich ein Session-Manager, der mit einer Awareness-Komponente interagiert, durch die

angemeldete Benutzer im System f¨

ur andere sichtbar sind.

Kommunikation Um einen vielf¨

altigen Austausch von Informationen zu unterst¨

utzen,

werden Komponenten gebraucht, die Kommunikationswerkzeuge implementieren. Neben

den zur Infrastruktur z¨

ahlenden synchronen Kommunikationsdiensten sind Foren,Wikis

und Weblogs in kooperativen Lern- und Arbeitsumgebungen weit verbreitet. Insbeson-

dere zum Informationsaustausch ¨

uber vorhandene Wissensobjekte eignen sich Kommen-

tarfunktionen und Shared Whiteboards, da sie – im Gegensatz zu den bisher aufgef¨

uhrten

Werkzeugen – die Objekte in den Mittelpunkt der Kommunikation stellen.

Unterst¨

utzende Dienste Unterst¨

utzende Dienste decken grundlegende Funktionen ab,

die Instanzen von Komponenten zur Laufzeit ben¨

otigen, um untereinander und mit

der Infrastruktur zu kommunizieren. Beispiele sind das Modulmanagement,¨

uber das

neue Komponenten registriert werden k¨

onnen, Logging und Fehlerbehandlung und die

27In vielen Systemen umfasst diese Komponente auch M¨

oglichkeiten zur Interaktion mit verschiedenen

Basisdiensten zur Authentifizierung, wie Verzeichnisdienste oder Ticketsysteme.

28Eine Sitzung ist eine zeitweise bestehende Verbindung zwischen Client und Server.

138

4.2. Eine Rahmenarchitektur f¨

ur verteilte Lern- und Arbeitsumgebungen

Kooperationsdienste

Objektmanagement

Objekt-

Manager Event-Manager Persistenz-

Manager

Versions-

kontrolle

Zugriﬀs-

kontrolle

Benutzermanagement

Aktoren-Manager Rollen-

Manager

Authentifi-

zierung Session-Manager

Interne Komponenten

Network-

Manager

Modul-

Manager

Locking

Logging

Format-

konvertierung

Ausnahme-

behandlung ...

Archivierung

Paketierung

Kommunikation

Forum Wiki Annotationen

Weblog Shared

Whiteboard ...

Awareness

Abbildung 4.10.: Kooperationsdienste

Implementierung von Komponentenschnittstellen zu Diensten der Infrastrukturschicht

(so genannte Protokolladapter, vgl. [SHB04]), bspw. zu Netzwerkprotokollen der An-

wendungsschicht wie Jabber oder WebDAV. Eine weitere wichtige Komponente sollte

Dienste zur Formatkonvertierung zwischen verschiedenen Inhaltstypen implementieren.

4.2.1.3. E-Learning-spezifische Dienste

Die dieser Schicht zugeordneten Dienste finden aufgrund ihrer Spezialisierung auf uni-

versit¨

ares E-Learning nur innerhalb einer Produktlinie Wiederverwendung. Eine ¨

Uber-

tragung auf thematisch verwandte Szenarien wie bspw. Wissensmanagement in F&E-

Projekten ist i. d. R. nicht m¨

oglich.

Dienste dieser Schicht sind zum Beispiel ein auf Modulstrukturen beruhendes Kurs-

management, die Sequenzierung von Lerninhalten nach IMS Standards, Dienste zur Dis-

kursstrukturierung oder ein den allgemeinen und bereichsspezifischen Regelungen zum

Datenschutz gen¨

ugendes Pr¨

ufungsmanagement.

Komponenten, die E-Learning-spezifische Dienste implementieren, k¨

onnen den Kate-

gorien Organisation,Campus Management,Lernszenarien und Community zugeordnet

werden.

Campus Management Grundlegend f¨

ur die Unterst¨

utzung universit¨

aren E-Learnings

ist eine geeignete Abbildung der Modul- und Pr¨

ufungsorganisation. Hierzu ist eine hie-

rarchische Struktur von Modulen, Semestern, Moduldurchl¨

aufen und Unterveranstal-

tungen wie ¨

Ubungsgruppen, Tutorien, Parallelveranstaltungen etc. durch ein Veran-

staltungsmanagement zu unterst¨

utzen. Sehr eng mit dem Veranstaltungsmanagement

verbunden ist das Pr¨

ufungsmanagement, welches auf Basis der existierender Pr¨

ufungs-

ordnungen konfigurierbare Anmelde- und Belegverfahren f¨

ur Veranstaltungen imple-

139

4. Eine Rahmenarchitektur f¨

ur universit¨

ares E-Learning

mentiert und die Fortschrittskontrolle von Studierenden innerhalb ihrer belegten Stu-

dieng¨

ange unterst¨

utzt. An allen ¨

offentlichen Universit¨

aten werden diese Dienste bereits

durch ein eigenst¨

andiges Campus Management System ¨

ubernommen und k¨

onnen so-

mit ¨

uber Schnittstellen in die Komponentenarchitektur mit aufgenommen werden (vgl.

hierzu Schnittstellen zum Campus Management, S. 152ff.).

Lernmanagement Komponenten dieser Kategorie zielen auf die Planung, Durchf¨

uh-

rung und Kontrolle von Lernprozessen ab. Dazu sind Dienste notwendig, welche die

Entwicklung von Lernenden unter Ber¨

ucksichtigung des Lernertyps anhand der Syste-

maktivit¨

at (Tracking) oder gezielten ¨

Uberpr¨

ufungen (Assessment) registriert. Ein E-

Portfolio unterst¨

utzt den Lernenden bei der Reflexion seiner Lernprozesse mithilfe eines

persistenten Speichers f¨

ur Artefakte, die im Verlauf seines Studiums erstellt werden. Be-

standteile einer solchen ”Sammelmappe“ sind Sammlungen von Arbeitsergebnissen und

Anmerkungen (bspw. von Tutoren oder Lehrenden), Feedback-M¨

oglichkeiten, aber auch

eigene Notizen zur pers¨

onlichen Selbstreflexion.

Lernszenarien Soll das Arbeiten und Lernen in virtuellen R¨

aumen einer bestimmten

Instruktion erfolgen, welche die Handlungsm¨

oglichkeiten durch die Bindung an bestimm-

te Rollen, Reihenfolgen oder Medientypen einschr¨

ankt, m¨

ussen dazu entsprechende Re-

striktionen in der Softwareschicht vorgehalten werden. Die dieser Kategorie zugeordneten

Komponenten unterst¨

utzen diese Einschr¨

ankungen bspw. durch konfigurierbare Diskurs-

strukturen, eine rollenbasierte Ressourcenverwaltung oder die Sequenzierung von Lektio-

nen und Inhalten. Dar¨

uber hinaus wird oftmals eine Workflow-Komponente ben¨

otigt,

die – basierend auf Zugriffsrechten und Bearbeitungsst¨

anden von Artefakten – Bearbei-

tungszyklen und Freigaben steuert.

Community ¨

Uber die Gruppenverwaltung der kooperativen Dienste hinausgehend wer-

den zur Unterst¨

utzung von sozialen Netzwerken weitere Funktionen ben¨

otigt. Die Ver-

waltung best¨

atigter und unbest¨

atigter Kontakte wird durch eine Kontaktmanagement-

Komponente ¨

ubernommen. Durch diese Komponente k¨

onnen auch k¨

urzeste Wege zu

Benutzern ermittelt werden, zu denen kein direkter sozialer Kontakt besteht. Auf Basis

des Kontaktmanagements k¨

onnen Benutzer individuelle Freigaben auf Daten des eigenen

Profils einrichten (Profildatenmanagement).

4.2.1.4. Anwendungen

Die Anwendungen implementieren eine Benutzungsschnittstelle, durch die der Endbe-

nutzer ¨

uber eine Menge von Diensten mit bestimmten Artefakten interagieren kann.

Einige typische E-Learning-Anwendungen wurden bereits in Tabelle 2.2 in dieser Arbeit

vorgestellt. Eine abstraktes Klassifikationsschema kooperationsunterst¨

utzender Systeme

anhand der Struktur des unterst¨

utzten Szenarien liefert Haake in [Haa99]. Danach bil-

den die drei Dimensionen Prozess-, Gruppen- und Inhaltsstruktur einen Strukturraum,

in dem Anwendungen entsprechend ihrer Auspr¨

agungen angeordnet werden k¨

onnen. Der

Grad an m¨

oglicher Selbstorganisation stellt in jeder Dimension die ordinale Skala von

selbststrukturiert, ¨

uber semi-strukturiert bis hin zu vollst¨

andig vorstrukturiert.

140

4.2. Eine Rahmenarchitektur f¨

ur verteilte Lern- und Arbeitsumgebungen

E-Learning-spezifische Dienste

Lernszenarien

Ressourcen-

verwaltung

Lernmanagement

Tracking

Campus Management

Veranstaltuns-

management

Prüfungs-

management

Assessment

E-Portfolios ...

Diskurs-

strukturen

Sequenzierung ...

Communities

Kontakt-

management

Profildaten-

management

Abbildung 4.11.: E-Learning-spezifische Dienste

Die Prozessstruktur ist zentraler Aspekt von Workflow-Management-Anwendungen.

Workflows, die fest vorgegeben sind, finden sich einerseits h¨

aufig in der organisatorischen

Unterst¨

utzung des Lernmanagements, wie dem Einrichten von Veranstaltungen oder das

Melden von Pr¨

ufungsergebnissen an die Verwaltung, andererseits auch im Learning De-

sign oder Lernprotokollen wieder, die den Ablauf von Lerneinheiten genau spezifizieren

oder den Ablauf von Diskursstrukturen genau vorgeben (vgl. dazu [PM02] und [HH05]).

Semi-strukturierte Workflows bieten neben einem vorstrukturierten Teil auch selbstor-

ganisierte Abschnitte. Ein Beispiel hierf¨

ur ist die in [RHS06] vorgestellte Unterst¨

utzung

der Projektmethode: In einem LMS-unterst¨

utzten Planspiel einer TV-Produktion wech-

seln sich Gruppenarbeitsphasen mit instruierenden Einf¨

uhrungsphasen und moderierten

Reflexionsphasen ab (vgl. auch [Jan04b]).

Ad-hoc Workflows werden von Benutzern selbst organisiert. Ein Beispiel ist das Ler-

nen in freien Lerngruppen im koaLA-System der Universit¨

at Paderborn (vgl. Kapitel

6). Studierende k¨

onnen dazu zwischen ¨

offentlichen oder privaten Gruppen w¨

ahlen, die

Aufnahme neuer Mitglieder durch Passwortvergabe oder Bewerbungsverfahren regeln

oder auch frei erlauben, sowie Rechte und Rollen im gemeinsamen Gruppenarbeitsraum

frei vergeben.

Die Gruppenstrukturen in Lern- und Arbeitsumgebungen k¨

onnen ebenfalls stark vor-

strukturiert sein, um bspw. mit einer rollenbasierten Zuordnung von Aktivit¨

aten zu Be-

nutzern/Benutzergruppen eine feste Teamzusammensetzung vorzugeben.

Ebenso kann die Inhaltsstruktur ausschließlich nach festen Regeln erfolgen, d. h. Spei-

cherort, Dateinamen, Versionierungssystem, Zugriffs- und Referenzm¨

oglichkeiten sind

dadurch festgelegt. Im Gegensatz dazu bilden virtuelle Dateiordner oder Shared White-

boards selbstorganisierbare Handlungsr¨

aume, in dem Benutzer frei sind in der Gestaltung

ihrer Inhaltsstrukturen.

141

4. Eine Rahmenarchitektur f¨

ur universit¨

ares E-Learning

Team

Inhalt

Workflow

selbst-

organi-

siert

semi-vor-

strukturiert

stark vor-

strukturiert

Abbildung 4.12.: Spezifikationsraum f¨

ur kooperative Lern- und Arbeitskontexte (in An-

lehnung an [RH04], S. 120)

Basierend auf dem Wiederverwendungsgrad der hier beschriebenen Dienste wird im

Folgenden zun¨

achst die Produktstandardarchitektur, dann die Produktarchitektur kon-

zipiert.

4.2.2. Die Produktstandardarchitektur

Die Umsetzungsm¨

oglichkeiten von kooperativen Diensten wurden im vorigen Kapitel

3.2.3 schon angedeutet. Als Alternative zur Implementierung der Dienste mithilfe der

Basistechnologien wurden in Abschnitt 4.1.5.3 Groupware-Frameworks genannt, die zur

Entwicklung und Unterst¨

utzung von geteilten Lern- und Arbeitsplattformen herangezo-

gen werden k¨

onnen. Groupware-Frameworks stellen jeweils eine Reihe von Kooperati-

onsdiensten f¨

ur ein bestimmtes Objektmodell (Dom¨

anenmodell) zur Verf¨

ugung.

Dom¨

anenmodelle sind in der Regel generisch, und beinhalten – im Fall des kooperativen

Arbeitens und Lernens – Abstraktionen zur Abbildung von Gruppen-, Prozess- und

Inhaltsstrukturen29. Als Beispiel wurde im Kapitel 3.2.3 das in Groupware-Frameworks

verbreitete Modell der Wissensraummetapher angef¨

uhrt.

Im Folgenden soll aus softwarearchitektonischer Sicht beschrieben werden, wie auf Basis

eines solchen generischen Objektmodells wiederverwendbare Modelle konfiguriert wer-

den k¨

onnen, die Sachverhalte kooperativer Arbeits- und Lernumgebungen beschreiben.

In Abh¨

angigkeit ihres Anwendungsbezugs k¨

onnen diese Modelle entweder f¨

ur einzelne

Anwendungen oder aber – als semantisch integrative Komponente – f¨

ur mehrere An-

wendungen einer Softwareproduktlinie eingesetzt werden (vgl. S. 131).

29Damit gehen sie ¨

uber Hypermedia-Modelle hinaus, die nur die reine Inhaltsverwaltung unterst¨

utzen

(vgl. hierzu [HS90]).

142

4.2. Eine Rahmenarchitektur f¨

ur verteilte Lern- und Arbeitsumgebungen

Die in diesem Abschnitt beschriebene Kernarchitektur ist in allen Anwendungen grund-

s¨

atzlich identisch und wird daher im Folgenden auch als ”Produktstandardarchitektur“

bezeichnet. Darauf basierende anwendungsspezifische Erweiterungen werden unter der

Bezeichnung ”Produktarchitektur“ im n¨

achsten Abschnitt erl¨

autert.

4.2.2.1. Gemeinsame Modelle

Die Objekttypen des generischen Dom¨

anenmodells stellen die Komponenten zur Model-

lierung von Arbeits- und Lernkontexten im Rahmen des in Abbildung 4.12 aufgespannten

Spezifikationsraums. Die normsprachliche Spezifizierung der daf¨

ur notwendigen Sichten

wurde mit Kapitel 3.3 ausf¨

uhrlich beschrieben. Demnach k¨

onnen Kompositionsbezie-

hungen ¨

uber Container und Gruppen als Beh¨

altnisse oder Kollektionen von Objekten

und Benutzern umgesetzt werden. Eine weitere M¨

oglichkeit besteht in der Speicherung

von Objektreferenzen als Attribut eines Objektes (vgl. S. 101ff.).

Diese konstruierten Objektverb¨

unde (Composites, vgl. [GHJV96], S. 213ff.) bieten per

se spezifische Interaktionen mit ihren einzelnen Modellelementen, da durch das Reposi-

tory jede Abstraktion mit Daten- und Verhaltensbeschreibungen assoziiert ist. ¨

Uber eine

Modell-Konfiguration kann definiert werden, mit welchen Kooperationsdiensten auf die

Composites zugegriffen werden kann und welche zus¨

atzlichen Eigenschaften das ganze

Modell bzw. einzelne Modellelemente besitzen.

Zus¨

atzlichen Eigenschaften wie Versionierbarkeit, Annotierbarkeit, Kategorisierbar-

keit u. ¨

a. werden daher klassen¨

ubergreifend ben¨

otigt. Das objektorientierte Design ge-

langt hier an seine Grenzen: Entweder muss jeder Objekttyp die Funktionalit¨

at neu

implementieren oder es gibt eine ”¨

Uberklasse“, die diese Funktionen bereitstellt, wie

bspw. eine Klasse Object. Dies w¨

urde aber den objektorientierten Ansatz ad absurdum

f¨

uhren.

Moderne Groupware-Frameworks nutzen zur Behandlung von Aspekten, die eine An-

forderung quer durch alle logischen Schichten ”schneiden“ (Cross Cutting Concerns, vgl.

S. 78), das im Kontext des Registrierungsdienstes bereits vorgestellte Entwurfsmuster

Dependency Injection. Dieses Muster erlaub das ”Injizieren“ von F¨

ahigkeiten in die Ob-

jekte zur Laufzeit der Anwendung, so dass allgemeine F¨

ahigkeiten einerseits nur einmal

programmiert werden m¨

ussen, andererseits nur an den Objekten verf¨

ugbar ist, die sie

auch wirklich ben¨

otigen.

Ein Beispiel f¨

ur die Implementierung querschnittlicher Belange im Kontext eines gene-

rischen Objektmodells ist in Abbildung 4.13 zu sehen. Hier wird die F¨

ahigkeit, kommen-

tiert werden zu k¨

onnen, als Aspekt konfiguriert. Sie ist damit klasseninvariant und kann

in verschiedenen Modellen wiederverwendet werden. So wird eine M¨

oglichkeit geschaffen,

systemweit ein einheitliches Verfahren f¨

ur Kommentare zu implementieren.

Diese M¨

oglichkeit der aspektorientierten Programmierung (AOP) kann in der Konfi-

guration eines Modells zur Definition wiederkehrender Funktionalit¨

at verwendet werden.

Eine darauf basierende Konfiguration zur Beschreibung eines Weblogs findet sich im An-

hang A.4 dieser Arbeit.

143

4. Eine Rahmenarchitektur f¨

ur universit¨

ares E-Learning

-created: datetime

-creator: object

-post: string

«type»

comment

-name: string

«type»

CMObject

«aspect»

commentable

«comments»

0..*

Abbildung 4.13.: Aspektorientierte Umsetzung von Kommentaren an Objekten auf Basis

der Wissensraummetapher des Alfresco-Servers.

Die durch die Normsprache spezifizierten und durch die Konfiguration des Groupware-

Frameworks definierten Modelle beschreiben Gegenstandsbereiche einer Lern- und Ar-

beitsumgebung, die kooperativ – also gemeinsam – ¨

uber Softwareprodukte manipuliert

werden k¨

onnen. Damit ein solches Modell zur Implementierung der Anwendungslogik

verschiedener Produkte wieder verwendet werden kann, muss es in den einzelnen Pro-

duktarchitekturen lokal verf¨

ugbar gemacht werden. Pattersons Groupwarereferenzmodell

beschreibt dazu die ”Geteilte Architektur“ (vgl. [SS01], S. 298f.): Die Produktarchitektur

implementiert eine eigene Sicht auf ein gemeinsames, zentral persistiertes Modell. Somit

kapselt das gemeinsame Modell Daten ¨

uber seinen allgemeinen Zustand, die dar¨

uber

hinaus noch durch anwendungsspezifische Daten erg¨

anzt werden k¨

onnen30. Dieses Ent-

wurfsmuster ist in der Literatur auch unter der Bezeichnung shared state bekannt31.

Die Herstellung eines gemeinsamen Arbeitszustands erfolgt dabei nicht durch den Aus-

tausch von ¨

Anderungsinformationen (Synchronisation), sondern ereignisbasiert durch

die gemeinsame Nutzung von Kooperationsdiensten. Hierzu kann beispielsweise das Ob-

server-Entwurfsmuster auf gemeinsame Modelle angewendet werden (vgl. [GHJV96],

S. 257f.).

Aus softwarearchitektonischer Sicht kann durch ein Groupware-Framework die Persis-

tenz der Modelle sowie der objektorientierte Zugriff darauf ¨

uber die Kooperationsdienste

gesichert werden (vgl. Abb. 4.14). Damit diese Dienste auch in den Produktarchitekturen

verf¨

ugbar sind, bedarf es dar¨

uber hinaus entsprechender Schnittstellen.

30Beispiele f¨

ur die so genannte dynamische Attributierung finden sich in [HR05].

31Das Model-View-Controller-Paradigma wird dabei durch eine Assoziation eines verschiedenen Anwen-

dungen gemeinsames Modell durch lokale Modelle dahingehend erweitert, dass die Anwendungen auf

gemeinsamen Daten arbeiten, d. h. lokale Modelle halten eine Referenz auf das gemeinsame Modell

und sind gleichzeitig an dessen ¨

Anderungen interessiert.

144

4.2. Eine Rahmenarchitektur f¨

ur verteilte Lern- und Arbeitsumgebungen

generisches

Objektmodell

Object

Repository

KonfigurationComposite

generisches

Objekt

Kooperations-

dienst

bietet Zugriﬀ

registriert bei

lokaler

Controller

manipuliert

1..n

0..n

1..n 1

1..n

0..n

lokales Modell

lokale View

1..n

registriert für

1..n

benutzt

verweist auf

1..n

1..n1..n

Anwendungen

zentraler Server

Abbildung 4.14.: Das verteilte MVC-Muster basiert auf zentral gehaltenen, gemeinsa-

men Modellen (Composites)

4.2.2.2. Schnittstellen zu Kooperationsdiensten

Um Instanzen gemeinsamer Modelle erstellen und manipulieren zu k¨

onnen, muss f¨

ur die

Zielsprache eine Bibliothek generischer Funktionen und Modellelemente existieren. In

der technischen Ausgestaltung des Zugriffs auf Kooperationsdienste und Objekte gibt

es jedoch architektonische Unterschiede, deren Vor- und Nachteile an dieser Stelle kurz

skizziert werden sollen.

Remote Procedure Calls und Object Access Die M¨

oglichkeit des entfernten Zugriffs

(remote access) auf Funktionen und Objekte des Groupware-Frameworks ¨

uber Web-

Service-Schnittstellen ist neutral bzgl. der f¨

ur die Anwendungsentwicklung verwendeten

Programmiersprache. Die Anwendung kann – muss aber nicht – in der Laufzeitumge-

bung des Servers liegen. Der Kommunikationsaufwand zwischen Server und Client ist

dabei abh¨

angig vom verwendeten Zugriffsprotokoll. Wird bspw. ein SOAP-Framework

eingesetzt, k¨

onnen Objekte aus der Laufzeitumgebung des Servers heraus mittels eines

XML-Schemas serialisiert und als SOAP-Nachricht an den aufrufenden Client ¨

ubertragen

werden. Clientseitig werden die Daten mit Hilfe des gleichen Schemas i. d. R. wieder in

Objekte transformiert, auf die innerhalb der Laufzeitumgebung des Clients dann zuge-

griffen werden kann. Sie fungieren dort allerdings nur als Datencontainer. Das Aufrufen

von Methoden, die serverseitig an den jeweiligen Objekten verf¨

ugbar sind, ist nicht ohne

weiteres m¨

oglich. Dies verhindert auch die Nutzung von softwaretechnischen Konzepten

zur Spezialisierung und Komposition, mit denen ein Objektmodell auf der Klientenseite

145

4. Eine Rahmenarchitektur f¨

ur universit¨

ares E-Learning

erweitert werden kann. W¨

ahrend eine Erweiterung des urspr¨

unglichen Modells auf dem

Server problemlos m¨

oglich ist32, muss auf Seite des Klienten ein zus¨

atzlicher Aufwand

betrieben werden, um aus den Datencontainern funktionale Fachobjekte zu generieren.

Hierzu kann das Entwurfsmuster des Proxy-Objekts verwendet werden (vgl. [GHJV96],

S. 227ff.).

Remote Proxy-Objekte Remote Proxy-Objekte leiten stellvertretend f¨

ur ein Objekt in-

nerhalb eines entfernten Adressraums Zugriffe auf Methoden und Attribute weiter an den

Server. Sie kapseln also die Funktionen serverseitiger Objekte, und bieten get- und set-

Methoden zum Auslesen und Schreiben von Attributen an. Die Kommunikation zwischen

Proxy und Server kann dabei ¨

uber standardisierte XML-basierte Protokolle laufen (bspw.

SOAP). Von Vorteil ist bei der Verwendung von Proxy-Objekten die Verf¨

ugbarkeit des

Objektmodells in Form von Konstrukten in der zur Entwicklung genutzten Program-

miersprache. Die Funktionen sind damit direkt an den Objekten verankert und k¨

onnen

auch in einer Klassenhierarchie vererbt werden. So kann selbst die Programmierung sehr

intuitiv mithilfe der generischen Modellelemente erfolgen (vgl. [HR05]). Auch clientsei-

tige Erweiterungen des Objektmodells durch Entwurfskonzepte wie Generalisierung und

Komposition sind auf diesem Weg m¨

oglich, bleiben aus Sicht der Wiederverwendbarkeit

jedoch auf das Produkt beschr¨

ankt.

An dieser Stelle muss daher abgew¨

agt werden, ob die im Produkt zu implementierende

Funktion in anderen Produkten der Softwarelinie wieder verwendet werden kann. Kann

dies angenommen werden, ist es sinnvoller, ein gemeinsames Modell zu konfigurieren und

die modellspezifischen Funktionen als h¨

oheren Dienst der Produktstandardarchitektur

uber Schnittstellen allen Produkten zur Verf¨

ugung zu stellen (s. n¨

achster Abschnitt ”E-

Learning-spezifische Dienste“).

Klassenbibliotheken/Frameworks Braucht der Zugriff auf Kooperationsdienste

nicht entfernt zu erfolgen, da zum Beispiel die zu entwickelnde Anwendung mit in der

Laufzeitumgebung des Groupware-Frameworks ausgef¨

uhrt werden kann, gibt es noch

eine dritte M¨

oglichkeit: Klassen und Funktionen des Objektmodells k¨

onnen auch in

Klassenbibliotheken oder – spezieller – Frameworks zusammengefasst werden. Deren

Verwendung kann auf zwei Arten erfolgen: (1) Objekte der Klassenbibliothek werden

instanziert, (2) neue Klassen werden durch Vererbung von gegebenen Klassen der Bi-

bliothek abgeleitet. Die Programmiersprache ist in diesem Fall fest vorgegeben. Dass die

Kommunikation zwischen Anwendung und Server aber innerhalb derselben Laufzeitum-

gebung erfolgt, wirkt sich i. d. R. positiv auf den Kommunikationsaufwand und somit

auch auf die Ausf¨

uhrungsgeschwindigkeit aus.

Aus technischer Sicht sind alle drei Ans¨

atze gleich m¨

achtig. Die Unterschiede liegen in

dem der Entwicklung zugrunde liegenden Paradigma: W¨

ahrend die Verwendung von

reinen Remote Procedure Calls und Object Access ein service-zentriertes Vorgehen

32Hierbei muss lediglich das die Schnittstelle beschreibende XML-Schema angepasst werden, um die

Anderungen auch f¨

ur Clients verf¨

ugbar zu machen.

146

4.2. Eine Rahmenarchitektur f¨

ur verteilte Lern- und Arbeitsumgebungen

impliziert, erlauben Proxy-Objekte und Klassenbibliotheken die Anwendung objekt-

orientierter Konzepte und bieten somit auch M¨

oglichkeiten der Modellerweiterung durch

Spezialisierung und Komposition.

4.2.2.3. E-Learning-spezifische Dienste

E-Learning-spezifische Dienste k¨

onnen anhand ihrer Wiederverwendbarkeit entweder als

h¨

ohere Dienste der Produktstandardarchitektur oder als Anwendungskomponenten der

Produktarchitektur implementiert werden. Ersteres bietet sich an, wenn ein Dienst inner-

halb der Softwareproduktlinie in mehreren Produkten wieder verwendet werden kann.

Beispielsweise Komponenten zur Abfrage des Awareness-Status best¨

atigter Kontakte

oder zur Unterst¨

utzung von Diskursstrukturen, um verschiedene, auf Diskursen beru-

hende Lernszenarien mit spezialisierten Anwendungen unterst¨

utzen zu k¨

onnen.

In beiden F¨

allen wird ¨

uber die oben beschriebenen Schnittstellen auf kooperative

Dienste zugegriffen, um gemeinsame Modelle auslesen und ggf. manipulieren zu k¨

onnen.

Wird ein Dienst als h¨

oherer Dienst der Produktstandardarchitektur implementiert, ent-

f¨

allt jedoch die direkte Anbindung an eine Benutzungsschnittstelle; die Darstellungs-

komponenten und Komponenten zur Steuerung der Interaktion mit dem Benutzer sind

Teil der Produktarchitektur. Statt dessen muss die Funktionalit¨

at ¨

uber eine Komponen-

tenschnittstelle zur Verf¨

ugung gestellt werden, damit sie f¨

ur Anwendungskomponenten

der einzelnen Produkte im Zugriff ist.

Wo E-Learning-spezifische Dienste in der Architektur verteilt sind, h¨

angt zuerst von

der Zuordnung zu Produktstandard- oder Produktarchitektur ab, jedoch auch von den

eingesetzten Technologien. L¨

asst sich ein E-Learning-spezifischer Dienst im Rahmen der

Produktstandardarchitektur ¨

uber ein modulares Erweiterungskonzept des Groupware-

Frameworks implementieren und sprechen keine anderen softwarearchitektonischen Prin-

zipien dagegen, ist diese Variante sicherlich zu bevorzugen (vgl. hierzu auch 151ff.).

Alternativ kann der Dienst unter Verwendung eines Application Frameworks realisiert

werden. Entweder im Rahmen der Produktstandardarchitektur mit der skizzierten Kom-

ponentenschnittstelle oder – falls die M¨

oglichkeit der Wiederverwendung nicht gegeben

ist – als Anwendungskomponente der Produktarchitektur inklusive einer Benutzungs-

schnittstelle. Diese M¨

oglichkeit wird im folgenden Abschnitt n¨

aher beschrieben.

4.2.3. Die Produktarchitektur

Softwareprodukte auf Basis der Produktstandardarchitektur implementieren eine Be-

nutzungsschnittstelle f¨

ur spezielle Anwendungskontexte des kooperativen Arbeitens und

Lernens. Dazu werden Anwendungskomponenten ben¨

otigt, die ¨

uber die Kooperations-

und E-Learning-spezifischen Dienste eine synchron und asynchron kooperative Interak-

tion auf gemeinsamen, zentral persistierten Modellen implementieren.

F¨

ur die Entwicklung von Benutzungsschnittstellen kooperativer Systeme hat sich das

Model-View-Controller (MVC)-Muster etabliert (vgl. [Ham02], S. 170f., [SS01], S. 306ff.).

Dieses leitet aus der Interaktion mit einer Benutzungsschnittstelle drei verschiedene

Rollen ab:

147

4. Eine Rahmenarchitektur f¨

ur universit¨

ares E-Learning

âDas Modell ist ein Teilbereich oder eine lokale semantische Interpretation eines

gemeinsamen Modells. Im einfachsten Fall ein generisches Objekt, in Anwendungs-

kontexten mit h¨

oherer Granularit¨

at kann ein lokales Modell auch mehrere gemein-

same Modelle umfassen. Aus softwarearchitektonischer Sicht muss die Produktar-

chitektur dazu ein lokales Modell von einem oder mehreren gemeinsamen Modellen

instanzieren k¨

onnen.

âEine View repr¨

asentiert die Benutzungsoberfl¨

ache der Anwendung. Abh¨

angig von

den eingesetzten Technologien kann dies beispielsweise ein Fenster in einer Desk-

topanwendung sein oder eine dynamisch generierte Webseite, die ¨

uber einen Web-

Browser ausgef¨

uhrt wird.

âEin Controller steuert die Elemente der Benutzungsoberfl¨

ache, nimmt Benut-

zereingaben auf und manipuliert das Modell.

Das MVC-Muster impliziert eine Trennung von Zust¨

andigkeiten an zwei Stellen der Pro-

duktarchitektur. Erstens trennt es die Belange des Modells von denen der Benutzungs-

oberfl¨

ache. Diese Trennung ist essentiell, damit verschiedene Sichten auf ein gemeinsa-

mes Modell geboten werden k¨

onnen. Sichten k¨

onnen dabei unterschiedliche Werkzeuge

implementieren, die in Abh¨

angigkeit von der jeweiligen Benutzerrolle und vom Anwen-

dungskontext spezialisierte Funktionen der Modellmanipulation unterst¨

utzen.

Zweitens trennt das MVC-Konzept die Darstellung der Benutzungsschnittstelle von ih-

rer Steuerung. Diese separierende Betrachtung ist von Bedeutung, damit bspw. verschie-

dene Darstellungsformen mit ein und der gleichen Steuerung angeboten werden k¨

onnen.

In Abschnitt 4.2.7.2 wird diese Trennung zum Entwurf einer Benutzungsschnittstelle f¨

mobile Endger¨

ate benutzt (S. 164ff.).

Die Umsetzung des MVC-Musters im Softwaredesign ist dabei technologieabh¨

angig.

Moderne (Web-)Application-Frameworks unterst¨

utzen die Trennung von Modell, Dar-

stellung und Steuerung mit unterschiedlichen Ans¨

atzen.

Wendet man dieses Entwurfsmuster auf die Entwicklung verteilter Anwendungen auf

Basis eines Objektframeworks an, lassen sich dar¨

uber die zentralen Komponenten der

Produktarchitektur herleiten:

1. Ein entsprechendes Application-Framework zur Unterst¨

utzung der Anwendungs-

entwicklung. Als Teil einer Laufzeitumgebung bieten Application-Frameworks i. d. R.

Trennung von Daten, Anwendungslogik und Pr¨

asentation (MVC-Konzept), einen

Registrierungsdienst (dependency injection), Schnittstellen zu Basisdiensten der

Infrastruktur wie Datenbanken, Middleware, E-Mail und Authentifizierung, sowie

ein lokales Sitzungsmanagement und Lokalisierung,

2. Schnittstellen zu Kooperationsdiensten und E-Learning-spezifischen Diensten der

Produktstandardarchitektur. Das kann – wie oben beschrieben – zum Beispiel ein

Web-Service-Cient oder eine Klassenbibliothek sein, die die konfigurierten Modelle

als Objektstruktur in der Laufzeitumgebung der Anwendung zur Verf¨

ugung stellen,

3. Eine Instanz eines gemeinsamen Modells (lokales Modell) als Grundlage koopera-

tiver Manipulation,

148

4.2. Eine Rahmenarchitektur f¨

ur verteilte Lern- und Arbeitsumgebungen

4. Anwendungskomponenten, die auf Basis der Kooperations- und E-Learning-Dienste

die lokale Instanz mit dem gemeinsamen Modell abgleichen und die Steuerung der

Interaktion ¨

uber die Benutzungsschnittstelle implementieren,

5. Eine Darstellungsschicht, die der Darstellung gemeinsamer Modelle und der durch

sie repr¨

asentierten Dokumente, Inhalte und Wissensstrukturen dient. Dar¨

uber hin-

aus erlaubt sie auch die synchrone und/oder asynchrone kooperative Interaktion

mit den jeweils dargestellten Artefakten.

Das Application Framework als Teil der Laufzeitumgebung soll im Kontext der Produkt-

architektur nicht n¨

aher spezifiziert werden. Auf die Instanzierung gemeinsamer Modelle

in der lokalen Anwendungsschicht soll jedoch im Folgenden n¨

aher eingegangen werden.

Ebenfalls auf architektonische Belange der Anwendungskomponenten und der Darstel-

lungsschicht.

4.2.3.1. Konstruktion lokaler Modelle

Die generischen und konfigurierten Modelle des Groupware-Frameworks bilden in ver-

schiedenen Anwendungen die Basis des kooperativen Arbeitens und Lernens. In der

Produktarchitektur m¨

ussen diese gemeinsamen Modelle den Anwendungskomponenten

als Objekte zur Manipulation zur Verf¨

ugung stehen, die Anwendungslogik also durch

eine anwendungsspezifische Objektschicht fundiert werden.

Die dazu ben¨

otigten Schnittstellen zu h¨

oheren Diensten der Produktstandardarchitek-

tur wurden im letzten Abschnitt bereits erl¨

autert. Auf Basis der dadurch zur Verf¨

ugung

stehenden Objekte und Funktionen k¨

onnen die gemeinsamen Modelle der Produktstan-

dardarchitektur im Sinne eines lokalen Modells anwendungsspezifisch interpretiert und

erweitert werden. Die Sichten verteilter Anwendungen k¨

onnen Modelle dabei in un-

terschiedlicher Granularit¨

at darstellen. Ein speziell auf ein bestimmtes Lernszenario

zugeschnittenes Werkzeug bedient beispielsweise nur einen bestimmten Ausschnitt ei-

nes gemeinsamen Modells, w¨

ahrend gr¨

oßere Lernplattformen verschiedene gemeinsame

Modelle in einem lokalen Modell zusammenf¨

uhren. Zwei Softwaretechniken k¨

onnen in

diesem Kontext angewendet werden:

Anwendungsspezifische Erweiterung Neue Anwendungen dieser Dom¨

ane k¨

onnen ¨

uber

Instanzierung, Vererbung und Spezialisierung von Klassenbibliotheken oder Proxy-Ob-

jekte in der Ziel-Programmiersprache umgesetzt werden. Das bedeutet, dass die neuen

Objektklassen vollst¨

andig auf den generischen Elementen der gemeinsamen Modelle ba-

sieren; sie erweitern sie und erben daher alle ihre Funktionen und Parameter, w¨

ahrend

die M¨

oglichkeit besteht, sie um dar¨

uber hinausgehende Funktionen und Parameter zu

erg¨

anzen.

Anwendungsspezifische Interpretation Der andere Weg ist, ein neues, unabh¨

angiges

Set an anwendungsspezifischen Klassen zu entwickeln und darin bloß eine Referenz

auf generische (Proxy-)Objekte zu verwalten. Auf der einen Seite bedeutet dieser Weg

149

4. Eine Rahmenarchitektur f¨

ur universit¨

ares E-Learning

Fabrik

Anwendung

Fabrik gene-

rische Objekte

CSCW-

Plattform /

Datenbank

123

Generische

Klassen

Anwendungs-

spezifische

Klassen

Präsentations-

schicht Anwendungsschicht objektorientierte API Persistente Objekt-

verwaltung

Abbildung 4.15.: Instanzierung von Klassen in der Objektschicht der Anwendung ¨

uber

Fabriken.

zun¨

achst einen gr¨

oßeren Aufwand f¨

ur Entwurf und Implementierung, die so genann-

ten Wrapper-Methoden f¨

ur die generischen Objekte zu schreiben, da die Methoden der

Proxy-Objekte bei diesem Vorgehen nicht einfach geerbt werden k¨

onnen. Auf der an-

deren Seite erlaubt dieses Vorgehen die Gestaltung einer eigenen Vererbungshierarchie

zwischen den anwendungsspezifischen Klassen. Ein solcher Vererbungsbaum kann vom

Basis-Objekt angefangen neu geschaffen werden und erleichtert die Adaption spezifischer

Dom¨

anen- oder Anwendungskonzepte.

Die Proxy-Objekte respektive die Klassenbibliothek umfasst in der Regel eine Fabrik, die

jedoch ausschließlich Instanzen generischer (Proxy-)Objekttypen erzeugen kann. Soll das

lokale Modell eine Interpretation oder Erweiterung eines gemeinsamen Modells sein, wird

neben einem neuen Set an Klassen auch eine anwendungsspezifische Fabrik ben¨

otigt,

an die die Erzeugung der neuen Objekte delegiert werden kann. Dieses klassenbasierte

Erzeugungsmuster kapselt das Wissen um die zu erzeugenden Klassen und lagert es aus

der Standardproduktarchitektur aus (vgl. Abbildung 4.15).

4.2.3.2. Ausf¨

uhrung und Manipulation von Modellen

Anwendungskomponenten erlauben eine automatisierte und interaktive Nutzung ge-

meinsamer Modelle im Kontext der Anwendung. Dazu implementieren sie bspw. Me-

thoden, die die Strukturen und Mechanismen der Modelle verdeutlichen, oder solche,

die eine aufgabenorientierte Manipulation realisieren.

Eine Anwendungskomponente zum Sitzungsmanagement baut dazu die Verbindung

mit den h¨

oheren Diensten der Produktstandardarchitektur auf, meldet den Benutzer

am Groupware-Framework an und koordiniert synchrone Funktionen und Darstellungen

zwischen kooperierenden Benutzern.

150

4.2. Eine Rahmenarchitektur f¨

ur verteilte Lern- und Arbeitsumgebungen

Abh¨

angig vom Typ der zu unterst¨

utzenden Darstellung ¨

ubernehmen die Anwendungs-

komponenten dabei unterschiedliche Aufgaben der Interaktionskontrolle. Beispielsweise

k¨

onnen in einer direktmanipulativen Anwendungsschnittstelle die Elemente lokaler Mo-

delle rein visuell dargestellt werden. Bei diesem Ansatz werden Technologien ereignis-

basierter, virtueller Welten mit F¨

ahigkeiten zum netzgest¨

utzten, kooperativen Arbeiten

und Lernen verkn¨

upft. Die direkte Manipulation kann dann durch das Object Action

Interaction-Modell (OAI) direkt innerhalb der Darstellung erfolgen (vgl. [Shn83]).

In Web-basierten Benutzungsschnittstellen liegt der Fokus der Interaktionssteuerung

dagegen eher auf der Ansteuerung von HTML-Schablonen (der View) und der Aus-

wertung von HTTP-Requests. Dar¨

uber k¨

onnen Interaktionen ausgewertet werden, die

der Benutzer im Browser get¨

atigt hat, und das Modell entsprechend manipuliert werden.

Durch das kooperative MVC-Muster ist die Objektschicht verteilter Anwendungen direkt

oder indirekt33 mit den Kooperationsdiensten des Groupware-Frameworks verbunden.

Diese Assoziation von lokalen Modellen mit zentral verwalteten gemeinsamen Modellen

erweitert das MVC-Konzept im Sinne einer zentralisierten Architektur, wodurch syn-

chrone Kooperationen erst erm¨

oglicht werden (vgl. [Ham02], S. 171f.).

Die gemeinsamen Modelle kapseln dazu sowohl dom¨

anenspezifische Modelldaten, die

f¨

ur alle Anwendungen von Interesse sind, als auch spezifische Daten einzelner Anwendun-

gen, die diese zur Darstellung und Ausf¨

uhrung des Modells persistent ben¨

otigen. Wird

ein Modell in einer gemeinsamen Sitzung durch eine Anwendung manipuliert, m¨

ussen

alle verteilten Anwendungen der Sitzung ¨

uber den neuen Zustand des Modells informiert

werden, wenn allgemeine Daten ge¨

andert wurden. Dar¨

uber hinaus m¨

ussen alle verteilten

Anwendungen des gleichen Typs informiert werden, wenn sich f¨

ur diesen Anwendungs-

typ spezifische Modelldaten ge¨

andert haben, bspw. Koordinaten zur Darstellung eines

Objektes in einem Shared Whiteboard.

Die Event-basierte Benachrichtigung ¨

uber Zustands¨

anderungen von Objekten kann

softwaretechnisch mithilfe des Observer-Patterns umgesetzt werden (vgl. [GHJV96],

S. 257f.). Dazu k¨

onnen Anwendungskomponenten der Produktarchitektur so genannte

Listener-Methoden implementieren, die ausgel¨

ost werden, wenn sich das Modell ¨

andert.

4.2.4. Verteilung

Die klare Trennung der Schichten und die Nutzung von Entwurfsmustern wie Depen-

dency Injection und dem kooperativen MVC-Konzept beg¨

unstigen einfach gerichtete

Abh¨

angigkeiten zwischen den Komponenten. Dies l¨

asst mehrere Verteilungsm¨

oglichkeiten

auf Laufzeitumgebungen zu. Denkbar ist eine so genannte ”Fat Server/Thin Client“-

Verteilung, bei denen alle Komponenten bis zur Darstellungsschicht in einer Umgebung

laufen. Durch die klare Trennung der Schichten nach Wiederverwendungsgrad bieten

sich jedoch insbesondere solche Verteilungsstrategien an, welche die Komponenten der

Produktstandardarchitektur zentral bereitstellen und – entsprechend der zu erwarte-

ten Mehrbelastung – in einer f¨

ur die Last optimierten Laufzeitumgebung installieren.

33Neben der direkten Verbindung k¨

onnen Komponenten der Produktarchitektur wie beschrieben ¨

uber

die E-Learning-Dienste mit den Kooperationsdiensten verbunden sein.

151

4. Eine Rahmenarchitektur f¨

ur universit¨

ares E-Learning

«device»

: DB Server

«device»

: Application Server

«execution environment»

: Application Framework

«component»

Groupware

Framework

«component»

E-Learning-

spezifische

Dienste

«device»

: Application Server

«component»

anwendungs-

spezifische

Dienste

«component»

FrontController

und View

«execution environment»

: Application Framework

Abbildung 4.16.: M¨

ogliche Verteilung der Architekturkomponenten

Im Sinne der Hochverf¨

ugbarkeit dieser in der Architektur relativ h¨

aufig nachgefrag-

ten Komponenten k¨

onnen die E-Learning-spezifischen Dienste auch in einer von dem

Groupware-Framework separaten Laufzeitumgebung betrieben werden. So k¨

onnen so-

wohl die Kooperationsdienste als auch die E-Learning-spezifischen Dienste redundant

ausgelegt und parallel betrieben werden.

Die individuellen Komponenten der darauf basierenden Anwendungen k¨

onnen nach

Betreibermodell verteilt werden, beispielsweise dezentral auf Servern der einzelnen Fa-

kult¨

aten. Abbildung 4.16 beschreibt eine m¨

ogliche Verteilung, bei der die Komponenten

der Produktarchitekturen auf mehrere Laufzeitumgebungen verteilt sind.

4.2.5. Integration in eine universit¨

are IT-Infrastruktur

Die aktuellen Bestrebungen nach einem integrierten Informationsmanagement an Hoch-

schulen und die daraus resultierenden Anforderungen an Schnittstellen wurden bereits

einleitend in Kapitel 2 motiviert (S. 17f., S.26ff.).

In diesem Unterkapitel sollen L¨

osungskonzepte f¨

ur wichtige Schnittstellen auf Basis

von Standardprotokollen erarbeitet und in die Rahmenarchitektur mit aufgenommen

werden. Beispielhafte Szenarien sind die Anbindung an Campus Management- und Bi-

bliothekssysteme. Unterkapitel 4.2.6 beschreibt dar¨

uber hinaus die Integration externer

Knowledge Pools, die auch zur internen Anbindung von Content Repositories an die hier

konzipierte verteilte Architektur genutzt werden kann.

Letztendlich ist die Anwendungsschicht der Ausgangspunkt f¨

ur die Herstellung von

Interoperabilit¨

at zwischen Systemen. Je mehr Dienste zwei oder mehr Systeme gemein-

sam haben, desto umfassender k¨

onnen sie integriert werden.

Abbildung 4.17 zeigt die unterschiedlichen Schichten, die f¨

ur eine Interoperabilit¨

at von

verteilten Systemen eine Rolle spielen. Um Interoperabilit¨

at zu erreichen, muss es f¨

jede Schicht mindestens eine gemeinsame Komponente geben. Die gew¨

unschten Dienste

152

4.2. Eine Rahmenarchitektur f¨

ur verteilte Lern- und Arbeitsumgebungen

Semantisches Modell

(bspw. gemeinsame Terminologie)

Anwendungen

(bspw. Suche)

Basisdienste

(bspw. Session Management)

Nachrichtenübermittlungsschicht

(bspw. SOAP, XML, RPCs, JRMI)

Infrastruktur

(bspw. HTTP, SMTP, TCP/IP)

Abbildung 4.17.: Interoperability Stack

beeinflussen, welche Strukturen im semantischen Modell ben¨

otigt werden. Diese k¨

onnen

bspw. in Form einer gemeinsam verwendeten dom¨

anenspezifischen Terminologie vorlie-

gen oder durch ein anderes gemeinsames Datenschema wie standardisierte Anfrage- und

Ergebnisformaten.

Auf der Schicht der Basisdienste muss ein gemeinsam zu nutzender Authentifizie-

rungsdienst vorhanden sein. Die Anwendungsdienste sollten dabei aber so unabh¨

angig

gestaltet sein, dass sie von keiner speziellen Umsetzung dieser Komponenten abh¨

angen,

sondern nur die Existenz dieser Komponenten erfordern. Dadurch wird die Anpassbar-

keit an andere Systeme erh¨

oht.

4.2.5.1. Anbindung an Verwaltungssysteme

Bei der Planung und beim Pr¨

ufungsmanagement ¨

ubernimmt die Hochschulverwaltung

mit Hilfe einer zentralen, stark prozessorientierten Systemlandschaft unterst¨

utzende

Funktionen, wie beispielsweise die Erstellung des Vorlesungsverzeichnisses oder Studien-

kontenverwaltung. Im Gegensatz dazu liegt die Durchf¨

uhrung der Lehre in der Hand von

Lehrst¨

uhlen, die i. d. R. teilautonom ¨

uber den Einsatz von Computerunterst¨

utzung zu

diesem Zweck frei entscheiden k¨

onnen. Um zus¨

atzliche Mehraufw¨

ande f¨

ur Administration

und Datenerfassung und damit verbundene Verz¨

ogerungen bei allt¨

aglich wiederkehren-

den Nutzungsszenarien zu vermeiden, m¨

ussen identische Daten z. B. von Personen und

Lehrveranstaltungen zwischen Verwaltungs- und elektronischen Lernumgebungen kon-

sistent gehalten werden.

Die Alternativen f¨

ur die technische Umsetzung der Integration wurden in diesem Ka-

pitel bereits vorgestellt. Die abzubildenden Nutzungsszenarien werden in [DEH+02],

[KNW03], [BFH+04] und [GR07] skizziert und weisen auf eine asynchrone, lose Kopplung

der Systeme hin, da zwischen den Systemen oftmals nur Ver¨

anderungen34 abgeglichen

werden m¨

ussen (vgl. Tabelle 4.3).

34Die Ver¨

anderung (Delta) l¨

asst sich als Differenz der Datenbest¨

ande der abzugleichenden Systeme

ermitteln, bspw. zur Ermittlung der seit der letzten Synchronisation neu erfassten Kursbuchungen

∆ = AlleKursbuchungen −Bereits ¨

UbermittelteKursbuchungen.

153

4. Eine Rahmenarchitektur f¨

ur universit¨

ares E-Learning

Eine synchrone Kommunikation ¨

uber entfernte Funktionsaufrufe oder verteilte Objekte

w¨

urde in dem Fall die Komplexit¨

at und den Kopplungsgrad der Schnittstelle unn¨

otig

erh¨

ohen und zu Mehrkosten vor allem in der Wartung und Weiterentwicklung f¨

uhren

(vgl. [RHG05], S. 70, [HPP07], S. 3). Eine direkte Kopplung sollte daher vermieden wer-

den.

Verwaltungssystem virtuelle Lernumgebung

Veranstaltung anlegen åKursraum und Gruppen anlegen und be-

schreiben

Dozenten zuordnen åBerechtigungen f¨

ur Dozenten auf Kurs-

raum einrichten

Teilnahmebeschr¨

ankung einrichten åGruppenzutritt beschr¨

anken

Studenten zu Veranstaltung zulassen åStudenten in Teilnehmergruppe aufneh-

men

Studenten von Veranstaltung abmelden åStudenten aus Teilnehmergruppe aus-

schließen

Tabelle 4.3.: Beispiele gemeinsamer Nutzungsszenarien von Verwaltungs- und Lernsys-

temen

Daher bietet sich eine nachrichtenbasierte Kommunikation ¨

uber eine Integrationsplatt-

form respektive ¨

uber ein Messagebussystem an, wobei das f¨

ur einen Prozess f¨

uhrende

System – also das, in dem die Daten erhoben werden – definiert sein muss. Das Message-

bussystem implementiert eine Warteschlange f¨

ur Nachrichten und garantiert damit die

lose Kopplung in der 1:n- bzw. n:m-Kommunikation zwischen den beteiligten Systemen.

Nachrichtenerzeugung und -verarbeitung k¨

onnen als Prozesse somit zeitlich getrennt

werden, was sowohl eine synchrone als auch asynchrone Kommunikation erm¨

oglicht. Die

Anbindung der Systeme an den Messagebus wird in der Regel durch Konnektoren her-

gestellt, die im Einzelfall individuell implementiert werden m¨

ussen.

Zun¨

achst wird f¨

ur das f¨

uhrende System die Schnittstelle definiert. Dadurch wird der

Funktionsumfang festgelegt, sowie das Format der auszutauschenden Daten und das

Kommunikationsmodell (synchron/asynchron). Gleichzeitig werden somit die Vorgaben

an die Gegenseite spezifiziert. Die Schnittstelle sollte dabei fachlich weit genug gefasst

sein, um nicht nur den spezifischen Anforderungen einer einzigen Plattform zu gen¨

ugen,

sondern ein m¨

oglichst breites Spektrum an Szenarien abbilden35. Dies minimiert die

Wahrscheinlichkeit einer ¨

Anderung der Schnittstelle bei Anbindung weiterer Systeme.

Ist das sendende System auf eine Antwort vom empfangenden System angewiesen, l¨

asst

sich ein asynchrones Kommunikationsmodell implementieren. Diese Art der Schnitt-

stelle zeichnet sich durch eine hohe Performance aus, da der sendende Thread sofort

35Das gilt auch f¨

ur den Fall, dass im ersten anzukoppelnden System ¨

Anderungen n¨

otig sind oder interne

Prozesse ge¨

andert werden m¨

ussen. Dies sind einmalige Aufwendungen, die kalkulierbar sind (vgl.

[RHG05], S. 70).

154

4.2. Eine Rahmenarchitektur f¨

ur verteilte Lern- und Arbeitsumgebungen

Application Framework

«component»

B:Anwendungs-

komponente

«controller»

b:Steuerung

«component»

A:Anwendungs-

komponente

«controller»

a:Steuerung

«component»

Client Stub

Message

Listener

Message Bus

Message

Event

Handler

Server-

Stub

Server-

Stub

Message

Channel

Message

Channel

Agent

Verwaltungs-

system

«component»

Client Stub

«component»

Anwendungs-

komponente

Abbildung 4.18.: Die Messagebus-Schnittstelle

weiterarbeiten kann. Weiterhin stabilisiert eine zwischengeschaltete Warteschlange den

Kommunikationsweg. Moderne Messagebussysteme garantieren auch dann eine Zustel-

lung der Nachricht, wenn das zu empfangende System zum Zeitpunkt der Sendung nicht

erreichbar ist. Die Nachricht wird dann in der Warteschlange vorgehalten und zugestellt,

wenn das System wieder empfangsbereit ist.

Ein synchrones Kommunikationsmodell muss hingegen gew¨

ahlt werden, wenn der sen-

dende Thread zum Weiterarbeiten ein Ergebnis vom Empf¨

anger ben¨

otigt, wie bspw. eine

differenzierte Statusmeldung ¨

uber die Transaktion.

Die Definition der Schnittstelle ist produktspezifisch und somit innerhalb der Rahmen-

architektur der Produktarchitektur zuzuordnen. Der Konnektor zum Messagebussystem

bzw. zur Integrationsplattform kann hingegen der Produktstandardarchitektur zugeord-

net werden (vgl. Abb. 4.18). Dieser Konnektor implementiert einen so genannten Messa-

ge Listener, der anhand einer Analyse des Nachrichtenkopfes eine empfangene Nachricht

an einen f¨

ur den Nachrichtentyp zust¨

andigen Message Event Handler weiterleitet. Da

Nachrichtentyp und -behandlung anwendungsspezifisch sind, muss diese Zuordnung aus

einer Konfiguration ausgelesen werden.

Die eigentliche Verarbeitung der Nachricht findet im Message Event Handler statt.

Hier werden aus der Nachricht Objekte erzeugt und darauf Funktionen aufgerufen. Im

Falle einer synchronen Kommunikation generiert ein Event Handler nach der Verarbei-

tung eine Antwort f¨

ur das aufrufende System, die ¨

uber den Konnektor auf den Message-

bus gelegt wird. Damit der urspr¨

ungliche Sender die Antwort der gesendeten Nachricht

zuordnen kann, muss die Antwort einen entsprechenden Schl¨

ussel referenzieren.

Grunds¨

atzlich k¨

onnen ¨

uber eine nachrichtenorientierte Middleware nicht nur Lernum-

gebungen an Verwaltungssysteme angebunden werden. Eine solche Integrationsplattform

kann als zentraler Dienstvermittler innerhalb einer gesamtuniversit¨

aren IT-Infrastruktur

Datenbanken, Web-Dienste und zum Teil propriet¨

are Anwendungsschnittstellen prozess-

155

4. Eine Rahmenarchitektur f¨

ur universit¨

ares E-Learning

gesteuert zusammenschalten. Durch das Publish-Subscribe-Verfahren auf Basis von spe-

zifischen Nachrichtenkan¨

alen bietet sich dar¨

uber hinaus – neben einem zentralen Iden-

tit¨

ats- und Rechtemanagement – ein zentraler Ansatzpunkt f¨

ur das Rechtemanagement

auf Dienstebene. Hier kann gesteuert werden, welche Systeme ¨

uber welche Nachrichten

in welchem Umfang informiert werden36.

4.2.5.2. Anbindung an Bibliothekssysteme

Ein wichtiger Bestandteil des wissenschaftlichen Arbeitens an Universit¨

aten ist die Lite-

raturrecherche, also das Suchen, Ausw¨

ahlen, Beschaffen und Verarbeiten wissenschaft-

licher Quellen. Insbesondere das Suchen in Onlinedatenbanken und das Ausw¨

ahlen und

Speichern relevanter Ergebnisse in einer eigenen Literaturliste sollte ohne Systemwechsel

durch die allt¨

aglich genutzte Lern- und Arbeitsumgebung unterst¨

utzt werden.

Dazu soll im Folgenden – gem¨

aß den Entwurfsprinzipien verteilter Architekturen –

ein geeignetes Standardprotokoll identifiziert und eine dazu geeignete Schnittstelle in

die Rahmenarchitektur aufgenommen werden.

Das Standardprotokoll im Bibliotheksbereich zur Abfrage von bibliographischen In-

formationssystemen ist die internationale Spezifikation ANSI/NISO Z39.50-2003: ”In-

formation Retrieval (Z39.50): Application Service Definition and Protocol Specificati-

on“ (vgl. [NIS02]). In den 90er Jahren f¨

orderte der Bund und der DFG unter der Fe-

derf¨

uhrung der Deutschen Bibliothek das Verbundprojekt ”DBV-OSI-II“, das auch viele

deutsche Datenbanksysteme um die Z39.50-Schnittstelle erweitert hat (vgl. [Luc96]).

Das hatte zur Folge, dass heute – mehr als zehn Jahre sp¨

ater – viele Internetportale und

Anwendungen ¨

uber diese Schnittstelle den Zugriff auf bibliographische Online-Kataloge

realisieren37.

Aus technischer Sicht setzt Z39.50 als sitzungsbasiertes Anwendungsprotokoll auf

dem Internet-Protokoll TCP/IP auf. Die Spezifikation legt die Funktionen fest (siehe

Tab. 4.4), sowie die Operatoren und ¨

Ubertragungsformate.

Funktion Erkl¨

arung

INITIALIZE Authentifizierung des Clienten, Er¨

offnung einer Z39.50-Session

SEARCH Suchanfragen, Query, Name von Result-Sets und Format

PRESENT ¨

Ubertragung von Suchergebnissen

DELETE_RESULT_SET L¨

oschen von Result-Sets beim Zielsystem

RESOURCE_REPORT Abfrage der angefallenen Kosten/Abrechnung

SCAN Suche in geordneten Term-Listen

CLOSE Schließen der Z39.50-Session

Tabelle 4.4.: Basisfunktionen des Z39.50 Protokoll

36Integrationsplattformen bieten z. T. die M¨

oglichkeit, Nachrichteninhalte f¨

ur bestimmte Systeme ge-

zielt aufzubereiten und daher Informationen f¨

ur bestimmte Adressaten auch einzuschr¨

anken.

37Beispiele: Digitale Bibliothek des Hochschulbibliothekszentrum NRW (http://rhea.hbz-nrw.de/

Digibib), das Portal p7 des Gemeinsamen Bibliotheksverbund (http://p7.gbv.de), oder die Li-

teraturverwaltung im Web 2.0 namens LibraryThing (http://librarything.de). Letzter Zugriff:

31.07.2008.

156

4.2. Eine Rahmenarchitektur f¨

ur verteilte Lern- und Arbeitsumgebungen

«specification»

ANSI/ISO

Z39.50-2003

Application Framework

«component»

Z39.50-Schnittstelle

+initialize()

+search()

+present()

+delete_result_set()

+resource_report()

+scan()

+close()

Z3950_Interface

Z39.50-Client

«component»

Anwendungs-

komponente

«controller»

a:Steuerung

Abbildung 4.19.: Die Z39.50-Schnittstelle in der Rahmenarchitektur

Da der Zugriff auf Online-Kataloge in verschiedenen Lern- und Arbeitsanwendungen

n¨

utzlich sein kann, ist die Z39.50 Schnittstelle in der Produktstandardarchitektur veror-

tet. Somit kann sie in den darauf basierenden Implementierungen unterschiedlich genutzt

werden. Die Schnittstelle impliziert architektonisch einen clientseitigen Stub38, der die

Komplexit¨

at der Z39.50-Spezifikation verbirgt und als Funktionen den Anwendungskom-

ponenten lokal verf¨

ugbar macht. Die Konfiguration der Endstellen, d. h. ob bibliogra-

phische Kataloge im Kontext der Anwendung fest vorgegeben oder manuell durch den

Benutzer erg¨

anzt werden k¨

onnen, muss in der Produktarchitektur vorgenommen werden.

Ebenso anwendungspezifisch ist die Art der Weiterverarbeitung der Ergebnisse. Auch sie

muss in der Anwendungslogik der einzelnen Produkte individuell programmiert werden.

4.2.6. Anbindung an interne und externe Content-Provider

Die in Kapitel 2 bereits beschriebene internationale und nationale Bildungspolitik hat

mit ihren F¨

orderprogrammen viele Verbundprojekte unterst¨

utzt, die Lerninhalte hoch-

schul- und sogar l¨

ander¨

ubergreifend zur allgemeinen Verwendung erstellt und ausge-

tauscht haben. Dar¨

uber sind ¨

uber die Jahre hinweg große Knowledge-Pools erwachsen,

die aus Netzwerken verteilter Lernobjekt-Repositories mit Inhalten und Metadaten be-

stehen. Zwei der gr¨

oßten Projekte sind in diesem Kontext die ARIADNE Foundation for

the European Knowledge Pool39 und das internationale Global Learning Objects Brokered

Exchange Consortium (GLOBE)40.

38Ein Stub (deutsch: Stummel, Stumpf) kapselt Funktionalit¨

at, die auf einem anderen Rechner oder in

einem anderen Speicherbereich ausgef¨

uhrt wird und sonst nur ¨

uber komplexe Protokolle zu erreichen

ist. Somit entspricht ein Stub dem in dieser Arbeit bereits vorgestellten Entwurfsmuster ”Remote

Proxy“ (Stellvertreter, vgl. S. 146).

39Mehr Informationen unter http://www.ariadne-eu.org/. Letzter Zugriff: 31.07.2008.

40Mehr Informationen unter http://globe.edna.edu.au. Letzter Zugriff: 31.07.2008.

157

4. Eine Rahmenarchitektur f¨

ur universit¨

ares E-Learning

Mithilfe dieser verteilten Architekturen l¨

asst sich einerseits das eigene Angebot um Lern-

inhalte erweitern. Ein f¨

oderierter Suchdienst 41 kontaktiert das oder die ausgew¨

ahlten

Netzwerke mit der gew¨

unschten Suchanfrage und liefert Metadatens¨

atze ¨

uber die Treffer

zur¨

uck. Diese k¨

onnen dann abgerufen und in das eigene Content Repository ¨

ubernommen

werden. Andererseits k¨

onnen ¨

uber die Netzwerke auch eigene Inhalte zur freien Wieder-

verwendung anderen Hochschulen und Dozierenden zur Verf¨

ugung gestellt werden. Dazu

muss das eigene Repository ¨

uber definierte Schnittstellen an den Verbund angeschlos-

sen werden, damit lokale Inhalte auch f¨

ur entfernte Benutzer ¨

uber die f¨

oderierte Suche

aufgefunden und geladen werden k¨

onnen.

Diese beiden Szenarien – der Betrieb des lokalen Repository als Client und als Provi-

der eines f¨

oderierten Knowledge Pools42 – sollen durch die Produktstandardarchitektur

unterst¨

utzt werden k¨

onnen. Dazu wird die Rahmenarchitektur im Folgenden um eine

entsprechende Schnittstelle nach dem SQI-Standard (Simple Query Interface) erwei-

tert43.

4.2.6.1. Das Simple Query Interface (SQI)

Gerade bei der Unterst¨

utzungen im E-Learning gibt es unterschiedlichste aktuelle Ans¨

atze

zur Verwaltung von Wissens- bzw. Lernobjekten, wie bspw. die Verteilung ¨

uber Peer-to-

Peer- oder semantische Netze. Dies f¨

uhrt zu einer hohen Heterogenit¨

at von Lernreposi-

tories und damit zu erschwerter Interoperabilit¨

at.

Aus diesem Grund wurde im Rahmen von CEN/ISSS Learning Technology Workshops

mit SQI eine Schnittstelle zur Konfiguration und ¨

Ubertragung von Anfragen an Lern-

repositories beschrieben44 (vgl. [S+05]). Auf Ebene der Basisdienste spezifiziert SQI

dazu ein Sitzungsmanagement, welches sich um Authentifizierung k¨

ummert und das von

h¨

oherwertigen Diensten genutzt werden kann. Auf Ebene der E-Learning-spezifischen

Dienste beschr¨

ankt sich SQI auf die Spezifikation eines Query-Dienstes, der die Inter-

operabilit¨

at f¨

ur Anfragen zwischen heterogenen Systemen herstellt. Dabei ist weder das

semantische Modell der Anfrage n¨

aher spezifiziert, noch wird eine Aussage ¨

uber Infra-

struktur und Nachrichten¨

ubermittlungsschicht getroffen. SQI ist daher kompatibel mit

unterschiedlichsten Netzwerkprotokollen und Datenformaten. Diese semantische Neutra-

lit¨

at f¨

uhrt aber dazu, dass zus¨

atzliche Vereinbarungen zwischen kooperierenden Syste-

men getroffen werden m¨

ussen, wie ¨

uber die Menge an Attributen und Vokabularien, die

41Zum Beispiel die f¨

oderierte Suche SILO (Search & Index Learning Objects) unter http://ariadne2.

unil.ch/SiloAriadne/. Letzter Zugriff: 31.07.2008.

42Dabei ist zu beachten, dass es sich durchaus auch um hochschulinterne Knowledge Pools und Content

Repositories handeln kann, wie bspw. Bibliotheks- und Dokumentenserver oder Learning Object

Repositories.

43Obwohl die IMS Spezifikation Digital Repositories Interoperability (IMS DRI) die Z39.50-Nachfolger

Search and Retrieve Web Service (SRW) und Search and Retrieve via URL (SRU, s. http:

//www.loc.gov/z3950/agency/) sowie das Protocol for Metadata Harvesting (OAI PMH, vgl.

http://www.openarchives.org/OAI/openarchivesprotocol.html) empfiehlt, scheint sich der SQI-

Standard zumindest f¨

ur Europ¨

aische Knowledge Pools durchzusetzen.

44Zwar wurde SQI f¨

ur die Dom¨

ane E-Learning entwickelt, kann jedoch problemlos auf andere Inhalte

wie bspw. Videos adaptiert werden. So lassen sich bspw. Inhalte der Plattform Youtube.com ¨

uber

SQI finden und zur¨

uckgeben. Das entsprechende WSDL-Binding f¨

ur SQI ist online unter http:

//sqi-wsdl.sourceforge.net/ verf¨

ugbar.

158

4.2. Eine Rahmenarchitektur f¨

ur verteilte Lern- und Arbeitsumgebungen

Entferntes

Repository

(SqiSource)

Simple Query

Interface

Component

Produktstandardarchitektur

(SqiTarget)

Simple Query

Interface

Component

Wrapper

Metadata

Allgemeine

Anfragesprache

Allgemeines

Ergebnisformat

Lokale Anfrage-

Sprache

Lokales

Ergebnis-

format

Abbildung 4.20.: Die SQI-Schnittstelle der Produktstandardarchitektur

in einer Anfrage genutzt werden k¨

onnen, die Anfragesprache und deren Repr¨

asentation,

sowie die Metadatenformate der Ergebnisses. Ein Mechanismus zur Abfrage oder Aus-

handlung dieser Parameter wird von der SQI-Spezifikation nicht angeboten.

Sind diese Vereinbarungen getroffen, wird u. U. noch eine Transformation zwischen

den vereinbarten Formaten und den im lokalen Repository genutzten Formaten ben¨

otigt

(Wrapper). Der grunds¨

atzliche Ablauf einer Anfrage w¨

urde somit wie in Abbildung 4.20

dargestellt aussehen.

Eine weiterer Bestandteil der SQI-Spezifikation ist die M¨

oglichkeit der asynchronen

zus¨

atzlich zur synchronen Anfrage. Bei einer asynchronen Anfrage wird deren Beant-

wortung vom angefragten System initiiert. Dieses ruft – sobald eine bestimmte Anzahl

an Ergebnissen vorliegt – eine bereitgestellte Methode des aufrufenden Systems auf und

ubermittelt ihr die vorliegenden Ergebnisse. Das aufrufende System muss nach dem Ab-

senden der Anfrage nicht auf das Ergebnis warten, sondern braucht erst beim Eintreffen

neuer Ergebnisse darauf zu reagieren. Dies hat vor allem Vorteile bei einer gleichzeiti-

gen Anfrage mehrerer Repositories oder ganzer P2P-Netzwerke, da die Antwortzeiten

hierbei stark variieren und auch der Ausfall eines Knotens in einem P2P-Netzwerk nicht

ungew¨

ohnlich ist.

4.2.6.2. Anfragesprachen und Ergebnisformate

Suchanfragen k¨

onnen mithilfe von Anfragesprachen formuliert werden. Sie stellen Syn-

tax und Semantik zur Verf¨

ugung, mit denen anzufragenden Systemen mitgeteilt wer-

den kann, welche Daten in welchem Zusammenhang relevant sind. Eine Anfragesprache

gilt dabei als ausdrucksst¨

arker, je klarer relevante von nicht relevanten Daten abge-

grenzt werden k¨

onnen. Dabei muss die M¨

achtigkeit und die Benutzbarkeit, d. h. die

Verst¨

andlichkeit und Erlernbarkeit, gegeneinander abgewogen werden. F¨

ur die Auswahl

der Anfragesprache spielt zus¨

atzlich zur Ausdrucksst¨

arke und Benutzbarkeit vor allem

ihre Verbreitung eine entscheidende Rolle, wenn mit anderen Systemen kommuniziert

werden soll. Beispiele f¨

ur Anfragesprachen sind XQuery, CQL und VSQL (s. Anhang

A.1).

159

4. Eine Rahmenarchitektur f¨

ur universit¨

ares E-Learning

F¨

ur das Ergebnisformat gilt ¨

Ahnliches wie f¨

ur die Anfragesprache. Auch in diesem Be-

reich l¨

asst SQI gewollt offen, in welcher Form die Ergebnismenge beschrieben wird. F¨

eine Implementierung gibt es demnach mehrere Alternativen.

Bekannte Metadatenformate wie Dublin Core oder IMS LOM (vgl. S. 2.2.4.2) unter-

scheiden sich in Art und Menge der Metadaten, als auch in Syntax und Semantik der

Repr¨

asentation. Entscheidungskriterien bei der Auswahl des Ergebnisformats sind daher

neben einem hohen Verbreitungsgrad (1) die ¨

Ubertragbarkeit auf systemintern genutzte

Repr¨

asentationsformate, sowie (2) die M¨

oglichkeit der Weiterverarbeitung:

1. Wird das lokale Repository angefragt, muss das Ergebnis in das gew¨

unschte Aus-

tauschformat transformiert werden. Bei dieser Zuordnung m¨

ussen nicht alle inter-

nen Attribute zwingend eine Entsprechung im Austauschformat finden. Es sollten

jedoch genug Informationen geboten werden, damit interne Objekte von außerhalb

zugreifbar sind,

2. Soll die Ergebnismenge einer f¨

oderierten Suche lokal dargestellt werden, also ¨

uber

Produkte der Standardarchitektur, so sollte das Austauschformat entsprechend der

jeweiligen Benutzungsschnittstelle gen¨

ugend Informationen bieten, damit entfernte

Objekte analog zu den lokal vorgehaltenen Inhalten angezeigt werden k¨

onnen.

4.2.6.3. Architekturkonzept

SQI spezifiziert eine Schnittstelle im Sinne einer Funktionsintegration. Das bedeutet,

dass alle SQI-konformen Systeme die definierten Funktionen anbieten und nutzen. So-

mit wird die Portabilit¨

at von Funktionen respektive Interoperabilit¨

at im Sinne des

Informations- und Dokumentenaustauschs gesichert. Besitzt das System also per se die

von SQI geforderte Funktionalit¨

at45, m¨

ussen diese nur noch durch Ausimplementierung

der Schnittstellenspezifikation und eines Transformators (Wrapper) explizit verf¨

ugbar

gemacht werden (vgl. Abb. 4.21).

Zur Implementierung einer SQI-Unterst¨

utzung muss die Produktstandardarchitektur

sowohl als Web-Service Client als auch als Provider auftreten k¨

onnen. Um einen SQI-

Client zu realisieren, m¨

ussen eine Reihe von SQI-Methoden aufgerufen werden. Der

grunds¨

atzliche Ablauf bei der Nutzung von SQI teilt sich dabei in drei Abschnitte46

(vgl. [SMD04], [SMVAD05]):

Session Management F¨

ur den Methodenaufruf wird eine eindeutige Session-ID ben¨

tigt, die auf Basis eines Berechtigungsnachweises (Credentials, bspw. Login-Daten)

erzeugt wird47.

Query Parameter Configuration Anfrageparameter gelten bis zum Ende einer Sitzung

oder bis sie neu gesetzt werden. Parameter, die sowohl f¨

ur synchrone als auch asyn-

chrone Anfragen gelten, sind die Anfragesprache, die Anzahl der Ergebnisse in einer

45Also die Suche in Metadaten und R¨

uckgabe von Ergebnissen (Search/Expose), sowie das Abrufen

und die Auslieferung von Objekten (Request/Deliver). Nach [IMS03a] sind dies Standardfunktionen

von Content-Repositories und somit in der Regel vorhanden.

46Zus¨

atzlich dazu sind mit so genannten SQIFaults Codes f¨

ur den Fehlerfall spezifiziert.

47Es besteht auch die M¨

oglichkeit einer anonymen Session-Erzeugung mit vom Zielsystem oftmals

eingeschr¨

ankten Berechtigungen.

160

4.2. Eine Rahmenarchitektur f¨

ur verteilte Lern- und Arbeitsumgebungen

Ergebnismenge, die Gesamtzahl der Ergebnisse, die maximale Ausf¨

uhrungszeit der

Suche und das Ergebnisformat.

Synchronous/Asynchronous Query Interface Bei der eigentlichen Anfrage wird unter-

schieden zwischen der synchronen Anfrage, die als R¨

uckgabewert das Anfrageer-

gebnis hat, und der asynchronen Anfrage. Bei dieser zweiten Variante wird eine

R¨

uckantwort asynchron an eine bei der Anfrage angegebene Methode des aufru-

fenden Systems gesendet.

Notwendig f¨

ur die Implementierung von asynchronen Abfragen ist die Bereitstellung ei-

nes Ergebnis-Listeners in der Produktstandardarchitektur, sowie eine eindeutige Identifi-

kation jeder Suchanfrage, um die sp¨

ater eintreffenden Antworten zuordnen zu k¨

onnen48.

«specification»

SQI

«component»

SOAP-Engine

SoapServer SoapClient

Application Framework CSCW-Content-

Repository

Programmierschnittstelle

CSCW-Content-Repository

«subsystem»

Object

Repository

«component»

SQI-Schnittstelle

+setQueryLanguage()

+setMaxQueryResults()

+setMaxDuration()

+setResultsFormat()

+setResultsSize()

+synchronousQuery():string

+getTotalResultsCount():int

+setSourceLocation()

+asynchronousQuery()

SqiTarget

+createSession():string

+createAnonymousSession():string

+destroySession()

SqiSessionManagement

+queryResultsListener()

SqiSource

SqiListener

SqiProvider

SqiClient

+search():string

+transformResult():string

SqiWrapper

«subsystem»

lokale Suche

Abbildung 4.21.: Komponentenstruktur der SQI-Schnittstelle

Die Anwendungsf¨

alle werden im Kontext des f¨

ur die Produktarchitektur verwende-

ten Application Frameworks als Web-Service umgesetzt. Der Service muss drei Ar-

ten von Aufrufen unterscheiden: Das Stellen einer synchronen Anfrage mit direktem

R¨

uckgabewert, das Beauftragen einer asynchronen Anfrage und das R¨

uckmelden des

Ergebnisses. Die R¨

uckmeldung wird dabei vom angefragten Repository ausgel¨

ost und

kann im Web Service dem ausl¨

osenden lokalen Objekt zugeordnet und an dieses weiter-

gereicht werden.

Um f¨

ur Anfragen ¨

uber SQI zur Verf¨

ugung zu stehen, muss die Produktstandard-

architektur als SQI-Provider fungieren. Die dazu spezifizierten Methoden werden als

Web-Service aus dem Kontext des Application-Frameworks heraus ver¨

offentlicht.

48Eine asynchrone Beantwortung der Anfragen erfordert jedoch keine asynchrone Nachrich-

ten¨

ubermittlung auf der Infrastrukturebene.

161

4. Eine Rahmenarchitektur f¨

ur universit¨

ares E-Learning

Zur Implementierung des Sitzungsmanagements wird ¨

uber die Programmierschnittstelle

des Groupware-Frameworks auf dessen Authentifizierung zur¨

uckgegriffen. Mit der Er-

zeugung der Sitzung wird die Anmeldung des entfernten Benutzers vorgenommen und

bei Erfolg eine Sitzungs-ID zur¨

uckgegeben. Die Zerst¨

orung der Sitzung impliziert die Ab-

meldung vom System und das Trennen der Verbindung. Zur Sitzungsverwaltung kann

in der Regel auf Funktionen des Application-Frameworks zur¨

uckgegriffen werden.

Die Methoden zur Konfiguration der Anfragen (Query Parameter Configuration) be-

einflussen die lokale Suche im Object Repository. Zur Speicherung der Suchparameter

kann die Session genutzt werden. Nach Eingang der Anfrage wird diese in einen Aufruf

zur lokalen Suche transformiert. Das Ergebnis muss dann je nach gew¨

unschten Ergebnis-

format aufbereitet werden. Bei einer synchronen Anfrage wird es direkt zur¨

uckgegeben,

bei einer asynchronen muss f¨

ur die lokale Suche ein eigenst¨

andiger Thread gestartet

werden, der diese analog zur synchronen Anfrage durchf¨

uhrt und das Ergebnis an die

ubermittelte Adresse sendet.

4.2.7. Erweiterte Benutzungsschnittstellen

Wie Kapitel 2 bereits deutlich gemacht hat, sind die Anforderungen an universit¨

are

E-Learning-Umgebungen gestiegen. Benutzer fordern komfortable Benutzungsschnitt-

stellen, sie m¨

ochten mit mobilen Endger¨

aten auf die aktuellsten Informationen zugreifen

oder genau diese nach ihrem Login in ein hochschulweites Portal personalisiert und ag-

gregiert einsehen wollen.

Der folgende Abschnitt zeigt daher Erweiterungsm¨

oglichkeiten der Benutzungsschnitt-

stellen auf Basis der Produktarchitektur auf.

4.2.7.1. AJAX/Rich Client Applications

Rich Client Applications wurden schon auf S. 55 skizziert. Gemeint ist damit die client-

seitige Anreicherung von Benutzungsschnittstellen mit Javascript49. Haupts¨

achlich wird

Javascript auf Programme angewendet, die innerhalb des Browsers ausgef¨

uhrt werden.

Ist der Quelltext geladen und vollst¨

andig interpretiert, l¨

auft er innerhalb des Browsers in

einem so genannten ”Sandkasten“, von wo aus nicht auf Ressourcen außerhalb des Brow-

sers (z. B. lokale Dateien) zugegriffen werden darf. In Javascript programmierte Funk-

tionen und Objekte k¨

onnen also nur die mit der Webseite geladenen Inhalte ver¨

andern.

Uber ein spezielles Objekt (XMLHttpRequest Object) kann dann die eigentliche Kommu-

nikation mit dem Server vom Benutzer entkoppelt und beispielsweise als Reaktion auf

die ¨

Anderung eines Steuerelements durchgef¨

uhrt werden. Dazu muss dem Objekt ein

Event-Listener angeh¨

angt werden, der auf vom Server kommenden Status¨

anderungen

einen Event-Handler ansteuert. Die Aktualisierung der Pr¨

asentation kann dann ¨

uber

das Document Object Model (DOM)50 erfolgen.

49Eine objektbasierte Skriptsprache, die durch die European Computer Manufacturers Association in-

ternational als ECMAscript spezifiziert wurde (ECMA-262) und f¨

ur die alle modernen Browser eine

Laufzeitumgebung bereitstellen.

50DOM ist eine vom W3C spezifizierte Programmierschnittstelle f¨

ur den Zugriff auf HTML- und XML-

Dokumente, die im Sinne der Objektorientierung die einzelnen Elemente als Klassen definiert. Zur

Anderung von Attributen stehen Methoden bereit. So kann mittels Javascript sowohl Inhalt, Struktur

162

4.2. Eine Rahmenarchitektur f¨

ur verteilte Lern- und Arbeitsumgebungen

Der Server liefert die Daten – asynchron zu dem eigentlichen Laden der Webseite

– an den Klienten aus, was insgesamt zu einem Benutzungsverhalten f¨

uhrt, das sich

dem von Desktop-Anwendungen sehr ¨

ahnelt. Neben einem erh¨

ohten Benutzerkomfort

hat diese Technik auch den Vorteil, dass synchrone Komponenten wie bspw. ein Chat

oder Awareness-Meldungen in die sonst asynchronen Web-Klienten eingebaut werden

k¨

onnen. Dabei k¨

onnen AJAX-Frameworks wie ”Prototype“ verwendet werden51.

Application Framework

Programmierschnittstelle

CSCW-Content-Repository

«model»

Wissensraum-

metapher

«component»

Ajax-Bibliothek

«component»

Anwendungs-

komponente

«component»

Template

Engine

Browser

«view»

Template

«controller»

Steuerung

«view»

Browser

Window

«controller»

Controller

Code

«model»

Document Object

Model

importiert

CSCW

Content

Repository

Web Server

Javascript Interface

Abbildung 4.22.: Model-View-Controller-Konzept der AJAX-Schnittstelle

Von dem eigentlichen Anwendungsszenario abstrahiert soll die Rahmenarchitektur nun

um diese Elemente erweitert werden. Dabei wird die Zweiteilung der Produktarchi-

tektur in eine sowohl server- als auch clientseitige Behandlung der Anwendungs- und

Pr¨

asentationsschicht durch das MVC-Entwurfsmuster verdeutlicht (vgl. Abb. 4.22). Sei-

tens der Produktarchitektur wird das lokale Objektmodell durch eine Steuerungslogik

kontrolliert, die in Anwendungskomponenten definiert ist. Zur Ausgabeerstellung kann

eine Template-Engine52 verwendet werden, wobei die zu konstruierende Sicht durch eine

oder – geschachtelt – mehreren XHTML-Schablonen beschrieben wird. An dieser Stelle

wird auch der Javascript-Code eingebettet, der die eingesetzte Ajax-Bibliothek referen-

ziert. Das MVC-Pattern kann f¨

ur die clientseitige Ausf¨

uhrung sowohl auf die gesamte

Seite als Ganzes angewendet werden, jedoch auch separate Modelle und Controller f¨

einzelne Ausgabeelemente implementieren. Der um den Javascript-Code angereicherte

XHTML-Quelltext wird ¨

uber den Web-Server an den Browser ausgeliefert und dort aus-

gef¨

uhrt.

und Layout des ¨

ubertragenen Dokumentes dynamisch ver¨

andert werden.

51Diese Bibliothek ist am weitesten verbreitet und im Internet unter http://prototypejs.org zu finden.

Eine bekannte Effekt-Erweiterung zu Prototype ist ”Scriptaculous“, zu finden unter http://script.

aculo.us. Letzter Zugriff: 31.07.2008.

52So genannte Template Engines sind meistens fester Bestandteil von (Web-)Application Frameworks.

Sie verarbeitet Text-Dateien (Templates) und ersetzt die dort definierten Platzhalter durch (Inhalts-

)Daten.

163

4. Eine Rahmenarchitektur f¨

ur universit¨

ares E-Learning

4.2.7.2. Mobile Endger¨

ate

Grunds¨

atzlich kann Mobile Learning immer dann zum Einsatz kommen, wenn kein Per-

sonal Computer zur Verf¨

ugung steht, d. h. wenn andere Formen wie WBTs nicht zur

Verf¨

ugung stehen. Dies ist insbesondere in spontanen Situationen, zum Nachlesen oder

in kurzen Lernphasen der Fall, aber auch um die Aktualit¨

at der Informationen sicher-

zustellen. (vgl. [KS05b], S. 9).

Mobile Lernszenarien k¨

onnen dabei entweder als eigenst¨

andige Anwendung umgesetzt

werden, die auf dem Endger¨

at lauff¨

ahig sind (vgl. [Str07]). Diese Art der Anwendung

kann mit der hier skizzierten Produktarchitektur jedoch nicht umgesetzt werden und

wird an dieser Stelle daher nicht n¨

aher betrachtet. Eine andere M¨

oglichkeit liegt in der

Erweiterung der Benutzungsschnittstelle existierender web-basierter Anwendungen, die

auf der Produktstandardarchitektur aufsetzen. Letzteres eignet sich insbesondere dazu,

existierende Anwendungslogik und Informationen auf mobilen Endger¨

aten verf¨

ugbar zu

machen.

Im Folgenden wird die Rahmenarchitektur um eine entsprechende Schnittstelle erwei-

tert, die diese Funktion erf¨

ullt und einen mobilen Zugriff auf Lernr¨

aume und Inhalte

bietet. Dazu muss jedoch zun¨

achst die erweiterte Infrastruktur eines solchen Szenarien

analysiert werden, um daran Anforderungen abzuleiten.

Die in Deutschland angebotenen ¨

Ubertragungsdienste GSM, GPRS und UMTS unter-

scheiden sich vor allem im ¨

Ubertragungsverfahren und in der Geschwindigkeit. Der

paketorientierte Datendienst GPRS ist eine abw¨

artskompatible Erweiterung des ur-

spr¨

unglich auf konstante Datenraten ausgelegte GSM-Netzes und erreicht eine reale

Ubertragungsgeschwindigkeit von ungef¨

ahr 50 kbit/s. Zum Datenaustausch wird das

Internetprotokoll (IP) verwendet, weshalb jedes mobile Endger¨

at eine individuelle IP-

Adresse erh¨

alt.

Der wirkliche Nachfolger des GSM-Netzes ist das Universal Mobile Telecommunicati-

ons Systems (UMTS), das sich durch eine leistungsf¨

ahigere Funktechnik53 auszeichnet

und spezifizierte Daten¨

ubertragungsraten umsetzen kann, die von 144 kbit/s f¨

ur den

hochmobilen Nutzer54 und bis zu 2 Mbit/s f¨

ur den quasistation¨

aren Betrieb reichen.

Studien gehen jedoch davon aus, dass UMTS im Jahr 2010 erst eine Marktdurch-

dringung von 50 % erreicht hat. In Anbetracht der Multimodef¨

ahigkeit55 der UMTS-

Endger¨

ate sollten Benutzungsschnittstellen von mobilen Ger¨

aten kurz- bis mittelfristig

auf die ¨

Ubertragungstechnologie GPRS ausgerichtet sein. Das bedeutet f¨

ur eine konkrete

Implementierung, dass die Struktur der Anwendung f¨

ur eine Transaktionsgeschwindig-

keit von ungef¨

ahr 50 kbit/s konzipiert wird. ¨

Uberfl¨

ussige Interaktionen und ¨

uberladene

Inhalte sollten daher vermieden werden.

Unabh¨

angig von der ¨

Ubertragungstechnologie wird das Wireless Application Protocol

(WAP) ben¨

otigt, um Internetinhalte f¨

ur die langsameren ¨

Ubertragungsraten und f¨

53Im Einzelnen wird die h¨

ohere Leistungsf¨

ahigkeit durch eine gr¨

oßere Bandbreite und ein neueres

Ubertragungsverfahren (Wideband-CDMA) erreicht.

54Die maximale Geschwindigkeit der Empfangseinheit betr¨

agt 500 km/h.

55Die Ger¨

ate k¨

onnen f¨

ur Sprach- und Datenverbindungen auch das GSM-Netz nutzen.

164

4.2. Eine Rahmenarchitektur f¨

ur verteilte Lern- und Arbeitsumgebungen

die kleineren Displays verf¨

ugbar zu machen. Der Standard besteht aus einer Sammlung

von Protokollen. In den Versionen WAP 1.0 bis 1.2 verl¨

auft die ¨

Ubertragung nach dem

Client-Gateway-Server-Prinzip: Ein WAP-Gateway ¨

ubersetzt die Anfragen des Klienten

in HTTP und nimmt eine Verschl¨

usselungskonvertierung von WTLS nach SSL/HTTPS

vor. Dem Webserver der Anwendung wird jedoch ¨

uber den MIME-Type mitgeteilt, dass

es sich um eine Anfrage in WML handelt. Die R¨

uckantwort des Servers wird durch

das WAP-Gateway zur¨

uckkonvertiert und kompiliert an den Klienten ¨

ubertragen56. Ab

der Version WAP 2.0, die auf einem ge¨

anderten Protokoll-Stack basiert, wird die Web-

Anwendung direkt ¨

uber HTTP/HTTPS angesprochen und der Umweg ¨

uber einen WAP-

Gateway eingespart57.

WAP-Klient WAP-Gateway Produkt-

architektur

WAP

Benutzungs-

schnittstelle

WAP Protokoll

Stack

Enkodierer/

Dekodierer

Protokoll-

transformation

Web-Server

CGI / XHTML /

WML

WAP Request (URL) HTTP Request (URL)

HTTP Response

(WML)

WAP Response

(Binary WML)

HTTP Request (URL)

HTTP Response (XHTML)

WAP 2.0

Abbildung 4.23.: Client-Gateway-Server-Prinzip der Schnittstelle f¨

ur mobile Endger¨

ate

Auf der Serverseite unterscheidet sich WAP somit kaum von anderen Dokumententypen

im WWW. Um eine Schnittstelle f¨

ur mobile Endger¨

ate im Kontext der Rahmenarchitek-

tur anzubieten, wird daher lediglich ein Webserver ben¨

otigt, der abh¨

angig von der bevor-

zugten Protokoll-Variante WAP 1.x oder 2.0 entsprechende MIME-Types unterst¨

utzen

muss.

Zur Beschreibung der Inhalte wird aktuell die Extensible HyperText Markup-Language

(XHTML) verwendet58. Diese kann dynamisch zur Laufzeit der Anwendung analog zur

normalen browserbasierten Ausgabe erzeugt werden. Somit kann im g¨

unstigsten Fall

sogar auf eine eigene Anwendungsfallsteuerung (Controller) f¨

ur den mobilen Zugriff ver-

zichtet werden, wenn die Pr¨

asentation (View) in großen Teilen identisch bleiben soll.

Die Auswahl eines geeigneten XML-Templates kann dann durch den Controller anhand

56Die Seiteninhalte werden in das kompaktere Format WBXML (WAP binay XML) umgewandelt, um

die bestehende Bandbreite besser auszunutzen. Die ¨

Ubertragung verl¨

auft im MIME-Type WMLC

(Wireless Markup Language Compiled).

57Allerdings werden die Inhalte dadurch auch nicht mehr f¨

ur das Endger¨

at aufbereitet. F¨

ur den End-

benutzer bedeutet diese datenintensivere Internetnutzung auch einen Kostenanstieg. Mobilfunkbe-

treiber kommen dem aber mit entsprechenden Produkten wie Datenflatrates entgegen.

58Die Weiterentwicklung von HTML wurde nach der Version 4.01 zugunsten von XHTML eingestellt

und somit auch das auf HTML beruhende und f¨

ur den mobilen Zugriff optimierte Compact HTML

(cHTML). Im Zuge der Spezifizierung von WAP 2.0 wurde ebenfalls auf die auf XML beruhende

Wireless Markup Language (WML) zugunsten von XHTML verzichtet.

165

4. Eine Rahmenarchitektur f¨

ur universit¨

ares E-Learning

des HTTP-Headers HTTP_ACCEPT getroffen werden, der die vom Browser akzeptierten

MIME-Types beinhaltet. Weitere Header-Informationen – sollte eine feinere Differenzie-

rung n¨

otig sein – sind HTTP_USER_AGENT und X-WAP-PROFILE.

Die Auswertung des Accept-Headers ¨

ubernimmt in der Rahmenarchitektur die Klasse

”AcceptDispatcher“. Sie ermittelt den MIME-Type, den der anfragende WAP-Klient

verarbeiten kann. Mit Hilfe dieser Informationen bestimmt der ”TemplateDispatcher“

die passende XML-Schablone, die durch die Anwendungsfallsteuerung mit dynamischen

Daten gef¨

ullt und ¨

uber den Web-Server an das WAP-Gateway – bzw. im Fall von WAP

2.0 direkt an den Klienten – zur¨

uckgeschickt wird.

Application Framework

Programmierschnittstelle

CSCW-Content-Repository

«model»

Wissensraum-

metapher

«component»

Anwendungs-

komponente

«controller»

Steuerung

CSCW

Content

Repository

Web Server

Javascript Interface

«component»

Template Engine

«view»

XHTML:

Template

«view»

WML:

Template

«view»

cHtml:

Template

«component»

Accept-

Dispatcher

WAP Gateway

WAP Klient

HTTP Request

HTTP Response

WML/cHtml

HTTP Response

XHTML

WAP Request/Response

Abbildung 4.24.: Die Auswahl der Sicht erfolgt in der Anwendungssteuerung ¨

uber einen

Dispatcher, der den HTTP-Request analysiert und eine entsprechende

Schablone ausw¨

ahlt.

4.2.7.3. Hochschulportale

Im Mittelpunkt einer weiteren Ausbaustufe kann ein gemeinsames Portal von Fach-

bereichen, Bibliothek, Verwaltung und IT-Diensten stehen, das eine einheitliche, sys-

tem¨

ubergreifende Benutzungsschnittstelle f¨

ur determinierte Abl¨

aufe bietet (Pr¨

asenta-

tionsintegration, vgl. [A+07])59.”Ziel hinter dem Portal ist es, die in der Regel ge-

trennten, inneren Systeme nach außen hin zu vereinheitlichen, so dass dem Benutzer

ein einziger Zugang, das Portal, das gesamte Unternehmen, oder zumindest einen wohl

definierten Ausschnitt daraus, pr¨

asentiert wird“ [Mas05], S. 53. Ein Hochschulportal ist

dabei eine horizontale Anwendung, d. h. dass sich eine Portalintegration nicht vertikal an

den Funktionalbereichen orientiert, sondern horizontal entlang der Prozesse. Hochschul-

portale integrieren dabei typischerweise Inhalte und Funktionen verschiedener, zumeist

heterogener Applikationen der Universit¨

at.

59Zum Thema Hochschulportale siehe auch [DEH+02], S. 4, [Ker04b], [MJ05], S. 21, [AJ05], S. 31f.

166

4.2. Eine Rahmenarchitektur f¨

ur verteilte Lern- und Arbeitsumgebungen

Die Integration orientiert sich dabei an den verf¨

ugbaren Benutzungsschnittstellen der

einzubindenden Anwendungen: Client-Side Content Fetching ist dabei eine Technik der

URL-Integration, bei der im Portal nur die Quell-Adresse des Backend-Systems hinter-

legt ist und der Browser die Daten von diesem direkt abholt. Beim Server-Side Content

Fetching werden die Daten zun¨

achst vom Portal aus dem Backend-System geladen und

dann an den Browser weitergegeben60. Weiterhin kann eine Portalsoftware nat¨

urlich auf

die existierende Infrastruktur von Web-Services und Nachrichten-orientierter Middle-

ware zugreifen, um verteilte Dienste zu integrieren oder Transaktionen einzubinden.

Eine Pr¨

asentationsintegration verschiebt somit per se keine Anwendungsgrenzen und

muss daher nicht zwangsweise zu einer Kopplung f¨

uhren. Gerade aus diesem Grund

eignet sie sich f¨

ur Anwendungsf¨

alle, in denen mit mehreren Anwendungen parallel gear-

beitet werden muss, eine Integration auf Daten- oder Funktionsebene aber nicht m¨

oglich

oder nicht gewollt ist, bspw. aus sicherheitstechnischen oder datenschutzrechtlichen Gr¨

un-

den (vgl. [OWZ+05], S. 47).

Kirchhoff et al. unterteilen in [KGHV04] die Portalsoftware in zwei Bestandteile – den

Portal-Basisdiensten und den Portal-Anwendungen, den so genannten Portlets:

Portal-Basisdienste b¨

undeln eine Reihe ¨

ubergreifender Dienste wie Layout-Manage-

ment, Struktur- und Content-Management als auch Infrastrukturdienste zur Au-

thentifizierung, Rechte- und Nutzerverwaltung, Suche etc. Diese Dienste sind fest

im Portal verankert und in ihrer Auspr¨

agung sehr herstellerspezifisch. Sie sollen

daher in diesem Kontext nicht weiter betrachtet werden. Eine allgemeine Beschrei-

bung findet sich in [KGHV04].

Portlets erm¨

oglichen die Aggregation von Content sowie die Ausf¨

uhrung von Funktiona-

lit¨

at verschiedener Anwendungen in der Pr¨

asentationsschicht. ”Damit integrieren

Portlets gesch¨

aftsprozessspezifische Funktionalit¨

at und bieten dem Anwender einen

homogenen Zugang zu unterschiedlichen Datenquellen und Applikationen“ [Pus04],

S. 118. Sie realisieren also die betreiberspezifischen Anwendungsfunktionalit¨

aten

f¨

ur das Portal und sollen daher in die Rahmenarchitektur mit aufgenommen wer-

den.

Portlets werden aus einer allgemeinen Portal-Anwendungsklasse abgeleitet. Im Sinne

des objektorientierten Gedanken deklariert eine abstrakte Portal-Oberklasse eine Reihe

von Methoden und Eigenschaften, die von den Anwendungsklassen geerbt und zum Teil

definiert werden m¨

ussen.

Es existieren verschiedene Formen von Anwendungsklassen am Markt, wie z. B. Port-

lets, Webparts, Remote Portlets, I-Views, I-Lets oder Gadgets, die zum Teil herstel-

lerabh¨

angig und nicht kompatibel zueinander sind61. Ein Portlet muss daher eine be-

60Bei dieser Variante kann h¨

aufig ein Cache verwendet werden, so dass auch bei Nicht-Verf¨

ugbarkeit

des Backends Inhalte ausgeliefert werden k¨

onnen. Ohne den Einsatz von Cache-Mechanismen kann

Server-Side Content Fetching den Portalserver erheblich belasten, da in der Regel personalisierte

Sichten abgerufen werden m¨

ussen.

61Im Java-Umfeld sind Portlets nach dem JSR168-Standard weit verbreitet. Die in 2008 von Sun neu

definierte Spezifikation JSR286 (Portlet Specification 2.0) erlaubt als Weiterentwicklung von JSR168

167

4. Eine Rahmenarchitektur f¨

ur universit¨

ares E-Learning

Application Framework

Programmierschnittstelle

CSCW-Content-Repository

«subsystem»

Persistenz-

schicht

«component»

B:Anwendungs-

komponente

«controller»

b:Steuerung

CSCW

Content

Repository

SOAP Schnittstelle

«component»

A:Anwendungs-

komponente

«controller»

a:Steuerung

«component»

SOAP-Engine

SoapServer

«component»

Portalschnittstelle

«service»

C:Dienst

Portal

«component»

Basisdienste

«component»

Portalsoftware

«subsystem»

D:Portlet

«specification»

JSR/Webpart

Abbildung 4.25.: Zugriff eines Portlets ¨

uber die SOAP-Schnittstelle der Produktarchi-

tektur

stimmte Portal-API implementieren, um z. B. auf die Portal-Basisdienste wie Authenti-

fizierung, Caching, Content-Management etc. zugreifen zu k¨

onnen.

Die zu pr¨

asentierenden Daten aus der Anwendung werden vom Portlet ¨

uber eine

SOAP-Schnittstelle aus der Produktarchitektur ausgelesen. Der von der Produktarchi-

tektur dazu zur Verf¨

ugung zu stellende Dienst kann – abh¨

angig von den ben¨

otigten Daten

– von einer Anwendungskomponente (hier: A) direkt implementiert werden oder jedoch

durch eine eigenst¨

andige Portalschnittstelle (hier: C), die auf einer oder mehreren An-

wendungskomponenten (hier: B) basiert. Somit k¨

onnen sowohl einfache Basisdienste der

Architektur wie bspw. die bibliographische Katalogsuche ¨

uber die Z39.50-Schnittstelle

als Portlet verf¨

ugbar gemacht werden als auch gekoppelte Komplexdienste aus der An-

wendungsschicht der Produkte.

F¨

ur die Darstellung ist in der Regel das Portlet selbst zust¨

andig. Die Vielfalt der techni-

schen L¨

osungen reicht dabei von einzelnen JSP-basierten Portlets bis hin zu framework-

basierten L¨

osungen auf Basis von Struts62 und JavaServer Faces (JSF) im Java-Umfeld,

bzw. ASP.NET und den Sharepoint Services im Windows Umfeld.

4.3. Proaktive Wiederverwendung von Komponenten

Der statische Teil der Rahmenarchitektur wurde durch die Definition logischer Kom-

ponenten und der Beschreibung ihres Zusammenspiels im letzten Unterkapitel behan-

delt. Es wurde ein Rahmenwerk konzipiert und die dazugeh¨

origen Komponenten nach

durch die Inter-Portlet-Kommunikation eine auf einen Kontext besser abgestimmte Anwendungso-

berfl¨

ache. In der Microsoft-Welt (Sharepoint Services) werden standardm¨

aßig Webparts eingesetzt.

62Struts ist ein Open-Source-Framework, das sowohl f¨

ur die Anwendungssteuerung als auch f¨

ur die

Pr¨

asentationsschicht von Java-Webanwendungen verwendet werden kann. Informationen unter:

http://struts.apache.org. Letzter Zugriff: 31.07.2008.

168

4.3. Proaktive Wiederverwendung von Komponenten

Grad der Wiederverwendung in Produktstandard- und Produktarchitektur aufgeteilt.

Dadurch wurde der Rahmen f¨

ur eine einheitliche Plattform spezifiziert, die f¨

ur verschie-

denste Anwendungen in der Dom¨

ane des universit¨

aren E-Learnings eine geeignete Basis

darstellt.

Nach Dern beschreibt der komplement¨

are dynamische Teil einer Anwendungsarchi-

tektur, wie die einzelnen Komponenten auf Grundlage der statischen Sicht beschrieben,

erstellt und eingef¨

uhrt werden (vgl. [Der03], S. 18f.). Damit die Wiederverwendungspo-

tenziale der Produktstandardarchitektur zugunsten einer kosteng¨

unstigeren und weniger

fehlerbehafteten Anwendungsentwicklung realisiert werden k¨

onnen, sollte das Vorgehen

auch hier die Wiederverwendung von Komponenten gezielt unterst¨

utzen. Dabei hat sich

in der Praxis ein Produktlinien-orientiertes Vorgehen bew¨

ahrt, das in den folgenden

Abschnitten beschrieben wird.

4.3.1. Softwareproduktlinien

”A software product line is a set of software-intensive systems that share a common,

managed set of features satisfying the specific needs of a particular market segment or

mission and that are developed from a common set of core assets in a prescribed way.“

Diese Definition des Carnegie Mellon Software Engineering Institutes (SEI) impliziert

bereits das Ideal einer proaktiven Wiederverwendung bei der Entwicklung einer Soft-

wareproduktlinie (SPL). N¨

amlich die zielgerichtete Entwicklung mehrfach verwendbarer

Komponenten f¨

ur einen bestimmten Anwendungsbereich unter vorhersehbaren techni-

schen Rahmenbedingungen (vgl. hierzu auch [CE00], S. 21, [MA07], S. 180).

Dieses vorausschauende Vorgehen geht dabei ¨

uber die reine Wiederverwendung von

Komponenten aus fr¨

uheren Entwicklungen oder Entwicklung abstrakter generischer Kom-

ponenten hinaus63. Dazu ist der Entwicklungsprozess ganzheitlich ausgerichtet und um-

fasst sowohl technische als auch methodische, organisatorische und strategische Aspek-

te64. In Analogie zur softwaretechnischen Unterscheidung von Produktstandard- und

Produktarchitektur werden methodisch konzeptionell auch zwei Lebenszyklen unter-

schieden, n¨

amlich die Plattformentwicklung (Domain Engineering) f¨

ur den Bau wie-

derverwendbarer Artefakte, und die Produktentwicklung (Application Engineering) f¨

die Erstellung darauf basierender Anwendungen (vgl. [CE00], S. 19ff., [MA07], S. 181f.,

[Sch08], S. 111f.).

Im Folgenden werden diese beiden Phasen n¨

aher erl¨

autert. Die Untergliederung lehnt

sich an [CE00] an. Eine detaillierte Beschreibung der T¨

atigkeiten findet sich im Vor-

gehensmodell, dass im folgenden Kapitel 5 konzipiert wird und im Anhang S. 259ff.

beschrieben ist.

63Die reaktive Wiederverwendung wird auch als Baukasten-orientierte Softwareentwicklung bezeichnet.

Der Schwerpunkt liegt dabei bei der Anwendungsentwicklung (vgl. [MA07]).

64Im Detail sind dies (1) die strategische Ausrichtung der Produktlinie an die Ziele der Organisation,

(2) das systematische Managen von Varianten respektive Systemunterschieden bei der Komponen-

tenentwicklung, (3) die Implementierung einer Produktstandardarchitektur als gemeinsame Basis

und (4) die konzeptionelle Trennung zwischen der Entwicklung wiederverwendbarer Komponenten

und der von Produkten (vgl. [Sch08], S. 110f.).

169

4. Eine Rahmenarchitektur f¨

ur universit¨

ares E-Learning

4.3.2. Separate Plattform- und Produktentwicklung

Der grunds¨

atzliche Aufbau bei beiden Phasen ist identisch: Analyse, Entwurf, Imple-

mentierung und Test, mit jeweils entsprechenden Entwicklungs-Ergebnissen f¨

ur Platt-

form oder Produkt. In der Plattformentwicklung liegt der Fokus auf der Umsetzung der

Standardarchitektur f¨

ur die Produktfamilie mitsamt ihren wiederverwendbaren Arte-

fakten65. Die Produktentwicklung umfasst die Erstellung konkreter Applikationen aus

der Plattform mit dem Ziel, einen hohen Wiederverwendungsgrad zu erreichen. Wie

in Abbildung 4.26 zu sehen ist, sind beide Prozesse miteinander eng verzahnt. Jede

Produktentwicklung bedeutet einen neuen Zyklus zur Weiterentwicklung der Plattform.

Die Zwischenergebnisse der Plattformentwicklung wie Spezifikation, Entwurf und Im-

plementierung der Standardkomponenten fließen in den jeweils korrespondierenden Ab-

schnitt der Produktentwicklung mit ein. Dieser ist durch eine Feedbackschleife wieder

r¨

uckgekoppelt, was eine iterativ-evolution¨

are Prozesssteuerung beg¨

unstigt.

Die konzeptionelle Ausrichtung der beiden Phasen ist jedoch unterschiedlich. W¨

ahrend

bei der Plattformentwicklung die Struktur und die Auswahlregeln f¨

ur die Komponenten

der Plattform konzipiert und verwaltet werden m¨

ussen, um die Variabilit¨

at innerhalb des

Produktraums zu beherrschen, sind bei der Produktentwicklung die notwendigen Stan-

dardkomponenten zu konfigurieren und gegebenenfalls mit zus¨

atzlichen Anwendungs-

komponenten zu erweitern.

Der ¨

Ubergang von einer Einzelsystemsicht hin zu einer integrierten Entwicklung einer

Systemfamilie r¨

uckt demnach die Gemeinsamkeiten und Unterschiede in den Produkt-

varianten in den Mittelpunkt, was das so genannte Variantenmanagement notwendig

macht (vgl. [Sch08], S. 112, [Beu05]). Entscheidend ist dabei der ¨

Uberblick dar¨

uber,

âwelche Anforderungen f¨

ur alle Systeme gelten (Gemeinsamkeiten),

âwelche Anforderungen nur f¨

ur einen Teil der zu entwickelnden Systeme gelten, aber

nicht f¨

ur alle relevant sind (Variabilit¨

aten) und

âwelche Anforderungen nur f¨

ur bestimmte Produkte relevant sind (produktspezfische

Anforderungen).

Ziel der Dom¨

anenanalyse (Scoping) als Teil der Plattformentwicklung ist es, diesen

Uberblick herzustellen. Dabei wird der Produktraum von einer ¨

ubergeordneten Strategie

– in diesem Fall bspw. die hochschulweite E-Learning- und IT-Strategie – abgeleitet und

im Sinne eines Portfolios pr¨

azisiert. Aus der Strategie k¨

onnen wesentliche Anforderungen

an die Produktlinie abgeleitet und im Rahmen von weiteren Analysen erg¨

anzt werden.

Diese Anforderungen k¨

onnen in Form textueller Beschreibungen verfasst werden. Hierzu

bietet sich die in Kapitel 4 vorgestellte normsprachliche Modellierung an. Die Ergebnis-

se der Dom¨

anen-Analyse sind eine Produktraumbeschreibung, ein Dom¨

anenlexikon und

Konzeptmodelle.

”Domain Engineering is the activity of collecting, organizing and storing past experiences in building

systems or parts of systems in a particular domain in the form of reusable assets (i.e., reusable

work products), as well as providing an adequate means for reusing these assets (i.e., retrieval,

qualification, dissemination, adoption, assembly, and so on) when building new systems“ [CE00],

S. 20.

170

4.3. Proaktive Wiederverwendung von Komponenten

PlattformentwicklungProduktentwicklung

Domänenanalyse

Produktraum-

spezifikation

Produktanalyse

Produkt-

spezifikation

Plattformentwurf

Plattform-

architektur

Produktentwurf

Produkt-

architektur

Plattform-

implementierung

Plattform-

komponenten

Produkt-

implementierung

Produkt-

komponenten

Plattformtest

Plattformtests

Produkttest

Produkttests

Prozess Ergebnis

Legende

ist Basis für ist Ergebnis von Iteration

Abbildung 4.26.: Zwei separate Iterationszyklen: Die Entwicklung der Produktstandard-

plattform und die Produktentwicklung.

Wechselseitig mit der Dom¨

anenanalyse wird in der Produktanalyse das traditionelle Re-

quirements Engineering66 weiter ausgedehnt, um die Variabilit¨

aten zu analysieren und

zu dokumentieren67. Das Ergebnis dieser beiden Prozesse in der ersten Iteration sind so

genannte Featuremodelle zur Modellierung von Variationspunkten und Varianten (vgl.

Abb. 4.27), die immer weiter verfeinert werden k¨

onnen. Sie bilden die Entscheidungs-

grundlage bei der Fragestellung, welche Komponenten der Plattform wiederverwendet

werden k¨

onnen, welche angepasst, neu hinzugef¨

ugt oder individuell f¨

ur ein Produkt neu

entwickelt werden m¨

ussen. Dar¨

uber hinaus unterst¨

utzen Featuremodelle in folgenden

Iterationen eine werkzeuggest¨

utzte Anforderungserhebung und Komponentenauswahl

(vgl. [CE00], S. 38ff., [Beu05], S. 75ff.).

Die Entscheidungen, welche Requirements-Artefakte SPL-spezifisch und welche pro-

duktspezifisch sind, beeinflussen in einem n¨

achsten Schritt ”Entwurf“ die Produktarchi-

tektur und das produkt¨

ubergreifende Architekturdesign der Plattform. Hier werden die

Anforderungen mit technischen L¨

osungen verkn¨

upft. Bei diesem Schritt kann die in die-

sem Kapitel konzipierte Rahmenarchitektur als Orientierung f¨

ur ein Architekturdesign

verwendet werden.

66Also das Finden und Verstehen von Anforderungen, die Anforderungsanalyse und -dokumentation,

sowie die Verifizierung und das Management derselben.

67Weiss und Lai schlagen dazu [WL99] weitere Analysen vor: (1) die Commonality Analysis zur Ana-

lyse der gemeinsamen Anforderungen aller Systeme der Produktlinie, (2) die Variability Analysis

zur Analyse von Anforderungen, die sich in den Systemen der Produktlinie unterscheiden und (3)

das Variability Modelling zur Modellierung von Variationspunkten, m¨

oglichen Varianten und ihren

Beziehungen.

171

4. Eine Rahmenarchitektur f¨

ur universit¨

ares E-Learning

Authenti-

fizierung

LDAP

Datenbank

Shibboleth

Benutzer-

profil

Gruppen

semi-strukturiert

stark vorstrukturiert

selbstorganisiert

Anmelde-

verfahren

freier Zutritt

administriert

Passwortgeschützt

Bewerbeverfahren

requires_v_vp

Forum

moderiert

unmoderiert

Abbildung 4.27.: Featuremodell mit notwendigen, optionalen, alternativen und exklusi-

ven Varianten (Ausschnitt).

Der Schritt ”Implementierung“ bedeutet f¨

ur die Plattformentwicklung die Umsetzung

oder Erweiterung von Standardkomponenten, die gemeinsame oder variable Features rea-

lisieren. Im Gegensatz dazu besteht ein großer Teil der Produktimplementierung darin,

einen Verbund von Standardkomponenten zusammenzustellen und diese anwendungsspe-

zifische Konfiguration um individuelle Komponenten zu erweitern. Das Ergebnis beider

Phasen ist eine funktionierende, erweiterte Produktplattform mit anwendungsspezifi-

schen Komponenten, die gemeinsam das neue Produkt zur Realisierung der erhobenen

Anforderungen implementieren.

In einem letzten Schritt wird zum einen das Zusammenspiel neuer Standardkompo-

nenten mit den bisherigen Standardkomponenten der Produktplattform getestet (”Platt-

formtest“), zum anderen die Integration der anwendungsspezifischen Komponenten mit

der Produktplattform (”Produkttest“).

4.3.3. Anwendbarkeit des Produktlinien-orientierten Vorgehens

In der Praxis hat sich gezeigt, dass im universit¨

atsweiten Kontext eine genaue Vorab-

Spezifizierung des Produktraums ohne eine zentrale Koordination nur schwer m¨

oglich

ist68. Auch wenn eine E-Learning-Strategie vorhanden ist, umfasst sie aus software-

technischer Sicht oftmals nur die hochschulweite Einf¨

uhrung und den Betrieb einer

68Diese Erkenntnis spiegelt die Erfahrung der Autors dieser Thesis aus der mehrj¨

ahrigen Mitarbeit in

universit¨

atsinternen und -¨

ubergreifenden Projekten und Arbeitskreisen zur Infrastrukturentwicklung

an Hochschulen wider.

172

4.3. Proaktive Wiederverwendung von Komponenten

oder mehrerer (monolithischer) Lernplattformen69. Komponentenbasierte Individualent-

wicklungen im Kontext einer dienstorientierten Infrastruktur finden zwar an amerikani-

schen Universit¨

aten mit der Open Knowledge Initiative70 immer mehr Verbreitung. Im

deutschsprachigen Raum hat sich dieses Vorgehen jedoch noch nicht durchgesetzt71. Al-

lerdings sind in den letzten Jahren an einigen Universit¨

aten zentrale Dienstleistungszen-

tren im Bereich ”Neue Medien“ eingerichtet worden, die neben der Beratung, Schulung

und Betrieb von Lernplattformen auch Software-Anpassung und -Entwicklung anbieten.

Weiterhin existieren an vielen Universit¨

aten bereits Foren und Arbeitskreise zum Thema

E-Learning. Oftmals engagieren sich auch dort Dozenten, die sich schon Ende der 90er

Jahre im Rahmen der BMBF-gef¨

orderten Projekte mit der Anwendungsentwicklung im

Bereich der computerunterst¨

utzten Lehre auseinander gesetzt haben. Auf diesen Erfah-

rungen aufbauend kann – koordiniert durch eine zentrale Stelle wie ein Dienstleistungs-

zentrum, ein Arbeitskreis oder ein initiales Pilotprojekt – eine Produktraumspezifikation

vorgenommen und mit der E-Learning-Strategie der Universit¨

at abgestimmt werden.

Aufgrund der hohen Initialkosten, die bereits vor Fertigstellung der ersten Anwendung

anfallen und somit schwer auf alle zu entwickelnden Produkte aufzuteilen sind, bedeutet

das aus der Softwareindustrie stammende Produktlinien-orientierte Vorgehen im univer-

sit¨

aren Kontext sicherlich eine H¨

urde. Schon bei der Entwicklung des ersten Produktes

ist eine stabile und wiederverwendbare Produktstandardarchitektur zu realisieren.

Dem muss man jedoch entgegenhalten, dass gerade an einer Universit¨

at wie nirgendwo

anders die M¨

oglichkeit besteht, wiederverwendbare Komponenten der Standardarchi-

tektur im Rahmen der Lehre und Forschung proaktiv und kosteng¨

unstig zu entwerfen,

zu implementieren und zu testen. Das dazu notwendige Softwaredesign kann sich an

der in dieser Arbeit spezifizierten Rahmenarchitektur orientieren. Der Erfahrung nach

eignen sich zur Umsetzung der Komponenten insbesondere Projektseminare und Ab-

schlussarbeiten (Bachelor-, Master- u. Diplomarbeiten). Notwendig ist dazu jedoch ein

standardisiertes Vorgehen, wie es im n¨

achsten Kapitel mit der Instanzierung eines Refe-

renzmodells f¨

ur Qualit¨

atsmanagement und Qualit¨

atssicherung bei der Entwicklung von

Bildungsangeboten erarbeitet wird.

69Strategie ”Verwendung von Standardsoftware“, siehe dazu S. 114. Weitere m¨

ogliche Inhalte einer E-

Learning-Strategie sind in Kapitel 2 als organisatorische und technische Maßnahmen aufgef¨

uhrt

(S. 25ff.).

70Informationen unter http://www.okiproject.org/, siehe auch S. 46. Letzter Zugriff: 31.07.2008.

71Es gibt jedoch Vorreiter, die fr¨

uh auf eine service-orientierte Architektur gesetzt haben und auf dieser

Basis auch Eigenentwicklungen umsetzen, bspw. das Karlsruher Integrierte InformationsManage-

ment (KIM, http://www.kim.uni-karlsruhe.de/). Viele Universit¨

aten befinden sich derzeit aber in

Abwartehaltung.

173

4. Eine Rahmenarchitektur f¨

ur universit¨

ares E-Learning

174

5. Entwicklungsmethodik

komponentenbasierter

Lernumgebungen

In diesem Kapitel wird als drittes Gestaltungsziel dieser Arbeit eine Methode entwi-

ckelt, die als Grundlage f¨

ur die normsprachliche Spezifizierung (Kapitel 4) und kom-

ponentenorientierte Umsetzung (Kapitel 5) universit¨

arer Lern- und Arbeitsumgebungen

herangezogen werden kann. Zun¨

achst werden die Konzepte von Methoden und Vorge-

hensmodellen erl¨

autert und voneinander abgegrenzt. Auf dieser Basis wird eine Ent-

scheidungshilfe zur Auswahl einer Prozesssteuerung f¨

ur die Softwareentwicklung von

E-Learning-Werkzeugen im universit¨

aren Kontext erarbeitet (6.1). Anschließend wer-

den verschiedene Referenzmodelle zur Entwicklung von E-Learning-Komponenten vor-

gestellt, um eine f¨

ur den Kontext dieser Arbeit passende Prozessarchitektur auszuw¨

ahlen

(6.2). Auf Basis der Prozessarchitektur des Referenzmodells f¨

ur Qualit¨

atsmanagement

und -sicherung bei der Planung, Entwicklung und Durchf¨

uhrung von Bildungsangeboten

(DIN PAS 1032-1:2004) wird eine Anpassung an das im letzten Abschnitt vorgestellte

Produktlinien-orientierte Vorgehen vorgenommen. Die Anwendung des Referenzmodells

auf die spezifischen Aspekte der Entwicklung von Lern- und Arbeitsumgebungen im

universit¨

aren Kontext basiert dabei auf den eigenen mehrj¨

ahrigen Erfahrungen des Au-

tors aus Verbundprojekten und Arbeitsgruppen im Bereich Neuer Medien in der Bildung,

insbesondere E-Learning, sowie aus Projekten zur IT-Infrastrukturentwicklung an Hoch-

schulen.

5.1. Grundlagen der methodischen Entwicklung

5.1.1. Begriffsdefinition einer Methode

Die Entwicklung von Informationssystemen (und ihren Bestandteilen) bedingt ein in-

genieurm¨

aßiges Vorgehen, damit es planbar und wiederholbar ist. Bereits seit den 80er

Jahren befasst sich die Wissenschaft daher mit dem Methoden-Engineering als rechner-

gest¨

utzten, methodischen Entwurf sowie zur rechnergest¨

utzten, kontrollierten Ausf¨

uhrung

von Methoden. Mittlerweile hat es einen hohen Stellenwert in der angewandten Infor-

matikforschung (vgl. [Gut94], S. 11).

Das Konzept der Methode bzw. das Verst¨

andnis, welches hinter dem Begriff der Me-

thode in der Forschung zu Informationssystemen und ihrer Entwicklung steht, unterliegt

in der Literatur unterschiedlichen Auffassungen und Definitionen. Der klassischen De-

finition aus dem Griechischen folgend, ist eine Methode ”der Weg zu etwas“. In den

175

5. Entwicklungsmethodik komponentenbasierter Lernumgebungen

verschiedenen Definitionen von Nonnemacher, Haberfellner1und Lorenz2steht insbe-

sondere die Planm¨

aßigkeit, die einen systematischen Ansatz erkennen l¨

asst, sowie der

Zweckbezug im Vordergrund. Stahlknecht und Hasenkamp propagieren dar¨

uber hinaus

in ihrer Definition die Verwendung von Prinzipien3.

Braun et al. haben unterschiedliche Methodendefinitionen daraufhin untersucht, in-

wieweit verschiedene Merkmale zu erkennen sind. Sie sind dabei zu dem Schluss gekom-

men, dass in der Literatur insbesondere die folgenden Merkmale im Vordergrund stehen

(vgl. [BWHW05], S. 1296f.):

Zielorientierung Methoden sind zielorientiert. Sie vereinbaren Regeln, wie vorzugehen

ist, um definierte Ziele zu erreichen und/oder Probleme zu l¨

osen.

Verfolgung eines systematischen Ansatzes Wenn Methoden Regeln und Instruktionen

vorgeben, wie Ziele erreicht und Probleme gel¨

ost werden k¨

onnen, dann m¨

ussen sie

auch eine systematische Struktur besitzen. Dies ist n¨

otig, um spezifische Arbeits-

schritte und Aufgaben zur Zielerreichung abzuleiten4.

Einsatz von Prinzipien Methoden sowie Methodenspezifikationen k¨

onnen eng mit Design-

Prinzipien, wie z. B. generellen Konstruktionsrichtlinien und/oder -strategien ver-

bunden sein. Ein Beispiel ist das Prinzip der Objektorientierung. Ein Prinzip ist

dabei allgemein g¨

ultig, abstrakt und bildet die theoretische Grundlage, die einer

Handlung zugrunde gelegt werden kann (vgl. [Bal01], S. 36).

Wiederholbarkeit Methoden, insbesondere in der Software-Entwicklung, sollten

nicht nur einmalig in einem bestimmten Kontext nutzbar sein und werden deshalb

relativ offen gestaltet. Einige Autoren motivieren in ihren Definitionen zus¨

atzlich,

dass Methoden kontext¨

ubergreifend wiederholbar sein sollten5.

In diesem Kapitel werden die Bestandteile einer Methode nach dem Methoden-Enginee-

ring dargestellt. Grundlage daf¨

ur bilden die Ausf¨

uhrungen von Gutzwiller (vgl. [Gut94]),

nach dem eine Methode durch die Konzepte Entwurfsaktivit¨

at, Rolle, Technik, Entwurfs-

ergebnis und Metamodell beschrieben wird. Diese konzeptionelle Methodenbeschrei-

bung dient als Darstellungsrahmen. Kernpunkt der weiteren Ausf¨

uhrungen wird als

Erweiterung der Methodenkonzepte die Vorgehensmodellierung sein, dessen Elemente

im n¨

achsten Abschnitt erkl¨

art werden.

1Nonnemacher gibt in Anlehung an Haberfellner (vgl. hierzu [Hab80], S. 1701) eine relativ knappe

Definition des Methodenbegriffs, die vielmehr einer kurzen Erkl¨

arung gleicht. Dort heißt es, dass

”eine Methode [. . . ] allgemein eine in der Art des Vorgehens festgelegte Arbeitsweise“ beschreibt

(vgl. [Non94]).

2Nach Lorenz ist eine Methode, ”ein nach Mittel und Zweck planm¨

aßiges (=methodisches) Verfahren“

[Lor95], S. 876.

”Vorschriften, wie planm¨

aßig nach einem bestimmten Prinzip (oder einer Kombination von Prinzipien)

zur Erreichung festgelegter Ziele vorzugehen ist“ (vgl. [SH99], S. 234).

4Dies ist insbesondere vielen Methoden zur Entwicklung von Informationssystemen zu Eigen, die auf

ein ingenieurm¨

aßiges Vorgehen setzen, um eine gewisse Plan- und Wiederholbarkeit zu gew¨

ahrleisten

(vgl. [Gre03], S. 955).

5Balzert spricht in [Bal01] in diesem Zusammenhang von der Anwendungsneutralit¨

at von methodischen

Vorgehensweisen.

176

5.1. Grundlagen der methodischen Entwicklung

5.1.2. Bestandteile eines methodischen Vorgehens

Grob und Seufert beschreiben in [GS96] ein Vorgehensmodell als ein ”[. . . ] ablauforga-

nisatorisches Konzept der Software-Entwicklung [. . . ], bei dem ein komplexer Prozess in

klar definierte, ¨

uberschaubare Einheiten gegliedert wird. Durch Vorgehensmodelle wird

Handlungswissen f¨

ur die Erstellung von Software in Form von Prinzipien, Methoden

und Werkzeugen zur Verf¨

ugung gestellt. Aus diesem allgemein g¨

ultigen Wissen soll ein

Softwareentwicklungsprozess f¨

ur konkrete Anwendungen abgeleitet werden“.

Prozess-

steuerung

Prozess-

architektur

Konfigurations-

management

Aktivität

RolleTechnik

Ergebnis

Version

untergeordnet

übergeordnet

0..n

Vorgänger

übergeordnet

0..n

1..n

0..n

nimmt wahr

0..n

wird verwendet in

1..n

wird verwendet von >

< erzeugt

1..n

definierter Stand

1..n

0..n

erstellt

untergeordnet

übergeordnet

0..n

System-

konfiguration

1..n

Phase Inkrement

0..1 0..n

Metamodell

1..n

Sicht auf

Abbildung 5.1.: Konzepte eines methodischen Vorgehens

Vorgehensmodelle beschreiben prim¨

ar die Prozessarchitektur und -steuerung, beantwor-

ten also die Fragen, wann eine Aktivit¨

at durchgef¨

uhrt und was f¨

ur ein Entwurfsergebnis

erstellt wird. Dar¨

uber hinaus k¨

onnen sie Konzepte des Konfigurationsmanagements im-

plizieren, die im Wesentlichen auf der Versionierung von Ergebnissen und deren Zuord-

nung zu einer Systemkonfiguration basieren. Demnach beschreiben Vorgehensmodelle

das Vorgehen im Großen, bieten jedoch oftmals keine konkreten Handlungsanweisungen

f¨

ur die konkrete Umsetzung. Die Betrachtungsweise einer Methode geht ¨

uber das Vorge-

hensmodell hinaus und erweitert dieses um die fehlenden Aspekte. Nach dem Methoden-

Engineering ist eine Methode damit die Erweiterung eines Vorgehensmodells um Rollen,

Techniken und dem Metamodell. Eine Methode dient w¨

ahrend eines gesamten Projek-

tes als roter Faden und gibt zus¨

atzlich konkrete Handlungsmuster vor. Dadurch wird

es einfacher, komplexen Anforderungen zu gen¨

ugen und diese in einem standardisierten

Prozess zu erf¨

ullen.

177

5. Entwicklungsmethodik komponentenbasierter Lernumgebungen

Da diese Elemente von Vorgehensmodellen und Methoden grundlegend sind f¨

ur die in

diesem Kapitel durchzuf¨

uhrende Methodenkonzeption, sollen sie an dieser Stelle kurz

erl¨

autert werden:

Prozessarchitektur Eine Prozessarchitektur gibt einen groben ¨

Uberblick ¨

uber die Pha-

sen des Entwicklungsprozesses sowie der zugeh¨

origen Aktivit¨

aten (vgl. [NS99],

S. 171).

Phase Eine Phase ist eine Kategorisierung des Fortschrittszustands einer Entwicklung

anhand der Erreichung von Meilensteinen, welche die Phasen voneinander abgren-

zen. Abh¨

angig davon sind einer Phase die zur Erreichung des Meilensteins notwen-

digen Aktivit¨

aten und Ergebnisse zugeordnet.

Inkrement In risikogetriebenen Vorgehensmodellen wird der Entwicklungsprozess als

iterativ aufgefasst. Dabei ist eine zyklische Wiederholung der einzelnen Phasen

vorgesehen, die jeweils eine Menge an Anforderungen realisiert. Jeder Zyklus be-

schreibt dabei ein Inkrement, f¨

ur das die Risiken separat abgesch¨

atzt, reduziert

und evaluiert werden k¨

onnen.

Prozesssteuerung Das Prinzip, das dem Vorgehensmodell zur Definition der Ablaufrei-

henfolge zugrunde liegt (vgl. [NS99], S. 175, sowie [Dow87]). Dieses kann je nach

Zielsetzung des Softwareentwicklungsprozesses variieren und klassifiziert die Zu-

geh¨

origkeit eines Vorgehensmodells zu einer der im n¨

achsten Abschnitt vorgestell-

ten Familien von Vorgehensmodellen.

Aktivit¨

at Unter einer Aktivit¨

at wird eine Verrichtungseinheit verstanden, die ein oder

mehrere definierte Ergebnisse erzeugt. Eine Aktivit¨

at kann in Subaktivit¨

aten bis

hin zu elementaren, nicht weiter teilbaren Arbeitsschritten6zerlegt werden. ”In

diesem Zusammenhang wird von einer Aktivit¨

aten-Struktur, -Hierarchie oder -

Dekomposition gesprochen“ [Gut94], S. 13. Diese Entwurfsaktivit¨

aten sind aggre-

gierte Aktivit¨

aten und werden danach klassifiziert, ob sie iterativ oder nicht itera-

tiv durchf¨

uhrbar sind. Manche Aktivit¨

aten sind beliebig oft wiederholbar. Hierzu

z¨

ahlen z. B. Testprozesse oder Verifikationen von Funktionalit¨

at. Elementare Ak-

tivit¨

aten lasen sich nicht weiter unterteilen und liefern bei der Ausf¨

uhrung immer

das gleiche Ergebnis.

Rollen Rollen repr¨

asentieren in diesem Kontext die Aufgabe zur Ausf¨

uhrung bestimm-

ter Aktivit¨

aten, die durch Einzelpersonen oder Gruppen ¨

ubernommen werden.

Eine Rolle ist also – bezogen auf den Aufgabentr¨

ager bzw. Rolleninhaber – als

Zusammenfassung spezifischer Aktivit¨

aten zu sehen. Bsp.: Nutzer, Architekt, Pro-

grammierer, Support (vgl. [KLT98], S. 21).

6In der Literatur oft verwendete Begriffe f¨

ur elementare Arbeitsschritte sind auch task oder workstep.

178

5.1. Grundlagen der methodischen Entwicklung

Techniken und Werkzeuge Techniken stellen Anleitungen oder Handlungsanweisungen

bereit, wie Einzelergebnisse und/oder logisch zusammenh¨

angende Gruppenergeb-

nisse innerhalb von Aktivit¨

aten erzielt werden k¨

onnen. Unter einem Werkzeug ist

eine Software zu verstehen, die zur Planung und Generierung des Informations-

systems verwendet wird (vgl. [FBML98], S. 17ff.). Eine Einteilung kann dabei in

Werkzeuge f¨

ur das Objekt- und Prozessmanagement sowie in Werkzeuge f¨

ur die

Softwareentwicklung erfolgen (vgl. [CG98], S. 219).

Ergebnisse Ergebnisse7werden durch die Aktivit¨

aten entweder erzeugt oder verwen-

det/modifiziert und bilden somit eine ”Input-Output“-Beziehung zwischen den

verschiedenen Aktivit¨

aten. Ein Entwurfsergebnis ist hierarchisch strukturiert und

kann wiederum in seine Bestandteile zerlegt werden. Eine Beschreibungsstruktur

legt fest, wie ein Ergebnis dokumentiert wird. Logisch zusammengeh¨

orende Er-

gebnisse k¨

onnen aggregiert und unter einem Bezeichner angesprochen werden. Ein

Ergebnis kann z. B. ein Netzplan der Systemarchitektur oder ein Regelwerk einer

Firewall sein. Die Gesamtheit aller Ergebnisse eines Vorgehensmodells kann auch

als Dokumentationsmodell verstanden werden (vgl. [Gut94], S. 14).

Version Eine Version ist ein urspr¨

ungliches Ergebnis oder eine Ver¨

anderung respektive

Weiterentwicklung eines Ergebnisses. Die Anzahl erforderlicher Versionen eines

Ergebnisses in einem Softwareentwicklungsprozess erh¨

oht sich beispielsweise dann,

wenn mehrere Entwickler ein Ergebnis bearbeiten oder im Entwicklungsprozess

bereits abgearbeitete T¨

atigkeiten erneut durchgef¨

uhrt werden m¨

ussen. Dies kann

bspw. im Fehlerfall oder bei ge¨

anderten Systembedingungen vorkommen.

Systemkonfiguration Eine Systemkonfiguration fasst die aktuellen Versionen von Er-

gebnissen an einem bestimmten Zeitpunkt der Entwicklung zusammen (vgl. [BK02],

S. 6). Jede neue Version eines Ergebnisses f¨

uhrt zu einer neuen Systemkonfigura-

tion.

Metamodell Das Metamodell bringt die Entwurfsergebnisse auf konzeptioneller Ebene

in Beziehung. ”Es stellt die atomatisierten Bestandteile aller Entwurfsergebnisse in

der Form eines Datenmodells [. . . ] ¨

ubersichtlich dar“ [Gut94], S. 14. Jedes Ergebnis

hat dabei seine eigenen Attribute oder Auspr¨

agungen. Die Komponenten eines

Metamodells, ihre Beziehungen zueinander und ihre Attribute k¨

onnen durch ein

Entity-Relationship-Modell (ERM) abgebildet werden (vgl. [Gut94], S. 24).

Diese Komponenten von Vorgehensmodellen werden in Abb. 5.1 in einem Ordnungssche-

ma noch einmal graphisch miteinander in Verbindung gesetzt.

Anhand des Grades der Detaillierung, also ihrer Abstraktion bzw. Spezialisierung,

lassen sich die Modelle des Softwareentwicklungsprozesses unterscheiden (vgl. [Bre98],

[FBML98]): W¨

ahrend Vorgehensstrategien auf einer sehr abstrakten Ebene nur Beschrei-

bungen zur Entwicklungsphilosophie, den Software-Werkzeugen und der Projektorgani-

7Bei Braun et al. lautet dieser Eintrag specification document; f¨

ur die Darstellung in dieser Arbeit

wurde er in den Eintrag Entwurfsergebnisse abgewandelt, da sich Braun et al. in [BWHW05] auf

[Gut94] beziehen und dieser den hier verwendeten Begriff benutzt.

179

5. Entwicklungsmethodik komponentenbasierter Lernumgebungen

sation enthalten, also keine konkreten Arbeitsabl¨

aufe definieren, liefern Vorgehensmo-

delle auf dieser Basis das dazugeh¨

orende Muster zur Beschreibung des Entwicklungs-

prozesses. Vorgehensmodelle sind also Instanzen, die von einer oder mehrerer Vorge-

hensstrategien abgeleitet wurden. Auf dieser Ebene lassen sich Modelle einordnen, die

nur f¨

ur spezifische Projekttypen verwendet werden k¨

onnen8. Ebenso wie diejenigen, die

allgemein g¨

ultig sind, also generisch verwendet werden k¨

onnen. Werden die in einem

Vorgehensmodell generisch verwendete Komponenten (also Rollen, Ablauf, Werkzeuge)

f¨

ur ein reales Projekt festgelegt, ist dies ein so genanntes Projektmodell.

5.1.3. Entwicklungsschemata von Vorgehensmodellen

Da in der Praxis unterschiedliche Zielsetzungen bei Softwareentwicklungsprojekten exis-

tieren, sind aus dem Softwareengineering die verschiedensten Vorgehensmodelle hervor-

gegangen, die auf bestimmte Ziele hin optimiert wurden. Abh¨

angig von ihrer Prozess-

steuerung – aktivit¨

ats-, ergebnis-, oder entscheidungsorientiert – k¨

onnen drei Familien

von Vorgehensmodellen unterschieden werden (vgl. [BK02], S. 3ff., auch [Dow87]):

1. Phasen-, Wasserfall- und Schleifenmodelle,

2. prototypische Vorgehensmodelle und die

3. inkrementellen, evolution¨

aren, rekursiven und iterativen Verbesserungsmodelle.

Analyse

Systementwurf

Implementierung

Integration

Einführung

Betrieb

Prototyp-Entwicklung

Legende:

Aktivität

Entwicklungsverlauf

Rückschritte

Abbildung 5.2.: Prozessarchitektur phasenorientierter Vorgehensmodelle (in Anlehnung

an [BK02], S. 7).

8Man spricht hierbei auch von Entwurfsobjektbindung (vgl. [Fil05], S. 13).

180

5.1. Grundlagen der methodischen Entwicklung

Phasen-, Wasserfall- und Schleifenmodelle Das Phasenmodell wurde 1956 erstmals

ver¨

offentlicht. Hierbei wird der Softwareentwicklungsprozess in bestimmte Phasen auf-

geteilt, denen Aktivit¨

aten zugeordnet sind.

In der ersten Phase – der Analysephase – werden die Anforderungen an das System

m¨

oglichst umfassend ermittelt und dokumentiert. Das Ziel dieser Phase ist ein gemeinsa-

mes und genaues Verst¨

andnis aller am Entwicklungsprozess beteiligten Rollen hinsicht-

lich des gew¨

unschten Systems. Auf Basis dieser Anforderungen wird in der Entwurfs-

phase eine IT-Architektur entworfen, welche die Anforderungen auf ein realisierbares

Softwaresystem abbildet. Dies beinhaltet bspw. den Entwurf der Benutzungsoberfl¨

ache,

die Datenmodellierung und den Funktionsentwurf, sowie den Entwurf der Klassen, Me-

thoden und Objektstrukturen. Das Ergebnis der Entwurfsphase ist der Systementwurf

als Abschlussdokument, der einzelne Komponenten des Systems identifiziert und doku-

mentiert. In der Implementierungsphase wird dieser Systementwurf durch eine Program-

miersprache in lauff¨

ahige Komponenten umgesetzt und getestet. Die Zusammensetzung

der Komponenten zu einem lauff¨

ahigen Gesamtsystem folgt in der Integrationsphase. In

der Einf¨

uhrungsphase wird das integrierte Gesamtsystem dann in die Informationsar-

chitektur des Auftraggebers ¨

ubertragen. W¨

ahrend des Systembetriebs erfolgt die Auf-

rechterhaltung der Systemfunktionen durch Fehlerbehebung, sowie die Anpassung des

Systems an sich ¨

andernde Kundenw¨

unsche und Umgebungsbedingungen.

Diese Phasen bauen konsequent aufeinander auf und werden sequenziell abgearbeitet

(vgl. Abb. 5.2). Am Ende jeder Phase kann ein fertig gestelltes Ergebnis (bspw. Anforde-

rungskatalog, Systementwurf, lauff¨

ahiges System) eine Qualit¨

atssicherung durchlaufen.

Im Phasenmodell ist ein R¨

ucksprung zu bereits abgeschlossenen Phasen, wie er unter

bestimmten Bedingungen vorkommen kann, wie z. B. im Fall von fehlerhaften Ergeb-

nissen aus fr¨

uheren Phasen, nicht abgebildet. Im Gegensatz dazu erlaubt die Fami-

lie der Wasserfallmodelle eine begrenzte r¨

uckw¨

arts gerichtete Iteration. Ob dabei ein

R¨

ucksprung nur zu der direkt vorhergehenden oder zu fr¨

uheren Phasen erlaubt ist, wird

durch die konkrete Auspr¨

agung eines bestimmten Vorgehensmodells dieser Familie defi-

niert (vgl. [BK02], S. 5).

Prototypische Vorgehensmodelle Vorgehensmodelle dieser Familie erlauben, wie auch

Wasserfall- oder Schleifenmodelle, wiederholte Durchl¨

aufe bereits abgearbeiteter Pha-

sen. Diese begr¨

unden sich entweder durch R¨

uckschritte aus anderen Phasen aufgrund

von Fehlern o. ¨

a. oder durch Prototypen, die zu verschiedenen Zeitpunkten als fester

Bestandteil im Entwicklungsprozess vorgesehen sind (vgl. [GS96]):

Explorative Prototypen dienen der ¨

Uberpr¨

ufung unklarer oder schwieriger Teile der

Anforderungen, die bereits im fr¨

uhen Entwicklungsstadium stattfinden kann. Sie

unterst¨

utzen die Kommunikation zwischen Anwendern und Entwicklern. Somit

k¨

onnen die Anforderungen auf Basis der mit dem Prototypen gesammelten Erfah-

rungen angepasst und neu entwickelt werden.

Experimentelle Prototypen k¨

onnen zur ¨

Uberpr¨

ufung unklarer oder schwieriger Design-

aspekte herangezogen werden, wie z. B. der ¨

Uberpr¨

ufung der gew¨

ahlten Architek-

tur hinsichtlich der Anforderungen an die Performance.

181

5. Entwicklungsmethodik komponentenbasierter Lernumgebungen

Evolution¨

are Prototypen erweitern und verbessern ein anf¨

angliches Testsystem konti-

nuierlich. Diese Form des Prototyping steht im Widerspruch zu der Prozesssteue-

rung der phasenorientierten Modelle und geh¨

ort somit eher der Familie evoluti-

on¨

arer Modelle an (s. n¨

achster Abschnitt).

Sowohl die Analyse- als auch die Designprototypen sollten m¨

oglichst schnell und kos-

teng¨

unstig umgesetzt werden k¨

onnen: F¨

ur die Analyse kann auch eine einfache Notati-

on verwendet werden, die eine Ausf¨

uhrung der dokumentierten Anforderungen erlaubt

(vgl. [BK02], S. 8). Oberfl¨

achen k¨

onnen auf dem Papier skizziert und f¨

ur Designpro-

totypen k¨

onnen auch existierende Softwaresysteme aus ¨

ahnlichen Projekten unter Ver-

nachl¨

assigung softwaretechnischer Standards angepasst und verwendet werden.

Inkrementelle, evolution¨

are, rekursive und iterative Verbesserungsmodelle Basili

und Turner stellten 1975 das iterative Verbesserungsmodell vor, welches sich im Ver-

gleich zu den bisher vorgestellten Modellen einer anderen Prozessarchitektur bedient:

Das eindimensionale phasenorientierte Vorgehen wird durch das Konzept der Inkremen-

te abgel¨

ost. Ein Inkrement wird dabei definiert als eine Teilmenge von Anforderungen,

die durch Aktivit¨

aten in den Bereichen Analyse, Entwurf, Implementierung, Integrati-

on, Installierung und Einsatz in sequenzieller Ordnung erstellt werden. Ein Inkrement

besteht somit aus allen Ergebnissen f¨

ur die durch ihn definierte Teilmenge der Sys-

temanforderungen. Also aus einem lauff¨

ahigen installierten System, das aber u. U. noch

nicht alle Anforderungen abdeckt. In Iterationsschritten werden dann immer weitere

Anforderungen umgesetzt, womit Folgeinkremente Erweiterungen bereits bestehender

Inkremente darstellen und die lauff¨

ahige erste Systemkonfiguration immer weiter aus-

bauen. Dieser Prozess endet erst, wenn alle Anforderungen erf¨

ullt sind und sich auch

keine neuen mehr ergeben durch ge¨

anderte Anforderungen oder ver¨

anderte Systembe-

dingungen9. Der Entwicklungsprozess wird hierbei also in mehreren Entwicklungszyklen

geplant, die jeweils gleiche Phasen durchlaufen. Zwar liegt diesem Modell ebenfalls ein

Top-down-Ansatz zugrunde, die zunehmende Konkretisierung geht dabei jedoch nicht

von Phasen, sondern von Entwicklungszyklen aus.

Bei den evolution¨

aren Modellen wird der Softwareentwicklungsprozess als risikogetrie-

ben angesehen. Hier findet nach jeder Iteration eine Verifikation der Entwicklungsziele

und eine Verifikation der Entwicklungsergebnisse statt. Diese Analyse bildet dann die

Entscheidungsgrundlage zur Auswahl der Anforderungen f¨

ur das n¨

achste Inkrement.

Rekursive Vorgehensmodelle verwenden dar¨

uber hinaus das Konzept der Rekursion f¨

ihren Systembegriff, der damit auch Teilsysteme und deren Teilsysteme usw. umfasst.

9Unter Umst¨

anden also erst, wenn das System deinstalliert wird.

182

5.1. Grundlagen der methodischen Entwicklung

Inkrement 3

Inkrement 2

Inkrement 1

Analyse

Systementwurf

Implementierung

Integration

Einführung

Betrieb

Analyse

Systementwurf

Implementierung

Integration

Einführung

Betrieb

Analyse

Systementwurf

Implementierung

Integration

Einführung

Betrieb

Anforderungen

Priorität 1

Anforderungen

Priorität 2

Anforderungen

Priorität 3

für jedes

Inkrement

ein Durch-

lauf

Abbildung 5.3.: Schrittweise Umsetzung von Anforderungen in inkrementellen Vorge-

hensmodellen (eigene Darstellung).

5.1.4. Entscheidungshilfe zur Auswahl der Prozesssteuerung f¨

ur die

Softwareentwicklung im universit¨

aren Kontext

Ein Entwicklungsprozess von Softwarekomponenten zur Unterst¨

utzung virtueller Lern-

und Arbeitsszenarien ist innerhalb einer Universit¨

at oftmals mit einem festen Termin

zur Einf¨

uhrung verbunden, n¨

amlich mit dem Beginn eines neuen Semesters. Bis dann

muss das neue System im Regelfall getestet und lauff¨

ahig in der universit¨

aren Informa-

tionsarchitektur integriert sein.

F¨

ur solche termingebundene Softwareentwicklungsprozesse eignen sich inkrementelle,

evolution¨

are Vorgehensmodelle grunds¨

atzlich eher als phasenorientierte, bei denen es

erst sehr sp¨

at im Projektverlauf zu einem ausf¨

uhrbaren Ergebnis kommt: Wenn sich die

Anforderungen priorisieren lassen, k¨

onnen die Wichtigsten in den ersten Inkrementen

zusammengefasst werden, in den Folgenden die weniger wichtigen. Somit wird ein Schei-

tern des Projektes verhindert, selbst wenn der Zeitplan nicht eingehalten werden kann:

Die wichtigsten Anforderungen sind durch die ersten lauff¨

ahigen Inkremente bereits um-

gesetzt, getestet und installiert, womit auch zus¨

atzlich das Risiko einer Fehlentwicklung

gemindert wird.

Da in phasenorientierten Modellen die Implementierung auf einen vollst¨

andigen Ent-

wurf aufsetzt, kann bei Termin¨

uberschreitung eines Meilensteins der Auslieferungstermin

der Software nicht unbedingt durch ein solches Weglassen von Teilfunktionalit¨

aten gesi-

183

5. Entwicklungsmethodik komponentenbasierter Lernumgebungen

chert werden10. Auch bedingt die Notwendigkeit eines vollst¨

andigen Entwurfes ein sehr

gutes Verst¨

andnis des zu entwickelnden Softwaresystems seitens der Architekten/Pro-

grammierer, weiterhin eine grundlegende Beschreibbarkeit der Anforderungen und ihre

Stabilit¨

at, denn Weiterentwicklungen und ¨

Anderungen sind – anders als in inkrementel-

len Vorgehensmodellen – nicht als nat¨

urlicher Bestandteil der Softwareentwicklung im

Modell vorgesehen.

Ein weiterer Vorteil von inkrementellen Vorgehensmodellen sind die M¨

oglichkeiten,

die im Projekt gesammelten Erfahrungen im gleichen Projekt weiter zu nutzen. Hier

wiederholen sich die durchzuf¨

uhrenden Aktivit¨

aten f¨

ur jedes Inkrement, so dass neu

Gelerntes im folgenden Inkrement direkt zur Anwendung kommen kann. In geringerem

Maße bieten zwar auch Prototypen oder außerplanm¨

aßige R¨

uckspr¨

unge im Projekt bei

phasenorientierten Modellen diese M¨

oglichkeiten. Zumindest Letzteres geht jedoch zu

Lasten der Projektlaufzeit.

Dies l¨

asst auch weitere Schl¨

usse auf die Kompetenzprofile einiger im Vorgehensmodell

definierter Rollen zu: Phasenorientierte Modelle sollten aus diesem Grund bei einem

festen Termin zur Fertigstellung nur von einem Team eingesetzt werden, das bereits viel

Erfahrung mit ihren Werkzeugen und Methoden in vorhergehenden Projekten gemacht

hat.

Aus softwaretechnischer Sicht bieten die phasenorientierten Modelle allerdings auch

Vorteile: Die Implementierung basiert auf einem abgeschlossenen Entwurf, der die voll-

st¨

andigen Anforderungen enth¨

alt. Somit k¨

onnen Komponenten besser identifiziert, pa-

rallel entwickelt und integriert werden. Die Schnittstellenbeschreibungen zwischen den

Komponenten erfolgen in diesen Vorgehensmodellen zur gleichen Zeit und sind damit

per se aufeinander abgestimmt. Der Komplexit¨

atsgrad einer Integration verschiedener

Inkremente h¨

angt im Gegensatz dazu allerdings davon ab, wie gut die Anforderungen

partitionierbar waren11, zum anderen von der Erweiterbarkeit der zugrunde liegenden

Systemarchitektur. Inkrementelle Modelle beg¨

unstigen diesbzgl. allenfalls das Testen

der Schnittstellen, da hier nicht alles zur gleichen Zeit integriert und getestet wird.

Außerdem werden die wichtigsten Systemschnittstellen h¨

aufig als erstes umgesetzt und

dadurch auch am h¨

aufigsten getestet.

Auch der Aufwand f¨

ur das Versions- und Konfigurationsmanagement ist bei inkremen-

tellen Vorgehensmodellen h¨

oher, da hier die Anzahl an Konfigurationen und Versionen

bedeutend gr¨

oßer ist als bei den anderen Vorgehensmodellen: Zu jedem Inkrement exis-

tiert mindestens eine Konfiguration, die alle dazugeh¨

orenden Versionen der Ergebnisse

enth¨

alt. Jede neue Version eines Ergebnisses f¨

uhrt gleichzeitig zu einer neuen Konfigura-

tion. In phasenorientierten Modellen ist die Anzahl der Versionen (und somit auch der

Konfigurationen) eher klein, denn sie entstehen nur dann, wenn einmal abgearbeitete

T¨

atigkeiten erneut durchgef¨

uhrt werden, also planm¨

aßig nur bei Prototypen oder außer-

planm¨

aßigen R¨

uckschritten. Im besten Fall liegt eine Version pro Ergebnis vor und eine

Konfiguration f¨

ur das lauff¨

ahige und installierte Gesamtsystem.

10Zwar wird in prototypischen Vorgehensmodellen ein ausf¨

uhrbarer Prototyp von den Endbenutzern

leicht als Endsystem erkennt, dieser sollte aber keinesfalls so eingesetzt werden.

11D. h., wie viele Anh¨

angigkeiten zwischen den verschiedenen Teilmengen der Anforderungen existieren.

184

5.2. Referenzmodelle zur Entwicklung von E-Learning-Komponenten

5.2. Referenzmodelle zur Entwicklung von

E-Learning-Komponenten

Vorgehensmodelle in der Dom¨

ane des computergest¨

utzten Lernens haben – je nach Cha-

rakteristika des Endproduktes (z. B. Lerninhalt als virtuelles Modul, Lernwerkzeug, ab-

geschlossene Lernumgebung oder gar ein ganzer virtueller Studiengang) – unterschied-

liche Aktivit¨

aten, Techniken und (Zwischen-) Ergebnisse zum Inhalt. Unabh¨

angig der

vorgenommen Klassifizierung von Modellen hinsichtlich ihrer Prozesssteuerung k¨

onnen

in diesem Anwendungskontext daher neben den eher technisch orientierten Modellen des

Softwareentwicklungsprozesses auch Vorgehensmodellen mit didaktischer Schwerpunkt-

setzung respektive hybride Modelle unterschieden werden (vgl. [Blu98], S. 153f, [Ker01],

S. 325 und [Paw01], S. 79). Letztere gewichten die technischen und didaktischen Aspekte

gleichermaßen12.

Im Folgenden sollen bekannte Referenz- und Vorgehensmodelle zur Entwicklung von

E-Learning-Komponenten erl¨

autert und gegen¨

ubergestellt werden, um ein passendes

Vorgehensmodell f¨

ur die Softwareentwicklung im universit¨

aren Kontext zu identifizieren.

Davon soll eine Prozessstruktur abgeleitet und um die Besonderheiten der normsprach-

lichen Spezifizierung und der Produktlinien-orientierten Umsetzung sowie um Rollen,

Techniken und ein Metamodell erg¨

anzt werden.

5.2.1. Didaktisch-orientierte Modelle

Die Strukturierung des Entwicklungsprozesses in didaktisch orientierte Vorgehensmodel-

le zur Entwicklung von Lernumgebungen geht zur¨

uck auf die Anwendung des generischen

systemic approach13 auf Bildungssysteme in den f¨

unfziger Jahren (vgl. [Iss97], S. 201).

Daraus entstand eine Vielzahl von pr¨

askriptiven Vorgehensmodellen, die zur Errei-

chung definierter Lehrziele den gesamten Prozess – von der Analyse und Konzeption

von Lernsystemen bis hin zur Umsetzung und Einsatz – abbilden14. Zwar unterschei-

den sie sich prim¨

ar durch einen individuellen Grad der Detaillierung, Linearisierung und

Interaktivit¨

at (vgl. [Blu98], S. 150) – so gibt es ziel- und inhaltsspezifische Modelle f¨

12Einen anderen Ansatz zur Kategorisierung von Vorgehensmodellen zur Entwicklung von Bildungs-

angeboten mit E-Learning-Komponenten w¨

ahlt Hambach in [Ham05a]. F¨

ur ihr dreistufiges Schema

betrachtet sie zus¨

atzlich Modelle der Designtheorie f¨

ur die Gestaltung von Produkten (Produktde-

sign), Medien (Mediendesign) und Kommunikation (Kommunikationsdesign). Allerdings merkt sie

an, dass einerseits nur wenige Belege f¨

ur Vorgehensmodelle in den verschiedenen Teildisziplinen des

Designs ermittelt werden konnten (S. 56), und andererseits ihr Ansatz zur Kategorisierung f¨

ur die

praktische Einordnung von Vorgehensmodellen anhand der Literatur zu feingliedrig ist. Aus diesem

Grund werden in dieser Arbeit die Modelle der Designtheorie außer Acht gelassen.

13Der systemic approach bzw. das general systems design beschreibt ein heuristisches Verfahren zur

Entwicklung von Systemen, welches auf verschiedene Problembereiche angewandt werden kann, wie

z. B. zur Softwareentwicklung, Organisationsentwicklung oder zum Management. Es besteht aus den

Schritten Analyse, Planung, Entwicklung sowie Evaluation und Revision (vgl. [Iss97], S. 200).

14F¨

ur diese Modelle haben sich in der Literatur unterschiedliche Begriffe etabliert: models of instruc-

tional design,Instructional Systems Development (IDD), Instructional Design and Development

(IDD), Instructional Systems Design (ISD), Instructional Systems Technology (IST), oder im Deut-

schen auch systematisches Instruktionsdesign (ID).

185

5. Entwicklungsmethodik komponentenbasierter Lernumgebungen

Bedarf an

Instruktion

ermitteln

Strategie u.

Methodik

auswählen

Inhalte

auswählen u.

organisieren

Operative

Lehrziele

definieren

Instruktion

entwerfen u.

entwickeln

Evaluieren

Instruktion

einsetzen

Abbildung 5.4.: Evolution¨

ares Prozessmodell des Instructional System Design

Lehrpl¨

ane und Schulkonzepte, Unterrichtseinheiten oder konkrete Lehr-/Lernprozesse15

– ihnen zugrunde liegt aber der gleiche, durch behavioristische und kognitivistische Lern-

paradigmen gepr¨

agte Modellansatz: Auf Basis operativ definierter Lehrziele (also dem

gew¨

unschten Ergebnis) und einer Instruktionssituation wird unter Zuhilfenahme eines

probabilistischen Regelsystems16 eine optimale Medienwahl abgeleitet und eine entspre-

chend optimierte Medienproduktion vorgeschlagen. Aktuelle Modelle des Instructional

Designs sind diesbzgl. komplexer. Sie leiten dar¨

uber hinaus auch eine Lehrstrategie bzw.

eine Spezifikation von Lehrzielen ab (vgl. [Ker01], S. 331).

Viele ID-Modelle sehen umfangreiche Evaluationsaktivit¨

aten w¨

ahrend und nach dem

Prozessdurchlauf vor (vgl. Abbildung 5.4), deren Ergebnisse R¨

uckkopplungen mit be-

reits abgeschlossenen Phasen oder Aktivit¨

aten begr¨

unden k¨

onnen17. Um schon zu einem

fr¨

uhen Zeitpunkt Schw¨

achen erkennen und beheben zu k¨

onnen, ist bereits der Entwurf

der Instruktionsmaterialien mit Personen der Zielgruppe zu pr¨

ufen. Neben dieser forma-

tiven Evaluation untersucht eine summative Evaluation nach Durchf¨

uhrung der Instruk-

tion die relative und absolute Qualit¨

at der Bildungsmaßnahme. Weiterf¨

uhrende Ans¨

atze

betrachten die Evaluation systematisch als durchgehende Aktivit¨

at f¨

ur alle Phasen und

nutzen diese als Mechanismus zur Steuerung und Kontrolle des gesamten Projektes (vgl.

Tabelle 5.1).

Die generelle Kritik am Objektivismus und Instruktionalismus wurde in dieser Arbeit

bereits im Kontext der lerntheoretischen und kognitionspsychologischen Grundlagen the-

matisiert (S. 82). Diese Kritik greift auch beim Instruktionsdesign. In den Regelwerken

wird n¨

amlich davon ausgegangen, dass das Ergebnis von Instruktion f¨

ur alle Lernenden

15Flechsig und Haller beschreiben in [FH77] diese einzelnen Anwendungsbereiche der Didaktik anhand

eines Modells von f¨

unf Ebenen.

16Die Methoden des ID sind nicht deterministisch, sondern bieten auf Basis empirischer Erkenntnisse

wahrscheinliche Beziehungen zwischen Wenn-Dann-Komponenten an.

17Somit ist die Prozesssteuerung von Modellen des Instruktionsdesigns als evolution¨

ar zu klassifizieren.

186

5.2. Referenzmodelle zur Entwicklung von E-Learning-Komponenten

im Wesentlichen gleich ist (deterministische Orientierung, vgl. [Blu98], S. 151f., [Ker01],

S. 132). Das bedeutet, dass eine objektiv wahrnehmbare Realit¨

at bzw. objektives Wis-

sen außerhalb des individuellen Lernens nicht anerkannt wird. Neuere ID-Modelle wur-

den jedoch bereits durch konstruktivistisch gepr¨

agte Lerntheorien beeinflusst, in denen

darstellend erkl¨

arende Lehrstrategien (Anleitung und Expertenwissen) mit einem aktiv-

explorierenden Lernen und Reflexionsphasen verschr¨

ankt werden (bspw. cognitive ap-

prenticeship, siehe S. 84). Von radikalen Vertretern des Konstruktivismus werden diese

Modelle trotzdem kaum akzeptiert (vgl. [Sch97b], S. 88ff.).

Analyse Design Produktion Implementation

Bed¨

urfnisse und Be-

darf erfassen,

Lehrziele und Leh-

rinhalte,

Programmierung,

Dokumentation,

Management der

Bildungsmaßnahme,

Merkmale des Ler-

ners analysieren,

Lernerfolgskontrolle,

Tr¨

agermedium,

Planung der Distri-

bution

Durchf¨

uhrung

Rahmenbedingun-

gen und allgemeine

Ziele feststellen

Managementstrate-

gie

Evalutation der

Machbarkeit

Formative Evaluati-

Summative Evalua-

tion

Evaluation der Im-

plementation

Tabelle 5.1.: Elemente g¨

angiger ISD-Modelle (aus [Ker01], S. 331).

5.2.2. Vorgehensmodelle f¨

ur die Web-Entwicklung

Im Laufe der letzten Jahre wurden viele Methoden zur Entwicklung Web-basierter Syste-

me konzipiert. Dabei wurde Methoden in Anlehnung an traditionelle Modellierungstech-

niken wie beispielsweise dem ER-Diagramm (ERM) oder der Object Modelling Technique

(OMT) entwickelt, oder aber auf Basis der St¨

arken existierender Methoden weiterent-

wickelt (vgl. [SK03], S. 70).

Der Fokus der meisten Methoden zur Web-Entwicklung konzentriert sich vorrangig auf

den Entwurf- und Implementierungsteil der Anwendung, weshalb sie nicht didaktisch,

sondern eher softwaretechnisch orientiert sind. Ebenfalls ist vielen von ihnen die Tren-

nung von Aspekten des Datenmodells, der Navigation, der Benutzungsschnittstelle und

der Pr¨

asentation gemein. Trotzdem lassen sich – abh¨

angig von Abstammung und Fo-

kus – Methoden mit hypertext-, daten- oder objektorientierten Paradigmen voneinander

unterscheiden.

5.2.2.1. Hypertext-orientierte Methoden

Im Gegensatz zu den CBTs und WBTs liegen in Hypermedia-Systemen die Inhalte

nicht ausschließlich linear, sondern insbesondere vernetzt vor. Somit kann ein Top-down-

Vorgehen die Entwicklung dieser Systeme nicht sehr effizient unterst¨

utzen. Es werden

daher andere Vorgehensmodelle ben¨

otigt, die auf die spezifischen Entwicklungsebenen

von Hypermedia-Systemen eingehen.

187

5. Entwicklungsmethodik komponentenbasierter Lernumgebungen

Nach [Sch92] sind dies (vgl. [GS96])18:

Generative Ebene Erstellung und Verwaltung der Text- und multimedialen Dokumente.

Die Pr¨

asentation des Lehrstoffs kann Texte, Tabellen, Grafiken, Bilder, Animatio-

nen, Audio- und Videosequenzen sowie weitere Software umfassen, die Multiple-

Choice, Simulationen, etc. implementieren k¨

onnen.

Formale Ebene Erstellung der Verkn¨

upfungen zwischen den Texteinheiten, um aus dem

linearen Text den netzwerkartigen Hypertext zu gestalten. Durch eine Aufgliede-

rung der Lehrstoffinhalte in logische Einheiten werden die Knoten (nodes) des

Hypertextes geschaffen, die mit Hilfe von Verweisen untereinander in Beziehungen

gebracht werden19.

Multimediale Ebene Erweiterung des Hypertexts um multimediale Objekte zu Hyper-

media. Dabei werden die Objekte als selbstst¨

andige Module oder als Teile beste-

hender Hypertextknoten in das Netz integriert.

Diese Entwicklungsebenen wurden von Vorgehensmodellen adressiert, die insbesondere

in den 1990er Jahren konzipiert wurden, also in der Zeit, in der Hypermedia-Systeme

eine große Verbreitung fanden. Ein strukturierter Hypermedia-Entwurf umfasst insbe-

sondere das logische Grundger¨

ust zur semantischen Vernetzung von Inhalten. Objekte

einer fachlichen Dom¨

ane werden dazu auf Komponenten aufgeteilt, die wiederum mit

so genannten Einheiten assoziiert werden k¨

onnen. Einheiten kapseln verschiedene In-

formationsdarstellungen20. Durch die freien Verweise zwischen Objekte, Komponenten

und Einheiten entsteht ein Hypergraph, auf den dann ¨

uber verschiedene Navigationss-

trukturen wie Men¨

us oder Indizes zugegriffen werden kann. Eine konkrete Anwendung

wird darauf basierend ¨

uber die Instanzierung des Hypergraphen und der Erstellung

einer Browsing Semantic erstellt. Auf diesem Weg k¨

onnen verschiedene Hypermedia-

Anwendungen auf Basis desselben Hypergraphs erstellt werden.

Als erstes Modell f¨

ur einen strukturierten Hypermedia-Entwurf bildete das Hyper-

text Design Model (HDM, vgl. [GPS93])21 eine fr¨

uhe Basis auch f¨

ur datenorientierte

Methoden. Im Rahmen der Entwicklung von Hypermedia-Systemen wurde HDM unter

verschiedenen Aspekten wie bspw. Automatisierung weiterentwickelt, wodurch die neuen

Methoden W2000 und HDM-Lite entstanden.

Ein neueres Hypertext-orientiertes Vorgehen, das nicht auf HDM basiert, ist die Web

Site Design Method (WSDM22), die an der Vrije Universiteit Brussel zwischen 1998 und

18Eine ganz ¨

ahnliche Sicht auf die Ebenen des Entwicklungsprozesses wird in [B+96] beschrieben: 1.

Entwurf des logischen Grundger¨

usts durch die Modellierung von Schemata, 2. Entwurf der Nutzung

durch die Spezifikation von Inhalten, konkreter Zugriffsstrukturen und Navigationsunterst¨

utzung

sowie 3. Entwurf der Pr¨

asentation durch die Bestimmung des Layouts eines Hypermedia-Systems.

19Hierbei k¨

onnen neben strukturbeschreibenden und bedeutungsabh¨

angigen auch benutzerorientierte

Beziehungen unterschieden werden, welche vom Benutzer selbst erzeugt werden k¨

onnen (vgl. [GS96]).

20Die Aufteilung auf Komponenten beschreiben also strukturelle, die Assoziation mit Einheiten per-

spektivische Verweise.

21Eine Verbesserung des Modells lag mit HDM2 vor, welches zus¨

atzlich Navigationsmuster wie Guided

Tours, Men¨

us oder Indizes umfasst.

22Informationen sind auf den Seiten der VU Br¨

ussel unter http://wise.vub.ac.be bei Prof. De Troye

und Sven Casteleyn zu finden. Letzter Zugriff: 31.07.2008.

188

5.2. Referenzmodelle zur Entwicklung von E-Learning-Komponenten

2003 entwickelt wurde. Die Entwicklungsgrundlage bildet bei dieser Methode der Ent-

wurf eines Aufgabenmodells, in dessen Verbindung ein Dom¨

anenmodell mit entworfen

wird23. Aus beiden Modellen wird dann das Navigationsmodell entwickelt. Aspekte der

Pr¨

asentation werden hierbei nicht behandelt.

5.2.2.2. Datenorientierte Methoden

Im Fokus datenorientierter Methoden liegt die Modellierung von datenbankgetriebe-

nen Web-Anwendungen. Dabei werden die Konzepte des Hypergraphen mithilfe von

Entity-Relationship-Modellen (ERM) abgebildet und um dom¨

anenspezifische Fachkon-

zepte erweitert. Beispiele f¨

ur datenorientierte Methoden sind die Web Modeling Language

(WebML24) und die Relationship Management Methodology (RMM, vgl. [ISB95]).

WebML ist ein sehr reichhaltiges Modell, das eine deutliche Pr¨

aferenz auf die Model-

lierung der Dom¨

anenstruktur und davon abgeleitet der Navigation der Web-Anwendung

hat. Eine darauf basierende Abbildung auf verschiedene Sichten erfolgt ¨

uber die Adap-

tion eines Rollenmodells.

Im Gegensatz zu WebML ist die RMM eine Weiterentwicklung des Hypertext Design

Models. Da dieses ein Vorgehen nur implizit modelliert, definiert die Relationship Mana-

gement Methodology – neben der Erweiterung um ein relationales Datenmodell – sechs

Entwurfsphasen25 und eine Implementierungsphase.

5.2.2.3. Objektorientierte Methoden

Ebenso wie das RMM konkretisiert das Object Oriented Hypertext Model (OOHDM,

vgl. [RSLC95] und [SPM99]) das Hypertext Design Model im Sinne eines Vorgehensmo-

dells. Der Fokus liegt hierbei jedoch in der Unterst¨

utzung eines objektorientierten An-

satzes. Die Ziele des Designs sind in der Hauptsache die Unabh¨

angigkeit der einzelnen

Phasen, sowie die methodeninvariante Wiederverwendung von Hypermedia-Elementen

und den Entwurf ohne Ber¨

ucksichtigung der sp¨

ateren Implementierung. Die vier Phasen

des OOHDM sind weiter gefasst als die der RMM. Sie umfassen die Dom¨

anenanalyse,

das Navigationsdesign, ein abstraktes Interface-Design und die Implementierung.

Erweiterungen des OOHDM um Techniken des Semantic Webs26 m¨

undeten in der

Semantic Hypermedia Design Method (SHDM), welche durch die Deklaration von Inhal-

ten als Ressourcen und ihrer Charakterisierung durch Ontologiesprachen die OOHDM

23Das Dom¨

anenmodell ist dem Aufgabenmodell bei dieser Methode folglich untergeordnet.

24Weitere Informationen zur Web Modeling Language sind unter http://www.webml.org verf¨

ugbar,

kommerzielle Werkzeugunterst¨

utzung ist unter http://www.webratio.com zu finden. Letzter Zugriff:

31.07.2008.

25Entwurfsphasen der RMM: (1) Entity-Relationship-Entwurf, Modellierung der Fachdom¨

ane; (2)

Entity-Entwurf, Aufbau des Hypergraphen durch Vernetzung; (3) Navigations-Entwurf, Definiti-

on von Zugriffspunkten und Indizes; (4) Konvertierungsprotokoll-Entwurf, Transformation in XML;

(5) Entwurf der Benutzungsschnittstelle und (6) Entwurf des Laufzeitverhaltens zur Beschreibung

der Pr¨

asentationsschicht (vgl. [ISB95]).

26Speziell zur Metadatenbeschreibung von Anwendungen, bspw. das Ressource Description Framework

(RDF) und die RDF Vocabulary Description Language (RDFS) zur Beschreibung von Schemata,

sowie die Web Ontology Language (OWL). Alle drei Techniken sind vom W3C spezifiziert und unter

http://www.w3.org online verf¨

ugbar.

189

5. Entwicklungsmethodik komponentenbasierter Lernumgebungen

in puncto Vorgehen auf die Verwendung aktuellster Technologien modernisiert hat. Der

objektorientierte Ansatz und die strikte Trennung von Inhalt und Layout wurden beibe-

halten. Die technische Unterst¨

utzung zur Entwicklung semantischer Web-Anwendungen

nach der SHDM kann durch MVC-Frameworks wie HyperDE27 erfolgen.

Dem OOHDM sehr ¨

ahnlich und auf einen durchgehenden Entwicklungsprozess abzie-

lend ist das an der LMU M¨

unchen entwickelte UML-Based Web Engineering (UWE). Der

Entwicklungsprozess lehnt sich dabei stark an den UML-basierten Rational Unified Pro-

cess (RUP) an. Somit liefert UWE ein sehr reichhaltiges, aber auch komplexes Modell,

das per se objektorientiert und auf interaktive Web-Anwendungen ausgerichtet ist. Ein

Vorteil hierbei ist die explizite und deutliche Strukturierung des Pr¨

asentationsbereichs,

die in der Form nicht in allen Methoden vorhanden ist.

Die Object-Oriented Hypermedia Method (OO-H) ist ebenfalls eine neuere Methode,

welche die Vorteile von WebML, OOHDM und UWE in sich vereint. Aufgrund des

von der OOHDM ¨

ubernommenen Konzepts einer starken Navigationsauspr¨

agung ist sie

insbesondere f¨

ur die Entwicklung von Hypermedia-Anwendungen geeignet. Eine Werk-

zeugunterst¨

utzung erg¨

anzt diese Methode28. Ein ¨

Uberblick ¨

uber alle hier genannten

Methoden zur Entwicklung von Web-Anwendungen wird in Tabelle 5.2 gegeben.

5.2.3. Hybride Modelle

Die hybriden Modelle kombinieren inhaltliche und methodische Aspekte aus Vorgehens-

modellen der didaktischen und der softwaretechnischen Disziplin. Diese Modelle eignen

sich im Speziellen f¨

ur die Konzeption und Implementierung von Software f¨

ur Lehr- und

Lernzwecke (vgl. [Ham05a], S. 51). In der Literatur finden sich Modelle zur Umsetzung

klassischer hypermedialer Lernumgebungen und in Bezug auf die Systemklasse offenere

Lernumgebungen.

5.2.3.1. Hybride Modelle zur Entwicklung hypermedialer Lernumgebungen

Blumstengel lehnt in [Blu98] ihr Modell zur Entwicklung hypermedialer Systeme an das

Instruktionsdesign an und ¨

ubernimmt die Evaluation als integralen Bestandteil der ver-

schiedenen Phasen. In der ersten Phase werden dazu bereits die Evaluationsinstrumente

festgelegt. Das Prozessmodell ihres Ansatzes besteht aus den vier Hauptphasen Bedarfs-

analyse, Alternativentwicklung, Produktion, und Anwendung und Evaluation. Die Pha-

sen werden mit durchgehenden Projektmanagement- und Revisionsprozessen flankiert.

Der softwaretechnische Produktionsprozess besteht wiederum aus den Unterprozessen

Planung, Entwurf (neben dem Screendesign auch aus einem didaktischen Feinentwurf),

Implementierung, Integration und Test. Eine dar¨

uber hinausgehende Detaillierung von

Vorgehensschritten und ein Rollenmodell sind nur stellenweise vorhanden, eine Metho-

densammlung fehlt.

27HyperDE ist eine Kombination aus MVC Framework (basierend auf Ruby on Rails) und einer

Entwicklungsumgebung f¨

ur Semantic Web-Anwendungen. Mehr Informationen sind unter http:

//www.tecweb.inf.puc-rio.br/hyperde/wiki/WikiStart verf¨

ugbar. Letzter Zugriff: 31.07.2008.

28VisualWADE Tool, verf¨

ugbar unter http://gplsi.dlsi.ua.es/iwad/ooh project/cawetool.htm.

Letzter Zugriff: 31.07.2008.

190

5.2. Referenzmodelle zur Entwicklung von E-Learning-Komponenten

Nagl et al. beschreiben in [NBS+99] ein Vorgehensmodell f¨

ur die industrielle Entwick-

lung multimedialer Lehr- und Lernsysteme, welches prim¨

ar eine Weiterentwicklung der

Elemente klassischer Softwaretechnik ist, die sich seitens der multimedialen Lehr- und

Lernsysteme ergeben. Es setzt sich im Grunde aus Prozessen des Software-Managements,

der -Entwicklung und -Qualit¨

atssicherung zusammen. Das SW-Management umfasst –

wie bei Blumstengel auch – Querschnittsfunktionen wie Planung und Controlling. Die

Software-Entwicklung enth¨

alt die typischen Phasen wie Entwurf und Implementierung,

dar¨

uber hinaus auch Wartung und Pflege, die sich einer Einf¨

uhrungsphase anschließen.

Zur Prozesssteuerung wird ein sequenzielles Vorgehen vorgeschlagen, wenn industriel-

le Rahmenbedingungen wie Budgetierung und Terminierung eingehalten werden sollen;

k¨

onnen diese vernachl¨

assigt werden, kann auch eine evolution¨

are Steuerung eingesetzt

werden, die mehr R¨

uckkopplungen impliziert. Neben den klassischen softwaretechni-

schen Merkmalen fließen auch inhaltliche und mediendidaktische Qualit¨

atsmerkmale in

die Software-Qualit¨

atssicherung mit ein.

Methode Notation

Anforderungen

Content

Hyperlinks

Pr¨

asentation

Dynamik

St¨

arken

Hypertext

HDM-lite ER +

eigene

7 7 3 3 7 Prozess zur Transformation

der Modelle, automatische

Generierung

WSDM eigene 7 3 3 7 3 benutzerzentrierte Vorge-

hensweise bei Analyse

Daten

RMM ER +

eigene

7 3 3 3 7 Hypertext-Modellierung,

vordefinierter Prozess

WebML ER, UML 33373ausgereifte Notation, DB-

Integration

Objekte

OOHDM UML +

eigene

33337m¨

achtige Konzepte f¨

ur kon-

textuelle Navigation

SHDM UML +

eigene

33337Semantic Web, gute Ent-

wicklungsumgebung

UWE UML 33333RUP-basierter Prozess

OO-H UML +

eigene

33373gute Werkzeugunterst¨

ut-

zung

Tabelle 5.2.: ¨

Uberblick ¨

uber Methoden zur Entwicklung von Web-Anwendungen (in An-

lehnung an [SK03], S. 72)

191

5. Entwicklungsmethodik komponentenbasierter Lernumgebungen

Ein ¨

ahnliches Modell spezifizierte Yass in [Yas00]. In Analogie zum Modell von Nagl et

al. ist auch dies eine logische Erweiterung eines Phasenmodells zur Softwareentwicklung

um didaktische Konzepte. Hierbei werden in der Projektdefinitionsphase Lernziele und

Lerneinheiten spezifiziert und die Didaktik der Lerneinheiten aufgebaut. Ebenfalls wer-

den die didaktischen Aspekte in der Test und Entwurfsphase explizit ber¨

ucksichtigt, wo

auch auf didaktische und inhaltliche Fehler, gestalterische M¨

angel sowie Abweichungen

von den Lernzielen gepr¨

uft und korrigiert wird. Als Prozesssteuerung wird von Yass ein

prototypisches oder evolution¨

ares Vorgehen vorgeschlagen.

Das Vorgehensmodell zur Erstellung virtueller Bildungsinhalte hat Klein zur Konstruk-

tion wiederverwendbarer hypermedialer Kurse konzipiert (vgl. [KS01] und [Kle02]). Die

Prozessarchitektur orientiert sich dabei am Wasserfallschema, R¨

uckkopplungen sind zu-

gelassen. Die einzelnen Phasen sind durch Vorgehensschritte detailliert beschrieben. Di-

daktische Aspekte werden in der Analysephase ber¨

ucksichtigt, wo Lernziele, -eigenschaf-

ten und -inhalte in nat¨

urlicher Sprache beschrieben werden. Dar¨

uber hinaus werden in

der Designphase Lerninhalte durch Module und entsprechenden Beziehungen modelliert,

die Entw¨

urfe von Lehrstoff, Lernszenarien, Benutzungsschnittstellen und Datenmodellen

umfassen.

Pawlowski hat in [Paw01] mit dem generischen Essener-Lern-Modell (ELM) eine Pro-

zessarchitektur spezifiziert, in der sich Design- und Entwicklungsprozesse durchg¨

angig

von der Curriculumsentwicklung bis zur Umsetzung einzelner Lerneinheiten durchzie-

hen. Ebenso Querschnittsprozesse wie Projektmanagement. Genau wie Yass empfiehlt

Pawlowski eine evolution¨

are Steuerung (S. 124f.). Eine Prototypentwicklung ist eben-

falls als Teil der Implementierungsphase mit ber¨

ucksichtigt (S. 123). Didaktische Aspekte

umfassen Prozesse der Curriculumsentwicklung sowie die Verwendung von Lerntechno-

logiestandards. Dar¨

uber hinaus sind der didaktische Kontext, Aktoren, Lernziele und

Methoden als Komponenten im Dom¨

anenmodell explizit vorgesehen.

5.2.3.2. Referenzmodell f¨

ur Qualit¨

atsmanagement und Qualit¨

atssicherung

Neben den Vorgehensmodellen zur Entwicklung von klassischen Lernumgebungen exis-

tiert eine allgemein akzeptierte und harmonisierte Prozessarchitektur, die bestehende

Ans¨

atze integriert und sich nicht auf die Systemklasse hypermedialer Lernumgebun-

gen bzw. WBTs beschr¨

ankt. Dieses Referenzmodell f¨

ur Qualit¨

atsmanagement und Qua-

lit¨

atssicherung bei der Planung, Entwicklung, Durchf¨

uhrung und Evaluation von Bil-

dungsprozessen und -angeboten ist beim Deutschen Institut f¨

ur Normung als DIN PAS

1032-1:2004 spezifiziert. Die PAS (Publicly Available Specification) wurde von einem

Experten-Team aus allen Bereichen der Bildung und Weiterbildung entwickelt. Sie ba-

siert somit auf Erfahrungen in den Anwendungs-, Forschungs- und Entwicklungsberei-

chen des E-Learnings. Das Referenzmodell der PAS, aus dem auch der neue Standard

ISO/IEC-Norm 19796-1:2005 hervorgegangen ist, basiert in der Hauptsache aus einem

generischem Prozessmodell, bestehend aus sieben Prozesskategorien mit insgesamt 38

Prozessen (Abb. 5.5), und einem umfangreichen generischen Beschreibungsmodell. Das

Beschreibungsmodell impliziert u. a. ein Rollenmodell (die Zuordnung von Aktoren zu

Prozessen), eine Methodensammlung und einen Qualit¨

atskriterienkatalog.

192

5.2. Referenzmodelle zur Entwicklung von E-Learning-Komponenten

Da keine logischen oder zeitlichen Beziehungen zwischen Prozessen definiert sind und

es f¨

ur einzelne Prozesse ebenfalls keine eindeutige Zuweisung von Methoden gibt, muss

bei Anwendung des generischen Modells zun¨

achst eine individuelle Auswahl, Anpassung

und ggf. Erweiterung der Prozesse vorgenommen werden.

Anforderungs-

ermittlung Initiierung Identifikation der

Stakeholder Zieldefinition Bedarfsanalyse

Rahmenbedingungen Analyse des

externen Kontextes

Analyse der

personellen

Ressourcen

Analyse der

Zielgruppe Analyse organisatorischer

u. institutioneller Kontext

Termin-/

Budgetplanung Analyse der

Ausstattung

Konzeption

Lernziele Inhaltliche

Konzeption Didaktik/Methodik Rollen und

Aktivitäten Organisatorische

Konzeption Technische

Konzeption

Konzeption de

Medien- und

Interaktionsdesigns

Konzeption

Medieneinsatz Konzeption

Kommunikation Konzeption Tests

und Prüfungen Konzeption

Wartung und Pflege

Produktion Inhaltliche

Realisierung Designumsetzung Medienrealisation Technische

Realisation Wartung und Pflege

Einführung Test der

Lernressourcen Anpassung der

Lernressourcen Freigabe der

Lernressourcen

Organisation des

Betriebs und der

Nutzung

Einrichtung der

technischen

Infrastruktur

Durchführung Administration Aktivitäten Überprüfung von

Kompetenzniveaus

Evaluation Planung Durchführung Auswertung Optimierung

Abbildung 5.5.: Die Prozessarchitektur der DIN PAS 1032-1:2004 (vgl. [DIN04a],

S. 10ff.)

Im Gegensatz zum Systems Approach, auf dem Modelle des Instruktionsdesigns basie-

ren, wird bei der PAS von der Annahme ausgegangen, dass nicht immer eindeutige

Kriterien zur Evaluierung einer Lernressource oder eines Lernszenarios definiert werden

k¨

onnen. Daher werden verschiedene Qualit¨

atsanforderungen formuliert, denen die Ge-

staltung und Durchf¨

uhrung der Entwicklungs- und Lernprozesse gen¨

ugen sollen. Neben

den didaktischen Aspekten m¨

ussen allerdings auch die Kriterien ISO 9241 f¨

ur Software-

produkte erf¨

ullt sein. Somit ist die PAS ein transparenter Rahmen zur Planung der

Entwicklung computergest¨

utzter Lernwerkzeuge, der neben einer Referenzprozessarchi-

tektur einen Fokus auf die Qualit¨

atsaspekte bei Prozessen und Produkten bietet. Zur

Prozesssteuerung selbst wird in dem Referenzmodell keine Vorgabe gemacht. Sie muss

im Rahmen der Instanzierung dieses Modells definiert werden.

5.2.4. Zusammenfassung und Bewertung

In diesem Unterkapitel wurden didaktisch orientierte, technisch orientierte und gemischt

orientierte Vorgehensweisen zur Durchf¨

uhrung von Entwicklungsprojekten im E-Learning-

Kontext vorgestellt. Es soll nun eine f¨

ur den Anwendungskontext der Arbeit geeignete

Prozessarchitektur identifiziert werden, die dann in einem n¨

achsten Schritt auf die beson-

deren Anforderungen normsprachlicher Spezifizierung und Produktfamilien-orientierte

Softwareentwicklung angepasst wird.

193

5. Entwicklungsmethodik komponentenbasierter Lernumgebungen

Die didaktisch orientierten Modelle des Instruktionsdesigns bieten durch ihre determi-

nistische Prozessstruktur und ihrer Evaluationskomponenten eine gute Planungssicher-

heit f¨

ur Methoden des Projektmanagements. Wichtige Aussagen ¨

uber den Entwicklungs-

stand eines Lernsystems k¨

onnen dadurch schnell getroffen werden. Zus¨

atzlich erlaubt die

R¨

uckkopplung von Maßnahmen zur Qualit¨

atssicherung zu vorherigen Phasen und Ak-

tivit¨

aten ein iteratives Vorgehen. Die Regelsysteme komplexerer ID-Modelle schr¨

anken

einen hochschulweiten Einsatz jedoch stark ein. Zum einen steht die zur operativen Defi-

nition von Lehrzielen notwendige aufw¨

andige Zielgruppenanalyse oft nicht im Verh¨

altnis

eines didaktisch hochwertigen Lernangebots (vgl. [Iss97], S. 215). Genauso scheuen viele

Anwender die umfangreiche formative Evaluation (vgl. [Ker01], S. 326). Zum anderen

sind ID-Modelle f¨

ur den Bereich der Printmedien konzipiert worden. Sie vernachl¨

assigen

daher in der Prozessarchitektur die Entwicklung von Medien bzw. Softwaresystemen.

Dar¨

uber hinaus – und das ist der entscheidende Punkt – sind ID-Modelle am Entwurfs-

objekt gebunden. Sie sind per se nicht generisch, sondern immer nur situativ g¨

ultig

respektive nur f¨

ur bestimmte Szenarios einsetzbar.

Die vorgestellten technisch orientierten Modelle zur Entwicklung von Lernsystemen be-

schreiben ein Vorgehen unterschiedlich detailliert. Aspekte wie Anforderungserhebung,

Einf¨

uhrung und Evaluation werden teilweise vernachl¨

assigt und sich nur auf die Soft-

wareentwicklung fokussiert. F¨

ur den praktischen Einsatz macht dies eine vorherige Ein-

bettung in ein ¨

ubergeordnetes Schema notwendig. Dar¨

uber hinaus konzentrieren sich

alle Modelle auf die Systemklasse der hypermedialen Lernumgebungen respektive Web

based Trainings, sind also ebenfalls am Entwurfsobjekt gebunden und nicht generisch.

Hybride Modelle ber¨

ucksichtigen sowohl technische als auch didaktische Aspekte. Dabei

sind manche eher an das didaktische Design angelehnt (bspw. Blumstengel), die Mehr-

heit der Modelle basiert aber auf Softwareentwicklungsmodellen, die um didaktische

Aspekte angereichert wurden (wie bspw. Nagl et al. und Yass). Bis auf das DIN PAS

Referenzmodell unterst¨

utzen sie die Entwicklung klassischer Lernumgebungen, und las-

sen sich nicht ohne weiteres zur Entwicklung lernerzentrierterer Szenarien heranziehen.

Das DIN PAS Referenzmodell ber¨

ucksichtigt als hybrides Modell ebenfalls technische

und didaktische Aspekte. Im Vergleich zu den anderen vorgestellten Modellen ist es

relativ jung und basiert als DIN-Spezifikation auf den kombinierten Erfahrungen von

Experten in der Anwendung, Entwicklung und Forschung von E-Learning-Umgebungen.

Mit einem detaillierten Prozessmodell, einer Methodensammlung und einem Qualit¨

ats-

Kriterienkatalog ist dieses Modell am umfangreichsten. Durch seine Referenzfunktion ist

es per se generisch. F¨

ur bestimmte Szenarios oder E-Learning-Systemklassen lassen sich

Modellinstanzen ableiten und anpassen.

F¨

ur den Kontext dieser Arbeit bietet sich daher eine Instanzierung und Anpassung

der PAS 1032-1:2004 an, die im Folgenden vorgenommen werden soll.

194

5.3. Konzeption der Methode auf Basis der DIN-PAS 1032-1:2004

5.3. Konzeption der Methode auf Basis der DIN-PAS

1032-1:2004

In diesem Unterkapitel soll das Referenzmodell der PAS, also die Prozessarchitektur

und das Beschreibungsmodell, auf den spezifischen Kontext dieser Arbeit angepasst

und erweitert werden. Dazu wird nach dem von Gutzwiller in [Gut94] vorgeschlagenen

Verfahren zur Methodenbeschreibung vorgegangen.

Zu Beginn werden daher die Handlungsfelder und Gestaltungsobjekte der Methode im

Rahmen eines Metaobjektmodells vorgestellt. Diese geben einen ¨

Uberblick, in welchen

Beziehungen die resultierenden Ergebnisse zueinander stehen.

Das Vorgehensmodell umfasst die separate Entwicklung der Anwendung und der Platt-

form. Da die PAS allerdings nur auf die einmalige Entwicklung einzelner E-Learning-

Komponenten ausgerichtet ist und keine Meta-Prozesse wie die gemeinsame Entwicklung

hochschulweiter E-Learning-Konzepte oder den Aufbau einer Standardarchitektur um-

fasst, werden im zweiten Abschnitt (5.3.3) diesbzgl. notwendige Prozesse identifiziert

und in das Modell aufgenommen.

Die erweiterte Prozessarchitektur wird im Anhang A.5 ausf¨

uhrlich beschrieben. Dieses

Beschreibungsmodell impliziert die Zuordnung von Rollen, Ergebnissen und Methoden/-

Techniken zu Prozessen. Daher wird in diesem Kapitel auf eine detailliertere Darstellung

des Ergebnisses verzichtet.

Zuletzt wird jeweils ein Konzept zur Prozesssteuerung sowohl f¨

ur die Plattforment-

wicklung als auch f¨

ur die (5.3.4) auf Grundlage von Erfahrungen vorgeschlagen.

5.3.1. Das Metaobjektmodell

Ein Metaobjektmodell ist ein konzeptionelles Datenmodell, das einen schnellen ¨

Uberblick

uber die beschreibenden und gestaltenden Bereiche der Methode liefert. Das in Abb. 5.6

dargestellte Modell basiert dabei auf den in den Kapiteln 4 und 5 vorgestellten Konzep-

ten f¨

ur die normsprachliche Spezifizierung und f¨

ur die Entwicklung der Architektur sowie

ihren Beziehungen zueinander. Es ist in UML notiert. Aus Gr¨

unden der ¨

Ubersichtlichkeit

wurde auf die Angabe der Kardinalit¨

aten verzichtet, da sie f¨

ur die gew¨

ahlte Betrach-

tungsebene keine wesentlichen Aussagen liefern.

Im Metaobjektmodell repr¨

asentieren verschiedene Gestaltungsobjekte die drei Hand-

lungsfelder der Methode:

Normsprachliche Spezifikation Basierend auf einem p¨

adagogisch-didaktischen Modell,

das in der Methode analysiert wird und daher nicht selbst zum konzeptionellen Teil

gez¨

ahlt werden kann, werden die statischen, funktionalen und dynamischen Gestal-

tungsaspekte einer Lernumgebung spezifiziert. Hierzu werden die normsprachliche

Konstrukte der in Kapitel 4 erarbeiteten Grammatik und Terminologie verwendet

(in der Abbildung invers gekennzeichnet).

Entwurf Unter Zuhilfenahme der normsprachlichen Spezifikation erfolgt in einem zwei-

ten Schritt der technologiespezifische Entwurf der Lernumgebung. Dieser basiert –

wie in Kapitel 5 beschrieben – grundlegend auf der Produktstandardarchitektur,

195

5. Entwicklungsmethodik komponentenbasierter Lernumgebungen

die wiederverwendbare Kooperations- und E-Learning-Dienste ¨

uber Komponen-

ten bereitstellt. Diese Architektur wird naturgem¨

aß durch das Umsystem eines

Entwicklungsprojektes beeinflusst. Zum einen durch hochschulweite IT-, Medien-

und E-Learning-Strategien, zum anderen durch Referenz- und Rahmenarchitek-

turen wie in Abschnitt 2.2.4.3 vorgestellt respektive in Kapitel 5 erarbeitet. Im

Entwurf wird eine passende Auswahl wiederverwendbarer Komponenten getrof-

fen, deren Variationspunkte entsprechend den Anforderungen konfiguriert und um

anwendungsspezifische Komponenten erg¨

anzt. In Gesamtheit bildet dies die Pro-

duktarchitektur. Dar¨

uber hinaus umfasst die Methode im Rahmen einer proaktiven

Wiederverwendung den separaten Entwurf der Produktstandardarchitektur.

Entwicklung In Analogie zum Entwurf erfolgt die Entwicklung von Plattform und An-

wendung separat. Ein Teil der wiederverwendbaren Dienste wird dabei ¨

uber ein

Groupware-Framework abgedeckt. Zur Entwicklung einer Anwendung werden an-

wendungsspezifische Dienste implementiert und integriert. Die Entwicklung bein-

haltet daher auch Integrationstests.

Die Methode selbst umfasst dar¨

uber hinaus Querschnittsfunktionen wie Projekt-, Risiko-

und Qualit¨

atsmanagement, die zugunsten einer besseren ¨

Ubersichtlichkeit nicht als Hand-

lungsfelder im Metaobjektmodell mit aufgenommen wurden.

5.3.2. Vorgehen zur Anwendungsentwicklung

Wie bereits in der Vorstellung der PAS erw¨

ahnt, muss das generische Referenzmodell

zur Verwendung auf einen bestimmten Anwendungskontext zugeschnitten werden. Dazu

wird im Folgenden zun¨

achst die Anwendungssituation konkretisiert, die die in dieser Ar-

beit vorgestellte normprachliche Spezifizierung und Produktlinien-orientierte Umsetzung

von E-Learning-Komponenten im Kontext universit¨

arer Informationsarchitekturen um-

fasst. Davon werden auch die Rollen abgeleitet, die im Beschreibungsmodell im Anhang

verwendet werden. In einem zweiten Schritt werden diejenigen Prozesse der PAS identifi-

ziert, die f¨

ur diese Anwendungssituation nicht relevant sind, oder die hierf¨

ur abge¨

andert

oder anderen Prozessstrukturen untergeordnet werden. Die verbleibende Prozessauswahl

wird in einem dritten Schritt dann spezifiziert und um neue Prozesse erg¨

anzt.

Zur besseren Unterscheidung zwischen den Prozessen der PAS und denen der zu kon-

struierenden Methode wird den Nummern der PAS-Prozessen ein P vorangestellt.

5.3.2.1. Spezifizierung der Anwendungssituation

Das zu beschreibende Vorgehen ist prim¨

ar gepr¨

agt durch die Merkmale des zweigeteil-

ten normsprachlichen Fachentwurfs, durch die separate Betrachtung von Plattform und

Anwendung im Softwareentwicklungsprozess und letztendlich auch durch die Komponen-

tenorientierung, die bei Entwurf und Implementierung besonders ber¨

ucksichtigt werden

muss. ¨

Uber allem steht jedoch die Anforderung, dass die zu entwickelnde E-Learning-

Komponente zu einem Bestandteil der hochschulweiten Infrastruktur und daher auch –

losgel¨

ost von der fachlichen bzw. inhaltlichen Ausgestaltung – sich am hochschulweiten

E-Learning-Verst¨

andnis orientieren sollte.

196

5.3. Konzeption der Methode auf Basis der DIN-PAS 1032-1:2004

beeinflussen

definieren

Ausprägung

implementiert

definiert

Anwendung

Plattform

Komponente

anwendungs-

spezifische

Komponente

wieder-

verwendbare

Komponente

Kooperations-

dienst

E-Learning spez.

Dienst

Produkt-

architektur

Rahmen-

architektur

IT-/E-Learning-

strategie

Groupware-

framework

Dienst

Variationspunkt

Gestaltungs-

aspekt

normsprachliche

Aussage

Satzmuster

Term Terminologie

Grammatik

dynamischer

Gestaltungs-

aspekt

funktionaler

Gestaltungs-

aspekt

statischer

Gestaltungs-

aspekt

päd.-didakt.

Modell

Lernziel Lerntheoret.

Ansatz Sozialform Lernmethode

Medieneinsatz

funktional

abhängig

implementiert

betreffen

Normsprachliche Spezifikation

spezifiziert

EntwurfEntwicklung

Testkatalog

Plattform-

architektur

Test

sichert

Qualität

Abbildung 5.6.: Das Metaobjektmodell zum ¨

Uberblick ¨

uber die beschreibenden und ge-

staltenden Bereiche der Methode 197

5. Entwicklungsmethodik komponentenbasierter Lernumgebungen

Aus diesem Grund erscheint es sinnvoll, die Anwendungsentwicklungen zusammen mit

einem zentralen technischen Dienstleister wie ein Medienzentrum, E-Learning-Center,

Rechenzentrum o. ¨

a. durchzuf¨

uhren, das sowohl mit der E-Learning- als auch mit der

IT-Strategie der Hochschule vertraut ist und dar¨

uber hinaus die Entwicklung der Pro-

duktstandardplattform verantwortet. Aus softwarearchitektonischer Sicht steht daher

der Blick auf die gesamtuniversit¨

are IT-Infrastruktur im Mittelpunkt, von dem ausge-

hend neue Entwicklungsprojekte, Schnittstellenintegration und der Aufbau von Infra-

strukturen und Diensten durchgef¨

uhrt werden k¨

onnen.

Ebenfalls muss die Dom¨

ane des E-Learnings gemeinsam mit den Anwendern aus unter-

schiedlichen Fachbereichen konzeptuell erschlossen werden. Das impliziert zum einen die

Bildung von Begriffen und Beschreibung von Konzepten29, zum anderen auch die Erar-

beitung gemeinsamer Qualit¨

atskriterien, an die sich die Entwicklung und Durchf¨

uhrung

von E-Learning-Projekten richten k¨

onnen. Dieses ist ein stetiger Prozess, weshalb die

Einrichtung eines festen Arbeitskreises sinnvoll sein kann, mit E-Learning-Experten und

Softwareentwicklern auf der einen und Fachbereichsvertretern und Didaktiker auf der

anderen Seite. Eine hochschulweite IT-/E-Learning-Strategie, welche die o. g. Aspekte

ber¨

ucksichtigt, kann hierzu den mittel- und langfristigen Handlungsrahmen definieren.

In einer solchen Konstellation, die bereits an einigen Hochschulen aufgebaut wur-

de bzw. sich im Aufbau befindet, k¨

onnen gemeinsam mit Fachbereichen und einzelnen

Lehrst¨

uhlen Projekte durchgef¨

uhrt und neue E-Learning-Komponenten entwickelt und

in die Infrastruktur integriert werden.

5.3.2.2. Anpassung und Erweiterung des Referenzmodells

Die spezifizierte Anwendungssituation beschreibt die Entwicklung von E-Learning-Werk-

zeugen auf Basis einer Standardarchitektur, die f¨

ur den hochschulweiten Betrieb be-

stimmt sind. Die Ausf¨

uhrungen zu Vorgehensmodellen haben bereits deutlich gemacht,

dass der Entwurf und die Entwicklung eine hohe Komplexit¨

at aufweisen, die im Rah-

men eines Projektes gehandhabt werden muss. Insbesondere wenn es sich um eine hoch-

schulweite L¨

osung mit hohen Nutzerzahlen oder eine organisationskritische Anwendung

handelt, wie beispielsweise eine Kursanmeldung oder ein Kommunikationskanal, ist ein

solches Projekt oft mit Risiken behaftet und es muss eine bestimmte Qualit¨

at sicher-

gestellt werden. Neben dem Risikomanagement und der Qualit¨

atssicherung z¨

ahlt auch

die Organisation des Projektes selbst zu den Querschnittsfunktionen, die umso wichtiger

wird, je gr¨

oßer das Projekt ist.

Projektvorbereitung Das Referenzmodell ber¨

ucksichtigt die Qualit¨

atssicherung

zwar implizit im Beschreibungsmodell30, im Prozessmodell der PAS ist die Qualit¨

ats-

sicherung jedoch nicht als Prozess explizit mit aufgef¨

uhrt. Gleiches gilt f¨

ur das Risikoma-

29Hierzu bietet die in Kapitel 4 beschriebene normsprachliche Rekonstruktion auf Basis einer

Dom¨

anenterminologie eine geeignete Grundlage.

30Beispielsweise m¨

ussen die Kriterien von ISO 9241 f¨

ur Softwareprodukte erf¨

ullt sein. Dar¨

uber hinaus

gibt es eine Reihe von lern- und medienpsychologischen Qualit¨

atskriterien in sieben Kriterienberei-

chen, die auf die spezielle Zielsetzung des Lernen bezogen sind.

198

5.3. Konzeption der Methode auf Basis der DIN-PAS 1032-1:2004

nagement und die Projektorganisation31. Aus diesem Grund wird eine erste Phase ”Pro-

jektvorbereitung“ definiert, in der neben den zus¨

atzlich aufgenommenen Management-

Prozesse 2.1.2, 2.1.8, 2.1.10, 2.1.11 auch Prozesse der PAS-Kategorie ”Rahmenbedin-

gungen“ zugeordnet werden. Dabei geht der Prozess ”P2.2 Analyse der personellen Res-

sourcen“ zum Teil in ”2.1.2 Festlegung von Rollen und Verantwortlichkeiten“ und in

”2.1.9 Projektplanung“ mit ein und ist im Modell in urspr¨

unglicher Form nicht mehr

vorhanden. Ebenfalls ist die ”P2.4 Analyse des organisatorischen und institutionellen

Kontextes“ zusammen mit ”P2.6 Analyse der Ausstattung“ in den Prozess ”2.1.7 Rah-

menbedingungen ermitteln“ eingegangen. Diese beiden Prozesse sind nicht mehr explizit

genannt, die ihnen zugeordneten T¨

atigkeiten sind aber im Beschreibungsmodell unter

2.1.7 vorhanden.

Analyse Aufgrund der gewollten didaktischen Neutralit¨

at des Modells und der im Ge-

genzug dazu starken technischen Bindung an die komponenten- und Produktlinien-orien-

tierte Entwicklung verlagert sich der Schwerpunkt im neuen Vorgehensmodell im Ent-

wurf und der Umsetzung auf die softwaretechnischen Aspekte. Um die didaktischen

Aspekte der Konzeption trotzdem nicht zu vernachl¨

assigen, wird die urspr¨

ungliche me-

diendidaktische Konzeption (P3.3, P3.7, P3.8, P3.9, ) in die Analysephase mit aufgenom-

men (2.2.1, 2.2.2, 2.2.3) und geht damit also in die detaillierte Anforderungserhebung mit

ein. Die Analyse der Zielgruppe erfolgt bereits in der Ermittlung der Rahmenbedingun-

gen (2.1.7). Der Prozess ”Konzeption der Tests und Pr¨

ufungen“ (P3.10) wird im neuen

Modell aufgrund der ge¨

anderten Schwerpunktsetzung jedoch nicht mit ber¨

ucksichtigt.

Dar¨

uber hinaus wird im neuen Modell ein weiterer Prozess mit aufgenommen: Zu-

sammen mit den Stakeholdern wird die Statik, die Funktionalit¨

at und die Dynamik der

zu unterst¨

utzenden Lern- und Arbeitsszenarien normsprachlich modelliert (2.2.4). Dazu

sind dem Anwendungsfall entsprechend Gruppen-/Nutzerstrukturen, Inhaltestrukturen

und Prozessstrukturen abzubilden. Funktionalit¨

at und Dynamik definieren, welche Frei-

heitsgrade auf den drei Dimensionen Teams, Inhalte und Prozesse unterst¨

utzt werden

sollen.

Konzeption Die Konzeptionsphase des neuen Modells beinhaltet auf der normsprach-

lichen Spezifizierung aufbauend zum einen den Entwurf der Produktarchitektur, zum

anderen die Erstellung eines organisatorischen Konzepts zur Systemeinf¨

uhrung (2.3.4),

Betrieb und Support (2.3.5) sowie zur Wartung und Pflege (2.3.6). Der PAS-Prozess ”Or-

ganisatorische Konzeption“ (P3.5) wurde dazu verfeinert und ist in seiner urspr¨

unglichen

Form nicht mehr im Modell enthalten. Dies tr¨

agt dem erh¨

ohten Abstimmungsbedarf

Rechnung, der in der Regel bei hochschulweit betriebenen E-Learning-Werkzeugen not-

wendig ist.

31Lediglich die ”Termin-/Budgetplanung“ wird hierzu angef¨

uhrt. Auf die Strukturierung des Projektes

sowie auf die Festlegung von Rollen und Verantwortungen wird jedoch nicht n¨

aher eingegangen.

199

5. Entwicklungsmethodik komponentenbasierter Lernumgebungen

Der Entwurf der Produktarchitektur orientiert sich am komponenten- und Produkt-

linien-orientierten Vorgehen. Daher werden drei neue Prozesse eingef¨

uhrt:

2.3.1 Herleitung der Produktarchitektur Instanzierung der Produktstandardarchitek-

tur inkl. Beschreibung der Konfiguration und der produktspezifischen Anpassun-

gen und Erweiterungen

2.3.2 Identifizierung relevanter Komponenten Abgleich der erhobenen Anforderungen

mit den Feature-Modellen und Konfigurationsm¨

oglichkeiten der vorhandenen Kom-

ponenten

2.3.3 Entwurf produktspezifischer Komponenten Entwurf produktspezifischer Funk-

tionen als Komponenten auf Basis der erhobenen Anforderungen.

Diese drei neuen Prozesse verfeinern den PAS-Prozess ”Technische Konzeption“ (P3.6),

der daher in seiner generischen Form nicht ¨

ubernommen wird.

Implementierung, Integration, Test In Analogie zur Konzeptionsphase wird auch hier

der generische PAS-Prozess ”Technische Umsetzung“ (P4.4) durch neue Prozesse ”Um-

setzung der Produktarchitektur“ (2.4.1), ”Instanzierung und Modifikation von Kompo-

nenten“ (2.4.2) und ”Implementierung produktspezifischer Komponenten“ (2.4.3) kon-

kretisiert. Der neue Prozess ”Umsetzung des Medien- und Interaktionsdesigns“ (2.4.4)

subsumiert die PAS-Prozesse ”Designumsetzung“ (P4.2) und ”Medienrealisation“ (P4.3).

Der Grund f¨

ur diese h¨

ohere Abstraktion ist der, dass die Content-Entwicklung kein ex-

pliziter Bestandteil des Modells sein soll. Das Modell soll nicht nur die Erstellung klas-

sischer Hypermedia-Umgebungen und Web based Trainings unterst¨

utzen, sondern auch

konstruktivistischere, lernerzentrierte Werkzeuge. Eine ”Inhaltliche Realisation“ (P4.1)

ist daher nicht per se relevant, weshalb der PAS-Prozess im neuen Modell auch nicht

weiter ber¨

ucksichtigt wird. In einem konkreten Projekt kann dieser Prozess bei Bedarf

problemlos mit eingebunden werden.

Die Implementierungsphase schließt mit einer aufeinander abgestimmten Reihe von

einzelnen Tests, um alle voneinander abh¨

angigen Komponenten im Zusammenspiel mit-

einander zu testen (”Integrationstest“, 2.4.5). Hierbei sollen (a) die Benutzungsschnitt-

stelle, (b) die Komponentenschnittstellen der Produktstandardarchitektur im Zusam-

menspiel mit neu entwickelten Komponenten und (c) die Kommunikationsschnittstelle

mit dem Basissystem getestet werden. In Summe mit zwei weiteren Prozessen ”System-

test“ (2.5.2) und ”Abnahme oder ¨

Ubernahmetest“ (2.5.5) aus der Systemeinf¨

uhrungs-

und Abnahmephase konkretisiert der Integrationstest den PAS-Prozess ”Test der Lernres-

sourcen“ (P5.1). Auch dies tr¨

agt dem erh¨

ohten Bedarf eines reibungslosen Ablaufs der

Einf¨

uhrung und des Betriebs einer hochschulweiten, evtl. sogar organisationskritischen

Anwendung Rechnung.

Systemeinf¨

uhrung und Abnahme Die ”Einrichtung der technischen Infrastruktur“

(2.5.1, angelehnt an den PAS-Prozess P5.5) wurde im Beschreibungsmodell insbeson-

dere um drei Aspekte konkretisiert:

200

5.3. Konzeption der Methode auf Basis der DIN-PAS 1032-1:2004

âSicherstellung von Infrastrukturkomponenten, die den Anforderungsspezifika ent-

sprechen

âMaßnahmen zur Ausfallsicherung, sicherem Zugriff und sicheren Transaktionen

âBereitstellung von Dokumentationen und Anleitungen f¨

ur den Betrieb, den Zugriff

und die Transaktionssicherheit.

Danach erfolgt der bereits erw¨

ahnte Systemtest, und nach Anpassung und Bereitstellung

schließlich der Abnahme- oder ¨

Ubernahmetest. Die Phase wird durch die Sicherstellung

des organisatorischen Betriebs (2.5.6) in Anlehnung an die in der Konzeptionsphase ent-

wickelte Aufbau- und Ablauforganisation (2.3.5) abgeschlossen. Abh¨

angig vom ”Konzept

der Systemeinf¨

uhrung“ (2.3.4) k¨

onnen nun die im Projekt entwickelten Komponenten

erst einmal einer begrenzten Nutzergruppe oder sogar schon hochschulweit freigegeben

werden.

Betrieb F¨

ur die Betriebsphase wurde aus der PAS alleinig der Prozess ”Administra-

tion“ (P6.1) ¨

ubernommen. Die im Referenzmodell enthaltenen Lern-, Unterst¨

utzungs-

und Transferaktivit¨

aten (P6.2) sowie pr¨

ufungsrelevante T¨

atigkeiten (P6.3) sind f¨

ur den

spezifizierten Anwendungskontext nicht relevant. Statt dessen wurden zwei neue Pro-

zesse ”Support“ (2.6.2) und ”Wartung und Weiterentwicklung“ (2.6.3, angelehnt an den

PAS-Prozess P4.5) definiert.

Evaluation In der Evaluationsphase soll eine systematische Untersuchung der Verwend-

barkeit bzw. G¨

ute der entwickelten E-Learning-Komponente durchgef¨

uhrt werden. Dazu

kann der Evaluations-Regelkreis der PAS – bestehend aus Planung (P7.1), Durchf¨

uhrung

(P7.2), Auswertung der Evaluation (P7.3) und die darauf aufbauende Verbesserung von

Produkten und Prozessen (P7.4) – ohne gr¨

oßere Modifikation ¨

ubernommen werden.

5.3.3. Vorgehen zur Entwicklung der Standardplattform

Die gemeinsame Erschließung von Konzepten mit E-Learning-Experten und Softwareent-

wicklern auf der einen und Fachbereichsvertretern und Didaktikern auf der anderen Seite

ist essenziell f¨

ur die Bildung eines gemeinsamen Fachvokabulars. Nur somit k¨

onnen fach-

bereichs¨

ubergreifende Anforderungen aufgenommen, softwaretechnisch umgesetzt und

als L¨

osung hochschulweit angeboten werden. Neben der reinen Anwendungsentwicklung

soll das zu konstruierende Modell daher auch die hochschulweite Dom¨

anenentwicklung

des E-Learnings unterst¨

utzen, sowohl aus konzeptioneller als auch aus technischer Sicht.

Letzteres meint die Entwicklung der Standardplattform.

Die von dem PAS-Referenzmodell abgeleitete Prozessarchitektur, das bislang nur die

Durchf¨

uhrung eines Entwicklungsprojektes umfasst, wird daher um drei Prozesskategori-

en erweitert: ”Analyse der E-Learning-Dom¨

ane“ (1.1), ”Entwurf der Standardplattform“

(1.2) und ”Entwicklung der Standardplattform“ (1.3). Da diese Prozesse nicht in der PAS

enthalten sind, sollen sie an dieser Stelle kurz erkl¨

art werden. Dar¨

uber hinaus werden

auch sie im Beschreibungsmodell im Anhang detailliert dargestellt.

201

5. Entwicklungsmethodik komponentenbasierter Lernumgebungen

1 Umsetzung der

Standardarchitektur

für die Produktfamilie

1.3 Domänen

Implementierung

1.1 Analyse der E-Learning-

Domäne

1.2 Domänen Design

1.1.1

Domänendefinition 1.1.2 Erstellung eines

Domänenlexikons 1.1.3 Beschreibung von

Konzepten 1.1.4

Featuremodellierung

1.2.1 Standardisierung

der Infrastruktur

1.2.2 Entwurf der

statischen Plattform-

architektur

1.2.3 Entwurf

wiederverwendbarer

Komponenten

1.3.1 Aufbau der

Infrastruktur

1.3.2 Implementierung

der

Plattformarchitektur

1.3.3 Implementierung

wiederverwendbarer

Komponenten

2 Umsetzung,

Einführung u. Betrieb

von Systemen der

Produktfamilie

2.7 Evaluation

2.6 Betrieb

2.5 Systemeinführung

u. Abnahme

2.4 Implementierung,

Integration und Test

2.3 Konzeption

2.2 Analyse

2.1 Projektvorbereitung

2.1.1 Initiierung 2.1.2 Festlegung von

Rollen u.

Verantwortlichkeiten

2.1.3 Identifikation der

Stakeholder 2.1.4 Zieldefinition 2.1.5 Bedarfsanalyse 2.1.6 Anforderungen an

Neuentwicklung und

Priorisierung

2.1.7

Rahmenbedingungen

ermitteln

2.1.8 Projektstruktur

definieren 2.1.9 Termin- u.

Budgetplanung 2.1.10 Risikoanalyse 2.1.11 Qualitäts-

sicherungsplanung

2.2.1 Analyse der zu

unterstützenden

Didaktik/Methodik

2.2.2 Anforderungs-

erhebung Medieneinsatz 2.2.4 Normsprachliche

Spezifizierung

2.2.3 Anforderungs-

erhebung Medien- u.

Interaktionsdesign

2.3.1 Herleitung der

Produktarchitektur

2.3.2 Identifizierung

relevanter

Komponenten und

Anpassung

2.3.3 Entwurf

produktspezifischer

Komponenten

2.3.4 Konzeption

Systemeinführung 2.3.5 Konzeption

Betrieb u. Support 2.3.6 Konzeption

Wartung u. Pflege

2.4.1 Umsetzung der

Produktarchitektur

2.4.2 Instanziierung u.

Modifikation von

Komponenten

2.4.3 Implementierung

produktspezifischer

Komponenten

2.4.4 Umsetzung des

Medien- u.

Instruktionsdesigns 2.4.5 Integrationstest

2.5.1 Einrichtung der

technischen

Infrastruktur 2.5.2 Systemtest 2.5.3 Anpassung 2.5.4 Bereitstellung 2.5.5 Abnahme- oder

Übernahmetest

2.5.6 Organisation des

Betriebs und der

Nutzung

2.6.1 Administration 2.6.2 Support 2.6.3 Wartung u.

Weiterentwicklung

2.7.1 Planung 2.7.2 Durchführung 2.7.3 Auswertung 2.7.4 Optimierung

Abbildung 5.7.: Prozessarchitektur der konzipierten Methode

202

5.3. Konzeption der Methode auf Basis der DIN-PAS 1032-1:2004

5.3.3.1. Analyse der E-Learning-Dom¨

ane

Die dieser Kategorie zugeordneten Prozesse haben in ihrer Kombination zweierlei Funk-

tion: Zum einen die mittel- und langfristige Bildung von Konzepten, deren Intention

allen Stakeholdern an der Universit¨

at bekannt ist. Zum anderen die Definition des Pro-

duktraums, der durch Eigenentwicklungen auf Basis der Standardplattform umgesetzt

werden kann. Hierzu werden in der Prozessarchitektur vier neue Prozesse definiert:

1.1.1 Dom¨

anendefinition Beschreibung des Umfangs der zu betrachtenden E-Lear-

ning-Dom¨

ane und Charakterisierung des Produktraums von zu betrachtenden E-Lear-

ning-Werkzeugen32. Hierbei kann eine hochschulweite E-Learning-Strategie einen Rah-

men vorgeben.

1.1.2 Erstellung eines Lexikons Beschreibung der E-Learning-Begriffe, die hochschul-

weit zur Strategie-, Konzept- und Anwendungsentwicklung verwendet werden sollen. Ziel

dabei ist die Sicherstellung einer gemeinsamen Kommunikationsbasis. Hierzu kann auch

ein Normsprachenlexikon verwendet werden, in dem neue Fachbegriffe durch eine bereits

definierte Terminologie rekonstruiert werden (vgl. hierzu Abschnitt 3.3.1).

1.1.3 Beschreibung von Konzepten Zur Sicherstellung eines gemeinsamen Verst¨

and-

nisses der Statik, Funktionalit¨

at und Dynamik von E-Learning-Szenarien muss deren

Beschreibung mit Hilfe einer angemessenen Modellierung, grafisch oder normsprachlich

erfolgen.

1.1.4 Featuremodellierung Auf Basis der Modelle der E-Learning-Dom¨

ane kann der

betrachtete Produktraum bzgl. Featurevariationen, -kombinationen und -konflikten ana-

lysiert und dokumentiert werden. Dies macht Abh¨

angigkeiten zwischen Funktionen trans-

parent und liefert eine geeignete Entscheidungsbasis f¨

ur die Systemabgrenzung von Pro-

duktplattform und darauf basierender Anwendung. Hierzu k¨

onnen Hilfsmittel wie das

in Abb. 4.27 dargestellte Featuremodell eingesetzt werden.

Wie bereits einleitend erw¨

ahnt, wird dieser Teil des Vorgehens am Besten im hoch-

schulweiten Rahmen eines Arbeitskreises durchgef¨

uhrt, der neben E-Learning-Experten,

Software-Entwicklern und Didaktikern aus Vertretern der verschiedenen Fachbereiche

besteht.

5.3.3.2. Entwurf der Standardplattform

Auf Basis der erarbeiteten gemeinsamen Modelle sowie der Systemabgrenzung von Stan-

dardplattform und darauf basierenden Anwendungen kann eine Standardisierung der

Infrastruktur vorgenommen und die Produktstandard-Architektur und ihre Komponen-

ten entworfen werden. An dieser Phase sind vorrangig SW-Architekten, -Entwickler und

Systemadministratoren beteiligt. Sie gliedert sich wie folgt:

32Beispielsweise ob sich die universit¨

atsinterne Softwareentwicklung vorrangig auf die Unterst¨

utzung

materialorientierte, kooperative Szenarien beschr¨

ankt, oder auch fachspezifische Simulationen und

virtuelle Labore umfasst.

203

5. Entwicklungsmethodik komponentenbasierter Lernumgebungen

1.2.1 Standardisierung der Infrastruktur Bez¨

uglich der Entwicklungsumgebung

m¨

ussen zwischen Architekten, Entwicklern und Administratoren Vereinbarungen ¨

uber

die Entwicklungs- und Laufzeitumgebung getroffen werden. Dazu geh¨

ort auch eine Aus-

wahl von SWE-Pattern und Frameworks sowie die Erstellung einer Architektur-/ Tech-

nologiestrategie33 und Programmierrichtlinien. Hierzu kann die in dieser Arbeit konzi-

pierte Rahmenarchitektur herangezogen werden.

1.2.2 Entwurf der Produktstandardarchitektur Zur Vorbereitung arbeitsteiligen Ent-

wickelns m¨

ussen die Kernfunktionen des funktions¨

ubergreifenden Rahmenwerks entwor-

fen werden. Dar¨

uber hinaus m¨

ussen existierende L¨

osungen eingebunden und funktionale

Erweiterungen in Form zus¨

atzlicher Komponenten leicht integriert werden k¨

onnen. Dazu

wird ein PlugIn-Mechanismus ben¨

otigt, der ebenfalls zu entwerfen ist.

1.2.3 Entwurf wiederverwendbarer Komponenten Sind durch die standardisierte In-

frastruktur noch nicht alle allgemeinen Dienste und Kooperationsdienste abgedeckt,

m¨

ussen die fehlenden Dienste entworfen werden. Weiterhin m¨

ussen auf Grundlage allge-

meiner Dienste und Kooperationsdienste die E-Learning-spezifischen Dienste konzipiert

werden.

Ergebnis dieser Phase sind die Entwurfsdokumente f¨

ur die Standardarchitektur, auf

denen in der n¨

achsten Phase die Umsetzung der Standardplattform basiert.

5.3.3.3. Entwicklung der Standardplattform

Ziel dieser Phase ist die Bereitstellung einer standardisierten Infrastruktur und darauf

aufbauender Produktstandardarchitektur. Die Phase gliedert sich in den Aufbau der

Infrastruktur, in die Implementierung der Standardarchitektur und wiederverwendbarer

Komponenten.

1.3.1 Aufbau der Infrastruktur Installation und Integration verschiedenster Technolo-

gien wie Infrastrukturkomponenten, IDEs, Frameworks, Schnittstellen und Protokolle,

um auf dieser Basis eine lauff¨

ahige Entwicklungs- und Laufzeitumgebung f¨

ur die Platt-

form und ihre Komponenten bereitzustellen.

1.3.2 Implementierung der Standardarchitektur Umsetzung der Kernfunktionen der

entworfenen Standardplattform sowie die Umsetzung eines PlugIn-Mechanismus zur In-

tegration von erweiternden Komponenten.

1.3.3 Implementierung wiederverwendbarer Dienste Implementierung allgemeiner

und E-Learning-spezifischer Funktionen, die in den verschiedenen, darauf basierenden

Anwendungen wieder verwendet werden k¨

onnen.

33Eine Architektur-/Technologiestrategie sollte in diesem Fall folgende Spezifikationen umfassen: Ba-

sisinfrastruktur f¨

ur Schichten und Vermittlungsschichten, genormte Schnittstellen zu den genutzten

externen Systemen, OO-Repository und Groupware-Framework, Programmiersprache(n) und App-

lication Server, Funktionsbibliotheken.

204

5.3. Konzeption der Methode auf Basis der DIN-PAS 1032-1:2004

Das Ergebnis dieser Phase ist eine funktionierende Entwicklungs- und Laufzeitinfra-

struktur, sowie eine funktionierende Standardplattform inklusive allgemeiner und do-

m¨

anenspezifischer Dienste.

5.3.4. Empfehlung einer Ablaufreihenfolge

Im letzten Abschnitt wurde die Prozessarchitektur durch Auswahl, Anpassung und Er-

weiterung der Prozesse aus der DIN PAS 1032-1:2004 aufgebaut (vgl. Abb. 5.7). Dar¨

uber

hinaus wurden inhaltlich und logisch zusammenh¨

angende Prozesse bereits zu Phasen zu-

geordnet, zu deren Abschluss die im Beschreibungsmodell genannten Ergebnisse (Mei-

lensteine) vorliegen m¨

ussen. Dabei bilden die Plattform- und Anwendungsentwicklung

zwei separate Iterationszyklen (vgl. hierzu auch S. 170ff.). Wie in Abbildung 5.8 dar-

gestellt ist, bauen die Phasen logisch aufeinander auf, wobei die Ergebnisse der Platt-

formentwicklung in korrespondierende Phasen der Anwendungsentwicklung eingehen34.

Um die Struktur und den Ablauf eines realen Projektes anhand dieser statischen Pro-

zessarchitektur planen zu k¨

onnen, soll im Folgenden ein Prinzip der Ablaufreihenfolge

zur Prozesssteuerung empfohlen werden.

Abschnitt 5.1.4 liefert dazu bereits eine Entscheidungsgrundlage f¨

ur die Softwareent-

wicklung im universit¨

aren Kontext, die ein iterativ-inkrementelles Vorgehen nahe legt,

allerdings auch die Nachteile aufzeigt.

In der mehrj¨

ahrigen Plattform- und Anwendungsentwicklung an der Universit¨

at Pa-

derborn35 haben sich ein prototypisches Vorgehen f¨

ur die Plattformentwicklung und ein

iterativ-inkrementelles Vorgehen f¨

ur die Anwendungsentwicklung bew¨

ahrt.

Entwurf und Entwicklung von Komponenten der Plattform werden proaktiv durch

Studierende im Rahmen von Projektseminaren und Abschlussarbeiten betrieben und

sind in der Regel nicht zeitkritisch. Durch experimentelle Prototypen k¨

onnen schwierige

Entwurfsentscheidungen ¨

uberpr¨

uft werden. Daneben dienen explorative Prototypen der

besseren Darstellung neuer Plattformfunktionen und liefern Anregungen, Anforderun-

gen und Verbesserungsvorschl¨

age seitens der Anwender. Aus dem gleichen Grund sind

explorative Prototypen auch f¨

ur die Forschung im Bereich CSCW/L von Interesse. An

fertiggestellten Komponenten werden Integrations- und Funktionstests durch erfahrene

wissenschaftliche Mitarbeiter vollzogen, bevor sie in die Plattform integriert werden.

Die anwendungsspezifische Konfiguration und Komponentenentwicklung erfolgen hin-

gegen iterativ-inkrementell, da die Fertigstellung der wichtigsten Funktionen zumeist

zeitkritisch sind36. Dazu ist in der Projektvorbereitungsphase der Prozess ”Anforderun-

gen an Neuentwicklung (grob) und Priorisierung“ (2.1.6) vorgesehen, in welchem wichtige

Anforderungen dokumentiert und priorisiert werden sollen, damit sie als Basis f¨

ur die

Planung der Inkremente respektive Iterationen dienen k¨

onnen. Die Iteration orientiert

sich dabei an den jeweils definierten Inkrementen und umfasst die Phasen Analyse (2.2),

Konzeption (2.3) und Anpassung, Integration, Test (2.4).

34Der in Abb. 4.26 dargestellte R¨

uckfluss von Ergebnissen der Anwendungsentwicklung in die Plattfor-

mentwicklung wurde bei dieser Abbildung zur besseren ¨

Ubersichtlichkeit ausgelassen, ist aber ebenso

vorhanden.

35Hierauf wird im folgenden Kapitel n¨

aher eingegangen.

36In der Regel m¨

ussen die wichtigsten Funktionen vor dem Beginn eines neuen Semesters fertiggestellt

sein.

205

5. Entwicklungsmethodik komponentenbasierter Lernumgebungen

Analyse der

E-Learning-

Domäne

Entwurf der

Standard-

plattform

normsprachl.

Spezifi-

zierung

Konzeption

Projekt-

vorbereitung

Systemein-

führung u.

Abnahme

Betrieb

Evaluation

Entwicklung

der

Standard-

plattform

gemeinsame

Konzepte,

Normsprachliches

Lexikon

Entwicklungs-

bedarf

Domänen-

Wissen

Produktraum-

spezifikation

Plattform-

architektur

Anforderungen

Standard-

funktionen

Produktspez.

Entwurf

produktspezifische

Konfiguration

Anpassung,

Integration,

Test

Produktspez.

Entwicklung

Produktarchitektur

Komponenten,

Standard-

infrastruktur

produktspezifische

Funktionen

Architektur

produktspezifischer

Komponenten

konfigurierte

Standardprodukt-

architektur mit

produktspezifischen

Komponenten

betriebsbereite

Lernumgebung

Erfahrungen aus

dem Betrieb

Prozess der

Plattform-

entwicklung

Prozess der

Produkt-

entwicklung Input/Output

Input/Output-

Beziehung Iteration

Abbildung 5.8.: Beziehungen zwischen den Phasen der konzipierten Methode

206

5.4. Zusammenfassung

In diesem Kapitel wurde eine Methode zum komponentenorientierten Entwurf und Ent-

wicklung von Lernumgebungen konzipiert, welche die normsprachliche Spezifikation bein-

haltet und per se auf die Umsetzung mehrerer Systeme ausgerichtet ist. Dazu wurden

zun¨

achst die theoretischen Grundlagen von Vorgehensmodellen untersucht und Gestal-

tungsobjekte f¨

ur die Methodenkonzeption identifiziert. Eine daran anschließende Be-

trachtung bereits existierender Vorgehensmodelle zur Umsetzung von Lernumgebungen

hat das Referenzvorgehensmodell DIN PAS 1032-1:2004 als gute Ausgangsbasis ausge-

wiesen. Darauf aufbauend wurden relevante Prozesse ausgew¨

ahlt, angepasst und um

dar¨

uber hinaus ben¨

otigte Prozesse erg¨

anzt. Das Resultat ist eine Methode, bestehend

aus

âeiner Prozessarchitektur, welche in Summe 49 Prozesse umfasst, die auf 10 aufein-

ander aufbauende Phasen verteilt sind,

âeinem Beschreibungsmodell (Anhang A.5), das f¨

ur jeden Prozess Beschreibung,

Aspekte, Ziele, Ergebnisse und Qualit¨

atskriterien beinhaltet,

âein Rollenmodell37, das die Beteiligung einer Rolle an Prozessen definiert und somit

Aufschluss ¨

uber Verantwortung und ben¨

otigte Kompetenz in konkreten Projekten

geben kann,

âeine Techniksammlung38 f¨

ur jeden Prozess und

âein Metaobjektmodell, das die Ergebnisse der Methode in Beziehung zueinander

setzt.

37Implizit im Beschreibungsmodell vorhanden.

38Analog zum Rollenmodell ebenfalls als Teil des Beschreibungsmodells.

207

5. Entwicklungsmethodik komponentenbasierter Lernumgebungen

208

6. koaLA – Integrierte Lern- und

Arbeitswelten f¨

ur die Universit¨

at 2.0

Im Rahmen des BMBF-F¨

orderprogramms ”Neue Medien in der Bildung“ wurde an der

Universit¨

at Paderborn das Projekt ”Locomotion“1durchgef¨

uhrt. Dieses Projekt bildete

den Umsetzungsrahmen f¨

ur die im Kontext dieser Arbeit entstandene hochschulweite

Lern- und Arbeitsplattform koaLA2. Die Plattform wurde als Anwendung auf Basis ei-

ner Produktstandardarchitektur f¨

ur web-basierte CSCW/L-Systeme umgesetzt und die

spezifizierten Nutzungsszenarien ausnahmslos mithilfe von Konzepten der Wissensraum-

metapher rekonstruiert. Semantisch zusammenh¨

angende Einheiten des Gesamtsystems

sowie Nutzungsszenarien wurden als Komponenten gekapselt und k¨

onnen somit in ver-

schiedenen Einsatzkontexten wieder verwendet werden.

Die koaLA-Plattform soll zur Abrundung der Arbeit im Folgenden vorgestellt werden.

6.1. Die Unterst¨

utzung formaler und informeller

Lernkontexte

Werkzeuge wie Wikis, Weblogs und Podcasts stellen in Verbindung mit sozialen Netzwer-

ken den Benutzer als Produzent von Inhalten respektive seine kooperativen T¨

atigkeiten

deutlich in den Mittelpunkt. Ein Einfluss, der nicht nur beim Arbeiten, sondern auch

beim Lernen weg von vollst¨

andig vorgegebenen Strukturen und geschlossenen Syste-

men hin zu wissens- und individuumzentrierten, offenen Umgebungen f¨

uhrt. An Uni-

versit¨

aten k¨

onnen diese Werkzeuge f¨

ur eine st¨

arker konstruktivistisch gepr¨

agte Lehre

und f¨

ur Lehrveranstaltungsformate wie Projektseminare, Jour-Fixe-Konzepte und Plan-

spiele eingesetzt werden, welche die Studierenden aktiv in die Lehre mit einbeziehen

(vgl. [HKSE03], [RHS06], [Ale06]). Die großen Potenziale dieser Werkzeuge f¨

ur die Leh-

re wurden bereits in Abschnitt 2.3.4 herausgearbeitet.

Daneben besteht aber immer noch Bedarf, sowohl die Elemente der Pr¨

ufungsord-

nungen wie Module, Veranstaltungen, Seminare etc., die den organisatorischen Rahmen

darstellen, als auch klassische Lehrformen wie beispielsweise der Frontalunterricht in

Massenveranstaltungen mithilfe von Computern zu unterst¨

utzen. Hierzu sind Konzepte

zu implementieren, in denen Prozessstrukturen und die Organisation von Gruppen und

1Low-cost Multimedia Organisation & Production, ein prozessorientiertes Vorhaben der Universit¨

Paderborn zur alltagstauglichen Erschließung und nachhaltigen Verankerung digitaler Medien in

allen Bereichen ihrer Lehr- und Lernpraxis (F¨

orderkennzeichen: 01 PI 05013). Weitere Informationen

zum Locomotion-Projekt unter http://locomotion.uni-paderborn.de/. Letzter Zugriff: 31.07.2008.

2Die Lern- und Arbeitsplattform koaLA (”ko-aktives Lernen und Arbeiten“) ist unter der Adresse

http://koala.uni-paderborn.de/ online verf¨

ugbar. Letzter Zugriff: 31.07.2008.

209

6. koaLA – Integrierte Lern- und Arbeitswelten f¨

ur die Universit¨

at 2.0

Inhalten stark vorgegeben sind. Diese beiden Extreme, die selbst gew¨

ahlten Gruppen-

strukturen wie Lerngruppen und Arbeitsgemeinschaften sowie Web 2.0-Werkzeuge auf

der einen und die durchstrukturierten und fest vorgegebenen Organisationskonzepte des

Lehrveranstaltungsmanagements auf der anderen Seite spannen den Spezifikationsraum

der zu unterst¨

utzenden kooperativen Lern- und Arbeitsszenarien auf. Soll der Lernen-

de im Zentrum einer Lern- und Arbeitsumgebung stehen, muss dieser dar¨

uber hinaus

seine eigenen Prozesse der Wissensschaffung selbst koordinieren und leicht zwischen

verschiedenen individuellen, kooperativen sowie strukturierten und selbstorganisierten

Kontexten wechseln k¨

onnen (vgl. Abb. 6.1).

Abbildung 6.1.: Einf¨

ugen aus der Zwischenablage in den eigenen Arbeitsraum

Zur Umsetzung der koaLA-Plattform wurden dazu Komponenten einer Architektur mit-

einander kombiniert, die verschiedene Variationspunkte als Konfigurationsm¨

oglichkeiten

anbieten, insbesondere in der Ausgestaltung virtueller Wissensr¨

aume und Organisations-

formen (vgl. hierzu auch [RH05]).

6.1.1. Konfigurierbare Wissensr¨

aume

Materialzentrierte Lernszenarien fokussieren vor allem das (kooperative) Arbeiten mit

Informationen in Form von Lernobjekten und Dokumenten. Die didaktische Spannweite

ist dabei groß. Sie reicht von der einfachen Rezeption vom Dozenten ins Netz gestell-

ter Informationen bis hin zur selbstorganisierten Projektgruppe. Um auf dieser Skala

verschiedene Szenarien unterst¨

utzen zu k¨

onnen, wurden sechs grundlegende Variations-

punkte von virtuellen Wissensr¨

aumen identifiziert:

Zugriffsvorbedingung Die Zugriffsvorbedingung koppelt die Zugriffsrechte an Materiali-

en im Raum an ein Systemereignis. Beispiel: Studierende m¨

ussen zuerst ein eigenes

210

6.1. Die Unterst¨

utzung formaler und informeller Lernkontexte

Dokument abgeben, bevor sie auf die Dokumente der ihrer Kommilitonen Zugriff

erhalten.

Zeitpunkt Die Konfiguration eines Zeitpunktes umfasst neben dem Zeitpunkt selbst die

Konfiguration des Raums vor und nach dem Zeitpunkt. Beispiel: Innerhalb einer

Abgabefrist k¨

onnen Dokumente im Raum abgelegt werden, danach wird das daf¨

notwendige Einf¨

ugerecht entzogen.

Kommentierbarkeit Materialien im Raum k¨

onnen objektbezogen von Benutzern kom-

mentiert werden. Dies kann (a) personifiziert oder (b) anonym erlaubt oder (c)

ganz untersagt sein. Beispiel: Kommentare k¨

onnen anonym abgegeben werden.

Hemmnisse k¨

onnen in Lernszenarien auftreten, in denen Studierende ihre Arbei-

ten gegenseitig zu bewerten haben. Hierbei kann eine anonyme Kommentarfunk-

tion den Teilnehmern helfen, Kritik zu ¨

außern. Dahingegen k¨

onnen personifizierte

Kommentare in didaktischen Szenarien wie der Projektmethode sinnvoll sein.

Darstellung Materialien von Studierenden k¨

onnen anonym oder mit Nennung des Na-

mens dargestellt werden. Beispiel: Der Autor eines Dokuments ist f¨

ur andere Kurs-

teilnehmer nicht erkennbar, wohl aber f¨

ur den Dozenten. In Analogie zur anonymen

Kommentierbarkeit kann auch hier Hemmnissen entgegengewirkt werden, eigene

L¨

osungen zur allgemeinen Diskussion zu stellen.

Rechte f¨

ur Eigen- und Fremdmaterial Die Zugriffsrechte auf eigene Dokumente und

auf die anderer Kursteilnehmer k¨

onnen separat verwaltet werden. Die Interaktion

des Benutzers mit den Materialien wird mit den Rechten f¨

ur Lesen, Schreiben und

L¨

oschen der Dokumente reguliert. Beispiel: Nach Ablauf einer Abgabefrist wird das

L¨

oschrecht an der bereits abgegebenen eigenen L¨

osung entzogen. Leserechte auf

Dokumente der Kommilitonen sind sowohl vor als auch nach dem konfigurierten

Zeitpunkt nicht gesetzt.

Eine Konfiguration von Variationspunkten beschreibt den internen Zustand einer Kom-

ponente. Externe Abh¨

angigkeiten zwischen Komponenten sind auf die abstrakte und

einheitliche Semantik der Basisklassen beschr¨

ankt, so dass eine lose Kombination von

Szenarien erm¨

oglicht wird. Abbildung 6.2 zeigt exemplarisch einen in einem Kurssze-

nario eingebetteten virtuellen Raum, der durch seine Konfiguration verschiedene Aus-

pr¨

agungen in den Variationspunkten annehmen kann. Auf diese Art und Weise un-

terst¨

utzt koaLA in Kursr¨

aumen neben den vom Dozenten verwalteten Lektionen auch

Projektr¨

aume, M¨

oglichkeiten der ¨

Ubungszettelabgabe, Seminarr¨

aume sowie speziellere

Werkzeuge wie Wikis, Weblogs, Foren und Pyramidendiskussionen.

Durch die M¨

oglichkeit zur flexiblen Kombination der Szenarien konnten alle Werk-

zeuge, die in den virtuellen Kursr¨

aumen zur Verf¨

ugung stehen, auch in Gruppenar-

beitsr¨

aumen integriert werden. Jede Lerngruppe in koaLA kann somit bspw. ihr eigenes

Wiki, Weblog oder Forum betreiben und kann dar¨

uber hinaus noch definieren, ob es zur

Außendarstellung der Gruppe beitragen, also auch f¨

ur Nicht-Gruppenmitglieder lesbar

sein soll, oder nur f¨

ur den internen Gebrauch bestimmt ist.

211

6. koaLA – Integrierte Lern- und Arbeitswelten f¨

ur die Universit¨

at 2.0

Übergeordneter virtueller Raum

mit allg. Kursbeschreibung

Kursräume

verschiedener

Semester

Teilnehmer

Darstellung

als

Verzeichnis

Geschützter Bereich

Betreuer

Materialpool mit Verknüpfungen

zu allen im Kursdurchlauf

verwendeten Lernmaterialien

Termine oder Lektionen

als didaktische Einheiten

mit zugeordneten Materialien

Verknüpfung zu

Originaldokument

im geschützten

Bereich

"Projektordner" als

didaktische Einheit "Abgaberaum Lösungsblätter"

als didaktische Einheit

Auf der Skala der Selbststeuerung frei konfigurierbare materialorientierte Szenarien

Komponente: Skript-basierte Lehrveranstaltung

Komponenten: Virtueller Abgaberaum

Abbildung 6.2.: Kombination konfigurierbarer Komponenten zur flexiblen Un-

terst¨

utzung von Lernszenarien (aus: [RH05])

212

6.1. Die Unterst¨

utzung formaler und informeller Lernkontexte

6.1.2. Flexible Gruppenstrukturen

Individuelle Arbeitsr¨

aume als auch kooperative Arbeitsr¨

aume wie Kursr¨

aume werden

in koaLA an Benutzergruppen gebunden. Somit stellt die Gruppe ein Konzept dar, mit

dem Kommunikationsobjekte, Materialien, soziale Strukturen und zus¨

atzliche Funktio-

nen organisiert werden k¨

onnen (vgl. Abb. 6.3). Dabei sind Kursr¨

aume eine besondere

Auspr¨

agung einer Gruppe, ebenso wie private Gruppen. In Analogie zu den kombinier-

baren, raumbasierten Lernszenarien k¨

onnen verschiedene Gruppen ¨

uber eine Hierarchie

miteinander in Beziehung gesetzt werden (vgl. Abb. 6.4). Hierdurch war es m¨

oglich, zum

einen eine klare Trennung zwischen selbstorganisierten Gruppen und organisatorischen

Konzepten wie Semestern, Modulen, Veranstaltungen, ¨

Ubungsgruppen, Fakult¨

aten und

Studieng¨

angen zu definieren, zum anderen aber auch den Wechsel zwischen Gruppen –

also zwischen informellen und formalen Lernkontexten – f¨

ur den Benutzer bestm¨

oglich

zu unterst¨

utzen.

Abbildung 6.3.: Jede Gruppe verf¨

ugt ¨

uber Weblogs, Foren, Wikis und verschiedenartig

organisierte Dateir¨

aume (hier: Lektionen).

So erlaubt es koaLA jedem Benutzer eigene Gruppen anzulegen. Dabei werden an-

hand der Sichtbarkeit anderen Nutzern gegen¨

uber drei Auspr¨

agungen unterschieden:

Offentliche Gruppen sind f¨

ur jeden Benutzer sowohl im Gruppenverzeichnis als auch in

den Profilen der Teilnehmer sichtbar. Der Zugang zu einer ¨

offentlichen Gruppe kann

dabei frei oder durch ein Passwort gesch¨

utzt sein. ¨

Offentliche Gruppen mit Einladung

213

6. koaLA – Integrierte Lern- und Arbeitswelten f¨

ur die Universit¨

at 2.0

Abbildung 6.4.: Moderierte ¨

Ubungsgruppen im Rahmen einer Veranstaltung

sind ebenfalls f¨

ur jeden Nutzer sichtbar, neue Mitglieder k¨

onnen allerdings ausschließ-

lich durch eine Einladung eines Gruppenadministrators3aufgenommen werden. Eine

private Gruppe ist nicht ¨

offentlich sichtbar. Ihre Mitgliedschaft erfolgt exklusiv ¨

uber die

Einladung eines Gruppenadministrators. Unabh¨

angig vom Gruppenformat haben ihre

Administratoren erweiterte M¨

oglichkeiten der Rechtesteuerung innerhalb der Gruppe.

So k¨

onnen beispielsweise in der Materialverwaltung Bereiche eingerichtet werden, die f¨

anderen Nutzer nicht bzw. explizit schreibbar sind.

Kurse werden in koaLA manuell durch einen Semesterbetreuer4oder semi-automa-

tisch durch den Abgleich mit dem Pr¨

ufungsverwaltungssystem angelegt (vgl. S. 218).

Wie oben bereits erw¨

ahnt, sind Kurse nur eine besondere Form von Gruppen, die an

einer bestimmten Stelle in der Gruppenhierarchie ausgewiesen werden. Der Mechanis-

mus der Rechtesteuerung verh¨

alt sich daher analog zu Gruppen. Durch diese Flexibilit¨

k¨

onnen in der Praxis unterschiedlichste Veranstaltungsformate abgebildet werden: Große

Veranstaltungen mit hunderten von Teilnehmenden erfordern oft bedingt durch das di-

daktische Vorgehen andere Rechtekonfigurationen als kleine Projektseminare mit 10-20

Teilnehmenden.

Jede Gruppe stellt einen Mail-Verteiler dar, der ¨

uber das interne Nachrichtensystem

aber auch mit E-Mail-Clients bedient werden kann.

3Zum Gruppenadministrator wird automatisch der Nutzer, der die Gruppe anlegt. Er kann weitere

Administratoren f¨

ur die Gruppe benennen und – sofern mindestens ein weiterer benannt ist – selbst

von der Administratorenrolle wieder Abstand nehmen.

4Der Semesterbetreuer ist in der Lage, neue Kurse einzurichten und fehlerhaft eingerichtete zu ¨

andern

bzw. zu l¨

oschen. An der Universit¨

at Paderborn ¨

ubernimmt diese Rolle der Benutzersupport.

214

6.1. Die Unterst¨

utzung formaler und informeller Lernkontexte

6.1.3. Soziale Netzwerke

Jeder Benutzer hat in koaLA eine Profilseite, die er mit Informationen ¨

uber sich selbst

f¨

ullen kann5(vgl. Abb. 6.5). Neben den Kontaktinformationen wie E-Mail-Adresse, Te-

lefonnummer und Instant Messaging-Daten k¨

onnen weitere pers¨

onliche Daten zum Stu-

dium (Schwerpunkt und Fachbereich) und zu pers¨

onlichen Interessen angegeben werden.

Abbildung 6.5.: Profil einer koaLA-Benutzerin

Die Teilnehmenden einer Gruppe (und somit auch Kursteilnehmer) haben ¨

uber die Funk-

tion Teilnehmer Zugriff auf eine Teilnehmerliste. Die Liste sowie die mit Nutzerprofilen

verkn¨

upften, f¨

ur andere sichtbare Aktionen (Forenbeitr¨

age, Kommentare, Materialien,

etc.) bilden die Basis f¨

ur die Wahrnehmung der anderen Teilnehmer und damit f¨

ur die

virtuelle Zusammenarbeit. Der Netzwerkgedanke findet sich in den auf einer Profilseite

angezeigten ¨

offentlichen Gruppen und pers¨

onlichen Kontakten, an denen der Benutzer

teilnimmt bzw. die er best¨

atigt hat. ¨

Uber die Funktion ”als Kontakt hinzuf¨

ugen“ k¨

onnen

Benutzer untereinander ihr Kontaktnetzwerk ausbauen.

5Die Angabe der Daten ist zwar nicht verpflichtend, die Praxis hat aber gezeigt, dass diese M¨

oglichkeit

der Selbstdarstellung von etwa der H¨

alfte der Benutzer freiwillig genutzt wird.

215

6. koaLA – Integrierte Lern- und Arbeitswelten f¨

ur die Universit¨

at 2.0

6.2. Die Systemarchitektur

Die ko-aktive Lern- und Arbeitsplattform koaLA wurde als Anwendungsschicht auf dem

CSCL-Server open-sTeam umgesetzt, der grundlegende Funktionen zur Kommunikati-

on und Inhalte-Verwaltung ¨

uber Programmierschnittstellen bereitstellt. Im Kern imple-

mentiert der am Heinz Nixdorf Institut Paderborn entwickelte Server das in Abschnitt

3.2.3 vorgestellte Objektmodell virtueller Wissensr¨

aume. Der Gedanke von ”angepass-

ten Sichten“ auf virtuelle Wissensr¨

aume wird selbst bei der Integration standardisierter

Internet-Protokolle konsequent fortgesetzt: G¨

angige Kommunikations- und Infrastruk-

turprotokolle werden im Server dabei mit den semantischen Objektstrukturen zusam-

mengef¨

uhrt, wobei verschiedene Adapter raumbasierte Nachrichten oder Aktionen in

protokollgerechte Informationen ¨

ubersetzen (und vice versa). Ein Ereignissystem sorgt

f¨

ur eine Verteilung von Nachrichten an angebundene Clients.

Semantische Objektstrukturen werden ¨

uber die sTeam-Basisobjekte (vgl.

Abb. 3.8) aufgebaut und persistiert. Ein Objekt ist mit einem festem Metadatensatz

ausgezeichnet6, weitere Daten k¨

onnen jederzeit dynamisch ¨

uber set-Methoden attribu-

iert werden. Das Auslesen der Daten erfolgt analog dazu ¨

uber get-Methoden. Durch

diese und wenige weitere Fabrik- und Objektmethoden wie create und delete ist das

Datenmanagement f¨

ur auf sTeam aufbauende Anwendungen vollst¨

andig gekapselt.

Die darauf aufbauenden koaLA-Komponenten sind in der serverseitigen Skriptsprache

PHP (Hypertext Preprocessor) entwickelt. Hierzu bietet sTeam eine vollst¨

andige Pro-

grammierschnittstelle (API). Alle in sTeam verwendeten Basisobjekte und der Groß-

teil an Funktionen und Methoden sind in Form von Proxyobjekten ¨

uber eine PHP-

Klassenbibliothek verf¨

ugbar. Hier¨

uber k¨

onnen die fachlichen Objekte der jeweils norm-

sprachlich spezifizierten Nutzungsszenarien komponiert werden, wodurch in der Regel

eine ¨

außerst effiziente und kosteng¨

unstige Umsetzung der jeweiligen Szenarien gelingt

(vgl. [HR05]). Komponenten werden durch ein zentrales Objekt identifiziert und k¨

onnen

durch verschiedene fachliche Methoden in der Schnittstelle ausgestaltet werden. Bei der

Ausf¨

uhrung des PHP-Codes erfolgt die Kommunikation mit dem sTeam-Server dann

uber den Client Object Access Layer (COAL). Der kooperative Zugriff erfolgt daher

zentral ¨

uber gemeinsame Objekte.

In der Produktarchitektur von koaLA werden mithilfe dieser Komponenten dyna-

mische Lern- und Arbeitskontexte ausgebaut, die zwar oftmals die gleichen fachlichen

Funktionen ben¨

otigen, sich aber letztendlich durch den Freiheitsgrad der Selbstorganisa-

tion voneinander unterscheiden. Die Integration von zentralen Basis- und Komplexdiens-

ten der universit¨

aren Informationsarchitektur ¨

uber offene Service-Schnittstellen erfolgt

abh¨

angig ihres Wiederverwendungsgrades zu einem Teil ¨

uber Serverkomponenten, zum

anderen in der Anwendungsschicht (siehe 6.3).

Die Pr¨

asentationsschicht der koaLA-Plattform wurde mithilfe von AJAX-Funktionen

derart ausgestaltet, dass eine einheitliche und intuitive Bedienung in Verbindung mit

einer ansprechenden Oberfl¨

ache unterst¨

utzt wird7. Somit sollen Nutzungsbarrieren ge-

6Bspw. Objektname, Beschreibung, Erzeuger, Erstellungs- und Modifizierungsdaten und Objekttyp.

7Die Mehrheit der befragten Studierenden (89 % bei n=390) empfindet koaLA als selbsterkl¨

arend und

nutzt das offizielle Beratungsangebot zur Plattform nur wenig (vgl. [G+08], S. 17ff.).

216

6.3. Integration in die hochschulweite IT-Infrastruktur

senkt und die Akzeptanz der Nutzer erh¨

oht werden. Beispielsweise kann der Betreuer

einer Lehrveranstaltung die Reihenfolge seiner Lektionen durch das Verschieben (Drag

& Drop) einzelner ¨

andern, ohne dass die Seite gespeichert und neu geladen werden muss.

Abbildung 6.6 zeigt eine Gesamt¨

ubersicht der Architektur von koaLA.

Virtuelle Wissenräume

Social Software

Communities

Tagging

Wikis

Weblogs

RSS and Podcasts

Erweiterte Benutzerschnittstellen AJAX / Rich Client Applikation

Unified

Messaging

User Awareness

Groupware

SMS

Kalender

Foren

ToDo-Lists

Web-Konferenzen

Whiteboarding

Voice Over IP

Dateiaustausch

Instant Messaging

Anwendungs-

schicht

KursverwaltungWeb Services Identitätsmanagement Lernszenarien

Shared Annotations

InfrastrukturkomponentensTeam ApplikationenWeb 2.0 Technologien Client Technologien

Bibliotheks-

systeme

Content

Repositories

Verwaltungs-

systeme

Lernplatt-

formen

Abbildung 6.6.: Die Web 2.0-Architektur der ko-aktiven Lern- und Arbeitsumgebung

koaLA

6.3. Integration in die hochschulweite IT-Infrastruktur

In Kapitel 2 wurde bereits auf die oftmals geringen Ankn¨

upfungspunkte von Lernumge-

bungen zu den Organisationskontexten der Lernenden hingewiesen (S. 26ff.). Beispiele

sind Systeme zur Studienorganisation und Verwaltung, also z. B. Systeme zur Anmel-

dung und Durchf¨

uhrung von Veranstaltungen, elektronische Seminarapparate oder die

(digitale) Bibliothek, die neben den Lernumgebungen die heterogene IT-Landschaft an

einer Universit¨

at pr¨

agen.

In koaLA wurden die in der Rahmenarchitektur beschriebenen serviceorientierten

Ans¨

atze genutzt, um f¨

ur wichtige Prozesse Medienbr¨

uche aufzuheben und Funktionen

oder Informationsobjekte anderer Systeme zu integrieren. In einem ersten Schritt wurde

ein einheitlicher Zugang zu den beteiligten Systemklassen ¨

uber den universit¨

atsweiten

Authentifizierungsdienst hergestellt. Hochschulangeh¨

orige brauchen also keinen separa-

ten neuen Zugang anlegen, um koaLA nutzen zu k¨

onnen. Darauf aufbauend wurde der

im Locomotion-Projekt ebenfalls eingef¨

uhrte elektronische Seminarapparat der hiesigen

Bibliothek angebunden. Damit sind die Informationen zu B¨

uchern und digitalen Objekte

des elektronischen Seminarapparates direkt innerhalb der Kursr¨

aume von allen Teilneh-

217

6. koaLA – Integrierte Lern- und Arbeitswelten f¨

ur die Universit¨

at 2.0

mern des Kurses im Zugriff (vgl. Abb. 6.7). ¨

Uber diese Funktion kann beispielsweise

die Verf¨

ugbarkeit der in der Bibliothek stehenden Exemplare ¨

uberpr¨

uft und digitale

Ausgaben sofort herunter geladen werden, ohne das System wechseln zu m¨

ussen.

Abbildung 6.7.: In Kursr¨

aume eingebettete Seminarapparate der Bibliothek

Als drittes System wurde das Paderborner HIS-LSF-Portal8angebunden, um eine dop-

pelte Datenerfassung bei dem Anlegen von Kursen zu vermeiden und angemeldete Teil-

nehmer zu Veranstaltungen mit den Daten in der Lern- und Arbeitsplattform zu syn-

chronisieren (vgl. [GR07]).

Dar¨

uber hinaus existieren verschiedene JSR168-kompatible Portlets, die in entsprechen-

den Portalsystemen eingebunden werden k¨

onnen und verschiedene Sichten auf Informa-

tionen in koaLA bieten9. Jedes Dateiobjekt, jeder Forenbeitrag oder Diskussionsstrang

sowie Weblogs oder Wikis k¨

onnen als RSS-Feed abonniert werden. Damit k¨

onnen Ak-

tivit¨

aten im System auch dann mitverfolgt werden, ohne dass ein Benutzer am Sys-

tem direkt angemeldet sein muss. RSS-Feeds k¨

onnen von lokalen Lesewerkzeugen (RSS

Reader), speziellen Web-Anwendungen oder Portalen abgerufen und entfernt verwaltet

werden. In koaLA selbst werden alle vom Benutzer abonnierten Feeds aggregiert auf

einer entsprechenden Seite angezeigt. Direkt nach der Systemanmeldung erscheinen die

aktuellsten zehn Neuigkeiten außerdem auf der pers¨

onlichen koaLA-Startseite.

8Hochschul-Informations-System Lehre-Studium-Forschung. Weitere Informationen auf den Webseiten

der HIS GmbH unter http://www.his.de/abt1/ab10. Letzter Zugriff: 31.07.2008.

9Zum Beispiel ¨

Ubersichten ¨

uber die im aktuellen Semester belegten Kurse und aktuelle Termine.

218

6.3. Integration in die hochschulweite IT-Infrastruktur

Als externes Nachweissystem f¨

ur E-Learning-Inhalte wurde der europ¨

aische ARIADNE-

Knowledge-Pool f¨

ur den Testbetrieb an koaLA angebunden. Wie in Abschnitt 4.2.6 be-

schrieben, k¨

onnen ¨

uber Web-Services Lerninhalte angefragt und ausgelesen werden. Die

Ergebnisse k¨

onnen in der sTeam-Persistenzschicht abgelegt und analog zu den digita-

len Informationsobjekten aus dem elektronischen Seminarapparat in allen unterst¨

utzten

Lernszenarien weiter verwendet werden. Dar¨

uber hinaus k¨

onnen eigene Inhalte ¨

uber

den ARIADNE-Pool ver¨

offentlich und damit beispielsweise anderen Hochschulen zur

Verf¨

ugung gestellt werden.

Abbildung 6.8.: Ein via Wiki-Technologie realisiertes Fachglossar f¨

ur Operations Rese-

arch/Management Science

Eine Anbindung anderer Lernplattformen an koaLA wurde im Rahmen des Locomotion-

Projekts nicht vorgenommen. Diese M¨

oglichkeit wurde jedoch bereits in einem vorheri-

gen BMBF-Projekt ”Virtuelles Studienfach Operations Research/ Management Science“

(kurz: VORMS10) vom Autor der vorliegenden Arbeit auf der gleichen Produktstandar-

darchitektur bereits implementiert (vgl. [RHS05] und [RS05]).

10Informationen ¨

uber das virtulle Studienfach VORMS findet sich im Internet unter http://www.vorms.

org. Letzter Zugriff: 31.07.2008.

219

6. koaLA – Integrierte Lern- und Arbeitswelten f¨

ur die Universit¨

at 2.0

Abbildung 6.9.: Weblogs werden vorrangig zur Ank¨

undigung und Koordination genutzt.

6.4. Die hochschulweite Einf¨

uhrung von koaLA

Die hochschulweite Einf¨

uhrung der koaLA-Umgebung erfolgt im Rahmen des Locomo-

tion-Projektes ¨

uber drei Stufen: Testbetrieb, Pilotphase und hochschulweite Einf¨

uhrung.

Zun¨

achst wurde koaLA zum Start des Wintersemester 2006/2007 f¨

ur interessierte

Studierende und Dozierende im Rahmen eines Testbetriebs eingef¨

uhrt und in 20 Veran-

staltungen als Lernmanagementsystem, Kommunikationsplattform und Gruppenarbeits-

platz genutzt. Die Dozierenden migrierten zumeist von eigenverantwortlich betriebenen

oder eigens entwickelten Plattformen zu diesem zentralen Angebot. Da die Zahl der Ver-

anstaltungen ausreichend f¨

ur einen Testbetrieb waren, wurde die neue Plattform inner-

halb der Universit¨

at zun¨

achst nicht aktiv beworben. Trotzdem wurde festgestellt, dass

nach nur zwei Wochen ca. 200 der zu diesem Zeitraum bereits angemeldeten 2000 Studie-

renden keine Kurse belegt hatten. Sie nutzten jedoch die Social Networking-Funktionen

und das Angebot, sich in eigenen Arbeitsgruppen selbst organisieren zu k¨

onnen.

Die Bandbreite der Nutzung im Rahmen der Lehre reichte von kleinen Projektsemina-

ren mit ca. 20 Teilnehmern bis zu Massenveranstaltungen mit ¨

uber 800 Teilnehmern. Hier

wurden unterschiedliche didaktische Szenarien realisiert. Die kleineren Seminare stellten

kooperative Funktionen wie eine gemeinsame Materialsammlung und Diskussionen an

220

6.5. Erfahrungen aus der Pilotbetriebsphase

Dokumenten bereit, wobei die großen Veranstaltungen eher auf die reine Materialbe-

reitstellung (Download) fokussiert waren und Foren eher zur Kl¨

arung organisatorischer

Fragen einsetzen.

Einige wenige Dozierende nutzten in der Testphase bereits Weblogs um Informationen

zur Veranstaltung zu ver¨

offentlichen und zu diskutieren. Diese Funktion wurde sowohl

von Dozierenden als auch von Studierenden als geeignete Darstellungsform f¨

ur organi-

satorische Informationen, Hilfestellungen bei ¨

Ubungsaufgaben und Motivation beschrie-

ben.

Im Pilotbetrieb, der im Sommersemester 2007 lief, wurde die Nutzung auf 70 Ver-

anstaltungen und ¨

uber 5000 Nutzer ausgebaut. Als Referenzstudieng¨

ange waren dabei

insbesondere der ”Zwei-Fach-Bachelor“ in den Kulturwissenschaften und die Informatik

angesprochen. Punktuell hatte die Plattform aber bereits auch in anderen Bereichen

Nutzer gewonnen. Neben Betrieb und Weiterentwicklung der Systeme wurden in der

Pilotphase Schulungs- und Beratungsangebote initiiert. F¨

ur die Studierenden sind die-

se im etablierten Notebook-Caf´e und bei der Schulungsinitiative doIT angesiedelt. F¨

die Lehrenden und Verwaltungsmitarbeiter wurde ein Schulungskonzept erarbeitet, das

zusammen mit der Hochschuldidaktik umgesetzt wird.

Die Ausweitung auf den hochschulweiten Einsatz fand im Wintersemester 07/08 statt.

Zum Zeitpunkt der Fertigstellung dieser Thesis im Sommersemester 2008 wurden ¨

uber

400 Veranstaltungen mit koaLA unterst¨

utzt und der 11.000 Student auf der Plattform

begr¨

ußt.

6.5. Erfahrungen aus der Pilotbetriebsphase

Im Rahmen des Locomotion-Projektes wurde die Plattform mehrmals evaluiert (bspw.

[G+08] und [Mar08]). Dabei wurde koaLA als niedrigschwelliges Angebot best¨

atigt, das

leicht zu bedienen ist und wenig bis keine Hilfestellung erfordert11. Die meisten Dozieren-

den12 denken, dass koaLA leicht zu benutzen ist (74 %) und dass die meisten Benutzer

den Umgang mit koaLA sehr schnell erlernen k¨

onnen (85 %). Nur ein geringer Prozent-

satz gab an, dass vor der Nutzung von koaLA viele Dinge erlernt werden mussten (4

%)13.

Die Mehrzahl der Dozierenden, die koaLA einsetzen, nutzen die Plattform mehrmals

pro Woche (54 %) oder ¨

ofter (17 %). Oft oder sehr oft benutzte Komponenten sind

dabei Kursr¨

aume (70 %), internes E-Mailsystem14 (39 %), Foren (28 %) und Gruppen-

arbeitsr¨

aume (25 %).

Das soziale Netzwerk (16 %), Weblogs (12 %) und Wikis (6 %) wurden weniger h¨

aufig

benutzt. Einige Dozierende gaben an, dass sie den Unterschied zwischen Foren, Weblogs

und Wikis nicht kennen. Die M¨

oglichkeit, unterschiedliche Grade der Selbstorganisation

f¨

ur Arbeitsr¨

aume und Kommunikationswerkzeuge ¨

uber einen Rechtedialog konfigurieren

zu k¨

onnen, finden die meisten Dozierenden jedoch n¨

utzlich.

11Zu den Hilfestellungen z¨

ahlt neben dem Supportangebot (telefonisch, E-Mail-basiert oder pers¨

onlich)

auch eine Online-Hilfe der Plattform, die aus verschiedenen moderierten koaLA-Foren bestand und

uber eine gesonderte Funktion auf jeder Maske verf¨

ugbar war.

12An der hier wiedergegebenen Umfrage haben 67 Dozierende teilgenommen (vgl. [Mar08]).

13Die Dozierenden sch¨

atzten sich dabei bzgl. ihrer Computer- und Internetkenntnisse als Fortgeschrit-

tene (40 %) bzw. Experten (40 %) ein. 20 % gaben nur grundlegende Kenntnisse an.

14Die Weiterleitung von internen Nachrichten an eine pers¨

onliche E-Mail-Adresse wird unterst¨

utzt.

221

6. koaLA – Integrierte Lern- und Arbeitswelten f¨

ur die Universit¨

at 2.0

Zusammenfassend l¨

asst sich feststellen, dass das System durch die Bereitstellung als

zentrales Angebot und die Integration in die IT-Infrastruktur in relativ kurzer Zeit eine

weite Verbreitung an der Hochschule gefunden hat. Die (konfigurierbaren) Grundfunk-

tionen von koaLA gen¨

ugen, um die meisten Basisszenarien in der Lehre zu unterst¨

utzen.

Um eine bestimmte Didaktik oder Organisation zu unterst¨

utzen, wurden Funktionen

der Plattform in Zusammenarbeit mit einzelnen Lehrst¨

uhlen und Fachbereichen durch

zus¨

atzliche Komponenten bereits erweitert.

Dar¨

uber hinaus ist ein Schulungsbedarf zu konstatieren, da Web 2.0-Werkzeuge wie

Wikis, Weblogs und soziale Netzwerke bislang nur von wenigen Dozierenden f¨

ur die Lehre

adaptiert wurden. Hier ist es notwendig, die Unterschiede zwischen den neuen Konzepten

zu vermitteln und den organisatorischen und didaktischen Nutzen durch entsprechende

Einsatzszenarien zu veranschaulichen.

222

7. Schlussbetrachtung

Zum Abschluss des Hauptteils der Arbeit sollen alle Ergebnisse noch einmal kurz zusam-

mengefasst werden. Daran anschließend folgt eine kritische W¨

urdigung, die insbesondere

auf den Nutzen, die Risiken und Erfolgsfaktoren des hier vorgestellten Ansatzes eingeht.

Letztendlich ergeben sich durch die vorliegende Arbeit eine Reihe von Perspektiven, die

sich weiter erforschen lassen.

7.1. Zusammenfassung

Eine organisationsweite Unterst¨

utzung von E-Learning an Pr¨

asenzhochschulen wird tech-

nologisch und organisatorisch h¨

aufig durch die große Heterogenit¨

at vorhandener Veran-

staltungsformen, Didaktiken und multimedialen Systemen erschwert. Bisherige Ans¨

atze

zur Kopplung verschiedener Lernwerkzeuge fokussieren den Funktionsumfang des daraus

entstehenden Systemverbundes, nicht die Wiederverwendbarkeit bzw. Integrationsf¨

ahig-

keit. Somit ist die Entwicklung und Integration neuer Lernwerkzeuge nur mit relativ

großem Aufwand m¨

oglich.

Diese Arbeit hat einen ganzheitlichen Ansatz aufgezeigt, mit dem kooperative Lern-

und Arbeitsumgebungen f¨

ur den universit¨

aren Einsatz entwickelt werden k¨

onnen. Der

vorgestellte Ansatz basiert auf drei Elementen:

âDer vorgestellte normsprachliche Spezifikationsrahmen umfasst eine Terminologie

aus 101 Ding-Pr¨

adikatoren und 39 Geschehnis-Pr¨

adikatoren, sowie eine auf sechs

Satzmustern beschr¨

ankte Grammatik. Es wurde gezeigt, wie Anforderungen an

statische Konzepte, Funktionalit¨

at und an Dynamik von Lernszenarien und -um-

gebungen mithilfe der Normsprache spezifiziert werden k¨

onnen.

âDas dargestellte Konzept einer komponentenorientierten E-Learning-Architektur

spezifiziert eine Plattform, die f¨

ur verschiedenste (verteilte) Anwendungen in der

Dom¨

ane des universit¨

aren E-Learnings eine geeignete Basis darstellt. Es wurde

gezeigt, wie man darauf aufbauend eine Produktarchitektur konzipiert und eine

Integration in die universit¨

are Informationsarchitektur schafft.

âDie konstruierte Methode beschreibt ein zweigeteiltes Vorgehen zur Spezifikation

und Entwicklung von Plattform und Anwendung. Sie umfasst ein Vorgehensmodell

mit 49 Prozessen, ein ausf¨

uhrliches Beschreibungsmodell, ein Rollenmodell und

eine Techniksammlung.

Zuletzt wurde die Realisierbarkeit des Ansatzes mit der an der Universit¨

at Paderborn

hochschulweit eingef¨

uhrten Lern- und Arbeitsplattform koaLA aufgezeigt.

223

7. Schlussbetrachtung

7.2. Kritische W¨

urdigung

Die Einf¨

uhrung zentraler Strategien an ¨

offentlichen Hochschulen ist durch ihre spezifische

Organisationsform – viele teilautonome Lehreinheiten mit dezentral verteilter Macht –

schwierig. Hierunter f¨

allt auch der in dieser Arbeit vorgestellte Ansatz zum Aufbau ei-

ner E-Learning-Infrastruktur, die Teil eines integrierten Informationsmanagements einer

Hochschule ist.

Im Folgenden werden daher in Anlehnung an Roth und Hoppe der Nutzen, die Risiken

und Erfolgsfaktoren des in dieser Arbeit vorgestellten Ansatzes kritisch dargestellt (vgl.

[RH06] und [RH07]).

7.2.1. Nutzen

Aus p¨

adagogisch-didaktischer Sicht muss der E-Learning-Einsatz zur Optimierung in-

dividueller Lernprozesse beitragen (vgl. [Bau03b]). Mit dem in dieser Arbeit vorgestell-

ten Ansatz kann die individuelle Anpassbarkeit an verschiedene Lernszenarien durch

vielf¨

altige Kombinationen von Komponenten erheblich verbessert werden; womit E-

Learning zielgerichteter eingesetzt werden kann. Dar¨

uber hinaus erlaubt die verwen-

dete Nutzungsmetapher virtueller Wissensr¨

aume per se ein selbstorganisiertes Lernen

und Arbeiten. Die Entwicklung der Komponente als Sicht hierauf schr¨

ankt das Maß an

Selbstorganisation nur mehr oder weniger stark ein. Dadurch k¨

onnen stark strukturierte

Lernszenarien auch mit selbstorganisierten Gruppen, Arbeitsr¨

aumen und Werkzeugen

kombiniert werden, was in Folge einen medienbruchfreien Austausch von Informationen

zwischen formalen und informellen Szenarien unterst¨

utzt und im Vergleich zu den meis-

ten existierenden Plattformen den Studierenden deutlich in den Mittelpunkt stellt. Die

Erfahrungen an der Universit¨

at Paderborn zeigen, dass diese Verbesserungen letztend-

lich die Akzeptanz von E-Learning im Allgemeinen und von einem zentral betriebenen

hochschulweiten Angebot im Besonderen erh¨

ohen k¨

onnen.

Aus technologischer Sicht muss Technologie als Mittel zum Zweck aufgabenangemessen

eingesetzt werden, um die p¨

adagogisch-didaktischen Ziele zu erreichen und Methodenef-

fizienz, Lernerfolg und Akzeptanz zu sichern. Speziell der Einsatz anerkannter Techno-

logien sowie die Verwendung von Standards und wieder verwendbaren Modulen k¨

onnen

diese Ziele gew¨

ahrleisten. Die in dieser Arbeit konzipierte Rahmenarchitektur verwendet

haupts¨

achlich Programmiersprachen-neutrale, XML-basierte Standards wie zum Beispiel

SOAP, VSQL oder XHTML. Der hier vorgestellte Ansatz ist per se auf Modularit¨

at aus-

gerichtet. Wiederverwendbarkeit bei hohem Integrationsgrad des Systems macht einen

Kernaspekt dieses Konzepts aus. Auch verteilte Komponenten sind bei verh¨

altnism¨

aßig

geringem technischen Aufwand flexibel integrierbar. Wartung und Pflege sowie Wei-

terentwicklung werden vereinfacht; ggf. ist auch ein Outsourcing der Entwicklung und

Wartung von Komponenten denkbar. Durch einfach gerichtete Abh¨

angigkeiten zwischen

Komponenten wird eine enge Kopplung zwischen Architekturelementen vermieden und

die Durchf¨

uhrung von ¨

Anderungen an einzelnen Komponenten erleichtert.

224

7.2. Kritische W¨

urdigung

Aus ¨

okonomischer Sicht hat der hier vorgestellte Ansatz im Vergleich zu anderen For-

men der Individualentwicklung langfristig positive Effekte auf alle Kostenarten, sowohl

die monet¨

ar als auch die nicht-monet¨

ar quantifizierbaren Kosten des Einsatzes von E-

Learning: Eine Unterst¨

utzung individueller Lernszenarien durch E-Learning kann durch

die verk¨

urzten Entwicklungszeiten relativ schnell bereitgestellt werden1. Netzwerkeffekte

und damit Skalenertr¨

age k¨

onnen durch einen m¨

oglichen hochschulweiten Einsatz stark

zum Tragen kommen. Mit der verk¨

urzten Entwicklungszeit ist auch eine Reduzierung

der Entwicklungskosten verbunden. Die Kosten der Bereitstellung, Wartung und Wei-

terentwicklung sind in Bezug auf die potenzielle Nutzerzahl relativ gering. Ebenfalls

beg¨

unstigt der komponentenbasierte Architekturansatz einen reduzierten Wartungsauf-

wand und eine Verbesserung der Kostensch¨

atzung.

Dar¨

uber hinaus ist eine organisatorische Integration von Service- und Verwaltungs-

leistungen sehr gut m¨

oglich. Gleichzeitig ist die Einbindung in die bestehenden orga-

nisatorischen Strukturen sowie in die bestehende technologische Infrastruktur flexibel

und kosteneffizient m¨

oglich. Zusatznutzen wird dadurch gew¨

ahrt, dass Komponenten,

Medien bzw. Konzepte hochschulweit genutzt werden k¨

onnen, die ansonsten nur an ein-

zelnen Fachbereichen oder Lehrst¨

uhlen verf¨

ugbar w¨

aren. Gleichzeitig kann durch die

Verwendung des vorgestellten Ansatzes eine Abgrenzung von anderen Bildungseinrich-

tungen erfolgen — eine Profilierung der Hochschule wird so m¨

oglich. Nicht zuletzt kann

durch Erforschung und Einsatz innovativer, zukunftsweisender Schl¨

usseltechnologien im

E-Learning die F¨

uhrungsrolle von Hochschulen ausgebaut bzw. best¨

atigt werden, was

als ¨

ubergeordnetes Nutzenpotenzial ber¨

ucksichtigt werden muss.

7.2.2. Risiken

Die komponentenbasierte, dienstorientierte Entwicklung von E-Learning-Werkzeugen ist

im Kontext universit¨

arer Informationsarchitekturen ein zukunftsweisendes Konzept, das

in Deutschland bislang nur in Pilotprojekten zum Einsatz kam. Es ist zwar auch iso-

liert an einzelnen Lehrst¨

uhlen oder Fachbereichen einsetzbar, kann seinen vollen Nutzen

jedoch nur im Zusammenhang mit Kooperationen bieten. Dabei sind nicht nur Ko-

operationen zwischen Hochschulen, sondern bereits Kooperationen auf Fakult¨

ats- oder

Lehreinheitsebene relevant.

Der Ansatz unterliegt hierbei direkten Netzwerkeffekten, da die Anzahl bereits vor-

handener Werkzeuge und Komponenten und damit indirekt auch die Anzahl der Nut-

zer als ausschlaggebend f¨

ur die Vorteile des Entwicklungsansatzes angesehen werden

m¨

ussen. Aufgrund dieser Netzwerkexternalit¨

aten kann der so genannte ”Pinguineffekt“

(vgl. [FS85]) zum Tragen kommen. Dieser Effekt besagt, dass fr¨

uhe Anwender einer neu-

en, ¨

uberlegenen Technologie nur einen geringen Nutzen ziehen, weil noch nicht gen¨

ugend

andere Nutzer daran beteiligt sind. In der Folge verharren potenzielle Anwender in ab-

wartender Haltung, wenngleich Netzwerkeffekte und Skalenertr¨

age Nutzen f¨

ur alle An-

wender bieten w¨

urden.

1Entwurf und Entwicklung der ersten zum Testbetrieb freigegebenen Version von koaLA hat auf Grund-

lage der bereits vorhandenen Standardarchitektur 4 Personenmonate gedauert. Diese hatte bereits

einen Großteil der Funktionen der aktuellen, hochschulweit ausgerollten Version.

225

7. Schlussbetrachtung

Im Zusammenhang mit dieser eventuellen Abwartehaltung kann es auch zu Akzeptanz-

problemen des neuen Ansatzes kommen. Dies kann unter anderem auch in Zusammen-

hang mit dem Know-how stehen das erforderlich ist, um den dienstorientierten Kompo-

nentenansatz zu unterst¨

utzen. Dabei ist nicht nur ein Architekturmanagement vonn¨

oten,

das neben den zu entwickelnden Anwendungsarchitekturen auch die Produktstandardar-

chitektur und die universit¨

aren Infrastrukturdienste umfasst, sondern auch die F¨

ahigkeit

gefragt, neue Komponenten auf dieser Basis zu entwickeln und zu integrieren.

Wie bei jedem Produkt, das nicht ”von der Stange“ gekauft sondern individuell ent-

wickelt wird, entsteht weiterhin Aufwand f¨

ur die Spezifikation und Entwicklung grund-

legender Basisszenarien bzw. dom¨

anenspezifischer Dienste. Hierbei ist speziell auf die

Definition von Prozessen in Lehre und Veranstaltungsorganisation zu verweisen, die sich

f¨

ur viele Dozierende schwierig gestaltet. Ohne eine grundlegende Prozess- bzw. Szena-

riendefinition lassen sich Lehrprozesse und -szenarien jedoch nur schwer effektiv und

effizient unterst¨

utzen. Der Einsatz der normsprachlichen Spezifikation hat sich hierf¨

in der Praxis jedoch als geeignetes Mittel erwiesen.

7.2.3. Erfolgsfaktoren

Die dargelegten Risiken bei der Einf¨

uhrung einer zentralen Anwendungsplattform und

einer dienstorientierten Individualentwicklung erlauben die Ableitung kritischer Erfolgs-

faktoren; jene Faktoren, die ausschlaggebend f¨

ur den erfolgreichen und damit effektiven,

effizienten und nachhaltigen Einsatz von universit¨

arem E-Learning mithilfe komponenten-

orientierter, integrativer Werkzeuge. Im Wesentlichen betreffen die im Folgenden kurz

dargestellten Erfolgsfaktoren die Probleme einer eventuellen Abwartehaltung, m¨

oglicher

Akzeptanzprobleme und gegebenenfalls fehlenden Know-hows:

Strategische Planung Die Entwicklung und Einf¨

uhrung einer dienstorientierten Kom-

ponentenarchitektur zur Unterst¨

utzung universit¨

aren E-Learnings sollte in Form eines

gute geplanten Projektes erfolgen. Essenziell ist dabei, alle beteiligten bzw. betroffe-

nen Organisationseinheiten und Personen mit ihren Anforderungen und Bed¨

urfnissen

zu ber¨

ucksichtigen und neben den technologischen auch p¨

adagogische und ¨

okonomische

Gesichtspunkte einzubeziehen. Das f¨

ur den Ansatz notwendige Change Management

sollte auf Basis eines umfassenden, konsistenten und mit allen relevanten Planungsebe-

nen abgestimmten strategischen Konzeptes erfolgen (vgl. [Hop05a]). Auch organisato-

rische Aspekte m¨

ussen dabei bedacht werden (vgl. [Hop05b]). Dies gilt insbesondere

f¨

ur Entwurf, Entwicklung, Integration, Betrieb und Support von Individualentwicklun-

gen auf Basis der Standardplattform; dies k¨

onnte als Dienstleistung bspw. von einem

Multimedia- oder E-Learning-Kompetenzzentrum angeboten und durch ein geeignetes

System verg¨

utet werden.

Systematisches Architekturmanagement Um die Komponentenentwicklung im

Spannungsfeld zwischen strategischen Zielen und den konkreten fachlichen Anforde-

rungen an ein integriertes Informationsmanagement am Campus effizient und nachhal-

tig durchf¨

uhren zu k¨

onnen, ist ein systematisches Architekturmanagement erforderlich

226

7.2. Kritische W¨

urdigung

(vgl. [Der03], [Foe03]). Hierunter ist ein Prozess zu verstehen, der ein methodisch fun-

diertes Vorgehen zur Gestaltung einer umfassenden Architektur (und ihrer Subarchitek-

turen) liefert, unter Beachtung im Vorfeld gesetzter mittel- oder langfristiger Architek-

turziele und technologischer Rahmenbedingungen. Dabei m¨

ussen zwei Ebenen betrachtet

werden: Zum einen die IT-Infrastruktur, welche die Hard- und Softwarekomponenten be-

schreibt und zum anderen die Architektur sozialer Systeme, welche die Organisationen,

Prozesse und Ressourcen betrachtet.

Zentrale Vermarktung Teil der aufbauorganisatorischen Konzeption ist auch die ¨

Uber-

legung, inwieweit die eingesetzten E-Learning-Systemkomponenten vermarktet werden

k¨

onnen und wie diese Vermarktung ggf. vonstatten gehen soll. Speziell im Hinblick auf

den komponentenorientierten, integrativen Ansatz ist eine zentrale Vermarktung erfolgs-

kritisch. Da Integrit¨

at, Wiederverwendbarkeit und Kooperation im Vordergrund dieses

Ansatzes stehen, kann nur eine Zusammenarbeit aller Akteure die Nutzenpotenziale zur

vollen Entfaltung bringen. Dies gilt nicht nur innerhalb einer Hochschule, sondern auch

nach außen, im Verbund mit anderen Bildungseinrichtungen. Zentrale Vermarktung (und

ggf. auch weitere zentrale Aufgaben und Aktivit¨

aten) k¨

onnten ebenfalls durch ein eige-

nes Multimedia- oder E-Learning-Kompetenzzentrum wahrgenommen werden (vgl. zu

dieser Auffassung auch [Bac01]). Eine Vermarktung von E-Learning-Komponenten ist

sowohl hochschulintern als auch hochschulextern denkbar; langfristig ist die verst¨

arkte

Entwicklung in Richtung eines Komponentenmarktes zu erwarten, in den Hochschulen

dann eintreten k¨

onnen.

Promotoren Um Nutzenpotenziale neuer L¨

osungen zu verdeutlichen, ist es sinnvoll,

Promotoren einzusetzen. Speziell der Hochschulleitung kommt eine große Bedeutung als

Einflussfaktor auf die Nachhaltigkeit des E-Learning-Einsatzes zu (vgl. auch [SE04]).

Entscheidungspersonen m¨

ussen voll hinter dem neu einzuf¨

uhrenden bzw. neu eingef¨

uhr-

ten System stehen und dessen erfolgreichen Einsatz ”vorleben“, um allen anderen Be-

teiligten als Vorbild zu dienen.

Qualifikationsmaßnahmen Um zu gew¨

ahrleisten, dass die Vorteile des zukunftswei-

senden Ansatzes komponentenorientierter Lernplattformen auch ausgesch¨

opft werden

k¨

onnen, muss das Wissen zur Konfiguration, Nutzung, Integration und ggf. auch Ent-

wicklung von Komponenten vorhanden sein. Speziell in Bezug auf die Definition von

Prozessen und Szenarien ist die Kompetenz notwendig, ¨

uber eine Sprache bzw. ein

Modell zur Abbildung von Lehr- und Lernszenarien zu verf¨

ugen, die als gemeinsame

Diskussionsgrundlage f¨

ur Architekten, Entwickler und Nutzer dienen kann. Um dies zu

erreichen und gleichzeitig unabh¨

angig von Dritten zu sein, sind entsprechende Qualifi-

kationsmaßnahmen f¨

ur ausgew¨

ahlte Beteiligte n¨

otig. Dadurch wird gleichzeitig positiv

auf Verst¨

andnis und Akzeptanz eingewirkt.

227

7. Schlussbetrachtung

7.3. Ausblick

Die Ziele der vorliegenden Arbeit wurden erf¨

ullt. Aus den Ergebnissen ergeben sich

jedoch gleichzeitig neue Fragestellungen technischer, organisatorischer und betriebswirt-

schaftlicher Art, die den Bedarf an weiterer Forschungsarbeit begr¨

unden.

Komponentenm¨

arkte f¨

ur E-Learning-Technologien ¨

Ahnlich wie Lerninhalte k¨

onnen

auch E-Learning-Komponenten in anderen Kontexten wieder verwendet werden. Die

Voraussetzung dazu ist ihre Interoperabilit¨

at, d. h. eine zur Architektur passende tech-

nische Basis (architectural match) und Semantik. Im Gegensatz zu Lerninhalten sind

Komponenten und Werkzeuge zumindest vom Grundsatz her didaktisch ”neutraler“,

so dass Lehrende mit anderen Zielgruppen und/oder anderen didaktischen Pr¨

aferenzen

ein solches Angebot eher ¨

ubernehmen werden als Inhalte2. Plattformen zum Austausch

von Softwarekomponenten k¨

onnten einerseits organisatorischer Natur sein, wie bspw. die

bereits in Kapitel 2 vorgestellte Open Source-Softwareb¨

orse CampusSource e.V., oder

technischer Natur, wie die von Microsoft zur Verf¨

ugung gestellte Austauschplattform

Microsoft Solution Sharing Network3,¨

uber die auf Basis von Sharepoint entwickelte E-

Learning-Komponenten zwischen Universit¨

aten ausgetauscht werden k¨

onnen. Je mehr

Universit¨

aten zuk¨

unftig auf eine serviceorientierte Umsetzung eines integrierten Cam-

pus-Managements setzen, desto eher wird sich ein Markt f¨

ur kommerzielle und freie

Softwarebausteine entwickeln, die in lokale Architekturen eingebunden werden k¨

onnen.

Die daraus resultierende Fragestellung ist, wie und unter welchen Rahmenbedingungen

sich Universit¨

aten auf einem solchen Markt behaupten wollen bzw. k¨

onnen.

Generative Programmierung Die in Kapitel 4 erarbeitete Normsprache ist zur forma-

len Anforderungsbeschreibung von Lern- und Arbeitsszenarien geeignet, die nach der

vorgestellten Methodik in entwicklungsspezifische Modellierungssprachen transformiert

und auf dieser Basis implementiert werden. Aus softwaretechnischer Sicht ist eine weitere

Formalisierung der Normsprache interessant, um von rekonstruierten Anforderungsbe-

schreibungen und einem Komponentenrepository automatisch bestehende Komponenten

konfigurieren und neue Komponenten generieren zu k¨

onnen (vgl. [CE00]).

Interne Organisation Das Management einer serviceorientierten Komponentenarchi-

tektur erfordert einen systematischen Ansatz, der einen technischen als auch organisa-

torischen Paradigmenwechsel impliziert. Die Voraussetzungen daf¨

ur sind die Sicherstel-

lung eines ganzheitlichen ¨

Uberblicks ¨

uber die technische Infrastruktur, die ¨

Ubernahme

von Planungs-, Entwicklungs- und Integrationsaufgaben von einer zentralen Stelle sowie

die Implementierung eines Verg¨

utungssystems f¨

ur entsprechende Dienstleistungen. Hier

stellt sich die Frage nach geeigneten Organisationsformen.

2Aus den vom BMBF gef¨

orderten Content-Projekten hat man u. a. das Res¨

umee gezogen, dass Lern-

inhalte unter Hochschullehrern nur in einem sehr begrenzten Umfang wieder verwendet werden.

In einschl¨

agigen Kreisen grassiert daher der Witz, dass Hochschullehrer eher die Zahnb¨

urste einer

Kollegin/eines Kollegen verwenden, als dessen Content.

3Im Internet verf¨

ugbar unter http://www.microsoft.com/ssneduca. Letzter Zugriff: 31.07.2008.

228

7.4. Fazit

Referenzimplementierungen f¨

ur verteilte Wissensr¨

aume Verbundhochschulen stellen

als virtuelle Organisationen h¨

ohere Anforderungen an die technische Umsetzung. Hierbei

ist auf Ebene der Wissensr¨

aume ebenfalls ein Verbund zu schaffen, der den Benutzern

– unabh¨

angig von der darunter liegenden Serverstruktur – einen transparenten Wechsel

zwischen lokalen und hochschul¨

ubergreifenden Rauminstanzen gew¨

ahrt. Diese Problem-

stellung umfasst neben der Mobilit¨

at auch Aspekte der Skalierbarkeit, der Verteilung

von Resourcen und der Verf¨

ugbarkeit von Servern im Verbund. Erste L¨

osungsans¨

atze

f¨

ur dieses Problem sind in [Bop06] zu finden, Referenzimplementierungen stehen aller-

dings noch aus.

7.4. Fazit

Der Paradigmenwechsel von der kooperativen IT-Versorgung hin zu einem integrierten

Informationsmanagement und dessen technische Realisierung durch serviceorientierte

Architekturen machen langfristig eine komponentenorientierte Entwicklung von Lern-

werkzeugen erforderlich. Bislang ist bis auf wenige Ausnahmen eine Wiederverwendung

von Systemkomponenten oder -modellen im universit¨

aren E-Learning nicht gegl¨

uckt.

Diese Arbeit liefert einen ganzheitlichen Ansatz. Sie stellt eine Terminologie und Gram-

matik zur bereichs¨

ubergreifenden Anforderungserhebung vor, spezifiziert eine auf den

Problembereich zugeschnittene Rahmenarchitektur und ein dazu passendes Vorgehens-

modell zur Entwicklung von E-Learning-Werkzeugen. Die Arbeit zeigt somit eine syste-

matische Herangehensweise auf, die auf dem Einsatz verf¨

ugbarer Technologien und inno-

vativer Konzepte beruht. Fehlende Bausteine werden auf die speziellen Anforderungen

universit¨

aren E-Learnings ausgerichtet und fußen auf anerkannten softwaretechnischen

Konzepten und Technologien.

Der vorgestellte systematische Ansatz wurde mit der Implementierung und Einf¨

uhrung

der hochschulweiten koaLA-Plattform an der Universit¨

at Paderborn praktisch ange-

wendet. Damit wurde im Locomotion-Projekt der Spagat geschafft, der Vielfalt von

E-Learning f¨

ur Forschung und Profilierung eine integrierende Plattform zu bieten, und

dar¨

uber hinaus allen Lehreinheiten, die dies aus eigener Kraft bzw. finanziellen Ressour-

cen nicht stemmen k¨

onnen, ein niedrigschwelliges, zentrales Angebot. So wurde bewie-

sen, dass das in dieser Thesis erarbeitete Konzept in der Praxis umsetzbar ist und als

m¨

ogliche Alternative zur Einf¨

uhrung einer klassischen, geschlossenen Lernumgebung an

Hochschulen in Betracht gezogen werden kann.

229

7. Schlussbetrachtung

230

Literaturverzeichnis

[A+02] Ackermann, J. u. a.: Vereinheitlichte Spezifikation von Fachkomponenten. Me-

morandum des Arbeitskreises 5.10.3 Komponentenorientierte betriebliche Anwen-

dungssysteme / Gesellschaft f¨

ur Informatik. 2002. – Forschungsbericht

[A+03] Anderson, T. u. a.: IMS Abstract Framework / IMS Global Lear-

ning Consortium. Version: 2003. http://www.imsglobal.org/af/afv1p0/

imsafwhitepaperv1p0.html. 2003. – White Paper

[A+07] Aumann, S. u. a.: Personalisierte Webportale f¨

ur Hochschulen. Eine Empfehlung

der DINI-AG ”Webportale” / Deutsche Initiative f¨

ur Netzwerkinformation e. V.

G¨

ottingen, 2007. – Forschungsbericht

[AJ05] Apostolopoulos, N. ; Juhnke: FUeL – FU e-Learning. In: Fellbaum, K.

(Hrsg.): Grundfragen multimedialen Lehrens und Lernens. Aachen : Shaker Ver-

lag, 2005, S. 25–34

[AKTZ04] Arnold, P. ; Kilian, L. ; Thillosen, A. ; Zimmer, G.: E-Learning, Handbuch

f¨

ur Hochschulen und Bildungszentren. N¨

urnberg : BW-Verlag, 2004

[Alb03] Albrecht, R.: E-Learning in Hochschulen. Die Implementierung von E-Learning

an Pr¨

asenzhochschulen aus hochschuldidaktischer Perspektive. Berlin : Verlag im

Internet, 2003

[Alb07] Alby, T.: Web 2.0. Konzepte, Anwendungen, Technologien. M¨

unchen, Wien :

Carl Hanser Verlag, 2007

[Ale06] Alexander, B.: Web 2.0 – A New Wave of Innovation for Teaching and Learning.

In: Educause Review (2006), S. 33–44

[AMM06] Arnold, P. ; Mayrberger, K. ; Merkt, M.: E-Learning als Prozessinnovati-

on zwischen Strategie und Didaktik. In: Seiler Schied, E. (Hrsg.) ; K¨

alin,

S. (Hrsg.) ; Sengstag, C. (Hrsg.): E-Learning – alltagstaugliche Innovation?

M¨

unster : Waxmann Verlag, 2006, S. 27–38

[And76] Anderson, J. R.: Language, memory and thought. Hillsdale, NJ, USA : Erlbaum,

1976

[And03] Andresen, A.: Komponentenbasierte Softwareentwicklung – mit MDA, UML und

XML. M¨

unchen, Wien : Hanser, 2003

[AP00] Arnold, P. ; Putz, P.: Communities of Practice als Orientierungsrahmen f¨

ur die

Gestaltung virtueller Lernumgebungen. In: Scheuermann, F. (Hrsg.): Campus

2000 – Lernen in neuen Organisationsformen. M¨

unster : Waxmann Verlag, 2000

[ASD07] ASD: ASD Simplified Technical English Specification ASD-STE 100: Internatio-

nal specifiaction for the preparation of maintenance documentation in a controlled

language / AeroSpace and Defence Industries Association of Europe. Br¨

ussel, 01

2007 (4). – Forschungsbericht

[AWKL06] Affolter, B. ; Wilding, B. ; Korner, M. ; Lautenschlager, P.: Video-

Streaming und -Podcasting – universit¨

are Bildung f¨

ur unterwegs? In: Sei-

ler Schied, E. (Hrsg.) ; K¨

alin, S. (Hrsg.) ; Sengstag, C. (Hrsg.): E-Learning

– alltagstaugliche Innovation? M¨

unster : Waxmann Verlag, 2006, S. 276–286

231

Literaturverzeichnis

[B+96] Boles, D. u. a.: Zwischenbericht der Projektgruppe Multimedia-Pr¨

asentationen

im Gesundheitswesen / Universit¨

at Oldenburg, Fachbereich Informatik. Olden-

burg, April 1996. – Forschungsbericht

[Baa99] Baacke, D.: Medienkompetenz als zentrales Operationsfeld von Projekten. In:

Handbuch Medien: Medienkompetenz – Modelle und Projekte. Bonn : Bundeszen-

trale f¨

ur Politische Bildung, 1999, S. 31–35

[Bac01] Bachmann, G.: Strategische Planung, F¨

orderprogramme und Institutionen an

Schweizer Hochschulen. In: Tagungsband 9. Europ¨

aischer Kongress und Fachmes-

se f¨

ur Bildungs- und Informationstechnologie LearnTec 2001 Bd. 2. Karlsruhe :

Karlsruher Messe- und Kongress-GmbH, 2001, S. 461–468

[Bal01] Balzert, H.: Lehrbuch der Software-Technik: Softwareentwicklung. Bd. 1. 2.

Auflage. Heidelberg, Berlin : Spektrum Verlag, 2001

[Bau03a] Baumgartner, P.: audit F¨

orderprogramm Neue Medien in der Bildung –

F¨

orderschwerpunk Hochschule / DLR Projekttr¨

ager Neue Medien in der Bildung.

St. Augustin, 2003. – Forschungsbericht

[Bau03b] Baumgartner, P.: Evaluation mediengest¨

utzten Lernens. Theorie – Logik –

Modelle. In: Kindt, M. (Hrsg.): Projektevaluation in der Lehre. Multimedia an

Hochschulen zeigt Profil(e). M¨

unster : Waxmann Verlag, 2003, S. 63–99

[Bau06a] Baudry, A.: Ein Modell zur strukturellen Beschreibung von formatierbaren Lern-

modulen f¨

ur die orthogonale Konstruktion konsistenter Lerneinheiten, Universit¨

Paderborn, Diss., 2006

[Bau06b] Baumgartner, P.: E-Learning-Szenarien. Vorarbeiten zu einer didaktischen Ta-

xonomie. In: Seiler Schied, E. (Hrsg.) ; K¨

alin, S. (Hrsg.) ; Sengstag, C.

(Hrsg.): E-Learning – alltagstaugliche Innovation? M¨

unster : Waxmann Verlag,

2006, S. 238–247

[Bau06c] Baumgartner, P.: Web 2.0: Social Software & E-Learning. In: Computer +

Personal (CoPers) 14 (2006), Nr. 8, S. 20–34

[BBSS01] Back, A. ; Bendel, O. ; Stoller-Schai, D.: E-Learning im Unternehmen.

Grundlagen – Strategien – Methoden – Technologien. Z¨

urich : Orell F¨

ussli, 2001

[BCG03] Baving, Tracy ; Cook, Donald ; Green, Trevor: Integrating the Educational

Enterprise / Department of Computer Science, University of Cape Town. 2003

(CS03-11-00). – Forschungsbericht

[BCK03] Bass, L. ; Clements, P. ; Kazman, R.: Software Architecture in Practice. 2.

Auflage. Boston, MA, USA : Addison-Wesley, 2003

[BD05] Beuschel, W. ; Draheim, S.: Potenziale kooperativer Medien f¨

ur neue Lehr-

und Lernformen – das Beispiel Weblogs. In: Fellbaum, K. (Hrsg.): Grundfragen

multimedialen Lehrens und Lernens. Aachen : Shaker Verlag, 2005, S. 225–236

[Bec03] Beck, J.: Elektronische Gesch¨

aftsprozesse mit Web Services. In: Online 2003

Messe D¨

usseldorf – Web Services: Schl¨

ussel f¨

ur eBusiness Integration. Online

GmbH, 2003

[BEF+56] Bloom, B.S. ; Engelhart, M.B. ; Furst, E.J. ; Hill, W.H. ; Krathwohl, D.R.:

Taxonomy of educational objectives. The classification of educational goals. In:

Handbook I., Cognitive Domain. New York, NY, USA : Longman, 1956

[Beu05] Beuche, D.: Softwareproduktlinien-Entwicklung mit Merkmalmodellen. In: OB-

JEKTspektrum (2005), Nr. 6, S. 74–79

[BFH+04] Brennecke, A. ; F¨

orster, A. ; Hohenhaus, M. ; Meyer, M. ; Oevel, G.

;Szegunis, J.: Pflichtenheft f¨

ur eine im Rahmen von Uni-Mobilis konzipierte

Dienste-Infrastruktur / Universit¨

at Paderborn. Paderborn, 2004. – Forschungs-

bericht

232

Literaturverzeichnis

[BG94] Bandler, R. ; Grinder, J.: Struktur der Magie: Metasprache und Psychothera-

pie. 6. Paderborn : Junfermann, 1994

[BGKT07] Bazijanec, B. ; Gausmann, O. ; Kl¨

ockner, S. ; Turowski, K.: Analyse von

Risikofaktoren bei der Einf¨

uhrung, Integration und Migration von integrierten

Informationssystemen an mittelgroßen deutschen Hochschulen. In: Gaedke, M.

(Hrsg.) ; Borgeest, R. (Hrsg.): Integriertes Informationsmanagement an Hoch-

schulen. Quo vadis Universit¨

at 2.0? Karlsruhe : Universit¨

atsverlag Karlsruhe,

2007, S. 37–53

[BHH+06] Bopp, T. ; Hampel, T. ; Hinn, R. ; L¨

utzenkirchen, F. ; Prpitsch, C. ; Rich-

ter, H.: Alltagstaugliche Mediennutzung erfordert Systemkonvergenzen in Aus-

und Weiterbildung. In: Seiler Schied, E. (Hrsg.) ; K¨

alin, S. (Hrsg.) ; Sengs-

tag, C. (Hrsg.): E-Learning – alltagstaugliche Innovation? M¨

unster : Waxmann

Verlag, 2006, S. 87–96

[BK02] Bunse, C. ; Knethen, A. von: Vorgehensmodelle kompakt. Heidelberg, Berlin :

Spektrum Verlag, 2002

[BL99] Berners-Lee, T.: Transkript der Rede von Tim Berners-Lee am 14.04.1999:

MIT Laboratory for Cmputer Science (LCS) 35th Aniversary celebrati-

ons, Cambridge Massachusetts.http://www.w3.org/1999/04/13-tbl.html.

Version: 1999, Abruf: 30.06.2008

[BLF99] Berners-Lee, T. ; Fischetti, M.: Weaving the Web. New York, NY, USA :

Harper Collings Publishers, 1999

[BLK01] BLK: Lebenslanges Lernen / Bund-L¨

ander-Kommission f¨

ur Bildungsplanung und

Forschungsf¨

orderung. Version: 2001. http://www.blk-bonn.de/papers/heft88.

pdf. Bonn, 2001 (Heft 88). – Forschungsbericht

[BLK03] BLK: Lebenslanges Lernen – ein Zwischenres¨

umee der Wissenschaftlichen Beglei-

tung / Bund-L¨

ander-Kommission f¨

ur Bildungsplanung und Forschungsf¨

orderung.

Version: 2003. http://www.blk-lll.de/LLL/LIT/NEWSLETTER(Sond).pdf. 2003.

– Forschungsbericht

[Blu98] Blumstengel, A.: Entwicklung hypermedialer Lernsysteme. Berlin : Wissen-

schaftlicher Verlag Berlin, 1998

[BMB00] BMBF: F¨

orderprogramm Neue Medien in der Bildung – Lehr- und Lernsoftware /

Bundesministerium f¨

ur Bildung und Forschung. Bonn, 2000. – Forschungsbericht

[BMB04a] BMBF: Bundesbericht Forschung 2004 / Bundesministerium f¨

ur Bildung und

Forschung. Version: 2004. http://www.bmbf.de/pub/bufo2004.pdf. Bonn/Ber-

lin, 2004. – Forschungsbericht

[BMB04b] BMBF: Kursbuch eLearning 2004 – Produkte aus dem F¨

orderprogramm / Bun-

desministerium f¨

ur Bildung und Forschung. Bonn, 2004. – Forschungsbericht

[BMRS96] Buschmann, F. ; Meunier, R. ; Rohnert, H. ; Sommerland, P.: Pattern

Oriented Software Architecture: A System of Patterns. 1. Auflage. Chichester,

UK : John Wiley & Sons, 1996

[B¨

ol02] B¨

ollert, K.: Objektorientierte Entwicklung von Software-Produktlinien zur Se-

rienfertigung von Software-Systemen, Universit¨

at Ilmenau, Diss., 2002

[B¨

on04] B¨

onkost, K. J.: Studienreform und Multimedia: Wissens-Upgrade f¨

ur die Hoch-

schullehrer. In: Krylov, A. (Hrsg.) ; Oberliesen, R. (Hrsg.): Zukunft gestalten.

Transnationaler Dialog zur Entwicklung von Bildung und Gesellschaft. National

Business Institute, 2004, S. 97–116

[Bop06] Bopp, T.: Verteilte kooperative Wissensr¨

aume, Universit¨

at Paderborn, Diss., 2006

233

Literaturverzeichnis

[Bos00] Bosch, J.: Design & Use of Software Architectures – Adopting and evolving a

product-line approach. 1. Auflage. New York, NY, USA : ACM Press, 2000

[BP94] Baumgartner, P. ; Payr, S.: Lernen mit Software. Innsbruck : ¨

Osterreichischer

Studienverlag, 1994

[BP04] Baumgartner, P. ; Preussler, A.: “Wir w¨

aren nicht hier, wo wir jetzt sind!”

Medidaprix im Spiegel der Community. In: Brake, C. (Hrsg.) ; Topper, M.

(Hrsg.) ; Wedekind, J. (Hrsg.): Der MEDIDAPRIX: Nachhaltigkeit durch Wett-

bewerb. M¨

unster : Waxmann Verlag, 2004, S. 165–176

[Br¨

a03] Br¨

annback, M.: R&D collaboration: role of Ba in knowledge creating networks.

In: Knowledge Management Reserach & Practice 1 (2003), S. 28–38

[Bre98] Bremer, G.: Genealogie von Entwicklungsschemata. In: M¨

uller-Luschnat, G.

(Hrsg.) ; Oberweis, A. (Hrsg.): Vorgehensmodelle f¨

ur die Betriebliche Anwen-

dungsentwicklung. Teubner, 1998, S. 32–59

[Bre04] Bremer, C.: E-Learning-Strategien im Spannungsfeld von Hochschulentwick-

lung, Kompetenzans¨

atzen und Anreizsystemen. In: Bremer, C. (Hrsg.) ; Kohl,

K. (Hrsg.): E-Learning Strategien – E-Learning Kompetenzen an Hochschulen.

Bielefed : AHD, 2004, S. 9–30

[Bro04] Kapitel Begriff. In: Der Brockhaus. Bd. 1. Leipzig, Mannheim : F. A. Brockhaus,

2004, S. 231

[Bru04] Brugger, R.: Auswahl und Betrieb von Lernplattformen. In: Euler, D. (Hrsg.)

;Seufert, S. (Hrsg.): E-Learning in Hochschulen und Bildungszentren. Olden-

bourg, 2004, S. 423–438

[Bue01] Buechtemann, C. F.: Perspektiven der Hochschul- und Wissenschaftspolitik –

Deutsche Nachwuchswissenschaftler in den USA / Bundesministerium f¨

ur Bildung

und Forschung. Bonn, 2001. – Forschungsbericht

[BV03] Birkh¨

olzer, T. ; Vaupel, J.: IT-Architekturen – Planung, Integration, Wartung.

Berlin-Offenbach : VDE Verlag, 2003

[BWHW05] Braun, C. ; Wortmann, F. ; Hafner, W. ; Winter, R.: Method construction

– a core approach to organizational engineering. In: SAC ’05: Proceedings of the

2005 ACM symposium on Applied computing. New York, NY, USA : ACM Press,

2005, S. 1295–1299

[Cas05] Castells, M.: Die Internet-Galaxie. Internet, Wirtschaft und Gesellschaft. 1.

Auflage. Wiesbaden : Verlag f¨

ur Sozialwissenschaften, 2005

[CB04] Carstensen, D. ; Barrios, B.: Campus 2004 – Kommen die digitalen Medien

an den Hochschulen in die Jahre? M¨

unster : Waxmann Verlag, 2004

[CE00] Czarnecki, K. ; Eisenecker, U. W.: Generative Programming – Methods, Tools,

and Applications. 1. Auflage. Boston, MA, USA : Addison-Wesley, 2000

[CET05] CETIS:The E-Learning Framework.http://www.elframework.org/framework.

Version: 2005, Abruf: 09.01.2008

[CG98] Chroust, G. ; Gr¨

unbacher, P.: Werkzeugunterst¨

utzung beim Einsatz von Vor-

gehensmodellen. In: Kneuper, R. (Hrsg.): Vorgehensmodelle f¨

ur die betriebliche

Anwendungsentwicklung. Stuttgart : Teubner, 1998

[CMO72] Cohen, M. D. ; March, J. G. ; Olsen, J. P.: A Garbage Can Model of Organi-

zational Choice. In: Administrative Science Quarterly 17 (1972), S. 1–25

[Coa91] Coad, P.: OOD Critera, Part 2. In: Journal of Object-Oriented Programming 4

(1991), S. 64–66

234

Literaturverzeichnis

[Coe02] Coenen, Olaf: E-Learning-Architektur f¨

ur universit¨

are Lehr- und Lernprozesse.

Lohmar, K¨

oln : Josef Eul Verlag, 2002

[Dav05] Davenport, T. H.: Thinking for a Living. Boston, MA, USA : Harvard Business

School Press, 2005

[Deg04] Degkwitz, A.: Das Informations-, Kommunikations- und Medienzentrum

(IKMZ) der BTU Cottbus als Infrastruktureinrichtung f¨

ur multimediales Leh-

ren und Lernen. In: Fellbaum, K. (Hrsg.): Grundfragen multimedialen Lehrens

und Lernens. Aachen : Shaker Verlag, 2004, S. 3–12

[DEH+02] Doberkat, E.-E. ; Engels, G. ; Hausmann, J. ; Lohmann, M. ; Veltmann,

C.: Anforderungen an eine eLearning-Plattform – Innovation und Integration /

Ministerium f¨

ur Schule, Wissenschaft und Forschung in NRW. Dortmund, Pa-

derborn, 2002. – Forschungsbericht

[Der03] Dern, G.: Management von IT-Architekturen. Informationssysteme im Fokus

von Architekturplanung und -entwicklung. 1. Auflage. Wiesbaden : Vieweg, 2003

[DiN99] DiNucci, D.: Fragmented Future. In: AllBusiness – Champions of Small Business

(1999), Nr. July Issue

[DIN04a] DIN: DIN PAS 1032-1:2004: Referenzmodell f¨

ur Qualit¨

atsmanagement und Qua-

lit¨

atssicherung – Planung, Entwicklung, Durchf¨

uhrung und Evaluation von Bil-

dungsprozessen und -angeboten / DIN Deutsches Institut f¨

ur Normung e. V.

Berlin, 2004. – Forschungsbericht

[DIN04b] DIN: DIN PAS 1032-2:2004: Didaktisches Objektmodell – Modellierung und

Beschreibung didaktischer Szenarien / DIN Deutsches Institut f¨

ur Normung e.

V. Berlin, 2004. – Forschungsbericht

[DL04] Dyson, P. ; Longshaw, A.: Architecting Enterprise Solutions. Patterns for High-

Capability Internet-based Systems. Weinheim : Wiley Verlag, 2004

[Dow87] Dowson, M.: Iteration in the Software Process. In: Proceedings of the 9th Int.

Conference on Software Engineering. Washington, DC, USA : IEEE Computer

Society Press, 1987

[DS07] Degkwitz, A. ; Schirmbacher, P.: Informationsinfrastrukturen im Wandel.

Informationsmanagement an deutschen Universit¨

aten. Bad Honnef : Bock und

Herchen Verlag, 2007

[D¨

ur06] D¨

urscheid, C.: Neue Lernwelten, neue Kommunikationsformen – ein Blick in

die Zukunft. In: Seiler Schied, E. (Hrsg.) ; K¨

alin, S. (Hrsg.) ; Sengstag, C.

(Hrsg.): E-Learning – alltagstaugliche Innovation? M¨

unster : Waxmann Verlag,

2006, S. 15

[Ede00] Edelmann, W.: Lernpsychologie. 6. Auflage. Kempten : K¨

oser Verlag, 2000

[Ede02] Ederleh, J.: Nachhaltigkeitsstrategien f¨

ur E-Learning im Hochschulbereich

– L¨

ander, Hochschulen, Projekte / HIS-Hochschul-Informations-System GmbH.

Hannover, 2002. – Forschungsbericht

[EGHP05] Ehlers, U. ; Goertz, L. ; Hildebrandt, B. ; Pawlowski, J.: Qualit¨

at im E-

Learning / Europ¨

aisches Zentrum f¨

ur die F¨

orderung der Berufsbildung. 2005. –

Forschungsbericht

[EKW05] Ederleh, J. ; Kleinmann, B. ; Wannemacher, K.: E-Learning-Strategien

deutscher Universit¨

aten – Fallbeispiele aus der Hochschulpraxis / Hochschul-

Informations-System. Hannover, 2005. – Forschungsbericht

[Epp01] Eppler, M. J.: Kognitive Werkzeuge als Instrumente des pers¨

onlichen Wissens-

managements. In: Reinmann-Rothmeier, G. (Hrsg.) ; Mandl, H. (Hrsg.):

Psychologie des Wissensmanagements: Perspektiven, Theorien und Methoden.

G¨

ottingen : Hogrefe, 2001, S. 251–258

235

Literaturverzeichnis

[Erp06] Erpenbeck, C.: Social Skills durch Social Software – Ein Mythos oder wie ¨

andert

sich die soziale Kompetenz durch den Einsatz von eLearning/Neuen Medien?

In: Keynote auf der 2nd EduMedia Conference 2006, 23. und 24. Mai 2006 in

Salzburg. Salzburg, 2006

[Ert01] Ertel, W.: Angewandte Kryptographie. Leipzig : Carl Hanser Verlag, 2001

[ES04] Euler, D. ; Seufert, S.: Von der Pionierphase zur nachhaltigen Implementierung

– Facetten und Zusammenh¨

ange einer p¨

adagogischen Innovation. In: Seufert,

S. (Hrsg.) ; Euler, D. (Hrsg.): E-Learning in Hochschulen und Bildungszentren.

M¨

unchen : Oldenbourg, 2004, S. 1–24

[ES05] Euler, D. ; Seufert, S.: E-Learning in Hochschulen und Bildungszentren. Ol-

denbourg, 2005

[F+02] Fischer, J. u. a.: Bausteine der Wirtschaftsinformatik: Grundlagen, Anwendung,

PC-Praxis. Berlin : Erich Schmidt Verlag, 2002

[F¨

ar94] F¨

arber, G.: Prozessrechentechnik. 3. Auflage. Berlin : Springer, 1994

[FB06] Fischer, A. ; Breiter, A.: Prozessorientiertes IT-Service-Management an Hoch-

schulen. In: Seiler Schied, E. (Hrsg.) ; K¨

alin, S. (Hrsg.) ; Sengstag, C. (Hrsg.):

E-Learning – alltagstaugliche Innovation? M¨

unster : Waxmann Verlag, 2006, S.

58–67

[FBB+99] Fowler, M. ; Beck, K. ; Brant, J. ; Opdykeand, D. R. ; Roberts, D.: Refac-

toring: Improving the Design of Existing Code. Amsterdam, NL : Addison-Wesley

Longman, 1999

[FBML98] Fischer, T. ; Biskup, H. ; M¨

uller-Luschnat, G.: Begriffliche Grundlagen f¨

Vorgehensmodelle. In: Kneuper, R. (Hrsg.): Vorgehensmodelle f¨

ur die betriebli-

che Anwendungsentwicklung. Stuttgart : Teubner, 1998

[FH77] Flechsig, K. H. ; Haller, H. D.: Einf¨

uhrung in didaktisches Handeln. Ein

Lehrbuch f¨

ur Einzel- und Gruppenarbeit. 2. Auflage. Stuttgart : Klett, 1977

[FH96] Feenstra, R. C. ; Hanson, G. H.: Globalization, Outsourcing, and Wage Ine-

quality. In: American Economic Review 86 (1996), S. 240–245

[Fie00] Fielding, R. T.: Architectural Styles and the Design of Network-based Software

Architectures. Irvine, CA, USA, University of California, Diss., 2000

[Fil05] Filß, Christian: Vergleichsmethoden f¨

ur Vorgehensmodelle. Dresden, Technische

Universit¨

at Dresden, Diplomarbeit, 2005

[FL05] Fenn, J. ; Linden, A.: Understanding Gartner’s Hype Cycles / Gartner Group.

Stamford, CT, USA, 2005. – Forschungsbericht

[FM06] Feldstein, M. ; Masson, P.: Unbolting the Chairs: Making Learning Mana-

gement Systems More Flexible.http://elearnmag.org/subpage.cfm?section=

tutorials\&article=22-1. Version: 2006, Abruf: 30.06.2008

[Foe03] Foegen, M.: Architektur und Architekturmanagement – Modellierung von Ar-

chitekturen und Architekturmanagement in der Softwareorganisation. In: HMD

– Praxis der Wirtschaftsinformatik (2003), Nr. 232

[FP04] Floyd, C. ; Pape, B.: Softwareentwicklung als Wissensprojekt. In: Pape, B.

(Hrsg.) ; Krause, D. (Hrsg.) ; Oberquelle, H. (Hrsg.): Wissensprojekte – Ge-

meinschaftliches Lernen aus didaktischer, softwaretechnischer und organisatori-

scher Sicht. M¨

unster : Waxmann Verlag, 2004, S. 389–409

[Fra94] Frank, U.: Multiperspektivische Unternehmensmodellierung – Theoretischer Hin-

tergrund und Entwurf einer objektorientierten Entwicklungsumgebung. Olden-

bourg, 1994

236

Literaturverzeichnis

[FS85] Farrell, J. ; Saloner, G.: Standardization, Compatibility, and Innovation. In:

The Rand Journal of Economics 16 (1985), S. 70–83

[G+08] Gerholz, K.-H. u. a.: Auswertung der Evaluation im koaLA Pilotbetrieb WS

07/08 / Universit¨

at Paderborn, Locomotion Projekt. Paderborn, 2008. – For-

schungsbericht

[GAO95] Garlan, D. ; Allen, R. ; Ockerbloom, J.: Architectural Mismatch: Why Reuse

is So Hard. In: IEEE Software 12 (1995), Nr. 6, S. 17–26

[GB98] Gavrilla, S. I. ; Barkley, J. F.: Formal Specification for Role Based Access

Control User/Role and Role/Role Relationship Management. In: Proceedings of

3rd ACM workshop on Role-based access control. Fairfax, VA, USA : ACM Press,

October 1998, S. 81–90

[GGA06] Gehtland, J. ; Galbraith, B. ; Almaer, D.: AJAX: Eine Pragmatische

Einf¨

uhrung in Web 2.0. M¨

unchen, Wien : Carl Hanser Verlag, 2006

[GHJV96] Gamma, E. ; Helm, R. ; Johnson, R. ; Vlissides, J.: Entwurfsmuster – Elemente

wiederkehrender objektorientierter Software. Bonn : Addison-Wesley, 1996

[GL05] Graf, S. ; List, B.: An Evaluation of Open Source E-Learning Platforms Stres-

sing Adaption Issues. In: Proceedings of 5th IEEE International Conference on

Advanced Learning Technologies (ICALT05), 2005

[Gla94] Glasersfeld, E. von: Piagets konstruktivistisches Modell: Wissen und Lernen.

In: Rusch, G. (Hrsg.) ; Schmidt, S. J. (Hrsg.): Piaget und der radikale Kon-

struktivismus. Frankfurt a. M. : Suhrkamp Verlag, 1994, S. 16–42

[GMS03] Gerhke, M. ; Meyer, M. ; Sch¨

afer, W.: Eine Rahmenarchitektur f¨

ur ver-

teilte Lehr- und Lernsysteme / CampusSource e.V. Version: 2003. http://

www.campussource.de/projekte/rahmenarchitektur.html. Hagen, Paderborn,

2003. – Forschungsbericht

[G¨

op07] G¨

opferich, S.: Textqualit¨

at steuern mit kontrollierter Sprache. Sprachstandard

oder Kontrollmechanismus? In: technische kommunikation 29 (2007), Nr. 4

[GPS93] Garzotto, F. ; Paolini, P. ; Schwabe, D.: HDM: A model-based approach to

hypertext application design. In: ACM Transactions on Information Systems 11

(1993), Nr. 1

[GR98] Greenberg, S. ; Roseman, M.: Using a Room Metaphor to Ease Transitions in

Groupware / Department of Computer Science, University of Calgary. Alberta,

Canada, 1998 (98/611/02). – Research Report

[GR07] Gossen, H. ; Roth, A.: Die Datenintegration zwischen HIS-LSF und univer-

sit¨

aren Lern- und Arbeitsplattformen – Ein Praxisbericht aus dem Locomotion

Projekt / DS&OR-Lab, Universit¨

at Paderborn. Paderborn, 2007 (WP073333). –

Arbeitspapier

[Gre03] Greiffenberg, S.: Methoden als Theorien der Wirtschaftsinformatik. In: Wirt-

schaftsinformatik Band 2 (2003), S. 947–968

[GS83] Gentner, D. ; Stevens, A.: Mental Models. Hillsdale, NJ, USA : Erlbaum, 1983

[GS96] Grob, L. ; Seufert, S.: Vorgehensmodelle bei der Entwicklung von CAL-

Software / Institut f¨

ur Wirtschaftsinformatik der Westf¨

alischen Wilhelms-

Universit¨

at M¨

unster. M¨

unster, 1996. – Forschungsbericht

[GTA05] Guicking, A. ; Tandler, P. ; Avgeriou, P.: Agilo: A Highly Flexible Groupware

Framework. In: Groupware: Design, Implementation, and Use. Berlin-Heidelberg

: Springer, 2005, S. 49–56

237

Literaturverzeichnis

[G¨

ul01] G¨

uldenberg, S.: Wissensmanagement und Wissenscontrolling in lernenden Or-

ganisationen: Ein systemtheoretischer Ansatz. 3. Auflage. Wiesbaden : Deutscher

Universit¨

ats-Verlag, 2001

[Gut94] Gutzwiller, T. A.: Das CC RIM-Referenzmodell f¨

ur den Entwurf von betriebli-

chen, transaktionsorientierten Informationssystemen. Heidelberg : Physica Ver-

lag, 1994

[Haa99] Haake, J. M.: Facilitating Orientation in Shared Hypermedia Workspaces. In:

Proceedings of Group ’99. ACM Press, 1999

[Hab80] Haberfellner, R.: Organisationsmethodik. In: Grochla, E. (Hrsg.):

Handw¨

orterbuch der Organisation. 2. Auflage. Stuttgart : Poeschel, 1980, S.

1701–1710

[H¨

af02] H¨

afele, H.: E-Learning Standards aus didaktischer Perspektive. In: Bachmann,

G. (Hrsg.) ; Haefeli, O. (Hrsg.) ; Kindt, M. (Hrsg.) ; Gesellschaft f¨

ur Medien

in der Wissenschaft (Veranst.): Campus 2002 – Die virtuelle Hochschule in der

Konsolidierungsphase. M¨

unster : Waxmann Verlag, 2002

[Ham02] Hampel, T.: Virtuelle Wissensr¨

aume – Ein Ansatz f¨

ur die kooperative Wissens-

organisation, University of Paderborn, Diss., 2002

[Ham04] Hampel, T.: Access Rights – The Keys to Cooperative Work/Learning. In:

Hicks, D.L. (Hrsg.): Metainformatics. International Symposium, MIS. Salzburg

: Springer, 2004, S. 14–31

[Ham05a] Hambach, S.: Die Entwicklung von Bildungsangeboten mit E-Learning-

Komponenten – Kategorisierung von Vorgehensmodellen. In: Rostocker Infor-

matik Berichte Heft 29 (2005), S. 49–60

[Ham05b] Hammerschall, U.: Verteilte Systeme und Anwendung. Pearson Studium, 2005

[Har03] Harrer, A.: Software Engineering Methods for re-use of Components and Design

in Educational Systems. In: International Journal of Computers & Applications

25 (2003), S. 17–23

[Has95] Hasebrook, J.: Multimedia-Psychologie: Eine neue Perspektive menschlicher

Kommunikation. Heidelberg : Spektrum Verlag, 1995

[Hau02] Haun, M.: Handbuch Wissensmanagement. 1. Auflage. Berlin : Springer, 2002

[HD02] Harrer, A. ; Devedzic, V.: Design and Analysis Patterns in ITS Architectures.

In: Moore, J. D. (Hrsg.) ; Redfield, C. (Hrsg.) ; Johnson, W. L. (Hrsg.):

Proceedings of the International Conference on Computers in Education (ICC02).

Los Alamitos, CA, USA : IEEE Computer Society Press, 2002, S. 523

[Hei03] Heidenreich, M.: Die Debatte um die Wissensgesellschaft. In: B¨

oschen, S.

(Hrsg.) ; Schulz-Schaeffer, I. (Hrsg.): Wissenschaft in der Wissensgesellschaft.

Wiesbaden : Westdeutscher Verlag, 2003

[Hel97] Hellmuth, Thomas W.: Terminologiemanagement – Aspekte einer effizienten

Kommunikation in der computerunterst¨

utzten Informationsverarbeitung, Univer-

sit¨

at Konstanz, Diss., 1997

[Hel05] Held, A.: Oracle 10g Hochverf¨

ugbarkeit – Ausfallsichere Datenbank mit RAC,

Data Guard und Flashback. M¨

unchen : Addison-Wesley, 2005

[Hes04] Hesse, F.W.: Eine kognitionspsychologische Analyse aktiven Lernens mit neuen

Medien. In: Carstensen, D. (Hrsg.) ; Barrios, B. (Hrsg.): Campus 2004 –

Kommen die digitalen Medien an den Hochschulen in die Jahre? M¨

unster :

Waxmann Verlag, 2004, S. 15–23

238

Literaturverzeichnis

[HH05] Hampel, T. ; Heckmann, P.: Deliberative Handling of Knowledge Diversity –

The Pyramid Discussion and Position-Commentary-Response Methods as Speci-

fic Views of Collaborative Virtual Knowledge Spaces. In: Proceedings of SITE

2005. Phoenix, AZ, USA, 2005

[Hil00] Hilliard, R.: An Overview of IEEE P1471, Recommended Practice for Architec-

tural Description. In: Delaware Valley Chapter. Seattle, WA, USA : International

Council of Systems Engineering (INCOSE), November 2000

[HKSE03] Hampel, T. ; Keil-Slawik, R. ; Essmann, B.: Jour Fixe – Structuring of Se-

mantic Spaces as a Didactic Concept. In: Rosset, A. (Hrsg.) ; AACE (Veranst.):

Proceedings of E-Learn 2003 AACE, AACE Press, 2003, S. 225–232

[HM97] H¨

ofling, S. ; Mandl, H.: Lernen f¨

ur die Zukunft – Lernen in der Zukunft –

Wissensmanagement in der Bildung. M¨

unchen : Hanns-Seidel-Stiftung, 1997

[HM05] Harrer, A. ; Martens, A.: Ansatz zur Definition einer Mustersprache f¨

ur Lehr-

/Lernsysteme. In: DelFI 2003, 3. Deutsche e-Learning Fachtagung der Gesell-

schaft f¨

ur Informatik. Bonn : K¨

ollen Druck + Verlag, 2005, S. 177–188

[Hop05a] Hoppe, G.: Entwicklung strategischer Einsatzkonzepte f¨

ur E-Learning an Hoch-

schulen. Lohmar, K¨

oln : Eul Verlag, 2005

[Hop05b] Hoppe, G.: Organisatorische Verankerung von E-Learning in Hochschulen. In:

Tavangarian, D. (Hrsg.) ; N¨

olting, K. (Hrsg.): Auf zu neuen Ufern! E-Learning

heute und morgen. M¨

unster : Waxmann Verlag, 2005, S. 237–246

[HPD05] Hauswirth, M. ; Podnar, I. ; Decker, S.: On P2P Collaboration Infrastruc-

tures. In: Proceedings of the 14th IEEE International Workshop on Enabling

Technologies: Infrastructures for Collaborative Enterprises. IEEE Computer So-

ciety, 2005, S. 66–71

[HPP07] H¨

uvelmeyer, J. ; Pohl, C. ; Postel, M.: Konzeption des integrierten Informa-

tionsmanagements von HIS-LSF/POS und weiteren IT-Systemen mit der Cam-

pusSource Engine / CampusSource e.V. Dortmund, 2007. – Forschungsbericht

[HR05] Hampel, T. ; Roth, A.: Rapid Development of Non-Monolithic CSCL-

Applications – About the Benefits of Using a Prescribed Terminology in Web

Programming. In: Proceedings of E-Learning in Corporate Government, Health-

care, & Higher Education. Vancouver, Canada, 2005, S. 2095–2102

[HRKK05] Hampel, T. ; Roth, A. ; Kahnwald, N. ; K¨

ohler, T.: An Adaptable Plat-

form for Evolving Communities of Practice. In: International Reports on Socio-

Informatics (IRSI). Special Issue Digital Communities 2 (2005), Nr. 2

[HS90] Halasz, F. G. ; Schwartz, M.: The Dexter Hypertext Reference Model. In:

Proceedings of the NIST Hypertext Standardization Workshop. Gaithersburg, ML,

USA : NIST, 1990, S. 95–133

[HS00] Herzum, P. ; Sims, O.: Business Component Factory: A Comprehensive Overview

of Component-Based Development for the Enterprise. Chichester, UK : John

Wiley & Sons, 2000

[HSWH07] H¨

ollrigl, T. ; Schell, F. ; Wenske, H. ; Hartenstein, H.: F¨

oderatives und

dienstorientiertes Identit¨

atsmanagement im universit¨

aren Kontext. In: Gaed-

ke, M. (Hrsg.) ; Borgeest, R. (Hrsg.): Integriertes Informationsmanagement an

Hochschulen. Quo vadis Universit¨

at 2.0? Karlsruhe : Universit¨

atsverlag Karlsru-

he, 2007, S. 75–90

[IEE01] IEEE: IEEE P1484.1/D9, 2001-11-30 Draft Standard for Learning Technology –

Learning Technology Systems Architecture (LTSA) / Learning Technology Stan-

dards Committee of the IEEE Computer Society. New York, NY, USA, 2001. –

Forschungsbericht

239

Literaturverzeichnis

[IM94] Ikeda, M. ; Mizoguchi, R.: FITS, A Framework for ITS – A computational

model of tutoring. In: Journal of Artifical Intelligence in Education 5 (1994), Nr.

3, S. 319–348

[IMS03a] IMS: IMS Digital Repositories Interoperability – Core Functions Informati-

on Model / IMS Global Learning Consortium. Version: 2003. http://www.

imsglobal.org/digitalrepositories/. 2003 (Version 1.0 Final Specification).

– Forschungsbericht

[IMS03b] IMS: IMS Learning Design Information Model / IMS Global Learning Consorti-

um. 2003. – Forschungsbericht

[ISB95] Isakowitz, T. ; Stohr, E. A. ; Balasubramaian, P.: RMM: A Methodology

for Structured Hypermedia Design. In: Communications of the ACM 38 (1995),

August, Nr. 8, S. 34–44

[Iss97] Issing, L. J. ; Issing, L. J. (Hrsg.) ; Klimsa, P. (Hrsg.): Instruktionsdesign f¨

Multimedia. Weinheim : Beltz Psychologie Verlags Union, 1997

[J¨

an04a] J¨

anig, C.: Wissensmanagement. Berlin : Springer, 2004

[Jan04b] Janneck, M.: Themenzentrierte Interaktion und Projektmethode. In: Pape,

B. (Hrsg.) ; Krause, D. (Hrsg.) ; Oberquelle, H. (Hrsg.): Wissensprojekte –

Gemeinschaftliches Lernen aus didaktischer, softwaretechnischer und organisato-

rischer Sicht. M¨

unster : Waxmann Verlag, 2004, S. 55–73

[JG07] Jaeger, M. ; Gr¨

utzmacher, J.: Weniger Freir¨

aume. Evaluation von Forschung

und Lehre im Bolognaprozess. In: Forschung & Lehre (2007), Nr. 4, S. 214

[JHM07] Juling, W. ; Hartenstein, H. ; Maurer, H.: Karlsruher Integriertes

Informations-Management KIM. In: Degkwitz, A. (Hrsg.) ; Schirmbacher,

P. (Hrsg.): Informationsinfrastrukturen im Wandel. Informationsmanagement an

deutschen Universit¨

aten. Bad Honnef : Bock und Herchen Verlag, 2007, S. 116–

129

[JIS08] JISC:e-Learning frameworks and tools programme.http://www.jisc.ac.

uk/whatwedo/programmes/elearning framework.aspx. Version: 2008, Abruf:

11.01.2008

[JL83] Johnson-Laird, P.: Mental Models. Cambridge, MA, USA : Harvard University

Press, 1983

[JN05] Jacobson, I. ; Ng, P.-W.: Aspect-Oriented Software Development with Use Cases.

Amsterdam, NL : Addison-Wesley Longman, 2005

[Kai01] Kaib, M.: Enterprise Application Integration (EAI). Gastvortrag am 08.05.2001,

Phillips Universit¨

at Marburg, 2001

[Kal03] Kaltenbaek, J.: Berliner Beitr¨

age zum E-Learning. Bd. 1: E-Learning und

Blended-Learning in der betrieblichen Weiterbildung. Berlin : Weißensee, 2003

[Kar95] Karlsson, E.-A.: Software Reuse. A Holistic Approach. Chichester, UK : John

Wiley & Sons, 1995

[KdE00] KdEG: Arbeitsdokument der Kommissionsdienststellen: Memorandum ¨

uber Le-

benslanges Lernen / Kommission der Europ¨

aischen Gemeinschaften. Br¨

ussel,

2000. – Forschungsbericht

[Keh01] Kehm, B.M.: Die Funktionserweiterung der Hochschulen durch lebenslan-

ges Lernen – Reaktionen angesichts hochkomplexer Erwartungen. In: Kehm,

B.M. (Hrsg.) ; Pasternack, P. (Hrsg.): Hochschulentwicklung als Komple-

xit¨

atsproblem. Fallstudien des Wandels. Weinheim, Basel : Beltz Verlag, 2001,

S. 122–143

240

Literaturverzeichnis

[Kei07] Keil, Reinhard: Medienqualit¨

aten beim eLearning: Vom Transport zur Trans-

formation von Wissen. In: BIBLIOTHEK Forschung und Praxis 31 (2007), Nr.

[Ker01] Kerres, M.: Multimediale und telemediale Lernumgebungen. M¨

unchen, Wien :

Oldenbourg, 2001

[Ker04a] Kerres, M.: Beyond Learning Platforms: Infrastructures for the Digital Cam-

pus. In: Proceedings of 6th International Conference on New Educational Envi-

ronments (ICNEE04), 2004

[Ker04b] Kerres, M.: Zur Integration digitaler Werkzeuge in die Hochschule. In: Kruse,

E. (Hrsg.) ; K¨

uchler, U. (Hrsg.) ; Kuhl, M. (Hrsg.): Unbegrenztes Lernen –

Lernen ¨

uber Grenzen? M¨

unster : LIT Verlag, 2004

[Ker06] Kerres, M.: Potenziale von Web 2.0 nutzen. In: Hohenstein, A. (Hrsg.) ;

Wilbers, K. (Hrsg.): Handbuch E-Learning. Expertenwissen aus Wissenschaft

und Praxis. M¨

unchen : DWD, 2006

[Ker07] Kerres, M.: Microlearning as a challenge for instructional design. In: Hug, T.

(Hrsg.) ; Lindner, M. (Hrsg.): Didactics of Microlearning. M¨

unster : Waxmann

Verlag, 2007

[KGHV04] Kirchhof, A. ; Gurzki, T. ; Hinderer, H. ; Vlachakis, J.: Was ist ein Portal?

Definition und Einsatz von Unternehmensportalen / Fraunhofer IAO. 2004. –

Forschungsbericht

[KIN00] Krogh, G. von ; Ichijo, K. ; Nonaka, I.: Enabling Knowledge Creation: How

to Unlock the Mistery of Tacit Knowledge and Release the Power of Innovation.

New York, NY, USA : Oxford University Press, 2000

[KL96] Kamlah, W. ; Lorenzen, P.: Logische Prop¨

adeutik – Vorschule des vern¨

unftigen

Redens. 3. Auflage. Stuttgart, Weimar : Metzler, 1996

[KL03] Kl¨

unter, D. ; Laser, J.: OpenLDAP einsetzen. Grundlagen, Praxiseinsatz und

Single Sign-On Mechanismen. Heidelberg : Dpunkt, 2003

[Kla04] Klassen, M.: UDDI Revisited. In: XML Magazin & Web Services (2004), Nr. 2

[Kle02] Klein, M.: Courseware Engineering – Ein Vorgehensmodell zur Erstellung von

wiederverwendbaren, hypermedialen Kursen, Universit¨

at Karlsruhe, Diss., 2002

[Kli93] Klimsa, P.: Neue Medien und Weiterbildung: Anwendung und Nutzung in Lern-

prozessen der Weiterbildung. Weinheim : Deutscher Studien Verlag, 1993

[KLT98] Kaindl, H. ; Lutz, B. ; Tippold, P.: Methodik der Softwareentwicklung. Braun-

schweig : Vieweg, 1998

[KM07] Kopp, B. ; Mandl, H.: Verteilte Kognition und ihre Bedeutung f¨

ur E-Learning.

In: Baumgartner, P. (Hrsg.) ; Reinmann, G. (Hrsg.): ¨

Uberwindung von Schran-

ken durch E-Learning. Innsbruck : Studienverlag, 2007, S. 101–119

[KNW03] Kerres, M. ; Nattland, A. ; Weckmann, H.-D.: Hybride Lernplattformen

und integriertes Informationsmanagement an der Hochschule. In: Dittrich, K.

(Hrsg.) ; Gesellschaft f¨

ur Informatik (Veranst.): Informatik 2003, Innovative In-

formatikanwendungen Bd. 2 Gesellschaft f¨

ur Informatik, 2003, S. 90–96

[Kol96] Kolb, B. ; Lippert, W. (Hrsg.): Netvertising – Werbung auf dem Internet.

D¨

usseldorf, M¨

unchen : Metropolitan, 1996

[Kop01] Koper, R.: Modeling units of study from a pedagogical perspective – The pe-

dagocial metamodel behind EML / Educational Technology Expertise Centre,

Open University of the Netherlands. 2001. – Forschungsbericht

241

Literaturverzeichnis

[K¨

os05] K¨

oster, A.: Tageb¨

ucher f¨

ur die Forschung. In: duz – Das unabh¨

angige Hoch-

schulmagazin (2005), Nr. 07/2005

[KS01] Klein, M. ; Stucky, W.: Ein Vorgehensmodell zur Erstellung virtueller Bil-

dungsinhalte. In: Wirtschaftsinformatik 43 (2001), S. 35–45

[KS05a] Keil-Slawik, R.: Dienste-Infrastrukturen als Mittel der Wissensorganisation.

In: Kerres, M. (Hrsg.) ; Keil-Slawik, R. (Hrsg.): Hochschulen im digitalen

Zeitalter: Innovationspotenziale und Strukturwandel. M¨

unster : Waxmann Verlag,

2005, S. 13–28

[KS05b] Kuszpa, M. ; Schern, E.: Mobile Learning – Modetrend oder wesentlicher Be-

standteil lebenslangen Lernens? / FernUniversit¨

at in Hagen. 2005. – Forschungs-

bericht

[Kub04] Kubicek, H.: Organisatorische Einbettung von E-Learning an deutschen Hoch-

schulen / Institut f¨

ur Informationsmanagement. Bremen, 2004. – Forschungsbe-

richt

[KZ02] Krammer, A. ; Zaha, J. M.: Komponentenfindung in monolithischen betriebli-

chen Anwendungssystemen / Lehrstuhl f¨

ur Wirtschaftsinformatik II, Universit¨

Augsburg. 2002. – Forschungsbericht

[LAGS99] Lee, S. D. ; Armitage, S. ; Groves, P. ; Stephens, C.: Online Teaching: MUDs,

MOOs, WOOs and IRC / JISC Technology Applications Programme. 1999. –

Forschungsbericht

[Lam74] Lampson, B. W.: Protection. In: ACM SIGOPS Operating Systems Review 8

(1974), Januar, Nr. 1, S. 18–24

[Lam07] Lamb, B.: Dr. Mashup – or, Why Educators Should Learn to Stop Worrying and

Love the Remix. In: Educause Review (2007), Nr. July/August, S. 12–24

[Lan66] Lane, R.E.: The Decline of Politics and Ideology in a Knowledge Society. In:

American Sociological Review 31 (1966), S. 650

[Leh98a] Lehmann, F. R.: Aktuelles Schlagwort: Normsprache. In: Informatik Spektrum

21 (1998), S. 366–367

[Leh98b] Lehmann, Frank R.: Materialsprachliche Entwicklung von Workflow-

Management-Anwendungen. In: Informationssystem-Architekturen, Rundbrief

des GI-Fachausschusses 5.2 5 Jg. (1998), Nr. 2, S. 88–94

[Lei01] Leidhold, W.: Die Wissensgesellschaft / Forschungszentrum f¨

ur Politische

Wissenschaft und Europ¨

aische Fragen. Version: 2001. http://www.politik.

uni-koeln.de/leidhold/pdf/Wissensgesellschaft.pdf. K¨

oln, 2001. – For-

schungsbericht

[Les03] Leslie, S.: Some Uses of Blogs in Education.http://www.edtechpost.ca/gems/

matrix2.gif. Version: 2003, Abruf: 25.09.2007

[Lin04] Lindner, R.: Spezifikationen, Normen und Standards f¨

ur Lernmaterialien. In:

Haake, J. (Hrsg.) ; Schwabe, G. (Hrsg.) ; Wessner, M. (Hrsg.): CSCL-

Kompendium. M¨

unchen, Wien : Oldenbourg, 2004, S. 341–356

[Lit07] Little, J. K.: Podcasting: A Teaching with Technology White Paper. In: Edu-

cause Connect (2007), Juni

[LL04] Ley, T. ; Lindstaedt, S.: Integrating Knowledge Management and eLearning:

A Competency Perspective. In: Reich, S. (Hrsg.): Digital Content Engineering

– Content Plattformen in Theorie und Praxis. Linz : Trauner Verlag, 2004, S.

42–56

242

Literaturverzeichnis

[LMW05] Lankes, J. ; Matthes, F. ; Wittenburg, A.: Architekturbeschreibung von

Anwendungslandschaften: Softwarekartographie und IEEE Std 1471-2000. In:

Liggesmeyer, P. (Hrsg.) ; Pohl, K. (Hrsg.) ; Goedicke, M. (Hrsg.): Software

Engineering 2005, Fachtagung des GI-Fachbereichs Softwaretechnik Bd. 64. Bonn

: K¨

ollen Druck + Verlag, 2005, S. 43–54

[Lor95] Lorenz, K.: Methode. In: Mittelstrass, J. (Hrsg.): Enzyklop¨

adie Philosophie

und Wissenschaftstheorie Bd. 2. Mannheim : Bibliographisches Institut, 1995, S.

876–879

[Lor00] Lorenzen, P.: Lehrbuch der konstruktiven Wissenschaftstheorie. Stuttgart, Wei-

mar : J. B. Metzler et al., 2000 (Metzler Reprint)

[LS04] Ley, T. ; Schachner, W.: eLearning Check: Sind Sie bereit f¨

ur eLearning? /

Know-Center Graz. Graz, 07/2004 2004. – Ergebnisbericht

[Luc96] Luchner: DBV-OSI-II: Projektericht Realisierungsphase. In: BIBLIOTHEKS-

DIENST (1996), Nr. 5

[Luh58] Luhn, H. P.: Automatic Creation of Literature Abstracts. In: IBM Journal of

Research and Development 2 (1958), Nr. 2, S. 159–165

[LW05] Leszczensky, Michael ; Wolter, Andr¨

a: Der Bologna-Prozess im Spiegel der

HIS-Hochschulforschung / HIS-Hochschul-Informations-System GmbH. Hanno-

ver, 2005. – Forschungsbericht

[MA07] Meister, J. ; Appelrath, H.-J.: Produktgetriebene Entwicklung von Software-

produktlinien. In: Wirtschaftsinformatik 49 (2007), Nr. 3, S. 180–187

[Man04] Mandl, H.: E-Learning – Trends und zuk¨

unftige Entwicklungen. In: Rebens-

burg, K. (Hrsg.): Grundfragen multimedialen Lehrens und Lernens; 2. Workshop

GML 2004. Norderstedt : BoD, 2004, S. 17–29

[Mar08] Marx, W.: Evaluation der koaLA-Plattform. Paderborn, Universit¨

at Paderborn,

Diplomarbeit, 2008

[Mas05] Masak, D.: Moderne Enterprise Architekturen. Berlin, Heidelberg : Springer,

2005

[Mat96] Mattson, M.: Object-Oriented Frameworks – A survey of methodological issu-

es. In: Proceedings of the 1996 Triennal IFAC World Congress. San Francisco,

California, USA : Elsevier Science, 1996, S. 259–264

[McD99] McDermott, R.: Nurturing three-dimentional communities of practice – how to

get the most out of human networks. In: Knowledge Management Review (1999),

Nr. 11/12, S. 26–29

[MG05] Messerschmidt, R. ; Grebe, R.: Zwischen vision¨

arer Euphorie und praktischer

Ern¨

uchterung. In: QUEM-Report Schriften zur beruflichen Weiterbildung (2005),

Nr. 91

[Mit06] Mitchell, P.: Wikis in education. In: Klobas, J. (Hrsg.): Wikis: Tools for

Information Work and Collaboration. Oxford, UK : Chandos Publishing, 2006,

S. 119–147

[MJ05] Malys, B. ; Juhnke, N.: Hochschulweite Integration von eLearning an der BTU

Cottbus. In: Fellbaum, K. (Hrsg.): Grundfragen multimedialen Lehrens und

Lernens. Aachen : Shaker Verlag, 2005, S. 13–24

[MK01] Mandl, H. ; Krause, U. M.: Lernkompetenz f¨

ur die Wissensgesellschaft (For-

schungsbericht Nr. 145) / Ludwig-Maximilians-Univesit¨

at, Lehrstuhl f¨

ur Empiri-

sche P¨

adagogik und P¨

adagogische Psychologie. M¨

unchen, 2001. – Forschungsbe-

richt

243

Literaturverzeichnis

[MMF07] Majer, F. ; Meinecke, J. ; Freudenstein, P.: Die Landkarte – Rahmenwerk zur

Unterst¨

utzung von Evolution und Betrieb serviceorientierter Architekturen. In:

Gaedke, M. (Hrsg.) ; Borgeest, R. (Hrsg.): Integriertes Informationsmanage-

ment an Hochschulen. Quo vadis Universit¨

at 2.0? Karlsruhe : Universit¨

atsverlag

Karlsruhe, 2007, S. 19–35

[MN96] Moser, S. ; Nierstrasz, O.: The Effect of Object-Oriented Frameworks on

Developer Productivity. In: Computer 29 (1996), Nr. 9, S. 45–51

[M¨

ol05] M¨

oller, E.: Die heimliche Medienrevolution – Wie Weblogs, Wikis und freie

Software die Welt ver¨

andern. Hannover : Heise, 2005

[Moo05] Moog, H.: IT-Dienste an Universit¨

aten und Fachhochschulen – Reorganisati-

on und Ressourcenplanung der hochschulweiten IT-Versorgung. Hannover : HIS-

Hochschul-Informations-System GmbH, 2005 (Hochschulplanung Band 178)

[Mos06] Mosel, S.: Self Directed Learning With Personal Publishing And Microcontent.

In: Hug, T. (Hrsg.) ; Lindner, M. (Hrsg.) ; Bruck, P. A. (Hrsg.): Proceedings

of Microlearning 2005. Learning & Working in New Media. Insbruck : Innsbruck

University Press, 2006, S. 99–109

[MTH98] M¨

uhlenbrock, M. ; Tewissen, F. ; Hoppe, U.: A Framework System for In-

telligent Support in Open Distributed Learning Environments. In: Journal of

Artifical Intelligence in Education (1998), Nr. 9, S. 256–274

[Nag03] Nagl, M.: EAI heißt insbesondere Integration: Schwierige Probleme und die

Rolle technischer Hilfsmittel. In: Online 2003 Messe D¨

usseldorf – Web Services:

Schl¨

ussel f¨

ur eBusiness Integration. Online GmbH, 2003

[NBS+99] Nagl, M. ; Balzert, H. ; Six, H. W. ; Sch¨

afer, W. ; Kelter, U.: Softwaretech-

nische Anforderungen an multimediale Lehr- und Lernsysteme / Forschergruppe

SofTec NRW. 1999. – Forschungsbericht

[Nie01] Niegemann, H.: Neue Lernmedien. Konzipieren, entwickeln, einsetzen. Bern :

Huber, 2001

[Nie04] Niegemann, H.: Kompendium E-Learning. Berlin : Springer, 2004

[NIS02] NISO: Information Retrieval (Z39.50): Application Service Definition and Proto-

col Specification / National Information Standards Organization. Bethesda, ML,

USA, 2002. – Forschungsbericht

[Non91] Nonaka, I.: The Knowledge-Creating Company. In: Havard Business Review

(1991), 11/12, S. 96–104

[Non94] Nonnemacher, M. G.: Schriften zum Controlling. Bd. Band 14: Informationsmo-

dellierung unter Nutzung von Referenzmodellen: Die Nutzung von Referenzmodel-

len zur Implementierung industriebetrieblicher Informationssysteme. Frankfurt a.

M. : Peter Lang Verlag, 1994

[Now05] Nowaczyk, O.: Explorationen: Ein Ansatz zur Entwicklung hochgradig interak-

tiver Lernbausteine. Paderborn : Bonifatius, 2005

[NRP00] North, K. ; Romhardt, K. ; Probst, G.: Wissensgemeinschaften – Keimzellen

lebendigen Wissensmanagements. In: io management 8 (2000), Nr. 7

[NS99] Noack, J. ; Schienmann, Bruno: Objektorientierte Vorgehensmodelle im Ver-

gleich. In: Informatik Spektrum 22 (1999), S. 166–180

[NT97] Nonaka, I. ; Takeuchi, H.: Die Organisation des Wissens – Wie japanische

Unternehmen eine brachliegende Ressource nutzbar machen. Frankfurt, New York

: Campus, 1997

244

Literaturverzeichnis

[NT01] Nonaka, I. ; Teece, D.J.: Managing Industrial Knowledge: New Perspectives on

Knowledge-Based Firms. Sage Publications, 2001

[NTK01] Nonaka, I. ; Toyama, R. ; Konno, N.: SECI, Ba and Leadershp: A Unified

Model of Dynamic Knowledge Creation. In: Nonaka, I. (Hrsg.) ; Teece, D.J.

(Hrsg.): Managing Industrial Knowledge: Creation, Transfer and Utilization. Lon-

don : Sage Publications, 2001

[OBD04] O’Murchu, I. ; Breslin, J. G. ; Decker, S.: Online Social and Business Networ-

king Communities / Digital Enterprise Research Institute, National University of

Ireland. Galway, 2004. – Forschungsbericht

[Oes04] Oestereich, B.: Objektorientierte Softwareentwicklung – Analyse und Design

mit der UML 2.0. 6. Auflage. M¨

unchen : Oldenbourg, 2004

[O’H07] O’Hear, S.: e-learning 2.0 – how Web technologies are shaping education.

www.readwriteweb.com/archives/e-learning 20.php. Version: 2007, Abruf:

30.06.2008

[OKI06] OKI: Repositories Win Through O.K.I. / Open Knowledge Initiative. 2006. –

Forschungsbericht

[O’R05] O’Reilly, T.: Web 2.0 – Design Patterns and Business Models for the Next Ge-

neration of Software.http://www.oreillynet.com/pub/a/oreilly/tim/news/

2005/09/30/what-is-web-20.html. Version: 2005, Abruf: 30.06.2008

[Ora02] Oravec, J. A.: Bookmarking the world: Weblog applications in education. In:

Journal of Adolescent and Adult Literacy 45 (2002)

[Ora03] Oravec, J. A.: Weblogs as an Emerging Genre in Higher Education. In: Journal

of Computing in Higher Education 14 (2003)

[Ort93] Ortner, E.: Informationsverarbeitung und Sprachkritik – Ein komplement¨

arer

Integrationsbereich f¨

ur Benutzer, Management und Systeme / Universit¨

at Kon-

stanz. Konstanz, 1993 (Bericht 17-93). – Forschungsbericht

[Ort95] Ortner, E.: Elemente einer methodenneutralen Konstruktionssprache f¨

ur Infor-

mationssysteme. In: Informatik Forschung und Entwicklung 10 (1995), S. 148–160

[Ort97] Ortner, E.: Methodenneutraler Fachentwurf. Stuttgart, Leipzig : Teubner, 1997

(Wirtschaftsinformatik)

[Ort98] Ortner, E.: Normsprachliche Entwicklung von Informationssystemen. In: Pohl,

K. (Hrsg.) ; Sch¨

urr, A. (Hrsg.) ; Vossen, G. (Hrsg.): Modellierung Bd. 9.

M¨

unster : CEUR-WS.org, 1998 (CEUR Workshop Proceedings)

[Ort00] Ortner, E.: Terminologiebasierte, komponentenorientierte Entwicklung von An-

wendungssystemen. In: Flatscher, R.G. (Hrsg.) ; Turowski, K. (Hrsg.): Ta-

gungsband 2. Workshop komponentenorientierter betrieblicher Anwendungssyste-

me. Wien, 2000, S. 1–20

[OWZ+05] Orlich, S. ; Werner, M. ; Zeitz, P. ; Apitzsch, J. ; Raith, C. ; Lietz, G.: Siche-

re Integration von E-Government-Anwendungen. In: E-Government-Handbuch.

Bundesamt f¨

ur Sicherheit in der Informationstechnik (BSI), 2005

[Paw01] Pawlowski, J.M.: Das Essener-Lern-Modell (ELM): Ein Vorgehensmodell zur

Entwicklung computerunterst¨

utzter Lernumgebungen, Universit¨

at Essen, Diss.,

2001

[PM02] Pfister, H. R. ; M¨

uhlenpfordt, M.: Supporting discourse in a synchronous

learning environment: The learning protocol approach. In: Proceedings of CSCL

2002. Hillsdale, NJ, USA : Erlbaum, 2002, S. 581–589

245

Literaturverzeichnis

[Poh07] Pohl, K.: Requirements Engineering – Grundlagen, Prinzipien, Techniken. 1.

Heidelberg : Dpunkt, 2007

[Pol66] Polanyi, M.: The Tacit Dimension. London, UK : Routlege & Kegan Paul, 1966

[Pol85] Polanyi, M.: Implizites Wissen. Frankfurt a. M. : Suhrkamp Verlag, 1985

[Pos07] Postel, M.: CampusSource Engine: Integrationsl¨

osung f¨

ur IT-Systeme. In:

CHECK.point eLearning (2007), 09/2007

[PR04] Pape, B. ; Rolf, A.: Integrierte Organisations- und Softwareentwicklung f¨

ur ko-

operative Lernplattformen in der Hochschule. In: Pape, B. (Hrsg.) ; Krause,

D. (Hrsg.) ; Oberquelle, H. (Hrsg.): Wissensprojekte – Gemeinschaftliches Ler-

nen aus didaktischer, softwaretechnischer und organisatorischer Sicht. M¨

unster :

Waxmann Verlag, 2004, S. 287–310

[PRH06] Pauleickhoff, F. ; Roth, A. ; Hampel, T.: Structuring Organizational Know-

ledge in Virtual Knowledge Rooms at Philips Semiconductors. In: Tochter-

mann, K. (Hrsg.) ; Maurer, H. (Hrsg.): Journal of Universal Computer Science,

Special Issue on Knowledge Management Bd. 12. Graz, 2006, S. 367–374

[Pro87] Probst, G.: Selbst-Organisation: Ordnungsprozesse in sozialen Systemen aus

ganzheitlicher Sicht. Berlin, Hamburg : Parey, 1987

[PRR03] Probst, G. ; Raub, S. ; Romhardt, K.: Wissen managen. Wie Unternehmen

ihre wertvollste Ressource optimal nutzen. 4. Auflage. Wiesbaden : Gabler, 2003

[PSBWW99] Pfister, H.R. ; Schuckmann, C. ; Beck-Wilson, J. ; Wessner, M.: The

Metaphor of Virtual Rooms in the Cooperative Learning Environment CLear.

In: Lecture Notes in Computer Science 1370 (1999), S. 107–113

[Pus04] Puschmann, T.: Prozessportale – Architektur zur Vernetzung mit Kunden und

Lieferanten. Berlin, Heidelberg : Springer, 2004

[Rad05] Rademacher, M.: CSCL mit Comets. Kooperatives Lernen an freien Online-

Tutorials. In: Fellbaum, K. (Hrsg.): Grundfragen multimedialen Lehrens und

Lernens. Aachen : Shaker Verlag, 2005, S. 187–197

[Rau04] Rauner, F.: Praktisches Wissen und berufliche Handlungskompetenz. Bremen

: Institut Technik und Bildung, Universit¨

at Bremen, 2004 (ITB - Forschungsbe-

richte 14/2004)

[RB04] Rinn, U. ; Bett, K.: Revolutioniert das ”E” die Lernszenarien an deutschen

Hochschulen? – Eine empirische Studie im Rahmen des Bundesf¨

orderprogramms

”Neue Medien in der Bildung”. In: Carstensen, D. (Hrsg.) ; Barrios, B. (Hrsg.):

Campus 2004 – Kommen die digitalen Medien an den Hochschulen in die Jahre?

M¨

unster : Waxmann Verlag, 2004, S. 428–437

[Reg04] Reglin, T.: Zwischen Effizienzversprechen und Sachzwang – Auf dem Weg zu

einer systematischen Zielreflexion im eLearning. In: E-Learning: Theorien und be-

triebliche Praxis. Fallstudien auf der betrieblichen Bildungsarbeit. K¨

oln : Institut

der deutschen Wirtschaft K¨

oln, 2004, S. 9–34

[Rei05a] Reinmann, G.: Blended Learning in der Lehrerbildung. Grundlagen f¨

ur die Kon-

zeption innovativer Lernumgebungen. Lengerich : Pabst Science Publishers, 2005

[Rei05b] Reinmann, G.: Wissensmanagement und Medienbildung – neue Spannungs-

verh¨

altnisse und Herausforderungen. In: MedienP¨

adagogik (2005), Nr. 5

[Rei07] Reinmann, G.: Bologna in Zeiten des Web 2.0. Assessment als Gestaltungsfaktor

/ Universit¨

at Augsburg, Philosophisch-Sozialwissenschaftliche Fakult¨

at. Augs-

burg, 2007 (16). – Arbeitsbericht

246

Literaturverzeichnis

[Ren03] Renzl, B.: Wissensbasierte Interaktion. Selbst-evolvierende Wissensstr¨

ome in

Unternehmen. Deutscher Universit¨

ats-Verlag, 2003

[Rep02] Reppert, I.: E-Learning: Versuchen wir es mal mit Blended Learning. In: Fi-

nancial Times Deutschland (2002), Nr. 08.02.

[RG93] Roseman, M. ; Greenberg, S.: Building Flexible Groupware Through Open

Protocols. In: Proceedings of the conference on Organizational computing systems.

New York, NY, USA : ACM Press, 1993, S. 279 – 288

[RH04] Rubart, J. ; Hampel, T.: Structuring Cooperative Spaces: From Static Templa-

tes to Self-Organization. In: Hicks, D. L. (Hrsg.): Metainformatics. International

Symposium, MIS 2003. Berlin, Heidelberg : Springer, 2004, S. 119–125

[RH05] Roth, A. ; Hampel, T.: Konfigurierbare Softwarekomponenten zur Un-

terst¨

utzung dynamischer Lern- und Arbeitsumgebungen f¨

ur virtuelle Gemein-

schaften. In: Tagungsband zum Workshop GeNeMe 2005: Gemeinschaften in

Neuen Medien. Dresden, 2005, S. 373–384

[RH06] Roth, A. ; Hoppe, G.: Approaching Heterogeneity within Educational Techno-

logy - Concepts, Risks, and Success Factors of Launching Service-oriented Ar-

chitectures. In: Pearson, E. (Hrsg.) ; Bohman, P. (Hrsg.) ; AACE (Veranst.):

Proceedings of Ed-Media 2006, 26.06.-30.-06.05, Orlando, Florida. Orlando, FL,

USA, 2006, S. 2228–2233

[RH07] Roth, A. ; Hoppe, G.: Technologische und organisatorische Aspekte von dienst-

orientierten E-Learning-Infrastrukturen an Hochschulen. In: Breitner, M.H.

(Hrsg.) ; Bruns, B. (Hrsg.) ; Lehner, F. (Hrsg.): Neue Trends im E-Learning –

Aspekte der Betriebswirtschaftslehre und Informatik. Heidelberg : Physica-Verlag,

2007

[RHG05] Roth, P. ; Hinz, D. ; Gast, C.: Integration von Learning Management in beste-

hende IT-Infrastrukturen. In: Information Management & Consulting 20 (2005),

Nr. 1, S. 69–76

[RHQ+04] Rupp, C. ; Hahn, J. ; Queins, S. ; Jeckle, M. ; Zengler, B.: UML 2 – glasklar.

M¨

unchen, Wien : Hanser, 2004

[RHS05] Roth, A. ; Hampel, T. ; Suhl, L.: Von serverzentrierten Lernobjekten zu ko-

operativen Wissensobjekten – Ein wissensbasierter Integrationsansatz verteilter

Lernplattformen am Beispiel des virtuellen Studienfachs Virtual Operations Rese-

arch/Management Science. In: Fellbaum, K. (Hrsg.): Tagungsband des 3. Work-

shops Grundfragen multimedialen Lehrens und Lernens. Aachen : Shaker Verlag,

2005, S. 177–186

[RHS06] Roth, A. ; Hampel, T. ; Strauch, T.: Supporting the Business Game of a

TV Production by LMS - About the Implementation of Highly Configurable

Submission Rooms for Various Learning Scenarios. In: Pearson, E. (Hrsg.) ;

Bohman, P. (Hrsg.) ; AACE (Veranst.): Proceedings of Ed-Media 2006, 26.06.-

30.-06.05, Orlando, Florida. Orlando, FL, USA, 2006, S. 818–823

[Ric06] Richardson, W.: Blogs, wikis, podcasts, and other powerful web tools for class-

rooms. Thousand Oaks Calif. : Corwin Press, 2006

[Roe02] Roehl, H.: Organisation des Wissens – Anleitung zur Gestaltung. Stuttgart :

Klett-Cotta, 2002

[Rog04] Rogner, L.: Weiterbildung in virtuellen Lernumgebungen – Grundlage, Entwick-

lung und Evaluation eines Konzepts, Universit¨

at Paderborn, Diss., 2004

[Rom02] Romhardt, K.: Wissensgemeinschaften – Orte lebendigen Wissensmanagements.

Z¨

urich : Versus Verlag, 2002

247

Literaturverzeichnis

[RR99] Robertson, S. ; Robertson, J.: Mastering the Requirements Process. 1. Auflage.

Amsterdam, NL : Addison-Wesley Longman, 1999

[RR03] Reinmann-Rothmeier, G.: Didaktische Innovationen durch Blended Learning.

Leitlinien anhand eines Beispiels aus der Hochschule. Bern : Huber, 2003

[RRM97] Reinmann-Rothmeier, G. ; Mandl, H.: Kompetenzen f¨

ur das Leben in einer

Wissensgesellschaft. In: H¨

ofling, S. (Hrsg.) ; Mandl, H. (Hrsg.): Lernen f¨

die Zukunft – Lernen in der Zukunft. M¨

unchen : Hanns-Seidel-Stiftung, 1997, S.

97–107

[RRM01] Reinmann-Rothmeier, G. ; Mandl, H.: Virtuelle Seminare in der Hochschule

und Weiterbildung. 1. Auflage. Bern : Huber, 2001

[RS05] Roth, A. ; Suhl, L.: Plattform¨

ubergreifende Architekturen in f¨

oderativen E-

Learning-Umgebungen. In: Breitner, M.H. (Hrsg.) ; Hoppe, G. (Hrsg.): E-

Learning – Einsatzkonzepte und Gesch¨

aftsmodelle. Heidelberg : Physica-Verlag,

2005, S. 143–152

[RSLC95] Rossi, G. ; Schwabe, D. ; Lucena, C. J. P. ; Cowan, D. D.: A Object-Oriented

Model for Designing the Human-Computer Interface Of Hypermedia Applicati-

ons. In: Fraisse, F. (Hrsg.) ; Garzotto, F. (Hrsg.) ; Isakowitz, T. (Hrsg.):

Hypermedia Design: Proceedings of the International Workshop on Hypermedia

Design. Berlin, Heidelberg : Springer, 1995

[RSS04] Roth, A. ; Scholz, M. ; Suhl, L.: Webbasiertes Lehrveranstaltungsmanagement

– Effizienzsteigerung durch horizontale Integration von Lehr-/Lerntechnologien.

In: Carstensen, D. (Hrsg.) ; Barrios, B. (Hrsg.) ; Gesellschaft f¨

ur Medien in

der Wissenschaft (Veranst.): Campus 2004 – Kommen die digitalen Medien an

den Hochschulen in die Jahre? M¨

unster : Waxmann Verlag, 2004, S. 438–449

[Rup07] Rupp, C.: Requirements-Engineering und -Management. Professionelle, iterative

Anforderungsanalyse f¨

ur die Praxis. 4. M¨

unchen : Carl Hanser Verlag, 2007

[S+00] Sherlund, B. u. a.: IEEE Recommended Practice for Architectural Description

of Software-Intensive Systems / Institute of Electric and Electronics Engineers,

Inc. Computer Society. New York, NY, USA, 2000 (Std 1471-2000). – Description

[S+04] Stepping, M. u. a.: CampusSourceEngine – Die Schnittstelle von e-Learning Sys-

temem zum HIS-GX System der HIS GmbH / CampusSource. Hagen, Hannover,

2004. – Forschungsbericht

[S+05] Simon, B. u. a.: A Simple Query Interface Specification for Learning Repositories

/ Europ¨

aisches Komitee f¨

ur Normung. 2005 (CWA 15454). – CEN Workshop

Agreement

[SAP02] SAP: Weltweite Kundenn¨

ahe gew¨

ahrleisten und Technologietrends in SAP-

L¨

osungen umsetzen / SAP AG. Walldorf : SAP, 2002. – Forschungsbericht

[Sch92] Schnupp, P.: Handbuch der Informatik. Bd. 10.1: Hypertext. M¨

unchen : Olden-

bourg, 1992

[Sch95] Schienmann, B.: Fachentwurf mit TAOS. Ein Terminologie-basierter Ansatz f¨

die Objektorientierte Spezifikation. In: Berichte der Informationswissenschaft der

Universit¨

at Konstanz (1995)

[Sch96] Schachtl, S.: Requirements for Controlled German in Industrial Applications.

In: Proceedings of the First International Workshop on Controlled Language Ap-

plications (CLAW 96). Leuven, BL, 1996, S. 143–149

[Sch97a] Schienmann, B.: Teubner-Texte zur Informatik. Bd. Bd. 20: Objektorientierter

Fachentwurf: ein terminologiebasierter Ansatz f¨

ur die Konstruktion von Anwen-

dungssystemen. Stuttgart, Leipzig : B. G. Teubner Verlagsgesellschaft, 1997

248

Literaturverzeichnis

[Sch97b] Schulmeister, R.: Grundlagen hypermedialer Lernsysteme. 2. Auflage.

M¨

unchen, Wien : Oldenbourg, 1997

[Sch00a] Schindler, Martin: Wirtschaftsinformatik. Bd. 32: Wissensmanagement in der

Projektabwicklung. Lohmar, K¨

oln : Josef Eul Verlag, 2000

[Sch00b] Schmidt, M. P.: Knowledge Communities. M¨

unchen : Addison-Wesley, 2000

[Sch01a] Schryen, G.: Komponentenorientierte Softwareentwicklung in Softwareunterneh-

men. 1. Auflage. Wiesbaden : Deutscher Universit¨

ats-Verlag, 2001

[Sch01b] Schulmeister, R.: Virtuelle Universit¨

at Virtuelles Lernen. M¨

unchen : Olden-

bourg, 2001

[Sch02] Schienmann, B.: Kontinuierliches Anforderungsmanagement. 1. M¨

unchen :

Addison-Wesley, 2002

[Sch04a] Scharsich, A.: Richtlinien ¨

uber die F¨

orderung der Entwicklung und Erprobung

von Maßnahmen der Strukturentwicklung zur Etablierung von eLearning in der

Hochschullehre im Rahmen des F¨

orderschwerpunkts Neue Medien in der Bildung

/ Bundesministerium f¨

ur Bildung und Forschung. 2004. – Forschungsbericht

[Sch04b] Schmitz, S.: E-Learning f¨

ur alle? Wie l¨

asst sich Diversit¨

at in Technik umsetzen?

In: Carstensen, D. (Hrsg.) ; Barrios, B. (Hrsg.): Campus 2004 – Kommen die

digitalen Medien an den Hochschulen in die Jahre? M¨

unster : Waxmann Verlag,

2004, S. 123–133

[Sch04c] Kapitel Einleitung. In: Sch¨

onherr, M.: Enterprise Application Integration –

Serviceorientierung und nachhaltige Architekturen. Berlin : Gito, 2004

[Sch05] Schramm, J.: SHRM workplae forecast. In: Workplace Visions (2005), Nr. Nr. 3

[Sch06] Schmidt, J.: Social Software. Onlinegest¨

utztes Informations-, Identit¨

ats- und

Beziehungsmanagement. In: Forschungsjournal Neue Soziale Bewegungen (2006),

Nr. 02.06., S. 37–46

[Sch08] Schmid, K.: Gleichheit in Vielfalt: Produktlinien in der industriellen Software-

entwicklung. In: ix (2008), Nr. 5, S. 110–114

[SE04] Seufert, S. ; Euler, D.: Nachhaltigkeit von eLearning-Innovationen. Ergebnisse

einer Delphi-Studie / SCIL St. Gallen. 2004. – Forschungsbericht

[SF01] S¨

uß, C. ; Freitag, B.: IFIS Report 2001/03: Learning Material Markup Langua-

ge LMML / Institut f¨

ur Informationssysteme und Softwaretechnik, Universit¨

Passau. 2001. – Forschungsbericht

[SH99] Stahlknecht, P. ; Hasenkamp, U.: Einf¨

uhrung in die Wirtschaftsinformatik.

9. Auflage. Berlin : Springer, 1999

[SHB04] Schmidt, C. ; Hampel, T. ; Bopp, T.: We’ve Got Mail! – Eine neue Qualit¨

der Integration von Nachrichtendiensten in die kooperative Wissensorganisation.

In: Engels, G. (Hrsg.) ; Seehusen, S. (Hrsg.): DelFI 2004, Die 2. E-Learning

Fachtagung Informatik, 2004 (Lecture Notes in Informatics), S. 211–222

[Shn83] Shneiderman, B.: Direct Manipulation: A Step Beyond Programming Langua-

ges. In: IEEE Computer 8 (1983), Nr. 16, S. 57–69

[SIF07] SIFA: Schools Interoperability Framework Implementation Specification, V.2.1

/ Schools Interoperability Framework Association. Washington, DC, USA, 2007.

– Specification

[SK03] Schwinger, W. ; Koch, N.: Modellierung von Web-Anwendungen. In: Kap-

pel, G. (Hrsg.) ; Pr¨

oll, B. (Hrsg.) ; Reich, S. (Hrsg.) ; Retschitzegger, W.

(Hrsg.): Web-Engineering. Systematische Entwicklung von Web-Anwendungen.

Heidelberg : Dpunkt, 2003, Kapitel 3, S. 49–76

249

Literaturverzeichnis

[SKRS01] Severing, E. ; Keller, C. ; Reglin, T. ; Spies, J.: Betriebliche Bildung via

Internet. Konzeption, Umsetzung und Bewertung. Eine Einf¨

uhrung f¨

ur Praktiker.

1. Auflage. Bern : Huber, 2001

[SM02] Seufert, S. ; Mayr, P.: Fachlexikon e-learning. Manager Seminare. Bonn :

Gerhard May Verlag, 2002

[SMD04] Simon, B. ; Massart, D. ; Duval, E.: Simple Query Interface Specification /

CEN/ISSS Workshop on Learning Technologies. 2004. – Forschungsbericht

[SMVAD05] Simon, B. ; Massart, D. ; Van Assche, F. ; Duval, E.: Authentication and

Session Management / CEN/ISSS Workshop on Learning Technologies. 2005. –

Forschungsbericht

[Som07] Sommerville, I.: Software Engineering. 8. Auflage. Pearson Studium, 2007

[SOP01] SOPHISTen: Die psychotherapeutischen Grundlagen des SOPHISTEN-

Regelwerks f¨

ur die nat¨

urlichsprachliche Methode / SOPHIST GmbH. N¨

urnberg,

2001. – Forschungsbericht

[SP97] Szyperski, C. ; Pfister, C.: Workshop on Component-Oriented Programming,

Summary. In: M¨

uhlh¨

auser, M. (Hrsg.): Special Issues in Object-Oriented Pro-

gramming – ECOOP96 Workshop Reader. Heidelberg : Dpunkt, 1997

[SPM99] Schwabe, D. ; Pontes, R. ; Moura, I.: OOHDM-Web: An Environment for

Implementation of Hypermedia Applications in the WWW. In: ACM SigWEB

Newsletter 8 (1999), 6, Nr. 2

[Spo07] Spool, J. M.: Web 2.0: The Power Behind the Hype. In: User Interface Engi-

neering (2007), 08/2007

[SR01] Seiler, T. B. ; Reinmann, G.: Der Wissensbegriff im Wissensmanagement: Eine

strukturgenetische Sicht. In: Reinmann, G. (Hrsg.) ; Mandl, H. (Hrsg.): Psycho-

logie des Wissensmanagements: Perspektiven, Theorien und Methoden. G¨

ottingen

: Hogrefe, 2001, S. 11–23

[SS01] Sch¨

ummer, J. ; Schuckmann, C.: Synchrone Softwarearchitekturen. In:

Schwabe, G. (Hrsg.) ; Streitz, N. A. (Hrsg.) ; Unland, R. (Hrsg.): CSCW-

Kompendium: Lehr- und Handbuch zum computergest¨

utzten kooperativen Arbei-

ten. Heidelberg : Springer, 2001, S. 297–307

[SSB04] Sauter, A. M. ; Sauter, W. ; Bender, H.: Blended Learning. Effiziente In-

tegration von E-Learning und Pr¨

asenztraining. 2. Auflage. Neuwied, Kriftel :

Luchterhand, 2004

[SSW+06] Schaeper, H. ; Schramm, M. ; Weiland, M. ; Kraft, S. ; Wolter, A.: Inter-

national vergleichende Studie zur Teilnahme an Hochschulweiterbildung / HIS-

Hochschul-Informations-System GmbH. Hannover, 2006. – Forschungsbericht

[Ste00] Steinmetz, R.: Multimedia-Technologie: Grundlagen, Komponenten und Syste-

me. 3. Auflage. Berlin, Heidelberg : Springer, 2000

[Str07] Str¨

ohlein, G.: Mobile Learning Using Mobiles: Hype or Tripe? In: Breitner,

M. H. (Hrsg.) ; Bruns, B. (Hrsg.) ; Lehner, F. (Hrsg.): Neue Trends im E-

Learning – Aspekte der Betriebswirtschaftslehre und Informatik. Heidelberg :

Physica-Verlag, 2007, S. 1–15

[Sve98] Sveiby, K. E.: Wissenskapital – Das unentdeckte Verm¨

ogen. Landsberg am Lech

: Verlag Moderne Industrie, 1998

[SVS03] Six, H. W. ; Voss, J. ; Sch¨

afer, W.: Architekturschema f¨

ur VU-Systeme /

CampusSource e.V. Version: 2003. http://www.campussource.de/projekte/

architektur vusysteme.html. Hagen, 2003. – Forschungsbericht

250

Literaturverzeichnis

[SW04] Seufert, S. ; Wessner, M.: Werkzeuge f¨

ur spezielle Lernmethoden. In: Haake,

J. (Hrsg.) ; Schwabe, G. (Hrsg.) ; Wessner, M. (Hrsg.): CSCL-Kompendium.

M¨

unchen, Wien : Oldenbourg, 2004, S. 127–136

[Tap97] Tapscott, D.: The Digital Economy: Promise and Peril In The Age of Networked

Intelligence. New York, NY, USA : McGraw-Hill, 1997

[Ter02] Tergan, S.-O.: Hypertext und Hypermedia: Konzeption, Lernm¨

oglichkeiten,

Lernprobleme. In: Issing, L. J. (Hrsg.) ; Klimsa, P. (Hrsg.): Information und

Lernen mit Multimedia. 3. Auflage. Weinheim : Beltz Verlag, 2002, S. 99–112

[TG03] Thelen, T. ; Gruber, C.: Kollaboratives Lernen mit WikiWikiWebs. In: Ker-

res, M. (Hrsg.): Digitaler Campus – vom Medienprojekt zum nachhaltigen Me-

dieneinsatz in der Hochschule. M¨

unster : Waxmann Verlag, 2003, S. 356–365

[Tha02] Thaller, G. E.: Software-Anforderungen f¨

ur Webprojekte – Vorgehensmodelle,

Spezifikation, Design. 1. Bonn : Galileo Press, 2002

[THH+96] Tulodziecki, G. ; Hagemann, W. ; Herzig, B. ; Leufen, S. ; M¨

utze, C.: Neue

Medien in den Schulen: Projekte-Konzepte-Kompetenzen. G¨

utersloh : Bertels-

mann Stiftung, 1996

[Tur99] Turowski, K.: Ordnungsrahmen f¨

ur komponentenbasierte betriebliche Anwen-

dungssysteme. In: Tagungsband des 1. Workshops Komponentenorientierte be-

triebliche Anwendungssysteme. Magdeburg : Universit¨

at Magdeburg, 1999

[Tur03] Turau, V.: Die Rolle von Web-Services im Middleware Spektrum. In: Onli-

ne 2003 Messe D¨

usseldorf – Web Services: Schl¨

ussel f¨

ur eBusiness Integration.

Online GmbH, 2003

[Tyl03] Tyler, J. G.: Digital Training Systems Architecture: Proposal for Elaboration

of the IEEE Learning Technology Systems Architecture, 1484.1 / ISO/IEC JTC1

SC36. 2003 (N0032). – Working Paper

[Vol04] Volkmer, R.: Blended Learning – Im Zeichen der Zeit. In: Baumbach, J. (Hrsg.)

;Kornmayer, E. (Hrsg.) ; Volkmer, R. (Hrsg.) ; Winter, H. (Hrsg.): Blended

Learning in der Praxis. Konzepte, Erfahrungen & ¨

Uberlegungen von Aus- und

Weiterbildungsexperten. Dreieich : IMSELBST-Verlag, 2004, S. 21–27

[V¨

ol06] V¨

olter, M.: Services, Komponenten, Modelle. In: OBJEKTspektrum (2006),

Nr. 5

[Wan07] Wannemacher, K.: Anreizsysteme zur Intensivierung von E-Teaching an Hoch-

schulen. In: Eibl, C. (Hrsg.) ; Magenheim, J. (Hrsg.) ; Schubert, S. (Hrsg.)

;Wessner, M. (Hrsg.): DeLFI 2007: 5. Deutsche e-Learning Fachtagung Infor-

matik. Bonn : K¨

ollen Druck + Verlag, 2007, S. 161–172

[WBR04] Wilson, S. ; Blinco, K. ; Rehak, D.R.: Service-Oriented Frameworks – Mo-

delling the infrastructure for the next generation of e-Learning Systems / DEST

(Australia), JISC-CETIS (UK), and Industry Canada. 2004. – Forschungsbericht

[Wei76] Weick, K. E.: Educational Organizations as Loosely Coupled Systems. In:

Administrative Science Quarterly 21 (1976), S. 1–19

[Wei93] Weidemann, B.: Instruktionsmedien / Institut f¨

ur Erziehungswissenschaft und

P¨

adagogische Psychologie, Universit¨

at der Bundeswehr. M¨

unchen, 1993. – For-

schungsbericht

[Wen98a] Wenger, E.: Communities of Practice – Learning as a social System. In: System

Thinker 6 (1998)

[Wen98b] Wenger, T.: Communities of Practice. Learning, Meaning, and Identity. Cam-

bridge, MA, USA : Cambridge Univ. Press, 1998

251

Literaturverzeichnis

[Wes01] Wessner, M.: Software f¨

ur e-Learning: Kooperative Umgebungen und Werk-

zeuge. In: Schulmeister, R. (Hrsg.): Virtuelle Universit¨

at Virtuelles Lernen.

M¨

unchen, Wien : Oldenbourg, 2001, Kapitel 7, S. 195–219

[Wie03] Wiedeking, M.: Sinn und Unsinn von Web-Services. In: Online 2003 Messe

D¨

usseldorf – Web Services: Schl¨

ussel f¨

ur eBusiness Integration. Online GmbH,

2003

[Wil06] Wilson, S.: Personal Learning Environment. In: Pushing the boundaries of the

VLE (II). Utrecht, NL, Sept. 2006 2006

[WK07] Wang, E. ; Klebl, M.: E-Learning-Standards und informelles Lernen – ein

Unverh¨

altnis? Eintrag vom 07.02.2007 im LEARNTEC-Blog. http://blog.

learntec.de/?p=82. Version: 02 2007, Abruf: 30.06.2008

[WKH+93] Weidenmann, B. ; Krapp, A. ; Hofer, M. ; Huber, G. ; Mandl, H.:

P¨

adagogische Psychologie. Weinheim, Basel : Beltz Verlag, 1993

[WL99] Weiss, D. M. ; Lai, C. T. R.: Software Product-Line Engineering – A Family-

Based Software Development Process. Reading, Masachusetts, USA : Addison-

Wesley, 1999

[WS01] Wenger, E. C. ; Snyder, W. M.: Communities of Practice: The Organizational

Frontier. In: Harvard Business Review on Organizational Learning. Boston, MA,

USA : Harvard Business School Press, 2001, S. 1–20

[XYES03] Xu, Zhengfang ; Yin, Zheng ; El Saddik, A.: A Web Services Oriented Frame-

work for Dynamic E-Learning Systems. In: Proceedings of Canadian Conference

on Electrical and Computer Engineering 2003 Bd. 2 IEEE Computer Society,

2003, S. 943–646

[Yas00] Yass, M.: Entwicklung multimedialer Anwendungen: Eine systematische

Einf¨

uhrung. Heidelberg : Dpunkt, 2000

[Zac99] Zack, M.H.: Managing Codified Knowledge. In: Sloan Management Review

Bd. 40. Cambridge, MA, USA, 1999, S. 45–58

[ZR05] Zawacki-Richter, O.: Einsatzkonzepte f¨

ur E-Learning zur Integration in nach-

haltige Supportstrukturen. In: Breitner, M. H. (Hrsg.) ; Hoppe, G. (Hrsg.): E-

Learning – Einsatzkonzepte und Gesch¨

aftsmodelle. Heidelberg : Physica-Verlag,

2005, S. 37–52

252

A. Anhang

A.1. Anfragesprachen f¨

ur Content-Repositories

A.1.1. XQuery

Die XML Query gilt in der Version 1.0 als W3C Recommendation. Sie kann zur Abfra-

ge f¨

ur XML-basierte Daten genutzt werden, aber auch f¨

ur alle anderen Datenquellen,

deren Inhalt mit Hilfe von XML repr¨

asentiert werden kann. Zur besseren Benutzbarkeit

existiert neben der XML-basierten Syntax auch eine verst¨

andliche nicht-XML-Syntax.

XQuery basiert auf dem selben Datenmodell wie XPath (XML Path Language) und

nutzt XPath-Ausdr¨

ucke zur Navigation in XML. Um Anfragen zu formulieren, erlaubt

XQuery die Bildung so genannter FLOWR-Ausdr¨

ucke1(vgl. Listing A.1.1). Weitere

Listing A.1: Beispiel f¨

ur einen FLWOR-Ausdruck in XQuery

1for $x in doc (” buecher . xml ”)/ b i b l i o t h e k /semapp

where $x/ signatur >”TQM”

3order by $x/ t i t e l

return $x/ t i t e l

XPath-Funktionen k¨

onnen dar¨

uber hinaus zur Gestaltung eigener Funktionen und Kon-

trollstrukturen f¨

ur Anfrage oder Ausgabe verwendet werden.

Insgesamt ist XQuery eine sehr ausdrucksstarke Anfragesprache, die auch viele M¨

og-

lichkeiten bei der Ausgabe anbietet. Eine Kenntnis der XML-Struktur der anzufragen-

den Datenquelle ist allerdings notwendig, um die Anfrage zu formulieren. XQuery kann

bei der Kommunikation zwischen Lernobjekt-Repositories genutzt werden, um XML-

Repr¨

asentationen der Metadaten ¨

uber die Lernobjekte (bspw. LOM) zu durchsuchen.

A.1.2. CQL

Die Common Query Language bietet gegen¨

uber XQuery eine intuitivere Formulierungs-

m¨

oglichkeiten von Anfragen, die aber trotzdem eine hohe Ausdrucksst¨

arke bietet. Dabei

verlangt sie keine syntaktische Auszeichnung der einzelnen Bestandteile einer Anfra-

ge, wie z. B. in XQuery durch die Schl¨

usselw¨

orter for,where, etc. F¨

ur eine einfache

Suchanfrage nach einer Zeichenkette ist es ausreichend, diese anzugeben2. Es besteht

die M¨

oglichkeit, diese Zeichenketten durch boolesche oder vergleichende Operatoren zu

1Hierbei k¨

onnen Anfragen mit den Ausdr¨

ucken F or,Let,OrderBy,W here und Return definiert

werden.

2Ein Beispiel f¨

ur eine g¨

ultige CQL-Anfrage ist ”repository“.

253

A. Anhang

verkn¨

upfen oder Existenzquantoren zu verwenden. Dar¨

uber hinaus erlaubt CQL die

Nutzung von Metadate zur n¨

aheren Spezifizierung der Suche. Eine Suche nach einem

Objekt, dass eine der Zeichenketten ”repository“ und ”E-Learning“ im Titel enth¨

alt,

kann wie folgt formuliert werden: ”title any ’repository E-Learning’“.

CQL erlaubt zus¨

atzlich Platzhalter (”*“, ”?“), unterscheidet Datentypen (Zeichenket-

ten, Zahl, Datum, etc.) und bietet sogar Operatoren, die eine gewisse Unsch¨

arfe zulas-

sen3. Dar¨

uber hinaus k¨

onnen Namensr¨

aume genutzt und somit zus¨

atzliche Operatoren

oder Metadaten verwendet werden.

A.1.3. VSQL

Die Very Simple Query Language ist die derzeit von fast allen SQI-f¨

ahigen Repositories

am h¨

aufigsten unterst¨

utzte Anfragesprache. Sie ist auf absolute Einfachheit ausgerichtet

und erlaubt nur eine einfache Angabe von Suchtermen f¨

ur eine Volltextsuche ¨

uber alle

Daten eines Repositories. Die Suche kann weder auf bestimmte Attribute eingeschr¨

ankt

werden, noch die Ordnung oder Ausgabe der Ergebnisse beeinflussen. Ein Suchterm wird

als Beispiel in Listing A.1.3 dargestellt.

Listing A.2: Beispiel-Anfrage f¨

ur VSQL

2<term>repos itor y </term>

<term>E−Learning</term>

4</simpleQuery>

3Zum Beispiel die Schl¨

usselw¨

orter prox und stern.

254

A.2. Geschehnis-Pr¨

adikatoren der Terminologie

A.2. Geschehnis-Pr¨

adikatoren der Terminologie

erzeugen

löschen arrangieren

verknüpfen übertragen zugreifen

synchroni-

sieren

tun

interagieren

anlegen

hochladen

durchführen

beginnen

abbrechen

abschließen

ausgeben

anzeigen

bereitstellen

belegen

drucken

verwalten

auswählen

suchen

hinzufügen

sortieren

senden weiterleiten

schreiben

verschieben

antworten

ausschließen

bedienen

aufrufen

registrieren

anmelden

authenti-

fizieren

abmelden

annotieren

zurückgeben

Abbildung A.1.: Die Basis-Geschehnispr¨

adikatoren (P) der Terminologie

255

A. Anhang

A.3. Ding-Pr¨

adikatoren der Terminologie

Dienst

System

Arbeitsraum

Berechtigung

Leserecht

Schreibrecht

Ausführrecht

Annotations-

recht

Zugriﬀsrecht Sanktionsrecht

Ding

Basis Person

Name

Bezeichnung

Vorname

Nachname

Veranstaltungs-

name

Kursteilnehmer

Dozent

Tutor

Prüfungs-

berechtiger

Organisations-

einheit

Mitarbeiter

Lehre

Gastdozent

Mitarbeiter

Verwaltung

Mitarbeiter

Bibliothek

Technischer

Support

Angestellter

Student

Gasthörer

Lehrstuhl

Fakultät

Verwaltung

Rechen-

zentrum

Bibliothek Nummer

Matrikel-

nummer

Primär-

schlüssel

Raumnummer

Veranstaltungs-

nummer

Status

eingeloggt

authentifiziert

angemeldet

registriert

zugelassen

Aktion

Methode

Stück

Akt

Aktivitäts-

struktur

Aktivität

Lernaktivität

Unterstützungs-

aktivität

Interaktion

Zeitangabe

Zeitraum

Semester

Datum

Bearbeitungs-

datum

Startdatum

Enddatum

Termin

Rolle

Administrator

Gast

Gruppen-

mitglied

Gruppen-

Administrator

System-

Administrator

Server-

Administrator

Container

Dokument

Externer

Verweis

Gruppe

Verknüpfung

Objekt

Raum

Benutzer

Ausgang

Verwaltung

Element

Liste

Index

Sammlung

Netzwerk

Hierarchie

Ressource

Werkzeug

Lernobjekt

Mail-Client

RSS-

Aggregator

WebDAV-

Ordner

Chat-Client

Whiteboard

Abbildung A.2.: Die Basis-Dingpr¨

adikatoren (Q) der Terminologie

256

A.4. Alfresco-Modell zur Verwaltung eines Weblogs

Listing A.3: weblog-model.xml

<?xml version=” 1.0 ” encoding=”UTF−8”?>

2<model

name=” koala:blogModel ”

4xmlns=” http: //www. a l f r e s c o . org /model/ dictionary /1.0 ”>

<description>Weblog Model</description>

6<version>1.0</version>

8<imports>

<!−− Import A l fr e sco D ict ion ary D e f i n i t i o n s −−>

10 <import u r i=” h tt p : //www. a l f r e s c o . org /model/ d ictionary /1.0 ”

p r e f i x=”d” />

12 <!−− Import A l fr e sco Content Domain Model D e f i n i t i o n s −−>

<import u r i=” h tt p : //www. a l f r e s c o . org /model/ content /1.0 ”

14 p r e f i x=”cm” />

<!−− Import koaLA Domain Model D e f i n i t i o n s −−>

16 <import u ri=” h tt p: //www. pro vi deal . net / koala /model /1.0 ”

p r e f i x=” koala ” />

18 </ imports>

20 <types>

22 <parent>cm:folder</parent>

<mandatory−aspects>

24 <aspect>cm:titled</aspect>

</mandatory−asp ects>

26 </ type>

28 <type name=” k o a l a:blogpost ”>

<parent>cm:folder</ parent>

30 <mandatory−aspects>

<aspect>cm:titled</aspect>

32 <aspect>koala:blogclassifiable</aspect>

</mandatory−asp ects>

34 </ type>

36 <type name=” koala:blogc a t e g o ry ”>

<title>Blog Category</ t i t l e>

38 <parent>cm:cmobject</ parent>

</ type>

40 </types>

42 <asp ects>

44 <title>Blog C l a s s i f i a b l e</ t i t l e>

46 <property name=” k o ala:catego r y ”>

<title>Category</ t i t l e>

48 <type>d:noderef</ type>

257

A. Anhang

50 <multiple>f a l s e</ mul tip le>

52 <atomic>true</atomic>

54 <tokenised>true</tokenised>

</ index>

56 </property>

</properties>

58 </aspect>

</ as pect s>

60 </model>

258

A.5. Beschreibungsmodell der konzipierten Methode

A.5.1. Vorgehen zur Plattformentwicklung

ID Kategorie Prozess Beschreibung

1.1 Analyse der E-Learning-

Dom¨

ane

Festlegung der Anwendungsdom¨

ane; Ableitung gemein-

samer, optionaler u. variabler Features; Pr¨

azisierung des

Produktraums der Produktfamilie

Teilprozesse/Aspekte Dom¨

anendefinition, Erstellung eines Lexikons, Beschreibung von Konzepten, Featu-

remodellierung

Ziel Definition der Anwendungsdom¨

ane und des Produktraums, Spezifizierung des Funk-

tionsumfangs herzustellender Produkte

Techniken

Ergebnis Produktraumbeschreibung; Dom¨

anenlexikon; Konzeptmodelle; Featuremodelle

Aktor Softwarearchitekt; Softwareentwickler; Didaktiker; Fachexperte

Bewertung/Kriterien Bsp.: Mittel- und langfristige Realisierbarkeit von Anwendungen auf Basis der Platt-

form

ID Kategorie Prozess Beschreibung

1.1.1 Analyse der E-

Learning-Dom¨

ane

Dom¨

anendefinition Beschreibung des Umfangs einer Dom¨

ane und Charakte-

risierung des Produktraums der Dom¨

ane

Teilprozesse/Aspekte

Ziel Definition der Anwendungsdom¨

ane und des Produktraums

Techniken Strategieanalyse, Marktanalyse, Bsp. existierender Systeme der Produktfamilie, Ge-

genbeispiele (z. B. Systeme außerhalb der Dom¨

ane), generische Regeln f¨

ur die Inklu-

sion oder Exklusion

Ergebnis Definition der Anwendungsdom¨

ane und des Produktraums

Aktor Fachexperte, Didaktiker, Softwarearchitekt

Bewertung/Kriterien Expertenaustausch, Produktstrategie, Marktanalysen, mittel- und langfristige Reali-

sierbarkeit

259

A. Anhang

ID Kategorie Prozess Beschreibung

1.1.2 Analyse der E-

Learning-Dom¨

ane

Erstellung eines Dom¨

anen-

Lexikons

Beschreibung der in der Dom¨

ane verwendeten Begriffe

Teilprozesse/Aspekte

Ziel Sicherstellung einer gemeinsamen Kommunikationsbasis f¨

ur alle Projektbeteiligten

Techniken Dokumentenanalyse, Interviews, Workshops, normsprachliche Rekonstruktion, Ter-

minologie

Ergebnis Lexikon ¨

uber Fachbegriffe der Dom¨

ane

Aktor Didaktiker, Softwarearchitekt, Fachexperte

Bewertung/Kriterien Klarheit, Widerspruchsfreiheit, Vollst¨

andigkeit, Allgemeinverst¨

andlichkeit

ID Kategorie Prozess Beschreibung

1.1.3 Analyse der E-

Learning-Dom¨

ane

Beschreibung von Konzep-

ten

Beschreibung der Konzepte einer Dom¨

ane mit Hilfe einer

angemessenen Modellierung

Teilprozesse/Aspekte

Ziel Sicherstellung eines gemeinsamen Verst¨

andnisses der Konzepte f¨

ur alle Projektbetei-

ligten

Techniken normsprachliche Spezifikation, Objektdiagramme, Interaktionsdiagramme, ERM, Da-

tenflussdiagramme, informeller Text

Ergebnis Modell der Dom¨

anenkonzepte, Objektstruktur des OO-Frameworks

Aktor Didaktiker, Fachexperte, Softwarearchitekt

Bewertung/Kriterien Best-Practice-Bsp., Abbildbarkeit der Objektstruktur auf das OO-Framework, Ex-

pertenreviews

260

A.5. Beschreibungsmodell der konzipierten Methode

ID Kategorie Prozess Beschreibung

1.1.4 Analyse der E-

Learning-Dom¨

ane

Featuremodellierung Identifizierung von Entit¨

aten, Funktionen und ihrer

Beziehungen; Analyse von ¨

Ahnlichkeiten, Variationen,

Kombinationen, Konflikten

Teilprozesse/Aspekte Modellierung gemeinsamer Features, Modellierung optionaler Features, Modellierung

von Freiheitsgraden mit variablen Features

Ziel Transparenz von Abh¨

angigkeiten, Entscheidungsbasis f¨

ur die Zuordnung von Features

zu Plattform oder Anwendung

Techniken Application Requirements-Matrix, Priority-Based Analysis, Checklist-Based Analy-

sis, FODA, Feature Diagramme, XPath, Captain Feature

Ergebnis Featuremodell, Katalog von Konfigurationsm¨

oglichkeiten f¨

ur neu zu implementieren-

de Anwendungen auf Basis der Plattform

Aktor Softwarearchitekt, Softwareentwickler, Didaktiker, Fachexperte

Bewertung/Kriterien Vollst¨

andigkeit, Granularit¨

ID Kategorie Prozess Beschreibung

1.2 Dom¨

anen-Design Standardisierung der Entwicklungs- u. Laufzeitinfra-

struktur; Entwurf der Plattformarchitektur und ihrer

Komponenten

Teilprozesse/Aspekte Standardisierung der Infrastruktur, Entwurf der statischen Plattformarchitektur, Ent-

wurf wiederverwendbarer Komponenten

Ziel Beschreibung des SW-Entwurfs von Plattform u. Komponenten

Techniken

Ergebnis Beschreibung einer standardisierten Entwicklungs- u. Laufzeitinfrastruktur, Ent-

wurfsdokumente f¨

ur die Plattform und ihrer Komponenten

Aktor Softwarearchitekt, Softwareentwickler, Techniker

Bewertung/Kriterien Bsp.: Anwendbarkeit von Standards, konzeptionelle Integrit¨

at, State of the art, Wie-

derverwendbarkeit, Vollst¨

andigkeit

261

A. Anhang

ID Kategorie Prozess Beschreibung

1.2.1 Dom¨

anen-Design Standardisierung der Infra-

struktur

Standardisierung der Entwicklungsumgebung, der Art

der Persistenz- u. Basisinfrastruktur, Auswahl von SWE-

Pattern und Frameworks

Teilprozesse/Aspekte Basisinfrastruktur f¨

ur Schichten u. Vermittlungsschichten, genormte Schnittstellen zu

den genutzten externen Systemen, OO-Framework, Programmiersprache(n), Applica-

tion Server,

Ziel Definition der Entwicklungsumgebung und der Basisinfrastruktur, Vereinbarung ¨

uber

Architektur- und SW-Entwicklungskonzepte

Techniken UML, Marktanalysen, Evaluationen, Prototyping

Ergebnis Standardisierte Infrastruktur, Technologiestrategie, Architekturstrategie, Program-

mierrichtlinien

Aktor Softwarearchitekt, Softwareentwickler, Techniker

Bewertung/Kriterien vorhandene Erfahrungen mit Architekturen, Technologien, u. SWE; Aufgabenan-

gemessenheit, Portabilit¨

at, Zuverl¨

assigkeit, ¨

Anderbarkeit, Effizienz, Best Practices,

State of the art, Referenzprojekte, konzeptionelle Integrit¨

ID Kategorie Prozess Beschreibung

1.2.2 Dom¨

anen-Design Entwurf der statischen

Plattformarchitektur

Entwurf der Kernfunktionalit¨

at der Plattform, Entwurf

eines Plug-In-Mechanismus zur Integration von Kompo-

nenten

Teilprozesse/Aspekte Kernfunktionalit¨

at: Persistierung von Objekten, Authentifizierung, Autorisierung,

Logging, Exception Handling, RSS-Engine, Tagging, Schnittstellen, Kommunikati-

onswerkzeuge; Aspekte des Entwurfs: Nebenl¨

aufigkeit, Komponentenschnittstellen,

Verteilung von Komponenten, Fehlertoleranz, Interaktion und Pr¨

asentation, Persis-

tierung von Daten

Ziel Verringerung der Komplexit¨

at; Vorbereitung arbeitsteiligen Entwickelns; Einbindung

existierender L¨

osungen; Erm¨

oglichung der Weiterentwicklung

Techniken Brainstorming, Entwurfsmethoden, SW-/Architekturpatterns, Diagrammsprachen,

z. B. UML; Traceability Links, HyperUML

Ergebnis Entwurfsdokumente f¨

ur die Plattformarchitektur

Aktor Softwarearchitekt, Softwareentwickler

Bewertung/Kriterien Expertenaustausch, Nachvollziehbarkeit, Lesbarkeit, Grad der Anwendung/Anwend-

barkeit von Standards, Wiederverwendbarkeit, konzeptionelle Integrit¨

262

A.5. Beschreibungsmodell der konzipierten Methode

ID Kategorie Prozess Beschreibung

1.2.3 Dom¨

anen-Design Entwurf wiederverwendba-

rer Komponenten

Entwurf allgemeiner und dom¨

anenspezifischer Dienste,

die in verschiedenen Anwendungen wieder verwendet

werden k¨

onnen

Teilprozesse/Aspekte Funktionsbl¨

ocke: Gruppenstrukturen (¨

offentliche Gruppen, private Gruppen, Zu-

trittsmechanismen), Dokumentenorganisation (Gruppen- und private Arbeitsr¨

aume,

Locking/Sperrmechanismen, Transformationen (Medientypen, Dateiumwandlung),

Versionierung von Objekten, Kategorisierung), Kommunikation (Foren, Blogs, Wi-

kis, Annotationen, internes Nachrichtensystem, Chat/VoIP/Audo/Video), Koordina-

tion(Kalender, Workflows), Community (Buddy-Listen, Awareness, Friend-of-a-friend

(soziales Netzwerk), Profile), Aspekte des Entwurfs: Nebenl¨

aufigkeit, Komponenten-

schnittstellen, Verteilung von Komponenten, Fehlertoleranz/Behandlung von Fehlern

und Ausnahmen, Interaktion und Pr¨

asentation, Persistierung von Daten

Ziel Verringerung der Komplexit¨

at; Vorbereitung arbeitsteiligen Entwickelns; Einbindung

existierender L¨

osungen; Erm¨

oglichung der Weiterentwicklung

Techniken Brainstorming, Entwurfsmethoden, SW-/Architekturpatterns, Diagrammsprachen,

z. B. UML; Traceability Links, HyperUML

Ergebnis Entwurfsdokumente f¨

ur die Plattformarchitektur

Aktor Softwarearchitekt, Softwareentwickler

Bewertung/Kriterien Expertenaustausch, Nachvollziehbarkeit, Lesbarkeit, Grad der Anwendung/Anwend-

barkeit von Standards, Wiederverwendbarkeit, konzeptionelle Integrit¨

ID Kategorie Prozess Beschreibung

1.3 Dom¨

anen-Implementierung Aufbau der entworfenen Entwicklungs- und Laufzeitin-

frastruktur, Umsetzung der Plattformarchitektur und ih-

rer Komponenten

Teilprozesse/Aspekte Aufbau der Infrastruktur, Implementierung der Plattformarchitektur, Implementie-

rung ihrer Komponenten

Ziel Bereitstellung der standardisierten Infrastruktur, Plattformarchitektur und Kompo-

nenten

Techniken

Ergebnis Funktionierende Entwicklungs- und Laufzeitinfrastruktur, funktionierendes Basissys-

tem inkl. Komponenten

263

A. Anhang

Aktor Softwarearchitekt, Softwareentwickler, Techniker

Bewertung/Kriterien Bsp.: Einsatz von Standards, Kompatibilit¨

at, Korrektheit, Stabilit¨

at, Performance,

Erweiterbarkeit, Portierbarkeit

ID Kategorie Prozess Beschreibung

1.3.1 Dom¨

anen-

Implementierung

Aufbau der Infrastruktur Installation und Integration verschiedenster Technologi-

en, Basisinfrastrukturkomponenten, IDEs, Frameworks,

Schnittstellen und Protokolle

Teilprozesse/Aspekte

Ziel Bereitstellung einer Entwicklungs- und Laufzeitumgebung f¨

ur die Plattform und f¨

ihre Komponenten

Techniken Basisinfrastruktur, Architekturprinzipien

Ergebnis Lauff¨

ahige Entwicklungsumgebung auf Basis einer standardisierten Infrastruktur

Aktor Softwarearchitekt, Softwareentwickler, Techniker

Bewertung/Kriterien Einsatz von Standards, Dokumentation der Konfiguration, Kompatibilit¨

at, Automa-

tisierbarkeit

ID Kategorie Prozess Beschreibung

1.3.2 Dom¨

anen-

Implementierung

Implementierung der Platt-

formarchitektur

Umsetzung der Kernfunktionalit¨

at, Umsetzung eines

PlugIn-Mechanismus zur Integration von Komponenten

Teilprozesse/Aspekte

Ziel Umsetzung des Architekturentwurfs zu einem lauff¨

ahigen System

Techniken Programmiersprachen, SW-Entwicklungspattern, Entwicklungsumgebungen, Biblio-

theken, Frameworks, Hyperspace-Ansatz, Hyper/J; Unit Tests

Ergebnis Standardplattform f¨

ur die Anwendungsentwicklung im E-Learning

Aktor Softwarearchitekt, Softwareentwickler

Bewertung/Kriterien Dokumentation, Expertenreviews, Testbarkeit, Korrektheit, Stabilit¨

at, Lesbarkeit,

Zweckm¨

aßigkeit, Erweiterbarkeit, Portierbarkeit

264

A.5. Beschreibungsmodell der konzipierten Methode

ID Kategorie Prozess Beschreibung

1.3.3 Dom¨

anen-

Implementierung

Implementierung wiederver-

wendbarer Komponenten

Implementierung allgemeiner und dom¨

anenspezifischer

Funktionen als wiederverwendbare Komponenten

Teilprozesse/Aspekte

Ziel Umsetzung des Komponenten-Entwurfs zu lauff¨

ahigen Komponenten; Integration der

Komponenten

Techniken Programmiersprachen, SW-Entwicklungspattern, Entwicklungsumgebungen, Biblio-

theken, Frameworks, Hyperspace-Ansatz, Hyper/J; Unit Tests

Ergebnis Komponenten zur Unterst¨

utzung allgemeiner und dom¨

anenspezifischer Belange, die

bei der Anwendungsentwicklung im E-Learning wieder verwendet werden k¨

onnen

Aktor Softwarearchitekt, Softwareentwickler

Bewertung/Kriterien Dokumentation, Expertenreviews, Testbarkeit, Korrektheit, Stabilit¨

at, Lesbarkeit,

Zweckm¨

aßigkeit, Erweiterbarkeit, Portierbarkeit

265

A. Anhang

A.5.2. Vorgehen zur Anwendungsentwicklung

ID Kategorie Prozess Beschreibung

2.1 Projektvorbereitung Projektorganisation und Rahmenbedingungen festlegen,

Projektziele definieren, Projektaufbau- und Ablaufstruk-

tur planen, Termin- und Budgetplanung, Qualit¨

ats- und

Risikomanagement

Teilprozesse/Aspekte Initiierung, Festlegung von Rollen und Verantwortlichkeiten, Identifikation der Stake-

holder, Zieldefinition, Bedarfsanalyse, Anforderungen an Neuentwicklung (grob) und

Priorisierung, Rahmenbedingungen ermitteln, Projektstruktur definieren, Termin-

und Budgetplanung, Risikoanalyse und Qualit¨

atssicherungsplanung

Ziel Durchf¨

uhrbarkeit des Projektes evaluieren bzw. herstellen

Techniken

Ergebnis Projektorganisation, Projektziele, Projektaufbau- u. -ablaufplan, Termin- u. Budget-

plan, Qualit¨

atssicherungsplan, Risikoanalyse

Aktor Initiator, Fachexperte, Didaktiker, Organisationsspezialist, Projektmanager

Bewertung/Kriterien Bsp.: Projekterfahrung der Mitglieder, Projektzielerreichung, konzeptuelle Konsis-

tenz, Orientierung an organisatorischen Schnittstellen, Orientierung am Erfolg, Sen-

sibilisierung der Mitglieder bzgl. Qualit¨

at u. Projektrisiken

ID Kategorie Prozess Beschreibung

2.1.1 Projektvorbereitung Initiierung Initiierung durch Identifikation und Beschreibung von

Bedarf und Bed¨

urfnis

Teilprozesse/Aspekte

Ziel Identifikation und Beschreibung von Bedarf und Bed¨

urfnis

Techniken Methoden der Bedarfsanalyse, Methoden der Marktforschung und -analyse, Metho-

den der Trendforschung, Umfragen, Balanced Scorecard, Skill Gap Analysen, Arbeits-

platzanalyse, Auditierung

Ergebnis Dokumentation von Bedarf und Bed¨

urfnis

Aktor Initiator, Fachexperte, Didaktiker, Organisationsspezialist

Bewertung/Kriterien Pr¨

ufung der Ergebnisse der Bedarfs- und Bed¨

urfnisidentifikation auf Plausibilit¨

266

A.5. Beschreibungsmodell der konzipierten Methode

ID Kategorie Prozess Beschreibung

2.1.2 Projektvorbereitung Festlegung von Rollen und

Verantwortlichkeiten

Definition von Auftraggeber, Lenkungsausschuss, Pro-

jektleitung, Projektteam, speziellen Gruppen; Kontrolle

der Termine und ggf. internen u. externen Kosten; Ein-

bindung der Fachbereiche; Einbindung von Projektmit-

arbeitern; Rollen von Ansprechpartnern

Teilprozesse/Aspekte

Ziel Bildung einer Projektorganisation und Herstellung ihrer Arbeitsf¨

ahigkeit; allg.

Verst¨

andnis von Rollen und Verantwortlichkeiten

Techniken Workshops; Moderation und Mediation; Methoden der Entscheidungsfindung: Aus-

sprache, Ansprache, Dialog; Organigramme; Workflow-Modellierung

Ergebnis Beschreibung von Rollen und Verantwortlichkeiten im Projektteam; Definiti-

on von Prozessen (Genehmigung von Aufw¨

anden, Eskalationsmechanismen, Qua-

lit¨

atssicherung, etc.)

Aktor Initiator; Fachexperte; Didaktiker; Organisationsspezialist; Projektmanager

Bewertung/Kriterien Projekterfahrung der Projektmitglieder; gewinnbringende Integration individueller

Kenntnisse und F¨

ahigkeiten in die Projektorganisation; Funktionsf¨

ahigkeit von Ko-

ordinationsmechanismen; zielgerichtete Produktivit¨

ID Kategorie Prozess Beschreibung

2.1.3 Projektvorbereitung Identifikation der Stakehol-

der

Identifikation von Aktoren, Interessenten und Nutzern;

Beschreibung und Bewertung ihrer Ziele

Teilprozesse/Aspekte Identifikation von Aktoren, Interessenten und Nutzern

Ziel Identifikation und Beschreibung der Gesamtheit der Stakeholder und deren Einfluss

sowie Mitwirkung am Bildungsprozess und am Projekt.

Techniken Literaturanalyse, Analyse von Strategiekonzepten, Business-Pl¨

anen, Organigrammen,

Richtlinien, Curricula, Rahmenpl¨

anen, Stoffverteilungspl¨

anen, Pr¨

ufungsordnungen,

Stundenpl¨

anen und Kriterien der ¨

Uberpr¨

ufung

Ergebnis Benennung der Stakeholder sowie Dokumentation und Bewertung ihrer Interessen

hinsichtlich Bildungsprozess und Projekt, Dokumentation der Anforderungen und

Grobziele. Identifikation und Beschreibung der Bedeutung und der Einfl¨

usse auf Ent-

stehung, Akzeptanz und Marktf¨

ahigkeit des SPL-Produktes

Aktor Initiator; Organisationsspezialist; Projektmanager

Bewertung/Kriterien Auftragskl¨

arung und -best¨

atigung, Workshops, Interviews

267

A. Anhang

ID Kategorie Prozess Beschreibung

2.1.4 Projektvorbereitung Zieldefinition Identifikation, Beschreibung und Bewertung der Projekt-

ziele der relevanten Stakeholder

Teilprozesse/Aspekte

Ziel Identifikation, Beschreibung und Bewertung der Ziele der relevanten Stakeholder,

Umsetzung in ein Qualit¨

atssystem nach ISO 9000

Techniken Befragung, Interview, Umfrage, Workshop, Dokumentenanalyse, Assessment

Ergebnis Dokumentation und Bewertung der Ziele relevanter Stakeholder, Operationalisierba-

re, konsistente Zielsetzungen zur Qualit¨

atsmessung nach ISO 9000

Aktor Initiator; Projektmanager; Evaluationsexperte; Organisationsspezialist

Bewertung/Kriterien Zielerreichung

ID Kategorie Prozess Beschreibung

2.1.5 Projektvorbereitung Bedarfsanalyse Spezifikation, Beschreibung und Bewertung des

Bildungsbedarfs; Schwachstellen-/Potenzialanalyse

(funktional/nicht-funktional); Erfassung von Ist-

Mengenger¨

usten; Beschreibung der Zielsetzung des

Projektes

Teilprozesse/Aspekte

Ziel Spezifikation, Beschreibung und Bewertung des Bildungsbedarfs und der Ziele, die

mit dem Projekt verbunden werden und deren Beschreibung

Techniken Befragung, Interview, Umfrage, Workshop, Dokumentenanalyse, systematische und

methodische Ausformulierung der Bedarfsanalyse (z.B. Verfahren der Markt- und

Bildungsforschung, der Organisationsanayse)

Ergebnis Dokumentation und Bewertung des Bildungsbedarfs und der Projektziele;

Schwachstellen/-potenzialanalyse; Ist-Mengenger¨

uste

Aktor Initiator; Projektmanager; Evaluationsexperte; Organisationsspezialist; Fachexperte;

Didaktiker

Bewertung/Kriterien Dokumentation und Bewertung des Bildungsbedarfs und der Projektziele

268

A.5. Beschreibungsmodell der konzipierten Methode

ID Kategorie Prozess Beschreibung

2.1.6 Projektvorbereitung Anforderungen an Neuent-

wicklung (grob) und Priori-

sierung

Erhebung und Beschreibung der groben Systemanforde-

rungen (funktional/nicht-funktional); Beschreibung des

Bildungsbedarfs (Niveau und Inhalt) und der Art der

Bildung (formal, nicht-formal, vorgeschrieben, Lernziel-

systematik); Beschreibung der Soll-Mengenger¨

uste;

Teilprozesse/Aspekte

Ziel Dokumentation und Priorisierung der groben Anforderungen als Basis f¨

ur die Planung

der Iterationen

Techniken Befragung, Interview, Dokumentenanalyse, Methoden des Requirements-Engineering

Ergebnis Beschreibung des Bedarfs und der Art der Bildung; Beschreibung funktionaler u.

nicht-funktional Systemanforderungen; Soll-Mengenger¨

uste

Aktor Initiator; Projektmanager, Softwarearchitekt; Evaluationsexperte; Didaktiker; Orga-

nisationsspezialist

Bewertung/Kriterien Anforderungskl¨

arung und -best¨

atigung, Workshops, Interviews

ID Kategorie Prozess Beschreibung

2.1.7 Projektvorbereitung Rahmenbedingungen ermit-

teln

Ermittlung finanzieller, zeitlicher, organisatorischer,

technischer und juristischer Rahmenbedingungen; Ana-

lyse des internen u. externen Umsystems; Analyse der

Zielgruppe,

Teilprozesse/Aspekte Internes Umsystem: Hochschulweite E-Learning-/IT-/Medien-Strategie; bestehen-

de Dienstleistungen; bestehende Basisinfrastruktur; (konkurrierende) Projekte; inter-

ne Einstellung von Entscheidungstr¨

agern; Lernkultur; Externes Umsystem: Know-

how in Literatur und bei Anbietern; Referenzmodelle und Rahmenarchitekturen;

Standards; Marktstudien, Evaluationen, Trends; gesetzliche Vorgaben (Datenschutz);

Bildungspolitik; Analyse der Zielgruppe:

Ziel Ermittlung expliziter und impliziter Rahmenbedingungen f¨

ur das Projekt; Identifi-

kation, Beschreibung und Bewertung relevanter Einfl¨

usse auf das Projekt bzw. der

Phase des Betriebs, die sich aus dem internen und externen Umsystem ergeben

Techniken Befragung; Interview; Dokumentenanalyse; Hinzunahme von Fachstellen,

Marktanalysen, quantitative und qualitative Methoden der empirischen Sozial-

/Bildungsforschung; Zielgruppenanalyse

269

A. Anhang

Ergebnis Dokumentation der Rahmenbedingungen; Dokumentation des organisatorischen und

institutionellen Kontextes; Dokumentation und Bewertung relevanter Kategorien der

externen Kontexte

Aktor Initiator; Projektmanagement; Organisationsspezialist; Softwarearchitekt; Fachexper-

te; Softwareentwickler

Bewertung/Kriterien Vollst¨

andigkeit, Qualit¨

at der Informationen, Plausibilit¨

atspr¨

ufung, Methoden zur

Analyse und Bewertung der Aktoren

ID Kategorie Prozess Beschreibung

2.1.8 Projektvorbereitung Projektstruktur definieren Aufbau- und Ablauforganisation f¨

ur die Durchf¨

uhrung

des Projektes festlegen; Beschreibung der Beziehungen

zwischen Aufbau- und Ablauforganisationselementen

Teilprozesse/Aspekte

Ziel abgestimmte Aufbau- und Ablaufstruktur

Techniken DIN 69901, ICB, Organigramme, Phasenschemata, Vorgehensmodelle

Ergebnis Dokumentation der Projektaufbau- und Ablaufstruktur, Work Breakdown Structure

Aktor Initiator; Projektmanager; Softwarearchitekt; Fachexpert; Organisationspezialist

Bewertung/Kriterien Vollst¨

andigkeit; konzeptuelle Konsistenz; Granularit¨

at; Anwendbarkeit; Adaptivit¨

270

A.5. Beschreibungsmodell der konzipierten Methode

ID Kategorie Prozess Beschreibung

2.1.9 Projektvorbereitung Termin- u. Budgetplanung Beschreibung der zeitlichen und logischen Anord-

nung von Arbeitspaketen sowie der Anordnungsbezie-

hungen zwischen Arbeitspaketen; Aufwandsabsch¨

atzung

und Ressourcenbedarfsermittlung; Kostenermittlung und

Budgetplanung

Teilprozesse/Aspekte Anfangskosten: Beratungskosten; tats¨

achliche Kosten f¨

ur Kauf oder Leasing der

Hardware; Kosten f¨

ur Anpassung des Ausr¨

ustungsstandortes (Klimaanlage, Sicher-

heitseinrichtungen etc.), Kosten der Betriebssystemsoftware, Installationskosten f¨

Kommunikationseinrichtungen (Telefon- und Datenleitungen), Personalbeschaffungs-

kosten, anf¨

angliche Personalkosten, Kosten f¨

ur die St¨

orung der sonstigen Organisati-

on, Managementkosten f¨

ur die Anfangsaktivit¨

aten, Kapitalkosten; Projektkosten:

Beschaffungskosten f¨

ur Anwendungssoftware, Kosten der Anpassung der Software an

bestehende Systeme, Personal- und Gemeinkosten bei Erstellung von Individualsoft-

wae im eigenen Haus, Kosten f¨

ur Anwenderschulung, Datenerfassungskosten, Doku-

mentationskosten, Kosten des Projektmanagements; Betriebskosten: Wartungskos-

ten (Software, Hardware), Verbrauchsgeb¨

uhren (Strom, Telefon, etc.), Abschreibun-

gen auf Hardware, Personalkosten

Ziel Qualitative und quantitative Planung und ¨

Uberpr¨

ufung der Projektentwicklung

Techniken Analogiesch¨

atzung, Algorithmische Sch¨

atzung: Function Point, COCOMO, INVAS,

Sch¨

atzklausuren; Gantt-Diagramme, Netzplantechniken

Ergebnis Abgestimmter Budget- und Ablaufplan

Aktor Projektmanager; Softwarearchitekt; Fachexperte

Bewertung/Kriterien Qualit¨

at der Sch¨

atzung; Orientierung an organisatorischen Schnittstellen; Orientie-

rung am Erfolg; Einhaltung von Terminen und Budgets

ID Kategorie Prozess Beschreibung

2.1.10 Projektvorbereitung Risikoanalyse Benennung von Projektrisiken, ihrer Faktoren und ih-

rer Indikatoren; Einsch¨

atzung der Wahrscheinlichkeiten

des Eintritts der Risiken; Bestimmung der Auswirkung

bei Eintritt; Auswahl bedrohlicher Risiken; Erarbeitung

von Gegenmaßnahmen; ¨

Uberwachung der Risiken und

der eingeleiteten Maßnahmen

271

A. Anhang

Teilprozesse/Aspekte Arten von Risiken: Leistungsrisiken, Terminrisiken, Kostenrisiken, Resourcenrisiken,

Projektmanagementrisiken, Qualit¨

atsrisiken, Konfigurationsrisiken

Ziel Absicherung des Projekterfolges gegen¨

uber m¨

oglichen Risiken

Techniken Brainstorming; Experteninterviews; Lessons learned; Auditierung; Methoden der

Wahrscheinlichkeitsrechnung; Entscheidungsb¨

aume; Controlling; Qualitative Risiko-

analyse, PMBOK, DIN 69905, PMF

Ergebnis Risikoanalyse, Plan von Gegenmaßnahmen

Aktor Softwarearchitekt; Softwareentwickler; Projektmanagement; Organisationsspezialist;

Techniker, Fachexperte

Bewertung/Kriterien Projekterfahrung im Team, Qualit¨

at der Sch¨

atzung von Wahrscheinlichkeiten; Identi-

fizierung von Risikoindikatoren, Sensibilisierung der Projektmitglieder bzgl. Risiken,

Etablierung eines “Fr¨

uhwarnsystems”

ID Kategorie Prozess Beschreibung

2.1.11 Projektvorbereitung Qualit¨

atssicherungsplanung Identifizierung der f¨

ur das Projekt geltenden

Qualit¨

atsstandards und Festlegung von Qua-

lit¨

atssicherungsmaßnahmen sowohl f¨

ur die (Zwischen-

)Produkte als auch f¨

ur die Prozesse. Festlegung von

Vorgehen zur kontinuierlichen Verbesserung der Projekt-

managementprozesse

Teilprozesse/Aspekte Aspekt Dokumentation: Prozessdokumentation: Zeitpl¨

ane, Programmierrichtlini-

en, Entwicklungsentscheidungen, Sch¨

atzprotokolle, Testberichte; Aspekt Tests: Sys-

temtests, Integrit¨

atstests, Uni-Tests, Benutzertests

Ziel Erh¨

ohung der Effizienz von Prozessen, sowie der Qualit¨

at von (Zwischen-) Produkten

und Dienstleistungen

Techniken ISO 9001, Bootstrap, ISO 15504 aka SPICE, EFQM, CMM, ITIL (eher Fokus auf

Betrieb, weniger auf Entwicklung), Six Sigma, PSP u. TSP, Hermes, PMBOK, SOX

(Sarbanes-Oxley Act), Fehlerm¨

oglichkeits- u. Einflussanalyse (FMEA, z.B. MIL-P-

1629)

Ergebnis Qualit¨

atsmanagementplan; organisierte Maßnahmen zur Verbesserung von

(Zwischen-)Produkten, Prozessen oder Leistungen

Aktor Softwarearchitekt; Softwareentwickler; Projektmanager; Fachexperte; Didaktiker;

Support; Techniker; Initiator

Bewertung/Kriterien Umfang der Dokumentation, Art und H¨

aufigkeit von Tests, Sensibilisierung der Pro-

jektmitarbeiter bzgl. Qualit¨

at, Qualit¨

atskontrolle

272

A.5. Beschreibungsmodell der konzipierten Methode

ID Kategorie Prozess Beschreibung

2.2 Analyse Analyse und Spezifikation der zu unterst¨

utzenden Didak-

tik/Methodik, des Medieneinsatzes, des Medien- u. Inter-

aktionsdesigns und der Statik, Funktionalit¨

at und Dyna-

mik des Lern-/Arbeitsszenarios

Teilprozesse/Aspekte Analyse der zu unterst¨

utzenden Methodik/Didaktik, Medieneinsatz, Kommu-

nikationsm¨

oglichkeiten u. Formen, Workflows, Rollen und Rechte, Medien-

/Interaktionsdesign

Ziel Identifikation und Beschreibung von Projekt-/Produkt-relevanten Einfl¨

ussen und An-

forderungen

Techniken

Ergebnis Evaluation der Abbildbarkeit organisatorischer u. didaktischer Anforderungen auf das

Dom¨

anenkonzept; Design-Prototyp; Pflichtenheft

Aktor Evaluationsexperte; Fachexperte; Didaktiker; Projektmanager; Organisationsspezia-

list; Softwarearchitekt; Mediendesigner

Bewertung/Kriterien Bsp.: Plausibilit¨

atspr¨

ufungen, Zweitgutachten, Abstimmung mit Aktoren,

Verst¨

andlichkeit, Angemessenheit, Vollst¨

andigkeit, Machbarkeitspr¨

ufung, Usability-

Tests, heuristische Evaluation, konzeptionelle Konsistenz

ID Kategorie Prozess Beschreibung

2.2.1 Analyse Analyse der zu un-

terst¨

utzenden Didakti-

k/Methodik

Analyse des didaktischen Gesamtkonzeptes, des Curricu-

lums und der Lernszenarien; Analyse didaktischer Mo-

delle und Konzepte

Teilprozesse/Aspekte Lernziele, Inhaltliches Konzept, Didaktik/Methodik (Lerntheoretische Grundmodel-

le, didaktische(s) Modell(e), Curriculum, Lernszenarien, Methodische Konzepte zum

Methodeneinsatz, Sozialformen, Aktivit¨

aten); Rollen und Aktivit¨

aten, organisatori-

sches Konzept (Lernort, Lehrort, Lernzeitpunkt, Gesamtdauer, Summer der Lernzeit)

Ziel ¨

Ubertragung der didaktischen Modelle und methodischen Konzepte auf die

Dom¨

anenkonzepte; Sicherung einer gemeinsamen Kommunikationsbasis zwischen Be-

teiligten bzgl. Didaktik/Methodik

273

A. Anhang

Techniken Interviews, Workshops, Brainstorming, Methoden der Aufgabenanalyse; Model-

le des Instruktionsdesigns; IMS LD (EML); MOT-Diagramme; UML Akti-

vit¨

atendiagramme; ClassSync Modeling Language (CML), CoopLets, DIN PAS 1032-

2:2004

Ergebnis Beschreibung der didaktischen Modelle und methodischen Konzepte in einer ange-

messenen Modellierung

Aktor Didakt, Softwarearchitekt, Fachexperte

Bewertung/Kriterien Lesbarkeit, Verst¨

andlichkeit, Nachvollziehbarkeit, Angemessenheit, Vollst¨

andigkeit

ID Kategorie Prozess Beschreibung

2.2.2 Analyse Anforderungserhebung: Me-

dieneinsatz

Auswahl und Beschreibung der einzusetzenden Medien;

Erweiterung des Pflichtenhefts

Teilprozesse/Aspekte Pr¨

asentation und Distribution von Informationen; Sammeln und Filtern von Informa-

tionen; Bearbeitung von Informationen, Interaktion; konstruktive Darstellung eigener

Lernergebnisse; “Performance-Support”-Werkzeuge, Kommunikation

Ziel Festlegung der Medienauswahl, Festlegung des Medieneinsatzes, der f¨

ur Funktionen,

Zielgruppe, Lernziele, Lerninhalte, Vorgaben und Rahmenbedingungen angemessen

ist

Techniken Wirkungsanalysen, Auswertung von Wirkungsanalysen, Arbeits- und Lernplatzana-

lysen

Ergebnis Dokumentation und Begr¨

undung der Medienauswahl und des Medieneinsatzes

Aktor Mediendesigner; Didaktiker; Softwarearchitekt

Bewertung/Kriterien Pr¨

ufung der methodisch-didaktischen Angemessenheit und technischen Machbarkeit

des gew¨

ahlten Medieneinsatzes vor der Einf¨

uhrung

274

A.5. Beschreibungsmodell der konzipierten Methode

ID Kategorie Prozess Beschreibung

2.2.3 Analyse Anforderungserhebung:

Medien- u. Interaktionsde-

sign

Entwicklung und Beschreibung des Medien- und In-

teraktionsdesigns auf Basis der Vorgaben zu Software-

Ergonomie, HCI-Design und Usability, sowie ggf. des

Corporate Design der Organisation; Erweiterung des

Pflichtenhefts

Teilprozesse/Aspekte

Ziel Festlegung des Design-Konzeptes f¨

ur alle relevanten Bereiche unter Ber¨

ucksichtigung

bestehender Vorlagen/Richtlinien

Techniken Analyse bestehender Benutzungsschnittstellen hinsichtlich Interaktion und Design

Ergebnis Dokumentation und Begr¨

undung des Design-Konzeptes (Design-Prinzipien, Stylegui-

de), Design-Prototyp

Aktor Mediendesigner, Didaktiker, Softwarearchitekt

Bewertung/Kriterien Usability-Test anhand des Design-Prototyps, heuristische Evaluation, Pr¨

ufung der

Konformit¨

at bzgl. bestehender Vorgaben

ID Kategorie Prozess Beschreibung

2.2.4 Analyse Normsprachliche Spezifizie-

rung

Entlang der gew¨

ahlten Nutzungsmetapher (hier: Wis-

sensraummetapher) werden die zu unterst¨

utzenden Nut-

zungsszenarien mittels normsprachlicher Konstrukte spe-

zifiziert.

Teilprozesse/Aspekte Statik: Gruppen-/Nutzerstrukturen, Inhalte- und Prozessstrukturen; Funktiona-

lit¨

at: Funktionen fachlicher Objekte und (kontextabh¨

angige) Benutzer- und Grup-

penrechte, diese auszuf¨

uhren; Dynamik: Zust¨

ande und Zustands¨

uberg¨

ange fachlicher

Objekte

Ziel Formale Erfassung

Techniken Aussagenbildung auf Basis einer Normsprache, MOT-Diagramme

Ergebnis Methodeninvariante Spezifikation der zu unterst¨

utzenden Nutzungsszenarios

Aktor Softwarearchitekt

Bewertung/Kriterien Vollst¨

andigkeit, Widerspruchsfreiheit, Korrektheit, Nachvollziehbarkeit, Lesbarkeit,

konzeptionelle Integrit¨

275

A. Anhang

ID Kategorie Prozess Beschreibung

2.3 Konzeption Herleitung der Produkt-Architektur aus der SPL-

Architektur, Identifizierung und Anpassung ben¨

otigter

SPL-Komponenten, Entwurf produktspezifischer Kom-

ponenten, Konzeption von Systemeinf¨

uhrung, Betrieb u.

Support, Wartung u. Pflege

Teilprozesse/Aspekte Produktarchitektur, plattformspezifische Komponenten, produktspezifische Kompo-

nenten, organisatorische Konzepte f¨

ur Systemeinf¨

uhrung, Betrieb und Support, War-

tung und Weiterentwicklung

Ziel Beschreibung des SW-Entwurfs von Produktarchitektur u. -komponenten; Kl¨

arung

und Sicherstellung von Systemeinf¨

uhrung, Betrieb, Support, Wartung und Pflege

Techniken

Ergebnis Entwurfsdokumente f¨

ur die produktspezifische Softwarearchitektur, die Integration

und Anpassung von SPL-Komponenten, produktspezifische Komponenten, Konzept

f¨

ur Systemeinf¨

uhrung, Betrieb, Support, Wartung und Pflege

Aktor Softwarearchitekt; Softwareentwickler; Techniker; Organisationsspezialist; Projekt-

manager; Support

Bewertung/Kriterien Bsp.: Nachvollziehbarkeit, Lesbarkeit, konzeptionelle Integrit¨

at; Reibungslose Syste-

meinf¨

uhrung u. Betrieb; Benutzerbefragungen; Auswertung von Fehlerstatistiken u.

Zufriedenheitsumfragen

ID Kategorie Prozess Beschreibung

2.3.1 Konzeption Herleitung der Produktar-

chitektur aus der Plattfor-

marchitektur

Instanzierung der Produktarchitektur; Beschreibung der

Konfiguration und der produktspezifischen Anpassungen

und Erweiterungen

Teilprozesse/Aspekte

Ziel Wiederverwendung der SPL-Architektur f¨

ur das Produkt; Verringerung der Komple-

xit¨

at; Vorbereitung arbeitsteiligen Entwickelns

Techniken Brainstorming, Entwurfsmethoden, SW-/Architektur-Patterns, Entwurfsprinzipien,

Diagrammsprachen, z.B. UML

Ergebnis Entwurfsdokumente f¨

ur die produktspezifische Softwarearchitektur

Aktor Softwarearchitekt; Softwareentwickler

Bewertung/Kriterien Expertenaustausch, Nachvollziehbarkeit, Lesbarkeit, Grad der Anwendung/Anwend-

barkeit von Standards, Wiederverwendbarkeit; konzeptionelle Integrit¨

276

A.5. Beschreibungsmodell der konzipierten Methode

ID Kategorie Prozess Beschreibung

2.3.2 Konzeption Identifizierung relevanter

Komponenten und Anpas-

sung

Abgleich der erhobenen Anforderungen mit dem Feature-

Katalog und Konfigurationsm¨

oglichkeiten der SPL-

Komponenten

Teilprozesse/Aspekte

Ziel Wiederverwendung von SPL-Komponenten f¨

ur das Produkt; Verringerung der Kom-

plexit¨

at; Vorbereitung arbeitsteiligen Entwickelns

Techniken Brainstorming, Entwurfsmethoden, SW-/Architektur-Patterns, Entwurfsprinzipien,

Diagrammsprachen, z.B. UML

Ergebnis Entwurfsdokumente f¨

ur die Integration und die Anpassung von SPL-Komponenten

innerhalb der produktspezifische Softwarearchitektur

Aktor Softwarearchitekt; Softwareentwickler

Bewertung/Kriterien Expertenaustausch, Nachvollziehbarkeit, Lesbarkeit, Grad der Anwendung/Anwend-

barkeit von Standards, Wiederverwendbarkeit; konzeptionelle Integrit¨

ID Kategorie Prozess Beschreibung

2.3.3 Konzeption Entwurf der produktspezifi-

schen Komponenten

Entwurf produktspezifischer Funktionen als Komponen-

ten auf Basis erhobener Anforderungen

Teilprozesse/Aspekte

Ziel Verringerung der Komplexit¨

at; Vorbereitung arbeitsteiligen Entwickelns; Einbindung

existierender L¨

osungen; Erm¨

oglichung der Weiterentwicklung

Techniken Brainstorming, Entwurfsmethoden, SW-/Architektur-Patterns, Entwurfsprinzipien,

Diagrammsprachen, z.B. UML

Ergebnis Entwurfsdokumentation f¨

ur die produktspezifischen Komponenten

Aktor Softwarearchitekt; Softwareentwickler

Bewertung/Kriterien Expertenaustausch, Nachvollziehbarkeit, Lesbarkeit, Grad der Anwendung/Anwend-

barkeit von Standards, Wiederverwendbarkeit; konzeptionelle Integrit¨

277

A. Anhang

ID Kategorie Prozess Beschreibung

2.3.4 Konzeption Konzeption Syste-

meinf¨

uhrung

Migrationsstrategie bei vorhandenem Altsystem; Krite-

rien zur Ersetzung des Altsystems; Festlegung von Ver-

antwortlichkeiten f¨

ur ¨

Ubergabeentscheidung; Festlegung

von T¨

atigen bei der Umstellung; Konzeption eines Not-

fallplans f¨

ur einen etwaigen Systemausfall

Teilprozesse/Aspekte

Ziel Kl¨

arung und Sicherstellung einer problemlosen Systemeinf¨

uhrung

Techniken Migrationsstrategien (bspw. “Database First” “Database Last” “Cold Turkey/Big-

Bang”); Checklisten; Aktivit¨

atendiagramme/EPKs; Einrichtung einer TaskForce; In-

formationsveranstaltungen; Workshops

Ergebnis Konzept f¨

ur die Systemeinf¨

uhrung

Aktor Techniker; Organisationsspezialist; Softwarearchitekt; Softwareentwickler, Projekt-

manager

Bewertung/Kriterien Reibungslose Systemeinf¨

uhrung

ID Kategorie Prozess Beschreibung

2.3.5 Konzeption Konzeption Betrieb und

Support

Konzeption f¨

ur den First- und Second Level Support;

Konzeption f¨

ur Endanwenderschulungen

Teilprozesse/Aspekte Organisationsform: Versorgungstr¨

ager, Kooperationsformen, Leitungsstrukturen;

Aufgabenverteilung: Zuordnungsprinzipien, Aufgabenverteilung zwischen IT-

Diensten, Mediendiensten und Bibliotheken

Ziel Kl¨

arung und Sicherstellung von Support und Schulungen

Techniken Versorgungskonzepte; Best Practices; Lessons learned; Workshops; Moderation; Me-

diation, Methoden der Entscheidungsfindung; Organigramme

Ergebnis Konzept f¨

ur den Betrieb und den Support; Schulungskonzept

Aktor Support; Techniker; Projektmanager; Softwarearchitekt; Softwareentwickler; Didak-

tiker; Fachexperte

Bewertung/Kriterien Auslastung des technischen Supports; Nachfrage nach didaktischem Support; Aus-

fallsicherheit;

278

A.5. Beschreibungsmodell der konzipierten Methode

ID Kategorie Prozess Beschreibung

2.3.6 Konzeption Konzeption Wartung und

Pflege

Konzeption der Pflege und Aktualisierung der Lernres-

sourcen: Verantwortung f¨

ur Wartung und Anpassung;

methodisch-didaktische Aktualisierung; inhaltliche Ak-

tualisierung; Existenz und Laufzeit von Wartungsver-

tr¨

agen, Verantwirtlichkeit f¨

ur ¨

Anderungsantr¨

age; Kri-

terien f¨

ur durchzuf¨

uhrende¨

Anderungen; Verfahren bei

Anderungen; Kontrollverfahren

Teilprozesse/Aspekte

Ziel Kl¨

arung und Sicherstellung von G¨

ultigkeit und Aktualit¨

at des Produktes und der

Inhalte bei ge¨

anderten Rahmenbedingungen oder Anforderungen

Techniken IS0 9001, Workflow-Modellierung, Checklisten, Wartungspl¨

ane und Vereinbarungen

Ergebnis Konzept der Verantwortlichkeiten und Maßnahmen f¨

ur Wartung und Pflege

Aktor Techniker; Support; Softwarearchitekt; Softwareentwickler; Projektmanagement

Bewertung/Kriterien Reibungsloser Betrieb und aktuelle Inhalte; Auswertung von Fehlerstatistiken und

Zufriedenheitsumfragen, Benutzerbefragungen

ID Kategorie Prozess Beschreibung

2.4 Implementierung, Integrati-

on und Test

Umsetzung der Produktarchitektur und produkts-

pezifischer Komponenten, Wiederverwendung von

SPL-Komponenten; Erweiterung der komponen-

ten¨

ubergreifenden Benutzungsschnittstelle und Inte-

grationstests

Teilprozesse/Aspekte Produktarchitektur, Konfiguration von Komponenten, Implementierung produktspe-

zifischer Komponenten, Medien- u. Interaktionsdesign, Integrationstests

Ziel Umsetzung der technischen und mediendidaktischen Konzeption

Techniken

Ergebnis Getestetes technisch funktionales System und dazugeh¨

orige Dokumentation

Aktor Softwareentwickler; Softwarearchitekt; Mediendesigner; Support; Techniker

Bewertung/Kriterien Bsp.: Expertenreviews, Testbarkeit, Korrektheit, Bedienbarkeit, Barrierefreiheit,

Browserkompatibilit¨

279

A. Anhang

ID Kategorie Prozess Beschreibung

2.4.1 Implementierung Umsetzung der Produktar-

chitektur

Umsetzung des Entwurfs der produktspezifischen Archi-

tektur; Installation und Integration verschiedenster Tech-

nologien: Basisinfrastrukturkomponenten, IDEs, Frame-

works, Schnittstellen u. Protokolle

Teilprozesse/Aspekte

Ziel Umsetzung des Architekturentwurfs zu einem lauff¨

ahigen System

Techniken allg. Standards, anerkannte Methoden und Tools f¨

ur das SW-Engineering: Booch,

Nassi-Shneidermann oder Jackson, CASE, UML; Unit Tests

Ergebnis Produktspezifisches Rahmenwerk f¨

ur SPL- und produktspezifische Komponenten;

Rahmenwerk f¨

ur Benutzungsschnittstelle; Dokumentation

Aktor Softwareentwickler; Softwarearchitekt

Bewertung/Kriterien Dokumentation, Expertenreviews, Testbarkeit, Korrektheit, Stabilit¨

at, Lesbarkeit,

Zweckm¨

aßigkeit, Erweiterbarkeit, Performance, Programmierrichtlinien

ID Kategorie Prozess Beschreibung

2.4.2 Implementierung Instanzierung und Modifika-

tion von Komponenten

Konfiguration von SPL-Komponenten und ihre Ein-

bindung in die Produktarchitektur; Umsetzung der

produktspezifischen Benutzungsoberfl¨

ache f¨

ur SPL-

Komponenten

Teilprozesse/Aspekte

Ziel Wiederverwendung von SPL-Komponenten in der Produktarchitektur; Integration

der Komponenten

Techniken allg. Standards, anerkannte Methoden und Tools f¨

ur das SW-Engineering: Booch,

Nassi-Shneidermann oder Jackson, CASE, UML; Units Tests, HTML-Editoren, CSS-

Werkzeuge, Checklisten, Interaktionsgraphen, Templates

Ergebnis Funktionale Erweiterung des Produktes durch SPL-Komponenten; Dokumentation

Aktor Softwareentwickler; Mediendesigner; Softwarearchitekt

Bewertung/Kriterien Dokumentation, Expertenreviews, Testbarkeit, Korrektheit, Stabilit¨

at, Lesbarkeit,

Zweckm¨

aßigkeit, Erweiterbarkeit, Performance, Programmierrichtlinien

280

A.5. Beschreibungsmodell der konzipierten Methode

ID Kategorie Prozess Beschreibung

2.4.3 Implementierung Implementierung produkts-

pezifischer Komponenten

Implementierung spezieller Funktionen als produktspe-

zifische Komponenten; Integration in die Produktarchi-

tektur (evtl. ¨

uber Plugin-Mechanismus); Umsetzung der

Benutzungsoberfl¨

ache f¨

ur produktspezifische Komponen-

ten

Teilprozesse/Aspekte Umsetzung der Datenmodelle; Implementierung des Application Layers; Implementie-

rung der Controller; Umsetzung des Medien- u. Interaktionsdesigns (HTML, AJAX,

CSS, JS, etc.); Anpassung der Sprachdateien

Ziel Umsetzung des Komponenten-Entwurfs zu lauff¨

ahigen Komponenten; Integration der

Komponenten

Techniken allg. Standards, anerkannte Methoden und Tools f¨

ur das SW-Engineering: Booch,

Nassi-Shneidermann oder Jackson, CASE, UML; Units Tests, HTML-Editoren, CSS-

Werkzeuge, Checklisten, Interaktionsgraphen, Templates

Ergebnis Funktionale Erweiterung des Produktes durch produktspezifische Komponenten; Do-

kumentation

Aktor Softwareentwickler; Mediendesigner; Softwarearchitekt

Bewertung/Kriterien Dokumentation, Expertenreviews, Testbarkeit, Korrektheit, Stabilit¨

at, Lesbarkeit,

Zweckm¨

aßigkeit, Erweiterbarkeit, Performance, Programmierrichtlinien

ID Kategorie Prozess Beschreibung

2.4.4 Implementierung Umsetzung Medien- u. In-

teraktionsdesign

Umsetzung von Navigationsstrukturen; Umsetzung des

Design-Konzeptes

Teilprozesse/Aspekte

Ziel Umsetzung des Design-Konzeptes f¨

ur alle relevanten Bereiche

Techniken HTML-Editoren, CSS-Werkzeuge, Checklisten, Interaktionsgraphen, Templates

Ergebnis Benutzungsschnittstelle f¨

ur das Produkt; Dokumentation

Aktor Softwareentwickler; Mediendesigner; Softwarearchitekt;

Bewertung/Kriterien Design-Prinzipen; Expertenreviews; Bedienbarkeit; Barrierefreiheit; verwendete Stan-

dards; Browserkompatibilit¨

281

A. Anhang

ID Kategorie Prozess Beschreibung

2.4.5 Implementierung Integrationstest Aufeinander abgestimmte Reihe von einzelnen Tests, um

alle voneinander abh¨

angigen Komponenten im Zusam-

menspiel miteinander zu testen

Teilprozesse/Aspekte Test der Benutzungsschnittstelle, Test der Komponentenschnittstellen im Zusammen-

spiel mit den neuen produktspezifischen Komponenten, Test der Kommunikations-

schnittstelle mit dem Basissystem

Ziel Sicherstellung des fehlerfreien Zusammenspiels aller Komponenten

Techniken Funktionstests, Schnittstellentests, “Bottom-Up-Methode” (Betrachtung bereits ge-

testeter Komponenten als ein System)

Ergebnis Getestetes technisch funktionales System; Dokumentation

Aktor Softwareentwickler; Softwarearchitekt; Support; Techniker

Bewertung/Kriterien Pr¨

ufung auf Fehlerfreiheit; Korrektheit, Vollst¨

andigkeit der Testf¨

alle; Automatisier-

barkeit

ID Kategorie Prozess Beschreibung

2.5 Systemeinf¨

uhrung u. Ab-

nahme

Uberf¨

uhrung der Lernressourcen von der Entwicklungs-

in die Betriebsumgebung

Teilprozesse/Aspekte Einrichtung der technischen Infrastruktur, Systemtest, Anpassung, Bereitstellung,

Abnahme- oder ¨

Ubernahmetest, Organisation des Betriebs und der Nutzung

Ziel Einf¨

uhrung der technologischen Komponenten in den Bildungsprozess

Techniken

Ergebnis Betriebsbereite Lernumgebung mit allen f¨

ur den Bildungsprozess notwendigen

Lernressourcen

Aktor Techniker; Softwareentwickler; Softwarearchitekt; Projektmanager; Didaktiker; Sup-

port; Support

Bewertung/Kriterien Bsp.: Auditierung der technischen Infrastruktur, der Testergebnisse u. Dokumentati-

on, sowie der Aufbau- u. Ablauforganisation durch ein Kontrollgremium; Abnahme-

protokoll

282

A.5. Beschreibungsmodell der konzipierten Methode

ID Kategorie Prozess Beschreibung

2.5.1 Systemeinf¨

uhrung u.

Abnahme

Einrichtung der technischen

Infrastruktur

Installation, Konfiguration und Inbetriebnahme der tech-

nischen Basisinfrastruktur, die das neue System voraus-

setzt. Einrichtung von Schutzmßnahmen (bspw. Sicher-

heitskonzept, Datensicherung)

Teilprozesse/Aspekte Sicherstellung von Infrastrukturkomponenten, die den Anforderungsspezifika entspre-

chen, z. B. Hardware-, Software-, und Netzwerkkomponenten bei Betreiber und Be-

nutzer; Maßnahmen zur Ausfallsicherung, sicherem Zugriff und sicheren Transaktio-

nen; Bereitstellung von Dokumentationen und Anleitungen f¨

ur den Betrieb, den Zu-

griff und die Transaktionssicherheit

Ziel Schaffung der technischen Voraussetzungen anhand der Anforderungen f¨

ur die Nut-

zung des SPL-Produktes

Techniken Soll-Ist-Vergleich, Implementierungsstrategie

Ergebnis Anforderungsgerechte technische Infrastruktur; Dokumentation der technischen Rea-

lisierung/Realisierbarkeit

Aktor Techniker; Softwareentwickler; Softwarearchitekten

Bewertung/Kriterien Auditierung der technischen Infrastruktur durch ein Kontrollgremium

ID Kategorie Prozess Beschreibung

2.5.2 Systemeinf¨

uhrung u.

Abnahme

Systemtest ¨

Uberpr¨

ufung und Validierung der Lernressourcen

Teilprozesse/Aspekte

Ziel Feststellung, ob die Lernressource die definierten Anforderungen erf¨

ullen und f¨

ur eine

endg¨

ultige Freigabe geeignet sind

Techniken Software Validation, z.B. nach IEEE; ISO 9000; Code Review; Moduldesigntest; Be-

lastungstest; Integrationstest; Usabilitytest

Ergebnis Dokumentierte Testergebnisse und ¨

Anderungsanforderungen

Aktor Projektmanager; Techniker; Softwareentwickler; Softwarearchitekt; Didaktiker

Bewertung/Kriterien Bewertung der Kriterien durch ein Kontrollgremium

283

A. Anhang

ID Kategorie Prozess Beschreibung

2.5.3 Systemeinf¨

uhrung u.

Abnahme

Anpassung Sicherstellung der Angemessenheit und Nachvollziehbar-

keit der Anpassungen hinsichtlich Funktionalit¨

at, Gestal-

tung und Dokumentation

Teilprozesse/Aspekte

Ziel Sicherstellung der Umsetzung aller Anforderungen f¨

ur Anpassungen an einer Lernres-

source bzw. einem definierten System in einer effektiven und kontrollierten Weise

Techniken Konfigurationsmanagement mit dokumentierter Programmversionskontrolle des ar-

chivierten Codes und der definierten Hardware- und Netzwerkkonfiguration; Doku-

menversionskontrolle unter Einsatz eines Dokumenten- oder Contentmanagementsys-

tems

Ergebnis Angepasste Lernressource (Update); Dokumentation der Anpassungen, z. B. Konfigu-

rationsmanagementplan, Anpassungsplan, Dokumentationsplan, bearbeitete Anpas-

sungsformulare, Design Review Bericht

Aktor Projektmanagement, Softwareentwickler; Softwarearchitekt; Techniker; Support; Me-

diendesigner

Bewertung/Kriterien Bewertung der Konfiguration und der Anpassungskontrolle durch ein Kontrollgremi-

ID Kategorie Prozess Beschreibung

2.5.4 Systemeinf¨

uhrung u.

Abnahme

Bereitstellung ¨

Ubergabe des Produkts und der Dokumentation an den

Betreiber

Teilprozesse/Aspekte Registrierung von Lizenzen, Installation und Konfiguration der getesteten Infra-

struktur und des SPL-Produktes in der Betriebsumgebung, Dokumentation, Da-

ten¨

ubernahme aus Altsystemen, Deaktivierung und/oder Entfernen von alten Ver-

sionen (Updating)

Ziel Bereitstellung des Systems in der Betriebsumgebung

Techniken Checklisten; Freischaltung im Netzwerk/¨

Ubergabe (z.B. Server)

Ergebnis Verf¨

ugbares funktionierendes System in der Betriebsumgebung;

Aktor Techniker; Support; Projektmanager; Softwareentwickler; Softwarearchitekt

Bewertung/Kriterien Bewertung der Kriterien durch ein Kontrollgremium; Dokumentation

284

A.5. Beschreibungsmodell der konzipierten Methode

ID Kategorie Prozess Beschreibung

2.5.5 Systemeinf¨

uhrung u.

Abnahme

Abnahme- oder

Ubernahmetest

Teilprozesse/Aspekte ¨

Ubernahme des Produkts und der Dokumentation durch den Betreiber und formale

Freigabe

Ziel ¨

Uberf¨

uhrung des Systems in den Betrieb

Techniken Soll-Ist-Vergleich; Funktions- u. Schnittstellentests; Belastungstests; Installationstest;

User-Akzeptanztest

Ergebnis Abgenommenes und formal freigegebenes System in der Betriebsumgebung; Doku-

mentierter Nachweis der Erf¨

ullung der Anforderungen

Aktor Projektmanager; Techniker; Initiator; Support; Didaktiker

Bewertung/Kriterien Abnahmeprotokoll; Abgleich mit dokumentierten Anforderungen; Bewertung der Tes-

tergebnisse und der Dokumentation durch ein Kontrollgremium

ID Kategorie Prozess Beschreibung

2.5.6 Systemeinf¨

uhrung u.

Abnahme

Organisation des Betriebs u.

der Nutzung

Schaffung der organisatorischen Voraussetzungen anhand

der Konzepte f¨

ur Systemeinf¨

uhrung, Betrieb, Support,

Wartung und Pflege

Teilprozesse/Aspekte Organisationsstruktur, Qualifikation des Lehr-/Betriebspersonals, Bedienkompetenz

und Vorwissen des Nutzers, Support und Wartung

Ziel Sicherstellung des organisatorischen Betriebs der Lernumgebung

Techniken Workshops; Informationsveranstaltungen; Qualifizierungsmaßnahmen; Anwendung

von Organisationskonzepten; Methoden des Change-Management; ISO 9001; ITIL

Ergebnis Organisatorischer Rahmen mit Aufbau- und Ablauforganisation

Aktor Projektmanagement; Support; Techniker; Organisationsspezialist

Bewertung/Kriterien Validierung der Aufbau- und Ablauforganisation durch ein Kontrollgremium

ID Kategorie Prozess Beschreibung

2.6 Betrieb Durchf¨

uhrung und Nutzung eines Bildungsangebots: Ad-

ministration, Support und Wartung

Teilprozesse/Aspekte Administration, Support, Wartung und Weiterentwicklung

Ziel Bereitstellung von Administration, Support und Wartung

285

A. Anhang

Techniken

Ergebnis Durchf¨

uhrung und Dokumentation von Administration, Support und Wartung

Aktor Techniker; Support; Softwarearchitekt; Softwareentwickler

Bewertung/Kriterien Bsp.: Lern- und Transfererfolg; Kompetenzzuwachs; Funktional: Korrektheit, Benutz-

barkeit; Nicht-funktional: Robustheit, Performance , Ausfallsicherheit; Reaktionszeit

ID Kategorie Prozess Beschreibung

2.6.1 Betrieb Administration Bereitstellung der Administration und der begleitenden

Maßnahmen; Benutzerverwaltung; Verwaltung und Frei-

gabe von Inhalten (insb. Verwaltung organisatorischer

Strukturen wie Semester, Kurse, Rollen und Rechte)

Teilprozesse/Aspekte Vergabe von Rollen und Rechten, Sperrung/L¨

oschung von Logins, Einrichtung und

Freigabe von Inhalten (Semester, Kurse, Griuppen, etc.)

Ziel Bereitstellung der Administration und begleitender Maßnahmen f¨

ur die Benutzung

des Produktes

Techniken ISO 9000; entsprechend dem organisatorischen, ¨

okonomischen und technologischen

Betriebskonzept (Technischer Support, Organisatorischer Rahmen); ITIL

Ergebnis Durchf¨

uhrung und Dokumentation der Administration und der begleitenden Maß-

nahmen

Aktor Techniker; Support

Bewertung/Kriterien Evaluation erfolgt in Abh¨

angigkeit von den gew¨

ahlten Standards formativ bzw. sum-

mativ; gesetzliche Vorschriften (z. B. Datenschutz)

ID Kategorie Prozess Beschreibung

2.6.2 Betrieb Support Beratung und Hilfestellung der Benutzer

Teilprozesse/Aspekte Information/Ank¨

undigung, Lehr-/Lernberatung: Technologie/Lernorganisation,

techn. und/oder didaktische Produktschulungen, Beschwerdemanagement, Bu-

chung/Einschreibung/Anmeldung

Ziel Bereitstellung von Beratungsleistungen und Hilfestellung f¨

ur Anwender bei der Be-

nutzung des Systems

Techniken Ticketsystem; Einrichtung einer Hotline/eines Helpdesks; ITIL

Ergebnis Durchf¨

uhrung und Dokumentation der Beratung und Hilfestellung

Aktor Support

Bewertung/Kriterien Benutzerbefragung; Reaktionszeit; Individualit¨

286

A.5. Beschreibungsmodell der konzipierten Methode

ID Kategorie Prozess Beschreibung

2.6.3 Betrieb Wartung und Weiterent-

wicklung

Ver¨

anderung des Produktes nach Auslieferung, zwecks

Fehlerbehebung, Leistungssteigerung oder Anpassung an

ver¨

anderte Rahmenbedingungen

Teilprozesse/Aspekte Softwarewartung: Durchsicht der Log-Dateien; Updates einspielen; Sicherheitspat-

ches; Hardware; Softwareweiterentwicklung: Strukturverbesserungen, funktionale

Erweiterungen, Korrekturen/Bugfixing

Ziel Sicherstellung der Aktualit¨

at des Systems bzw. ge¨

anderter/neuer Anforderungen;

Erh¨

ohung der Ausfallsicherheit

Techniken Konzepte zur Softwarepflege/-wartung/-weiterentwicklung: Korrigierende Wartung,

pr¨

aventieve Wartung, adaptive Wartung, perfektionierende Wartung; Re-Engineering;

IEEE 1219-98; ITIL

Ergebnis Durchf¨

uhrung und Dokumentation der Wartung

Aktor Techniker; Softwarearchitekt; Softwareentwickler

Bewertung/Kriterien Kompatibilit¨

at; Konsistenz; Ausfallzeiten; Reaktionszeit

ID Kategorie Prozess Beschreibung

2.7 Evaluation Systematische Untersuchung der Verwendbarkeit bzw.

G¨

ute eines Bildungsangebotes

Teilprozesse/Aspekte Planung, Durchf¨

uhrung, Auswertung, Optimierung

Ziel Evaluation und Verbesserung des Bildungsangebots und der Bildungsprozesse

Techniken ISO 9000; Evaluationsmodelle, z.B. Kirkpatrick; Summative und formative Evaluati-

onsmethoden und -verfahren

Ergebnis Evaluationsplanung, Evaluationsberichte, Optimierungskonzept

Aktor Projektmanager; Support; Evaluationsexperte

Bewertung/Kriterien

287

A. Anhang

ID Kategorie Prozess Beschreibung

2.7.1 Evaluation Planung Parameter, Kriterien, Instrumente und Methoden so-

wie der organisatorischen Rahmenbedingungen zur

Durchf¨

uhrung einer Evaluation

Teilprozesse/Aspekte Zielsetzung, Art der Evaluation, Zeitraum/Anzahl der Evaluation(en), Festlegung von

Parametern und Kriterien, Auswahl von Instrumenten und Methoden zur Evaluation

Ziel Konzeption der Evaluation im Hinblick auf Wirksamkeit und Wirtschaftlichkeit des

Bildungsangebotes

Techniken Normen, unternehmensinterne/-¨

ubergreifende Verfahrensanweisungen; Evaluations-

modelle, z.B. Kirkpatrick

Ergebnis Dokumentation und Begr¨

undung des Evaluationsplans zur Durchf¨

uhrung der Evalua-

tion

Aktor Evaluationsexperte; Initiator; Projektmanagement

Bewertung/Kriterien Durch Erfahrungsauswertungen nach der Durchf¨

uhrung der Evaluation

ID Kategorie Prozess Beschreibung

2.7.2 Evaluation Durchf¨

uhrung Umsetzung des Evaluationsplans

Teilprozesse/Aspekte Realisation, Erfassung von Messdaten

Ziel Ermittlung von Daten zur Ergebniskontrolle und zur Kontrolle der eingesetzten Mittel

und Ressourcen, z.B. im Kontext von Aufwand, Eignung und Wirksamkeit

Techniken Normen, unternehmensinterne/-¨

ubergreifende Verfahrensanweisungen; Einsatz der

Instrumente und Methoden aus dem Evaluationsplan

Ergebnis Dokumentation der Umsetzung, Dokumentation der Messdaten

Aktor Support; Evaluationsexperte

Bewertung/Kriterien Erfahrungsauswertung nach der Durchf¨

uhrung der Evaluation

288

A.5. Beschreibungsmodell der konzipierten Methode

ID Kategorie Prozess Beschreibung

2.7.3 Evaluation Auswertung Auswertung der ermittelten Messdaten

Teilprozesse/Aspekte Zusammenfassung, Analyse, Interpretation, Empfehlung

Ziel Gewinnung von Erkenntnissen ¨

uber Methoden, eingesetzte Mittel und Ressourcen

und erzielte Ergebnisse; Schlussfolgerungen zu Aufwand, Eignung und Wirksamkeit

Techniken Normen, unternehmensinterne und -¨

ubergreifende Verfahrensanweisungen; Beschrei-

bung und Begr¨

undung der verwendeten Auswahlmethoden

Ergebnis Dokumentation und Begr¨

undung der Auswertungsergebnisse in einer Zusammenfas-

sung; Dokumentation und Begr¨

undung von Analyse und Interpretation der Auswer-

tungsergebnisse; Dokumentation und Begr¨

undung von Empfehlungen

Aktor Evaluationsexperte

Bewertung/Kriterien Erfahrungsauswertung nach der Durchf¨

uhrung der Evaluation; Soll-Ist-Vergleich nach

Durchf¨

uhrung der Evaluation

ID Kategorie Prozess Beschreibung

2.7.4 Evaluation Optimierung Verbesserung von Produkten und Prozessen

Teilprozesse/Aspekte vorbeugende Maßnahmen: Erfassung, Analyse, Umsetzung ge¨

anderter Rahmen-

bedingungen, korrektive Maßnahmen: Erfassung, Analyse, Umsetzung ge¨

anderter

Rahmenbedingungen

Ziel Steigerung oder Erhaltung der Wirksamkeit und Wirtschaftlichkeit von Produkten

und Prozessen

Techniken vorbeugende Maßnahmen zur Aktualisierung und Anpassung der Dimensionen Ver-

fahren, Zeit, Personen und Inhalte an ge¨

anderte Rahmenbedingungen; Korrektve

Maßnahmen zur Umsetzung von Empfehlungen aus der Evaluation zu den Dimensio-

nen Verfahren, Zeit, Personen und Inhalte

Ergebnis Dokumentation der durchgef¨

uhrten Optimierungsmaßnahmen; Steigerung oder Er-

haltung der Wirksamkeit und Wirtschaftlichkeit von Produkten und Prozessen

Aktor Projektmanagement; Evaluationsexperte

Bewertung/Kriterien Erfahrungsauswertung nach der Durchf¨

uhrung der Evaluation

289