Agile Softwareentwicklung im Kontext hoher Safety-Anforderungen

Die Entwicklung von komplexen Software-Systemen ist im Vorhinein schwer im Detail planbar. Dies hat in den letzten Jahren zu einem vermehrten Einsatz von agilen Vorgehensweisen in der Softwareentwicklung geführt. Agile Vorgehensweisen haben das Ziel, den Aufwand für Planung und Dokumentation gering zu halten bzw. diese Tätigkeiten erst dann auszuführen, wenn sie direkt für die Entwicklung benötigt werden. Somit soll in größeren Entwicklungsprojekten auf sich ändernde Anforderungen flexibel reagiert werden, ohne dass die Planung und Dokumentation jedes Mal komplett wiederholt werden müssen. [1]

Mit dem zunehmenden Einsatz von Software in Systemen wie Autos oder Fabrikanlagen, die direkte Auswirkungen auf Menschen haben können, steigen auch die Anforderungen an die Betriebssicherheit (engl. Safety). Das Ziel von Safety ist, dass bei bestimmungsgemäßer Verwendung eines Systems keine Fehlfunktionen mit potenziellen Auswirkungen auf den Anwender auftreten. [2]

Aus diesen beiden Entwicklungen ergibt sich die Frage, inwiefern agile Vorgehensweisen auch für die Entwicklung von Software mit hohen Safety-Anforderungen angewandt werden können.

Klassische, lineare Vorgehensmodelle in der Softwareentwicklung sehen eine schrittweise Abarbeitung von Projektphasen vor.

Beispielhaft hierfür ist das V-Modell, welches Phasen für das Aufstellen der Anforderungen, den Entwurf des Systems, die Implementierung und die Tests auf unterschiedlichen Detail-Ebenen enthält.

Für die Entwicklung von großen, komplexen Systemen, bei denen sich Anforderungen während der Entwicklung ändern, wurden in den letzten Jahren immer mehr agile Vorgehensweisen statt den klassischen, sequentiellen Modellen gewählt.

Mit einem agilen Vorgehen soll flexibler auf Anforderungsänderungen während der Entwicklung reagiert werden, die hohe Komplexität besser bewältigt werden, Produkte früher auf den Markt gebracht werden und eine höhere Kundenzufriedenheit erreicht werden.

Um diese Ziele zu erreichen, wird die Entwicklung inkrementell durchgeführt. Am Beispiel des agilen Vorgehensmodells Scrum wird dies genauer erläutert:

Statt einer umfänglichen Planung des gesamten Projekts wird in Scrum beim Projektstart ein Product Backlog aufgestellt, welcher zu Beginn eine wenig detaillierte Planung und die Benutzeranforderungen enthält und während des Projekts verfeinert wird.

Die Entwicklung ist in Sprints organisiert. Für einen Sprint werden Anforderungen aus dem Product Backlog ausgewählt und genauer spezifiziert. Daraus ergibt sich der Sprint Backlog. Typischerweise werden dann die ausgewählten Anforderungen innerhalb von zwei bis vier Wochen implementiert und getestet.

Das Ziel eines Sprints ist ein potenziell auslieferbares Produkt, welches verwendet werden kann, um bereits während der Entwicklung Feedback vom Kunden zu erhalten.

Durch das Feedback kann frühzeitig auf veränderte Anforderungen reagiert werden. Da das Product Backlog nur die grobe Planung vorgibt, muss für die Anpassungen nicht wie bei dem V-Modell die komplette Detail-Planung erneut durchgeführt werden.

Das Entwicklungsteam besteht aus drei bis neun Mitgliedern, organisiert sich selbst und arbeitet interdisziplinär. Es kann also sein, dass ein Entwickler auch als Tester arbeitet, wenn damit das Sprint-Ziel besser erreicht werden kann. [3]

Eine häufig in agilen Entwicklungsprozessen eingesetzte Methode ist die testgetriebene Entwicklung. Anforderungen werden dabei zuerst in Test-Code umgeschrieben. Anschließend wird nur so viel Funktionalität implementiert, wie für das Bestehen der Tests notwendig ist. [1]

