Das EXCO CSV-Glossar – Prägnante Begriffsdefinitionen aus der Welt der Validierung

Im Rahmen des GxP-Umfelds und dieses Frameworks gibt es zwei besondere Sprints:

• Vorbereitungs-Sprint (erster Sprint)
• Abschluss-Sprint / Release-Sprint (letzter Sprint)

Im Abschluss-Sprint werden alle notwendigen Berichte erstellt und finalisiert, die vor dem Go-Live eines Systems benötigt werden, wie z.B. eine SOP zur Nutzung des Systems, ein Business Continuity Plan, der Validierungsbericht und das Validierungsinventar. Der Abschluss-Sprint sorgt zudem dafür, dass Arbeitsergebnisse, Materialien, Hilfsmittel und Werkzeuge für ein nächstes Release oder ein anderes Projekt wieder verwendet werden können und ordnungsgemäß archiviert werden. Zudem werden im Abschluss-Sprint Trainings für die Nutzung des neuen Systems durchgeführt und alles getan, damit der Go-Live möglichst reibungslos verläuft.

Im Rahmen des Agilen Validierungsframeworks wurde dazu die SOP Lebenszyklus computergestützter Systeme (SWLC) erstellt.

Siebzehn Personen (Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland und Dave Thomas) definierten auf einer Konferenz in Utah vom 11. bis 13. Februar 2001 die wichtigsten Werte der Softwareentwicklung als Agiles Manifest (Manifesto for Agile Software Development).

Agile Leitsätze

Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

• Individuen und Interaktionen mehr als Prozesse und Werkzeuge.
• Funktionierende Software mehr als umfassende Dokumentation.
• Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung.
• Reagieren auf Veränderung mehr als das Befolgen eines Plans.

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.
(Quelle: Manifest für Agile Softwareentwicklung)

Agile Prinzipien

Außerdem wurden die zwölf agilen Prinzipien aufgelistet:

Wir folgen diesen Prinzipien:

Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.

• Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.
• Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.
• Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.
• Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.
• Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.
• Funktionierende Software ist das wichtigste Fortschrittsmaß.
• Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.
• Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.
• Einfachheit -- die Kunst, die Menge nicht getaner Arbeit zu maximieren -- ist essenziell.
• Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbst organisierte Teams.
• In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.

(Quelle: Manifest für Agile Softwareentwicklung)

ALCOA

A)ttributable
Bei jedem Dokument muss erkennbar sein, wer der Autor und wer der Eigentümer des Dokumentes ist. Nur wenn ein Dokument zuweisbar ist, sind die Verantwortlichkeiten dafür klar.

L)egible
Jedes Dokument muss in allen Teilen lesbar sein. Dies bedeutet, dass jegliche Inhalte (gerade auch Abbildungen) scharf sein müssen. Falls das Dokument manuell erzeugt wurde, dann muss die Handschrift gut lesbar sein.

C)ontemporaneous
Vor allem für Aufzeichnungen gilt, dass diese zeitnah während und nach der Ausführung der dokumentierten Tätigkeiten erfolgen müssen. Dies wird beispielsweise durch einen Datums- und Zeitstempel belegt.

O)riginal
Nur Originale, nicht jedoch Kopien sind erlaubt. Jeder Ausdruck einer solchen Datei wird als ungültige Kopie bewertet.

A)ccurate
Sämtliche Inhalte der Dokumente müssen akkurat also korrekt sein. Dies beinhaltet auch, dass eine Überprüfung auf Korrektheit stattgefunden hat.

+(Complete, Consistent, Enduring, Available)

Complete
Jedes Dokument muss in sich vollständig sein und darf keine Lücken haben.

Consistent
Jedes Dokument und alle Inhalte im Dokument müssen konsistent sein, dürfen also zu anderen Dokumenten oder innerhalb des Dokumentes keine Widersprüche aufzeigen. Auch die Abfolge mehrerer Datums- und Zeitstempel muss widerspruchsfrei sein.

Enduring
Das Dokument muss dauerhaft aufbewahrt werden, dies gilt sowohl für Papierformate (beispielsweise sind Thermopapiere nicht dauerhaft), als auch für elektronische Formate (beispielsweise dürfen Inhalte nicht in flüchtigen bzw. überschreibbaren Speichern aufgehoben werden).

Available
Das Dokument muss (für Befugte) verfügbar sein.

+ Traceable

Traceable
Alle Daten in einem Dokument müssen rückverfolgbar über den gesamten Prozess bzw. Lebenszyklus des Dokumentes sein, inklusive aller daran durchgeführten Änderungen.

APIs ermöglichen den Zugriff auf Datenbanken, User Interfaces, andere Funktionalitäten und vereinfachen damit die Modularisierung von komplexeren Systemen.

Eine spezielle Form einer API, eine REST-API (Representational State Transfer API) sorgt dabei für den Datenaustausch verteilter Systeme - vor allem bei Web Anwendungen.

Die Validierung von APIs benötigt die Durchführung von Integrationstests und wird in der Regel von Spezialisten durchgeführt.

Ein Artefakt kann zur Projektdokumentation oder zur Systemdokumentation gehören oder ein sonstiges Arbeitsergebnis sein. Für die wichtigsten Artefakte wird in einer Rollen & Verantwortlichkeits-Matrix geregelt, wer welches Artefakt erstellt, prüft oder freigibt.

Acceptance test-Driven Development oder auch abnahmetestgetriebene Entwicklung bezeichnet einen kollaborativen Ansatz in der Entwicklung von Systemen, bei der das Team die Anforderungen (meist User Stories) zusammen mit den Akzeptanzkriterien im Jargon des Kunden dokumentiert und damit die zugehörigen Testfälle vor dem Schreiben des Codes erstellt. Dabei werden häufig Satzschablonen genutzt.

Diese Vorgehensweise ist verwandt mit BDD.

Ein Audit kann intern durchgeführt werden, um

• Audits durch Auftraggeber oder Behörden vorzubereiten und um
• Stärken und Schwächen und damit Verbesserungspotentiale zu identifizieren.

Audits werden auch von einem Unternehmen bei seinen Zulieferern durchgeführt, um den Lieferanten zu bewerten und die Eignung als Lieferant im regulierten Bereich zu bewerten.

Ein Audit bewertet immer die vorhandenen Prozesse (entsprechend der vorab durchgeführten Auditplanung) anhand der Systemdokumentation und anhand der Aussagen der Beteiligten. Das Prinzip der “two sources of evidence” muss dabei eingehalten werden. Ein Auditbericht fasst die Ergebnisse des Audits zusammen, listet alle Befunde auf und bewertet diese nach einem vorab festgelegtem Maßstab.

Audits können in einer vereinfachten Version als Gap-Analyse durchgeführt werden. Sie sind dann meist weniger formal, verzichten manchmal auf die Bewertung von Schwächen und begnügen sich gelegentlich auch mit den unbelegten Aussagen der Teilnehmenden, sofern es eine offene und fehlerbejahende Gesprächskultur gibt.

Auditberichte enthalten eine Liste von Mängeln. Je nach Schweregrad werden diese durch ein weiteres Audit (Re-Audit) erneut überprüft.

Werden Audits gegen eine Norm oder einen Standard durchgeführt, dann wird dies auch häufig als Assessment bezeichnet.

Der Außerbetriebnahme-Bericht wird nach der Beendigung der Stilllegung - bei mehreren Phasen der Stilllegung auch mehrmals - erstellt.

Er dokumentiert alle gemäß dem Plan und der Risikoanalyse durchgeführten Aktivitäten und Maßnahmen und beschreibt Abweichungen vom Plan und offene Punkte.

Im Rahmen des Agilen Validierungsframeworks wurde dazu die SOP Außerbetriebnahme computergestützter Systeme erstellt.

Der Außerbetriebnahme-Plan und die Außerbetriebnahme-Risikoanalyse sind bei der Planung einer Stilllegung möglichst frühzeitig zu erstellen. Die Phase der Außerbetriebnahme kann mehrere Teilphasen beinhalten, wie beispielsweise eine Zeit des Nur-Lese-Zugriffs und eine anschließende vollständige Stilllegung. Entsprechend gibt es bei länger dauernden Phasen häufig auch mehrere Versionen des Außerbetriebnahme-Plans.

Im Rahmen des Agilen Validierungsframeworks wurde dazu die SOP Außerbetriebnahme computergestützter Systeme  erstellt.

Der Außerbetriebnahme-Plan und die Außerbetriebnahme-Risikoanalyse sind bei der Planung einer Stilllegung möglichst frühzeitig zu erstellen. Die Phase der Außerbetriebnahme kann mehrere Teilphasen beinhalten, wie beispielsweise eine Zeit des Nur-Lese-Zugriffs und eine anschließende vollständige Stilllegung.

Die Risikoanalyse betrachtet alle mit der Stilllegung des Systems einhergehenden Risiken und zur Mitigation notwendigen Maßnahmen. Diese berücksichtigen beispielsweise auch eine Phase, in der das System nur eingeschränkt (meist nur lesend) genutzt werden darf, sowie die vollständige Löschung des Systems und Entfernung aller Daten.

In der Risikoanalyse müssen auch die regulatorischen und gesetzlichen Aufbewahrungspflichten betrachtet werden.

Bei länger dauernden Phasen entstehen mehrere Versionen der Außerbetriebnahme-Risikoanalysen, da einzelne Risiken bereits mitigiert wurden oder nicht mehr auftreten können, während über den zeitlichen Verlauf häufig neue hinzukommen. Dies betrifft insbesondere die Aufrechterhaltung von Read-only-Zugriffen über einen langen Zeitraum, in dem sich typischerweise die genutzten Versionen von Betriebssystemen, Datenbanken und Softwaresystemen ändern, aber auch notwendige Hardware möglicherweise nicht mehr verfügbar ist.

Im Rahmen des Agilen Validierungsframeworks wurde dazu die SOP Außerbetriebnahme computergestützter Systeme  erstellt.

Der Umgang mit Verbesserungsvorschlägen, Fehlern und anderen Arten von Änderungen an GxP-relevanten computergestützten Systemen, die entwickelt oder konfiguriert werden, muss in einer SOP geregelt werden.

Im Rahmen des Agilen Validierungsframeworks wurde dazu die SOP Änderungslenkung computergestützter Systeme erstellt.

Die Lenkung der Änderungen sorgt dafür, dass für jede Änderung die Auswirkungen auf das System selbst, auf seine Systemdokumentation und auf den vorgesehenen Zweck (Intended Use) analysiert und bewertet werden und die Änderung adäquat eingeplant und durchgeführt werden kann. Vor allem für GxP-relevante Systeme ist die Änderungslenkung wichtig, um sicherzustellen, dass das System weiterhin einen validierten Zustand hat.

Der Umgang mit Verbesserungsvorschlägen, Fehlern und anderen Arten von Änderungen an GxP-relevanten computergestützten Systemen, die entwickelt oder konfiguriert werden, muss in einer SOP geregelt werden.

Im Rahmen des Agilen Validierungsframeworks wurde dazu die SOP Änderungslenkung computergestützter Systeme erstellt.

Für jedes Release, das zur Nutzung freigegeben werden soll, muss eine Baseline erstellt und im Projektordner abgelegt werden. Der Baseline müssen alle zu diesem Release gehörenden Artefakte aller Plattformen zugeordnet und dauerhaft gesichert werden. Erst mit der Erzeugung der Baseline gilt die Systemdokumentation als final.

Eine Überarbeitung der zu einem Release gehörenden Artefakte ist nur mit einer neuen Version erlaubt, ohne dass die zur Baseline gehörende Version verändert wird.

Eine Baseline umfasst u.a.

• das fortgeschriebene Validierungsinventar
• den Installations-Qualifizierungsbericht für die Testumgebung
• die überprüfte Verfolgbarkeits-Matrix
• die User Akzeptanz Tests
• die Release Notes, inklusive aller Änderungen
• die aktualisierte Version der Systemdokumentation
• das Zugriffskonzept
• sämtliche Dokumente, die für die Phase der Nutzung und Wartung notwendig sind
• die erzeugten Software-Komponenten
• den Installations-Qualifizierungsbericht für die Produktivumgebung
• die finalen Abnahmetests auf der Produktivumgebung
• den Testbericht
• den Validierungsbericht
• die Dokumentation der Freigabe des Releases/der Konfiguration für den produktiven Einsatz.

Das Validierungsinventar listet diese Systemdokumentation mit Version, Gültigkeitsdatum, Ablageort und eventuellen Kommentaren auf.

Alle in den genutzten Systementwicklungsumgebungen erzeugten Artefakte (Code, Konfigurationsdateien, Parametrisierungen, …) werden ebenfalls eingefroren und mit dem gleichen Namen der Baseline bezeichnet.

Behavior-Driven Development oder auch verhaltensgetriebene Entwicklung bezeichnet einen kollaborativen Ansatz in der Entwicklung von Systemen, bei der das Team den Schwerpunkt auf die Lieferung des erwarteten Verhaltens einer Komponente oder eines Systems für den Kunden legt. Dabei werden Testfälle zum Verhalten der Anwendung dokumentiert bevor Code geschrieben wird.

Diese Vorgehensweise ist verwandt mit ATDD.

Benutzungs-Anleitungen sind häufig aufgabenbezogen geschrieben und sprechen die Leserinnen und Leser direkt an. Mit Hilfe eines Index lassen sich relevante Textstellen leichter auffinden.

Während SOPs zur Nutzung von Systemen vor allem die Prozesse beschreiben, die von den Nutzerinnen und Nutzern verpflichtend durchzuführen sind, beschreiben Benutzungs-Anleitungen typischerweise weitere Anwendungsfälle und ergänzen diese um hilfreiche Details, FAQs, Tipps & Tricks, mögliche Fehlerquellen und ihre Beseitigung sowie Beispiele.

