Der Begriff der Software-Einheit (englisch: Software Unit) entstammt der IEC 62304.
Definitionen
Definition Software-Einheit
Die IEC 62304 definiert eine Software-Einheit als „Software-Komponente, die nicht in weitere Komponenten unterteilt ist“.
Definition Software-Komponente
Eine Software-Komponente definiert die Norm als „jedes identifizierbare Teil eines Computerprogramms“. Eine Software-Komponente bzw. eine Software-Einheit kann eine logische Komponente ebenso wie eine physikalische Komponente sein.
Definition Software-System
Schließlich ist ein Software-System eine „integrierte Sammlung von SOFTWARE-KOMPONENTEN, die so organisiert sind, dass eine spezifische Funktion oder ein Satz von Funktionen ausgeführt werden kann“
Die Norm legt nicht fest, was Hersteller als Software-System festlegen: Sie können 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ämlich mindestens eines pro PESS (programmierbares elektronisches Sub-System).
Wie Sie eine Architektur schnell und konform mit IEC 62304 und FDA entwerfen und dokumentieren beschreiben die Videotrainings im Auditgarant, ebenso die regulatorischen Forderungen.
Logische Software-Einheiten
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äre es möglich, ein Package oder ein Assembly als Einheit zu definieren. Folglich identifizieren sie Komponenten in Komponenten- oder Klassendiagrammen.
Physische Software-Einheiten
Manche Herstellern, besonders solche, bei denen die Entwicklung einer expliziten Architektur nicht so selbstverständlich 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äre das Verteilungsdiagramm. Weil diese Hersteller aber glauben, Komponenten müsse man mit einem Komponentendiagramm darstellen, „missbrauchen“ Sie Komponentendiagramme, um Verteilungsaspekte zu beschreiben.
Die IEC 62304 erlaubt beide Sichtweisen. Mit einer ausschließlich „retrospektiven Beschreibung“ von Software-Einheiten und Software-Komponenten ist sie aber sicher nicht einverstanden.
Granularität von Software-Einheiten
Ebenfalls ist es hilfreich zu verstehen, dass in verschiedenen Komponenten die Granularität unterschiedlich bestimmt werden kann. D.h. die Software-Einheiten können auf verschiedenen Ebenen einer schichtorientierten Architektur gefunden werden wie die folgende Abbildung zeigt, die die Software-Einheiten mit einem roten Rahmen markiert.
Alternative Darstellung
Wichtig ist die Feststellung, dass man eine Software-Einheit als Komponente definiert, die nicht weiter zerlegt ist, und nicht als Komponente, die nicht weiter zerlegt werden kann.
Regulatorische Anforderungen
Software-Einheiten spezifizieren
Die IEC 62304 fordert zumindest bei Sicherheitsklasse C, das Software-System im Rahmen der Software-Architektur bzw. des detaillierten Designs bis auf Einheiten zu zerlegen. D.h.
- Sie müssen die Software-Komponenten und Software-Einheiten identifizieren (benennen) z.B. mit Hilfe eines Komponentendiagramms. Dabei sollten Sie im Komponentenbaum zumindest die zweite Bausteinebene spezifizieren. D.h. Ihre Software-Einheiten bilden auf der zweiten Ebene, die „Blätter“ des Komponentenbaums. Selbstverständlich ist es empfehlenswert, auch tiefer zu spezifizieren, aber nicht notwendigerweise gefordert.
- Sie müssen die Schnittstellen dieser Komponenten und Einheiten spezifizieren. Dazu sollten Sie beispielsweise die API dieser Schnittstellen beschreiben einschließlich Über- und Rückgabetypen, dem Verhalten bei richtigen und falschen Parametern.
- Ebenso müssen Sie darlegen, welche Komponente bzw. Einheit welche Schnittstelle welcher anderen Software-Komponente bzw. Software-Einheit aufruft. Auch das lässt sich im Komponentendiagramm darstellen.
Software-Einheiten verifizieren
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öglicher Akzeptanzkriterien. Sie nennt zumindest Beispiele wie Kodierrichtlinien oder die Überprüfung, ob der Code die Software-Anforderungen erfüllt.
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ührung des Codes z.B. im Rahmen von Unit-Tests erfordern.
Typische Fehler und Tipps, um diese zu vermeiden
Die Unit-Tests testen nicht die Software-Units (Software-Einheiten)
Software-Entwickler verstehen unter Unit-Tests meist Software-Tests, mit denen sie ihre Klassen, Methoden oder Funktionen testen. Dabei versäumen sie es regelmäßig, die Software-Einheiten (Software-Units) zu testen, die in der Architektur spezifiziert wurden und sich oft viel höher im Komponentenbaum befinden. Das führt in Audits regelmäßig zu problematischen Situationen.
Keine testbare Spezifikation der Anforderungen an eine Software-Einheit
Die Aufgabe der Software-Architekten bzw. beim Komponentendesign besteht darin — wie oben beschrieben — die Schnittstellen der Software-Einheiten zu spezifizieren. Das unterbleibt häufig. Eine Darstellung der Software-Einheiten und deren Schnittstellen in einem Komponentendiagramm (z.B. mit der Lolipop-Notation) erfüllt nicht die Anforderung nach einer Spezifikation der Schnittstellen.
Unklare Anforderungen an die Verifizierung von Software-Einheiten
Ein weiterer Fehler besteht darin, dass die Hersteller im Entwicklungsplan keine konkrete Anleitung geben, wie Software-Einheiten generell zu verifizieren sind. Beispiele könnten sein
- Jeder Code muss einem Code-Review unterzogen werden.
- Jeder Code muss einer (automatisierten) statischen Code-Analyse unterzogen werden, die z.B. Metriken, Kodierrichtlinien, Formatierung usw. prüft.
- Alle öffentlichen Funktionen/Methoden aller Einheiten müssen getestet werden. Ein Maß für die Vollständigkeit dieser Tests könnte sein:
- % der Funktionen (sollte 100% sein)
- Code Coverage (Zweig- oder Anweisungsabdeckung)
- % der an die Softwareeinheit gestellten Anforderungen, die getestet werden (sollte 100% sein)
- Anwendung von (Blackbox-)Testverfahren z.B. wurde fehler-, grenzwert-, äquivalenzklassen, zustands- und entscheidungstabellenbasiert getestet?
- % der getesteten Funktionen, die sicherheitskritisch sind, wobei Sie das nicht(!) alleine bei der Einheit, sondern nur im Gesamtkontext der Software-Architektur und Risikoanalyse beurteilen können.
FAQ zu Software-Einheiten
Was mache ich, wenn die Spezifikation der Software-Einheiten zu aufwendig wird?
Wenn Sie zu viel Aufwand bei der Spezifikation Ihrer Einheiten und deren Schnittstellen haben, kann das mehrere Ursachen haben:
- Sie haben zu viele Funktionen/Methoden pro Schnittstelle. In diesem Fall ist nicht der Aufwand Ihr Problem, sondern Ihre Architektur. Die Architektur ist suboptimal, weil Sie eine (zu) breite Schnittstelle haben und damit gegen das fundamentale Paradigma guter Architekturen „Weak Coupling — Strong Cohesion“ verstoßen.
- Sie haben Ihren Komponentenbaum zu granular zerlegt. Zerlegen Sie Ihre Software mindestens auf den ersten beiden Bausteinebenen und dann ggf. tiefer bis ein Entwickler die dann identifizierte Software-Einheit ohne nennenswerte ad-hoc Design-Entscheidungen entwickeln kann.
- Sie glauben nur, dass es zu viel Aufwand sei. Der wesentliche Teil der Wertschöpfung bei der Software-Entwicklung findet im Rahmen der Software-Architektur statt, nicht mehr (nur) beim Kodieren. Daher ist es gut und richtig, wenn Sie sich viele Gedanken in dieser Phase machen und nicht später die Software aufwendig „refactoren“ müssen.
