UDE Datenabzug FD

Vorlage:Inprogress zurück Fachdesign Business Intelligence

Neue Vorlage, Stand November 2019, mit Änderungen vom 10.07.2020

Allgemeine Hinweise: Beipackzettel für Fachdesigns
Checklist der Entwickler unter: Formale Abnahmekriterien für Fachdesigns
Usabiliy: Checkliste für UX-Review

Rückfragen an Entwickler im DoTo entsprechend kennzeichnen (@E:)

Zugehöriges FD-Ticket/Bugfix-Ticket:	271745 - zFDPA: BIA: ECTS-Landesstatistik Datenbestand sichern
Zugehöriges PA-Ticket:	271744 - zPA: BIA: ECTS-Landesstatistik Datenbestand sichern
Entwurf (Autorinnen/Autoren)	Daniel Quathamer
Link zum DV-Konzept (ggf. nur HIS-intern)	DV-Konzept ECTS-Landesstatistik Datenbestand sichern

Änderungsprotokoll

Datum	Autor/-in	Abschnitt	Änderung	Erhöht den Aufwand der zugehörigen PA?
[JJJJ-MM-DD]	[Autor/-in]	[Abschnitt im FD-Dokument]	[Kurze Beschreibung der Änderung]	[Ja/Nein]

Einleitung

Motivation

Es gibt eine Vielzahl von Steuerungsmechanismen bei denen der Vergleich mit vergangenen Daten benötigt werden. Diese Daten braucht es dann qualitätsgesichert und in der Form eingefroren, dass sie nicht durch zukünftige Änderungen (insbesondere rückwirkende Änderungen) der Bewegungsdaten verändert werden und so dauerhaft im Zustand zum Zeitpunkt der Ermittlung zur Verfügung stehen.

Beispiele:

Am Ende einer Prüfungskampagne soll das Ergebnis dieser Phase eingefroren werden, so dass in der Folge eine kommenden Kampagne mit dieser verglichen werden kann.
Die Studierendenzahlen einer amtlichen Lieferungen sollen für kommende Vergleiche herangezogen werden.
Die Entwicklung der Absolventenzahlen sollen über die Jahre angeschaut und vertieft analysiiert werden.

Auch die Lieferung der ECTS-Landesstatistik soll zukünftig eingefroren werden und somit für nachfolgende Vergleichsanalysen auf unterschiedlichen Ebenen (Fakultäten, Lehreinheiten, Abschlüssen und/oder Studiengängen) dauerhaft und unveränderbar zur Verfügung stehen. Damit die Entwicklung der genannten Ebenen auch in Zukunft im Verlauf betrachtet werden können und eventuelle Stuerungsmaßnahmen darauf aufgebaut werden können. Dazu ist es notwendig, die einzelnen Leistungsdaten der Studierenden jedes Jahr zum Zeitpunkt der Lieferung einzufrieren. Einzig die Lieferdatei weiterzuverwenden oder die veröffentlichten Ergebnisse zu nutzen greift zu kurz, denn diese ist insbesondere für interne Auswertungen (die deutlich tieffer gehen müssen) nicht detailliert genug. Eine hochschulinterne Verlaufsbetrachtung auf unterschiedlichen Ebenen, bei der im Sinne der ECTS-Landesstatistik SOLL- und IST-ECTS verglichen wernde braucht demnach:

den eingefrorenen Leistungsstand der Studierenden
die zum Zeitpunkt der Lieferung gültige Lehrverflechtung, wenn diese auch ausgewertet werden soll

Dieses Fachdesign behandelt zunächst den Umgang mit den Leistungsdaten und nutzt vorhandene Funktionen der HISinOne-BI um diese zu sichern und künftig zur Verfügugn zu stellen. Die Sicherung der Lehrverflechtung zum Zeitpunkt der Lieferung wird, sollte der Bedarf entstehen, in einem noch kommenden eigenen FD betrachet.

Betroffene Prozesse im Referenzmodell

Zum welchem Geschäftsanwendungsfall (GAF) gehört dieses FD? Auswertung generieren

Welche Systemanwendungsfälle (SAF) sind betroffen? Standardbericht aufrufen

Voraussetzung, Abgrenzung, weitere Funktionalitäten, Abhängigkeiten

