# Projekt Klausurplaner JHS

Planung für einen Klausur-/Aufsichtenplaner (nur WHV)

:::spoiler Inhaltsverzeichnis
[toc]
:::

## Allgemein

**Beteiligte**

* Entwickler: AK, MF, HB, (OK)
* Ansprechpartner:
* FB W CW, ST
* FB MIT RM, (AL)
* ggf. FB I (RZ)

**Termine**

:::spoiler vergangene Termine
* Januar 2024 Idee, Abstimmung Anforderungen
* 08.01. "KickOff-Meeting"
* 12.02. Detailplan zu den Vorgaben (Format Prüferplan, Prüfungen)
* 13.02. Konzeptvorstellung der SSPler
* 19.02. Detailabstimmung CSV, Zeitplan
:::

* 15.03. Ziel: Prototyp (SSP AK/MF)

**Lizenz**

* Software: [GPL 3.0](https://www.gnu.org/licenses/gpl-3.0.de.html) (Freie Software)
* Doku: [CC-0 1.0](https://creativecommons.org/publicdomain/zero/1.0/deed.de)

**Softwareentwicklung**

* Versionsverwaltung: **[github](https://github.com/ricom/pruefungsplaner)**
* Planung: [trello](https://trello.com/invite/b/cLdv6JHX/ATTIe91331fc6f5813ed27683ecab83974df392A520F/) (Einladungslink!)

## Anforderungen

:::spoiler Programmierumgebung
* Webanwendung Standards
* Programmiersprache: PHP mind. 8.1
* HTML5/CSS3
* Javascript (möglichst wenig)
* Entwicklerdokumentation: PHPDoc
* Sparche: deutsch (Doku, Klassen, etc.)
* Frameworks
* [PHP Laravel](https://laravel.com/) 10.x und Module
* HTML/CSS [Bootstrap](https://getbootstrap.com/docs/5.0/getting-started/introduction/) 5.x
* IDE: empflohnnen [VSC](https://code.visualstudio.com/download)
* Hosting: Jade HS
:::

:::spoiler Allgemeine Rahmendaten

* Einzubindende Organisationseinheiten
* FB W
* FB MIT
* FB I (Aula)
* Onlineteam?
* Zeiten
* 4 Prüfungsblöcke (08:15 - 10:30, 10:45 - 13:00, 13:15 - 15:30, 15:45 - 18:00, 18:15 - 20:30 (RZ))
* Onlinestudiengänge (09:00, 12:00, 15:00)
* Pläne
* Prüferplan (jedes Semester neu)
* Aufsichtenplan (jedes Semester neu)
* Prüfungsplan
* Raumplan mit Raumnummern, Plätze (bleibt gleich)
* Räume
* jeder Fachbereich hat eigene Räume
* einige große Räume Aula, ME02, H101 gemeinsam genutzt (Abstimmung notwendig, Verteilungsplan liegt vor (RZ))
:::

:::spoiler Anforderungen FB MIT/W (gekürzt)

1. Planung nur für Klausurenprüfungen K1 und K2 (FB W, FB MIT) und E-Prüfungen (FB W)
2. Weitere individuelle Prüfungstermine manuell (FB MIT, FB W)
3. Pro Semester eines Studiengangs pro Tag max. eine Klausur und mind. ein Tag Pause (FB MIT)
4. In benachbarten Semestern eines Studiengangs Klausuren nicht am selben Tag (FB MIT, FB W)
5. Alle Klausuren eines Studienganges sollen sich zeitlich nicht überlappen (FB MIT)
6. Raumgröße soll zur Zahl der Prüflinge passen (FB MIT, FB W)
7. Anzahl Prüflinge erst nach der Anmeldephase bekannt (FB MIT, FB W)
8. Räume (z.B. Aula, ME02) können nur nach Absprache mit Fachbereichen genutzt werden
9. Prüferplan vorab festgelegt (wird für jeden FB erstellt)
10. FB MIT Aufsichten ordnen sich selbst Klausuren zu
11. Ab 50 Prüflinge zwei Aufsichten
12. Klausuren mit Nachteilsausgleich separat geplant
13. TODO: FB MIT Semesterzüge, FB W nur Studiengänge?

:::

:::spoiler Excel-Datei für den Import (Prüfungsplan)

* **Nummer:** Kursnummer lt. Prüfungsamt
* **Bezeichnung:** Kurstitel vollständige Länge nach Modulhandbuch
* **Prüfer_in:** Name des/der Prüfer_in
* **Datum:** Angesetztes Prüfungsdatum
* **Uhrzeit Beginn:** Beginn der Prüfung
* **Uhrzeit Ende:** Ende der Prüfung
* **Prüfungsform:** Klausur, eHausarbeit oder Test am Rechner
* **Studiengang:** Zugehörig zu Studiengang x
* **Fachbereich:** W oder MIT

:::

:::spoiler Wunschliste

* Termine für Exchangekalender eintragen, zur Verfügung stellen (für Prüfer, Aufsichten)
* Anbindung an SPlus ()

:::

## UML Diagramme

:::spoiler Use Case Diagramme (TODO HB)

### Use Case

package Akteure {
    actor Administrator as AD
    actor Pruefer as P
    actor Aufsicht as A
    actor System as S
}

### Anwendungsfälle Administrator(Zuständige)

- [ ] Verwaltung von Räumen
- [ ] Verwaltung von Prüfern
- [ ] Verwaltung von Aufsichten
- [ ] Verwaltung von Prüfungen

left to right direction
skinparam packageStyle rectangle

actor Administator as AD
actor System as S

rectangle Räume{
    usecase "Räume aussuchen" as UC1
    usecase "Räume reservieren" as UC2
}

AD  --> UC1
UC1 --> S
S   --> UC2

### Anwendungsfälle Pruefer

- [ ] Einmallogin
- [ ] Übersicht über seine Prüfungen
- [ ] Zeiträume Verfügbarkeit (bisher Wunschzettel)

### Anwendungsfälle Aufsicht

- [ ] Einmallogin
- [ ] Übersicht über seine Prüfungen
- [ ] Termine Prüfungsaufsicht auswählen
- [ ] Info über Verlegung, Ausfall etc. einer Prüfung
- [ ] Ausfalle der Aufsicht (krank, etc.)

### Anwendungsfälle System

left to right direction
skinparam packageStyle rectangle

actor Administrator as AD
actor Aufsicht as A
actor System as S

rectangle Meldungen{
    usecase "Änderung angeben" as UC1
    usecase "Änderung bekannt geben" as UC2
}

AD  --> UC1
UC1 --> S
S   --> UC2
UC2 --> A

## Klassendiagramm

:::spoiler Klassendiagramm Entwurf (TODO)

skinparam style strictuml
skinparam class {
    BackgroundColor white
    ArrowColor gray
    BorderColor black
}

class Pruefer { 
    - name: String
    - vorname: String 
    - Akad_Grad: int
    + getName(): String
    + getVorname(): String
    + setName(String)
    + setVorname(String)    
}

:::

## Screenshots (alte Software FB W ST)

:::spoiler Screenshots
* **Beschreibung:** Der nachfolgende Screenshot zeigt die derzeitige Interimslösung, die nach der nicht mehr lauffähigen Access-DB genutzt wird. Sie ist in Claris Filemaker Pro umgesetzt und kann sowohl auf MacOS als auch unter Windows verwendet werden.

* **Einzelblatt:** Darstellung/Eingabemaske für eine Prüfung inkl. Anmeldezahl, Aufsichten und Prüfungsraum

* **Anmeldezahl:** Nach Ende des Prüfungsanmeldezeitraums wird über diese Eingabemaske die Anmeldezahl eingepflegt. Sie wird vom Prüfungsamt mitgeteilt und dient zur Festlegung der erforderlichen Raumkapazität für die Prüfung und die Anzahl der erforderlichen Aufsichten.

* **Liste Intern/Web:** Unterschiedliche Listen für die interne (unter den MA, z.B. inkl. Aufsichten) und die öffentliche (Web-Veröffentlichung) Verwendung.

* **Tagesvertreter:** Eingabemaske für die Vergabe der Tagesvertretung. Sollten Aufsichten kurzfristig ausfallen, treten die Tagesvertreter an ihre Stelle.
:::

## Archiv

### Anforderungen (alt)

:::spoiler Anforderungen FB MIT (original)
1. Im Dekanat FB MIT planen wir ausschließlich Klausurenprüfungen (K1 und K2).
2. Weitere Prüfungstermine werden uns u.U. mitgeteilt und dann im Klausurenplan veröffentlicht (nach Zuruf). Diese Tage / Zeiträume stehen dann nicht für Klausurenplanung zur Verfügung ()
3. Klausuren in einem Semester eines Studiengangs sind so zu planen, dass pro Tag max. eine Klausur geplant wird und zwischen den Klausuren mind. ein Tag Pause eingefügt wird
4. Klausuren eines benachbarten Semesters eines Studiengangs sollen nicht auf den selben Tag gelegt werden
5. Alle Klausuren eines Studienganges sollen sich zeitlich nicht überlappen.
6. Die Raumgröße soll zur Prüfungsteilnehmerzahl passen (es wird max. die Hälfe der normalen Raumbelegung verplant)
7. Anzahl der Prüflinge der jeweiligen Prüfungen erfahren wir nach der Anmeldephase
8. Gemeinsame Räume (z.B. Aula) können nur nach Absprache mit anderen Fachbereichen in WHV genutzt werden (dazu haben wir bisher einen Plan, verschickt vom FB I, genutzt)
9. Die Prüfer für die Klausuren sind bereits im Prüferplan festgelegt (der vom FB MIT erstellt wird)
10. Aufsichten werden zurzeit so geplant, dass die Kollegen sich selbständig in die Tabelle der Klausuren eintragen (ab 50 Prüflinge planen wir mit zwei Aufsichten)
11. Klausuren, für die die Prüflinge einen Nachteilsausgleich bekommen, werden separat geplant. D.h., dass dafür ein weiterer Raum und eine weitere Aufsicht (meist pro Nachteilsausgleichsklausur) gestellt werden
:::

### Datenbank

:::spoiler Datenbankmodell (Entwurf RM)

Das Datenbankmodell wird bei der Nutzung von PHP und Laravel durch das Model (Klassendiagramm) generiert und angepasst.

RM: Datenmodell auf Basis von CW als Vorlage (zum gemeinsamen Bearbeiten)

left to right direction     
hide circle

entity Pruefer {
    PrueferID (PK)
    --
    Name
    Vorname
    AkadGradID
}

entity Fach {
    FachID (PK)
    --
    Name
    PrueferID (FK)
}

'? ggf. Prüfungstermin? '
entity Pruefungstermin {
    PruefungID (FK)
    FachID (FK)
    --
    Semester
}

entity Pruefung {
    PruefungID (PK)
    --
    Name
    Dauer
}

'? Mitarbeiter in Aufsicht umbenannt '
entity Aufsicht {
    AufsichtID (PK)
    --
    Name
    Vorname
    Status ?
    AkadGradID (FK)
    StatusID (FK)
}

'? BezeichnungL/K in StatusKurz und StatusLang geändert '
entity Status {
    StatusID (PK)
    --
    StatusLang
    StatusKurs
}

'? Bezeichnung in AkadGradLang; Kurzform in AkadGradKurz '
entity AkadGrad {
    AkadGradID (PK)
    --
    AkadGradLang
    AkadGradKurz
}

'? Bezeichnung Student in Raum geändert '
entity Raum {
    RaumID (PK)
    --
    RaumNr
    RaumKapazitaet
}

' Beziehungen '

 '? Relation im ERD richtig? hier gedreht: '
Pruefer     "1" -- "n" Aufsicht
Pruefer     "1" -- "n" Fach
Pruefer     "1" -- "n" Pruefung

Fach        "1" -- "n" Pruefung
Fach        "1" -- "n" Pruefungstermin

Pruefung    "1" -- "n" Pruefungstermin
Pruefungstermin "1" -- "n" Raum
Pruefungstermin "1" -- "n" Aufsicht
Status      "1" -- "n" Aufsicht

 '? 1:1 Relation im ERD richtig? hier geändert: 1:n '
AkadGrad    "1" -- "n" Aufsicht
AkadGrad    "1" -- "n" Pruefer

**TODO-Liste**

- [ ] Begriffe/Tabellen klären
- [x] Aufsicht besser Aufsicht?
- [x] Mehrere Aufsichten (FB MIT)
- [x] Relation AkadGrad 1 -- n Prüfung?
- [x] Student besser Raum?
- [ ] Akademischer Grad besser Titel?
- [ ] ERD besprechen
- [ ] Zweitprüfer?
- [ ] Prüfung Termin?
- [ ] Slots mit Zeiten?
- [ ] Studiengang?
- [ ] Fachbereich?
:::

:::spoiler Vorlage ERD (CW)
:::