• gmp-publishing.com
  • Login GMP-Datenbanken
  • Warenkorb
GMP-Newsletter: LOGFILE

Lesen Sie GMP-News und informative Beiträge zum Thema GMP in unserem kostenlosen GMP-Newsletter "LOGFILE".

 

>>> Mehr Infos & Anmeldung

PDE-Gutachten
Seit 1. Juni 2016 müssen für alle Human- und Tierarzneimittel, die in Mehrzweckanlagen hergestellt werden PDE-Werte für enthaltene Wirkstoffe ermittelt werden.

Image

Wir liefern zur Zeit PDE-Gutachten für über 1500 Wirkstoffe!

Sie erhalten Ihr Gutachten:
...gemäß EMA-Richtlinie
...auf Englisch
...ausgestellt auf Ihr Unternehmen
...erstellt durch europ. Toxikologen

>>> Mehr erfahren
GMP-Risikoanalysen

Image

Standardvorlagen für Räume und Ausrüstung im pharmazeutischen Umfeld

Einfach, schnell und günstig zur Risikoanalyse

>>> Jetzt informieren: GMP-Risikoanalysen

GMP LOGFILE: Leitartikel

21.11.2017

LOGFILE Nr. 44/2017 – System-Lebenszyklus - Das "V-Modell"

System-Lebenszyklus – das V-Modell

Auszug aus dem GMP-Fachwissen Computergestützte Systeme im GMP-Umfeld

5 min. Lesezeit

von Markus Roemer

 

Das "V-Modell"

Für die Validierung computergestützter Systeme wird als Referenzmodell das so genannte V-Modell herangezogen. Dabei wird das Modell in sehr vielen und verschiedenen Ausprägungen verwendet und dargestellt. Das kann auch zu Verwirrungen oder Missverständnissen führen, so dass hier primär die Charakteristika dieser Vorgehensweise beschrieben werden sollen.

Das V-Modell eignet sich zur Darstellung von Spezifikations- und zugehörigen Testphasen. Die einzelnen Tests – Akzeptanztests, Systemtests und Integrationstests – werden gegen die entsprechenden Vorgabedokumente, Benutzeranforderungen und Systemspezifikationen beziehungsweise technischen Spezifikationen durchgeführt.

Die exakte Festlegung der einzelnen Stufen des V-Modells muss für einen skalierbaren Validierungsansatz anpassbar sein (siehe ISPE-GAMP®5-Klassifizierung). Das Modell bietet generell eine verein-fachte und gut verständliche Darstellung der Vorgehensweise bei der Validierung zwischen Spezifikations- und Testphasen an. Zur Abbildung des gesamten System-Lebenszyklus und aller Validie-rungsmaßnahmen (z. B. Schulungen, Installation etc.) bedarf es allerdings einer anderen Darstellungsform (z. B. Workflow-Diagramme o. Ä.).

Das V-Modell erhielt seinen Namen aus der Darstellung des Buchstabens „V“, in dem der linke Teil die Spezifikationsphasen und der rechte Teil die Testphasen darstellen soll. Teilweise werden hori-zontale Linien zwischen dem linken und rechten Teil gezogen, womit verdeutlicht wird, dass hier eine Abhängigkeit zwischen der jeweiligen Spezifikation (linke Seite) und der Testphase (rechte Seite) besteht.

Meist wird das V-Modell in vier Ebenen dargestellt (siehe Abbildung 1):

Abbildung 1 Beispieldarstellung des V-Modells

Image

Die einzelnen Phasen sollen nachstehend erläutert werden:

Das Dokument der Benutzeranforderung beinhaltet entweder die prozess- oder funktionsbasierten Anforderungen des Benutzers bzw. Prozessverantwortlichen:

  • Beispiel „prozessbasiert“: Nur autorisierte Benutzer dürfen ein Zugangsrecht zum System
    haben.
  • Beispiel „funktionsbasiert”: Das System muss über einen Passwortschutz verfügen.

Man erkennt schon an diesem relativ einfachen Beispiel, dass die Entwicklung und Darstellung von Anforderungen unterschiedlich ausfallen können.

In der funktionalen Spezifikation werden die Benutzeranforderungen weiter funktional zur Umsetzung detailliert.

  • Beispiel: Passwortschutz mit modalem Dialogfeld/Eingabe Benutzerkennung und Passwort

Die technische Spezifikation (Design) ist eine Erläuterung für den Programmierer, wie die Systemspezifikation umzusetzen ist.

  • Beispiel: Datenbankfeld DbfPsw: 16 Chr, Alphanum, Dlgform.properties: mod = true. In der Programmentwicklung wird dieses technische Design in ein lauffähiges Programm verwandelt.

Das technische Design kann auch die Festlegung der benötigten Hardware enthalten und aus mehreren Teilen bestehen. Bei einer SPS-Anlage könnten dies z. B. detaillierte Stromlaufpläne oder Funktionsdiagramme sein; bei Datenbanksystemen z. B. Entity-Relationship-Diagramme oder Schnittstellenspezifikationen; für eine Tabellenkalkulation die Formelbeschreibung eines Felds; bei der Datenmigration ein technischer Datenmigrationsplan usw.

Beim Unit-Test wird geprüft, ob die Programmeinheit – auch Modul oder Unit genannt – läuft. Die Prüfung erfolgt z. B. über den White-Box-Test.

Der Integrationstest dient zur Überprüfung, ob die technische Spezifikation eingehalten wurde. Im Integrationstest werden auch die Eignung und das Zusammenwirken der Programmeinheiten getestet.

  • Beispiel: Ist der Name des Datenbankfeldes DbfPsw? usw.