Eine Benutzungs-Anleitung kann ein schriftliches (meist stark mit Grafiken ergänztes) Dokument sein, aber auch in digitaler Form erfolgen, beispielsweise

• als Online-Hilfe,
• als aufrufbare (meist kurze) Videosequenzen,
• als Funktionalität innerhalb der Software, die Nutzerinnen und Nutzer direkt an die jeweiligen Stellen führt und dort das System erklärt (häufig als “Show me” Funktion) oder
• als Chat-Bot.

Der Bericht zur periodischen Überprüfung enthält unter anderem

• Informationen zur Durchführung der periodischen Überprüfung wie
1. System inklusive Versionsstand und Ablageort der Systemdokumentation
2. Teilnehmende
3. Durchführungszeitraum
• Bewertung der einzelnen Prüfpunkte mit Dokumentation der Nachweise bei Erfüllung und bei Abweichungen
• Gesamt-Bewertung des Systems bezüglich des weiterhin validierten Zustands und der Auditfähigkeit

Der Systemeigner muss für alle Systeme ein Betriebshandbuch einfordern, das unter anderem folgendes dokumentiert:

• Service- und Supportstrategie
• SLAs / OLAs
• Systemzeit
• Monitoring und Kapazitätsmanagement
• Periodische und kontinuierliche Überprüfungen
• Nutzerkonten und Zugriffsrechte
• Sicherheit
• Systemadministration
• Job Management
• Archivierung von Daten
• Backup & Restore
• Dokumentenmanagement
• Außerbetriebnahme

Im Rahmen des Agilen Validierungsframeworks wurde dazu die SOP Lebenszyklus computergestützter Systeme (SWLC) erstellt.

Zu Beginn der Blackout-Phase wird das System für die normale Nutzung (nach einer entsprechend frühzeitigen Ankündigung gemäß Außerbetriebnahme-Plan) gesperrt. In der Blackout-Phase werden dann die Vorbereitungen für die nachfolgende Read-Only-Phase (falls vorgesehen) oder der Stilllegungs-Phase durchgeführt wie beispielsweise:

• Archivierung von Daten.
• Backup aller Daten.
• Portierung auf andere Hardware.
• Überarbeitung der Zugriffsrechte (in der Regel Einschränkung auf wenige Nutzerinnen und Nutzer mit ausschließlich Read-Only-Zugriff und sehr wenige administrative Zugänge).

Fallen Systeme aus oder sind nur noch eingeschränkt verfügbar, werden die Geschäftsprozesse davon meist unmittelbar betroffen sein. Für diese Fälle werden in einem Business Continuity Plan mögliche Ausfallszenarien beschrieben und Maßnahmen definiert, die dann erfolgen sollen.

Dies können beispielsweise sein:

• Bis zu einer festgelegten Dauer Geschäftsprozesse nicht mehr durchführen (meist nur für wenige Stunden).
• Alternative Systeme benutzen.
• Mit papierbasierter Dokumentation arbeiten.
• In allen Fällen muss geregelt sein, wie der Wiederanlauf des Systems durchgeführt wird und wie und durch wen Daten nachgetragen werden.

Für jedes System sollten die Teilnehmenden des Change Control Boards (CCB) festgelegt werden. Diese bestehen immer mindestens aus dem Systemeigner, dem Prozesseigner und dem IT-Qualitätsbeauftragten.

Weitere Personen könnten sein: Testmanagement und Validierungsleitung, sofern diese Rollen zum Zeitpunkt des Änderungsantrages besetzt sind.

Im Rahmen des Agilen Validierungsframeworks wurde dazu die SOP Änderungslenkung computergestützter Systeme erstellt.

Ein Code ist die schriftliche Anleitung eines Programmierers oder Entwicklers, in der die Informationen und Aktivitäten aufgeführt sind, die zur Ausführung einer Aufgabe erforderlich sind.

Um diese Codes zu schreiben oder zu erstellen, verwenden die Entwickler verschiedene Programmiersprachen, darunter:

• C
• C++
• HTML
• Java
• JavaScript
• PHP
• Python
• Ruby
• Rust
• SQL

In den meisten Fällen hängt die von den Entwicklern gewählte Programmiersprache für die Erstellung eines Codes vom erwarteten Ergebnis der Arbeit sowie von den Kenntnissen des Entwicklers ab.

Anforderungen werden aufgestellt durch übergeordnete Gesetze/Regularien seitens:

• Gesetzgeber
• Aufsichtsbehörden
• Normierungsgremien

Beispiele für entsprechende Behörden sind:

• Bundesministerien für Gesundheit und Ernährung, Landwirtschaft und Verbraucherschutz (Arzneimittel und Wirkstoffherstellungsverordnung AMWHV, Arzneimittelgesetz AMG).
• Europäische Gesundheitsbehörde EMA European Medicine Agency (Europäisches Arzneimittel Gesetz EudraLex, MDR).
• Amerikanische Gesundheitsbehörde FDA Food and Drug Administration.

Diese Gesetze und Verordnungen werden dann firmenintern heruntergebrochen auf Standards und Vorschriften (Standard Operation Prozedur SOP, Arbeitsanweisung AA). Die Einhaltung der Regularien ist eine Handelsvoraussetzung für Arzneimittel und Medizinprodukte. Ein Produkt darf nur dann verkauft werden, wenn sich dies mit den Gesetzen des Verkaufslandes vereinbaren lässt.

Computergestützte Systeme (CS abgekürzt) umfassen beispielsweise auch Arbeitsanweisungen, Personal und Ausrüstung als Teil der Funktion oder des Prozesses.

Zur Erzielung und Einhaltung der Konformität mit den anzuwendenden GxP-Vorschriften und der Eignung für den vorgesehenen Zweck müssen diese validiert werden.

Hardware und Software sind die beiden Hauptbestandteile eines Computersystems. Hardware sind die physischen und sichtbaren Komponenten des Computers.

Das Funktionieren eines computergestützten Systems wird durch eine Reihe von Hardwarekomponenten des Computersystems ermöglicht. Jede dieser Komponenten erfüllt eine individuelle Aufgabe, die das Funktionieren des Computersystems als Ganzes erforderlich macht. Einige dieser Hardware-Komponenten sind

• Hauptplatine
• Zentrale Verarbeitungseinheit (CPU)
• Speicher mit wahlfreiem Zugriff (RAM)
• Festplatte (HDD) oder Solid-State-Laufwerk (SSD)
• Grafikkarte
• Netzgerät

Software ist ein Satz von Anweisungen, die auf dem Computer laufen und die Hardware in die Lage versetzen, bestimmte Aufgaben zu erfüllen.

Im Rahmen des Agilen Validierungsframeworks umschreibt die Abkürzung CSV den dokumentierten Prozess zur Validierung von computergestützten Systemen, der nachvollziehbar, konsistent und wiederholbar nachweist, dass das CS den vorgesehenen Zweck erfüllt.

Zur Definition von CSV als Comma-Separated Values erfahren Sie mehr in Wikipedia.

Der Zweck des Daily Scrums besteht darin, den Fortschritt in Richtung des Sprint‐Ziels zu überprüfen und das Sprint Backlog bei Bedarf anzupassen, um die bevorstehende geplante Arbeit zu justieren.

Das Daily Scrum ist ein 15‐minütiges Event für die Developer des Scrum Teams. Um die Komplexität zu reduzieren, wird es an jedem Arbeitstag des Sprints zur gleichen Zeit und am gleichen Ort abgehalten. Falls der Product Owner oder der Scrum Master aktiv an Einträgen des Sprint Backlogs arbeitet, nimmt er als Developer teil.

Die Developer können Struktur und Techniken beliebig wählen, solange ihr Daily Scrum sich auf den Fortschritt in Richtung des Sprint‐Ziels fokussiert und einen umsetzbaren Plan für den nächsten Arbeitstag erstellt. Das schafft Fokus und fördert Selbstmanagement.

Daily Scrums verbessern die Kommunikation, identifizieren Hindernisse, fördern die schnelle Entscheidungsfindung und eliminieren konsequent die Notwendigkeit für andere Meetings.

Das Daily Scrum ist nicht die einzige Gelegenheit, bei der die Developer ihren Plan anpassen dürfen. Sie treffen sich oftmals während des Tages für detailliertere Diskussionen zur Anpassung oder Neuplanung der restlichen Arbeit des Sprints.
(Quelle: 2020-Scrum-Guide)

Für Systeme, die außer Betrieb genommen werden, existiert die Rolle des Daten-Eigners, der Eigentümer aller Prozesse und Daten des stillzulegenden Systems ist.

Die Rolle Daten-Eigner ist verantwortlich für:

• Adäquate Wartung,
• Integrität,
• Archivierung und
• Nutzung

der Prozesse und Daten nach dem regulären Betrieb des Systems im Rahmen der bestehenden Gesetze, Regularien und Verordnungen für den gesamten restlichen Lebenszyklus des Systems bis zur finalen Stilllegung und bis zur endgültigen Vernichtung von Daten und System.

Die Verantwortlichkeit beinhaltet auch die Delegation von Tätigkeiten im Rahmen des Daten-Managements und schließt die formale Dokumentation der Delegation in Form von SLAs, Verträgen, Betriebshandbüchern oder ähnlichen Dokumenten ein.

Der Daten-Migrations-Bericht dokumentiert die Durchführung des Daten-Migrations-Planes und eventueller Abweichungen.

Werden in ein neues System Daten aus einem Vorgänger-System übertragen, so muss die Migration dieser Daten in einem Daten-Migrations-Plan beschrieben werden.

Die wichtigsten Inhalte des Migrations-Planes sind

• Beschreibung der Algorithmen und Werkzeuge zur Migration der Daten inklusive notwendiger Anpassung der Daten an das neue System wie beispielsweise Konversionen von Datentypen, Strukturen und Ähnlichem.
• Qualitätssichernde Maßnahmen zur Überprüfung der migrierten Daten.
• Vorgehensweisen zur Wiederherstellung des Datenbestandes bei fehlgeschlagener Migration.
• Archivierungskonzept der alten Daten vor allem bei Veränderung oder Löschung eines Teils der Daten während der Migration.

Während der Durchführung dynamischer Tests oder der Nutzung der Systeme stellen Tester und Nutzer häufig Abweichungen von dem erwarteten Verhalten des Systems fest. Meist handelt es sich dabei um tatsächliche Fehlerwirkungen, die dann als Defects in einem entsprechenden Werkzeug eingetragen werden. Zu jedem Defect sollte außerdem ein Verweis auf den jeweiligen Test und die zugehörige Anforderung erfolgen, um die Verfolgbarkeit herzustellen.

Werden in einem Review oder anderen statischen Tests Fehlerzustände aufgedeckt, dann können diese ebenfalls als Defect aber auch in einem separaten Reviewprotokoll dokumentiert werden.

Defects werden mit Hilfe eines Werkzeugs wie beispielsweise Jira erstellt und bearbeitet.

Das Glossar des ISTQB verwendet den Begriff defect ausschließlich für Fehlerzustände, Fehlerwirkungen werden als failure bezeichnet.
In dem Kontext des agilen Validierungsframeworks geht es dagegen um die Bezeichnung des Vorgangstyps für alle Arten von Fehler, Anomalien, Auffälligkeiten, Bugs, …

Die Definition of Done enthält Kriterien zur Überprüfung jedes einzelnen Product Backlog Items (Product Backlog Eintrags, PBI).

Die Definition of Done ähnelt der Definition of Ready. Sie repräsentiert ein gemeinsames Verständnis des Scrum Teams, unter welchen Bedingungen ein Product Backlog Item als fertig bearbeitet bezeichnet werden kann. Sie enthält für gewöhnlich Qualitätskriterien, Einschränkungen und allgemeine nicht-funktionale Anforderungen, wie z.B. das Schreiben von Kommentaren und Design-Dokumenten. Mit zunehmender Erfahrung des Scrum Teams entwickelt sich die Definition of Done weiter. Sie enthält dann strengere Kriterien für höhere Qualität.

Die folgenden, standardisierten Kriterien sind typischerweise Bestandteil jeder Definition of Done:

• Alle definierten Akzeptanzkriterien für ein Product Backlog Item sind erfüllt.
• Alle Entwicklungsartefakte (z.B. Quellcode, Dokumente) sind im Versionskontrollsystem abgelegt.

Im Gegensatz zur Definition of Ready kann die Definition of Done vom Entwicklungsteam im Laufe des Projekts angepasst werden. Sie hilft dabei, zu Beginn eines Sprints die Anzahl und den Umfang der zu bearbeitenden Tasks festzulegen, wobei nicht alle Kriterien der Definition of Done auf jedes Product Backlog Item zutreffen müssen. Am Ende des Sprints dient die Definition of Done neben den Akzeptanzkriterien dazu, zu entscheiden, ob ein Product Backlog Item als fertig akzeptiert wird. Die Definition of Done muss schriftlich im Entwicklungsplan festgehalten werden.

In dem Moment, in dem ein Product‐Backlog‐Eintrag die Definition of Done erfüllt, wird ein Increment geboren.

Die Definition of Done schafft Transparenz, indem sie allen ein gemeinsames Verständnis darüber vermittelt, welche Arbeiten als Teil des Increments abgeschlossen wurden. Wenn ein Product‐Backlog-Eintrag nicht der Definition of Done entspricht, kann es weder released noch beim Sprint Review präsentiert werden. Stattdessen wandert es zur zukünftigen Berücksichtigung in das Product Backlog zurück.

Wenn die Definition of Done für ein Increment Teil der Standards der Organisation ist, müssen alle Scrum Teams diese als Mindestmaß befolgen. Wenn sie kein Organisationsstandard ist, muss das Scrum Team eine für das Produkt geeignete Definition of Done erstellen.

