Traceability

Donnerstag 5. März 2015

Unter Traceability versteht man die Nachvollziehbarkeit verschiedener Aktivitäten entlang des Entwicklungslebenszyklus. Die für Medizinprodukte spezifischen Normen wie die ISO 14971 und die IEC 62304 stellen teilweise konkrete Anforderungen an die Traceability.


Traceability entlang der Entwicklung von Medizinprodukten

Lesen Sie mehr

Traceability und IEC 62304

Die IEC 62304 verlangt die Traceability u.a.

  • von den System-Anforderungen zu den Software-Anforderungen
  • von den Software-Anforderungen in die Software-Architektur
  • vom detaillierten Design zur Software-Architektur
  • von den Software-Systemtests zu den Software-Anforderungen

Traceability zwischen Software-Anforderungen und Software-Architektur

„Der Hersteller muss verifizieren und dokumentieren, dass die Software-Architektur die System- und Software-Anforderungen […] implementiert“ lautet die Forderung der IEC 62304 im Kapitel 5.3.6 zur Verifizierung der Software-Architektur. Ein kurzer Satz, der viele Herstellern fragen lässt: „Und wie mache ich das?“

Diese Nachverfolgung der Software-Anforderungen zur Software-Architektur ist alles andere als trivial. Oft gelingt es noch, die Anforderungen eindeutig zu nummerieren. Ab wie soll man von dort auf ein einziges Architektur-Dokument verlinken können? Ein Dokument in dem die verschiedensten architekturellen Aspekte behandelt werden. Möglicherweise von der Wahl der Programmiersprache über ER-Diagramm für die statische Sicht bis hin zu UML-Verteilungsdiagrammen und Begründungen für bestimmte Architekturpattern.

Diese Verbindung (die Traceability zwischen Requirements und Architektur) wird besonders dann Schwierigkeiten bereiten, wenn das Architekturdokument viel (unstrukturierten) Fließtext enthält. Fließtext halte ich generell für herausfordernd. Denn unsere Sprache ist so vielgestaltig und nuanciert, dass die Eindeutigkeit schnell leidet: Eine Passivkonstruktion, und schon muss man über den Akteur keine Aussage machen. Ein Konjunktiv, und schon bleibt es im Unklaren, ob dieser Aspekt verpflichtend ist oder nicht, oder nur eine Überlegung des Autors wiedergibt. Daher mein Plädoyer:

  • Nutzen Sie lieber Modelle statt Text. Hier sind die Ausdrucksmöglichkeiten sehr eingeschränkt und die Aussagen damit eindeutiger. Modelle in Form von Bildern erlauben einen schnellen Überblick und einfachere Diskussion.
  • Halten Sie Ihr UML-Diagramm „sauber“ von zu vielen Metadaten. Verunstalten Sie es nicht durch Links zu den Software-Anforderungen. Ich empfehle Ihnen aber, im UML-Klassen/Komponentendiagramm die Sicherheitsklassen gemäß IEC 62304 (farblich) zu kennzeichen, ebenso Komponenten anderer Hersteller (SOUPs).
  • Strukturieren Sie das Architektur-Dokument in viele Kapitel. Ein Textabschnitt sollte eine halbe Seite nicht überschreiten, bevor er durch eine neue Überschrift unterbrochen wird. So können Sie über die Überschriften relativ genau auf einen Architekturaspekt verweisen (verlinken): „realisiert in Komponente X (siehe Kapitel m)“, „wird berechnet durch Methode Y(siehe Kapitel n)“, „ist gelöst durch Wahl der Technologie Z (siehe Kapitel o)“.
  • Fügen Sie ein eigenes Kapitel (ggf. sogar ein eigenes Dokument) ein, das der Traceability gewidmet ist. Listen Sie darin die Anforderungen (erneut) auf und schreiben Sie zu jeder einen ganz kurzen Satz mit einem Verweis auf eines dieser Teilkapitel im Architekturdokument.

Traceability zwischen Software-Anforderungen und Software-Systemtests

Das Tracing zwischen Software-Anforderungen und Software-Systemtests gestaltet sich hingegen oft etwas einfacher, da Sie sowohl die Software-Anforderungen als auch die Software-Systemtests (im Gegensatz zu Architekturaspekten) einfach durchnummerieren können.

Allerdings benötigt man für diese Traceability zwischen beiden eine n:m-Beziehung. Das lässt sich über eine Tabelle ausdrücken, die zeigt, welche Systemtests welche Anforderungen testen, und welche Anforderungen durch welche Systemtests geprüft werden.

Traceability und ISO 14971

Ähnlich der Beziehung zwischen Software- bzw. System-Anforderungen und Software- bzw. Systemtests verhält es sich bei der ISO 14971. Die Norm fordert die Traceability

  1. zwischen Risiken und Maßnahmen zur Risikobeherrschung und
  2. zwischen Maßnahmen und der Verifizierung der Maßnahmen (genauer mit der Überprüfung, ob diese implementiert und wirksam sind).

Beide Beziehungen pflegen Hersteller üblicherweise in einer „Risiko-Tabelle“, die manchmal auch fälschlich als „FMEA-Tabelle“ bezeichnet wird.

Werkzeuge für die Traceability

Dass die Word-gestützte Dokumentation schwierig ist, weiß ich. Besonders weil die Verlinkung über Dokumentengrenzen hinweg nicht funktioniert. Aber das ist ja genau der Grund, aus wir MedPack und RiskPack entwickelt haben. MedPack und RiskPack sind Add-ons zu dem „Application Lifecycle Management“ Werkzeug Polarion. Damit bekommt man das Traceability-Chaos besser in den Griff. Das finden übrigens auch die Auditoren. Denn unser Tool hat sich in einigen Audits bewährt. Nicht nur der Auswertungen wegen, die fehlendes Traces direkt anzeigen.

