•  
  •  
  •  
  •  
  •  
Agile Softwareentwicklung in regulierten Umgebungen

Regulatorien im Medtech: Bye-bye agile Entwicklung?

Wegen ihrer strengen Vorschriften und Normen glauben viele Unternehmen, dass eine agile Softwareentwicklung im regulierten Umfeld nicht möglich ist. Doch weit gefehlt, denn mit den richtigen Methoden ist die agile Entwicklung sogar noch ein Gewinn, meint Dominik Berner, Software-Ingenieur bei bbv.

19.11.2020Text: bbv0 Kommentare
Agile Softwareentwicklung in regulierten Umgebungen
  •  
  •  
  •  
  •  

Agile Softwareentwicklung und Regularien: Ist das ein Widerspruch oder gibt es einen Ausweg? Gerade viele Medtech-Unternehmen glauben, dass durch die strengen Vorschriften agile Methoden nicht möglich sind. Dabei ist die agile Entwicklung regulierter Software bei weitem nicht so schwer, wie man vielleicht denkt. Auch wenn der Aufwand nicht zu verachten ist, der für das Bestehen eines Software-Audits notwendig ist, können Artefakte und Funktionen entwickelt werden, die den Mehrwert des Produkts erhöhen und am Ende sogar ein besseres Ergebnis hervorbringen.

Entwicklung regulierter Software auf den Punkt gebracht

Die meisten Normen erfordern eine umfassende Dokumentation. Für Medizingeräte-Software regelt zum Beispiel die IEC 62304 die Dokumentation der Prozesse für die Entwicklung, Prüfung und Freigabe sowie für technische und architektonische Entwürfe. Darüber hinaus verlangen Normen nach einer Risikobewertung der potenziellen Gefahren für den Endnutzer und die Verknüpfung von Tests mit den dokumentierten Anforderungen. Wenn ein Gerät zusätzliche Anforderungen erfüllen muss, wie zum Beispiel bei Herzschrittmachern, beinhaltet die ISO 14708 weitere Anforderungen an die Dokumentation, das Design und an die Qualitätskontrollen.

Kurz vor der Markteinführung sind eine ganze Reihe von Systemtests notwendig, um die Betriebsfähigkeit zu überprüfen. Das reicht von Messungen elektromagnetischer Störungen bis hin zu Tests bei Minustemperaturen, Erdbeben, Stromausfall oder beim Betrieb durch unerfahrene Personen. Erfüllt ein Gerät die festgelegten Anforderungen nicht vollständig, gilt das Audit als nicht bestanden und der Entwicklungsprozess beginnt von vorn. Und auch nach der Markteinführung eines Geräts oder einer Software muss die weitere Entwicklung fortlaufend dokumentiert werden.

Das klingt kompliziert? Sicherlich lässt sich der Mehraufwand nicht leugnen; aber wenn die agilen Konzepte richtig angewendet werden, ist hält er sich in Grenzen. Und das Gute ist: Die strengen Vorschriften stellen sicher, dass die Geräte und die Software so sicher wie möglich arbeiten und technisches Versagen nicht zu Personenschäden führt.

Hier habe ich bewusst das Wort «sicher» und nicht das Wort «gut» verwendet, denn Vorschriften garantieren auf keinen Fall, dass ein Gerät bequem zu bedienen ist oder ein echtes Problem löst. Die Vorschriften besagen lediglich, dass bekannt ist, wie dieses Gerät funktioniert und dass es sich an international festgelegte Normen hält. Glücklicherweise trägt die agile Entwicklung dazu bei, nicht nur «sichere», sondern auch «gute» Geräte zu entwickeln, indem sie frühzeitiges Feedback in die Entwicklung einfliessen lässt.

Mit agiler Entwicklung wird nicht nur «sichere», sondern auch «gute» Software entwickelt, da sie frühzeitiges Feedback in die Entwicklung einfliessen lässt.

 

Wie lässt sich agil arbeiten im regulatorischen Umfeld?

Bisher erfolgte das Software-Design grösstenteils upfront und die restliche Entwicklung linear. Wenn man Glück hatte, entwickelte man in monatlichen und nicht in jährlichen Zyklen auf Basis des V-Modells. Heute ist die moderne Softwareentwicklung viel schneller. Änderungen können viel leichter in die Software eingearbeitet werden als z. B. in Hardwarekomponenten. Mithilfe von agilen Konzepten können wir diesen Vorteil nutzen, um besserer Produkte zu entwickeln. Doch ist dies auch in stark regulierten Umgebungen möglich? Die Antwort lautet ja, wenn man die folgenden Punkte beachtet:

Dokumentieren heisst Verstehen

Um ein Audit erfolgreich zu bestehen, muss der Prozess der Softwareentwicklung genau beschrieben sein, und es müssen alle beteiligten Personen geschult werden. Die Beschreibung besteht üblicherweise aus einem Qualitätshandbuch, in dem die Qualitätsmetriken festgelegt sind und wie sie eingehalten werden (sogenannte «Quality Assurance Plans», kurz QAPs ) Zusätzlich enthält die Beschreibung mehrere Standard-Arbeitsanweisungen (sogenannte SOPs), in denen die Prozesse für die Entwicklung und die Lieferung des Produkts beschrieben werden. Das einzige Ziel der Dokumentation ist es, sicherzustellen, dass veränderte Anforderungen oder Mängel nachverfolgt werden und die Software auf Basis des definierten Qualitätsstandards entwickelt wird.

Das einzige Ziel der Dokumentation von Prozessen ist es, sicherzustellen, dass veränderte Anforderungen oder Mängel nachverfolgt werden und die Software auf Basis des definierten Qualitätsstandards entwickelt wird.

 

Das klingt recht einfach. Da es sich aber um regulatorisch wichtige Dokumente handelt, kann sich der Prozess von der Erstellung bis zur Genehmigung als aufwendig und langwierig entpuppen. Aus diesem Grund sollten Sie sicherstellen, dass die Person, die für die Prozessgestaltung zuständig ist (z. B. der Scrum Master), stets mit im Boot ist. Ein einfacher Verweis auf den Scrum Guide könnte bereits ausreichen, um die Ansprüche an eine SOP zu erfüllen.

Continuous Integration für regulatorische Dokumente

Im Vergleich zur «normalen» Software ist die Entwicklung regulatorischer Software mit einem höheren Dokumentationsaufwand verbunden. Regulierte Software-Dokumentation muss als integraler Bestandteil der Software betrachtet werden – sonst wird diese nie auf den Markt kommen. Um das zu erreichen, bevorzuge ich den Ansatz «Documentation as a Code»: Wenn die Dokumentation direkt neben dem Code steht, kann sie leichter aktualisiert werden. Und wenn eine Anforderung oder ein Testfall betroffen ist, wird dies im Review-Prozess im Team gleich mitberücksichtigt.

Ob kontinuierlich oder direkt vor dem Release: Der Aufwand für die Dokumentation wird gleich bleiben. Doch mit «Writing as you develop» wird die Korrektheit der Dokumentation deutlich verbessert.

 

Die Dokumentation in einem textbasierten Format zu erstellen, z. B. Asciidoc, erleichtert darüber hinaus die Versionsverwaltung mit Git. In der CI-Pipeline kann die Dokumentation anschliessend in PDF konvertiert und an den Ort verschoben werden, an dem Sie die regulatorischen Dokumente für die Freigabe speichern.

Doch auch die Dokumentation selbst wird leichter. Es lässt sich viel einfacher überprüfen, ob zum Beispiel jeder Anforderung die erforderlichen Testfälle zugeordnet sind oder ob es verwaiste Tests gibt. Es kann mit geringem Mehraufwand tiefgehender getestet und viel Zeit gespart werden, wenn Warnmeldungen auf leere Teile eines Dokuments oder alte Formatvorlagen hinweisen. Zudem können auch Software-Tests, die bestimmte Anforderungen verifizieren, viel einfacher mit der Dokumentation verknüpft werden. Ob kontinuierlich oder direkt vor dem Release: Der Aufwand für die Dokumentation wird gleich bleiben. Doch mit «Writing as you develop» wird die Korrektheit der Dokumentation deutlich verbessert.

Produktvalidierung und regulatorischen Release entkoppeln

Wenn es dann auf das Release zugeht, sind oft einige zeitaufwendige manuelle und semi-manuelle Tests notwendig. Viele dieser Tests können und sollten automatisiert werden und in eine geeignete CI/CD-Infrastruktur eingebettet sein. Einige Tests müssen jedoch nach wie vor auf herkömmliche Weise erfolgen. Dazu gehören Belastungs- oder Stresstests unter extremen Klimabedingungen oder bei schwerwiegender, unsachgemässer Behandlung der Geräte sowie die Validierung der Produkte anhand von klinischen Studien. Der Aufwand für diese abschliessende Qualitätssicherung ist oft beträchtlich und es ist einfach nicht praktikabel, dies alle paar Wochen durchzuführen.

