Funktionale Sicherheit und agile Entwicklungsmethoden – Ein unüberbrückbarer Gegensatz (Teil 2)?
Funktionale Sicherheit und agile Entwicklungsmethoden: Im ersten Teil des Blog haben wir die Prinzipien der agilen Entwicklung und die der FuSi Entwicklung betrachtet. Darauf aufbauend, wollen wir nun im 2. Teil zum einen mögliche Konfliktfelder diskutieren, wenn man agil in FuSi Projekten entwickeln will. Ebenso beleuchten wir aber auch die Chancen die sich aus dieser innovativen Vorgehensweise ergeben können.
Wesentliche Prinzipien Konflikte zwischen FuSi Entwicklung und agiler Entwicklung:
Wenn man über einen erfolgreichen Einsatz von agilen Methoden in FuSi Projekten nachdenkt, muss man sich folgendes Faktum bewusst machen:
Daraus ergeben sich nachfolgende Punkte bei denen zumindest im ersten Blick sich widersprechende Ziele vorhanden sind:
Ziele FuSi Entwicklung | Ziele Agile Entwicklung |
Qualitative hochwertige Requirements | User Stories, sonst tendenziell wenig Dokumentation |
Dokumenten-intensive formale Tests | Flexible Tests mit wenig Dokumentation |
Anspruch darauf dass alle Fehler gefunden werden | Pareto Prinzip |
Nachweis der Unabhängigkeit zwischen Test und Entwicklung | Cross-Funktionale Teams |
Starke Interaktion/Abstimmung mit nicht agilen Teams wie HW und Mechanik Entwicklung | Reine Software Entwicklung unter Verwendung von Standard/PC Hardware |
Nicht zu verschiebende Termine wie Start of Production (SOP) geben den Rahmen vor | Das Team entscheidet in Zusammenarbeit mit dem Product Owner zusammen wann welche Funktion implementiert wird. Keine harten Terminvorgaben |
Die Konflikte ergeben sich aus der Tatsache, dass man in Funktionalen Sicherheitsprojekten Punkte erfüllen muss, gegen die man sich im Agilen Manifest bewusst entschieden hat. Aus Gründen der Nachweispflicht, im Fall der Fälle gegenüber der Staatsanwaltschaft, ist der Aspekt Dokumentation und Planung sehr umfangreich zu erfüllen. Verbale Kommunikation und Abstimmung lässt sich im Zweifel nicht mehr eindeutig nachweisen. Damit lässt sich die dynamische Interaktion und der umfangreiche Austausch zwischen Individuen, wie er in agilen Projekten im Mittelpunkt steht nicht so ohne weiteres umsetzen. Das gleiche gilt für den zweiten Punkt des agilen Manifests (Funktionierende Software wird mehr geschätzt als umfangreiche Dokumentation). In FuSi Projekten, ist eine funktionierende Software immer erforderlich, da es sich um den Einsatz in sicherheitskritischen Bereichen handelt. Aber die Dokumentation muss trotzdem sein – aus den oben genannten Gründen.
In besonders sicherheitskritischen FuSi Projekten wird bei der Anwendung von agilen Methoden auch der Nachweis der Unabhängigkeit zwischen Test und Entwicklung, ein nicht zu unterschätzende Herausforderung.
Chancen die sich aus einer sinnvollen Kombination beider Welten ergeben können:
Natürlich ergeben sich aber auch Chancen für die Entwicklung von Software, vor allem dann, wenn die FuSi Welt und die Agile Welt mit einem pragmatischen Ansatz zusammen gebracht werden.
Der wesentliche Vorteil ist dass durch die richtige Anwendung von agilen Vorgehensweisen, eine unglaublich mächtige und umfangreiche Transparenz in das Projekt gebracht wird. Verantwortlich dafür sind z.B. bei der Anwendung von Scrum, die Daily Team Meetings sowie die Planung kurzer (2 oder 3 Wochen) Sprints. In gut funktionierenden agilen Teams, ist auch die Kommunikation im Team und zwischen Team und Product Owner sehr intensiv.
Diese Punkte zusammen haben folgende Auswirkungen:
- fachliche Probleme werden praktisch sofort nach Ihrer Entstehung erkannt und im Team kommuniziert.
- Mehraufwände und die Auswirkungen auf die Planung werden durch die kurzen Planungszyklen sehr früh erkannt.
- Über den Product Owner ist das Management über alle relevanten Punkte zeitnah unterrichtet.
Neben den Vorteilen für das Projekt Management ergeben sich folgende positive Effekte auf die fachliche Arbeit im Projekt:
- Unklare Requirements werden schneller erkannt und die Klärung offener Fragen wird forciert
- Generelle Verbesserung der fachlichen Inhalte in der Dokumentation
- Tester und Entwickler arbeiten an gemeinsamen Ziel und damit viel mehr miteinader als gegeneinander
- Die Qualität der Tests kann deutlich erhöht werden.
Fazit:
Es ist unbestritten eine, nicht zu unterschätzende Herausforderung für Firmen und Projektleiter, agile Vorgehensweisen in FuSi Projekten anzuwenden. Wie bei allen Dingen die etwas ungewöhnlich oder neu sind, und nicht notwendigerweise dem Maintraim entsprechen, kann es viele Gegner und Bedenkenträger geben. Daher ist eine Entscheidung für so einen Weg in diesem Sinne als mutig zu bezeichnen.
Andererseits gibt es viele sehr gute Gründe die Anwendung von agilen Prinzipien und Methoden auch in sicherheitskritischen Projekten sprechen. Einige wesentliche habe ich in vorherigen Abschnitt genannt. Wenn also Ihr Projekt genau in diesen Bereichen Probleme hat, sollten Sie über die Einführung von agilen Methoden ernsthaft nachdenken.
Zum Schluss noch ein Wort zu V-Modell versus agile Methoden. Viele FuSi Standards setzen mehr oder weniger stark das V-Modell als Vorgehensmodell voraus. Die agilen Methoden sind aber weder ein Gegensatz, noch widersprechen Sie dem V-Modell direkt. Sinnvoll, im Sinne von FuSi-Projekten, angewandt, stellen Sie eine tolle Ergänzung dar. Aus meiner Sicht können in diesem Bereich die Anforderungen der meisten FuSi-Standards uneingeschränkt eingehalten werden auch wenn das Projekt agil abgewickelt wird. Der Schlüssel ist ein pro-aktiver Umgang mit den möglichen Konflikten, wie Sie beschrieben wurden, sowie der pragmatische Einsatz der Agilität.
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).
Hi Martin,
habe das Webinar angesehen und war echt gut gemacht. Nur hat bei mir der Schluss „Conclusion“ gefehlt. Ist das richtig oder gibt es bei der Ablage im Netz noch einen Fehler?
Gruss,
Klaus