Requirements Traceability in der Softwarewartung: Messbarer Nutzen

Prozessstandards wie Automotive SPICE, ISO 26262, IEC 61508 und DO-178B fordern Traceability-Dokumentation. Damit müssen alle relevanten Verknüpfungen zwischen Anforderungen und anderen Artefakten im Softwareentwicklungsprozess gepflegt werden.

Sind diese Trace-Links erst einmal vorhanden, ermöglichen sie weitaus mehr. Entwickler und Tester können sie zur Navigation zwischen verwandten Artefakten nutzen. QA-Verantwortliche und Projektmanager können auf dieser Basis Auswirkungsanalysen für Change Requests und alle Arten von Coverage-Analysen durchführen — Implementierungen durch Tests abgedeckt, Anforderungen durch Implementierungen abgedeckt und vieles mehr.

Aber lässt sich der Nutzen auch quantifizieren? Wie stark profitiert ein Entwicklungsteam tatsächlich von Requirements Traceability bei der Wartung von Softwaresystemen?

Profitieren Entwicklungsteams von Requirements Traceability?

Prof. Dr. Patrick Mäder et al. haben eine empirische Studie durchgeführt, um diese Frage zu beantworten. In einem kontrollierten Experiment führten 71 Probanden reale Wartungsaufgaben an zwei fremden Entwicklungsprojekten durch — insgesamt 461 Aufgaben.

Die Ergebnisse sind eindrucksvoll: Probanden mit Traceability arbeiteten im Durchschnitt 24 % schneller und lieferten im Durchschnitt 50 % mehr korrekte Lösungen. Traceability spart nicht nur Aufwand — sie verbessert nachweisbar die Qualität der Softwarewartung.

Details zur Studie

Als Untersuchungsobjekte wurden zwei bestehende Open-Source-Systeme gewählt: GanttProject (ein plattformübergreifendes Projektplanungswerkzeug in Java) und iTrust (eine webbasierte Patientenakte in Java). Beide Systeme sind von erheblicher Größe, wie die folgende Tabelle zeigt.

Das Experiment umfasste acht verschiedene Aufgaben — vier je Softwaresystem. Für GanttProject wurden reale Fehlerberichte aus dem Issue-Tracker verwendet. Für iTrust wurden Änderungsanforderungen durch Vergleich älterer und aktueller Versionen von Use-Case-Spezifikationen abgeleitet.

Die Korrektheit der Lösungen wurde auf drei Stufen gemessen: falsch, teilweise korrekt und vollständig korrekt. Lösungen wurden akzeptiert, wenn sie den Fehler behoben oder das gewünschte Ergebnis erzielt haben — auch wenn der Lösungsweg vom Original abwich.

Um das Vorgehen der Probanden zu kontrollieren, wurde ein spezielles Werkzeug mit integrierter Entwicklungs- und Traceability-Unterstützung bereitgestellt. Traces wurden in einem separaten Fenster angezeigt, beschriftet mit den Namen der verknüpften Artefakte. Ein Klick auf einen Trace öffnete die zugehörige Quelldatei und hob die verlinkte Stelle hervor. Traces wurden außerdem im Dateibaum markiert.

Ergebnisse

Probanden ohne Traceability benötigten im Schnitt 889 Sekunden pro Aufgabe. Mit Traceability waren es nur 678 Sekunden — eine Reduktion um 24 %.

Bei der Korrektheit: Ohne Traceability lieferten die Probanden in 50 % der Fälle korrekte Lösungen. Mit Traceability stieg dieser Wert auf 74 % — 50 % mehr korrekte Lösungen.

Die Probanden wurden auch zu ihrer Erfahrung befragt. Viele äußerten sich positiv:

• „Traceability hat mir wirklich geholfen."
• „Mit verfügbaren Traces fand ich den Code ausreichend dokumentiert und habe keine Verbesserungsvorschläge."
• „Traceability hat meinen Fokus auf die relevanten Codeteile gelenkt und mich davor bewahrt, Zeit mit irrelevantem Code zu verschwenden."
• „Traceability hat das Lösen der Aufgaben deutlich einfacher gemacht."

Einige Probanden wünschten sich ausführlichere Trace-Dokumentation:

• „Manchmal haben mich Traces verwirrt. Kommentare dazu wären hilfreich."
• „Übersicht und Informationen zu den verlinkten Methoden wären wünschenswert."

Weitere Verbesserungsvorschläge:

• „Direkter auf den betroffenen Code verlinken, nicht nur auf den Methodenrumpf."
• „Suche im verlinkten Code ermöglichen."
• „Visuelle Übersicht der Dokumente mit markierten Relevant-Bereichen bereitstellen."

Fazit

Traceability führte zu einem Effizienzgewinn von 24 % und 50 % mehr korrekten Lösungen. Bis auf zwei Ausnahmen gaben alle Studienteilnehmer an, sich durch Traceability bei der Aufgabenbearbeitung unterstützt gefühlt zu haben.

Wichtig zu beachten: Diese Studie deckte nur einen Teil der möglichen Traceability-Anwendungsszenarien ab. In einer ergänzenden Untersuchung zu „Usage Scenarios for Requirements Traceability in Practice" von Patrick Mäder et al. wurden 29 verschiedene Anwendungsszenarien in sechs Gruppen identifiziert:

• Requirements Engineering und Management
• Projektmanagement
• Compliance-Nachweis
• Design und Implementierung
• Testen
• Wartung und Weiterentwicklung

Auf die Frage, warum sie Traceability in ihren Projekten einsetzen, nannten die Befragten mit großem Abstand Entwicklungsaktivitäten (80 %) — ein deutliches Signal, dass bessere Werkzeugunterstützung noch größere Potenziale erschließen würde.

Die Daten sprechen eine klare Sprache: Die Qualität der Werkzeugunterstützung hat direkten Einfluss auf den realisierbaren Nutzen. Ein dediziertes Traceability-Tool, das mit dem Projekt wächst, ist kein Luxus — es entscheidet darüber, ob Traceability als Mehraufwand oder als Wettbewerbsvorteil wahrgenommen wird.

Requirements Traceability in der Praxis — Wie durchgängige Traceability in regulierten Projekten wirklich funktioniert, welche Werkzeuge sich bewährt haben und wann der RTM-Ansatz an seine Grenzen stößt: Requirements Traceability bei itemis →