Agile Softwareentwicklung für GxP-Systeme.
Agile Softwareentwicklung für GxP-Systeme verbindet iterative Lieferung mit nachweisbarer Compliance: Der Nachweis entsteht record-basiert in der Software Development Tool Chain - aus Anforderungen, Risikobewertungen und Testevidenz -, und jede Iteration bleibt prüffähig. Wir integrieren die regulatorischen Vorgaben so in Ihre agilen Workflows, dass die Vorteile der Agilität erhalten bleiben.
Agil entwickeln, GxP-konform nachweisen.
Oberflächlich betrachtet scheinen agile Prinzipien im Konflikt mit den geltenden GxP-Anforderungen zu stehen. Tatsächlich beschreibt GAMP 5 Second Edition, wie sich agile Methoden angemessen nachweisen lassen - über Standards für Epics und User Stories, integrierte Risikobewertungen und eine bewusst gewählte Software Development Tool Chain. Entscheidend ist der Perspektivwechsel: Der Nachweis wird nicht neben der Entwicklung erzeugt - er entsteht als Record in ihr.
Der GAMP Good Practice Guide "Enabling Innovation" (2021) hat diesen Weg vorgezeichnet, die Second Edition (2022) hat ihn in den Hauptleitfaden gehoben. So aufgesetzt senkt agile Entwicklung den Validierungsaufwand des computergestützten Systems - erforderlich sind spezialisierte Kenntnisse und die durchdachte Anpassung der agilen Methoden an die regulatorischen Anforderungen. Wie jede Iteration ihre Evidenz selbst trägt, zeigt der Sprint-Workflow.
Der GxP-konforme Iterations-Zyklus.
Agile Entwicklung im regulierten Umfeld liefert in kurzen Iterationen und hält dabei die regulatorischen Vorgaben nachweisbar ein. Risikobewertung und Nachweis gehören zum Zyklus selbst; die Computer Software Assurance (CSA) der FDA verfolgt denselben risikobasierten Ansatz.
- 1
Backlog & Anforderungen
Erhebung und Management der Anforderungen als Epics und User Stories - einschließlich regulatorischer und Security-Anforderungen - nach definierten Standards, mit klaren Rollen und Verantwortlichkeiten.
- 2
Sprint-Planung & Risikobewertung
Auswahl der User Stories für die Iteration und integrierte, risikobasierte Bewertung - die Risikobewertung wird Teil der Sprint-Planung, nicht ein separater Vorgang.
- 3
Implementierung in der Tool Chain
Umsetzung direkt in der Software Development Tool Chain - der Nachweis entsteht als Record aus der Entwicklung: Anforderungsstände, Pipeline-Läufe, Reviews.
- 4
Test & Verifizierung
Agile Teststrategie und Testplanung, automatisiert wie manuell, mit nachweisbarer Abdeckung der definierten Anforderungen je Iteration.
- 5
Review & Nachweis
Die Records der Iteration werden zum Sprint-Ergebnis zusammengeführt - vollständig rückverfolgbar und auditfähig, ohne nachgelagerte Doppelpflege in Dokumenten.
- 6
Release im validierten Zustand
Freigabe der Iteration, ohne den validierten Zustand zu verlieren - Inkremente werden kontrolliert und nachweisbar in den Betrieb überführt.
Agil oder Wasserfall im regulierten Umfeld.
Beide Modelle können GxP-konform betrieben werden. Der Unterschied liegt darin, wie Anforderungen, Risikobewertung und Nachweis über den Lebenszyklus verteilt werden - und wie schnell auf neue Erkenntnisse reagiert werden kann.
| Aspekt | Wasserfall | Agil (GxP-konform) |
|---|---|---|
| Anforderungen | Vorab vollständig festgelegt | Als Epics und User Stories, iterativ verfeinert |
| Lieferung | Einmalig am Ende des Projekts | In kurzen, lauffähigen Inkrementen je Sprint |
| Risikobewertung | Phasenweise, meist zu Projektbeginn | In jeden Sprint integriert, fortlaufend |
| Dokumentation | Als nachgelagerte, eigene Phase | Als Records aus der Tool Chain heraus, kontinuierlich |
| Umgang mit Änderungen | Aufwändiges Change-Verfahren | Eingeplant im nächsten Iterationszyklus |
| Validierungsaufwand | Hoch und gegen Projektende geballt | Verteilt über die Iterationen, getragen von laufend entstehender Evidenz |
Müssen die Tools selbst validiert werden?
Nein - Backlog-, Traceability- und Test-Tools sind keine GxP-Business-Anwendungen im eigentlichen Sinne. Die Werkzeuge der Entwicklung sind Infrastruktur-Software im Sinne von GAMP; die FDA ihrerseits behandelt unterstützende Test- und Automations-Tools als Software, die Produktion und Qualitätssystem unterstützt - nachweispflichtig, aber mit risikogerecht abgestufter Tiefe. Gefordert ist der dokumentierte Eignungsnachweis nach Intended Use - die Kontrolltiefe folgt dem Risiko der Aufgabe, die das Werkzeug übernimmt.
| Werkzeug | Kontrolltiefe nach Intended Use |
|---|---|
| Backlog- und Anforderungsmanagement | dokumentierter Eignungsnachweis und Basis-Kontrollen für Zugriff und Versionierung - hier entstehen Epics und User Stories |
| Traceability und Test-Management | kontrollierte Workflows: Die Verknüpfung von Anforderung, Risiko und Testevidenz im Werkzeug trägt die Rückverfolgbarkeit |
| Automatisierte Tests für risikoreiche Software | höchste Kontrolltiefe: verifizierte Prüf-Workflows und geschützte, verfügbare Records über die gesamte Aufbewahrungsfrist |
Was früher im Dokument stand, liegt jetzt im Werkzeug: Anforderungsstände, Risikobewertungen, Testergebnisse. Damit greifen die Anforderungen an die Datenintegrität auf die in den Tools geführten Daten: Sie müssen geschützt, verfügbar und über die Aufbewahrungsfristen erhalten bleiben - hier liegt die eigentliche Sorgfaltspflicht, nicht in einer Validierung des Werkzeugs.
Agile Entwicklung - regelkonform begleitet.
Wir wenden GAMP 5 nicht nur an - wir haben daran mitgearbeitet.
QFINITY hat an GAMP 5 Second Edition im Kernteam mitgewirkt - dem Industriestandard, der beschreibt, wie agile und iterative Entwicklung im regulierten Umfeld angemessen nachgewiesen wird.
Vorgezeichnet hat diesen Weg der GAMP Good Practice Guide "Enabling Innovation" (2021): Critical Thinking, agile Methoden, Records in Tools statt nachgelagerter Dokumente. Die Second Edition (2022) hat diese Prinzipien in den Hauptleitfaden gehoben - beide Werke wirken zusammen, von Scrum über das Scaled Agile Framework (SAFe) bis zu Continuous Integration und Continuous Delivery (CI/CD).
Häufige Fragen zur agilen Entwicklung im GxP-Umfeld.
Ja. Kein Regelwerk schreibt ein Entwicklungsmodell vor; gefordert ist der nachweisbare, risikobasierte Umgang mit Anforderungen, Risiken und Tests. Wie sich agile Ansätze angemessen nachweisen lassen, beschreibt GAMP 5 Second Edition - über Standards für Epics und User Stories, integrierte Risikobewertungen und eine kontrollierte Software Development Tool Chain.
Nein - die Tools der Software Development Tool Chain sind keine GxP-Business-Anwendungen, sondern Infrastruktur-Software; gefordert ist ein dokumentierter Eignungsnachweis nach Intended Use, mit Kontrolltiefe nach Risiko. Besondere Aufmerksamkeit gilt den Records in den Tools: Sie sind der Nachweis und müssen geschützt, verfügbar und über die Aufbewahrungsfristen erhalten bleiben.
Beide wirken zusammen: Der Good Practice Guide (2021) hat die Methodik ausgearbeitet - Critical Thinking, agile Workflows, Records in Tools statt nachgelagerter Dokumente. GAMP 5 Second Edition (2022) hat diese Prinzipien in den Hauptleitfaden gehoben: Anforderungen als Epics und User Stories, integrierte Risikobewertung, Testevidenz aus den Werkzeugen. GAMP ist dabei Methodik, kein Regelwerk - er beschreibt den Weg, die Anforderungen kommen aus den Regularien.
Richtig aufgesetzt: ja. Entsteht der Nachweis als Record in der Tool Chain, verteilt sich der Aufwand über die Iterationen, und die Evidenz liegt bei der Freigabe bereits vor. Validiert wird das computergestützte System im Prozess - die agile Entwicklung liefert die Evidenz dafür kontinuierlich zu.
Agil entwickeln, validierten Zustand sichern.
Wir verzahnen Ihr agiles Entwicklungsmodell mit Anforderungsstandards, integriertem Risikomanagement und einer GxP-konformen Tool Chain - so sinkt der Validierungsaufwand, statt am Projektende zu kumulieren. Im Erstgespräch klären wir, wo Ihre Sprints regulatorische Nachschärfung brauchen. Kostenfrei, etwa 30 Minuten.
Erstgespräch vereinbaren
