Entwicklungsprozess: Entwicklungsprozesse und Prozessmodelle

Der Entwicklungsprozess beschreibt, wie die daran beteiligten Rollen (z.B. Requirements Engineers, Programmierer, Architekten, Tester usw.) Inputs in Outputs (z.B. Baupläne, Software, Dokumentation) überführen. Das „wie“ umfasst die Reihenfolge, in der die einzlenen Aktivitäten erledigt werden und die Abhängigkeiten dieser Aktivitäten ebenso die die Methoden zur Erledigung.

Zu den Methoden zählen beispielsweise die Kontextmethode für das Ergeben von Anforderngen, die Modellierung für das Beschreiben einer Architektur oder die Blackbox-Testverfahren zum systematischen Ableiten von Testfällen.

Die meisten Medizinproduktehersteller arbeiten entweder gemäß einem Wasserfall- oder V-Modell-artigen oder einem agilen Prozessmodell. Sie können mehr zur agilen Software-Entwicklung lesen.

Übersicht

Lesen Sie mehr darüber,

Regulatorische Forderungen an Prozesse

Alle relevanten Regularien und Normen fordern ein prozessorientiertes Vorgehen:

  • Die Medizinprodukterichtlinie fordert beispielsweise Software-Lebenszyklusprozesse.
  • Die IEC 62304.
  • Die ISO 13485 fordert prozessorientiertes Arbeiten, nicht nur aber auch bei der Entwicklung.
  • Die ISO 14971 beschreibt einen Risikomanagementprozess (wohlgemerkt Prozess!).
  • Die IEC 62366 fordert, dass die Gebrauchstauglichkeit von Medizinprodukten mit Hilfe eine „gebrauchstauglichkeitsorientierten Entwicklungsprozesses“ gewährleistet wird.
  • Die IEC 60601-1 ist v.a. für deren Beispiel eines Entwicklungsprozesses, der dem V-Modell sehr gleicht:

Entwicklungsprozess gemäß IEC 60601-1

Keine(!) dieser Regularien fordert allerdings ein konkretes Prozessmodell.

Umsetzung der regulatorischen Forderungen and Entwicklungsprozesse

Gleich für welches Prozessmodell Sie sich entscheiden, Sie müssen

  1. sich für eines entscheiden (zumindest pro Projekt) und dies auch dokumentieren,
  2. nach diesem Prozessmodell auch arbeiten und
  3. dabei die von den Regularien vorgeschriebenen Aktivitäten durchführen.

Die folgende Grafik gibt Ihnen einen Überblick über diese Aktivitäten:

V-Modell nach Johner

Diese Abbildung möchte aber kein V-Modell unterstellen — auch wenn es danach aussieht. Diese Aktivitäten können Sie auch iterativ und inkrementell durchlaufen. Lesen Sie dazu mehr zur agilen (Software-)Entwicklung

Beachten Sie, dass Sie alle Aktivitäten auf der linken Seite mit einer Verifzierung abschließen müssen.

Zusammenspiel von Entwicklungs- und Risikomanagementprozess

Wie Sie in einem Prozess die Forderungen der ISO 14971 und ISO 13485 bzw. IEC 62304 erfüllen können

Die meisten für die Entwicklung von Medizinprodukten relevanten Normen wie die ISIO 13485, die ISO 14971, die IEC 62304 und die IEC 62366 stellen Anforderungen an Prozesse. Um diese Anforderungen zu erfüllen, formulieren viele Medizinproduktehersteller Prozessbeschreibungen/SOPs — und zwar für jeden dieser Prozesse getrennt. Das führt dazu, dass die an der Entwicklung Beteiligten gleichzeitig mehrere dieser SOPs beachten müssen. Fehler sind hier fast vorprogrammiert. Daher soll diese Beitrag zeigen, wie die Aktivitäten aus dem Risikomanagement in den Entwicklungsprozess „eingewoben“ werden können.

