Allgemeine Grundsätze der Software Validierung

Publiziert am 29. Juni 2014 von schludi

Zweck

Dieses Dokument dient als Leitfaden für die Software Validierung und stellt die Ansichten der FDA (Food and Drug Administration) über dieses Thema dar.
Die Anleitung fasst allgemeine Validierungsprinzipien zusammen, die die FDA vorschreibt für die Validierung von Entwurfs-, Entwicklungs- und Produktionssoftware von Medizingeräten.

Rahmen

Dieser Leitfaden beschreibt, wie sich bestimmte Vorkehrungen für das Qualitätssystem von Softwrare medizinischer Geräte mit dem momemtanen Ansatz der FDA und Evaluierung von Software-Validierungssystemen treffen lassen.

Anmerkung: Das Wort ¨System¨ benutzt die FDA oft als Definition für ein Bündel mehrerer Prozesse.

Dieses Dokument zeigt Kriterien, die von der FDA für die Validierung von Software akzeptiert werden. Jedoch zeigt es nicht alle Aktivitäten und Aufgaben für die Einhaltung des Gesetzes in allen Instanzen.

Wenn Software von jemand anderem als dem Gerätehersteller entwickelt wird, darf der Software Entwickler nicht direkt für die

Software Validierung ist eine Anforderung der Qualitätssystemerichtlinie, welche am 7. Oktober 1996 veröffentlicht wurde (21 Code of Federal Regulation (CFR) Part 820 bzw. 61 Ferderal Register (FR) 52602). Validierungsanforderungen beziehen sich auf…

… Software die als Komponente in medizinischen Produkten genutzt wird
… Software die selbst ein medizinisches Produkt ist
… Software die bei der Produktion medizinischer Produkte genutzt wird
… Software die bei der Entwicklung medizinischer Produkte genutzt wird
… Software die bei der Implementierung des Qualitätssystems des Medizingeräteherstellers genutzt wird
- … Software die das Device Design History File aufzeichnet

Terminologie

Requirement

Ein Requirement ist jedes Bedürfnis oder jede Erwartung an ein System oder dessen Software.

Es gibt die folgenden Arten von Requirements:

Design Requirements
Functional Requirements
Implementation Requirements
Interface Requirements
Performance Requirements
Physical Requirements

Software Requirements werden typischerweise von System Requirements hergeleitet und in funktionalen Begriffen erklärt. Sie werden genau ausgestaltet, definiert und während dem Fortschreiten des Entwicklungsprojektes beschrieben.

Spezifikation

Eine Spezifikation wird als ein Dokument, welches Requirments erklärt/darlegt, definiert (Siehe 21 CFR §820.3(y).).

Zu einer Spezifikation gehören zum Beispiel die folgenden Artefakte

Zeichnungen
Muster
relevante Dokumente
…

In der Spezifikation stehen auch Prüfkriterien und -mittel um ein Requirement hinsichtlich seiner Konformität zu überprüfen.

Es gibt die folgenden Arten von Spezifikationen

System Requirements Specification
Software Requirements Specification
Software Design Specification
Software Test Specification
Software Integration Specification

Alle diese Spezifikationsdokumente definieren spezifierte Requirements und dienen als ¨Design Output¨, wofür verschiedenste Formen der Verifikation notwendig sind.

Verifizierung und Validierung

Die Prozesse des Qualitätsmanagmentsystems werden in der ISO-Norm ISO 8402:1994 beschrieben, welche die Begriffe Verifikation und Validierung als zwei unterschiedliche und eindeutige Dinge definiert. Demgegenüber gibt es viele Software Engineering Zeitschriften, Artikel und Fachbücher, welche die Begriffe ¨Validierung¨ und ¨Verifikation¨ wie Synonyme behandeln.

Die Definitionen werden hier nach der Norm gewählt.

Software Verification

Software Verifikation führt den objektiven Beweis, dass der ¨Design Output¨ einer einzelnen Phase im Softwareentwicklungslebenszyklus alle spezifizierten Requirements erfüllt.
Software Verifikation überprüft die Widerspruchsfreiheit, die Vollständigkeit und die Korrektheit von Software und ihrer Dokumentation, wie sie entwickelt wird und unterstützt anschließend Schlussfolgerungen ob die Software validiert ist.

Software Tests sind eine von mehren Verifikationsmöglichkeiten, die belegen sollen dass das Softwareentwicklungsergebnis (Design Output) den eingeflossenen Requirements (Design Input) entspricht.

Verfikationsmöglichkeiten/Aktivitäten zur Verifizierung von Software sind u.a.

Code Analysen
Softaretests
- Code-Durchgänge bzw. Debugging
- Logging
- Unit Tests …
Dokumentenreviews
und viele weitere Techniken …

Software Validierung

Software Validierung ist Teil der Design Validierung für ein fertiges Gerät, wird aber nicht separat in der Qualitätssystemverordnung aufgeführt.

Die FDA erwähnt Software Validierung als…

¨… Bestätigung durch Untersuchungen und Erbringung eines objektiven Beweises, dass die Software Spezifikation konform zu den Benutzeranforderungen und dem vorgesehenem Verwendungszeck ist und das einzelne Requirements, die durch Software implementiert wurden, durchgängig erfüllt sind.¨In der Praxis können Software Validierungsaktivitäten, die sicherstellen ob die Software Requirements erfüllt sind, sowohl während der Entwicklung als auch am Ende des Software Development Life Cycles auftreten.
Seit Software für gewöhnlich ein Teil größerer Hardwaresysteme ist, wird die Softwarevalidierung den Beweis beinhalten, dass alle Software Requirements korrekt , komplett und nachvollziehbar/rückverfolgbar zu den System Requirements implementiert/umgesetzt wurden.
Die Schlussfolgerung darauf, dass Software validiert ist, hängt stark von ausführlichen Softwaretests, Überprüfungen, Analysen und anderen Software Verifikationsaktivitäten ab, die in den verschiedensten Phasen des Software Development Life Cycles ausgeführt werden.
Das Testen der Softwarefunktionalität des Gerätes in einer simulierten Benutzungsumgebung und Benutzer-seitiges Testen sind typische Bestandteile des allgemeinen Design Validierungsprogrammes.

