Anforderungsmanagement bei modellgetriebener Entwicklung

Modellgetriebene Entwicklung (Model-Driven Development, MDD) im Embedded-Computing liegt voll im Trend, unter anderem in sicherheitskritischen Branchen wie der Luft- und Raumfahrt oder der Medizintechnik. Modellierungsverfahren sind in der Softwareentwicklung zwar nichts neues, moderne Modellierungswerkzeuge übersetzen das Modell aber unmittelbar in die Implementierung: Sie generieren den Programmcode. Der Programmierer schreibt also keinen Code, er zeichnet Modelle.

Vereinfacht gesagt besteht der MDD-Prozess aus zwei Schritten. Im ersten Schritt erstellt der Entwickler eine grafische Darstellung der Software und ihrer Funktionalität. Im zweiten Schritt analysiert ein Tool dieses Modell und generiert daraus den Quellcode, wobei in vielen Fällen Programmierer noch manuell eingreifen. In der Vergangenheit konnte MDD bei Zuverlässigkeit und Effizienz nicht mit manuell geschriebenem Code konkurrieren. Fortschritte bei den Modellierwerkzeugen haben den Abstand aber schrumpfen lassen oder ganz beseitigt. Verfechter der MDD-Technik betonen das visuelle Wesen dieses Verfahrens, die Vereinfachung komplexer Systeme, das Potenzial zur Wiederverwendung von Komponenten und die allgemeine Flexibilität. Ungeachtet der Popularität des MDD-Verfahrens haben Unternehmen, die diese Technik einsetzen, allerdings häufig mit Schwierigkeiten bei der Sicherheitszertifizierung zu kämpfen.

Die Normen passen nicht mehr

Diese Schwierigkeiten hängen teils mit dem Alter der verbreitetesten Sicherheitsnormen zusammen. Die für industrielle Sicherheit geltende IEC 61058 und die davon abgeleiteten Normen sowie die Norm für den medizinischen Bereich (IEC 62304) erwähnen MDD nicht einmal. Trotzdem setzen viele Entwickler in diesen Branchen auf MDD: diese Anwender sehen sich mit besonderen Herausforderungen bei der Verifikation konfrontiert, speziell wenn es um die Anforderungsverfolgung (Requirements Traceability) geht.

Diese Herausforderungen werfen eine Reihe wichtiger Fragen auf: Vor welchen Problemen stehen Entwickler derzeit, wenn sie modellbasiertes Design nutzen, aber zur Sicherheitszertifizierung weiterhin eine Anforderungsverfolgung brauchen? Welche Hilfestellung leisten moderne Requirements-Traceability-Tools dabei?

Geprüfte Rückverfolgbarkeit

Die Anforderungsverfolgung ist auf verschiedenen Märkten zu einem entscheidenden Bestandteil der Sicherheits-Verifikationsprozesse geworden, etwa im Aerospace-, Rüstungs-, Verkehrs-, Nuklear- und Medizinsektor. Die Bedeutung ist in jenen Branchen besonders, in denen Softwarefehler hohe Risiken mit sich bringen können.

Die Anforderungsverfolgung verknüpft die abstrakteste Beschreibung eines Projekts mit den Implementierungs- und Designebenen. Von dort aus lässt sich das Design auf den implementierten Code und etwaige zugehörige Tests abbilden. Hiermit wird die Idee durchgesetzt, dass jede Anforderung implementiert und prüfbar sein muss. Diese Art von Rückverfolgbarkeit verknüpft Tests mit dem Code, den sie verifizieren und den Anforderungen, die der jeweilige Code implementiert. Ist sie erfolgreich, macht die bidirektionale Anforderungsverfolgung die zahlreichen Beziehungen sichtbar, die zwischen den Anforderungen eines Systems, dem Code, der diese Anforderungen umsetzt, und den Tests, die die Erfüllung der Anforderungen belegen, bestehen.

Die Anforderungsverfolgung gibt Softwareproduzenten die Möglichkeit, gegenüber ihren Kunden den Nachweis zu führen, dass er

• die Anforderungen verstanden hat,
• das Produkt die Anforderungen in vollem Umfang erfüllt und
• das Produkt keine unnötigen Features und Funktionalitäten enthält.

