{"id":60,"date":"2018-01-25T14:44:53","date_gmt":"2018-01-25T14:44:53","guid":{"rendered":"http:\/\/its-niehoff.de\/?page_id=60"},"modified":"2022-10-03T12:29:22","modified_gmt":"2022-10-03T12:29:22","slug":"ablauf-der-validierung","status":"publish","type":"page","link":"https:\/\/its-niehoff.de\/?page_id=60","title":{"rendered":"Ablauf der Validierung"},"content":{"rendered":"

\"\"Schulung und Information<\/strong><\/p>\n

Eine strukturierte Projektarbeit zur Validierung eines computergest\u00fctzten Systems beginnt mit Schulung und Information. Nur wenn alle Mitarbeiter, die mit einer validierten Software arbeiten, ausreichend \u00fcber Softwarevalidierung informiert sind, kann die Validierung durchgef\u00fchrt werden. Dabei ist neben dem Ziel der Validierung auch der Umgang mit einem validierten System wichtig.<\/p>\n

Nach der Schulung m\u00fcssen die Rahmenbedingungen definiert werden. Diese Rahmenbedingungen m\u00fcssen in einem „Validationmasterplan<\/strong> (VMP“ definiert werden. Details zu einem VMP finden Sie hier<\/a>.<\/p>\n

Nachdem der VMP definiert und von allen Mitarbeitern akzeptiert ist, werden vorhanden Computergest\u00fctzte Systeme inventarisiert.<\/p>\n

Jedes inventarisierte System wird auf die Kritikalit\u00e4t<\/a> untersucht. Nur Systeme, die als kritisch eingestuft werden, m\u00fcssen validiert werden. Kritische Systeme werden validiert.<\/p>\n

F\u00fcr Systeme, die als kritisch eingestuft werden, muss ein Lastenheft<\/a> und ein Pflichtenheft<\/a> 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\u00fcssen ein Pflichtenheft erstellen. Dabei beschreibt der Hersteller, so detailliert wie m\u00f6glich, wie die geforderten Lasten in dem System umgesetzt sind. Die Erstellung eines Pflichtenheftes ist schon sehr aufw\u00e4ndig und wird oftmals untersch\u00e4tzt. Dabei ist das Pflichtenheft f\u00fcr Sie die Grundlage, nachdem die Testf\u00e4lle erarbeitet werden k\u00f6nnen. Wir empfehlen dabei die Beschreibung des Pflichtenheftes durch eine neutrale Person auf Testbarkeit pr\u00fcfen zu lassen.<\/p>\n

Aus der Beschreibung des Lastenheftes und des Pflichtenheftes k\u00f6nnen „user requirements specification“ definiert werden. Diese user requirements specification oder auch als URS oder Benutzeranforderung bezeichnet, definieren Ihre Anforderungen an eine Last des Computergest\u00fctzten Systems. Diese URS m\u00fcssen testbar sein. Sie sollten also m\u00f6glichst pr\u00e4zise beschrieben sein.<\/p>\n

Die URS werden in eine Risikoeinsch\u00e4tzung \u00fcberf\u00fchrt. Bei der Risikoeinsch\u00e4tzung wird ganz destruktiv gepr\u00fcft, was alles zu einem Fehler in dem System f\u00fchren kann. Die Risikoeinsch\u00e4tzung wiederum wird in eine Risikoanalyse \u00fcberf\u00fchrt. Die Risikoanalyse<\/a> ist dabei das zentrale Element einer Softwarevalidierung.<\/p>\n

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\u00fchrt werden. Das Testen bei dem Hersteller einer Software ist dabei sehr viel aufw\u00e4ndiger und realistisch nur automatisiert durchzuf\u00fchren. Der Anwender hat in der Regel keine Kenntnis \u00fcber die inneren Strukturen der Software. Automatisierte Tests m\u00fcssen programmiert werden und die Wirksamkeit des Testes muss nachgewiesen werden. Daf\u00fcr fehlen dem Anwender in der Regel sowohl die Instrumente wie auch die Kenntnisse.<\/p>\n

Nachdem alle geforderten und zugesicherten Lasten erfolgreich getestet wurden, kann das System f\u00fcr die Routine freigegeben werden.<\/p>\n

Um das validierte System in einem validen Zustand zu halten, ist es notwendig alle St\u00f6rungen und \u00c4nderungen zu dokumentieren.<\/p>\n

St\u00f6rungen werden in einem Incident\u00a0Management behandelt. \u00c4nderungen werden in einem Change\u00a0Management behandelt. Im Gegensatz zu dem Incident Management ist das Change Management etwas aufw\u00e4ndiger. Dabei ist es wichtig zu verstehen, dass sich das Change Management auf ge\u00e4nderte Funktionalit\u00e4ten oder Anpassungen bei Konfigurationen bezieht. Nicht auf \u00c4nderungen der Bewegungsdaten wie ein Auftrag.<\/p>\n

\u00c4nderungen an einem validierten System m\u00fcssen strukturiert ablaufen. Diese \u00c4nderungen werden auch als Change, als Change Control oder als Request for Change benannt. Es geht dabei aber nur um eine strukturierte Bearbeitung einer \u00c4nderungen. Wir orientieren uns bei einem Request for Change an die Anforderungen von ITIL V3 erg\u00e4nzt um die Anforderungen des Annex 11.<\/p>\n","protected":false},"excerpt":{"rendered":"

Schulung und Information Eine strukturierte Projektarbeit zur Validierung eines computergest\u00fctzten Systems beginnt mit Schulung und Information. Nur wenn alle Mitarbeiter, die mit einer validierten Software arbeiten, ausreichend \u00fcber Softwarevalidierung informiert sind, kann die Validierung durchgef\u00fchrt werden. Dabei ist neben dem Ziel der Validierung auch der Umgang mit einem validierten System wichtig. Nach der Schulung m\u00fcssen … <\/p>\n

\u201eAblauf der Validierung\u201c<\/span> weiterlesen<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":[],"_links":{"self":[{"href":"https:\/\/its-niehoff.de\/index.php?rest_route=\/wp\/v2\/pages\/60"}],"collection":[{"href":"https:\/\/its-niehoff.de\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/its-niehoff.de\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/its-niehoff.de\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/its-niehoff.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=60"}],"version-history":[{"count":6,"href":"https:\/\/its-niehoff.de\/index.php?rest_route=\/wp\/v2\/pages\/60\/revisions"}],"predecessor-version":[{"id":105,"href":"https:\/\/its-niehoff.de\/index.php?rest_route=\/wp\/v2\/pages\/60\/revisions\/105"}],"wp:attachment":[{"href":"https:\/\/its-niehoff.de\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=60"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}