Die Developer müssen sich an die Definition of Done halten. Wenn mehrere Scrum Teams an einem Produkt zusammenarbeiten, müssen sie eine gemeinsame Definition of Done definieren und sich alle daran halten.
(Quelle: 2020-Scrum-Guide)

Die Definition of Done wird häufig mit der Definition of Ready definiert. Beide sind nicht als Quality Gates wie in den klassischen Projekten zu betrachten, da sie das Team unterstützen sollen, aber damit keine Freigabe verbunden sein darf.
Im GxP-Kontext sollte in der Definition of Done enthalten sein, dass eine ausreichende Dokumentation zu dem Product Backlog Item erfolgt ist, um eine Validierung zu ermöglichen.

Die Definition of Ready ist eine Liste von Kriterien hinsichtlich Qualität, Vollständigkeit, Präzision, Informationsgehalt, etc., die an die Product Backlog Items gestellt werden.

Die folgenden, standardisierten Kriterien sind typischerweise Bestandteil jeder Definition of Ready:

Alle Product Backlog Items müssen für jede projektbeteiligte Person verständlich beschrieben sein.
Die Product Backlog Items müssen klein genug sein, so dass sie vom Entwicklungsteam innerhalb eines Sprints umgesetzt werden können.
Jedes Product Backlog Item besitzt mindestens ein Akzeptanzkriterium.
Diese Kriterien können in der Projektinitialisierungsphase für jedes Projekt individuell ergänzt werden.

Nur wenn ein Product Backlog Item alle Kriterien erfüllt, darf es in das Sprint Backlog übernommen und dessen Umsetzung geplant werden. Verantwortlich für die Festlegung und Einhaltung der Definition of Ready ist der Product Owner. Dadurch wird ein hohes Maß an Transparenz und Klarheit erreicht, sodass das Entwicklungsteam Product Backlog Items effizient abarbeiten kann. Die Definition of Ready muss schriftlich im Entwicklungsplan festgehalten werden.

Die Definition of Ready wird häufig mit der Definition of Done definiert. Beide sind nicht als Quality Gates wie in den klassischen Projekten zu betrachten. Sie sollen das Team unterstützen, aber es darf damit keine Freigabe verbunden sein.
Im GxP-Kontext sollte in der Definition of Ready enthalten sein, dass eine gewisse Prüfung des Backlog Eintrags erfolgt ist bezogen auf die Regularien (insbesondere hinsichtlich ERES).

Design Spezifikationen und jegliche technische Dokumentation sind Dokumente, die während der Entwicklung entstehen und zumeist formlos als Confluence-Seiten abgelegt werden. Die Dokumentation sollte so ausführlich sein, dass geschulte Personen in der Lage sind, die Entwicklung des Systems durchzuführen, das System im Betrieb zu warten und das System weiterzuentwickeln.

Die spezifischen Fähigkeiten, die von den Developer benötigt werden, sind oft breit gefächert und variieren je nach Arbeitskontext. Die Developer sind jedoch immer ergebnisverantwortlich dafür,
● einen Plan für den Sprint zu erstellen, das Sprint Backlog;
● Qualität durch die Einhaltung einer Definition of Done einzubringen;
● täglich ihren Plan zur Erreichung des Sprint‐Ziels anzupassen; und
● sich wechselseitig als Expert zur Verantwortung zu ziehen.
(Quelle: 2020-Scrum-Guide)

Was nicht dokumentiert wurde, ist auch nicht durchgeführt worden!
Zur Dokumentation zählen folgende Dokumentarten:

• Vorgabedokumente (z. B. Arbeitsanweisungen, SOP etc.) und Vorlagen müssen geprüft und nach betriebsinternen Verfahren genehmigt sein. Die Aktualität und Richtigkeit sollten regelmäßig überprüft werden.
• Nachweisdokumente in Papierform (z. B. Aufzeichnungen, Projektdokumentation etc.). Sie müssen dokumentenecht sein und wiederauffindbar aufbewahrt bzw. archiviert werden. Außerdem sollten sie sich eindeutig auf die ihnen zugrunde liegenden Vorgabedokumente beziehen.
• Nachweisdokumente in elektronischer Form müssen unveränderbar sein und wiederauffindbar aufbewahrt bzw. archiviert werden. Beispielsweise dürfen sie nicht für jeden ohne Sicherheitsabfrage löschbar sein.
• Aufzeichnungen müssen eindeutig, vollständig und nachvollziehbar sein und sie müssen mit den tatsächlich durchgeführten Tätigkeiten übereinstimmen.
  Alle Dokumente unterliegen einem Lebenszyklus. Der jeweilige Status muss dabei für jedes Dokument klar ersichtlich sein, um die jeweilige Gültigkeit erkennen zu können.

Im Agilen Validierungsframework wird die Dokumentation des CS (Nachweisdokumente und Aufzeichnungen) zudem unterschieden in

• Systemdokumentation und
• Projektdokumentation.

Der Entwicklungsplan erfolgt beispielsweise in einem separaten Dokument, der in einem Projektverzeichnis abgelegt wird, im ALM-System (beispielsweise Jira oder ADO) oder in einem gemeinsam genutzten Wiki (beispielsweise Confluence).

Im Rahmen dieses Frameworks wird dafür Confluence genutzt.

Die Entwurfsqualifizierung oder Designqualifizierung wird meist mit DQ (Design Qualification) abgekürzt und umfasst alle Aktivitäten zur Überprüfung des Design eines Systems. Hierbei werden zumeist die ursprünglichen Anforderungen des Auftraggebers mit dem Design des Auftragnehmers verglichen. Hilfreich ist dabei die Traceability-Matrix.

Im Rahmen der Validierung eines computergestützten Systems werden Entwurfsprüfungen an verschiedenen Stellen des Prozesses durchgeführt. Dazu zählen insbesondere Verifikationen wie:

• Pairing (d.h. gleichzeitiges gemeinsames Arbeiten meist durch zwei Entwickler oder einem Entwickler und einem Tester oder einem Entwickler und einem Fachexperten mit dem Ziel, dass die zweite Person unmittelbar Rückmeldungen zu den Arbeitsergebnissen und deren Qualität gibt).
• Formale Reviews (d.h. die Prüfung durch einen oder mehrere Gutachter wird protokolliert).
• Prüfung der Definition of Ready (DoR) und der Definition of Done (DoD).
• Vorab-Abnahme der Inhalte eines Release in einem Sprint-Review.
• Finale Abnahme der Inhalte eines Releases nach erfolgten Benutzer-Akzeptanztests.

Eine eigene Phase Entwurfsqualifizierung gibt es im Rahmen des Agilen Validierungsframeworks nicht.

Epics werden in natürlicher Sprache formuliert und sind Anforderungen auf einer höheren, noch nicht umsetzbaren Ebene. Sie werden häufig ohne weitere Vorgaben definiert, manchmal aber auch identisch zu User Stories.

Epics sind in der Standard-Konfiguration von Jira die oberste Hierarchie-Ebene aller Vorgangstypen. Sie dienen zur Organisation der einzelnen Elemente wie:

• Stories
• Tasks
• Tests
• Defects

Epics gehen zeitlich über mehrere Sprints und können so auch zur zeitlichen Einplanung (beispielsweise in Roadmaps in Jira) verwendet werden.

Eine Aufzeichnung im GxP-Kontext meint eine Dokumentation in physischer, elektronischer oder hybrider (also auf Papier und elektronisch) Form, die nachweisen, dass eine bestimmte geforderte Aktivität tatsächlich durchgeführt wurde oder bestimmte Anforderungen der Regulatorik eingehalten wurden.

Während physische Aufzeichnungen häufig das manuelle Schreiben von Informationen beispielsweise in einem Logbuch oder das manuelle Ausfüllen von Checklisten beinhaltet, geht es bei elektronischen Aufzeichnungen um Daten in einem System.

Werden diese Daten zusätzlich unterschrieben und mit einem Zeitstempel versehen, spricht man von einer Elektronischen Signatur.

An Elektronische Aufzeichnungen und elektronische Signaturen werden in der Europäischen Union über EudraLex Volume 4—GMP Guidelines, Annex 11 und in den USA (und weltweit) über die Anforderungen der FDA in CFR Title 21 Part 11 geregelt. Diese müssen zusammen mit allen anderen Anforderungen erstellt, umgesetzt und geprüft werden. Dazu gibt es im Agilen Validierungsframework eine Reihe von Templates für User Stories, die auf diesen beide Regularien basieren und nur noch entsprechend dupliziert und angepasst werden müssen.

Die Produkt-Risikoanalyse wird in vielen Unternehmen funktionale Risikoanalyse genannt, allerdings sollten nicht-funktionale Risiken ebenso betrachtet werden wie jegliche funktionale Risiken, daher wird im Agilen Validierungsframework der Begriff FRA nicht genutzt.

FTEs sind eine rechnerische Größe im Personalwesen und in der Projektplanung und -steuerung zur Darstellung der sich rechnerisch ergebenden Vollzeitstellen in einem Kontext.

FTEs werden meist unter diesem englischen Begriff und nur selten als VTZ für Vollzeitäquivalent, MAK für Mitarbeiterkapazität oder ähnlichen deutschen Abkürzungen bezeichnet.

FTEs werden meist unter diesem englischen Begriff und nur selten als VTZ für Vollzeitäquivalent, MAK für Mitarbeiterkapazität oder ähnlichen deutschen Abkürzungen bezeichnet.

Mit ihr werden die zur Verfügung stehenden Arbeitszeiten aller Beschäftigten in einem Unternehmen oder in einem Projekt auf eine normierte Größe umgerechnet, um so eine bessere Vergleichbarkeit zu ermöglichen.

Dies geschieht, in dem alle tatsächlich zur Verfügung stehenden Arbeitsstunden der Personen durch die übliche Arbeitszeit von Vollzeit-Erwerbstätigen (also zum Beispiel 35h, 38h oder 40h) geteilt wird. So ergeben sich aus vier Teilzeitkräften mit je 20h bei einer üblichen Arbeitszeit von 40h/Woche beispielsweise 2 FTEs.

Ein Problem der Zahl besteht darin, dass sie keinen Mehraufwand durch Übergaben, vermehrte Kommunikation oder Ähnliches berücksichtigt, wenn es sich um viele Teilzeitkräfte handelt. Dennoch ist diese Größe aussagekräftiger als die bloße Anzahl der Beschäftigten oder der Projektteammitglieder ohne Berücksichtigung der Arbeitszeiten oder der Zeiten, die für das jeweilige Projekt reserviert sind.

Die Funktionsqualifizierung wird meist mit OQ (Operational Qualification) abgekürzt und umfasst alle Aktivitäten, die zum Nachweis der korrekten und vollständigen Umsetzung der Anforderungen im System vor eine Auslieferung dienen. Dies sind im Rahmen der Validierung Aktivitäten der Analytisches Qualitätssicherung (v.a. Tests), die auf Basis der User Stories und sonstiger Anforderungen im Hinblick auf die korrekte Funktionalität und zum Nachweis der Eignung für den Vorgesehenen Zweck geplant, durchgeführt und berichtet werden:

• Modultest
• Integrationstest
• Funktionstest

Die genauen Teststufen werden im Testkonzept des Projektes entsprechend der Vorgaben des Validierungsplans des Projekts festgelegt.

Jegliche Arten von Benutzer-Anleitungen sollten ebenfalls geprüft werden.

GAMP®-Anleitungen enthalten Beschreibungen der Aktivitäten und Empfehlungen zu Dokumenten, um ein GxP-computergestütztes System konform zu den Anforderungen von Regulierungsbehörden weltweit zu erstellen.

Obwohl der Leitfaden den Anspruch erhebt, auch für Agile Entwicklungsmethoden angepasst zu sein, basiert er doch im Wesentlichen auf dem klassischen Wasserfall- oder V-Modell und muss daher für die eigene Organisation interpretiert werden. Auch der in der 2nd Edition hinzugefügte Anhang D8 Agile Software Development fasst die Besonderheiten des Agilen Umfelds nur kurz zusammen. Diese notwendige Interpretation wurde mit dem Agilen Validierungsframework vorbereitet und für die eigene Organisation instanziiert.

Herausgeber des GAMP®5 ist die ISPE-Praxisgemeinschaft mit dem Namen GAMP.

Stand 2023 ist die aktuellste Version Risikobasierter Ansatz für konforme GxP-computergestützte Systeme Version 5 - 2nd Edition.

Eine Gap-Analyse ist eine Aktivität, um eine Organisationseinheit oder ein Projekt hinsichtlich der Konformität seiner Prozesse zu internen oder übergeordneten Regularien und Standards zu bewerten mit dem Ziel Schwachstellen (Gaps) aufzudecken und diese zu beheben.

Sie kann

• sich nur auf einen Teilbereich von Prozessen konzentrieren und damit eine geringere Anzahl von Checkpunkten überprüfen
• den Grundsatz der “two sources of evidence” auf nur einen Nachweis reduzieren
• eigenverantwortlich und ggf. auch ohne Moderation stattfinden (in diesem Fall ist in der Regel eine ausgearbeitete Checkliste nötig).

Sie kann aber auch den vollständigen Umfang eines regulären Audit beinhalten, von ausgebildeten Auditoren durchgeführt werden und damit beispielsweise zur Vorbereitung eines externen Audits dienen.

Ein geschlossenes System kann die Identität der Nutzerinnen und Nutzer des Systems zweifelsfrei bestätigen. Dies geschieht in der Regel durch ein Verzeichnis, in dem alle Nutzerinnen und Nutzer enthalten sind, welches von einer zentralen Stelle gemanagt wird. Zudem ist für die Identifikation ein eineindeutiger Login aus Benutzernamen und Passwort und ggf. zusätzlicher Mechanismen (wie 2-Faktor-Authentifizierung) in Kraft.

