Werkzeuggestützte Entwicklung
medizinischer Software
Die Entwicklung medizinischer Software – egal, ob für PC-Applikatione...
Polarion Software®
2www.polarion.com
Leider wird in einer laufenden Software-Entwicklung schnell klar, dass zentrale Schwi...
Polarion Software®
3www.polarion.com
Zu allen identifizierten Deliverables können weiterhin noch Attribute aus der Norm en...
Polarion Software®
4www.polarion.com
Europe, Middle-East, Africa: Polarion Software GmbH
Kesselstraße 19 — 70327 Stuttgart...
Nächste SlideShare
Wird geladen in …5
×

Werkzeuggestützte Entwicklung Medizinischer Software

242 Aufrufe

Veröffentlicht am

Die Entwicklung medizinischer Software – egal, ob für PC-Applikationen, wie Diagnose- oder Therapieplanungssysteme, oder embedded Applikationen wie, die Steuerung eines Beatmungsgerätes – wird durch die internationale Norm IEC 62304 geregelt. Diese Norm macht Vorgaben für alle Phasen des Lebenszyklus einer medizinischen Software, die in der Entwicklung berücksichtigt werden müssen. Da Software-Entwicklung eine sehr dynamische und technikorientierte Tätigkeit ist, werden hierbei häufig Werkzeuge eingesetzt, die die Entwicklung effizienter und den Entwicklungsfortschritt transparenter machen.

Erfahren Sie in diesem Whitepaper, wie Sie die Software-Entwicklung in der Medizintechnik compliance-konform machen.