Im Zusammenhang mit sicherheitskritischer Software belegt die Anforderungsverfolgung zudem, dass die Software-Risiken minimiert und alle notwendigen Verifikationsaktivitäten durchgeführt wurden. Wenn man bedenkt, welche katastrophalen Folgen ein Softwarefehler in einem sicherheitskritischen Medizingerät (zum Beispiel einem implantierbaren Defibrillator) haben kann, wird verständlich, weshalb konkrete, verifizierbare Belege für die Umsetzung der Anforderungen unumgänglich sind. Über mehr als zwanzig Jahre hinweg hat sich die Anforderungsverfolgung als eine wichtige Methode erwiesen, diese Belege einzuholen, zu organisieren und zu verknüpfen.

Modelle und Anforderungen als Herausforderung

Die Anforderungsverfolgung war ursprünglich für einen Software-Lebenszyklus traditioneller Art gedacht, in dem entweder Requirements-Database-Tools oder Textdokumente zum Einsatz kommen. Die Einbindung des MDD in einen Traceability-basierten Arbeitsablauf ist dagegen eine relativ neue Aufgabe. Verschärft werden die Komplikationen für sicherheitskritische Anwendungen dadurch, dass die Sicherheits-Zertifizierungsnormen keine Leitlinien bieten.

Bei der Entwicklung der Normen IEC 61508 und IEC 62304 wurden beispielsweise nur wenig Orientierungshilfen für die Verwendung von MDD-Techniken geboten. Zwischenzeitlich lernte man jedoch viel darüber, wie man MDD mit der Anforderungsverfolgung integrieren sollte. Die jüngsten Aktualisierungen berücksichtigen diese Erfahrungen und bieten Hilfestellung, wie sich einige der durch unkorrekte Integration entstehende potenzielle Gefahren vermeiden lassen.

Das Modell an die Anforderungen anpassen

Für die Avionik-Branche klärt die Norm DO-178C, wie Designmodelle zur Anforderungsverfolgung passen. Da Modelle eine abstrakte Übersicht über ein Projekt darstellen können, wurden sie von einigen Unternehmen wie übergeordnete Anforderungen behandelt. Andere Unternehmen dagegen betrachteten Modelle als Quellcode, da sie sich zum Generieren der eigentlichen Implementierung verwenden lassen.

Die Vorgehensweise, die für die DO-178C zugelassen wurde und aus dem Blickwinkel der Anforderungsverfolgung am sinnvollsten ist, behandelt Designmodelle als untergeordnete Anforderungen. Modelle werden als Designdokumente angesehen, die Auskunft darüber geben, was die Implementierung leisten soll.

Es ist wichtig, Designmodelle auf diese Weise zu behandeln, damit eine exaktere Verifikation möglich ist. Ohne das Erstellen einer abstrakten Definition des Systems lässt sich schwierig sicherstellen, dass das Modell wie gewünscht funktioniert. Wichtig ist es auch, das Modell nicht wie die fertige Implementierung zu behandeln: Hierbei würden Defekte ignoriert, die sich durch den Codegenerierungs-Prozess, durch externe, zum generierten Code hinzugefügte Codeelemente (manuellen Code) und durch die Verifikation der Zielumgebung einschleichen können.

Bild 1: Wer alle Anforderungen mit nur einem opaken Modell verknüpft, verhindert dass sich die Sicherheitskonzepte in den Anforderungen und den einzelnen Designelementen und Prozeduren zuordnen und verfolgen lassen.LDRA

Untergeordnete Anforderungen

Die Behandlung von Modellen als untergeordnete Anforderungen wirkt sich entscheidend auf die Anforderungsverfolgung aus. Um die vollständige Rückverfolgbarkeit der Anforderungen zu gewährleisten, müssen sämtliche übergeordneten Anforderungen durch untergeordnete Anforderungen implementiert sein. Die Voraussetzung für eine bidirektionale Anforderungsverfolgung ist, dass sich umgekehrt auch alle untergeordneten Anforderungen auf die entsprechenden übergeordneten Anforderungen abbilden lassen.

Damit die Anforderungsverfolgung aussagefähig ist, sind Verknüpfungen nötig zwischen den tatsächlichen Modellelementen und den Anforderungen, aus denen sie entstanden sind. Es ist verlockend, alle übergeordneten Anforderungen mit einem einzelnen opaken Modell zu verknüpfen, also einem Top-Level-Modell, das keine für die Anforderungsverfolgung sichtbaren Elemente enthält (Bild 1). Dies aber würde den Zweck der Anforderungsverfolgung ignorieren. Nur der Teil des Modells, der eine bestimmte Anforderung repräsentiert, kann Belege dafür liefern, dass die betreffende Anforderung im Design umgesetzt wurde. Wurde eine Anforderung nicht implementiert, kommt es darauf an, dass das genaue Modellelement bei einem Fehler isoliert werden kann.

