Prof. Dr. Christian Johner

Autor: Prof. Dr. Christian Johner

Inhaber der Johner Institut GmbH

Software-Anomalie: Das sollten Sie beachten

Freitag 26. Mai 2017

Die IEC 62304 definiert eine Anomalie als jeglichen Zustand, der abweicht von dem, was auf Grund von Anforderungsspezifikationen, Entwicklungsdokumenten, Normen usw. oder von Wahrnehmungen oder Erfahrungen zu erwarten ist. Anomalien können sich unter anderem beim Review, bei der Prüfung, der Analyse, der Kompilierung oder bei der Benutzung von Medizinprodukte-Software oder zugehöriger Dokumentation finden.

Lesen Sie hier,

  • welche regulatorischen Anforderungen Sie mit Bezug zu Software-Anomalien beachten müssen und
  • wie Sie damit umgehen können.

Update: Die IEC 62304 fordert in Kapitel 5.1.12 die „Identification and avoidance of common software defects“. Was Sie diesbezüglich machen können.

Software-Anomalie: Regulatorische Anforderungen

IEC 62304

Die IEC 62304 fordert von den Herstellern mit Bezug auf Software-Anomalien Folgendes:

  1. Sie müssen übliche Software-Fehler vermeiden, insbesondere auch diejenigen, die für eine Technologie oder Programmiersprache typisch sind. Lesen Sie dazu unten mehr.
  2. Abhängig von der Softwareklasse müssen Sie Anomalien, die sie bei Integrations- und Systemtests finden, dokumentieren und mit dem Problemlösungsprozess behandeln.
  3. Sie müssen Anomalien, die sie während dieses Problemlösungsprozesses finden, ebenfalls dokumentieren.
  4. Sie müssen bei der Software-Freigabe die verbliebenen Software-Anomalien dokumentieren, bewerten und sicherstellen, dass sie zu keinen inakzeptablen Risiken führen. D.h.: es ist nicht generell verboten, Software mit Anomalien in den Markt zu bringen.
  5. Anomalien bei SOUPs (die z.B. in Release Notes veröffentlicht wurden) müssen auf Sicherheitsrelevanz bewertet werden.

FDA

Sehr vergleichbare Anforderungen stellt die FDA. Sie fordert im Rahmen der 510(k) Submission, die verbliebenen Anomalien zu dokumentieren mit

  • Problembeschreibung
  • Auswirkungen auf das Produkt
  • Plänen und Zeitschiene, um diese zu beheben.
  • Darlegung möglicher Auswirkungen auf die Leistungsfähigkeit und Sicherheit des Produkts
  • Begründung, weshalb man diese (noch) nicht behoben hat.

Zusätzlich zur IEC 62304 empfiehlt die FDA, die Liste der Software-Anomalien auch dem Endanwender mitzuteilen.

Vorsicht: Software-Anomalie / Fehler in Medizinproduktesoftware

Tipps zum Umgang mit Anomalien

Viele Hersteller sind unsicher, wie sie mit Anomalien umgehen sollen. Fragen in diesem Kontext sind:

  • Muss ich wirklich alle Fehler, die ich in der statischen Code-Analyse entdecke, bewerten? Das sind hunderte….
  • Woher weiß ich als Software-Entwickler, ob verbliebene Anomalien akzeptabel sind?

Zu diesen Fragen ein paar Tipps.

Tipp #1: Generelle Akzeptanzkriterien für Software-Anomalien

Alle Abweichungen von den eigenen Vorgaben sind Anomalien. Dennoch können Sie generelle Kriterien definieren, unter denen Anomalien akzeptierbar sind. Z.B.: Abweichungen

  • bei einem definierten Satz von Kodierrichtlinien (z.B. die Formatierung betreffend)
  • die bereits im Code Review als unkritisch klassifiziert wurden
  • von Vorgaben zur statischen Code-Analyse, die nur in einer bestimmten Anzahl von Fällen verletzt werden dürfen
  • in als unkritisch definierten Komponenten

Tipp #2: Was Sie tun können, wenn Sie zu viele Anomalien durch die statische Code-Analyse entdecken

