Entwicklung und Dokumentation eines Klausurorganisationssystems mit Microsoft Access

  Seite  II

  Inhaltsverzeichnis  

  Abbildungsverzeichnis  III

1  Einführung  1

1.1  Aufbau der Diplomarbeit  1

1.2  Ziel der Arbeit  2

2  Entwicklungsplanung  3

2.1  Phasenkonzeption  4

2.1.1  Phasenmodelle  4

2.1.2  Realisierte Phasen der Softwareentwicklung  7

2.2  Vom Problem zum Sollkonzept  8

2.3  Problemstellung  9

2.3.1  Der Prozeß Klausurorganisation  9

2.3.2  Prozeßkettenanalyse und Problembeschreibung  12

2.3.3  Sollstruktur  14

2.4  Lösungsalternativen und Entscheidung  16

2.5  Sollkonzept  22

2.5.1  Der Prozeß Klausurorganisation mit KOSY-Funktionalität  26

2.5.2  Das Entity Relationship Modell  26

3  Die Realisierung der Softwareentwicklung  30

3.1  Die Entwicklungsumgebung Microsoft Access 97  30

3.1.1  Struktur und Objekte  30

3.1.2  Die Programmiersprache Visual Basic für Applikationen für Office 97  31

3.2  Das relationale Datenmodell des Klausurorganisationssystems  32

3.3  Die Entwicklung der Funktionen des Klausurorganisationssystems  36

3.3.1  Die Menü und Dialoggestaltung  36

3.3.2  Raum und Platzbelegung  40

4  Systemtest und Softwareeinführung  47

4.1  Der Systemtest  47

4.1.1  Prüfung des Funktionsumfangs  48

4.1.2  Prüfung der Qualitätsanforderungen  48

4.2  Die Softwareeinführung  51

  Literaturverzeichnis  54

  Versicherung  55

Anhang C  Sollprozeß der Klausurorganisation C  1

Anhang D  Fragebogen zur Ermittlung der Softwarequalität D  1

  Seite  III

  Abbildungsverzeichnis  

  Abbildung 1 Wasserfallmodell mit Rückkopplung nach BOEHM  5

  Abbildung 2 Spiralmodell nach BOEHM  6

  Abbildung 3 Prototyping Modell  6

  Abbildung 4 Entwicklungsphasen des Klausurorganisationssystems  7

  Abbildung 5 Prozeß der Sollkonzeptentwicklung  9

  Abbildung 6 Klausurstruktur  10

  Abbildung 7 Der Prozeß Klausurorganisation i e S  11

  Abbildung 8 Struktur der Zulassungsliste  11

  Abbildung 9 Der Prozeß Klausurorganisation im Kontext  13

  Abbildung 10 Abruf der Daten aus Pluto  16

  Abbildung 11 Weitergabe der Daten auf Diskette  17

  Abbildung 12 Bewertung der Entwicklungssysteme  20

  Abbildung 13 Der Funktionsbaum des Klausurorganisationssystems  22

  Abbildung 14 Fensteraufbau des Klausurorganisationssystems  24

  Abbildung 15 Entitättyp FACHPRÜFUNG  27

  Abbildung 16 Entitättyp LEHREINHEIT  27

  Abbildung 17 Entitättyp KLAUSUR  27

  Abbildung 18 ER-Modell für die Entitättypen Klausur Fachprüfung und Lehreinheit  28

  Abbildung 19 ISA Beziehungen  28

  Abbildung 20 ERM der Klausurorganisation  29

  Abbildung 21 Die Beziehung zwischen Klausur und Fachprüfung  33

  Abbildung 22 Beziehung zwischen Fachprüfung und Lehreinheit  34

  Abbildung 23 Benutzerzuordnungen  35

  Abbildung 24 Zuordnung der Menüs zu den Benutzergruppen  37

  Abbildung 25 Prinzip der Einblendung von Zusatzmenüleisten  37

  Abbildung 26 Querverweise zwischen Dialogformularen  39

  Abbildung 27 Programmablaufplan der Raum und Platzbelegung  41

  Abbildung 28 Tabellen für die Raum und Platzbelegung  42

  Abbildung 29 Abfrage: Anzahl Kandidaten je Klausur  43

  Abbildung 30 Prozedur Weiter der Klausurauswahl  44

  Abbildung 31 Aufbau der Funktion AutoRaumzuteilung  45

  Abbildung 32 Zusammenhang von Klassen und Standardmodulen  45

  Abbildung 33 Beispiel eines Projektplans zur Softwareeinführung  53

