Einleitung

Referenzen auf nichtexistierende Kapitel oder Dokumente, veraltete Abbildungen, inkonsistente Bezeichnungen!

Eine ungepflegte Systemarchitektur-Dokumentation wirft oft mehr Fragen auf, als sie zu beantworten im Stande ist. Dementsprechend sollte darauf geachtet werden, dass alle Informationen immer auf Stand gehalten werden.

Doch selbst mit den besten Vorsätzen, präzise definierten Arbeitsabläufen und streng eingehaltenen Entwicklungsprozessen, werden sich immer wieder einmal Fehler einschleichen. Dies hat zur Folge, dass man den Informationen doch nicht immer ganz vertraut und öfter auch in der Implementation nachsieht.

Im Folgenden wird das Problem des Informations-Managements im Systementwicklungsprozess beleuchtet. Dabei werden die Schwächen des «klassischen» dokumentenzentrierten Ansatzes angesprochen und alternative Ansätze aufgezeigt.

Wieso ist es so schwierig die, Informationen aktuell zu halten?

Eine Systemarchitektur hat eine hierarchische Struktur, welche üblicherweise in einem oder mehreren Dokumenten mittels Abbildungen und Text, beschrieben wird.

In Abbildung 1 ist ein Beispiel für die Struktur einer Systemarchitektur dargestellt. Die Pfeile stellen zum einen die hierarchische Abhängigkeit dar und zum anderen den Informationsfluss (Bezeichnungen etc.) im Zuge des Design-Prozesses.

Abbildung 1: Systemarchitektur Dokumente (mit Implementations-Artefakten) für ein System mit drei Teilsystemen.

Die Informationen sind also über mehrere Dokumente und Abbildungen verteilt und wenn eine Information an mehreren Stellen verwendet wird, handelt es sich immer um eine Duplikation. Man erstellt also jedes Mal eine Kopie der Information, wobei keinerlei Verbindung mehr zur Ursprungsinformation besteht.

Damit ist das Problem schon offensichtlich. Um eine Änderung korrekt durchzuführen, muss die Information an allen Stellen, wo diese verwendet wird, angepasst werden. Dies ist nicht nur sehr zeitaufwändig, sondern auch fehleranfällig, da völlig unbekannt ist, wo die entsprechende Information überall verwendet wird.

Das fortlaufende Kopieren und Weitergeben einer Information erinnert stark an das wohl allen bekannte Kinderspiel «Stille Post», wobei hier der Reiz gerade darin liegt, dass es unvermeidlich zu Fehlern kommt.

In Abbildung 2 dient dieses einfache Spiel, zum Aufzeigen dessen, was mit einer Parameterbezeichnung passieren könnte – in diesem Fall sogar, ohne einen inhaltlichen Fehler einzuführen. Für die Verständlichkeit einer Systemarchitektur ist dies jedoch auch sehr abträglich.

Abbildung 2: Problem von Informationsduplizierung, veranschaulicht anhand des Kinderspiels «Stille Post»

Wie kann das divergieren von Informationen verhindert werden?

Wenn wir uns das «Stille Post»-Beispiel ansehen, ist die Lösung wohl offensichtlich.

Abbildung 3: Der erste in der Reihe stellt sicher, dass alle die Information direkt von ihm erhalten. Die Information kann nicht divergieren, wenn sie immer aus einer einzigen Quelle stammt.

Und so einfach ist der ganze Spass des Spiels zunichtegemacht. Für alle anderen Fälle, in denen abweichende Informationen keinen Spass machen, bringt dies jedoch einen grossen Vorteil.

In der Softwareentwicklung gibt es ein Grundprinzip, welches genau darauf abzielt: «Don’t repeat yourself». Hauptziel ist, Redundanz zu vermeiden, um die Widerspruchsfreiheit zu erhöhen. Dieses Prinzip kann auch auf eine Systemarchitektur angewendet werden. Damit wäre es möglich, diese einfach und mit geringem Fehlerrisiko auf Stand zu halten, wovon nicht nur der Design-Prozess profitiert, sondern auch der Entwicklungs- und LifeCycle-Prozess.

