Viele verbinden mit der Umsetzung von Funktionaler Sicherheit, viel Formalismus, und unnötig umfangreiche Dokumentation und viele Prozesse mit einem hohen Anteil an theoretischen Überbau. Und ja es gibt solche Projekte sehr oft und in jeder Industrie. Ich habe die Erfahrung gesammelt das solche Projekte oft aber nicht besonders effizient sind, wenn man sie an der echten Umsetzung von wirksamen Sicherheitsmaßnahmen misst. Der nachfolgende Blogbeitrag geht der Frage nach, warum das so ist? Zudem ist der Beitrag ein Plädoyer für eine pragmatische Softwareentwicklung in Projekten der Funktionalen Sicherheit.

Woher kommt der Formalismus?

Zunächst mal sind es die Standards, wie ISO26262, IEC61508, DO178, EN50128, die dazu verleiten recht formal vorzugehen. Hinter diesen Standards steht zumindest in Deutschland das Produkthaftungsgesetz. D.h. im Schadensfall ist es sehr wahrscheinlich, dass man als Hersteller beweisen muss, dass man alles getan hat um Fehler während der Produktentwicklung und Produktion zu vermeiden. In einer solchen Situation helfen mündliche Absprachen wenig für die Beweisführung. Nur dokumentierte, korrekte Information ist hier wirklich hilfreich. Dieser Punkt ist sehr ernst zu nehmen und er lässt sich auch durch das beste pragmatische Vorgehen nicht eliminieren. Ein gewisser Formalismus und eine damit einhergehende Dokumentation, liegt in der Natur der Sache und lässt sich nicht vermeiden. Daraus lässt sich ableiten, dass ein Projekt der Funktionalen Sicherheit grundsätzlich teurer (Richtwert: 2-3mal teurer) ist als ein Projekt bei dem das Thema keine Rolle spielt.

Muss man sich also mit dem Formalismus abfinden und sich ihm ergeben?

Plädoyer für eine pragmatische Softwareentwicklung!

Bevor ich diese Frage beantworte möchte ich mich zunächst mit dem Begriff des Pragmatismus beschäftigen. Was bedeutet Pragmatismus und welche Voraussetzungen müssen gegeben sein damit man ihn sinnvoll anwenden kann?

Nun pragmatisches Vorgehen in der Software Entwicklung bedeutet, dass man immer wieder einzelne Aspekte gegeneinander abwägt und einen Kompromiss findet. Eine unabdingbare Voraussetzung für so ein Vorgehen ist aber, dass man Erfahrung im Thema hat. Nur so kann man verantwortungsvolle Kompromisse im Sinne der Safety in einem Abwägungsprozess eingehen.

Als Beispiel möchte ich hier die Planungsdokumentation in einem Funktionalen Sicherheitsprojekte anführen. Wenn ich diese Dokumente umfangreich gestalte, kann ich das Vorgehen mit einem hohen Detailgrad sehr genau festlegen. Das fördert die Eindeutigkeit der Vorgehensweise.

Andererseits zeigen die Projekte immer wieder, dass zu viele Details in Planungsdokumenten kontraproduktiv sind, da die Übersicht verloren geht. Der eigentliche rote Faden, der durch so ein Projekt durch die Planungsdokumente vorgegeben werden sollte geht verloren. Dies ist in Summe der Funktionalen Sicherheit deutlich abträglicher als die ggf. fehlenden Details. Mit dieser Erfahrung erstellt man Planungsdokumente die in kompakter Form das Wesentliche Vorgehen im Projekt beschreiben. In der Regel ist der Änderungsaufwand für solche Dokumente im Projektverlauf auch deutlich geringer, was ein weiterer Vorteil ist.

Ähnliches Effekte kann man auch bei den technischen Inhalten des Safety Projektes beobachten. Mehr als 2 Ebenen von Requirements wird in so gut wie keinem Projekt benötigt (Ausnahme ist normbedingt die Luftfahrt). Ebenso erreichen Projekte die auf formal dokumentierte umfangreiche Unittests verzichten in der Regel mehr im Sinne der Safety als Projekte die hier einen großen Aufwand treiben.

Schon diese Beispiele beantworten die Frage ob man sich mit dem Formalismus in Funktionalen Sicherheitsprojekten abfinden muss ganz klar: NEIN. Statt umfangreichem Formalismus sollte man viel mehr den Aufwand in eine ausgewogene Strategie für die Abwicklung solcher Projekte stecken. Damit erreicht man im Sinne der Safety viel mehr!

Fazit

Zusammenfassend lässt sich sagen, dass ein gewisser Formalismus in Funktionalen Sicherheitsprojekten unumgänglich ist, da es anderes nicht möglich ist sich im Sinne des Produkthaftungsgesetz abzusichern, sodass man im Schadensfall nachweise kann das man alles getan hat um die Anzahl der Fehler zu minimieren.

Andererseits darf der Formalismus kein Selbstzweck im Projekt werden. Viel mehr im Sinne der Safety erreicht man für sein Projekt optimal abgestimmte Strategien ausarbeitet. Optimal gelingt dass wenn man eine entsprechende Erfahrung dafür mitbringt.

Als toller neben Effekt lassen sich damit dann die Kosten für Safety Projekte sinnvoll begrenzen. Man erreicht ein optimales Kosten/Nutzenverhältnis.

Ihre individuellen Fragen zur Funktionalen Sicherheit beantworten wir gerne in einem ersten, kostenlosen 30min Beratungsgespräch!
Vereinbaren Sie gleich einen Termin: Eine kurze Mail an info[at]heicon-ulm.de genügt, oder greifen Sie gleich zum Telefonhörer: +49 (0) 7353 981 781 (Mo bis Fr 08:00 – 18:00Uhr).