F: Wie siehst Du hier die Anforderungen an das Thema unabhängigkeit zwischen Test und Entwickler. Die FDA Guidance schreibt dies ja als allgemeines Prinzip vor. Ich tue mir aber etwas schwer, denn gerade auf Unittestebene sind es doch die Entwickler, die den Code am besten kennen und auch am ehesten Wissen wo sie hinlagen müssen. Ist es tatsächlich so, dass hier die Tester vom Entwickler unterschiedlich sein müssen (z.B. auch bei Risikorelevantem Code)?

A: Sehr viele Normen und Vorschriften sind etwas unscharf. Die konkretesten Antworten nennt Dir die IEC 60601 (3rd edition). Sie schreibt "Der [Verifizierungs-] Plan muss enthalten [... den] angemessene Grad der Unabhängigkeit des Personals, das die VERIFIZIERUNG durchführt;" Sie verlangt im Gegensatz zur Validierung nicht, dass die Personengruppen (!) diskunkt sind. Es muss aber auch bei der Verifizierung klar sein, dass ein Entwickler seinen Code nicht ausschließlich selbst testet. Als Kompromiss hat sich bewährt, dass der Entwickler zwar seinen eigenen Unit-Test schreibt, das Code-Review durch eine zweite Person(!) diesen Test mit bewertet.

F: Ich habe eine Detailfrage zu der eigentlich grundlegenden Definition von "Software- Einheit" in der 62304. Die Definition lautet: Eine Software Einheit ist eine SW- Komponente, die nicht in weitere Komponenten unterteilt ist." Das klingt esrtmal klar, hat aber Tücken im Detail, denn was heisßt "nicht unterteilt" ganz konkret? Ist in C++ eine Klasse die maßgebliche Ebene? Oder ist eine Klasse in Methoden unterteilt? Oder (extreme Auslegung) ist eine Methode in Zeilen unterteilt? Wie wird dies aus Ihrer Erfahrung heraus von Auditoren gesehen?

A: Die Diskussion über die Größe eine Software- Einheit ist so alt wie die Definition dieses Begriffs.

In der Praxis ist es genau so, wie Sie es vermuten. In C++ entspricht eine Klasse einer solchen Einheit. Zumindest wenn man sauber objektorientiert arbeitet. Bei eher prozeduralem Code oder bei statischen Funktionen/Methoden stellt die Klasse kein geeignetes Kriterium mehr da, weil Sie ja nur durch die Datei selbst eine abgegrenzte Einheit begründet. In diesem Fällen sollte diese einzelne Funktion als Einheit betrachtet werden.

Die Auditoren steigen meist nicht so tief in den Code ab und lassen sich selten auf diese Diskussion ein. Die Entscheidung, dass Klassen generell Einheiten gleichzusetzen sind, wurde bisher nicht widersprochen.

Unabhängig sollte die Entwicklung sich nicht durch ein zu granulares Verständnis einer Software-Einheit und v.a. der Software-Komponente selbst blockieren. Umso kleiner Sie die Komponenten wählen, umso (exponentiell) höher wird Ihr Aufwand für das Testen, die Integration und die zugehörige Dokumentation. Dem folgend, empfehle ich auch, Ihre Komponenten eher grobgranular festzulegen. Diese Komponenten müssen dann aber wirkliche Komponenten sein und die Forderungen nach "weak coupling" (einschließlich Vermeidung aller zyklischer Abhängigkeiten) und "strong cohesion" uneingeschränkt erfüllen. Zu stark miteinander verwobene, amöbenhafte Komponenten sind der Tod für die Wartbarkeit, Wiederverwendbarkeit, Austauschbarkeit und Testbarkeit Ihrer Komponenten. Risikobeherrschung wird zudem fast unmöglich.

