{"id":8575,"date":"2016-07-26T10:00:00","date_gmt":"2016-07-26T08:00:00","guid":{"rendered":"http:\/\/www.johner-institut.de\/blog\/?p=8575"},"modified":"2024-05-24T11:15:16","modified_gmt":"2024-05-24T09:15:16","slug":"detailliertes-design-iec-62304-kapitel-5-4","status":"publish","type":"post","link":"https:\/\/www.johner-institut.de\/blog\/iec-62304-medizinische-software\/detailliertes-design-iec-62304-kapitel-5-4\/","title":{"rendered":"Detailliertes Design: FDA und IEC 62304 konform dokumentieren"},"content":{"rendered":"\n

Ein „detailliertes Design<\/strong>“ fordern sowohl die IEC 62304 als auch die FDA, jedoch ohne diesen Begriff pr\u00e4zise zu definieren. Lesen Sie hier, wie Sie die regulatorischen Anforderungen schnell und „auditsicher“ erf\u00fcllen k\u00f6nnen.<\/p>\n\n\n\n\n\n\n\n

„Detailliertes Design“: Begriffsdefinition<\/h2>\n\n\n\n

Definition nach ISO\/IEC 24765<\/h3>\n\n\n\n

Die ISO\/IEC 24765 („Systems and software engineering – Vocabulary“) definiert „Detailed design“ wie folgt:<\/p>\n\n\n\n

    \n
  1. 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.<\/cite><\/li>\n\n\n\n
  2. The result of the process in (1).<\/cite><\/li>\n<\/ol>\n\n\n\n

    Der Granularit\u00e4tsgrad entscheidet<\/h3>\n\n\n\n

    Detailliertes Design:  <\/strong>in der Software-Entwicklung bedeutet es die Verfeinerung der Software-Architektur. Feinarchitektur<\/strong> ist somit ein Synonym zu detailliertem Design. Das detaillierte Design unterscheidet sich von der Grobarchitektur vor allem durch den Granularit\u00e4tsgrad – nicht dadurch, dass etwa v\u00f6llig andere Aspekte adressiert w\u00fcrden.<\/p>\n\n\n\n

    Wikipedia definiert Softwarearchitektur<\/a> wie folgt: Eine Softwarearchitektur ist einer der Architekturtypen in der Informatik und beschreibt die grundlegenden Komponenten und deren Zusammenspiel innerhalb eines Softwaresystems.<\/cite><\/p>\n\n\n\n

    Wenn man sich auf diese Definition einl\u00e4sst, 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<\/strong> die Bausteinebenen ab Ebene n+1. Welchen Wert n annimmt, entscheidet der Hersteller abh\u00e4ngig von der Gr\u00f6\u00dfe und Komplexit\u00e4t des Softwaresystems.<\/p>\n\n\n\n

    \"Detailiertes<\/a>
    Die Zerlegung eines Systems bis ins detaillierte Design (in gr\u00fcn: Software-Einheiten) Zum Vergr\u00f6\u00dfern klicken<\/figcaption><\/figure>\n\n\n\n

    Regulatorische Anforderungen an das detaillierte Design<\/h2>\n\n\n\n

    Forderungen der IEC 62304 (Kapitel 5.4) an das detaillierte Design<\/h3>\n\n\n\n
    \"Detailliertes<\/figure>\n\n\n\n

    IEC 62304:2006<\/h4>\n\n\n\n

    Das Kapitel 5.4 der IEC 62304:2006 („Medical device software – Software life cycle processes“) ist etwas missverst\u00e4ndlich, da nicht ganz konsistent. So hei\u00dft es dort:<\/p>\n\n\n\n

    \n

    \u201eDer Hersteller muss ein detailliertes Design fu\u0308r jede Software-Einheit<\/a> einer Software-Komponente entwickeln und dokumentieren. […]
    <\/em>Der Hersteller muss ein detailliertes Design fu\u0308r alle Schnittstellen zwischen der Software-Einheit und externen Komponenten (Hardware oder Software) sowie fu\u0308r alle Schnittstellen zwischen den einzelnen Software-Einheiten entwickeln.<\/em><\/p>\n<\/blockquote>\n\n\n\n

    Die Inkonsistenz: Da die Norm eine „Software-Einheit“ einerseits definiert als nicht weiter in Komponenten unterteilbare Software-Komponente, pa\u00dft dazu nicht, f\u00fcr Software-Einheiten andererseits ein detailliertes Design zu verlangen.<\/p>\n\n\n\n

    IEC 62304:2006 Amendment 1:2016<\/h4>\n\n\n\n

    In der IEC 62304:2006 A1:2016 hei\u00dft 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“.<\/p>\n\n\n\n

    Die neue Version der Norm spricht also nicht mehr von verfeinern<\/em>, sondern von zerlegen<\/em>. Diese Konkretisierung lenkt den Fokus noch st\u00e4rker auf die statische Struktur, was von vielen als eine etwas eingeschr\u00e4nkte Sicht auf eine Verfeinerung kritisiert wird. Denn mindestens ebenso wichtig ist die dynamische Betrachtungsweise, die Abl\u00e4ufe in ihrer zeitlichen Abfolge betrachtet.<\/p>\n\n\n\n

    Forderungen der FDA an das „Detailed Design“<\/h3>\n\n\n\n

    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\u00f6gliches Entwicklungsartefakt.<\/p>\n\n\n\n

    Dieser Artikel konzentriert sich jedoch auf das „software detailed design“. Die Anforderungen daran formuliert die FDA im<\/p>\n\n\n\n

      \n
    1. „Software Validation Guidance Document<\/a>“ und<\/li>\n\n\n\n
    2. teilweise\u00a0im „Guidance Document Content for the Premarket Submissions for Software Contained in Medical Devices<\/a>„.<\/li>\n<\/ol>\n\n\n\n

      ad a) Software Validation Guidance<\/h4>\n\n\n\n

      Der Software Validation Guidance schreibt:<\/p>\n\n\n\n

      „[…] 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.“<\/cite><\/p>\n\n\n\n

      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.<\/p>\n\n\n\n

      Die FDA legt somit weder den Granularit\u00e4tsgrad noch die Aspekte genau fest, die ein „detailed design“ zu adressieren hat. Allerdings w\u00fcnscht sie ein Tracing von Unit-Tests zum detaillierten Design<\/strong>.<\/p>\n\n\n\n

      ad b) Premarket Submission Guidance<\/h4>\n\n\n\n

      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).<\/p>\n\n\n\n

      Die FDA bleibt etwas vage, was die SDS betrifft:<\/p>\n\n\n\n

      „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.“<\/cite><\/p>\n\n\n\n

      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, \u00fcberl\u00e4sst die FDA den Herstellern.<\/p>\n\n\n\n

      Tipps zum detaillierten Design<\/h2>\n\n\n\n

      1. \u00dcber Schnittstellen spezifizieren<\/h3>\n\n\n\n

      Da eine Software-Einheit eine Komponente ist, die man nicht weiter unterteilt, d.h. eine Komponente, deren Innenleben man gerade nicht<\/strong> kennt, k\u00f6nnen Sie diese Einheit nur \u00fcber deren \u00e4u\u00dfere Schnittstellen definieren. (Innere Schnittstellen kann es keine geben, sonst w\u00e4re es keine Einheit im Sinne der Definition der IEC 62304.) Dieses Verhalten \u00fcber die \u00e4u\u00dferen Schnittstellen besteht zum einen aus der Reaktion der Komponente auf Aktionen \u00fcber eben diese \u00e4u\u00dferen Schnittstellen, zum anderen aus Verhalten der Komponente an den Schnittstellen, das von innen getriggert ist. Gehen wir auf diese Punkte ein.<\/p>\n\n\n\n

      a) M\u00f6gliche Aktionen \u00fcber die Schnittstellen einer Software-Komponente<\/strong><\/h4>\n\n\n\n

      Eine Aktion \u00fcber eine \u00e4u\u00dfere Schnittstelle kann sein:<\/p>\n\n\n\n