Funktionale Sicherheit und agile Entwicklungsmethoden – Ein unüberbrückbarer Gegensatz (Teil 1)?
Als Motivation für den Beitrag dienen mir folgende Fragestellungen:
- Sie wenden agile Entwicklungsmethoden an und müssen zukünftig Funktionale Sicherheitsanforderungen erfüllen? Unter welchen Voraussetzungen funktioniert das?
- Sie entwickeln sicherheitskritische Embedded Systeme in Branchen wie der Bahnindustrie, der Luftfahrt, der Automobilbranche, der Medizintechnik oder der Automatisierungstechnik. Ist es möglich in so einem Umfeld agile Entwicklungsmethoden einzusetzen?
Im ersten Teil dieses Blogs betrachten wir die jeweiligen Pole (Agile Entwicklung; FuSi Entwicklung) für sich. Im zweiten Teil diskutieren, wir, was zu beachten ist, wenn die beiden vermeintlich sehr getrennten Welten zusammengebracht werden sollen.
Das agile Manifest und die 12 Prinzipien im Wortlaut:
Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:
- Individuen und Interaktionen mehr als Prozesse und Werkzeuge
- Funktionierende Software mehr als umfassende Dokumentation
- Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
- Reagieren auf Veränderung mehr als das Befolgen eines Plans
Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.
Die nachfolgenden 12 Prinzipien stehen hinter dem agilen Manifest:
- Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.
- Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.
- Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.
- Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.
- Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.
- Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.
- Funktionierende Software ist das wichtigste Fortschrittsmaß.
- Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.
- Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.
- Einfachheit — die Kunst, die Menge nicht getaner Arbeit zu maximieren — ist essenziell.
- Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.
- In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.
Sowohl aus dem agilen Manifest, als auch den 12 Prinzipien ist zu erkennen, dass der Kunde im Mittelpunkt fast aller Betrachtungen steht und dass die Verfasser motivierte Einzelpersonen in performanten und funktionierende Teams voraussetzen. Ebenso ist zu berücksichtigen, dass die Ursprünge der agilen Entwicklung im IT-Umfeld zu finden sind. Die Entwicklung von embedded Software stand nicht im Fokus.
Grundprinzipien der Funktionalen Sicherheit
Was Funktionale Sicherheit grundsätzlich ist, habe ich im Blog Beitrag „Funktionale Sicherheit – Was ist das?“ betrachtet. Dort ging es vorwiegend um eine Abgrenzung und Definition der Thematik. Nun wollen wir uns mehr auf die zugrundeliegenden Prinzipien konzentrieren.
Der grundlegendste Aspekt dabei ist, die Feststellung dass es bisher keine Methode gibt Software garantiert fehlerfrei zu entwickeln. Auf der Anderen Seite steht in Deutschland das Produkthaftungsgesetz. Danach ist jeder der ein Produkt in den Verkehr bringt, für dessen korrekte Funktionsweise haftbar.
Für software-intensive Produkte ergibt sich daraus ein zunächst nicht auflösbarer Konflikt. Eine fehlerfreie Herstellung ist grundsätzlich ausgeschlossen. Als Hersteller wiederum bin ich für diese Fehler haftbar.
Beispiel: Auto
Übrigens, ein ganz aktuelles Beispiel dafür ist das autonome Fahren mit dem Auto. Das Risiko für eventuell auftretende Schäden, wird sich eindeutig vom Fahrer auf den Hersteller verlagern. Das ist zunächst eine „einfach“ Verschiebung des Risikos, mit allerdings weitreichenden Folgen. Nachdem aktuellen Stand der Diskussion, wird eine gesellschaftlich und wirtschaftlich akzeptierte Antwort auf diese Haftungsfrage über Erfolg oder Misserfolg der Einführung dieser Technologie entscheiden.
Um den grundsätzlichen Konflikt aufzulösen, wurden nun Standards und Normen entwickelt, mit dem Ziel die Anzahl der Fehler in einem Software-Produkt auf ein akzeptables Minimum zu reduzieren. Dafür wurde der Begriff der Funktionalen Sicherheit geprägt. Wenn ich als Hersteller nachweisen kann, dass ich die für mein Produkt relevante Funktionale Sicherheitsnorm eingehalten habe, dann habe ich gute Chancen auch im Falle eines Gerichtsverfahrens nachweisen zu können, dass ich den Stand der Wissenschaft und Technik erfüllt habe und mir somit kein schuldhaftes Verhalten vorzuwerfen ist.
Gleichzeitig bedeutet dies, dass in einer FuSi Entwicklung die Themen: Einhaltung von Prozessen, Verifikation und Dokumentation sehr wichtig sind. In sehr kritischen Projekten kann das folgende Verteilung der Tätigkeiten im Projekt bedeuten:
Nachdem Betrachten der Wesentlichen Prinzipien der agilen Welt und der FuSi Welt, werde ich Teil 2 dieses Blogs die sich daraus ergebenden Konflikte diskutieren, die vorhanden sind, wenn man beide Welten miteinander vereinigen will. Genauso wichtig sind mir aber die Chancen zu diskutieren die sich aus einer Kombination der agilen und der FuSi Welt ergeben.
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).
Hinterlasse einen Kommentar
An der Diskussion beteiligen?Hinterlasse uns deinen Kommentar!