Einführung Seite 1

1 Einführung

Unter Klausurorganisationssystem ist eine Software zu verstehen, die Lehrende der Fachhochschule Dortmund nutzen können, um Klausuren mit Hilfe der elektronischen Datenverarbeitung zu organisieren. Es stellt einen Bestand an Funktionen bereit, welche die Aufgaben der Klausurvorbereitung und -bewertung unterstützen. Dabei wird darauf gebaut, daß die klausurrelevanten Daten, von der Fachhochschulverwaltung, in einer elektronisch verarbeitbaren Form zur Verfügung gestellt w erden. Dem System liegt eine relationale Datenbank zugrunde, welche Microsoft Access mit dem Anwendungsprogramm vereint. Dabei ist das Anwendungsprogramm derart konzipiert, daß zur Bedienung der Software weder Kenntnisse über Datenbanken im allgemeinen, noch über Microsoft Access im speziellen erforderlich sind. Insofern kann das Klausurorganisationssystem aus Sicht des Anwender als eigenständiges Programm betrachtet werden. Die Entwicklung der Software bezieht sich auf Zweierlei: einerseits auf die Entwicklung der Datenbank und andererseits auf die Anwendungsprogrammierung. Diese Diplomarbeit beschreibt die verschiedenen Entwicklungsstufen und bildet zusammen mit den Anhängen die Entwicklungs- und Systemdokumentation.

1.1 Aufbau der Diplomarbeit

Im Anschluß an diese Einführung befaßt sich das zweite Kapitel mit der Planung der Softwareentwicklung. Dabei werden stets theoretische Ausarbeitungen mit der praktischen Entwicklungsarbeit in Zusammenhang gebracht. Im ersten Teil dieses Kapitels sollen verschiedene Phasenmodelle der Softwareentwicklung dargestellt werden, um diesen die realisierten Phasen der Entwicklung gegenüberzustellen. In den darauffolgenden Teilen des zweiten Kapitels soll erläutert werden, wie aus einer Problemerkenntnis ein detailliertes Sollkonzept entsteht. In diesem Zusammenhang wird eine Problemstellung herausgearbeitet, welche die Entwicklung eines Klausurorganisationssystems begründet. Dazu wird der Prozeß Klausurorganisation näher untersucht und eine Struktur erarbeitet, die Grundlage für d ie Entscheidung über die zum Einsatz kommende Entwicklungssoftware ist. Im fünften und letzten Teil des zweiten Kapitels wird das Sollkonzept und dessen Entstehung ausführlich erörtert. Dieses Sollkonzept besteht aus einer verbalen Beschreibung der Softwareanforderungen, der Darstellung des Sollprozesses sowie der Darstellung des Datenbankentwurfs.

Das dritte Kapitel befaßt sich mit der eigentlichen Entwicklung des Klausurorganisations- systems. Dazu wird im ersten Teil das Datenbankmanagementsystem Microsoft Access 97 vorgestellt, welches die Entwicklungsumgebung liefert. Darauf aufbauend soll im zweiten Teil, in enger Anbindung an den Datenbankentwurf des Sollkonzepts, die Definition des relationalen Datenmodells erfolgen. Dieses Datenmodell ist Grundlage für die Funktionsentwicklung, wie sie

Einführung Seite 2

im dritten Teil dieses Kapitels dargestellt wird. Dieser Teil gliedert sich in die Erläuterung des Konzeptes der Menü- und Dialogsteuerung und in die Beschreibung der Programmierung der Funktionen anhand eines Beispiels.

Letztlich soll das vierte Kapitel Aufschluß über die Grundlagen von Softwaretests und Softwareeinführungen geben, um die Testphase des Klausurorganisationssystems beschreiben sowie Maßnahmen zur Systemeinführung nennen zu können.

1.2 Ziel der Arbeit