Bild 2: Requirements-Traceability-Tools binden Anforderungen aus einem Designmodell in den allgemeinen Traceability-Prozess ein. Damit lassen sich viele Sicherheits-Normen leichter umsetzen.LDRA

Es kann eine echte Herausforderung sein, zwischen dem Modell und den übergeordneten Anforderungen für Rückverfolgbarkeit zu sorgen, zumal beide meist auf sehr unterschiedliche Weise gespeichert und dargestellt werden. Die übergeordneten Anforderungen existieren vorwiegend in Textform, während die meisten Modellierungs-Tools grafische Oberflächen für das Design zur Verfügung stellen. Moderne Anforderungsverfolgungs-Tools können diese Lücke schließen, indem sie die übergeordneten Anforderungen und die Modellelemente aus ihren jeweiligen Beständen entnehmen (Bild 2). Diese Komponenten lassen sich dann verknüpfen und gemeinsam mit anderen Traceability-Verknüpfungen verwalten, zum Beispiel Verbindungen zwischen Anforderungen und Funktionstests.

Parallele Traces

Die zentrale Innovation des MDD ist die Abgrenzung zwischen Entwicklungs- und Codierungsprozess, die allerdings Probleme mit der Anforderungsverfolgung verursachen kann. Sind der Entwicklungs- und Codierungsprozess unabhängig voneinander, kann sich die Rückverfolgbarkeit für beide als kompliziert und fehleranfällig erweisen. Die Anforderungsverfolgung ist als eine kontinuierliche Maßnahme gedacht, die sich über den gesamten Softwareentwicklungs-Lebenszyklus erstreckt. Sind Implementierung und Design nicht miteinander verknüpft, müssen die beim Design im Interesse der Anforderungsverfolgung vorgenommenen Verknüpfungen während der Implementierung wiederholt werden.

Optimale Modellierungs-Tools entschärfen diese Gefahr etwas. Viele dieser Tools können Verbindungen zwischen den Modellelementen und dem zu ihnen gehörenden Code automatisch herstellen. Viele Anwender kombinieren die Modellierungs-Tools jedoch mit individuellen Build-Prozessen, zusätzlichem handgeschriebenem Code und Custom-Code-Generatoren, so dass die Verbindungen zwischen Code und Modell in der Realität weniger deutlich sichtbar sind als theoretisch möglich.

Auch die Tests verfolgen

Auch wenn die Rückverfolgbarkeit zwischen Code und Modell gegeben ist, können die Verbindungen zwischen den im Modell erfolgenden Tests und dem Test-Quellcode in der Zielumgebung fehlen. Nach dem MDD-Paradigma ist es wichtig sicherzustellen, dass sich das Modell gemäß den übergeordneten Anforderungen verhält und dass es Tests gibt, die dieses Modellverhalten belegen.

Um diesen Grad an Verifikation zu erreichen, enthalten die Modellierungs-Tools Mechanismen, um das Modell innerhalb der Modellierungs-Umgebung zu prüfen. Diese Tests mögen zum Verifizieren des Designs nützlich sein, sie stellen aber keine echte, ausführbare Objektcode-Verifikation dar. Die Unterscheidung zwischen Tests auf der Quellcode-Ebene und solchen auf der Modell-Ebene bedeutet, dass Traceability-Verbindungen zwischen den Anforderungen und den Modelltests nicht automatisch für die Rückverfolgbarkeit zwischen den Quellcode-Tests und den Anforderungen relevant sind. Auch hier löst man dieses Problems üblicherweise dadurch, dass man parallele Traceability-Ketten für Quellcode-Tests und modellbasierte Tests einrichtet. Dies aber hat redundante Tests zur Folge und bringt die zusätzliche Komplexität mit sich, die sich durch das manuelle Integrieren der Testergebnisse ergibt.

Spuren vereinen

