m306-v2-tbz/Abgaben/Beepzone-Stack-Projektplanung.md

Initialisierung

Projektidee

Inventar System BeepZone Finalisieren

BeepZone : Eine Effiziente, Funktionsreiche als auch Integrierbare Inventarisierungslösung geschrieben in Rust

T.Bachmann (aka. crt / umts) - 2025-12-09

SMART Ziele

• Spezifisch:

  • Finalisierung des BeepZone Inventarsystems (Backend: MySQL + SeckelAPI, Frontend: EGUI EMO Desktop Client) für einen initialen Testlauf. Konkret umfasst dies: Client RBAC Support, minimales Client Admin Panel, alle UI Elemente im Client funktionstüchtig, Code des ganzen Stacks aufräumen, Funktionsprüfungen/Tests und saubere Dokumentation des Systems. Das ganze als Open Source Lösung welche durch andere für ihre Zwecke angepasst/verbessert werden kann.

• Messbar:

  • Erfolg messbar durch: 100% Abdeckung der definierten Kernfeatures laut Arbeitspaketen, alle 23 Arbeitspakete abgeschlossen, vollständige Dokumentation (Setup Anleitung und API Docs), erfolgreiche Deployment auf dem internen Server. Fortschritt wird durch Kanban Board und wöchentliche Checkpoints getrackt.

• Attraktiv:

  • Das Projekt ist sinnvoll und motivierend weil:
    • Intern: Es schliesst die aktuelle Lücke im Bereich Inventarisierung, reduziert unbemerkten Diebstahl und erleichtert Audits von Zimmern und deren zugewiesenen Objekten erheblich.
    • Extern: Es entsteht ein vorzeigbares Open Source Projekt das von anderen verwendet erweitert und verbessert werden kann.
    • Persönlich: Die Arbeit mit Rust und EGUI motiviert da es meinem bevorzugten Tech Stack entspricht.

• Realistisch:

  • Das Ziel ist erreichbar da:
    • Es auf bestehendem grösstenteils funktionierendem Code aufbaut (keine Neuentwicklung von Grund auf).
    • Ich als einziger Entwickler die nötige Erfahrung in Rust habe und die Codebasis kenne.
    • 10 Wochen Projektzeit mit eingeplantem Puffer für Bugs zur Verfügung stehen.
    • Vorhandene Tools (Rust, MySQL, EGUI) genutzt werden keine neuen Technologien erlernen nötig.

• Terminiert:

  • Projektstart: 2026-05-11
  • Projektabschluss: 2026-07-20 (Zimmerkontrollen beim Kunden)
  • Gesamtdauer: 51 Arbeitstage (~10 Wochen)
  • Meilensteine pro Phase im GANTT Diagramm definiert.

Risikoanalyse

Nr.	Risiko	Auswirkung	Schadensausmass	Eintrittswahrscheinlichkeit	Gegenmassnahme
R1	Prokrastination und Zeitmangel	Terminverzug, unfertige Features	Hoch	Hoch	Feste Zeitblöcke mit Timer setzen, Musik an, wichtigste Features priorisieren, Zeitpuffer einplanen
R2	Unerwartete Bugs nach Refactoring	Funktionsausfälle, Regressionen	Mittel	Mittel	Kleine Änderungen schrittweise anwenden, nach jeder Änderung testen, Git Commits granular halten
R3	Unklare Anforderungen Admin Panel	Fehlende oder falsche Funktionen	Mittel	Mittel	Frühzeitig bei zukünftigen Admins nachfragen was sie brauchen
R4	Ungenügende Testabdeckung	Bugs und Sicherheitsprobleme im Prod	Hoch	Gering	Realistische Testfälle schreiben, Seed Daten für Tests erstellen

Risikomatrix

	Gering	Mittel	Hoch
Hoch (Wahrsch.)			R1
Mittel (Wahrsch.)		R2, R3
Gering (Wahrsch.)			R4

PESTEL-Analyse

Mit LP In Person gemacht worden.

Projektauftrag Definieren

Projektbezeichnung :

Initial Finalisierung des BeepZone Inventar Systems

Projekt Kürzel :

EGUI-EMO

Projektnummer

• 72

Ausgangslage (Ist)

• BeepZone-Backend (MySQL Schema und Sekel-Proxy) : Läuft stabil, benötigt jedoch etwas Aufräumarbeiten und Dokumentation.
• BeepZone-eGUI (Desktop Client) deckt die Grundfunktionalität ab, es fehlen aber Features (zB. RBAC, Admin Panel) und es gibt Lücken bezüglich Tests und Dokumentation.

--> Kurze Beschreibung was es schon kann, was es noch braucht (beim Soll unten)

Projektergebnis (Soll)

