Blog

Ob sich eine kontinuierliche Integration rechtfertigt? Ja, sicher.

Software-Entwicklungsteams aus verschiedenen Branchen erkennen den Wert solcher Vorgehensweise wie kontinuierliche Integration. Einige betrachten sie als ein «Muss» eines wirksamen Lebenszyklus. Doch gerade in sicherheitskritischen Bereichen und vor allem in der Luft- und Raumfahrt gibt es nach wie vor starken Widerstand gegen die Implementierung einer kontinuierlichen Integration. Man glaubt, dass eine kontinuierliche Integration formal nicht mit den Anforderungen des DO-178B/C-Standards kombiniert werden kann. Darüber hinaus wird angezweifelt, ob eine solche Agilität einen praktischen Wert für einen geordneten und detaillierten Entwicklungsprozess hat.

Diese Bedenken sind unbegründet, und ich kann beweisen, dass ein DO-178C-Projekt von einer kontinuierlichen Integration profitieren kann.

Kontinuierliche Integration bezweckt, Testaktivitäten in den Entwicklungszyklus zu integrieren, statt diese auf den Schluss aufzuschieben. Dieses Ziel gliedert sich in folgende Aufgaben:
  • Integration sämtlicher Softwareteile, um zu sehen, wie sie miteinander zusammenpassen;
  • Überprüfung der Software auf eventuelle Regression durch die jüngsten Änderungen;
  • Überprüfung der Funktionalität kürzlich implementierter Änderungen (falls zutreffend).

Dieser Aufgabenzyklus sollte häufig genug durchgeführt werden, so dass alle Fehler korrigiert werden können, bevor zur nächsten Stufe des Lebenszyklus übergegangen wird.

«Ein jedes DO-178C-Projekt kann von einer

kontinuierlichen Integration profitieren»


Zur Umsetzung einer kontinuierlichen Integration müssen die folgenden Voraussetzungen vorliegen:
  • Ein Versionskontrollsystem zum Speichern und Abrufen von Projektartefakten in Verbindung mit einem Assemblierungs-Tool;
  • Automatisierte Tests und ein Testausführungs-Framework;
  • Hilfsmittel zur Analyse von Testergebnissen.

Glücklicherweise bieten die Besonderheiten des DO-178-Standards im Hinblick auf schwerwiegende Entwicklungsmethoden eine solide Grundlage für alle drei Anforderungen.

DO-178 schreibt eine umfassende Konfigurationskontrolle und Änderungsverwaltung vor.
Jede einzelne Änderungsanfrage sowie die hieraus resultierenden Änderungen an den Artefakten müssen nachvollziehbar identifiziert und verfolgt werden. Normalerweise geht es nur darum, ein Konfigurationsmanagement-Tool einzurichten, um den Bauprozess zu automatisieren und zu überwachen, wie jede nachfolgende Änderung in den vorherigen Aufbau eingebaut wird.

Anforderungsbasierte Testung ist eine der Schlüsselideen des DO-178-Standards.
Üblicherweise wird die Entwicklung des Codes und der Testfälle von zwei verschiedenen Gruppen ausgeführt. Wenn die Teststrategie festgelegt ist und die Testwerkzeuge und -umgebung konfiguriert sind, steht dem Testteam nichts im Wege, Testverfahren mit Testbeispielen zu entwickeln. Das bedeutet, dass bei einer Codeänderung alles für eine kontinuierliche Integration und, was noch wichtiger ist, für eine kontinuierliche Prüfung bereitsteht.

Die DO-178 erfordert eine gründliche Rückverfolgbarkeit.
Üblicherweise lässt sich jede einzelne Funktion auf entsprechende Anforderungen zurückverfolgen. Auch Testfälle und -Verfahren werden bis zu den Anforderungen zurückverfolgt. Die Verfolgungsmatrizen werden in einer klar strukturierten Form gespeichert. Alles steht bereit, um den benötigten Satz von Tests auszuwählen und diese nach der Codeänderung auszuführen. Eine Rückverfolgungsmatrix wird ebenfalls die Analyse begünstigen: fehlerhafte Teile können fast sofort identifiziert werden.

