Ablauf der Validierung

Schulung und Information

Eine strukturierte Projektarbeit zur Validierung eines computergestützten Systems beginnt mit Schulung und Information. Nur wenn alle Mitarbeiter, die mit einer validierten Software arbeiten, ausreichend über Softwarevalidierung informiert sind, kann die Validierung durchgeführt werden. Dabei ist neben dem Ziel der Validierung auch der Umgang mit einem validierten System wichtig.

Nach der Schulung müssen die Rahmenbedingungen definiert werden. Diese Rahmenbedingungen müssen in einem „Validationmasterplan (VMP“ definiert werden. Details zu einem VMP finden Sie hier.

Nachdem der VMP definiert und von allen Mitarbeitern akzeptiert ist, werden vorhanden Computergestützte Systeme inventarisiert.

Jedes inventarisierte System wird auf die Kritikalität untersucht. Nur Systeme, die als kritisch eingestuft werden, müssen validiert werden. Kritische Systeme werden validiert.

Für Systeme, die als kritisch eingestuft werden, muss ein Lastenheft und ein Pflichtenheft vorliegen. Dabei ist das Lastenheft als eine Art Wunschkonzert anzusehen. Hier werden (testbar) alle geforderten funktionalen und nicht funktionalen Anforderungen (Lasten) definiert. Oftmals dient das Lastenheft dabei als Vertragsgrundlage. Hersteller der Software müssen ein Pflichtenheft erstellen. Dabei beschreibt der Hersteller, so detailliert wie möglich, wie die geforderten Lasten in dem System umgesetzt sind. Die Erstellung eines Pflichtenheftes ist schon sehr aufwändig und wird oftmals unterschätzt. Dabei ist das Pflichtenheft für Sie die Grundlage, nachdem die Testfälle erarbeitet werden können. Wir empfehlen dabei die Beschreibung des Pflichtenheftes durch eine neutrale Person auf Testbarkeit prüfen zu lassen.

Aus der Beschreibung des Lastenheftes und des Pflichtenheftes können „user requirements specification“ definiert werden. Diese user requirements specification oder auch als URS oder Benutzeranforderung bezeichnet, definieren Ihre Anforderungen an eine Last des Computergestützten Systems. Diese URS müssen testbar sein. Sie sollten also möglichst präzise beschrieben sein.

Die URS werden in eine Risikoeinschätzung überführt. Bei der Risikoeinschätzung wird ganz destruktiv geprüft, was alles zu einem Fehler in dem System führen kann. Die Risikoeinschätzung wiederum wird in eine Risikoanalyse überführt. Die Risikoanalyse ist dabei das zentrale Element einer Softwarevalidierung.

Aus den URS und dem Ergebnis der Risikoanalyse werden Akzeptanzkriterien abgeleitet. Gegen diese Akzeptanzkriterien wird getestet. Anwenderseitig kann hier nur ein Black Box Test durchgeführt werden. Das Testen bei dem Hersteller einer Software ist dabei sehr viel aufwändiger und realistisch nur automatisiert durchzuführen. Der Anwender hat in der Regel keine Kenntnis über die inneren Strukturen der Software. Automatisierte Tests müssen programmiert werden und die Wirksamkeit des Testes muss nachgewiesen werden. Dafür fehlen dem Anwender in der Regel sowohl die Instrumente wie auch die Kenntnisse.

Nachdem alle geforderten und zugesicherten Lasten erfolgreich getestet wurden, kann das System für die Routine freigegeben werden.

Um das validierte System in einem validen Zustand zu halten, ist es notwendig alle Störungen und Änderungen zu dokumentieren.

Störungen werden in einem Incident Management behandelt. Änderungen werden in einem Change Management behandelt. Im Gegensatz zu dem Incident Management ist das Change Management etwas aufwändiger. Dabei ist es wichtig zu verstehen, dass sich das Change Management auf geänderte Funktionalitäten oder Anpassungen bei Konfigurationen bezieht. Nicht auf Änderungen der Bewegungsdaten wie ein Auftrag.

Änderungen an einem validierten System müssen strukturiert ablaufen. Diese Änderungen werden auch als Change, als Change Control oder als Request for Change benannt. Es geht dabei aber nur um eine strukturierte Bearbeitung einer Änderungen. Wir orientieren uns bei einem Request for Change an die Anforderungen von ITIL V3 ergänzt um die Anforderungen des Annex 11.