Um nicht nur einzelne Code-Einheiten zu testen sondern auch ihr Zusammenspiel, wird in agilen Prozessen auch häufig die kontinuierliche Integration eingesetzt. Sie ermöglicht es, dass Module regelmäßig in das Gesamtsystem integriert und deren Integration automatisiert getestet werden kann. [4]

In Deutschland wird der Umgang mit Gefahren und Schäden infolge von fehlerhaften Systemen durch das Produkthaftungsgesetz geregelt. Um rechtliche Konsequenzen im Schadensfall zu beschränken, kann der Entwicklungsprozess nach Normen zertifiziert werden. [5]

Diese Normen definieren Vorgehensweisen für die Planung, Entwicklung, Wartung und Außerbetriebnahme eines Systems. Ziel der Vorgehensweisen ist eine Minimierung von Gefahren für die Nutzer und die Umwelt.

Ein Beispiel für eine solche Norm ist die IEC 61508 „Funktionale Sicherheit sicherheitsbezogener elektrischer/elektronischer/programmierbarer elektronischer Systeme“. Auf ihr basierend gibt es speziell für Kraftfahrzeuge die Norm ISO 26262.

In Entwicklungsprozessen mit hohen Safety-Anforderungen hat sich das V-Modell mit einer klaren Trennung zwischen den verschiedenen Rollen wie Entwickler und Tester bewährt.

Eine wichtige Rolle spielt dabei auch die Nachverfolgbarkeit der Zusammenhänge zwischen den Anforderungen, den Testfällen und dem Programmcode.

Um eine hohe Testabdeckung sowohl auf der Ebene von einzelnen Programm-Einheiten, als auch auf Systemebene zu erreichen, wird eine hohe Automatisierung der Tests und der Modul-Integration angestrebt.

Ebenfalls hat es sich bewährt, möglichst früh mit Tests zu beginnen und sie an das entstehende System anzupassen, da die Behebung von Fehlern umso aufwändiger wird, je später sie entdeckt werden. [2][6]

Während die Ziele des agilen Vorgehens eine höhere Produktivität und Kundenzufriedenheit umfassen, wird nicht explizit das Erfüllen von Safety-Anforderungen als Ziel angegeben.

Die der agilen Softwareentwicklung zugrundeliegenden Werte priorisieren ein funktionierendes Produkt höher als eine umfassende Dokumentation. Ebenso hat die Reaktion auf Veränderungen eine höhere Priorität als das Einhalten eines Plans. [7]

Dies scheint im Widerspruch zu stehen zu dem exakten Befolgen einer Norm und der genauen Dokumentation des Entwicklungsprozesses, um eine Zertifizierung nach einer Norm zu erhalten.

Da die Normen IEC 61508 und ISO 26262 von dem V-Modell ausgehen [8], ist eine Umsetzung der Normen bei einem agilen Vorgehen nicht offensichtlich.

Beispielsweise ist bei dem agilen Vorgehensmodell Scrum keine Rolle für die Qualitätssicherung vorgesehen. Eine strikte Trennung der Rollen, also beispielsweise zwischen Entwickler und Tester wird bei Scrum ebenfalls nicht explizit gefordert. [3]

Obwohl Safety-Anforderungen nicht explizit als Ziel in der agilen Entwicklung genannt werden, gibt es Aspekte, die eine höhere Betriebssicherheit ermöglichen:

Die beim agilen Vorgehen häufig eingesetzte testgetriebene Entwicklung sorgt dafür, dass genau so viel Code geschrieben wird, wie auch Tests existieren. Dies erleichtert eine hohe Testabdeckung und ermöglicht das frühe Entdecken von Fehlern.

Zusammen mit dem Product Backlog und den Sprint Backlogs entsteht dadurch auch eine bessere Nachverfolgbarkeit der Zusammenhänge zwischen Anforderungen, Tests und geschriebenem Code.