BeepZone Stack produktionsreif machen, veröffentlichen und für internen Einsatz bereit stellen.

Teilziele

• Fehlende im UI angezeigte Funktionen implementieren.
• Fehlende Funktionen bezüglich Admin Panel und RBAC implementieren.
• Tests aller Funktionen und Feinschliff.
• Code aufräumen sowie Dokumentation und Setup Anleitung fertig stellen.

Unternehmensbedarf (Nutzen)

• Intern: Schliesst die aktuelle Lücke im Bereich Inventarisierung, reduziert unbemerkter Diebstahl, und erleichtert Audits von Zimmern und deren Zugewiesenen Objekte
• Extern: Vorzeigbares OpenSource Projekt das von anderen Verwendet werden kann bzw. erweitert und Verbessert werden kann.

Administrative Informationen

Auftragsgeber

• T.Bachmann (auf Grundes Eigeninitative)

Projektverantwortlicher

• T.Bachmann

Ziel Betrieb

• Immo

Terminvorgaben

Projektabschluss bis 2026-01-26 (Start der Zimmerkontrollen).

Planung

Projektstrukturplan (PSP)

PSP.drawio

Arbeitspakete

Allgemeine Infos (für alle Pakete gleich):

• Projektname:
  • Inventar System BeepZone Finalisieren
• Projekt Nummer:
  • 72
• Projekt Kürzel:
  • EGUI-EMO
• Datum Finalisierung:
  • 2026-01-06
• Verantwortlicher/Leiter/Mann für alles:
  • T.Bachmann

---

Arbeitspakete für 72.1 Bestandsaufnahme und Planung

Arbeitspaket: 72.1.1 Überflug Frontend

• Arbeitspaket Titel:
  • Überflug Frontend

• PSP Nummer: 72.1.1

• Arbeitspaketbeschreibung:

  • Check des BeepZone eGUI EMO Desktop Clients sowohl visuell als auch im Code um eine Liste mit Problemen und ggf. fehlenden Features zu machen

• Ziele:

  • Lücken im Frontend finden um realistische Planung zu gestallten.

• Ergebniserwartung:

  • Markdown formatierte Liste mit Referenzen zum Quellcode Abschnitten oder Visuellen Features welche in betracht gezogen werden sollten.
    

• Schnittstellen zu anderen Arbeitspaketen:

  • Input für 72.1.3 und 72.2

• Voraussetzungen für das Arbeitspaket:

  • Code Zugang
  • Lokal laufende Test Instanz SeckelAPI mit BeepZone Konfiguration
  • Developer Laptop mit VSCode und Rustup Toolchain
  • 1x Zebra Barcode Scanner

• Nicht Inhalte:

  • Änderungen/Reparaturen am Code

• Sonstiges:

  • Festgestellte wiederholdende Probleme sollten, falls Sinnvoll, Code Modulen Zugewiesen werden um Effiziente Notizen zu schaffen und duplikate zu mindern
  • Nah aneinanderliegende Probleme sollten unter einem Grösseren Task zusammengeführt werden um die Übernahme in den PSP sowie das Kanban zu vereinfachen.
  • Bei Problemen welche nur auf einem Betriebssystem auftretet so muss dies so Notiert werden.
  • Sollte hier abgelegt werden : 72-1-1_Front-End-Ueberflug.md

• Aktivitäten:

  • Alle Module der Core Engine überfliegen
  • Alle UI Views überfliegen
  • Initialisierungs und API Files im root src folder überfliegen
  • Barcode Scanner Integration Testen
  • Markdown Finalisieren

Arbeitspaket: 72.1.2 Überflug Backend

• Arbeitspaket Titel:
  • Überflug Backend

• PSP Nummer:

  • 72.1.2

• Arbeitspaketbeschreibung:

  • Check der Backend Kompenente auf Code, Config und Schema basis um eine Liste mit Problemen und ggf. fehlenden Features zu machen.

• Ziele:

  • Backend Lücken finden

• Ergebniserwartung:

  • Markdown formatierte Liste mit Referenzen zum Quellcode Abschnitten oder Visuellen Features welche in betracht gezogen werden sollten.

• Schnittstellen zu anderen Arbeitspaketen:

  • Input für 72.1.3 und 72.2

• Voraussetzungen für das Arbeitspaket:

  • Code Zugang
  • Lokal laufende Test Instanz SeckelAPI mit BeepZone Konfiguration
  • Developer Laptop mit VSCode und Rustup Toolchain

• Nicht Inhalte:

  • Änderungen am Code, Schema sowie Config Templates.