Grundlage sind vorhandene Studierenden- und Leistungsdaten, sowie Daten zur Lehrverflechtung der Studiengänge dieser Studierenden. Diese werden im Land NRW jährlich (im Frühjahr) im Rahmen der ECTS-Landesstatistik für das vergangene akademische Jahr auf Ebene der amtl. Lehreinheiten zusammengetragen und an das stat. Landesamt IT.NRW übergeben. Im Hintergrund werden dafür bis auf Ebene der Leistungsdaten einzelner Studierender diese Daten zusammengetragen und darauf aufbauend dann die SOLL-ECTS und die IST-ECTS aufaddiert. Diese Funktion ersetzt nicht die Funktionsweise zu bestimmten Stichtagen im Sinne der amtl. Statistiken Daten dauerhaft einzufrieren, sondern ergänzt diese für hochschulinteren Sichtweisen und Auswertungen im Bereich der Verlaufsanalysen für Studierende und/oder Prüfungen.

Glossar

Begriffserklärungen für spezielle Abkürzungen und Fachbegriffe.

Wichtige BI Begriffe sind hier erklärt: Entwickler Glossar HISinOne-BI

Zusammenfassung, Lösungsansatz

Eingefrorener Datenabzug von Leistungsdaten für die Ermittlung der ECTS-Landesstatistik

Grundidee des FD ist die folgende Workflowstory, die dann sowohl systeminterne Aufrufe als und Ansprüche an das Sytem HISinOne-BI als auch an Arbeiten und Abläufe außerhalb des System stellt.

WENN

ein die Lieferung der ECTS-Landesstatistik erfolgt ist (einmaliger Stichtag je akademisches Jahr),

MÖCHTE ICH

die zugrundeliegenden Leistungsdaten systemseitig dauerhaft und unveränderbar einfrieren,

SO DASS ICH

in folgenden Jahren und bei kommenden Ereignissen diese Datenbestände für Verlaufsbetrachtungen rund um den Erwerb von ECTS verwenden kann.

In der Folge wird für das neue Datenblatt eine Userstory erläutert, die sich im Wesentlichen an den Aufgaben und dem dafür neu zu erstellenden Datenblatt in der HISinOne-BI orientieren.

Userstories für Kennzahlen- / Berichtserweiterung

US: historische Betrachtung von Leistungsdaten im Sinne der ECTS-Landesstatistik

Als Aspekt der Studienerfolgsmessung im Sinne des ECTS-Erwerbs (vgl. SOLL und IST) möchte ich als BI-Spezialist die summierten ECTS der Studierenden, die für die ECTS-Landesstatistik herangezogen wurden in der BI zur Verfügung haben, um bei der Erkennung von Studierenden mit Problemen zu helfen.

AK: Test, dass die Summierung der ECTS stattgefunden hat und diese eingefroren dauerhaft zur Verfügung stehen

Gegeben: sei ein HISinOne-BI-Instanz in der auf Ebene von Einzelprüfungen Leistungsdaten der hochschuleignenen Studierende erfasst sind.
Wenn: die Funktion "Datenblätter einfrieren" für dieses Datenblatt erfolgt ist,
Dann: kann man in der HISinOne-BI zukünftig diesen eingefrorenen Zustand der ECTS-Leistungsdaten für vergleichende Betrachtungen oder zu Dokumentationszwecken aufrufen.

Oberflächendesign/UX

Dieses Kapitel bitte ersetzen durch Webservice Spezifikation, wenn mit diesem Fachdesign nur ein Webservice beschrieben werden soll.

Menüführung und Menüpunkt benennen

Business Intelligence > Standardberichte > Studierende, Prüfungen > Datenabzüge > Datenblätter einfrieren - Bericht erstellen

Persona(e) auflisten, die das Interface benutzen: Primäre Persona/Sekundäre Persona(e)

Primäre Persona - eine Persona auswählen:

Vorlage:Personas (BI-Spezialist/-in)

Vorlage:Personas (BI-Administrator/-in)

Prototyp des Oberflächendesigns, ggf. mehrere Seiten

Die Berichte ermöglichen es, diverse Datenblätter (bzw. die zugrunde liegenden Faktentabellen) an beliebigen Tagen einzufrieren/zu archivieren. Um dies durchzuführen wird der Bericht "Datenblätter einfrieren" genutzt. Es wird das gewünschte Datenblatt ausgewählt und der Bericht abgeschickt. Die Daten der zugrunde liegenden Faktentabelle werden in eine zuvor angelegte Archivtabelle geschrieben. Dann hier: "ECTS-Landesstatistik".

Die Archivdatenblätter werden über eigene Berichte abgerufen.

Die Auswahlmasken Der Archivdatenblätter gleichen denen der bekannten, üblichen Datenblätter.

Die Ergebnistabellen enthalten dieselben Spalten, abgesehen von der zusätzlichen Spalte 'Archivierungsdatum' bei den Archivdatenblättern.