Ein weiterer Weg, dies zu erreichen, ist die andauernde Synchronisation der Informationen. Dabei wird die Änderung einer Information automatisch an alle Instanzen, welche diese benutzen, propagiert. Dabei handelt es sich um einen dezentralen Ansatz, bei welchem eine Softwareentwicklungs-Analogie am ehesten einem Git-Repository, mit der Möglichkeit zum Zusammenführen (merge), mehrerer Informationsbestände entspricht.

Wie lässt sich dies umsetzen?

Single Point of Definition

Ebenfalls aus der Softwareentwicklung kommt ein Ansatz, den man entweder als pragmatisch oder radikal betrachten kann, «the Code is the design». Vielleicht ist dieser Ansatz auch ein Resultat des «Law of the Instrument» («Wer nur einen Hammer hat, sieht in jedem Problem einen Nagel»).

Und obwohl die Schlichtheit dieser Idee einen gewissen Reiz hat, bringt sie zu viele Limitierungen mit sich.

• Limitierung auf reine Software-Projekte.
• Die Verständlichkeit leidet enorm an einer Überfrachtung mit zu vielen unnötigen Details.
• Das rein textbasierte Medium erlaubt keinerlei grafische Elemente zur Erläuterung.

Ein etwas generellerer Ansatz ist die Verwendung eines zentralen Informationsmanagers, welcher Informationen zentral verwaltet und für die unterschiedlichen Einsatzgebiete zur Verfügung stellt. Diese Idee ist auch nicht neu und wird in der Softwareentwicklung zum Beispiel im «Model View Controller»-Konzept verwendet. In der Systementwicklung spricht man dabei oft von «Model based …» oder «Model driven …». Dabei versteht man unter «Model» den Ort, an dem die zentralen Daten abgelegt bzw. verwaltet werden.

In Abbildung 4 ist das weiter oben gezeigte Beispiel der Struktur einer Systemarchitektur dargestellt, wobei eine zentrale Informationsmanagement-Instanz hinzugefügt wurde.

Abbildung 4: Systemarchitektur für ein System mit drei Teilsystemen mit zentraler Informationshaltung.

Dieser Ansatz benötigt aber eine stärkere Unterstützung durch spezifische Softwarelösungen, da Informationen vom «System Model» bezogen werden müssen. Als Folge dessen sind die Architektur-Dokumente nicht mehr das direkte Ausgangsprodukt des Designprozesses, sondern müssen in einem gesonderten Schritt, aus dem «System Model», generiert werden.

Doch auch, wenn dies eine gewisse Umstellung in den gewohnten Arbeitsmitteln mit sich bringt, überwiegen die Vorteile einer solchen Lösung. Dies ist nicht zuletzt daran zu sehen, dass sich ähnliche Konzepte in anderen Gebieten bereits durchgesetzt haben. Als Beispiele seien hier die CAD-Software für die Mechanikentwicklung oder ECAD-Software für die Elektronikentwicklung erwähnt. In der IMT werden hierfür zum Beispiel «SOLIDWORKS 3D CAD» und «Altium Designer» eingesetzt.

Synchronisation

Eine geläufige Bezeichnung für diesen Ansatz ist «Roundtrip engineering», dabei sollen Informationen in unterschiedlichen Dokumenten, Software-Artefakten, etc. synchron gehalten werden.  Es beschreibt damit so etwas, wie das Idealbild einer Software Architektur oder gar einer ganzen Produktumsetzung. Unabhängig an welcher Stelle ich eine Information verändere wird diese automatisch an allen Stellen, wo sie verwendet wird, nachgeführt. Es verspricht sogar noch mehr, unabhängig davon, ob eine neue Komponente in der Architektur oder der Implementation hinzugefügt wird, erhält man denselben vollständigen Satz an Dokumenten, Software-Artefakten, etc. So schön dies auch wäre, beginnt hier diese Utopie etwas zu bröckeln.

Das grundlegende Problem ist, dass dies eine eineindeutige Beziehung zwischen allen hierarchischen Ebenen voraussetzt. Dies würde nicht nur zu sehr strikten Einschränkungen bei der Umsetzung führen, sondern ist in manchen Fällen zudem nicht erreichbar, da durch die Abstraktion auf höheren Ebenen gar nicht die gesamte Information vorhanden ist.

