Agile Softwareentwicklung für Medizinprodukte

Montag 28. Januar 2019

Viele Medizinproduktehersteller schwören auf die agile Softwareentwicklung. Der nicht nur rechtlichen Implikationen ist man sich aber häufig nicht bewusst.

1. Agile Softwareentwicklung allgemein

a) Historie, Motivation

Die agile Softwareentwicklung entstand quasi als Gegenbewegung zu dem Trend,

  • immer mehr Dokumente bei der Software-Entwicklung zu verlangen,
  • die Entwickler zunehmend auf deren Rollen zu reduzieren (z.B. Architekt, Tester, Programmierer, Projektleiter) und nicht mehr als Individuen zu sehen,
  • mit Formalien, Reviews, Meilensteinen und Kontrollen den Entwicklungsprozess schwergewichtiger zu gestalten und
  • aufgrund einer Selbstzentrierung die Kunden nicht ausreichend einzubeziehen.

Die agile Softwareentwicklung versucht, dieser schwergewichtigen Softwareentwicklung mit leichtgewichtigen und meist iterativen und inkrementellen bis hin zu „evolutionären“ Vorgehensmodellen wie dem „extreme Programming“ oder SCRUM zu begegnen.

b) Das agile Manifest

Das agile Manifest beschreibt die Glaubenssätze:

  1. Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.
  2. Funktionierende Programme sind wichtiger als ausführliche Dokumentation.
  3. Die stetige Abstimmung mit dem Kunden ist wichtiger als die ursprüngliche Leistungsbeschreibung in Verträgen.
  4. Der Mut und die Offenheit für Änderungen stehen über dem Befolgen eines festgelegten Plans.

Ein weiterer Abschnitt in diesem Beitrag diskutiert diesen Wertekanon im Kontext der Softwareentwicklung für Medizinprodukte.

Prof. Dr. Christian Johner
Benötigen Sie Unterstützung dabei, Ihre Software agil und konform mit den Anforderungen der IEC 62304 und FDA zu entwickeln? Professor Johner und sein Team helfen gerne! Nehmen Sie Kontakt auf!

2. Regulatorische Anforderungen an die Entwicklung medizinischer Software

Eins vorweg: Die agile Softwareentwicklung für Medizinprodukte lässt sich mit den Forderungen der IEC 62304 in Einklang bringen.
Das sagt die Norm sogar explizit. Hilfreiche Hinweise finden Sie im ersten Kapitel des Anhang B. Hier wird eingeräumt, dass nicht alle Anforderungen definiert sein müssen, bevor „Outputs“ produziert werden. Als Beispiel wird genannt, dass eine Software-Komponente spezifiziert, klassifiziert, implementiert und verifiziert werden kann, bevor die komplette Software-Architektur abgeschlossen wurde. Gleich der nächste Satz weist allerdings auf das Risiko hin, dass auf diese Weise Inkonsistenzen entstehen können.

Im Folgenden geben wir einen Überblick darüber, wie Sie solche Risiken beherrschen und weitere Forderungen der Norm einhalten können.

a) Forderung nach Verifikation aller Aktivitäten

Die IEC 62304 macht unmissverständlich klar, dass Sie jede Aktivität mit einem Verifikationsschritt abschließen müssen: Das Erstellen

Weiter verlangt die Norm, diese Aktivitäten rückverfolgbar (-> Traceability) zu dokumentieren.

b) Softwarearchitektur: Keine ad-hoc Design Entscheidungen

Ebenso klar verbietet die IEC 62304 adhoc Design-Entscheidungen. Selbstverständlich können fähige Softwarearchitekten eine Software-Architektur iterativ überarbeiten und normenkonform dokumentieren.

Allerdings: Eine Softwarearchitektur „upfront“ zu entwickeln ist bereits schwer genug. Eine Softwarearchitektur während eines kontinuierlichen Refactorings konsistent weiter zu entwickeln und dabei die Dokumentation zu aktualisieren, ist die ganz hohe Schule, mit der die meisten Firmen überfordert sind.

