path: root/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