Doch betrachten wir das etwas pragmatisch, zeigt sich, dass dies für den Anwendungsfall der Systementwicklung auch gar nicht nötig ist. Vielmehr scheint es für mich viel verständlicher, wenn klar definiert ist, auf welcher Ebene welche Information definiert ist. Mit der Ausnahme dieser Einschränkung kann die zentrale Datenhaltung, welche zuvor vorgestellt wurde, dieselbe Funktionalität zur Verfügung stellen.

Kann die zentrale Information auch über die Systemarchitektur hinaus verwendet werden?

Natürlich wäre es konsequent, in möglichst allen Aspekten der Systementwicklung, diese zentralen Daten zu verwenden. Dies erfordert jedoch eine Integration aller dafür notwendigen Funktionen in eine Softwarelösung, oder zumindest eine definierte Schnittstelle, um die Informationen zu teilen. Da die unterschiedlichen Gebiete der Systementwicklung jedoch jeweils sehr spezifische Anforderungen haben und es dafür bereits sehr gute eigenständige Softwarelösungen gibt (z.B. «SOLIDWORKS 3D CAD» und «Altium Designer»), wäre es wohl mit einem enormen Aufwand verbunden, die Informationen auch direkt in den spezifischen CAD-Anwendungen zu verwenden.

Für den agilsten Teil der Systementwicklung, die Softwareentwicklung, ist es aber gut möglich, mit Hilfe von Code-Generierung, die Struktur und sogenannten «Boilerplate-Code», für die Implementation zu erzeugen. Damit können die Vorteile des zentralen Informationsmanagements bis in die Umsetzung hinein genutzt werden. Die IMT setzt hierfür auf das eigene, im Haus entwickelte Software-Tool «DATAFLOW Designer», welches neben dem Bereitstellen von Boilerplate-Code auch beim Nachweis der Normenkonformität unterstützt.

Zusammenfassung

Das Ziel ist eine aktuelle, widerspruchsfreie und verständliche System Architektur, welche jedem Entwickler die benötigten Informationen einfach und schnell zur Verfügung stellt. Um dies zu erreichen, sollte die Entwickler bei der Erstellung und Anpassung bestmöglich unterstützt werden. Ein fundamentaler Baustein dafür stellt das zentrale Informations-Management dar, mit dem es möglich ist, die Entwickler vom Design bis zur Umsetzung auf vielseitige Weise zu unterstützen. Die erzielbaren Effizienz- und Qualitätssteigerungen kommen dabei sowohl dem Kunden als auch dem Entwickler zugute.

Einleitung

Die (EN) ISO 13485 in Ihrer Ausgabe von 2016, genauso wie die FDA Guidances und die Europäische Medical Device Regulation (MDR) fordern, dass Software, welche im Qualitätsmanagement System der Medizingerätehersteller verwendet wird, zu validieren sei. Während die ISO 13485 und die EU MDR nicht weiter beschreiben, wie die Toolvalidierung auszusehen hat, hat die US FDA am 11. Januar 2002 eine Guidance veröffentlicht: “General Principles of Software Validation; Final Guidance for Industry and FDA Staff”. Auch die Arbeitsgruppen von ISO und IEC haben sich Gedanken zu diesem Thema gemacht und 2017 den ISO/TR 80002-2 veröffentlicht: «Validation of software for medical device quality systems».

Ziel dieses Artikels ist es, einen einfachen Weg aufzuzeigen, wie eine solche Tool-Validierung aufgebaut werden kann.

Software Liste

Beide, die ISO 13485 (in Kapitel 4.1.6) und die FDA Guidance (in Kapitel 4.8) fordern, dass die Validierung der Software dem Risiko der Software entspricht, unabhängig von der Firmengrösse oder der zur Verfügung stehenden Ressourcen. Dementsprechend benötig ein Qualitätsmanagementsystem eine Übersicht über die eingesetzten Softwareapplikationen sowie ihres Verwendungszwecks. Vorzugsweise wird in dieser Übersicht auch dokumentiert ob es sich um eine