• Sonstiges:

  • Originales "Lesbares" Schema wurde durch Datenverlust verloren und existiert nur noch in "Dump Schema" Format, Aufräumarbeiten welche der lesbar/verständlich-keit dienen sind erlaubt solange diese keine Änderungen des eigentlichen Schemas mit sich bringen.
  • Stellen die in Betracht gezogen werden sollten vorerst nur in 4 Kategorien eingestuft werden :
    • Gravierendes -> Gröberes welches Nutzen, Sicherheit, Stabilität stark beinträchtigen
    • Einfach Behebbares -> Kleinigkeiten welche jedoch einen Relevanten unterschied machen.
    • Diverses -> Alles was nicht in die anderen zwei Einstufungen passt.
    • Später -> Sieht eventuel nicht schön aus (Code als auch Visuel) jedoch funktionstüchtig
  • Sollte hier abgelegt werden : 72-1-2_Back-End-Ueberflug.md

• Aktivitäten:

  • Verwendete Route Module der Backend in dessen Code prüfen
  • Config welche als Template geliefert wird prüfen
  • Schema Prüfen und ggf. etwas Aufräumen
  • Markdown Finalisieren

Arbeitspaket: 72.1.3 Planungsrelevante Dokumente Vervollständigen

• Arbeitspaket Titel:
  • Planungsrelevante Dokumente Vervollständigen

• PSP Nummer:

  • 72.1.3

• Arbeitspaketbeschreibung:

  • Dokumente wie Risikoanalyse,SWOT,PSP usw. basierend auf Notizen aus Arbeitspaketen 72.1.1 und 72.1.2 updaten/erstellen.

• Ziele:

  • Grundbausteine der Projektplanung Vervollständigt

• Ergebniserwartung:

  • Projektplanungs Abschnitte welche von Arbeitspaketen 72.1.1 sowie 72.1.2 Abhängig sind sowie Grundlagen soweit finalisiert um mit 7.1.4 Fortzufahren

• Schnittstellen zu anderen Arbeitspaketen

  • Nutzt Markdown Notiz Datein aus 72.1.2 und 72.1.2
  • Input für 72.1.4.

• Voraussetzungen für das Arbeitspaket:

  • In Schnittstellen erwähnte Markdown Notizen

• Nicht Inhalte:

  • Weitere Code/Applikations Analysen
  • Änderungen der Notizen

• Sonstiges:

  • Feedback von Projektplanungs Fachperson (in diesem Fall Modul Lehrer) holen bei ungewissheit.

• Aktivitäten:

  • SMART Ziele richtig definiert
  • PSP Diagram vervollständigen
  • Arbeitspakete (exklusiv Zeitangaben) Finalisiert
  • Netzplan Erstellt
  • GANTT Diagramm Erstellt
  • Arbeitspaket mit Zeitangaben ergänzen
  • Markdown zur Kontrolle kurz überfliegen

Arbeitspaket: 72.1.4 Planung Kontrollieren

• Arbeitspaket Titel:
  • Planung Kontrollieren

• PSP Nummer:

  • 72.1.4

• Arbeitspaketbeschreibung:

  • Planung auf Lücken Prüfen

• Ziele:

  • Sichere Planung, Risiken minimieren.

• Ergebniserwartung:

  • Projektplanung wird mich Fachperson (Modul Lehrperson) angeschaut und allfällige Lücken werden behoben.

• Schnittstellen zu anderen Arbeitspaketen:

  • Baut auf 72.1.3, Input für 72.1.5.

• Voraussetzungen für das Arbeitspaket:

  • Die im Arbeitspacket 72.1.3 finalisierte Projektplanung

• Nicht Inhalte:

  • Jegliche Arbeiten am/mit Code

• Sonstiges:

  • Prokrastinations Check !!!

• Aktivitäten:

  • Kontrolle mit Fachperson
  • Korrektur Allfälliger Lücken

Arbeitspaket: 72.1.5 Projekt in Kanban aufnehmen

• Arbeitspaket Titel:
  • Projekt in Kanban aufnehmen

• PSP Nummerr:

  • 72.1.5

• Arbeitspaketbeschreibung:

  • Projekt in Kanban aufnehmen Pakete in Tasks wandeln und dazugehörige Aktivitäten als Todos dessen Tasks erfassen.

• Ziele:

  • Übersichtliches und Familiäres Tracking von Arbeitsvortschritt.

• Ergebniserwartung:

  • Kanban Board erstellt und alle in Projektplanung erstellten Arbeitspakete als auch deren dazugehörige Aktivitäten erfasst.

• Schnittstellen zu anderen Arbeitspaketen:

  • Nutzt alles aus 72.1, Voraussetzung für Start Abschnitt 72.2.

• Voraussetzungen für das Arbeitspaket:

  • Kanban Tool (Wahrscheinlich Wekan)