Software Verifikation und Validation ist schwer, weil ein Entwickler nicht ewig testen kann. Es ist auch nicht leicht zu wissen, wieviel Beweisführung notwendig ist. Software Validierung beinhaltet die Entwicklung eines gewissen Vertrauensgrades (¨level of confidence¨) in die Erfüllung der Anforderungen, Benutzererwartungen und automatisierten Softwarefunktionen und -features des Gerätes.
Maßnahmen über gefundene Defekte in Spezifikationsdokumenten und Abschätzungen über verbleibende Defekte, Testabdeckungen und andere Techniken werden alle genutzt um einen angemessenen Vertrauensgrad (¨level of confidence¨) zu entwickeln, bevor das Produkt in den Markt kommt.
Der Vertrauensgrad, der Grad der Softwarevalidierung und -verifikation, sowie der benötigte Testaufwand wird in Abhängigkeit des Sicherheitsrisikos und der Gefahr (Hazard) der automatisierten Funktionen des Gerätes variieren.

Zusätzliche Leitlinien bezüglich des Risikomanagements für Software beinhaltet der internationale Standard ISO/IEC 14971-1 und IEC 60601-1-4 (Referenziert in Anhang A).

IQ/OQ/PQ

Für viele Jahre haben sowohl die FDA, als auch die regulierte Industrie versucht Software Validierung im Kontext der Prozessvalidierungsterminologie zu verstehen und zu definieren. Zum Beispiel beschreiben Industriedokumente und andre FDA Validierungsrichtlinien manchmal die Benutzer-seitige Software Validierung in den Begriffen:

Installationsqualifikation (IQ)
Operationale Qualifikation (OQ)
Performancequalifikation (PQ)

Diese Begriffe und zusätzliche Informationen bezüglich der Begriffe IQ,OQ und PQ können in den folgenden FDA Richtlinien gefunden werden:

Guideline on General Principles of Process Validation (May 1987)
Glossary of Computerized System ans Software Development Terminology (August 1995)

Während die IQ/OQ/PQ Terminologie ihren Zweck sehr gut erfüllt hat und eine von mehreren gültigen Möglichkeiten für die Organisation von Softwarevalidierungsaufgaben auf der Benutzerseite ist, wird sie von vielen Softwareexperten nicht ausreichend verstanden und wird hier daher nicht weiter behandelt. Jedoch müssen sowohl dem FDA Personal, als auch dem Personal des Geräteherstellers die tatsächlichen Unterschiede in der Terminologie bewusst sein, falls Informationenen über Software Validierung eingefordert werden.

Software Entwicklung als Teil des System Designs

Die Entscheidung Systemfunktionalität durch Software zu implementieren wird typischerweise während des System Designs gemacht. Software Requirements sind üblicherweise von den allgemeinen System Requirements und dessen Design, welches beabsichtigt diverse Teile in Software zu implementieren, hergeleitet.
Für ein fertiggestelltes Gerät gibt es einen Anwenderbedarf (user needs) und einen Verwendungszweck (intended use) , wobei Benutzer in der Regel die Entscheidung, welche Requirements durch Hardware oder Software realisiert werden, nicht treffen.
Folglich muss Software Validierung im Kontext der Gesamtvalidierung des Systems betrachtet werden.

Ein ausdefiniertes Lastenheft präsentiert den Anwenderbedarf und den Verwendungszweck, für den das Produkt entwickelt wird/wurde. Das Primärziel von Softwarevalidierung ist zu zeigen, dass fertige Softwareprodukte die dokumentierten Software Requirements und System Requirements erfüllen.

Die Korrektheit und Komplettheit der System Requirements und Software Requirements wird als Teil des Design Validierungsprozesses des Gerätes verstanden. Software Validierung beinhaltet die Konformitätsbestätigung aller Software Spezifikationen und die Bestätigung das alle Software Requirements zurückfolgbar (Tracability) in die Systemspezifikationen sind.
Das Nachweisen und Belegen der allgemeinen Design Validierung des Gesamtsystems ist ein wichtiger Teil um sicherzustellen, das alle Aspekte des Medizingerätes mit den Benutzderbedarfen und dessen Verwendungszweck konform sind.

Unterschiede von Software zu Hardware

Obwohl Software und Hardware oft die selben Engineeringaufgaben haben, gibt es gravierende Unterschiede.
Hier einige Beispiele:

Die häufigsten Softwareprobleme sind auf Fehler zurückzuführen, die während des Design und Development Prozesses gemacht wurden, während die Qualität eines Hardware Produktes stark von Design, Entwicklung und der Produktion abhängt, ist die Qualität eines Software Produktes primär von Design und Entwicklung mit wenig Bedenken bzgl. Ihrer Herstellung geprägt. Softwareerstellung bedeutet lediglich das Kopieren/Vervielfältigen von Programmen, was leicht zu verifizieren ist. Es ist nicht schwer tausende Kopien eines Programmes herzustellen die exakt wie das Original funktionieren. Die Schwierigkeit besteht darin, dass das Original-Programm alle Spezifikationen erfüllt.
Software kann eine alternative Serie von Anweisungen ausführen, die von der ursprünglichen Eingabe abhängig sind. Dies ist der am meisten beitragende Faktor für die unterschiedliche Charakteristik von Hardware und Software und ihrer Komplexität. Sogar kurze Programme können sehr komplex und schwer zu verstehen sein
Üblicherweise kann das Testen alleine nicht sicherstellen, dass Software vollständig und korrekt ist. Zusätzlich zum Testen werden weitere Verifikationsmaßnahmen und ein gut strukturierter und dokumentierter Entwicklungsprozess kombiniert um einen umfassenden Validierungsansatz sicherzustellen.
Im Gegensatz zu Hardware ist Software nicht physisch und kann daher nicht verschleissen. Software kann sich im Alter verbessern, wenn verborgene Defekte aufgedeckt und entfernt werden. Die Tatsache, dass Software Updates und Änderungen erhält, birgt die Gefahr dass neue Defekte entstehen können, die durch die Änderung kommen können.
Im Gegensatz zu manchen Hardwarefehlern, treten Softwarefehler häufig ohne Vorwarnung auf. Programmverzweigung, die es erlaubt verschiedene Programmabschnitte während der Ausführung zu durchlaufen, kann Fehler noch lange Zeit nach der Markteinführung verstecken.
Eine weitere Charakteristik von Software ist die Leichtigkeit und Geschwindigkeit in der sie geändert werden. Dieser Faktor lässt Soft- und Hardwareexperten glauben, dass Software Probleme leicht gelöst werden können. Die Kombination mit dem fehlenden Verständnis von Software lässt Manager glauben, dass kontrolliertes Engineering bei Software nicht zu wichtig ist, wie bei Hardware. In Wirklichkeit ist aber genau das Gegenteil der Fall. Wegen der Komplexität sollte der Entwicklungsprozess von Software stärker kontrolliert werden, als der von Hardware, um Probleme die später schwer erkannt werden können im Entwicklungsprozess zu verhindern.
Im Software Code unbedeutend erscheinende Änderungen können unerwartete und sehr signifikante Probleme an einer anderen Stelle des Programmes verursachen (Seiteneffekte).
Aufgrund der hohen Nachfrage an Softwareexperten und ihrer Mitarbeit in verschiedenen Projekten an unterschiedlichen Orten, muss das Softwarepersonal, welches Änderungen an der Originalsoftware macht, nicht in die Erstellung der Oríginalsoftware involviert sein. Eine genau Dokumentation der Software ist unerlässlich.
Historisch gesehen sind Softwarebausteine nicht so häufig von Standardisierung und Änderungen wie HW Komponenten betroffen. Jedoch fangen die Entwickler von medizinischen Geräten an komponentenbasierte Entwicklungstools und -techniken zu nutzen. Objektorientierte Methoden und die Benutzung von Standardsoftwarebausteinen versprechen eine schnellere und weniger kostspielige Entwicklung. Jedoch benötigen komponentenbasierte Ansätze eine besondere Achtsamkeit während der Integration. Vor der Integration wird Zeit benötigt um wiederverwendbare Software vollends zu definieren und entwickeln und um das Verhalten von Standardsoftwarekomponenten gänzlich zu begreifen.

Aus diesen und den selbern Gründen, benötigt Software Engineering eine stärkere Kontrolle als Hardware Engineering.

Vorteile von Softwarevalidierung

Softwarevalidierung ist ein kritisches Werkzeug, welches benutzt wird um die Qualität von Gerätesoftware sicherzustellen.
Softwarevalidierung …

… verbessert die Gebrauchstauglichkeit
… die Ausfallsicherheit des Gerätes,
… führt zu sinkenden Fehlerraten,
… führt zu weniger Rückrufen und Korrekturarbeiten,
… führt zu einer Verringerung des Patienten- und Benutzerrisiko
… führt zu reduzierten Haftungsbedingungen
… reduziert die Langzeitkosten von Software …
- … durch Verbesserung der Betriebssicherheit bei Softwareänderungen und der Revalidierung der geänderten Software
- … durch die Reduzierung von Wartungsaufwänden

Design Review

Design Reviews sind eine dokumentierte, umfassende und systematische Überprüfungen des Designs um die Angemessenheit der Design Requirements zu bewerten, deren Tauglichkeit sicherzustellen und Probleme zu identifzieren. Während in einem Entwicklungsteam während eines Softwareprojektes viele formlose technische Design Reviews stattfinden können, ist ein formelles Design Review strukturierter und enthält Beteiligung von anderen Mitarbeitern außerhalb des Entwicklungsteams. Formelle Design Reviews können Ergebnisse von anderen formellen oder informellen Design Reviews referenzieren oder einbeziehen. Design Reviews können separat für die Software durchgeführt werden, nachdem die Software mit der Hardware in ein System integriert wurde.
Design Reviews sollten die Überprüfung

zur Einhaltung des Development Planes
der Requirements Spezifikation
der Design Spezifikation
des Testplans und -prozeduren
allen anderen Dokumenten und Akvtitäten die mit dem Projekt in Verbindung gebracht werden
Ergebnisse von Verifikation jedes Stadiums des defnierten Lebenszyklusses
Valildierungsergebnisse des Gesamtgerätes

enthalten.