Es ist allerdings möglich, die fehlende Verbindung zwischen dem modellbasierten Design und der Quellcode-Verifikation zu entschärfen. Anforderungsverfolgungs-Tools lassen sich nutzen, um Anforderungen und Traceability-Nachweise aus mehreren Quellen zu ziehen. Durch das Zusammenstellen von untergeordneten, als Modellelemente dargestellten Anforderungen und übergeordneten Anforderungen aus externen Dokumenten oder Datenbanken erreicht man, dass die Traceability-Verknüpfungen direkt an die Designelemente gehen können, die wiederum mit dem Quellcode verknüpft sind.

Bild 3: Die direkte Verknüpfung mit Modellelementen vermeidet das Entstehen doppelter Verknüpfungen und vereinfacht den Traceability-Prozess.LDRA

Ebenso ist es möglich, die Ergebnisse von Quellcode-Tests und modellbasierten Tests gemeinsam zu präsentieren. Anforderungsverfolgungs-Tools können Traceability-Nachweise als durchgehenden Ablauf organisieren, der Anforderungen, untergeordnete Anforderungen, Design, Quellcode und Tests zusammenfasst. Dies reduziert die zusätzliche Komplexität, die sich durch das Pflegen und Integrieren zweier separater Traceability-Maßnahmen einstellt (Bild 3).

Test-Cases wiederverwenden

Die Vielzahl separater Testanforderungen lässt sich außerdem durch das Wiederverwenden von Testfällen verringern. Hierzu werden die beim modellbasierten Testen verwendeten Ein- und Ausgangsinformationen isoliert und in einem Format exportiert, das auch die Quellcode-Testwerkzeuge verstehen.

Mit einigen Verifikations- und Modellierungs-Werkzeugen lässt sich dieser Prozess sogar automatisieren. Von Seiten der Rückverfolgbarkeit kommt es darauf an, dass die Traceability-Nachweise wiederverwendbar sind. Hat sich bereits erwiesen, dass sich bestimmte Testfall-Parameter auf eine Anforderung abbilden lassen, kann man diese Parameter auf der Quellcode-Ebene wiederverwenden. Die gleichen Begründungen und Artefakte, die zur Verknüpfung zwischen Anforderung und Modelltest dienten, lassen sich auch für die Verknüpfung zwischen Anforderungen und Quellcode-Test verwenden.

Herausforderungen meistern

Trotz seiner Popularität stellt das MDD sicherheitskritische Anwendungen vor eine Reihe neuer Herausforderungen. Besondere Bedeutung hat dabei der Abgleich zwischen der Anforderungsverfolgung und dem modellgetriebenen Entwicklungskonzept. MDD lässt viele traditionelle Grenzen zwischen Design, Anforderungen und Implementierung verschwimmen, so dass man das Modell im Traceability-Prozess leicht falsch platziert. Das modellbasierte Design nimmt den Designprozess außerdem aus dem Testprozess auf der Quellcode-Ebene heraus, was die Gefahr doppelter oder fehlerhafter Anforderungsverfolgungs-Maßnahmen birgt. Hinter diesen neuen Herausforderungen steht die Frage, wie sich eine neue Softwareentwicklungs-Methode überhaupt in die kritischen Softwareentwicklungs-Praktiken integrieren lässt. Auch hier besteht die Antwort darin, auf Innovation und erprobte Verfahrensweisen zu setzen.

Die Erfahrungen und die Praxis beim Einsatz der modellbasierten Entwicklung und Verifikation im Avionik-Bereich (zusammengefasst als Ergänzung zur Norm DO-178C / ED-12C) bildet eine gute Grundlage für die Entwicklung von Normen in anderen Fachdisziplinen. Die Bereiche Medizin- und Industriesicherheit können auf dieser Basis erprobte Verfahrensweisen für die Einbindung von Modellen in die Lifecycle-Anforderungsverfolgung erarbeiten. Moderne Anforderungsverfolgungs- und Test-Werkzeuge bringen aktive Innovationen mit, die dies vereinfachen und automatisieren.

Der Anforderungsverfolgungs-Komplex kann überaus anstrengend sein, besonders wenn er mit einem unklaren Verständnis des Traceability-Prozesses erfolgt. Richtig umgesetzt, lässt sich die Anforderungsverfolgung jedoch für die Verifikation auf sämtlichen Ebenen des Softwareentwicklungs-Lebenszyklus nutzen. Dabei dürfen die Vorteile des modellbasierten Designs keinesfalls auf Kosten der Sicherheit gehen. Mit den richtigen Tools sind hier keine Kompromisse nötig.

(lei)