Skip to content. | Skip to navigation

Citation and Metadata
Document Actions
Full Text

1 Entstehungszusammenhang

1.1 Universitäre Entwicklung

Anders als die meisten Lehr-Lernplattformen und Kursmanagementsysteme, die sich momentan noch auf dem Markt behaupten können, wurde Stud.IP konsequent aus universitären Strukturen heraus ohne nennenswerte Finanzbeihilfen entwickelt. Der Grundstein wurde in einer Lehrveranstaltung am Göttinger “Zentrum für interdisziplinäre Medienwissenschaft (ZiM) im Wintersemester 1999/2000 gelegt, bei der jedoch bereits in der zweiten Sitzung die klassische Seminarstruktur zugunsten einer freien Arbeitsgruppe aufgegeben wurde. Gemeinsames Ziel der verschiedenen Gründungsmitglieder aus fünf verschiedenen Fachbereichen war die Einführung einer lehrunterstützenden Internetplattform auf Datenbankbasis und HTML-Oberfläche.

Die erste, für alle Veranstaltungen des ZiM im Wintersemester 2000/2001 eingesetzte Softwareversion (V 0.2), beinhaltet bereits wesentliche Elemente der jetzigen Software: Ein personalisiertes Vorlesungsverzeichnis mit der Möglichkeit für die Studierenden, ihre Studienplanung damit abzuwickeln sowie erste didaktische Werkzeuge innerhalb der einzelnen Veranstaltungen (Forensysteme, Dateiablage) zu nutzen. Die beiden Grundlinien, Motivation und Identifikation mit dem System durch Personalisierung sowie der rein unterstützende Ansatz von Präsenzlehre (mittlerweile bekannt als “blended learning”), waren klar erkennbar. Im Verlauf des Jahres 2001 kam es zu einem stetigen Anwachsen der Entwicklermannschaft und der ersten veröffentlichten Version auf http://sourceforge.net/projects/studip/.

Seitdem wurde der Funktionsumfang weiter ausgebaut, ohne dass von dem Konzept einer Mischung aus Verwaltungstool für die universitäre Lehre, Community-Plattform in Form eines virtuellen Kommunikations- und Aktionsraumes für alle Studierenden und Lehrenden sowie als eLearning-Umgebung zur Bereitstellung von Unterrichtsmaterialien abgewichen wurde.

Die Weiterentwicklung und Betreuung wurde im Jahr 2002 durch die Göttinger Firma data-quest vom ZiM übernommen, ferner wurde die Plattform in den Open-Source- Softwareverbund “CampusSource” aufgenommen – als bis dahin einzige, die nicht aus Nordrhein-Westfalen stammt. Ebenfalls im Jahr 2002 kam es zu einer ersten finanziellen Förderung in nennenswerter Höhe durch Drittmittel: im Rahmen des bmb+f Programmes “Notebook University” wurde Stud.IP Grundlage des Göttinger Antrages und um viele Funktionen für mobile Nutzungsszenarien erweitert (WAP-Schnittstelle, XML-Export, erweiterter Terminkalender mit Synchronisationsfunktionen, Literaturverwaltung mit Anbindung an Bibliothekssysteme u.v.a.).

Mit der ersten Stud.IP-Tagung am 24.09.2003 in Göttingen wurde ein weiterer Schritt in Richtung verteilter Entwicklung vollzogen: durch die neuen universitätsweiten Installationen der Software etwa in Osnabrück und Oldenburg wurden die Entwicklungskapazitäten weiter ausgebaut.

Im Frühjahr 2004 stellt sich Stud.IP als ausgereiftes Lernmanagementsystem mit umfassendem Funktionsumfang dar, das bundesweit von über 50.000 registrierten Studierenden und Lehrenden genutzt wird.

1.2 Didaktisches Konzept

Grundgedanke von Stud.IP ist die Unterstützung universitärer Lehrveranstaltungen, nicht deren Ersetzung durch rein virtuelle Angebote. Zwar ist es möglich eigenständige Lernmodule in die Lernumgebung einzubinden, der Schwerpunkt liegt jedoch im Angebot von Werkzeugen für Didaktik und Administration.

Universitäre Lehrveranstaltungen sind in der Mehrheit in wöchentlichen Präsenzsitzungen organisiert: der Zeitraum zwischen den Sitzungen soll von den Studierenden zur Vor- und Nachbereitung genutzt werden. Eben hier liegen jedoch die Defizite der reinen Präsenzuniversität: viele Studierende nehmen nur die eigentlichen Seminartermine als “Studienzeit” war, die Sitzungen leiden in der Praxis an mangelnder Vor- und Nachbereitung seitens der Studierenden.

