Entwicklung einer webbasierten Anwendung zur Erstellung, Verwaltung und Freigabe digitaler Ausbildungsnachweise

2.1 Unternehmens- und Projektumfeld

Das Projekt wird bei der Systemhaus Ulm GmbH in Neu-Ulm durchgeführt. Das Unternehmen ist im Bereich IT-Dienstleistungen und Softwareentwicklung tätig. Auftraggeber des Projekts ist der fachliche Ausbilder. Die spätere Benutzergruppe der Anwendung besteht aus Auszubildenden, Umschülern, Werkstudenten und Praktikanten sowie den zuständigen Ausbildern.

Die Anwendung unterstützt einen wiederkehrenden betrieblichen Prozess: die Erstellung, Prüfung und Archivierung von Ausbildungsnachweisen. Ausbildungsnachweise sind für die Ausbildung relevant, da sie den Verlauf der Ausbildung dokumentieren und regelmäßig geprüft werden müssen. Der bisherige Prozess ist abhängig von einer externen Plattform und kann nur begrenzt an interne Anforderungen angepasst werden.

2.2 Ist-Analyse

Aktuell werden Ausbildungsnachweise über eine externe Webanwendung geführt. Auszubildende erfassen dort ihre Tätigkeiten, während Ausbilder die Nachweise prüfen und freigeben. Die Datenverarbeitung und Speicherung erfolgt außerhalb des Unternehmens. Anpassungen an das Layout, den Workflow oder zusätzliche interne Anforderungen sind nur im Rahmen der vom Anbieter bereitgestellten Funktionen möglich.

Die Nutzung der externen Lösung führt zu folgenden Einschränkungen:

• wiederkehrende Lizenzkosten pro Benutzer oder Zeitraum
• Abhängigkeit von Verfügbarkeit und Weiterentwicklung des Drittanbieters
• eingeschränkte Anpassbarkeit an interne Rollen, Prozesse und Formate
• begrenzte Kontrolle über Datenhaltung und technische Erweiterbarkeit
• keine einfache Integration in eigene interne Systeme
• eingeschränkte Möglichkeit zur Umsetzung individueller Erinnerungs- und Freigabeprozesse

Zusätzlich entsteht administrativer Aufwand, wenn neue Benutzer angelegt, Berechtigungen angepasst oder Nachweise exportiert und abgelegt werden müssen. Da unterschiedliche Personengruppen wie Auszubildende, Umschüler, Werkstudenten und Praktikanten betreut werden, ist eine starre externe Lizenz- und Rollenstruktur nicht optimal.

2.3 Problemstellung

Die zentrale Problemstellung besteht darin, dass ein regelmäßig benötigter betrieblicher Prozess von einer externen Lösung abhängig ist. Diese Lösung verursacht Kosten und lässt sich nur begrenzt an interne Anforderungen anpassen. Für den Ausbildungsbetrieb ist es daher sinnvoll, eine eigene Webanwendung zu entwickeln, die den Kernprozess der Ausbildungsnachweise digital abbildet und gleichzeitig erweiterbar bleibt.

Die neue Anwendung soll den bestehenden Prozess nicht unnötig komplexer machen. Der Schwerpunkt liegt deshalb auf einem klar abgegrenzten MVP. Dieses MVP enthält die Funktionen, die für die Erstellung, Prüfung und Freigabe von Ausbildungsnachweisen notwendig sind. Erweiterungen wie Mehrmandantenfähigkeit, Schnittstellen zu HR-Systemen oder qualifizierte elektronische Signaturen werden bewusst nicht umgesetzt, um den Projektumfang im Rahmen von 80 Stunden einzuhalten.

2.4 Zielgruppe und Stakeholder

Die wichtigsten Stakeholder des Projekts sind:

Die Hauptbenutzer der Anwendung sind Auszubildende und Ausbilder. Auszubildende benötigen eine übersichtliche Oberfläche zum Erfassen, Speichern und Einreichen ihrer Berichte. Ausbilder benötigen eine Ansicht eingereichter Berichte, Kommentarfunktionen sowie Aktionen zur Freigabe oder Ablehnung.