Die folgende Abbildung zeigt zwar ein V-Modell, die Überlegungen sind davon aber unabhängig.

Zusammenspiel von Entwicklungsprozess und Risikomanagementprozess

Der Prozess der Entwicklung eines Medizinprodukts beginnt bereits vor der eigentlichen Entwicklung. Eine der ersten Aufgaben besteht darin, den Geschäftserwartungen und den Kontext zu definieren, in dem das künftige Produkt eingesetzt werden soll (1). In dieser Phase sollte mit der Zweckbestimmung und das formuliert werden, was die IEC 62366 etwas missverständlich die „Spezifikation der Anwendung“ nennt. Diese präzise und erweiterte Beschreibung der Zweckbestimmung erfüllt gleichzeitig die Forderung der ISO 14971 Kapitel 4.2. Während dieser ersten Phase sollte der Hersteller die Risikoanalyse im Sinne einer Preliminary Hazard Analysis starten. Bereits aus der Zweckbestimmung wird offensichtlich welche Gefährdungen und Risiken das Produkt verursacht.

Ebenfalls zu Beginn der Entwicklung, beispielsweise in der zweiten Phase (2), sollte der Hersteller den Risikomanagementplan und damit die Risikopolitik bzw. die Risikoakzeptanzkriterien festlegen und damit den Forderungen der ISO 14971 Kapitel 3 Rechnung tragen.

Die dritte Phase (3) des Entwicklungs- und damit Risikomanagementprozesses ist die Spezifikation des Produkts im Sinne eines Pflichtenheftes. In dieser Phase der Entwicklung beschreibt der Hersteller die Anforderungen an das Produkt aus einer Blackbox-Sicht und damit dessen Inputs und Outputs. Eine Input und Output-Analyse hilft dabei, weitere Gefährdungen und Risiken zu identifizieren. Mit diesem Teil der Risikoanalyse sollten die Hersteller die Preliminary Hazard Analysis abschließen können und damit die Identifikation und Bewertung der wichtigsten Gefährdungen bzw. Risiken.

Die Risikoanalyse kann frühestens abgeschlossen werden, wenn die Entwickler die Anforderungen aus der zweiten Phase in die Planung einer Lösung überführt haben — die Architektur (3). Die Art und Weise, wie das Produkt aufgebaut sein soll, führt zusätzliche Risiken ein oder hilft Risiken zu minimieren. D.h. in Phase (3) sollte die Risikoanalyse in großen Teilen abgeschlossen sein (hier stünde z.B. eine FMEA zur Identifikation weiterer Risiken an). Gleichzeitig beginnt spätestens in dieser Phase die Planung der Risiko-minimierenden Maßnahmen gemäß ISO 14971 Kapitel 6. Im Risikomanagementprozess ist die Architektur-Phase somit ein Dreh- und Angelpunkt zwischen Risikoanalyse und Risikobeherrschung. Damit soll aber nicht gesagt sein, dass die Architekten die Hauptlast des Risikomanagements tragen sollten.

Die Umsetzung der Architektur und damit der geplanten risikominimierenden Maßnahmen erfolgt in Phase (5), die Verifizierung der Umsetzung und der Wirksamkeit während der Tests (6).

Der Risikomanagementprozess endet zwar nicht mit der Entwicklung bzw. dem Entwicklungsprozess. Aber nach der Validierung bzw. spätestens mit der Freigabe des Produkts (7) muss der Hersteller die abschließende Nutzen-Risiko-Bewertung verfassen, in der er abwägen muss, ob der Nutzen die Gefährdungen bzw. Risiken überwiegt.

Wie gerade angedeutet endet weder der Risikomanagementprozess noch die Risikoanalyse mit der Entwicklung. Im Rahmen der nachgelagerten Phase verlangt die ISO 14971 eine kontinuierliche Neu-Bewertung der Risikoakzeptanzkriterien, eine Aktualisierung der Risikoanalyse (z.B. anhand von Marktdaten) und ggf. neue Maßnahmen, um Risiken zu minimieren.