Für geschlossene Systeme sind bei Änderungen an elektronischen Aufzeichnungen die Protokollierung in einem Audit Trail häufig ausreichend, gegebenenfalls zusätzlich mit einer elektronischen Signatur bestätigt.

Die Geschäftsprozess-SOP liegt in der Verantwortung des Prozesseigners, der damit die Prozesse beschreibt, die zur Durchführung und Aufrechterhaltung der Geschäfte notwendig sind. Wenn diese Prozesse mit Hilfe eines Computerisierten System erfolgen, sollte auch der Systemeigner die SOP freigeben.

Häufig ist die Benutzungs-Anleitung ein Teil der Geschäftsprozess-SOP.

Das Product Backlog Refinement ist eine Aktivität im Rahmen von Scrum, die das Erreichen der Definition of Ready der ausgewählten Stories zum Ziel hat.
Dies geschieht im Rahmen von Scrum häufig durch die Kommunikation in den üblichen Scrum Events vor allem

• während der Daily Scrums und
• im Sprint Planning.

GxP umfasst somit alle Praktiken, die für die Einhaltung von Leitlinien notwendig sind, die von Behörden empfohlen werden.
Diese Behörden kontrollieren die Autorisierung und Zulassung für die Herstellung und den Verkauf von

• Nahrungsmitteln,
• Lebensmitteln,
• Arzneimitteln,
• Tierarzneimitteln und
• aktiven pharmazeutischen Wirkstoffen.

Beispiele für GxP:

Das GxP-Inventar ist ein zentrales Artefakt, das eine Auflistung aller GxP-relevanten Systeme enthält.

Empfehlenswert ist es, auch die nicht-GxP-relevanten Systeme aufzulisten und mit einer entsprechenden Begründung (zum Beispiel aus der System-Risikoanalyse heraus) zu versehen.

Zu jedem System werden beispielsweise folgende Informationen notiert:

• Systemname und -kürzel
• Versionsstand des Systems
• Ablageort der Systemdokumentation
• Hersteller / Lieferant
• Systemeigner
• Prozesseigner
• Zuständige Qualitätsbeauftragte
• Datum der letzten Validierung / Qualifizierung
• Datum des nächsten Lieferantenaudits
• Datum der nächsten periodischen Überprüfung

Impediments werden als tatsächliche Probleme auf einem eigenen Impediment Board verwaltet. Sie werden im Laufe eines Scrums häufig im Daily, aber auch jederzeit zwischendurch erstellt. Wenn zum Zeitpunkt von Sprint Review und Sprint Retrospektive Impediments vorhanden sind, dienen diese häufig als Grundlage der Diskussionen und Verbesserungsvorschläge. Scrum Master sollten das Scrum Team bei der Beseitigung von Impediments unterstützen und auch mit darauf achten, dass diese zeitnah beseitigt werden.

Ein Increment ist ein konkreter Schritt in Richtung des Produkt‐Ziels. Jedes Increment ist additiv zu allen vorherigen Increments und gründlich geprüft, um sicherzustellen, dass sie alle zusammen funktionieren.
Um einen Mehrwert zu erzielen, muss das Increment verwendbar sein.

Innerhalb eines Sprints kann mehr als ein Increment erstellt werden. Deren Summe wird im Sprint Review vorgestellt, womit Empirie unterstützt wird. Ein Increment könnte jedoch auch schon vor Ende des Sprints an die Stakeholder geliefert werden. Das Sprint Review sollte niemals als Barriere zur Lieferung von Wert angesehen werden.

Arbeit kann nicht als Teil eines Increments betrachtet werden, solange sie nicht der Definition of Done entspricht.
(Quelle: 2020-Scrum-Guide)

Die Installationsqualifizierung wird meist mit IQ (Installation Qualification) abgekürzt und umfasst alle Aktivitäten, die zum Nachweis der korrekten Installation und Konfiguration von Systemen (Software und Hardware) für

• Testumgebung und
• Produktivumgebung

notwendig sind.

Sie ist (zumindest in einem geringen Umfang) für jede durchgeführte Installation notwendig.
Die Installationsqualifizierung der Testumgebung wird häufig mehrere Male je Release durchgeführt.

Die Installationsqualifizierung der Produktivumgebung erfolgt typischerweise für jedes Release einmalig.

Der Umfang der Installationsqualifizierung ist abhängig von der Art der Änderung.

Der Plan und die zu erzeugenden Berichte der Installationsqualifizierung werden im Verlauf der Sprints möglichst früh festgelegt.

Sinnvoll ist es, für das System Checklisten vor der ersten Installation zu erstellen, die dann bei jeder durchgeführten Installation durchgegangen und überprüft werden.

Der vorgesehene Zweck (Intended use) wird gemäß des Agilen Validierungsframeworks im Rahmen der System-Risikoanalyse definiert und zur Klassifizierung des Software als auch als Grundlage der Validierungsplanung verwendet. Der vorgesehene Zweck kann (zusammen mit der System-Risikoanalyse) im Lebenszyklus verändert (meist erweitert) werden.

Hilfreich für die Definition des vorgesehenen Zwecks ist die Nutzung einer Satzschablone.

Die Rolle IT-Qualitätsbeauftragter unterstützt u.a. das Scrum Team, Systemeigner und Prozesseigner bezüglich aller Aspekte zur Einhaltung der regulatorischen und anderer qualitätsbezogenen Standards, Normen und Richtlinien sowie der internen Qualitätsvorgaben im gesamten System-Lebenszyklus. Die Rolle stellt zudem sicher, dass das oberste Management eine qualitätsbezogene Perspektive auf die Entwicklung und den Betrieb, sowie die Außerbetriebnahme des Systems erhält.

Sie unterstützt die Validierungsleitung in einem Projekt, sowie Systemeigner und Prozesseigner im gesamten System-Lebenszyklus, damit das System den Vorgesehenen Zweck erfüllt.

Dazu ist die Rolle verantwortlich für

• die Prüfung der Mehrzahl der Arbeitsergebnisse in einem Projekt und aller Änderungsanträge im gesamten System-Lebenszyklus hinsichtlich der Einhaltung der Vorgaben,
• die Sicherstellung, dass jegliche Lieferanten ein genügend gutes Qualitätsmanagement-System etabliert haben,
• die Beratung des Teams hinsichtlich Nutzung von Prozessen und Dokumentvorlagen und
• die Unterstützung des Qualitätsmanagements hinsichtlich Umsetzbarkeit und Optimierung von Prozessen und Dokumentvorlagen.

Die Rolle kann in Personalunion mit der Validierungsleitung und dem Testmanagement wahrgenommen werden, nicht jedoch mit dem Systemeigner oder mit dem Prozesseigner.

Kategorie 1

Zur Kategorie 1 zählen bewährte oder kommerziell verfügbare Software wie beispielsweise

• Betriebssysteme,
• Datenbanken und
• Programmierumgebungen.

Außerdem gehören auch Infrastruktur-Software-Werkzeuge zur Kategorie 1 wie

• Netzwerküberwachungssoftware,
• Sicherheitssoftware und
• Antivirus Programme.

Kategorie 2

Diese Kategorie ist mit Erstellung des GAMP5 entfallen.

Kategorie 3

Zur Kategorie 3 gehören Serienprodukte für Geschäftszwecke und Standardsoftware, die nicht oder nur gering konfigurierbar ist, wie beispielsweise eine Standardkonfiguration mit vordefinierten Parametern.

Kategorie 4

Zur Kategorie 4 zählt komplexe Software die vom Anwender konfiguriert werden kann wie beispielsweise

• LIMS
• Datenerfassungssysteme
• ERP
• Tabellenkalkulation ohne Makros oder Programmierungen

Kategorie 5

In die Kategorie 5 werden alle CS einbezogen, die kundenspezifisch entwickelt (kodiert) und speziell für die individuellen Geschäftsprozesse angepasst wurden. Dazu zählt auch die Tabellenkalkulation mit Makros oder Programmierungen.

Hinweis: Das Agile Validierungs-Framework wurde mit dem Schwerpunkt auf CS der Kategorie 5 entwickelt und kann auch gut für CS der Kategorie 4 eingesetzt werden.

Der Kommunikationsplan enthält für alle identifizierten Rollen oder Gruppen (meist Stakeholder)

• wann und wie häufig (beispielsweise an jedem letzten Arbeitstag im Monat)
• welche Inhalte (beispielsweise Projektfortschritt)
• in welcher Form und mit welchen Mitteln (beispielsweise informelle Email mit Link auf ein aktualisiertes Dashboard und Erklärungen in Textform in der Mail)

Informationen kommuniziert werden.

Häufig enthält die Stakeholder-Analyse auch den Kommunikationsplan.

Das Konfigurationsmanagement dient der Sicherstellung der Integrität eines Software-Releases. Dies wird durch die Dokumentation aller zum Release gehörigen Dateien erreicht. Hierzu zählen neben dem Quellcode und den daraus generierten Binaries alle Dokumente der Systemdokumentation (Vorgabedokumente, Spezifikationen, Entwicklungsdokumentation), Konfigurationsdateien, Installationsdateien, Datenbanken und Skripte, die zu diesem Softwaresystem beigetragen haben.

Die zum Release gehörigen Dateien werden über die Mechanismen des genutzten ALM Systems dokumentiert. Hierbei muss für jedes Release ein entsprechender Versionsbezeichner erzeugt werden, der alle zugehörigen Dateien eines Releases eindeutig protokolliert.

Die Leistungsqualifizierung wird meist mit PQ (Performance Qualification) abgekürzt und umfasst alle Aktivitäten, die zum Nachweis der korrekten und vollständigen Umsetzung der Anforderungen im System unmittelbar vor und nach einer Auslieferung dienen. Dies sind im Rahmen der Validierung Aktivitäten der Qualitätssteuerung wie beispielsweise

• Systemtest als Vor-Auslieferungstest (system acceptance test, SAT)
• Benutzerakzeptanztest (user acceptance test, UAT)

Die genauen Teststufen werden im Testkonzept des Projektes entsprechend der Vorgaben des Validierungsplans des Projekts festgelegt.

Die Durchführung einer Lieferantenbewertung ist abhängig von der System-Risikoanalyse, dazu notwendige Tätigkeiten und Arbeitsergebnisse können Teil der Projektarbeit sein, aber auch unabhängig vom Projekt von anderen Personen oder Organisationseinheiten durchgeführt werden.

Die Dokumente zur Lieferantenbewertung sind nicht Teil der Systemdokumentation und werden vom Qualitätsmanagement gelenkt, sie werden allerdings bei GxP-relevanten Systemen von der Validierungsleitung sowohl im Validierungsplan als auch im Validierungsbericht berücksichtigt.

Eine Lieferantenbewertung kann beispielsweise in Form einer Selbstbefragung mit Hilfe eines Formulars als auch in Form von Audits erfolgen.

Ein Zugriff auf einen Microservice erfolgt in der Regel über eine API (Application Programming Interface).

Eine API ist ein Rahmen, der die Kommunikation zwischen zwei Anwendungen ermöglicht. APIs und Microservices sind zwei Begriffe, die häufig verwendet werden. Mit Microservices können zuverlässige Anwendungen erstellt werden, ohne ständig neuen Code schreiben zu müssen. Da jeder Microservice für eine einzige Aufgabe erstellt wird, können Entwickler Anwendungen schneller erstellen, ohne die Vielseitigkeit oder Skalierbarkeit zu beeinträchtigen.

Zu einem Risiko, das als Ursache-Wirkungs-Paar definiert wurde, können sowohl Maßnahmen bezogen auf die Ursache als auch bezogen auf die Wirkung / den Schaden definiert werden.

Mitigationen sind im Rahmen der Projektrisiken sehr vielfältig, bei Produktrisiken werden häufig die Durchführung analytischer Qualitätssicherungsmaßnahmen (Dynamisches Testen, Reviews) genutzt. In einer risikoorientierten Teststrategie bedeutet es, dass durch sorgfältige Auswahl von Testverfahren und passenden Abdeckungsmaßen die Wahrscheinlichkeit des Auftretens des jeweiligen Produktrisikos im ausgelieferten Produkt auf ein Mindestmaß reduziert werden soll.

Der jeweilige Schaden kann dagegen typischerweise durch geeignetes Fehlerhandling und durch gute Benutzerdokumentation - vor allem in Form von SOPs reduziert werden.

Arten von Mitigationen

• Mitigation der Ursache
  • Vermeidung der Ursache
  • Verringerung der Wahrscheinlichkeit, dass die Ursache eintreten kann
  • Definition von Alarmen / Warnungen
• Mitigation der Wirkung / des Schadens
  • Verringerung des Schadens
  • Alternativen, die mit Eintreffen der Ursache durchgeführt werden
  • Versicherung
  • Delegation an andere Stellen
• Sonstige Mitigation
  • Beobachtung möglicher Auslöser der Ursache etablieren
  • Beobachtung der Wirkungen etablieren
  • Risiko (vorläufig) akzeptieren

Im Rahmen des Agilen Validierungsframeworks wurde dazu die SOP Risikomanagement erstellt.

Eine gleichartige Benennung unterstützt die Ablage und das Wiederauffinden von Verzeichnissen und Dateien.

Das Wichtigste bei der Benennung und Organisation Ihrer Dateien sind Konsistenz und Beschreibungskraft, so dass es offensichtlich ist, wo eine Datei zu finden ist und was sie enthält.

Ordnungsgemäße Dateinamen erleichtern die Identifizierung und den Abruf von Daten, verringern die Verwirrung, wenn mehrere Personen an gemeinsamen Verzeichnissen und Dateien arbeiten, und verhindern unbeabsichtigte Überschreibungen und Löschungen.

