Agil ins Safety-Projekt

Ursprünglich stammen sie aus der Softwareentwicklung, aber mittlerweile haben agile Ansätze auch einen festen Platz bei der Entwicklung industrieller Güter erobert. Oberflächlich betrachtet stehen sich Agilität und funktionale Sicherheit an vielen Stellen diametral gegenüber. So fordert die IEC61508-1 die klare Festlegung von Zuständigkeiten und Verantwortlichkeiten, während im agilen Projektmanagement das Team als Ganzes stärker in die Verantwortung genommen wird. Bei tiefergehender Betrachtung lassen sich zahlreiche agile Konzepte dennoch ebenso nutzbringend im Safety-Projekt verwenden.

Grundzüge der agilen Produktentwicklung

Im Kern geht es darum, agile Praktiken und Methoden einzusetzen, um passende Lösungen in einem von Komplexität geprägten Umfeld zu finden. Im Besonderen gilt das bei der Entwicklung neuer Produkte. Die Grundlagen hierfür umfassen die Dimensionen Vernetzung, Offenheit, Partizipation und Agilität, oder kurz VOPA.

Die Vernetzung beinhaltet die konsequente Nutzung der innerhalb oder außerhalb der Organisation zugänglichen Kompetenzen. Hierfür ist es erforderlich, dass über die Grenzen bestehender Strukturen (Abteilungen, Standorte, Unternehmen) hinaus gedacht wird. Bei der Offenheit spielt eine aktive und offene Kommunikation die zentrale Rolle. Neue Ideen und kreative Problemlösungen entstehen oft im Grenzbereich der unterschiedlichen Disziplinen. Die aktive Förderung des Wissensaustauschs ist eine wichtige Voraussetzung dafür. Die Partizipation zielt auf die Einbeziehung aller relevanten Mitarbeiter in die Entscheidungsprozesse ab, im Einklang von Verantwortlichkeit und Kompetenz. Schlussendlich bleibt noch die Agilität an sich. Teams sollen selbstorganisiert und selbstverantwortlich agieren. Alle Aktivitäten der Organisation sollen sich am Kundennutzen ausrichten.

Lässt man die Kernelemente von VOPA Revue passieren, leuchtet sofort ein, dass diese vom Management gewollt und aktiv gefördert werden müssen, damit sie Teil einer modernen Unternehmenskultur sein können.

Grundlegende Anforderungen der IEC61508

Vorauszuschicken ist, dass diese Betrachtung sich auf die Vermeidung systematischer Fehler beschränkt. Hierfür definiert die IEC61508 diverse Anforderungen, primär im Teil 1 und teilweise in den Teilen 2 (System-/Hardware-/ASIC-Entwicklung) und 3 (Software-Entwicklung).

Dazu gehören:

• Das Management der funktionalen Sicherheit,
• Anforderungen an den Produktlebenszyklus,
• Anforderungen an die Dokumentation,
• ein strukturierter Entwurf und eine strukturierte Spezifikation,
• Verifikation und Validierung
• sowie das Assessment der funktionalen Sicherheit.

Zum besseren Verständnis potenzieller Konfliktfelder werden die sich aus der Auflistung ergebenden Aufgaben innerhalb eines Projekts kurz skizziert.

Das Management der funktionalen Sicherheit und die Anforderungen an den Produktlebenszyklus bilden den Rahmen, in dem das Projekt abgewickelt wird. Kerngedanke dabei ist die klare Festlegung von Verantwortlichkeiten für Abläufe im Projekt und für die zu erstellenden Arbeitsergebnisse. Zwar schreibt die IEC61508 das Vorgehensmodell nicht explizit vor, dennoch werden in der Praxis die Anforderungen an den Produktlebenszyklus meistens mit dem V-Modell beantwortet. Dieses Modell gewährleistet eine strukturierte Vorgehensweise, ausgehend von den (Safety) Requirements, der Architektur, von Design- und technischer Dokumentation sowie den dazugehörenden Testebenen (Modultest, Integrationstests, Validierungs- bzw. Systemtest).Für jedes Arbeitsergebnis und jede Projektphase muss eine geeignete Verifikation bzw. Validierung (V&V) durchgeführt werden. Darunter fallen primär Aktivitäten wie Reviews und Tests, jedoch kann auch eine Analyse als V&V-Nachweis dienen.

Ein Safety-Projekt schließt zwingend mit einem unabhängigen Assessment ab. Inhalt des Assessments sind einerseits der Rahmen, sprich der Prozess, in dem das Projekt abgewickelt wurde, und andererseits die innerhalb des Projekts erstellten Dokumente.

Ausgewählte Spannungsfelder

Beim Vergleich der traditionellen mit der agilen Welt fallen einige unvereinbar erscheinende Spannungsfelder auf. Spiegelt man das agile Manifest an der IEC61508 ergibt sich bei zwei Prinzipien Konfliktpotential:

Prinzip 1: Funktionierende Ergebnisse zählen mehr als umfassende Dokumentation

Prinzip 2: Reagieren auf Veränderungen zählt mehr als das Befolgen eines Plans

Bei näherer Betrachtung dieser Prinzipien muss der Kontext berücksichtigt werden, in dem das agile Manifest entstanden ist: Sie beziehen sich nämlich in der ursprünglichen Form auf reine Softwareprodukte, die den Mechanismen einer „Plattform-Ökonomie“ unterworfen sind. Prinzip 1 setzt voraus, dass der erste Anbieter am Markt das Rennen macht und spätere Produktanpassungen (SW-Updates) für Anbieter und Anwender mit relativ geringem Aufwand durchführbar sind. Für klassische Industriegüter mag es Fälle dieses First Mover Advantage geben, jedoch nur dann, wenn die ersten Produkte am Markt auch den hohen Qualitätsanforderungen der meist konservativen Industriekunden entsprechen. Spätere Anpassungen am Produkt, insofern die Hardware betroffen ist, bedeuten im Vergleich zu reiner Software deutlich höhere Kosten.