2.5 Funktionale Anforderungen

Die funktionalen Anforderungen beschreiben, welche konkreten Funktionen die Anwendung bereitstellen muss.

2.6 Nichtfunktionale Anforderungen

Neben den fachlichen Funktionen wurden nichtfunktionale Anforderungen definiert. Diese betreffen Qualitätseigenschaften wie Sicherheit, Wartbarkeit und Bedienbarkeit.

2.7 Projektabgrenzung

Zur Einhaltung des genehmigten Zeitrahmens von 80 Stunden wird das Projekt bewusst abgegrenzt. Nicht Bestandteil des Projekts sind:

• Entwicklung einer nativen mobilen Anwendung
• Migration bestehender Daten aus der bisherigen externen Plattform
• Anbindung an IHK-Portale oder andere externe Systeme
• Umsetzung einer qualifizierten elektronischen Signatur
• Mehrmandantenfähigkeit für mehrere Standorte
• komplexe Reporting- oder Statistikfunktionen
• vollständige Produktivsetzung inklusive Betriebskonzept
• Bearbeitung hochgeladener Word- oder PDF-Dateien direkt im Browser

Diese Abgrenzung stellt sicher, dass der Fokus auf den prüfungsrelevanten Kernfunktionen liegt: Anforderungsanalyse, Konzeption, Datenmodell, Implementierung, Test und Bewertung einer funktionsfähigen Webanwendung.

2.8 Wirtschaftlichkeitsbetrachtung

Die Wirtschaftlichkeitsbetrachtung bewertet, ob die Eigenentwicklung im Vergleich zur weiteren Nutzung einer externen Lösung sinnvoll ist. Da die bisherige Lösung wiederkehrende Lizenzkosten verursacht und nur eingeschränkt anpassbar ist, entstehen sowohl direkte als auch indirekte Kosten.

Für die Eigenentwicklung entstehen zunächst einmalige Projektkosten, die sich aus den Entwicklungsstunden des Auszubildenden sowie den begleitenden Aufwänden für Fachgespräche, Code-Review und Abnahme zusammensetzen. Diese werden anhand kalkulatorischer Stundensätze betrachtet.

Zusätzlich können laufende Betriebskosten für Server, Wartung und Pflege entstehen. Da die Anwendung zunächst als interner Prototyp entwickelt wird und vorhandene Infrastruktur genutzt werden kann, werden diese Kosten im Projektzeitraum nicht als eigenständige Beschaffungskosten angesetzt.

Projektkosten der Eigenentwicklung

Die Kalkulation erfolgt mit kalkulatorischen Stundensätzen (Auszubildender 20,00 EUR, Mitarbeiter 45,00 EUR), da die tatsächlichen Personalkosten nicht veröffentlicht werden.

Kostenvergleich (jährlich)

Die bisher genutzte externe Lösung verursacht nutzerabhängige Lizenzkosten. Für die Betrachtung werden 15 betreute Personen (Auszubildende, Umschüler, Werkstudenten, Praktikanten) zu durchschnittlich 6,00 EUR pro Person und Monat angenommen.

Amortisationsrechnung

Die jährliche Kostenersparnis entspricht den eingesparten Lizenzkosten von 1.080,00 EUR. Die Amortisationsdauer ergibt sich aus den einmaligen Entwicklungskosten geteilt durch die jährliche Ersparnis:

1.915,00 EUR ÷ 1.080,00 EUR/Jahr ≈ 1,77 Jahre ≈ 1 Jahr und 9 Monate

Nach rund 1 Jahr und 9 Monaten sind die Entwicklungskosten durch die eingesparten Lizenzkosten gedeckt. Da das Unternehmen die Anwendung langfristig einsetzen möchte, ist das Projekt auch unter wirtschaftlichen Gesichtspunkten sinnvoll.

