ESE Fachwissen
Agilität in Safety-Projekten - geht das?
Autor: Frank Poignée, infoteam Software AG
Beitrag - Embedded Software Engineering Kongress 2017
Agile Softwareentwicklung stellt sich als Ziel, den Entwicklungsprozess flexibler und schlanker zu machen, als das bei den klassischen Vorgehensmodellen wie dem V-Modell der Fall ist. Können agilen Methoden auch bei der Entwicklung von sicherheitsgerichteten Systemen vorteilhaft eingesetzt werden und gleichzeitig alle Anforderungen der IEC 61508 an den Entwicklungsprozess erfüllt werden?
Motivation
Softwareentwicklung hat sich in den letzten 50 Jahren ständig weiterentwickelt. Schon seit einigen Jahren taucht dabei immer wieder Agil oder Scrum als Vorgehensmethodik auf, und immer mehr Entwicklungsteams arbeiten auf dieser Basis. Agile Methoden eignen sich dabei besonders gut, um auf sich ändernde Anforderungen zu reagieren, und Projekte, die mit agilen Methoden erstellt werden, haben eine deutlich höhere Wahrscheinlichkeit, erfolgreich abgeschlossen zu werden.
Können wir für unsere Kunden auch im Bereich Safety und Security effektiver arbeiten, indem wir agile Methoden einsetzen?
Was bedeutet Agil überhaupt?
In der Literatur wird der Februar 2001 als Meilenstein genannt, an dem das Agile Manifest [/1/] formuliert wurde. Die Aussagen in diesem Agilen Manifest stehen dabei in direktem Bezug auf Werte, die auch bei der Entwicklung mit Bezug auf funktionale Sicherheit sehr hoch eingestuft sind – nur finden sich diese eben auf der RECHTEN SEITE wieder und werden im Agilen als "weniger wichtig eingeschätzt" (siehe Bild 1, PDF: Aussagen des Agilen Manifest).
Besonders fällt dies bei den Punkten Prozess, Dokumentation und Plan natürlich auf!
Kommt die agile Entwicklung dabei ohne die Werte auf der RECHTEN Seite wirklich aus, läuft dadurch alles besser im Projekt, und sind Kunden dann also alle zufriedener? Und wenn dem wirklich so ist, stehen nicht damit schon die Anforderungen der IEC 61508 an den Entwicklungsprozess einem Einsatz von agilen Methoden bei der Entwicklung mit Bezug auf funktionale Sicherheit entgegen?
Tatsächlich arbeitet auch ein agiles Team nicht ohne Prozess – ganz so erschreckend sieht es also aus Safety-Sicht nicht aus.
Wo sind die Unterschiede in den Prozessmodellen?
Nehmen wir Scrum als Beispiel für die agile Vorgehensmethodik. Der Ansatz von Scrum ist, empirisch, inkrementell und iterativ zu arbeiten und beruht auf der Erfahrung, dass viele Entwicklungsprojekte einfach zu komplex sind, um in einen vollumfänglichen Plan gefasst werden zu können; ein wesentlicher Teil der Anforderungen und Lösungsansätze ist zu Beginn unklar. Diese Unklarheit lässt sich beseitigen, indem Zwischenergebnisse geschaffen werden, anhand derer sich dann fehlende Anforderungen und Lösungstechniken effizienter finden als durch eine abstrakte Klärungsphase.
In den Normen zur funktionalen Sicherheit findet sich das V-Modell, in der Softwareentwicklung auch als Wasserfallmodell bekannt. Dies ist ein lineares, nicht iteratives Vorgehensmodell, das in aufeinander folgenden Projektphasen organisiert ist. Dabei gehen Phasenergebnisse, wie bei einem Wasserfall, immer als bindende Vorgaben für die nächsttiefere Phase ein. Jede Phase hat vordefinierte Start- und Endpunkte mit eindeutig definierten Ergebnissen und wird nur einmal durchlaufen.
Zumindest in der Theorie! Tatsächlich gibt es auch in einem Safety Projekt "late Requirements", und es muss daher auch etwas wie Iterationen bei den Projektphasen beherrscht werden.
Auch schreibt die IEC 61508 nicht wirklich zwingend das V-Modell als Entwicklungsprozess vor! Es ist eben nur einfacher, das Erreichen der Ziele und Anforderungen der Norm anhand des V-Modells nachzuweisen. Ein Tailoring des Entwicklungsprozesses ist erlaubt, und meist ist nur Bequemlichkeit die Motivation, das V-Modell in den Projektbeschreibungen als Vorgehensweise vorzugeben. Erspart man der eigenen Entwicklung doch so den sonst zu erbringenden Nachweis, dass alle Ziele und Anforderungen in den Lebenszyklusphasen entsprechend der Norm erfüllt werden.
Gibt es ein agiles V-Modell?
Betrachtet man im "kontinuierlichen" V-Modell die rechte Seite des V – da geht es um das Testen – kann dies schon mit der linken Entwicklungsseite "parallel" angegangen werden. Eine Möglichkeit, hier etwas aus der agilen Welt zu übernehmen, ist die Phasen Implementation und Test/Überprüfung in der Form zu betrachten, dass diese wie ein agiles Projekt angegangen werden (siehe Bild 2, PDF: "Agiles" V-Modell).
Warum erst ab der Phase Implementation? Wir halten uns zunächst an das V-Modell, um Anforderungen zu definieren und einen Systementwurf zu dokumentieren, da Risikobetrachtungen in diesen beiden Schritten einen hohen Stellenwert haben – und sich diese effizienter in einem "statischen" Ablauf durchführen lassen als auf einem (hoch-) dynamischen Design, das wir erhalten, wenn sich Änderungen an den Anforderungen ergeben.
Stellen wir aber einem Verfechter der agilen Modelle dieses "agile V-Modell" vor, wird er zu Recht den Kopf schütteln und sagen: Das ist nicht agil, sondern eben "nur" iterativ, was wir da ausführen! Wir haben einen wichtigen Teil außer Acht gelassen, nämlich die Dynamik in den Anforderungen, was ja gerade einer der Vorteile der agilen Vorgehensweise darstellt. In unserem Modell dagegen definieren wir GENAU EINEN Satz an Anforderungen, an dem wir uns während der Iterationen bedienen, ändern diesen aber nicht (siehe Bild 3, PDF: "Iteratives" V-Modell).
Oder doch ein "Safety Scrum" Prozess?
Folgen wir einem anderen Ansatz: Vielleicht ist es eher Erfolg versprechend, einen sicheren Scrum-Prozess zu definieren.
Das sieht erst mal auch gar nicht so schwierig aus: wir führen "nur" für jeden Sprint zunächst eine neue Aktivität "Safety-Analyse" durch, dann folgt der eigentliche Sprint, der dann mit einer zusätzlichen Aktivität "Safety-Validierung" abgeschlossen wird (siehe Bild 4, PDF: Safety Scrum).
So einfach ist das dann aber auch nur in der Theorie. Es ergeben sich für die Entwicklung dadurch tatsächlich zwei – nehmen wir die Zertifizierungsprüfungen gleich noch mit dazu, dann sogar drei – überlappende Prozessmodelle.
Da ist zum einen die Safety-Analyse, also die Betrachtung der Risiken. Hier werden während des "backlog groomings" Einträge in das Produkt-Backlog definiert, welche die Sicherheitsanforderungen an das System definieren.
Während der Sprint-Planung muss wiederum eine Safety-Analyse durchgeführt werden, da durch die in das Sprint-Backlog übernommenen Einträge erneut Risiken im System entstehen und betrachtet werden müssen – wir ändern ja einen vorher entstandenen Systemzustand und müssen durch Änderungs-Auswirkungs-Analysen den Bezug auf System-Risiken abdecken!
Im abschließenden Sprint-Review hat dann ebenfalls wieder eine Safety-Analyse stattzufinden.
Schauen wir und den Validierungsanteil in Bezug auf das Scrum-Prozessmodell an, dann haben wir auch hier während des "backlog groomings" Einträge zu definieren, die im Weiteren zu beachten und für gewöhnlich während des abschließenden Sprint-Reviews durchzuführen bzw. zu prüfen sind.
Auch die Zertifizierungsprüfungen liefern Aufgaben, die in das Produkt-Backlog einzupflegen und dann umzusetzen sind – also im "daily scrum", im Sprint-Review und der Sprint-Retrospektive adressiert werden. Dieses Safety Assessment sollte kontinuierlich und parallel über die Entwicklung begleitend durchgeführt werden, damit das daraus resultierende Feedback so früh als möglich wieder berücksichtigt werden kann.
Das Safety Assessment ist dadurch eigentlich ein eigener Scrum, der parallel zur Entwicklung durchlaufen wird und eigene safetybezogene Aktivitäten und Rollen kennt, wie z. B. Assessment Owner, Assessment Backlog.
Es bleibt da schon die Frage, ob diese Vorgehensweise dann tatsächlich die ursprünglich in der Motivation genannten Vorteile bezüglich Flexibilität und "schlanker als klassische Vorgehensmodelle" erwarten lässt.
Das hier beispielhaft genannte Scrum ist übrigens nur eines von alternativen agilen Vorgehensmodellen. Bei allen bleiben immer Eigenschaften, die ein Vertreter der agilen Methoden gewahrt haben möchte, die aber diametral zu den Anforderungen der Normen zur funktionalen Sicherheit verlaufen oder eben nur noch sehr ineffizient umgesetzt werden können, wenn die Safety-Aspekte betrachtet werden.
Oder doch "nur" V-Modell mit Iterationen?
Der Ansatz, etwas aus der agilen Welt in den Safety-Prozess zu holen und so den Entwicklungsprozess "wenigstens etwas zu verbessern", ist tatsächlich nicht so schwierig. Betrachtet man die Prozessphase "Wartung und Pflege" einmal näher, dann findet sich dort schon die ganze Zeit eine iterative Vorgehensweise: das Change Management. Eine legitime und Norm-konforme Vorgehensweise ist es, schon während der noch laufenden, nicht abgeschlossenen Entwicklung diesen Change Management Prozess zu leben. Eine zusätzliche Motivation dafür ist, dass wir nicht nur zumindest eine Annäherung an eine agile Vorgehensweise schaffen, sondern auch gleichzeitig unser Entwicklungsteam in dem Prozess schulen, den das Team auch nach der Abnahme/Übergabe/Zertifizierung zu leben hat.
Fazit
Tatsächlich werden wir schwer GENAU EIN Prozessmodell finden, das für ALLE Projekte die passende Lösung darstellt!
Erfolgreich abgeschlossene Softwareprojekte aus dem realen Leben haben gezeigt, dass die Antwort auf die Frage "Agilität in Safety-Projekten – geht das?" durchaus "ja" lauten kann.
Es ist dabei aber eben nicht so, dass sich ALLE Aufgabenstellungen BESSER agil bewältigen lassen!
Quellen
[/1/] http://agilemanifesto.org/iso/de/manifesto.html
Unsere Trainings & Coachings
Wollen Sie sich auf den aktuellen Stand der Technik bringen?
Dann informieren Sie sich hier zu Schulungen/ Seminaren/ Trainings/ Workshops und individuellen Coachings von MircoConsult zum Thema Qualität, Safety & Security.
Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie hier.
Qualität, Safety & Security - Fachwissen
Wertvolles Fachwissen zum Thema Qualität, Safety & Security steht hier für Sie zum kostenfreien Download bereit.
Fachwissen zu weiteren Themen unseren Portfolios finden Sie hier.