• «Off the shelf» Software (also eine Software die als Massenprodukt im Handel erworben werden kann),
• eine angepasste Software
• oder sogar um eine explizit für den geplanten Einsatz entwickelte Software handelt.

Eine Standard-Software wie z.B. Word von Microsoft sind zu tausenden installiert, die Wahrscheinlichkeit, dass die Schwarmintelligenz dieser tausenden von Nutzern ein Fehler findet, ist wohl um einiges höher, als meine Tool Validierung. Diesem Umstand darf in der Toolvalidierung Rechnung getragen werden. Der Prozess für Standard Software, welche nur für nicht-kritische Zwecke verwendet wird, kann unter Umständen bereits hier abgeschlossen werden.

Abbildung 1: Software Liste

Software Validierungsplan

Der Software-Validierungsplan bzw. Toolvalidierung sollte folgende Elemente enthalten:

1. Beschreibung der Software inklusive vorgesehenen Gebrauch, vorgesehene Nutzer und deren Umgebung
2. Anforderungen an die Software
3. Testspezifikation für die Softwareanforderungen
4. Risikomanagement Plan für die zu validierende Software

Diese Elemente können entweder alle in einem Dokument mit verschiedenen Unterkapitel dokumentiert werden, oder aber in verschiedene Dokumente ausgelagert. Letzteres eignet sich vor allem bei umfangreicheren Anforderungsdokumenten.

Beschreibung der Software

Das Kapitel oder Dokument mit der Beschreibung der Software soll den vorgesehenen gebrauch, die vorgesehenen Nutzer und deren Umgebung beschreiben. Use Case Diagramme können hier von Vorteil sein um eine einfache, visuelle Übersicht zu geben:

Abbildung 2: Use Case Diagram – Benutzer Verwalten

Software Nutzer Anforderungen

Die Nutzer-Anforderungen sollten in einer testbaren Form erfasst und mit einer eindeutigen ID versehen werden. Wir bei IMT nutzen hier meist die folgende Syntax:

zum Beispiel könnte eine solche Anforderung heissen

oder

Beide Anforderungen haben eine eindeutige ID und können getestet werden. Anforderungen welche nicht getestet werden können sind zu vermeiden, so sollte «schnell» durch eine Zeitangabe wie «2 Sekunden» ersetzt werden, oder «hell» durch «unter einer Inspektionslampe mit 1500lx».

Testspezifikation für die Nutzer-Anforderungen

Jede Nutzer-Anforderung benötigt im Minimum einen Test. Zur Testspezifikation gehört neben einer eindeutigen ID, die Prüfanweisung sowie das Akzeptanzkriterium oder erwartete Resultat. So könnte ein Test für obiges UR-001 aussehen:

Risikomanagement Plan für diese Software

Da die Auswirkungen bei einem Fehler der Software im Qualitätsmanagementsystem anders sind, als bei einem Medizinprodukt, muss auch der Risikomanagementplan entsprechend angepasst sein. Insbesondere die Definitionen der Auswirkungskategorien benötigen eine differenzierte Betrachtung. Je nach Anwendungsbereich bekommen die selben Auswirkungskategorien eine völlig unterschiedliche Bedeutung. Die Auswirkungskategorie «kritisch» bedeutet bei einem Medizingerät möglicherweise den Tod eines Patienten, bei einer Software zur Rückverfolgung der Medizingeräte dagegen der Verlust von Daten.

Prüfen und Bewerten

Bevor der Validierungsbericht erstellt werden kann, muss die Software getestet und die Risiken müssen bewertet werden.

Testbericht

Die Software ist gemäss der Prüfspezifikation zu prüfen. Dabei ist zu jedem Prüfschritt nicht nur ein «Pass/Fail» zu protokollieren, sondern auch das tatsächlich beobachtete Verhalten, so dass die Prüfung nachgestellt werden kann. Daher muss auch die Software und ihre Umgebungsbedingungen protokolliert werden. Dazu gehören:

• Name und Hersteller der Software
• Version, Build Nummer
• Betriebssystem
• 32/64 Bit Umgebung
• Verwendete Peripherie
• ….