Über die rein monetäre Betrachtung hinaus liegt der wesentliche Nutzen in der höheren Anpassbarkeit, der besseren Kontrolle über Daten und Prozesse sowie der Möglichkeit, die Anwendung gezielt zu erweitern. Für ein Systemhaus mit eigener Softwarekompetenz ist dies ein relevanter qualitativer Vorteil. Gleichzeitig reduziert die Eigenentwicklung die Abhängigkeit von Drittanbietern und schafft eine technische Grundlage für weitere interne Digitalisierungsprozesse.

3.1 Technologieauswahl

Für die technische Umsetzung wurde ein klassischer Webanwendungsansatz gewählt. Die Anwendung wird serverseitig mit PHP und Laravel entwickelt. Laravel stellt viele Funktionen bereit, die für das Projekt relevant sind, darunter Routing, MVC-Struktur, Datenbankmigrationen, Eloquent ORM, Middleware, Validierung, Authentifizierung, Mailversand und gute Erweiterbarkeit.

Die Auswahl der Technologien:

Für die Datenhaltung wird im Entwicklungs- und Prototypbetrieb SQLite eingesetzt, da es ohne separaten Datenbankserver auskommt und sich die Anwendung dadurch schnell und reproduzierbar starten lässt. Das relationale Datenmodell ist datenbankunabhängig über Laravel-Migrationen definiert, sodass für den Produktivbetrieb ohne Codeänderung auf MySQL beziehungsweise MariaDB gewechselt werden kann. Der E-Mail-Versand nutzt im Prototyp den Log-Treiber, wodurch die Benachrichtigungen nachvollziehbar in der Logdatei protokolliert werden, ohne dass ein realer Mailserver erforderlich ist.

3.2 Vergleich möglicher Lösungsansätze

Im Rahmen der Konzeption wurden drei grundsätzliche Lösungsansätze betrachtet.

Variante 1: Weiterverwendung der externen Lösung

Diese Variante hätte den geringsten Entwicklungsaufwand verursacht. Die bestehenden Einschränkungen hinsichtlich Lizenzkosten, Datenhaltung und Anpassbarkeit wären jedoch bestehen geblieben. Da das Ziel des Projekts ausdrücklich eine interne und anpassbare Alternative ist, wurde diese Variante verworfen.

Variante 2: Eigenentwicklung als Single-Page-Application mit REST-API

Eine Trennung in Backend-API und modernes JavaScript-Frontend wäre technisch flexibel. Für den Projektumfang von 80 Stunden wäre dieser Ansatz jedoch zu aufwendig gewesen. Zusätzlich hätten Authentifizierung, API-Sicherheit und Frontend-State-Management mehr Komplexität erzeugt, ohne für das MVP zwingend erforderlich zu sein.

Variante 3: Monolithische Laravel-Webanwendung

Diese Variante wurde ausgewählt. Laravel ermöglicht eine schnelle Umsetzung mit klarer MVC-Struktur. Blade-Templates reichen für die benötigten Formulare, Listen und Detailansichten aus. Die Anwendung bleibt trotzdem erweiterbar, da Geschäftslogik später in Services ausgelagert und Schnittstellen ergänzt werden können.

3.3 Architekturkonzept

Die Anwendung wird als monolithische Laravel-Anwendung nach dem MVC-Prinzip umgesetzt. Das bedeutet, dass Datenmodell, Anwendungslogik und Darstellung voneinander getrennt werden.

Die Schichten der Anwendung:

1. Presentation Layer – Blade-Templates, HTML-Formulare, Übersichtsseiten und Detailansichten.
2. Controller Layer – Entgegennahme von HTTP-Requests, Aufruf der Fachlogik und Rückgabe von Views oder Weiterleitungen.
3. Application / Service Layer – Fachliche Abläufe wie Statuswechsel, Einreichen, Freigeben, Ablehnen, Benachrichtigung und PDF-Erzeugung.
4. Domain / Model Layer – Eloquent Models für Benutzer, Ausbildungsnachweise, Einträge und Kommentare.
5. Infrastructure Layer – Datenbank, Mailversand, PDF-Bibliothek und Dateisystem.