Design Reviews sind das Primärwerkzeug für das Management und die Bewertung von Entwicklungsprojekten. Zum Beispiel erlauben es formelle Design Reviews zu bestätigen, dass alle Ziele, die im Softwarevalidierungsplan definiert wurden, auch erreicht sind. Die Verordnung für Qualitätssysteme erfordert mindestens ein formelles Design Review während der Entwurfsphase des Gerätes. Jedoch wird empfohlen, mehrere Design Reviews durchzuführen (beispielsweise am Ende jeder Aktivität im Softwarelebenszyklus, als Vorbereitung auf die nächste Aktivität). Formelle Design Reviews sind besonders gegen Ende der Anforderungsaktivitäten, vorher wurden die Hauptressources zu den spezifischen Lösungen. Probleme die an diesem Punkt gefunden werden, können einfach gelöst werden, Zeit und Geld sparen und reduzieren die Wahrscheinlichkeit für das Übersehen eines kritischen Fehlers.
Die folgenden Antworten auf ein paar Schlüsselfragen sollten während des formellen Design Reviews dokumentiert werden:

Wurden die entsprechenden Aufgaben, erwarteten Ergebnisse, Outputs oder Produkte definiert, dokumentiert oder implementiert für alle Aktivitäten im Softwarelebenszyklusses?
- Entsprechen die Aufgaben und die erwarteten Ergebnisse, Outputs oder Produkte aller Aktivitäten im Softwarelebenszyklus allen Anforderungen anderer Aktivitäten im Softwarelebenszyklus in Sachen Korrektheit, Vollständigkeit, Konsistenz und Genauigkeit?
- Erfüllen die Aufgaben und die erwarteten Ergebnisse, Outputs oder Produkte aller Aktivitäten im Softwarelebenszyklus die Standards, die Praxis und Abmachungen der Aktivität
- Defnieren, dokumentieren oder implementieren die erwarteten Ergebnisse, Outputs oder Produkte aller Aktivitäten im Softwarelebenszyklus eine angemessene Basis um Aufgaben für die nächste Life Cycle Aktität zu initiieren?

Grundlagen der Software Validierung

Dieser Abschnitt listet die allgemeinen Grundlagen, die bei der Validation von Software berücksichtigt werden sollten.

Requirements

Eine dokumentierte Software Requirements Spezifikation stellt eine Baseline sowohl für Validierung als auch für die Verifizierung zur Verfügung. Der Softwarevalidierungsprozess kann ohne eine ausdefinierte und dokumentierte Software Requirements Specification nicht abgeschlossen werden (Ref: 21 CFR 820.3(z) and (aa) and 820.30(f) and (g)).

Fehlervermeidung

Softwarequalitätssicherung sollte sich auf die Verhinderung von Fehlern in den Software-Entwicklungsprozess fokussieren und nicht versuchen, die Qualität in den Softwarecode “reinzutesten”, nachdem er geschrieben wurde. Das Testen von Software ist sehr beschränkt in seiner Fähigkeit alle verborgenen Fehler im Code ans Tageslicht zu führen. Zum Beispiel verhindert die Komplexität am meisten bei Software, dass sie vollständig getestet wird.
Das Testen von Software ist eine notwendige Aktivität. Jedoch ist das Testen von Software durch Software meistens nicht ausreichend um die Gewissheit zu erlangen dass die Software ihren vorgesehenen Verwendungszweck (Intended Use) erfüllt.
Damit man der Software ein gewisses Vertrauen zukommen lassen kann, sollten Softwareentwickler eine Mischung von Methoden und Techniken anwenden um Softwarefehler zu verhindern und zu erkennen das Software Fehler auftreten können. Die beste Mischung von Methoden hängt von vielen Faktoren ab, die Eintwicklungsumgebung, Anwendung, Projektgröße und das Risiko eingeschlossen.

Zeit und Aufwand

Den Status zu erhalten, das Software validiert ist benötigt Zeit und Aufwand. Die Vorbereitung der Softwarevalidierung sollte früh anfangen, z.B. während der Design und Development Planung und dem Design Input. Der Entschluss, dass die Software validiert ist, sollte aus den gesammelten Nachweisen geplanter Validierungsaktitäten stammen, die im Laufe des Software-Lebenszyklus angefallen sind.

Software Life Cycle

Die Software Validierung gehört zu einem gelebten Softwarelebenszyklus. Der Softwarelebenszyklus beinhaltet Softwareengineeringaufgaben und Dokumentation die notwendig sind, um den Softwarevalidierungsfortschritt zu unterstützen. Zusätzlich beinhaltet der Softwarelebenszyklus spezifische Verifikations- und Validierungsaktivitäten, die dem Verwendungszweck (Intended use) der Software entsprechen. Diese Leitline empfiehlt keine einzelnen Life Cycle Modelle – nur das sie ausgewählt und für ein Softwareentwicklungsprojekt genutzt werden sollten.

Validierungspläne

Der Softwarevalidierungsprozess wird durch die Benutzung eines Planes definiert und kontrolliert. Der Softwarevalidierungsplan legt fest, was während den Softwarevalidierungsaktivitäten erreicht werden soll. Softwarevalidierungspläne sind ein bedeutsames Werkzeug für Qualitätssysteme. Softwarevalidierungspläne legen den Rahmen, den Ansatz, die Mittel, die Pläne, die Validierungsaktivtäten und ihren Umfang sowie Aufgaben und Arbeitspunkte fest.

Prozeduren

Der Softwarevalidierungsprozess wird durch die Benutzung von Prozeduren ausgeführt. Diese Prozeduren legen fest, wie die Softwarevalidierungsaktivitäten durchgeführt werden sollen.Die Prozeduren sollten die speziellen Aktionen oder Schritte identifizieren, die durchgeführt werden müssen um individuelle Validierungsaktivitäten, Aufgaben und Arbeitspunkte auszuführen.

Softwarevalidierung nach Änderungen

