10 Qualitätsanforderungen
Die drei wichtigsten Qualitätsziele sind in Sektion 1.2 beschrieben. Dieses Kapitel enthält den vollständigen Qualitätsbaum und messbare Szenarien für alle relevanten Qualitätskategorien.
10.1 Qualitätsbaum
| Kategorie | Qualitätsanforderung | Priorität | Szenario |
|---|---|---|---|
| Wartbarkeit | Neue CRUD-Domäne in einem Arbeitstag integrierbar | Hoch | QS-01 |
| Wartbarkeit | Breaking Changes erkennbar vor dem Upgrade | Hoch | QS-02 |
| Performance | Gefilterte, paginierte Liste von 10 000 Entitäten in < 500 ms | Hoch | QS-03 |
| Sicherheit | Kein Benutzer sieht unberechtigt Datensätze | Hoch | QS-04 |
| Sicherheit | Jede Schreiboperation ist nachvollziehbar | Hoch | QS-05 |
| Zuverlässigkeit | Pod-Ausfall ohne Datenverlust und ohne manuelle Intervention | Mittel | QS-06 |
| Zuverlässigkeit | Framework-Startfehler werden frühzeitig erkannt | Mittel | QS-07 |
| Portabilität | Datenbankwechsel ohne Code-Änderung in consuming Apps | Mittel | QS-08 |
| Betreibbarkeit | Fehlkonfiguration wird beim Start gemeldet | Mittel | QS-09 |
| Testbarkeit | Integrationstests ohne produktive Infrastruktur ausführbar | Niedrig | QS-10 |
| Stammdatenkonsistenz | Alle Fachapplikationen verwenden identische, mehrsprachige Codelisten | Mittel | QS-11 |
10.2 Qualitätsszenarien
10.2.1 QS-01: Neue CRUD-Domäne in kurzer Zeit
| Aspekt | Beschreibung |
|---|---|
| Kategorie | Wartbarkeit / Developer Experience |
| Stimulus | Ein Entwickler einer Behörde erhält den Auftrag, eine neue Domäne (Entity, Repository, Command, REST-Endpoint) zu implementieren |
| Umgebung | Consuming App mit konfiguriertem e-gov-framework; Entwickler kennt die Dokumentation und die Demo-Applikation |
| Artefakt | Framework-Kern (BaseRepositoryImpl,
BaseExecutor, DomainCommandFactory) |
| Reaktion | Die Domäne ist vollständig integriert: persistierbar, permission-gefiltert, audit-getrailed, per REST erreichbar |
| Metrik | Aufwand ≤ 1 Arbeitstag (8 h) für einen Entwickler mit Java/Spring-Erfahrung |
Architektonische Massnahmen: BOM für konsistentes
Dependency-Management;
BaseRepositoryImpl/BaseExecutor-Basisklassen;
Convention over Configuration via Spring Boot Auto-Konfiguration;
egov-framework-demo als Referenzimplementierung.
10.2.2 QS-02: Breaking Changes vor dem Upgrade erkennbar
| Aspekt | Beschreibung |
|---|---|
| Kategorie | Wartbarkeit / Evolvierbarkeit |
| Stimulus | Das Framework-Team veröffentlicht eine neue Version |
| Umgebung | Consuming App; Entwickler prüft Kompatibilität vor dem BOM-Upgrade |
| Artefakt | Maven BOM, CHANGELOG, Semantic Versioning |
| Reaktion | Breaking Changes sind als Major-Version-Bump (SemVer) und im CHANGELOG dokumentiert; Minor/Patch-Upgrades sind ohne Anpassung in der consuming App möglich |
| Metrik | 100 % der Breaking Changes werden als Major-Version veröffentlicht; CHANGELOG enthält Migration-Hinweise |
Architektonische Massnahmen: Conventional Commits steuern automatische Versionsvergabe via Semantic Release; CHANGELOG wird automatisch generiert; Artifactory als versioniertes Repository.
10.2.3 QS-03: Gefilterte Listenabfrage unter 500 ms
| Aspekt | Beschreibung |
|---|---|
| Kategorie | Performance / Effizienz |
| Stimulus | Ein Sachbearbeiter lädt eine gefilterte, paginierte Liste |
| Umgebung | Produktivsystem unter Normallast; Tabelle enthält 10 000 Entitäten; Benutzer hat eingeschränkte Rollenberechtigungen |
| Artefakt | QueryBuilder, PermissionBuilder,
FilterParser, Datenbankindex |
| Reaktion | Die gefilterte, permission-bereinigte, paginierte Ergebnisliste wird korrekt zurückgeliefert |
| Metrik | Gesamtantwortzeit (inkl. Permission-Filter) ≤ 500 ms (p95) |
Architektonische Massnahmen: Nativer JDBC statt JPA
Criteria API (kein ORM-Overhead); Permission-Filter direkt in SQL (kein
Post-Filter in Java); Indizes auf egov_iam_role_membership
(userId, valid_from, valid_to).
Bekannte Grenze: Tokenizer.java wirft
einen Stack Overflow bei IN-Conditions mit ca. 1 300+ Werten (→ Risiko
R-1).
10.2.4 QS-04: Kein Benutzer sieht unberechtigt Datensätze
| Aspekt | Beschreibung |
|---|---|
| Kategorie | Sicherheit / Vertraulichkeit |
| Stimulus | Ein Sachbearbeiter sendet eine Listeanfrage für Entitäten, für die er keine Berechtigung hat |
| Umgebung | Produktivsystem; Benutzer ist authentifiziert, aber nicht für alle Datensätze autorisiert |
| Artefakt | PermissionBuilder, BaseRepositoryImpl,
egov_iam_permission_definition |
| Reaktion | Die Antwort enthält ausschliesslich Datensätze, für die eine
permission_definition mit der Rolle des Benutzers
existiert; unberechtigte Datensätze werden weder zurückgegeben noch als
fehlend signalisiert |
| Metrik | 0 unberechtigte Datensätze in jeder Antwort; nachweisbar durch Integrationstests mit verschiedenen Rollen |
Architektonische Massnahmen: Row-based Security als
opt-out (ADR-004); PermissionBuilder ist ohne expliziten
Admin-Modus nicht umgehbar.
10.2.5 QS-05: Jede Operation nachvollziehbar
| Aspekt | Beschreibung |
|---|---|
| Kategorie | Sicherheit / Nachvollziehbarkeit / Compliance |
| Stimulus | Ein Sicherheitsverantwortlicher oder Prüfer möchte nachvollziehen, wer wann welche Datenänderung vorgenommen hat |
| Umgebung | Produktivsystem; die Fachapplikation nutzt BaseExecutor
für alle Schreiboperationen |
| Artefakt | Command-Tabelle (egov_cmd_command),
DomainCommandFactory |
| Reaktion | Jede Schreiboperation ist als Zeile in egov_cmd_command
protokolliert: Benutzer, Zeitstempel, Aktion, Status
(EXECUTED / HARD_VALIDATION_FAILED) |
| Metrik | 100 % aller Schreiboperationen, die über BaseExecutor
laufen, sind in der Command-Tabelle eingetragen |
Architektonische Massnahmen: Command-Pattern für
alle Schreiboperationen (ADR-003); INITIALIZED-Status wird
vor der Ausführung persistiert, sodass auch abgebrochene Operationen
sichtbar sind.
Bekannte Grenze:
NonTxExecutor-Operationen laufen ausserhalb von
Spring-Transaktionen; bei einem Pod-Ausfall während solcher Operationen
ist die Rollback-Garantie nicht gewährleistet (→ Risiko R-2). Dies wird
in Framework 2.0 adressiert.
10.2.6 QS-06: Pod-Ausfall ohne Datenverlust
| Aspekt | Beschreibung |
|---|---|
| Kategorie | Zuverlässigkeit / Fehlertoleranz |
| Stimulus | Ein Kubernetes-Pod, der das Framework ausführt, fällt während einer Schreiboperation aus |
| Umgebung | Produktivsystem; Kubernetes-Cluster mit mehreren Replikas; PostgreSQL mit synchronem Commit |
| Artefakt | Command-Tabelle, Spring-Transaktionsmanagement,
Kubernetes Liveness/Readiness Probes |
| Reaktion | Neue Anfragen werden durch Kubernetes auf verbleibende Pods
umgeleitet; halbfertige Transaktionen werden durch die Datenbank
zurückgerollt; der Command-Eintrag verbleibt im Status
INITIALIZED und ist damit als unvollständig erkennbar |
| Metrik | Kein stiller Datenverlust; Wiederherstellungszeit < 30 s (Kubernetes-Probe-Intervall) |
Architektonische Massnahmen: Command-Status
INITIALIZED wird vor der Ausführung persistiert;
Spring-Transaktionen stellen atomares Rollback sicher; LUID-IDs sind
ohne DB-Koordination erzeugbar.
Bekannte Grenze:
NonTxExecutor-Operationen laufen ausserhalb von
Spring-Transaktionen; ein Pod-Ausfall während solcher Operationen kann
zu inkonsistenten Datenbankzuständen führen (→ Risiko R-2). Dies wird in
Framework 2.0 adressiert.
10.2.7 QS-07: Datenbankwechsel ohne Code-Änderung
| Aspekt | Beschreibung |
|---|---|
| Kategorie | Portabilität / Flexibilität |
| Stimulus | Eine Behörde wechselt ihre Infrastruktur von PostgreSQL zu SQL Server (oder umgekehrt) |
| Umgebung | Bestehende consuming App; neues Datenbankschema wird mit Flyway migriert |
| Artefakt | DatabaseConfigurationService,
QueryBuilder, Flyway-Skripte |
| Reaktion | Die consuming App läuft nach Anpassung von
egov.persistence.database.type ohne Änderung an Java-Code
oder Queries korrekt gegen die neue Datenbank |
| Metrik | 0 Code-Änderungen in der consuming App beim DB-Typwechsel; alle Integrationstests bestehen gegen beide Datenbanktypen |
Architektonische Massnahmen: Dual-DB-Support
(ADR-006); DatabaseConfigurationService kapselt alle
Dialekt-Unterschiede.
10.2.8 QS-08: Integrationstests ohne produktive Infrastruktur
| Aspekt | Beschreibung |
|---|---|
| Kategorie | Testbarkeit |
| Stimulus | Ein Entwickler führt die Integrationstests lokal oder in der CI-Pipeline aus |
| Umgebung | Entwickler-Workstation oder GitLab-CI-Runner; kein Zugriff auf produktive Datenbanken |
| Artefakt | Testcontainers-Konfiguration, application-test.yml |
| Reaktion | Die Integrationstests starten PostgreSQL und ggf. ZooKeeper als kurzlebige Docker-Container und laufen vollständig durch |
| Metrik | Alle Integrationstests laufen ohne externe Infrastruktur; Ausführungszeit in CI < 10 Minuten |
Architektonische Massnahmen: Testcontainers mit
JDBC-URL-Protokoll (jdbc:tc:postgresql:...); separate
Test-Profile für PostgreSQL, SQL Server, H2 und ZooKeeper.
10.2.9 QS-09: Stammdatenkonsistenz über Applikationsgrenzen
| Aspekt | Beschreibung |
|---|---|
| Kategorie | Stammdatenkonsistenz / Interoperabilität |
| Stimulus | Fachapplikationen können auf denselben Codelisten-Typ zugreifen (z.B. Nationalität) |
| Umgebung | Produktivsystem; beide Apps nutzen das e-gov-mdm-Modul
mit gemeinsamer Datenbank |
| Artefakt | e-gov-mdm, e-gov-mdm-api,
egov_mdm_vocabulary-Tabellen |
| Reaktion | Beide Applikationen liefern identische, mehrsprachige Codelisten-Werte für denselben Code-Typ |
| Metrik | 0 Inkonsistenzen zwischen Applikationen bei Codelisten-Abfragen; nachweisbar durch cross-App-Integrationstests |
Architektonische Massnahmen: Zentrales MDM-Modul als
Single Source of Truth; e-gov-mdm-api stellt REST-Endpunkte
bereit; Flyway-Migrations-Skripte sichern konsistente
Codelisten-Initialisierung.
10.3 Mengengerüst
| Kennzahl | Wert | Bemerkung |
|---|---|---|
| Maximale Entitäten pro Tabelle (Richtwert) | 10 000 | |
| Maximale IN-Filter-Werte | ca. 1 300 | Technisches Limit Tokenizer (Risiko R-1) |
| Maximale parallele Pod-Instanzen | 100 | LUID-Konfiguration maxSegments |
| Unterstützte Datenbanktypen | 2 (PostgreSQL, SQL Server) | |
| Unterstützte Sprachen (MDM) | de, fr, it, en | Konfigurierbar via UserLanguageProvider |