AGIL? ABER SICHER! - Embedded Testing...• Die ISO 26262 fordert ein funktionales und technisches Sicherheitskonzept, ausgehend von einer Gefährdungsanalyse. • Die Risikoanalyseaufgaben

Vorlage: Folienmaster_169 (2015/02/13)

AGIL? ABER SICHER!

EIN METAMODELL ZUR VERWALTUNG VON USER STORIES

UND ARTEFAKTEN DER FUNKTIONALEN SICHERHEIT

1Eine Präsentation der IT-Designers Gruppe – von Hannes Todenhagen

• Name: Hannes Todenhagen

• Firma: IT Designers Gruppe

• Bereich:• Application Lifecycle Management• Tools, Methoden, Prozesse und Consulting

• Aufgabengebiete:• Requirements Engineering• Realisierung von Toolintegrationslösungen• Prozessberatung im Automobilbereich• Server-Entwicklung im Projekt MEC-View

Mein Profil


1. Motivation

a) Agile Methodik

b) Stolpersteine

c) Voraussetzungen

2. Das Metamodell

a) Metamodelle in der Praxis

b) WorkItem-Typen und deren Beziehungen

c) Workflows

3. Beispiel

4. Fazit

Agenda


MOTIVATION

WIESO AGIL UND WAS BRINGT AGILITÄT?


• Spezifikationsorientierte Prozesse strukturieren den Ablauf eines Softwareentwicklungsprojekts.• Die Umsetzung wird geplant,• die notwendige Dokumentation wird erstellt,• Tests und Abnahmeaufgaben werden durchgeführt und• die lauffähige Software in ausreichender Qualität ist das Ergebnis.

• Allerdings ergibt sich daraus oft ein Problem:

Motivation – Agile Methodik


Wurde wirklich das Softwaresystem umgesetzt, was auch gebraucht wird?

Wurde wirklich das Softwaresystem umgesetzt, was auch gebraucht wird?

• Die Entwicklung agiler Methoden startete Anfang der 90er Jahre.

• Ein Meilenstein wurde 2001 durch die Veröffentlichung des Agilen Manifests erreicht.

• Die vier Werte hinter dem Agilen Manifest:• Individuen und Interaktionen mehr als Prozesse und Werkzeuge• Funktionierende Software mehr als umfassende Dokumentation• Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung• Reagieren auf Veränderung mehr als das Befolgen eines Plans



Wo liegen die Unterschiede zwischen agiler Methodik und spezifikationsorientierter Vorgehensweise?

• Das Vorgehen wird anhand des Mehrwerts für die Stakeholder gegliedert, nicht nach Tätigkeiten im Projekt.

• Das Ergebnis wird inkrementell durch ein „Cross-Functional Team“ erzeugt.

• Dadurch wird der Zyklus „Priorisieren, Planen, Implementieren und Feedback“ möglichst schnell durchlaufen.



Was bedeutet das für die Automobilindustrie?

• Software-Funktionen ersetzen zunehmend bisher hydraulisch oder mechanisch realisierte Funktionen:• Beispiele dafür sind Funktionen wie ABS oder ESP

• Zusätzlich werden neue Fahrerassistenzfunktionen, bis hin zum autonomen Fahrzeug, realisiert.



Reine Softwaresysteme spielen zunehmend eine größere Rolle.Reine Softwaresysteme spielen zunehmend eine größere Rolle.

„Embrace The Change!“

• Dies führt zu einem Konflikt mit dem Vorgehen der ISO 26262!

• Die Gefährdungs- und Risikoanalyse, sowie das funktionale und technische Sicherheitskonzept müssen bei jeder Änderung angepasst werden.

Motivation – Stolpersteine


„Funktionierende Software mehr als umfassende Dokumentation“

• Für den Sicherheitsnachweis ist Dokumentation enorm wichtig.

• Agiles Vorgehen fördert die zeitnahe Erstellung von lauffähiger Software, Dokumentation ist jedoch nicht überflüssig!

Motivation – Stolpersteine