Diese “Lücke” zwischen den Präsenzterminen versucht Stud.IP zu schließen – die Themen der Veranstaltung sollen auch zwischen den Sitzungen präsent sein, im Forum diskutiert werden, im Wiki-System weiterentwickelt oder transparent vorbereitet werden, Thesenpapiere und Kommentare zeitig abrufbar sein.

Die Motivation der Studierenden, diese Angebote auch wirklich wahrzunehmen, wird durch zwei Strategien gesteigert: zum einen eine hohe Identifikation mit dem System durch starke Personalisierung (Real-Name-Pflicht, eigene Homepage, Community-Bereich), zum anderen Hilfe bei ungeliebten administrativen Aufgaben.

Dieser letzte Punkt motiviert auch die Lehrenden mit dem System zu arbeiten: die Seminarorganisation wird durch Ablaufpläne, Teilnehmerlisten, Zulassungsverfahren, ein Newssystem und vieles andere mehr, signifikant vereinfacht.

Durch die interdisziplinär zusammengesetzte Entwicklergruppe stellt Fachunabhängigkeit ein weiteres didaktisches Konzept von Stud.IP dar. Alle Funktionalitäten sollen nach Möglichkeit so flexibel konzipiert sein, dass sie nicht nur einem begrenzten Nutzerkreis dienlich sind, sondern gleichermaßen von Juristen, Wirtschaftswissenschaftlern, Naturwissenschaftlern, Medizinern und Geisteswissenschaftlern genutzt werden können. Auch auf den ersten Blick fachorientierte Funktionalitäten wie die systemweite TeX-Unterstützung (für den Bereich der mathematisch-naturwissenschaftlichen Fächer) offenbaren beim näheren Hinsehen Potential auch für andere Gebiete: etwa durch die Unterstützung von Notensatz oder die Einbettung arabischer Schriftzeichen. Durch die fachunabhängigen Funktionen finden die Nutzer ein einheitliches Bedienkonzept vor und müssen sich etwa als Magisterstudierende mit vielfältigen Fächerkombinationen nicht störenden Medienbrüchen stellen.

2 Technische Konzeption

2.1 Entwicklungsansatz

Eine der grundlegenden Entscheidung bei der Konzeption von Stud.IP wurde sehr früh getroffen: für die Entwicklung sollte ausschließlich auf Open-Source Komponenten zurückgegriffen werden, da diese nach Ansicht der Entwickler die passgenaueste Voraussetzung für Softwareentwicklungen an deutschen Hochschulen darstellt.

Als technische Basis dient ein klassisches LAMP-System: Linux als Betriebssystem (un-abhängig von der jeweiligen Distribution), ein Apache-Webserver, eine MySQL- Datenbank sowie PHP als eigentliche Skriptsprache. Das notwendige Sessionmanagement wird über eine leicht modifizierte Variante der PHPlib-Bibliothek realisiert und setzt Sessioncookies voraus. Durch Verwendung der PHPlib exisitiert eine Abstraktionsschicht für die Datenbankoperationen, sodass sich mit wenigen Modifikationen auch andere Datenbanken als MySQL einsetzen lassen.

2.2 Rechtesystem

Im Wesentlichen lassen sich drei unterschiedliche Implementierungen von Rechtesystemen in Lernmanagementsystemen unterscheiden:

  • Offene Systeme, die im Wesentlichen nur zwischen ”Autorenschaft” und ”Zugehörigkeit” unterscheiden
  • Granulare Systeme, bei denen für jeden Benutzer bezogen auf jede einzelne Ressource fein differenzierte Rechte vergeben werden können
  • Rollenbasierte Systeme, bei denen sich die Rechte des Benutzers im System im wesentlichen aus den Hierarchien in der ”realen Welt” ableiten.

Stud.IP setzt konsequent ein rollenbasiertes Rechtesystem ein, welches sich in den letzten Jahren gut bewährt hat: die Stukturen an deutschen Hochschulen sind relativ klar hierarchisch organisiert – von den Studierenden über Tutoren, wissenschaftlichen Hilfskräften hin zu Hochschullehrern, darüber noch eine Schicht von Administration und Verwaltung (etwa in den Dekanaten). Ebendiese Strukturen bildet Stud.IP 1:1 in der Plattform ab, wobei jeder Nutzer innerhalb seiner Rechterolle freien Handlungsspielraum genießt. Neben den Rollen prägen Institutionen die Hochschullandschaft: vom Lehrstuhl über das Institut bis zu Fakultät und Universität.