Ein offenes System kann die Identität der Nutzerinnen und Nutzer des Systems nicht (zweifelsfrei) bestätigen.

Dies ist beispielsweise der Fall bei einer Web-Applikation, bei der ein Zugriff über Login Daten erfolgt, die aber nicht von der Organisation auf Korrektheit überprüft werden. Daher wird durch die FDA 21 CFR Part 11 gefordert, dass für offene Systeme jede Änderung von elektronischen Aufzeichnungen nicht nur durch eine elektronische Signatur bestätigt werden muss, sondern weitere Maßnahmen wie Digitale Signatur, Verschlüsselung von Dokumenten oder ähnliches notwendig sind. Damit soll die Authentizität der elektronischen Aufzeichnungen, ihre Integrität und die Vertraulichkeit gesichert werden.

In OLAs werden typischerweise die gleichen Inhalte wie in einem SLA vereinbart, allerdings handelt es sich dabei nicht um einen Vertrag, sondern um eine Vereinbarung innerhalb des gleichen Unternehmens. OLAs werden häufig zur Unterstützung von SLAs vereinbart.

Beispiel: Ein Systemeigner hat in einem SLA eine Dienstleistung als Auftragnehmer mit einem Kunden (extern oder mit dem Team des Prozesseigners) abgeschlossen. Um die geforderten Services bieten zu können, vereinbart er als Service-Nehmer entsprechende OLAs mit dem IT-Betrieb als Service-Geber der jeweiligen Dienstleistungen.

Product Backlog Items (oder Product Backlog Einträge) werden häufig mit PBI abgekürzt.

Im Agilen Validierungsframework werden folgende Product-Backlog-Items genutzt:

• Story
• Task
• Defect

Die periodische Überprüfung erfolgt häufig durch eine unabhängige Person (Leitung der periodischen Überprüfung) zusammen mit Prozess- und Systemeigner sowie eventuell weiteren Experten oder Aufgabenverantwortlichen.

Die Häufigkeit der periodischen Überprüfung wird im Validierungsplan und im Betriebshandbuch festgelegt und der jeweils nächste Termin im GxP-Inventar geplant.

Während der periodischen Überprüfung werden die vorhandenen Systemdokumente sowie jegliche Aufzeichnungen zum System (beispielsweise Änderungsanträge, Audit Trail Reviews, Änderungen von Usern und Zugriffsrechten, Dokumentation von Archivierungen und Dokumentation von Backup/Restore) gesichtet und hinsichtlich der Konformität zu den SOPs und den definierten Prozessen geprüft.

Eine periodische Überprüfung ist meist deutlich weniger aufwändig als ein Audit. Das Vorhandensein entsprechender Dokumente und das Befolgen der Prozesse steht im Fokus, nicht jedoch der konkrete Inhalt der Dokumente.

Zusammen mit Prüfkriterien zur Regulatorik werden häufig auch weitere Prüfkriterien, z.B. zur Datensicherheit, zur Einhaltung steuerlicher, gesetzlicher oder anderer Vorgaben, durchgeführt.

Am Ende der periodischen Überprüfung wird ein Bericht der periodischen Überprüfung als Teil der Systemdokumentation abgelegt und das GxP-Inventar entsprechend aktualisiert.

Das Product Backlog ist eine emergente, geordnete Liste der Dinge, die zur Produktverbesserung benötigt werden. Es ist die einzige Quelle von Arbeit, die durch das Scrum Team erledigt wird.

Product‐Backlog‐Einträge, die durch das Scrum Team innerhalb eines Sprints abgeschlossen (Done) werden können, gelten als bereit für die Auswahl in einem Sprint‐Planning‐Event. Diesen Transparenzgrad erlangen sie in der Regel durch Refinement‐Aktivitäten. Das Refinement des Product Backlogs ist der Vorgang, durch den Product‐Backlog‐Einträge in kleinere, präzisere Elemente zerlegt und weiter definiert werden. Dies ist eine kontinuierliche Aktivität, wodurch weitere Details wie Beschreibung, Reihenfolge und Größe ergänzt werden. Die Attribute variieren oft je nach Arbeitsumfeld.

Die Developer, die die Arbeit erledigen werden, sind für die Größenbestimmung umsetzungsverantwortlich. Der Product Owner kann die Developer beeinflussen, indem er dabei unterstützt, die Product‐Backlog‐Einträge zu verstehen und Kompromisse einzugehen.
(Quelle: 2020-Scrum-Guide)

Im Agilen Validierungsframework werden folgende Product-Backlog-Items genutzt:

• Story
• Task
• Defect

Ein einzelner Vorgang im Product Backlog, der erledigt werden muss. Wird auch Product-Backlog Eintrag genannt und häufig mit PBI abgekürzt.

Im Agilen Validierungsframework werden folgende Product-Backlog-Items genutzt:

• Story
• Risk
• Task
• Defect

Das Refinement von Product Backlog Einträgen geschieht im Rahmen von Scrum häufig durch die Kommunikation in den üblichen Scrum Events vor allem

• während der Daily Scrums und
• im Sprint Planning.

Daneben ist es aber auch möglich das Product Backlog Refinement als separates Event durchzuführen. Dies hat den Zweck, die Definition of Ready der Product Backlog Items herzustellen, um das eigentliche Sprint Planning zu verkürzen.

Falls kein Product Owner aus einem Fachbereich oder seitens des Kunden verfügbar ist, übernimmt der Projektleiter die Rolle des Product Owners.
Der Product Owner vertritt den Prozess Eigner, sofern dies in der Rollen & Verantwortlichkeiten-Matrix für das jeweilige Projekt nicht anders geregelt wurde.

Der Product Owner ist verantwortlich für die Eigenschaften und den wirtschaftlichen Erfolg des Produkts. Der Product Owner erstellt, priorisiert und erläutert die zu entwickelnden Produkteigenschaften.

Zudem urteilt er am Ende eines Sprints darüber, welche Produkteigenschaften fertiggestellt wurden.

Dem Product Owner allein obliegt die Entscheidung über das Produkt, seine Eigenschaften und die Reihenfolge der Implementierung. So steuert er dessen Eigenschaften, Auslieferungszeitpunkte und Kosten. Zur Definition der Produkteigenschaften verwendet der Product Owner das Product Backlog. Darin trägt er in Zusammenarbeit mit dem Entwicklungsteam und den übrigen Stakeholdern die Anforderungen an das Produkt ein.

Der Product Owner ordnet, detailliert und aktualisiert das Product Backlog regelmäßig im Product Backlog Refinement.

Der Product Owner hält regelmäßig Rücksprache mit den Stakeholdern, um deren Bedürfnisse und Wünsche zu verstehen. Dabei muss er die Interessen und Anforderungen unterschiedlicher Stakeholder aufnehmen, nachvollziehen und ggf. auch gegeneinander abwägen.

Wie dies geschieht, kann je nach Organisation, Scrum Team und Individuum sehr unterschiedlich sein.

Der Product Owner ist auch für ein effektives Product‐Backlog‐Management ergebnisverantwortlich, das Folgendes umfasst:
● das Produkt‐Ziel zu entwickeln und explizit zu kommunizieren;
● die Product‐Backlog‐Einträge zu erstellen und klar zu kommunizieren;
● die Reihenfolge der Product‐Backlog‐Einträge festzulegen; und
● sicherzustellen, dass das Product Backlog transparent, sichtbar und verstanden ist.

Der Product Owner kann die oben genannten Arbeiten selbst durchführen oder die Umsetzungsverantwortung an andere delegieren. Unabhängig davon bleibt der Product Owner ergebnisverantwortlich.

Damit der Product Owner Erfolg haben kann, muss die gesamte Organisation seine Entscheidungen respektieren. Diese Entscheidungen sind im Inhalt und in der Reihenfolge des Product Backlogs sowie durch das überprüfbare Increment beim Sprint Review, sichtbar.

Der Product Owner ist eine Person, kein Gremium. Der Product Owner kann die Bedürfnisse vieler Stakeholder im Product Backlog berücksichtigen. Diejenigen, die das Product Backlog ändern möchten, können dies tun, indem sie versuchen, den Product Owner zu überzeugen.
(Quelle: 2020-Scrum-Guide)

Person, die gesamtverantwortlich für den validierten Zustand des Systems und seine Nutzung ist
Die Rolle Prozess Eigner wird durch die Rolle Product Owner vertreten, sofern dies in der Rollen & Verantwortlichkeiten-Matrix für das jeweilige Projekt nicht anders geregelt wurde.

Die Rolle Prozess Eigner ist unter Anderem verantwortlich für

• die Initiierung und Durchführung einer System-Risikoanalyse und aller sich daraus ergebenden Maßnahmen inklusive der Definition des vorgesehenen Zwecks,
• die erstmalige Validierung der in ihrem Geschäftsbereich genutzten GxP-relevanten Systeme,
• die Aufrechterhaltung des validierten Zustands der in ihrem Geschäftsbereich genutzten GxP-relevanten Systeme und
• die Initiierung und Durchführung periodischer Überprüfungen und aller sich daraus ergebenden Maßnahmen.

Die Produkt-Risikoanalyse wird in vielen Unternehmen funktionale Risikoanalyse genannt, allerdings sollten nicht-funktionale Risiken ebenso betrachtet werden wie jegliche funktionale Risiken.

Die erstmalige Erstellung einer Produkt-Risikoanalyse wird in der Regel im Rahmen eines Workshops durchgeführt, in der das Scrum-Team die unterschiedlichen beabsichtigten Funktionalitäten des Systems analysiert und potentielle Probleme aufdeckt. Diese werden ähnlich einer FMEA klassifiziert und bewertet. Je nach Ergebnis der Bewertung werden geeignete Mitigationen (Maßnahmen) ermittelt, wie beispielsweise

• Einrichtung von Alarmen (Watchdogs) oder Monitoring zur frühzeitigen Erkennung des Auftretens
• Durchführung von analytischen Qualitätssicherungsmaßnahmen zur Verringerung der Wahrscheinlichkeit des Auftretens
  • Durchführung von statischen Tests wie beispielsweise Reviews
  • Durchführung von dynamischen Tests
• Erarbeitung von alternativen Lösungswegen (Workarounds) für den Fall des Auftretens zur Verringerung des damit verbundenen Schadens

Die Produkt-Risikoanalyse ist ein während der Systementwicklung fortlaufend überarbeitetes Dokument, eine erste Version wird über die System-Risikoanalyse initiiert, eine (vorläufig) letzte Version erfolgt in der Regel mit dem Abschluss des Releases.

Im Rahmen des Agilen Validierungsframeworks wurde dazu die SOP Risikomanagement erstellt.

Das Produkt‐Ziel befindet sich im Product Backlog. Der Rest des Product Backlogs entsteht, um zu definieren, „was“ das Produkt‐Ziel erfüllt.

Ein Produkt ist ein Instrument, um Wert zu liefern. Es hat klare Grenzen, bekannte Stakeholder, eindeutig definierte Benutzer oder Kunden. Ein Produkt kann eine Dienstleistung, ein physisches Produkt oder etwas Abstrakteres sein.

Das Produkt‐Ziel ist das langfristige Ziel für das Scrum Team. Das Scrum Team muss eine Zielvorgabe erfüllen (oder aufgeben), bevor es die nächste angeht.

(Quelle: 2020-Scrum-Guide)

Das Produkt-Ziel ist das Commitment zum Product Backlog. Im GxP-Kontext muss das Produkt-Ziel dem vorgesehenen Zweck entsprechen.

Eine wesentliche Eigenschaft der Projektdokumentation ist, dass sie nur während des Projektes gültig ist. Sie ist keinen Aufbewahrungspflichten unterworfen ist, sämtliche Informationen sind nach Projektende wertlos. Damit kann die Projektdokumentation nach der Beendigung bedenkenlos gelöscht werden.

Tipp:
Die Projektdokumentation nicht zu früh löschen oder archivieren. Sie kann in der letzten Retrospektive zu dem Projekt als Erinnerungshilfe dienen. Und sie dient möglicherweise als Blaupause für das nächste Projekt.

Im Rahmen des Agilen Validierungsframeworks wurde dazu die SOP Lebenszyklus computergestützter Systeme (SWLC) erstellt.

Die Read-only-Phase dient bei der Außerbetriebnahme des Systems dazu, im Rahmen der jeweiligen Aufbewahrungspflichten weiterhin einen lesenden Zugang zu ermöglichen, um beispielsweise

• Daten rückwirkend nutzen,
• Nachweise für Behörden (u.a. auch Finanzbehörden), Gerichte und Auditoren erbringen und
• Berichte erzeugen zu können.

Der Außerbetriebnahmeplan muss dabei sicherstellen, dass der Lesezugriff für meist viele Jahre möglich ist, dazu müssen gegebenenfalls Upgrades/Updates der Systeme erfolgen oder (veraltete) Systeme und Betriebssysteme am Laufen gehalten werden.

Wenn Daten aus einem alten in ein neues System migriert wurden oder sie vollständig und dauerhaft in anderer Form vorliegen, kann eine Read-only-Phase auch entfallen. Erst nach Ende der Aufbewahrungspflichten dürfen die Daten vollständig gelöscht werden.

Die Benennung eines Releases muss im Rahmen der Konfigurationsplanung für ein zu erstellendes Produkt frühzeitig festgelegt werden. Typischerweise werden diese Regelungen in einem Unternehmen produktübergreifend definiert.

Beispiel 1:

Die Versionierung der Dateien soll nach dem Prinzip des Semantic Versioning erfolgen.

Hierbei ist die Versionsnummer folgendermaßen aufgebaut:

Major.Minor.Patch