Aber auch Datum, Prüfer sowie eine Bewertung im 4-Augen-Prinzip gehört dazu:

Ein solcher Report für obiges Beispiel könnte wie folgt aussehen:

Risikoanalyse

In der Risikoanalyse sollten alle bekannten Probleme bewertet werden. Bei Software, welche mit dem Zweck des Einsatzes in regulierter Umgebung vertrieben wird, wird oft auch eine entsprechende Liste der bekannten Anomalien veröffentlicht. Hier lohnt es sich auf der Support-Webseite vom Hersteller nachzusehen oder den Support zu kontaktieren. Neben den Problemen die dem Hersteller bekannt sind, sind auch Unzulänglichkeiten wie fehlende Features zu bewerten. Ist ein Risiko nicht akzeptabel, müssen Kontrollmassnahmen definiert werden, um das Risiko zu reduzieren. Als Medizingerätehersteller, welche sich an Risikomanagement nach ISO 14971 gewöhnt sind, empfehlen wir, dabei dem gleichen Prozess zu folgen.

Software Validierungsbericht

Der Software Validierungsreport sollte folgende Elemente enthalten:

1. Identifikation der Software und Umgebung
2. Testbericht(e) oder Verweis(e) darauf
3. Risikomanagementbericht über die bekannten Anomalien der Software
4. Nachweis, dass alle Anforderungen geprüft wurden. Dies lässt sich am einfachsten über eine Traceability Matrix abbilden.
5. Formelle Bewertung und Freigabe der Software zur Nutzung

Hinweis: Für «kleinere» Applikationen, kann möglicherweise Testreport, Risikoanalyse und Validierungsbericht auch in einem Dokument erstellt werden.

Identifikation der Software und Umgebung, Testbericht

Oft gibt es für die Software eine Matrix der validierten Versionen und Umgebungen, dann sollte diese im Validierungsbericht entsprechend abgebildet werden:

Risikomanagementbericht über die bekannten Anomalien der Software

Der Validierungsbericht soll weiter das Restrisiko welche durch die Nutzung dieser Software entsteht bewerten. Insbesondere liegt hier der Fokus auf der Akzeptabilität der bekannten Anomalien und/oder fehlenden Funktionen.

Traceability

Ein weiterer Aspekt den es abzudecken gibt, ist nachzuweisen dass alle Anforderungen an die Software getestet wurden. Je nach Umfang der Anforderungen und der Dokumentation der Tests haben sich zwei Möglichkeiten herausgeschält dies zu dokumentieren:

Vorwärts-Verlinkung der Anforderungen zu den Tests

Die Anforderungstabelle wird um eine Spalte ergänzt, wo die Anforderung geprüft wird:

Diese Variante eignet sich vor allem bei kleinem Umfang an Anforderungen und wenn die gesamte Validierung in einem Dokument erstellt wird.

Traceability-Matrix

Bei umfangreichen Anforderungsdokumenten oder wenn die Testdurchführung ihre eigenen ID’s besitzt, empfiehlt es sich eine Traceability Matrix zu erstellen, welche die Anforderungen der Testspezifikation und eventuell dem Testbericht gegenüberstellt:

Sollen mehrere Berichte für verschiedene Laufzeitumgebungen und Softwareversionen abgebildet werden müssen, so kann dies in einer Traceability Matrix sehr einfach durch zusätzliche Spalten abgebildet werden.

Formelle Bewertung und Freigabe

Zu guter Letzt soll das Gesamtpaket der Dokumentation bewertet und mit einem Entscheid der Freigabe dokumentiert werden.

Zusammenfassung

Bildlich dargestellt, ist die Validierung der Software im Qualitätsmanagementsystem nichts anderes, als die Systematische, dokumentierte Durchführung der linken und rechten, oberen Ecken des in der Softwareentwicklung weit verbreiteten V-Modells:

Dazu gehören:

• Vorgesehener Nutzen sowie Anforderungen
• Risikomanagement
• Validierung der Nutzeranforderung
• Bewerten der Risiken
• Bewerten der Gesamtvalidieurng und Freigabe der Software für den vorgesehenen Nutzen.