Wie sich agiles Vorgehen und Softwareentwicklung nach GAMP5 (Good Automated Manufacturing Practise) vereinen lassen.
In vielen industriellen Branchen gelten besondere gesetzliche und regulatorische Bestimmungen, um die Produktqualität, die Risiken und die Wirkungen einer Software einschätzen und sicherstellen zu können. Ein solches sogenanntes “reguliertes Umfeld” ist die Pharmabranche bzw. der gesamte Gesundheitssektor als solches. Auch hier hat sich ein Vorgehen nahezu ausnahmslos verbreitet, dass sich “Good Automated Manufacturing Practice” nennt und mit GAMP5-Standard abgekürzt wird. GAMP5 stellt ein Regelwerk für automatisierbare Prozesse dar. Dazu gehört auch eine empfohlene Vorgehensweise für die Softwareentwicklung und Wartung. In der Regel sieht GAMP5 ein Vorgehen nach dem V-Modell vor, um die qualitätsgesicherte und dokumentierte Entwicklung, Wartung und den Betrieb im Rahmen eines Qualitätssicherungssystems abzubilden.
GAMP5-Regulatorien in der Softwareentwicklung
Ein wesentlicher Bestandteil des GAMP5 Standards ist es davon auszugehen, dass vor Beginn der Entwicklung sämtliche Anforderungen erfasst und dokumentiert sind, um im Fall von Problemen oder Schadensfällen Verantwortliche zu kontaktieren und Gegenmaßnahmen planen und später den Erfolg eines Projektes eindeutig messen und dokumentieren zu können.
Im Gegensatz zum Vorgehen nach GAMP5 ergibt ein agiles Projektmanagement mehr Freiheit in der kurzfristigen Planung und kann flexibler auf Änderungen und unerwartete Ereignisse reagieren. Darüber hinaus ist der Informationsfluss zwischen allen Beteiligten aufgrund der direkten Kommunikation deutlich schneller. Somit können Fehler früher entdeckt und beseitigt werden.
Da das Vorgehen nach GAMP im regulierten Umfeld hoch standardisiert ist und zwischen allen Beteiligten die erwartbaren Ergebnisse, die benötigte Zeit, das Vorgehen und die Kosten vorab klärt, hat dieses Modell unbestreitbare Vorteile für die Einhaltung von Compliance und Governance. Nachteil des V-Modells ist jedoch, dass es durch seine strikten Vorgaben und die geringe Flexibilität nur bedingt für den Entwicklungsprozess geeignet ist.
GAMP5-Regularien und agiles Vorgehen
Es spricht jedoch im GAMP5 Modell nichts dagegen, die Vorgehensweise des Entwicklungsteams agil zu gestalten. Durch Nutzung der Vorteile beider Modelle ergibt sich die Chance, insgesamt die Qualität und die Geschwindigkeit einer Entwicklung zu verbessern, ohne die Vorgaben der Regulierungsanforderungen zu verletzen.
Ein rein agiles Vorgehen im regulierten Umfeld hat den Nachteil, den gesamten Dokumentationsprozess neu implementieren zu müssen. Dies führt in der Praxis häufig zu erheblichen Aufwendungen für die Abstimmung und Freigabe. Diese Aufwendungen werden häufig unterschätzt und kosten das Projekt viele Ressourcen, die für die eigentliche Entwicklung und Qualitätssicherung dann nicht mehr zur Verfügung stehen.
Agile Softwareentwicklung im regulierten Umfeld – How To
Wenn es gelingt, die Vorteile des V-Modells und des agilen Vorgehens miteinander zu verbinden und die Nachteile so gering wie möglich zu halten, kann man die Qualität und die Entwicklungsgeschwindigkeit verbessern und dennoch die Vorgaben der Regulatorik einhalten. Grundsätzlich muss die Organisation des Projektes an die konkreten Anforderungen, die sich aus den Projektzielen ergeben, angepasst sein. Deshalb an dieser Stelle einige eher allgemeine Vorgehensweisen, die den Start in agile Softwareentwicklung im regulierten Umfeld erleichtern:
In den Entwicklerteams können agile Methoden eingesetzt werden
Die Erfahrung zeigt, dass Entwicklerteams produktiver und zufriedener sind, wenn sie organisatorisch aus dem starren Korsett des V-Modells herausgelöst sind und sich selbst organisieren dürfen. Hierbei ist das Softwaretesten ausdrücklicher Bestandteil des Arbeitens: DONE bedeutet dabei entwickelt, getestet und auch dokumentiert.
2. Alle anderen Teile des Projektes werden nach den Regeln des V-Modells organisiert.
Üblicherweise sind besonders in großen regulierten Organisationen die Projektmanagement-Richtlinien stark vorgegeben und nur mit erheblichem Aufwand in der Abstimmung veränderbar. In der Regel reichen die geplante Projektlaufzeit und die Budgetvorgaben dazu nicht aus.
3. Klare Kommunikationsschnittstellen zwischen den agilen und den herkömmlichen Teilprojekten mit Etablierung eines angepassten Rollenmodells
Da im V-Modell und in der agilen Vorgehensweise Verantwortungen unterschiedlich organisiert sind, sollte zum Projektstart eine Abstimmung über die Rollenverteilung, die Verantwortungen und die Kommunikationswege stattfinden. Ohne diese Abstimmung kommt es häufig zu Reibungsverlusten und Missverständnissen in der Kommunikation.
4. Abgeschlossene Requirements Engineering Phase und vollständig definierte Abnahmekriterien vor Beginn der Entwicklungstätigkeiten
Im V-Modell sind spätere Änderungen oder Ergänzungen der Requirements i.d.R. nur mit erheblichem organisatorischen Aufwand durchführbar. Eine Möglichkeit, den Konflikt zwischen rigidem V-Modell und flexiblem agilen Vorgehen zu lösen, kann darin bestehen, die Requirements und Abnahmekriterien so zu definieren, dass den Entwicklerteams ausreichend Freiheiten in der Umsetzung gewährt werden. Hier sind die Requirements Engineers besonders gefordert, die Balance zwischen belastbaren Anforderungen und flexibler Umsetzung herzustellen.
5. Überführung definierter und getesteter Releasestände vom Entwicklerteam an das Projekt
Eine gute Voraussetzung für ein gelungenes Projekt ist die klare Definition von Meilensteinen, deren Erreichung jeweils mit einem neuen Release für die höheren Teststufen einhergeht. Dies erleichtert u.a. die Kommunikation des Projektfortschritts und das Erwartungsmanagement des Gesamtprojektes.
6. Hohe Testfrequenz im Entwicklerteam, niedrigere Testfrequenz der anderen Teststufen
Idealerweise sollte im Entwicklerteam jeder Build-Process von einem automatisierten Testlauf abgeschlossen werden. Dies ist am einfachsten umzusetzen, wenn bereits im Source Code die Unit Tests von den Entwicklern angelegt werden. Je höher die Teststufe, umso seltener muss getestet werden, da die niedrigeren Teststufen bereits einen großen Teil der Qualitätsanforderungen sicherstellen. Hier hat es sich bewährt, eine möglichst vollständige Coverage der Unit Tests unter Berücksichtigung der identifizierten Risiken anzustreben.
7. Berücksichtigung der unterschiedlichen Geschwindigkeiten und Vorgehensweisen im Projektplan
Im Projektplan wird es mit hoher Wahrscheinlichkeit unterschiedliche Anforderungen an die Frequenz von Fortschritts- und Defektberichten geben, da die Entwicklerteams i.d.R. tägliche Builds mit Defect Reports generieren, während die anderen Tester vielleicht mit wöchentlichen oder monatlichen Releases und Reports arbeiten werden.
8. Das Testmanagement und die Freigabeprozesse müssen an die hybride Arbeitsweise angepasst werden
Im agilen Entwicklungsprozess sollte der Automatisierungsgrad des Testens sehr hoch sein und der Freigabeprozess an Meilensteinen orientiert werden. Je höher die Teststufe umso formaler und manueller wird das Testen ausfallen, was den Schwerpunkt des Testmanagements auf die Dokumentenvollständigkeit und die Organisation der Tests legt.
Unter Berücksichtigung dieser Schwerpunkte kann eine Einführung agiler Softwareentwicklung auch im regulierten Umfeld gelingen. Ein systematischer Ansatz ist dabei die Grundvoraussetzung, um agile Softwareentwicklungsmethoden unter Einhaltung der regulatorischen Anforderungen zu integrieren.
Wenn auch Du von unserer Expertise in regulierten Umfeldern profitieren möchtest, dann lass uns über Deine konkrete Herausforderung sprechen. Wir sind unter techtalk@trendig.com für Deine Anfrage erreichbar und freuen uns, mit Dir ins Gespräch zu kommen.