Die Rechte in Stud.IP leiten sich daher im Wesentlichen aus dem Dreieck Person/Rolle – Institution – Veranstaltung ab. Dieses Dreieck ist flexibel, ein und dieselbe Person kann somit in einer Einrichtung Dozent einer Veranstaltung sein und Autor etwa in einem Organisationsgremium einer anderen Einrichtung.

Derartige Konstruktionen lassen sich auch mit granularen Rechtesystemen umsetzen, jedoch sind diese wesentlich schwieriger zu bedienen, insbesondere bei rekursiven Strukturen wenig performant und von Laien nicht ohne weiteres zu warten. Dem Vorwurf, rollenbasierte Rechtesystem könnten Sonderfälle nicht flexibel genug abbilden kann entgegengehalten werden: in vier Jahren ist bei mehreren tausend unterstützten Veranstaltungen in Göttingen kein Fall aufgetaucht, der sich nicht hätte umsetzen lassen – zumal sich spezialisierte Rollen wie Raum- oder Bibliotheksadministratoren hinzufügen lassen.

Ein System mit dezidiert offener Rechtestruktur wird sich unserer Einschätzung nach im universitären Umfeld nicht durchsetzen können, da es zu viele Reibungspunkte mit den gewachsenen Universitätshierarchien aufweist.

2.3 Bedienung

Deutsche Universitäten präsentieren sich als besonders heterogenes Biotop von unterschiedlichen Befindlichkeiten und Vorlieben – auch und gerade im Bereich des Technikeinsatzes. Während man im Bereich der betrieblichen Weiterbildung den Angestellten klare Vorgaben in Bezug auf die zu verwendende Software stellt (die Arbeitsplatzrechner werden inklusive Software zur Verfügung gestellt), muss man bei Studierenden die unterschiedlichsten Vorlieben bei der Wahl von Betriebssystem, Browser etc. berücksichtigen, wenn man wirklich eine breite Nutzerschaft erreichen will.

Stud.IP beschränkt sich daher konsequent auf den Einsatz von reinem HTML. Einige Komfortfunktionen werden über Javascript angeboten. Das System lässt sich jedoch auch in vollem Umfang ohne derartige Erweiterungen oder gar Plug-Ins bedienen, was bei den Studierenden auf große Zustimmung stößt – müssen sie sich doch nicht darum kümmern ein Flash-Plugin zu installieren oder eine Java-Runtime einzurichten.

Bei der GUI-Gestaltung wird ferner großer Wert auf konsistente und intuitive Bedienung gelegt, als vages Vorbild dient die Bedienung von Apple-Software mit klarer Iconographie und haptischen Entsprechungen wie “aufziehen”. Dabei wird in Rechnung gestellt, dass Studierende noch immer nicht flächendeckend über Breitbandzugänge verfügen: als Grundlage für die Menge der zu übermittelnden Daten dient immer noch das 56K-Modem. Daher finden keine großformatigen Schmuckgrafiken oder aufwändige Animationen Verwendung, vielmehr werden kompakte, immer wiederkehrende Grafikelemente verwendet.

Eine kontextsensitive Hilfe leitet den Nutzer durch das System: auf jeder Seite steht ein Hilfetext bereit, der sämtliche Funktionalitäten des jeweiligen Bereiches erläutert.

2.4 Schnittstellen

Die Förderprogramme im Bereich eLearning der letzten Jahre haben für eine unüberschaubare Flut an Insellösungen gesorgt. Schon länger wächst das Bewusstsein, dass diese Einzelmodule zumindest integrierbar sein sollten, im besten Fall kombinierbar. Im Bereich der Lernmodule bilden sich Standards wie SCORM heraus, auf anderen Ebenen existieren zumindest allgemein akzeptierte Datenstrukturen wie XML.

Stud.IP trägt dieser Entwicklung Rechnung und bietet diverse Schnittstellen zur Anbindung anderer System an: einen XML-Export für Veranstaltungskommentare und Teilnehmerlisten, eine iCal-Schittstelle zum Austausch und Synchronisation von Kalenderdaten sowie eine XML-RPC Schnittstelle zur Anbindung von spezialisierten Clientsystemen und zur “Fernsteuerung” des Systems.