• Nicht Inhalte:

  • Keine Arbeit an Features

• Aktivitäten:

  • Erstellung Kanban Board
  • Erstellen von Phasen Orientierter Arbeitspaket Tags
  • Übertragung von Arbeitspaketen und deren Aktivitäten

Arbeitspakete für 72.2 Umsetzung

Arbeitspaket: 72.2.1 Zusammenführung der History, Editor und Viewer Module

• Arbeitspaket Titel:
  • Zusammenführung der History, Editor und Viewer Module

• PSP Nummer:

  • 72.2.1

• Arbeitspaketbeschreibung:

  • History, Editor und Viewer sind momentan drei separate Module die alle irgendwie das gleiche machen aber halt anders. Das ganze als ein neues "ObjectInteractor" Modul zusammenführen. Die alten Module sind eher PoC-Qualität und haben diverse Bugs.

• Ziele:

  • Ein Modul für Asset/Object Interaktionen statt drei halbfertige
  • JSON, Bilder und Dateien sollen korrekt laden

• Ergebniserwartung:

  • Neuer ObjectInteractor der auf verschiedene Tables anwendbar ist
  • Item View funktioniert richtig (ist die komplexeste Table View)
  • Binary Files und Bildformate (gif, tiff, jpeg2000) gehen

• Schnittstellen zu anderen Arbeitspaketen:

  • Basis für Issue View (72.2.4)

• Voraussetzungen für das Arbeitspaket:

  • Bestehender Code der drei Module

• Nicht Inhalte:

  • Backend Änderungen

• Sonstiges:

  • Fokus auf Code Vereinfachung durch Modul Zusammenführung

• Aktivitäten:

  • Konzepierung des neuen ObjectInteractor Moduls
  • Grobes Umsetzung des ObjectInteractor
  • Aufruf von JSON Data Entries korrigieren
  • Support für Binary Data Entries implementieren
  • Support für Bildformate implementieren (gif, tiff, jpeg2000)

Arbeitspaket: 72.2.2 Workflows finalisieren

• Arbeitspaket Titel:
  • Workflows finalisieren

• PSP Nummer:

  • 72.2.2

• Arbeitspaketbeschreibung:

  • Halbfertige Workflows fertig machen, vor allem Replacement und die Quick Actions in der Inventory View.

• Ziele:

  • Geplante Workflows tatsächlich benutzbar machen.

• Ergebniserwartung:

  • Replacement Workflow geht
  • Quick Actions im Ribbon sind aufgeräumt und funktionieren

• Schnittstellen zu anderen Arbeitspaketen:

  • Nutzt Template Logik.

• Voraussetzungen für das Arbeitspaket:

  • Grundlegende UI Struktur.

• Nicht Inhalte:

  • Schema Änderungen.

• Sonstiges:

  • Überflüssige Aktionen welche schon anderst besser implementiert wurde ausblenden/entfernen.

• Aktivitäten:

  • Replacement Workflow fertig implementieren
  • Quick Action: "Inventarize Room" implementieren
  • Quick Action: "Add Multiple from Template" implementieren
  • Einfache Kiosk Relevante Workflows implementieren (Scan Item Only)
  • Nicht benötigte Quick Actions im Inventory Ribbon entfernen

Arbeitspaket: 72.2.3 Schema Änderungen im Client fertig Implementieren

• Arbeitspaket Titel:
  • Schema Änderungen im Client fertig Implementieren

• PSP Nummer:

  • 72.2.3

• Arbeitspaketbeschreibung:

  • Client an die letzten Schema Änderungen anpassen. Aktuell gibt es Mismatches zwischen Backend Schema und was der Client erwartet.

• Ziele:

  • Client passt zum aktuellen DB Schema und nutzt es auch richtig.

• Ergebniserwartung:

  • Joins (Supplier, Zone, Category) werden richtig angezeigt
  • Belongs To Spalte und Min Role sind drin
  • Workflow Table Definitionen stimmen mit Schema überein

• Schnittstellen zu anderen Arbeitspaketen:

  • Eng gekoppelt mit Backend Schema.

• Voraussetzungen für das Arbeitspaket:

  • Aktuelles Backend Schema

• Nicht Inhalte:

  • DB Schema Änderungen selbst

• Sonstiges:

  • Asset Generation String Übernahme in Workflows und Clone Aktionen sicherstellen

• Aktivitäten:

  • Min Role Anzeige im Asset Editor hinzufügen
  • Joins auf Inventory View reparieren (Supplier, Zone, Category)
  • Belongs To implementieren
  • Workflow definitions auf neues Schema aktualisieren

Arbeitspaket: 72.2.4 Issue View Realisieren

• Arbeitspaket Titel:
  • Issue View Realisieren

