KIF365:Campus-Management-Systeme: Unterschied zwischen den Versionen

Aus KIF
(Die Seite wurde neu angelegt: =PRE ALPHA= Campusmanagementsysteme Erfahrungsberichte München (TU), demnächst System der Uni Wien. atm noch HIS/POS, reicht nicht aus, bzw nicht umfassend, zusä...)
 
Keine Bearbeitungszusammenfassung
 
(44 dazwischenliegende Versionen von 16 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
=PRE ALPHA=


=Erfahrungsberichte=


Campusmanagementsysteme
==== HIS-Partner ====
* habe da grade eine Liste gefunden:
** http://www.his.de/partner


===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'''
**'''UNIVIS'''Vorteil: 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


Erfahrungsberichte
===FH München===
München (TU), demnächst System der Uni Wien.
* Eigenentwicklung PRIMUSS [[http://www.fh-muenchen.de/home/fhm/pressestelle/fhnachrichten/d_03_2005.pcms#primuss]]
atm noch HIS/POS, reicht nicht aus, bzw nicht umfassend, zusätzlich deswegen bis zu 3 Anmeldungen pro Prüfungen.
* Soll laut Florian viele hier geforderte Punkte bereits efüllen
Studenplanverwaltung: eigenes System+UNIVIS
UNIVIS-Vorteil: Detailierte Informationen, da “Modulkatalog”
Grundstudiumstool (selbst geschrieben): Übungsgruppenanmeldesystem, Notenlisten, Sitzplatzbelegungen für Prüfungen. Einige Sicherheitslücken, Manipulation durch PHP-Link ID-Mitschickgehacke. Autentifizierung via Browserzertifikat.
Elearning Plattform. Schlechte Bedienbarkeit, JavaScript. Buggy&langsam
Subversionsystem demnächst
Uni Kahrlsruhe Turotienvergabe “Webinscribe” → Angabe von Präferenzen, zuteilung durch system,  Frontend und Backand neu entwickelt
HIS
Tutorienverwaltung Institutseigen oder BSCW, sehr chaortisch
KING, Karlsruher Integriertes Management. .net implementiert. MS wirbt damit,
Lernplattform, ILIAS: “Schreibtisch” mit Vorlesungen die man hört dazu passende Foren,
Uni Würzburg
SB@home, Übungseinschreibung,  Wochen lang nicht errecihbar zu Beginn eines Semesters, weil überlastet.
Moodle-System. Verwirrden 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, übungsplatzabgabe (eigentlich Mail und SVN), Stundenplangebastel.
Keine Online-Prüfungseinscreibung.PABO.
TU Darmstatd.
HIS/POS, schlechte Erfahrungen. Vorlesungsverzeichnis, Übungseinschreibung. “WTF”?... “
Prüfungseinschreibung analog.
Verschiedene Raumbuchungssysteme
Ilmenau
hab nich zugehört
Magdeburg
UNIVIS, is wohl schwer zu bedienen.
Volesungsverzeichnis, Raumvergabe, Adressen von Mitarbeiter, Stundenplantool (exportierungsfähig), Datenbank für alle öffentlichen Daten
HISQIS für 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 egener 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
HIS
HU Berlin
AGNES (HISBUS), Probleme wie bei allen anderen. (prüfungsanmeldung)
Goya (Eigenentwicklung), Performanceprobleme
moodle
TU Graz
CampusOnline, alles, bis auf Verwrechnung/Buchhaltung.
Man bekommt alles, außer Abschlussdokumente
es kann NICHT: oO
semesteranfang ist lasttechnisch Problem wie überall.
Hohe zufriedenheit bei studenten
kann man kaufen


Für Selbstentwicklung:
===Uni Karlsruhe===
bringt Lehre voran
*Turotienvergabe via '''Webinscribe'''
interuniversitäre Zusammenarbeit
**Angabe von Präferenzen,
zugeschnitten auf die eigene Uni/Fakultät
**Zuteilung durch System
ein wachsendes System ist einfach
**Frontend und Backand erneuert
Aufbau von KnowHow an der Uni
*'''HIS'''
gute Systeme können verkauft werden (TU Graz, TU Dresden)
*Tutorienverwaltung durch institutseigene Tools oder '''BSCW'''
kurzer Weg im Kompetenzgerangel
**sehr chaotisch
kostensparender, da man nicht teuer einkaufen muss
*'''KING''' Karlsruher Integriertes Management
gegen Selbstentwicklung:
**.net implementiert
der Überblick kann eventuell nicht gewonnen werden um  Unis mit komischen Studiengangenzu verwalten
**M$ wirbt damit,
die Analyse von den spezifischen Anforderungen einer Fakultät ist von Studenten einer anderen Fakultät nicht machbar
*Lernplattform '''ILIAS''':  
technische Anforderungen müssen geschaffen werden, die eventuell sehr umfangreich sind
**“Schreibtisch” mit Vorlesungen die man hört
ziemlich viel zusammenarbeit von verschiedenen Bereichen, Büropingpong
**passende Foren
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.


===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''' aka FlexNow


Anforderungen an ein Campus-Management-System
===TU Darmstadt===
es muss funktionieren
*'''HIS/POS'''
Übersicht über alle nötigen Daten
**schlechte Erfahrungen
Hohe Anforderung an Sicherheit, besonders hoher Schutz privater Daten
**Vorlesungsverzeichnis
Signatur beim Senden von Daten
**Übungseinschreibung.  
verschlüsseltes versenden von Daten (E-Mail)
**'''großes WTF?... '''
Zugriffsrechte klar dokumentieren und Zugriff protokollieren
*Prüfungseinschreibung analog
Trennung zwischen Software-Admin und System-Admin
*Verschiedene Raumbuchungssysteme
verbindliche funktionierende Prüfungsanmeldung (ohne BackUp script, das eine Anmeldung evtl. Überschreibt)
Einschreibung in Übungseinschreiben
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, 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
resolve PEBKAC


===TU Ilmenau===
* HIS, Version 8.1.0 vom 02.02.2006 :)
* unbekannt, wo das überall eingesetzt wird
* zumindest bei Bescheinigungen.. also offensichtlich Studiumsverwaltung