Das Reagieren auf Veränderungen ist auch bei Safety-Projekten erlaubt. Zu Prinzip 2 sollte jedoch ergänzt werden, dass Änderungen einem klar definierten Änderungsprozess unterworfen werden müssen, insbesondere Änderungen an der bereits freigegebenen Safety Requirements Specification oder gar am zertifizierten Serienprodukt. Da dies wiederum mit einem höheren Formalaufwand verbunden ist, sollte am Anfang des Safety-Projekts genügend Zeit in eine höhere Stabilität der Anforderungen investiert werden.

Der Schlüssel zur Vereinigung beider Welten liegt dementsprechend darin, ausgewählte agile Methoden so innerhalb eines Safety-Projekts anzuwenden, dass mehr Flexibilität entsteht aber die Anforderungen der IEC61508 dennoch erfüllt werden.

Generische Projektmodelle

Vorweg sei betont, dass unserer Auffassung nach kein generisches Projektmodell unreflektiert auf eine Organisation ausgerollt werden sollte. Jedoch kann die Betrachtung folgender Modelle einen Lösungsrahmen aufzeigen.

Sequentieller Ansatz

Zunächst wird ein Prototyp rein in einem agilen Projekt entwickelt. Erst danach beginnt die Umsetzung in einem IEC61508 konformen Entwicklungsprozess, sozusagen als Folgeprojekt. Dieser Ansatz kann hilfreich sein, wenn noch größere Unsicherheiten hinsichtlich technischer Machbarkeit der Produktidee bestehen. Falls sich die Idee als nicht realisierbar herausstellt, werden so viel Zeit und Geld gespart. Der Nachteil ist jedoch, dass bei der nachgelagerten Safety-Umsetzung in der Regel auch Änderungen am Design erforderlich sind, da im agilen Prototyp meist nicht alle technischen Anforderungen nach der IEC61508-2/-3 berücksichtigt werden.

Paralleler Ansatz

Beim parallelen Ansatz – sicher und agil – kommen im Projekt praktisch zwei Entwicklungsprozesse gleichzeitig zum Einsatz. Grundlegend hierfür ist die Tatsache, dass eine sicherheitsgerichtete Komponente nicht nur aus sicheren Elementen besteht. Wenn diese Elemente hinreichend voneinander unabhängig sind, können die nicht-sicheren Elemente in einem agilen und die sicheren Elemente in einem IEC61508-Prozessmodell umgesetzt werden. In der Praxis ist es typisch, dass nicht-sichere Software, wie integrierte Webserver agil entwickelt werden. Dieses Modell ist folglich dann gut geeignet, wenn das Projekt große, komplexe nicht-sichere Bestandteile beinhaltet.

Integrierter Ansatz

Bei diesem Modell sind agile Methoden in das Phasenmodell nach IEC61508 integriert. Vereinfacht erklärt wird hier innerhalb der Phasen Design, Architektur, Implementierung und Test zunächst agil gearbeitet. Zum Abschluss der Phasen wird jedoch streng darauf geachtet, dass alle für diese Phase definierten Arbeitsergebnisse erzeugt und die festgelegten Verifikations- und Validierungstätigkeiten erfolgreich durchgeführt wurden.

In der Praxis wiederum können Kombinationen aller dieser Grundmodelle angewandt werden. Ebenfalls kann innerhalb einer Organisation individuell für jedes Projekt das jeweils geeignete Modell gewählt werden.

Transfer in der Praxis

Die geschilderten generischen Projektmodelle helfen dabei, einen Lösungsrahmen aufzuzeigen, es ist jedoch davon abzuraten, ein generisches Projektmodell direkt auf eine Organisation zu übertragen. Bei der Einführung eines agilen Projektmodells für Safety-Projekte müssen umfangreiche strategische Leitplanken des Unternehmens berücksichtigt werden.

Im Vorfeld der Einführung gilt es daher, Kernfragen zu beantworten:

• In welchen Bereichen des Unternehmens sollen agile Methoden eingeführt werden? Im Management, im Produktmanagement, in der Entwicklung …
• Wieviel Agilität verträgt die Organisation?
• Welche Kultur herrscht im Unternehmen?
• Wieviel Agilität möchte das Management zulassen?
• Was verspricht man sich von der Einführung agiler Methoden?
• Welche Ziele sollen damit erreicht werden?
• Wie sehen die typischen Projekte des Unternehmens aus: Evolutionäre Weiterentwicklung oder „revolutionäre“ Neuent wicklungen?
• Welche Produkte oder Dienstleistungen werden angeboten: Mechanik, Elektronik, Firmware, Software, oder Services?
• Wo steht das Unternehmen? – Wo steht der Wettbewerb?

Vor der Einführung sollte also zunächst eine fundierte Bestandsaufnahme des Status-Quo, der spezifischen Herausforderungen und der genauen Zielsetzung stehen. Bei der Definition und Einführung der neuen Projektmodelle sollten zudem Experten aus den Gebieten der funktionalen Sicherheit und agiler Methoden mit starkem Praxisbezug und Verständnis für das Kerngeschäft des Unternehmens zur Verfügung stehen.

Zusammenfassung und Fazit

Agile Safety, – agile Methoden und funktionale Sicherheit – sind heute kein Widerspruch mehr. Das bestätigen auch die Zertifizierer. Zahlreiche Industrieunternehmen haben die Synthese bereits erfolgreich vollzogen und können dadurch innovative Produkte in kürzerer Zeit entwickeln und früher in den Markt einführen.