Die Medizinprodukteverordnung (MDR) (wie bereits die Medizinprodukterichtlinie (MDD) und damit das Medizinproduktegesetz zuvor) verlangt, dass Hersteller für ihre Software Lebenszyklus-Prozesse einhalten. Auch die IEC 62304 und die IEC 82304 sprechen von Software-Lebenszyklus-Prozessen. Doch was versteht man unter einem Software-Lebenszyklus?
Der Software-Lebenszyklus beinhaltet alle Phasen, die ein Software-Produkt von der ersten Idee bis zur Außerbetriebnahme durchläuft.
Es geht also nicht nur um die Software-Entwicklung:
Die IEC 62304 definiert den Begriff Software-Lebenszyklus-Modell hingegen als konzeptionelle Struktur, welche die Lebenszeit der Software von der Anforderungsdefinition bis zur Freigabe für die Produktion umfasst und
- die Prozesse, Aktivitäten und Aufgaben festlegt, die an der Entwicklung eines Software-Produkts beteiligt sind,
- die Reihenfolge und die Abhängigkeiten von Aktivitäten und aufgaben beschreibt und
- die Meilensteine festlegt, bei denen die Vollständigkeit der festgelegten zu liefernden Ergebnisse verifiziert wird.
Damit beschränkt die IEC 62304 in ihrer Definition den Begriff Software-Lebenszyklus auf die erste Phase, die Software-Entwicklung, obwohl die Norm selbst Anforderungen auch andere Prozesse formuliert (s.u.).
Die IEC 82304 adressiert den gesamten Lebenszyklus, inkl. Aktivitäten nach dem Inverkehrbringen wie Wartung, Außerbetriebnahme und Deinstallation der Software.
Phase 1: Software-Entwicklung
Für die Softwareentwicklung sind viele Vorgehensmodelle bekannt und im Einsatz. Dazu zählen das Wasserfall-Modell, das V-Modell, agile Vorgehensmodelle und der Rational Unified Process.
Die IEC 62304 schreibt kein spezielles Softwarelebenszyklus-Modell vor. Sie hält agile Vorgehensmodelle für adäquat, wenn gleich sie gedanklich eher einem V-Modell (zumindest als Dokumentationsmodell) verhaftet zu sein scheint: Gleich welches Vorgehensmodell ein Hersteller bei der Entwicklung seiner Software nutzt, die Dokumentation muss am Ende der Softwareentwicklung die üblichen Artefakte enthalten:
- Software-Anforderungen
- Software-Architektur und detailliertes Design
- Code und andere Artefakte
- Code-Reviews, Ergebnisse der statischen Code-Analyse
- Unittests, Integrationstest und Systemtests, jeweils mit Testspezifikation und Testergebnissen
Phase 2: Software-Wartung
Die meisten Fehler, die Fehlerdatenbanken (z. B. des BfArMs oder der FDA) melden, betreffen nicht die initiale Software-Entwicklung, sondern die nächste Phase im Lebenszyklus einer Software, die Wartung.
Laut FDA werden 79% aller Fehler in der Wartungsphase verursacht. Entsprechend verlangen die Normen wie die IEC 62304 oder die Guidance Dokumente der FDA, dass es auch für die Wartung definierte Vorgehensmodelle gibt.
Vereinfacht gesagt, sollten bei der Wartung die Software die gleichen Phasen durchlaufen werden wie bei der initialen Softwareentwicklung. Idealerweise können die Tests als Regressionstests durchlaufen werden, die sicherstellen, dass in der Wartungsphase möglichst wenig neue Bugs hinzugefügt werden.
Phase 3: Außerbetriebnahme
Die letzte Phase, die eine Software im Lauf ihres Lebenszyklus durchläuft, ist die Außerbetriebnahme. Dies geschieht oft durch eine Ablösung durch ein anderes Produkt.
Weitere Prozesse im Lebenszyklus
Die IEC 62304 zählt weitere Prozesse zum Softwarelebenszyklus wie den Risikomanagement-Prozess, den Problemlösungsprozess und das Konfigurationsmanagement. Den Problemlösungsprozess sehen wir als integralen Teil der Software-Entwicklung und Wartung. Dieser Prozess trägt Sorge, dass Fehler analysiert, Trends ausgewertet und die passenden Maßnahmen (Korrektur, Meldung an Behörden usw.) ergriffen werden. Der Konfigurationsmanagement-Prozess soll sicherstellen, dass keine unautorisierten Änderungen am Code erfolgen (Kunde kann nicht direkt beim Entwickler anrufen) und dass zu jeder Zeit nachvollzogen werden kann, welche Artefakte in welcher Version Teil eines Software Releases sind.
Änderungshistorie
- 2024-01-22: Verweise auf die IEC 82304 ergänzt
- 2015-05-02: Initiale Erstellung des Artikels