F: Wie kann ich die Komplexität in einem Produkt, das viele Zukaufkomponenten (die selbst SW enthalten) bzgl. Klassifizierung der Off-The-Shelf-Produkte und der erforderliche Dokumentation in den Griff bekommen? Gerade in einem Produkt, das - um eine Zahl zu nennen - 30 Komponenten wie Betriebssystem, Monitore, Motoren + Steuerungen etc. enthält, findet man ja die Situation, dass heute in all diesen Komponenten zumindest Firmware drin steckt. Eine Verbindung zu dem Softwaresystem ist ja meistens über das Betriebssystem, gemeinsame Speichernutzung und ausgetauschte Signale gegeben. Hast Du hier eine Idee wie man gerade in solchen Situationen pragmatisch vorgehen kann?

A: Eine pragmatische Vorgehensweise besteht darin, dass man

• alle Firmware der Hardware zu schlägt. Damit reduziert sich die Anzahl der Komponenten dramatisch, in deinem Beispiel Monitor.
• für ein Softwareprodukt ggf. mehrere (!) Softwaresysteme definiert. Spezielle wenn diese über eigene Prozessoren verfügen, ist das ein gangbarer Weg. In Deinem Beispiel sehe ich das möglicherweise bei den Motoren als gegeben. Professor Stettin weißt explizit auf die Möglichkeit hin, dass man mit mehreren Softwaresystemen sogar eine gegenseitige Überwachung (vergleichbar der Risikomaßnahmen in Hardware) realisieren kann. Und um die im Raume stehende Frage zu beantworten: Die IEC 62304 erlaubt dieses Vorgehen.

Die Liste an weiteren Fragen wird immer länger. Um diese Seite nicht übermäßig lang werden zu lassen, können Sie sich einen Link auf die Antworten zuschicken lassen. Tragen Sie einfach unten Ihre E-Mailadresse ein.

Die Fragen

• Muss ich Testwerkzeuge validieren? Genauso wie das Produkt selbst?
• Muss ich mich nach IEC 62304 und IEC 62366 zertifizieren? Schließlich sind beide Normen harmonisiert.
• Wie bekomme ich meine Dokumente (System-Anforderungen, Software-Anforderungen, Software-Design) usw. synchronisiert? Wie vermeide ich es, dass bei einer Versionsänderung eines Dokuments die Verweise in allen anderen Dokumenten überarbeitet werden müssen?
• Wann kann man eine Software der Hardware zuordnen?
• Kombinationen von Medizinprodukten: Ich habe mehrere einzelne Produkte, beispielsweise eine Software, einen PC, auf dem die Software läuft, ein Medizingerät, das über einen Router mit dem PC verbunden ist und von der Software angesteuert wird. Was muss/soll ich als Medizinprodukt in Verkehr bringen?
• Die ISO 14971 verlangt den vorhersagbarem Missbrauch bei der Risikoanalyse zu betrachten. Hat dieser etwas mit der Gebrauchstauglichkeit zu tun? Schließlich greifen die ISO 14971 und IEC 62366 eng ineinander.
• Kann ich meine Software vollständig in Gefährdungsklasse A klassifizieren?
• Wie validiere ich Software?
• Kann ich ein klinisches Informationssystem durch Modularisierung teilweise als Medizinprodukt, teilweise als "Nicht-Medizinprodukt" in Verkehr bringen?
• Verlangt die IEC 62304 nun die Validierung oder nicht?
• Muss ich in jedem Fall Unittests durchführen?
• Fallen Assemblercode und Firmware auch unter die Forderungen der IEC 62304?
  
• Muss ein Medizinprodukt immer zweikanalig ausgelegt sein? Falls ja, wie würde man das bei Software realisieren?
• Ich habe ein Software-System, welches durch ein zweites unabhängiges kontrolliert werden soll, auch um die Sicherheitsklassifizierung des überwachten Systems von C auf B zu reduzieren. Muss dann das kontrollierende System automatisch als Klasse C eingestuft werden?
  

Tragen Sie einfach in das Formular Ihre E-Mail-Adresse ein. Sie bekommen nicht nur die Antworten auf noch mehr Fragen, sondern auch die kostenlose Gesetzessammlung.

Garantie: Ich, Christian Johner, achte die Vertraulichkeit Ihrer persönlichen Daten genauso wie Sie. Daher gebe ich Ihre Daten unter keinen Umstände an Dritte weiter. Versprochen!