Entwicklungsplan versus Entwicklungsprozessbeschreibung

Donnerstag 17. September 2015

Sie benötigen beides, den (Software-) Entwicklungsplan und die Beschreibung des (Software-) Entwicklungsprozesses, die man häufig auch „Entwicklungs-SOP“ oder „Verfahrensanweisung Entwicklung“ nennt.

Doch wie unterscheiden sich die Dokumente? Welche Informationen sollte der Entwicklungsplan enthalten welche die Prozessbeschreibung? Dieser Beitrag liefert Antworten.

Beschreibung des Entwicklungsprozesses

Es existieren mehrere weitgehend synonyme Beschreibungen für Entwicklungsprozesse:

  • Beschreibung Entwicklungsprozess
  • Verfahrensanweisung Entwicklung
  • Entwicklungs-SOP

Gegenstand einer Entwicklungsprozess-Beschreibung

Eine Verfahrens- oder Prozessbeschreibung sollte allgemein, d.h. unabhängig von einem konkreten Produkt oder Projekt festlegen, wer wann wie welche Tätigkeit mit welchem Input und welchem Output durchführt.

  • Mit wann ist die Reihenfolge, in der Tätigkeiten durchgeführt werden, gemeint oder die Abhängigkeit von einer anderen Tätigkeit.
  • Das wie bezieht sich auf die Methoden oder Werkzeuge.
  • Die Inputs sind die „Eingaben“ für die jeweiligen Tätigkeit als auch für den gesamten Prozess. Beispielsweise kann eine Systemspezifikation ein Input des ganzen Prozesses und Input der Tätigkeit „Software-Architektur entwickeln“ sein. Die Software-Architektur sollte als Input der Tätigkeit „Software implementieren“ dienen, ist aber kein Input des Entwicklungsprozesses selbst.
  • Das analoge gilt für die Outputs, die Ergebnisse von Tätigkeiten und des Prozesses.

Diese Aspekte erinnern an das Turtle-Diagramm, das als einfaches Modell zum Erstellen von Verfahrens- und Prozessbeschreibungen dient.

Das Turtle-Diagramm illustriert die Aspekte, die eine Prozess- bzw. Verfahrensanweisung aus Blackbox-Sicht beschreiben sollte.
Abb 1: Das Turtle-Diagramm illustriert die Aspekte, die eine Prozess- bzw. Verfahrensanweisung aus Blackbox-Sicht beschreiben sollte.

Beispiel

Lassen Sie uns das an einem Beispiel ansehen: Eine Beschreibung eines Entwicklungsprozesses könnte festlegen, dass es der Software-Entwickler ist (wer), der für das Was, nämlich das Code-Review verantwortlich ist.

Dies – nun kommen wir zum „wann“ – muss er sofort machen, wenn ein Kollege eine Software-Einheit fertiggestellt hat oder wenn der Code auf einen Branch „gemerged“ werden soll oder wenn ein Tag vergangen ist.

Das wie bezieht sich auf die Methoden oder Verfahren bzw. Werkzeuge. Das Werkzeug bzw. die Methode beim Code-Review könnte das Durchgehen einer Review-Checkliste auf Papier sein.

Der Input dieser Tätigkeit ist der Code und ggf. Coding-Guidelines, gegen die zu prüfen ist. Der Output ist die ausgefüllte Checkliste mit der Bewertung, ob der Code den Coding-Guidelines entspricht oder nachgebessert werden muss.

Weiterführende Informationen

Lesen Sie hier mehr zu folgenden Themen

Entwicklungsplan

Gegenstand des Entwicklungsplans

Der Entwicklungsplan hingegen muss die Vorgaben für ein konkretes Entwicklungsprojekt bzw. zu entwickelndes Produkt festlegen.

Wenn die „Entwicklungs-SOP“ das Vorgehen weitgehend regelt d.h. fast alle notwendigen Vorgaben enthält, enthält der Entwicklungsplan neben dem Verweis auf die Entwicklungs-SOP nur noch Aspekte wie:

  • Konkrete Festlegung der Termine bzw. Zuordnung der Termine zu den im Entwicklungsprozess definierten Meilensteinen
  • Zuordnung von Personen zu den Rollen, die die Entwicklungsprozessbeschreibung fordert

Damit können Sie Ihren Entwicklungsplan auf ein zweiseitiges Dokument schrumpfen.

Regulatorische Anforderungen

Software-Entwicklungsplan

Forderungen der IEC 62304

Die IEC 62304 fordert, dass der Entwicklungsplan die im Kapitel „Entwicklungsprozess“ angesprochenen Aspekte adressiert. Wie gesagt, ist es oft sinnvoll, auf den Entwicklungsprozess zu referenzieren. Konkret sollte der Software-Entwicklungsplan beinhalten

  • den konkreten Prozess (die Norm lässt die Freiheit einen zu wählen, er muss aber festgelegt sein)
  • Die Inputs und Outputs der Tätigkeiten einschließlich formaler Anforderungen an die Dokumentation
  • Explizit müssen dabei das Tracing, das Testing, das Konfigurationsmanagement und die Problemlösung adressiert sein.
  • Ziel des konkreten Entwicklungsvorhabens (Verweis auf Software-Anforderungen)
  • Werkzeuge
  • Normen und/oder eigene Vorgaben wie Kodierrichtlinien.