===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.


things to do wenn ein System eingeführt werden soll
===Uni Paderborn===
Lobbyarbeit vermeiden (Interessenkonflikte unterbinden)
*HIS/POS Vorlesungsverzeichnis, Prüfungsanmeldung und -historie, Bescheinigungen werden im Prüfungssekretariat ausgestellt.
für und wider erläutern → kostenlos ist of umsonst und billig
*Stud-Info. Prüfungseinschreibung in der Informatik, mit Prüfungsergebnissen, funktioniert unter Last gar nicht.
auf rechtliche Verpflichtungen hinweisen (Barierefreiheit, z.B.)
*Koala, Übungsmaterialen online stellen, Foren, Übungsabgabe, wird an gesamter Uni verwendet. Versenden von Mails an Übungsteilnehmer
Refferenzen von anderen Unis vorlegen, Kontakte herstellen.
*CampusNet wird unter dem Namen PAUL zum Sommersemester 09 eingeführt
Macht in den Gremien Nutzen (FakRat, Senat, Konzil)
 
Presse, Öffentlichkeit (allerletzte Möglichkeit, nur doppelte geprüfte Fakten veröffentlichen)
===TU Dresden===
things to do,  wenn das System eingeführt wurde nud schlecht ist
*jExam
zur Beschwerde motivieren
**selbstgerschrieben von Softwaretechnologielehrstuhl der Fakultät Informatik
Presse, Öffentlichkeit (allerletzte Möglichkeit, nur doppelte geprüfte Fakten veröffentlichen)
**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 in die Hose gegangen:
****Durch update STiNe nicht erreichbar, Erstis konnten sich nicht registrieren etc...
**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. Ausserdem ist es eine ideale Moeglichkeit einer Ausgruendung.
 
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===
 
Die Analysephase kann aus einem ueberwiegend subjektiven Blickwinkel sehr schwierig werden, da Studiengaenge mit komplexen Regelungen nicht sofort erkannt/ueberblickt werden koennen. Der Einblick der Studenten in alle Ablaeufe der Universitaet ist nicht gegeben und erfordert weitgehende Vorbereitung und Zusammenarbeit mit weiteren Teilen der Universitaet, wodurch der Zeit- und Managementaufwand unverhaeltnismaessig erhoeht wird.
 
