Autor: Prof. Dr. Stefan Wagner, Institut f\u00fcr Softwaretechnologie, Universit\u00e4t Stuttgart<\/p>\n
W\u00e4hrend agiles Software Engineering stark ver\u00e4ndert hat, wie in der Praxis Software entwickelt wird, spielt es bei sicherheitskritischen Systemen noch eine untergeordnete Rolle. Die Integration von Sicherheitsanalysen in ein Vorgehen nach Scrum ist aber m\u00f6glich ohne an Agilit\u00e4t zu verlieren. Im Folgenden betrachten wir ein Beispiel daf\u00fcr und verkn\u00fcpfen die Sicherheitsanalysen mit Behaviour-Driven Development zur verbesserten Qualit\u00e4tssicherung.<\/strong><\/p>\n Software wird zunehmend eine zentrale Komponente in sicherheitskritischen Systemen, da sie oft f\u00fcr die Steuerung der Systeme verantwortlich ist. In allen sicherheitskritischen Dom\u00e4nen, sei es Fahrzeugbau, Flugzeugbau oder auch Werkzeugmaschinen, ist die Digitalisierung und damit auch der massive Einsatz von Software heute angekommen.<\/p>\n F\u00fcr die Entwicklung von Software au\u00dferhalb eingebetteter und sicherheitskritischer Systeme setzt sich zunehmend das agile Software Engineering mit selbstorganisierenden Teams, kurzen Zyklen und flexiblem Anforderungsmanagement durch. Dadurch entstehen am Anfang des Projekts aber keine umfassenden und detaillierten Anforderungsdokumente und Architekturentw\u00fcrfe, was im Widerspruch zu vielen Sicherheitsanalysemethoden und Sicherheitsstandards steht. Dort erwartet man eine detaillierte Architektur des Systems, um die Analysen durchf\u00fchren und die Ergebnisse f\u00fcr eine Zertifizierung dokumentieren zu k\u00f6nnen.<\/p>\n Wie kann man sich dieser Herausforderung nun stellen? Wie kann man die Vorteile der agilen Software-Entwicklung auch f\u00fcr sicherheitskritische Systeme nutzen?<\/p>\n Der am h\u00e4ufigsten verwendete agile Entwicklungsprozess ist Scrum [1]. Er schreibt die Rollen des Scrum Masters, des Product Owners und des Teams vor. Scrum betont, dass das Team selbstorganisierend ist, w\u00e4hrend der Scrum Master auf die Einhaltung der Scrum-Regeln achtet und der Product Owner die Schnittstelle zum Kunden ist. Anforderungen werden in einem Backlog gehalten und priorisiert. Anforderungen aus dem Backlog werden dann in zwei- bis vierw\u00f6chigen Sprints abgearbeitet. Die Sprints bestehen neben der eigentlichen Entwicklungsarbeit aus einem Planungstreffen, dem Sprint-Review und der Retrospektive. Im Planungstreffen wird festgelegt, was im Sprint getan werden soll. Im Sprint-Review wird am Ende des Sprints ein potentiell auslieferbares Produkt-Inkrement dem Kunden pr\u00e4sentiert. In der Retrospektive sammelt das Team Prozessverbesserungen.<\/p>\n Es gibt einige wenige Vorschl\u00e4ge, wie Scrum genutzt werden kann, um sicherheitskritische Systeme zu entwickeln. Safe Scrum [2] und R-Scrum [3] sind die zwei bekanntesten Beispiele, die es bereits schaffen viele Dokumentationsanforderungen in Scrum einzubauen, dass die Anforderungen aus Standards wie der IEC 61508 eingehalten werden k\u00f6nnen. Eine Schwierigkeit bleibt aber, dass die Anteile, die die funktionale Sicherheit betreffen au\u00dferhalb des Sprints bleiben. Die Agilit\u00e4t leidet hier etwas.<\/p>\n Deshalb haben wir uns dazu entschieden, als Sicherheitsanalysemethode STPA\u00a0\u00a0<\/strong>(System-Theoretic Process Analysis) [4] einzusetzen. Die von Nancy Leveson am MIT entwickelte Methode bringt f\u00fcr uns hier zwei entscheidende Vorteile: (1) Es geht von einer iterativen Weiterentwicklung von System und Sicherheitsanalyse im Wechsel aus und (2) fokussiert sich im Gegensatz zu anderen Methoden nicht auf einzelne Komponenten sondern auf deren Zusammenspiel, was die Einbindung von Software aber auch Nutzern einfach erm\u00f6glicht.<\/p>\n Wir haben als entsprechende Scrum-Erweiterung\u00a0S-Scrum<\/em>\u00a0[5] vorgeschlagen, das in vielen Aspekten stark an Safe Scrum orientiert ist. Der grundlegende Prozess ist in Abbildung 1 dargestellt. Hier gibt es zwar auch vor den Sprints eine Software-Sicherheitsspezifikation (SSRS), aber die Durchf\u00fchrung von STPA ist innerhalb des Sprints und sogar im t\u00e4glichen Ablauf. Die Kommunikation zwischen Sicherheitsexperten und Team ist durch ein explizites Regular Safety Meeting sichergestellt, das nicht unbedingt t\u00e4glich durchgef\u00fchrt werden muss. Die direkte Einbindung der Ergebnisse wird durch eine Abbildung auf Tests in der kontinuierlichen Integration (TDD\/BDD\/CI) erzielt. Nach den Sprints gibt es noch eine\u00a0Final STPA Validation<\/em>, die alle Sicherheitsanforderungen nochmal explizit validiert, damit dies in die Dokumentation einflie\u00dfen kann.<\/p>\n Abbildung 1 (s.\u00a0PDF<\/a>): Vereinfachter Ablauf von S-Scrum<\/p>\n Trotz doch einiger zus\u00e4tzlicher Aktivit\u00e4ten und Dokumente, die in S-Scrum gegen\u00fcber Scrum existieren, konnten wir in einer Studie [5] zeigen, dass die Agilit\u00e4t aus Sicht der Entwickler darunter kaum leidet. Wir sind also der agilen Entwicklung sicherheitskritischer Systeme einen Schritt n\u00e4her gekommen.<\/p>\n Neben der Einbindung einer geeigneten Sicherheitsanalysemethode ist auch eine einfache Verkn\u00fcpfung zu agiler Qualit\u00e4tssicherung notwendig, um in der Entwicklung sicherheitskritischer Software agil sein zu k\u00f6nnen. Aus der agilen Software-Entwicklung stammt ein Ansatz, der vielversprechend ist, um ihn mit Sicherheitsanforderungen zu verbinden:\u00a0Behaviour-Driven Development<\/em>\u00a0(BDD) [6].<\/p>\n Die Grundidee ist hier, dass das Verhalten vorab mit der Hilfe von Beispielen und Szenarien in einem sogenannten\u00a0Three Amigos Meeting<\/em>, bestehend aus einem Entwickler, einem Tester und einem Kundenvertreter, spezifiziert wird. Die Spezifikation ist dabei meist in Form von einfachem nat\u00fcrlichsprachigen Text. Beispielsweise wird dazu die Sprache\u00a0Gherkin<\/em>\u00a0verwendet. Diese Gherkin-Spezifikationen werden dann von Testern automatisiert eingelesen und als Testfall gegen das System gepr\u00fcft. Diese Spezifikation und der Test werden geschrieben, bevor das spezifizierte Szenario implementiert ist, sodass die Entwickler dann ein klares Kriterium haben, wann sie eine Anforderung erf\u00fcllt haben: dann, wenn alle Tests erfolgreich durchgef\u00fchrt werden k\u00f6nnen.<\/p>\n Das spannende f\u00fcr Sicherheitsanalysen ist, dass wir uns bei der funktionalen Sicherheit auch mit dem Verhalten des Systems besch\u00e4ftigen: Mit welchem Verhalten kann das System in einen unsicheren Zustand kommen und eine Gef\u00e4hrdung ausl\u00f6sen? Damit lassen sich die Sicherheitsanalysen, die wir in S-Scrum mit der STPA entwickeln leicht in Gherkin-Spezifikationen umbauen, die wiederum als Testspezifikation dienen k\u00f6nnen. Ein Beispiel einer solchen Spezifikation ist in Abbildung 2 gezeigt.<\/p>\n Abbildung 2 (s.\u00a0PDF<\/a>): Ein Beispiel f\u00fcr ein Unsafe Scenario und zugeh\u00f6riges Szenario in BDD<\/p>\n Wir haben diese Verkn\u00fcpfung der STPA-Sicherheitsanalyse und BDD in Experimenten untersucht [7]. Wir konnten dabei zeigen, dass gegen\u00fcber dem herk\u00f6mmlichen Erstellen von Akzeptanztests insbesondere die Kommunikation zwischen den Beteiligten durch BDD erh\u00f6ht wurde. Das Three Amigos Meeting zusammen mit der nat\u00fcrlichsprachigen Szenario-Spezifikation scheint es deutlich leichter zu machen, um \u00fcber die Anforderungen und Tests zu sprechen. Damit ist BDD eine sehr vielversprechende Methode f\u00fcr den Kontext sicherheitskritischer Systeme.<\/p>\n Unsere Ergebnisse haben das Thema sicher noch nicht ersch\u00f6pfend gel\u00f6st. Durch S-Scrum mit eingebettetem BDD steht aber nun ein empirisch erprobter Entwicklungsprozess zur Verf\u00fcgung, der sowohl iterative Sicherheitsanalyse als auch eine enge Integration mit agiler Qualit\u00e4tssicherung erlaubt. Wir gehen davon aus, dass dies aber nur der Start ist. Um die empirischen Ergebnisse zu erh\u00e4rten suchen wir Partner f\u00fcr weitere Studien. Auch BDD und die dazugeh\u00f6rige Art Szenarios zu spezifizieren k\u00f6nnte noch viele weitere Bereiche in der Entwicklung eingebetteter Software-Systeme unterst\u00fctzen. Der Fokus auf einfaches Verst\u00e4ndnis und Kommunikation bei gleichzeitig vollautomatischer Testausf\u00fchrung stellt eine interessante Kombination f\u00fcr viele Arten von Anforderungen dar. Wir planen auch hier weiter die M\u00f6glichkeiten zu untersuchen.<\/p>\n 1.\u00a0www.scrumguides.org<\/a><\/p>\n 2. T. St\u00e5lhane, T. Myklebust, G. Hanssen. The application of Safe Scrum to IEC 61508 certifiable software. In:\u00a0Proceedings of the 11th<\/sup>\u00a0International Probabilistic Safety Assessment and Management Conference and the Annual European Safety and Reliability Conference<\/em>. 2012.<\/p>\n 3. B. Fitzgerald, K.-J. Stol, R. O\u2019Sullivan, D. O\u2019Brien. Scaling agile methods to regulated environments: An industry case study. In:\u00a0Proceedings of the 35th<\/sup>\u00a0International Conference on Software Engineering<\/em>. IEEE, 2013.<\/p>\n 4. N. Leveson.\u00a0Engineering a Safer World: Systems Thinking Applied to Safety<\/em>. MIT Press, 2011.<\/p>\n 5. Y. Wang, J. Ramadani, S. Wagner. An exploratory study of applying a Scrum development process for safety-critical systems. In:\u00a0Proceedings of the 2017 International Conference on Product-Focused Software Improvement<\/em>. Springer, 2017.<\/p>\n 6. M. Wynne, A. Hellesoy.\u00a0The Cucumber Book: Behaviour-Driven Development for Testers and Developers.\u00a0<\/em>Pragmatic Bookshelf, 2012.<\/p>\n 7. Y. Wang, S. Wagner. Combining STPA and BDD for safety analysis and verification in agile development: A controlled experiment. In:\u00a0Proceedings of the 2018 International Conference on Agile Software Development.\u00a0<\/em>Springer<\/em>, 2018.<\/p>\n Stefan Wagner ist Professor f\u00fcr Software Engineering und Gesch\u00e4ftsf\u00fchrender Direktor des Instituts f\u00fcr Softwaretechnologie der Universit\u00e4t Stuttgart. Er studierte Informatik in Augsburg und Edinburgh und promovierte an der TU M\u00fcnchen. Seine Forschungsschwerpunkte sind Requirements Engineering, Software-Qualit\u00e4t, funktionale Sicherheit und agiles Software Engineering. Er bearbeitet diese Themen gerne mit empirischen und psychologischen Methoden in enger Kooperation mit der Industrie. Daneben ist er zu diesen Themen auch als Berater und Trainer freiberuflich t\u00e4tig. Er ist Mitglied bei GI, ACM und IEEE.<\/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><\/strong>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nEinleitung<\/h2>\n
Sicherheitsanalyse in Scrum mit STPA<\/h2>\n
Behaviour-Driven Development und Sicherheitsanforderungen<\/h2>\n
Zusammenfassung und Ausblick<\/h2>\n
Literaturverzeichnis<\/h2>\n
Autor<\/h2>\n
\nUnsere Trainings & Coachings<\/h2>\n
\nQualit\u00e4t, Safety & Security – Fachwissen<\/h2>\n