Vorlage: Folienmaster_169 (2015/02/13) AGIL? ABER SICHER! EIN METAMODELL ZUR VERWALTUNG VON USER STORIES UND ARTEFAKTEN DER FUNKTIONALEN SICHERHEIT 1 Eine Präsentation der IT-Designers Gruppe – von Hannes Todenhagen
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
2Eine Präsentation der IT-Designers Gruppe – von Hannes Todenhagen
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
3Eine Präsentation der IT-Designers Gruppe – von Hannes Todenhagen
MOTIVATION
WIESO AGIL UND WAS BRINGT AGILITÄT?
4Eine Präsentation der IT-Designers Gruppe – von Hannes Todenhagen
• 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
5Eine Präsentation der IT-Designers Gruppe – von Hannes Todenhagen
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
Motivation – Agile Methodik
6Eine Präsentation der IT-Designers Gruppe – von Hannes Todenhagen
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.
Motivation – Agile Methodik
7Eine Präsentation der IT-Designers Gruppe – von Hannes Todenhagen
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.
Motivation – Agile Methodik
8Eine Präsentation der IT-Designers Gruppe – von Hannes Todenhagen
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
9Eine Präsentation der IT-Designers Gruppe – von Hannes Todenhagen
„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
10Eine Präsentation der IT-Designers Gruppe – von Hannes Todenhagen
• 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
11Eine Präsentation der IT-Designers Gruppe – von Hannes Todenhagen
DAS METAMODELL
DIE GRUNDLAGE FÜR ERFOLGREICHES AGILES ARBEITEN
12Eine Präsentation der IT-Designers Gruppe – von Hannes Todenhagen
• 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
13Eine Präsentation der IT-Designers Gruppe – von Hannes Todenhagen
• 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
14Eine Präsentation der IT-Designers Gruppe – von Hannes Todenhagen
• 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
15Eine Präsentation der IT-Designers Gruppe – von Hannes Todenhagen
• Ausgehend von dem WorkItem-Typ „User Story“, wird das Metamodell schrittweise aufgebaut.
Das Metamodell – WorkItem-Typen und deren Beziehungen
16Eine Präsentation der IT-Designers Gruppe – von Hannes Todenhagen
• Requirements werden aus einer User Story abgeleitet.
• Tasks beschreiben die Implementierungsaufgaben.
Das Metamodell – WorkItem-Typen und deren Beziehungen
17Eine Präsentation der IT-Designers Gruppe – von Hannes Todenhagen
• Zusätzliche WorkItem-Typen beschreiben den Status und die Ergebnisse der funktionalen Risikoanalyse in Bezug auf eine User Story.
Das Metamodell – WorkItem-Typen und deren Beziehungen
18Eine Präsentation der IT-Designers Gruppe – von Hannes Todenhagen
19Eine Präsentation der IT-Designers Gruppe – von Hannes Todenhagen
• Der Bezug zur Produktvision wird über das Safety Goal, die Gefährdungen und Szenarien hergestellt.
Das Metamodell – WorkItem-Typen und deren Beziehungen
20Eine Präsentation der IT-Designers Gruppe – von Hannes Todenhagen
21Eine Präsentation der IT-Designers Gruppe – von Hannes Todenhagen
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.
Das Metamodell – WorkItem-Typen und deren Beziehungen
22Eine Präsentation der IT-Designers Gruppe – von Hannes Todenhagen
• Technische Risiken und entsprechende technische Sicherheitsanforderungen werden zusätzlich mit der User Story verlinkt.
Das Metamodell – WorkItem-Typen und deren Beziehungen
23Eine Präsentation der IT-Designers Gruppe – von Hannes Todenhagen
24Eine Präsentation der IT-Designers Gruppe – von Hannes Todenhagen
• Metainformationen wie Testergebnisse und Commit-Informationen werden ebenfalls verlinkt.
Das Metamodell – WorkItem-Typen und deren Beziehungen
25Eine Präsentation der IT-Designers Gruppe – von Hannes Todenhagen
26Eine Präsentation der IT-Designers Gruppe – von Hannes Todenhagen
• Ein Workflow für jeden WorkItem-Typ vervollständigt das Metamodell.
Das Metamodell – Workflows
27Eine Präsentation der IT-Designers Gruppe – von Hannes Todenhagen
• 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
28Eine Präsentation der IT-Designers Gruppe – von Hannes Todenhagen
BEISPIEL
BEISPIELE AUS DEM FORSCHUNGSPROJEKT MEC-VIEW
29Eine Präsentation der IT-Designers Gruppe – von Hannes Todenhagen
• Mobile Edge Computing basierte Objekterkennung für hoch- und vollautomatisiertes Fahren in urbanen Verkehrsräumen
Beispiel – Das Forschungsprojekt MEC-View
30Eine Präsentation der IT-Designers Gruppe – von Hannes Todenhagen
Projekthomepage: http://www.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
31Eine Präsentation der IT-Designers Gruppe – von Hannes Todenhagen
• 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
32Eine Präsentation der IT-Designers Gruppe – von Hannes Todenhagen
Beispiel – FMEA-Widget
33Eine Präsentation der IT-Designers Gruppe – von Hannes Todenhagen
Beispiel – FMEA-Widget
34Eine Präsentation der IT-Designers Gruppe – von Hannes Todenhagen
• 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
35Eine Präsentation der IT-Designers Gruppe – von Hannes Todenhagen
• Im Rahmen der Entwicklung wurden mehrere Dashboards definiert.
• Dashboards zeigen Metriken und Traceability Tabellen verschiedener WorkItems in einzelnen Widgets.
Beispiel – Dashboards und Dokumente
36Eine Präsentation der IT-Designers Gruppe – von Hannes Todenhagen
FAZIT
VORTEILE DES METAMODELLS UND MÖGLICHE ANWENDUNGEN
37Eine Präsentation der IT-Designers Gruppe – von Hannes Todenhagen
• 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
38Eine Präsentation der IT-Designers Gruppe – von Hannes Todenhagen
VIELEN DANK FÜR IHRE AUFMERKSAMKEIT!
39Eine Präsentation der IT-Designers Gruppe – von Hannes Todenhagen
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
40Eine Präsentation der IT-Designers Gruppe – von Hannes Todenhagen
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
41Eine Präsentation der IT-Designers Gruppe – von Hannes Todenhagen