Um das Projekt in einem sinnvollen Rahmen zu entwickeln, muessen verschiedene Fachbereiche reibungslos zusammenarbeiten, was sich oft schwierig gestaltet.
 
Durch den grossen Umfang des Projektes ist es fuer fast alle Fakultaeten unmoeglich auf entsprechend qualifizertes Personal zurueckzugreifen.
 
Es besteht die Gefahr, dass Mangels eines Wartungsvertrages mit dem ausfuehrenden Lehrstuhl eine kontinuierliche Pflege und Aktualisierung des Systems nicht garantiert ist. Der Entwickler ist hier nicht in der Lage ueber einen laengeren Zeitraum die eben genannten Punkte zu erfuellen, da seine Zeit an der Uni in der Regel begrenzt ist.
 
=Anforderungen an ein Campus-Management-System=
;es muss funktionieren
:Das System muss dauerhaft zuverlässig arbeiten. Auch unter hoher Lastanforderung und während systeminterner Prozesse(z.B. Backups) muss die effiziente Bedienbarkeit gewährleistet sein.
;Helpdesk auch für Studierende
:Auch die Studierenden benötigen Ansprechpartner, die vor Ort und per Telefon erreichbar sind, zur Lösung akuter Probleme. Einführenden Schulungen müssen angeboten werden.
 
==Sicherheit==
;hohe Anforderung an Sicherheit
;absoluter Schutz privater Daten
:Nur Personen, die notwendig mit den Daten arbeiten müssen dürfen diese einsehen. Studierende dürfen nur auf ihre eigenen Daten zugreifen. Persönliche Daten dürfen nicht öffentlich angezeigt werden.
;transparente Zugriffsrechte
:Berechtigungen müssen feingranular vergeben werden und einsehbar sein.
;Zugriff protokollieren
:Alle Änderungen an studentischen Daten müssen persönlich und zeitlich zuordnungsbar protokolliert werden und einsehbar sein.
;Trennung zwischen Anwendungs-Admin und System-Admin
:Der Regelbetrieb muss ohne System-Adminrechte,d.h. uneingeschränkte Zugriffsrechte, möglich sein, das schließt auch Wartungsarbeiten (z.B. Backups) ein.
 
==Bedienung==
;Bedienbarkeit
:Allgemeine Usability-Standards sind einzuhalten. Das schließt konsistente und nicht-komplexe Bedienung ein.
;intuitive Bedienung für alle Benutzergruppen
:Weil ein Campus-Management-System die Schnittstelle zu allen Abläufe der Hochschule bildet, muss sichergestellt werden, dass alle Benutzergruppe das System leicht bedienen können. Die Bedienungsabläufe müssen auch für Studierende optimiert sein. Insbesondere computerunerfahrene Studierende müssen das System ohne Probleme nutzen können.
;Barrierefreiheit
:Den einschlägigen Vorschriften zur Barrierefreihiet ist Folge zu leisten.
;Mehrsprachigkeit
:Das komplette System, inklusive Dokumente und Bedienelemente, muss zumindest in Landessprache und Englisch verfügbar sein.
;uneingeschränkte Erreichbarkeit
:Die Benutzung darf nicht auf bestimmte Bereiche wie z.B. Campus, IP-Bereich, VPN-Verbindung beschränkt sein.
 
==Verfügbarkeit==
;Plattformunabhängigkeit
:Das System muss sich an aktuelle Standards wie z.B. die des W3C halten und von allen gängigen Betriebssystemen benutzbar sein.
;Zukunftsicherheit
:Die technische Betreuung des Systems muss dauerhaft persnonell und finanziell abgesichert sein.
 