Vereinfachte Architektur:

3.4 Rollen- und Berechtigungskonzept

Die Anwendung unterscheidet zwei Hauptrollen:

Die Berechtigungen werden serverseitig umgesetzt. Entscheidend ist, dass die Benutzeroberfläche allein nicht als Sicherheitsmechanismus ausreicht. Auch wenn ein Button für einen Benutzer nicht angezeigt wird, muss der Zugriff im Backend zusätzlich geprüft werden.

Beispiele:

• Ein Auszubildender darf nur eigene Berichte sehen.
• Ein Auszubildender darf einen freigegebenen Bericht nicht mehr bearbeiten.
• Ein Ausbilder darf eingereichte Berichte prüfen.
• Nur freigegebene Berichte dürfen als finales PDF exportiert werden.

Die technische Umsetzung erfolgt über Middleware, Policies oder zentrale Prüfungen in Controller- beziehungsweise Serviceklassen.

3.5 Status- und Freigabekonzept

Ein Ausbildungsnachweis durchläuft mehrere Zustände. Diese Zustände bilden den fachlichen Workflow ab.

Statusübergänge:

Die Statuslogik verhindert ungültige Abläufe. Ein freigegebener Bericht darf beispielsweise nicht mehr durch den Auszubildenden verändert werden. Ein abgelehnter Bericht kann hingegen erneut bearbeitet und wieder eingereicht werden.

3.6 Sicherheitskonzept

Für die Anwendung sind mehrere Sicherheitsmaßnahmen relevant:

• Authentifizierung vor Zugriff auf geschützte Bereiche
• rollenbasierte Autorisierung
• serverseitige Validierung aller Eingaben
• Schutz vor Cross-Site Request Forgery durch CSRF-Tokens
• Schutz vor unberechtigtem Zugriff auf fremde Berichte
• Nutzung vorbereiteter Datenbankzugriffe über Eloquent ORM
• keine Speicherung unnötiger personenbezogener Daten
• klare Fehlermeldungen ohne technische Detailinformationen für Endbenutzer

Da Ausbildungsnachweise personenbezogene Daten enthalten können, ist insbesondere der Zugriffsschutz wichtig. Auszubildende dürfen ausschließlich eigene Berichte einsehen und bearbeiten. Ausbilder erhalten Zugriff auf eingereichte Berichte zur Prüfung.

3.7 Benutzeroberflächen und Navigationsstruktur

Die Benutzeroberfläche wird bewusst einfach gehalten. Die Anwendung soll ohne längere Einarbeitung genutzt werden können. Die Navigation unterscheidet sich je nach Rolle.

Navigation für Auszubildende

• Dashboard
• Meine Berichte
• Neuen Bericht erstellen
• Bericht bearbeiten
• Bericht einreichen
• PDF anzeigen, sofern freigegeben

Navigation für Ausbilder

• Dashboard
• Eingereichte Berichte
• Bericht prüfen
• Kommentar erfassen
• Bericht freigeben
• Bericht ablehnen

Die Oberfläche folgt einem formularbasierten Aufbau. Für die Zielgruppe ist keine komplexe Single-Page-Oberfläche erforderlich. Wichtig sind klare Statusanzeigen, verständliche Aktionen und nachvollziehbare Rückmeldungen nach dem Speichern oder Einreichen.

4.1 Fachliches Datenmodell

Das Datenmodell bildet die zentralen Objekte der Anwendung ab:

• Benutzer
• Ausbildungsnachweise
• Berichtseinträge
• Kommentare

Ein Benutzer kann mehrere Ausbildungsnachweise besitzen. Ein Ausbildungsnachweis besteht aus mehreren Einträgen. Ein Bericht kann Kommentare durch Ausbilder enthalten. Zusätzlich werden Statusinformationen und Zeitpunkte gespeichert.

4.2 Entitäten und Beziehungen

