In dieser Arbeit wird ein Referenzmodell zur Entwicklung von Medizinprodukten konstruiert, das die gesetzlichen Vorgaben zur Herstellung von Medizinprodukten erfüllt und die Ableitung unternehmensspezifischer, agiler Vorgehensmodelle ermöglicht. Mit der zunehmenden Verbreitung agiler Entwicklungsmethoden und dem damit verbundenen Ziel, bessere Produkte in kürzerer Zeit zu entwickeln, gewinnt der Einsatz agiler Vorgehensmodelle auch bei Herstellern von Medizinprodukten an Bedeutung. Während agile Vorgehen auf der Wiederholung des Entwicklungsprozesses in kurzen Zeiträumen basieren und sich weniger auf Dokumentation, sondern auf ein funktionierendes Produkt konzentrieren, folgen die bei Medizingeräteherstellern umgesetzten Vorgehen oft plangetriebenen Modellen. Die Konformität zu den gesetzlichen Vorgaben ist von Medizingeräteherstellern anhand umfangreicher Dokumentation nachzuweisen.
Aktuelle Ansätze zur Umsetzung agiler Methoden bei der Entwicklung von Medizinprodukten folgen überwiegend hybriden Vorgehensmodellen, bei welchen die Phasen der Anforderungsermittlung, Spezifikation und Prüfung plangetrieben durchgeführt werden. In diesen hybriden Modellen wird nur die Implementierung unter Einsatz agiler, iterativer Methoden durchgeführt. Um die Vorteile der agilen Werte und Prinzipien auf alle Phasen der Entwicklung anzuwenden, wurde in dieser Arbeit daher ein Referenzmodell zur Entwicklung von Medizinprodukten konstruiert, dass die gesetzlichen Vorgaben zur Herstellung von Medizinprodukten erfüllt und mit welchem die Ableitung unternehmensspezifischer, agiler Vorgehensmodelle ermöglicht wird.
Mit der Konstruktion des Referenzmodells sind die Hauptprobleme agiler Entwicklung gelöst. Die Konformität zu gesetzlichen Vorgaben ist mit der Zuweisung regulatorischer Vorgaben zu den im Referenzmodell definierten Aktivitäten und Arbeitsergebnissen erfüllt. Das Problem der Dokumentation ist mit der Einführung eines inkrementell erstellten und freigegebenen Life Cycle Element gelöst.
Inhaltsverzeichnis
Management Summary
Glossar
Einleitung
1.1 Ausgangslage
1.2 Forschungsproblem
1.3 Forschungsfrage
1.4 Zielsetzungen und inhaltliche Abgrenzung
2 Theoretischer Teil
2.1 Entwicklung von Medizinprodukten
2.1.1 Klassifizierung
2.1.2 Technologie
2.1.3 Produktlebenszyklus
2.1.4 Ressourcenbedarf
2.1.5 Auditierung der Produktionsstätte
2.1.6 Gesetzliche Anforderungen
2.1.7 Prozessanforderungen
2.1.8 Rollen
2.2 Entwicklung von Systemen
2.3 Agile Entwicklung
2.3.1 Agiles Manifest
2.3.2 Agile Vorgehensmodelle
2.3.2.1 Scrum
2.3.2.2 LeSS Framework
2.3.2.3 SAFe
2.3.2.4 XP
2.3.2.5 Disciplined Agile
2.3.3 Hybride GxP Vorgehensmodelle
2.4 Zusammenfassung und Bewertung
3 Methodische Vorgehensweise
3.1 Referenzmodellierung
3.2 Modellierungssprache
4 Konstruktiver Teil
4.1 Problemdefinition
4.2 Referenzmodellrahmen
4.3 Referenzmodellstruktur
4.3.1 Prozessmodell Sprint Planung
4.3.2 Prozessmodell Daily Scrum
4.3.3 Prozessmodell Durchführung der Arbeit
4.3.4 Prozessmodell Sprint Review
4.3.5 Prozessmodell Sprint Retrospektive
4.4 Referenzdatenmodell
4.5 Referenzmodellkonfiguration
4.6 Prüfung des Referenzmodells
4.7 Schwierigkeiten und Einschränkungen
4.8 Vergleich mit den Zielsetzungen
5 Schlussfolgerungen und Empfehlungen
5.1 Auswertung und Interpretation der Ergebnisse
5.2 Nachweis, dass die Realisierung die Ziele erreicht hat
5.3 Ausblick
5.4 Ungelöste Probleme
6 Anhang
6.1 Gesetzliche Anforderungen
6.2 BPMN 2.0 Elemente
6.3 Entity-Relationship Elemente
Literaturverzeichnis
Abkürzungsverzeichnis
Tabellen- und Abbildungsverzeichnis
Management Summary
Mit der zunehmenden Verbreitung agiler Entwicklungsmethoden und dem damit verbundenen Ziel, bessere Produkte in kürzerer Zeit zu entwickeln, gewinnt der Einsatz agiler Vorgehensmodelle auch bei Herstellern von Medizinprodukten an Bedeutung. Während agile Vorgehen auf der Wiederholung des Entwicklungsprozesses in kurzen Zeiträumen basieren und sich weniger auf Dokumentation, sondern auf ein funktionierendes Produkt konzentrieren, folgen die bei Medizingeräteherstellern umgesetzten Vorgehen oft plangetriebenen Modellen. Die Konformität zu den gesetzlichen Vorgaben ist von Medizingeräteherstellern anhand umfangreicher Dokumentation nachzuweisen. Aktuelle Ansätze zur Umsetzung agiler Methoden bei der Entwicklung von Medizinprodukten folgen überwiegend hybriden Vorgehensmodellen, bei welchen die Phasen der Anforderungsermittlung, Spezifikation und Prüfung plangetrieben durchgeführt werden. In diesen hybriden Modellen wird nur die Implementierung unter Einsatz agiler, iterativer Methoden durchgeführt. Um die Vorteile der agilen Werte und Prinzipien auf alle Phasen der Entwicklung anzuwenden, wurde in dieser Arbeit daher ein Referenzmodell zur Entwicklung von Medizinprodukten konstruiert, dass die gesetzlichen Vorgaben zur Herstellung von Medizinprodukten erfüllt und mit welchem die Ableitung unternehmensspezifischer, agiler Vorgehensmodelle ermöglicht wird.
Für die Konstruktion des Referenzmodells sind ausgewählte agile und hybride Vorgehensmodelle auf ihre gemeinsamen Eigenschaften untersucht worden. Mit dem Ergebnis, dass Scrum das Modell mit der höchsten Abstraktionsstufe ist und die meisten Gemeinsamkeiten mit den untersuchten Vorgehensmodellen hat, wird das Referenzmodell basierend auf den Prozessen und Arbeitsergebnissen von Scrum entwickelt. Zur Ableitung des Referenzmodells wurde entgegen den untersuchten, hybriden Vorgehensmodellen nicht von einem plangetriebenen Vorgehensmodell als Basis ausgegangen, sondern mit Scrum als idealisierte Darstellung agiler Entwicklung werden die gesetzlichen Anforderungen in ein definiertes, agiles Vorgehensmodell integriert. Mit diesem Vorgehen wird sichergestellt, dass die agilen Werte und Prinzipien möglichst unverändert auf das Referenzmodell anwendbar sind.
Mit der Abgrenzung des Referenzmodells innerhalb der Wertschöpfungskette von Medizinprodukteherstellern werden mit der Definition des Referenzmodellrahmens die detaillierten Prozess- und Informationsobjekte entworfen und miteinander verbunden. Mit der Konstruktion des Referenzmodells sind die Hauptprobleme agiler Entwicklung gelöst. Die Konformität zu gesetzlichen Vorgaben ist mit der Zuweisung regulatorischer Vorgaben zu den im Referenzmodell definierten Aktivitäten und Arbeitsergebnissen erfüllt. Das Problem der Dokumentation ist mit der Einführung eines inkrementell erstellten und freigegebenen Life Cycle Element gelöst.
Die Wiederverwendbarkeit des Referenzmodells wird durch die Anwendung der Business Process Model and Notation (BPMN) 2.0 als Modellierungssprache sichergestellt.
Mit der abschliessenden Prüfung auf die Erfüllung der agilen Werte und regulatorischen Anforderungen schliesst die Arbeit ab und stellt Herstellern von Medizinprodukten ein Referenzmodell zur Ableitung unternehmensspezifischer Vorgehensmodelle zur Verfügung, mit welchen die Entwicklung von Medizinprodukten agil und in Übereinstimmung mit den gesetzlichen Vorgaben möglich ist.
Glossar
Dieses Glossar führt alle in dieser Arbeit verwendeten spezifischen Ausdrücke auf. Die zugrundeliegenden Methoden und Vorgehen dieser Arbeit basieren teilweise auf englischen Fachbegriffen, die nur dann ins Deutsche übersetzt wurden, wenn die Verständlichkeit der Begriffe nicht beeinflusst wird. Nicht in dieses Glossar aufgenommen wurden Abkürzungen (Kapitel 0, S. 112) und Begriffe, die für die Zielgruppe dieser Arbeit offensichtlich sind.
Tabelle 1 Glossar
Abbildung in dieser Leseprobe nicht enthalten
Einleitung
“I estimate that 75% of those organizations using Scrum1 will not succeed in getting the benefits that they hope for from it.”
Ken Schwaber
1.1 Ausgangslage
Hersteller von Medizinprodukten stehen vor der Herausforderung, die immer kürzer werdenden Innovationszyklen mit der steigenden Komplexität gesetzlicher Vorgaben zu vereinbaren. Steht die Entwicklung neuer, technologisch innovativer Produkte im Vordergrund, dann kann zwar die finanzielle Erwartung im Vergleich zur Verbesserung bestehender Produkte weit übertroffen werden, für eine signifikante Erhöhung des Markterfolges ist jedoch ein früher Einbezug der Nutzer erforderlich (Brown, Dixon, Eatock, Meenan, & Young, 2008, p. 5). Die Nutzer von Medizinprodukten sind in sehr unterschiedlichen Bereichen tätig und erstrecken sich von Ärzten, Gesundheitspersonal bis zu Patienten, wodurch eine Erfassung von Benutzeranforderungen mit regelmässiger Rückmeldung während der Produktentwicklung nicht immer möglich ist. Innovative Produkte und sich ändernde Anforderungen der Zielgruppen ermöglichen zudem kaum eine vollständige und fehlerfreie Spezifikation von Medizinprodukten vor dem Entwicklungsbeginn. Nach Schmitt (Schmitt & Pfeifer, 2015, S. 142-143) steigt dadurch bei linearen, plangetriebenen Vorgehensmodellen das Risiko von Spezifikationsfehlern und damit erhöhen sich auch die Kosten zur Fehlerbehebung, sofern diese nicht in der Definitionsphase eines Produktes entdeckt werden (Abbildung 1, S. 2).
Aus finanziellen Gründen sind viele Hersteller darauf angewiesen, ihre Medizinprodukte während der klinischen Erprobung iterativ weiterzuentwickeln (BVMed, 2014). Plangetriebene Vorgehensmodelle, wie zum Beispiel das V-Modell, unterstützen die iterative Entwicklung jedoch nur bedingt. Um im internationalen Wettbewerb mit qualitativ hochwertigen Produkten erfolgreich zu bestehen und um die Risiken und Fehlerkosten bei der Entwicklung von Medizingeräten zu reduzieren, setzen Hersteller daher zunehmend auf den Einsatz agiler Methoden (TÜVRheinland, 2020).
Agile Vorgehensmodelle basieren auf der engen Zusammenarbeit der Entwicklung mit den Benutzern des Produktes und zeichnen sich durch kurze, sich wiederholende Entwicklungszyklen aus. Zu den weiteren Vorteilen agiler Modelle gehören das transparente Vorgehen und die umgehende Reaktion auf Fehler und Veränderungen. Durch den direkten Einbezug von Kunden fördern agile Vorgehen das Entstehen von innovativen und den Nutzeranforderungen entsprechenden Produkten in kürzerer Zeit. Im Vergleich zu plangetriebenen Vorgehensmodellen, bei welchen der Kunde das Endprodukt nach der Fertigstellung bewertet, ermöglicht die regelmässige und umgehende Rückmeldung des Kunden während der agilen Entwicklung eine kontinuierliche Anpassung des Produktes an die Erwartungen des Benutzers. (Beck, et al., Manifest für Agile Softwareentwicklung, 2001).
Abbildung 1 Entwicklung von Fehlerkosten in sequentiellen Vorgehensmodellen
Abbildung in dieser Leseprobe nicht enthalten
Quelle: (Pfeifer (2010) in Nierensee, 2012, S. 12)
Die Vorteile agiler Vorgehensmodelle bestätigt Yu Beng Lau (Yu Beng Leau, 2012, p. 165) in einem Vergleich agiler und traditioneller2 Vorgehensmodelle. Geringere Fehlerkosten und eine ständige Bereitschaft, Änderungen zu berücksichtigen sind dabei entscheidende Vorteile gegenüber traditionellen Vorgehensmodellen (Tabelle 2, S. 3). Zusätzlich bestätigt Yu Beng Leau (Yu Beng Leau, 2012, p. 164) die Notwendigkeit einer starken Einbindung des Kunden und der Verfügbarkeit eines Teams mit hoher Sozialkompetenz. Die stärkere Beteiligung des Kunden lässt sich dabei insofern hinterfragen, dass auch bei traditionellen Vorgehensmodellen die Kundenbeteiligung während der Anforderungsanalyse und bei der Produktabnahme hoch sein kann.
Tabelle 2 Agile und traditionelle Vorgehensmodelle im Vergleich
Abbildung in dieser Leseprobe nicht enthalten
Quelle: (Yu Beng Leau, 2012, p. 165)
Einsparungspotentiale bei der Anwendung agiler Vorgehensmodelle verspricht auch der Scaled Agile Framework (SAFe). Der Einsatz von SAFe kann zu einer 30-75% schnelleren Produkteinführungszeit führen und eine 20-50% höhere Produktivität erzielen. Die Zahlen basieren auf ausgewählten Fallstudien des Urhebers von SAFe, eine wissenschaftliche Bestätigung der Produktivitätssteigerung konnte nicht identifiziert werden (Leffingwell, 2018). Neben SAFe basieren weitere agile Vorgehensmodelle auf den Werten und Prinzipien des Agilen Manifest. Zu den Werten des Agilen Manifest gehört, dass Planung, Prozesse, Tools und Dokumentation einen geringeren Wert zugeschrieben bekommen als Individuen und Interaktion, funktionierende Software, Kundenzusammenarbeit und Reaktion auf Veränderung (Beck, et al., Manifest für Agile Softwareentwicklung, 2001).
Den Werten des agilen Manifests stehen die rechtlichen Grundlagen für die Entwicklung und Zulassung von Medizingeräten gegenüber. In den U.S.A. werden die rechtlichen Grundlangen von der FDA (U.S. Food and Drug Administration) festgelegt und im CFR (Code of Federal Regulations) definiert. Die relevanten Vorgaben zur Entwicklung von Medizinprodukten sind im CFR Title 21, Subchapter H Medical Devices aufgeführt. Analog der rechtlichen Grundlagen der FDA bestimmt die Medizingeräteverordnung 2017/7453 (MDR) des Europäischen Parlamentes den Rechtsrahmen für Medizinprodukte in der EU (Europäische Union). Die Einhaltung der jeweils gültigen Vorschriften zur Inverkehrbringung im Absatzland ist in beiden Geltungsbereichen zwingend erforderlich.
Ein gemeinsames Merkmal der länderspezifischen Vorschriften ist die Etablierung eines Qualitätsmanagementsystems. Die Anforderungen an ein Qualitätsmanagementsystem sind in der EU als Europäischen Norm (EN) festgeschrieben und von der Internationalen Organisation für Normung (ISO) 134854 veröffentlicht. Die EN 62304 der IEC (International Electrotechnical Commission) definiert Anforderungen an den Lebenszyklus von Medizingeräten und beschreibt dazu ein anwendbares Prozessmodell.
Vor der Inverkehrbringung eines Medizinproduktes muss den zuständigen Behörden nachgewiesen werden, dass die Produktentwicklung nach den Vorgaben des unternehmensspezifischen Qualitätsmanagementsystems erfolgt ist. Als Nachweis wird eine nachvollziehbare und widerspruchsfreie Dokumentation gefordert. Neben der Nachvollziehbarkeit und Widerspruchsfreiheit fordert die MDR, dass die technische Dokumentation eines Medizingerätes «in klarer, organisierter, leicht durchsuchbarer und eindeutiger Form präsentiert» wird (Europäisches Parlament und der Rat der Europäischen Union, 2017, S. 108). Umgesetzt werden die Dokumentationsanforderungen häufig durch ein auf dem V-Modell basierendes Vorgehen (Abbildung 2, S. 5). Nach Abschluss einer Phase werden dabei die während der jeweiligen Entwicklungsphase entstandenen Dokumentationen formal freigegeben. Diese Freigaben erfolgen dabei nach den in ISO 13485 (Kapitel 4.2 Dokumentationskontrolle in DIN-Normenausschuss Medizin (NAMed), 2016, S. 18-20) und CFR 820 (§820.40 Document controls in FDA, 2020) definierten Anforderungen an die Dokumentation. Als Besonderheit zu Entwicklungsprojekten, die nicht durch regulatorische Vorgaben getrieben werden, müssen die im Rahmen der Herstellung von Medizinprodukten erstellten Dokumente formal geprüft und rechtsgültig unterschrieben werden.
Abbildung 2 V-Modell
Abbildung in dieser Leseprobe nicht enthalten
Quelle: (GAMP-4 in PIC/S, 2007, p. 13)
Obwohl die agilen Werte und Prinzipien funktionierende Software höher werten als eine umfassende Dokumentation, gibt es einen direkten Zusammenhang zwischen einer erfolgreichen Projektabwicklung und der nachvollziehbaren Dokumentation der Ermittlung, Abstimmung und Änderung von Anforderungen. Unabhängig von der Branche basieren dabei 49% aller Fehler von Anforderungen auf falschen Annahmen, 29% auf fehlenden Anforderungen, 13% auf Inkonsistenzen und 5% auf Unklarheiten (Hooks and Kristin (2001) in Yilmaz & Yilmaz, 2011, p. 23). Mit dem Widerspruch der gesetzlichen Anforderungen an eine nachvollziehbare und vollständige Dokumentation zu einer weniger auf Dokumentation basierenden agilen Vorgehensweise wird in Kapitel 11.2 das Forschungsproblem dieser Arbeit hergeleitet.
1.2 Forschungsproblem
Beim Versuch, die agilen Prinzipien bei der Entwicklung von Medizinprodukten zu nutzen, wird vielfach ein hybrides Modell eingesetzt. Hybride Modelle kombinieren dabei mindestens zwei Vorgehensmodelle, wobei häufig die die Planungs-, Anforderungs- und Testphasen plangetrieben und linear erfolgen (Abbildung 3, S. 6). Die agilen Methoden werden meistens in der Implementierungsphase eingesetzt und setzen damit stabile und freigegebenen Pläne und Anforderungen voraus.
Abbildung 3 Hybrides Vorgehensmodell
Abbildung in dieser Leseprobe nicht enthalten
Quelle: (Lin & Fan, 2009, p. 390)
Der durch den Einsatz agiler Methoden erhofften Nutzen, wie zum Beispiel Änderungen auch spät in der Entwicklung berücksichtigen zu können, wird bei hybriden Vorgehensmodellen nicht vollständig ausgeschöpft, da die Anforderungen, Entwicklungs- und Validierungspläne vor der jeweiligen Phase freigegeben sein müssen.
Ein Vergleich von agilen Vorgehensmodellen belegt, dass 3 von 5 Modellen die Entwicklung von Software abdecken. Systeme, die wie Medizinprodukten aus einer Kombination aus Hardware, Software und mechanischen Komponenten bestehen können, werden nur von 2 Modellen berücksichtigt (Ebert & Paasivaara, 2017, p. 100).
Aus der weiteren Betrachtung von Kriterien zur Einfachheit, Skalierbarkeit, Komplexität und Kosten kann festgestellt werden, dass 4 der 5 agilen Vorgehensmodelle mindestens das Prinzip der Einfachheit nicht mehr erfüllen (Tabelle 3, S. 7).
Tabelle 3 Vergleich agiler Frameworks
Abbildung in dieser Leseprobe nicht enthalten
Quelle: (Ebert & Paasivaara, 2017, p. 100)
Handlungsempfehlungen zur Umsetzung der gesetzlichen Vorgaben bei der Entwicklung von Medizinprodukten wurden von der Association for the Advancement of Medical Instrumentation (AAMI) in Form eines technischen Berichtes veröffentlicht. Dabei werden die in der ISO 623045 definierten Aktivitäten zur Softwareentwicklung in einen agilen Entwicklungslebenszyklus integriert. Der technische Bericht versteht sich jedoch als Handlungsempfehlung und nicht als Vorgehens- oder Referenzmodell (AAMI, 2012, p. 1).
Obwohl agile Vorgehensmodelle Ansätze agilen Entwicklung von Medizingeräten existieren, wurde mit der Untersuchung des Forschungsproblems deutlich, dass es noch kein Referenzmodell gibt, das die Werte und Prinzipien der agilen Entwicklung und die regulatorischen Anforderungen darstellt und somit eine Ableitung von unternehmensspezifischen Vorgehensmodellen erlaubt. Mit dem in diesem Kapitel identifizierten Forschungsproblem wird in Kapitel 11.3 die Forschungsfrage dieser Arbeit hergeleitet.
1.3 Forschungsfrage
Die aktuell veröffentlichten Vorgehensmodelle zur agilen Entwicklung von Medizingeräten basieren überwiegend auf hybriden Ansätzen. Der Ordnungsrahmen ist dabei oft nicht eindeutig abgegrenzt oder beschränkt sich auf die Entwicklung von Software. Eine Suche im Referenzmodellkatalog der Universität Saarbrücken6 lieferte kein Ergebnis zu den Suchbegriffen «agil» oder «Medizingerät» oder «medical device». Daraus lässt sich schliessen, dass für die Herstellung von Medizingeräten kein Referenzmodell existiert, welches die Vorgaben für die Herstellung von Medizinprodukten unter Einhaltung der agilen Prinzipien beschreibt.
Bei erster Betrachtung der Prinzipien und Werte des Agilen Manifest werfen besonders der Wert «Funktionierende Software mehr als umfassende Dokumentation» (Beck, et al., Manifest für Agile Softwareentwicklung, 2001) und das Prinzip von «[...] Anforderungsänderungen selbst spät in der Entwicklung [...]» (Beck, et al., Prinzipien hinter dem Agilen Manifest, 2001) die Frage auf, wie eine agile Entwicklung von Medizinprodukten mit den regulatorischen Vorgaben erfolgen kann, ohne die Vorgaben des CFR (§820.30 und §820.40) zur schriftlichen Freigabe von Planungs- und Entwicklungsdokumentation zu verletzen.
Aus der Forschungslücke zur agilen Entwicklung von Medizinprodukten ergibt sich die Forschungsfrage: Welche Eigenschaften muss ein agiles Referenzmodell zur Entwicklung von Medizinprodukten besitzen, damit die regulatorischen Vorgaben erfüllt werden können?
1.4 Zielsetzungen und inhaltliche Abgrenzung
Die Forschungsfrage dieser Arbeit soll mit der Konstruktion eines Referenzmodells für die agile Entwicklung von Medizinprodukten beantwortet werden. Das Referenzmodell soll es ermöglichen, Vorgehensmodelle zur Entwicklung von Medizinprodukten durch Anwendung der agilen Werte und Prinzipien unter Einhaltung der regulatorischen Vorgaben zu abzuleiten. Um die Zielsetzung zu erreichen, werden in dieser konstruktiven Entwicklungsarbeit nachfolgende Teilaufgaben bearbeitet:
- Kapitel 1 beschreibt die Ausgangslage und das Problem. Die Frage, wie Medizinprodukte unter Anwendung der agilen Werte und Prinzipien entwickelt werden können, leitet die Konstruktion des in im Rahmen dieser Arbeit erstellten Referenzmodells ein.
- Kapitel 2 schafft die theoretischen Grundlagen für die Entwicklung von Medizinprodukten. Dafür werden ausgewählte agile Vorgehensmodelle in Bezug auf deren Anwendbarkeit zur Entwicklung von Medizinprodukten untersucht und bewertet.
- Kapitel 3 beschreibt das Vorgehen zur Beantwortung der Forschungsfrage. Die Forschungsfrage wird mit der Definition eines Referenzmodells beantwortet. Ziel ist dabei, existierende Vorgehensmodelle zu vereinfachen und induktiv das Referenzmodell herzuleiten (Balzert, Schröder, & Schäfer, Wissenschaftliches Arbeiten, 2011, S. 285).
- Kapitel 4 realisiert das Referenzmodell zur agilen Entwicklung von Medizinprodukten. Nach den Grundsätzen ordnungsmässiger Referenzmodellierung werden dabei ausgehend von der Problemdefinition zuerst der Referenzmodellrahmen und die Referenzmodellstruktur entwickelt. Der konstruktive Teil dieser Arbeit schliesst mit dem Vollständigkeitsnachweises des Referenzmodells ab (Schütte, 1998, S. 177-308).
- Kapitel 5 fasst die Ergebnisse dieser Arbeit zusammen und gibt einen Ausblick auf weiterführende Arbeiten.
Das in dieser Arbeit erstellte Referenzmodell erlaubt die Ableitung von Vorgehensmodellen und beschränkt sich auf die regulatorischen Anforderungen zur Entwicklung von Medizingeräten der MDR (Europäisches Parlament und der Rat der Europäischen Union, 2017) und des CFR (FDA 21 Part 820, 2020).
Folgende Themen werden bei der Konstruktion des Referenzmodells nicht berücksichtigt oder beantwortet:
- Technische Umsetzung regulatorischer Vorgaben;
- System Engineering Prinzipien und Praktiken, insbesondere Methoden zur Anforderungsermittlung, Aufwandschätzung, Entwurf, Entwicklung, Verifikation und Validierung;
- Vor- und Nachteile agiler Vorgehen gegenüber plangetriebenen, linearen, oder iterativen Vorgehensmodellen;
- Entscheidungsgrundlagen zur Auswahl eines Vorgehensmodells;
- Anleitung zur Einführung agiler Prozessmodelle;
- Kulturelle und soziale Einflussfaktoren;
- Vorlagen, Arbeitsanweisungen oder Tools zur Umsetzung.
Agile Modelle, zum Beispiel Lean oder Kanban, die nicht auf dem agilen Manifest (Kapitel 22.32.3.1, S. 27) basieren, werden im Rahmen dieser Arbeit nicht weiter betrachtet.
2 Theoretischer Teil
Der theoretische Teil dieser Arbeit beginnt mit der Definition grundlegender Begriffe und Prozesse, die bei der Herstellung von Medizinprodukten zur Anwendung kommen. Nach der darauffolgenden Identifikation und Beschreibung der gesetzlichen Anforderungen werden ausgewählte agile Methoden und hybride Vorgehensmodelle erläutert. Abschliessend werden die agilen Methoden auf ihre Anwendbarkeit zur Herstellung von Medizinprodukten bewertet (Kapitel 22.4, S. 44) und bilden eine Basis für die Konstruktion des Referenzmodells.
2.1 Entwicklung von Medizinprodukten
Medizinprodukte werden in verschiedensten Gebieten eingesetzt und umfassen dadurch, im Vergleich zu Arzneimitteln, eine sehr heterogene Produktgruppe (BVMed, 2014). Die Definition eines Medizinproduktes ist in den U.S.A. im CFR, Title 21, Part 210 (h) (FDA, 2020) festgelegt. Die in der Verordnung für Medizinprodukte (Europäisches Parlament und der Rat der Europäischen Union, 2017) beschriebene Definition von Medizinprodukten (Definition 1, S. 11) entspricht im Wortlaut der Definition in den U.S.A. Auf eine Differenzierung der Definitionen wird daher im Rahmen dieser Arbeit verzichtet.
Definition 1 Medizinprodukt
«Instrumente, Apparate, Werkzeuge, Maschinen, Geräte, Implantate, Reagenzien für die in-vitro Anwendung, Software, Materialien oder andere gleichartige oder verwandte Gegenstände, die alleine oder in Kombination, vom Hersteller für die Anwendung für Menschen für einen oder mehrere der folgenden spezifischen medizinischen Zwecke bestimmt sind:
- Erkennung, Verhütung, Überwachung, Behandlung oder Linderung von Krankheiten;
- Erkennung, Überwachung, Behandlung, Linderung oder Kompensierung von Verletzungen;
- Untersuchung, Ersatz, Veränderung oder Unterstützung des anatomischen Aufbaus oder eines
- physiologischen Vorgangs;
- Lebenserhaltung oder Lebensunterstützung;
- Empfängnisregelung;
- Desinfektion von Medizinprodukten;
- Bereitstellung von Informationen mittels In-vitro-Untersuchung von aus dem menschlichen Körper stammenden Proben;
und deren bestimmungsgemäße Hauptwirkung weder durch pharmakologische oder immunologische Mittel noch metabolisch, im oder am menschlichen Körper, erreicht wird, deren vorgesehene Wirkungsweise aber durch solche Mittel unterstützt werden kann » (GHTF/SG1/N071:2012, 5.1 in DIN-Normenausschuss Medizin (NAMed), 2016, S. 14-15).
Die Entwicklung von Medizinprodukten, die ausschliesslich aus Software bestehen, unterscheidet sich vor allem im Herstellungsprozess. Instrumente, Apparate und Stoffe müssen unter Einsatz von Produktionsmaschinen hergestellt werden, Software kann nach der einmaligen Programmierung beliebig oft verteilt werden. Daher werden Medizinprodukte, die einzig aus Software bestehen, als Software as a Medical Device (SaMD) bezeichnet (Definition 2, S. 12).
Definition 2 Software as a Medical Device
«The term “Software as a Medical Device” (SaMD) is defined as software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device» (IMDRF SaMD Working Group, 2013, p. 6).
2.1.1 Klassifizierung
Wegen der vielfältigen Einsatzmöglichkeiten von Medizinprodukte und deren Einfluss auf die Patientensicherheit, erfolgt die Einteilung von Medizinprodukten in unterschiedliche Risikoklassen. Die Klassifizierung hängt dabei vom Gebrauchszweck des Medizinproduktes ab. Die zur Klassifikation anwendbaren Regeln sind in der MDR definiert und basieren auf der Anwendungsdauer, der Invasivität und der Aktivität des Medizinproduktes (Europäisches Parlament und der Rat der Europäischen Union, 2017, S. 123-139). Eine ähnliche Klassifizierung ist für die Inverkehrbringung von Medizingeräten in den U.S.A. erforderlich und in CFR 21 Part 8207 definierten. Die Risikoklassen der FDA entsprechen weitgehend der MDR Klassen, wobei die Klassen IVD und AIMD im CFR nicht separat ausgewiesen sind, sondern mit den Klassen I bis III abgedeckt sind. Beispielhaft werden daher in dieser Arbeit die derzeit gültigen Risikoklassen der Schweiz aufgeführt (Tabelle 4, S. 13).
Tabelle 4 Klassen von Medizinprodukten
Abbildung in dieser Leseprobe nicht enthalten
Quelle: (swissmedic - Schweizerisches Heilmittelinstitut, 2019)
Im Rahmen der für die Erstellung des Referenzmodells durchzuführenden Abstraktion der Informationselemente gehören der Prozess der Klassifizierung und die Unterteilung in unterschiedlich in Risikoklassen zu den Elementen, die bei der Modellierung zu berücksichtigen sind. Die Anzahl und Bezeichnungen der Klassen sind für das Referenzmodell dagegen erst bei der Ableitung unternehmensspezifischer Vorgehensmodelle relevant und werden im Verlauf der Arbeit nicht weiter betrachtet.
2.1.2 Technologie
Die unterschiedlichen Risikoklassen lassen bereits vermuten, dass verschiedenste Technologien und Wissensbereiche für die Entwicklung von Medizinprodukten erforderlich sind. Beispielhaft werden für die Entwicklung einer Bandscheibenprothese (Abbildung 4, S. 14) neben medizinischen Fachwissen auch Kompetenzen aus den Bereichen Metallurgie, Kunststofftechnik und Verfahrenstechnik benötigt.
Abbildung 4 Bandscheibenprothese aus Titan und Polyethylen
Abbildung in dieser Leseprobe nicht enthalten
Quelle: (Stöckli Medical, 2019)
Im Beispiel der Bandscheibenprothese besteht das Medizinprodukt ausschliesslich aus mechanischen Komponenten. Für komplexe, integrierte Systeme, im Beispiel ein Ultraschallsystem (Abbildung 4, S. 14), ist zusätzliches Fachwissen, unter anderem aus der Informatik, erforderlich.
Abbildung 5 Farb-Ultraschall System
Abbildung in dieser Leseprobe nicht enthalten
Que1.3 Produktlebenszyklus
Die Vorgaben zur Klassifizierung und die heterogene Produktpalette von Medizinprodukten lassen bereits vermuten, dass der Lebenszyklus von Medizinprodukten die Konfiguration von Risikoklassen und Produkttypen berücksichtigt. Ein Vorgehensmodell (Definition 3, S. 16), oder auch Prozessmodell, beschreibt das Vorgehen zum Entwickeln eines Produktes (Balzert, Lehrbuch der Softwaretechnik: Basiskonzepte und Requirements Engineering, 2009, S. 598).
Definition 3 Vorgehensmodell
“Framework of processes and activities concerned with the life cycle that may be organized into stages, which also acts as a common reference for communication and understanding” (IEEE 12207, 2008; IEEE 15288, 2008).
Die Existenz eines Vorgehensmodells ist «eine unvermeidbare Konsequenz, wenn die Entwicklung eines Systems geplant ist» (IEEE 15288, 2008, p. 11). Für die Entwicklung von Systemen wurden in den Jahren verschiedene Vorgehen entworfen und verbessert. Die dabei entwickelten Modelle unterscheiden sich in der Abfolge der Prozessschritte, die sequentiell, inkrementell, evolutionär oder in einer Kombination durchgeführt werden und verschiedene Vor- und Nachteile bieten (IEEE TR 24748, 2011, pp. 50-54).
Einigen Vorgehensmodellen wird das plangetriebene Vorgehen mit einer strikten Trennung der einzelnen Phasen als nachteilig zugeschrieben. Diese Annahme ist nur bedingt korrekt und der (linearen) Darstellung der Modelle geschuldet. Selbst das Wasserfallmodell und das V-Modell erlauben und empfehlen die Rückkopplung zwischen den jeweiligen Entwicklungsphasen (INCOSE, 2015, p. 32). Gemeinsam sind den Modellen für die Entwicklung von Systemen die Phasen Konzept, Entwicklung, Herstellung, Nutzung, Pflege und Ausserbetriebnahme (INCOSE, 2015, p. 28), welche zwar mit unterschiedlicher Terminologie beschrieben werden aber trotzdem das gleiche Ziel verfolgen. Die Entwicklungsphase von Systemen durchläuft nach Jenney (Jenney, et al., 2010, p. 77) die Aktivitäten Dekomposition, Definition, Integration und Verifikation. Der Lebenszyklus von Medizinprodukten (Abbildung 6, S. 16) beginnt mit der Ideenfindung und Entwicklung bis zur Marktkonformität und wird mit der Marktüberwachung und regelmässigen Auditierung abgeschlossen (BVMed - Bundesverband Medizintechnologie e.V., 1999-2020), (swissmedic - Schweizerisches Heilmittelinstitut, 2019).
Abbildung 6 Lebenszyklus eines Medizinproduktes
Abbildung in dieser Leseprobe nicht enthalten
Quelle: in Anlehnung an (BVMed - Bundesverband Medizintechnologie e.V., 1999-2020), (swissmedic - Schweizerisches Heilmittelinstitut, 2019)
Als Besonderheit zum klassischen Produktlebenszyklus werden in den jeweiligen Phasen neben den allgemeinen Produktentwicklungsaktivitäten (Abbildung 7, S. 17), wie der Ideenfindung, auch spezifische Aktivitäten für die Entwicklung von Medizinprodukten ausgeführt. Diese umfassen, wie in der Einleitung dieses Kapitels beschrieben, neben einer Risikoklassifizierung, klinischen Tests und der Erstellung einer Konformitätserklärung auch die Auditierung der Produktionsstätte und die Überwachung des Produktes im Markt (BVMed - Bundesverband Medizintechnologie e.V., 1999-2020).
Abbildung 7 Produktentwicklungsaktivitäten
Abbildung in dieser Leseprobe nicht enthalten
Quelle: in Anlehnung an (BVMed - Bundesverband Medizintechnologie e.V., 1999-2020)
2.1.4 Ressourcenbedarf
Eines der Prinzipien agiler Vorgehensmodelle ist ein Team, das konstant an der Entwicklung des Produktes arbeitet (Kapitel 2.3.1, S. 27). Folgt die Entwicklung eines Medizinproduktes einem Phasenmodell, so werden in jeder Entwicklungsphase unterschiedliche Qualifikationen benötigt (Abbildung 8, S. 19). Die Auswirkungen dieses ungleichmässigen Bedarf an Qualifikationen wird im Rahmen dieser Arbeit nicht behandelt, da sich nach den agilen Prinzipien (Kapitel 22.32.3.1, S. 27) das Entwicklungsteam selbst organisiert und daher angenommen wird, dass die Beschaffung des notwendigen Fachwissens im Rahmen der Entwicklungsarbeit stattfindet. Die Möglichkeiten zur Optimierung der Ressourcenauslastung im Zusammenhang mit den notwendigen Qualifikationen in wissensintensiven Projekten könnte jedoch in separaten Forschungsarbeit untersucht werden.
Abbildung 8 Ressourcenbedarf während der Entwicklung von Medizinprodukten
Abbildung in dieser Leseprobe nicht enthalten
Quelle: (Harer & Baumgartner, 2018, S. 130)
2.1.5 Auditierung der Produktionsstätte
Eine Besonderheit bei der Entwicklung von Medizinprodukten ist die Anforderung, dass die Herstellung einem dokumentierten und reproduzierbaren Prozess folgen muss. Das bedeutet, für jedes Endprodukt müssen die einzelnen Produktionsschritte nachvollziehbar sein, so dass unter Einsatz der gleichen Mittel ein ein identisches Produkt entsteht. Zur Dokumentation gehören dabei neben der Reihenfolge der ausgeführten Schritte auch die verwendeten Produktionsmaschinen, Materialien und die Bearbeitungsparameter und dient dem Nachweis, dass ein hergestelltes Produkt seiner Spezifikation entspricht (DIN-Normenausschuss Medizin (NAMed), 2016, S. 30). Um die Reproduktion der Herstellung zu garantieren, wird vor Beginn der Produktion die Betriebsstätte auditiert. Die Auditierung umfasst dabei die Qualifikation der Infrastruktur und die Validierung der Computersysteme, Prozesse, Methoden und Reinigungsverfahren (Harer & Baumgartner, 2018, S. 224).
Die Auditierung der Produktionsstätte wird im Rahmen dieser Arbeit nicht vollumfänglich berücksichtigt, da diese zum Produktionsprozess zugeordnet ist und vom Anwendungsbereich des Referenzmodells abgegrenzt wurde (Kapitel 44.2, S. 51). Ausnahme bildet die Entwicklung von Software, für welche mindestens der Build-Prozess einem dokumentierten Verfahren folgen und in einer validierten Umgebung stattfinden muss. Die Erstellung der Dokumentation zur Qualifizierung und Validierung wurde dagegen berücksichtigt und kann im Rahmen der Referenzmodellkonfiguration (Kapitel 77, S. 77) während der Entwicklung von Medizinprodukten erfolgen.
2.1.6 Gesetzliche Anforderungen
Ohne die Einhaltung der jeweils gültigen gesetzlichen Anforderungen an Medizinprodukte ist eine Inverkehrbringung des Produktes im Zielland nicht möglich. In diesem Kapitel werden die zur Entwicklung des Referenzmodells relevanten gesetzlichen Vorgaben zur Entwicklung von Medizinprodukten beschrieben.
Für die Mitgliedsstaaten der Europäischen Union ist die Verordnung 2017/745 über Medizinprodukte (Europäisches Parlament und der Rat der Europäischen Union, 2017) bindend. Die Anforderungen aus der Verordnung lassen auf die Beachtung der vier Aspekte
- Qualitätsmanagement;
- Risikomanagement;
- Software-Lebenszyklus;
- Nachweis der Gebrauchstauglichkeit;
reduzieren (Johner, Hölzer-Klüpfel, & Wittorf, 2011, S. 9).
Zusätzlich zur Verordnung über Medizinprodukte existieren existieren harmonisierte europäische Normen, die bei der Entwicklung von Medizinprodukten ebenfalls befolgt und deren Einhaltung nachgewiesen werden müssen. Die wesentlichen Normen umfassen nach Johner (Johner, Hölzer-Klüpfel, & Wittorf, 2011, S. 9, 26-30) und Harer (Harer & Baumgartner, 2018, S. 71) die:
- EN ISO 13485: Medizinprodukte – Qualitätsmanagementsysteme – Anforderungen für regulatorische Zwecke;
- EN ISO 14971: Medizinprodukte – Anwendung des Risikomanagements auf Medizinprodukte;
- EN IEC 62366: Medizinprodukte – Anwendung der Gebrauchstauglichkeit auf Medizinprodukte;
- EN IEC 62304: Medizingeräte – Software – Software-Lebenszyklus-Prozesse;
- EN ISO 14155: Klinische Prüfung von Medizinprodukten an Menschen – gute klinische Praxis;
- EN IEC 62366: Anwendung der Gebrauchstauglichkeit auf Medizinprodukte;
- EN IEC 60601-1-6: Medizinische elektrische Geräte – Teil 1-6: Allgemeine Festlegungen für die Sicherheit einschliesslich der wesentlichen Leistungsmerkmale – Ergänzungsnorm: Gebrauchstauglichkeit.
Für Medizinprodukte, die in den U.S.A. in Verkehr gebracht werden, ist die Food and Drug Administration (FDA) zuständig, welche die für Medizinprodukte relevanten Anforderungen im Rechtstitel 21 des Code of Federal Regulations (CFR), Unterkapitel H, definiert. Mit leichten Abweichungen in der Formulierung verfolgen die Vorgaben das gleiche Ziel, die Patientensicherheit von Medizinprodukten nachzuweisen und die Risiken ausreichend zu berücksichtigen. Bei der Konstruktion des Referenzmodells ist zu beachten, dass nicht alle Normen ihre Anwendung finden. Abhängig von der Produktklassifizierung müssen unterschiedliche Normen berücksichtigt werden. Für bestimmte Medizinprodukte, die ausschliesslich aus Software bestehen, oder für Implantate ohne elektronische Bauteile ist zum Beispiel die Anwendung der EN IEC 60601-1-6 nicht notwendig, da es sich nicht um ein elektrisches Gerät handelt.
2.1.7 Prozessanforderungen
Um die Anwendbarkeit des konstruierten Referenzmodells nachzuweisen, erfolgt eine Prüfung des Referenzmodells gegen die relevanten regulatorischen Anforderungen der EU (Europäisches Parlament und der Rat der Europäischen Union, 2017) und der U.S.A. (FDA 21 Part 820, 2020). Die jeweiligen gesetzlichen Anforderungen wurden gruppiert und lassen sich reduzieren auf Aktivitäten zur Bewertung von Risiken, der Prüfung und Freigabe von Dokumenten und der Nachweis der Gebrauchstauglichkeit (Anhang 66.1, S. 88). Die Gebrauchstauglichkeit wird im Rahmen des erforderlichen Qualitätsmanagementsystems nachgewiesen und schliesst mit der Ausstellung einer Konformitätserklärung ab.
Für die Ableitung des Referenzdatenmodells werden die im Rahmen des Qualitätsmanagementsystems erstellten Arbeitsergebnisse berücksichtigt. Die zu berücksichtigenden Arbeitsergebnisse aus den gesetzlichen Vorgaben (Kapitel 66.1, S. 88) umfassen dabei:
- Entwicklungspläne;
- Anforderungen an das zu entwickelnde Produkt, an zugelieferte Produkte, an Dienstleister, Lieferanten und Berater;
- Produktspezifikationen;
- Entwicklungs- und Testergebnisse;
- Validierte Produktionsprozesse und Automationsprozesse inklusive Kalibrierungen von Messwerkzeugen;
- Arbeitsvorschriften;
- Korrektive und präventive Massnahmen;
- Klinische Bewertungen;
- Technische Dokumentationen.
Ebenfalls zu den Arbeitsergebnissen gehören eine qualifizierte Infrastruktur, validierte Computersysteme und validierte Prozesse, sofern diese für die Entwicklung erforderlich sind. Dies ist zum Beispiel für die Herstellung von Software der Fall. Für die Referenzmodellierung bedeutet dies, die Aktivitäten zur Auditierung der Produktionsstätte müssen soweit abstrahiert werden, dass eine uneingeschränkte Anwendung des Modells für beide Geschäftsfälle, die Herstellung von Medizinprodukten und die Herstellung von Software as a Medical Device, möglich ist.
2.1.8 Rollen
Um ein Prozessmodell erstellen zu können, müssen die Rollen identifiziert werden, die am jeweiligen Prozess beteiligt sind. Die Entwicklung von Medizinprodukte benötigt umfangreiches Fachwissen aus verschiedenen Disziplinen. Das benötigte Wissen hängt dabei vom jeweiligen Produkt ab und kann Themen wie die Metallkunde, Medizintechnik, Pharmakologie, Hardwaretechnik und Softwaretechnik umfassen. Zusammenfassend werden für die Herstellung von Medizinprodukten neben den an der Entwicklung beteiligten Personen auch die nach den gesetzlichen Vorgaben erforderlichen Personenkategorien benötigt. Diese Personenkategorien umfassen Prüfungsteilnehmer, Prüfer, unabhängige Experten, unabhängige Prüfer der Mitgliedsstaaten (für die EU) und die benannten Stellen (Kapitel 66.1, S. 88).
2.2 Entwicklung von Systemen
Zum weiteren Verständnis der Entwicklung von Medizinprodukten sind in diesem Kapitel die historischen Herausforderungen komplexer Systementwicklungen zusammengefasst und leiten zur Beschreibung agiler Vorgehensmodelle über.
Bereits 1956 wurden Kriterien für die erfolgreiche Entwicklung von Computersystemen definiert (Benington, 1983). Dabei setzt Benington (Benington, 1983, p. 361) auf fundiertes Training der Mitarbeiter, empfiehlt die Durchführung von Tests durch ein unabhängiges Team, sieht die Notwendigkeit iterative Entwicklung, unterstützt das Lernen aus Fehlern, sieht die Notwendigkeit des gezielten Einsatzes von Werkzeugen zur Testautomatisierung und fordert eine nachvollziehbare Dokumentation von Fehlern. Entscheidender Erfolgsfaktor ist für Benington die Rolle des leitenden Ingenieures, der für alle Entwicklungsaktivitäten zuständig ist und deren Zusammenspiel verantwortet.
Die Beobachtungen von Benington (Benington, 1983) finden sich in aktuellen, agilen Modellen und dem agilen Manifest (Kapitel 22.32.3.1, S. 27) wieder. So vermutet Benington (Benington, 1983, p. 361) mögliche Kosteneinsparungen durch eine kontinuierliche, iterative Entwicklung. Selbständiges Handeln und Lernen und die Voraussetzung der richtigen Person am richtigen Ort finden sich auch in den Prinzipien der agilen Entwicklung wieder. Benington sieht es auch unrealistisch, ein System zu entwerfen, ohne zu wissen, wie es funktioniert. Damit wird indirekt die plangetriebene Entwicklung, bei der die Entwicklung nach Abschluss des Entwurfes durchgeführt wird, als nicht praktikabel bewertet. Weitere Massnahmen zur Verbesserung der Entwicklung sind nach Benington der Einsatz von Hilfsprogrammen für den Entwurf und die Entwicklung sowie eine eigenständige Qualitätssicherung. Im Unterschied zu den agilen Werten und Prinzipien, mit welchen ein funktionierendes Produkt einer umfangreichen Dokumentation vorgezogen wird und statt dessen die direkte Kommunikation bevorzugt wird, sieht Benington die Verfügbarkeit von Dokumentation als notwendig, da ein System von den unterschiedlichen Zielgruppen, von der Unternehmensführung zu Konstruktionsingenieuren über Programmierer, Tester, Benutzer und Wartungspersonal, verstanden werden muss (Benington, 1983, p. 361).
In seinem Erfahrungsbericht beschreibt Royce (Royce, 1987, p. 331) ebenfalls, dass Entwicklungsphasen nicht linear, sondern iterativ erfolgen müssen, um kostenintensive Anforderungs- oder Entwurfsänderungen zu vermeiden. Nach Royce (Royce, 1987, pp. 332-333) soll die Analyse für komplexe Projekte sorgfältig durchgeführt werden und er sieht die Notwendigkeit von Iterationen zwischen Anforderungen, Entwurf und Testung höher zwischen Analyse und Programmierung. Eine verständliche, informative und aktuelle Dokumentation vermeidet nach Royce Missverständnisse bei Entwicklung und Test und wirkt sich positiv auf die Wartungskosten aus. Royce sieht ebenfalls ein iteratives, mit dem Kunden durchgeführtes design review vor (Royce, 1987, p. 337). Analog zu Benington (Benington, 1983) sieht Royce (Royce, 1987, p. 331) es als notwendig, dass mindestens eine Person ein tiefes Verständnis des Systems hat und jedes Teammitglied mindestens ein elementares Verständnis hat. Wie später auch im agilen Manifest empfohlen, sieht Royce es als «important to involve the customer in a formal way» (Royce, 1987, p. 335). Damit lässt sich feststellen, dass die Elemente des agilen Manifests bereits vor der Definition des agilen Manifests bekannt waren. Die Frage, warum sich das von Royce bereits 1970 empfohlene Vorgehen nicht früher etabliert hat, ist nicht Bestandteil dieser Arbeit, könnte aber zu einer Forschungsarbeit leiten, bei der die Frage untersucht wird, warum selbst Projekte, die nach agilen Methoden durchgeführt werden, scheitern.
[...]
1 Agiles Vorgehensmodell zur Entwicklung, Auslieferung und Wartung komplexer Produkte (Schwaber & Sutherland, 2017)
2 Unter traditionellen Vorgehensmodellen werden plangetriebene, sequentielle Vorgehensmodelle verstanden. Beispiel: Wasserfallmodell, V-Modell
3 Englisch: Medical Device Regulation
4 Medizinprodukte – Qualitätsmanagementsysteme – Anforderungen für regulatorische Zwecke
5 Internationaler Standard: Medical device software – Software life cycle processes
6 http://rmk.iwi.uni-sb.de/
7 Medical Device Classification Procedures
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
¡Carge sus propios textos! Gane dinero y un iPhone X. -
¡Carge sus propios textos! Gane dinero y un iPhone X. -
¡Carge sus propios textos! Gane dinero y un iPhone X. -
¡Carge sus propios textos! Gane dinero y un iPhone X. -
¡Carge sus propios textos! Gane dinero y un iPhone X. -
¡Carge sus propios textos! Gane dinero y un iPhone X. -
¡Carge sus propios textos! Gane dinero y un iPhone X. -
¡Carge sus propios textos! Gane dinero y un iPhone X. -
¡Carge sus propios textos! Gane dinero y un iPhone X. -
¡Carge sus propios textos! Gane dinero y un iPhone X. -
¡Carge sus propios textos! Gane dinero y un iPhone X. -
¡Carge sus propios textos! Gane dinero y un iPhone X. -
¡Carge sus propios textos! Gane dinero y un iPhone X. -
¡Carge sus propios textos! Gane dinero y un iPhone X. -
¡Carge sus propios textos! Gane dinero y un iPhone X. -
¡Carge sus propios textos! Gane dinero y un iPhone X. -
¡Carge sus propios textos! Gane dinero y un iPhone X. -
¡Carge sus propios textos! Gane dinero y un iPhone X. -
¡Carge sus propios textos! Gane dinero y un iPhone X. -
¡Carge sus propios textos! Gane dinero y un iPhone X. -
¡Carge sus propios textos! Gane dinero y un iPhone X. -
¡Carge sus propios textos! Gane dinero y un iPhone X. -
¡Carge sus propios textos! Gane dinero y un iPhone X. -
¡Carge sus propios textos! Gane dinero y un iPhone X. -
¡Carge sus propios textos! Gane dinero y un iPhone X.