Die Major-Version ist bei inkompatiblen Änderungen anzupassen.
Die Minor-Version ist bei neuen, jedoch abwärtskompatiblen Änderungen anzupassen.
Die Patch-Version ist bei abwärtskompatiblen Fehlerbehebungen anzupassen.
Weitere Zusätze zur Versionsnummer für Vorabversionen und Build-Metadaten sind erlaubt.

Eine Vorabversion wird gekennzeichnet, indem ein Bindestrich, gefolgt von einem Vorabversionsbezeichner, an die Patch-Version angehängt wird.
Build-Metadaten werden gekennzeichnet, indem ein Plus-Symbol, gefolgt von den Metadaten, an die Patch-Version oder Vorabversion angehängt wird.


Beispiel 2:

Die Versionsnummer einer Baseline ist folgendermaßen aufgebaut:

Major.Minor.Inkrement

Major Releases werden an der ersten Stelle X.x.x hochgezählt, wenn grundlegend neue Funktionalitäten hinzukommen oder größere Anteile verändert werden. Hierbei gibt es dann auch entsprechend große Auswirkungen auf die Durchführung der Arbeitsaufgaben mit dem System - meist muss dazu eine Nutzungs-SOP angepasst werden.
Minor Releases werden an der zweiten Stelle x.X.x hochgezählt, wenn Änderungen an wenigen Teilen erfolgen beziehungsweise in geringerem Umfang. Die durchgeführten Änderungen haben geringe Auswirkungen auf die Durchführung von Arbeitsaufgaben, eine Anpassung von Nutzungs-SOPs ist nicht notwendig.
Inkremente werden an der dritten Stelle x.x.X hochgezählt, wenn die Änderungen nur sehr geringfügige Auswirkungen auf die Nutzung haben und sich typischerweise nur auf die Gestaltung der Nutzungsoberfläche (der GUI) beziehen oder interne technische Verbesserungen beinhalten, die nach außen keinerlei Auswirkungen haben.

Release Notes können in einer einfachen Version für Nicht-GxP-relevante Systeme oder in einer vollständigen Version erstellt werden.

Einfache Release Notes

Sind in einem Projekt nur einfache Release Notes nötig, so werden diese typischerweise im Tracking-Tool erstellt, mit notwendigen Kommentaren ergänzt und an die Stakeholder formlos verteilt sowie zusätzlich als System-Dokument abgelegt. Einfache Release-Notes müssen nicht gelenkt werden, sie werden aber als Teil der Baseline eingefroren und somit dauerhaft archiviert.

Vollständige Release Notes

Vollständige Release Notes enthalten alle Anforderungen an das System und deren geplante und durchgeführte Überprüfungen. Dazu zählen:

• User Stories
• Risiken oder Verweis auf die funktionale Risikoanalyse
• Testfälle (Tests)
• Testprotokolle (Executions) (inklusive Verweis auf Reviewprotokolle, falls separat dokumentiert)
• Bugs

Das Hinzufügen einzelner oder aller Aufgaben und Unteraufgaben zu den Release Notes ist optional möglich, in den meisten Fällen jedoch nicht sinnvoll.

Ein Release-Sprint ist der letzte Sprint vor der endgültigen Auslieferung und enthält in der Regel keine Codierungsaktivitäten, sondern vor allem Finalisierungen der Systemdokumentation.

Reviews sind eine Art statischer Test, bei dem ein Arbeitsergebnis oder -prozess von einer oder mehreren Personen bewertet wird, um Fehlerzustände zu erkennen oder Verbesserungen zu erzielen.

Reviewarten sind vor allem

• Informelles Review
• Walkthrough
• Technisches Review
• Inspektion

Reviewprotokolle werden für die Durchführung von statischen Überprüfungen (meist von Dokumenten) erstellt, um die darin ermittelten Befunde und möglicherweise weitere Kennzahlen zu protokollieren.

Das ausführliche Reviewprotokoll enthält die Planung, die ermittelten Befunde als auch die Ergebnisse inklusive der Kennzahlen eines formalen Reviews wie einer Inspektion oder eines Technischen Reviews.

Für weniger formale Reviews wie beispielsweise Walkthroughs, 4-Augen-Prüfung oder Deskchecks ist die Dokumentation als Test mit einer Ausführung ausreichend, das Ergebnis wird dann als Testergebnis des statischen Tests festgehalten.

Reviewverfahren sind vor allem

• ad-hoc
• checklistenbasiert
• rollenbasiert
• szenariobasiert
• schrittweise Verfeinerung

Ein Risiko ist ein potentielles Problem; also ein Faktor, der zu negativen Konsequenzen in der Zukunft führen könnte. Die Wahrscheinlichkeit des Eintretens ist dabei > 0% und < 100% (sonst handelt es sich um ein tatsächliches Problem).

Ein Risiko wird analysiert und mit einer Risikostufe bewertet. Dazu werden die Wahrscheinlichkeit des Eintretens der Ursache, der Schaden bei Eintreten der Wirkung und die Entdeckungswahrscheinlichkeit bewertet, um eine gesamte Risikostufe zu bestimmen.

Zu einem Risiko wird im Agilen Validierungsframework auch der Typ (Projektrisiko oder Produktrisiko) angegeben. Produktrisiken werden in der Traceability-Matrix wie Stories behandelt, die durch geeignete Tests abgedeckt werden.

Im Rahmen des Agilen Validierungsframeworks wurde dazu die SOP Risikomanagement erstellt.

Dokument, das für ein Projekt die Rollen und Verantwortlichkeiten mit Hilfe von zwei Tabellen festlegt.
Das Dokument enthält eine Tabelle, die für jede Rolle im Projekt festlegt, welche Verantwortlichkeit für Artefakte bestehen und eine weitere Tabelle, die darstellt, welche Rolle von welcher Person besetzt wird.

Ein erster Entwurf sollte mit der Projekt-Charta zusammen erstellt werden, damit das Management den Personalbedarf frühzeitig abschätzen kann.

Grammatikalische Vorgaben, um natürlich-sprachige Anforderungen zu formulieren und damit für eine höhere Qualität zu sorgen.
Natürlich-sprachige Anforderungen haben allgemein das Problem, dass sie leicht widersprüchlich, mehrdeutig oder unvollständig ausgedrückt werden. Um diese Probleme zu verringern, existiert eine Reihe von Satzschablonen, die die Auswahl bestimmter Schlüsselworte und ihre Reihenfolge vorgeben.

Scott Ambler definierte für (User) Stories eine Satzschablone, die sich mittlerweile allgemein durchgesetzt hat:

Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen>.

Für die zugehörigen Akzeptanzkriterien wird im Agilen Validierungsframework eine vereinfachte und deutsche Version der Gherkin Satzschablone genutzt:

Unter der Bedingung <Voraussetzung>, wenn ich <Aktion>, dann <Reaktion>.

Im Rahmen des Agilen Validierungsframeworks wird zudem eine Satzschablone für den vorgesehenen Zweck genutzt.

Schulungsmaterialien können sehr unterschiedliche Dokumente sein, beispielsweise

• SOPs,
• Videos,
• Online-Hilfen oder andere Hilfesysteme innerhalb des Systems,
• Confluence-Seiten mit Anleitungen oder Erklärungen,
• Präsentationen,
• Selbstschulungsunterlagen,
• Bücher,
• Tutorials beispielsweise als HTML-Dokumente,
• E-Learnings und
• Trainingshandbücher, Flipchart-Entwürfe, Metaplantafelbilder, Arbeitsblätter und Übungsmaterialien für Präsenzschulungen.

Alle Schulungs-Materialien müssen entweder direkt zur Systemdokumentation abgelegt oder referenziert werden.

Auf Grund der unterschiedlichen Formate gelten die allgemeinen Formatvorlagen für den jeweiligen Dokumenttyp, wie beispielsweise für SOPs oder für Berichte.

Vor allem bei der Nutzung von cloudbasierten Systemen (as-a-service) wird das Release Management durch den Anbieter der Systeme betrieben und die Anwenderinnen und Anwender lediglich über bevorstehende oder bereits erfolgte Änderungen am System informiert.

Diese Informationen werden über spezielle Webseiten des Anbieters veröffentlicht oder per Mail (beispielsweise als Newsletter) verbreitet.

Screening ist die Aktivität, in der diese Informationen gelesen und bewertet werden. Für GxP-relevante Systeme wird die Aktivität mit der Verantwortlichkeit, der Häufigkeit der Durchführung, dem Umgang mit den Ergebnissen der Analyse und der Dokumentation des Screenings im Validierungsplan festgelegt.

Kurz gesagt fordert Scrum, dass ein Scrum Master ein Umfeld fördert, in dem

1. ein Product Owner die Arbeit für ein komplexes Problem in ein Product Backlog einsortiert;

2. das Scrum Team aus einer Auswahl dieser Arbeit innerhalb eines Sprints ein wertvolles Increment erzeugt;

3. das Scrum Team und dessen Stakeholder die Ergebnisse überprüfen und für den nächsten Sprint anpassen;

4. diese Schritte wiederholt werden.
(Quelle: 2020-Scrum-Guide)

Der Sprint ist ein Container für alle anderen Events. Jedes Event in Scrum ist eine formelle Gelegenheit, Scrum‐Artefakte zu überprüfen und anzupassen. Diese Events sind speziell darauf ausgelegt, die erforderliche Transparenz zu ermöglichen. Wenn ein Event nicht wie vorgeschrieben durchgeführt wird, verpasst man die Gelegenheit, zu überprüfen und anzupassen. Events werden in Scrum verwendet, um Regelmäßigkeit zu schaffen und die Notwendigkeit von Meetings, die in Scrum nicht definiert sind, zu minimieren. Optimalerweise werden alle Events zur selben Zeit und am selben Ort abgehalten, um die Komplexität zu reduzieren.

(Quelle: 2020-Scrum-Guide)

Es gibt folgende Scrum Events:

• Sprint
• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospektive

Der Scrum Master ist für das Gelingen des Scrum-Prozesses verantwortlich. Er legt die Scrum Regeln fest und stellt deren Einhaltung sicher. Er moderiert die einzelnen Treffen und kümmert sich um die Behebung von Störungen und Hindernissen. Der Scrum Master ist somit als Coach für den Prozess und die Beseitigung von Hindernissen verantwortlich.

Er tut dies, indem er allen dabei hilft, die Scrum‐Theorie und ‐Praxis zu verstehen, sowohl innerhalb des Scrum Teams als auch in der Organisation.

Der Scrum Master ist ergebnisverantwortlich für die Effektivität des Scrum Teams. Er tut dies, indem er das Scrum Team in die Lage versetzt, seine Praktiken innerhalb des Scrum‐Rahmenwerks zu verbessern.

Scrum Master sind echte Führungskräfte, die dem Scrum Team und der Gesamtorganisation dienen.

• Der Scrum Master dient dem Scrum Team auf unterschiedliche Weise, unter anderem dadurch,
• die Teammitglieder in Selbstmanagement und interdisziplinärer Zusammenarbeit zu coachen;
• das Scrum Team bei der Fokussierung auf die Schaffung von hochwertigen Increments zu unterstützen, die der Definition of Done entsprechen;
• die Beseitigung von Hindernissen (impediments) für den Fortschritt des Scrum Teams zu bewirken; und
• sicherzustellen, dass alle Events von Scrum stattfinden, positiv und produktiv sind und innerhalb der Timebox bleiben.

Der Scrum Master dient dem Product Owner auf unterschiedliche Weise, unter anderem dadurch,

• bei der Suche nach Techniken zur effektiven Definition des Produkt‐Ziels und zum Product‐Backlog‐Management zu helfen;
• dem Scrum Team dabei zu helfen, die Notwendigkeit klarer und präziser Product‐Backlog‐Einträge zu verstehen;
• bei der Etablierung einer empirischen Produktplanung für ein komplexes Umfeld zu helfen; und
• die Zusammenarbeit mit Stakeholder nach Wunsch oder Bedarf zu fördern (facilitate).

Der Scrum Master dient der Organisation auf unterschiedliche Weise, unter anderem dadurch,

• die Organisation bei der Einführung von Scrum zu führen, zu schulen und zu coachen;
• Einführungen von Scrum in der Organisation zu planen und zu empfehlen;
• Mitarbeitende und Stakeholder beim Verständnis und bei der Umsetzung eines empirischen Ansatzes für komplexe Arbeit zu unterstützen; und
• Barrieren zwischen Stakeholder und Scrum Teams zu beseitigen.

(Quelle: 2020-Scrum-Guide)

Innerhalb eines Scrum Teams gibt es keine Teilteams oder Hierarchien. Es handelt sich um eine geschlossene Einheit von Fachleuten, die sich auf ein Ziel konzentrieren, das Produkt‐Ziel.

Scrum Teams sind interdisziplinär, d.h. die Mitglieder verfügen über alle Fähigkeiten, die erforderlich sind, um in jedem Sprint Wert zu schaffen. Sie managen sich außerdem selbst, d.h. sie entscheiden intern, wer was wann und wie macht.

Das Scrum Team ist klein genug, um flink zu bleiben und groß genug, um innerhalb eines Sprints bedeutsame Arbeit fertigzustellen, üblicherweise 10 oder weniger Personen. Im Allgemeinen haben wir festgestellt, dass kleinere Teams besser kommunizieren und produktiver sind. Wenn Scrum Teams zu groß werden, sollten sie in Erwägung ziehen, sich in mehrere zusammengehörende Scrum Teams zu reorganisieren, die sich alle auf dasselbe Produkt konzentrieren. Daher sollten sie sich Produkt‐Ziel, Product Backlog und Product Owner teilen.