Kurze schriftliche Beschreibung des Oberflächenkonzepts

Jede der Archivtabellen besitzt die selben Felder, wie du zu archivierende Faktentabelle und erhält ein neues Feld 'Archivierungsdatum'. Dort wird am Tag des Einfrierens/der Archivierung das aktuelle Datum erfasst. Die Archivtabellen werden über eigenen Berichte abgerufen.

Im Folgenden wird die Funktionalität anhand des SOS-Moduls beschrieben. Sie wird als generische Funktion im Kernmodul bereitgestellt, d.h. neben dem Beispiel unten zur Studierenden- oder Prüfungsstatistik lassen sich damit beliebige Faktentabellen in der BI archivieren.

Neben den Tabelleninhalten werden bei der Erst-Installation auch die Metadaten zur Tabelle und den zugehötigen Feldern kopiert (Tabellen sx_tables und sx_fields), damit Datenblatt-Masken damit arbeiten können.

Generell werden nur Datensätze des jeweils aktuellen Semesters archiviert. Mit Ausnahme der ersten Archivierung. Bei dieser wird der gesamte Inhalt des Datenblattes (bzw. der zugrunde liegenden Faktentabelle) in die Archivtabelle übertragen. Bei jeder weiteren Archivierung wird anhand der Spalte 'Archivierungsdatum' geprüft, ob am jeweiligen Tag bereits archiviert wurde. Falls dies zutrifft werden zunächst alle Datensätze mit tagesaktuellem Archivierungsdatum gelöscht und anschließend alle Datensätze des aktuellen Semesters archivert. Ansonsten werden lediglich die Datensätze des aktuellen Semesters der Archivtabelle hinzugefügt.

Am Tag der Erstarchivierung darf keine weitere Archivierung stattfinden, um nicht Daten aus früheren Semestern zu löschen. Dies wird technisch abgefangen.

Am Tag der Erstarchivierung darf keine weitere Archivierung stattfinden, um nicht Daten aus früheren Semestern zu löschen. Dies wird technisch abgefangen.

Am Tag der Erstarchivierung darf keine weitere Archivierung stattfinden, um nicht Daten aus früheren Semestern zu löschen. Dies wird technisch abgefangen.

Es leiten sich zusamenfassend 3 Szenarien ab:

Erstarchivierung: Wurde ein Datenblatt noch nie archivert, werden alle Datensätze archivert.
Mehrere Archiverungen am selben Tag: Bei jeder weiteren Archivierung wird die vorherige Archiverung rückgängig gemacht und nur noch das aktuelle Semester archiviert.
Einzelne Archivierung mindestens einen Tag nach der Erstarchivierung: Es wird nur das aktuelle Semester archiviert.

Berichtsentwurf

Konnektorerweiterung

Selektionsparameter

| [Parameterbezeichnung]
| [Parameterbeschreibung]
|[ Single Select / Multi Select / Sicht / Freitext]
| [Technischer Beschreibungstext]

| [Parameterbezeichnung]
| [Parameterbeschreibung]
|[ Single Select / Multi Select / Sicht / Freitext]
| [Technischer Beschreibungstext]

| [Parameterbezeichnung]
| [Parameterbeschreibung]
|[ Single Select / Multi Select / Sicht / Freitext]
| [Technischer Beschreibungstext]

Name	Info-Text	Feldart	Hinweise

Ergebnisbericht

| [Parameterbezeichnung]
| [Parameterbeschreibung]
|[ Feld in der BI-Datenbank]
|[ Feld in der H1-Datenbank]
| [Technischer Beschreibungstext]

| [Parameterbezeichnung]
| [Parameterbeschreibung]
|[ Feld in der BI-Datenbank]
|[ Feld in der H1-Datenbank]
| [Technischer Beschreibungstext]

| [Parameterbezeichnung]
| [Parameterbeschreibung]
|[ Feld in der BI-Datenbank]
|[ Feld in der H1-Datenbank]
| [Technischer Beschreibungstext]

Name	Info-Text	BI-Feld	H1-Feld	Hinweise

Reports

Diagramme

Texte zu Meldungen

| 1
| [Erfolg/Info/Warnung/Fehler/User-Rückfragen]
|[Popup rechts/ Festplatzierte Meldung/Infobutton] | [Text] |[Text]/[nicht erforderlich]
| 2
| [Erfolg/Info/Warnung/Fehler/User-Rückfragen]
|[Popup rechts/Festplatzierte Meldung/Infobutton] | [Text] |[Text]/[nicht erforderlich]
| 3
| [Erfolg/Info/Warnung/Fehler/User-Rückfragen]
|[Popup rechts/Festplatzierte Meldung/Infobutton] | [Text] |[Text]/[nicht erforderlich]>>>>>>