Diese Diplomarbeit soll die praktische Softwareentwicklungstätigkeit dokumentieren und dabei den Bezug zu theoretischen Modellen, wie Phasenmodellen, Datenmodellen oder Prozeßkettendiagrammen herstellen. Dabei sollen Problembereiche, die sich aus diesem Bezug ergeben aufgezeigt werden. Der Anhang A, das Handbuch des Klausurorganisationssystems, dient dem Anwender als Nachschlagewerk im Rahmen der Benutzung des Systems. Nicht zuletzt soll die Arbeit zur Weiterentwicklung des Klausurorganisationssystems animieren, denn mit dem Vorliegen der aktuellen Version kann die Entwicklung, aus Sicht des Autors keineswegs als abgeschlossen betrachtet werden. Hierzu können die Objektdefinitionen, die dem Anhang B zu entnehmen sind, dienlich sein. Die Hauptsache der Entwicklung liegt jedoch in dem Vorliegen eines Systems, das die Klausurorganisationstätigkeiten erheblich vereinfachen kann, wie diese Arbeit zeigen wird.

Entwicklungsplanung Seite 3

2 Entwicklungsplanung

Planung dient dem Zweck, eine Ereignis- und Aktionsabfolge festzulegen, die von einem Istzustand zu einem gewünschten Sollzustand führt. Dabei bezeichnet der Istzustand eine Ausgangssituation, die in der Gegenwart liegt und der Sollzustand ein bestimmtes Ziel, das in der Zukunft liegt. Unter einem Plan kann somit eine definierte Abfolge von Ereignissen und Aktionen zur Erreichung eines gewünschten, zukünftigen Zustands verstanden werden. Die Erfordernis zur Planung ergibt sich aus einem, als unbefriedigend empfundenen Istzustand. Das Ziel der Planung ist somit eine Zustandsverbesserung. Bezogen auf die Softwareentwicklungsplanung bedeutet dies, daß ein Istzustand durch den Einsatz oder der Veränderung einer Software verbessert werden soll. Dabei bezieht sich die Planung auf folgende Bereiche:

• Analyse des Prozesses, der durch den Einsatz einer Software zu verändern ist.

• Planung des Softwareentwicklungsprozesses.

• Projektmanagement

Diese Bereiche können zusammenfassend als Software-Engineering bezeichnet werden. 1 besteht Software-Engineering aus dem Softwareentwicklungsprozeß sowie aus

Nach DENERT dem Projektmanagement, wobei letzteres Planen, Kontrollieren und Verwalten, vor allem aber Führen und Koordinieren aller Beteiligten bedeute. Etwas weiter faßt ZILAHI-SZABÓ den Begriff: "Die Disziplin Software-Engineering umfaßt (...) den Gesamtprozess d er Systemanalyse, -

2

entwicklung und -nutzung."

Die Planung von Softwareentwicklungen kann je nach Projektumfang unterschiedliche Ausmaße annehmen. Dabei können Fragen des Budgets, des einzusetzenden Personals oder des Zeitrahmens in Abhängigkeit von der Zielsetzung, mit unterschiedlicher Gewichtung in die Projektplanung eingehen. Die Entwicklungsplanung des Klausurorganisationssystems bezieht sich zum einen auf den zu optimierenden Prozeß Klausurorganisation und zum anderen auf den Gesamtprozeß der Softwareentwicklung. Ein Projektmanagement kam aus folgenden Gründen nicht in Betracht:

• Das Projekt wurde nur durch eine Person bearbeitet.

• Die Entwicklung verursachte der Fachhochschule keine Prozeß- oder Zusatzkosten und unterlag somit keinen Budgetrestriktionen.

1 Vgl.: [DENERT], Seite 13

2 So: [ZILAHI-SZABÓ], Seite 293

Entwicklungsplanung Seite 4

Zusammenfassend kann die Entwicklungsplanung in die Bereiche Planung der Vorgehensweise anhand von Phasenmodellen sowie der Problemanalyse und Sollkonzeptentwicklung geteilt werden.

2.1 Phasenkonzeption

Das Konzept der Entwicklungsphasen spielt in der Softwareentwicklung eine große Rolle. In der Literatur wird eine nahezu unüberschaubare Vielfalt an Phasenmodellen diskutiert. An dieser Stelle sei ein kleiner Überblick der verschiedenen Modelle gegeben, um im folgenden die Phasen der Klausurorganisationssystementwicklung zu erläutern.

2.1.1 Phasenmodelle

Lineare Phasenmodelle kennzeichnen sich durch Ihren, nach vorn gewandten Ablauf der Phasen aus, wobei eine Phase erst beginnt, wenn die vorhergehende vollständig abgearbeitet