• PSP Nummer:

  • 72.2.4

• Arbeitspaketbeschreibung:

  • Issue View ist aktuell nur ein Platzhalter. Das soll eine richtige View werden.

• Ziele:

  • Issues können angeschaut und bearbeitet werden

• Ergebniserwartung:

  • Table Renderer Config für Issues
  • Editor Renderer Config für Issues
  • Ribbon UI das Sinn macht

• Schnittstellen zu anderen Arbeitspaketen:

  • Nutzt Editor Renderer aus 72.2.1.

• Voraussetzungen für das Arbeitspaket:

  • Funktionierendes Basis Framework.

• Nicht Inhalte:

  • Perfektion (soll "knapp gut genug" sein).

• Sonstiges:

  • Priorisierung der Grundfunktion.

• Aktivitäten:

  • Table Renderer für Issues implementieren
  • Viewer/Editor/History Modul für Issues integrieren
  • Ribbon UI Elemente für Issues gestalten

Arbeitspaket: 72.2.5 Reporting Funktion Umsetzen und Integrieren

• Arbeitspaket Titel:
  • Reporting Funktion Umsetzen und Integrieren

• PSP Nummer:

  • 72.2.5

• Arbeitspaketbeschreibung:

  • Reports sollen generiert und gedruckt werden können, z.B. nach Audits. Baut auf der Label Template Engine auf.

• Ziele:

  • Berichte aus dem System raus bekommen (Papier oder Digital)

• Ergebniserwartung:

  • Label Template Engine kann auch Reports
  • Label und Report Templates sind in einer View zusammen

• Schnittstellen zu anderen Arbeitspaketen:

  • Audit Workflow

• Voraussetzungen für das Arbeitspaket:

  • Label Template Engine

• Nicht Inhalte:

  • Komplexe Analytics

• Sonstiges:

  • Fokus auf Audit Berichterstattung

• Aktivitäten:

  • Label Template Engine reportfähig machen
  • Report Template View implementieren und mit Label Template View zusammenführen
  • Tabelle für Report Template Views anlegen

Arbeitspaket: 72.2.6 Kiosk Kompatibles Frontend Vervollständigen

• Arbeitspaket Titel:
  • Kiosk Frontend Vervollständigen

• PSP Nummer:

  • 72.2.6

• Arbeitspaketbeschreibung:

  • Vereinfachter Kiosk Modus für schnelles Ausleihen/Zurückgeben. Soll auch für Leute bedienbar sein die nicht so technisch affin sind.

• Ziele:

  • Einfache Bedienung für jeden
  • Grundfunktionen von Inventory, Category, Supplier, Borrowing verfügbar

• Ergebniserwartung:

  • Separate View, reduziert aufs Wesentliche, für Kiosk Betrieb

• Schnittstellen zu anderen Arbeitspaketen:

  • Input für End User Tests (72.3.4)

• Voraussetzungen für das Arbeitspaket:

  • Client Code

• Nicht Inhalte:

  • Kein komplettes Redesign der eignetlichen Views im Client

• Sonstiges:

  • Grosse Buttons, Touch freundlich und klare Anweisungen und help buttons.

• Aktivitäten:

  • Kiosk View Layout (Grosse Schrift, wenig Details) entwerfen
  • Schnelles User Switching und auto logout möglich
  • Konfigurations Option zum Starten im Kiosk Modus hinzufügen

Arbeitspaket: 72.2.7 Feinschliff und Bug Behebung

• Arbeitspaket Titel:
  • Feinschliff und Bug Behebung

• PSP Nummer:

  • 72.2.7

• Arbeitspaketbeschreibung:

  • Bugs fixen die beim Überflug und während der Umsetzung aufgetaucht sind. Alles was sich so angesammelt hat.

• Ziele:

  • Das Ding soll sauber aussehen und stabil laufen
  • RBAC soll auch im UI richtig greifen

• Ergebniserwartung:

  • Visuelle Bugs weg (Margins, Scaling, Ribbon spinnt nicht mehr rum)
  • RBAC blendet Sachen aus die der User nicht sehen soll
  • Tables werden richtig angezeigt
  • Alte/peinliche Texte sind raus

• Schnittstellen zu anderen Arbeitspaketen:

  • Abschluss der Entwicklungsphase vor dem Testen.

• Voraussetzungen für das Arbeitspaket:

  • Hauptfeatures implementiert.

• Nicht Inhalte:

  • Grosse neue Features.

• Sonstiges:

  • Siehe Liste "Einfaches" und "Wichtiges" aus Überflug, Falls Zeit vorhanden noch an echter modulisierung des Clients Arbeiten.

