Rückverfolgbarkeit (Anforderungsmanagement)
Rückverfolgbarkeit (auch Nachvollziehbarkeit oder engl. Requirements Traceability) bezeichnet in der System- und Softwareentwicklung die Zuordenbarkeit von Anforderungen zu beliebigen Artefakten über den gesamten Entwicklungsprozess[1] und ist somit Teil des Anforderungsmanagements. Rückverfolgbarkeit ist speziell bei der Entwicklung sicherheitskritischer Systeme relevant, wo Normen und Richtlinien wie ISO 26262, Automotive SPICE, und EN 50128 die Erfassung von Requirements Traceability fordern, um damit nachweisen zu können, dass kritische Anforderungen in angemessener Form umgesetzt und validiert wurden.
Konzepte und Terminologie
[Bearbeiten | Quelltext bearbeiten]Requirements Traceability entsteht, wenn Artefakte eines Entwicklungsprozesses mittels Trace Link verbunden werden. Jeder Trace Link verbindet genau ein Quellartefakt mit einem Zielartefakt. Die Menge aller Trace Links und verknüpfter Artefakte eines Entwicklungsprojektes bilden die Kanten und Knoten eines Graphen, welcher mit Methoden der Graphentheorie analysiert und bewertet werden kann, um die Qualität des Entwicklungsprojektes zu bewerten.[2]
Welche Artefakte in einem Projekt verlinkt werden, wird in einem Traceability Information Model (TIM) definiert. Ein TIM ist ein Metamodell, welches projektspezifisch die zu erfassenden Trace Link-Typen (z. B. Trace zwischen Quellcode und Testfall) und die dabei verknüpften Artefakt-Typen (z. B. Anforderung, Komponente, Testfall) definiert.[3][4] Ein TIM erlaubt es auch bei einer großen Anzahl von Stakeholdern an einem Entwicklungsprojekt, gleichmäßige Traceability-Qualität zu erreichen und diese prüfbar zu machen.[2][4]
Nutzung von Traceability-Informationen
[Bearbeiten | Quelltext bearbeiten]Die Nutzung von erfassten Traceability-Informationen unterstützt zahlreiche Entwicklungsaktivitäten:[5][6]
- Auswirkungsanalyse (engl. Impact Analysis) von Änderungen – ändert sich eine Anforderung, geben deren Trace Links Auskunft darüber, welche anderen Artefakte mit dieser in Beziehung stehen. Diese können leicht geprüft und bei Bedarf modifiziert werden.
- Abdeckungsanalyse (engl. Coverage Analysis) – nicht verlinkte Anforderungen sind ein Indiz dafür, dass die spezifizierte Funktionalität nicht vollständig implementiert wurde. Insbesondere für den Zertifizierungsprozess von sicherheitskritischen Systemen ist nachzuweisen, dass alle (Sicherheits-)Anforderungen vollständig umgesetzt und getestet wurden.
- Projektstatusanalyse – die Vollständigkeit des mittels TIM spezifizierten Traceability-Graphen gibt einen Überblick über den Stand und Fortschritt eines Entwicklungsprojektes. Zum Beispiel Anforderungen ohne Trace Link oder mit verlinktem Quellcode, aber ohne Test befinden sich noch in der Entwicklung.
- Wiederverwendung von Produktkomponenten – Mittels Trace Links können Anforderungen inklusive aller realisierenden Artefakte in Einheiten zusammengefasst und für verschiedene Produkte genutzt werden.
- Persistierung von Zusammenhängen – Wissen über eine Entwicklung ist häufig nur in den Köpfen einzelner Personen verankert. Trace Links speichern dieses Wissen und visualisieren Zusammenhänge zwischen Artefakten. Selbst wenn Stakeholder ein Projekt verlassen, bleibt deren Wissen erhalten.
- Testoptimierung – durch die Verlinkung von Anforderungen, Quellcode, Testfällen und Testergebnissen kann nach Änderungen und bei Fehlern schnell identifiziert werden, welche Tests ausgeführt werden müssen und wo identifizierte Fehler lokalisiert sind.
Einen umfangreicheren Überblick über unterstützte Entwicklungsaktivitäten und deren Relevanz liefert.[7]
Traceability-Herausforderungen
[Bearbeiten | Quelltext bearbeiten]Die konsequente Erfassung von Traceability-Informationen ist mit mehreren Schwierigkeiten verbunden:
- Hohe Erfassungskosten – Heutige Entwicklungsprojekte mit einer Vielzahl von Artefakten bedingen eine Vielzahl von Trace Links und einen enormen Aufwand zu deren Erfassung.[8] Zum Beispiel in Entwicklungsprojekten der Automobilindustrie sind mehrere zehntausend Anforderungen und daraus resultierenden große Mengen an Design-Artefakten, Quellcode, und Testfällen üblich.[9]
- Heterogene Entwicklungswerkzeuge – Verschiedene Entwicklungsartefakte wie Anforderungen, Softwaredesign, Quellcode oder Testprotokolle werden häufig mit individuellen Werkzeugen erstellt und verwaltet. Viele Werkzeuge sind nicht interoperabel und erlauben keine werkzeugübergreifende Traceability. Artefakt-Daten aus heterogenen Werkzeugen müssen daher aufwendig homogenisiert werden.
- Aufwendige Analysen – Artefakte sind häufig nicht direkt, sondern mittelbar über andere Artefakte verlinkt. Für Traceability-Analysen müssen somit vor allem Pfade (engl. Trace Path) und Teilbäume im Trace-Graphen betrachtet werden. Eine Auswertung erfordert daher potentiell aufwendige Algorithmen basierend auf Tiefen- oder Breitensuche.
Aufgrund dieser Herausforderungen sollte der gewünschte Grad von Rückverfolgbarkeit bewusst geplant werden und mittels geeigneter Traceability Software Lösungen unterstützt werden.[8]
Traceability in der Praxis
[Bearbeiten | Quelltext bearbeiten]Umfangreiche Studien dokumentieren die Wirksamkeit, aber auch die Schwierigkeiten der Erfassung von Traceability-Informationen:
- Rückverfolgbarkeit beschleunigt und verbessert Entwicklungstätigkeiten – Eine Studie mit 71 Probanden, welche Quellcode-Änderungen mit und ohne Traceability-Unterstützung durchführten, zeigt deutliche Vorteile der Traceability. Entwickler erledigten Aufgaben mit Traceability-Unterstützung 24 % schneller und 50 % korrekter.[10]
- Vollständigere Rückverfolgbarkeit hilft Programmierfehler vermeiden – Bei der Analyse von Entwicklungsdaten aus 24 mittelgroßen und großen Open-Source-Projekten wurde ein statistisch signifikanter Zusammenhang zwischen der Vollständigkeit der erfassten Traceability-Informationen und der Fehlerrate des entwickelten Quellcodes nachgewiesen. Komponenten mit vollständigerer Traceability wiesen eine geringere Fehlerzahl auf.[11]
- Das Erreichen einer konformen Rückverfolgbarkeit ist schwierig – Eine Analyse der Einreichungen zur Vor-Markt-Prüfung von Software in medizinischen Geräten an die US Food and Drug Administration (FDA) aus dem Jahr 2013 identifizierte im Bereich Traceability signifikante Lücken zwischen Einreichung und Behördenvorgabe.[12] Das aufwendige Erreichen einer normkonformen Rückverfolgbarkeit wird als „Big Freeze“ bezeichnet. Ein Big Freeze vermeidet häufig eine Weiterentwicklung, weil eine erneute Zertifizierung mit enormem Aufwand verbunden ist.[13]
Visualisierung von Traceability Informationen
[Bearbeiten | Quelltext bearbeiten]Ein Ziel von Traceability besteht darin, die Zusammenhänge zwischen einzelnen Artefakten darzustellen. Da die Anzahl und Komplexität der Links steigt, werden Techniken zur Visualisierung der Trace Links benötigt. Dabei sollten relevante Informationen zu den Artefakten (z. B. um welchen Typ handelt es sich, Metadaten zum Lebenszyklus und Attribute) und deren Trace Links (Linktyp, d. h. welche Artefakte sind miteinander verlinkt, Metadaten zum Lebenszyklus oder die Linkstärke) ebenfalls abbildbar sein.[14]
Gängige Visualisierungen sind Traceability Matrizen, Graphen, Listen und Hyperlinks.
- Traceability Matrix – Eine Traceability Matrix ist eine tabellarische Darstellung, bei der die Artefakte eines Typs (z. B. Anforderungen) in Spalten und die Artefakte eines anderen Typs in Zeilen (z. B. Quelltext) abgebildet sind. Zellen visualisieren die Verlinkung (Wert) oder Nicht-Verlinkung (leere Zelle) von zwei Artefakten.[14] Matrizen können leicht einen Überblick über alle Trace Links vermitteln und eignen sich damit vor allem für Management-Aufgaben.[14] Aber bei hohen Artefakt-Zahlen werden auch Matrizen unübersichtlich.
- Traceability Graph – Ein Traceability Graph visualisiert Artefakte als Knoten und Trace Links als Kanten. Graphen eignen sich vor allem für Entwicklungsaufgaben und ermöglichen explorativ einen Überblick über Verlinkungen zu erhalten. Graphen zeichnen sich durch eine hohe Verständlichkeit der abgebildeten Informationen aus.[14] Durch Navigation durch die Graphen kann leicht identifiziert werden, an welchen Stellen Links und Artefakte fehlen.
- Listen – Listen repräsentieren jeden Trace Link als ein Eintrag bestehend aus Quell-Artefakt, Ziel-Artefakt und zugehörigen Attributen. Listen eignen sich vor allem, wenn Aktionen auf mehreren Artefakten gleichzeitig ausgeführt werden sollen und erleichtern Filterungen und Sortierungen. Listen werden jedoch im Vergleich zu den anderen beiden Visualisierungen als weniger geeignet empfunden, um Projektmanagement, Entwicklungs- oder Testaufgaben durchzuführen.[14]
- Hyperlinks – Hyperlinks zwischen Artefakten ermöglichen das einfache und schnelle navigieren zwischen verlinkten Artefakten. Hyper Links erlauben es zwischen Artefakten in ihrer natürlichen Umgebung zu navigieren und dort gleichzeitig Kontextinformationen einzusehen.[14] Hyperlinks haben den Nachteil, dass es schwer ist einen Überblick über alle Verlinkungen eines Projekts zu erlangen.
Visualisierungen lassen sich kombinieren, um den jeweiligen Nachteilen entgegenzuwirken.
Technische Realisierung
[Bearbeiten | Quelltext bearbeiten]Manuell
[Bearbeiten | Quelltext bearbeiten]Traceability wird manuell erreicht, indem Trace Links manuell oder werkzeuggestützt in einer Datenstruktur erfasst werden, z. B. als Spreadsheet in Microsoft Excel. Obwohl weit verbreitet, ist dieses Vorgehen aufwendig, fehleranfällig und führt zu Aussagen in schlechter Qualität.[15]
Werkzeuggestützt
[Bearbeiten | Quelltext bearbeiten]Werkzeuggestützte Traceability setzt voraus, dass Entwicklungsinformationen die über verschiedenen Werkzeuge verteilt sind, homogenisiert und zusammengefasst werden können. Dazu gibt es folgenden Ansätze:
- Homogenisierung der Werkzeuglandschaft mittels ALM Werkzeug – ALM Werkzeugketten decken homogen den gesamten Software- und Systementwicklungsprozess ab und verwalten alle Artefakte in einer Datenbasis. Vorteil dieses Ansatzes ist, dass sich aufgrund der Homogenisierung die Verlinkung von Artefakten leicht verwalten und auswerten lässt. Nachteil hierbei ist, dass eine ALM-Werkzeugkette ganzheitlich eingeführt werden muss und dass sich einzelne Werkzeuge in dieser Kette nur schwer austauschen lassen. Hier droht ein „Big Freeze“ (s. o.) für die Werkzeugkette.
- Homogenisierung der Daten als Quasi-Requirements – Requirements-Management-Werkzeuge bieten umfassende Traceability Funktionalitäten zwischen Anforderungen. Um auch andere Artefakte des Entwicklungsprozesses zu verlinken, bieten Werkzeuge wie IBM Rational DOORS die Möglichkeit externe Artefakte als „Quasi-Anforderung“ zu importierten (z. B. Matlab Modells als sog. Surrogate[16]). Dieses Verfahren wird von vielen am Markt etablierten Werkzeugen unterstützt. Nachteil sind die verschiedenen Adapter und Konverter, welche pro Artefakttyp benötigt werden und welche in Version und Datenformat konsistent sein müssen. Im Gegensatz zu einer ALM-Werkzeugkette muss man die Konsistenz der Adapter und Konvertierer individuell sicherstellen.
- Homogenisierung der Daten mittels dediziertem Traceability-Werkzeug – Der Ansatz dedizierter Traceability-Werkzeuge ist es, relevante Informationen aus den Artefakten eines Entwicklungsprozesses zu extrahieren und in einem einheitlichen Traceability-Modell zusammenzuführen. Die Extraktion aus den Werkzeugen erfolgt dabei über Adapter, welche für beliebige, auch proprietäre, Werkzeuge erstellt werden können. Dedizierte Traceability-Werkzeuge vereinen die Vorteile der beiden vorgenannten Ansätze: die Konsistenz der Adapter und Konverter wird durch den Anbieter des Traceability-Werkzeugs sichergestellt, während die Flexibilität der Werkzeugkette durch anpassbare Schnittstellen im Werkzeug selbst gewährleistet wird. Aufgrund der Flexibilität dieser Werkzeuge müssen bei der Definition des Traceability Information Models nicht nur die Artefakt-Typen und deren Verlinkung definiert werden, sondern es muss auch die technische Anbindung an das entsprechende Werkzeug konfiguriert werden.
Dedizierte Traceability Werkzeuge
[Bearbeiten | Quelltext bearbeiten]Capra
[Bearbeiten | Quelltext bearbeiten]Capra ist ein dediziertes Traceability Management Werkzeug, das die Erzeugung, Verwaltung, Visualisierung und Analyse von Traceability Links zwischen Modellen in verschiedenen DSMLs, Programmiersprachen und anderen Artefakten, wie beispielsweise Tasks und Tests innerhalb von Eclipse ermöglicht. Capra ist aus dem EUREKA/ITEA Forschungsprojekt AMALTHEA4public hervorgegangen. Das Tool steht als Open Source unter EPL zur Verfügung[17].
Reqtify
[Bearbeiten | Quelltext bearbeiten]Reqtify ist eine leicht benutzbare, interaktive Anwendung, um End-to-End Traceability umzusetzen und/oder zu visualisieren. Es unterstützt u. a. Coverage- und Impact-Analyse. Reqtify verfügt über mehr als 100 Schnittstellen zu verschiedensten kommerziellen Werkzeugen oder Standardformate. Reqtify ist ein kommerzielles Lösung der Firma Dassault Systemes.
YAKINDU Traceability
[Bearbeiten | Quelltext bearbeiten]YAKINDU Traceability ermöglicht unkompliziertes und anpassbares Traceability-Management – zum Beispiel, um Standards wie die ISO 26262 zu erfüllen. YAKINDU Traceability ist ein kommerzielles Produkt der Firma itemis und hat wie Capra seinen Ursprung im EUREKA Forschungsprojekt AMALTHEA.[18]
Werkzeugauswahl
[Bearbeiten | Quelltext bearbeiten]Die Entscheidung für eine Traceability Lösung ist nicht trivial, da sich die vermeintlich einfachen und kostengünstigen Lösungen im Verlauf der Entwicklung häufig als unzulänglich und nicht wartbar erweisen.[12] Daher sollte die Entscheidung für ein Werkzeug das Ergebnis einer systematischen Analyse sein.[19]
Literatur
[Bearbeiten | Quelltext bearbeiten]- Cleland-Huang, Gotel, Zisman: Software and Systems Traceability, London, Dordrecht, Heidelberg, New York 2012, ISBN 978-1-4471-2238-8.
- Mary Beth Chrissis: CMMI Top10 Interpretation Issues. (PDF; 2,6 MB) CarnegieMellon Software Engineering Institute, Pittsburgh 2004, S. 8–9.
- Chris Rupp: Requirements-Engineering und Management. 4. Auflage. Hanser, München, Wien 2007, ISBN 978-3-446-40509-7, S. 409–442.
- Karl E. Wiegers, Joy Beatty: Software Requirements, Microsoft Press, Redmond, Washington 3rd Edition 2013, ISBN 978-0-7356-7966-5.
Einzelnachweise
[Bearbeiten | Quelltext bearbeiten]- ↑ Gotel, Finkenstein: An analysis of the requirements traceability problem. In: Proceedings of the 1st IEEE International Conference on Requirements Engineering. Colorado Springs, CO, USA 1994, S. 94 ff.
- ↑ a b P. Rempel, P. Mäder: A quality model for the systematic assessment of requirements traceability. In: 2015 IEEE 23rd International Requirements Engineering Conference (RE). 1. August 2015, S. 176–185, doi:10.1109/RE.2015.7320420.
- ↑ P. Mader, O. Gotel, I. Philippow: Getting back to basics: Promoting the use of a traceability information model in practice. In: 2009 ICSE Workshop on Traceability in Emerging Forms of Software Engineering. 1. Mai 2009, S. 21–25, doi:10.1109/TEFSE.2009.5069578.
- ↑ a b Orlena Gotel, Jane Cleland-Huang, Jane Huffman Hayes, Andrea Zisman, Alexander Egyed: Traceability Fundamentals. In: Software and Systems Traceability. Springer London, 2012, ISBN 978-1-4471-2238-8, S. 3–22, doi:10.1007/978-1-4471-2239-5_1.
- ↑ Karl Wiegers, Joy Beatty: Software Requirements. Hrsg.: Microsoft. Band 3.
- ↑ Karl Wiegers: Requirements Traceability: Links in the Requirements Chain, Part 1. 16. Januar 2013, abgerufen am 13. Dezember 2016 (englisch).
- ↑ Elke Bouillon, Patrick Mäder, Ilka Philippow: A Survey on Usage Scenarios for Requirements Traceability in Practice. In: Requirements Engineering: Foundation for Software Quality (= Lecture Notes in Computer Science). Nr. 7830. Springer Berlin Heidelberg, 2013, ISBN 978-3-642-37421-0, S. 158–173, doi:10.1007/978-3-642-37422-7_12.
- ↑ a b Alexander Egyed, Paul Grünbacher, Matthias Heindl, Stefan Biffl: Value-Based Requirements Traceability: Lessons Learned. In: Design Requirements Engineering: A Ten-Year Perspective (= Lecture Notes in Business Information Processing). Nr. 14. Springer Berlin Heidelberg, 2009, ISBN 978-3-540-92965-9, S. 240–257, doi:10.1007/978-3-540-92966-6_14.
- ↑ Houdek: Managing Large Scale Specification Projects. In: 19th Intl. Working Conference on Requirements Engineering: Foundation for Software Quality. Essen, Germany 2013 (refsq.org [PDF]).
- ↑ Patrick Mäder, Alexander Egyed: Do developers benefit from requirements traceability when evolving and maintaining a software system? In: Empirical Software Engineering. Band 20, Nr. 2, 22. Juni 2014, S. 413–441, doi:10.1007/s10664-014-9314-z.
- ↑ P. Rempel, P. Mäder: Preventing Defects: The Impact of Requirements Traceability Completeness on Software Quality. In: IEEE Transactions on Software Engineering. PP, Nr. 99, 1. Januar 2016, S. 1–1, doi:10.1109/TSE.2016.2622264.
- ↑ a b P. Mäder, P. L. Jones, Y. Zhang, J. Cleland-Huang: Strategic Traceability for Safety-Critical Projects. In: IEEE Software. Band 30, Nr. 3, 1. Mai 2013, S. 58–66, doi:10.1109/MS.2013.60.
- ↑ About Open-DO. In: www.open-do.org. Abgerufen am 12. Dezember 2016.
- ↑ a b c d e f Yang Li, Walid Maalej: Which Traceability Visualization Is Suitable in This Context? A Comparative Study. In: Lecture Notes in Computer Science. 7195. Auflage. Requirements Engineering: Foundation for Software Quality. 2012, S. 194–210.
- ↑ Traceability-Anforderungen kennen und mit ALM effizient umsetzen. In: All-Electronics.de. 25. November 2015 (all-electronics.de [abgerufen am 12. Dezember 2016]).
- ↑ IBM Rational DOORS Traceability – MATLAB & Simulink. In: de.mathworks.com. Archiviert vom (nicht mehr online verfügbar) am 22. Mai 2016; abgerufen am 19. Dezember 2016. Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.
- ↑ Eclipse Foundation: Eclipse Capra. In: projects.eclipse.org. 28. Juli 2016 (eclipse.org [abgerufen am 6. Juli 2017]).
- ↑ YAKINDU Traceability. itemis AG, abgerufen am 4. Februar 2020 (englisch).
- ↑ Orlena Gotel, Patrick Mäder: Acquiring Tool Support for Traceability. In: Software and Systems Traceability. Springer London, 2012, ISBN 978-1-4471-2238-8, S. 43–68, doi:10.1007/978-1-4471-2239-5_3.
