Kategorien: Software & IEC 62304

4 Kommentare

  1. Bettina Zucker | Mittwoch, 5. Mai 2021 um 10:22 Uhr - Antworten

    Kleiner Korrekturhinweis: Am Ende von 2. wird das letzte Kapitel der Norm als Kapitel 20 statt Kapitel 10 genannt.


    • Prof. Dr. Christian Johner | Mittwoch, 5. Mai 2021 um 10:29 Uhr - Antworten

      Danke, liebe Frau Zucker, für Ihre Adleraugen!
      Sie haben ja so Recht! Ich habe das sofort korrigiert.
      Nochmals vielen Dank!
      Beste Grüße, Christian Johner


  2. Andre Meyer | Donnerstag, 6. Mai 2021 um 09:15 Uhr - Antworten

    Besten Dank, Herr Johner für die wertvolle Übersicht und Einschätzung.

    Eine Folgefrage habe ich noch: Weshalb aus software engineering Sicht es Sinn macht, nicht zwischen der MD-Software (Inference-Teil) und dem Data-Processing Teil zu unterscheiden?

    Ist es in der Praxis nicht oft so, dass dies auch unterschiedliche Software-Projekte sind, die demnach auch unterschiedlich getestet werden? Wir haben zum Beispiel dafür unterschiedliche Software-Projekte, Continuous Integration Pipelines (für automatisierte Unit/Integration Tests, Coverage, etc.) und teilweise sogar andere Programmiersprachen (zB. Python um die Modelle zu bauen, und TypeScript/JavaScript für das SaMD, welches die Modelle konsumiert (mit einer Python-Schnittstelle).

    Besten Dank!


    • Prof. Dr. Christian Johner | Donnerstag, 6. Mai 2021 um 16:49 Uhr - Antworten

      Sehr geehrter Herr Meyer,

      danke für Ihre wichtige Frage!

      Mir ging es um die regulatorische Betrachtung der Software. Hier ist es einfach wie es ist: Die IEC 62304 ist nur für Software anwendbar, die Teil des Produkts ist. Das Kapitel 4.1.6 der ISO 13485 wendet sich hingegen an computerisierte Systeme.

      Ihr Einwand ist absolut zutreffend: Eine gute Software-Entwicklung ist eine gute Software-Entwicklung, unabhängig davon, ob die Software Teil des Produkts wird oder nicht. Auch teile ich Ihre Einschätzung, dass einige Best-Practices wie z.B. das Tooling oder gewisse Metriken und Kodierrichtlinien eher von der Programmiersprache abhängen und entsprechend berücksichtigt werden sollten.

      Daher sehe ich keinen Dissens. Es gibt nur zwei Betrachtungwinkel: Den regulatorischen Blick und den Blick eines professionellen Software-Engineerings.

      Viele Grüße, Christian Johner


Hinterlassen Sie einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.