BeepZone : Eine sehr Effiziente, Funktionsreiche als auch Integrierbare Inventarisierungslösung geschrieben in Rust
T.Bachmann (aka. crt / umts) - 2025-12-09
- Spezifisch:
- Finalisierung des BeepZone Inventarsystems (Backend: MySQL + SeckelAPI, Frontend: EGUI-EMO Desktop Client) für einen initialen Testlauf. Implementation/Umsetzung von mindestens folgendem : 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 welches durch andere für Ihre Zwecke angepasst/verbessert werden kann.
- Messbar:
- Erfolg messbar durch: 100% Abdeckung der Kernfeatures (z.B. mindestens 5 neue Funktionen im Admin Panel implementiert), mindestens 80% Code-Coverage durch Tests, vollständige Dokumentation (mindestens 20 Seiten Setup-Anleitung und API-Docs) und erfolgreiche Deployment auf dem internen Server. Fortschritt tracken durch wöchentliche Checkpoints. {Meh}
- Ausführbar:
- Das Ziel ist erreichbar, da es auf bestehendem Code aufbaut (Backend läuft schon grossteils stabil), ich als einziger Entwickler habe Erfahrung in Rust und Zeit bis das ganze um zu Setzen bis Deadline. Keine bekannten unmögliche Sprünge, wie z.B. aus dem Nix von Grund auf das System bauen, es geht nur um die Initiale Finalisierung, nicht um Neuentwicklung. Zwar Anspruchsvoll, aber machbar ohne externe Hilfe.
- Realistisch:
- Passt zu meinem Ressourcenmanagement: Keine Überstunden nötig, da es in 5 Wochen geplant ist mit Puffern für Bugs. Nutzt vorhandene Tools (Rust, MySQL), und internen Bedarf deckt es realistisch ab (z.B. weniger Diebstahl durch bessere Tracking). Kein Traumziel wie globaler Marktstandart, sondern fokussiert auf Individualisierten Einsatz und Open Source Release.
- Terminiert:
- Projektabschluss bis 2026-01-12, mit Meilensteinen pro KW (siehe GANTT im Planung-Abschnitt). Start: 2025-12-09, Ende: Fix vor Zimmerkontrollen.
Leifaden/Info:
Falls eine Fehlermeldung erzeugt wurde, muss das System dem Administrator die Möglichkeit bieten, die erzeugte Fehlermeldung auf den Netzwerkdrucker zu drucken.
Wenn ein Nutzer innerhalb eines Ausleihvorgangs einen Bibliothekskunden auswählt, soll das Bibliothekssystem diesem Nutzer
den Namen des Kunden
die Adresse des Kunden und
den augenblicklichen Kontostand des Kunden anzeigen
An jedem ersten Tag eines Monats um 08:00 Uhr und unter der Bedingung, dass der Administrator die automatische Backup-Funktion aktiviert hat, soll das System die Daten des Bilothekssystems, die seit dem letzten Backup verändert wurden, automatisch archivieren (Delta-Sicherungsstrategie).
Falls ein Bibliothekskunde weniger als 10 Objekte entliehen hat, soll das Bibliothekssystem diesem Bibliothekskunden die Möglichkeit bieten, Leihobjekte online zu reservieren.
Wenn das Bibliothekssystem in Betrieb ist, soll das Bibliothekssystem fähig sein, Daten für ein Software-Update von einem zentralen Administrationsrechner über das lokale Netzwerk zu empfangen.
Das Bibliothekssystem soll ausschliesslich dem Administrator die Möglichkeit bieten, neue Leihobjekte von externen Datenmedien in den Datenbestand des Bibliothekssystems zu importieren.
Falls während des Importierens ein semantscher oder syntaktischer Datenfehler auftritt, soll das Bibliothekssystem dem Administrator für einzelne zu importierende neue Leihobjekte den jeweiligen Fehler (Fehlernummer und Fehlerbeschreibung) auf dem Bildschirm und auf dem Drucker ausgeben.
Wenn das Bibliothekssystem Daten neu eingegebener Bibliothekskunden oder neuer Leihgegenstände vom benachbarten Bibliothekssystem empfangen hat, soll das Bibliothekssystem die empfangenen Daten permanent speichern.
Todo
| Risiko |
Auswirkung |
Wahrscheinlichkeit |
Gegenmassnahme |
| Prokastination und Zeitmangel |
Terminverzug |
Hoch |
Wichtigste Features Priorisieren und Zeitpuffer einplanen |
| Unerwartete Bugs nach Code Aufräumen |
Funktionsausfälle |
Mittel |
Kleine Änderunen Schrittweise anwenden und immer testen |
| Unklare Anforderungen im Admin Panel |
Fehlende Funktionen |
Mittel |
Bei zukünftigen Administratoren nach gewünschtem fragen |
| Nicht genug Tests |
Bugs und Sicherheitsprobleme |
Niedrig |
Realistische Testfälle machen und Seed Daten erstellen |
-> Schadensausmass als spalte hinzufügen
-> Risikomatrix Kompatibel Machen (X Achse : Schadenshöhe, Y Achse : Eintrittswahrscheinlichkeit, Je 3 Stufen, Gering, Mittel, Hoch)
-> Punkte Nummerieren
-> Punkt 1: Zeit Start und Zeit Ende definieren, Wecker/Timer Setzen und dann mal schauen wie weit ich der Zeit gekommen bin. Musik
-> Punkt 2: Besser Formulieren,
Todo (Abklären ob überhaupt nötig evt?)
Leitfaden/Info:
Bei der PESTEL-Analyse (auch PESTLE-Analyse) ist man bestrebt, die externen Einflussfaktoren, die auf ein Unternehmen einwirken, zu identifizieren, zu bewerten und daraus strategische Entscheidungen abzuleiten. Externe Einflussfaktoren gehören der sogenannten Makro-Umwelt an, der das jeweilige Unternehmen ausgesetzt ist, ohne sie jedoch maßgeblich beeinflussen zu können. Die PESTEL-Analyse konzentriert sich dabei auf sechs übergeordnete Einflussbereiche, deren Anfangsbuchstaben das Akronym PESTEL bilden:
Political (politisch)
Economic (ökonomisch)
Social (soziokulturell)
Technological (technologisch)
Ecological (ökologisch-geografisch)
Legal (rechtlich)
Das Resultat einer PESTEL-Analyse ist stets eine systematische und wertende Beschreibung des Marktes. Das Ziel der PESTEL-Analyse besteht dabei darin, die verschiedenen Risiken, Chancen und Herausforderungen der makroökonomischen Rahmenbedingungen herauszuarbeiten und darauf basierend die strategische Unternehmensführung anzupassen. Die PESTEL-Analyse ist damit ein ausgesprochen hilfreiches Tool für kontrolliertes Unternehmenswachstum.
Todo (Eigentlich redundant da gemacht in person mit LP)
Projektauftrag definieren -> (Gemacht)
Projektanforderungen analysieren -> (Soweit glaubs auch gemacht?)
= Pflichtenheft erstellen (WIE man die Wünsche umsetzen wird) -> (Muss ich noch Anschauen)
Organigramm erstellen (Laut LP bei mir nicht notwendig)
Stakeholderanalyse -> (???)
Phasenmodell wählen -> (Fue-Projekt, Org.Projekt, Invest.Projekt, Softwareprojekt -> Das Phasenmodell ist Bestandteil eines Vorgehensmodells, Kanban <3)
Initial Finalisierung des BeepZone Inventar Systems
EGUI-EMO
- 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)
BeepZone-Stack produktionsreif machen, veröffentlichen und für internen Einsatz bereit stellen.
- 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.
- 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.
- T.Bachmann (auf Grundes Eigeninitative)
Projektabschluss bis 2026-01-26 (Start der Zimmerkontrollen).
(Hier Kommt das referenz zu Drawio PSP, Später)
Allgemeine Infos (für alle Pakete gleich):
- Projektname: Inventar System BeepZone Finalisieren
- Projekt Nummer: 72
- Projekt Kürzel: EGUI-EMO
- Datum Arbeitspaket Finalisierung: 2026-01-06
- Verantwortlicher/Leiter/Mann für alles: T.Bachmann
Arbeitspaket Titel: Überflug Frontend
PSP Nummer: 72.1.1
Arbeitspaketbeschreibung: Kurzer Check des BeepZone-eGUI EMO Desktop Clients visuell und im Code und eine Liste mit fehlenden Features, Problemen und Notizen machen
Ziele: Lücken im Frontend finden um Planung zu machen.
Ergebniserwartung: Notizliste
Schnittstellen zu anderen Arbeitspaketen: Input für 72.1.3 und 72.2
Voraussetzungen für das Arbeitspaket: Code Zugang und VSCode + RustUp Setup
Nicht Inhalte: Keine Änderungen am Code
Sonstiges: Priorisiere eindeutige Probleme
Arbeitspaket Titel: Überflug Backend
PSP Nummer: 72.1.2
Arbeitspaketbeschreibung: Check der SeckelAPI und des Beepzone MySQL Schemas, evt. Liste mit fehlenden Teilen und Problemen machen.
Ziele: Backend Lücken finden
Ergebniserwartung: Notizliste für Planung
Schnittstellen zu anderen Arbeitspaketen: Input für 72.1.3 und 72.2
Voraussetzungen für das Arbeitspaket: Backend Server Zugang und VSCode RustUp Setup.
Nicht Inhalte: Keine Fixes
Arbeitspaket Titel: Planungsrelevante Dokumente Vervollständigen
PSP Nummer: 72.1.3
Arbeitspaketbeschreibung: Dokumente wie Risikoanalyse SWOT usw. basierend auf Überflügen updaten.
Ziele: Vollständige Planungsdoks für den Rest des Projekts.
Ergebniserwartung: Aktualisierte Markdown Datei.
Schnittstellen zu anderen Arbeitspaketen Nutzt Notizen aus 72.1.1/72.1.2, Input für 72.1.4.
Voraussetzungen für das Arbeitspaket: Vorhandene Markdown.
Nicht Inhalte: Keine neuen Analysen
Sonstiges: Kurz Halten.
Arbeitspaket Titel: Planung Kontrollieren
PSP Nummer: 72.1.4
Arbeitspaketbeschreibung: Planung prüfen auf Lücken, Zeitpuffer einbauen.
Ziele: Sichere Planung ohne Risiken.
Ergebniserwartung: Geprüfte Planung.
Schnittstellen zu anderen Arbeitspaketen: Baut auf 72.1.3, Input für 72.1.5.
Voraussetzungen für das Arbeitspaket: Halt so Fertige Doks.
Nicht Inhalte: Prefferabel: Noch Kein Start der Umsetzung.
Sonstiges: Prokrastinations Check !!!
Arbeitspaket Titel: Projekt in Kanban aufnehmen
PSP Nummerr: 72.1.5
Arbeitspaketbeschreibung: Projekt in Kanban aufnehmen Pakete in Tasks wandeln, Checklisten machen.
Ziele: Übersichtliches Tracking
Ergebniserwartung: Kanban Board ready
Schnittstellen zu anderen Arbeitspaketen: Nutzt alles aus 72.1, Start für 72.2.
Voraussetzungen für das Arbeitspaket: Kanban Tool (Wahrscheinlich Wekan)
Nicht Inhalte: Keine Arbeit an Features
Arbeitspaket Titel: Item History View Vervollständigen
PSP Nummer.: 72.2.1
Arbeitspaketbeschreibung: Vollständige Item History Ansicht im Frontend.
Ziele: Funktionale View für Item History.
Ergebniserwartung: Lauffähigee History Komponent.
Schnittstellen zu anderen Arbeitspaketen: Aus Notizen 72.1.1, Link zu 72.2.5
Voraussetzungen für das Arbeitspaket: Rust/EGUI.
Nicht-Inhalte: Noch keine Arbeit an Kiosk Overlay.
Sonstiges: KISS (Keep it simple stupid)
Arbeitspaket Titel: Audit Workflow polieren
PSP Nummer: 72.2.2
Arbeitspaketbeschreibung: Audit Workflow im Frontend abschliessen und UI polieren.
Ziele: Fertiger Workflow für Audits
Ergebniserwartung: Polierter Code
Schnittstellen zu anderen Arbeitspaketen: Zu 72.2.1, Input für Tests
Voraussetzungen für das Arbeitspaket: Bestehender Code
Nicht Inhalte: Keine neuen Features
Sonstiges: Fokus auf Usability
Arbeitspaket Titel: Item Replacement und Relationship implementieren
PSP Nummer: 72.2.3
Arbeitspaketbeschreibung: System für Item Replacement und Relationships bauen
Ziele: Logisches System für Ersetzungen und Verbindungen
Ergebniserwartung: Implementierter Code/Feature
Schnittstellen zu anderen Arbeitspaketen: Zu Backend, Link zu 72.2.1.
Voraussetzungen für das Arbeitspaket: Notizen
Nicht-Inhalte: Kein Polieren
Sonstiges: Sollte robust sein
Arbeitspaket Titel: RBAC Support im Frontend polieren
PSP Nummer: 72.2.4
Arbeitspaketbeschreibung: RBAC im Frontend finalisieren
Ziele: Für User Rolle nicht funktionelle Views und Features verstecken
Ergebniserwartung: Poliertes RBAC im Client
Schnittstellen zu anderen Arbeitspaketen: Zu Backend;, Input für 72.3.
Voraussetzungen für das Arbeitspaket: Halbfertiger Code
Nicht-Inhalte: Keine extras oder Client Admin Panele
Sonstiges: Bitte Testen auf Prod Tauglichkeit
Arbeitspaket Titel: Issue View und Reporting fertig implementieren
PSP Nummer: 72.2.5
Arbeitspaketbeschreibung: Issue View und Reporting fertig machen.
Ziele: Vollständige Views für Issues und Reports.
Ergebniserwartung: Funktionale Komponente
Schnittstellen zu anderen Arbeitspaketen: Zu 72.2.2, Für Non Techpowerusers.
Voraussetzungen für das Arbeitspaket: Grobes Design Konzept
Nicht-Inhalte: Keine Analytics extras
Sonstiges: Fokus auf Drucksystem.
Arbeitspaket Titel: Kiosk Kompatibles Frontend Vervollständigen
PSP Nr.: 72.2.6
Arbeitspaketbeschreibung: Vereinfachtes Kiosk Overlay für nicht so schlaues IT Staff bauen
Ziele : Einfache UI für Basisnutzung
Ergebniserwartung: Fertiges Overlay
Schnittstellen zu anderen Arbeitspaketen: Aus Feedback Notizen, Zu 72.3.4.
Voraussetzungen für das Arbeitspaket: Client Code?
Nicht Inhalte: Kein Full on Redesign
Sonstiges: Design sollte leicht anpassbar sein (Evt. reimplementation früher entwickelter deprecated JSONderuloUI Language)
Arbeitspaket Titel: Client Code Aufräumen
PSP Nummer.: 72.2.7
Arbeitspaketbeschreibung: Frontend Code bisschen säubern grottenhässliches Ghüdder entfernen
Ziele: Sauberer Code als zuvor
Ergebniserwartung: Aufgeräumteres Repo
Schnittstellen zu anderen Arbeitspaketen: Nach allen Umsetzungen, Für 72.4.3.
Voraussetzungen für das Arbeitspaket: Fertige Features
Nicht-Inhalte: Kein anfangen mit Backend Aufräumen
Arbeitspaket Titel: Tests der Client Komponente
PSP Nummer: 72.3.1
Arbeitspaketbeschreibung: Prüfung/Testimplementation der einzelnen Frontend Teile
Ziele: Bugs im Client finden mit so min. 80% Abdeckung
Ergebniserwartung: Test Liste und liste mit danach gebrauchten Fixes
Schnittstellen zu anderen Arbeitspaketen: Aus 72.2, Input für 72.3.2.
Voraussetzungen für das Arbeitspaket: Rust Tests
Nicht Inhalte: Keine Gesamt Tests
Sonstiges: Ganze mit Beispiel Daten machen für Real World applicability.
Arbeitspaket Titel: Tests der Gesamtfunktion
PSP Nummer: 72.3.2
Arbeitspaketbeschreibung: Check ob Client und Backend happy mit einander zusammenpassen und Client als gesamtes Funktioniert
Ziele: Ganzer Ablauf prüfen
Ergebniserwartung: Bericht mit Fixlist
Schnittstellen zu anderen Arbeitspaketen: Nach 72.3.1
Voraussetzungen für das Arbeitspaket: Lauffähiges System
Nicht Inhalte: Noch kein User Feedback
Sonstiges: Möglichst reale Szenarien verfolgen.
Arbeitspaket Titel: Sicherheits und Performance Tests
PSP Nummer: 72.3.3
Arbeitspaketbeschreibung: Prüfung auf Sicherheits und Performance Lücken
Ziele (Welche Leistungen sollen erbracht werden?): Ein Sexy Sicheres und schnelles System
Ergebniserwartung: Problem Liste.
Schnittstellen zu anderen Arbeitspaketen: Nach 72.3.2, Für Doks und so.
Voraussetzungen für das Arbeitspaket Ressourcen: Tools und so
Nicht Inhalte: Keine Funktions Tests
Sonstiges: Intern fokussiert
Arbeitspaket Titel: End User Tests
PSP Nummer: 72.3.4
Arbeitspaketbeschreibung: Tests mit Nutzern
Ziele: Feedback zu Anpassungen
Ergebniserwartung: Feedback Notizen
Schnittstellen zu anderen Arbeitspaketen: Nach Tests, Für 72.5.
Voraussetzungen für das Arbeitspaket: System und Zeit zukünftiger User
Nicht Inhalte: Keine Techpoweruser Tests (Also somit eigentlich tests meiner Seits)
Sonstiges: 1 bis 2 Sessions
Arbeitspaket Titel: Back End Dokumentation
PSP Nummer: 72.4.2
Arbeitspaketbeschreibung: Docs für Backen schreiben.
Ziele: Klare Backend Nutzungs als auch grobe Code Doks.
Ergebniserwartung: Dokumentation zu Bakend
Schnittstellen zu anderen Arbeitspaketen: Aus 72.2, Zu 72.4.3.
Voraussetzungen für das Arbeitspaket: Backend Code und Laufendes Backend System
Nicht Inhalte: Kein Frontend Doks
Arbeitspaket Titel: Front End Dokumentation
PSP Nummer: 72.4.2
Arbeitspaketbeschreibung: Docs für Frontend schreiben.
Ziele: Klare Frontend Nutzungs und grobe Code Doks.
Ergebniserwartung: Dokumentation zu Frontend
Schnittstellen zu anderen Arbeitspaketen: Aus 72.2, Zu 72.4.3.
Voraussetzungen für das Arbeitspaket: Frontend Code und Laufender Stack
Nicht Inhalte: Kein Backend Doks
Arbeitspaket Titel: Setup und Benutzeranleitung
PSP Nummer: 72.4.3
Arbeitspaketbeschreibung: Anleitung für Setup und Nutzung schreiben.
Ziele: Einfaches jedoch ausführliches Guide für User
Ergebniserwartung: Vollständige Anleitung
Schnittstellen zu anderen Arbeitspaketen: Aus Tests, Für Release.
Voraussetzungen für das Arbeitspaket: System Kenntnisse welche ich habe.
Nicht Inhalte: Keine Code Docs
Arbeitspaket Titel: Code Kommentare von Fluchwörtern befreien
PSP Nummer: 72.4.4
Arbeitspaketbeschreibung: Code Kommentare säubern und unprofessionelles entfernen.
Ziele: Saubere Kommentare
Ergebniserwartung: Bereinigter Code
Schnittstellen zu anderen Arbeitspaketen: Aus 72.2.7, Für Open Source Release <3
Voraussetzungen für das Arbeitspaket: Repos
Nicht Inhalte: Kein Neuschreiben von Code
Arbeitspaket-Titel: Beta Release auf Git erstellen
PSP-Nr.: 72.5.1
Arbeitspaketbeschreibung: Beta Version auf Git pushen.
Ziele (Welche Leistungen sollen erbracht werden?): Erster Tagged Release
Ergebniserwartung: Git Release.
Schnittstellen zu anderen Arbeitspaketen: Nach Doks, Für Einsatz
Voraussetzungen für das Arbeitspaket : Scheinbar Fertiges System
Nicht-Inhalte: Kein Final non-Beta Release.
Arbeitspaket Titel: Rückblick auf gelerntes und Zukünftiges
PSP Nummer: 72.5.2
Arbeitspaketbeschreibung: Review des Projekts, "Lessons Learned" notieren
Ziele: Abschluss Notizen für Zukunft.
Ergebniserwartung: Review Doks.
Schnittstellen zu anderen Arbeitspaketen: Gesamtes Projekt.
Voraussetzungen für das Arbeitspaket: Alles
Nicht Inhalte: Keine neuen Features oder so.
Sonstiges: Für nächste Projekte und später zu implementierende Features.
(Hier Kommt das referenz Drawio Netzplan, Später)
--> Placeholder für Echtes Diagram Später
--> Meilensteine Tabelle Separat (mit festen Daten) beifügen (unten)
| Woche / Zeitraum |
Phase |
Kernaufgaben |
| KW50 (09.12.–15.12.2025) |
Bestandsaufnahme und Planung |
- Repo grob aufräumen
- Notizen erstellen
- Planung grob finalisieren |
| KW51 (16.12.–22.12.2025) |
Umsetzung und Planung |
- Fehlende Features implementieren
- Planung vervollständigen |
| KW52 (23.12.–29.12.2025) |
Umsetzung und Planung |
- Fehlende Features implementieren
- Planung vervollständigen |
| KW01 (30.12.2025–05.01.2026) |
Umsetzung |
- Fehlende Features implementieren
- Planung vervollständigen |
| KW02 (06.01.–11.01.2026) |
Umsetzung |
- Fehlende Features implementieren
- Code polieren |
| KW03 (12.01.–18.01.2026) |
Testen und Bugfixes |
- Tests für Features durchführen
- Leistungstests
- Bugreparaturen basierend auf Test Ergebnissen |
| KW04 (19.01.–25.01.2026) |
Dokumentieren |
- API Dokumentatieren
- Manuals schreiben
- Entwickler Notes
|
| 26.01.2026 |
Abschluss |
- Qualitätschecks
- Publizikation Beta Release Tags
- Aufsetzen Prod Instanz auf Server |
