Individuelle Software

Die Entwicklung maßgeschneiderter Software beginnt nicht mit einer Wunschliste. Wir untersuchen, wer handelt, wodurch ein Ablauf startet, welche Informationen benötigt werden, wo eine Entscheidung fällt, welcher Zustand sich ändert, wer einen Sonderfall übernimmt und woran die Erledigung zu erkennen ist. Dasselbe Problem lässt sich womöglich lösen, indem ein unnötiger Schritt entfällt, Daten berichtigt, eine vorhandene Plattform sauber eingerichtet oder zwei Systeme verlässlich verbunden werden. Programmierung ist eine Möglichkeit, keine vorweggenommene Antwort.

Die Make-or-buy-Entscheidung berücksichtigt verfügbare Produkte, Lizenz- und Ausstiegsbedingungen, Konfigurationstiefe, Schnittstellenzugang, Sicherheit, Barrierefreiheit, Datenportabilität, Anbieterbindung und die gesamten Betriebskosten. Für einen üblichen Prozess kann der Kauf deutlich vernünftiger sein. Eine Erweiterung bietet sich an, wenn die Plattform grundsätzlich passt, aber ein eigener Ablauf fehlt. Individualsoftware rechtfertigt ihren Wartungsaufwand erst dann, wenn ein belegter Prozess, ein besonderes Domänenmodell, eine Integrationsgrenze oder die Produkterfahrung mit Standardmitteln nicht sauber genug umzusetzen ist.

Die schriftliche Produktgrenze benennt Nutzer, Rollen, Abläufe, Funktionen, Daten, Berichte, Integrationen, Umgebungen, Geräte, Sprachen, Barrierefreiheitsziel, Migration, Schulung, Abnahme, Release, Rechte und Verantwortung nach dem Start. Discovery, Prototyp, Minimum Viable Product, Produktionsversion und laufender Betrieb werden getrennt behandelt. Ein MVP ist das kleinste stimmige Produkt, mit dem sich ein benanntes Risiko prüfen lässt. Es ist weder das vollständige Zielbild zum Niedrigpreis noch eine Begründung, elementare Sicherheits- und Wiederherstellungsfunktionen auszulassen.

Vor der Prüfung von Umfang und Abhängigkeiten versprechen wir weder Nutzung, Umsatz, Effizienz noch Kompatibilität, Sicherheit, Verfügbarkeit oder einen festen Endtermin. Prüfen lässt sich konkretes Verhalten: Eine benannte Rolle erledigt eine definierte Aufgabe, die richtige Regel ändert den erwarteten Zustand, Daten lassen sich abstimmen, unzulässige Aktionen werden verweigert und der Betrieb erkennt und behebt einen vereinbarten Fehler. Geschäftliche Wirkung wird nach dem Start gegen einen dokumentierten Ausgangswert gemessen, nicht der bloßen Existenz einer Anwendung zugeschrieben.

Ein wartbares System verwendet die Begriffe des tatsächlichen Geschäfts. Gemeinsam mit den Verantwortlichen definieren wir Akteure, Datensätze, Ereignisse, Regeln, Zustände und Invarianten. Ähnlich klingende Begriffe werden getrennt, sobald sie unterschiedliche Pflichten tragen; Lead, Kunde, Konto, Vertrag und Nutzer sind keine Synonyme. Für einen Zustandswechsel stehen Befugnis und Nachweis fest. Dieses Domänenmodell verbindet Oberflächentexte, Daten, APIs, Tests, Berichte und spätere Betriebsentscheidungen.

Für jedes erhebliche Datenfeld werden führendes System, Verantwortlicher, Schutzbedarf, Aktualität, Validierung, Änderungsrecht, Aufbewahrung und Konfliktregel festgelegt. Abgeleitete Werte behalten eine nachvollziehbare Formel und einen Quellenzeitpunkt. Import und Migration umfassen Zuordnung, Umwandlung, abgewiesene Datensätze, Abstimmung und Rückfallweg. Eine erfolgreiche Dateiübertragung belegt keine richtige Migration. Produktivdaten gelangen nur mit einer genehmigten, angemessenen Schutzregel in Entwicklungs- oder Testumgebungen.

Die Architektur richtet sich nach den tatsächlichen Bedingungen: Transaktionsgrenzen, erwartete Last, Latenz, Offline-Bedarf, geografische und vertragliche Vorgaben, Wiederherstellungsziele, Fähigkeiten des Teams, Bereitstellungsmodell und Änderungsaufwand. Eine gut gegliederte Anwendung kann sicherer und leichter zu betreiben sein als vorschnell eingeführte Microservices. Für bestimmte Bausteine ist ein Managed Service verantwortungsvoller als eine Eigenentwicklung. Wir halten Entscheidung und verworfene Varianten fest, damit spätere Teams wissen, wann eine Neubewertung nötig wird.