Veröffentlicht in: Software
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
242
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
3
Aktionen
Geteilt
0
Downloads
0
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Werkzeuggestützte Entwicklung Medizinischer Software

  1. 1. Werkzeuggestützte Entwicklung medizinischer Software Die Entwicklung medizinischer Software – egal, ob für PC-Applikationen, wie Diagnose- oder Therapieplanungssysteme, oder embedded Applikationen wie, die Steuerung eines Beatmungsgerätes – wird durch die internationale Norm IEC 62304 geregelt. Diese Norm macht Vorgaben für alle Phasen des Lebenszyklus einer medizinischen Software, die in der Entwicklung berücksichtigt werden müssen. Da Software-Entwicklung eine sehr dynamische und technikorientierte Tätigkeit ist, werden hierbei häufig Werkzeuge eingesetzt, die die Entwicklung effizienter und den Entwicklungsfortschritt transparenter machen. Es stellt sich also zwangsläufig die Frage, mit welchen Werkzeugen bzw. mit welchen Ansätzen die Umsetzung der Forderungen dieser Norm unterstützt werden kann. Welche Herausforderungen an die Software-Entwicklung stellt die IEC 62304? Die IEC 62304 ist eine Prozessnorm und aus diesem Grund sehr unkonkret bezüglich der tatsächlich anzuwendenden Praktiken und Methoden. Sie macht Vorgaben für Prozesse, Aktivitäten und Aufgaben und definiert diese Begriffe wie folgt: Prozess: Satz von in Wechselbeziehung oder Wechselwirkung stehenden Aktivitäten, der Eingaben in Ergebnisse umwandelt. Aktivität: Satz von einer oder mehreren aufeinander bezogenen oder sich gegenseitig beeinflussenden Aufgaben. Aufgabe: Eine Teilarbeit, die erledigt werden muss. Die Norm identifiziert die fünf Prozesse Entwicklung, Wartung, Konfigurationsmanagement, Problemlösung und Software-Risikom- anagement und definiert jeweils Aktivitäten und Aufgaben, die innerhalb dieser Prozesse erledigt und nachgewiesen werden müs- sen. Auf den ersten Blick scheinen die Hauptforderungen der Norm deshalb zu sein, • Prozesse zu konkretisieren, • Aktivitäten innerhalb dieser Prozesse festzulegen sowie • Dokumente zu erstellen. Aus diesem Grund scheinen sich Werkzeuge zum „Business Process Modelling“ (BPM) anzubieten. Diese bieten die Möglichkeit, Rollen, Artefakte sowie Aktivitäten und deren Beziehungen zueinander festzulegen und zu visualisieren. Hiermit lassen sich die oben genannten Forderungen erfüllen und auditsicher umsetzen. Polarion Software® Whitepaper Copyright © 2015 Polarion Software - Die Vervielfältigung und Weitergabe dieses Dokuments in unveränderter Form ist gestattet.
  2. 2. Polarion Software® 2www.polarion.com Leider wird in einer laufenden Software-Entwicklung schnell klar, dass zentrale Schwierigkeiten mit einer solchen recht abstrakten Beschreibung nicht gelöst werden können: • Software-Anforderungen müssen bis zur einzelnen Anforderung identifizierbar sowie mit Tests und gegebenenfalls System- Anforderungen verknüpfbar sein. Die Prozessmodellierung endet meist bei einem „Anforderungsdokument“, ist an dieser Stelle also nicht detailliert genug. • Es müssen zumeist mehrere Produkt-Versionen verwaltet werden, wobei bei diesen große Überschneidungen von Anforderungen vorliegen können. Diese sollten nicht redundant vorgehalten werden. Diese zweite Dimension wird im BPM nicht berücksichtigt. • Es müssen ggf. mehrere Varianten verwaltet werden, was eine dritte Dimension ergibt, die ebenfalls nicht berücksichtigt werden kann. Business Process Modelling wird diesen Anforderungen also nur unzureichend gerecht. Eine weitere Disziplin, die besonders in der Software-Entwicklung häufig Anwendung findet, ist das sogenannte Application Lifecycle Management (ALM). Mit ALM lassen sich beliebig definierbare Artefakte, ihr Status sowie ihre Beziehungen zueinander verwalten. Wird die IEC 62304 aus diesem Blickwinkel betrachtet, lassen sich ihre zentralen Forderungen folgendermaßen formulieren: • Artefakte: Im Rahmen der Aktivitäten sind bestimmte „zu liefernde Produkte“ („Deliverables“) zu erstellen. • Status/Review: Es muss erkennbar sein, in welchem Zustand sich ein Deliverable befindet, bspw. muss das Ergebnis eines Tests oder der Zustand einer Anforderung (angenommen oder nicht) klar sein. • Traceability: Zwischen den Deliverables muss eine Beziehung festgelegt werden, bspw. muss für Anforderungen angegeben werden, wie diese getestet werden. Wie können die Anforderungen der IEC 62304 in einem ALM-Konzept abgebildet werden? Wird die IEC 62304 entsprechend den obigen drei Punkten analysiert, ergibt sich der in Abbildung 1 gezeigte Zusammenhang. Die Rechtecke symbolisieren hierbei die geforderten „Deliverables“, wobei in der zweiten Zeile jeweils die zentrale Forderung nach einem Review angegeben ist. Die Pfeile symbolisieren die Abhängigkeiten, wobei diese zum abhängigen Element hin (Impact) gezeichnet sind. Für eine Darstellung der Traceability müssen diese Pfeile nur umgedreht dargestellt werden. Die farbigen Rechtecke im Hintergrund repräsentieren die in der Norm identifizierten Prozesse (hellgrau bzw. Hintergrund: Konfigurationsmanagement-Prozess, hellblau bzw. rechtes Rechteck: Prob- lemlösungsprozess, rot bzw. linkes Rechteck: Software-Risikomanage- ment-Prozess, fleischfarben bzw. großes zentrales Rechteck: Entwick- lungs- und Wartungs-Prozess) sowie die Dekomposition des Software- Produktes (grünlicher bzw. zentrales kleines Rechteck). Die IEC 62304 aus Sicht des Application Lifecycle Managements
  3. 3. Polarion Software® 3www.polarion.com Zu allen identifizierten Deliverables können weiterhin noch Attribute aus der Norm entnommen werden. So müssen bspw. für SOUP Komponenten der Hersteller, eine Versionsnummer und eine eindeutige Bezeichnung sowie die Anforderungen an die Komponente und die Anforderungen der Komponente an ihre Laufzeitumgebung definiert werden (Kapitel 8.1.2 und 5.3.4 der IEC 62304:2006). Wie kann dieses Konzept konkret in einem Werkzeug umgesetzt werden? Für die Umsetzung dieses Konzeptes sollte ein Werkzeug die Möglichkeit bieten, Artefakte und Prozesse flexibel anzupassen. Zum einen nach Vorgaben der Norm und zum anderen an die eigenen Unternehmensprozesse. Die Anwender des Werkzeugs sollen sich am Ende keine Gedanken machen müssen, was die nächsten Schritte sind und wie diese umgesetzt werden, sondern sollen vom Werkzeug durch die Prozesse geführt werden. Dabei darf der Anwender aber nicht gezwungen werden, sich in eine komplett neue Umgebung einarbeiten zu müssen. Das Werkzeug dient dazu, die Arbeit des Anwenders zu unterstützen. Es darf sie nicht beeinträchtigen. Die Eingabe der Daten und die Reporting-Funktionalitäten müssen daher intuitiv bedienbar sein, so dass die Anwender das Werkzeug sofort akzeptieren. Die Vorgaben, die aus der Norm kommen, sollten schon vorkonfiguriert sein und nur noch durch Unternehmensvorgaben ergänzt werden müssen. So lässt sich das produktive Arbeiten mit einem Werkzeug wesentlich beschleunigen, da sichergestellt ist, dass alle Bedingungen der Norm erfüllt werden. Der Anwender muss eine fertige Schablone erhalten, die nur noch nach Prozessvorgaben auszufüllen ist. Zusätzlich benötigen sowohl Kollegen als auch Vorgesetzte einen Überblick, welche Schritte als nächstes erledigt werden müssen. Dies im Optimalfall als Live-Report, so dass parallel die Aufgaben erledigt werden und kein zusätzlicher Aufwand notwendig ist, um das Management über den Status zu informieren. Wichtig ist, dass sich diese Aufgaben mit möglichst wenigen Werkzeugen umsetzen lassen, da Schnittstellen die Traceabillity-Analyse erschweren und auch den Anwender vor die Herausforderung stellt, den Umgang mit mehreren Tools zu erlernen. SOUP Item nach Vorgabe der 62304 SEQ Abbildung * ARABIC 3: Traceabillity-Analyse aller Software- Requirements ohne System-Testfälle
  4. 4. Polarion Software® 4www.polarion.com Europe, Middle-East, Africa: Polarion Software GmbH Kesselstraße 19 — 70327 Stuttgart, GERMANY Tel +49 711 489 9969 - 0 Fax +49 711 489 9969 - 20 www.polarion.com - info@polarion.com Americas & Asia-Pacific: Polarion Software, Inc. 1001 Marina Village Parkway, Suite 403, Alameda, CA 94501, USA Tel +1 877 572 4005 Fax +1 510 814 9983 www.polarion.com - info@polarion.com Autoren Sven Wittorf Geschäftsführer, Medsoto GmbH, Konstanz Dipl.-Ing. Sven Wittorf ist Spezialist für medizinische Software. Er betreut und schult Firmen beim Aufsetzen nor- menkonformer Softwarentwicklungsprozesse und ist seit 2012 geschäftsführender Gesellschafter der Medsoto GmbH, die Software-Werkzeuge für Medizintechnikhersteller erstellt. Darüberhinaus ist er als Referent für benannte Stellen tätig und ist Mitautor des Buches “Basiswissen medizinische Software”, das im dpunkt Verlag erschienen ist. Daniel Morris Technical Account Manager, Consultant, Polarion Software GmbH, Stuttgart Daniel Morris ist Technical Account Manager, Consultant im Professional-Services-Teams der Polarion Software GmbH. Neben seinem Informatik-Studium an der Fachhochschule Aachen arbeitete er bereits als Software- Entwickler bei der IBS Aachen GmbH. Seit 2011 unterstützt er Polarion-Kunden dabei, ihre Entwicklungsprozesse zu professionalisieren und Application-Lifecycle-Management-Software zu implementieren. Aktuell absolviert Daniel Morris zudem ein Masterstudium in Wirtschaftsinformatik an der Hochschule Wismar. Über Polarion Software Polarion Software ist ein führender Anbieter einer durchgängigen und zu 100% Browser-basierten Plattform für Anforderungs-,Test- und Application-Lifecycle-Management (ALM). Polarion wird von globalen Unternehmen in einer Vielzahl von Branchen eingesetzt, wie zum Beispiel im Automobilbau, in der Medizintechnik und in der Luft- und Raumfahrt. Kunden erzielen mit Polarion die für die Herstellung Ihrer Produkte nötige Agilität, Traceability und Compliance. Käufer der mit Polarion entwickelten Produkte erwarten eine herausragende Qualität und Sicherheit. Mehr als 2,5 Millionen Anwender weltweit vertrauen deswegen auf Polarion, um die Zusammenarbeit in ihren Unternehmen voranzutreiben, ALM und Product Lifecycle Management (PLM) zu verküpfen und um ihre hochwertigen Produkte auf den Markt zu bringen. Weitere Informationen unter: www.polarion.com

×