Prof. Dr. Christian Johner

Autor: Prof. Dr. Christian Johner

Inhaber der Johner Institut GmbH

Agile Softwareentwicklung für Medizinprodukte

Montag 2. Februar 2015

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

Ein weiterer Beitrag geht auf die Besonderheiten von Scrum ein und gibt Hinweise, wie man die typischen Probleme bei diesem „Vorgehensmodell“ vermeidet.

Agile Softwareentwicklung allgemein

Historie

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.

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!

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.

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.

Verifikation bei der agilen Software-Entwicklung

Sie können diesen Forderungen 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

 

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.

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

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.

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.

Agile Softwareentwicklung: Gefahren und Missverständnisse

Auf zwei Gefahren bei der agilen Softwareentwicklung für Medizinprodukte haben wir bereits hingewiesen:

  1. Die Dokumentenfreigaben erfolgen nicht IEC 62304 konform oder erhöhen statt erniedrigen den Overhead.
  2. Die Software-Architektur wird retrospektiv oder unzulänglich erstellt oder/und dokumentiert.

Aus dem Wertekanon der agilen Softwareentwicklung ergeben sich nicht nur in der Medizinprodukte-Welt weitere Gefahrenpunkte.

Wertekanon der agilen Softwareentwicklung

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?

Missverständnisse dieses Wertekanons

Ich kenne die Aussagen der Entwicklungsabteilungen sehr gut 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.

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

Iterationszyklen bei Medizinprodukten

Es ist erstrebenswert, etwa im Monatszyklus eine potenziell auslieferbare Software zu entwickeln, beispielsweise um die Komplexität der Softwareentwicklung zu reduzieren. Allerdings ergibt es oft keinen Sinn, in diesem Zyklus die neue Version des Medizinprodukts tatsächlich in den Verkehr zu bringen, denn funktionale Änderungen oder Verbesserungen am Produkt, bedeuten eine neue Zulassung bzw. Konformitätsprüfung.

Ein erneutes Konformitätsbewertungsverfahren oder/und Einreichung der technischen Dokumentation bei benannten Stellen oder der FDA ist vielen Firmen zu aufwändig. Zudem kann eine FDA Clearance 90 Tage dauern. Daher iterieren die meisten Firmen nicht über den vollständigen Entwicklungsprozess.

Zusammenfassung: Gefahren bei der agilen Softwareentwicklung vermeiden

Lassen Sie uns die potenziellen(!) Gefahren und Nachteile einer agilen Softwareentwicklung für Medizinprodukte zusammenfassen:

  1. 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.
  2. 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.
  3. Leichtgewichtige Dokumentenfreigaben: Wenn Sie keine leichtgewichtigen Freigaben haben aber normenkonform arbeiten (wollen), werden Sie Ihre Entwicklung mit agiler Herangehensweise im Vergleich mit einem konventionellen Prozessmodell verlangsamen, weil Sie zu viel mehr Verifikationsschritte absolvieren müssen.
  4. Kein „QM-Sprint“!: Wenn Sie die Dokumentation erst zum Schluss des Projekts angehen (“QM-Sprint”) haben Sie nicht nur gegen den Sinn der Norm IEC 62304 (“keine ad-hoc Design-Entscheidungen”) verstoßen, sondern sich vereinten Nachteile aller Vorgehensmodelle eingebrockt: Keine Normenkonformität, dennoch Dokumentationsaufwand und keinen Nutzen, den Sie dadurch bekommen hätten, dass Sie durch die Dokumentation Fehler früh finden bzw. von Beginn vermeiden. (Wertschöpfung sollte nicht nur beim Implementieren, sondern v.a. beim Konstruieren erfolgen d.h. in Dokumenten!)
Weiterführende Informationen

Ein weiterer Beitrag geht auf die Besonderheiten von Scrum ein und gibt Hinweise, wie man die typischen Probleme bei diesem „Vorgehensmodell“ vermeidet. Weitere Informationen zum TIR45 finden Sie hier.

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:

  1. Richtig iterieren 1: 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).
  2. 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.
  3. Richtig iterieren 2: 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.
  4. Richtig iterieren 3: Nutzen Sie den Iterationstyp C auch, um die Komplexität der Softwareentwicklung zu reduzieren.
  5. 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.
  6. 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.
  7. 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.

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

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!

Sie benötigen 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!

Kontakt aufnehmen


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