„Rückverfolgbarkeit (Anforderungsmanagement)“ – Versionsunterschied
| [ungesichtete Version] | [ungesichtete Version] |
K Typos raus |
K link ergänzt |
||
| Zeile 56: | Zeile 56: | ||
==== YAKINDU Traceability ==== |
==== YAKINDU Traceability ==== |
||
<blockquote>"YAKINDU Traceability ermöglicht unkompliziertes und anpassbares Traceability-Management – zum Beispiel um Standards wie die ISO 26262 zu erfüllen."</blockquote>YAKINDU Traceability ist ein kommerzielles Produkt der Firma itemis und hat wie Capra seinen Ursprung im [[EUREKA]] Forschungsprojekt [https://itea3.org/project/amalthea.html AMALTHEA] . |
<blockquote>"[https://www.itemis.com/en/yakindu/traceability/ YAKINDU Traceability] ermöglicht unkompliziertes und anpassbares Traceability-Management – zum Beispiel um Standards wie die ISO 26262 zu erfüllen."</blockquote>YAKINDU Traceability ist ein kommerzielles Produkt der Firma itemis und hat wie Capra seinen Ursprung im [[EUREKA]] Forschungsprojekt [https://itea3.org/project/amalthea.html AMALTHEA] . |
||
== Literatur == |
== Literatur == |
||
Version vom 12. Dezember 2016, 15:44 Uhr
Rückverfolgbarkeit (auch Nachvollziehbarkeit oder englisch Traceability) bezeichnet in der System- und Softwareentwicklung die Zuordenbarkeit von Anforderungen über zu belibiegem Artefakten des gesamten Entwicklungsprozesses[1] und ist somit Teil des Anforderungsmanagements. So soll z.B. für einen Testfall nachvollziehbar sein, aufgrund welcher Anforderung(en) er entstanden ist. Umgekehrt soll verfolgbar sein, welche Testfälle die korrekte Umsetzung einer Anforderung sicherstellen.
Mit Hilfe der Rückverfolgbarkeit von Anforderungen wird die Erstellung qualitativer Aussagen über den Entwicklungsfortschritt und –Prozess ermöglicht. Dies ist speziell bei der Entwicklung sicherheitskritischer Systeme relevant, wo Normen wie etwa die ISO 26262 oder Automotive SPICE die Einführung von Requirements Traceability fordern, um damit nachweisen zu können, dass kritische Anforderungen in angemessen hoher Qualität umgesetzt sind. Weiter wird mit Requirements Traceability die Analyse der Auswirkung von Änderungen erleichtert.
Konzepte und Terminologie
Requirements Traceability wird erreicht, indem die Artefakte des Entwicklungsprozesses mittels sogenannter Trace Links verbunden werden können. Ein Trace Link verbindet dabei ein Quellartefakt mit einem Zielartefakt. Die Verbindungen haben also eine primäre, semantische Richtung, sollen aber zur besseren Auswertbarkeit bidirektional navigierbar sein. Auf diese Weise entsteht ein Graph bestehend aus Artefakten als Knoten und Trace Links als Kanten, der sich mit bekannten Mitteln der Graphentheorie analysieren lässt. Welche Artefakte dabei mit welchen anderen Artefakten verlinkt werden sollen bzw. dürfen, ist im sog. Traceability Information odel (TIM) auf Typ-Ebene festgelegt. Das TIM selbst ist ebenfalls ein Graph, dessen Knoten die Artefakttypen wie z.B. „Lastenheft-Anforderung“ oder „Test-Protokoll“ bilden. Die Kanten definieren die erlaubten Verlinkungen dieser Typen. Das TIM kann man somit als Metamodell für den Trace-Graphen interpretieren.[2]
Herausforderung
Die Herausforderungen bei der Requirements Traceability sind mannigfaltig:
- Die verschiedenen Entwicklungsartefakte wie Anforderungen, Softwaredesign, Quellcode oder Testprotokolle werden mit spezialisierten Werkzeugen erstellt und verwaltet, die nicht immer interoperabel sind. Für die werkzeugübergreifende Traceability müssen die Daten aus heterogenen Werkzeugen daher mitunter aufwändig homogenisiert werden.
- Viele Artefakte sind nicht direkt, sondern mittelbar verlinkt. Für die Auswertung sind somit vor allem Pfade (sog. Traces) und Teilbäume im Trace-Graphen relevant. Eine Auswertung erfordert daher potentiell aufwendige Algorithmen basierend auf Tiefen- oder Breitensuche.
- Die Menge der Entwicklungsartefakte ist hoch. In Projekten zur Entwicklung von Automotive-System allein sind mehrere zehntausend Anforderungen relevant, dazu kommen dann entsprechenden Mengen an Design-Artefakten, Source-Code, Testfälle und –Protokolle.[3]
Aufgrund dieser Herausforderungen ist das Erreichen einer vollständigen Rückverfolgbarkeit von Anforderungen aufwändig.
Auswirkungen in der Praxis sind
- Oftmals wird eine normkonforme Rückverfolgbarkeit gar nicht erst erreicht. So weist etwa 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 grade im Bereich Traceability signifikante Lücken zwischen Einreichung und Behördenvorgabe nach.[4]
- Das Erreichen einer normkonformen Rückverfolgbarkeit führt zum „Big Freeze“: Jede Weiterentwicklung wird vermieden, weil eine erneute Zertifizierung der Normkonformität wesentlich aufwendiger wäre als die Weiterentwicklung selbst.[5]
Umsetzung
Manuell oder halbautomatisch
Vielfach wird die Traceability manuell oder halbautomatisiert erreicht, indem Trace-Daten werkzeuggestützt und/oder manuell z.B. in MS Excel ausgewertet werden. Aufgrund der o.g. Herausforderungen ist dieses Vorgehen aufwendig und führt zu Aussagen in schlechter Qualität.[6]
Werkzeuggestützt
Bei der werkzeuggestützten Traceability gilt es, die über die verschiedenen Bestandteile der Werkzeuglandschaft verteilten Daten zu homogenisieren und zu aggregieren. Hierzu gibt es folgenden Ansätze:
Homogenisierung der Werkzeuglandschaft – ALM Werkzeuge
ALM Werkzeugkettendecken homogen den gesamten Lebenszyklus eines Systems ab und Verwalten dabei in eingem ganzheitlichen Ansatz alle Artefakte des Entwicklungsprozesses.
Vorteil dieses Ansatzes ist, dass sich aufgrund der Homogenisierung die Verlinkung von Artefakten leicht verwalten und mit dedizierten Werkzeugen innerhalb des ALM-Tools 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 - Quasi-Requirements
Requirements-Management-Werkzeuge bieten die Möglichkeit zur Verwaltung und Auswertung von Links zwischen Requirements. Um eine vollständige Verlinkung auch zu anderen Artefakten des Entwicklungsprozesses zu ermöglichen, können bei eingigen dieser Werkzeuge andere Artefakte als „Quasi-Anforderung“ importiert werden. Hier wird z.B. erklärt, wie Elemente eines Matlab Modells als sog. "Surrogate" nach IBM DOORS importiert werden.
Der Vorteil hierbei ist, dass viele am Markt etablierte Werkezeuge die Möglichkeit bieten, die Daten als Quasi-Requirements darzustellen.
Nachteil hierbei ist, dass man für die verschiedenen Artefakt-Typen verschiedene Adapter oder Konvertierer benötigt, die in Version und Datenformat konsistent sein müssen. Im Gegensatz zu einer ALM-Werkzeugkette muss man hier die Konsistenz der Adapter und Konvertierer in Eigenregie sicherstellen.
Homogenisierung der Daten - dedizierte Traceability Werkzeuge
Der Ansatz dedizierte Traceability-Werkzeuge ist, die relevanten Daten aus den Artefakten im Entwicklungsprozess zu extrahieren und in einem einheitlichen Traceability-Modell darzustellen. Die Anbindung der bestehenden Bestandteile der Werkzeuge erfolgt dabei über Adapter. Zudem bieten diese Werkzeuge Schnittstellen, um beliebige – auch proprietäte – Werkzeuge einzubinden.
Der Einsatz dedizierter Traceability-Werkezuge vereint die Vorteile der beiden oben genannten Ansätze: Die Konsistenz der Adapter und Konvertierer wird durch den Anbieter des Traceability-Werkezeugs sichergestellt, während die Flexibilität der Werkzeugkette durch anpassbare Schnittstellen im Werkzeug selbst gewährleistet wird
Der Nachteil bei diesem Ansatz ist, dass aufgrund der Flexibilität dieser Werkzeuge bei der Definition des Traceability Information Model nicht nur die Artefakt-Typen und deren Verlinkung definiert wird, sondern dass auch die technische Anbindung der Werkzeuge konfiguriert werden muss.
Dedizierte Traceability Werkzeuge
Capra
"Capra ist ein dedizierten Traceability Management Werkzeug, welches die Erzeugung, Verwaltung, Visualisierung und die Analyse von Trace Links innerhalb Eclipse ermöglicht."
Capra ist Bestandteil der Open Source Tool Platform AMALTHEA 4public, die wiederum aus dem EUREKA Forschungsprojekt AMALTHEA hervorgegangen ist.
Reqtify
"Reqtify ist eine leicht benutzbare, interaktive Anwendung um Requirements zu verwalten. Es ermöglicht Traceability und Auswirkungsanalyse über den kompletten Lebenszyklus in der Hardware- und Softwareentwicklung."
Reqtify ist ein kommerzielles Werkzeug der Firma Claytex.
YAKINDU Traceability
"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 .
Literatur
- 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 3-446-40509-7, S. 409–442.
- ↑ 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.
- ↑ Software and Systems Traceability - Springer. doi:10.1007/978-1-4471-2239-5 (springer.com [abgerufen am 12. Dezember 2016]).
- ↑ Houdek: Managing Large Scale Specification Projects. In: 19th Intl. Working Conference on Requirements Engineering: Foundation for Software Quality. Essen, Germany 2013 (refsq.org [PDF]).
- ↑ 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, ISSN 0740-7459, S. 58–66, doi:10.1109/MS.2013.60 (ieee.org [abgerufen am 12. Dezember 2016]).
- ↑ About Open-DO. In: www.open-do.org. Abgerufen am 12. Dezember 2016.
- ↑ Traceability-Anforderungen kennen und mit ALM effizient umsetzen. In: All-Electronics.de. 25. November 2015 (all-electronics.de [abgerufen am 12. Dezember 2016]).