Wenn Sie feststellen, dass Sie trotz Tipp #1 mit zu vielen Ihrer eigenen Vorgaben in Konflikt kommen, dann hat das meist eine der folgenden Ursachen:

  1. Sie haben sich übertrieben harte Regeln gegeben. Dann überarbeiten Sie die Regeln.
  2. Sie haben sich Regeln gegeben, deren Vorgaben Sie nur im Lauf der Zeit erreichen können. Dann legen Sie die Regeln als Funktion der Zeit fest.
  3. Sie haben Code unzureichender Güte geschrieben. Dann verbessern Sie ihn.
  4. Sie haben die Regeln global definiert, obwohl die Gütekriterien nur „lokal“ (z.B. kritische Module) relevant wären. Dann formulieren Sie die Regeln neu.

Tipp #3: Wer bestimmt, ob eine Anomalie sicherheitsrelevant ist

Es ist nicht die Aufgabe, Kompetenz und Verantwortung der Software-Entwickler zu entscheiden, ob eine Software-Anomalie kritisch ist. Das kann nur der Risikomanager gemeinsam mit dem Systemarchitekten entscheiden. Beide können dann festlegen, welche Komponenten als sicherheitsrelevant zu klassifizieren sind. Basierend auf dieser Festlegung darf dann die Software-Entwicklung „Bugs“ in kritische und nicht kritische Anomalien einteilen.

Tipp #4: Anomalien vermeiden

Die IEC 62304 fordert seit dem Ammendment 2015, dass Sie insbesondere technologie- und programmiersprachenspezifische Software-Fehler (Anomalien) zu vermeiden versuchen. Mit dieser Forderung tun sich viele Hersteller schwer. Daher hier einige Gedanken:

Jede Programmiersprache hat Stärken und Schwächen, beispielsweise:

  • C
    • keine erzwungene Fehlerbehandlung
    • Überschreiben von Speicher
  • C#/.NET, tw. Java
    • Memory-Leaks
    • keine stringente Prozesstrennung
    • verschiedene .NET-Versionen
    • Update der Laufzeitumgebung während des Betriebs
    • Konsistenzprobleme bei Upcasting
    • Verwechslung von == und equals, usw.
  • JavaScript
    • keine statische Typisierung
    • Uneinheitliche Ausführung in verschiedenen Browsern
  • viele Sprachen: Klassische Laufzeitfehler wie NullPointerException, DivisionByZeroException, ClassCastException u.v.m.

Wenn Sie faul sein wollen, suchen Sie z.B. nach „C# most common mistakes“. Dann finden Sie weitere Ideen.

Persönliche Anmerkung: Die meisten Ursachen für Software-Anomalien liegen nicht in den Programmiersprachen, sondern in der Entwicklung selbst begründet, die grundlegende Best-Practices des Software-Engineerings ignoriert wie


Kategorien: Software & IEC 62304
Tags: ,

2 Kommentare über “Software-Anomalie: Das sollten Sie beachten”

  1. Heiko Schmidt schrieb:

    Hallo Herr Johner

    bei uns geht regelmäßig die Diskussion los, was eine Software Anomalie ist.
    Aus meiner Sicht ist alles was gegen Vorgaben verstößt eine Anomalie (z.B. Kodierrichtlinien, Metriken, Anforderungen,…).

    Beispiele aus der Praxis (extreme Fälle):

    Quellcodekommentar der auf Deutsch ist, anstatt wie vorgegeben auf Englisch.

    Eine Metrik die nicht eingehalten wird

    All diese Dinge gehören aus meiner Sicht in die Liste der ungelösten SW-Anomalien, wenn Sie nicht für das entsprechende Release gelöst werden.

    Auch ein Problem was aus dem Feld gemeldet wird und nach der Analyse auf Software zurückzuführen ist, ist aus meiner Sicht eine Software Anomalie, wenn es nicht für das entsprechende Release gelöst wird, sondern erst später, da unkritisch.

    Mich würde Ihre Meinung dazu interessieren, sind das alles Anomalien, die in die Liste gehören ?
    Es sind natürlich extreme Beispiele, die man besser löst, als Sie zu verwalten !

  2. Prof. Dr. Christian Johner schrieb:

    Lieber Herr Schmidt,

    ich stimme Ihrer Einschätzung absolut zu. Dass die meisten Firmen nur die Anomalien in die Liste aufnehmen, die das externe Verhalten betreffen, ist eine andere Sache. Diese Vorgehensweise ist auch vertretbar, wenn man zu listende Abweichungen nur als diejenigen definiert, die gegen die SRS gehen. Und dazu würden nicht eingehaltene Code-Metriken nicht dazuzählen.

    Besten Dank für die spannende Frage!
    Christian Johner

Kommentar schreiben