Die ebenfalls in der agilen Entwicklung verbreitete kontinuierliche Integration erleichtert das häufige Testen der Interaktion zwischen den Modulen eines Systems.

Ein möglicher Vorteil des inkrementellen Vorgehens sind genauere Safety-Analysen auf den Inkrementen, da die Analyse eines Inkrements potenziell weniger komplex ist als die eines kompletten Systems.

Agile Vorgehensmodelle sind zwar nicht für die Entwicklung Safety-kritischer Systeme ausgelegt, enthalten dennoch dafür hilfreiche Elemente wie die testgetriebene Entwicklung oder die kontinuierliche Integration.

Trotz des fehlenden Fokus auf eine umfängliche Dokumentation wird agiles Vorgehen in einer Umfrage von Unternehmen nicht als Widerspruch zu Safety-Anforderungen gesehen.

Die in der Umfrage von Kugler Maag Cie befragten Unternehmen gaben an, gewisse Aspekte aus agilen Methoden ausgewählt und mit dem konventionellen Vorgehen verbunden zu haben. So wurde zum Beispiel ein Qualitätssicherungsingenieur zusätzlich außerhalb des Sprint Teams eingesetzt. [9]

Um die Safety-Anforderungen noch stärker in das agile Vorgehen zu integrieren, schlagen Stålhane et al. vor zusätzlich zu dem Product Backlog einen Safety Product Backlog einzuführen und nach jedem Sprint sowohl funktionale als auch sicherheitsrelevante Anforderungen zu validieren. [6]

Weiterführend könnte noch untersucht werden, inwiefern die Sicherheitsanforderungen und Normen mit Ansätzen, die sich noch stärker an der agilen Vorgehensweise orientieren, erfüllt werden können.

• [1] Wedel, Michael. Wohlriechende Software für eingebettete Systeme entwickeln. handwerklich sauber, test- und wartbar. Vortrag in der Ringvorlesung „Forum Software und Automatisierung”. Universität Stuttgart: 2.11.2017
• [2] Liedtke, Thomas. Softwareprüfung für “sichere” (Safety + Security + Privacy) Systeme. Vortrag in der Ringvorlesung „Forum Software und Automatisierung”. Universität Stuttgart: 9.11.2017
• [3] Schwaber, Ken und Sutherland, Jeff. The Scrum Guide. scrum.org/resources/scrum-guide (Aufgerufen am 21.3.2018).
• [4] Diebold, Philipp, et al. What do practitioners vary in using scrum?. International Conference on Agile Software Development. Springer, Cham. 2015.
• [5] § 1 Abs. 2.5 ProdHaftG
• [6] Stålhane, Tor et al. The application of Safe Scrum to IEC 61508 certifiable software. 11th International Probabilistic Safety Assessment and Management Conference and the Annual European Safety and Reliability Conference. 2012.
• [7] Beck, Kent et al. Manifesto for Agile Software Development. agilemanifesto.org. (Aufgerufen am 21.3.2018).
• [8] Wang, Yang, Jasmin Ramadani und Stefan Wagner. An Exploratory Study on Applying a Scrum Development Process for Safety-Critical Systems. International Conference on Product-Focused Software Process Improvement. Springer, Cham. 2017.
• [9] Albertz, Joachim et al. Agile in Automotive. State of Practice 2015. www.kuglermaag.com. (Aufgerufen am 21.3.2018).

Dieser Beitrag entstand nach zwei Vorträgen im Rahmen der Ringvorlesung „Forum Software und Automatisierung“ am IAS.

Vortragsdatum: 02.11.2017
Vortragender: Dr. Michael Wedel, mk-messtechnik GmbH
Vortragstitel: Wohlriechende Software für eingebettete Systeme entwickeln

Vortragsdatum: 09.11.2017
Vortragender: Dr. Thomas Liedtke, Kugler Maag CIE GmbH
Vortragstitel: Softwareprüfung für „sichere“ (Safety + Security + Privacy) Systeme