Zusammenfassend empfehlen wir Herstellern, die Aktivitäten, die die ISO 14971 verlangt, in der SOP für den Entwicklungsprozess zu berücksichtigen.


Mittwoch 23. März 2016 von Prof. Dr. Christian Johner

Der TIR45 („Guidance on the use of AGILE practices in the development of medical device software“) ist ein Technical Information Report (daher TIR) der AAMI, der Association for the Advancement of Medical Instrumentation.

Der 2012 veröffentlichte TIR45 hat sich vor allem ein Ziel gesetzt: Medizinprodukte-Herstellern eine Anleitung zu geben, wie sie Software agil und konform mit den FDA-Forderungen, speziell denen in den Guidance Documents, entwickeln können. Auch die IEC 62304 hat der Technical Report im Fokus.

Lesen Sie hier eine kompakte Zusammenfassung.

Den ganzen Beitrag lesen »


Donnerstag 17. September 2015 von Prof. Dr. Christian Johner

Sie benötigen beides, den (Software-) Entwicklungsplan und die Beschreibung des (Software-) Entwicklungsprozesses, die man häufig auch Entwicklungs-SOP nennt. Doch wie unterscheiden sich die Dokumente? Welche Informationen sollte der Entwicklungsplan enthalten welche die Prozessbeschreibung?

Update: Ergänzung zum Entwicklungsplan
Den ganzen Beitrag lesen »


Freitag 15. Mai 2015 von Prof. Dr. Christian Johner

Scrum ist eher ein Rahmen (Framework) für das agile Projektmanagement als ein Vorgehensmodell im Sinne eines Prozessmodells. Bereits deshalb kann ein Vorgehen nach Scrum durchaus konform mit den regulatorischen Anforderungen an die Entwicklung von Medizinprodukten (insbesondere Software) und der IEC 62304 sein.

Dieser Beitrag hat nicht zum Ziel, Scrum zu beschreiben (das ist an anderer Stelle z.B. Wikipedia bereits erfolgt). Vielmehr möchte er diskutieren, welche Voraussetzungen erfüllt sein müssen und typische Gefahren vermieden werden sollten.

Den ganzen Beitrag lesen »


Donnerstag 15. Januar 2015 von Prof. Dr. Christian Johner

Regulatorische Anforderungen an die Dokumentenfreigabe

Gleich ob agile Entwicklung oder Entwicklung nach V-Modell: Medizinproduktehersteller müssen Dokumente bei Änderungen freigeben:

  • Anforderungen dürfen Sie zwar ändern – aber wir müssen sie freigeben (z.B. IEC 62304 Kapitel 5.2).
  • Die Architektur dürfen Sie an diese Anforderungen anpassen – aber Sie müssen sie dann freigeben (z.B. IEC 62304 Kapitel 5.3).
  • Den Code dürfen Sie dementsprechend überarbeiten – müssen die Software aber am Ende freigeben(z.B. IEC 62304 Kapitel 5.8).

Diese Forderungen formuliert nicht nur die IEC 62304, sondern ebenso die ISO 13485 und die FDA.

Ineffiziente Dokumentenfreigaben

Folgen von ineffizente Dokumentenfreigaben

Wenn die Freigabe dieser Dokumente nicht leichtgewichtig sind, wird mit hoher Wahrscheinlichkeit Folgendes passieren: Die Freigaben erfolgen erst retrospektiv, also wenn die Software längst entwickelt wurde.

Das ist nicht nur entgegen den regulatorischen Anforderungen (beispielsweise denen aus der IEC 62304), sondern auch einfach dumm. Man hat die Arbeit, aber nicht den Nutzen einer Dokumentation, nämlich den Nutzen, darin und damit Konzepte zu erarbeiten, Fehler früh zu finden und einfach zu beheben.

Wie Sie prüfen können, ob Sie mit Ihrer Dokumentenfreigabe Ihren Entwicklungsprozess behindern