• Aktivitäten:

  • RBAC Implementierung im Client polieren
  • Print Preview Text Scaling reparieren
  • Window Frame Margins korrigieren
  • "Bye" Button zu "Logout" umbenennen und verhindern das er den Client Crasht
  • Help Text Popups aktualisieren
  • Verbleibende nicht implementierte Features im Ribbon UI ausblenden
  • Ungenutzte Imports und Dead Code entfernen
  • TODO und HILFE Kommentare abarbeiten

Arbeitspakete für 72.3 Testen

Arbeitspaket: 72.3.1 Tests der Client Komponente

• Arbeitspaket Titel:
  • Tests der Client Komponente

• PSP Nummer:

  • 72.3.1

• Arbeitspaketbeschreibung:

  • Frontend Module durchtesten ob alles geht wie es soll. Automatisierte Tests einbauen wo sinnvoll.

• Ziele:

  • Bugs finden und fixen

• Ergebniserwartung:

  • Liste was getestet wurde und was kaputt war
  • Unit Tests mit Rust built-in Framework

• Schnittstellen zu anderen Arbeitspaketen:

  • Basierend auf Features aus 72.2.
  • Geht über in 72.3.2.

• Voraussetzungen für das Arbeitspaket:

  • Ausführbarer Client Build für MacOS, Linux und Windows.
  • Test Backend

• Nicht Inhalte:

  • Keine End to End Tests mit echtem Backend (hier nur Mocking oder Unit).

• Sonstiges:

  • Edge Cases (leere Listen, Netzwerkfehler) besonders beachten.

• Aktivitäten:

  • Unit Tests für State Management Logik schreiben
  • GUI Komponenten isoliert prüfen (soweit möglich in Egui)
  • Input Validierung bei Formularen testen
  • Fehlerbehandlung bei API Timeouts simulieren
  • Testbericht erstellen

Arbeitspaket: 72.3.2 Tests der Gesamtfunktion

• Arbeitspaket Titel:
  • Tests der Gesamtfunktion

• PSP Nummer:

  • 72.3.2

• Arbeitspaketbeschreibung:

  • Integrationstests: Schaut ob Client und Backend zusammen funktionieren wie sie sollten.

• Ziele:

  • Daten werden gespeichert und richtig abgerufen
  • Komplexe Workflows (Ausleihe, Rückgabe usw.) laufen durch

• Ergebniserwartung:

  • Alles spielt zusammen ohne Probleme
  • Bug Liste für letzte Fixes

• Schnittstellen zu anderen Arbeitspaketen:

  • Nach 72.3.1, vor 72.3.3.

• Voraussetzungen für das Arbeitspaket:

  • Laufendes Backend (Staging/Dev) und aktueller Client.

• Nicht Inhalte:

  • Keine User Acceptance Tests (das ist 72.3.4).

• Sonstiges:

  • Testdaten sollten realistisch sein (keine "asdf" Namen).

• Aktivitäten:

  • Vollständigen "Happy Path" durchspielen (Login -> Item suchen -> Ausleihen -> Logout)
  • "Unhappy Path" testen (Falsches Passwort, Gewollt Probleme verursachen)
  • Barcode Scanner Integration mit echten Hardware Scans testen
  • Datenbank Integrität nach komplexen Transaktionen prüfen

Arbeitspaket: 72.3.3 Sicherheits und Performance Tests

• Arbeitspaket Titel:
  • Sicherheits und Performance Tests

• PSP Nummer:

  • 72.3.3

• Arbeitspaketbeschreibung:

  • Checken ob es offensichtliche Sicherheitslücken gibt und ob das System performant genug ist.

• Ziele:

  • Keine dummen Sicherheitslöcher
  • UI bleibt responsive auch bei vielen Daten

• Ergebniserwartung:

  • Kurzer Security Check Bericht
  • Performance Messungen

• Schnittstellen zu anderen Arbeitspaketen:

  • Nach 72.3.2.

• Voraussetzungen für das Arbeitspaket:

  • Tools (Wireshark, Browser DevTools, Benchmark Scripts).

• Nicht Inhalte:

  • Keine Penetration Tests auf Enterprise Niveau.

• Sonstiges:

  • Fokus auf typische Angriffsvektoren (SQL Injection, XSS, Privileg Escalation).

• Aktivitäten:

  • API Endpoints auf Autorisierungs Prüfungen testen (Kann User X Admin Dinge tun?)
  • Input Felder auf Injection Anfälligkeit prüfen
  • Ladezeiten bei grossen Listen (zB 1000+ Items) messen
  • Speicherverbrauch des Clients über längere Zeit beobachten (Memory Leaks)
  • Netzwerk Traffic auf unnötige Datenübertragung analysieren

Arbeitspaket: 72.3.4 End User Tests