Beim Systemtest/Functional Test wird das Programm gegen die Systemspezifikationen geprüft.

  • Beispiel: Ist der Passwortschutz modal? Falsche Eingaben, Abbruch der Funktion, weitere Funktionsprüfungen

Im Akzeptanztest/Requirements Test wird das System gegen die Benutzeranforderungen geprüft.

  • Beispiel: Ist der Passwortschutz vorhanden?

Ein Nachteil des „einfachen“ V-Modells ist, dass verschiedene Dokumente oder Phasen nicht oder nicht vollständig abgebildet werden, z. B. Testplan, Testbericht, Risikoanalysen, Systeminstallationen (Test- und Produktivumgebung), Systemdokumentation wie Installationsanweisung/Benutzerhandbuch oder die jeweiligen Verantwortlichkeiten in den Phasen.

Nimmt man alle Phasen und Dokumente in das Modell auf, wird es ab einem gewissen Punkt unübersichtlich. Auch für zyklische Wiederholungen (z. B. neue Revision einer Spezifikation, zweiter Testlauf nach Fehlerbehebung) stößt das Modell an seine Darstellungsgrenzen.

Generell lässt sich noch feststellen, dass die oberen Bereiche des V-Modells eher anwender- bzw. prozessorientiert sind (Verantwortung beim Betreiber) und der untere Bereich eher funktionale und technische Inhalte (primäre Verantwortung beim Lieferanten) hat.

Der Erfolg eines Projektes und die Erreichung der Validierungsziele hängen wesentlich davon ab, wie die Prozesse und Dokumente im linken Ast des V-Modells umgesetzt werden, d.  h. wie eine Anforderung des Benutzers im Detail bis zum Entwickler des Systems transformiert wird. Dabei muss berücksichtigt werden, dass der Benutzer zum Beispiel eine pharmazeutische Ausbildung hat und der Entwickler Informatiker ist. Hier kann die Validierung als ein Kommunikationsmodell dienen. Die meisten Fehler in einer Software sind schlicht und einfach missverstandene Anforderungen. Die entstehenden Kosten zur Beseitigung von Fehlern in einer späteren Testphase oder im Produktivbetrieb steigen sehr stark an, so dass sich hier fundierte Überlegungen und eine praktikable Auslegung des Informationsflusses zwischen Benutzer und Entwickler grundsätzlich lohnen (z. B. Requirements Engineering und Management).

Es ist zum Beispiel auch eine Möglichkeit, ein Projekt mit einer definierten Prototypen-Entwicklungsphase zu beginnen. Dabei wird in enger Zusammenarbeit ein System als Prototyp bis zu einem gewissen Reifegrad entwickelt und gemeinsam bewertet. Der Vorteil ist, dass man sich ein deutlich besseres Bild über das System und die Abdeckung der Anforderungen machen kann. Solche Modelle müssen dann aber auch wieder in die Philosophie des V-Modells koordiniert zurückgeführt werden.

An dieser Stelle soll darauf hingewiesen werden, dass es keine regulatorische Forderung zur Benutzung des V-Modells gibt, sondern es nur eine Darstellungsmöglichkeit unter mehreren ist. Aus dem V-Modell kann jedoch eine sehr wertvolle Erkenntnis gezogen werden: Ein System kann nicht besser getestet werden als es spezifiziert wurde (siehe horizontale Linien).

Andere Darstellungsmodelle sind z. B. das Spiralmodell, Wasserfallmodell, Löffel-Modell, X-Modell. Das deutsche Bundesverwaltungsamt – Bundesstelle für Informationstechnik (BIT) bietet viele frei verfügbare Informationen für das V-Modell XT an (www.bit.bund.de/ im Menü Standards und Methoden; Untermenü V-Modell XT). Der Zusatz „XT“ steht dabei für „eXtreme Tailoring“ und dient der flexiblen Anpassbarkeit.

 

LOGFILE-44-System-Lebenszyklus-das_V-Modell.pdf

 

Dieser Text ist ein Auszug aus dem GMP-Fachwissen Computergestützte Systeme im GMP-Umfeld

Image

Computergestützte Systeme sind aus der modernen Arzneimittelherstellung nicht mehr wegzudenken. Dieses Buch enthält wertvolle Informationen und praxiserprobte Strategien, die eine reibungslo-se Validierung und den GMP-konformen Betrieb computergestützter Systeme auf Basis aktueller Regelwerke sicherstellen.
Dabei wird der gesamte Lebenszyklus computergestützter Systeme von der Projektplanung bis zur Stilllegung betrachtet. Auch spezielle Fragestellungen zu aktuellen Themen wie Cloud-Computing, elektronische Signatur und Datenintegrität werden aufgegriffen.

Aus dem Inhalt:

  • Regulatorische Anforderungen an die Validierung computergestützter Systeme
  • Systemklassifizierung und Risikomanagement
  • Validierung und Betrieb computergestützter Systeme
  • Externe Dienstleister
  • Datenintegrität

Autor:

Markus Roemer
Berater
comes compliance services, Ravensburg
E-Mail: markus.roemer@comes-services.com

Kommentare
Es wurden bisher noch keine Kommentare zu dieser News geschrieben
 
 
Unsere News-Redaktion empfiehlt
Datenintegrität bei computergestützten Systemen
SOP 517-01 Life Cycle computergestützter Systeme (CS)
GMP-Regelwerke für computergestützte Systeme