Eine besondere Bedeutung kommt der LDAP-Unterstützung zu, mit deren Hilfe sich die Nutzerdaten etwa mit dem Studentenwerk abgleichen lassen – ein wesentlicher Schritt in Richtung universitätsweitem ”single-sign-on”. Durch die PlugIn-Architektur der Nutzer-Authentifizierung ist mit geringfügigen Modifikationen auch eine Anmeldung gegen einen Radius-Server möglich.

Als sehr praxistauglich hat sich auch das Konfigurationsmodul für die Anbindung externer Seiten erwiesen: relevante Daten wie Veranstaltungskommentar, Newsmeldungen oder Mitarbeiterdaten lassen sich aus Stud.IP heraus in bestehende Institutsseiten oder CMS-Systeme einbinden. Das Design der heraus gespiegelten Daten kann nahtlos dem Design der anfordernden Seite angepasst werden.

Eine weitere, sehr praxistaugliche Lösung finden die Anwender in der z39.50-Schnittstelle, mit der sich beliebige Bibliothekskataloge - etwa die Bestände der Deutschen Bibliothek (ddb) – abfragen und die Ergebnisse in die Lernumgebung integrieren lassen.

3 Anwendungsszenarien

3.1 Lehre

Kernaufgabe von Stud.IP ist die Unterstützung universitärer Lehre. Die dafür angebotenen Werkzeuge lassen sich einteilen in didaktische und administrative, wobei die Grenze fließend verläuft und Synergien angestrebt werden: ein eher didaktisch orientiertes Werkzeug wie das Forensystem kann auch administrative Abläufe unterstützen, etwa bei Nachfragen zum Ablauf der Veranstaltung: es ist effektiver die häufig gestellten Fragen einmalig im Forum zu beantworten, als in jeder Sprechstunde aufs neue.

Allen Werkzeugen gemein ist, dass sie innerhalb der Seminarumgebung für jede einzelne Veranstaltung zur Verfügung stehen.

Didaktische Werkzeuge

Wie in 1.1 beschrieben, war das Forensystem die Keimzelle von Stud.IP. Jede Veranstaltung beinhaltet ein Forensystem mit beliebig vielen Themenordnern, die Struktur des Forums ist baumartig aufgebaut (threaded discussion), auf Wunsch können die Nutzer die Ansicht in eine flache Ansicht (flat view) umschalten. Eine Reihe von Zusatzfunktionen stehen zur Verfügung wie Bewertung, Zitieren, Sortierung oder Filterung von Beiträgen.

Im Dateibereich können sowohl Lehrende ihre begleitenden Materialien wie Vorlesungsfolien oder Übungsaufgaben einstellen, als auch Studierende ihre Hausaufgaben oder Thesenpapiere "abgeben" – der physische Seminarordner entfällt. Für urheberrechtlich geschützte Inhalte wie gescannte Literatur steht eine Dokumentverlinkung zur Verfügung die sich gegen externe Dokumentenserver authentifizieren kann.

Mit Umfragen und Tests kann der Lehrende den Wissensstand seines Kurses abfragen, der Seminar-Chat erlaubt auch jenseits der Präsenzsitzung synchrone Kommunikation.

Mit dem Wiki-Web steht eine kollaborative Arbeitsumgebung mit vielfältigen Einsatzmöglichkeiten zur Verfügung– etwa freies Brainstorming, Glossaraufbau oder gemeinsame Textproduktion (dieser Artikel etwa ist mit Hilfe der Wiki-Umgebung als Werk mehrerer Autoren entstanden). Sämtliche Arbeitsschritte auf den untereinander verlinkten Seiten werden dabei inklusive Personenzuordnung protokolliert.

Administrative Werkzeuge

Die Literaturverwaltung greift direkt auf lokale und überregionale Bibliotheksbestände zu, wodurch eine händische Eingabe entfällt. Studierende und Lehrende können die fertigen Listen über eine Exportschnittstelle direkt in ihre lokalen Literaturverwaltungsprogramme (z.B. Endnote) übernehmen.

Das Newssystem erlaubt die schnelle Information über zeitkritische Änderungen wie Raumverschiebungen und kann etwa über eine WAP-Schnittstelle abgerufen werden.

Mit der dynamischen Teilnehmerliste und der angeschlossenen Gruppenverwaltung erhält der Lehrende ein komfortables Werkzeug zur Organisation seines Kurses.