• Arbeitspaket Titel:
  • End User Tests

• PSP Nummer:

  • 72.3.4

• Arbeitspaketbeschreibung:

  • Echte Leute (oder so) das System benutzen lassen und schauen wo sie hängen bleiben.

• Ziele:

  • Feedback kriegen ob die UI verständlich ist
  • Wo stolpern Leute?

• Ergebniserwartung:

  • Liste mit Usability Problemen und Vorschlägen
  • Grünes Licht für Release

• Schnittstellen zu anderen Arbeitspaketen:

  • Letzter Schritt vor Doku & Abschluss.

• Voraussetzungen für das Arbeitspaket:

  • Testpersonen (Mitschüler, Freunde).
  • Bereitgestellte Testumgebung.

• Nicht Inhalte:

  • Keine technischen Debugging Sessions.

• Sonstiges:

  • "Think Aloud" Methode bei den Tests anwenden.

• Aktivitäten:

  • Test Szenarien für User vorbereiten (Aufgabenstellung)
  • User bei der Durchführung beobachten (nicht helfen!)
  • Feedback und Schwierigkeiten notieren
  • Kurzes Interview nach dem Test durchführen
  • Ergebnisse auswerten und ggf. Quick Fixes erstellen

Arbeitspakete für 72.4 Dokumentieren

Arbeitspaket: 72.4.1 Back End Dokumentation

• Arbeitspaket Titel:
  • Back End Dokumentation

• PSP Nummer:

  • 72.4.1

• Arbeitspaketbeschreibung:

  • Technische Doku fürs Backend schreiben (API, Datenbank). Damit später jemand anderes auch noch durchblickt.

• Ziele:

  • Andere Entwickler können verstehen was Sache ist

• Ergebniserwartung:

  • Markdown Files im Repo oder Wiki

• Schnittstellen zu anderen Arbeitspaketen:

  • Parallel zu 72.4.2.

• Voraussetzungen für das Arbeitspaket:

  • Finaler Code Stand.

• Nicht Inhalte:

  • Keine Endanwender Doku.

• Sonstiges:

  • Automatisch generierte Docs wo möglich nutzen (rustdoc, swagger).

• Aktivitäten:

  • API Komplett beschreiben (Request/Response)
  • Datenbankschema dokumentieren
  • Environment Variablen und Konfiguration erklären
  • Deployment Abhängigkeiten auflisten

Arbeitspaket: 72.4.2 Front End Dokumentation

• Arbeitspaket Titel:
  • Front End Dokumentation

• PSP Nummer:

  • 72.4.2

• Arbeitspaketbeschreibung:

  • Technische Doku für den Client. Wie ist der Code aufgebaut, wie funktionieren die Module.

• Ziele:

  • Leute die neue Module bauen wollen sollen sich reindenken können

• Ergebniserwartung:

  • Code Struktur und UI Konzepte dokumentiert

• Schnittstellen zu anderen Arbeitspaketen:

  • Parallel zu 72.4.1.

• Voraussetzungen für das Arbeitspaket:

  • Finaler Client Code.

• Nicht Inhalte:

  • Keine Bedienungsanleitung.

• Sonstiges:

  • Screenshots zur Erklärung von UI Komponenten nutzen.

• Aktivitäten:

  • Modul Struktur des Frontends aufzeichnen
  • Wichtige UI Komponenten und deren Parameter dokumentieren
  • Build Prozess und Voraussetzungen (Rust) festhalten
  • Bekannte Limitationen und Bugs auflisten

Arbeitspaket: 72.4.3 Setup und Benutzeranleitung

• Arbeitspaket Titel:
  • Setup und Benutzeranleitung

• PSP Nummer:

  • 72.4.3

• Arbeitspaketbeschreibung:

  • Handbuch für Admins (wie installiert man das) und normale User (wie bedient man das).

• Ziele:

  • Leute können das System selbst aufsetzen und benutzen ohne ständig fragen zu müssen

• Ergebniserwartung:

  • PDF oder Markdown Handbuch

• Schnittstellen zu anderen Arbeitspaketen:

  • Konsolidiert Infos aus 72.4.1 und 72.4.2 für Laien.

• Voraussetzungen für das Arbeitspaket:

  • Funktionierendes System zum Screenshots machen.

• Nicht Inhalte:

  • Keine internen Code Details.

• Sonstiges:

  • Verständliche Sprache, Schritt für Schritt Anleitungen.

• Aktivitäten:

  • Quick Start Guide für die Installation schreiben
  • Bebilderte Anleitung für Standard Workflows (Ausleihe, Rückgabe)
  • Admin Guide (User anlegen, Items importieren)
  • Troubleshooting FAQ erstellen
  • Anleitung Korrekturlesen lassen