==Minimalfunktionalität==
;Übersicht über alle nötigen Daten
:Studierende müssen die Möglichkeit haben alle studienrelevanten Daten wie z.B. Termine, Personendaten, Organisationsdaten, Studienleistungen einsehen zu können.
;Prüfungsanmeldung
:Verbindliche An- und Abmeldung zu Prüfungen soll über das System zuverlässig möglich sein. Der Status der Anmeldung muss jederzeit überprüfbar sein.
;Anmeldung zu Veranstaltungen
:Die Studenten müssen sich zu allen teilnehmerbeschränkten Veranstaltungen an- und abmelden können.
;Kalenderfunktionen
:Import-/Exportfunktion für gängige Kalenderprogramme sollten vorhanden sein
:System muss eine Übersicht über Termine mit Links zu Übungsblättern enthalten
:Eine Benachrichtigung per Mail und optional SMS muss einstellbar sein
;sinnvolle Backuplösung
:Das Backup darf nicht zum Aussetzen des Betriebs führen. Der Abstand des Backups muss gering genug sein, um Verbindlichkeit s.o. sicherzustellen.
;Datenschnittstelle zu allen vorhandenen Daten in offene Formate/dokumentierte Schnittstellen / einfache Datenmigration?
:Daten müssen in standardisierten Formaten wie z.B. PDF,xml,OpenDocument u.ä. zumindest ausgegeben werden können. Alle solche Schnittstellen des Systems sollen auch in Dokumentation und Hilfe angegeben werden.
;Studierendendokumente
:zur Erzeugung von elektronischen Dokumenten s.u.
 
==zusätzliche Funktionalität==
;von Lehrstuhlseite: Platzzuweisungen für Prüfungen
;bei Selbstentwicklung: Modularer Aufbau
;Signatur beim Senden von Daten
;verschlüsseltes versenden von Daten (E-Mail)
 
;'''resolve PEBKAC'''
 
=Erzeugung von elektronischen Dokumenten=
Ein Campus Management System soll in der Lage sein elektronische Dokumente für z.B. Zeugnisse oder Studienbescheinigungen zu erstellen, ohne dass eine Unterschrift oder ein Stempel nötig ist. Dabei besteht das Problem, dass die Authentizität der Dokumente von öffentlichen Stellen überprüfbar sein muss. Grundsätzlich besteht bei Dokumenten, die eigenständig auf Papier ausgedruckt werden die Möglichkeit einer Fälschung, da keine Siegel oder Unterschriften die Echtheit bezeugen.
 
Eine Möglichkeit diesem nachzukommen ist die Erstellung einer Kennziffer, welche dem Dokument eindeutig zugeordnet ist und über eine Webseite die Überprüfung der relevanten Daten ermöglicht. Die Kennziffer muss dabei so gestaltet werden, dass kein gezieltes Durchsuchen des Kennziffernraumes möglich ist. Das könnte durch ausreichend großen Kennziffernraum und Schutz durch Prüfzeichen erreicht werden. Eine andere Möglichkeit ist die digitale Signatur des Dokuments, welche dem Dokument beigefügt wird. Eine Institution ist dann in der Lage mit der Signatur die Authentizität des Dokumentes zu überprüfen.
 
 
 
=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. Barrierefreiheit)
 
*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.

Aktuelle Version vom 15. Juli 2009, 10:43 Uhr

Erfahrungsberichte[Bearbeiten]

HIS-Partner[Bearbeiten]

TU München[Bearbeiten]

  • 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

FH München[Bearbeiten]

  • Eigenentwicklung PRIMUSS [[1]]
  • Soll laut Florian viele hier geforderte Punkte bereits efüllen

Uni Karlsruhe[Bearbeiten]

  • Turotienvergabe via Webinscribe
    • Angabe von Präferenzen,
    • Zuteilung durch System
    • Frontend und Backand erneuert
  • HIS
  • Tutorienverwaltung durch institutseigene 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[Bearbeiten]

  • 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[Bearbeiten]

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

TU Darmstadt[Bearbeiten]

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

TU Ilmenau[Bearbeiten]

  • HIS, Version 8.1.0 vom 02.02.2006 :)
  • unbekannt, wo das überall eingesetzt wird
  • zumindest bei Bescheinigungen.. also offensichtlich Studiumsverwaltung

