MST013 – Regulatory: Prozesse IEC 62304

avatar Philipp Spenden per Paypal Icon Amazon Wunschliste Icon Spenden per Liberapay Icon
avatar Fabian

Rückblick

  • Prozess: Satz von in Wechselbeziehung oder Wechselwirkung stehenden Aktivitäten, der Eingaben in Ergebnisse umwandelt
  • Aktivität: Satz von einer oder mehreren aufeinander bezogenen oder sich gegenseitig beeinflussenden Aufgaben
  • Aufgabe: eine Teilarbeit, die erledigt werden muss

Prozesse der IEC 62304

  1. Software Entwicklungsprozess
  2. Software Wartungsprozess
  3. Software Risikomangement Prozess
  4. Software Problemlösungsprozess
  5. Software Konfigurationsmanagement Prozess

Software Entwicklungsprozess – Planung

Erste Teilaktivität des Software Entwicklungsprozesses

Planung – Allgemein

Aktivität: Planung der Softwareentwicklung

Output: Software Entwicklungsplan

  1. Rollen und Verantwortlichkeiten
  2. Software Entwicklungsmodell
    • Projektphasen
      • Outputs in den Phasen
      • Review-Kriterien der Outputs
  3. Verweis auf weitere Prozesse der IEC 62304
  4. Software Entwicklungsprozess im Projekt
    • Allgemein
      • Tooling
        • Compiler, Interpreter, Entwicklungsumgebung, Versionskontrollsystem…
      • Coding Guidelines
  5. Planung der Software Anforderungen
  6. Planung der Software Architektur und des Detail Design
  7. Planung der Implementierung
  8. Planung der Software Unit Verifikation
  9. Planung der Software Integration
  10. Planung der Software System Verifikation
  11. Planung des Software Release

Planung – Softwareanforderungen

  1. Wo werden die Softwareanforderungen erfasst?
    • Word, Excel, IBM Doors, Redmine, Polarion, OpenProject, CodeBeamer, HelixALM, JIRA, Greenlight guru GO, …
  2. Evtl. Satzschablonen verwenden
    • Use Cases oder “Requirement-Schablone” (shall, should, may)
  3. Sicherstellen der Traceability
    • von den Systemanforderungen zur Architektur und Verifikation
  4. Festlegen des zu unterstützendes Betriebssystems
  5. Festlegen der zu unterstützende Hardware
  6. Sicherstellen der Verifizierbarkeit
  7. Sicherstellen, dass die Softwareanforderungen widerspruchsfrei und vollständig sind
    • Review und Freigabeprozess
  8. Granularitär / Detailierungsgrad der Anforderungen festlegen
  9. Wertebereiche, Datentypen und Reaktionen des Systems (auch bei Fehleingaben)
  10. Schnittstellen zu anderen Systemen
    • Reaktionszeiten
    • Interoperabilität
    • Datenvolumen und Last auf dem System

Planung – Architektur und Detailliertes Design

  1. Wo wird die Software Architektur erfasst?
  2. Definition Software-System, -Item und -Unit
  3. Beschreiben was für Software Item und Units dokumentiert werden muss
    • Static View
    • Dynamic View
    • Interfaces

Planung – Implementierung

  1. Commit Workflows
  2. Anwendung der Tools

Planung – Software Unit Verifikation

  1. Planung der Verifikation der Schnittstellen von Software-Unit
    • Statische Code-Analyse
    • Code Reviews
    • Dynamische Analyse
  2. Beschreiben in welchem System die Software Units verifiziert wird
  3. Akzeptanzkriterien festlegen (beim Verhalten der Schnittstellen)
  4. Testabdeckung festlegen

Planung – Software Integration

  1. Integration Strategy (Top-down, bottom-up, …)
  2. Beschreiben in welchem System die Integration und Integrationstest durchgeführt wird
  3. Festlegen was in den Testplan und -Bericht kommt
  4. Akzeptanzkriterien festlegen
    • Zuverlässigkeit und Robustheit
    • Performance
    • Kompatibilität und Wartbarkeit
  5. Festlegen wie Anomalien in den Problemlösungs-Prozess einfließen

Planung – Software System Verifikation

  1. Beschreiben in welchem System die Software System Verifikation durchgeführt wird
  2. Sicherstellen, dass alle Software-Anforderungen verifiziert werden
  3. Festlegen was in den Testplan und -Bericht kommt
  4. Akzeptanzkriterien festlegen
  5. Festlegen wie Anomalien in den Problemlösungs-Prozess einfließen

Planung – Software Release

  1. Beschreiben in welchem System das Software Release durchgeführt wird
  2. Festlegen wo die Software-Releases abgelegt werden
  3. Festlegen wo offenen Anomalien und Bugs dokumentiert und bewertet werden
  4. Schema der Software-Versionsnummern festlegen
  5. Sicherstellen, dass alle zuvor genannten Aktivitäten durchgeführt wurden
    • Mittels Checkliste durch die technische Dokumentation gehen und Review durchführen

Allgemeine Software Entwicklungsmodelle