Doch gerade weil diese abschliessenden Tests so kostenintensiv sind, ist es riskant, mit weniger kritischen Tests ebenfalls bis zum letzten Moment zu warten. Findet man dann noch kleinere Bugs, ist es häufig zu aufwendig, diese vor dem Release zu korrigieren. Denn sobald Code verändert wird, müssen vorhergehende Tests möglicherweise erneut durchgeführt werden. Das Ergebnis sind dann häufig Produkte, die der Nutzer nicht versteht und nur mithilfe von Handbüchern bedienen kann.

Nationale Aufsichtsbehörden wie die U.S. Food and Drug Administration (FDA) gestatten demgegenüber, die Testdurchläufe schon vor der Freigabe des Geräts durchzuführen. So können repräsentative Nutzergruppen z. B. ein User Interface oder einen Klick-Dummy testen, auch wenn das Software-Design das finale Audit noch nicht bestanden hat. Darüber hinaus helfen regelmässige und frühzeitige Integrations- und Belastungstests dabei, Fehler aufzuspüren, bevor das Gerät überhaupt in Produktion geht.

Schon früh den Blick für QS-Prozesse schärfen

Um ein gewisses Mass an Objektivität zu gewährleisten, erfolgt die regulatorische Qualitätssicherung von Personen, die nicht an der Entwicklung des Produkts beteiligt waren. Der Leitsatz «Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge» trifft auch hier zu.

So wie Kunden oder Endnutzer muss auch die QS-Abteilung mit dem Produkt zufrieden sein.

 

Je besser Sie als Entwickler wissen, wie die Qualitätssicherung (QS) funktioniert, desto besser sind Sie in der Lage, auf ihre Bedürfnisse einzugehen. Im Endeffekt sind QS-Mitarbeiter nicht anders als Kunden und Endnutzer, die mit dem Produkt zufrieden sein müssen. Daher kann der persönliche Kontakt zur QS-Abteilung die Feedback-Qualität deutlich verbessern.

Übergeben Sie frühe Entwürfe Ihrer Arbeit an die QS, um zu erfahren, ob das, was Sie produzieren, für sie brauchbar ist. Sprechen Sie mit der QS-Abteilung darüber, was für die Tests benötigt wird, und helfen Sie sich gegenseitig beim Aufbau der benötigten Testinfrastruktur. Das frühzeitige Durchführen von einfachen Probeläufen der Tests, auch wenn das Produkt erst halb fertig ist, bringt eine Menge Dinge ans Licht. So können Sie den Kurs noch frühzeitig korrigieren.

Trotz Normen flexibel bleiben

Die Entwicklung von regulatorischer Software wird nie so leicht sein wie die Entwicklung einer Smartphone-App. Die 12 Prinzipien der agilen Softwareentwicklung lassen sich jedoch auch hier gut anwenden. Mithilfe von agilen Konzepten wird die Durchführung der finalen Software-Tests deutlich erleichtert. Ausserdem können auf diese Weise bessere Produkte für den Endnutzer entwickelt und schneller auf den Markt gebracht werden. Somit ist es also auch in stark regulierten Bereichen möglich, die Softwareentwicklung flexibel und agil zu gestalten.

Dieser Artikel erschien bereits in ähnlicher Form und auf Englisch auf dem persönlichen Blog von Dominik Berner.

Der Autor

Dominik Berner

Dominik Berner ist Software-Ingenieur bei bbv. Dank seines Know-hows im MedTech-Bereich kennt er die Wachstumsgrenzen von Startups und Kleinunternehmen, aber auch die Verhältnisse in Grossfirmen. Als Agilist betrachtet Berner Softwareentwicklung als Teamsport, der eine starke Unternehmenskultur erfordert.

Unser Wissen im Abo

Arbeiten von zuhause aus

«Homeoffice bringt mehr Produktivität»

Agile Software Development
25 Jahre bbv

Anspruchsvolle Seilschaften

Agile Software Development
Transformation im Unternehmen

Kosten senken bei der Softwaremodernisierung

Agile Software Development

Artikel kommentieren

Die E-Mail-Adresse wird nicht publiziert. Notwendige Felder sind mit einem * versehen.

Beachtung!

Entschuldigung, bisher haben wir nur Inhalte in English für diesen Abschnitt.

Achtung!

Entschuldigung, bisher haben wir für diesen Abschnitt nur deutschsprachige Inhalte.

Beachtung!

Entschuldigung, bisher haben wir nur Inhalte in English für diesen Abschnitt.

Achtung!

Entschuldigung, bisher haben wir für diesen Abschnitt nur deutschsprachige Inhalte.