Softwareentwicklung und digitale Prozessgestaltung
Vom Arbeitsprozess zur technischen Lösung
Meine Projekte beginnen nicht mit einer möglichst langen Funktionsliste, sondern mit dem zugrunde liegenden Arbeitsprozess: Wer benötigt welche Informationen? Wer darf sie sehen oder verändern? Welche Schritte und Zustände müssen nachvollziehbar bleiben? Erst daraus entstehen Datenmodell, Berechtigungen, Oberfläche und technische Umsetzung.
Ziel ist nicht möglichst viel Eigenentwicklung. Vorhandene Funktionen von WordPress oder Nextcloud nutze ich dort, wo sie den fachlichen Bedarf sauber abdecken; eigene Logik entsteht dort, wo Rollen, Datenflüsse oder Prozessanforderungen sonst nicht zuverlässig umgesetzt werden können.
Entwicklungsprozess in vereinfachter Form
Der Ablauf ist kein starres Phasenmodell. Bei neuen Erkenntnissen geht es bewusst zurück zu Anforderungen oder Architektur. Die Darstellung zeigt die typische Richtung meiner Arbeit.
1 · Reale Abläufe und Problemstellung
Zweck · Beteiligte · vorhandene Arbeitsweise · Grenzen
2 · Anforderungen, Rollen und Daten
wer benötigt was · Lesen/Ändern/Freigeben · Zustände · notwendige Daten
3 · Architektur
Module · Datenmodell · Schnittstellen · Plattformfunktionen
4 · Berechtigungen
serverseitige Prüfungen · Rollenwechsel · Export · Protokollierung
5 · Umsetzung mit überprüfbarer KI-Unterstützung
Code · Refactoring · Fehleranalyse · Testvorbereitung · Dokumentationsentwürfe
6 · Tests und Reviews
manuell · automatisiert · statisch · Laufzeit · Architektur
7 · Dokumentation und Releasezustand
README · Handbuch · Changelog · bekannte Grenzen · Release-Gates
Rollen und Berechtigungen von Anfang an
Berechtigungen sind kein nachträgliches Detail. Bereits vor der Umsetzung wird geklärt, welche Rolle Informationen sehen, anlegen, bearbeiten, freigeben, exportieren oder löschen darf. Gerade bei Beschäftigten-, Schul- oder Assistenzdaten ist eine großzügige Rechtevergabe keine neutrale Vereinfachung.
Fachliche Fragen
- Welche Aufgabe hat die Rolle?
- Welche Information benötigt sie tatsächlich?
- Wer entscheidet oder gibt frei?
- Welche Änderungen müssen nachvollziehbar sein?
Technische Umsetzung
- serverseitige Zugriffsprüfung
- klare Trennung von Lesen und Ändern
- kontrollierte Exporte
- definiertes Verhalten bei Rollenwechseln
Technische Struktur vor Einzeloberfläche
Bei WordPress- und Nextcloud-Anwendungen trenne ich fachliche Logik, Datenhaltung, Berechtigungen, Oberfläche und Dokumentenerzeugung möglichst klar voneinander. Gemeinsam benötigte technische Grundlagen werden nicht für jedes Einzelprojekt neu implementiert.
Modularität
Fachlich getrennte Funktionen sollen nicht unnötig voneinander abhängig sein.
Datenmodell
Datenstrukturen entstehen aus Rollen, Zuständen und Beziehungen des tatsächlichen Prozesses.
Plattformintegration
Vorhandene WordPress- oder Nextcloud-Schnittstellen werden genutzt, bevor parallele Benutzer-, Rechte- oder Dateilogik entsteht.
KI als Werkzeug, nicht als Freigabeinstanz
KI-Werkzeuge nutze ich zur Strukturierung von Anforderungen, Codeanalyse, Fehlersuche, Vorbereitung von Testfällen, Dokumentation und getrennten Review-Schritten. Ergebnisse werden am Code, an Tests, an der Dokumentation und am tatsächlichen Systemzustand geprüft.
Architekturentscheidungen, Datenschutz- und Sicherheitsbewertung, Tests und Freigaben bleiben menschliche Verantwortung.
Testen, ausliefern und dokumentieren
Je nach Projekt kombiniere ich manuelle Funktionstests, automatisierte Tests, statische Analysen, Build- und Laufzeitprüfungen sowie Code- oder Architekturreviews. Ein fehlgeschlagener Test wird als Fehler dokumentiert; ein noch nicht ausgefülltes formales Abnahmeprotokoll wird davon getrennt betrachtet.
Bei einem größeren Nextcloud-Verbund ist dieser Prüfpfad als mehrstufiges Delivery-Gate dokumentiert: schnelle PHP- und JavaScript-Prüfungen, Paket- und Vertragsprüfungen, reproduzierbarer Archivbau mit Prüfsummen, Containerchecks, authentifizierte HTTP-Smokes einschließlich CSRF- und Adminschutz sowie Rechtematrizen für Allow-/Deny-Fälle. Zusätzlich werden Testabdeckungs-Baselines geführt, damit Rückgänge sichtbar werden.
Repository, README, Handbuch, Versionshistorie und Changelog sollen denselben tatsächlichen Stand beschreiben. WordPress fasst diesen Stand verständlich zusammen; technische Quelle bleiben Repository, Tests und veröffentlichte Releases.
Bezeichnungen wie „stabil“, „produktiv erprobt“ oder „produktionsreif“ verwende ich nur, wenn sie durch einen überprüfbaren Zustand belegt sind.