4.3 Tabellenbeschreibung

Tabelle users

Die Tabelle users speichert die Benutzer der Anwendung. Neben den Standardfeldern für Name, E-Mail-Adresse und Passwort enthält sie ein Rollenfeld.

Tabelle training_reports

Diese Tabelle speichert die Wochenberichte. Jeder Bericht ist einem Benutzer zugeordnet.

Tabelle report_entries

Die Tabelle report_entries enthält die einzelnen Tätigkeitszeilen eines Berichts.

Tabelle report_comments

Die Tabelle report_comments speichert Kommentare von Ausbildern zu Berichten.

4.4 Normalisierung

Das Datenmodell wurde so aufgebaut, dass wiederholte Informationen vermieden werden. Benutzerinformationen werden nur in der Tabelle users gespeichert. Wochenberichte verweisen über Fremdschlüssel auf Benutzer. Tätigkeiten werden nicht direkt im Wochenbericht gespeichert, sondern in einer eigenen Tabelle report_entries. Dadurch können mehrere Tätigkeiten pro Bericht abgebildet werden, ohne mehrere Spalten wie activity_1, activity_2 oder activity_3 anlegen zu müssen.

Die erste Normalform ist erfüllt, da alle Felder atomare Werte enthalten. Die zweite Normalform ist erfüllt, da alle Nicht-Schlüsselfelder vollständig vom jeweiligen Primärschlüssel abhängen. Die dritte Normalform ist erfüllt, da keine transitiven Abhängigkeiten zwischen Nicht-Schlüsselfeldern bestehen. Beispielsweise wird der Name eines Auszubildenden nicht zusätzlich im Bericht gespeichert, sondern über die Beziehung zur Tabelle users ermittelt.

Die relationale Struktur verbessert die Datenkonsistenz und erleichtert spätere Erweiterungen, zum Beispiel zusätzliche Statusprotokolle oder weitere Rollen.

5.1 Projektstruktur

Die Implementierung erfolgt innerhalb einer Laravel-Projektstruktur. Laravel trennt die Anwendung in verschiedene Verzeichnisse für Models, Controller, Views, Routen, Datenbankmigrationen und Konfiguration.

Wichtige Bestandteile der Projektstruktur:

Die Entscheidung für diese Struktur unterstützt eine klare Trennung der Verantwortlichkeiten. Controller verarbeiten Eingaben, Models bilden Daten ab und Views sind für die Darstellung zuständig.

5.2 Datenbankmigrationen und Models

Die Datenbankstruktur wird über Laravel-Migrationen erstellt. Migrationen bieten den Vorteil, dass die Datenbankstruktur versioniert und reproduzierbar aufgebaut werden kann.

Migration für Ausbildungsnachweise (Auszug aus database/migrations/2026_03_03_000001_create_training_reports_table.php):

Schema::create('training_reports', function (Blueprint $table) {
    $table->id();
    $table->foreignId('user_id')->constrained()->cascadeOnDelete();
    $table->foreignId('approved_by')->nullable()->constrained('users')->nullOnDelete();
    $table->date('week_start');
    $table->date('week_end');
    $table->string('status')->default('draft');
    $table->timestamp('submitted_at')->nullable();
    $table->timestamp('approved_at')->nullable();
    $table->timestamps();
});

Das zugehörige Model TrainingReport (Auszug aus app/Models/TrainingReport.php) enthält Beziehungen zu Benutzer, Einträgen und Kommentaren.

class TrainingReport extends Model
{
    protected $fillable = [
        'user_id',
        'approved_by',
        'week_start',
        'week_end',
        'status',
        'submitted_at',
        'approved_at',
    ];

    public function user()
    {
        return $this->belongsTo(User::class);
    }

    public function entries()
    {
        return $this->hasMany(ReportEntry::class);
    }

    public function comments()
    {
        return $this->hasMany(ReportComment::class);
    }
}

Die Beziehungen ermöglichen eine einfache und lesbare Abfrage der zusammengehörigen Daten. Dadurch können Berichte mit ihren Einträgen und Kommentaren gemeinsam angezeigt werden.