Über verschiedene Zugangsregelungen werden Plätze in teilnehmerbeschränkten Veranstaltungen automatisch für die Studierenden transparent vergeben.

Der Ablaufplanassistent erzeugt automatisch die Präsenztermine, die in die Terminkalender der teilnehmenden Nutzer eingetragen werden.

Mit dem Evaluationstool kann eine standardisierte Lehrevaluation effektiv für beliebig viele Veranstaltungen durchgeführt werden, die Daten können per CSV-Export in Statistikprogrammen wie SPSS ausgewertet werden – wahlweise personalisiert oder anonymisiert (auch auf Datenbankebene).

3.2 Verwaltung

Im Laufe der Stud.IP-Entwicklung gewann die Unterstützung der verschiedenen universitären Verwaltungsebenen zunehmend an Bedeutung – nicht zuletzt, weil die universitätsweite Akzeptanz auch von der Verwaltung bestimmt wird und eine scharfe Abgrenzung zu rein didaktischen Bereichen weder möglich noch sinnvoll erscheint (siehe oben).

Mit dem dynamischen Vorlesungskommentar können universitätsweit oder nur für einzelne Bereiche alle Veranstaltungen nach verschiedenen Kriterien sortiert oder gruppiert ausgegeben werden, auch ein Export (etwa im XML-Format) steht zur Verfügung.

An die Veranstaltungsverwaltung gekoppelt ist eine komplexe Raum- und Ressourcenverwaltung, die sowohl ein Makro- (mit Hilfe eines zentralen Ressourcenadministrators) als auch ein Mikromanagement (Ressourcen wie Beamer können von Abteilungen eigenverantwortlich verwaltet werden) ermöglicht. Die Belegungspläne aller Ressourcen können öffentlich eingesehen werden.

Die Anbindung externer Seiten über eine SRI-Schnittstelle wurde bereits beschrieben, ein praktisches Werkzeug, um die Außendarstellung der Universität aktuell und einheitlich zu halten.

3.3 Der Mensch im Mittelpunkt – Kommunikation

Das Konzept der Personalisierung als ein zentrales Motivationsprinzip zieht sich durch alle Bereiche des Stud.IP-Systems: Ziel ist es, dass “soziale System” Universität auch mit seinen Menschen abzubilden und nicht die Benutzung einer "kalten" Verwaltungssoftware zu erzwingen. Eine Vielzahl von Funktionen konzentrieren sich daher auf die einzelnen Nutzer:

Für jeden registrierten Nutzer wird eine persönliche Homepage eingerichtet, die ohne HTML-Kenntnisse gepflegt und mit beliebigen Inhalten bestückt werden kann. Beispiele sind Angaben zum Lebenslauf oder Studienschwerpunkten. In einem Gästebuch können sich Besucher verewigen, großer Beliebtheit erfreuen sich auch die persönlichen Umfragen und Tests.

In speziell eingerichteten Community-Veranstaltungen kann losgelöst vom Fach oder der Veranstaltung mit anderen Nutzern über politische oder kulturelle Dinge debattiert werden. Dieses ist in vielen Fällen der zwanglose “Einstieg”, um sich mit den grundlegenden Funktionen der Plattform vertraut zu machen.

Der persönliche Terminkalender bietet weitreichende Organisationsmöglichkeiten. Die einzelnen Präsenzsitzungen werden automatisch eingetragen, eigene private Termine können ergänzt werden.

Auf der “Wer ist online”-Seite sieht man, wer außer einem selbst gerade im System eingeloggt ist. Auf der Score-Liste treten die Nutzer, wenn sie möchten, in einen humorvollen Wettbewerb um den höchsten Aktivitätswert im System.

Im Adressbuch werden die Kontaktdaten anderer Nutzer gesammelt und automatisch aktualisiert, wenn die eingetragenen Nutzer etwas an ihren eigenen Daten ändern. Die Einträge können in Gruppen organisiert und mittels vCard-Export in Organizer übertragen werden.

Im systemweiten, veranstaltungs- oder personenbezogenen Chat kann synchron kommuniziert werden. Ferner existiert ein systeminternes Nachrichtensystem mit aktivierbarer Mailweiterleitung zur asynchronen Kommunikation.

