Ein Großteil der Softwaredefekte in Medizingeräten tritt nach erfolgter Produktfreigabe auf, und viele der Defekte haben mit der Anwendung ungeeigneter Software-Updates und -Upgrades zu tun. Aus diesem Grund wird die Wartung als ebenso wichtig angesehen wie Entwicklung. Die mit der Wartung einhergehenden Risiken müssen wiederum gemäß den im Standard formulierten Prozessen und Prozeduren verfolgt, verwaltet und abgemildert werden (Bild 1). Angesichts der Ähnlichkeit der vor und nach der Freigabe erforderlichen Prozesse und unter der Bedingung, dass von vornherein eine zuverlässige Software bereitgestellt wird, ist es sinnvoll, dieselbe Toolchain anzuwenden, die auch bei der Entwicklung benutzt wurde.
Für den Wartungsplan muss der Hersteller alle Prozeduren, die für die Implementierung der Wartungsaktivitäten und –aufgaben nötig sind, erstellen oder identifizieren. Um Hilfemaßnahmen umzusetzen, Änderungen im Zuge der Wartung und für das Management der Freigabe revidierter Software zu kontrollieren, sollten alle gemeldeten Probleme und Anforderungen der Benutzer dokumentiert und aufgelöst werden. Upgrades und damit zusammenhängende Modifikationen an der Funktionalität der Medizingeräte-Software lassen sich dadurch besser koordinieren.
Einzelne Modifikationen können sich sehr unterschiedlich auswirken und von geringfügigen Korrekturen bis zur kompletten Migration einer Applikation auf eine neue Umgebung oder Plattform reichen. Ziel ist es in beiden Fällen, die freigegebene Medizingeräte-Software zu modifizieren, ohne ihre Integrität zu beeinträchtigen. Wenn die Änderungen nach neuer Entwicklungsarbeit verlangt, sollten sie gemäß den Abschnitten in den allgemeinen Teilen der Norm sowie den speziell für die Wartung geltenden Teilen verwaltet werden. Wie bei der Analyse der Softwareanforderung sollte auch bei der Wartung ein Format verwendet werden, das sich für die bidirektionale Rückverfolgbarkeit eignet.
Identifikation erforderlicher Nachprüfungen
Viele Softwaremodifikationen erfordern Änderungen an der bestehenden Funktionalität – möglicherweise im Hinblick auf zusätzliche Dienstfunktionen in der Software. Unter diesen Umständen ist sicherzustellen, dass etwaige Änderungen oder Ergänzungen an der Software keine negativen Auswirkungen auf den existierenden Code haben.
Ein Requirements-Traceability-Tool wie der LDRA TBmanager hilft dabei, das Problem zu entschärfen, indem die Verbindungen zwischen Anforderungen, Entwicklung und Test-Artefakten und -Aktivitäten automatisch gepflegt werden. In dem Beispiel in Bild 2 wird eine Änderung an der System-Anforderung »Installation und Konfiguration« vorgeschlagen. Dank der zuvor eingerichteten Rückverfolgbarkeit zwischen Anforderungen, Code und Test kann das Tool zeigen, welche Codeabschnitte von der vorgeschlagenen Änderung betroffen sind (Bild 3).
Der existierende Code in seiner eingeführten Form sollte ebenfalls Gegenstand von Maßnahmen zur Qualitätskontrolle wie der statischen Analyse gewesen sein, um zu ermitteln, ob die Codierstandards erfüllt sind. Modultests sollten außerdem die Funktionalität der einzelnen Codemodule bestätigen. Mit der dynamischen Analyse sollte schließlich der Nachweis erfolgen, dass alle Teile des Codes angesprochen wurden.
Selbstverständlich werden einige Tests Änderungen erfordern, um die von der aktualisierten Anforderung diktierte neue Funktionalität wiederzugeben. In vielen Fällen reicht es jedoch aus, zu bestätigen, dass alles so funktioniert wie zuvor. Artefakte aus dem Entwicklungsprozess, wie etwa Berichte über Einhaltung der Codierstandards und Code-Coverage-Reports werden ebenfalls beibehalten und mit den Anforderungen verknüpft, damit beim erneuten Ausführen der Tests auch diese Artefakte erneut generiert werden (Bild 4).
Fazit
Eine Norm für die funktionale Sicherheit von Software, wie sie mit der IEC 62304 und ihren zahlreichen Teilen, Abschnitten und Unterabschnitten vorliegt, kann zunächst abschreckend wirken. Sobald man sie jedoch in leichter verständliche Stücke unterteilt hat, können die ihr zugrundeliegenden Prinzipien als solide Leitlinien für die Ausarbeitung eines qualitativ hochwertigen Softwareentwicklungs-Prozesses dienen, der sich nicht nur bis zur ersten Produktfreigabe erstreckt, sondern bis zur Wartung und darüber hinausreicht. Ein solcher Prozess ist wichtig, um Zuverlässigkeit und Qualität – in erster Linie der Sicherheit und Effektivität – von Medizingeräten zu gewährleisten.