Sie können auch andere ALM-Werkzeuge nutzen. Diese eigenen sich, wenn Sie sie richtig konfigurieren, um die Traceability bei der IEC 62304 herzustellen. Bei der ISO 14971 tun sich die Werkzeuge schwerer, weil die Risiken keine üblichen „Entities“ sind. Auch diese ließen sich ergänzen, aber dann müsste man das ganze Risikomanagement damit abbilden. Und das kann meines Wissens nur RiskPack.

(„realisiert in Komponente X“, „wird berechnet durch Methode Y“, „ist gelöst durch Wahl der Technologie Z“
War dieser Artikel hilfreich? Bitte bewerten Sie:
1 Stern2 Sterne3 Sterne4 Sterne5 Sterne

Autor des Beitrags " Traceability

Johner Institut GmbH

Logo Johner Institut klein

Bewertung 0 von 5 bei 0 Bewertungen


Kategorien: Risikomanagement & ISO 14971, Software & IEC 62304

4 Kommentare über “Traceability”

  1. Jörn Tietjen schrieb:

    Ich halte die Verwendung von UML-Diagrammen im Rahmen der Architekturdokumentation für absolut nützlich, weil man komplexe Sachverhalte wie z.B. eine Multi-Tier-Architektur und die Beziehung zwischen den Schichten einfach viel besser visualisieren kann, als sie in Prosa zu beschreiben.
    Separate Beschreibungen ein und derselben Abstraktionselemente für bestimmte Einsatzzwecke erzeugen IMHO nur double-maintenance.
    Ein Software-Modell in UML-Notation abzubilden hat viele Vorteile, weil man Projektartefakte aus verschiedensten Blickwickeln aus einer *konsistenten* Quelle erstellen kann: Architektur, Risikomanagement, Traceability, Test, Implementierung, usw.
    Die Information liegt also gebündelt vor, jedes Modellelement wird genau einmal definiert, kann aber in verschiedenen Kontexten und in verschiedenen Sichten dargestellt werden (je nach dem, welche Information im jeweiligen Kontext benötigt wird).

    Außerdem sind die meisten UML-Tools in der Lage, einen Export und Import von Modellen in portablen Formaten wie z.B. XML durchzuführen. Durch geeignete Scripte kann man leicht „Metadaten“ einfügen oder automatisch verarbeiten.
    Aber warum überhaupt proprietäre Metadaten verwenden? Die UML bietet für solche Zwecke wie die Kennzeichnung gleichartiger Modellelemente das Mittel der Stereotypen an. Damit kann man leicht risikorelevante Elemente von anderen unterscheiden (und vieles Andere mehr).
    Eine manuelle farbliche Kennzeichnung scheint mir im Vergleich dazu weit anfälliger für Fehlinterpretationen und out-dating zu sein.

    Aber vielleicht ist das ja alles mehr eine Frage des persönlichen Geschmacks 😉

  2. Christian Johner schrieb:

    Sehr geehrter Herr Tietjen,

    danke für Ihre Ergänzungen.

    Ich bin nicht ganz sicher, ob es mir gelungen ist, mich verständlich zu artikulieren. Wenn der Eindruck entstanden wäre, dass ich UML-Diagramm für ungeeignet halte, wäre das exakt das Gegenteil dessen, was ich ausdrücken wollte.

    Ich stimme Ihnen absolut zu, dass Stereotypen geeigneter sind, um Sicherheitsklassen zu charakterisieren, als eine (nur) farbliche Kennzeichnung.

    Nochmals besten Dank!

    Christian Johner

  3. Stefan Bolleininger schrieb:

    Hallo Herr Johner,

    der Empfehlung, „UML-Diagramme“ nicht mit Anforderungen zu verunstalten, kann ich mich nicht anschliessen.
    Ein gutes Werkzeug, welches Mehr als nur Diagramme zeichnen lässt, sondern ein Modell verwaltet besitzt eben diesen Vorteil, die Notwendigkeit eines AArchitekturelements durch Anforderungen nachweisen zu können.
    Besonders, wenn die Architektur aufgrund einer Modelländerung/Anforderungsänderung verändert werden muss, ist so eine schnelle Prüfung des Einflusses möglich und die Tragweite der Anforderungsänderung kann plausibel abgeschätzt werden.
    Ebenso verhält es sich mit den Risikomitigationen, da diese damit an ein Modellelement geknüpft sind und sich die Auswirkung der Codeänderung auf Risikomitigationen, oder deren Nicht-Auswirkung dokumentiert nacgewiesen ist.
    In Kurz:
    Durch die Verknüpfung Modellelement und Anforderung wird eine Impactanalyse vereinfacht und das Projekt/Produkt wartbarer gestaltet.

    Beste Grüße

    Stefan Bolleininger

  4. Christian Johner schrieb:

    Sehr geehrter Herr Bolleininger,

    danke für Ihre wertvollen Gedanken. Die Verlinkung von Anforderungen im Architektur-Diagramm kann durchaus funktionieren, da bin ich ganz bei Ihnen. Es funktioniert v.a., wenn man nicht 1000e Anforderungen zu tracen hat, wenn das Modell so detailliert erstellt wurde, dass man die Traces überhaupt sinnvoll lokalisieren kann und wenn die Anforderungen sich überhaupt im Modell abbilden lassen.

    Viele Grüße
    Christian Johner

Kommentar schreiben