Blog

Warum der DO-178C-Standard mehr Flexibilität bei der Software-Entwicklung erfordert

Zunächst sei bemerkt, dass der DO-178C-Standard keinen bestimmten Lebenszyklus oder eine bestimmte Methodik voraussetzt. Er beschreibt Ziele und Schritte die zur Erreichung dieser Ziele umgesetzt werden können. Zudem sind die Ziele zum Beispiel recht allgemein gehalten: «Es müssen übergeordnete Anforderungen entwickelt werden».

Es mag erscheinen, dass eine solche Verschwommenheit der einzelnen Ziele in DO-178C zu viel Raum für Anarchie im Projektlebenszyklus zulässt. Ein vollständiger Satz von mehreren Dutzend miteinander verbundenen Zielen würde jedoch den Handlungsspielraum bei der Wahl eines Lebenszyklus beträchtlich einschränken. Das Wasserfall oder V-Modell des Lebenszyklus scheint der einfachste und logischste Weg zu sein, alle Ziele auf einmal zu erfüllen. Der einfachste Weg ist jedoch nicht immer der geeignetste.

Die Ziele sind in 10 Gruppen unterteilt, die in den Tabellen A1 bis A10 im Anhang der Norm dargestellt sind. Jede Gruppe entspricht einem bestimmten Aspekt des Lebenszyklus. Darüber hinaus definiert die Tabelle die Prozessstrenge in Bezug auf die Software-Ebene:

<IMG>


Der Logik der Dinge zufolge gilt: je höher die Ebene, desto mehr Ziele sind zu erreichen. Schauen Sie sich jedoch die Verteilung dieser Ziele an. Die Anzahl der Verifikationsziele übersteigt die Anzahl der Entwicklungsziele um ein Vielfaches. Außerdem sind die Entwicklungsziele für Software der Stufen A, B und C genau die gleichen. Somit geht der DO-178C-Standard davon aus, dass die Zuverlässigkeit der Software auf der Sorgfältigkeit der Verifikation beruht. Diese Schlussfolgerung lässt sich noch eindeutiger formulieren: «Von der Zuverlässigkeit der sicherheitskritischen On-Board-Software kann nichts gesagt werden, bis die Verifikation abgeschlossen ist!»

Es überrascht nicht, dass Wasserfall- und V-Modell durchaus kostspielig werden können, wenn ein Fehler Zeit hat sich über den gesamten Lebenszyklus auszubreiten, bevor er in späten Verifikationsphasen festgestellt wird. Häufig werden zusätzliche Iterationen des gesamten Zyklus am Ende der Zeitachse des Produkts hinzugefügt, um Probleme vom Anfang der Geschichte an zu beheben. Als Ergebnis haben wir Terminstress, demoralisiertes und ausgelaugtes Projektteam, verärgerte Kunden und aufgebrachte Topmanager.

Der offensichtliche Ratschlag für Projektleiter ist, so viele Verifikationen wie möglich bereits in einem frühen Stadium durchzuführen. Bingo! Dieses Konzept ist eines der charakteristischen Merkmale von "Agil".

Ich möchte dem Feuer des heiligen Krieges der Schwergewichte gegen das „Agile“ kein Öl ins Feuer gießen. Ich möchte hervorheben, dass die Bezeichnung "agil" nicht gleichbedeutend mit Anarchie ist. Behandeln Sie die Anforderungen, den Entwurf und andere erforderliche Ergebnisse als einen wertvollen Teil Ihres Produkts und nicht als lästige oder ermüdende Dokumentation. Aus dieser Perspektive sind die Agilen Methoden ideal für die Lösung bestimmter Aufgaben: Fragmentieren Sie Ihr Lebenszyklusmodell einfach in kleinere Iterationen und integrieren Sie die Verifizierung in den Lebenszyklus.

Sicherlich ist es bei der bei der Implementierung von "Agile" im einem sicherheitskritischen Projekt notwendig, besondere Vorsicht zu wahren. Es ist keine leichte Aufgabe, den Geist der "agilen" Methodologie an die DO-178C-Umgebung anzupassen. Ich werde ein praktisches Beispiel für eine solche Anpassung in meinem nächsten Beitrag anführen.