Generell gilt im Stud.IP-System: alles was gesagt und getan wird, wird von jemandem gesagt und getan. Durch die Realnamepflicht reicht ein Klick auf den Benutzernamen, um die persönliche Homepage aufzurufen. Das System erhält dadurch einen freundlichen und lebendigen Anstrich. Beispielsweise fällt die inhaltliche Bewertung von Diskussionbeiträgen aufgrund der zusätzlichen Informationen über den Autor leichter.

4 Evaluation

Interne Evaluationen von Stud.IP wurden an verschiedenen Einrichtungen durchgeführt. Hier sollen die beiden Evaluationen des Fachbereichs Informatik der Universität Rostock, Lehrstuhl Rechnerarchitektur, im Rahmen des Projekts “Notebook University Rostock” und des Zentrum zur Unterstützung virtueller Lehre der Universität Osnabrück (virtUOS) im Rahmen des “ELAN-Projekts” vorgestellt werden. Die Studien bzw. Vorträge können unter http://www.studip.de (Materialien / Evaluationen) heruntergeladen werden.

Am Lehrstuhl Rechnerarchitektur wurden die Plattformen Stud.IP 0.9, Clix Campus 4.0 und Blackboard ML verglichen. Analysiert wurden folgende Faktoren: Kosten, Support, Administrierbarkeit, Funktionen sowie Leistungsgrenzen.

Kosten: Stud.IP ist das mit Abstand günstigste System. Als Open-Source-Software ist die Anschaffung kostenlos. In der Studie wird darauf hingewiesen, dass für die Preisdifferenz zu den beiden übrigen Systemen ein erhebliches “Paket Entwicklerleistung zur Anpassung an lokale Bedürfnisse eingekauft werden” kann.

Support: Support kann für alle Systeme bei markteingeführten Unternehmen gekauft werden. Zum Support steht im Bericht: “Es muss hier betont werden, dass Stud.IP als Open Source System den Käufer, im Widerspruch zu gängigen Vorurteilen, nicht schlechter stellt, als dies bei einer Entscheidung für ein Closed-Source-System der Fall wäre. Stud.IP ist kommerzielle (d.h. unter geschäftlichen Gesichtspunkten entwickelte, vertriebene und gewartete) Software, die unter einem offenen Lizenzmodell (GPL) verteilt wird, und nicht etwa “Freeware”, für die sich niemand mehr verantwortlich fühlt.”

Administrierbarkeit: Hierzu findet sich im Abschluss-Statement folgendes: “Im Bezug auf Administrierbarkeit garantiert einzig Stud.IP, dass Administrationsaufgaben mit entsprechend feiner Granularität an Unteradministratoren, sprich Zuständige in einzelnen Instituten oder Fachbereichen, ausgelagert werden können.”

Funktionen: Hier wird Stud.IP besonders hinsichtlich seiner Funktionen für die Präsenzuniversität mit den entsprechenden Managementkomponenten als deutlich überlegen dargestellt. Ebenfalls werden die Kommunikationsbereiche von Stud.IP als besonders elaboriert beurteilt. Kritik wird am Fehlen von “Selbsttests”, “Shared Whiteboard” und “Evaluationen” geübt. Diese Möglichkeiten bestehen jedoch seit den Versionen 0.95 (Tests, Wiki-Web) bzw. 1.1 (Evaluationen).

Leistungsgrenzen: Es wird darauf hingewiesen, dass in Bezug auf die Leistungsgrenzen zu allen drei untersuchten Systemen “viele Fragen unbeantwortet bleiben”. Hierzu ist jedoch anzumerken, dass an der Universität Osnabrück über 21.000 Nutzer registriert sind. Mündlichen Aussagen von Herrn Thelen (virtUOS) zufolge waren im Verlauf von Anmeldeverfahren bereits über 200 gleichzeitig im System online.

Die Studie der Universität Rostock stellt folgende weitere Punkte bei der Bewertung von Stud.IP hervor: es wird keine weitere – lizenzkostenpflichtige – Software benötigt, einfaches Handling, große Übersichtlichkeit, sehr gute Benutzerführung, einziges System mit kontextsensitiver Hilfe.

Am Zentrum virtUOS wurde Stud.IP, WebCT und Blackboard hinsichtlich der “ISO 9241-10 – Grundsätze der Dialoggestaltung” untersucht (Ollermann, F. et al., 2003: Vortrag auf der Stud.IP-Tagung). An der Universität Osnabrück wurden die drei Systeme parallel installiert.

