Projektmanagement Durch Traceability lassen sich unbändige Projekte zähmen

Der Einsatz von Traceability kann in einem Projekt für mehr Transparenz zwischen den Entwicklungsschritten sorgen. Die Verknüpfung von Anforderungen mit Entwicklung und Test hält diese stets präsent.

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Axivion GmbH

Parasoft® Deutschland GmbH

itemis AG

Steine, die durch Abschläge einige scharfe Kanten enthielten, sind die ersten belegten Werkzeuge der Menschen aus der Steinzeit um Probleme zu lösen. Dies ist nun 2,6 Millionen Jahre her und die Werkzeuge haben eine ebenso massive kulturelle Evolution erfahren wie wir Menschen. Für einige Probleme müssen passende, einfach verwendbare Werkzeuge noch entwickelt werden. Eine dieser Herausforderungen ist das Planen von Software. Ziele und Anforderungen sind meistens die Einstiegspunkte eines Entwicklungsprojektes. Sie bleiben leider häufig während und nach der Entwicklungsphase auf der Strecke. Am zu oft miserablen Projektende wird dann gerne über fehlende, unvollständige oder inkonsistente Anforderungen geschimpft¹. Doch es gibt Methoden, um Anforderungen tiefer in den Entwicklungsprozess hineinzuziehen. Eine heißt Traceability.

In der Automotive-Entwicklung gibt es für einige Komponenten 3.500 Seiten starke Anforderungsdokumentationen². Schon die Masse dieser Anforderungen lässt es nicht zu, als Mensch den Überblick zu behalten, geschweige denn bei einem Änderungs- bzw. Erweiterungswunsch ohne Hilfsmittel abzuschätzen, welche Auswirkungen eine Änderung auf das übrige System hat. Der Mensch denkt linear und ist in der Lage, bewusst vier bis fünf Eigenschaften miteinander zu vergleichen. Mit jeder neuen Eigenschaft nimmt die Variantenvielfalt exponentiell zu. Der Mensch ist aber nicht in der Lage, exponentielles Wachstum zu erfassen³. Er benötigt Unterstützung durch Methoden und Werkzeuge.

Häufig sind die Lösungen für derartig schwergewichtige Herausforderungen ebenso schwergewichtig. So bringen viele Methoden und Werkzeuge erst einmal keine Erleichterung, sondern schaffen neue Hürden. Dabei helfen bei großen Problemen auch schlichte Lösungen, etwa die Verknüpfung von Anforderungen mit Entwicklungsergebnissen und Tests. So bleiben sie während des gesamten Prozesses präsent und werden laufend aktualisiert. Dadurch ist auch ersichtlich, welche Anforderungen erfüllt worden sind. Diese Verknüpfung erreichen wir mittels Traceability.

Verschiedene Möglichkeiten der Verknüpfung

Der Begriff Traceability bezeichnet in der Produktionswirtschaft die Rückverfolgbarkeit von Produkten: Für jedes Produkt kann nachvollzogen werden, wo es gefertigt, gelagert und transportiert wurde. Der Begriff des Tracing existiert auch innerhalb von Programmen. Er bezeichnet die Funktion zur Fehlersuche in Programmen. Hierbei wird bei jedem Aufruf und Verlassen einer Funktion eine Meldung ausgegeben, so dass der Entwickler nachverfolgen kann, welchen Verlauf das Programm nimmt.

Übertragen auf Softwareentwicklungsprozesse bezeichnet der Begriff die Nachverfolgbarkeit von Anforderungen in den Entwicklungsprozess hinein. Mit Hilfe sogenannter Traces können alle Mitglieder eines Teams Spuren zwischen Anforderungen und aller Art von Entwicklungsartefakten legen: zwischen Anforderungen und Quellcode, Anforderung und Dokumentation, Anforderung und Test u.v.m. Das zieht die Anforderungen in den gesamten Entwicklungsprozess. Richtlinien für die Entwicklung sicherheitskritischer Softwaresysteme in der Luftfahrt fordern umfassende Traceability⁴. Diese soll in allen Projektphasen verfügbar sein und so einen verständlichen und effizienten Validierungsprozess ermöglichen.