3 in die Grundphasen:

wurde. Die Abschnitte gliedern sich nach STAHLKNECHT

• Systemanalyse,

• Systementwicklung,

• Systemeinführung und

• Systempflege.

Diese Grundphasen werden durch unterschiedliche Gewichtung auf die Phasen in

4 die folgenden Phasen als typisch:

verschiedenster Art verfeinert. So bezeichnet EBERLEH

• Planung,

• Analyse,

• Design,

• Programmierung,

• Installation und Test sowie

• Betrieb und Wartung Weiterentwicklungen des linearen Phasenmodells resultieren aus der Frage, ob von einer Phase in eine vorangegangene zurückgesprungen werden darf. Bei einer sequentiellen "Abarbeitung" der Phasen werden ggf. Fehler, die in einer der ersten Phasen gemacht werden, bis in die Letzte mitgezogen. Aus diesem Dilemma entstand das sogenannte Wasserfallmodell

5

mit Rückkopplung nach BOEHM .

3 Vgl.: [STAHLKNECHT], Seite 220

4 Vgl.: [EBERLEH], Seite 350 5 Vgl.: [BOEHM], Seite 494ff.

Entwicklungsplanung Seite 5

6

Abbildung 1 Wasserfallmodell mit Rückkopplung nach BOEHM

Dieses Modell soll ein frühstmögliches Aufspüren von Fehlern ermöglichen und deren Beseitigung in derjenigen Phase gewährleisten, in welcher sie aufgetreten sind. Als besonderen Nachteil empfand BOEHM selbst, daß in frühen Phasen des Projekts der Gesamtumfang nicht oder nur schwer überschaubar ist mit der Folge, daß z.B. erst bei der Codierung klar wird, daß das Projekt u.U. nicht realisierbar ist. Somit schlug BOEHM das sogenannte Spiralmodell vor. Bei diesem Modell werden vier Phasen der Softwareentwicklung mehrfach durchlaufen, wobei angestrebt wird, möglichst früh Prototypen vorliegen zu haben, die bewertet werden können. Anhand dieser Bewertung wird entschieden, ob eine Weiterentwicklung des Projekts bzw. von Projektteilen lohnt oder nicht.

6 entnommen aus [BOEHM], Seite 495

Entwicklungsplanung Seite 6

7 Abbildung 2 Spiralmodell nach BOEHM

Das Spiralmodell wurde im Laufe der Zeit verschiedentlich modifiziert und weiterentwickelt.

Letztlich sei das Prototyping als Vorgehensmodell erwähnt. Hier geht es darum, möglichst schnell ein ablauffähiges Programm zu erstellen, an dem die Eigenschaften des Produkts untersucht werden können. Aus dieser Untersuchung ergeben sich die Anforderungen, die in das Endprodukt eingehen sollen. I nsofern kann die Prototyperstellung als besonderes Hilfsmittel der Systemanalyse verstanden werden, obgleich der Prototyp in alle Entwicklungsphasen einfließt, wie Abbildung 3 zeigt.

8 Abbildung 3 Prototyping - Modell

7 Vgl.: [BALZERT], Seite 129ff.

8 entnommen aus [CHROUST], Seite 165

Entwicklungsplanung Seite 7

2.1.2 Realisierte Phasen der Softwareentwicklung

Im vorangegangenem Kapitel wurden einige Phasenmodelle erwähnt und kurz beschrieben. Nun geht es darum, die Entwicklungsphasen der Klausurorganisationssystementwicklung aufzuzeigen. Die Entwicklung des Klausurorganisationssystems war durch eine lange Entwicklungszeit geprägt, in der sich Anforderungen und Aufgabenstellungen verändert haben. Gestartet wurde die Entwicklung im Rahmen einer Projektarbeit, betreut von Dr. Unterstein der Fachkonferenz Informatik, des Fachbereichs Wirtschaft im Wintersemester 96/97. Die Aufgabenstellung bezog sich zunächst auf die Auslotung von technischen Möglichkeiten zur Datenübernahme aus dem Rechner der Fachhochschulverwaltung, zur Weiterbearbeitung in einer Tabellenkalkulations- oder Datenbankanwendung. Dabei ging es um diejenigen Daten, die zur Organisation der Fachprüfung Datenverarbeitung I, relevant waren. In diesem Zusammenhang war ein Konzept und eine Anwendung für die Automatisierung von Organisationstätigkeiten wie Raum- und Sitzplanung oder Notenberechnungen zu erarbeiteten. Dazu wurde eine Microsoft Access Datenbankanwendung entwickelt, die diese Funktionen zur Verfügung stellte. Anhand dieser Datenbankanwendung konnten neue Anforderungen an das System definiert werden, welche wiederum umgesetzt wurden. Schließlich war die Projektarbeit abgeschlossen und das Klausurorganisationssystem sollte im Rahmen dieser Diplomarbeit weiterentwickelt werden. Die Betreuung fand nun durch Prof. Dr. Großmann statt. Dieser personelle Wechsel zog wiederum einen Wechsel der Anforderungen nach sich. So sollte sich z.B. die Anwendung nicht nur auf eine bestimmte Fachprüfung beziehen, sondern die Organisation beliebiger Fachprüfungen durch beliebige Prüfer ermöglichen. Somit wurde das gesamte Konzept überarbeitet.