Durch die Komplexität von Software, kann eine unscheinbare kleine Änderung maßgebliche Auswirkungen auf das Gesamtsystem haben. Wenn eine Änderung (sogar eine kleine Änderung) an der Software gemacht wird, muss der Validierungsstatus der Software neu festgelegt und dokumentiert werden.
Wenn eine Software geändert wird, muss eine Validierungsanalyse nicht nur für die Validierung der aktuellen Änderungen gemacht werden, sondern es muss auch das Ausmaß und die Auswirkungen dieser Änderung auf das Gesamtsystem betrachtet werden.
Basierend auf dieser Analyse sollte der Softwareentwickler eine entsprechende Anzahl an Softwareregressionstests durchführen um zu zeigen, das ungeänderte aber gefährdete Systemabschnitte nicht nachteilig beeinträchtigt wurden. Design Kontrollen und entsprechende Regressionstests unterstützen das Vertrauen dass die Software nach den Änderungen noch validiert ist.

Validierungsabdeckung – Validation Coverage

Die Validierungsabdeckung sollte auf der Softwarekomplexität und ihren Sicherheitsrisiken basieren – nicht auf der Firmengröße oder irgendwelchen Randbedingungen. Die Auswahl von Validierungsaktivitäten, Aufgaben und Arbeitsschritten sollte entsprechend der Komplexität des Softwaredesigns und -nutzung und den damit verbundenen Risiken für den Verwendungszweck ausgeführt werden. Bei geringem Risiko können auch nur Baselinevalidationen durchgeführt werden. Sobald sich das Risiko erhöht, sollten zusätzliche Validierungsaktivitäten hinzugefügt werden um das zusätzliche Risiko abzudecken. Die Validierungsdokumentation sollte ausreichend sein um zu zeigen, dass alle Softwarevalidierungspläne und -prozeduren erfüllt wurden.

Unabhängigkeit vom Review – Independence of Review.

Valdierungsaktivitäten sollten mit dem Qualitätssicherheitsgebot “Unabhängigkeit vom Review” durchgeführt werden. Selbstvalidierung ist sehr schwer. Eine unabhängige Bewertung ist immer besser, besonders bei Anwendungen mit höherem Risiko. Manche Firmen handeln für Dritte/Fremdfirmen Verifikation und Validation aus, aber diese Lösung wird nicht immer machbar sein. Ein weitere Ansatz ist es Betriebsangehörigen, die nicht in ein Design involviert sind, aber ausreichendes Wissen für die Durchführung der Projektvalidation und -verifikation besitzen, zuzuweisen.

Flexibilität und Verantwortlichkeiten

Spezielle Umsetzungen der Softwarevalidierungsgrundsätze können sich von Anwendung zu Anwendung unterscheiden. Der Gerätehersteller hat die Flexibilität bei der Wahl, wie Validierungsprinzipien ausgewählt werden, aber behält die ultimative Verantwortung zu zeigen, dass die Software validiert ist.
Software wird in einem breitem Spektrum an Umgebungen und für ein reiches Angebot an Geräten mit unterschiedlichen Risiken entworfen, entwickelt, validiert und reguliert.Medizingeräteanwendungen, die von der FDA reguliert sind, enthalten Software die …

… eine Komponente, ein Teil oder Zuberhör eines medizinischen Gerätes ist
… selber ein Medizingerät ist oder
… für die Produktion, den Entwurf, die Entwicklung oder andere Teile des Qualitätssystems ist.

In jeder Umgebung, können Softwarebausteine von vielen Quellen genutzt werden um die Anwendung zu erstellen (z.B. In-House Entwicklung, Standardsoftware, Vertragssoftware, Shareware…). Zusätzlich können Softwarekomponenten in vielen Formen auftauchen (z.B. Anwendungssoftware, Betriebssysteme, Compiler, Debugger, Konfigurationsmanagmenttools und viele mehr). Die Validierung von Software in diesem Umfeld kann niederschmetternd komplex sein, außerdem ist es angebracht, dass alle Softwarevalidierungsgrundsätze berücksichtigt werden, wenn der Softwarevalidierungsprozess aufgesetzt wird. Der resultierende Softwarevalidierungsprozess sollte mit den verbundenen Sicherheitsrisiken, die mit dem System, dem Gerät, dem Produkt oder Prozess in Verbindung gebracht werden, angemessen sein.
Softwarevalidierungsaktivitäten und -aufgaben können zerstreut an verschiedenen Stellen von verschiedenen Organisationen durchgeführt werden. Jedoch, unabhängig der Verteilung, vertraglichen Beziehungen, Komponentenquellen oder der Entwicklungsumgebung bekommt der Gerätehersteller und Spezifkationsersteller die absolute Verantwortlichkeit für die Sicherstellung, das Software validiert ist.

Aktivitäten und Aufgaben

Softwarevalidierung wird während einer Serie von Aktivitäten und Aufgaben, die während den unterschiedlichen Stadien des Softwarelebenszyklusses geplant und ausgeführt werden, durchgeführt. Diese Aufgaben können einmalig oder häufig durchlaufen werden. Dies ist abhängig vom Lebenszyklusmodell (Life Cycle Model) was im Rahmen von Änderungen während des Softwareprojektfortschritts benutzt wird.

Softwarelebenszyklusaktivitäten

Diese Richtlinie empfiehlt nicht die Benutzung eines speziellen Software Life Cycle Modells. Softwareentwickler sollten ein Softwarelebenszyklusmodell etablieren, was ihrem Produkt und der Organisation entspricht. Das Softwarelebenzyklusmodell, das ausgewählt wird, sollte die Software von ihrer Geburt bis zu ihrem Ausscheiden begleiten. Aktivitäten in einem typischem Softwarelebenszyklusmodell beinhaltet

