Funktionale Sicherheit
Agil entwickeln - auch bei Safety-Projekten?
Die Methoden der agilen Software-Entwicklung haben das Ziel, den Entwicklungsprozess flexibler und schlanker zu gestalten – im Vergleich zum klassischen Vorgehen mit dem V-Modell. Eignen sich diese Methoden auch für funktional sichere Systeme?
Die Software-Entwicklung hat sich in den letzten 50 Jahren kontinuierlich weiterentwickelt. Schon seit einigen Jahren tauchen nun regelmäßig Begriffe wie ‚Agil‘ oder ‚Scrum‘ als Vorgehensmethodik auf, und der Großteil etablierter Entwick-lungsteams arbeitet mittlerweile in den meisten Projekten auf dieser Basis. Agile Entwicklungsmethoden haben vor allem einen enormen Vorteil gegenüber klassischen Modellen: Sie eignen sich besonders gut, um flexibel und schnell auf sich verändernde Anforderungen zu reagieren. Auch hat sich gezeigt, dass Projekte, die mit agilen Methoden erstellt werden, eine deutlich höhere Wahrscheinlichkeit für einen erfolgreichen Abschluss aufweisen.
Eine Ausnahme für den Einsatz agiler Methoden bilden bis heute oft noch viele Softwareprojekte mit Bezug zur Funktionalen Sicherheit. Der Grund liegt unter anderem darin, dass die Basisnorm für solche funktional sicheren Systeme, die IEC 61508, das klassische V-Modell in der Beschreibung der einzelnen Entwicklungsphasen nutzt. Auch viele Leitfäden basieren auf dem V-Modell. Doch Softwareprojekte in der Funktionalen Sicherheit werden zunehmend komplexer, was zu erhöhten Herausforderungen beim Einsatz der klassischen Vorgehensmethoden führt. Daher liegt die Überlegung nahe, ob sich agile Methoden in der Funktionalen Sicherheit nutzen lassen, um Software flexibler und effizienter entwickeln zu können.
Was bedeutet ‚agil‘?
Bild 1: Auszug aus dem agilen Manifest mit hervorgehobenen, zentralen Anforderungen aus der IEC 61508.
© Infoteam SoftwareIn der Literatur wird der Februar 2001 als das Datum genannt, an dem das ‚Agile Manifest‘ als Meilenstein formuliert wurde. Die darin getroffenen Aussagen nehmen direkten Bezug zu Werten, die auch bei der Entwicklung funktional sicherer Software eine entscheidende Rolle spielen (siehe Bild 1). Einige dieser Werte (im Bild 1 in Rot dargestellt) erfahren allerdings im agilen Prozess eine leichte Abschwächung. Dies fällt insbesondere bei zentralen Punkten wie ‚Prozess‘, ‚Dokumentation‘ und ‚Plan‘ auf, die in der Entwicklung funktional sicherer Software höchsten Stellenwert genießen. Daraus ergeben sich drei wichtige Kernfragen:
- Kommt die agile Entwicklung ohne die auf der rechten Seite genannten Werte aus?
- Sind Projekte dadurch erfolgreicher und Kunden entsprechend zufriedener?
- Stehen, falls beide formulierten Teilaspekte tatsächlich zutreffen, die Anforderungen der IEC 61508 an den Entwicklungsprozess funktional sicherer Software dem Einsatz von agilen Methoden entgegen?
Tatsächlich – so viel sei vorweggenommen – arbeiten auch agile Teams nicht ohne Prozess; ganz so erfolglos sieht es aus Safety-Sicht also nicht aus.
Die Unterschiede in den Prozessmodellen
Nachfolgend soll Scrum als Beispiel für die agile Vorgehensmethodik dienen. Der Ansatz von Scrum ist, empirisch, inkrementell und iterativ zu arbeiten. Er beruht auf der Erfahrung, dass viele Entwicklungsprojekte zu komplex sind, um in einen vollumfänglichen Plan gefasst werden zu können. So ist ein wesentlicher Teil der Anforderungen und der Lösungsansätze zu Beginn häufig noch unklar. Diese Unklarheit lässt sich beseitigen, indem Zwischenergebnisse geschaf-fen werden, anhand derer sich nachfolgend die fehlenden Anforderungen und Lösungstechniken effizienter finden lassen als durch eine abstrakte Klärungsphase.
In den Normen zur Funktionalen Sicherheit findet sich das V-Modell, das in der Software-Entwicklung auch als Wasserfallmodell bekannt ist. Es ist ein lineares, nicht iteratives Vorgehensmodell, das in aufeinanderfolgenden Projektphasen organisiert ist. Dabei gehen Phasenergebnisse, wie bei einem Wasserfall, immer als bindende Vorgaben für die nächsttiefere Phase ein. Jede Phase hat vordefinierte Start- und Endpunkte mit eindeutig definierten Ergebnissen und wird nur einmal durchlaufen – zumindest in der Theorie! Tatsächlich gibt es auch in einem Safety-Projekt sogenannte ‚Late Requirements‘. Insofern muss auch so etwas wie ‚Iterationen‘ bei den Projektphasen beherrscht werden.
Darüber hinaus schreibt die IEC 61508 nicht zwingend den Einsatz des V-Modells als Entwicklungsprozess vor! Ein Tailoring des Entwicklungsprozesses ist erlaubt, und meist ist nur Bequemlichkeit die Motivation, das V-Modell in den Projektbeschreibungen als Vorgehensweise vorzugeben. Schließlich sparen die Projektleiter bei der eigenen Entwicklung auf diese Weise den sonst zu erbringenden Nachweis ein, dass alle Ziele und Anforderungen in den Lebenszyklusphasen entsprechend der Norm erfüllt werden.
Gibt es ein agiles V-Modell?
Bild 2: Beispielhaftes ‚agiles‘ V-Modell, das die Anforderungen und das Design klassisch ‚statisch‘ vorsieht und die Implementierung und das Testen agil interpretiert und integriert.
© Infoteam SoftwareBei Betrachtung des klassischen V-Modells (siehe Bild 2 in Rot) fällt auf, dass die linke Seite (Entwicklung) parallel zur rechten Seite (Testen) angegangen werden kann. Eine Möglichkeit dafür ist, sowohl die Phase ‚Implementation‘ als auch ‚Test/Überprüfung‘ wie ein agiles Projekt anzugehen. Doch warum erst ab der Phase der Implementation?
Bild 3: Vereinfacht dargestellt: Für das ‚iterative‘ V-Modell werden zu Beginn einmal die Anforderungspakete erstellt, welche später für die einzelnen Iterationsschritte als Grundlage dienen.
© Infoteam SoftwareDer Grund hierfür liegt in der Risikobetrachtung, die bei den beiden vorangehenden Schritten einen hohen Stellenwert einnimmt. Für das Definieren der Anforderungen und für die Dokumentation eines Systementwurfs ist deshalb ein ‚statischer‘Ablauf die effizientere Methode im Vergleich zu einem (hoch-) dynamischen Design, das die Konsequenz aus Änderungen der Anforderungen wäre.
Verfechter agiler Modelle schütteln bei einem solchen ‚agilen V-Modell‘ zu Recht den Kopf und argumentieren, dass ein solches Vorgehen nicht agil, sondern ‚nur‘ iterativ sei. Denn einen elementaren Teil ignoriert dieses Modell: die Dynamik innerhalb der Anforderungen, was gerade einen der Vorteile der agilen Vorgehensweise darstellt. Das ‚agile V-Modell‘ definiert dagegen nur einmal Anforderungen als unveränderliche Grundlage für die nachfolgenden Iterationen (Bild 3).
Bild 4. Beispielhaftes Modell für einen Safety-Scrum-Prozess: Der eigentliche Sprint wird ummantelt von den Aktivitäten Safety-Analyse zu Beginn und Safety-Validierung am Ende.
© Infoteam SoftwareMöglicherweise wäre es aufgrund dieser Tatsache konsequent, einen sicheren Scrum-Prozess zu definieren. Das sieht erstmal nicht so schwierig aus: Für jeden Sprint muss zunächst eine neue Aktivität ‚Safety-Analyse‘ durchgeführt werden, auf die der eigentliche Sprint und mit der ‚Safety-Validierung‘ eine zusätzliche Aktivität als Abschluss folgen (Bild 4).
So einfach ist es allerdings nur in der Theorie, denn für die Entwicklung ergeben sich auf diese Weise tatsächlich zwei überlappende Prozessmodelle – unter Berücksichtigung der Zertifizierungsprüfung sind es sogar drei: Da ist zum einen die ‚Safety-Analyse‘, also die Betrachtung der Risiken. Hier werden während des ‚backlog grooming‘ Einträge im Produkt-Backlog erstellt, welche die Sicherheitsanforderungen an das System definieren. Während der Sprint-Planung ist wiederum eine Safety-Analyse durchzuführen. Grund dafür sind die in das Sprint-Backlog übernommenen Einträge. Durch sie entstehen erneut Risiken im System, die es zu betrachten gilt, da der vorher entstandene Systemzustand geändert wird und somit der Bezug auf Systemrisiken durch Änderung-Auswirkung-Analysen zu überprüfen ist. Letztlich ist auch im abschließenden Sprint-Review eine Safety-Analyse durchzuführen.
Beim Validierungsanteil sind in Bezug auf das Scrum-Prozessmodell während des ‚backlog grooming‘ ebenfalls Einträge vorzunehmen, die im Weiteren zu beachten und für gewöhnlich während des abschließenden Sprint-Reviews durchzuführen beziehungsweise zu prüfen sind. Vergleichbar dazu liefern daneben die Zertifizierungsprüfungen Aufgaben, die in das Produkt-Backlog einzupflegen und dann umzusetzen sind – also im ‚daily scrum‘, im Sprint-Review und in der Sprint-Retrospektive adressiert werden. Dieses Safety-Assessment sollte kontinuierlich und parallel über die gesamte Entwicklung begleitend durchgeführt werden, damit das daraus resultierende Feedback so früh wie möglich wieder berücksichtigt werden kann.
Das Safety-Assessment ist dadurch ein eigenständiger Scrum-Prozess, der parallel zur Entwicklung durchlaufen wird und eigene Safety-bezogene Aktivitäten und Rollen kennt – wie beispielsweise ‚Assessment Owner‘ und ‚Assessment Backlog‘. Angesichts dieser notwendigen Vorgehensweise ist die Frage gerechtfertigt, ob ein Safety-Scrum-Prozess tatsächlich die ursprüngliche Motivation agiler Entwicklungsmethoden hinsichtlich Flexibilität und „schlanker als klassische Vorgehensmodelle“ erfüllt.
Im Übrigen ist das hier beispielhaft genannte Scrum nur eines von mehreren agilen Vorgehensmodellen. Allen Modellen ist jedoch gemein, dass sie Eigenschaften aufweisen, die Vertreter agiler Methoden zwar gewahrt haben möchten, die jedoch diametral zu den Anforderungen der Normen für Funktionale Sicherheit verlaufen oder sich nur wenig effizient in Safety-Projekten anwenden lassen.
Der Ansatz, wenigstens Teilaspekte aus der agilen Welt in den Safety-Prozess zu übernehmen und so den Entwicklungsprozess im Rahmen der Möglichkeiten etwas variabler und optimierter zu gestalten, ist tatsächlich nicht so schwierig. In der Prozessphase ‚Wartung und Pflege‘ beispielsweise findet sich schon immer eine iterative Vorgehensweise: das ‚Change-Management‘. Eine legitime und normenkonforme Vorgehensweise ist es, schon während der noch laufenden, nicht abgeschlossenen Entwicklung diesen Change-Management-Prozess zu verinnerlichen und umzusetzen.
Lösung: V-Modell mit Iterationen?
Dadurch wird zum einen eine Annäherung an agile Vorgehensweisen geschaffen. Zum anderen schult ein solches Vorgehen gleichzeitig die Entwicklungsteams für den Prozess, den sie nach der Abnahme/Übergabe/Zertifizierung zu leben haben.
Zusammenfassend lässt sich festhalten: Im normativ regulierten Umfeld, wie etwa der Entwicklung funktional sicherer Software, ist es in der Tat schwierig, ein Prozessmodell zu finden, das für alle Projekte die exakt passende Lösung darstellt. Wichtig ist große Erfahrung im Umgang sowohl mit den Anforderungen der Safety-Normen als auch mit dem Vorgehen agiler Entwicklungsmethoden, denn nicht alle Aufgabenstellungen lassen sich in der Funktionalen Sicherheit agil besser und effizienter bewältigen. Dennoch zeigen erfolgreich abgeschlossene Softwareprojekte, dass die Antwort auf die Frage „Agilität in Safety-Projekten – geht das?“ durchaus „Ja!“ lauten kann.
Autor:
Frank Poignée ist Consultant Safety und Chief Engineer bei der Infoteam Software.
Das könnte Sie auch interessieren
Das deterministische IIoT
Der Netzwerk- und Echtzeit-Spezialist TTTech arbeitet mit Hochdruck daran, seine TSN-Lösung für den breiten Rollout weiter zu optimieren – und verknüpft sie mit ihrer wachsenden IIoTPlattform. Ein Gespräch mit Georg Kroiss, Business Development...
mehr...Für vielfältige Anwendungen
Als Bedienstationen sind Panel-PCs im Fertigungsprozess mittendrin im Geschehen. Deshalb müssen die Geräte je nach Branche gewisse Mindest-Anforderungen erfüllen – etwa bezüglich der Schutzklasse, der Hygiene sowie der Handschuhbedienung.
mehr...Wenn Botnetze angreifen
Den Nachweis, dass sich IoT-Systeme sehr einfach angreifen lassen, haben inzwischen nicht nur unzählige Live-Hacks erbracht, sondern auch reale Botnetz-Angriffe. Servicezugänge erweisen sich dabei als gravierende Schwachstelle.
mehr...Echtzeit für Fog-Server
In Zeiten von Industrie 4.0 ist Echtzeit zwischen Maschinen und Anlagen und ihren zu- und abführenden Systemen gefordert. Virtualisierte Fog-Server in redundanter Auslegung sind dafür prädestiniert. Basis hierfür sind Computer-on-Module mit 10 GbE...
mehr...Robust in die Fertigung
Flash-Module punkten mit Platzersparnis und Stabilität gegenüber mechanischen Festplatten. Aber sind Daten bei Spannungsausfall, Vibration und Temperaturschwankungen auch wirklich sicher?
mehr...Die IIoT-Alternative
AllJoyn ist eine Open-Source-IoT-Initiative, die auf den Consumer-Electronic-Markt abzielt. Das Ziel: Geräte und Systeme erkennen sich selbstständig und interagieren. Erste AllJoyn-Anbindungen für CAN-basierte Produkte machen das Framework auch für...
mehr...Controller für das IIOT
National Instruments stellt jetzt eine Familie von Industrie-Controllern vor, die für den Einsatz an 'Smart Machines' und in intelligenten Systemen für das industrielle Internet der Dinge prädestiniert sein soll. Welche Philosophie und Strategie...
mehr...Die neue Rolle von Single-Board-Computern
Der Raspberry Pi wurde ursprünglich entwickelt, um Kinder für das Programmieren zu begeistern und ihr Interesse an einem Job in der Elektrobranche zu wecken. Doch sein Erfolg hat auch die Kreativität professioneller Ingenieure entfacht, die den...
mehr...Der Weg ins IoT
Das IoT fordert Entwickler heraus: Die Notwendigkeit, Embedded-Applikationen schnell zu entwickeln, einzusetzen und zu warten, stellt bisher verwendete Tools und Methoden in Frage. Ein Plattformkonzept inklusive IoT-Betriebssystem hilft Ingenieuren...
mehr...