Die Norm IEC 62304 fordert die Verifikation von Software-Units, erklärt aber nicht genauer, was zu tun ist. Was bedeutet Software-Unit-Verifikation und wie könnten Akzeptanzkriterien erfüllt werden?
In Abschnitt 5.5.5 fordert die IEC 62304 für Medizintechniksoftware der Klassen B und C (siehe Kasten) kurz und knapp in einem einzigen Satz: „Der Hersteller soll Software-Unit-Verifikation durchführen und die Ergebnisse dokumentieren.“ Um diese Forderung erfüllen zu können, muss man die Norm durchforsten, um zunächst zwei Aspekte zu klären: Wie definiert die IEC 62304 eine Software-Unit und was versteht die Norm unter Verifikation?
Definition Software-Unit
In Abschnitt 3.25 der Norm wird eine Software-Unit als ein Software-Element („item“) definiert, das sich auf der untersten Ebene des Software-Systems befindet und das nicht weiter unterteilt wird (Abbildung 1). Wohlgemerkt sagt die Norm nicht, dass eine Software-Unit nicht weiter unterteilt werden kann. Dadurch wird ein Widerspruch vermieden, denn in der Notiz in Abschnitt 3.28 überlässt die Norm dem Hersteller die Definition der Granularität einer Software-Unit.
Die Begründung liefert Abschnitt B.3: Der Begriff wird absichtlich unbestimmt gehalten, damit die Norm für unterschiedlich große (Software-) Projekte und unterschiedliche Entwicklungsmethoden angewendet werden kann. Eine weitere Charakterisierung für eine Software-Unit nennt Abschnitt B.5.4: Software-Units können separat getestet werden. Insgesamt hat man also die Merkmale „nicht weiter unterteilt“ und „separat testbar“. Konkreter kann man werden, wenn man die verwendete Programmiersprache heranzieht: Die kleinste Software-Unit in der Programmiersprache C ist eine Funktion im Sinne von C, in den objektorientierten Programmiersprachen wie C++ oder Java kann man auch Methoden als Units betrachten.
Weil medizinische Software für eingebettete Systeme oftmals in der Programmiersprache C geschrieben wird, betrachten wir im Folgenden diese Programmiersprache.
Welche Units es gibt und welche Funktionalität sie haben sollen, wird für Software der Klassen B und C durch den ausführlichen Software-Entwurf („Software detailed design“, Abschnitt 5.4) festgelegt. Der Software-Entwurf ergibt die Software-Architektur. Eine gute Architektur ist durch schmale Schnittstellen zwischen den Units und eine vernünftige Größe der Units gekennzeichnet. Dabei kann eine Unit auch mehrere C-Funktionen umfassen.
Definition Verifikation
Die IEC 62304 definiert in Abschnitt 3.33 Verifikation als „Bestätigung durch Bereitstellung eines objektiven Nachweises, dass spezifizierte Anforderungen erfüllt wurden“. Diese Anforderungen werden beim Software-Entwurf spezifiziert, der laut Abschnitt 5.4.1 für Software der Klassen B und C durchgeführt und dokumentiert werden muss. Hierbei werden die Anforderungen an die Gesamt-Software auf die Units verteilt, was letztendlich die Beschreibung der Funktionalität einer Software-Unit ergibt.
Für Software der Klassen B und C muss der Entwurf so ausführlich sein, dass die korrekte Implementierung der Software-Unit möglich ist. Laut Abschnitt 5.4.3 muss für Software der Klasse C ein so ausführlicher Entwurf auch für die Schnittstellen dokumentiert werden. Insbesondere für Software der Klasse C sind somit die Anforderungen ausreichend detailliert dokumentiert, dass man nun beginnen kann, den Nachweis Ihrer Erfüllung bereit zu stellen.
Diese Bestätigung bzw. Verifikation der Software-Units wird laut Abschnitt 5.5.2 der IEC 62304 durch einen Prozess aus Strategien, Methoden und Prozeduren erbracht. Testen ist offensichtlich in diesen Methoden enthalten, da dazu für Software der Klassen B und C die Angemessenheit der Testprozeduren beurteilt werden müssen (ebenfalls laut Abschnitt 5.5.2).
Drei Beispiele für Akzeptanzkriterien für Software-Units der Software-Klassen B und C gibt der folgende Abschnitt 5.5.3 der IEC 62304 in der Notiz. Diese drei Beispiele werden im Folgenden diskutiert.
Akzeptanzkriterium Anforderungen
Implementiert der Software-Code Anforderungen inklusive der Risikokontrollmaßnahmen? Dies prüft man typischerweise durch geeignete Testfälle. Gibt es zu einer Anforderung mindestens einen Testfall, der sie prüft und ist dieser Testfall durchgeführt und bestanden, so implementiert der Code die Anforderung. Die Zuordnung von Anforderungen zu Testfällen ist eine manuelle/menschliche Tätigkeit, eine automatische Zuordnung ist im Allgemeinen nicht möglich. Hat man diese Zuordnung jedoch in einem geeigneten Werkzeug hergestellt, so kann man werkzeuggestützt ermitteln, ob alle Anforderungen Testfälle besitzen und ob diese bestanden sind.
Abbildung 2 zeigt eine Abdeckung der Anforderungen durch Testfälle im Werkzeug TESSY. TESSY ist ein Unit-Test-Werkzeug, das auch Anforderungen und ihre Beziehung zu Testfällen verwalten kann. Das Ziel ist ein vollständig grün ausgefüllter Kreis, der anzeigt, dass alle Anforderungen mit Testfällen assoziiert sind und dass alle diese Testfälle ausgeführt wurden und bestanden sind.
Akzeptanzkriterium Interface-Design
Ist der Software-Code ohne Widersprüche zum Interface-Design der Software-Unit? TESSY kann das Interface einer Software-Unit aus dem Software-Code ermitteln und sowohl im GUI als auch im Report für Menschen lesbar darstellen, aber auch in maschinenlesbarer Form (XML).
In Abbildung 3 ist die Struktur des Interfaces der Software-Unit func dargestellt. Es zeigt im Wesentlichen die Variablen und ihre Passierrichtung. Die Passierrichtung IN gibt an, dass die Variable von der Softwareeinheit lediglich gelesen wird. Infolgedessen muss vor dem Test ein Eingabewert für diese Variable angegeben werden. Die Passierrichtung OUT erfordert für einen ordnungsgemäßen Test einen erwarteten Wert, der dann nach dem Test mit dem tatsächlichen Wert verglichen wird.
Wenn die Schnittstellenbeschreibung als Ergebnis des detaillierten Entwurfs (Abschnitt 5.4.3) in maschinenlesbarer Form vorliegt, kann man möglicherweise den Vergleich der erwarteten Schnittstelle (aus dem Entwurf) mit der tatsächlichen Schnittstelle (aus dem Code) automatisieren, unter Verwendung des von TESSY erstellten maschinenlesbaren Formats (XML). Ohne einen automatisierten Vergleich ist ein Review erforderlich, was normalerweise einen hohen Aufwand bedeutet.
Akzeptanzkriterium Programmierverfahren und Codier-Standards
Ist der Software-Code konform zu Programmierverfahren und Codier-Standards? Abschnitt B.5.5 empfiehlt, Codier-Standards zu nutzen, um durchgehend die gewünschten Merkmale des Codes zu erreichen. Als Beispiele für Codier-Standards werden (a) Anforderungen für Verständlichkeit, (b) Regeln zur Benutzung der Programmiersprache oder Einschränkungen bei der Verwendung der Programmiersprache und (c) das Management der Komplexität genannt.
Regeln zur Benutzung der Programmiersprache ergeben einen (projekt-) einheitlichen Programmierstil, was die Wartbarkeit des Codes fördert. Solche Regeln zur Benutzung der Programmiersprache betreffen üblicherweise Dinge wie Namensgebung, Einrückungen, das Setzen von (geschweiften) Klammern und ähnliches. Mit dem BARR Embedded C Coding Standard gibt es hierfür einen frei verfügbaren Regelsatz. Diese Regeln können durch das statische Analysewerkzeug ECLAIR geprüft werden.
Eine Regel behandelt das Setzen der geschweiften Klammern (Abb. 4). Anhänger des „One True Brace Style“ oder 1TBS müssen jetzt tapfer sein, denn die BARR-Regel besagt, dass eine öffnende geschweifte Klammer alleine in einer Zeile stehen muss; die dazugehörige schließende geschweifte Klammer muss darunter ebenfalls in einer eigenen Zeile stehen, und zwar in der gleichen Spalte wie die Öffnende. Bei 1TBS steht die öffnende geschweifte Klammer am Ende der Zeile, beispielsweise nach der Entscheidung einer if-Anweisung. Das statische Analysewerkzeug ECLAIR prüft über 80% der BARR-Regeln.
Es gibt aber auch vorgefertigte Sätze von Codier-Regeln, die die Programmiersprache einschränken. Dadurch soll potenzielles Fehlverhalten von Software verhindert werden. Beispiele sind der CERT C Coding Standard oder die MISRA-Regeln, beides für die Programmiersprache C.
Als letztes Beispiel für Codier-Regeln nennt Abschnitt B.5.5 das Management der Komplexität. Zu diesem Zweck kann man sicherstellen, dass bestimmte Metriken bestimmte Werte nicht überschreiten.
Autor: Frank Büchner, Principal Engineer Software Quality, Hitex GmbH