Qualitätsplaung
Definition der System Requirements
Eine detailierte Software Requirements Spezifikation
Der Aufbau des Codings
Das Testen
Die Installation
Die Operation und der Support
Die Instandhaltung
Die Stilllegung / Retirmenent

Verifikation, Testen und andere Aufgaben die Softwarevalidierung unterstützen treten während jeder dieser Aktivitäten auf. Ein Lebenszyklusmodell organisiert diese Softwareentwicklungsaktivitäten mit unterschiedlichen Möglichkeiten und stellt ein Framework für das Monitoring und zur Kontrolle des Softwareentwicklungsprojektes bereit. Verschiedene Softwarelebenszyklusmodelle (Wasserfall, Spiralmodell, Rapid Prototyping, inkrementelle Entwicklng, … etc) sind im
FDA Glossar definiert: Glossary of Computerized System and Software Development Terminology

Diese und viele weitere Lebenszyklusmodelle werden in verschiedenen Referenzlisten im Anhang A beschrieben.

Typische Aufgaben, die Validierung begünstigen

Für jede Aktivität im Softwarelebenszyklus gibt es gewisse Aufgaben, die eine Schlussfolgerung begünstigen. Jedoch werden diese speziellen Aufgaben, die durchgeführt werden müssen, ihre Reihenfolge der Ausführung und die Iteration und das Timing ihrer Ausführungen von einem spezifischen Softwarelebenszyklusmodell und den Sicherheitsrisiken der Applikation vorgeschrieben. Für Anwendungen mit geringem Risiko könnten manche Aufgaben nicht notwendig sein. Zumindest sollte der Softwareentwickler jede dieser Aufgaben berücksichtigen, erklären und dokumentieren welche Aufgaben für die spezielle Anwendung nicht sinnvoll sind. Die folgende Diskussion ist generisch und es ist nicht beabsichtigt ein einzelnes Softwarelebenszyklusmodell vorzuschreiben oder eine Reihenfolge festzulegen, in der die Tasks abgearbeitet werden.

Qualitätsplanung

Design und Entwicklungsplanung sollte in einem Plan, der notwendige Aufgaben, Prozeduren für Anomalieberichte und Lösungen, notwendige Ressourcen und Review Anforderungen vom Management, die formelle Design Reviews beinhalten, zusammengefasst werden. Ein Softwarelebenszyklusmodell und damit verbundene Aktivitäten sollten identifziert werden, genauso wie die notwendigen Aufgaben für jede Aktivität im Softwarelebenszyklus.

Im Plan sollte enthalten sein:

Die spezifischen Aufgaben für jede Lebenszyklusaktivität
Aufzählungen von wichtigen Qualitätsfaktoren
– Ausfallsicherheit
– Handhabbarkeit
– Usability
– …
Methoden und Prozeduren für jede Aufgabe
Die Akzeptanzkriterien der Aufgaben

Veröffentlicht unter Allgemein, Medizintechnik | Hinterlasse einen Kommentar

Experiment mit YouTube-Video: Street Fighter 2 Rock Guitar Cover

Publiziert am 23. Juni 2014 von schludi

Intention

Mir schwirrte seit geraumer Zeit die Titelmelodie von Street Fighter 2 im Kopf herum. Das lag vermutlich daran, dass das Super Nintendo bei uns immer im Hintergrund lief und die Melodie sich nach einiger Zeit wiederholte.

Ich dachte mir, dass sich das Intro mit Sicherheit als Rockversion noch besser anhört. Das Gedudel von dem SNES Soundchip, nachdem das CAPCOM-Logo erscheint, hörte sich predistiniert für ein Gitarrenriff an.

Umsetzung

Zunächst nahm ich mit Cubase, ezDrummer und meinem Line 6 Toneport die Gitarren- und Bassspuren auf. Nachdem ich es abgemixt hatte, lag das Stück eine ganze Zeit lang ungeachtet bei Soundcloud rum.

Nachdem mir ein Bekannter (Florian Breidenbach) Nintendo Videos zusendete, die mit der Gitarre gecovert werden, und dazu den Kommentar: “Warum ist dir sowas nicht eingefallen?” gegen den Kopf warf, schickte ich Ihm zunächst den Link zu dem Soundcloud Projekt. Reaktionslos verblieb unser Chat.

Da ich nun noch 2 Tage Elternzeit habe, wollte ich mal die Resonanz auf ein YouTube Video testen. Ich nahm also das MP3 und benutzte meine Webcam mit Adobe Premiere um mich beim Spielen des Stücks zu filmen.

Ergebnis

Beobachtung der Besucherentwicklung

Ob die Resonanz auf ein YouTube Video größer ist, als auf ein Soundcloud-Projekt, wird sich zeigen. Ich habe das Video lediglich in einen WhatsApp Gruppenchat und 2 Freunden gepostet. Das Posting blieb relativ resonanzlos, daher vermute ich auch nicht, dass es weitergeschickt wird.

Ob ein solches Video ohne Promotion und ohne Bekanntheit des YouTube-Kanals heute noch Anklang finden kann ist eine spannende Beobachtung :-). Ich gebe zu, dass ich die Existenz von YouTube-Communities komplett verschlafen habe. Es gibt sehr viele professionell wirkende Videos von Amateurfilmern und Gruppen auf YouTube, die einer Fernsehproduktion wenig nachstehen.
Zu meiner Zeit, in der ich mit Videoschnitt experimentierte, wurden die Videos in MJPEG über eine Interupt-konfigurierte Video-Karte mit Antennen-Eingang mühseelig in den PC gespielt. Das Rendern einzelner Videosequenzen dauerte Stunden und es gab kein YouTube. Dementsprechend schwerer fällt mir die Bedienung moderner Videoschnittprogramme, die für die späte Generation Y zur Routine gehören.