Integrationen werden als Verträge behandelt. Für API, Webhook, Queue oder Dateiaustausch sind Richtung, Identität, Version, Schema, Validierung, Autorisierung, Idempotenz, Limits, erwartete Verzögerung, Wiederholung, Reihenfolge, Fehlerbehandlung, Beobachtbarkeit und Eigentümer definiert. OpenAPI kann eine HTTP-Schnittstelle beschreiben; die geschäftliche Bedeutung und Zuverlässigkeit legt das Dokument allein nicht fest. Anbieter- und Verbraucherverhalten wird an der Grenze geprüft, auch bei Teilausfall, doppelter Lieferung, veralteten Daten und unerreichbaren Abhängigkeiten.

Die Lieferfolge orientiert sich an Risiko und nutzbarem Ergebnis. Ein vertikaler Schnitt verbindet Oberfläche, Regel, Daten und Integration für einen wirklichen Ablauf. Falsche Annahmen fallen so früher auf als bei getrennten Paketen aus Screens und Backend-Aufgaben. Der Backlog hält Zweck, Abnahme, Abhängigkeiten und offene Entscheidungen fest. Ein Designprototyp beantwortet Interaktionsfragen, ein technischer Spike reduziert Ungewissheit; beides ist noch keine produktionsreife Software. Vorführungen enthalten auch Fehler- und Berechtigungsfälle.

Quellcode liegt in einem vereinbarten Repository mit Review, nachvollziehbaren Änderungen und geschützten Release-Regeln. Die Prüfstrategie folgt dem Risiko: Unit- und Komponententests für Regeln, Vertragstests für Schnittstellen, Integrationstests für Systemgrenzen, Ende-zu-Ende-Tests für zentrale Abläufe sowie Migrations- oder Lasttests, wenn sie erforderlich sind. Ein bestandener Test ist ein Nachweis für die getestete Version und Umgebung. Er beweist nicht, dass keinerlei Fehler oder Schwachstelle mehr existiert.

Build und Release trennen Code von umgebungsspezifischer Konfiguration. Geheimnisse werden nicht eingecheckt; Berechtigungen, Rotation und Notfallzugang sind geregelt. Abhängigkeiten werden bewusst ausgewählt, passend festgeschrieben, geprüft und über einen kontrollierten Weg aktualisiert. Unterschiede zwischen Entwicklung, Test, Staging und Produktion sind dokumentiert. Continuous Integration und Deployment mindern manuelle Abweichungen nur dann, wenn Freigaben, Herkunft der Artefakte, Schutz der Umgebungen und Rückfall ebenso eindeutig sind.

Änderungen bleiben klein genug für Review und Wiederherstellung. Bei Datenbankänderungen werden alte und neue Anwendungsversionen, Backfill, Validierung und die Grenzen eines Rollbacks berücksichtigt. Feature-Schalter, gestufte Freigabe oder Parallelbetrieb kommen dort zum Einsatz, wo sie das Risiko tatsächlich senken. Leistung wird an repräsentativen Abläufen und Serviceindikatoren gemessen, nicht nur an synthetischen Punktwerten. Entscheidungen, Ausnahmen, bekannte technische Schulden und Restrisiken bleiben bis zur Abnahme sichtbar.

Sicherheitsanforderungen entstehen aus Nutzern, Daten, Aktionen, Vertrauensgrenzen und realistischen Missbrauchswegen. Das Bedrohungsmodell verfolgt Identität, Autorisierung, Eingaben, Geschäftslogik, Speicherung, Kommunikation, Administration, Abhängigkeiten und Wiederherstellung. Das Secure Software Development Framework von NIST bietet eine gemeinsame Struktur, um sichere Entwicklung in unterschiedliche Lebenszyklen einzubinden. Wir benennen die angewandten Praktiken und Nachweise; die Bezugnahme auf SSDF ist keine unabhängige Zertifizierung sämtlicher Aufgaben oder Ergebnisse.

Bei Webanwendungen kann ein vereinbarter Umfang des OWASP ASVS, einschließlich Version und Level, allgemeine Sicherheitsformulierungen in prüfbare Anforderungen überführen. Anwendbare Punkte werden mit Entwurf, Umsetzung und Tests verknüpft. Geprüfte Bereiche, behobene wesentliche Feststellungen, Ausschlüsse und Restrisiken sind dokumentiert. Unabhängiger Penetrationstest, Zertifizierung, regulatorische Beurteilung, laufende Sicherheitsüberwachung und Incident Response bleiben gesonderte Leistungen, sofern sie nicht ausdrücklich beauftragt sind. Absolute Sicherheit wird nicht behauptet.

