KIF365:Campus-Management-Systeme

Erfahrungsberichte

TU München

• demnächst System der TU Graz
• atm noch HIS/POS,
  • reicht nicht aus, bzw nicht umfassend, zusätzlich deswegen bis zu 3 Anmeldungen pro Prüfungen.
• Studenplanverwaltung: Fakultäseigenes System+UNIVIS
  • UNIVISVorteil: auch Veranstaltungen anderer Fakultäten
  • Fakultäseigenes System: Detailierte Informationen, da “Modulkatalog”
• Grundstudiumstool (selbst geschrieben):
  • Übungsgruppenanmeldesystem
  • Notenlisten
  • Sitzplatzbelegungen für Prüfungen
  • einige Sicherheitslücken
    • Manipulation der Parameter des HTTP-Requests
  • Autentifizierung via Browserzertifikat.
• Elearning-Plattform
  • Schlechte Bedienbarkeit
  • JavaScript
  • laaaaaangsam

Uni Karlsruhe

• Turotienvergabe via Webinscribe
  • Angabe von Präferenzen,
  • Zuteilung durch System
  • Frontend und Backand erneuert
• HIS
• Tutorienverwaltung durch institutseigen Tools oder 'BSCW
  • sehr chaotisch
• KING Karlsruher Integriertes Management
  • .net implementiert
  • M$ wirbt damit,
• Lernplattform ILIAS:
  • “Schreibtisch” mit Vorlesungen die man hört
  • passende Foren

Uni Würzburg

• SB@home
  • Übungseinschreibung zu Beginn eines Semesters wochenlang nicht erreichbar
• Moodle-System. Verwirrend zu bedienen, funktioniert recht gut.
• Institute haben auch noch eigene Systeme, werden aber nach und nach abgebaut und auf moodle umgestellt.

Uni Bremen

• Stud-IP
  • Übungseinschreibeung
  • Übungspaufgabenbgabe (eigentlich Mail und SVN)
• Stundenplangebasteltool
• Keine Online-Prüfungseinscreibung
• PABO

TU Darmstadt

• HIS/POS
  • schlechte Erfahrungen
  • Vorlesungsverzeichnis
  • Übungseinschreibung.
  • großes WTF?...
• Prüfungseinschreibung analog
• Verschiedene Raumbuchungssysteme

TU Ilmenau

• hab nich zugehört :D

Uni Magdeburg

• UNIVIS
  • schwer zu bedienen
  • Volesungsverzeichnis
  • Raumvergabe**Adressen von Mitarbeiter
  • Stundenplantool (exportierungsfähig)
  • Datenbank für alle öffentlichen Daten
• HISQIS
  • Prüfungsanmeldung
    • für große Studiengänge funktionierts
    • bei kleinen Studiengängen analoge Prüfungseinschreibung
  • zentrale Stammdatenhaltung,
  • Datenbank im Inf-Rechenzentrum
  • sicherheitstechnisch schlecht (nur Passwortschutz)
  • Übungseinschreibung: früher durch Lehrstuhl, jetze für jedes Institut.

Uni Paderborn

• HIS/POS Vorlesungsverzeichnis, Prüfungsanmeldung und -historie, Bescheinigungen werden im Prüfungssekretariat ausgestellt.
• Stud-Info. Prüfungseinschreibung in der Informatik, mit Prüfungsergebnissen, funktioniert unter Last gar nicht.
• Koala, Übungsmaterialen online stellen, Foren, Übungsabgabe, wird an gesamter Uni verwendet. Versenden von Mails an Übungsteilnehmer

TU Dresden

• jExam
  • selbstgerschrieben von Softwaretechnologielehrstuh der Fakultät Informatik
  • Studentenprojekt
  • in Java
  • Probleme zu Semesterbegin: Überlastung
  • Notenbekanntgabe
  • Prüfungseinschreibeung
  • Übungseinschreibung
  • Stundenplantool
• HIS
  • benutzt die Fak Inf nicht, deswegen keine Infos hierzu
• OPAL Bildungsportal
  • Datensammelmaschine
  • äh, ja, keiner weiß was, weil Lernen im Internet ist doof

HU Berlin

