Traceability: Alternative zu teuren Werkzeugen?

Eines der wichtigsten Konzepte im Systems Engineering ist die Nachverfolgbarkeit, oder Traceability. Auch in den 60ern wurde diese bereits eingesetzt, obwohl dokumentenbasiert gearbeitet wurde. Das funktionierte, war aber sehr mühselig.

Inzwischen haben wir sehr leistungsfähige Werkzeuge, die uns mit Traceability unterstützen. Doch diese sind teuer. Die Investition ist gerechtfertigt, wenn wir komplexe, sicherheitskritische Systeme entwickeln. Doch auch viele kleine Projekte würden von besserer Traceability profitieren. Welche Alternativen gibt es? Darum geht es in diesem Artikel.

Ihre Meinung interessiert mich. Bitte beantworten Sie die drei kurzen Fragen zu Traceability in der Spalte rechts oder hier.

Vielen Dank!

Der Mehrwert von Traceability

Es gibt viele gute Gründe, die Artefakte des Systems zu verknüpfen (siehe Nachverfolgbarkeit – warum eigentlich?), denn diese gibt uns einen großen Mehrwert. die wichtigsten sind:

• Vollständigkeit – Wir können bspw. nachweisen, das jede Anforderung zumindest in irgendeiner Weise berücksichtigt wurde, oder das jedes Komponente zumindest in irgendeiner Weise getestet wurde.
• Auf Änderungen reagieren – Über Traceability verstehen wir die Auswirkungen von Änderungen und brauchen nur die Teile des Systems zu überarbeiten, die betroffen sind.
• Navigation – Schnell zu relevanten Inhalten springen (Danke Carsten!)

Verknüpfungen können über viele Wege hergestellt werden: Ein Querverweis in Word ist ein Trace, ebenso wie ein Hyperlink auf dieser Webseite. Allerdings können mit dieser Art der Traceability nicht so einfach die zwei eben beschriebenen Mehrwerte realisiert werden.

Was teure Werkzeuge bieten

Moderne Werkzeuge wie DOORS, Jama oder CodeBeamer (Anforderungen) bzw. Cameo, Enterprise Architect oder Rhapsody (Systemmodelle) erlauben nicht nur die Erstellung von Traces, sondern auch die Nutzung, um einen echten Mehrwert zu schaffen. Beispielsweise haben fast alle modernen RE-Werkzeuge die Möglichkeit,

• bei Änderungen Verknüpfungen als suspekt zu markieren, damit diese nachgearbeitet werden können,
• eine Impaktanalyse durchzuführen, die über mehrere Ebenen hinweg die Auswirkung einer möglichen Änderung verfolgt,
• Lücken in der Traceability aufzuzeigen,
• Tabellen zu erstellen, die ein Mapping darstellen (Zuweisung von Funktionen, etc.)
• Das ganze mit Versionierung, Baselines und Branches zu unterstützen, um die Entwicklungszyklen sauber zu verwalten sowie den Compliance-Anforderungen gerecht zu werden.

Diese Features sind nur in „teuren“ Werkzeugen zu finden. Nicht alle Hersteller haben eine öffentliche Preisliste, aber alle bewegen sich in einer „ähnlichen“ (Faktor 3) Größenordnung, um die €1500 pro Nutzer pro Jahr.

Codebeamer gibt es ab €828 pro Nutzer pro Jahr (Preisliste)

Hier muss man unbedingt aufpassen nicht Äpfel und Birnen zu vergleichen: Es gibt doch gewaltige Unterschiede bezüglich Features, es gibt Node-Locked und Floating Nutzer, etc. Der Trend geht zum Abo in der Cloud, doch viele Werkzeuge können auch für einen einmaligen Preis für die Installation auf den eigenen Servern erworben werden. Natürlich kosten dann Updates wieder extra…

Wer nach ISO 26262 und ASPICE Mobilitätslösungen entwickelt, kommt um ein teures Werkzeug wie die eben aufgeführten nicht herum. Doch für einfache Produkte ist Traceability wünschenswert. Dort kann der Preis einer solchen Lösung oft nicht gerechtfertigt werden.

Office – oft der Einstieg in die Traceability

Office ist auch in 2020 noch das am weitesten verbreitetste Werkzeug für die Produktentwicklung. Nicht nur Word und Excel, auch Powerpoint tummeln sich lustig auf einem Sharepoint-Server. Und das ist für kleine Projekte ja auch in Ordnung. Wenn das Lastenheft fünf Seiten nicht übersteigt, dann ist das noch handhabbar. Probleme entstehen, wenn die Komplexität wächst, bzw. wenn Compliance ins Spiel kommt.

