# Stadt Humoriana – vollständige Projektdokumentation ## 1. Dokumentstatus **Dokumentationsstand:** 22.09.2026 **Dokumentierter Plattformstand:** MD Stadtportal 1.15.4 **Projektstatus:** aktiv / fortlaufendes Portfolio- und Simulationsprojekt **Rekonstruierter Planungsbeginn:** 27.04.2026 **Rekonstruierter Aufwand bis heute:** 104,5 Personentage (MT) **Requirements:** 88 **Testfälle / Testläufe:** 102 / 102 **Arbeitspakete:** 48 **Issues:** 24 **Risiken:** 18 Der Projektbeginn und der Aufwand sind **rückgerechnet**, keine nachträgliche Behauptung einer lückenlosen Zeiterfassung. Zwischen dem 27.04.2026 und 22.09.2026 liegen 107 reguläre Werktage. Ein Aufwand von 104,5 MT bildet den heute dokumentierten Umfang deshalb als nahezu durchgängige Solo-Entwicklung über knapp fünf Monate realistisch ab. Eingerechnet sind Konzept, Stadtwelt, Datenmodell, Theme/Plugin, Fachmodule, Migrationen, Fehleranalyse, Tests, UX-Härtung und Dokumentation. ## 2. Projektursprung Humoriana begann als fiktive Stadt mit zunächst rund 30 humorvollen Geschichten. Wiederkehrende Orte, Straßennamen, Behörden und Eigenheiten wurden daraus zu einer zusammenhängenden Stadtwelt. Der erste technische Schritt war kein Bürgerportal, sondern ein Informationsportal, das diese Welt strukturiert darstellen sollte. Aus dem Informationsportal entstand iterativ eine Fachanwendung. Immer wenn eine neue Funktion nicht mehr glaubwürdig als statischer Text abbildbar war, wurde sie in strukturierte Daten und eigene Logik überführt. Dadurch wuchs Humoriana von einer Contentseite zu einem kommunalen Simulations- und Serviceportal mit Bürgerkonto, Registern, Finanzen, Mobilität, Arbeitsmarkt, Statistik und eigener Betriebsadministration. ## 3. Projektziele Die Anwendung verfolgt zwölf dokumentierte Ziele: glaubwürdige kommunale Darstellung, zentrale Datenwahrheit, Bürger-Self-Service, modulare Verwaltung ohne Core-Hacks, realistische Stadtsimulation, updatefähiger Betrieb, mobile Gleichwertigkeit, nachvollziehbare Fachprozesse, portfoliofähige Architektur, Wartbarkeit, datensparsame Öffentlichkeit und Erweiterbarkeit. ## 4. Umfang des aktuellen Systems Der aktuelle Stand bildet unter anderem folgende Domänen ab: - Rathaus, Ämter, Online-Dienste und Vorgangsstatus - zehn Stadtteile mit Karte, Flächen- und Registerbezug - Melderegister und Personenstands-/Dokumentlogik - Mein HUM als Bürgerkonto mit Login, Logout und Fachcockpit - Melde-/Ausweis-/Passbezüge und weitere Bürgerdokumente - Haushalte, HUM-Konten, Finanzledger und wiederkehrende Buchungen - Versorgung, Stadtwerke, Wohnen, Versicherung, Kranken-/Pflegekasse und Rente - HUM Net/Mobil - Fahrzeuge, Verkauf, Mobilität, ÖPNV, Parken, Taxi, Tankstellen und Werkstätten - HUMCard, Tickets und HUMPass-Angebote - Schulen, Kitas, Soziales, Gesundheit, Sicherheit, Feuerwehr und Polizei - Freizeit, Kultur, Veranstaltungen, Vereine und Stadtgeschichten - Betriebe, Handwerk, Handel, Branchen- und Telefonbuch - Arbeitsmarkt, Arbeitgeber, Beschäftigungsstatus, JobCenter und freie Stellen - öffentliche Einwohner-, Haushalts-, Schul-, Wirtschafts- und Arbeitsmarktstatistik - zentrale Meldungen für Hero, Aktuelles, Archiv und Detailansicht - Portalsuche über statische und dynamische Inhalte - Backup, Restore, Patchinstallation und Versionierung - zusätzliche Betriebshilfen für Systembackup, Notfall-Dateieditor und Erweiterungsbereinigung Im zugrunde liegenden Portalstand existieren über 120 öffentliche Inhalts-/Funktionsrouten und mehr als 60 dynamische Renderer-Varianten. ## 5. Stadtmodell – dokumentierter Snapshot Der aktuelle dynamische Datenstand wird in der Projektdokumentation als Snapshot geführt, nicht als dauerhaft festgeschriebene Zahl: | Kennzahl | Stand | |---|---:| | Einwohner | 58.421 | | Haushalte | 27.501 | | Stadtteile | 10 | | Stadtgebiet | 74,6 km² | | Schulen | 18 | | lokale Arbeitgeber / Einrichtungen | 136 | | Beschäftigt / Ausbildung | ca. 32.171 | | davon Arbeitsplatz in Humoriana | ca. 14.636 | | Auspendler | ca. 17.535 | | arbeitslos / arbeitssuchend | ca. 1.977 | Entscheidend ist nicht die Zahl selbst, sondern ihre Herkunft: Einwohner, Haushalte, Stadtteilwerte und Arbeitsmarktkennzahlen werden aus den jeweiligen Fachbeständen abgeleitet und nicht als voneinander unabhängige Marketingwerte gepflegt. ## 6. Architektur ### 6.1 Schichten **Öffentliches Portal** – Navigation, Seiten, Suche, Stadtteile, Meldungen, Dienste, Statistik, Jobs und Branchenbuch. **Mein HUM** – personalisierte Bürgeroberfläche. **Fachlogik** – Register, Dokumente, Finanzen, Mobilität, HUMPass, Beschäftigung, Meldungen und Statistik. **Administration** – redaktionelle und fachliche Pflege, JobCenter, Register, Finanzen, Mobilität/Handel sowie Backup/Update. **Datenhaltung** – strukturierte Flat-File-/JSON-Bestände mit definierten Aggregatoren und Migrationen. **Betrieb** – Patchmanifest, Backups, Restore, Versionscode, Integritätsprüfungen und Notfallwerkzeuge. ### 6.2 Core-Trennung Der CMS-Kern ist nicht der Ort für Humoriana-Fachlogik. Die Anwendung nutzt ein eigenes Theme und eigene Erweiterungen. Dadurch bleiben Fachcode, UI und Datenmigrationen kontrollierbar und ein Basisupdate muss nicht manuell mit Core-Hacks verschmolzen werden. ### 6.3 Renderer-Prinzip Redaktionelle Seiten können dynamische Fachbereiche über definierte Renderer einbetten. Dadurch bleibt die Seitenstruktur redaktionell handhabbar, während Tabellen, Statistiken, Formulare und Bürgerfunktionen aus aktuellen Daten erzeugt werden. Der Suchindex behandelt diese Renderer gesondert, damit interne Platzhalter nicht öffentlich erscheinen. ## 7. Fachliche Datenketten ### Register → Statistik Der aktive Personenbestand bestimmt Einwohnerzahl, Stadtteilverteilung und Altersstruktur. Die Umstellung auf Live-Daten beseitigte den früheren Fehler 58.420 vs. 58.421. ### Haushalt/Konto → Finanzen Haushaltskonten und nachträglich erzeugte virtuelle HUM-Konten werden gemeinsam ausgewertet. Dadurch entsprechen Finanzübersicht und Haushaltsstatistik demselben fachlichen Stand. ### Beschäftigung → JobCenter → Mein HUM Automatische Arbeitsmarktzuordnung liefert eine reproduzierbare Grundverteilung. Manuelle JobCenter-Zuweisungen überschreiben diese. Der Bürger sieht Arbeitgeber und Tätigkeit in Mein HUM. Eine Kündigung setzt den Bürger wieder auf arbeitssuchend und gibt gegebenenfalls die vermittelte Stelle frei. ### Meldung → sämtliche Newsdarstellungen Meldungen sind die einzige Newsquelle. Hero, Aktuelles, Archiv und Detailansicht werden aus demselben Objekt erzeugt. Die früheren separaten Bludit-Newsbeiträge wurden migriert und nach erfolgreicher Übernahme entfernt. ### Patch → Backup → Migration Ein Patch wird auf Ausgangsversion, Versionscode und Dateihashes geprüft. Vor riskanten Änderungen wird eine Sicherung erstellt. Datenmigrationen ergänzen oder transformieren vorhandene Strukturen, ohne den gesamten Produktivbestand als Patchdatei mitzuliefern. ## 8. Requirements Engineering Die Baseline umfasst 88 Anforderungen: - **USR:** 20 - **SYS:** 28 - **SEC:** 12 - **SRS:** 10 - **HRS:** 6 - **SWC:** 12 Die Anforderungen sind in User-/System-/Security-/Software-/Hosting- und Consistency-Anforderungen getrennt. Besonders wichtig sind die SWC-Anforderungen: Sie beschreiben nicht isolierte Features, sondern Regeln zwischen Modulen, etwa Register ↔ Statistik, JobCenter ↔ Mein HUM oder Meldung ↔ Frontenddarstellung. ## 9. Verifikation und Regression Für jede dokumentierte Anforderung existiert mindestens ein Testfall. Zusätzlich enthält die Akte Integrationsprüfungen für die besonders fehleranfälligen Datenketten. Die Testläufe dokumentieren Softwarestand, Testaufbau, Ergebnis und Sollverhalten. Schwerpunkte der Regression: - Login/Logout und Zugriffstrennung in Mein HUM - Registeränderung → Einwohner-/Stadtteilstatistik - Bürgerrestore ohne Dokumentduplikate - Haushalts-/virtuelles Konto → Finanzsummary - Arbeitgeberzuweisung → Mein HUM → JobCenter - Stelle zuweisen/kündigen → Vakanzbestand - Meldung anlegen/löschen → Hero/Aktuelles/Archiv/Detail - Portalsuche ohne Renderer-Tokens oder doppelte HTML-Entities - mobile Buchungs-/Preistabellen als Karten - Patchprüfung, Prebackup und Workspace-Erhalt - Cacheinvalidierung bei großen Registerbeständen ## 10. Fehler- und Änderungsmanagement Die Akte enthält {len(issues)} geschlossene Issues aus der realen Ausbauphase. Sie dokumentieren nicht nur klassische Bugs, sondern auch Änderungswünsche und Qualitätsabweichungen. Beispiele sind der additive Bürgerrestore, mobile Überbreite, abweichende Einwohner-/Finanzzähler, doppelte Newsquellen, JobCenter-UX und sichtbare Renderer-Tokens. ## 11. Risikoanalyse {len(risks)} Risiken decken Datenkonsistenz, Restore/Update, Performance, Flat-File-Schreibvorgänge, öffentliche Informationspreisgabe, JobCenter-/Stellenkopplung, mobile UX, Shared Hosting und Wartbarkeit ab. Das größte fortbestehende Qualitätsthema ist eine formale Barrierefreiheitsprüfung; responsive Nutzbarkeit allein ersetzt keine vollständige BITV/WCAG-Abnahme. ## 12. Betriebs- und Recovery-Konzept Das Portal ist für Shared Hosting ausgelegt. Für den Regelbetrieb sind weder Root-Zugriff noch Node/npm noch eine zusätzliche SQL-Instanz notwendig. Backup und Patchmanagement können über die Administration erfolgen. Ein separates Systemplugin ergänzt Core-/Systembackups. Ein Notfall-Dateieditor dient schnellen Reparaturen, wenn WebFTP unnötig umständlich wäre. Wichtiges Betriebsprinzip: **Codeupdate und Produktivdaten werden getrennt.** Patches enthalten keine Kopie laufender Bürger-/Register-/Finanzbestände. Restore-Operationen werden als eigener bewusster Vorgang behandelt. ## 13. Sicherheit Humoriana ist eine Fiktion, verarbeitet innerhalb der Simulation jedoch personenbezogene Strukturen. Deshalb gelten auch im Portfolio-Projekt technische Schutzprinzipien: - persönliche Bereiche nur nach Authentifizierung - Adminaktionen nur in der Administration - CSRF-/Sitzungsabsicherung der Basis nutzen - Workspace-Daten gegen direkten Webzugriff schützen - keine privaten Bürgerdaten im öffentlichen Branchenbuch - keine unnötigen internen Pfade in öffentlichen Hilfetexten - Patch-/Archivpfade validieren - vor riskanten Änderungen sichern - keine Passwörter/PINs/Schlüssel in Portfolio-Dokumenten ## 14. UX und Mobile Die mobile Überarbeitung war eine eigene Integrationsphase. Desktoptabellen wurden dort, wo sie mobil unbrauchbar waren, in Karten transformiert. Lange Überschriften, Sticky-Header und horizontales Überlaufen wurden systematisch korrigiert. Das Ziel ist kein optisch identischer Desktop, sondern eine gleichwertig bedienbare mobile Fachoberfläche. ## 15. Release- und Migrationshistorie Die detaillierte Historie liegt als eigener Anhang vor. Dokumentiert sind unter anderem die Ausbaustände 1.11.x bis 1.15.4: Fahrzeugfunktionen, Versorgung, Backup/Update, Branding, Bürgerrestore, ToDo-UX, mobile Härtung, Live-Statistik, Schul-/Wirtschaftsausbau, JobCenter, zentrale Meldungen, Suchbereinigung, Finanzkonsistenz und öffentliche Dokumentationshärtung. ## 16. Aufwand und Zeitrekonstruktion Die WBS summiert sich auf **104,5 MT**. Die Rückrechnung startet am **27.04.2026**. Bis zum 22.09.2026 liegen 107 Werktage. Damit entspricht die Dokumentation ungefähr einer durchgehenden Vollzeit-Soloentwicklung. Das ist für die Breite des Systems realistischer als der frühere Zwischenwert von 66,5 MT, der wesentliche Fach-, Test- und Integrationsarbeit noch nicht vollständig erfasst hatte. Die Rekonstruktion teilt den Aufwand auf Konzept/Stadtwelt, Frontend, Datenmodell, Bürgerdienste, Register, Mobilität, Finanzen, Betrieb, Statistik, Arbeitsmarkt, Integration, Tests und Dokumentation auf. Die Einzelwerte stehen im WBS-Export. ## 17. Aktueller Reifegrad und offene Qualitätsarbeit Der funktionale Reifegrad wird mit **97 %** geführt. Das bedeutet nicht „fertig“, sondern: Die wesentlichen fachlichen Ketten existieren und sind integriert. Die nächste Qualitätsstufe liegt weniger in zusätzlichen Features als in: - automatisierten Regressionstests - formaler BITV/WCAG-Prüfung - feingranulareren Rollen-/Rechteprofilen - expliziten Datenverträgen zwischen Fachmodulen - weiterem Audit-/Historienmodell für ausgewählte Änderungen - Belastungs-/Parallelitätstests für Flat-File-Schreibpfade ## 18. Portfolioaussage Humoriana dokumentiert ein Anwendungsentwicklungsprojekt, nicht nur ein Theme. Der Schwerpunkt liegt auf Fachlogik, Datenkonsistenz, Migrationen, modularer Administration, Fehleranalyse, Tests und Betriebsfähigkeit. Die fiktive Stadt dient als Domäne, um Zusammenhänge sichtbar zu machen, die bei isolierten Demoformularen kaum entstehen würden.