5.3 Berichtserfassung durch Auszubildende

Auszubildende können neue Wochenberichte erstellen. Dabei werden der Zeitraum sowie einzelne Tätigkeiten erfasst. Ein Bericht wird zunächst als Entwurf gespeichert. Solange der Bericht den Status draft oder rejected besitzt, darf der Auszubildende ihn bearbeiten.

Der grundlegende Ablauf:

1. Auszubildender meldet sich an.
2. Auszubildender öffnet die Übersicht eigener Berichte.
3. Auszubildender erstellt einen neuen Bericht.
4. Pflichtfelder werden validiert.
5. Bericht und Einträge werden gespeichert.
6. Bericht kann später bearbeitet oder eingereicht werden.

Serverseitige Validierung (Auszug aus app/Http/Controllers/ReportController.php):

$request->validate([
    'week_start' => ['required', 'date'],
    'week_end' => ['required', 'date', 'after_or_equal:week_start'],
    'entries' => ['required', 'array', 'min:1'],
    'entries.*.entry_date' => ['required', 'date'],
    'entries.*.activity' => ['required', 'string', 'max:2000'],
    'entries.*.hours' => ['required', 'numeric', 'min:0.25', 'max:24'],
]);

Die Validierung verhindert unvollständige oder fachlich ungültige Eingaben. Beispielsweise dürfen Tätigkeiten nicht leer sein und Stundenwerte müssen in einem sinnvollen Bereich liegen.

5.4 Prüf- und Freigabeworkflow

Nach dem Einreichen erhält der Bericht den Status submitted. Dadurch wird er in der Prüfungsansicht der Ausbilder sichtbar. Ausbilder können den Bericht prüfen, einen Kommentar hinzufügen und anschließend freigeben oder ablehnen.

Bei einer Freigabe wird der Status auf approved gesetzt. Zusätzlich werden der freigebende Ausbilder und der Zeitpunkt der Freigabe gespeichert. Bei einer Ablehnung wird der Status auf rejected gesetzt. Der Auszubildende kann den Bericht anschließend überarbeiten und erneut einreichen.

Die Statuswechsel sind in einer eigenen Service-Klasse ReportWorkflowService gekapselt. Dadurch bleibt die Fachlogik vom Controller getrennt und ist gezielt testbar. Beispiel für die Freigabe (Auszug aus app/Services/ReportWorkflowService.php):

public function approve(TrainingReport $report, User $approver): void
{
    if ($report->status !== 'submitted') {
        throw new DomainException('Nur eingereichte Berichte können freigegeben werden.');
    }

    $report->update([
        'status' => 'approved',
        'approved_by' => $approver->id,
        'approved_at' => now(),
    ]);

    Mail::to($report->user->email)->send(new ReportStatusMail($report, 'approved'));
}

Die Statusprüfung stellt sicher, dass fachlich ungültige Aktionen nicht ausgeführt werden. Dadurch kann beispielsweise ein Entwurf nicht direkt freigegeben werden. Unmittelbar nach dem Statuswechsel wird der zuständige Auszubildende per E-Mail informiert.

5.5 E-Mail-Benachrichtigungen

E-Mail-Benachrichtigungen werden eingesetzt, um Benutzer über relevante Statusänderungen zu informieren. Wenn ein Bericht eingereicht wird, kann der zuständige Ausbilder informiert werden. Wird ein Bericht freigegeben oder abgelehnt, wird der Auszubildende informiert.

Benachrichtigungen werden bewusst an Statusänderungen gekoppelt. Dadurch wird vermieden, dass unnötige E-Mails bei jeder kleinen Bearbeitung versendet werden.

Relevante Ereignisse:

Die technische Umsetzung erfolgt über Laravel-Mailables. Dadurch bleiben E-Mail-Templates und Versandlogik getrennt von der eigentlichen Fachlogik.

5.6 PDF-Erzeugung

