Blog

Der "agile" Ansatz in einem sicherheitskritischen Bereich

In meinem früheren Beitrag unter dem Titel «Warum der DO-178C-Standard mehr Flexibilität bei der Software-Entwicklung erfordert» habe ich über die Wichtigkeit von Verifizierungsmaßnahmen für Projekte in sicherheitskritischen Bereichen berichtet und erläutert, warum man diese Aktivitäten besser nicht aufschieben sollte. Theoretisch sollten die Tests unmittelbar nach der Entwicklung eines Teils der Anforderungen und des entsprechenden Codes durchgeführt werden. Dieser Ansatz ist in der Welt der "agilen" Softwareentwicklung weit verbreitet. Dabei werden zwei spezielle Methoden daran ausgerichtet: Testgetriebene Entwicklung (TGE) и Kontinuierliche Integration (KI).

In diesem Artikel werde ich zeigen, wie die Implementierung dieser "agilen" Techniken zur Verbesserung des DO-178C-Projekts durch die Einbeziehung von Tests in den Mini-Entwicklungszyklus bei gleichzeitiger Aufrechterhaltung der Konformität mit dem Standard beiträgt.

Zunächst etwas zur Theorie

Kurz gesagt, sieht die Methode der testgesteuerten Entwicklung wie folgt aus: Schreiben Sie einen Test, führen Sie ihn aus und stellen Sie sicher, dass er ein negatives Ergebnis liefert; dann schreiben Sie einen Code, führen Sie den Test erneut aus und stellen Sie sicher, dass dieser nun ein positives Ergebnis liefert (oder passen Sie den Code an, sofern das Ergebnis immer noch negativ ist). Die Idee hierbei ist, die jeweils gewünschte Funktionalität mit dem Test vorzugeben und dann einen Programmcode zu entwickeln, der den Test erfolgreich bestanden hat. Auf den ersten Blick mag die TGE-Methode für die auf dem DO-178C-Standard basierende Projektstruktur nicht anwendbar erscheinen. Zwei kleine Korrekturen ändern die Situation jedoch vollständig: schreiben Sie einen Test auf der Grundlage der Anforderungen und überlassen Sie die Codeentwicklung und die Testentwicklung an zwei verschiedene Personen. So kann der Grundgedanke der TGE-Methodik organisch an die schwergewichtige Entwicklungsmethodik angepasst werden.

Die kontinuierliche Integration war ursprünglich eine Methode zur häufigen Integration von Arbeitskopien des Programms in seinen Hauptzweig. Das Hauptziel von KI war die Lösung der Integrationsprobleme. Diese Methode wird nun etwas umfassender angesehen. Meistens wird die KI durch einen automatisierten Zusammenbauprozess unterstützt und durch verschiedene Qualitätssicherungsmaßnahmen ergänzt. Die kontinuierliche Integration bildet in Verbindung mit der TGE eine sehr gute Grundstruktur für die Überwachung des Projektstatus und eine spürbare Qualitätssteigerung. Mein Artikel «Begründet sich kontinuierliche Integration? Ganz sicher» beschreibt die KI-Methode etwas näher und wirft ein Licht auf ihre Anwendung bei DO-178C-Projekten.

Von der Theorie zur Praxis

Typische DO-178-Projekte bestehen oft aus mehreren Stufen. Diese Stufen können als "Release", „Assemblierung", "Version", "Download", "Label" usw. bezeichnet werden. Die Dauer einer Stufe liegt in der Regel zwischen zwei und zehn Monaten oder mehr. Jede Stufe besteht wiederum aus einer Reihe von Änderungsanfragen. Nach dem Abschluss der Arbeit an allen Änderungsanfragen wird die Assemblierung freigegeben und an die Verifizierungsgruppe zum Testen weitergeleitet. Anschließend wird parallel zum Testen der vorherigen Assemblierung mit der Arbeit an der nächsten Assemblierung begonnen.



Dieses Prinzip der Projektarbeit führt oft dazu, dass sich der Fehler im Lebenszyklus verwurzelt, Turbulenzen in den Arbeitsablauf hineinbringt und zu Fehlfunktionen in der Arbeit oder auch zu unnötigen Aktionen führt. Zudem sind solche Projekte durch Überraschungen in letzter Minute, ungeplante zusätzliche Stufen zur Fehlerbehebung, Abweichungen vom Zeitplan, Terminverzögerungen und eine Unmenge von bereits bekannten, jedoch bisher nicht behobenen Fehlern in der gelieferten Software geprägt.

