diff --git a/arbeitskacheln/00_index.md b/arbeitskacheln/00_index.md index 0b66536..b75dc3b 100644 --- a/arbeitskacheln/00_index.md +++ b/arbeitskacheln/00_index.md @@ -20,6 +20,9 @@ Kachel-Template und Nutzer-Vorgaben zur Methodik: siehe Memory 4. **Person/Benutzer-Trennung (PERS-001/002):** MABEA hat aktuell nur `Benutzer` (Login=Person verschmolzen). Echte Trennung ist ein Datenmodell-Bruch — Umfang vorher separat abschätzen, bevor verbindlich eingeplant. +5. **UNKNOWN-Readiness-Zustand (READY-002):** MABEA zählt ein nie kontrolliertes Objekt aktuell + als „einsatzbereit" (keine Kriterien verletzt, aber auch nie geprüft). Fachlich zu klären, + ob das gewollt ist oder ein eigener UNKNOWN-Zustand eingeführt werden soll. ## Epic-Übersicht @@ -218,6 +221,7 @@ eigenes Modul (MAINT-\*, MABEA hat nur Prüfung, keine Wartung)**. | `10_maintenance.md` | MAINT-001 … MAINT-006 (vollständig) | | `11_defects.md` | DEFECT-001 … DEFECT-005 (vollständig) | | `12_personnel.md` | PERS-001 … PERS-007 (vollständig) | +| `13_readiness.md` | READY-001 … READY-005 (vollständig) | -Restliche Kacheln (READY, DOC, MOBILE, OPS): nur Zeile in der Tabelle oben, Details folgen -nach Freigabe. +Restliche Kacheln (DOC, MOBILE, OPS): nur Zeile in der Tabelle oben, Details folgen nach +Freigabe. diff --git a/arbeitskacheln/13_readiness.md b/arbeitskacheln/13_readiness.md new file mode 100644 index 0000000..e3955d4 --- /dev/null +++ b/arbeitskacheln/13_readiness.md @@ -0,0 +1,128 @@ +# Epic 13 — Readiness + +Details zu READY-001 … READY-005 (vollständig). + +--- + +## READY-001 — Regel-Engine (Grundgerüst) + +- **Ziel:** Konfigurierbarer Mechanismus statt fest verdrahteter if/else-Logik, um zu + bestimmen, ob ein Asset einsatzbereit ist. +- **Beschreibung:** Regelkatalog (welche Faktoren zählen: Fehlbestand/Prüfung/Wartung/ + Mangel/Beladung), pro Regel an-/abschaltbar, evtl. Gewichtung. +- **Benutzerwert:** Verschiedene Organisationen haben unterschiedliche Kriterien für + „einsatzbereit" — konfigurierbar statt Code-Änderung nötig. +- **Abhängigkeiten:** ASSET-004 +- **Datenmodell:** `readiness_regel` (id, schluessel, aktiv, beschreibung) +- **Backend:** Regel-Auswertungs-Engine (iteriert aktive Regeln, sammelt Gründe) +- **Frontend:** keins in dieser Kachel (Konfiguration folgt READY-005) +- **Mobile:** keins +- **QR-Code/Seriennummer/Inventarnummer:** nein +- **Akte:** Grundlage für Readiness-Anzeige +- **Rechte:** keine neuen (Auswertung ist lesend) +- **Audit:** nein +- **Akzeptanzkriterien:** Regeln iterierbar, Ergebnis = Liste erfüllter/nicht erfüllter + Kriterien. +- **Tests:** Regel-Iterations-Test. +- **DoD:** **HIGH RISK** (größte technische Unsicherheit im gesamten Backlog) — MABEA hat + stattdessen eine fest verdrahtete Funktion (`einsatzbereitschaft()` mit hartcodierten + Kriterien Fehlbestand/Ablauf/Prüfung/Sperre/Mangel/in_wartung/HU-UVV). Umbau zu einer + echten Regel-Engine ist ein substanzieller Umbau, kein Nachzug — vor Umsetzung klären, + ob der Konfigurierbarkeits-Bedarf real ist (bisher nur eine Organisation im Einsatz, ein + fester Kriterienkatalog reicht evtl. aus). + +## READY-002 — Zustände READY/LIMITED/NOT_READY/UNKNOWN + +- **Ziel:** Einheitliche Zustands-Terminologie. +- **Beschreibung:** Enum mit vier Werten, UNKNOWN für Assets ohne ausreichende + Datenbasis (z.B. noch nie kontrolliert). +- **Benutzerwert:** Klare Ampel statt Zahlenwerk. +- **Abhängigkeiten:** READY-001 +- **Datenmodell:** keins neu (Enum-Rückgabewert der Engine) +- **Backend:** Mapping Regel-Ergebnisse → einer der vier Zustände +- **Frontend:** Badge/Farbe je Zustand +- **Mobile:** Anzeige +- **QR-Code/Seriennummer/Inventarnummer:** nein +- **Akte:** Stammdatenbereich +- **Rechte:** wie Lese-Recht +- **Audit:** nein +- **Akzeptanzkriterien:** alle vier Zustände erreichbar, UNKNOWN korrekt für „noch nie + kontrolliert". +- **Tests:** Zustandstest je Fall. +- **DoD:** **DECISION REQUIRED (fachlich, nicht nur technisch):** MABEA kennt nur drei + Zustände (einsatzbereit/eingeschränkt/nicht_einsatzbereit). **UNKNOWN fehlt bisher — ein + noch nie kontrolliertes Objekt wird aktuell als „einsatzbereit" gezählt**, weil keine + Kriterien verletzt sind. Das ist fachlich fragwürdig: „nie geprüft" sollte vermutlich + nicht dasselbe bedeuten wie „geprüft und in Ordnung". Vor Umsetzung mit dem Nutzer + klären, ob das der gewünschte aktuelle Zustand ist oder korrigiert werden soll. + +## READY-003 — Regel-Kopplung (Prüfung/Wartung/Mangel/Beladung) + +- **Ziel:** Tatsächliche Verzahnung der Regel-Engine mit den anderen Epics. +- **Beschreibung:** Jede Regel liest den relevanten Zustand aus INSP/MAINT/DEFECT/LOAD. +- **Benutzerwert:** Gesamtbild statt Einzelmodule, die nichts voneinander wissen. +- **Abhängigkeiten:** READY-002, INSP-004, DEFECT-005, LOAD-006, MAINT (falls Wartung + ebenfalls einfließen soll) +- **Datenmodell:** keins neu +- **Backend:** Regel-Implementierungen je Faktor +- **Frontend:** Gründe-Liste in der Readiness-Anzeige +- **Mobile:** Anzeige +- **QR-Code/Seriennummer/Inventarnummer:** nein +- **Akte:** Stammdatenbereich +- **Rechte:** wie Lese-Recht +- **Audit:** nein zusätzlich +- **Akzeptanzkriterien:** jeder Faktor einzeln testbar, Kombination mehrerer Faktoren + korrekt (mehrere Gründe gleichzeitig möglich). +- **Tests:** Faktor-Einzeltests + Kombinationstest. +- **DoD:** deckt sich weitgehend mit MABEA (`dashboard.einsatzbereitschaft()` hat bereits + Fehlbestand/Ablauf/Prüfung/Sperre/Mangel/in_wartung/HU-UVV kombiniert) — Wartung (MAINT) + kann noch nicht einfließen, da das Wartungs-Epic in MABEA nicht existiert. + +## READY-004 — Readiness-Dashboard + +- **Ziel:** Zentrale Übersicht „wie viele Assets sind einsatzbereit". +- **Beschreibung:** Kachel mit Zahlen je Zustand + aufklappbare Detailliste mit Gründen. +- **Benutzerwert:** Leitungsverantwortliche sehen auf einen Blick den Gesamtzustand. +- **Abhängigkeiten:** READY-003 +- **Datenmodell:** keins neu +- **Backend:** Aggregations-Endpunkt +- **Frontend:** Dashboard-Kachel +- **Mobile:** Anzeige +- **QR-Code/Seriennummer/Inventarnummer:** nein +- **Akte:** nein (übergreifende Sicht) +- **Rechte:** Verantwortliche +- **Audit:** nein +- **Akzeptanzkriterien:** Zahlen stimmen mit Summe der Einzel-Assets überein. +- **Tests:** Konsistenztest (Summe Detail = Summe Kachel). +- **DoD:** deckt sich 1:1 mit MABEA (Kachel „Einsatzbereites Material", bereits umgesetzt + inkl. aufklappbarer Detailliste). + +## READY-005 — Regel-Konfiguration-UI + +- **Ziel:** Administrator kann Regeln an-/abschalten ohne Code-Änderung. +- **Beschreibung:** UI zum Umschalten der READY-001-Regeln. +- **Benutzerwert:** Organisationsspezifische Anpassung ohne Entwicklerbeteiligung. +- **Abhängigkeiten:** READY-003 +- **Datenmodell:** keins neu (nutzt `readiness_regel.aktiv`) +- **Backend:** PATCH-Endpunkt +- **Frontend:** Einstellungsseite +- **Mobile:** keins +- **QR-Code/Seriennummer/Inventarnummer:** nein +- **Akte:** nein +- **Rechte:** Administrator +- **Audit:** Änderung geloggt +- **Akzeptanzkriterien:** Regel abschalten entfernt sie sichtbar aus der Bewertung. +- **Tests:** Ein-/Ausschalt-Test. +- **DoD:** **P2, abhängig von READY-001** (ob die Regel-Engine überhaupt gebaut wird) — + kann komplett entfallen, wenn READY-001 zurückgestellt bleibt und ein fester + Kriterienkatalog ausreicht. + +--- + +**MABEA-Ist-Stand-Abgleich:** Funktional ist Readiness in MABEA bereits gut abgedeckt +(`dashboard.einsatzbereitschaft()` kombiniert mehr Faktoren als in dieser Kachel-Spezifikation +ursprünglich vorgesehen — sogar Fahrzeug-HU/UVV und Mangel-Priorität fließen schon ein). Die +konzeptionelle Lücke ist die **fehlende Konfigurierbarkeit** (READY-001/005: alles ist fest +im Code verdrahtet statt als an-/abschaltbare Regeln) und der **fehlende UNKNOWN-Zustand** +(READY-002 — ein nie kontrolliertes Objekt gilt fälschlich als einsatzbereit). Letzteres ist +die wichtigste fachliche Nachfrage aus diesem Epic, nicht nur eine technische Fleißaufgabe.