Arbeitspaket: 72.4.4 Code Kommentare von Fluchwörtern befreien

• Arbeitspaket Titel:
  • Code Kommentare von Fluchwörtern befreien

• PSP Nummer:

  • 72.4.4

• Arbeitspaketbeschreibung:

  • Frust Kommentare und andere schöne Wörter aus dem Code entfernen. Soll ja Open Source werden.

• Ziele:

  • Code der vorzeigbar ist

• Ergebniserwartung:

  • Sauberer Code ohne peinliche Kommentare

• Schnittstellen zu anderen Arbeitspaketen:

  • Letzter Schritt vor Release.

• Voraussetzungen für das Arbeitspaket:

  • Zugriff auf alle Sourcen.

• Nicht Inhalte:

  • Keine Funktionsänderungen mehr.

• Sonstiges:

  • Search & Replace ist dein Freund.

• Aktivitäten:

  • Globale Suche nach Blacklist Wörtern (Flüche, Slang)
  • Unpassende TODOs entfernen oder umschreiben
  • Auskommentierten "Müll" Code löschen
  • Rechtschreibung in öffentlichen Doc Strings prüfen
  • Commit Messages prüfen (falls History rewrite geplant)

Arbeitspakete für 72.5 Abschluss

Arbeitspaket: 72.5.1 Beta Release auf Git erstellen

• Arbeitspaket-Titel:
  • Beta Release auf Git erstellen

• PSP-Nr.:

  • 72.5.1

• Arbeitspaketbeschreibung:

  • Release Tag machen und Binaries/Source auf Git hochladen.

• Ziele:

  • Entwicklung ist offiziell durch
  • Es gibt was zum Runterladen

• Ergebniserwartung:

  • Git Tag gesetzt, Release Notes, Binaries hochgeladen

• Schnittstellen zu anderen Arbeitspaketen:

  • Das Ende der Fahnenstange.

• Voraussetzungen für das Arbeitspaket :

  • Alle Tests grün, Doku fertig.

• Nicht-Inhalte:

  • Kein Deployment auf Server (das ist separater Schritt/Task).

• Sonstiges:

  • Ein kleiner Feier-Moment.

• Aktivitäten:

  • Versionsnummern in Config Dateien (Cargo.toml) erhöhen
  • CHANGELOG.md aktualisieren
  • Git Tag setzen (z.B. v1.0.0-beta) und pushen
  • Release auf Plattform (Gitea/GitHub/GitLab) erstellen
  • Binaries kompilieren und anhängen

Arbeitspaket: 72.5.2 Rückblick auf gelerntes und Zukünftiges

• Arbeitspaket Titel:
  • Rückblick auf gelerntes und Zukünftiges

• PSP Nummer:

  • 72.5.2

• Arbeitspaketbeschreibung:

  • Schauen was gut lief und was nicht. Was kommt als nächstes?

• Ziele:

  • Aus Fehlern lernen
  • Grobe Ideen für v2.0

• Ergebniserwartung:

  • Kurzer Abschlussbericht / Lessons Learned

• Schnittstellen zu anderen Arbeitspaketen:

  • Bezieht sich auf das gesamte Projekt.

• Voraussetzungen für das Arbeitspaket:

  • Projektabschluss.

• Nicht Inhalte:

  • Keine Entwicklung.

• Sonstiges:

  • Ehrlich zu sich selbst sein.

• Aktivitäten:

  • Soll/Ist Vergleich der Zeitplanung durchführen
  • Analyse der aufgetretenen Risiken
  • Feedback von Nutzern konsolidieren
  • Liste mit Ideen für "BeepZone 2.0" erstellen
  • Persönliches Fazit schreiben

Arbeitspaket: 72.5.3 Deployment auf internem Server

• Arbeitspaket Titel:
  • Deployment auf internem Server

• PSP Nummer:

  • 72.5.3

• Arbeitspaketbeschreibung:

  • BeepZone Stack auf dem internen Server aufsetzen für produktiven Einsatz.

• Ziele:

  • System läuft produktiv und ist nutzbar

• Ergebniserwartung:

  • Laufende Instanz auf Server

• Schnittstellen zu anderen Arbeitspaketen:

  • Nach 72.5.1 (Release muss existieren)

• Voraussetzungen für das Arbeitspaket:

  • Fertiges Release
  • Serverzugang

• Nicht Inhalte:

  • Weitere Entwicklung

• Sonstiges:

  • Docker oder direkt je nach Serverumgebung

• Aktivitäten:

  • Server vorbereiten (MySQL, Dependencies)
  • Backend deployen und konfigurieren
  • Initialdaten laden
  • Client Binaries bereitstellen
  • Kurzer Funktionstest auf Prod