Kategorien: Auf was Sie bei der Systementwicklung von Medizinprodukten achten müssen, Beliebteste Beiträge, Software & IEC 62304, Usability & IEC 62366-1
Tags: , , ,

4 Kommentare

  1. Joachim Schneider | Donnerstag, 14. März 2019 um 10:57 Uhr - Antworten

    Hallo Herr Prof. Dr. Johner,

    vielen Dank für den für mich sehr informativen und gelungenen Artikel. Ich bin durch eine Google-Recherche darauf gestoßen um für mich die Frage zu klären, ob agile Entwicklungsprozesse auch bei reiner Hardwareentwicklung zum Einsatz kommen. Agil habe ich bislang immer nur in Verbindung mit Softwareentwicklung wargenommen. Aufgrund höheren Aufwandes bei Verifizierung und Validierung gegenüber Software habe ich diesbezüglich Zweifel bzw. kann mir die entsprechende Dokumentation als recht aufwändig vorstellen. Wie ist Ihre Einschätzung dazu und haben Sie ggf. Literaturtips?

    Vielen Dank und viele Grüße,
    Joachim Schneider


    • Prof. Dr. Christian Johner | Donnerstag, 14. März 2019 um 16:24 Uhr - Antworten

      Sehr geehrter Herr Schneider,

      danke für Ihre Frage!

      Ich halte die agile Entwicklung bei der Hardware ebenfalls für möglich und sogar wünschenswert. Kurze Iterationen, bei denen man in cross-funktionalen Teams Dinge ausprobiert, die sich nicht a priori abschätzen lassen (z.B. Laufzeitverhalten) können die Entwicklung beschleunigen. Im Gegensatz zur Software entstehen dabei aber (mehr) Prototypen und oft weniger „potentially shippable increments“. Daher verifiziert man nur den Aspekt, den man in der jeweiligen Iteration ausprobieren will.

      Im Gegensatz zur Software sehe ich sogar weniger Dokumentationsprobleme: Es käme niemand auf die Idee ohne Dokumentation eine Elektronik zu entwerfen oder etwas zu Fräsen. Platinenlayouts, CAD-Zeichnungen entstehen bei den „Hardwerkern“ zwangsläufig. D.h. hier überlegt man immer erst, was man tut, bevor man es tut. Manche „Softwarker“ entwickeln leider direkt darauf los.

      An einem Buch zur IEC 60601-1 und dem Vorgehen arbeiten wir gerade, es wird in den nächsten Wochen fertig.

      Viele Grüße, Christian Johner


  2. Ralf Müller | Mittwoch, 8. Juni 2022 um 09:44 Uhr - Antworten

    Guten Tag Herr Johner,

    Vielen Dank für die wertvollen Ressourcen. Ich habe versucht eine Antwort zu finden auf Ihre Homepage, aber keine gefunden.
    Wo fallen den prototypes/PoC (proof-of-concept) rein wenn man schnell was bauen will in einer Sandbox environment um dies für discovery/user research zu nutzen? Schon im Design Control oder ausserhalb und dann von Neuem anfangen.

    Danke


    • Prof. Dr. Christian Johner | Mittwoch, 8. Juni 2022 um 09:49 Uhr - Antworten

      Sehr geehrter Herr Müller,

      das ist eine sehr gute Frage! Es gibt keine generelle Antwort. Es wäre beides Möglich:

      1. PoC im Design Control: Wenn Sie sagen, dass Sie damit Anforderungen der Stakeholder erheben oder es gar als Teil der formativen Evaluation betrachten, dann unterliegen Sie klar den Anforderungen an das Design Control
      2. PoC außerhalb Design Control: Wenn Sie sagen, dass Sie rausfinden wollen, ob Dinge überhaupt möglich sind und ob es überhaupt Sinn ergibt, ein Entwicklungsprojekt zu starten, bzw. wenn Sie es als Forschung deklarieren, dann sind sie außerhalb dieser Anforderungen. Allerdings dürfen Sie dann die Ergebnisse nicht mehr in der weiteren Produktentwicklung verwenden.

      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.