Lange Zeit galt das V-Modell als Standardvorgehen für Softwareentwicklungsprojekte in GxP-regulierten Umgebungen wie der Pharma- oder Medizintechnikbranche. Mit der zunehmenden Verbreitung agiler Entwicklungsmethoden stellt sich jedoch auch hier die Frage, wie die Vorteile eines agilen Vorgehens mit den regulatorischen Anforderungen der GxP-Richtlinien erfolgreich kombiniert werden können.

Sei es die Migration auf S/4HANA, die Nutzung von Laborsystemen oder die Automatisierung im Produktionsumfeld. Die Entwicklung von Softwarekomponenten im Life-Science-Bereich unterliegt fast immer den GxP-Richtlinien, die verbindliche Vorgaben hinsichtlich der Sorgfalt bei der Entwicklung sowie der Nachvollziehbarkeit über den gesamten Lebenszyklus von den Anforderungen bis zum abschließenden Test im Betrieb machen. Um den daraus resultierenden Validierungspflichten gerecht zu werden, hat sich das V-Modell als Standardvorgehen etabliert.

Sequenzielles Vorgehen im V-Modell

In einem sequenziellen Vorgehen werden zunächst alle Anforderungen in einem Top-Down-Prozess schrittweise spezifiziert und anschließend umgesetzt. In einer separaten Testphase werden die Softwarekomponenten dann Bottom-up vom Entwicklungstest über Funktionstests bis hin zu integrativen Akzeptanztests verifiziert. Für jeden dieser Schritte besteht eine Dokumentationspflicht, die eine durchgängige Nachvollziehbarkeit über den gesamten Entwicklungsprozess sicherstellen soll. Ein übergeordnetes Risikomanagement auf Anforderungsebene stellt sicher, dass dabei nur die GxP-relevanten Teile des Systems betrachtet werden.

Für jedes Projekt das passende Entwicklungsvorgehen

Für Softwareentwicklungsprojekte mit bekannten Nutzeranforderungen sowie einem klar definierten Funktionsumfang, wie sie bisher häufig in der Pharma- und Medizintechnikbranche anzutreffen sind, kann dieses Vorgehen durchaus zielführend sein. Trifft man jedoch auf Projektumgebungen, in denen es auf eine möglichst kurze Time-to-Market ankommt, in denen die Anforderungen zu Projektbeginn noch nicht klar definiert sind oder sich kontinuierlich ändern können, stößt dieses sequenzielle Vorgehen schnell an seine Grenzen. Hier bieten agile Methoden, die eine frühzeitige Bereitstellung und iterative Weiterentwicklung von Funktionselementen unterstützen, deutliche Vorteile.

Schnelleres Feedback dank agiler Vorgehensweise

Im Gegensatz zum streng sequenziellen Vorgehen im Wasserfall- oder V-Modell wird beim agilen Vorgehen der Gesamtumfang in kurzzyklische, aufeinander folgende Sprints zerlegt, an deren Ende jeweils fertige Softwarekomponenten zur Verfügung stehen. Dadurch ergeben sich deutliche Vorteile hinsichtlich der früheren Verfügbarkeit lauffähiger (Teil-)Programme. Dies ermöglicht dem Auftraggeber bzw. Nutzer eine schnellere Rückmeldung über die Umsetzung einzelner Anforderungen und erlaubt ggf. die Aufnahme neuer Anforderungen in den Scope auch während des Projektes.

Um dieses Vorgehensmodell in GxP-konformen Umgebungen erfolgreich einsetzen zu können, müssen jedoch zusätzliche Validierungsschritte im Sinne von Haltepunkten vorgesehen werden, um die notwendigen Dokumentationen und Freigaben nicht aus den Augen zu verlieren. Entsprechende Erweiterungen des bestehenden Vorgehens sollen im Folgenden vorgestellt werden.

Kontinuierliche Dokumentation als Basis für ein GxP-konformes agiles Vorgehen

Im Mittelpunkt des agilen Vorgehensmodells für GxP-Umgebungen steht die kontinuierliche Pflege der Dokumentation. Anstatt alle Anforderungen zunächst in einer separaten Analysephase zu spezifizieren, wird in jedem Sprintzyklus der gesamte Ablauf des V-Modells aus Analyse, Umsetzung und Test durchlaufen - und die Drafts der Dokumentation werden sukzessive für die im Sprint enthaltenen Anforderungen erweitert. Dadurch stehen die erforderlichen Dokumente, wie z.B. die User Requirements Specification oder die Functional Specification, aber auch Tests, schneller zur Verfügung als beim herkömmlichen Vorgehen. Dies bietet dem Validierer die Möglichkeit, schon frühzeitig immer wieder zu prüfen, ob die Art der Dokumentation den Anforderungen entspricht und steuernd einzugreifen. Dies reduziert die Fehleranfälligkeit und erhöht die Qualität der Dokumentation. Für einen produktiven Go-Live werden die während der Entwicklung entstandenen Drafts zu formalen Dokumenten eingefroren und abschließend die formalen Tests durchlaufen, sodass am Ende eine vollständige Validierungsdokumentation für die Release vorliegt. Die nächste Release kann dann in der gleichen agilen Vorgehensweise entwickelt werden.

