In der Softwareentwicklungsbranche kam es in den letzten Jahren zu einem Umbruch. Aktuelle Herausforderungen, wie etwa rasch kürzer werdende Innovationszyklen, legen den Einsatz agiler Methoden nahe. So auch in Safety-relevanten Bereichen. [...]
Die sich ändernden Anforderungen des Marktes konfrontieren Unternehmen zunehmend mit immer kürzer werdenden Innovationszyklen und der schnellen Reaktion auf Veränderungen der Bedürfnisse. Auf Grund dieser Tatsachen haben sich viele Softwareentwicklungsteams den traditionellen Modellen wie dem Wasserfall- oder V-Modell abgewandt und sind auf agilere Methoden umgestiegen. Diese Faktoren haben nun auch den Einzug in den Bereich der Entwicklung von sicherheitskritischen Softwareanwendungen gefunden.
Der Einsatz agiler Methoden in diesem Bereich scheint jedoch Konfliktpotenziale zu verursachen. Diese Konflikte stützen sich im Wesentlichen auf die unterschiedliche Auffassung des Entwicklungsprozesses beider Ansätze. Während Safety-relevante Ansätze großen Wert auf Formalität und Prozessorientierung legen, wird der Fokus bei agilen Methoden auf die Individuen und deren Interaktion gelegt. Umfassende Dokumentation, welche im Safety-relevanten Bereich als Evidenz der ordnungsgemäßen Betrachtung aller sicherheitskritischen Gefahren gilt, wird in agilen Ansätzen zu Gunsten lauffähiger Software weniger gewichtet. Bezüglich des Verhältnisses zu Kunden steht in agilen Methoden die Zusammenarbeit und die Reaktion auf sich ändernde Anforderungen im Zentrum. Softwareentwicklungsmethoden, die im sicherheitskritischen Bereich Tradition haben, legen hier vermehrt Wert auf die Einhaltung von Verträgen und dem Verfolgen der erstellten Planung. Ein weiteres wesentliches Unterscheidungsmerkmal ist die gänzlich konträre Vorgehensweise von agilen und traditionellen Vorgehensmodellen. Während letztere stark sequentiell vorgehen, wird in agilen Methoden vermehrt iterativ Software entwickelt. In agilen Methoden finden daher keine Analyse der Anforderungen und Entwicklung des Designs vor der Implementierung statt. Dies ist jedoch im Bereich sicherheitskritischer Softwareentwicklung erforderlich, da diese Ergebnisse direkt als Information in die Safety-Analysen einfließen.
Bei der Anwendung von agilen Methoden im sicherheitskritischen Bereich stellt sich nun die Frage, wie diese Konflikte überwunden und die im Prozess notwendigen Safety-Analysen ohne der dafür benötigten Informationen durchgeführt werden können. Um diese Frage zu beantworten, wurden nun Lösungsansätze für ein geeignetes Vorgehensmodell entwickelt.
Ein Lösungsansatz widmet sich der Problematik der fehlenden Information für den Safety-Prozess in der Anfangsphase der Softwareentwicklung, die für die Identifizierung von Hazards notwendig wäre. Hierfür wird die sogenannte „Pre-Game“-Phase angedacht. Die Ziele dieser Phase, die vor der ersten agilen Iteration stattfinden soll, sind die Schaffung einer gemeinsamen Vision, die Identifizierung der wesentlichsten Anforderungen, die Erstellung eines High-Level-Designs und die darauf basierenden ersten Safety-Analysen.
Ein weiterer, auf dem ersten aufbauender Lösungsansatz widmet sich der fortlaufenden evolutionären Weiterentwicklung des Designs und der Safety-Analysen. Dies führt zu spezifischen Aufgaben des Systemarchitekts und des Safety Engineers:
– Evaluation der letzten Iteration (Eignung der eingesetzten Architektur und Verifikation der Implementierung der Safety-Anforderungen)
– Vorbereitung der nächsten Iteration (Lenkung des Designs durch Priorisierung der Anforderungen sowie Durchführung der Safety-Analysen basierend auf zukünftigen Anforderungen)
Diese Ansätze bieten den Vorteil, dass Änderungen, die sich durch die Umwelt ergeben, laufend in den Entwicklungsprozess einfließen können. Weiters werden sämtliche Entscheidungen basierend auf dem neuesten Informationsstand getroffen und können so den Fortschritt der Software positiv beeinflussen.
* Christoph Schmiedinger ist Development Project Manager bei der Frequentis AG.
Be the first to comment