• Risikoanalyseaufgaben müssen in den agilen Prozess integriert werden.

• Die Prozessdokumentation muss von der Produktdokumentation getrennt werden, beides ist jedoch notwendig.• User Stories beschreiben den Mehrwert für mindestens einen

Stakeholder und dienen als Diskussionsgrundlage mit den Entwicklern.• Requirements bilden eine Spezifikation für das System bzw. jedes

Subsystem.

• Ein ALM-Tool muss eingesetzt werden, um den Überblick über alle Artefakte und Dokumente zu behalten.

Motivation – Voraussetzungen


DAS METAMODELL

DIE GRUNDLAGE FÜR ERFOLGREICHES AGILES ARBEITEN


• Als Einstiegspunkt wird das Metmodell der Siemens Polarion Vorlage „Agile Software Projekt“ verwendet.

• Zusätzliche Link-Rollen: „relates to“, „branched from“, „follow-up“, „derived from“, „duplicates“, „depends on“

Das Metamodell - Metamodelle in der Praxis - Agil


• Polarion Extension für ISO 26262 (Teil 3: Concept Phase)

• Zusätzliche Link-Rollen: „relates to“, „branched from“, „follow-up“, „duplicates“, „depends on“, „parent“, „refines“

Das Metamodell – Metamodelle in der Praxis - ISO 26262


• Für die Durchführung eines Softwareprojekts mit agiler Methodik wird eine Kombination der beiden Metamodelle benötigt.• Die Basis für die Kunden-orientierte Arbeitsweise bilden User Stories.• Die ISO 26262 fordert ein funktionales und technisches

Sicherheitskonzept, ausgehend von einer Gefährdungsanalyse.

• Die Risikoanalyseaufgaben müssen in die inkrementelle Erstellung der Software und Dokumentation mit aufgenommen werden.

• Die Nachvollziehbarkeit (Traceability) muss zwischen allen WorkItems und Artefakten gegeben sein.

Das Metamodell


• Ausgehend von dem WorkItem-Typ „User Story“, wird das Metamodell schrittweise aufgebaut.

Das Metamodell – WorkItem-Typen und deren Beziehungen


• Requirements werden aus einer User Story abgeleitet.

• Tasks beschreiben die Implementierungsaufgaben.



• Zusätzliche WorkItem-Typen beschreiben den Status und die Ergebnisse der funktionalen Risikoanalyse in Bezug auf eine User Story.




• Der Bezug zur Produktvision wird über das Safety Goal, die Gefährdungen und Szenarien hergestellt.




Zusammenfassung:

• Jede User Story bringt einen Mehrwert für die Stakeholder mit sich.

• Jede neue Funktionalität wird auf Risiken untersucht.

• Ein Risiko besteht, wenn durch die neue Funktionalität ein Sicherheitsziel nicht oder nur zum Teil eingehalten werden kann.



• Technische Risiken und entsprechende technische Sicherheitsanforderungen werden zusätzlich mit der User Story verlinkt.




• Metainformationen wie Testergebnisse und Commit-Informationen werden ebenfalls verlinkt.




• Ein Workflow für jeden WorkItem-Typ vervollständigt das Metamodell.

Das Metamodell – Workflows


• Jedem Zustand wird eine Vorbedingung und eine oder mehrere Rollen für den Übergang in den Zustand zugewiesen.

• Beispiel: Accepted• Vorbedingung:

• Es wurde ein WorkItem des Typs „Functional Safety Analysis“ hinzugefügt und mindestens bis zum Zustand „Done“ bearbeitet.

• Es wurden Tasks und Requirements abgeleitet.• Rolle für den Zustandsübergang:

• Product Owner / Safety Product Owner

Das Metamodell – Workflows


BEISPIEL

BEISPIELE AUS DEM FORSCHUNGSPROJEKT MEC-VIEW


• Mobile Edge Computing basierte Objekterkennung für hoch- und vollautomatisiertes Fahren in urbanen Verkehrsräumen

Beispiel – Das Forschungsprojekt MEC-View