In Umfragen an Studierende und Dozenten wurden folgende Punkte bewertet: Aufgabenangemessenheit, Selbstbeschreibungsfähigkeit, Steuerbarkeit, Erwartungskonformität, Individualisierbarkeit und Erlernbarkeit. Auf Aussagen wie z.B. “Die Software bietet mir alle Möglichkeiten, die ich für die Bearbeitung meiner Aufgaben benötige.” (hier im Bereich Aufgabenangemessenheit) konnten die Befragten in einer Skala von 1 (stimmt nicht) bis 5 (stimmt sehr) antworten. Zudem konnten die Befragten “Keine Angabe” auswählen.

Zusammenfassend lässt sich feststellen, dass Stud.IP in allen Bereichen von Dozenten besser bewertet wurde als WebCT.

Durch die offene Systemarchitektur bietet Stud.IP Kommunikationswissenschaftlern ein lohnendes Forschungsgebiet, das mittlerweile in zwei Diplomarbeiten, einer Dissertation sowie einer Nutzerbefragung im Rahmen des Göttinger “Notebook University” Projektes bearbeitet wurde. Die Ergebnisse sind unter www.studip.de im Bereich “Materialien” einsehbar.

5 Nachhaltigkeit durch Support und Weiterentwicklung

5.1 Grundüberlegung

Besonders bei der Weiterentwicklung und der Qualitätssicherung kann es zu Zielkonflikten zwischen dem Open-Source-Ansatz "jeder kann partizipieren" und den Ansprüchen der Stud.IP-Betreiber (z.B. Rechenzentren) nach garantierter Qualitätssicherung, ständig verfügbarem Support und verbindlichen Ansprechpartnern kommen. Deshalb wird bei Überlegungen zur Anschaffung von Open-Source-Software immer wieder die Kritik geäußert, dass durch fehlende Organisationsstrukturen und fehlendem Support der Einsatz mit einem Risiko behaftet sei. Im Folgenden zeigen wir, dass diese Bedenken bezüglich des Einsatzes von Stud.IP als Open-Source-Software an zentraler Stelle in der Organisation einer Hochschule unbegründet sind. Dieses erreichen wir durch transparente Organisationsstrukturen bei Weiterentwicklung und Qualitätskontrolle sowie durch das Angebot eines geregelten Supports.

Wenngleich Stud.IP unter einer Open-Source-Lizenz steht, so handelt es sich keinesfalls um “Freeware”, für die sich niemand verantwortlich fühlt. Die data-quest GmbH hat Stud.IP in großen Teilen entwickelt und bietet Betreibern all jene Support-Leistungen an, welche oft nur von Closed-Source-Anbietern erwartet werden. Daneben werden spezielle Modifikationen und umfangreiche Weiterentwicklungen für die Betreiber angeboten. Generell lässt sich feststellen, dass Betreiber, Entwickler und Nutzer einer eLearning-Plattform unterschiedliche Anforderungen an Nachhaltigkeit und Support stellen.

5.2 Betreiber-Community

Bei den Betreibern von Stud.IP handelt es sich in der Regel um Hochschul-, Fakultäts- oder Institutsleitungen, welche die technische Verantwortung für den Betrieb des Systems an Rechenzentren oder EDV-Abteilungen delegieren.

Die data-quest GmbH informiert die Betreiber über anstehende Entwicklungen, Updates oder Bugs. Auf Wunsch werden auch Backups der Systeme durchgeführt. Daneben werden die Betreiber über Wünsche und Weiterentwicklungen Dritter informiert, sodass sich Interessengruppen bilden können. Hierdurch lassen sich gemeinsame Entwicklungen koordinieren, Arbeiten verteilen und damit Kosten für die Betreiber einsparen. Daneben bietet sich die Möglichkeit, gemeinsam Drittmittelanträge zu stellen.

Betreiber können Supportverträge mit der data-quest GmbH abschließen. Der Support umfasst jene Stud.IP-Versionen, welche unter http://sourceforge.net/projects/studip oder http://www.campussource.de von der data-quest GmbH publiziert wurden. Diese Verträge können technischen und/oder administrativen Support umfassen. Grundlage der Verträge ist ein Support-Punkte-System, wobei der tatsächlich geleistete Zeitaufwand abgerechnet wird. Die Abrechnung erfolgt viertelstundenweise. Reaktionszeiten sind vertraglich geregelt und liegen an Werktagen bei maximal vier Stunden. Der Bearbeitungszustand von Supportanfragen und alle gestellten Anfragen und deren Lösungen können in einem Statustracking-System verfolgt werden. Bei Bedarf lassen sich auch individuelle Supportverträge mit der data-quest GmbH aushandeln.