Theoretisch gibt es diverse Möglichkeiten, um Verknüpfungen, die Traces, zwischen Entwicklungsartefakten zu erstellen. Die unterschiedlichen Formen sind in der Tabelle links gegenübergestellt: Während explizite inhärente Traces stets in die Artefakte mit eingebracht werden müssen, liegen sie bei der expliziten kohärenten Form neben den Artefakten als separates Tracing-Modell. Die implizit inhärente Form setzt voraus, dass es außerhalb des Modells Regeln gibt, etwa Namenskonventionen, die beschreiben, wie die Artefakte verknüpft werden. Der Erfolg dieser Variante hängt davon ab, dass jeder Mitarbeiter, der im Entwicklungsprozess arbeitet, diese Regeln kennt. Die letzte Variante bezeichnet das nachträgliche Finden impliziter Zusammenhänge und geht in Richtung Data-Mining. Die Analyse allein wird selten ein vollständiges Tracing-Modell ergeben sowie mit manuellen Ausnahmeregeln vervollständigt werden müssen und eignet sich eher für eine nachträgliche Analyse.

Favorisierte Form des Tracings ist das explizite und kohärente Tracing, bei dem die gesamten Trace-Informationen in einem separaten Modell liegen. Dieses Modell wird während des gesamten Entwicklungsprozesses gepflegt, erweitert und instandgehalten. Auf diese Weise liefert es stets aktuelle Informationen zum Status der Entwicklung. Es ist eine wichtige Grundlage für die Coverage- und Impact-Analyse und wird von Prozessstandards wie SPICE, CMMI oder ISO 26262 gefordert.

Begleitet Traceability ein Projekt von Anfang an, so kann man auch die Auswahl der Entwicklungs- und Requirements-Engineering-Software darauf abstimmen. Soll Traceability jedoch während des Projektes eingeführt werden, bieten sich entweder Plug-Ins bestehender Werkzeuge oder gänzlich unabhängige Werkzeuge an. YAKINDU Traceability (www.yakindu.com/traceability) ist ein unabhängiges Werkzeug, das sich flexibel in bestehende Werkzeugketten integrieren lässt (siehe Kasten).

Egal welche Werkzeuge zum Einsatz kommen: Auch beim Einsatz von Traceability ist Vorsicht geboten, damit sie wirklich hilft und nicht noch mehr Arbeit und Kosten verursacht. Wenn das Tracing zu kleinteilig gestaltet wird, kann es selbst zu einem nicht mehr wartbaren Gebilde werden.

Als Best-Practice-Vorschlag könnte sich das Tracing auf die notwendigen Traces beschränken, wie sie beispielsweise im Automotive Bereich in SPICE definiert wurden (siehe Schaubild 1). Daneben sollten vor der Einführung folgende Fragen geklärt und allen Projektbeteiligten mitgeteilt werden:⁵

• Welche Elemente sollen durch Tracing verknüpft werden?

• Wer ist für das Verknüpfen und die Pflege der Traces verantwortlich?

• Wann und wie werden die Traces instandgehalten?

• Welche Trace-Typen benötigen wir?

• Wie stellen wir die Qualität der Trace-Informationen sicher?

• Was verstehen wir unter Qualität in diesem Zusammenhang?

• Was wollen wir durch Traceability erreichen?

Der letzte Punkt ist entscheidend für die Akzeptanz bei den Projektbeteiligten. Ein Beispiel: Wir erhoffen uns durch den Einsatz von Traceability folgende Berichte zeitnah erzeugen zu können:

• Coverage-Analyse auf Basis von Storys auf der einen und Softwaremodulen auf der anderen Seite,

• Impact-Analyse von Change-Requests an unsere bestehende Software,

• Jeder Mitarbeiter sollte zur Pflege und initialen Eingabe eines Traces maximal 20 Minuten (zwei Prozent der Zeit für die Aufgabe) benötigen.

Tracing-Tools sollten Validierungen unterstützen

In diesem Fall steht die Verknüpfung zwischen Anforderungen in Form von Storys und Entwicklungsartefakten im Fokus. Daraus ergeben sich die Kriterien für eine hohe Qualität von Traces: Alle entwickelten Softwaremodule sind über Traces mit Stories verbunden – es gibt kein Modul, das nicht mit einer Story verbunden ist.