Für freigegebene Ausbildungsnachweise wird eine PDF-Erzeugung umgesetzt. Der PDF-Export ist nur für Berichte mit dem Status approved vorgesehen. Dadurch wird verhindert, dass unfertige oder abgelehnte Berichte als finale Nachweise exportiert werden.

Ablauf der PDF-Erzeugung:

1. Benutzer öffnet einen freigegebenen Bericht.
2. Anwendung prüft Berechtigung und Status.
3. Daten des Berichts werden geladen.
4. Eine separate PDF-View wird gerendert.
5. Die PDF-Bibliothek erzeugt daraus eine PDF-Datei.
6. Die Datei wird als Download bereitgestellt.

Der Export ist im ExportController umgesetzt (Auszug aus app/Http/Controllers/ExportController.php). Die Statusprüfung (approved) und der Zugriffsschutz werden zentral über die Policy-Methode export erzwungen:

public function export(TrainingReport $report)
{
    $this->authorize('export', $report);

    $report->load(['user', 'entries', 'comments.author', 'approver']);

    $pdf = Pdf::loadView('reports.pdf', ['report' => $report]);

    return $pdf->download('ausbildungsnachweis_' . $report->id . '.pdf');
}

Die zugehörige Policy stellt sicher, dass ausschließlich freigegebene Berichte exportiert werden dürfen (Auszug aus app/Policies/TrainingReportPolicy.php):

public function export(User $user, TrainingReport $report): bool
{
    return $report->status === 'approved'
        && ($user->id === $report->user_id || $user->isAusbilder());
}

Für die PDF-Ausgabe wird eine eigene View (resources/views/reports/pdf.blade.php) verwendet. Dadurch kann das Layout für die Druckausgabe unabhängig von der normalen Webansicht angepasst werden.

5.7 Validierung und Fehlerbehandlung

Alle Benutzereingaben werden serverseitig validiert. Dies ist notwendig, da clientseitige Validierung im Browser umgangen werden kann. Fehlerhafte Eingaben werden mit verständlichen Fehlermeldungen an den Benutzer zurückgegeben.

Beispiele für Validierungsregeln:

• Zeitraum darf nicht leer sein.
• Enddatum darf nicht vor dem Startdatum liegen.
• Mindestens ein Tätigkeitseintrag muss vorhanden sein.
• Stunden dürfen nicht negativ sein.
• Kommentare dürfen nicht leer sein.

Neben der Validierung werden Berechtigungen konsequent geprüft. Ein Benutzer darf keine Berichte anderer Auszubildender bearbeiten. Ausbilderaktionen sind nur für Benutzer mit entsprechender Rolle möglich.

6.1 Teststrategie

Die Qualitätssicherung erfolgt durch eine Kombination aus manuellen Funktionstests und automatisierten Feature-Tests mit PHPUnit. Die automatisierten Tests sichern die fachlich kritischen Abläufe dauerhaft und reproduzierbar ab, während die manuellen Tests die Bedienung und das Zusammenspiel der Oberfläche prüfen. Der Schwerpunkt liegt auf den Kernprozessen der Anwendung:

• Anmeldung und rollenabhängige Navigation
• Erstellung eines Wochenberichts
• Bearbeitung eines Entwurfs
• Einreichung zur Prüfung
• Prüfung durch Ausbilder
• Freigabe oder Ablehnung
• E-Mail-Benachrichtigung
• PDF-Erzeugung
• Zugriffsschutz

Die Testfälle enthalten positive und negative Tests. Positive Tests prüfen erwartete Standardabläufe. Negative Tests prüfen, ob ungültige Aktionen korrekt verhindert werden.

6.2 Testumgebung

Die Tests werden in einer lokalen Entwicklungs- beziehungsweise Testumgebung durchgeführt. Verwendet werden:

• PHP 8.1 mit Laravel 10
• SQLite (Entwicklung); für automatisierte Tests In-Memory-SQLite
• Browser zur manuellen Prüfung der Oberfläche
• PHPUnit für automatisierte Feature-Tests
• Testbenutzer für die Rollen Azubi und Ausbilder
• Mail-Testkonfiguration über den Log-Mailer
• DomPDF zur Prüfung des Exports

