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 Prüfungsanmeldung, Scheine noch analog im PA Stud-Info. Prüfungseinschreibung, 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

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

Pro

• bringt Lehre voran
• interuniversitäre Zusammenarbeit
• zugeschnitten auf die eigene Uni/Fakultät
• ein wachsendes System ist einfach
• Aufbau von KnowHow und Kompetenz an der Uni
• gute Systeme können verkauft werden (TU Graz, TU Dresden)
• kurzer Weg im Kompetenzgerangel
• kostensparender, da man nicht teuer 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
• Übersicht über alle nötigen Daten
  • 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 Software-Admin und System-Admin
• verbindliche funktionierende Prüfungsanmeldung (ohne BackUp script, das eine Anmeldung evtl. Überschreibt)
• Einschreibung in Übungen
• Bedienbarkeit (Usabilitystandards)
• konsequente und konsistente und nicht-komplexe Bedienung
• intuitive Bedienung
• Kalenderfunktionen (Import/Export/Übersicht über Termine/Links zu Übungsblättern etc. ...SMS bei Terminänderung … )
• konsequente Internationalität (Mehrsprachigkeit (Landessprache+Englisch n>2)
• Datenexport von allen vorhaneden Daten in offene Formate/dokumentierte Schnittstellen
• einfache Datenmigartion
• von Lehrstuhlseite: Platzzuweisungen für Prüfungen
• von universitärer Seite: Modularer Aufbau
• Barierefreiheit (kein JavaScript, Plattformunabhängigkeit, kein Flash)

Technische Betreuung des Systems muss dauerhaft und nachhaltig abgesichert sein

• sinnvolle Backup Lösung
• resolve PEBKAC

Vor der Anschaffung eines Systems

• Lobbyarbeit vermeiden (Interessenkonflikte unterbinden)
• Für und Wider erläutern-> kostenlos ist of umsonst und billig
• auf rechtliche Verpflichtungen hinweisen (Barierefreiheit, z.B.)
• Refferenzen von anderen Unis vorlegen, Kontakte herstellen.
• Macht in den Gremien Nutzen (FakRat, Senat, Konzil)
• Presse, Öffentlichkeit (allerletzte Möglichkeit, nur doppelte geprüfte Fakten veröffentlichen)

Wenn das System eingeführt wurde und schlecht ist

• zur Beschwerde motivieren
• Presse, Öffentlichkeit (allerletzte Möglichkeit, nur doppelte geprüfte Fakten veröffentlichen)