Prof. Dr. Christian Johner

Autor: Prof. Dr. Christian Johner

Inhaber der Johner Institut GmbH

Scrum (agiles Projektmanagement) am Beispiel der Entwicklung medizinischer Software

Freitag 15. Mai 2015

Scrum ist eher ein Rahmen (Framework) für das agile Projektmanagement als ein Vorgehensmodell im Sinne eines Prozessmodells. Bereits deshalb kann ein Vorgehen nach Scrum durchaus konform mit den regulatorischen Anforderungen an die Entwicklung von Medizinprodukten (insbesondere Software) und der IEC 62304 sein.

Dieser Beitrag hat nicht zum Ziel, Scrum zu beschreiben (das ist an anderer Stelle z.B. Wikipedia bereits erfolgt). Vielmehr möchte er diskutieren, welche Voraussetzungen erfüllt sein müssen und typische Gefahren vermieden werden sollten.

Wie Scrum in der Entwicklung medizinischer Software häufig eingesetzt wird

Scrum in de Medizintechnik

Scrum auch in der Medizintechnik? (Bildquelle: Wikipedia)

Viele Medizinproduktehersteller, besonders die, bei denen die Software einen zentralen Anteil an der Entwicklung des Produkt hat, arbeiten gemäß Scrum — oder behaupten dies zumindest.

  • Mit einem ALM-Werkzeug wie JIRA, MedPack oder einem Bugtracker wie Mantis sammeln die Hersteller Wünsche und Bugs in Form von „Tickets“.
  • Eine Person (Entwickler, Produktmanager), meist als Product Owner bezeichnet, oder ein Gremium des Herstellers entscheidet dann, welches Ticket berücksichtigt wird und in welches Release es einfließt. Die Liste dieser Tickets entspricht dann dem Sprint-Backlog. Diesen Sprint-Backlog ergänzen sie ggf. durch ältere, bereits bestehende „Wünsche“ aus dem Product Backlog.
  • Das Entwicklungsteam versucht innerhalb des nun beginnenden Sprints, diese Tickets (Sprint-Backlog-Items) möglichst vollständig abzuarbeiten. Der Scrum Master steht bei Schwierigkeiten als „Springer“ bereit und hilft Schwierigkeiten, z.B. technische, organisatorische und zwischenmenschliche Probleme, zu lösen.
  • Spätestens gegen Ende des Sprints testet das Team, die Software möglichst.

Doch ist dieses Vorgehen konform mit den Forderungen der IEC 62304?

Scrum: Typische Probleme mit der Konformität zur IEC 62304

Dieser Abschnitt betont die typischen Fallen, in die Medizinproduktehersteller tappen, wenn sie wie oben beschrieben entwickeln. Dass mit Scrum generell IEC 62304 konform entwickelt werden kann, steht außer Frage und ist in einem Buch von Marc Bless bereits „bewiesen“ worden.

1. Falle: Fehlende Analyse und Freigabe

Jeder „Weiterentwicklungswunsch“ (vergessen wir an dieser Stelle die Unterscheidung zwischen „Bug or Feature“) ist ein Hinweis darauf, dass das Produkt nicht die tatsächlichen Kundenanforderungen erfüllte. Jede dieser Defizite kann zu Risiken führen. Diese Risiken müssen Sie analysieren, bewerten und dies dokumentieren. Dies kann mit einem Werkzeug erfolgen. Wie das geht zeigt ein Videotrainings im Auditgarant.

Die Analyse der Probleme muss zudem eine Trendanalyse beinhalten. Die müssen Sie allerdings nicht bei jedem Release durchführen. Wenige Male im Jahr wird ausreichen.

Vergessen Sie auch nicht, explizit die Änderungen der Software zu genehmigen. Dies nur implizit zu dokumentieren, indem man einem Ticket das Release zuweist, würde dieser Forderung nicht gerecht.

2. Falle: Fehlender Entwicklungs-/Wartungsplan