Das Scrum Team ist umsetzungsverantwortlich (responsible) für alle produktbezogenen Aktivitäten: Zusammenarbeit mit den Stakeholder, Verifikation, Wartung, Betrieb, Experimente, Forschung und Entwicklung und alles, was sonst noch erforderlich sein könnte. Es ist von der Organisation so aufgebaut und befähigt, dass es seine Arbeit selbst steuert. Das Arbeiten in Sprints mit einer nachhaltigen Geschwindigkeit verbessert den Fokus und die Kontinuität des Scrum Teams.

Das gesamte Scrum Team ist ergebnisverantwortlich (accountable), in jedem Sprint ein wertvolles, nützliches Increment zu schaffen. Scrum definiert drei spezifische Ergebnisverantwortlichkeiten innerhalb des Scrum Teams: Developer, Product Owner und Scrum Master.
(Quelle: 2020-Scrum-Guide)

In SLAs werden typischerweise vereinbart:

• Zugesicherte Eigenschaften der Dienstleistung (häufig als Support bezeichnet) bezogen auf

1. Umfang
2. Reaktionszeit
3. Schnelligkeit der Bearbeitung
4. Service-Level (beispielsweise Bronze, Silber, Gold, Platin)

• Zugesicherte Eigenschaften der Systeme wie

1. Verfügbarkeit (beispielsweise 24/7)
2. Ausfallraten (beispielsweise Downtime maximal 0,05% / Jahr)

• Zugesicherte regelmäßige Wartungsaufgaben

1. Monitoring von Effizienzkennzahlen wie beispielsweise Performanz
2. administrative Aufgaben wie User-Management
3. Job-/Batch-Planung
4. Archivierungsaufgaben

• Rollen und Verantwortlichkeiten
• Eskalationsstufen
• Ermittlung von Kennzahlen zu den zugesicherten Eigenschaften der Dienstleistungen und des Systeme
• Vertragsrelevante Informationen wie

1. Zweck
2. Vertragspartner
3. Vertragslaufzeit
4. Rechtsgrundlagen
5. Preise
6. Änderungshistorie
7. Freigaben / Unterschriften

SOPs (Standard Operating Procedures) sind in der Medizintechnik und in der Pharmazeutik zwingend vorgeschrieben, um die Compliance zu Richtlinien, Standards, Normen, Verordnungen und Gesetzen zu garantieren.

Im Rahmen des Agilen Validierungsframeworks wurden für alle wesentlichen SOPs, die den Softwareentwicklungsprozess und die Validierung betreffen, entsprechende Muster-SOPs erarbeitet. Geschäftsprozess-SOPs können dagegen nur vom Prozesseigner, bzw. beauftragten Autoren, passend zu den konkreten Anwendungen der Systeme in dem jeweiligen Unternehmen erstellt werden.

Sprints sind der Herzschlag von Scrum, wo Ideen in Wert umgewandelt werden.

Es sind Events mit fester Länge von einem Monat oder weniger, um Konsistenz zu schaffen. Ein neuer Sprint beginnt unmittelbar nach dem Abschluss des vorherigen Sprints.

Alle Arbeiten, die notwendig sind, um das Produkt‐Ziel zu erreichen, einschließlich Sprint Planning, Daily Scrums, Sprint Review und Sprint Retrospective, finden innerhalb der Sprints statt.

Während des Sprints
● werden keine Änderungen vorgenommen, die das Sprint‐Ziel gefährden würden;
● nimmt die Qualität nicht ab;
● wird das Product Backlog nach Bedarf verfeinert; und
● kann der Scope (Inhalt und Umfang) geklärt und mit dem Product Owner neu vereinbart
werden, sobald mehr Erkenntnisse vorliegen.

(Quelle: 2020-Scrum-Guide)

Im Rahmen des GxP-Umfelds und dieses Frameworks gibt es zwei besondere Sprints:

• Vorbereitungs-Sprint (erster Sprint)
• Abschluss-Sprint / Release-Sprint (letzter Sprint)

Im Rahmen des Agilen Validierungsframeworks wurde dazu die SOP Lebenszyklus computergestützter Systeme (SWLC) erstellt.

Das Sprint Backlog besteht aus dem Sprint‐Ziel (Wofür), den für den Sprint ausgewählten Product‐Backlog‐Einträgen (Was) sowie einem umsetzbaren Plan für die Lieferung des Increments (Wie).

Das Sprint Backlog ist ein Plan von und für die Developer. Es ist ein deutlich sichtbares Echtzeitbild der Arbeit, welche die Developer während des Sprints zur Erreichung des Sprint‐Ziels ausführen wollen. Folglich wird das Sprint Backlog während des gesamten Sprints immer dann aktualisiert, wenn mehr gelernt wurde. Es sollte genügend Details beinhalten, damit sie ihren Fortschritt im Daily Scrum überprüfen können.
(Quelle: 2020-Scrum-Guide)

Der aus dem Sprint Planning resultierende Plan wird durch die gemeinschaftliche Arbeit des gesamten Scrum Teams erstellt.

Der Product Owner stellt sicher, dass die Teilnehmenden vorbereitet sind, die wichtigsten Product‐Backlog‐Einträge zu besprechen, und wie sie dem Produkt‐Ziel zuzuordnen sind. Das Scrum Team kann zu Beratungszwecken auch andere Personen zur Teilnahme am Sprint Planning einladen.

Das Sprint Planning behandelt die folgenden Themen:

Thema Eins: Warum ist dieser Sprint wertvoll?

Thema Zwei: Was kann in diesem Sprint abgeschlossen (Done) werden?

Thema Drei: Wie wird die ausgewählte Arbeit erledigt?

Das Sprint Planning ist zeitlich beschränkt auf maximal acht Stunden für einen einmonatigen Sprint. Bei kürzeren Sprints ist das Event in der Regel kürzer.
(Quelle: 2020-Scrum-Guide)

Der Zweck der Sprint Retrospective ist es, Wege zur Steigerung von Qualität und Effektivität zu planen.

Das Scrum Team überprüft, wie der letzte Sprint in Bezug auf Individuen, Interaktionen, Prozesse, Werkzeuge und seine Definition of Done verlief. Die überprüften Elemente variieren oft je nach Arbeitsdomäne. Annahmen, die das Team in die Irre geführt haben, werden identifiziert und ihre Ursprünge erforscht. Das Scrum Team bespricht, was während des Sprints gut gelaufen ist, auf welche Probleme es gestoßen ist und wie diese Probleme gelöst wurden (oder auch nicht).

Das Scrum Team identifiziert die hilfreichsten Änderungen, um seine Effektivität zu verbessern. Die wirkungsvollsten Verbesserungen werden so schnell wie möglich in Angriff genommen. Sie können sogar in das Sprint Backlog für den nächsten Sprint aufgenommen werden.

Die Sprint Retrospective schließt den Sprint ab. Sie ist für einen einmonatigen Sprint auf maximal drei Stunden beschränkt. Bei kürzeren Sprints ist das Event in der Regel kürzer.
(Quelle: 2020-Scrum-Guide)

Die Sprint Retrospektive ist eine gemeinsame Aktivität des Scrum Teams und das letzte Element eines Sprints. Hierbei überprüft das Scrum Team seine bisherige Arbeitsweise, um sie in Zukunft effizienter und effektiver zu machen. Der Scrum Master unterstützt das Scrum Team darin, gute Praktiken und Verbesserungen zu finden, die im nächsten Sprint umgesetzt werden.

Das Team soll seine Arbeitsweise ehrlich überprüfen, dazu müssen Kritik und unangenehme Wahrheiten offen geäußert werden können. Das schließt auch Gefühle und Empfindungen ein. Die Retrospektive soll daher in einem geschützten Raum ablaufen, Stakeholder dürfen nur auf Einladung dazukommen.

Beispiel für Festlegungen zum Ablauf einer Retrospektive:

Jedes Teammitglied erhält maximal fünf Karteikarten, auf denen notiert wird, was im Sprint gut bzw. schlecht lief. Anschließend stellt jedes Teammitglied seine Notizen kurz vor und ordnet sie einer Kategorie Gut oder Schlecht zu. Alternativ kann ein Starfish-Diagramm mit den Kategorien Beibehalten, Anfangen, Mehr davon, Weniger davon und Aufhören genutzt werden.
Nachdem alle Teammitglieder ihre Notizen vorgestellt haben, erfolgt eine Bewertung hinsichtlich Relevanz durch das Projektteam. Hierzu erhält jedes Teammitglied maximal drei Stimmpunkte, die beliebig auf die Karteikarten der Kategorien verteilt werden dürfen (es dürfen auch mehrere Punkte pro Karte vergeben werden).
Die drei Karteikarten aus der Kategorie Schlecht bzw. Aufhören mit den meisten Punkten werden in das Impediment Backlog übernommen.
Im Anschluss versucht das Team gemeinsam mindestens eine konkrete Verbesserungsmaßnahme abzuleiten, die es im Rahmen des nächsten Sprints umsetzen kann. Die Verbesserungsmaßnahme wird im Sprint Backlog aufgenommen. Das Ergebnis der Retrospektive wird im ALM System festgehalten.

Die Sprint Retrospektive dauert maximal 45 Minuten je Sprint-Woche.

Zweck des Sprint Reviews ist es, das Ergebnis des Sprints zu überprüfen und künftige Anpassungen festzulegen. Das Scrum Team stellt die Ergebnisse seiner Arbeit den wichtigsten Stakeholder vor, und die Fortschritte in Richtung des Produkt‐Ziels werden diskutiert.

Während des Events überprüfen das Scrum Team und die Stakeholder, was im Sprint erreicht wurde und was sich in ihrem Umfeld verändert hat. Auf der Grundlage dieser Informationen arbeiten die Teilnehmenden gemeinsam daran, was als Nächstes zu tun ist. Auch kann das Product Backlog angepasst werden, um neue Möglichkeiten wahrzunehmen. Das Sprint Review ist ein Arbeitstermin, und das Scrum Team sollte vermeiden, es auf eine Präsentation zu beschränken.

Das Sprint Review ist das vorletzte Event des Sprints und ist für einen einmonatigen Sprint auf maximal vier Stunden zeitlich beschränkt. Bei kürzeren Sprints ist das Event in der Regel kürzer.
(Quelle: 2020-Scrum-Guide)

Das Sprint‐Ziel ist die einzige Zielsetzung für den Sprint. Obwohl das Sprint‐Ziel ein Commitment der Developer ist, bietet es Flexibilität in Bezug auf die genaue Arbeit, die erforderlich ist, um es zu erreichen. Das Sprint‐Ziel schafft auch Kohärenz und Fokus und ermutigt somit das Scrum Team, zusammen statt in separaten Initiativen zu arbeiten.

Das Sprint‐Ziel wird während des Sprint‐Planning‐Events erstellt und dann zum Sprint Backlog hinzugefügt. Während die Developer innerhalb des Sprints arbeiten, behalten sie das Sprint‐Ziel im Gedächtnis. Wenn sich herausstellt, dass die Arbeit von ihren Erwartungen abweicht, arbeiten sie mit dem Product Owner zusammen, um den Umfang des Sprint Backlogs innerhalb des Sprints zu verhandeln, ohne das Sprint‐Ziel zu beeinflussen.
(Quelle: 2020-Scrum-Guide)

Das Sprint-Ziel ist das Commitment zum Sprint Backlog.

Im GxP-Kontext muss das Produkt-Ziel dem vorgesehenen Zweck entsprechen.

Stakeholder sind Personen oder Organisationen, die gegenwärtig oder in Zukunft direkt oder indirekt von der Erstellung, Änderung oder Stilllegung eines Systems betroffen sind und daher Bedürfnisse, Erwartungen und Wünsche haben.

Eine Stakeholder-Analyse analysiert, welche Stakeholder es in einem bestimmten Kontext gibt und wie diese in ein Projekt eingebunden werden.

Eine Stakeholder-Analyse analysiert welche Stakeholder es in einem bestimmten Kontext gibt und wie diese in ein Projekt eingebunden werden.

Häufig enthält die Stakeholder-Analyse auch den Kommunikationsplan.

Im Rahmen des Agilen Validierungsframeworks wurde dazu die SOP Lebenszyklus computergestützter Systeme (SWLC) erstellt.

Standard Operating Procedures (selten in Deutsch als Standard-Vorgehensweise oder ähnlich bezeichnet) sind in der Medizintechnik und in der Pharmazeutik zwingend vorgeschrieben, um die Compliance zu Richtlinien, Standards, Normen, Verordnungen und Gesetzen zu garantieren.

Im Rahmen des Agilen Validierungsframeworks wurden für alle wesentlichen SOPs, die den Softwareentwicklungsprozess und die Validierung betreffen, entsprechende Muster-SOPs erarbeitet. Geschäftsprozess-SOPs können dagegen nur vom Prozesseigner, bzw. beauftragten Autoren, passend zu den konkreten Anwendungen der Systeme in dem jeweiligen Unternehmen erstellt werden.

(User) Stories sind eine Art von Product-Backlog-Einträgen, die beschreiben, welche Produkteigenschaft der Benutzer will und warum. Dabei gehören zum Produkt alle Artefakte, die mit dem Release an den Prozesseigner ausgeliefert werden, dies umfasst neben dem computerisierten System (der Software und der Hardware) auch alle Dokumentationen, die zum Betrieb des Systems gefordert sind (beispielsweise Geschäftsprozess-SOP, Validierungsplan und -bericht, Betriebshandbuch).

Stories werden mit Hilfe eines Werkzeugs wie beispielsweise Jira erstellt und bearbeitet, dazu werden häufig Satzschablonen genutzt.

Stories werden vom Product Owner oder anderen Mitgliedern des Scrum-Teams gemäß der dokumentierten Regeln zum Schreiben von User Stories formuliert. Diese Regeln werden durch die Retrospektiven kontinuierlich optimiert.