Der einzig vernünftige Weg der Traceability in Office ist Excel. Hier kann, vereinfacht, ein Element in der linken Spalte stehen (bspw. Anforderungen) und das verlinkte Element in der Spalte daneben (bspw. Test). Hier gibt es zwei potentielle Probleme:

• Nur 1:1-Beziehungen lassen sich hier vernünftig abbilden (ja, 1:n geht auch, aber ungeschickt und sperrig)
• Keine vernünftige Versionierung.

Wikis & Ticketsysteme

Wikis sind Webseiten, deren Inhalte leicht vom Nutzer verändert werden können und intensiv Hyperlinking zwischen den Inhalten nutzen. Es gibt viele kostenlose Wikisysteme, unter anderem auch das, auf dem die Wikipedia aufgebaut ist. Im kommerziellen Umfeld ist of Confluence von Atlassian zu finden. Auch wenn hier eher aus der Dokumentensicht gearbeitet wird, können trotzdem recht einfach kleinere Einheiten geschaffen werden, was die Traceability vereinfacht. Also bspw. eine Wiki-Seite pro Kapitel, so dass sich das Lastenheft dann aus einem Dutzend Wikiseiten zusammensetzt. Dann kann zumindest jedes Kapitel verlinkt werden, was die Traceability etwas feingranularer macht. Weiterhin ist jede Wikiseite versioniert.

Auch Ticketsysteme sind weit verbreitet. Es gibt kostenlose Systeme wie Bugzilla, als auch viele webbasierte mit kommerziellen Modellen, wie gitHub, oder Jira. Hier kann feingranulare Traceability genutzt werden. Allerdings fehlen den Ticketsystemen viele Eigenschaften, die die professionellen RE-Lösungen haben, zum Beispiel:

• Keine Dokumentenstruktur – Im Gegensatz zu RE-Systemen können die Tickets oft nicht in einer Baumstruktur angeordnet werden, um diese dann als ganzheitliches „Dokument“ wahrzunehmen.
• Keine Baselines – es ist oft nicht möglich, eine Gruppe Tickets zu versionieren, nur einzelne Tickets
• Primitive Traceability-Analyse – Dinge wie Suspects, Gap- oder Impactanalyse sind entweder gar nicht vorhanden, oder lassen sich nur ungeschickt über Filter und ähnliches realisieren.

Es gibt Anbieter, die dieses Problem erkannt haben. Zum Beispiel gibt es Plug-Ins wie R4J, die Jira mit Funktionen für das Anforderungsmanagement erweitern. Dies kann in manchen Situationen auch eine gute Lösung sein. Wir dürfen nur keine Wunder erwarten, denn irgendwann erreicht man Grenzen, die durch das zugrundeliegende Ticketsystem nicht überwunden werden können.

Auf Ticketsysteme aufgesetzte Plug-ins (wie R4J für Jira) können in manchen Fällen ausreichen, doch schnell sind auch hier Grenzen erreicht

Was gibt es noch?

Um es vorweg zu nehmen: Ich bin überrascht, wie wenige nützliche Traceabilitylösungen ich gefunden habe. Wenn es um Traceability im Anforderungsmanagement geht, erscheint mir ReqView erwähnenswert. Dieses Werkzeug ist mit €330/Nutzer/Jahr nicht ganz billig, aber deutlich günstiger als traditionelle RE-Werkzeuge und verspricht einen ähnlichen Funktionsumfang.

Ansonsten gibt es noch viele Exoten, die für die Traceability „verbogen“ werden können, wie Mindmaps zum Beispiel.

Traceability kann auch außerhalb der Werkzeuge, in denen gearbeitet wird, stattfinden. Dazu gibt es verschiedene Lösungen, um werkzeugübergreifende Traceability zu realisieren. Bekannte Kandidaten sind Tasktop oder Zapier.

Auch wenn Traceability aus dem Systems Engineering kommt, so ist diese nicht darauf beschränkt. Überall, wo Informationselemente miteinander verknüpft werden, haben wir es ja mit einer Art der Traceability zu tun. Insofern habe ich mich auch hier umgeschaut, aber wenig „offensichtlich Nützliches“ gefunden. Im Projektmanagement zum Beispiel wird schon seit Jahrzehnten Traceability mit Gantt-Diagrammen praktiziert. Auch wenn es hier Berührungspunkte mit Systems Engineering gibt, hilft uns das nicht mit der traditionellen Traceability.

Fazit

Ja, es gibt alternativen zu teuren Werkzeugen, um Nachverfolgbarkeit zu praktizieren. Aber nicht viele. Mich würde sehr die Meinung meiner Leser interessieren und würde mich über eine Teilnahme der Umfrage in der rechten Spalte freuen.

Bild: Pexels / Pixabay