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.
„Detailliertes Design“: Begriffsdefinition
Definition nach ISO/IEC 24765
Die ISO/IEC 24765 („Systems and software engineering – Vocabulary“) definiert „Detailed design“ wie folgt:
- The process of refining and expanding the preliminary design of a system or component to the extent that the design is sufficiently complete to be implemented.
- The result of the process in (1).
Der Granularitätsgrad entscheidet
Detailliertes Design: in der Software-Entwicklung bedeutet es die Verfeinerung der Software-Architektur. Feinarchitektur ist somit ein Synonym zu detailliertem Design. Das detaillierte Design unterscheidet sich von der Grobarchitektur vor allem durch den Granularitätsgrad – nicht dadurch, dass etwa völlig andere Aspekte adressiert würden.
Wikipedia definiert Softwarearchitektur wie folgt: Eine Softwarearchitektur ist einer der Architekturtypen in der Informatik und beschreibt die grundlegenden Komponenten und deren Zusammenspiel innerhalb eines Softwaresystems.
Wenn man sich auf diese Definition einlässt, die sehr stark auf die statische Struktur der Software ausgerichtet ist, dann beschreibt die Grobarchitektur die ersten n Bausteinebenen, die Feinarchitektur d.h. das detaillierte Design die Bausteinebenen ab Ebene n+1. Welchen Wert n annimmt, entscheidet der Hersteller abhängig von der Größe und Komplexität des Softwaresystems.
Regulatorische Anforderungen an das detaillierte Design
Forderungen der IEC 62304 (Kapitel 5.4) an das detaillierte Design
IEC 62304:2006
Das Kapitel 5.4 der IEC 62304:2006 („Medical device software – Software life cycle processes“) ist etwas missverständlich, da nicht ganz konsistent. So heißt es dort:
„Der Hersteller muss ein detailliertes Design für jede Software-Einheit einer Software-Komponente entwickeln und dokumentieren. […]
Der Hersteller muss ein detailliertes Design für alle Schnittstellen zwischen der Software-Einheit und externen Komponenten (Hardware oder Software) sowie für alle Schnittstellen zwischen den einzelnen Software-Einheiten entwickeln.
Die Inkonsistenz: Da die Norm eine „Software-Einheit“ einerseits definiert als nicht weiter in Komponenten unterteilbare Software-Komponente, paßt dazu nicht, für Software-Einheiten andererseits ein detailliertes Design zu verlangen.
IEC 62304:2006 Amendment 1:2016
In der IEC 62304:2006 A1:2016 heißt es nun statt „the manufacturer shall refine the software architecture until it is represented by software units“ nun „the manufacturer shall subdivide the software until it is represented by software units“.
Die neue Version der Norm spricht also nicht mehr von verfeinern, sondern von zerlegen. Diese Konkretisierung lenkt den Fokus noch stärker auf die statische Struktur, was von vielen als eine etwas eingeschränkte Sicht auf eine Verfeinerung kritisiert wird. Denn mindestens ebenso wichtig ist die dynamische Betrachtungsweise, die Abläufe in ihrer zeitlichen Abfolge betrachtet.
Forderungen der FDA an das „Detailed Design“
Die FDA benutzt den Begriff nicht nur im Kontext von Software, sondern auch allgemein in der Produktentwicklung: In einem Guidance Document zu den Design Controls (21 CFR part 820.30) nennt die FDA explizit das „detailed design“ als mögliches Entwicklungsartefakt.
Dieser Artikel konzentriert sich jedoch auf das „software detailed design“. Die Anforderungen daran formuliert die FDA im
- „Software Validation Guidance Document“ und
- teilweise im „Guidance Document Content for the Premarket Submissions for Software Contained in Medical Devices„.
ad a) Software Validation Guidance
Der Software Validation Guidance schreibt:
„[…] the design specification may contain both a high level summary of the design and detailed design information. The completed software design specification constrains the programmer/coder to stay within the intent of the agreed upon requirements and design. A complete software design specification will relieve the programmer from the need to make ad hoc design decisions. […] Coding is the software activity where the detailed design specification is implemented as source code.“
Der FDA geht es also beim detailed design (einen Begriff, den sie zwar verwendet aber nicht definiert) darum, den Entwicklern so genaue Vorgaben zu geben, dass keine wesentlichen Freiheitsgrade bei der Implementierung bleiben.
Die FDA legt somit weder den Granularitätsgrad noch die Aspekte genau fest, die ein „detailed design“ zu adressieren hat. Allerdings wünscht sie ein Tracing von Unit-Tests zum detaillierten Design.
ad b) Premarket Submission Guidance
Das Guidance Document zur Premarket Submissions for Software Contained in Medical Devices unterscheidet nicht „Software Architecture“ und „Detailed Design“, sondern „Architecture Design Chart“ und „Software Design Specification“ (SDS).
Die FDA bleibt etwas vage, was die SDS betrifft:
„The information presented in the SDS should be sufficient to ensure that the work performed by the software engineers who created the Software Device was clear and unambiguous, with minimal ad hoc design decisions. The SDS may contain references to other documents, such as detailed software specifications.“
Vergleichbar zum anderen „Guidance Document“ soll so detailliert spezifiziert werden, dass keine ad-hoc Entscheidungen der Entwickler notwendig sind. Wie diese Vorgaben zu formulieren sind, überlässt die FDA den Herstellern.
Tipps zum detaillierten Design
1. Über Schnittstellen spezifizieren
Da eine Software-Einheit eine Komponente ist, die man nicht weiter unterteilt, d.h. eine Komponente, deren Innenleben man gerade nicht kennt, können Sie diese Einheit nur über deren äußere Schnittstellen definieren. (Innere Schnittstellen kann es keine geben, sonst wäre es keine Einheit im Sinne der Definition der IEC 62304.) Dieses Verhalten über die äußeren Schnittstellen besteht zum einen aus der Reaktion der Komponente auf Aktionen über eben diese äußeren Schnittstellen, zum anderen aus Verhalten der Komponente an den Schnittstellen, das von innen getriggert ist. Gehen wir auf diese Punkte ein.
a) Mögliche Aktionen über die Schnittstellen einer Software-Komponente
Eine Aktion über eine äußere Schnittstelle kann sein:
- der Aufruf einer Methode,
- das Anlegen eines analogen oder digitalen Signals (bei sehr hardware-naher Programmierung),
- das Übergeben eines Kommandos über ein Bussystem,
- der Aufruf über eine Webservice-Schnittstelle,
- usw.
Achten Sie darauf, dass Sie (falls sinnvoll) alle Interoperabilitätsebenen adressieren. (Wie das geht, lernen Sie in den Videotrainings des Auditgarant).
Die Reaktionen der Komponente können nur über die gleichen Schnittstellen erfolgen.
Typischer Fehler, die Definition von Zustandsautomaten: Seien Sie sehr vorsichtig damit, die Software-Komponente als Zustandsautomat zu beschreiben. Ein Zustand ist eine innere Eigenschaft der Komponente. Sie können allerdings einen Zustand als eine Klammer von nach außen, d.h. über die Schnittstellen, sichtbaren Eigenschaften definieren. Verfallen Sie nur nicht der Gefahr, innere Zustände und äußeres Verhalten zu verwechseln.
b) Detailliertes Design: Von innen getriggertes, nach außen sichtbares Verhalten
Es gibt auch Situationen, bei denen das nach außen sichtbare Verhalten keine Reaktion der Software-Komponente auf Aktionen über deren äußere Schnittstellen darstellt. Beispielsweise könnte es sein, dass die Komponente zeitgesteuert oder beim Vorliegen von inneren Fehlern Signale nach außen sendet oder ein bestimmtes äußeres Verhalten zeigt.
Denken Sie allerdings zweimal nach, ob dieses Verhalten wirklich von der Komponente selbst getriggert wurde und keine Reaktion auf eine Aktion von außen ist. Ein Interrupt wäre beispielsweise ein Signal von außen.
2. Richtige Granularität wählen
Hersteller sollten die Granularität des detaillierten Designs richtig wählen, um Nachteile zu vermeiden:
Nachteile einer zu granularen Beschreibung
- Die Dokumentation ist aufwendig, kostet Zeit und Geld und frustriert die Entwickler
- Der Aufwand beim Pflegen der Dokumentation ist hoch, die Wahrscheinlichkeit steigt, dass „Modell“ und Code nicht mehr synchron sind, was wiederum zu Problemen im Audit führen kann.
Nachteile einer zu grob-granularen Beschreibung
- Die regulatorischen Anforderungen sind nicht erfüllt, es droht Ärger beim Audit, der Zulassung, im schlimmsten Fall vor Gericht.
- Die Entwickler haben keine ausreichend präzisen Vorgaben, um die Anforderungen an die jeweiligen Komponenten so entwickeln zu können, dass die Anforderungen an das Gesamtsystem erfüllt sind und die Komponenten auch zueinander passen. Aufwendige Nachbesserungen und Projektverzug sind die Folge.
- Es gibt keine ausreichende Dokumentation, um
- Risiken abschätzen zu können (auch bei Änderungen an der Architektur),
- neue Entwickler einzuarbeiten und
- über Sicherheitsklassen und die Seggregation von Komponenten entscheiden zu können.
- Den Testern fehlen Vorgaben für das Ableiten von Testfällen.
Tipps zur richtigen Wahl der Granularität
- Bei rückwirkender Dokumentation zumindest die ersten beiden Bausteinebenen dokumentieren.
- Sonst so genau dokumentieren, bis ein „normaler“ Entwickler die Anforderungen an die jeweilige Komponente umsetzen kann ohne Entscheidungen treffen zu müssen, die für die weitere Entwicklung der Software entscheidend sind.
- Nur in Ausnahmefällen das System bis auf Klassenebene zerlegen.
Letztlich darf die Aufgabe, die der Entwickler umzusetzen hat, nur so groß sein, dass sie noch „in dessen Kopf passt“, ohne die Notwendigkeit eines „Pagings“ d.h. ohne dass er oder sie auf einem Blatt Papier beginnen muss, die Lösung zu konzipieren.
3. Präzsion und Granularität nicht verwechseln
Wie eben geschildert, sollte das detaillierte Design so granular sein, dass ein/e Entwickler/in es umsetzen kann, ohne wesentliche Entwurfsentscheidungen treffen zu müssen. Diese Verfeinerung hat zwei Dimensionen:
Dimension 1: Granularität
Die Software-Architektur beschreibt im Komponentenbaum die Ebenen 1 bis n. Das detaillierte Design beschreibt den Komponentenbaum ab der Ebene n+1. Die Aufteilung ist in gewisser Weise willkürlich. Meist wählt man jedoch für n eine kleine Zahl zwischen 0 und drei.
Dimension 2: Präzision
Komponenten — gleich auf welcher Ebene — spezifiziert man idealerweise über deren Schnittstellen. Eine unpräzise Spezifikation würde beispielsweise sagen, dass eine Komponente die Kontraindikationen von Medikamenten für einen gegebenen Patienten berechnen soll.
Eine präzise Spezifikation würde beispielsweise umfassen:
- Die Methodensignatur inklusive Übergabe- und Rückgabedatentypen
- Den Algorithmus (nicht dessen Software-technische Umsetzung!) anhand dessen die Kontraindikationen berechnet werden
- Das Verhalten der Methode bei unvollständigen oder fehlerhaften Übergabewerten
- Das Zeitverhalten
Tipp: Wie Sie von der Software-Architektur zum detaillierten Design kommen
Wir empfehlen Ihnen nicht, auf dem Weg von der Software-Architektur zum detaillierten Design gleichzeitig die Präzision und die Granularität zu erhöhen. Sie benötigen bereits auf der/den ersten Bausteinebene/n eine präzise (Schnittstellen-)Spezifikation der Komponenten. Andernfalls können Sie die Komponenten nicht unabhängig voneinander in ein detailliertes Design überführen.
4. Architektur richtig auf Dokumente aufteilen
Eine weitere häufig gestellte Frage betrifft die Aufteilung der Software-Architektur und des detaillierten Designs auf ein oder mehrere Dokumente. Es gibt keine allgemeingültige Antwort, aber Entscheidungshilfen:
- Wenn Sie die Entwicklung von Software-Komponenten outsourcen oder durch eine andere Abteilung realisieren möchten, dann teilen Sie die Software-Architektur und die detaillierten Designs auf verschiedene Dokumente auf.
- Wenn Sie ein kleineres bis mittleres Projekt haben, das von einer Organisationseinheit entwickelt wird, spricht das für ein Architekturdokument, das das detaillierte Design beinhaltet.
- Wenn Sie ein größeres Projekt planen oder/und die Dokumentation der Software-Architektur die 40-Seiten-Grenze deutlich zu übersteigen droht, sollten Sie das Dokument in eine Software-Architektur und in ein oder mehrere „Detailed Designs“ aufteilen.
Entscheidend ist auch die Frage, was Sie als Software-System definieren: Die Gesamtheit aller Software in Ihrem Produkt? Oder die Software innerhalb eines PESS bzw. eines Prozessor-/Speicherbereichs?
Unterstützung beim Entwurf und der Dokumentation des detaillierten Designs
Haben Sie noch Fragen dazu, wie Sie Ihre Software-Akte IEC 62304-konform erstellen können? Und zwar schnell, auditsicher und ohne QM-Overhead? Dann besuchen Sie das „Kompaktseminar ‚medizinische Software’“ oder melden Sie sich über unser MicroConsulting. Hier werden wir Ihnen alle Fragen persönlich und falls möglich kostenfrei beantworten.
Hallo Herr Prof. Johner,
ich denke, es hängt davon ab, wie man den Begriff „Komponente“ definiert. Wenn man eine Komponente als die Zusammenfassung von Daten+Aktivitäten (Ablaufdiagramme, Algorithmen etc.) versteht, dann kann die Aussage der 62304 durchaus Sinn machen.
Im Rahmen dieser Interpretation wäre dann das detaillierte Design genau die Sammlung statischer und dynamischer Aussagen über das Innenleben der Komponente. Gleichzeitig würde man sagen, dass eine Sinus-Funktion, Socket usw. keine Komponente im Sinne der obigen Aussage ist, sondern eher ein Primitive. Klar würde man kein detailiertes Design der Sinus-Funktion aus einer mathematischen OTS-Bibliothek machen.
Grüße,
Stefan Koch
Hallo Hr. Prof. Johner,
ich hätte da noch eine Frage zum „detaillieren Design“. Wenn ich Grafiken/Daten etc. an den Drucker schicke, ist das ein sehr komplexer Vorgang der da abläuft bis das Papier aus dem Drucker kommt. (Hab da selber schon was Low-Level gemacht…) Aus „high-Level“ Programmierersicht (C#, C++) sind das aber nur ein paar abstrakte Befehlszeilen. Wie soll man das detaillieren und vor allem sinnvoll testen(außer ein paar Seiten ausdrucken und schauen ob Farbe aufm Papier ist)? Oder sind Betriebssystem-Funktionen generell da außen vor?
Viele Grüße,
Dietmar Ferstl
Sehr geehrter Herr Ferstl,
besten Dank für die spannende Frage! Das Betriebssystem ist eine SOUP. Für SOUP nehmen Sie definitionsgemäß kein detailliertes Design vor.
D.h. Sie würden „nur“ die Anforderungen an Ihre SOUP beschreiben („soll ausdrucken können“) und die Erfüllung der Anforderungen verifizieren bzw. validieren.
Beste Grüße
Christian Johner
Vielen, vielen Dank für die schnelle Antwort !
Ich sehe da eine grundsätzliche Problematik. Nehmen wir an, man hätte einen Windows/Linux-PC der die reine Bedienung und Visualisierung von Daten realisiert. auf der anderen Seite einen PC der Ultra-Low-Level programmiert ist, also ohne Betriebssystem, ohne Programmiersprache und die Festplatte nicht einmal formatiert ist.
Dieses High-Performance-System erhält vom WIN-PC nur Anweisungen und liefert Daten.
Kann man jetzt einfach hergehen und nur die „Lalli“-Win-PC-Software für ein Audit einen Lebenszyklus samt Risiko-Analyse verpassen und den eigentlich kritischen PC zum SOUP erklären?
Würde doch das Audit stark „vereinfachen“, oder habe ich da was übersehen? 🙂
schönen Gruß,
Dietmar Ferstl
Wenn der „High-Performance-PC“ kein Medizinprodukt sein sollte — was zu hinterfragen wäre — und auch kein Teil des Medizinprodukts, dann ist seine Software nicht einmal eine SOUP. Dann wird einem wahrscheinlich in der Risikoanalyse für das MP der Daten-Input vom High-Performance-PC um die Ohren fliegen, weil man darüber keine Aussage treffen kann.
Das Kapseln von Altlasten oder kritischen Komponenten in eine SOUP ist daher nicht der Königsweg.
Hallo Hr. Prof. Johner,
Ist SOUP nicht per Definition eine „Software Unit“, da sie nicht weiter zerteilt werden kann?
Und sollte daher anhand von „Software Unit Acceptance Criteria“ verifiziert werden?
Lieben Gruß,
Maximilian Steindl
Sehr geehrter Herr Steindl,
danke für die beiden wichtigen Fragen! Ich antworte direkt und in der gleichen Reihenfolge.
Hilft das? Falls nicht, gerne nachhaken.
Viele Grüße
Christian Johner
Danke für die schnelle Antwort!
Hmm… Ich bin davon ausgegangen, dass der Standard es offen lässt und es manchmal als „Software Item“ gesehen wird, und aber öfters als „Software Unit“. Weil ja auch eine „Software Unit“ ein „Software Item“ ist. Zusätzlich steht auch als „Note“ bei der „Software Unit“:
„SOFTWARE UNITS can be used for the purpose of software configuration management or testing.“ Was ja auch zutreffend wäre auf SOUP. Zusammengefasst würde ich SOUP als „Software Unit“ intuitiver finden, aber nun gut 🙂
Wenn nun SOUP ein „Software Item“ ist, bedeutet das, dass es im Prozess „Software integration and integration testing“ getestet werden muss?
Hier fällt es mir schwer eine Grenze zu ziehen zwischen SOUP und eigens entwickelter „Software Items“, wie trenne ich diese Software Items so, dass ich SOUP einzeln testen kann? Oder reicht es zu sagen, ich habe das „Software Item“ in dem auch SOUP verwendet wird getestet und validiert?
In dem obige Beispiel mit dem Drucker aufzugreifen: Reicht es die Klasse die mir die Seite ausdruckt zu testen, und damit auch indirekt mit SOUP zutesten, oder wäre es entsprechend des Standards korrekt, die einzelnen verwendeten Befehle der SOUP direkt zu testen?
Lieben Gruß,
Maximilian Steindl
Sehr geehrter Herr Steidl,
es ist wie Sie vermuten: Eine SOUP muss (abhängig von der Sicherheitsklasse) den Anforderungen an die Integrationsprüfungen genügen.
Bezüglich der Akzeptanzkriterien bzw. des Testens von SOUPs:
Nochmals besten Dank!
Viele Grüße
Christian Johner