KIF365:Campus-Management-Systeme: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
|||
Zeile 7: | Zeile 7: | ||
==Erfahrungsberichte== | ==Erfahrungsberichte== | ||
===TU München=== | |||
*demnächst System der TU Graz | *demnächst System der TU Graz | ||
*atm noch '''HIS/POS''', | *atm noch '''HIS/POS''', | ||
Zeile 26: | Zeile 26: | ||
*demnächst Subversionsystem für Übungsabgabe | *demnächst Subversionsystem für Übungsabgabe | ||
===Uni Kahrlsruhe=== | |||
*Turotienvergabe via '''Webinscribe''' | *Turotienvergabe via '''Webinscribe''' | ||
**Angabe von Präferenzen, | **Angabe von Präferenzen, | ||
Zeile 40: | Zeile 40: | ||
**“Schreibtisch” mit Vorlesungen die man hört | **“Schreibtisch” mit Vorlesungen die man hört | ||
**passende Foren | **passende Foren | ||
===Uni Würzburg=== | |||
*'''SB@home''' | *'''SB@home''' | ||
**Übungseinschreibung zu Beginn eines Semesters wochenlang nicht erreichbar | **Übungseinschreibung zu Beginn eines Semesters wochenlang nicht erreichbar | ||
*'''Moodle-System'''. Verwirrend zu bedienen, funktioniert recht gut. | *'''Moodle-System'''. Verwirrend zu bedienen, funktioniert recht gut. | ||
*Institute haben auch noch eigene Systeme, werden aber nach und nach abgebaut und auf moodle umgestellt. | *Institute haben auch noch eigene Systeme, werden aber nach und nach abgebaut und auf moodle umgestellt. | ||
Uni Bremen | |||
Stud-IP | ===Uni Bremen=== | ||
Keine Online-Prüfungseinscreibung | *'''Stud-IP''' | ||
TU Darmstatd | **Übungseinschreibeung | ||
HIS/POS | **Übungspaufgabenbgabe (eigentlich Mail und SVN) | ||
Prüfungseinschreibung analog | *Stundenplangebasteltool | ||
Verschiedene Raumbuchungssysteme | *Keine Online-Prüfungseinscreibung | ||
Ilmenau | *'''PABO''' | ||
hab nich zugehört | |||
Magdeburg | ===TU Darmstatd=== | ||
UNIVIS | *'''HIS/POS''' | ||
Volesungsverzeichnis | **schlechte Erfahrungen | ||
HISQIS für | **Vorlesungsverzeichnis | ||
zentrale Stammdatenhaltung, | **Übungseinschreibung. | ||
Datenbank im Inf-Rechenzentrum | **'''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 egener Lehrstuhl, jetze für jedes Institut. | Übungseinschreibung: früher egener Lehrstuhl, jetze für jedes Institut. | ||
Uni Paderborn | |||
===Uni Paderborn=== | |||
HIS/POS Prüfungsanmeldung, Scheine noch analog im PA | HIS/POS Prüfungsanmeldung, Scheine noch analog im PA | ||
Stud-Info. Prüfungseinschreibung, mit Prüfungsergebnissen, funktioniert unter Last gar nicht. | 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 | Koala, Übungsmaterialen online stellen, Foren, Übungsabgabe, wird an gesamter Uni verwendet. Versenden von Mails an übungsteilnehmer | ||
TU Dresden | |||
===TU Dresden=== | |||
jExam | jExam | ||
HIS | HIS | ||
HU Berlin | |||
===HU Berlin=== | |||
AGNES (HISBUS), Probleme wie bei allen anderen. (prüfungsanmeldung) | AGNES (HISBUS), Probleme wie bei allen anderen. (prüfungsanmeldung) | ||
Goya (Eigenentwicklung), Performanceprobleme | Goya (Eigenentwicklung), Performanceprobleme | ||
moodle | moodle | ||
TU Graz | |||
===TU Graz=== | |||
CampusOnline, alles, bis auf Verwrechnung/Buchhaltung. | CampusOnline, alles, bis auf Verwrechnung/Buchhaltung. | ||
Man bekommt alles, außer Abschlussdokumente | Man bekommt alles, außer Abschlussdokumente | ||
Zeile 80: | Zeile 106: | ||
kann man kaufen | kann man kaufen | ||
Für Selbstentwicklung | ==Für und Wider von Selbstentwicklung solcher Systeme an der eigenen Uni== | ||
===Pro== | |||
bringt Lehre voran | bringt Lehre voran | ||
interuniversitäre Zusammenarbeit | interuniversitäre Zusammenarbeit | ||
Zeile 89: | Zeile 117: | ||
kurzer Weg im Kompetenzgerangel | kurzer Weg im Kompetenzgerangel | ||
kostensparender, da man nicht teuer einkaufen muss | kostensparender, da man nicht teuer einkaufen muss | ||
===Contra=== | |||
der Überblick kann eventuell nicht gewonnen werden um Unis mit komischen Studiengangenzu verwalten | der Überblick kann eventuell nicht gewonnen werden um Unis mit komischen Studiengangenzu verwalten | ||
die Analyse von den spezifischen Anforderungen einer Fakultät ist von Studenten einer anderen Fakultät nicht machbar | die Analyse von den spezifischen Anforderungen einer Fakultät ist von Studenten einer anderen Fakultät nicht machbar | ||
Zeile 100: | Zeile 129: | ||
Anforderungen an ein Campus-Management-System | ==Anforderungen an ein Campus-Management-System== | ||
es muss funktionieren | es muss funktionieren | ||
Übersicht über alle nötigen Daten | Übersicht über alle nötigen Daten |
Version vom 15. November 2008, 07:49 Uhr
PRE ALPHA
Campusmanagementsysteme
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: eigenes System+UNIVIS
- UNIVISVorteil: 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
- buggy&langsam
- demnächst Subversionsystem für Übungsabgabe
Uni Kahrlsruhe
- 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 Darmstatd
- 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
- Prüfungsanmeldung
- 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 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 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 Studiengangenzu verwalten die Analyse von den spezifischen Anforderungen einer Fakultät ist von Studenten einer anderen Fakultät 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 Ü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
things to do wenn ein System eingeführt werden soll 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) things to do, wenn das System eingeführt wurde nud schlecht ist zur Beschwerde motivieren Presse, Öffentlichkeit (allerletzte Möglichkeit, nur doppelte geprüfte Fakten veröffentlichen)