Im Rahmen des Agilen Validierungsframeworks wurde dazu die SOP Lebenszyklus computergestützter Systeme (SWLC) erstellt.

Story Points werden in Projekten im Rahmen von Agile Poker Sessions geschätzt und den Stories (und teilweise auch anderen Elementen des Product-Backlogs) zugewiesen.

Sub-Tasks dienen zur Strukturierung von Arbeiten, die zu verschiedenen Zeitpunkten oder von verschiedenen Personen übernommen werden. Sie sind lediglich zur Selbstorganisation des Scrum-Teams gedacht, daher sind sie nicht Teil irgendwelcher Berichte beziehungsweise der Systemdokumentation.

Sie sind somit nur ein Hilfsmittel zur Erledigung des übergeordneten Vorgangstyps und haben außerhalb der Steuerung des Projektes keine weitere Bedeutung.

Die Systemdokumentation bildet die wesentliche Grundlage für die Validierung des Systems und muss kontinuierlich (also mit jeder Änderung des Systems) aktualisiert werden.

Im Gegensatz zur Projektdokumentation unterliegt die Systemdokumentation deutlich längeren Aufbewahrungspflichten. Die Erzeugung und Überarbeitung wird im Agilen Framework mit der Erzeugung und Überarbeitung von Code gleichgesetzt, das bedeutet, dass auch dafür Stories mit Akzeptanzkriterien erzeugt, eingeschätzt und überprüft werden.

Die Rolle System Eigner ist vor allem verantwortlich für die Erstellung, die Verfügbarkeit, den Betrieb, die Unterstützung der Nutzerinnen und Nutzer im Betrieb, die Wartung und die Außerbetriebnahme von IT Lösungen.

Die Rolle System Eigner gibt typischerweise validierungsrelevante Dokumente zusammen mit der Rolle Prozess Eigner frei.

Zu Projektstart wird ein Architekturentwurf erstellt (Upfront-Design). Dieser kann auf bereits durchgeführte Projekte oder etablierte Vorgehensweisen verweisen bzw. durch diese bereits abgebildet sein. Der Architekturentwurf soll sich an der vorläufigen Sprint-Planung und zu erledigenden Tasks orientieren.

Es ist keine vollständig erschöpfende Architekturbeschreibung zu Projektstart erforderlich, sofern dies nicht vom Projektumfeld vorgegeben ist.

Hinweis: Die Architektur darf im Rahmen der Retrospektive hinterfragt werden. Falls Handlungsbedarf besteht und die auszuführenden Maßnahmen klar sind, können Änderungen an der Architektur als Backlog-Item im Product Backlog eingetragen und abgeschätzt werden. Sollte das optimale Vorgehen nicht klar sein, können im Rahmen eines „Architecture Spike“ mögliche Änderungen evaluiert und im Anschluss an den nächsten Sprint Vorschläge unterbreitet werden bzw. eine Entscheidung getroffen werden. Verfeinerungen der Architektur können während der Projektlaufzeit als separate Backlog Items im Product Backlog erfasst werden.

Der Systementwurf ist Teil des Entwicklungsplans oder wird hierin referenziert. Zusätzlich ist der Systementwurf Voraussetzung für die Validierungsplanung.

Im Rahmen des Agilen Validierungsframeworks wurde dazu die SOP Lebenszyklus computergestützter Systeme (SWLC) erstellt.

Eine System-Risikoanalyse wird in der Regel im Rahmen eines oder mehrerer Workshops erstellt. Teilnehmen sollten an diesem Workshop alle Stakeholder.

In einem ersten Schritt wird der vorgesehene Zweck (Intended Use) des Systems formuliert. Dies wird durch die Anwendung einer Satzschablone vereinfacht.

Mit Hilfe einer Reihe von Fragen erarbeiten die Teilnehmenden dann die damit verbundenen Risiken hinsichtlich:

• Einfluss auf die Gesundheit von Patienten und der Regulatorik
• Datenschutzgesetze
• Vorgaben von Finanzbehörden
• Geschäftszielen
• Image
• Kundenzufriedenheit
• und weiteren Faktoren

Dies hilft - nicht nur im regulierten Umfeld - für Systeme und Software, die erstellt, überarbeitet oder gekauft wird, von Anfang an entsprechende Probleme zu vermeiden oder zumindest einen möglichen Schaden zu reduzieren.

Typischerweise wird der vorgesehene Zweck währenddessen mehrmals überarbeitet und verfeinert.

In einem weiteren Schritt werden zu den Risiken geeignete Maßnahmen ermittelt. Diese könnten sofort umsetzbar sein, es könnte aber auch eine tiefergehende Analyse des jeweiligen Risikos im Rahmen einer funktionalen Risikoanalyse oder in einer Beratung mit Experten als Maßnahme ermittelt werden (beispielsweise zum Datenschutz, zur Einhaltung spezieller Normen, Standards und Gesetze) gesichert.

Eine wichtiges Ergebnis der System-Risikoanalyse ist die Feststellung der GxP-Relevanz und der Notwendigkeit einer Qualifizierung oder Validierung.

Im Rahmen des Agilen Validierungsframeworks wurde dazu die SOP Risikomanagement erstellt.

Tasks dienen dazu alle Aufgaben in einem Projekt auf einem agilen Board in Jira zu dokumentieren, die im Rahmen des Projektes anfallende Tätigkeiten beschreiben. Im Gegensatz zu User Stories enthalten Tasks keine Anforderungen an das Produkt und sind daher auch nicht Bestandteil der Release Notes.

Sie können, müssen aber nicht, Akzeptanzkriterien enthalten. Tasks sollten einem Epic zugeordnet werden, um zeitliche Abhängigkeiten besser erkennen und managen zu können.

Aufgaben, die unterhalb einem beliebigen Vorgangstyp erzeugt werden, heißen Sub-Tasks. Sie sind grundsätzlich nur ein Hilfsmittel zur Erledigung des übergeordneten Vorgangstyps und haben außerhalb der Steuerung des Projektes keine weitere Bedeutung.

Der Testbericht fasst die Ergebnisse einer oder mehrerer Teststufen, Testzyklen oder aller Tests für ein Release in einem Bericht zusammen.

Besonders wichtig ist, dass der Testbericht alle Abweichungen vom im Testkonzept definierten Vorgehen darstellt und begründet. Dies schließt beispielsweise Auffälligkeiten in der Traceability Matrix ein und Testfälle, die auch zum Ende der Teststufe oder des Releases nicht pass sind (also nicht erfolgreich durchgeführt werden konnten).

Für ein GxP-relevantes computerisiertes System (also eines, das validiert werden muss), ist der Testbericht die Grundlage für den Validierungsbericht.

Zwingend erforderlich sind in einem Testfall, die Dokumentation erforderlicher Testschritte mit dem jeweils erwarteten (Zwischen-)Ergebnis. Außerdem sollte für jeden Testschritt festgelegt werden, ob und in welcher Form ein objektiver Nachweis erforderlich ist.

Die zu verwendenden Testdaten können vorgegeben oder erst im Testprotokoll gewählt und dokumentiert werden.

Weitere Informationen in einem Testfall können beispielsweise sein

• die Klassifikation des genutzten Testverfahrens,
• die Dokumentation von Abhängigkeiten zu anderen Testfällen oder sonstige Voraussetzungen zur Durchführung und
• die Kennzeichnung, ob der Testfall für die Durchführung standardmäßiger Regressionstests genutzt werden soll.

Das Testkonzept ist die Grundlage aller Testaktivitäten und wird in Zusammenarbeit mit allen Stakeholdern erstellt. Es beschreibt im Wesentlichen Was, Wer, Wann, in welchem Rahmen und mit welchen Mitteln in Bezug auf das Testen durchführen soll:

• Rahmenbedingungen (z.B. Testumgebung, Werkzeuge, finanzielle und personelle Ressourcen, Schulungsbedarf)
• Testbasis, Testobjekte, spezifische Risiken
• Teststrategie (Testprozesse, Teststufen, Testeingangs- und Testendekriterien)
• Vorgehensweise (Testumfang, Methodiken, Retests, Regressionstests)
• Dokumentation der Tests, Metriken
• Zeitliche Planung

Die Testfälle (auch nur als Tests bezeichnet) und ihre Ausführungen (Executions) werden in einem Vorgangstyp Test Plan zusammengefasst, der leicht mit dem Testkonzept verwechselt werden kann.

Hinweis: Der Testplan ist zudem ein in Unternehmen häufig genutztes Synonym für das Testkonzept, meint aber gemäß ISO 29119 nur die zeitliche Planung (test schedule (EN)), ist also eine problematische Benennung des Dokumentes.

Die Testfälle (in Tools oft nur: Tests) und ihre Ausführungen (Executions) werden einem Test Plan zugeordnet, d.h. alle Tests, die für eine bestimmte Version, zu einer bestimmten Zeit bzw. in einer bestimmten Teststufe ausgeführt werden sollen, werden zusammengefasst. Im Testkonzept wird auf den Test Plan häufig nur verwiesen, um Redundanzen zu vermeiden.

Hinweis: Der Testplan ist ein in Unternehmen häufig genutztes Synonym für das Testkonzept, meint aber gemäß ISO 29119 nur die zeitliche Planung (test schedule (EN)), ist also eine problematische Benennung des Dokumentes.

Ein Testprotokoll enthält neben den verwaltenden Informationen (wer hat das wann ausgeführt), vor allem folgende Details:

• Tatsächliches Ergebnisse der einzelnen Testschritte
• Objektive Beweise (falls gefordert)
• Verweis auf Defekte

Die Traceability Matrix ermöglicht die Verfolgbarkeit einer Story und eines Risikos über die geplanten und durchgeführten Testfälle und zu eventuell ermittelten Fehlern (Defects), sie ist ein wichtiges Hilfsmittel für die Erstellung von Testbericht und Validierungsbericht und ermöglicht die Durchführung von Auswirkungsanalysen bei der Planung von Änderungen des CS.

Die Validierung, vor allem die Validierung computergestützter Systeme (CSV) weist nachvollziehbar, konsistent und wiederholbar nach, dass das CS den vorgesehenen Zweck erfüllt.

FDA considers software validation to be “confirmation by examination and provision of objective evidence that software specifications conform to user needs and intended uses, and that the particular requirements implemented through software can be consistently fulfilled.“

[…]

In large measure, software validation is a matter of developing a “level of confidence” that the device meets all requirements and user expectations for the software automated functions and features of the device. Measures such as defects found in specifications documents, estimates of defects remaining, testing coverage, and other techniques are all used to develop an acceptable level of confidence before shipping the product. The level of confidence, and therefore the level of software validation, verification, and testing effort needed, will vary depending upon the safety risk (hazard) posed by the automated functions of the device.

General Principles of Software Validation; Final Guidance for Industry and
FDA Staff, Document issued on: January 11, 2002, pp 6-7

Der Validierungsbericht fasst die Ergebnisse der Validierungsaktivitäten zusammen und bewertet unter anderem die Ergebnisse des Tests gemäß Testbericht und Traceability Matrix sowie eventuelle Abweichungen zum Validierungsplan.

Zeitgleich mit dem Validierungsbericht wird auch eine aktualisierte Version des Validierungsinventars erzeugt.

Das Validierungsinventar listet alle für die Validierung wichtigen Artefakte mit Version, Gültigkeitsdatum und Ablageort auf. Sie ist damit ein zentrales Dokument zum Ziehen einer Baseline.

Die Validierungsleitung ist gemäß SOP Validierung computergestützter Systeme verantwortlich für die Erstellung des Validierungsplans, des Validierungsinventars und des Validierungsberichtes.

Sie verantwortet damit die Validierungsstrategie und deren Umsetzung, begleitet sämtliche im Validierungsplan vereinbarten Aktivitäten aus regulatorischer Sicht und berät das Projekt- oder Scrum Team, vor allem Systemeigner und Prozesseigner, hinsichtlich der regulatorischen Konformität.

Sie überprüft die Durchführung der Maßnahmen und die Konformität mit den regulatorischen Vorgaben und stimmt sich diesbezüglich mit der Rolle IT-Qualitätsbeauftragter ab.

Der Validierungsplan beschreibt den vorgesehenen Zweck des Systems und ein grobes Systemdesign, plant alle für die Validierung notwendigen Validierungsaktivitäten und die zu erzeugenden Artefakte.

Die Traceability Matrix ermöglicht die Verfolgbarkeit einer Story und eines Risikos über die geplanten und durchgeführten Tests und zu eventuell ermittelten Fehler, sie ist ein wichtiges Hilfsmittel für die Erstellung von Testbericht und Validierungsbericht und ermöglicht die Durchführung von Auswirkungsanalysen bei der Planung von Änderungen des CS.

Im Rahmen des GxP-Umfelds und dieses Frameworks gibt es zwei besondere Sprints:

• Vorbereitungs-Sprint (erster Sprint)
• Abschluss-Sprint / Release-Sprint (letzter Sprint)

Das Agile Validierungs-Framework nutzt als Beispiel für ein Tracking-Tool Jira mit dem Plug-in Xray. Die darin konfigurierten Vorgangstypen (issue types) sind:

• Epic
• Story
• Task
• Defect
• Sub-Task
• Impediment
• Testplan
• Test Vorbedingung
• Test Set
• Test
• Execution
• Risk
• Mitigation

Zu jedem Vorgangstyp gehört ein passender Workflow, der die genutzten Status und die erlaubten Übergänge definiert sowie Bildschirmmasken, in denen die Anzeige bei Erstellen, Bearbeiten oder Ansehen von Vorgängen konfiguriert werden.

Der Begriff Intended Use wird im GAMP 5 als vorgesehener Zweck übersetzt. In anderen Quellen findet man auch:

• beabsichtigter Zweck
• vorgesehener Nutzen
• beabsichtigter Nutzen