| Aktuelle Version |
Dein Text |
| Zeile 1: |
Zeile 1: |
| | =Pre Alpha->Beta= |
|
| |
|
| =Erfahrungsberichte= | | =Erfahrungsberichte= |
|
| |
| ==== HIS-Partner ====
| |
| * habe da grade eine Liste gefunden:
| |
| ** http://www.his.de/partner
| |
|
| |
|
| ===TU München=== | | ===TU München=== |
| Zeile 24: |
Zeile 21: |
| **JavaScript | | **JavaScript |
| **laaaaaangsam | | **laaaaaangsam |
|
| |
| ===FH München===
| |
| * Eigenentwicklung PRIMUSS [[http://www.fh-muenchen.de/home/fhm/pressestelle/fhnachrichten/d_03_2005.pcms#primuss]]
| |
| * Soll laut Florian viele hier geforderte Punkte bereits efüllen
| |
|
| |
|
| ===Uni Karlsruhe=== | | ===Uni Karlsruhe=== |
| Zeile 35: |
Zeile 28: |
| **Frontend und Backand erneuert | | **Frontend und Backand erneuert |
| *'''HIS''' | | *'''HIS''' |
| *Tutorienverwaltung durch institutseigene Tools oder '''BSCW''' | | *Tutorienverwaltung durch institutseigen Tools oder '''BSCW'' |
| **sehr chaotisch | | **sehr chaotisch |
| *'''KING''' Karlsruher Integriertes Management | | *'''KING''' Karlsruher Integriertes Management |
| Zeile 56: |
Zeile 49: |
| *Stundenplangebasteltool | | *Stundenplangebasteltool |
| *Keine Online-Prüfungseinscreibung | | *Keine Online-Prüfungseinscreibung |
| *'''PABO''' aka FlexNow | | *'''PABO''' |
|
| |
|
| ===TU Darmstadt=== | | ===TU Darmstadt=== |
| Zeile 68: |
Zeile 61: |
|
| |
|
| ===TU Ilmenau=== | | ===TU Ilmenau=== |
| * HIS, Version 8.1.0 vom 02.02.2006 :) | | *hab nich zugehört :D |
| * unbekannt, wo das überall eingesetzt wird
| | |
| * zumindest bei Bescheinigungen.. also offensichtlich Studiumsverwaltung
| |
|
| |
|
| ===Uni Magdeburg=== | | ===Uni Magdeburg=== |
| Zeile 89: |
Zeile 81: |
|
| |
|
| ===Uni Paderborn=== | | ===Uni Paderborn=== |
| *HIS/POS Vorlesungsverzeichnis, Prüfungsanmeldung und -historie, Bescheinigungen werden im Prüfungssekretariat ausgestellt.
| | 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.
| | 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
| | 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=== | | ===TU Dresden=== |
| *jExam | | *jExam |
| **selbstgerschrieben von Softwaretechnologielehrstuhl der Fakultät Informatik | | **selbstgerschrieben von Softwaretechnologielehrstuh der Fakultät Informatik |
| **Studentenprojekt | | **Studentenprojekt |
| **in Java | | **in Java |
| Zeile 134: |
Zeile 125: |
| *Datenlosten '''CampusNet''', STiNE genannt | | *Datenlosten '''CampusNet''', STiNE genannt |
| **seit 2006 in Betrieb | | **seit 2006 in Betrieb |
| **Anmeldephase in die Hose gegangen: | | **Anmeldephase nicht geklappt |
| ****Durch update STiNe nicht erreichbar, Erstis konnten sich nicht registrieren etc...
| |
| **Sicherheitslücken im System gefunden | | **Sicherheitslücken im System gefunden |
| ***sämtliche persönliche Daten waren einsehbar | | ***sämtliche persönliche Daten waren einsehbar |
| Zeile 157: |
Zeile 147: |
| ===Pro=== | | ===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. | | 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. | | Universitaeten koennen sich gegenseitig unterstuetzen und einzelne Teilbereiche der Entwicklung je nach Notwendigkeit des jeweiligen Lehrplanes verteilen. |
| Zeile 175: |
Zeile 165: |
|
| |
|
| ===Contra=== | | ===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. |
|
| |
|
| 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= | | =Anforderungen an ein Campus-Management-System= |
| ;es muss funktionieren
| | *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.
| | *Übersicht über alle nötigen Daten |
| ;Helpdesk auch für Studierende
| | **hohe Anforderung an Sicherheit |
| :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.
| | **besonders hoher Schutz privater Daten |
| | | **Signatur beim Senden von Daten |
| ==Sicherheit==
| | **verschlüsseltes versenden von Daten (E-Mail) |
| ;hohe Anforderung an Sicherheit
| | *Zugriffsrechte klar dokumentieren und Zugriff protokollieren |
| ;absoluter Schutz privater Daten
| | **Trennung zwischen Software-Admin und System-Admin |
| :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.
| | *verbindliche funktionierende Prüfungsanmeldung (ohne BackUp script, das eine Anmeldung evtl. Überschreibt) |
| ;transparente Zugriffsrechte
| | *Einschreibung in Übungen |
| :Berechtigungen müssen feingranular vergeben werden und einsehbar sein.
| | *Bedienbarkeit (Usabilitystandards) |
| ;Zugriff protokollieren
| | *konsequente und konsistente und nicht-komplexe Bedienung |
| :Alle Änderungen an studentischen Daten müssen persönlich und zeitlich zuordnungsbar protokolliert werden und einsehbar sein.
| | *intuitive Bedienung |
| ;Trennung zwischen Anwendungs-Admin und System-Admin
| | *Kalenderfunktionen (Import/Export/Übersicht über Termine/Links zu Übungsblättern etc. ...SMS bei Terminänderung … ) |
| :Der Regelbetrieb muss ohne System-Adminrechte,d.h. uneingeschränkte Zugriffsrechte, möglich sein, das schließt auch Wartungsarbeiten (z.B. Backups) ein.
| | *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''' |
|
| |
|
| ==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== | | =Vor der Anschaffung eines Systems= |
| ;Ü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'''
| | *Lobbyarbeit vermeiden (Interessenkonflikte unterbinden) |
| | | *Für und Wider erläutern-> kostenlos ist of umsonst und billig |
| =Erzeugung von elektronischen Dokumenten=
| | *auf rechtliche Verpflichtungen hinweisen (Barierefreiheit, z.B.) |
| 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.
| | *Refferenzen von anderen Unis vorlegen, Kontakte herstellen. |
| | | *Macht in den Gremien Nutzen (FakRat, Senat, Konzil) |
| 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.
| | *Presse, Öffentlichkeit (allerletzte Möglichkeit, nur doppelte geprüfte Fakten veröffentlichen) |
| | |
| | |
| | |
| =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== | | ==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. | | *zur Beschwerde motivieren |
| | | *Presse, Öffentlichkeit (allerletzte Möglichkeit, nur doppelte geprüfte Fakten veröffentlichen) |
| *Notfalls an die Presse/Öffentlichkeit treten und auf Probleme eines Systems hinweisen. Wichtig: Nur doppelt geprüfte Fakten veröffentlichen. | |