Weshalb diese regulatorischen Anforderungen tw. unlogisch sind

Der Entwicklungsplan soll zuerst vorliegen. Das bedeutet aber, dass Werkzeuge und Vorgaben das Testen betreffend bereits benannt sind. Das ergibt allerdings nicht immer Sinn. Beispielsweise ist es Aufgabe des Architekten, Technologien wie eine Programmiersprache zu wählen, die geeignet sind, die Software-Anforderungen zu erfüllen. Abhängig von der Wahl der Programmiersprache — um das Beispiel fortzuführen — ist jedoch die Wahl

  • der Werkzeuge
  • der Testmethoden
  • der Art und Weise wie das Konfigurationsmanagement umgesetzt wird.

Software-Entwicklungsprozess

MDR / IVDR

Die MDR (und gleichlautend die IVDR) fordert von den Herstellern ein Qualitätsmanagementsystem:

Das Qualitätsmanagementsystem umfasst alle Teile und Elemente der Organisation eines Herstellers, die mit der Qualität der Prozesse, Verfahren und Produkte befasst sind. Es steuert die erforderliche Struktur und die erforderlichen Verantwortlichkeiten, Verfahren, Prozesse und Managementressourcen zur Umsetzung der Grundsätze und Maßnahmen, die notwendig sind, um die Einhaltung der Bestimmungen dieser Verordnung zu erreichen.

MDR, Artikel 10

Dieses Qualitätsmanagementsystem muss auch die Entwicklung abdecken:

die Produktrealisierung einschließlich Planung, Auslegung, Entwicklung, Herstellung und Bereitstellung von Dienstleistungen;

MDR, Artikel 10

D.h. alle Hersteller unabhängig von der Klasse der Produkte müssen Verfahren bzw. Prozesse für die Produktrealisierung beschreiben. Genau dies geschieht üblicherweise in Form einer entsprechenden SOP bzw. Prozessbeschreibung.

ISO 13485

Die ISO 13485 widmet dem Thema Produktrealisierung das ganze siebte Kapitel und fordert ebenfalls eine (oder mehrere) Prozess- bzw. Verfahrensbeschreibungen.

Aufteilung der Inhalte: Entwicklungsplan oder Entwicklungs-SOP?

Sie haben die Wahl, ob Sie Ihre Vorgaben eher in der Entwicklungsprozess-Beschreibung oder eher im Entwicklungsplan dokumentieren. Im ersten Fall würde der Entwicklungsplan wie oben geschrieben die Entwicklungs-SOP im Wesentlichen nur referenzieren. Im zweiten Fall steht in der Entwicklungs-SOP, dass die Details im Entwicklungsplan festzulegen seien.

Bei Ihrer Entscheidung können Sie sich von folgenden Fragen leiten lassen:

  • Sind Sie ein Entwicklungsdienstleister? Falls ja, werden Sie wahrscheinlich an vielen verschiedenen Projekte und Produkten arbeiten. Das bedingt verschiedene Technologien und Vorgaben der Hersteller. In diesem Fall werden Sie die meisten konkreten Inhalte im Entwicklungsplan dokumentieren.
  • Sind Sie ein kleinerer Inverkehrbringer, der im Wesentlichen ein oder wenige ähnliche Produkte immer „nur“ weiterentwickelt? Dann werden sich Ihre Vorgehensmodelle kaum unterscheiden, und Sie können die meisten Inhalte bereits in Ihrer SOP festhalten.
  • Sind Sie ein mittleres bis großes Medizintechnik-Unternehmen? Dann werden Sie wahrscheinlich viele Produkte mit vielen unterschiedlichen Software-Systemen entwickeln, für die eine für alle gültige SOP nur relativ allgemeingültig bleiben kann.

Unterstützung beim Schreiben Ihre Entwicklungsplans oder Ihrer Entwicklungs-SOP

Wir haben Ihnen ein Videotrainings im Auditgarant vorbereitet, in dem wir erklären, wie Sie Entwicklungsprozesse beschreiben können, wann Sie Ihren Entwicklungsplan schlank halten können und unter welchen Voraussetzungen Sie welche Informationen am besten in den Entwicklungsplan bzw. in die Prozessbeschreibung verschieben. Auch auf die regulatorischen Forderungen der IEC 62304 gehen wir ein.

Wenn Sie Fragen zum Schreiben von Entwicklungsprozess-Beschreibungen (SOPs) oder Entwicklungsplänen haben, dann nehmen Sie gleich Kontakt mit uns auf.

Kontakt aufnehmen

War dieser Artikel hilfreich? Bitte bewerten Sie:
1 Stern2 Sterne3 Sterne4 Sterne5 Sterne

Kategorien: Software & IEC 62304
Tags:

Kommentar schreiben