Die IEC 62304 fordert einen Entwicklungs- bzw. Wartungsplan. Dieser muss u.a. den Prozess, die angewendeten Methoden und Werkzeuge beschreiben. Firmen können diese Forderung erfüllen, wenn Sie einen Software-Entwicklungsprozess definieren, auf den sie im Entwicklungs- bzw. Wartungsplan referenzieren und diesen nur noch ergänzen durch:

  • Konkrete Meilensteine
  • Zeitplanung
  • Zuordnung der Mitarbeiter zu Rollen
  • Abweichungen oder Ergänzungen des Software-Entwicklungsprozesses

3. Falle: Keine konsistente Dokumentation der Software-Anforderungen

Nicht nur die IEC 62304, sondern insbesondere auch die FDA fordern, dass Sie für jedes Software-Release eine konsistente Dokumentation der Software-Anforderungen vorlegen können. Vielen Herstellern scheitern daran, diese Forderung zu erfüllen, weil das Ticket-System nur die Deltas zur Vorgängerversion enthält.
Lassen Sie uns wissen, wen wir Sie dabei unterstützen können, trotz eines „Scrum-artigen Vorgehens“ Ihre Software-Anforderungen IEC 62304 und FDA konform zu dokumentieren.
Kontakt aufnehmen

Dass es ohne die vollständig dokumentierten Software-Anforderungen auch keine Freigabe dieses Dokuments gibt, könnte man schon fast als „Folgefehler“ bezeichnen.

4. Falle: Die Software-Architektur ist nicht konsistent dokumentiert und freigegeben

Da Scrum kein Entwicklungsprozessmodell ist, kann es auch keine Aktivität „Software-Architektur erstellen und dokumentieren“ explizit verlangen. Die IEC 62304 tut dies jedoch. Das bedeutet, dass Sie in Ihrer Prozessbeschreibung bzw. Verfahrensanweisung „Softwareentwicklung“ fordern müssen, dass die Software-Architektur initial erstellt und bei jedem Release (vor der Programmierung) aktualisiert und freigegeben(!) wird.

5. Falle: Unvollständige Tests

Diese Falle ist eine fast zwangsläufige Folge, wenn die Software-Anforderungen nicht vollständig (also nicht nur in Form von Deltas zum Vorgänger-Release) dokumentiert sind: Die vollständige Liste an Software-Anforderungen ist eine wesentliche Voraussetzung für ein vollständiges Testen des Softwaresystems. Denn die IEC 62304 fordert nicht, dass einfach die Software getestet wird, sondern dass alle Software-Anforderungen auf Erfüllung geprüft sind.

6. Falle: Fehlende Validierung der Werkzeuge

Software-Entwicklungsabteilungen, die gemäß Scrum arbeiten, setzen viele Werkzeuge ein. Wir haben bereits über die ALM-Tools bzw. Ticketsysteme gesprochen. Hinzukommen Testwerkzeuge, Werkzeuge zum Bestimmung des Code Coverage oder für die statische Code-Analyse. Diese Werkzeuge sind teilweise Messwerkzeuge und entsprechend zu validieren. Sie finden in einem weiteren Beitrag Hinweise dazu, welche Werkzeuge wie zu validieren sind.

Sonstige Fallen beim agilen Entwickeln

Wir geben Ihnen in ausführlichen Beitrag Tipps, welche typischen Probleme bei der agilen (nicht speziell Scrum) Entwicklung von medizinischer Software auftreten und wie Sie diese vermeiden können.

Weiterführende Informationen

Lesen Sie hier mehr über die agile Entwicklung und die typischen Probleme mit diesem „Vorgehensmodell“. Informieren Sie sich auch über die Vorstellung der AAMI zum Thema „agile Entwicklung“ und über den TIR 45.

Wenn Sie Hilfe benötigen oder unsicher sind, ob Ihr Entwicklungsprozess den Forderungen der FDA oder der IEC 62304 genügt, dann melden Sie sich. Wir helfen gerne.

Kontakt aufnehmen


Kategorien: Software & IEC 62304
Tags: , , ,

Kommentar schreiben