Was bedeutet „validierbare Softwareentwicklung“?

„Unsere Software ist validierbar“ steht in vielen Angeboten. Der Satz ist selten falsch, aber fast immer inhaltsleer – denn validierbar ist streng genommen jede Software, wenn man genug Aufwand hineinsteckt. Interessant wird die Aussage erst, wenn sie beantwortet, mit welchem Aufwand ein Eignungsnachweis möglich ist und was dafür bereits vorbereitet ist.

1. Die falsch gestellte Frage

Validierbarkeit ist keine Eigenschaft, die man einem Produkt ansieht. Sie ergibt sich aus dem Zusammenspiel dreier Dinge: einem klar definierten Verwendungszweck, einem Systemverhalten, das sich zuverlässig wiederholen lässt, und Artefakten, die belegen, dass geprüft wurde. Fehlt eines davon, wird Validierung nicht unmöglich – nur teuer.

2. Validiert, validierbar, verifiziert

Die dritte Zeile ist die einzige, die eine Aussage über ein Produkt vor seinem Einsatz erlaubt. Sie ist damit die einzige, die ein Anbieter überhaupt treffen kann – und auch nur in dieser Form.

3. Fünf strukturelle Voraussetzungen

1. Anforderungen mit Kennung und Akzeptanzkriterien. Ohne Bezugspunkt gibt es nichts zu validieren. Eine Anforderung, die sich nicht testen lässt, verhindert den Nachweis unabhängig von der Technik.
2. Explizite Struktur statt impliziter Konvention. Datenmodell, Rollen, Rechte und Validierungsregeln müssen benennbar und vergleichbar sein – nicht über zwanzig Klassen verteilt.
3. Reproduzierbare Artefakte. Aus demselben Stand muss dasselbe Ergebnis entstehen, sonst prüft man bei jedem Lauf etwas anderes.
4. Automatische, aufbewahrte Nachweise. Testergebnisse, Prüfungen und Freigaben müssen dem exakten Stand zugeordnet bleiben.
5. Kontrollierte Änderung. Ohne bewertete Änderungen verfällt jeder einmal geführte Nachweis mit dem nächsten Release.

4. Determinismus und Reproduzierbarkeit

Der am häufigsten unterschätzte Punkt. Ein System, das sich in gleicher Konfiguration unterschiedlich verhält, lässt sich nicht sinnvoll prüfen – jeder Testlauf wäre eine Einzelbeobachtung. Praktische Konsequenzen:

• Builds aus einer versionierten Definition, nicht aus dem Zustand einer Maschine.
• Abhängigkeiten mit festgeschriebenen Versionen, nicht mit gleitenden Bereichen.
• Konfiguration als Artefakt, nicht als manuell gepflegte Umgebung.
• Zeit-, Zufalls- und Sortierabhängigkeiten im Code bewusst behandeln.

Der Einsatz von KI in der Entwicklung ändert daran nichts: Nicht der Entstehungsvorgang muss reproduzierbar sein, sondern das ausgelieferte Artefakt. Ein Modell darf zweimal unterschiedlich formulieren – der geprüfte und freigegebene Stand ist trotzdem eindeutig.

5. Was eine Plattform beitragen kann

Eine Entwicklungsplattform kann Validierbarkeit nicht herstellen, aber erheblich verbilligen. Beitragen kann sie:

• explizite Modelle für Daten, Rollen, Rechte und Validierungen,
• Historisierung und nachvollziehbare Konfigurationsänderungen,
• reproduzierbare Builds aus einer versionierten Projektdefinition,
• standardisierte, bereits erprobte Basisfunktionen statt projektspezifischer Eigenbauten,
• auswertbare Protokolle über Delivery und Zielumgebung.

Der Effekt ist ein doppelter: Weniger individuell entwickelte Funktionalität bedeutet weniger, das projektspezifisch nachgewiesen werden muss – und die verbleibende Nachweisarbeit wird durch vorhandene Artefakte leichter. Wie CodamAI das abbildet, steht auf der Feature-Seite.

6. Was die Organisation leisten muss

Der Rest ist und bleibt organisatorisch – und lässt sich an kein Produkt delegieren:

• Verwendungszweck festlegen und abgrenzen,
• Risiken bewerten und daraus die Prüftiefe ableiten,
• Validierungsumfang planen und freigeben,
• Rollen und Verantwortlichkeiten benennen,
• Abweichungen bewerten und dokumentieren,
• den validierten Zustand über Änderungen hinweg halten.

Deshalb ist die zulässige Formulierung eines Anbieters immer eine unterstützende: Eine Plattform kann in validierungssensitiven Prozessen eingesetzt werden, sofern projektspezifische Anforderungen umgesetzt und validiert werden. Alles darüber hinaus wäre eine Zusage, die niemand einlösen kann.

7. Woran Validierbarkeit scheitert

• Unklarer Verwendungszweck. Ohne ihn ist jede Prüftiefe beliebig – und damit entweder zu teuer oder zu dünn.
• Verstreute Fachlogik. Wenn dieselbe Regel an vier Stellen implementiert ist, muss sie viermal nachgewiesen werden.
• Manuelle Umgebungen. „Auf dem Testsystem lief es“ ist kein Nachweis, wenn niemand den Zustand des Testsystems kennt.
• Nachweise in flüchtigen Werkzeugen. Was nach 30 Tagen gelöscht wird, existiert für die Prüfung nicht.
• Änderungen ohne Bewertung. Der einmal geführte Nachweis altert mit jedem Release.

Checkliste: Validierbarkeit vorbereiten

Fazit

„Validierbar“ ist kein Siegel, sondern eine Aufwandsaussage. Wer sie ernst meint, kann sie belegen: mit identifizierten Anforderungen, expliziter Struktur, reproduzierbaren Builds und Nachweisen, die beim Arbeiten entstehen.

Der angenehme Nebeneffekt ist, dass diese Punkte auch außerhalb regulierter Projekte gute Praxis sind. Validierbarkeit ist deshalb selten ein Sonderaufwand – meistens ist sie einfach ordentliche Ingenieursarbeit, konsequent zu Ende geführt.