„Historisch gewachsen“ lautet meist die Erklärung für Softwarearchitekturen, die entweder bei der Güte der Dokumentation oder/und der Güte des Modells Zweifel aufkommen lassen.

Auch die FDA schränkt die Freiheit bezüglich der Reihenfolge der Aktivitäten im Entwicklungsprozess in ihrer Guidance „General principles of software validation“ entsprechend ein:

  • Kap. 5.2.2 „Requirements“ enthält die Empfehlung, ein Design Review durchzuführen, um sicherzustellen, dass Anforderungen vollständig spezifiziert und angemessen sind, bevor umfangreiche Software-Design-Aktivitäten beginnen.
  • Kap. 5.2.3 „Design“ enthält die Empfehlung, ein Design Review am Ende der Software-Design-Aktivitäten durchzuführen, um sicherzustellen, dass das Design korrekt, konsistent, „accurate“ und testbar ist, bevor es implementiert wird.

c) AAMI TIR45

Die AAMI („Association for the Advancement of Medical Instrumentation“) hat einen Versuch unternommen, aufzuzeigen, wie sich agile Software-Entwicklung mit den regulatorischen Anforderungen sowohl der FDA als auch der IEC 62304 vereinbaren lässt.

Das Ergebnis hat sie im TIR45 formuliert. An vielen Stellen darin (z.B. Kap. 5.3.3, 5.4.1, 5.5.3, 5.5.4, 6.5.1, 6.5.3) finden sich Hinweise darauf, dass eine parallele Entwicklung von Anforderungen, Architektur und Code unter gut kontrollierten Bedingungen erlaubt ist. Dies könnte man so interpretieren, das die US-Behörde die Forderungen bzgl. der Reihenfolge der Aktivitäten inzwischen weniger streng sieht, zumal der TIR45 2012 veröffentlicht wurde, während die o.g. Guidance der FDA 2002 zuletzt überarbeitet wurde.

Doch Vorsicht: Dies bedeutet eben auch, dass die FDA bisher offenbar keinen Anlass sieht, Ihre Forderungen zu revidieren. Zwar war die FDA im Komitee der AAMI durch einzelne Mitarbeiter vertreten, doch enthält der TIR45 den klaren Hinweis, dass dies nicht bedeutet, dass die Aussagen von den US-Behörden mitgetragen werden.

Weiterführende Informationen

Lesen Sie hier mehr zum AAMI TIR 45 „Guidance on the use of AGILE practices in the development of medical device software“.

3. Typische Fallen bei der agilen Software-Entwicklung

a) Falle 1: 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.

b) Falle 2: 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

c) Falle 3: 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.

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

e) Falle 4: 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.

f) Falle 5: 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.

g) Falle 6: 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.

h) Falle 7: QM-Sprints

Sie können den Forderungen nach Verifizierung genügen, indem Sie die folgenden Aktivitäten mehrfach und iterativ durchlaufen:

  • Sie dokumentieren/überarbeiten mehrfach die Softwareanforderungen, die Rückverfolgbarkeit und das Review
  • Sie dokumentieren/überarbeiten mehrfach die Softwarearchitektur, die Rückverfolgbarkeit und das Review
  • Sie dokumentieren/überarbeiten mehrfach das detaillierte Design, die Rückverfolgbarkeit und das Review
  • usw.

Damit kommen Sie zu Mini-Vs:

Auch Mini-Vs für die agile Softwareentwicklung für Medizinprodukte führen nicht immer zur IEC 62304 Konformität
Abb. 1: Auch Mini-Vs für die agile Softwareentwicklung für Medizinprodukte führen nicht immer zur IEC 62304 Konformität

In der Praxis der agilen Softwareentwicklung bei Medizinprodukten stößt man meist auf einen der beiden folgenden Ansätze:

Ansatz 1: Verifikation in jedem Sprint

Damit haben Sie aber im ungünstigsten Fall den Dokumentationsaufwand nicht erniedrigt, sondern vervielfacht. Mit Delta-Reviews und einem kontinuierlichen Weiterschreiben der Dokumente können Sie dieses Problem relativieren. Das ist aber die hohe Kunst; agile Verfahren benötigen hervorragend ausgebildete Protagonisten und effiziente Dokumentenfreigaben. (Lesen Sie zu den Dokumentenfreigaben hier mehr.)

