Nach einer arbeitsbedingten, schöpferischen Pause möchten wir nun wieder voll Durchstarten und in dem aktuellen Blogartikel die Tätigkeit der Planung des Software-Lebenszyklus skizzieren. Nun muss man ehrlicherweise zugeben, dass es in der Praxis im Regelfall aber gerade nicht so ist, dass der erste Schritt die Planung darstellt – vielmehr werden initial oftmals grob die Nutzergruppen und der Nutzungskontext beschrieben um basierend darauf die Komplexität und den Aufwand einschätzen zu können. Ein guter Ausgangspunkt ist hierbei – Sie ahnen es sicher bereits – Ihre Zweckbestimmung. Gut erstellt, dient diese perfekt dazu, Ihre Produktidee zu kommunizieren und dadurch den unterschiedlichen Abteilungen einen ersten Eindruck zu vermitteln. Die Komplexität Ihres Produkts entscheidet auch ganz wesentlich Ihre weitere Vorgehensweise: Entwickeln Sie beispielsweise eine Mobile-Health Applikation, kann eine detaillierte Zweckbestimmung durchaus ausreichen, um eine seriöse Planung und Abschätzung des Lebenszyklus durchzuführen. Ist die Komplexität Ihres Systems allerdings vergleichbar mit der eines PACS Systems, wird eine Planung zum aktuellen Zeitpunkt nur sehr schwierig möglich sein und eine fundiertere Anforderungsanalyse nötig sein.

Eines Vorweg – die Gesamtheit der zu planenden Tätigkeiten werden nur in den seltensten Fällen in einem einzigen Plan realisiert. Diese Trennung ist insofern auch sinnvoll, als dass die einzelnen Pläne von unterschiedlichen Personen für unterschiedliche Zielgruppen geschrieben werden.

Auf der übergeordneten Ebene des Projektmanagementplans kann es durchaus zielführend sein, die Arbeitspakete und die Meilensteine eher grob zu definieren und das Augenmerk auf die Ressourcenplanung und Einschätzung der Timelines zu legen. Der genaue Entwicklungsprozess beispielsweise muss hier noch nicht im Detail spezifiziert werden. An dieser Stelle ein Tipp aus der Praxis: Achten Sie bei der Festlegung des Freigabezeitpunkts Ihres Medizinprodukts auch immer auf das Marketing. Oftmals gibt es durch jährlich stattfindende Fachkongresse harte Deadlines, bei denen Ihr Produkt vorgestellt werden muss und entsprechend fachgruppenwirksam präsentiert wird.

Die Inhalte des Software-Entwicklungsplans sind in der IEC 62304 unter 5.1.1 beschrieben – so werden in diesem Plan u.a. die einzelnen Entwicklungsphasen definiert und in einen logischen Zusammenhang gebracht (Lebenszyklusmodell). Die Phase der Erstellung der Spezifikation hat beispielsweise

• als definierten Input ein freigegebenes Lastenheft,
• als Output die nachvollziehbare Spezifikation (mit entsprechenden Referenzen auf das Lastenheft / Nutzeranforderungen),
• als Verifikationstätigkeit den Nachweis, dass Sie einzelnen Anforderungen gewisse Eigenschaften aufweisen (widerspruchsfrei, verständlich, …)
• als Validierungstätigkeit den Nachweis, dass alle Anforderungen aus dem Lastenheft richtig umgesetzt wurden.

Dieser wichtige Plan behandelt die Phase(n) nach der erstmaligen Freigabe. Hier sollte definiert sein, welche Kriterien Sie anlegen, um die eingehenden Rückmeldungen zu bewerten und das Problem zu analysieren. Harte Kriterien und eine gute Einschulung Ihres Servicecenters sind hierbei Pflicht, um eine objektive Einschätzung zu erhalten. Ebenso sollte in diesem Plan beschrieben sein, was Sie unter einem Bugfix, Patch, Update oder Service Pack verstehen und ob es definierte Releasezyklen gibt.

Dieser Plan dient der eindeutigen Identifikation der erstellten Artefakte – beginnend bei Dokumenten (Spezifikation, Software-Architektur, Testpläne…) bis hin zu den Source-Code Komponenten. Die Festlegung der Dokumentnamen auf Dateiebene, die Bezeichnung der einzelnen Anforderungen, Risiken und Problemberichte und, ganz wichtig, die Organisation Ihres Konfigurationsmanagementsystems (SVN, Git, Mercurial…) runden diesen Plan ab.

Der Risikomanagementplan beschreibt die essentiellen Tätigkeiten in Hinblick auf die Identifikation, Einschätzung und Kontrolle von Gefährdungen in Zusammenhang mit Ihrem Produkt. Sie erinnern sich bestimmt an den oben erwähnten Software-Entwicklungsplan – es macht absolut Sinn, jeder der beschriebenen Phasen auch entsprechende Tätigkeiten des Risikomanagements (FMEA, …) zuzuordnen.

Gleiches gilt auch für Tätigkeiten in Zusammenhang mit dem Usability-Engineering. Von der Phase der Erstellung der Spezifikation bis hin zum Validieren der Gebrauchstauglichkeit sollte hierbei auf die einzelnen Phasen der Software-Entwicklung, jeweils im Kontext der Risikomanagementaktivitäten, eingangen werden (z.B. erste Definition der vorhersehbaren Fehlbedienung basierend auf den initialen Nutzeranforderungen in der Phase der Anforderungsanalyse).

Besonders bei innovativen Produkten ist es sinnvoll, sich ehestmöglich einen ersten Überblick über die vorhandenen klinischen Daten zu machen. Recherchieren Sie basierend auf der Zweckbestimmung in gängigen medizinischen Datenbanken ¹⁾ nach Leistungs- und Sicherheitsdaten zu Ihrem Medizinprodukt bzw. äquivalenten Produkten. Ziel dieser Aktivität ist es festzustellen,

• ob Sie zusätzlich klinische Prüfungen am Menschen benötigen, um klinische Daten mit Ihrem Produkt zu erheben,
• ob Sie zusätzlich klinische Prüfungen am Menschen benötigen, um die Äquivalenz mit einem bereits existierenden Produkt nachzuweisen,
• welchen Weg Sie in Bezug auf präklinische Prüfungen, z.B.: bei der Bewertung der Biokompatibilität, gehen müssen.

Erst nach dieser Tätigkeit wird es möglich sein, eine seriöse Planung und Kostenabschätzung der klinischen Bewertung durchzuführen.

Auf der Ebene des Projektmanagementplans ist es wichtig, die Definition der Verantwortlichkeiten, zumindest auf Abteilungsebene, durchzuführen. Dies ist letztendlich auch nötig, um eine seriöse Abschätzung des abteilungsspezifischen und gesamten Finanzierungsbedarfs erstellen zu können. Die detaillierte Definition von Verantwortlichkeiten auf Ebene der einzelnen Positionen ist zielführend in den anderen, untergeordneten Plänen. Beispielsweise bietet sich für die Festlegung dafür die RASCI ²⁾Methode an.

So weit ein kurzer Einblick in diese herausfordernden Tätigkeiten. Wie eingangs erwähnt, bleibt die Organisation dieser Pläne Ihnen überlassen - fassen Sie je nach Sinnhaftigkeit die einzelnen Pläne zusammen oder referenzieren Sie die einzelnen Pläne untereinander. Im nächsten Blogartikel werden wir auf unterschiedliche Lebenszyklusmodelle für medizinische Software eingehen und gleichzeitig die Phase der Planung abschließen.