Share ZU:
12 April 2016 @ Karsten Krennrich

Scrum und ISO 26262: Nahe Verwandte oder grundlegend verschieden?

Im Rahmen eines Workshops sind mein Kollege Philip Stolz und ich gemeinsam mit den Teilnehmern, überwiegend Kollegen aus der Automobilentwicklung, dieser Frage auf den Grund gegangen. Wir haben Unterschiede und Gemeinsamkeiten des Scrum Frameworks und der Norm ISO 26262 herausgearbeitet.

Zunächst könnte man annehmen, dass es zwischen einem der bekanntesten agilen Frameworks (Scrum) und der ISO 26262 keine Gemeinsamkeiten und nur Unterschiede gibt. Tatsächlich sind wir u.a. auch auf die folgenden Unterschiede gestoßen:

  ISO 26262 Scrum Framework
Prozess / Vorgehen Es wird ein Phasenmodell mit Aktivitäten empfohlen, das sich stark an dem V-Modell orientiert. Das Rahmenwerk beschreibt fünf Ereignisse (Sprint Planning, Sprint, Daily Scrum, Sprint Review und Sprint Retrospektive), die zyklisch wiederholt werden. Die Ereignisse stellen dabei nur Hüllen für konkrete Arbeitsinhalte dar und machen dabei keine Unterscheidung zwischen den Arten der Arbeitsinhalte, wie z.B. Entwicklung oder Test.
Rollen / Verantwortung Die Rolle des Safety Managers ist für die Umsetzung der geforderten Funktionalen Sicherheit verantwortlich. Es gibt das Scrum Team mit den folgenden drei Rollen: Scrum Master, Product Owner, Development Team. Die Gesamtverantwortung für den Entwicklungsgegenstand verteilt sich auf alle diese Rollen.
Arbeitsergebnisse Nicht jedes Arbeitsergebnis, das in einer Phase erstellt oder entwickelt wird, muss dem Kunden als nutzbares Produkt dienen. In jedem Sprint steht die Erstellung oder Entwicklung eines, für den Kunden nutzbaren,  Inkrements im Vordergrund.

Bei näherer Betrachtung haben wir zusammen mit den Teilnehmern aber auch wesentliche Gemeinsamkeiten gefunden:

  1. Sowohl die ISO 26262 als auch das Scrum Framework sprechen davon, Artefakte zu entwickeln.
  2. Die Agilen Werte und Prinzipien betonen funktionierende Software/Systeme. Im Sinne der ISO 26262 ist eine Software/ ein System genau dann funktionierend, wenn dafür die erforderlichen Nachweise für funktionale Sicherheit erbracht wurden. Daher trägt die Existenz bestimmter Dokumentation zum Funktionieren der Software/des Systems bei.
  3. Es werden nur wenige Empfehlungen bezüglich der Art und Weise der Umsetzung bzw. der Form der Arbeitsergebnisse gemacht. Das Scrum Framework macht hierzu überhaupt keine Aussage. Die ISO 26262 sagt beispielsweise auch nur, dass „Safety goals“ oder „Safety requirements“ dokumentiert werden müssen, aber wie diese genau abgebildet werden, regelt die Norm nicht.

Diese Gemeinsamkeiten konnten wir dazu nutzen, um Ansätze zu erarbeiten, die es ermöglichen, Anforderungen der ISO 26262 mittels agiler Vorgehensweisen wie z.B. dem Scrum Framework zu erfüllen. Ein Hauptansatz ist es, den Fokus von der Befolgung von Prozessen und Aktivitäten auf die inkrementelle Erstellung von Artefakten (Arbeitsergebnisse oder Inkremente) mit einer bestimmten Qualität zu richten.

Wir kommen also zu dem Schluss, dass Scrum und die ISO 26262 zwar keine nahen Verwandten sind, aber durchaus das Potential haben, eine erfolgsversprechende Bindung miteinander einzugehen.

Karsten Krennrich

Kontaktieren Sie Karsten Krennrich

Herr Karsten Krennrich ist als Consultant der HOOD Group tätig. Seine Schwerpunkte liegen in der Beratung von Requirements Engineering (RE) orientierten Entwicklungsprozessen. Er ist als Projektleiter bei der HOOD Software Division verantwortlich für die Realisierung von Softwarelösungen im Bereich der Entwicklungsprozess unterstützenden Werkzeuge. Für diese Anpassungen und Erweiterung von Standard Werkzeugen erarbeitet Herr Krennrich auch die zur Realisierung notwendigen Konzepte. Bei deren Implementierung arbeitet Herr Krennrich unter anderem auch mit den Konfigurationsmanagement Werkzeugen CMSynergy und Subversion. Neben dem RM-Werkzeug DOORS® von IBM hat Herr Krennrich auch Praxiserfahrungen mit den Werkzeugen CaliberRM® von Borland und RequisitePro® von IBM. Er verfügt außerdem über Erfahrungen im Bereich Datenbanken und Informationssysteme, im Software Engineering und im Themenbereich Produktlinien.