Softwarekomponenten

Definition des Begriffs Software-Komponente gemäß IEC 62304

Die IEC 62304 definiert eine Software-Komponente als jedes identifizierbare Teil eines Computerprogramms. Im Englischen entspricht dies dem Software-Item.

Software-Komponenten, die nicht weiter zerlegt werden nennt die Norm Software-Einheiten (Software Unit).

Die IEC 62304 legt nicht fest, ob die Software-Komponenten logische und physische Komponenten sind. Eine logische Software-Komponente wäre z.B. ein Package oder ein Modul. Unter physische Software-Komponenten versteht man hingegen Teile einer Software, die als Datei erkennbar sind wie dlls, exe-, HEX- oder Skriptdateien.

SOUP sind ebenfalls Software-Komponenten, da sie auch identifizierbare Teile eines Software-Systems sind.

Weiterführende Informationen

Entwickler haben verstehen unter einer Software Unit und einem Unit-Test etwas anderes als die Norm. Lesen Sie hier mehr zu den typischen Fallen bei Unit-Tests und hier mehr zu Software Einheiten.

Was eine gute Software-Komponente auszeichnet

Software-Komponenten sollten generell Funktionalitäten kapseln und über wohl-definierte Schnittstellen zur Verfügung stellen. Je schwächer Software-Komponenten voneinander abhängen („weak coupling“) umso wartbarer und testbarer ist die Software-Architektur.

Eine schwache Kopplung von Komponenten erreichen Sie, indem Sie beispielsweise

  • nur wenige Methoden und Variablen dieser Komponente öffentlich machen,
  • die Anzahl der Übergabeparameter von Methoden minimieren,
  • Vererbung über Komponentengrenzen hinweg vermeiden und
  • Methoden durch Interfaces abstrahieren.

Kapselung von Software-Komponenten zerstören

Eines der zentralen Architektur-Paradigmen lautet: „Weak coupling and strong cohesion“. Es sollte also eine schwache Kopplung zwischen den Komponenten und ein starker Zusammenhalt innerhalb einer Komponente bestehen.

Die Architekturen mancher Medizinproduktehersteller verkörpern genau das Gegenteil. Daher möchte ich Ihnen ein paar Tipps geben, wie auch Sie die Kapselung Ihrer Komponenten schnell und erfolgreich zerstören können :-):

  1. Am besten Sie bilden gar keine Komponenten. Vielmehr malen Sie in Powerpoint um eine willkürliche Auswahl an Klassen einen Rahmen und nennen diesen „Komponente“.
  2. Nutzen Sie bei Ihren Klassen bzw. Methoden/Funktionen möglichst oft das Schlüsselwort „public“. Schließlich soll doch jeder auf die großartigen Funktionen zugreifen können.
  3. Achten Sie darauf, dass Ihre Methoden möglichst viele Übergabeparameter haben. Es ist doch super praktisch, eine Klasse Patient mit allen Angaben wie Vorname, Nachname, Geburtsname, Geburtsdatum, Wohnort, Postleitzahl, Straße, Land, Name Versicherung, Versicherungsstatus, Versicherungsnummer usw. zu instanzieren. Oder?
  4. Zu den Klassikern zählen möglichst viele globale Variable. Nur so können Sie von überall auf deren Werte zugreifen.
  5. Sehr bewährt hat es sich bei objektorientierten Sprachen über Komponentengrenzen hinweg zu erben. Damit können auch andere Komponenten von den raffinierten Funktionalitäten einer Super-Komponente profitieren.
  6. Ebenso zielführend ist es, Fehler über Komponentengrenzen zu werfen.

Apropos Objektorientierung: Wer hat sich eigentlich diesen Quatsch ausgedacht?

Anforderungen der IEC 62304 an die Entwicklung von Software-Komponenten

Die IEC 62304 verlangt zumindest für Software der Sicherheitsklassen B und C in Kapitel 5.3 (Software-Architektur), dass die Hersteller die Software-Komponenten identifizieren und die Schnittstellen zwischen diesen Komponenten beschreiben.

Weiter fordert die Norm in Kapitel 5.4, dass die Hersteller die Software-Komponenten weiter in Software-Einheiten zerlegen (zumindest bei Sicherheitsklasse C).

Schließlich adressiert die IEC 62304 das Integrationstesten von Software-Komponenten in Kapitel 5.6.

Im Auditgarant finden Sie mehrere Videotrainings, wie Sie die Forderungen der IEC 62304 auch im Bezug auf die Spezifikation und das Testen von Software-Komponenten sehr präzise und ohne nennenswerten Dokumentationsaufwand erfüllen.

Videotrainings ansehen


Dienstag 26. Juli 2016 von Prof. Dr. Christian Johner

Ein „detailliertes Design“ fordern sowohl die IEC 62304 als auch die FDA, jedoch ohne diesen Begriff präzise zu definieren. Lesen Sie hier, wie Sie die regulatorischen Anforderungen schnell und „auditsicher“ erfüllen können.

Inhaltsübersicht

Den ganzen Beitrag lesen »


Mittwoch 19. August 2015 von Prof. Dr. Christian Johner

Software-Systeme sollten aus Komponenten bestehen, die über Software-Schnittstellen miteinander kommunizieren. Dieser Artikel beschreibt, wie Sie Software-Schnittstellen IEC 62304 konform dokumentieren können. Dabei zeigt er Konzepte, die sich nicht nur auf interne und externe Software-Schnittstellen, sondern auch auf Hardware-Schnittstellen übertragen lassen.

Update: Internet als interne Schnittstelle?

Den ganzen Beitrag lesen »


Mittwoch 12. August 2015 von Prof. Dr. Christian Johner

Die IEC 60601-1 definiert ein PESS, ein programmierbares elektronisches Subsystem, als System, das auf einer oder mehreren zentralen Prozessoreinheiten beruht, einschließlich deren Software und Schnittstellen.

Die Norm verrät nicht, was sie unter System versteht, es ist in diesem Kontext eine Komponente des Medizinprodukts. Dafür stellt die IEC 60601-1 konkrete Anforderungen an die PESS.

 

Den ganzen Beitrag lesen »


Mittwoch 6. Mai 2015 von Prof. Dr. Christian Johner

Viele Medizinproduktehersteller nutzen für die Entwicklung ihrer Produkte Engineering Dienstleister. Dieser Beitrag verrät Ihnen, auf was Sie dabei achten sollten.

Den ganzen Beitrag lesen »