• AGNES (HISPOS)
  • Probleme wie bei allen anderen. (Prüfungsanmeldung)
  • Veranstaltungsverzeichnis
• Goya (Eigenentwicklung; nur von Inst. f.Informatik genutzt)
  • Performanceprobleme
  • Weiterentwicklung und Support fraglich
  • Synchronisation mit anderen Systemen nur manuell
  • ebenfalls Veranstaltungsverzeichnis, allerdings teilw. Unterschiede in Angaben
• moodle
  • Accountname und Passwort automatisch identisch mit HISPOS

TU Graz

• CampusOnline
  • kann "alles", bis auf Verwrechnung/Buchhaltung.
  • alle Studiendokumente verfügbar außer Abschlussdokumente
  • es kann NICHT: äh, verwirrend, kam nicht hinterher
• Semesteranfang ist lasttechnisch Problem wie überall.
• hohe Zufriedenheit bei Studenten
• kann man kaufen

Uni Hamburg

• Datenlosten CampusNet, STiNE genannt
  • seit 2006 in Betrieb
  • Anmeldephase nicht geklappt
  • Sicherheitslücken im System gefunden
    • sämtliche persönliche Daten waren einsehbar
    • Nachrichtendienst (zum Versenden und Generieren von Nachrichten) wurde daraufhin abgeschalten
    • Datenschutzmensch für das System an der Uni hat den Code nie zu sehen bekommen
  • herausgegebene Passwörter funktioierten nicht
  • Systemfehler an der Tagesordnung
    • 37.000 Studenten zu einer Veranstaltung angemeldet
    • Veranstaltungen verschwinden, und tauchen wieder auf
  • Adressenverwaltung
  • Semesterbescheinigungen zum Ausdrucken
  • Beurlaubung und Exmatrikulation über das System
  • System kann keine zulassungsfreien Studiengänge
    • Workaround: Abinoten im System wurden bei allen Studenten auf 1.0 gesetzt
  • Resulotion siehe: http://www.informatik.uni-hamburg.de/Fachschaft/2008/stine-stoppen.pdf
    • Einschüchterung durch Unileitung als einzige Reaktion

ZU EMPFEHLEN: http://svine.tutnicht.de/schtiehne.swf

Für und Wider von Selbstentwicklung solcher Systeme an der eigenen Uni

Pro

Im Rahmen der Lehre (Softwareentwicklung und aehnliches) bringt die Entwicklung eines CMS handfeste Erfahrungen, die spaeter fuer die Studenten nuetzlich sein koennten. Auch der Bezug zu einem realen Projekt kann die Motivation zum gewissenhaften Arbeiten der Studenten steigern.

Universitaeten koennen sich gegenseitig unterstuetzen und einzelne Teilbereiche der Entwicklung je nach Notwendigkeit des jeweiligen Lehrplanes verteilen.

Das CMS ist passgenau auf die Vorgaenge der eigenen Universitaet abgebildet.

Durch einen modularen Aufbau ist das Entwickeln durch einzelne Teams ueber einen laengeren Zeitraum sehr gut moeglich. Auch das spaetere Erweitern ist durch die eigene Universitaet ist moeglich.

Den Studenten werden durch die Komplexitaet eines solchen Projektes die essentiellen Grundsaetze der Softwareentwicklung (sauberer Code/Dokumentation, etc) verdeutlicht. Die Theorie der Fachausbildung wird praktisch gefestigt und vertieft.

Ausgereifte Systeme sind potentiell wertvoll fuer den Wissenstransfer mit anderen Universitaeten, wie am Beispiel der Systeme der TU Graz und TU Dresden zu sehen ist.

Bei auftretenden Problemen mit dem System ist der Kontakt zu den Entwicklern sehr viel einfacher und direkter als bei ausser Haus Loesungen.

Die Entwicklung eines internen Systems ist kostensparender, da man nicht teuere Fremdsoftware einkaufen muss.

Contra