Ansatz 2: „Qualitätssprint“

Die zweite Möglichkeit besteht darin, dass Sie die Dokumentation der oben genannten Aktivitäten einschließlich der Reviews erst nach dem letzten Iterationsschritt erstellen. Das ist der Ansatz, den man in der Praxis bei den agil entwickelnden Firmen häufiger beobachtet.

Damit haben aber diese Firmen die Nachteile vereinigt:

  • Sie betreiben weiterhin den Aufwand für die (Rückwärts-) Dokumentation.
  • Sie profitieren nicht von den Vorteilen, welche die Dokumentation und die Reviews leisten könnten: Nämlich Fehler frühzeitig im Prozess zu erkennen und zu beheben und so viel Zeit und Geld zu sparen.
  • Die Entwicklungsabteilung arbeitet weitgehend unbehelligt und unabhängig von der Qualitätssicherung und lässt somit die Qualitätssicherung zu einem Overhead verkommen, den man sich leistet, weil es die Regularien fordern.
  • Sie haben gegen den Sinn der Norm IEC 62304 (“keine ad-hoc Design-Entscheidungen”) verstoßen und trotz Dokumentationsaufwand keine Normenkonformität erreicht.

Den Sinn dieser Regularien haben die Firmen damit pervertiert. Sehen Sie sich dazu auch das Video im Beitrag über das V-Modell an.

i) Falle 8: SCRUM als ein Prozessmodell missverstehen

Scrum ist eher ein Rahmen (Framework) für das agile Projektmanagement als ein Vorgehensmodell im Sinne eines Prozessmodells.

Scrum in de Medizintechnik
Abb. 2: SCRUM auch in den Medizintechnik? Bildquelle Wikipedia

Die Einträge im Product-Backlog und im Spint-Backlog sind vom Typ „Task“. Das sind Aufgaben! Für den Inhalt dieser Aufgaben gibt es keine Typsicherheit. Beispielsweise enthalten diese „Tickets“ Aufgaben wie:

  • Implementiere diesen neue Screen
  • Führe ein Refactoring für Modul x durch
  • Setze diese User Story in unserer Software um

Annahme, dass die Summe aller Tickets den Software-Anforderungen entspräche, wird in den meisten Audits widerlegt.

Es spricht jedoch überhaupt nichts dagegen, SCRUM bei der Entwicklung von Medizinprodukten zu verwenden, wenn die oben genannten Fallen vermieden und die weiter unten genannten Empfehlungen berücksichtigt werden.

4. Missverständnisse des Wertekanons der agilen Softwareentwicklung

a) Reflektion des Wertekanons

Die Werte des agilen Manifests klingen ebenso vernünftig wie attraktiv. Lassen Sie uns diesen Wertekanon analysieren:

1. „Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge“

Unbestritten, eine vertrauensvolle Zusammenarbeit im Team, eine gute Kommunikation und hochqualifizierte Mitarbeiter stellen die Voraussetzung für eine erfolgreiche Softwareentwicklung dar. Das relativiert die Forderungen der Normen wie die der IEC 62304 oder ISO 13485 nach wohldefinierten Prozessen und der gezielten Auswahl, Validierung und Dokumentation der eingesetzten Werkzeuge nicht im geringsten.

2. „Funktionierende Programme sind wichtiger als ausführliche Dokumentation“

Den zweiten Grundsatz hören viele Entwickler am liebsten. Natürlich sind funktionierende Programme essenziell. Die Hoffnung, durch agile Softwareentwicklung den Dokumentationsaufwand reduzieren zu können, wird aber meist enttäuscht. Im Gegenteil: Der Versuch vieler Firmen, agil und nach IEC 62304 zu entwickeln, endet sehr oft im „worst case“: Einem besonders hohen Anteil an Dokumentation, der der Qualität des Produkts nicht dienlich ist. Dazu gleich mehr.