Vorgehensmodelle

  • Es gibt keine Vorgabe in der Norm IEC 62304
  • Forderung: Betrachtung der Abhängigkeiten zwischen den Aktivitäten
    • Erst die Anforderungen und die Software Archtektur abschließen, dann die Risikoanalyse abschließen.
  • Mehrere Vorgehensmodell sind denkbar.
  • Die IEC 62304 zählt u.a Wasserfallmodell, iterativ-inkrementell, evolutionär etc. auf.
  • Entwicklungsmodelle können textuell oder als Flowchart beschrieben werden.

Wasserfallmodell

  • Alle Entwicklungsschritte des Wasserfallmodells werden nacheinander durchgeführt.
  • Phasenbasiert, erst eine Phase abschließen, dann Beginn der nächsten Phase
  • Review der Ergebnisse zwischen den Phasen
  • Vorteile
    • Einfach.
    • Phasenabschlüsse geben Sicherheit über den Projektfortschritt.
    • Klare Abschätzung von Kosten und Umfang bei stabilen Anforderungen.
  • Nachteile
    • Fehler werden meistens erst spät entdeckt.
    • Wiederholung von Phasen im Fehlerfall.
    • Unflexibel gegenüber Änderungen im Projekt.

V-Modell

  • Weiterentwicklung des Wasserfallmodells
    • Jetzt: Jede Phase hat eine gegenüberliegende Testphase
  • Vorteile
    • Testaspekte können früher betrachtet werden.
    • Fehler in der Spezifikation oder im Design können früher gefunden werden.
    • Durch Berücksichtigung von Testaspekten ist die Dokumentation besser.
  • Nachteile
    • Implementierungsfehler werden erst beim Testen entdeckt, meistens sehr spät.
    • Auch hier: Im Fehlerfall müssen Phasen wiederholt werden, was sehr zeitaufwändig ist.

Iterativ-inkrementelle Modelle

  • Iterativ: Einzelne Phasen werden direkt durchlaufen
  • Inkrementell: Pro Durchlauf wird der Funktionsumfang erweitert
  • Fehler, die am Ende jedes Phasendurchlaufs entdeckt werden, werden im nächsten Durchlauf behoben.

Agiles Entwicklungsmodell

  • Die Basis agiler Softwareentwicklung ist das iterativ-inkrementelle Modell.
  • Ziel ist es, bürokratische Strukturen abzubauen und den Fokus auf die kundennahe Entwicklung zu richten.
  • Weitverbreitet ist dabei Scrum.
  • Mit der IEC 62304 ist dieses Modell zwar vereinbar, wird allerdings noch etwas zögerlich eingesetzt, da die Norm sehr V-Modell-artig aufgebaut ist. Viele schrecken vor der Kombination aus agiler Welt und V-Modell-Welt noch zurück.

Quellen

SW Entwicklungsplanung:

  • IEC 62304:2015

SW Entwicklungsmodelle:

2 Kommentare

  1. Vielen Dank für die tolle Zusammenfassung.

    Erinnert mich stark an meine Studienzeit zurück (Med. Ing.). Allerdings würde ich mir noch eine Episode mit einem Schwerpunkt auf die Rechtliche Aspekte wünschen: Urheberrecht, Standards, Haftung, Lizenzen (am besten mit Fachanwalt als Gast)

    Und eine Episode mit Fokus auf die (realistische) Aufwandsabschätzung. Denn bei aller Liebe zur Dokumentation muss am Ende des Tages auch mal richtig gearbeitet werden. Entwickler lieben nichts mehr, als wenn sie durch’s Management ständig blockiert werden.

    Und zu guter Letzt: Was würdet Ihr Gründungs-/StartUp-Interessierten mit auf dem Weg geben? Wie kann man sich seinen Weg in diesen Markt bahnen ohne zig Jahre in allen möglichen Abteilungen von Großunternehmen gearbeitet zu haben?

    • Hallo Markus,

      vielen Dank für Dein Feedback. Bei rechtlichen Aspekten kann ich Dir den Podcast Rechtsbelehrung (https://rechtsbelehrung.com) empfehlen. Die kennen sich beim Thema Urheberrecht und Haftung deutlich besser aus. Wir haben schon alle Hände voll zu tun, “nur” die Aspekte der Medizintechnik zu beleuchten.
      Zum Thema Aufwand der Dokumentation. Da kann ich aus eigener Erfahrung sprechen… Hier müssen keine riesigen Aufwände erzeugt werden. Das Erstellen der Dokumentation macht am meisten Sinn, wenn es in die Arbeit mit eingebunden wird (z.B. in die DOD bei Scrum) oder in Regelterminen. Ich habe oft genug gesehen, dass bei nur Projektbeginn (bei den Anforderungen) und bei Projektabschluss die Dokumentationsaufwände dokumentiert werden soll. Diese Projekte konnten alle nicht in der geplanten Zeit und nicht mit den geplanten Kosten realisiert werden. Das Johner-Institut hat hierzu ein eine gute Praxiserfahrung zusammen geschrieben. Ich bin mir sicher, da die ein oder andere Frage von Dir beantwortet wird: https://www.johner-institut.de/blog/iec-62304-medizinische-software/agile-softwareentwicklung-fuer-medizinprodukte/

      Vielleicht findet sich ja mal eine Gelegenheit, bei der wir uns persönlich austauschen können. Wo bist Du denn anzutreffen?

      Liebe Grüße,
      Philipp

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.