Produkthaftung und agile Praktiken und Prinzipien

Gesetzliche Vorgaben zur Produkthaftung haben zur Entwicklung von Prozessstandards geführt, die  bei der Entwicklung von sicherheitskritischen Produkten eingehalten werden müssen.  Wie vertragen sich agile Praktiken und Prinzipien mit den Anforderungen solcher Standards?

Um dieser Frage nachzugehen, habe ich die wichtigsten agilen Methoden, Praktiken und Prinzipien in einer Grafik zusammengetragen (Abbildung 1).

Abbildung 1: Agile Methoden, Praktiken und Prinzipien

Danach habe ich beispielhaft das Prozessmodell des Standards ISO 26262, der Grundlage für sicherheitskritische Entwicklungen im Automobilbereich ist, in einem weiteren Schaubild dargestellt und untersucht, in welchen Bereichen agile Methoden sinnvoll einsetzbar sind bzw. nach meiner Kenntnis erfolgreich eingesetzt wurden.  Das Ergebnis sehen Sie in Abbildung 2.

Abbildung 2: ISO 26262 und agile Methoden

In einem dritten Schritt habe ich untersucht, welche agilen Praktiken und Prinzipien der Einhaltung eines Prozessstandards wie der ISO 26262 widersprechen,  welche neutral sind  und welche in Hinsicht auf Safety  sich positiv auswirken können. Diese  Methodenelemente habe ich in der ersten Grafik  entsprechend markiert, das Ergebnis sehen Sie in Abbildung 3.

Abbildung 3: Agile Praktiken und Prinzipien bzgl. Safety

Das geht gar nicht

Die folgenden Kernprinzipien der agilen Gemeinde stehen im Widerspruch zu Anforderungen, die durch gesetzliche Vorgaben an die Entwicklungsprozesse für sicherheitskritische Produkte gestellt werden:

  1. Sich selbst organisierende Teams
  2. Die Betonung von Code und Test vor allen anderen Entwicklungsprodukten
  3. Anforderungen hauptsächlich in Form von Szenarien darzustellen
  4. Das Minimieren unnötiger Funktionalität
  5. Das Akzeptieren von Änderungsanforderungen in späten Entwicklungsphasen

Wie lässt sich diese provozierende Liste begründen?  Ich denke, am einfachsten durch ein Szenario! Stellen Sie sich vor, aufgrund eines Fehlers in einem in Ihrem Verantwortungsbereich entwickelten Produkt sind Menschen zu Schaden gekommen sind.  Sie stehen nun vor Gericht und müssen nachweisen, dass sie alles Ihnen Mögliche getan haben, einen solchen Fehler zu vermeiden.

Sie sagen dem Richter also: „Dafür war das Team zuständig, die haben sich selbst organisiert.“ Dann zeigen Sie ihm den Code und die Tests. Leider fehlt  Ihnen das Protokoll der Besprechung, in der Sie auf den speziellen Safety Case hingewiesen haben, der durch die Tests nicht abgedeckt wurde und der dann für die Katastrophe verantwortlich war.

Ihr Rechtsanwalt wird sich bemühen, beim Richter Verständnis dafür zu wecken, dass ihr Fokus auf dem Business Value lag,  also darauf, dem Kunden Nutzen zur Verfügung zu stellen und nicht, ihn vor Schaden zu bewahren.

Und er wird versuchen, das Gericht zu überzeugen, dass Ihre absolut wasserdichten Tests dafür gesorgt haben, dass die kleine Änderung vor dem letzten Sprint mit Sicherheit keine Fehler in zuvor entwickelte Funktionalität eingebracht haben konnte.

Soweit zu dieser szenario-basierten Begründung meiner Liste. Es gibt noch andere Formen der Begründung, lesen Sie z.B. zum ersten Punkt Blog-Eintrag zu  selbstorganisierenden Teams.

 

 

 

Bitte folgen Sie uns:
Agil und Safety: Die kompatiblen Praktiken und Prinzipien

Schreibe einen Kommentar

Social media & sharing icons powered by UltimatelySocial