Ich habe Ihnen noch ein paar Tipps, wie Sie die Agilität Ihrer Entwicklung durch schwergewichtige Freigaben endgültig abtöten können:

  • Verlangen Sie möglichst viele Unterschriften.
  • Achten Sie darauf, dass alle Geschäftsführer unterschreiben müssen, v.a. diejenigen, die selten vor Ort sind.
  • Machen Sie die Freigaben auf Papier im Umlaufverfahren. Ideal sind mehrere Standorte.
  • Definieren Sie eine erneute Freigabe als Nicht-Erreichen eines bereits erreichten Meilensteins.
  • Lassen Sie das QM- oder Regulatory-Affairs über Inhalte entscheiden.
  • Nutzen Sie ein Werkzeug zur Dokumentenverwaltung, das möglichst unbeliebt ist, beispielsweise weil es niemand bedienen kann, weil es regelmäßig nicht verfügbar ist und das den Ausdruck und die manuelle Unterschrift nicht erspart.

Klingt das zynisch? Wenn Sie die von mir beobachte Realität so nennen wollen. Wie viele dieser Punkte treffen bei Ihnen zu?

Dokumentenfreigaben effektiv und effizient gestalten

Die Antwort auf die Frage, wie man Dokumentenfreigaben gestalten sollte, müsste lauten, „das hängt davon ab“. Diese Antwort wäre aber keine beliebte, obwohl das die korrekte ist. Denn die Größe des Teams, dessen Verteilung, die Organisation der Firma, die Art der Produkte usw. haben einen Einfluss auf einen optimalen Prozess.

Da ich mich nicht drücken will, hier ein paar Best Practices:

Teamzusammensetzung

Reduzieren Sie die Anzahl der Personen bei einer Dokumentenfreigabe so weit wie möglich. Daran sollten i.d.R. nur teilnehmen:

  • der Autor bzw. die für die jeweilige Aktivität/Phase verantwortliche Person. Bei einer Software-Architektur wäre das der Software-Architekt.
  • Der Auftraggeber dieser Phase bzw. dieses Dokuments. Bei einer Software-Architektur ist das der- oder diejenige, der/die die Systemspezifikation geschrieben hat, beispielsweise ein Produktmanager.
  • Der Auftragnehmer dieser Phase bzw. dieses Dokuments. Um bei unserem Beispiel der Software-Architektur zu bleiben, wären das die Entwickler, die diese Architektur umsetzen müssen.
  • Die für die Tests verantwortliche Person, die prüfen kann, ob das Geschriebene auch testbar ist. Das wäre bei einer Software-Architektur der Integrationstester, falls es den gibt.
  • Das Qualitätsmanagement muss ebenso wenig involviert werden wie die Geschäftsführung. Aus dem Review fliegt jede Rolle raus, die keinen Beitrag leisten kann, aber die Terminfindung erschwert.
  • Der Risikomanager kann, aber muss nicht eingebunden werden, das hängt in der Tat vom Projekt bzw. Produkt ab.

D.h. dass an einem Review etwa vier oder fünf Personen (maximal) teilnehmen sollten. Also ein etwa Acht-Augen-Prinzip :-).

Dokumentenfreigabe - Das Acht Augen Prinzip

Sie können in Ihrer SOP die zu beteiligenden Personen auch davon abhängig machen, ob das Dokument initial erstellt oder überarbeitet wurde.

Einsatz von Werkzeugen und Gestaltung der Dokumente

