Autor: Frank Poign\u00e9e, infoteam Software AG 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\u00f6nnen agilen Methoden auch bei der Entwicklung von sicherheitsgerichteten Systemen vorteilhaft eingesetzt werden und gleichzeitig alle Anforderungen der IEC 61508 an den Entwicklungsprozess erf\u00fcllt werden?<\/strong><\/p>\n Softwareentwicklung hat sich in den letzten 50 Jahren st\u00e4ndig 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 \u00e4ndernde Anforderungen zu reagieren, und Projekte, die mit agilen Methoden erstellt werden, haben eine deutlich h\u00f6here Wahrscheinlichkeit, erfolgreich abgeschlossen zu werden.<\/p>\n K\u00f6nnen wir f\u00fcr unsere Kunden auch im Bereich Safety und Security effektiver arbeiten, indem wir agile Methoden einsetzen?<\/p>\n 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 \u2013 nur finden sich diese eben auf der RECHTEN SEITE wieder und werden im Agilen als „weniger wichtig eingesch\u00e4tzt“ (siehe Bild 1,\u00a0PDF<\/a>: Aussagen des Agilen Manifest).<\/p>\n Besonders f\u00e4llt dies bei den Punkten Prozess, Dokumentation und Plan nat\u00fcrlich auf!<\/p>\n Kommt die agile Entwicklung dabei ohne die Werte auf der RECHTEN Seite wirklich aus, l\u00e4uft 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?<\/p>\n Tats\u00e4chlich arbeitet auch ein agiles Team nicht ohne Prozess \u2013 ganz so erschreckend sieht es also aus Safety-Sicht nicht aus.<\/p>\n Nehmen wir Scrum als Beispiel f\u00fcr 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\u00e4nglichen Plan gefasst werden zu k\u00f6nnen; ein wesentlicher Teil der Anforderungen und L\u00f6sungsans\u00e4tze ist zu Beginn unklar. Diese Unklarheit l\u00e4sst sich beseitigen, indem Zwischenergebnisse geschaffen werden, anhand derer sich dann fehlende Anforderungen und L\u00f6sungstechniken effizienter finden als durch eine abstrakte Kl\u00e4rungsphase.<\/p>\n 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\u00fcr die n\u00e4chsttiefere Phase ein. Jede Phase hat vordefinierte Start- und Endpunkte mit eindeutig definierten Ergebnissen und wird nur einmal durchlaufen.<\/p>\n Zumindest in der Theorie! Tats\u00e4chlich gibt es auch in einem Safety Projekt „late Requirements“, und es muss daher auch etwas wie Iterationen bei den Projektphasen beherrscht werden.<\/p>\n 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\u00fcllt werden.<\/p>\n Betrachtet man im „kontinuierlichen“ V-Modell die rechte Seite des V \u2013 da geht es um das Testen \u2013 kann dies schon mit der linken Entwicklungsseite „parallel“ angegangen werden. Eine M\u00f6glichkeit, hier etwas aus der agilen Welt zu \u00fcbernehmen, ist die Phasen Implementation und Test\/\u00dcberpr\u00fcfung in der Form zu betrachten, dass diese wie ein agiles Projekt angegangen werden (siehe Bild 2,\u00a0PDF<\/a>: „Agiles“ V-Modell).<\/p>\n Warum erst ab der Phase Implementation? Wir halten uns zun\u00e4chst an das V-Modell, um Anforderungen zu definieren und einen Systementwurf zu dokumentieren, da Risikobetrachtungen in diesen beiden Schritten einen hohen Stellenwert haben \u2013 und sich diese effizienter in einem „statischen“ Ablauf durchf\u00fchren lassen als auf einem (hoch-) dynamischen Design, das wir erhalten, wenn sich \u00c4nderungen an den Anforderungen ergeben.<\/p>\n Stellen wir aber einem Verfechter der agilen Modelle dieses „agile V-Modell“ vor, wird er zu Recht den Kopf sch\u00fctteln und sagen: Das ist nicht agil, sondern eben „nur“ iterativ, was wir da ausf\u00fchren! Wir haben einen wichtigen Teil au\u00dfer Acht gelassen, n\u00e4mlich 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\u00e4hrend der Iterationen bedienen, \u00e4ndern diesen aber nicht (siehe Bild 3,\u00a0PDF<\/a>: „Iteratives“ V-Modell).<\/p>\n Folgen wir einem anderen Ansatz: Vielleicht ist es eher Erfolg versprechend, einen sicheren Scrum-Prozess zu definieren.<\/p>\n Das sieht erst mal auch gar nicht so schwierig aus: wir f\u00fchren „nur“ f\u00fcr jeden Sprint zun\u00e4chst eine neue Aktivit\u00e4t „Safety-Analyse“ durch, dann folgt der eigentliche Sprint, der dann mit einer zus\u00e4tzlichen Aktivit\u00e4t „Safety-Validierung“ abgeschlossen wird (siehe Bild 4,\u00a0PDF<\/a>: Safety Scrum).<\/p>\n So einfach ist das dann aber auch nur in der Theorie. Es ergeben sich f\u00fcr die Entwicklung dadurch tats\u00e4chlich zwei \u2013 nehmen wir die Zertifizierungspr\u00fcfungen gleich noch mit dazu, dann sogar drei \u2013 \u00fcberlappende Prozessmodelle.<\/p>\n Da ist zum einen die Safety-Analyse, also die Betrachtung der Risiken. Hier werden w\u00e4hrend des „backlog groomings“ Eintr\u00e4ge in das Produkt-Backlog definiert, welche die Sicherheitsanforderungen an das System definieren.<\/p>\n W\u00e4hrend der Sprint-Planung muss wiederum eine Safety-Analyse durchgef\u00fchrt werden, da durch die in das Sprint-Backlog \u00fcbernommenen Eintr\u00e4ge erneut Risiken im System entstehen und betrachtet werden m\u00fcssen \u2013 wir \u00e4ndern ja einen vorher entstandenen Systemzustand und m\u00fcssen durch \u00c4nderungs-Auswirkungs-Analysen den Bezug auf System-Risiken abdecken!<\/p>\n Im abschlie\u00dfenden Sprint-Review hat dann ebenfalls wieder eine Safety-Analyse stattzufinden.<\/p>\n Schauen wir und den Validierungsanteil in Bezug auf das Scrum-Prozessmodell an, dann haben wir auch hier w\u00e4hrend des „backlog groomings“ Eintr\u00e4ge zu definieren, die im Weiteren zu beachten und f\u00fcr gew\u00f6hnlich w\u00e4hrend des abschlie\u00dfenden Sprint-Reviews durchzuf\u00fchren bzw. zu pr\u00fcfen sind.<\/p>\n Auch die Zertifizierungspr\u00fcfungen liefern Aufgaben, die in das Produkt-Backlog einzupflegen und dann umzusetzen sind \u2013 also im „daily scrum“, im Sprint-Review und der Sprint-Retrospektive adressiert werden. Dieses Safety Assessment sollte kontinuierlich und parallel \u00fcber die Entwicklung begleitend durchgef\u00fchrt werden, damit das daraus resultierende Feedback so fr\u00fch als m\u00f6glich wieder ber\u00fccksichtigt werden kann.<\/p>\n Das Safety Assessment ist dadurch eigentlich ein eigener Scrum, der parallel zur Entwicklung durchlaufen wird und eigene safetybezogene Aktivit\u00e4ten und Rollen kennt, wie z. B. Assessment Owner, Assessment Backlog.<\/p>\n Es bleibt da schon die Frage, ob diese Vorgehensweise dann tats\u00e4chlich die urspr\u00fcnglich in der Motivation genannten Vorteile bez\u00fcglich Flexibilit\u00e4t und „schlanker als klassische Vorgehensmodelle“ erwarten l\u00e4sst.<\/p>\n Das hier beispielhaft genannte Scrum ist \u00fcbrigens nur eines von alternativen agilen Vorgehensmodellen. Bei allen bleiben immer Eigenschaften, die ein Vertreter der agilen Methoden gewahrt haben m\u00f6chte, die aber diametral zu den Anforderungen der Normen zur funktionalen Sicherheit verlaufen oder eben nur noch sehr ineffizient umgesetzt werden k\u00f6nnen, wenn die Safety-Aspekte betrachtet werden.<\/p>\n Der Ansatz, etwas aus der agilen Welt in den Safety-Prozess zu holen und so den Entwicklungsprozess „wenigstens etwas zu verbessern“, ist tats\u00e4chlich nicht so schwierig. Betrachtet man die Prozessphase „Wartung und Pflege“ einmal n\u00e4her, dann findet sich dort schon die ganze Zeit eine iterative Vorgehensweise: das Change Management. Eine legitime und Norm-konforme Vorgehensweise ist es, schon w\u00e4hrend der noch laufenden, nicht abgeschlossenen Entwicklung diesen Change Management Prozess zu leben. Eine zus\u00e4tzliche Motivation daf\u00fcr ist, dass wir nicht nur zumindest eine Ann\u00e4herung an eine agile Vorgehensweise schaffen, sondern auch gleichzeitig unser Entwicklungsteam in dem Prozess schulen, den das Team auch nach der Abnahme\/\u00dcbergabe\/Zertifizierung zu leben hat.<\/p>\n Tats\u00e4chlich werden wir schwer GENAU EIN Prozessmodell finden, das f\u00fcr ALLE Projekte die passende L\u00f6sung darstellt!<\/p>\n Erfolgreich abgeschlossene Softwareprojekte aus dem realen Leben haben gezeigt, dass die Antwort auf die Frage „Agilit\u00e4t in Safety-Projekten \u2013 geht das?“ durchaus „ja“ lauten kann.<\/p>\n Es ist dabei aber eben nicht so, dass sich ALLE Aufgabenstellungen BESSER agil bew\u00e4ltigen lassen!<\/p>\n [\/1\/]\u00a0\u00a0\u00a0https:\/\/agilemanifesto.org\/iso\/de\/manifesto.html<\/a><\/p>\n Beitrag als PDF downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema\u00a0Qualit\u00e4t, Safety & Security<\/strong>.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema Qualit\u00e4t, Safety & Security steht\u00a0hier\u00a0<\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\n
\n<\/strong><\/p>\nBeitrag – Embedded Software Engineering Kongress 2017<\/h3>\n
Motivation<\/h2>\n
Was bedeutet Agil \u00fcberhaupt?<\/h2>\n
Wo sind die Unterschiede in den Prozessmodellen?<\/h2>\n
Gibt es ein agiles V-Modell?<\/h2>\n
Oder doch ein „Safety Scrum“ Prozess?<\/h2>\n
Oder doch „nur“ V-Modell mit Iterationen?<\/h2>\n
Fazit<\/h2>\n
Quellen<\/h2>\n
\nUnsere Trainings & Coachings<\/h2>\n
\nQualit\u00e4t, Safety & Security – Fachwissen<\/h2>\n