Zielgruppe

Nun ist es so, dass es bereits etliche Videos von professionellen Gitarristen gibt, in denen alte Nintendo-Melodien gecovert werden. Wenn man deren Anzahl an Aufrufen, Likes und Abonennten genauer unter die Lupe nimmt, stellt man fest, dass hier eine eigene Nischen-Community innerhalb von YouTube existiert die sich auf RSpielemelodiencover auf der Rockgitarre spezialisiert hat.

Wer das für unsinnig hält, sollte sich einmal das “Let’s Play”-Genre auf YouTube genauer ansehen. Hierbei handelt es sich vorwiegend um abgefilmte Spiele, die mit Kommentaren des Spielers versehen sind. Auf Wikipedia gibt es hierzu einen lesenswerten Artikel. Mein erster Gedanke war: “Wer will jemanden beim Spielen zuschauen und dessen Kommentare hören?”. Doch es gibt die Zielgruppe :-).

Fazit

An dieser Stelle werde ich nach einer Beobachtungsphase mein Fazit posten.

Veröffentlicht unter Gitarre, Musik | Hinterlasse einen Kommentar

Android statistics and facts

Publiziert am 28. Mai 2014 von schludi

Problem

During the development of android applications the developer has to decide which API Level his applications requires. The API Level is clearly associated with a Android Codename (i.e. Ice Cream Sandwich: 14 and 15 (MR1), Jelly Bean 16 to 17 (MR1), Kit Kat 18…).

A trustable source that shows the frequency of usage for Android Versions can give the information about which versions should be considered retrospective.

Approach

A link collection of popular sources will be provided in this article. The developer has to customize the androidmanifest.xml in his application to define the minimum API Level.

Solution

Which android versions have to be considered for the development?

http://developer.android.com/about/dashboards/index.html

Where can i get an actual complete list of API Levels and Android Names?

http://developer.android.com/guide/appendix/api-levels.html

Veröffentlicht unter Allgemein, Android SDK | Hinterlasse einen Kommentar

Android: JOYN deaktvieren / ausschalten / ausstellen ohne zu rooten oder Custom ROM zu installieren

Publiziert am 20. April 2014 von schludi

Problem

Die deutschen Netzanbieter, insbesondere die Telekom, haben sich darauf geeinigt einen neuen Dienst JOYN als Alternative zu WhatsApp anzubieten. Das Ziel ist es zu verhindern, dass die Kunden alle zu kostenlosen Anbietern wie WhatsApp, Tremor etc wechseln. Seitdem die Handys internetfähig sind können die Provider lediglich über das Anbieten von Paketdatenverbindungen Geld für Nachrichten verdienen. Früher war es möglich pro SMS abzurechnen, heute lediglich je übertragenem Datenvolumen (insofern keine Flatrate vorhanden ist).

Nun ist es leider so, dass dieser JOYN Dienst penetrant nervt, das Handy vibrieren lässt und einem ständig durch Notifications/Statusmeldungen in den Glauben bringt, man hätte gerade eine SMS empfangen. Dies passiert z.B. wenn ein WLAN gefunden wurde. Es passiert auch nachts wenn die WLAN Verbindung mal zusammenbricht. Dies kann fürchterlich nerven

Prämissen

Zunächst sollte die neuste Android Version des Anbieters installiert sein.

Ansatz

In den Menüs der neuen Android Version (hier im Beispiel ein Galaxy S4 mit D1 Vertrag) befindet sich ein Eintrag um JOYN zu deaktivieren.

Lösung für Galaxy S4 mit Telekom D1 Branding

Bild 1: Menü -> Einstellungen (links unten der Button unterhalb des Display)
Bild 2: Verbindungen -> Weitere Einstellungen
Bild 3: JOYN-Dienste
Bild 4: Haken bei JOYN Dienste rausnehmen

Fazit

Das Problem von Custom ROMs die speziell von Mobilfunkanbietern angefertigt und ausgeliefert werden ist nicht nur, das man später in den Besitz der neusten Android Version kommt, sondern auch die nicht-vorhandene Community, die mit leidenschaft Updates und Funktionen in integriert und idealistisch fehlerfreie Software in kurzer Zeit bereitstellt.

Veröffentlicht unter Allgemein, Android SDK | Hinterlasse einen Kommentar

Übungstrack / Practise Eddi Van Halen Solo JUMP

Publiziert am 13. April 2014 von schludi

If you want to practice Eddi Van Halens Solo from the famous song Jump, you can use the following Track i have especially created:

This is my take:

Veröffentlicht unter Gitarre | Hinterlasse einen Kommentar

IBM Doors: Performance tests with DXL

Publiziert am 25. März 2014 von schludi

Problem

Sometimes it is necesseray to benchmark DXL scripts for their execution time.

Approach

There is a basic function called getTickCount_() that gives the current milliseconds. When subtracting the time before and after the execution we can get the execution time that was needed for the script.

Solution

int measureStart = (getTickCount_());

sleep_(1240);

int measureEnd = (getTickCount_());

print "The doing took " (measureEnd - measureStart) " seconds";

Veröffentlicht unter DXL, IBM DOORS | Hinterlasse einen Kommentar

C#+LDAP: Email an Lotus Notes Gruppen per SMTP schicken

Publiziert am 11. März 2014 von schludi

Problem

In einem Unternehmen sollen Lotus Notes Gruppen aufgelöst werden um den Mitgliedern der LN Gruppe Mails über einen normalen SMTP Server zu schicken

Ansatz

