{"id":11771,"date":"2015-09-15T06:00:10","date_gmt":"2015-09-15T04:00:10","guid":{"rendered":"https:\/\/www.johner-institut.de\/blog\/?p=11771"},"modified":"2024-11-07T12:46:30","modified_gmt":"2024-11-07T11:46:30","slug":"software-einheiten-iec-62304","status":"publish","type":"post","link":"https:\/\/www.johner-institut.de\/blog\/iec-62304-medizinische-software\/software-einheiten-iec-62304\/","title":{"rendered":"Software-Einheit: spezifizieren und testen unter IEC 62304"},"content":{"rendered":"\n

Der Begriff der Software-Einheit (englisch: Software Unit) entstammt der IEC 62304.<\/p>\n\n\n\n

Vielen Herstellern unterlaufen beim Spezifizieren und Testen dieser Software-Einheiten Fehler. Diese Artikel gibt Ihnen Tipps, diese zu vermeiden.<\/div>\n\n\n\n\n\n\n\n

Definitionen<\/h2>\n\n\n\n

Definition Software-Einheit<\/h3>\n\n\n\n

Die IEC 62304<\/a> definiert eine Software-Einheit<\/strong> als „Software-Komponente, die nicht in weitere Komponenten unterteilt ist“<\/cite>.<\/p>\n\n\n\n

Definition Software-Komponente<\/h3>\n\n\n\n

Eine Software-Komponente<\/strong> definiert die Norm als „jedes identifizierbare Teil eines Computerprogramms“<\/cite>. Eine Software-Komponente bzw. eine Software-Einheit kann eine logische Komponente ebenso wie eine physikalische Komponente sein.<\/p>\n\n\n\n

Definition Software-System<\/h3>\n\n\n\n

Schlie\u00dflich ist ein Software-System eine \u201eintegrierte Sammlung von SOFTWARE-KOMPONENTEN, die so organisiert sind, dass eine spezifische Funktion oder ein Satz von Funktionen ausgef\u00fchrt werden kann\u201c<\/em><\/p>\n\n\n\n

Die Norm legt nicht fest, was Hersteller als Software-System festlegen: Sie k\u00f6nnen entweder die Gesamtheit aller Software eines Medizinprodukts als Software-System definieren oder alle Software in jedem Prozessor- bzw. Speicherbereich. D.h. ein Medizinprodukt kann mehrere Software-Systeme haben, n\u00e4mlich mindestens eines pro PESS (programmierbares elektronisches Sub-System)<\/a>.<\/p>\n\n\n\n

\n
<\/i> Weiterf\u00fchrende Informationen<\/div>\n

Wie Sie eine Architektur schnell und konform mit IEC 62304 und FDA entwerfen und dokumentieren beschreiben die Videotrainings im Auditgarant<\/a>, ebenso die regulatorischen Forderungen.<\/p>\n<\/div>\n\n\n\n

Logische Software-Einheiten<\/h3>\n\n\n\n

Es ist die Entscheidung des Herstellers, ab wann er Software-Komponenten nicht weiter zerlegt. D.h. die Software-Einheit muss z.B. bei eine objektorientierten Sprache keine Klasse sein. Ebenso w\u00e4re es m\u00f6glich, ein Package oder ein Assembly als Einheit zu definieren. Folglich identifizieren sie Komponenten in Komponenten- oder Klassendiagrammen.<\/p>\n\n\n\n

\n

Physische Software-Einheiten<\/h3>\n

Manche Herstellern, besonders solche, bei denen die Entwicklung einer expliziten Architektur nicht so selbstverst\u00e4ndlich ist, bezeichnen hingegen die identifizierbaren Teile der kompilierten Software als Softwar-Einheiten bzw. Komponenten, also *.exe, *.dll oder *.HEX-Dateien. Der dazu passende UML-Diagrammtyp w\u00e4re das Verteilungsdiagramm. Weil diese Hersteller aber glauben, Komponenten m\u00fcsse man mit einem Komponentendiagramm darstellen, \u201emissbrauchen\u201c Sie Komponentendiagramme, um Verteilungsaspekte zu beschreiben.<\/p>\n

Die IEC 62304<\/a> erlaubt beide Sichtweisen. Mit einer ausschlie\u00dflich \u201eretrospektiven Beschreibung\u201c von Software-Einheiten und Software-Komponenten ist sie aber sicher nicht einverstanden.<\/p>\n<\/div>\n\n\n\n

Granularit\u00e4t von Software-Einheiten<\/h3>\n\n\n\n

Ebenfalls ist es hilfreich zu verstehen, dass in verschiedenen Komponenten die Granularit\u00e4t unterschiedlich bestimmt werden kann. D.h. die Software-Einheiten k\u00f6nnen auf verschiedenen Ebenen einer schichtorientierten Architektur gefunden werden wie die folgende Abbildung zeigt, die die Software-Einheiten mit einem roten Rahmen markiert.
\"Software-Einheit,<\/a><\/p>\n\n\n\n

Alternative Darstellung<\/p>\n\n\n\n

\"Alternative<\/a><\/figure>\n\n\n\n

Wichtig ist die Feststellung, dass man eine Software-Einheit als Komponente definiert, die nicht weiter zerlegt ist<\/strong>, und nicht als Komponente, die nicht weiter zerlegt werden kann<\/strong>.<\/p>\n\n\n\n

Regulatorische Anforderungen<\/h2>\n\n\n\n

Software-Einheiten spezifizieren<\/h3>\n\n\n\n

Die IEC 62304 fordert zumindest bei Sicherheitsklasse C, das Software-System im Rahmen der Software-Architektur<\/a> bzw. des detaillierten Designs bis auf Einheiten zu zerlegen. D.h.<\/p>\n\n\n\n

    \n
  1. Sie m\u00fcssen die Software-Komponenten und Software-Einheiten identifizieren<\/strong> (benennen) z.B. mit Hilfe eines Komponentendiagramms. Dabei sollten Sie\u00a0im Komponentenbaum zumindest die zweite Bausteinebene spezifizieren. D.h. Ihre Software-Einheiten bilden auf der zweiten Ebene, die „Bl\u00e4tter“ des Komponentenbaums. Selbstverst\u00e4ndlich ist es empfehlenswert, auch tiefer zu spezifizieren, aber nicht notwendigerweise gefordert.<\/li>\n\n\n\n
  2. Sie m\u00fcssen die Schnittstellen<\/a> dieser Komponenten und Einheiten spezifizieren<\/strong>.\u00a0Dazu sollten Sie\u00a0beispielsweise die API dieser Schnittstellen beschreiben einschlie\u00dflich \u00dcber- und R\u00fcckgabetypen, dem Verhalten bei richtigen und falschen Parametern.<\/li>\n\n\n\n
  3. Ebenso m\u00fcssen Sie darlegen, welche Komponente bzw. Einheit welche Schnittstelle welcher anderen Software-Komponente bzw. Software-Einheit aufruft. Auch das l\u00e4sst sich im Komponentendiagramm darstellen.<\/li>\n<\/ol>\n\n\n\n

    Software-Einheiten verifizieren<\/h3>\n\n\n\n

    Die IEC 62304 verlangt, dass Sie Akzeptanzkriterien der Software-Einheiten ebenso festlegen, wie Strategien, Methoden und Verfahren zu deren Verifizierung. Die Norm schreibt aber ebenso wenig konkrete Strategien, Methoden und Verfahren vor wie die Auswahl m\u00f6glicher Akzeptanzkriterien. Sie nennt zumindest Beispiele wie Kodierrichtlinien<\/a> oder die \u00dcberpr\u00fcfung, ob der Code die Software-Anforderungen erf\u00fcllt.<\/p>\n\n\n\n

    Nur bei Klasse C nennt die Norm Akzeptanzkriterien wie die Ressourcenbelegung, die durch eine reine Analyse des Codes nicht mehr bewertbar sind, d.h. eine Ausf\u00fchrung des Codes z.B. im Rahmen von Unit-Tests erfordern.<\/p>\n\n\n\n

    Typische Fehler und Tipps, um diese zu vermeiden<\/h2>\n\n\n\n

    Die Unit-Tests testen nicht die Software-Units (Software-Einheiten)<\/h3>\n\n\n\n

    Software-Entwickler verstehen unter Unit-Tests meist Software-Tests, mit denen sie ihre Klassen, Methoden oder Funktionen testen. Dabei vers\u00e4umen sie es regelm\u00e4\u00dfig, die Software-Einheiten (Software-Units) zu testen, die in der Architektur spezifiziert wurden und sich oft viel h\u00f6her im Komponentenbaum befinden. Das f\u00fchrt in Audits regelm\u00e4\u00dfig zu problematischen Situationen.<\/p>\n\n\n\n

    Keine testbare Spezifikation der Anforderungen an eine Software-Einheit<\/h3>\n\n\n\n

    Die Aufgabe der Software-Architekten bzw. beim Komponentendesign besteht darin — wie oben beschrieben — die Schnittstellen der Software-Einheiten zu spezifizieren. Das unterbleibt h\u00e4ufig. Eine Darstellung der Software-Einheiten und deren Schnittstellen in einem Komponentendiagramm (z.B. mit der Lolipop-Notation) erf\u00fcllt nicht die Anforderung nach einer Spezifikation der Schnittstellen.<\/p>\n\n\n\n

    Unklare Anforderungen an die Verifizierung von Software-Einheiten<\/h3>\n\n\n\n

    Ein weiterer Fehler besteht darin, dass die Hersteller im Entwicklungsplan keine konkrete Anleitung geben, wie Software-Einheiten generell zu verifizieren sind. Beispiele k\u00f6nnten sein<\/p>\n\n\n\n