Sprache wechseln

IEC 62304 2015 – Auswirkungen auf Software der Klasse A

17-Mar-2016 - Wolfgang Huber

Die Aktualisierungen der 62304:2015 ändern ein paar Dinge für Software der Klasse A. Einerseits ist die Segregation von Software zwischen Klasse A und Klasse B oder C einfacher, die Arbeit für die Dokumentation jedoch umfassender geworden.

1.24. Segregation


Es wurde jetzt dargelegt, dass ein Softwaresystem in der Klasse A bleibt, wenn es zwar zu Risiken beiträgt, aber Risikokontrollen außerhalb des Softwaresystems durchgeführt werden (entweder in der Hardware oder beispielsweise auch Software der Klasse B oder C, die auf einem anderen Prozessor ausgeführt wird).

Ein SOFTWARESYSTEM gehört zur Softwaresicherheitsklasse A, wenn:
- das SOFTWARESYSTEM nicht zu einer GEFÄHRLICHEN SITUATION beitragen kann; oder
- das SOFTWARESYSTEM zu einer GEFÄHRLICHEN SITUATION beitragen kann, die nicht zu einem unannehmbaren RISIKO unter Berücksichtigung der externen RISIKOKONTROLL-Maßnahmen für das SOFTWARESYSTEM führt.

1.25. Zusätzliche Requirements

Die Anwendung der neuen Version für Software der Klasse A geht mit einigen neuen Maßnahmen einher. Wenn Sie sich für die IEC 62304 entscheiden, sind folgende Maßnahmen erforderlich:

  • Für die Software Requirements muss es Testfälle geben.
  • Probleme müssen während der Tests behoben werden.
  • Nach den Änderungen müssen Regressionstests durchgeführt werden.
  • Sie müssen nachweisen, dass der Testansatz gut ist (z. B. dass eine vollständige und dokumentierte Traceability der Software Requirements vorliegt).
  • Sie müssen die Testaufzeichnungen auf dem aktuellen Stand halten (z. B. mit Informationen wie bestanden/nicht bestanden, Tester usw.).
  • Vor Freigabe des Produkts müssen Sie sicherstellen, dass die Tests alle durchgeführt wurden.
  • Sie müssen bekannte Probleme mit der Freigabe des Produkts bewerten und melden.
  • Und Sie müssen Änderungsanfragen vor ihrer Implementierung analysieren.

 

1.26. Schlussfolgerung

Alles oben beschriebene sieht nach ziemlich viel zusätzlicher Arbeit aus, aber wenn Sie Best Practices oder einen gängigen Ansatz für die Softwareentwicklung einsetzen, werden Sie sowieso einen Großteil der oben beschriebenen Arbeit erledigen.

Die einzige Ausnahme scheinen hier sehr agile Prozesse zu sein, bei denen Sie von einer Nutzerstory zur nächsten gehen, bis Sie der Meinung sind, Sie sind fertig. Aber auch in diesem Fall können Sie einige der Software Requirements während Ihrer Entwicklung problemlos extrahieren und sie den Nutzerstories zuordnen, die Sie für die Verifizierung verwenden. Damit ist die Hälfte schon geschafft.