Gerade startet eine Diskussion in der functional safety-Blase, ob es und wenn wie es möglich ist vorgegebene Wege abzukürzen oder zu umgehen.
Ursache scheint zu sein, dass in den Entwicklungsprojekten zusehends erkannt wird, dass die Funktionale Sicherheit mit ihren Vorgaben sehr zeitintensiv, dokumentationslastig und teuer ist, also der Aufwand die Kosten, Termine und Ergebnisqualitäten des Projekts negativ beeinflusst, schlicht verursacht.
Das ist allerdings der größte Unsinn aller Zeiten
und dient lediglich dem Zweck endlich wieder einen Schuldigen gefunden zu haben.
Termine werden eh in 98% der Projekte nicht eingehalten!
Budgets werden eh in 80% der Projekte überschritten!
Ergebnisqualität ist eh in 97% der Projekte nicht die mit den Stakeholdern vereinbarte!
Und die Ressourcenplanung ist in nahezu jedem Projekt daneben!
Da dies die Faktoren sind, welche über Erfolg oder Scheitern eines Projektes richten, sind demnach knapp 94% aller Projekte gescheitert; und dazu bedarf es gar keiner Funktionalen Sicherheit. Das bekommen die im Projekt auch so hin; versprochen.
Nun aber die Denkweise, weil die Funktionale Sicherheit ja relativ neu im Projekt zu verankern ist (als nächstes wird es dann die Cyber-Security-Jungs treffen, so meine Prognose; let´s see), dass genau dies zu dem Schlamassel führt; also im gesamten Projekt; bei allem was nicht passt.
Beispiel gefällig?
Es gibt keine Architektur und System Engineering braucht es ja schon einmal gar nicht; kostet doch nur Zeit und Geld; und zeigt nicht SOFORT Ergebnisse.
Es wird dann also ein Riesenaufwand in Abstimmungsrunden, Meetings, Diskussionen zwischen den einzelnen Fakultäten, usw. betrieben, um die notwendigen Klärungen und Zusammenhänge hinzubekommen; natürlich ohne jemanden, der den Hut auf hat dafür. Das Ergebnis wird ein heilloses Durcheinander, keiner blickt mehr durch, jeder hat mit jedem etwas abgestimmt und vereinbart und in zahllosen Dokumenten, Meeting Minutes, Protokollen, LOPs und OPLs aufgeschrieben.
Und da kommt der FuSi-Engineer jetzt daher und verlangt ´ne sauber spezifizierte Architektur. Und das auch noch mit einer spezifizierten Notation. Der Doof. Also basteln wir uns jetzt ´ne Pseudo-Architektur zusammen, die vorne und hinten nicht passt. Und wer hat die verursacht? Genau, der FuSi-Man. Der war´s!
Die Standards zur funktionalen Sicherheit verlangen nichts Neues, insbesondere nicht in Prozess oder Organisation. Insbesondere in der Softwareentwicklung sind die Anforderungen genau das, was auch andere Standards zur Softwareentwicklung fordern (schau mal bei IEEE).
Aber nun sollen wir also in den Entwicklungsprojekten mit Konsequenz und Disziplin den vielen, vielen Standards folgend (by the way: da haben sich jeweils Spezialisten Gedanken gemacht und überlegt, wie es am Besten geht) die Projekte mit Sinn und Verstand durchführen; genau der Reihe nach; wie bei einem Kochrezept;
geht´s noch, das wär ja noch schöner, bei uns geht das aber so nicht weil wir anders sind, da könnte ja jeder kommen, da haben wir ja noch nie so gemacht.
Der Clou: wenn ich darauf hinweise, antworten alle “Ja, stimmt, Du hast Recht.” und machen genau so weiter.
Also passiert alles wie immer und es ändert sich nichts, außer das jetzt der FuSi-Man der Schuldige ist (war ganz früher der Quality-Man, dann gab´s den SPICE-Man, den sonstwas-Man). Überlegen wir also, wie wir den in die Schranken verweisen können und genauso weiter machen können wie bisher. Lassen wir doch die Tests weg, und die Dokumentationen werden wir wohl stark vereinfachen müssen, und Sicherheitsmechanismen haben wir doch eh gemacht, warum das auch noch aufzeigen oder nachweisen.
Was mich bei der Diskussion so extrem stört ist die Tatsache, dass wir früher bei der Quality nur über die Produktperformance gesprochen haben, ob der Kunde also zufrieden ist und wiederkommt oder eben nicht. Hier bei der Funktionalen Sicherheit reden wir darüber, ob wir gegebenenfalls jemanden töten oder nicht.
Und das ist aus meiner Sicht etwas ganz anderes!
Mit Kalkül, mit Vorsatz, um kurzfristig ein Projekt zu retten und den Gesichtsverlust (den eigenen, meist bei den Projektverantwortlichen und deren Managern) zu minimieren.
Da frage ich mich ernsthaft, welche Werte herrschen da heute vor selbst in den niederen Rängen der Organisationshierarchien (das ab einer bestimmten Hierarchie-Ebene Korruptheit, Egozentrik und Werteverfall system-immanent ist, ist klar, sonst wäre man schließlich nicht dort), dass es egal ist, ob jemand zu schaden kommen könnte oder nicht.
Und besonders entsetzlich empfinde ich, dass derartige Diskussionen von “Experten” der Funktionalen Sicherheit mit getrieben werden, aber zu diesen “Experten” habe ich mich ja in einem früheren Blog schon positioniert.
Habe übrigens gerade erst ein Projekt, in dem ich involviert war, abgebrochen, da dort die Funktionale Sicherheit komplett gefakt wurde/ werden sollte.