Diese Anforderung an das Tracing formuliert im zweiten Teil bereits eine Validierungsregel. Tracing-Werkzeuge, die derartige Validierungen direkt unterstützen, helfen allen Projektbeteiligten. Denn schlagen die Validierungen fehl, gibt das Werkzeug ihnen unmittelbare Meldung. Somit stärkt das Tool die Konsistenz des Tracing-Modells.

Der Einsatz von Traceability kann in einem komplexen Projekt für mehr Transparenz zwischen den Entwicklungsschritten sorgen. Die Verknüpfung von Anforderungen mit Entwicklung und Test hält diese stets präsent. Der Einsatz sollte solide geplant und mit allen Projektbeteiligten kommuniziert werden, damit Traceability ihren Nutzen entfalten kann.

Ergänzendes zum Thema

YAKINDU Traceability

YAKINDU Traceability ist ein unabhängiges Eclipse-basiertes Traceability-Werkzeug. Es lässt sich flexibel in bestehende Werkzeugketten integrieren, egal welche Entwicklungswerkzeuge in dem jeweiligen Projekt bereits im Einsatz sind. Idealerweise kann es als Add-On in eine bestehende Eclipse-Entwicklungsumgebung nachinstalliert werden.

Die Verwendung einer anderen Entwicklungsumgebung schließt dieses Tracing-Werkzeug aber nicht aus. In diesem Fall kommt das Werkzeug als zusätzliches Tool zum Einsatz. Es lässt sich mit vielen bestehenden Entwicklungswerkzeugen integrieren.

Das zentrale Element des Traceability-Tools sind die Traces. Ein Trace verbindet zwei Artefakte miteinander und besteht aus zwei Tracepoints von bestimmten Tracepoint-Typen. In YAKINDU Traceability werden diese Tracepoint-Typen durch die Anwender konfiguriert. Er kann neben der anzuzeigenden Farbe eine Kategorie, zusätzliche Attribute und den sogenannten Tracepoint-Provider konfigurieren. Ein Tracepoint-Provider stellt die Verbindung zwischen dem Tracing und einem beliebigen Artefakt-Typ her. So gibt es bereits Tracepoint-Provider für Datei- und Ordnerelemente auf Dateisystemebene, die Eclipse-UML-Implementierung oder das Requirements Interchange Format (ReqIF).

Aufgrund der offenen Architektur des Werkzeugs können Tracepoint-Provider für (noch) unbekannte Artefakte nachträglich entwickelt und integriert werden. Auf die Konfiguration der Tracepoint-Typen und der Traces folgt die Erstellung der Traces während des Entwicklungsprozesses.

Dafür beschränkt sich das Tool auf wenige aussagekräftige Editoren und Views. Defekte Traces, die zum Beispiel entstehen, wenn ein Entwicklungsartefakt auf den sich ein Trace bezieht, gelöscht oder verschoben wird, werden direkt erkannt und dem Benutzer mitgeteilt. So gewährleistet das Werkzeug ein technisch konsistentes Modell. Die semantische Konsistenz sollten jedoch noch die Stakeholder selbst prüfen und sicherstellen. Unterstützung hierfür bieten die Traceability-Berichte mit ihren grafischen Darstellungen.

Literaturhinweise:

[1] Vgl. PM Solutions, Research Report: Strategies for Project Recovery, 2011

[2] Vgl. Matthias Weber, Joachim Weisbrod: Requirements Engineering in Automotive Development: Experiences and Challenges, ECOOP 2000, Cannes, Frankreich

[3] Vgl. Hanser: Rolf Dobelli, Die Kunst des klaren Denkens

[4] Vgl. Normen: DO-178, DO-254 (Software Considerations in Airborne Systems and Equipment Certification)

[5] Vgl. INCOSE: M. Brörkens, Ö. Gürsoy: Managing and understanding complex systems using traceability and open source software

* Svenja Wendler ist IT-Beraterin bei der itemis AG in Lünen. Sie befasst sich mit modellbasierter Softwareentwicklung, Validierungsmöglichkeiten und Data-Mining.

(ID:42473939)