Projekthomepage: http://www.mec-view.de/

http://mec-view.de/

• Die Lösungsstrategie und das Metamodell wurden im Rahmen der Entwicklung der Backendserversoftware erstellt und evaluiert.

• Zum Einsatz kam das Application Lifecycle Management (ALM)-Tool Polarion von Siemens.

• Die Prozess- sowie Produktdokumentation wurde in Polarion verwaltet.

Beispiel – Das Forschungsprojekt MEC-View


• Für die funktionale und technische Risikoanalyse werden FMEA-Workshops durchgeführt.

• Es wurde ein FMEA-Widget für Polarion entwickelt, das diese Workshops unterstützt.

• Mit dem FMEA-Widget werden alle benötigten Informationen für die Workshops dargestellt.

• Es können Risiken und Sicherheitsanforderungen direkt im Widget erstellt werden.

Beispiel – FMEA-Widget






• Zusätzlich zu den im Metamodell verankerten Links, wurden die WorkItems auch noch mit Kapiteln in Dokumenten verknüpft.

• Die einheitliche Versionierung von Prozess- und Produktdokumentation ist dadurch möglich.

Beispiel – Dashboards und Dokumente


• Im Rahmen der Entwicklung wurden mehrere Dashboards definiert.

• Dashboards zeigen Metriken und Traceability Tabellen verschiedener WorkItems in einzelnen Widgets.

Beispiel – Dashboards und Dokumente


FAZIT

VORTEILE DES METAMODELLS UND MÖGLICHE ANWENDUNGEN


• Mit Hilfe des Metamodells werden alle Artefakte während der Entwicklung erfasst.

• Dokumente und Metriken können für die ISO 26262 daraus abgeleitet werden.

• Das Metamodell orientiert sich an der agilen Arbeitsweise.

• Das Metamodell ist Prozess-unabhängig und kann z. B. mit Scrum, Kanban oder XP verwendet werden.• Der Prozess definiert, wann welcher Zustandsübergang der WorkItem-

Typen durchgeführt wird.• Für jeden Zustandsübergang kann eine Methode definiert werden,

diese kann sich auch anhand des ASILs unterscheiden.

Fazit


VIELEN DANK FÜR IHRE AUFMERKSAMKEIT!


Funktionale Sicherheit und ISO 26262:

• ROSS, Hans-Leo. Funktionale Sicherheit im Automobil: ISO 26262, Systemengineering auf Basis eines Sicherheitslebenszyklus und bewährten Managementsystemen. Carl Hanser Verlag GmbH Co KG, 2014.

• LÖW, Peter; PABST, Roland; PETRY, Erwin. Funktionale Sicherheit in der Praxis. Anwendung von DIN EN, 2010, 61508. Jg.

• SCHÄUFFELE, Jörg; ZURAWKA, Thomas. Automotive Software Engineering. Warrendale, PA: SAE International, 2005.

• Norm: ISO 26262

Literatur


Agile Methodik und Scrum:

• MANIFESTO, Agile. Agile manifesto. Haettu, 2001, 14. Jg., S. 2012. Available: http://agilemanifesto.org/ (Last accessed: 06/22/2019)

• SCHWABER, Ken; SUTHERLAND, Jeff. The scrum guide. Scrum Alliance, 2011, 21. Jg.

• MEYER, Bertrand. Agile. The good, the hype and the ugly. Switzerland: Springer International Publishing, 2014.

• GOLL, Joachim; HOMMEL, Daniel. Mit Scrum zum gewünschten System. Wiesbaden: Springer Fachmedien, 2015.

• HANSSEN, Geir Kjetil; STÅLHANE, Tor; MYKLEBUST, Thor. SafeScrum®–Agile Development of Safety-Critical Software. Springer International Publishing, 2018.

Literatur


http://agilemanifesto.org/

Documents

AGIL? ABER SICHER! - Embedded Testing...• Die ISO 26262 fordert ein funktionales und technisches Sicherheitskonzept, ausgehend von einer Gefährdungsanalyse. • Die Risikoanalyseaufgaben