Softwareentwicklung und digitale Prozessgestaltung
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 müssen nachvollziehbar dokumentiert werden? Erst daraus entstehen Datenmodell, Berechtigungen, Oberfläche und technische Umsetzung.
Ziel ist nicht möglichst viel Eigenentwicklung, sondern eine nachvollziehbare Lösung, die vorhandene Plattformfunktionen sinnvoll nutzt und ihre Grenzen offen dokumentiert.
Reale Abläufe als Ausgangspunkt
Am Anfang steht die fachliche und organisatorische Klärung. Ich zerlege einen Ablauf in beteiligte Rollen, Eingaben, Zustände, Entscheidungen, Ausgaben und Dokumentationsanforderungen. Dabei unterscheide ich zwischen dem tatsächlichen Bedarf, bestehenden Gewohnheiten und Funktionen, die lediglich technisch möglich wären.
Anforderungen werden so formuliert, dass später überprüfbar bleibt, ob sie umgesetzt wurden. Offene Fragen, Annahmen und noch nicht entschiedene Punkte werden getrennt dokumentiert.
Dokumentations- und Nachweispflichten
Ziel und Nutzen des Prozesses
beteiligte Rollen und Verantwortlichkeiten
benötigte und nicht benötigte Daten
Bearbeitungsschritte und Statuswechsel
Ausnahmen und Fehlerfälle
Zugriff folgt Aufgabe und Verantwortung
Rollen- und Berechtigungsmodelle sind für mich kein nachträgliches Detail. Bereits vor der Umsetzung wird geklärt, welche Rolle welche Informationen sehen, anlegen, bearbeiten, freigeben, exportieren oder löschen darf.
Dabei geht es nicht nur um technische Zugriffssperren. Berechtigungen müssen zur tatsächlichen Verantwortung passen, verständlich administrierbar sein und Änderungen möglichst nachvollziehbar machen. Besonders bei Beschäftigten-, Schul- oder Assistenzdaten ist eine großzügige Vergabe von Rechten keine neutrale Vereinfachung.
Typische Prüffragen
- Benötigt die Rolle diese Information tatsächlich?
- Reicht Lesen oder ist Bearbeiten erforderlich?
- Wer darf Entscheidungen freigeben?
- Müssen Änderungen protokolliert werden?
- Was passiert beim Rollenwechsel?
- Welche Daten dürfen exportiert werden?
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.
Vorhandene Funktionen der jeweiligen Plattform werden bevorzugt genutzt, wenn sie den fachlichen Bedarf zuverlässig abdecken. Eigene Logik ist dort sinnvoll, wo Anforderungen sonst nicht nachvollziehbar, wartbar oder sicher umgesetzt werden können.
Modularität
Funktionen werden so gegliedert, dass fachlich getrennte Bereiche nicht unnötig voneinander abhängig sind.
Datenmodell
Datenstrukturen entstehen aus Rollen, Zuständen und Beziehungen des tatsächlichen Prozesses – nicht allein aus der später sichtbaren Formularoberfläche.
Plattformintegration
Bestehende WordPress- oder Nextcloud-Schnittstellen werden genutzt, bevor parallele Benutzer-, Rechte- oder Dateilogik aufgebaut wird.
KI als Werkzeug, nicht als Freigabeinstanz
KI-Werkzeuge nutze ich unter anderem zur Zerlegung von Anforderungen, zur Codeanalyse, Fehlersuche, Entwicklung von Testfällen, Prüfung von Dokumentation und Vorbereitung getrennter Review-Schritte.
Ergebnisse werden nicht ungeprüft übernommen. KI kann falsche Annahmen überzeugend formulieren, vorhandene Funktionen übersehen oder geplante Funktionen mit tatsächlich implementierten Funktionen verwechseln. Deshalb werden Vorschläge am Code, an Tests, an der Dokumentation und am tatsächlichen Systemzustand überprüft.
Architekturentscheidungen, Datenschutz- und Sicherheitsbewertung, Tests sowie Freigaben bleiben menschliche Verantwortung.
Geeignete Unterstützung
- Anforderungen strukturieren
- Code und Änderungen vergleichen
- Fehlerhypothesen entwickeln
- Testfälle vorschlagen
- Dokumentation vorbereiten
- Reviews aus unterschiedlichen Rollen durchführen
Nicht delegiert
- fachliche Verantwortung
- Veröffentlichungsentscheidung
- Datenschutzprüfung
- Sicherheitsfreigabe
- Bewertung produktiver Daten
- Behauptung eines erfolgreichen Tests
Prüfen, was tatsächlich funktioniert
Welche Prüfungen sinnvoll sind, hängt vom jeweiligen Projekt ab. Je nach Anwendung kombiniere ich manuelle Funktionstests, automatisierte Tests, statische Analysen, Buildprüfungen und getrennte Code- oder Architekturreviews.
Entscheidend ist die Nachvollziehbarkeit: Ein fehlgeschlagener Test wird nicht als Erfolg dokumentiert. Fehler werden möglichst reproduzierbar beschrieben, Änderungen einzeln geprüft und nicht durch mehrere unkoordinierte Eingriffe verdeckt.
Mögliche Prozessdarstellung:
- Fehler korrigieren oder Änderung zurücknehmen
- erwartetes Verhalten definieren
- Ausgangszustand sichern
- Änderung begrenzen
- Test oder Review durchführen
- Ergebnis dokumentieren
Dokumentation gehört zur Anwendung
Code allein erklärt weder den fachlichen Zweck noch Rollen, Grenzen oder den sicheren Betrieb einer Anwendung. Deshalb gehören technische und nutzungsbezogene Dokumentation zum Entwicklungsprozess.
Repository, Versionshistorie, README, Handbuch und Changelog sollen denselben tatsächlichen Stand beschreiben. WordPress präsentiert diesen Stand verständlich; die technische Quelle bleiben jedoch das jeweilige Repository, vorhandene Tests und veröffentlichte Releases.
- Installations- und Betriebsanforderungen
- Rollen und Berechtigungen
- Funktionsumfang
- bekannte Grenzen
- Versions- und Kompatibilitätsangaben
- Änderungen zwischen Releases
- offene oder geplante Funktionen
Bezeichnungen wie „stabil“, „produktiv erprobt“ oder „produktionsreif“ verwende ich nur, wenn der jeweilige Status durch Tests, Dokumentation, Nutzung oder einen definierten Releasezustand belegt ist.
Die Projektkonfiguration definiert dafür bewusst abgestufte Statusbegriffe von „Konzept“ und „Prototyp“ bis „Stabil“ und „Archiviert“.
Arbeitsweise an konkreten Projekten
Die einzelnen Projektseiten zeigen, wie diese Grundsätze in unterschiedlichen Praxisfeldern angewendet werden. Dort werden Problemstellung, Architektur, Rollen, Status, eigener Anteil und bekannte Grenzen projektbezogen dargestellt.