Wie Traceability von der Last zur Lust wird

Anbieter zum Thema

MicroConsult Academy GmbH

ET System electronic GmbH

MES Electronic Connect GmbH & Co. KG

Method Park Software AG

Die richtigen Konzepte und Werkzeuge für den Erfolg

Um aus der Traceability diesen Mehrwert ziehen zu können sind ein schlüssiges Konzept und Automatisierung durch Werkzeugunterstützung Grundvoraussetzungen. Ein denkbares Konzept beruht auf einem Modell, dessen Gegenstände Elemente (auch Items genannt), Element-Pools, Element-Traces, Pool-Traces, Versionen von Elementen und Pools sowie Baselines und Releases sind.

• Elemente sind die kleinsten verfolgbaren Einheiten, z.B. einzelne Anforderungen oder einzelne Testfallspezifikationen. Sie sind durch einen eindeutigen Identifikator gekennzeichnet, einzeln versionierbar und tragen Workflow-Attribute, die ihren Status als „draft“, „stable“, „active“, „deleted“ etc. beschreiben.
• Pools (oft auch Module genannt) sind Zusammenfassungen von Elementen gleichen Typs, z.B. die Anforderungen zu einem bestimmten Teil eines Projektes. Pools sind ebenfalls durch Links miteinander verbunden. In sogenannten Baselines lassen sich Entwicklungsstände eines Pools versionieren.

Auf dieser Grundlage werden nun strukturelle und logische Regeln für die Konsistenz der Traceability erstellt, wie:

• Ein Element muss genau einem Pool angehören.
• Ein Pool-Link muss sich immer auf eine bestimmte Baseline oder den Head beziehen.
• Traces dürfen nur zwischen Elementen gezogen werden, die zu voneinander abhängigen Pools gehören. Dabei sind nur Traces erlaubt, die zu einem definierten Typ gehören, denn Traces drücken eine bestimmte Relation aus. Natürlich sind verschiedene Arten von Traces zwischen den gleichen Arten von Elementen erlaubt.
• Von einem Element mit Workflow-Status „deleted“ darf keine Trace zu einem Element mit Status „active“ führen.
• Ein Pool darf nicht freigegeben werden, wenn er von einem Pool abhängt, der nicht freigegeben ist.
• Ist ein Pool über verschiedene Pool-Traces von einem anderen Pool abhängig (z.B. hängt die Integrationstest-Spezifikation direkt und indirekt über die Architektur-Spezifikation von den Anforderungen ab, vgl. Abb. 1), dann müssen sich alle Wege auf die gleiche Baseline des referenzierten Pools beziehen. Bei einem ganzen Netz aus Abhängigkeiten ist gerade diese Anforderung nicht immer trivial.

Externer Traceability-Mechanismus schafft Verbindung

Hat man Modell und Regeln definiert, ist die wichtigste Arbeit im Grunde getan, denn man könnte das Modell durch Handarbeit implementieren. Damit die Traceability aber wirklich Spaß macht (und auch damit sie bezahlbar bleibt), muss ein möglichst hoher Automatisierungsgrad erreicht werden. Ein weiteres Ziel ist eine möglichst hohe Durchgängigkeit bei der Erstellung und Pflege der Traces. Diese Ziele, aber auch eine konsistente Integration mehrerer Entwicklungs-Tools, sind in der Regel nur mit Hilfe eines externen Traceability-Werkzeuges zu erreichen. Viele Werkzeuge unterstützen zwar innerhalb ihrer Grenzen die Traceability, scheitern jedoch daran, externe Elemente mit einzubeziehen.

Die beliebte Vorgehensweise, alle Arten von Elementen im Requirement Management Tool zu verwalten, weil es Traceability unterstützt, kann nicht als Lösung gelten. Denn entweder müssen Elemente wie Architektur-Beschreibungen oder Testfall-Spezifikationen mit Werkzeugen bearbeitet werden, die nicht dafür geeignet sind; oder man bearbeitet die Elemente, z.B. UML-Diagramme, in einem adäquaten Modellierungs-Tool und importiert anschließend die graphische Darstellung ins RM-Werkzeug. Das allerdings birgt die große Gefahr, dass bei Änderungen am Diagramm der Import vergessen und dadurch ein inkonsistenter Stand der Arbeit erreicht wird. Man stelle sich diese Vorgehensweise für Quellcode vor!

(ID:296369)