Uni Magdeburg[Bearbeiten]

  • 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[Bearbeiten]

  • 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
  • CampusNet wird unter dem Namen PAUL zum Sommersemester 09 eingeführt

TU Dresden[Bearbeiten]

  • jExam
    • selbstgerschrieben von Softwaretechnologielehrstuhl 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[Bearbeiten]

  • 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[Bearbeiten]

  • 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[Bearbeiten]

  • Datenlosten CampusNet, STiNE genannt
    • seit 2006 in Betrieb
    • Anmeldephase in die Hose gegangen:
        • Durch update STiNe nicht erreichbar, Erstis konnten sich nicht registrieren etc...
    • 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[Bearbeiten]

Pro[Bearbeiten]

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. Ausserdem ist es eine ideale Moeglichkeit einer Ausgruendung.

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[Bearbeiten]

Die Analysephase kann aus einem ueberwiegend subjektiven Blickwinkel sehr schwierig werden, da Studiengaenge mit komplexen Regelungen nicht sofort erkannt/ueberblickt werden koennen. Der Einblick der Studenten in alle Ablaeufe der Universitaet ist nicht gegeben und erfordert weitgehende Vorbereitung und Zusammenarbeit mit weiteren Teilen der Universitaet, wodurch der Zeit- und Managementaufwand unverhaeltnismaessig erhoeht wird.

Um das Projekt in einem sinnvollen Rahmen zu entwickeln, muessen verschiedene Fachbereiche reibungslos zusammenarbeiten, was sich oft schwierig gestaltet.

Durch den grossen Umfang des Projektes ist es fuer fast alle Fakultaeten unmoeglich auf entsprechend qualifizertes Personal zurueckzugreifen.

Es besteht die Gefahr, dass Mangels eines Wartungsvertrages mit dem ausfuehrenden Lehrstuhl eine kontinuierliche Pflege und Aktualisierung des Systems nicht garantiert ist. Der Entwickler ist hier nicht in der Lage ueber einen laengeren Zeitraum die eben genannten Punkte zu erfuellen, da seine Zeit an der Uni in der Regel begrenzt ist.

Anforderungen an ein Campus-Management-System[Bearbeiten]

es muss funktionieren
Das System muss dauerhaft zuverlässig arbeiten. Auch unter hoher Lastanforderung und während systeminterner Prozesse(z.B. Backups) muss die effiziente Bedienbarkeit gewährleistet sein.
Helpdesk auch für Studierende
Auch die Studierenden benötigen Ansprechpartner, die vor Ort und per Telefon erreichbar sind, zur Lösung akuter Probleme. Einführenden Schulungen müssen angeboten werden.

Sicherheit[Bearbeiten]

hohe Anforderung an Sicherheit
absoluter Schutz privater Daten
Nur Personen, die notwendig mit den Daten arbeiten müssen dürfen diese einsehen. Studierende dürfen nur auf ihre eigenen Daten zugreifen. Persönliche Daten dürfen nicht öffentlich angezeigt werden.
transparente Zugriffsrechte
Berechtigungen müssen feingranular vergeben werden und einsehbar sein.
Zugriff protokollieren
Alle Änderungen an studentischen Daten müssen persönlich und zeitlich zuordnungsbar protokolliert werden und einsehbar sein.
Trennung zwischen Anwendungs-Admin und System-Admin
Der Regelbetrieb muss ohne System-Adminrechte,d.h. uneingeschränkte Zugriffsrechte, möglich sein, das schließt auch Wartungsarbeiten (z.B. Backups) ein.

Bedienung[Bearbeiten]

Bedienbarkeit
Allgemeine Usability-Standards sind einzuhalten. Das schließt konsistente und nicht-komplexe Bedienung ein.
intuitive Bedienung für alle Benutzergruppen
Weil ein Campus-Management-System die Schnittstelle zu allen Abläufe der Hochschule bildet, muss sichergestellt werden, dass alle Benutzergruppe das System leicht bedienen können. Die Bedienungsabläufe müssen auch für Studierende optimiert sein. Insbesondere computerunerfahrene Studierende müssen das System ohne Probleme nutzen können.
Barrierefreiheit
Den einschlägigen Vorschriften zur Barrierefreihiet ist Folge zu leisten.
Mehrsprachigkeit
Das komplette System, inklusive Dokumente und Bedienelemente, muss zumindest in Landessprache und Englisch verfügbar sein.
uneingeschränkte Erreichbarkeit
Die Benutzung darf nicht auf bestimmte Bereiche wie z.B. Campus, IP-Bereich, VPN-Verbindung beschränkt sein.

