Nachverfolgung bis zum Code: Geht das?

Um die Frage aus dem Titel gleich zu beantworten: Natürlich ist eine Traceability von Anforderung bis zum Code möglich. Doch der Aufwand ist beträchtlich. Wann dies Sinn macht und wie es umgesetzt werden kann, darum geht es in diesem Artikel.

Warum?

Eine Nachverfolgung von den Anforderungen bis zum Code wird fast immer von Vorschriften bezüglich funktionaler Sicherheit getrieben. Auch wenn Traceability viele Vorteile hat, so vergrößert sich der Aufwand und verkleinert sich der Mehrwert, je mehr wir uns der Implementierung nähern.

Fast alle Sicherheitsvorschriften erwarten hier drei Aspekte:

• Traceability zwischen Code und Anforderung. Damit ist gewährleistet, dass jede Anforderung umgesetzt ist.
• Traceability zwischen Softwaretest und Anforderung. Der Softwaretest hat eine implizite Traceability zum Code, die bspw. über Code Coverage explizit gemacht werden kann. Insbesondere sind vom Code abgeleitete Tests mit Vorsicht zu genießen und erfüllen nicht unbedingt die Compliance-Anforderungen. Dazu gehören Unit Tests, die vom Entwickler beim Entwickeln geschrieben werden. Zusätzlich zu diesen muss es von den Anforderungen abgeleitete Softwaretests geben.
• Traceability zwischen Änderung und Code. Sowohl während als auch nach der Entwicklung wird es Änderungen geben. Auch diese müssen verfolgt werden, bis zum Code.

Werkzeuggrenzen

Um von den Anforderungen bis zum Code verfolgen zu können, müssen fast immer Werkzeuggrenzen überwunden werden, also von der Ablage der Anforderungen bis zum Source Code Repository. Wenn es um Projekte geht, die Compliance erfordern, können wir von sauber verwalteten Anforderungen mit eindeutigen IDs ausgehen. Ein einfacher Weg der Traceability ist es dementsprechend, die IDs einfach in den Quellcode einzubetten, zum Beispiel in Kommentaren. Da Programmierer gern automatisieren und Quellcode leicht zu parsen ist, funktioniert dieser Ansatz in der Praxis sogar erstaunlich gut. Auch die Granularität der Traceability kann hier gut gesteuert werden. Die Verantwortlichen können entscheiden, ob auf Datei- (oder Klassen-)ebene verknüpft werden kann, oder auf der ebene einzelner Funktionen/Methoden.

Statt hier selbst zu automatisieren kann hier auch auf kommerzielle Lösungen zurückgegriffen werden, wie LDRA zum Beispiel.

Beim Umgang mit Änderungen können wir uns die Funktionsweise von Repositoires für die Versionierung wie git oder Subversion zu Nutze machen. Dort gibt es die Möglichkeit, Änderungen aus verschiedenen Quellcodedateien als Commit zu verwalten. Daher bietet sich hier eine Traceability zu Commits an, statt zu Dateien oder Funktionen.

Integration erleichtert das Leben

Automatisierung erleichtert das Leben hier ungemein. Daher gibt es viele Lösungen, die dem Team Arbeit abnehmen. Gut ausgebaut sind die Integrationen zwischen Application Lifecycle Management (ALM) und Quellcode. ALM-Werkzeuge wie Jira haben inzwischen eine sehr gute Integration über Erweiterungen sowohl mit Repositories wie git, als auch mit Entwicklungsumgebungen wie IntelliJ. Weiterhin gibt es Infrastrukturlösungen, die über eine paarweise Integration hinausgehen, wie Tasktop. Damit kann bspw eine Integration zwischen Jama (Anforderungen), Jira (ALM) und git (Code) hergestellt werden, wie im folgenden Video zu sehen ist.

In diesem Bereich haben sich auch Plattformen wie gitHub oder gitLab etabliert, die hier ein funktionierendes, integriertes Ökosystem bereitstellen. Allerdings geht es bei diesen Plattformen nur bis zur ALM-Ebene. Anforderungen fehlen, und für Systems Engineering sind sie ebenfalls nur bedingt zu gebrauchen (im Gegensatz zum Software Engineering, wo sie hervorragend funktionieren).

Alles in einer Umgebung

Der Wunsch vieler Team ist es, alles in einer Arbeitsumgebung zu erledigen. Dies wird von MBSE-Plattformen versprochen. Auch wenn Code eigentlich nicht im Scope ist, so könnte auf Code-Generierung gesetzt werden, was insbesondere in der Luftfahrt und in der Zugtechnik auch praktiziert wird. Wenn mit einer zertifizierten Werkzeugkette gearbeitet wird, dann fallen viele Verificationaktivitäten auf Codeebene weg.

Doch der Weg zu einer einzigen Arbeitsumgebung ist steinig. Codegenerierung erfordert ein Umdenken und eine gewisse Investition, die sich erst langfristig auszahlt. Auch „nach oben“ ist eine Arbeitsumgebung problematisch. Der Umgang mit Anforderungen in den meisten Modellierungswerkeugen ist von der Usability her armselig, verglichen mit modernen Anforderungsmanagementwerkeugen. Und eine schlechte Usability führt zu schlechter Zusammenarbeit mit den Stakeholdern.

Fazit

Ja, Traceability von Anforderungen bis zum Code ist möglich und auch wichtig: Tragische Ereignisse wie die vom Therac-25 verursachten Todesfälle haben für die heutigen Vorschriften gesorgt.

Aber Traceability zum Code ist aufwändig und darf kein Selbstzweck sein. Die oben aufgeführten drei Anwendungsfälle sind eine gute Hilfestellung, um den Sinn und Zweck der Code-Traceability nicht aus den Augen zu verlieren.

Für Interessierte, die tiefer einsteigen wollen, empfehle ich den Artikel Software Standards Compliance 101: Tracing code to requirements

Photo by israel palacio on Unsplash