Das Ziel der Optimierung des Projektlebenszyklus besteht darin, die Fehlerverbreitung durch deren Erkennung und Behebung während der Entwicklung des jeweiligen Codeteils zu reduzieren.

Dazu ist es notwendig, Korrekturen in Technologie und Verfahren vorzunehmen. Aus technologischer Sicht sind zwei Sachen erforderlich:
  • ein Mittel zur automatisierten Entwicklung und Umsetzung von Assemblierungen;
  • automatisierte Testverfahren.

Eine gute Basisstruktur für Testläufe und die Visualisierung der Ergebnisse ist eine wünschenswerte, aber keine zwingende Voraussetzung. Diese zwei Aspekte sind maßgeblich für eine erfolgreiche Implementierung von TGE- und KI-Methoden. Keine Änderung des Verfahrens ist von Vorteil, wenn die Test- oder Assemblierungsfolge mit mühsamen manuellen Operationen überlastet ist. Stellen Sie das Verfahrensfließbild richtig, bevor Sie mit der Prozesseinstellung fortfahren!

Aus der Sicht des Prozesses gibt es keine globalen Modifikationen. In gleicher Weise finden "Releases" und Gruppierung von Arbeiten auf separaten Änderungsanfragen statt. Nur der Prozess der Implementierung von Änderungsanfragen kann weiter verfeinert werden. Darüber hinaus sind einige weitere Maßnahmen erforderlich, um Kohärenz und Konsistenz zu erreichen.

Zunächst sollten für jede einzelne Änderungsanfrage die folgenden 7 Stufen umgesetzt werden:
  1. Entwicklung der Anforderungen.
  2. Prüfung der Anforderungen.
  3. Parallele Entwicklung von Code und Testbeispielen entsprechend den Anforderungen.
  4. Hinzufügen von neu entwickeltem Code und entsprechenden Tests zur KI-Assemblierungs-Pipeline.
  5. Testergebnisse erhalten.
  6. Behebung von Code-Fehlern und Anpassung von Tests (falls erforderlich). Wiederholen Sie die Schritte 3-6, bis die erforderliche Abdeckung der Anforderungen und des Codes erreicht ist und die Testbeispiele mit einem erfolgreichen Ergebnis überprüft sind.
  7. Durchführung der Code- und Testauswertung. Wiederholen Sie die Schritte 3-6, sofern bei den Prüfungen Mängel festgestellt werden.

Mit diesem 7-Stufen-Rezept können Sie das tun, was der Titel dieses Beitrags verlangt: von einem schwerfälligen, umständlichen V-Modell des Zyklus zu einer Reihe kurzer und spezifischer V-Modell-Mini-Zyklen wechseln.

Andererseits sollten die in Stufe 5 erzielten Testergebnisse nicht als formale Verifikation gemäß DO-178C betrachtet werden. Sie sollten diese Operationen als Teil eines Entwicklungszyklus betrachten, der auf ein qualitativ hochwertiges Ergebnis abzielt. Nachdem alle für das "Release" vorgesehenen Änderungsanfragen erledigt sind, können Sie das formale Release-Verfahren aufrufen und das Programm im Standardmodus (auch als "Auswertungslauf" bezeichnet) ausführen. Zum Zeitpunkt dieses Launch werden Sie alle erforderlichen Anforderungen an den Code, Code-Elemente und Tests bereits genehmigt und überprüft haben. Dadurch wird die Einhaltung des Standards sichergestellt. Das Anlaufen im Standardmodus wird zu einem einfachen und vorhersehbaren Prozess, da:
  • die Probleme während der Entwicklungsphase behoben werden;
  • die implementierte KI-Methode automatische Softwarebereitstellung sicherstellt.




Es mag so erscheinen, als ob in diesem Fall die Arbeit hinzugefügt oder dupliziert wird. Das ist wohl wahr, aber es gibt eine Rechtfertigung dafür. Schätzen Sie die Kosten für solche "zusätzlichen" Aufgaben ab und vergleichen Sie diese mit den Gesamtkosten einer ungeplanten Säuberungsphase, einer Terminverzögerung oder eines nach der Übergabe festgestellten Mangels. Beachten Sie auch die spürbare Steigerung der Produktqualität und die positiven Auswirkungen auf die Zufriedenheit der Kunden. Es wäre gescheiter, an einem bestimmten Punkt im Lebenszyklus etwas mehr Aufwand zu investieren, aber auf lange Sicht viel mehr zu sparen. In der Praxis erhöht sich die Gesamteffizienz des Projekts bis zu 30%, nachdem ein solch flexibler "agiler" Umschwung vollzogen und verinnerlicht worden ist.