Diese Beschreibung der verschiedenen Entwicklungsstufen lassen einen Vergleich zum Spiralmodell oder zum Prototyping zu. In der Tat lagen schon mehrere Versionen des Klausurorganisationssystems vor, welche als Prototypen bezeichnet werden können. Die folgende Abbildung stellt die Entwicklungsphasen der Systemprototypen dar:

Projektstart

Abbildung 4 Entwicklungsphasen des Klausurorganisationssystems

Entwicklungsplanung Seite 8

Die Abbildung stellt die Entwicklungsphasen der Prototypen des Klausurorganisationssystems dar, wobei es jedoch noch nicht zu einer Systemeinführung gekommen ist. Der graue Balken in der Zeile Systemeinführung soll andeuten, daß das System noch einzuführen ist (vgl.: Kapitel 4, Seite 47).

Im folgenden sollen nicht die einzelnen Phasen der Entwicklung jeder Version erläutert werden. Es wird vielmehr von der Entwicklung des Klausurorganisationssystems in der aktuellen Version ausgegangen. Dabei fließen die Ergebnisse der Vorversionen in die Beschreibungen der Phasen mit ein.

2.2 Vom Problem zum Sollkonzept

Ausgangspunkt aller Tätigkeiten im Rahmen der Entwicklung von Individualsoftware, ist ein unbefriedigender Zustand. Seitens der betroffenen Person kommt der Wunsch auf, diesen Zustand zu verändern. Diese Phase stellt das Erkennen eines Problems dar. Das bedeutet nicht, das es bereits eine konkrete Beschreibung des Problems geben muß. In den meisten Fällen herrscht vielmehr das Gefühl vor: "Hier ist etwas nicht in Ordnung!", oder "Kann man das nicht besser machen?", wobei jedoch die Erkenntnis besteht, daß der Einsatz einer Software den Prozeß zum Positiven verändern könnte. In diesem Fall kann zur Problemanalyse eine außenstehende Person, ein Softwareentwickler hinzugezogen werden. Sie wird in enger Zusammenarbeit mit dem Anwender eine Istaufnahme vornehmen um Schwachstellen aufzuzeigen und erste Lösungsansätze entwickeln. Das Ergebnis dieser Phase ist eine grobe Sollstruktur, welche eine Sollprozeßbeschreibung und die daraus entwickelten Systemanforderungen dokumentiert. Diese Dokumentation der Lösungsalternativen sei als feine Sollstruktur bezeichnet, die dem Anwender als unabdingbare Entscheidungsunterlage dient. Erst nach Auswahl der, aus Sicht des Anwenders, besten Alternative kann diese näher konkretisiert werden. Das bedeutet die Erweiterung der feinen Sollstruktur, um den Bezug zu einer konkreten Software, zum Sollkonzept. Das Sollkonzept ist somit keine Aufzählung von Möglichkeiten mehr, sondern eine Auswahl aus diesen und deren konkrete Beschreibung, z.B. in einem Pflichtenheft.

Entwicklungsplanung Seite 9

Abbildung 5 Prozeß der Sollkonzeptentwicklung

Diese Abbildung stellt den Prozeß der Sollkonzeptentwicklung modellhaft dar. In der Realität wird es Abweichungen in unterschiedlichen Ausprägungen geben. Dies kann vom Umfang des Projekts, von der Art der Beziehung der Beteiligten zueinander oder anderen Faktoren abhängen. So war die Sollkonzeptentwicklung des Klausurorganisationssystems durch die Professor (Anwender) - Student (Entwickler) - Beziehung und der Tatsache der nicht anfallenden Kosten geprägt.