• der Überblick kann eventuell nicht gewonnen werden um Unis mit komischen Studiengängen zu verwalten
• die Analyse der spezifischen Anforderungen einer Fakultät ist von Studenten einer anderen Fakultät vom Zeitaufwand und dem Verständnis her nicht machbar
• technische Anforderungen müssen geschaffen werden, die eventuell sehr umfangreich sind
• ziemlich viel zusammenarbeit von verschiedenen Bereichen, Büropingpong
• man-power eventuell nicht vorhanden
• Verlust von Know-How durch Weggang der Entwickler
• Wartungsaufwand liegt beim Entwickler, dafür bei der Uni, wenn sich niemand findet, gibts Probleme.

Anforderungen an ein Campus-Management-System

• es muss funktionieren

Sicherheit

• hohe Anforderung an Sicherheit
• besonders hoher Schutz privater Daten
• Signatur beim Senden von Daten
• verschlüsseltes versenden von Daten (E-Mail)
• Zugriffsrechte klar dokumentieren und Zugriff protokollieren
  • Trennung zwischen Anwendungs-Admin und System-Admin

Bedienung

• Bedienbarkeit (Usabilitystandards)
• konsequente und konsistente und nicht-komplexe Bedienung
• intuitive Bedienung
• konsequente,vollständige Internationalität (Mehrsprachigkeit (Landessprache+Englisch n>2)
• uneingeschränkte Erreichbarkeit

Verfügbarkeit

• Plattformunabhängigkeit (kein (clientseitiges) JavaScript, unabh. von OS und Hardware, kein Flash)
• Technische Betreuung des Systems muss dauerhaft und nachhaltig (inkl. Finanzierung) abgesichert sein
• Zukunftsicherheit

Minimalfunktionalität

• Übersicht über alle nötigen Daten
• verbindliche funktionierende Prüfungsanmeldung (ohne BackUp script, das eine Anmeldung evtl. Überschreibt)
• Einschreibung in Übungen
• Kalenderfunktionen (Import/Export/Übersicht über Termine/Links zu Übungsblättern etc. ...SMS bei Terminänderung … )
• sinnvolle Backuplösung
• Datenschnittstelle zu allen vorhandenen Daten in offene Formate/dokumentierte Schnittstellen / einfache Datenmigration?
• Studierendendokumente

zusätzliche Funktionalität

• von Lehrstuhlseite: Platzzuweisungen für Prüfungen
• bei Selbstentwicklung: Modularer Aufbau

• resolve PEBKAC

Einwirkungsmöglichkeiten der Studenten

Vor der Anschaffung eines Systems

• Bei der Auswahl des Systems sollen keine Interessenkonflikte entstehen, in dem Sinne, dass Personen von Herstellerseite beeinflusst werden. Es sollten Systeme vorgezogen werden, bei denen keine Beziehungen von Mitarbeitern der Hochschule zur Herstellerfirma existieren.

• Ein kostenloses System hat zwar den Preisvorteil bei der Einführung, kann aber nicht unbedingt alle Anforderungen erfüllen (z.B. nicht alle Prüfungsordnungen werden modelliert).

• Es sollte auf rechtliche Verpflichtungen hingewiesen werden (z.B. Barierefreiheit)

• Bei anderen Fachschaften deren Erfahrungen erfragen. Kontakte zu Personen herstellen, die bei oder vor der Einführung eines Systems beteiligt waren.

• Man sollte in Gremien Informationen geben, damit diese von höherer Position an die Hochschulleitung getragen werden.

• Notfalls an die Presse/Öffentlichkeit treten und auf Probleme eines Systems hinweisen. Wichtig: Nur doppelt geprüfte Fakten veröffentlichen.

• Studenten können sich anbieten eine Beurteilung (Testen der Funktionen) der bewerbenden Systeme durchzuführen. Andere Entscheidungsträger könnten diese Entlastung gutheißen und ihre Beurteilung entsprechend treffen.

Wenn das System eingeführt wurde und schlecht ist

• Einzelne Studenten können dazu motiviert werden Beschwerde einzureichen, da dies mehr Aussagekraft haben kann als eine Fachschaft, die sowieso ständig mitredet. Einzelne Studenten wenden sich eher selten an die Hochschulleitung.

• Notfalls an die Presse/Öffentlichkeit treten und auf Probleme eines Systems hinweisen. Wichtig: Nur doppelt geprüfte Fakten veröffentlichen.