Verfügbarkeit[Bearbeiten]

Plattformunabhängigkeit
Das System muss sich an aktuelle Standards wie z.B. die des W3C halten und von allen gängigen Betriebssystemen benutzbar sein.
Zukunftsicherheit
Die technische Betreuung des Systems muss dauerhaft persnonell und finanziell abgesichert sein.

Minimalfunktionalität[Bearbeiten]

Übersicht über alle nötigen Daten
Studierende müssen die Möglichkeit haben alle studienrelevanten Daten wie z.B. Termine, Personendaten, Organisationsdaten, Studienleistungen einsehen zu können.
Prüfungsanmeldung
Verbindliche An- und Abmeldung zu Prüfungen soll über das System zuverlässig möglich sein. Der Status der Anmeldung muss jederzeit überprüfbar sein.
Anmeldung zu Veranstaltungen
Die Studenten müssen sich zu allen teilnehmerbeschränkten Veranstaltungen an- und abmelden können.
Kalenderfunktionen
Import-/Exportfunktion für gängige Kalenderprogramme sollten vorhanden sein
System muss eine Übersicht über Termine mit Links zu Übungsblättern enthalten
Eine Benachrichtigung per Mail und optional SMS muss einstellbar sein
sinnvolle Backuplösung
Das Backup darf nicht zum Aussetzen des Betriebs führen. Der Abstand des Backups muss gering genug sein, um Verbindlichkeit s.o. sicherzustellen.
Datenschnittstelle zu allen vorhandenen Daten in offene Formate/dokumentierte Schnittstellen / einfache Datenmigration?
Daten müssen in standardisierten Formaten wie z.B. PDF,xml,OpenDocument u.ä. zumindest ausgegeben werden können. Alle solche Schnittstellen des Systems sollen auch in Dokumentation und Hilfe angegeben werden.
Studierendendokumente
zur Erzeugung von elektronischen Dokumenten s.u.

zusätzliche Funktionalität[Bearbeiten]

von Lehrstuhlseite
Platzzuweisungen für Prüfungen
bei Selbstentwicklung
Modularer Aufbau
Signatur beim Senden von Daten
verschlüsseltes versenden von Daten (E-Mail)
resolve PEBKAC

Erzeugung von elektronischen Dokumenten[Bearbeiten]

Ein Campus Management System soll in der Lage sein elektronische Dokumente für z.B. Zeugnisse oder Studienbescheinigungen zu erstellen, ohne dass eine Unterschrift oder ein Stempel nötig ist. Dabei besteht das Problem, dass die Authentizität der Dokumente von öffentlichen Stellen überprüfbar sein muss. Grundsätzlich besteht bei Dokumenten, die eigenständig auf Papier ausgedruckt werden die Möglichkeit einer Fälschung, da keine Siegel oder Unterschriften die Echtheit bezeugen.

Eine Möglichkeit diesem nachzukommen ist die Erstellung einer Kennziffer, welche dem Dokument eindeutig zugeordnet ist und über eine Webseite die Überprüfung der relevanten Daten ermöglicht. Die Kennziffer muss dabei so gestaltet werden, dass kein gezieltes Durchsuchen des Kennziffernraumes möglich ist. Das könnte durch ausreichend großen Kennziffernraum und Schutz durch Prüfzeichen erreicht werden. Eine andere Möglichkeit ist die digitale Signatur des Dokuments, welche dem Dokument beigefügt wird. Eine Institution ist dann in der Lage mit der Signatur die Authentizität des Dokumentes zu überprüfen.


Einwirkungsmöglichkeiten der Studenten[Bearbeiten]

Vor der Anschaffung eines Systems[Bearbeiten]

  • 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. Barrierefreiheit)
  • 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[Bearbeiten]

  • 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.