Datenschutz, Barrierefreiheit und internationale Nutzung gehören zur Produktdefinition. Datenminimierung, Aufbewahrung, Löschung, Protokolle, Testdaten, Analytik und Supportzugriff werden mit dem verantwortlichen Auftraggeber und dessen Beratung geklärt. Das vereinbarte WCAG-2.2-Ziel prägt Struktur, Tastaturbedienung, Fokus, Fehler, Statusmeldungen, Kontrast, Reflow, Authentifizierung und repräsentative Aufgaben; automatische Scans decken nur einen Teil ab. Sprachen werden als echte Oberflächen geprüft, einschließlich Rechts-nach-links-Darstellung, Daten, Namen, Zahlen und gemischter Schreibrichtung.

Zuverlässigkeit wird mit Serviceindikatoren beschrieben, die für Nutzer relevant sind. Verfügbarkeit, Antwortzeit, erfolgreiche Verarbeitung, Datenaktualität, Queue-Alter oder Wiederherstellung können je nach Ablauf verschieden wichtig sein. Ein SLI misst einen beobachteten Wert, ein SLO setzt ein internes Ziel, ein SLA begründet eine vertragliche Zusage mit festgelegten Folgen. Diese Begriffe sind nicht austauschbar. Ausfallarten, Monitoring, Backup, Restore, Kapazität und Grenzen von Abhängigkeiten stehen neben dem Ziel.

Die Abnahme arbeitet mit repräsentativen Rollen, Daten und Umgebungen. Je nach Produkt umfasst sie Sollablauf, ungültige Eingabe, verweigerte Aktion, doppelte Anfrage, ausgefallene Schnittstelle, verzögerten Job, unvollständige Migration, mobile und tastaturgestützte Nutzung, Lokalisierung, verlangsamten Betrieb und Wiederherstellung. Der Nachweis verbindet Anforderung, getestetes Artefakt und Ergebnis. Die Fehlerliste trennt Release-Blocker, akzeptierte Einschränkungen und spätere Verbesserungen. Eine Vorführung ist hilfreich, ersetzt aber keine schriftliche Abnahme.

Der Release-Plan benennt Artefakt, Umgebung, Konfiguration, Geheimnisse, Datenbewegung, Domain- und Zertifikatsänderungen, Kommunikation, Wartungsfenster, Entscheidungsbefugnis und Rückfall. Schritte mit möglichem Datenverlust oder Arbeitsausfall werden geprobt. Migrationssummen werden abgestimmt, Hintergrundprozesse und Integrationen beobachtet. Die Rückfallgrenze bleibt ehrlich: Eine bereits an ein Fremdsystem übermittelte Aktion oder irreversible Datenänderung kann eine fachliche Kompensation statt eines einfachen technischen Rollbacks erfordern.

Die Übergabe umfasst Repository- und Quellzugang, Rechte, Architektur- und Entscheidungsprotokolle, Domänenmodell, Datenwörterbuch, Schnittstellenverträge, Umgebungs- und Abhängigkeitsverzeichnis, Build- und Release-Weg, Tests, bekannte Risiken, Runbooks und Verwaltungsabläufe. Eigentum richtet sich nach dem unterzeichneten Angebot; Open-Source- und Drittkomponenten bleiben an ihre Lizenzen gebunden. Ein Quellcodepaket ohne reproduzierbaren Build, Kontoinhaberschaft und Betriebskontext ist keine vollständige Übergabe.

Der laufende Betrieb ist eine eigene, schriftlich geregelte Verantwortung. Er kann Monitoring, Incident- und Problembehandlung, Pflege von Abhängigkeiten, Reaktion auf Schwachstellen, Backups, Wiederherstellungstests, Kapazität, Kostenprüfung und ein bestimmtes Änderungskontingent umfassen. Zeiten, Kanäle, Reaktionserwartungen, Eskalation und Ausschlüsse sind klar. Aus einem Entwicklungsauftrag entstehen nicht automatisch Rund-um-die-Uhr-Betreuung, feste Reaktionszeit, Uptime-Zusage, unbegrenzte Änderungen oder unbefristeter Support.

KI-Funktionen erhalten eine eigene Grenze. Modell und Wissensquellen, Datenweg, Rechte, Evaluationsfälle, menschliche Entscheidungshoheit, Ablehnung und Fallback, Protokollierung, Kosten und Änderungskontrolle werden benannt. Ein Modell kann Suche, Klassifikation, Extraktion oder Entwürfe unterstützen. Es wird jedoch nicht zur unsichtbaren führenden Quelle und trifft standardmäßig keine unumkehrbare, folgenreiche Entscheidung allein. Genauigkeit, Verfügbarkeit und Anbieterverhalten werden im vereinbarten Kontext gemessen, nicht allgemein versprochen.