3. „Die stetige Abstimmung mit dem Kunden ist wichtiger als die ursprüngliche Leistungsbeschreibung in Verträgen“ und
4. „Der Mut und die Offenheit für Änderungen stehen über dem Befolgen eines festgelegten Plans“

Die tückischste Falle stellen aber die beiden letzten Punkte des Manifests dar. Weshalb bedarf es einer ständigen Abstimmung mit dem Kunden? Weshalb sind regelmäßige Änderungen notwendig?

b) Missverständnisse dieses Wertekanons

Sie kennen sicher Aussagen der Entwicklungsabteilungen wie „der Kunde hat sich anders entschieden“ oder „die Anforderungen haben sich geändert“. Dahinter verbirgt sich aber ein geradezu tragisches Missverständnis: Die Nutzungsanforderungen ändern sich nämlich in einem gegebenen Nutzungskontext nie. Es besteht vielmehr ein Defizit, diese Nutzungsanforderungen systematisch, richtig und vollständig zu identifizieren. Und dieses Defizit versuchen Firmen dadurch zu kompensieren, dass sie einen Entwicklungsprozess schaffen, der mit diesen Änderungen umgehen kann.

Würden die Hersteller nur ein Bruchteil der Energie, die sie für die Umstellung auf agile Prozesse aufbringen, in ein systematisches Requirements-Engineering und in eine Ausbildung der dafür Verantwortlichen investieren, kämen sie schneller, zuverlässiger und preisgünstiger zu neuen Produkten. Zu Produkten, die deren Kunden wirklich brauchen.

Normen wie die ISO 9241-210 (2010) geben Ihnen wertvolle Hinweise dazu, wie Sie Nutzungsanforderungen systematisch erheben. Ganz nebenbei erreichen Sie damit weitgehende Konformität mit der IEC 62366.

Vorsicht!

Fazit: Missbrauchen Sie die Agilität nicht, um die Inkompetenz beim systematischen Erheben der Software-Anforderungen und Stakeholder-Anforderungen zu kompensieren.

5. Empfehlungen für die agile Softwareentwicklung für Medizinprodukte

Wir empfehlen Ihnen die (agile) Softwareentwicklung wie folgt zu gestalten, um Ihre Medizinprodukte-Software schnell, professionell und IEC 62304-konform zu entwickeln:

a) Richtig iterieren

Iterieren Sie nicht über den kompletten Softwareentwicklungsprozess, um die wirklichen Kundenanforderungen zu erheben (Typ A). Nutzen Sie stattdessen systematische Verfahren zum Erheben der Nutzungsanforderungen und iterieren Sie mit Hilfe von horizontalen Prototypen nur über die Phasen Stakeholder-Anforderungen und Systemanforderungen (Abb: Typ B).

Wenn Sie unsicher sind, ob die gewählte Architektur geeignet ist, nutzen Sie vertikale Prototypen für eine Antwort. Es gibt keine Notwendigkeit, den Kunden erneut einzubeziehen. Sie müssen somit nur über Pfad C iterieren und nicht über den vollständigen Entwicklungsprozess.

Nutzen Sie den Iterationstyp C auch, um die Komplexität der Softwareentwicklung zu reduzieren.

Bei der agilen Softwareentwicklung für Medizinprodukte gibt es mehrere Möglichkeiten zur Iteration
Abb. 3: Bei der agilen Softwareentwicklung für Medizinprodukte gibt es mehrere Möglichkeiten zur Iteration

b) Anforderungen nicht agil ableiten

Wenn Sie die Agilität nutzen, um sich an die wirklichen “Kundenanforderungen” “heran-zu-iterieren”, verzichten Sie auf eine effiziente Entwicklung. Leiten Sie insbesondere die Nutzungsanforderungen systematisch her.

c) Upfront Grobarchitektur

Nachdem Sie diese Anforderungen kennen, modellieren Sie die Softwarearchitektur upfront, zumindest die beiden ersten Bausteinebenen. Beschreiben Sie also nicht jede Methode, weil sonst der Aufwand, das Modell und die Software synchron zu halten zu hoch ist. Die IEC 62304 verlangt das auch nicht.