Für die Entwicklerteams bedeutet diese Form der kontinuierlichen Dokumentation am Ende des Tages möglicherweise mehr Dokumentationsaufwand. Allerdings ist die zu leistende Dokumentation besser in den Entwicklungsprozess integriert und wird daher in der Regel als angenehmer empfunden.

Schleichende Erweiterung des Projekt-Scopes

Ein Risiko dieses agilen Vorgehens besteht darin, dass sich der Projektumfang ständig erweitert. Denn im Gegensatz zum klassischen Vorgehen, bei dem die zu Projektbeginn definierten Anforderungen als Ganzes umgesetzt werden und somit kaum ein ‚Scope creep‘ auftreten kann, lädt das agile Vorgehen mit häufigen Zwischenreleases dazu ein, die Anforderungen im Sinne eines Moving Target ständig anzupassen und zu erweitern. Dies kann gerade bei Projekten mit explorativem Charakter sehr gewinnbringend sein, birgt aber einerseits die Gefahr, dass Projekte hinsichtlich Kosten und Zeit aus dem Ruder laufen. Zum anderen kann es zu einer schleichenden Verschiebung der GxP-Relevanz kommen, indem z.B. ein bisher unkritischer Prozess durch zusätzliche Implementierungen plötzlich GxP-relevant wird. Dies kann dazu führen, dass die Form der Dokumentation nicht mehr den Anforderungen im Rahmen der Validierung entspricht.

Erfolgsfaktoren für die Einführung agiler Methoden in regulierten Umfeldern

Um den oben genannten Risiken wirksam zu begegnen, sollten bei einem agilen Vorgehen folgende Hinweise beachtet werden:

• Auch wenn die Umsetzung einzelner Funktionselemente im Rahmen eines agilen Vorgehens schrittweise und iterativ erfolgt, empfiehlt es sich dennoch, frühzeitig ein ‚Big Picture‘ des geplanten Gesamtsystems zu entwickeln und die Grenzen der Architektur abzustecken. Ansonsten besteht die Gefahr, dass das Gesamtsystem an den ständig wachsenden Anforderungen kollabiert.
• Um den Entwicklerteams neben Dokumentationspflichten und Tests genügend Zeit für die Umsetzung zu lassen, sollten die Sprints nicht zu kurzzyklisch angelegt werden, sondern mindestens zwei bis vier Wochen betragen. Darüber hinaus sollten regelmäßige Demos dem Auftraggeber und anderen Stakeholdern die Möglichkeit geben, Feedback zur Art der Umsetzung zu geben und ggf. Anpassungen an den Anforderungen vorzunehmen.
• Bei produktiven Go-Lives sollten die Releasephasen des geplanten Systems mit denen anderer angebundener Systeme abgestimmt werden, um dort Störungen zu vermeiden. D.h. diese Produktivsetzungen zwischen den angebundenen Systemen sollten zeitlich und funktional abgestimmt werden.
• Feste Zeitpunkte innerhalb des Sprints, zu denen die Dokumentationsupdates bereitgestellt werden müssen, können helfen, die notwendige Dokumentationsdisziplin zu etablieren. Die Durchsetzung sollte in enger Zusammenarbeit zwischen dem Sprint Master und dem Validierer erfolgen.

Fazit: Wachsende Akzeptanz agiler Methoden

Agile Vorgehensweisen bieten in bestimmten Projektumgebungen auch für Softwareprojekte in der Pharma- und Medizintechnikbranche Vorteile - insbesondere in Form von schnellerem Feedback und schrittweiser Implementierung einzelner Softwarekomponenten. Ein geringerer Dokumentationsaufwand gehört jedoch nicht dazu. Eine effiziente und gleichzeitig GxP-konforme Validierung lässt sich jedoch bei entsprechenden Vorkehrungen auch mit agilen Methoden umsetzen.

Dass diese Kombination in Zukunft weiter an Bedeutung gewinnen könnte, zeigt auch die Ende 2022 veröffentlichte zweite Version des GAMP 5©-Leitfadens - dem Standardregelwerk für die Validierung computergestützter Systeme in der pharmazeutischen Industrie. Erstmals wird darin neben dem V-Modell auch der Einsatz von agilen Softwareentwicklungsmethoden empfohlen. Daneben sollen auch in dem gemeinsam von EMA und PIC/S veröffentlichten Konzeptpapier zur Revision des Annex 11^[1] Akzeptanzkriterien für agile Entwicklungsmethoden erarbeitet werden.

Damit ist das V-Modell als Basis für Validierungsvorgehen nicht mehr die einzige Regel. Was dies für die Mehrzahl der Softwareprojekte in diesem Bereich bedeutet, bleibt abzuwarten. Auf jeden Fall wird es sich in Zukunft lohnen, kritisch zu hinterfragen, welches Vorgehen für ein Projekt am besten geeignet ist.

^[1] https://www.ema.europa.eu/en/documents/regulatory-procedural-guideline/concept-paper-revision-annex-11-guidelines-good-manufacturing-practice-medicinal-products_en.pdf