KIF365:Campus-Management-Systeme

Aus KIF

Beta

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 (HISBUS)
    • Probleme wie bei allen anderen. (Prüfungsanmeldung)
  • Goya (Eigenentwicklung)
    • Performanceprobleme
  • moodle

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)

Wwenn das System eingeführt wurde nud schlecht ist

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