Lotus Notes besitzt i.d.R. einen LDAP Server, der die Notes Gruppen aufschlüsselt. Auf LDAP kann über C# zugegriffen werden.

Lösung

public ArrayList resolvingNotesGroups(String mailGroup)
{
 ArrayList alMailAddys = new ArrayList();

 DirectoryEntry DirEntry = new DirectoryEntry();
 {
  DirEntry.Path = "LDAP://notesldap.it.company.com";
  DirEntry.AuthenticationType = AuthenticationTypes.ServerBind;
 }
   
 DirectorySearcher search = new DirectorySearcher(DirEntry);
 DirectoryEntry de = new DirectoryEntry();

 Dictionary<String, String> dict = new Dictionary<string, string>();

 // Tweak this to refine your search
 search.Filter = "(cn=" + mailGroup + ")";// BBME_AC_Rubi
 // I limit my results while I tweak          
 search.SearchScope = SearchScope.Subtree;          

 try
 {
  SearchResultCollection src = search.FindAll();
        
  if (src.Count != 0)
  {
   foreach (SearchResult result in search.FindAll())
   {
    // Display each of the values for the property 
    // identified by the property name.
    foreach (object property in result.Properties["member"])
    {
     // CN Name ermitteln
     dict.Add(property.ToString(), "");
    }
   }
    
  }
  else
  {
   throw new Exception("GroupResolving - No Entry found for: " + search.Filter);
  }

  int indexStart;
  int indexEnd;


  foreach (KeyValuePair<string, string> entry in dict)
  {
   search.Dispose();
   search = new DirectorySearcher(DirEntry);

   indexStart = entry.Key.IndexOf("=");
   indexEnd = entry.Key.IndexOf(",");

   // Entry key only CN 
   search.Filter = "(cn=" + entry.Key.Substring(indexStart + 1, indexEnd - indexStart - 1) + ")";
   search.SearchScope = SearchScope.Subtree;

   foreach (SearchResult result in search.FindAll())
   {
    if (result != null)
    {

     de = result.GetDirectoryEntry();
     alMailAddys.Add(de.Properties["mail"].Value.ToString());
    }
    else
    {
     throw new Exception("Peolple Resolving - No Entry found for: " + search.Filter);
    }
   }
  }

 }
 catch (Exception ex)
 {
  throw new Exception("Following error occured: " + ex.Message.ToString());
 }
 finally
 {
  search.Dispose();
  DirEntry.Close();
 }

 return alMailAddys;
}}

Veröffentlicht unter .NET | Hinterlasse einen Kommentar

Proberaumcover: Eric Clapton – Cocaine

Publiziert am 10. Februar 2014 von schludi

Veröffentlicht unter Musik | Hinterlasse einen Kommentar

JIRA 6.x SQL Statement: Get actual value / last change for custom field

Publiziert am 30. Januar 2014 von schludi

Problem

The actual value of a custom field from an Issue should be selected

Solution

select CAST(pk.PROJECT_KEY as VARCHAR(10))+'-'+CAST(issue.issuenum AS varchar(10)), cfo.customvalue FROM 
CustomFieldValue cfv 
INNER JOIN CustomField CF on CF.Id = CFV.CustomField
INNER JOIN CustomFieldOption CFO on CF.Id  = CFO.CustomField
INNER JOIN jiraissue issue on issue.id = cfv.issue 
INNER JOIN project_key pk on PROJECT_ID=issue.PROJECT
WHERE cf.CFName = 'Classification' 
And CAST(CFO.Id AS VARCHAR(10)) =CFV.StringValue;

Veröffentlicht unter Atlassian JIRA | Hinterlasse einen Kommentar

Cubase VST Instrumente: Kostenlose Alternative zu ezDrummer?

Publiziert am 28. Januar 2014 von schludi

Problemstellung

Kostenlose Schlagzeugplugins die authentische Sounds für echtes Schlagzeug liefern sind sehr rar.

Vormerkung

Für echte Schlagzeugsounds stellt der Mikrofonhersteller Sennheiser ein kostenloses VST Instrument zur Verfügung das sich vielversprechend anhört.

Ich denke ein Test lohnt sich…
http://de-de.sennheiser.com/drummica

Hier ein Tutorial von Delamar:

http://www.delamar.de/video-workshops/rock-drums-programmieren-22655/

Veröffentlicht unter Musikproduktion | Hinterlasse einen Kommentar

Zweck

Rahmen

Terminologie

Requirement

Spezifikation

Verifizierung und Validierung

Software Verification

Software Validierung

IQ/OQ/PQ

Software Entwicklung als Teil des System Designs

Unterschiede von Software zu Hardware

Vorteile von Softwarevalidierung

Design Review

Grundlagen der Software Validierung

Requirements

Fehlervermeidung

Zeit und Aufwand

Software Life Cycle

Validierungspläne

Prozeduren

Softwarevalidierung nach Änderungen

Validierungsabdeckung – Validation Coverage

Unabhängigkeit vom Review – Independence of Review.

Flexibilität und Verantwortlichkeiten

Aktivitäten und Aufgaben

Softwarelebenszyklusaktivitäten

Typische Aufgaben, die Validierung begünstigen

Qualitätsplanung

Intention

Umsetzung

Ergebnis

Beobachtung der Besucherentwicklung

Zielgruppe

Fazit

Problem

Approach

Solution

Problem

Prämissen

Ansatz

Lösung für Galaxy S4 mit Telekom D1 Branding

Fazit

Problem

Approach

Solution

Problem

Ansatz

Lösung

Problem

Solution

Problemstellung

Vormerkung

Meta

Kontakt

Kategorien

Letzte Beiträge

Letzte Kommentare

Archive

Capri Clouds