Für die Tests werden über einen Seeder (database/seeders/DatabaseSeeder.php) reproduzierbar Benutzer und Beispieldaten angelegt. Das Passwort der Testzugänge lautet einheitlich password.

6.3 Testfälle

6.4 Testergebnisse

Die definierten Kernfunktionen konnten erfolgreich getestet werden. Neben den manuellen Funktionstests wurden zentrale Abläufe zusätzlich durch automatisierte Feature-Tests mit PHPUnit abgesichert (tests/Feature/ReportWorkflowTest.php). Diese prüfen unter anderem die Berichtserstellung, die Validierung, die Statusübergänge, den Zugriffsschutz auf fremde Berichte sowie die Einschränkung des PDF-Exports auf freigegebene Berichte.

Ausgabe des automatisierten Testlaufs (php artisan test):

PASS  Tests\Unit\ExampleTest
✓ that true is true

PASS  Tests\Feature\ExampleTest
✓ the application redirects guests to login

PASS  Tests\Feature\ReportWorkflowTest
✓ azubi kann bericht erstellen
✓ bericht ohne taetigkeit wird abgelehnt
✓ enddatum vor startdatum ist ungueltig
✓ azubi kann bericht einreichen
✓ eingereichter bericht ist nicht editierbar
✓ ausbilder kann bericht freigeben
✓ ausbilder kann bericht ablehnen
✓ entwurf kann nicht freigegeben werden
✓ azubi kann fremden bericht nicht einsehen
✓ entwurf kann nicht exportiert werden
✓ ausbilder kann kommentieren
✓ gast wird zum login geleitet

Tests:    14 passed (24 assertions)
Duration: 2.73s

Besonders wichtig war die Prüfung des Statusmodells, da hierdurch der Freigabeprozess fachlich abgesichert wird. Durch die testgetriebene Absicherung wurde sichergestellt, dass ein freigegebener Bericht nicht mehr durch Auszubildende geändert werden kann und dass PDF-Exporte ausschließlich für freigegebene Berichte möglich sind.

Die Testergebnisse bestätigen, dass das MVP für eine Demonstration und fachliche Abnahme geeignet ist. Für eine spätere Produktivsetzung wären ergänzende Tests sinnvoll, insbesondere zusätzliche Integrations- und Lasttests sowie eine ausführlichere Datenschutz- und Sicherheitsprüfung.

7.1 Funktionsumfang

Der geplante Funktionsumfang wurde im Rahmen des MVP umgesetzt. Nicht umgesetzte Erweiterungen entsprechen der definierten Projektabgrenzung und stellen keine Zielabweichung dar.

7.2 Zeitplanung

7.3 Abweichungen und Begründungen

Die Gesamtzeit von 80 Stunden wurde eingehalten. Leichte Verschiebungen ergaben sich innerhalb einzelner Phasen. Für die Implementierung der Backend-Funktionen und die PDF-Erzeugung wurde etwas mehr Zeit benötigt als geplant. Ursache hierfür war die notwendige genaue Abstimmung der Statuslogik mit den Berechtigungsprüfungen. Insbesondere die Einschränkung, dass nur freigegebene Berichte exportiert werden dürfen, musste sauber in den Workflow integriert werden.

Zeit eingespart wurde beim UI-Entwurf, da bewusst eine einfache und formularbasierte Benutzeroberfläche gewählt wurde. Dadurch konnten die Oberflächen ohne umfangreiche Mockup-Iteration umgesetzt werden. Auch bei der Dokumentation wurde Zeit eingespart, da Projektergebnisse und Entscheidungen bereits während der Umsetzung fortlaufend notiert wurden.

Die Abweichungen hatten keinen negativen Einfluss auf das Projektergebnis. Der geplante MVP-Funktionsumfang wurde erreicht.