2.3 Problemstellung

2.3.1 Der Prozeß Klausurorganisation

Vor der Analyse des Klausurorganisationsprozesses, seien die im folgenden verwandten Begriffe erläutert:

Eine Klausur ist eine Zusammenfassung für die Fachprüfungen, die fachlich, terminlich und organisatorisch eine Einheit bilden. Eine Fachprüfung bezieht sich auf ein bestimmtes Fach eines Studiengangs mit der entsprechenden Version der Studienordnung. Des weiteren können Fächer in Lehreinheiten unterteilt sein. Dementsprechend werden Lehreinheiten den Fachprüfungen zugeordnet. Sie stellen in diesem Zusammenhang einen Teil der Fachprüfung dar, welche durch verschiedene Personen gestellt und korrigiert werden. Diese Personen seien als Prüfer bezeichnet. Derjenige Prüfer, der für die Organisation der gesamten Klausur verantwortlich ist, sei als Hauptprüfer bezeichnet. Die folgende Abbildung faßt diese Begriffe beispielhaft zusammen:

Entwicklungsplanung Seite 10

Abbildung 6 Klausurstruktur

Wie die Abbildung zeigt, muß nicht jede Lehreinheit jeder Fachprüfung zugeordnet sein. So ist z.B. die Lehreinheit x nicht der Fachprüfung, Studiengang 1, Studienordnung A zugeordnet. Andererseits muß jedoch jede Fachprüfung zumindest aus einer Lehreinheit bestehen. Der Vollständigkeit halber sei erwähnt, daß die starre Zuordnung des Prüfers zur Lehreinheit nicht korrekt ist. Denn es sind Konstellationen möglich, bei der eine Lehreinheit durch verschiedene Prüfer, in Abhängigkeit von der Fachprüfung, geprüft wird. Dementsprechend müßte sich die Zuordnung des Prüfers auf die Verbindung von Lehreinheit zu Fachprüfung beziehen. Dieser Fall wird später berücksichtigt, aufgrund der Darstellbarkeit jedoch an dieser Stelle ausgespart.

Eine Analyse des Geschäftsprozesses Klausurorganisation des Fachbereichs Wirtschaft erfolgte durch Befragungen, z.B. von Dozenten oder Angestellten des Prüfungsamtes und durch Beobachtungen. Das Ergebnis der Analyse ist die Darstellung des Prozesses i n Form

9

eines Ereignisprozeßkettendiagramms nach der ARIS -Methode Diagramm beschreibt die Klausurorganisation im eigentlichen Sinne (i.e.S.) sich auf die Organisationstätigkeiten des Hauptprüfers:

9 Vgl.: [SCHEER98], Seite 20ff.

10 Vgl.: Anhang A: "Klausurorganisationssystem, Handbuch", Seite 1ff.

Entwicklungsplanung Seite 11

Abbildung 7 Der Prozeß Klausurorganisation i.e.S.

Die durch das Prüfungsamt erstellten Zulassungslisten werden an die jeweiligen Hauptprüfer weitergereicht. Dieses Ereignis ist für den Hauptprüfer das Signal für den Start der Klausurorganisation. Ferner erhält der Hauptprüfer einen Prüfungsplan.

Die Zulassungslisten beziehen sich jeweils auf eine Fachprüfung, und somit auf den Studien- gang und der entsprechenden Studienordnung. Eine Zulassungsliste hat folgende Struktur.

Abbildung 8 Struktur der Zulassungsliste

Zusätzlich steht dem Hauptprüfer der Prüfungsplan, ebenfalls in Form einer Liste zur Verfügung. Der Prüfungsplan ist gruppiert nach Studiengang, Studienordnung und dem Kriterium "Grund- oder Hauptstudiumsklausur". I nnerhalb dieser Gruppierung sind alle Fachprüfungen des Fachbereichs aufgeführt, mit folgenden Angaben:

Fachnummer, Fachbezeichnung, Gewichtung, Reguläres Semester, Tag der Prüfung, Uhrzeit, Dauer in Minuten, Form, Anzahl der Meldungen, Prüfer und Raum/Aufsicht.