Das Papierkram-Problem
Compliance-Frameworks — ASPICE, ISO 26262, ISO 21434, der CRA — verlangen im Kern dasselbe: nachverfolgbare Nachweise, dass Anforderungen, Design, Code und Tests zusammenpassen. Die meisten Teams erzeugen diese Nachweise von Hand, in Word und Excel, im Nachhinein. Das ist langsam, veraltet in dem Moment, in dem sich der Code ändert, und Ihre besten Entwickler hassen jede Minute davon.
Die Lösung: Compliance wie Code behandeln
Ich implementiere Docs-as-Code-Toolchains — rund um sphinx-needs — bei denen Anforderungen, Safety-Ziele, Bedrohungsszenarien und Testergebnisse als strukturierte, verknüpfte Objekte in der Versionsverwaltung liegen. Der Nachverfolgbarkeits-Graph wird generiert, nicht gepflegt. Die Audit-Nachweise fallen aus der Arbeit ab, die Ihre Entwickler ohnehin leisten.
Was ich baue
- sphinx-needs-Graphen, die Anforderung → Architektur → Code → Test verknüpfen
- Automatisierte Nachverfolgbarkeits- und Coverage-Reports, die bei jedem Commit neu entstehen
- Safety-Case- und Cybersecurity-Case-Tooling, damit ISO-26262- und -21434-Argumente aktuell bleiben
- In CI integrierte Gates, damit Nachweise nie unbemerkt vom echten Code abdriften
- Migration weg von handgepflegten Word-/Excel-/DOORS-Workflows
Der Nutzen
Ihre Entwickler schreiben Rust und C, keine Dokumente. Ihr Assessor bekommt einen lebendigen, abfragbaren Nachweis-Graphen statt eines Stapels veralteter Dateien. Die Nachverfolgbarkeit, die ASPICE und die Safety- und Security-Normen verlangen, wird zum Nebenprodukt guter Ingenieursarbeit — kein separates Projekt, das mit dem Ausliefern konkurriert.
Für Releases, die eine formale, evidenzbasierte Vertrauensargumentation brauchen, geht das nahtlos ins Trustable Software Framework über.