Erniedrigen Sie die Hürden für ein Review durch einfache Werkzeuge:

  • Nutzen Sie eine Checkliste, die maximal ein beidseitig bedrucktes Blatt umfasst. Diese Checkliste liegt ausgedruckt in einem Hängeordner oder einer Schublade bei jedem am Platz. Es bedarf nur eines Handgriffs, um mit dem Review und damit der Dokumentenfreigabe beginnen zu können. Nutzen Sie doch den Auditleitfaden, die Checkliste, die wir für benannte Stellen entwickelt haben.
    Auditleitfaden: Die IEC 62304 Checkliste auch für die Dokumentenfreigabe
  • Nutzen Sie besonders bei verteilten Teams webbasierte ALM-Werkzeuge. Dass ich für Medizinprodukteentwickler das MedPack empfehle, wird Sie nicht überraschen.
  • Gleich ob auf Papier oder im Werkzeug: Nehmen Sie nur ganz konkrete und überprüfbare Punkte mit in die Checklisten mit auf. Ein Punkt „Ist das Dokument vollständig?“ ist ziemlich wertlos. Eine Frage „Gibt es am Ende des Dokuments eine zweispaltige Tabelle, in deren linker Spalte alle IDs der Systemanforderungen aufgeführt und in deren rechte Spalte ein Stichwort oder einen Halbsatz zur Umsetzung in der Architektur steht?“ lässt sich hingegen genau prüfen.
  • Vermeiden Sie Monsterdokumente. Zerlegen Sie die Dokumente! Eine Systemarchitektur muss die Systemkomponenten (z.B. programmierbare elektronische Subsysteme PESS) und deren Zusammenspiel beschreiben. Die Anforderungen an die PESS hingegen lassen sich pro PESS formulieren. Analog gilt das für die Software-Architektur. Je kleiner ein Dokument, umso schneller und besser ist es prüfbar.
  • Vermeiden Sie diese furchtbaren „Document Headers“. Den Rekord, den ich neulich sah, waren 12 Seiten!
  • Alle Querschnittsaspekte wie Glossare gehören rausfaktorisiert.

Praktische Durchführung von Dokumentenfreigaben

  • Trennen Sie Projektmanagementaspekte von Dokumentenfreigaben. Ein Meilenstein kann als erreicht definiert werden, wenn das Dokument ein erstes Review passiert hat. Jede weitere Änderung am Dokument muss problemlos und schnell durchführbar sein. Das macht das Entwicklungsteam (im Fall der SW-Architekturdokuments) unter sich aus.
  • Trennen Sie rein formale Prüfungen und Freigaben von inhaltlichen. Das Formale (auch im Sinne eines 21 CFR part 11) kann am Schluss kommen.
  • Bevorzugen Sie häufige, zeitnahe und kurze Reviews (< 30 Minuten) vor Dauersitzungen. Nach 45 Minuten intensiver Prüfung sind die meisten Hirne ermüded.

Kultur und Umgebung bei der Freigabe von Dokumenten

  • Schaffen Sie Orte, an denen man sich in Ruhe zusammensetzen kann. Störungen durch Telefon oder E-Mail müssen tabu sein.
  • Als Geschäftsführer und Projektleiter drücken Sie Wertschätzung für diese Review-Tätigkeiten aus. Wenn Sie glauben, nur ein programmierender Programmierer sei ein guter Entwickler, sind Sie falsch auf Ihrem Posten. Bei Google werden übrigens Reviews genauso hoch bewertet wie das Schreiben von Dokumenten und das Programmieren.

So, das soll jetzt mal reichen. Jetzt sind Sie dran! Schicken Sie mir Ihre Ideen.


Montag 8. Dezember 2014 von Prof. Dr. Christian Johner

Wir können bei uns nicht automatisiert testen, weil wir sehr Hardware-nah programmieren, antwortet mir mein Kunde auf meine Anregung, durch die Automatisierung gleichzeitig Zeit zu sparen und die Güte der embedded Software zu erhöhen. Und außerdem würde das die IEC 62304 auch nicht verlangen.

Sicher trifft es zu, dass die IEC 62304 keine Automatisierung verlangt. Es ist auch zutreffend, dass bei sehr Hardware-nahe embedded Software die Hardware vorhanden sein muss, um diese Software zu testen. Dennoch: Den ganzen Beitrag lesen »