Lfd.-Nr.	Meldungsart	Meldungsdarstellung	Meldungstext (deutsch)	Meldungstext (englisch)

Rechte

Benötigte Rechte:

Schlüssel	Name	Rollen	Beschreibung
cs.bia.standardreports.VIEW_REPORTS	Standardberichte anzeigen	BI-Spezialist/-in
cs.bia.standardreports.ADMIN	HISinOne-BI administrieren	BI-Administrator/-in
[Technischer Schlüssel]	[Name des Rechts]	[Rollen]	[Ausführliche Beschreibung, was das Recht bewirkt. Ggf. Abhängigkeiten von anderen Rechten.]

Benötigte Rechteparameter:

Rechteparameter	Rechte	Beschreibung	Beispiel
[Name des Rechteparameters]	[Einzuschränkende Rechte]	[Ausführliche Beschreibung des Rechteparameters]	[Beispiele für die Ausprägung des Parameters]

Globale Schalter/ BI-Parameter

In der Regel werden in der BI keine Globalen Schalter verwendet, sondern Repository Variablen, Konstanten und Entladeparameter. Diese werden in diesem Abschnitt beschrieben.

Schlüssel (optional)	Label	Hilfetext	Typ	Default-Wert
[Pfad]	[Label]	[Hilfetext]	[Typ]	[Default-Wert]

Allgemeine Angaben

Berichtswesen (fachliche Aspekte)	FD ist Teil des Berichtswesen
Pseudonymisierung	[Begründung, warum nicht erforderlich] oder [Link zum AK]
Datenkontrollblätter	[Begründung, warum nicht erforderlich] oder [Link zum AK]
Datenschutzbericht	[Begründung, warum nicht erforderlich] oder [Link zum AK]
Suche nach Personen (Datenvermeidung und Datensparsamkeit)	[Begründung, warum nicht erforderlich] oder [Link zum AK]
Migration (fachlich)	[Begründung, warum nicht erforderlich] oder [Link zum AK]
Mobile Endgeräte	[Begründung, warum nicht erforderlich] oder [Link zum AK]
Datenmenge, Performanz	[Angaben zur Datenmenge / Performanz]
Externe Systeme / Webservices	[Begründung, warum nicht erforderlich] oder [Link zum AK]
Auslieferung von Defaultdaten	[Begründung, warum nicht erforderlich] oder [Link zum AK]
3-Säulen – Transport	[Begründung, warum nicht erforderlich] oder [Link zum AK]
Domain Modell	[Link zum Kapitel im Fachdesign] (optional)
Systemverhalten	[Link zum Kapitel im Fachdesign] (optional)

Hilfsmittel

Vorkonfigurierte Links für die Anlage von Tickets zur Anpassung des Referenzmodells

Der Klick auf einen der u. a. Links öffnet ein Erweiterungsticket mit vorbelegten Feldern. Bitte die Ticketnummer des erstellten Tickets hinter dem SAF/GAF eintragen.

ALU • APP • BIA • COA • DOC • EXA-PM • EXA-STG • EXA-VM • PSV • RES • STU-GEB • STU • SYS • RES

Informationen zu Akteurinnen/Akteuren sind im Referenzmodell enthalten. Beispielsweise in dem Diagramm Referenzprozessmodell201706 >Beteiligte >Systemrollen >EXA >EXA-Veranstaltungsmanagement-Akteure_Rollen.

Liste der UX-Expertinnen/-Experten.

Englische Texte müssen spätestens mit Beginn der Entwicklung erstellt werden. Wenn Unterstützung bei der Übersetzung benötigt wird, bitte ein Ticket an Team Dokumentationskoordination erstellen: Anfrage an Team Doku-Koordination (Das Ticket unter die PA einhängen.)

Wenn ein Fachdesign datenschutzrechtlich überprüft werden soll, dann bitte ein Hiszilla-Ticket erstellen mit Thomas Holz (holz@his.de) und Udo Baum (baum@his.de) im Cc. Die Zuständigkeit bleibt beim Fachteam, meist Anfragesteller/-in. Thomas Holz und Udo Baum sind für die Weiterleitung an das DFN-CERT verantwortlich.

Tabelle zur Dokumentation von Datenmenge und Performanz

Akzeptanzkriterium	Anzahl Datenobjekte (optional)	Laufzeit (in Sekunden)
[AK x.x]	n	< [Laufzeit]
[AK x.x]	max	< [Laufzeit(max)]

zurück Fachdesign Business Intelligence