d) Testautomatisierung

Übernehmen Sie den in der agilen Softwareentwicklung üblichen Ansatz, die Unit-, Integrations- und Systemtests wie den ganzen Build-Prozess möglichst vollständig zu automatisieren.

e) Dokumentation als Teil des Sprints

Definieren Sie die Dokumentation explizit als Teil der zu entwickelnden Artefakte (“definition of done”) und verzichten Sie nicht auf eine explizite und kontinuierlich aktualisierte Architektur. Andernfalls sind Sie nicht IEC 62304 konform und verstoßen damit gegen das Gesetz.

f) Leichtgewichtige Dokumentenfreigaben

Aktualisierten Sie bei jedem Sprint zuerst die Dokumente (Anforderungen, Architektur) und geben Sie diese wirklich frei (Verifizierung).

Gestalten Sie dazu sehr leichtgewichtige Dokumentenfreigaben, um jede Form der Bürokratie zu vermeiden. Diese Freigaben bedeuten nicht, das Sie diese Dokumente in der folgenden (kurzen) Implementierungsphase nicht parallel zum Code weiterentwickeln dürfen.

Hierzu kann Ihnen sowohl der Anhang B der IEC 62304 als auch der TIR45 im Audit bzw. bei einer FDA-Inspektion als Argumentationshilfe dienen. Geänderte Dokumente sollten Sie zeitnah, z.B. am Ende jedes Sprints, erneut prüfen und freigeben.

g) Design Reviews

Führen Sie regelmäßig Design Reviews durch, in deren Rahmen Sie die Konsistenz Ihres gesamten Design Outputs prüfen. Hierbei helfen Ihnen Traceability-Analysen, die Sie ohnehin benötigen.

6. Weitere Unterstützung

Wenn Sie noch genauer erfahren möchten, wie Sie Ihre Softwareentwicklung agil und konform mit der IEC 62304 gestalten können, dann nutzen Sie unsere Hilfe:

  • Seminar medizinische Software: Hier werden wir die Entwicklungsprozesse und die agilen Verfahren besprechen – auch als Inhouse-Seminar buchbar.
  • Seminar Requirements, Usability und IEC 62366: Hier lernen Sie, wie man Nutzungsanforderungen systematisch erhebt. So sparen Sie sich den Stress unnötiger Iterationen.
  • Persönliche Beratung: Wir haben Freude daran, Ihr Team dabei zu unterstützen,
    • mit einem Blick von außen, Verbesserungspotenziale zu identifizieren,
    • Ihren Prozess auf Normenkonformität zu prüfen und
    • mit Praxistipps die Entwicklung noch effektiver und effizienter zu gestalten.

Nehmen Sie gleich Kontakt mit uns auf!

Fazit

Agilität der Agilität willen ist Unsinn. Die Werte des agilen Manifest sind es aber keineswegs: Vertrauensvolle Zusammenarbeit, Kundenorientierung, gegenseitiges Verständnis, gedankliche Flexibilität und effektive Kommunikation. Leben Sie diese Werte!

War dieser Artikel hilfreich? Bitte bewerten Sie:
1 Stern2 Sterne3 Sterne4 Sterne5 Sterne

Kategorien: Software & IEC 62304
Tags: ,

Ein Kommentar über “Agile Softwareentwicklung für Medizinprodukte”

  1. Erik schrieb:

    Sehr informativer Artikel – gerade mit Fokus auf Medizintechnik, … beim „Agile Manifest“ sollte jedoch der Zusatz nicht vergessen werden: „Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden,schätzen wir die Werte auf der linken Seite höher ein.“

    Und ja, die potentiellen Gefahren und Punkt 2: „Wenn Sie die Agilität nutzen, um sich an die wirklichen “Kundenanforderungen” “heran-zu-iterieren”, verzichten Sie auf eine effiziente Entwicklung.“
    => Zwischenergebnisse als Sprint-Inkremente und Feedback á Retrospektive steigern m. W. die Effizienz und Effektivität 😉

Kommentar schreiben