«Die Besonderheiten des DO-178-Standards bieten im Hinblick auf schwerwiegende Entwicklungsmethoden eine

solide Grundlage für eine kontinuierliche Integration»


Natürlich funktioniert dieser Ansatz dann gut, wenn die Prüfung automatisiert oder zumindest halb automatisiert ist. Moderne Software-Test-Toolkits von VectorCast, LDRA, Rational und anderen Softwareentwickler bieten eine solide Grundlage für die Testautomatisierung. Modellbasierte Entwicklungsumgebung eröffnet neue Horizonte für die kontinuierliche Integration durch Simulationsverfahren mit Software- (SiL) bzw. Hardware-Rückkopplungsschleife (HiL). Selbst in manuell durchgeführte visuelle Tests einer alten Schule kann eine kontinuierliche Integration eingebaut werden. Es besteht fast immer eine Möglichkeit, die automatische Eingabe einzurichten. Die Bildschirmanzeigen können zur weiteren Analyse aufgezeichnet werden. Somit können alle Tests, mit wenigen Ausnahmen, in die Strategie passen: «Automatisch ausführen, sobald eine Änderung bereit ist, Ergebnisse analysieren, sofern erforderlich».

Die Konformität ist einer der wichtigsten Aspekte bei der Entwicklung von Avionik-Software. Manche glauben, dass jedes Werkzeug für eine kontinuierliche Integration qualifiziert sein sollte. Das stimmt aber nicht. Der DO-178C-Standard besagt: «Werkzeuge, die zur Entnahme, Verkürzung oder Automatisierung von Operationen im Software-Lebenszyklus verwendet werden und deren Ergebnisse nicht verifiziert sind, müssen qualifiziert werden». Es können auch weitere Strategien ausgewählt werden, um die Anforderungen des DO-178-Standards einzuhalten, wie z.B.:
  • Möglichkeit der Qualifizierung von Automatisierung und Auswahlfunktionalität der erfolgreichen/ fehlgeschlagenen Ausführung;
  • Möglichkeit der Auswertung von Ausgangsdaten der Entwicklungswerkzeuge;
  • Möglichkeit der Anwendung einer Kombination aus Qualifizierung und Überprüfung.

«Es besteht keine Notwendigkeit,

jedes Werkzeug für eine kontinuierliche

Integration zu qualifizieren»


Man kann auch einen anderen Weg gehen, nämlich die Aufgaben der kontinuierlichen Integration und der Zertifizierung zu trennen. Zum Schluss kann eine formale Verifikation (auch genannt „Wertungslauf“) einmal durchgeführt werden, ohne dass Automatisierungswerkzeuge verwendet werden. Sollte eine kontinuierliche Integration während des gesamten Projekts angewandt werden, können Sie sicher sein, dass Ihr Code in gutem Zustand ist und Ihre Tests korrekt und vollständig sind. Daher besteht nur ein minimales Risiko plötzlicher und kostspieliger Updates.

Da die kontinuierliche Integration von den Zertifizierungsbehörden nicht vorgeschrieben wird, ist man versucht, zusätzliche Kosten zu vermeiden. Es ist Ihre Entscheidung, aber treffen Sie sie wohlüberlegt. Zeit und Ressourcen, die in der frühen Projektphase für die Implementierung der Testautomatisierung und der kontinuierlichen Integration aufgewendet wurden, werden sich später bezahlt machen. Sie werden mit weniger Fehlern, der Möglichkeit, den Alptraum der verspäteten Integration zu vermeiden, sowie geringeren Änderungskosten in den nachfolgenden Phasen des Projekts belohnt (Beck-Kurve). Oder Sie können die Tests verschieben und am Vorabend des Projektendtermins dafür büßen, indem Sie eine ganze Fehlerkaskade beheben. Jede einzelne Änderung wird unter solchen Bedingungen eine echte Herausforderung sein (Boehm'sche Kurve). Sehen Sie sich diese beiden Kurven an und wählen Sie diejenige, die Sie in Ihrem Projekt am liebsten sehen würden.

Beck-Kurve


Boehm'sche Kurve