Software-Anomalie: Das sollten Sie beachten

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.

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

• ein konsequenter Einsatz von Versionsverwaltungssystemen,
• automatischer täglicher Build-Prozess,
• damit verbundene Regressionstests mit einem hohen Code-Coverage,
• automatisierte statische Code-Analyse und Überprüfung von Codier-Richtlinien,
• systematische Code-Reviews und
• eine gute Ausbildung des Entwicklungsteams.