Konfigurationshandbuch Studienerfolg
Einführung
Voraussetzung ist die Komponente Kern sowie die Komponente Studierende, Prüfungen.
Die Komponente Studienerfolg erweitert die vorhandenen Berichte der Komponente Studierende, Prüfungen des Infosystems um detaillierte Auswertungen im Bereich Studienverlauf.
Installation der Komponente Studienerfolg
Die Installation der Komponente Studienverlauf (ERFOLG) unterscheidet sich zwischen HISinOne und SuperX. Daher gibt es zu jedem System eine eigene Installationsseite:
Konstanten
Nach der Installation können Sie das Verhalten der Software über Konstanten steuern.
- Übersicht
- Eine Übersicht über alle Konstanten der Komponente finden Sie hier: Konstanten_-_HISinOne-BI#BI-Komponente_Studienerfolg.2F_Verlauf
- Besonderheiten einzelner Konstanten
- ERFOLG_NUR_KOEPFE
- Für die Auswertungen des Studienverlaufs werden derzeit in der Auslieferung nur "Köpfe" ausgewertet, d.h. Studierende im ersten Studiengang und ersten Fach. Um die Berechnung auf "Fälle" auszuweiten (d.h. beliebiger Studiengang, beliebiges Fach), muss man die Konstante ERFOLG_NUR_KOEPFE auf 0 setzen. Bitte beachten Sie, dass dann die Laderoutine erheblich mehr Zeit brauchen wird.
- Wenn in der Komponente Studienerfolg auch Fälle ausgewertet werden, kann folgendes Phänomen zu Fehlinterpretationen führen: wenn ein Studierender am Ende des Bachelors sich im letzten Semester schon im zweiten Studiengang für den Master einschreibt, und dann im zweiten Semester des Masters, wenn der BA abgeschlossen ist, auf den 1. Studiengang "umschreibt", wird dieser Fall im Infosystem als Wechsel interpretiert, und das Masterstudium würde damit direkt nach dem 1. FS enden.
- ERFOLG_START_SEM
- Standardmäßig werden alle Semester, die in der Komponente Studierende, Prüfungen vorliegen, auch in der Komponente Studienerfolg übernommen. Dies ist ggf. nicht sinnvoll, weil in älteren Semestern noch keine validen Daten vorliegen oder weil die Laderoutine sehr lang läuft. Sie können daher mit Hilfe der Konstante ERFOLG_START_SEM den zu ladenden Semesterzeitraum (fünfstellige HIS-Notation mit 4 Stellen für das Jahr und 1 Stelle für WiSe/SoSe) begrenzen. Setzen Sie die Konstante beispielsweise auf 20172, dann werden nur die Daten im und nach dem WiSe 2017/2018 in die Komponente Studienerfolg übernommen.
- ERFOLG_start_stg_verlauf
- Mit dieser Konstante legen Sie fest, ab welchem Semester in der nächtlichen Laderoutine der Datenbestand in der Hilfstabelle ausgetauscht und neu berechnet werden soll. Wenn Sie z.B. ERFOLG_START_SEM=20162 setzen, dann werden nur Daten ab dem WiSe 2016/2017 in die Komponente Studienerfolg übernommen. Wenn Sie zusätzlich ERFOLG_start_stg_verlauf=20181 setzen, dann legen Sie fest, dass nur Studienanfänger im oder nach dem SoSe 2018 in der nächtlichen Laderoutine neu berechnet werden. Der Datenbestand des WiSe 2016/2017 bis zum WiSe 2017/2018 würde nicht neu berechnet werden.
- ERFOLG_ects_anz_sem
- Die Anzahl der Semester, die
- im "Studienverlauf pro Semester Datenblatt" für einen Soll-Ist-Vergleich bei Credits berechnet werden sollen.
- im Akkreditierungs-Bericht "Studienverlauf mehrerer Kohorten" rückwirkende Kohorten berechnen sollen.
Die Auslieferung berechnet 10 Semester rückwirkend, d.h. die letzten 5 Jahre. Wenn Sie die Konstante auf 20 setzen, werden die Anfängerkohorten der letzten 10 Jahre berechnet. Je nach Laufzeit der ERFOLG Hauptladeroutine können Sie hier Anpassungen vornehmen.
Bestandteile des Studienerfolgs-Moduls
Faktentabelle Studienverlauf
In der Komponente Studienerfolg sind die Komponenten von der Datentransformation bis zur Präsentation enthalten. Es werden keine Daten aus dem Basissystem HISSOS extrahiert und die vorhandenen Datentabellen der Komponente Studierende, Prüfungen werden mit Schlüsseln verknüpft. Daraus wird eine aggregierte Hilfstabelle erzeugt, die wiederum als Basis für die Abfragen dient.
Hilfstabellen sind aggregierte Datentabellen, die aus den Basisdatentabellen gebildet werden. Sie erhöhen die Performance der Abfragen, da die Tabellen sinnvoll für einige Abfragen summiert werden.
Die Tabelle sos_stg_verlauf erhebt für Studienfälle den Studienbeginn und den Studienverlauf. Bei dem Semester der Prüfung wird standardmäßig das Semester erhoben, in dessen Zeitraum das Datum der Prüfung fällt.
Die Tabelle wird nach dem Update der Komponente Studierende, Prüfungen auf der Basis von tagesaktuellen Daten (also keine Stichtagsdaten) neu generiert. Derzeit werden nur Köpfe (d.h. 1. Studiengang, 1. Fach) ohne Beurlaubte erhoben und im Verlauf analysiert.
Feldname | Feldtyp | Größe | Beschreibung |
---|---|---|---|
matrikel_nr | INTEGER | 50 | |
studiengang_nr | SMALLINT | 2 | Erster/Zweiter Studiengang etc. |
fach_nr | SMALLINT | 2 | Erstes/Zweites Fach etc. |
ca12_staat | SMALLINT | 2 | Nationalität |
geschlecht | SMALLINT | 2 | Geschlecht
1=Männlich, 2=Weiblich |
alter | NUMERIC | (14,2) | Alter in Jahren |
hzbnote | NUMERIC | (4,2) | Note der HZB |
hzbart | SMALLINT | 2 | Art der HZB (gruppiert)
in 6 groben Kategorien: Allgem. HS-Reife, Fachgeb.HS-Reife etc. (siehe SOS-Modul) |
hzbkfz | INTEGER | 4 | KFZ-Kennzeichen der HZB |
hrst | CHAR | 1 | Hörerstatus |
anfang_sem | SMALLINT | 2 | Semester des Studienbeginns |
anfang_art | CHAR | 1 | Art des Studienbeginns
E=Einschreibung,1=Erstes Fachsemester,S=erstes eingeschriebenes Semester an dieser Hochschule, H=1. Hochschulsem. |
anfang_status | INTEGER | 4 | Status bei Studienbeginn |
anfang_fach | CHAR | 3 | Fach bei Studienbeginn |
anfang_abschluss | CHAR | 2 | Angestr.Abschluss bei Studienbeginn |
anfang_fachsem | SMALLINT | 2 | Anzahl Fachsem. bei Studienbeginn |
anfang_alter | NUMERIC | (5,2) | Alter bei Studienbeginn |
wechsel_sem | SMALLINT | 2 | Erstes Semester, zu dem ein Wechsel von Fach oder Abschluss stattgefunden hat. |
wechsel_fach | CHAR | 3 | Fach, in das gewechselt wurde |
wechsel_abschluss | CHAR | 2 | Abschluss, in den gewechselt wurde |
zwischen_fachsem | SMALLINT | 2 | Anzahl Fachsem. bei Zwischenprüfung |
zwischen_sem | SMALLINT | 2 | Semester bei Zwischenprüfung
Prüfungssemester psem, nicht Datum |
zwischen_sempruef | SMALLINT | 2 | Semester lt. Prüfungsdatum bei Zwischenprüfung |
zwischen_art | CHAR | 2 | Art der Zwischenprüfung
B=Bestanden,O=Ohne bestandene Zwischenprüfung |
zwischen_fach | CHAR | 3 | Fach bei Zwischenprüfung |
zwischen_abschluss | CHAR | 2 | Abschluss bei Zwischenprüfung |
ende_fachsem | SMALLINT | 2 | Anzahl Fachsem. bei Studienende |
ende_sem | SMALLINT | 2 | Semester bei Studienende
Prüfungssemester psem, nicht Datum. Wird derzeit nicht ausgewertet. |
ende_sem_d_pruef | SMALLINT | 2 | Semester lt. Prüfungsdatum bei Studienende |
ende_art | CHAR | 2 | Art des Studienendes
B=Bestanden,O=Ohne bestandene Prüfung, U=Unbekannt |
ende_fach | CHAR | 3 | Fach bei Studienende |
ende_abschluss | CHAR | 2 | Abschluss bei Studienende |
stuart | CHAR | 1 | Art des Studiums |
stufrm | CHAR | 1 | Studienform |
ch62_grund_exmatr | CHAR | 2 | Exmatrikulationsgrund |
Exmatrikulationsgründe
Im Bericht "Studienverlauf (Kohortenbetrachtung)" sowie "Exmatrikulationsgründe" werden Exmatrikulationsgründe spaltenweise ausgegeben. Bei der Klassifizierung der Exmatrikulationsgründe gehen wir über den amtlichen Schlüssel (k_gdex.astat bei der Datenquelle sospos).
Spalte | HS-Wechsel | Aufgabe | ohne Rückmeldung | Einberufung | ohne Prüfung | mit Prüfung | sonstige Gründe |
Amtl. Schlüssel | 4 | 6 | 7 | 5 | 2,8,3 | 1 | 9 oder leer |
Hochschulspezifische Anpassungen
Hochschul-Repository
Eine Anleitung zu den Repository Variablen finden Sie hier: Hochschul-Repository-Erfolg- HISinOne-BI
Virtuelle Studiengangnummern
In der Studienverlaufsbetrachtung, die die Studiengänge/Fächer normalerweise durchnummeriert, d.h. man studiert einen Studiengang in der ersten Studiengangnummer im ersten Fach usw., kann es vorkommen, dass die Studiengangnummer willkürlich wechselt. Es ist ein übliches Vorgehen, dass Studierende während ihres voraussichtlich letzten Bachelor-Semesters bereits im Masterstudiengang eingeschrieben werden. In der BI führt dieses Vorgehen im Bereich Studienverlauf zu „fehlerhaften“ Ausgaben, wie z. B. der Angabe Anzahl Fachsemester = 1 für einen Studierenden im 7. Bachelorsemester, weil im ausgewerteten 1. Mastersemester die Fachsemesterzahl 1 eingetragen ist. Der Wunsch der Hochschulen ist aber, dass Studierende mit Paralleleinschreibung im ersten Master- und im letzten Bachelorsemester in der BI-Komponente Studienverlauf korrekt ausgewertet werden können. Beispielsweise sollen im Studienverlauf Datenblatt die Fachsemester korrekt ausgegeben werden und im Bericht Studienverlaufsanalyse (Kohortenbetrachtung) (und ähnlichen weiteren Berichten) sollen die noch im Bachelorstudium befindlichen Studierenden korrekt bei „noch immatrikuliert gemäß Beginn“ gezählt werden. Somit wird bei Mehrfachstudiengängen nach Fach und Abschluss eine virtuelle Studiengangnummer ermittelt, die unabhängig von der "physischen" Studiengangnummer ist.
![]() Verfügbar ab Version |
{{{1}}} {{{2}}} |
In RELEASE=2021.12 und älter müssen Sie, um diese Zählweise zu nutzen, die Konstanten
- ERFOLG_NUR_KOEPFE=0 und
- ERFOLG_VIRT_STGNR=1
setzen. Nach eine Änderung der Konstanten müssen Sie die Hauptladeroutine Studienverlauf neu ausführen.
Wichtige Administrationstätigkeiten: HowTo
Spezielle Benutzerberechtigung
Wenn Sie einzelnen Benutzerinnen und Benutzern Rechte auf die Analyse des Studienverlaufs nur für die eigene Kostenstelle (Lehreinheit oder Fakultät) geben wollen, gehen Sie wie folgt vor:
Prüfen Sie, ob die Nummern der Fakultäten und/oder Lehreinheiten mit denen des Kostenstellen-Baums im Organigramm korrespondieren. In dem u.g. Beispiel sind dies die Lehreinheiten aus der KLR:
Legen Sie zunächst eine Gruppe "Studienverlauf Lehreinheiten" an. Diese Gruppe bekommt Rechte auf die Maske "Analyse des Studienverlaufs".
Danach geben Sie dem User (hier "testuser") diese Gruppe, und die Kostenstellen-Rechte auf die Lehreinheit "AB":
Danach geben Sie der Gruppe "Studienverlauf Lehreinheiten" Rechte auf die ERFOLG-Kostenstellen-Sicht "Lehreinheit und Fach" - nur auf diese.
Außerdem braucht die Gruppe die Rechte auf alle Abschluss-Sichten:
Danach leeren Sie den Manager-Cache oder starten Tomcat neu, und melden sich neu an. Das folgende Bild zeigt die Oberfläche des Benutzers "testuser" nach Login und Aufruf der Maske:
Datei:menue eingeschraenkt.png