5.3 Entwickler-Community

Neben den Entwicklern der data-quest GmbH und der Göttinger Universität, entwickeln zunehmend Programmierer anderer Hochschulen mit an der Software. Daneben gibt es einige Privatpersonen (meist Studenten), die sich an der Entwicklung beteiligen. Insgesamt zählt die Entwickler-Community derzeit ca. 15 bis 20 Personen.

Die Entwicklung wird über einen eigens eingerichteten “Developer-Server” (http://develop.studip.de) koordiniert.

Für die Entwickler wurde eine eigene Stud.IP-Installation eingerichtet. Diese enthält den jeweils tagesaktuellen Entwicklungsstand der Software. Hier finden sich alle Richtlinien, die von den Entwickler zu beachten sind. Diese betreffen z.B. Codestyle, Internationalisierung, Sonderzeichenbehandlung und Kommentierungen. Das Bugtracking erfolgt ebenfalls auf der Developer-Installation. Bugs werden hier in einem Forum eingestellt, bewertet und die zuständige Person zur Behebung aufgefordert. Hieraus ergeben sich regelmäßig Diskussionen unter dem Aspekt “Bug oder Feature”. Die Nutzung einer Stud.IP-Installation für die Weiterentwicklung der Plattform gewährt ein umfangreiches Testen des Systems bereits während der Entwicklung.

Das stets aktuelle CVS ist generell für jeden mit einem Lesezugriff freigegeben. Die externen Entwickler “ziehen” sich einen CVS-Snapshot, machen ihre Weiterentwicklung und liefern ein kommentiertes Diff an data-quest. Hier werden die externen Komponenten einer Qualitätskontrolle unterzogen und in die offiziellen Modulen des Stud.IP-CVS eingearbeitet.

Entwicklungen, welche keiner Qualitätskontrolle von data-quest unterzogen wurden, können im CVS-Modul “Stud.IP-unsupported” ebenfalls der Allgemeinheit zur Verfügung gestellt werden. Für diese Entwicklungen kann natürlich keine Gewährleistung und kein Support übernommen werden.

Dokumentationen zur Entwicklungen lassen sich für Entwickler und Interessierte über die Systeme PHPDoc und Xref einsehen.

5.4 Release-Zyklen

Das offizielle Release einer neuen Stud.IP-Version erfolgt zweimal jährlich bei Sourceforge (http://sourceforge.net/projects/studip) und bei CampusSource (www.campussource.de). Service-Releases mit Bugfixes erscheinen bei Bedarf. Da Stud.IP bisher hauptsächlich an Hochschulen zum Einsatz kommt, orientiert sich der Release-Zyklus am hochschulspezifischen Halbjahresrhythmus. Die Entwicklung findet auf dem Entwickler-System statt, anschließend werden die Neuentwicklungen vor Semesterbeginn an der Universität Göttingen auf dem Produktivsystem installiert. Hier erfolgt nun der abschließende “Test” für den Produktiveinsatz durch derzeit fast 9.000 Nutzer. Unter Umständen werden Hotfixes für diese Installation im laufenden Semester vorgenommen. Gegen Ende des Semesters wird abschließend von data-quest ein Release veröffentlicht.

6 Ausblick

Im Frühjahr 2005 läuft Stud.IP an über 30 Standorten, davon in Osnabrück, Oldenburg und Rostock universitätsweit als offizielle Plattform. Die gewählte Software-Architektur (siehe 2.1) hat sich dabei als performant und stabil erwiesen, auch bei Nutzerzahlen von 21.000 und über 3.000 laufenden Veranstaltungen (Installation Osnabrück).

Zukünftige Entwicklungslinien von Stud.IP fokussieren auf zwei Bereiche: Zum einen wächst die generelle Bedeutung des Bereiches “Wissensmanagement”, mit all seinen Anforderungen an Vernetzung und Metadatenretrieval.

Zum anderen soll Stud.IP universitäre Forschergruppen noch effektiver unterstützen: In zunehmendem Maße werden Forschungsprojekte interdisziplinär und räumlich dispers durchgeführt. Damit einhergehend wächst der Bedarf an Kommunikation und Projektmanagement. Hier besteht die Hoffnung, dass die Umsetzung von Forschung und Lehre in einer einheitlichen Arbeitsumgebung die Universitäten wieder näher an das “Humboldtsche Ideal” heranführt.