Normkonforme Medizinproduktentwicklung

Transkript

1 Agile Methoden in der Medizintechnik mit agilen Prozessen und Artefakten Marc Bless Version Mai 2012, Baden-Baden

2 Inhaltsverzeichnis Vorwort 4 Von der Norm zum Prozess: des Meta-Prozesses 7 Überblick der Prozesse und Artefakte 10 Prozesse, Meetings, Reviews 12 Acceptance Testing 13 Clean Code / SOLID Principles 14 Continuous Integration 16 Early Integration / Early Testing 17 Exploratory and Manual Testing 18 Integration Testing 19 Problem Communication 20 Product Backlog Grooming 21 Quality Management Prozess 23 Release Planning Meeting 24 Risk Analysis and Management 25 Scrum 27 Software Maintenance Process 28 Sprint Planning 29 Sprint Retrospective 31 Sprint Review 32 Team Kick-Off Meeting 34 Test Automation 35 Version 0.1 /

3 Test-Driven Design (TDD) 37 Unit Testing 39 Usability Process 40 Zero Bug Tolerance 41 Dokumente, Artefakte, Pläne 43 Architecture Documentation 44 Definition of Done 45 Definition of Ready 47 Iteration Notes 49 Linkable IDs 50 Product Backlog 51 Release Notes 53 Software Development Plan 54 Software Maintenance Plan 56 Sprint Development Plan = Sprint Backlog 57 Team Charter / Working Agreements 59 Test Documentation 61 User Story 62 Versioning System 64 Historie und Ausblick 66 Version 0.1 /

4 Vorwort Medizintechnik und die Entwicklung entsprechender Medizinprodukte befinden sich in einem regulierten Umfeld. Gesetze, Normen und Richtlinien geben mehr oder weniger harte Rahmenbedingungen vor, in deren Grenzen ein Medizinprodukt umgesetzt werden darf. Lange Entwicklungszeiten für Produktlebenszyklen sind wirtschaftlich heutzutage nicht mehr sinnvoll. Eine kurze Time-to-Market wird immer wichtiger, um den Marktbegleitern einen Schritt voraus zu sein und innovative Produktideen schnell als erster am Markt platzieren zu können. Der Kunde eines Medizinproduktes wird immer mündiger und entscheidet selbst über den Erfolg einzelner Produkte und Dienstleistungen. Dies erfordert bereits bei der Entstehung neuer Produktideen eine gewisse Nähe zum Anwender oder sogar die entwicklungsbegleitende Einbindung echter Anwender. In traditionellen Vorgehensweisen kann der Anwendungserfolg oft erst ganz am Ende des Prozesses ermittelt werden. Ein entsprechendes Reagieren auf Kunden und Anwender sowie deren wertvolles Feedback kann dann erst in einem nächsten Produkt, Projekt oder Release stattfinden und sich auswirken. Der Kunde bewertet ein Produkt nicht nur nach seinen Funktionen und der einfachen Handhabung, sondern auch nach seiner Qualität und Fehlerfreiheit. Dabei spielen oft schon Kleinigkeiten eine große Rolle, die zu einer negativen Bewertung eines Produktes führen können. In sozialen Netzwerken und Produktbewertungsportalen multiplizieren sich diese Effekte mittlerweile soweit, dass wir feststellen müssen: über Sieg oder Niederlage eines Produktes kann heute die breite Masse der Anwender entscheiden, unabhängig von Marketing- und Werbemaßnahmen. Der Einsatz agiler Management- und Entwicklungsmethoden liegt auf der Hand. Schnelle Entwicklungszyklen, Einbindung und Feedback echter Anwender, sowie höchste Qualitätsansprüche können durch agile Methoden nachhaltig realisiert werden. Des weiteren haben agile Methoden in den letzten Jahren ein breites Publikum erreicht und sind in aller Munde. Viele Versprechen, aber auch Missverständnisse kursieren bezüglich agiler Methoden: Scrum ist chaotisch. Jeder macht, was er will. Es wird nichts mehr dokumentiert. Scrum funktioniert nur bei kleinen Web-Projekten. Version 0.1 /

5 Agilität funktioniert nicht bei komplexen Medizintechnik-Projekten. Agile Methoden funktionieren in unserer Organisation nicht. Scrum ist die Lösung all unserer Probleme. Durch Agilität werden wir effizienter. Die IEC beschreibt einen konkreten Software-Life-Cycle-Prozess und muss eins-zueins umgesetzt werden. Wir müssen ein V-Modell einsetzen, um normkonform zu arbeiten. Die Kombination der agilen Welt und des regulierten Umfeldes der Medizinproduktentwicklung bereitet vielen Leuten Kopfzerbrechen und führt zu großer Unsicherheit. In dieser Unsicherheit lauert die Gefahr, agile Methoden in bestehende, normkonforme Prozesse zu pressen, ohne dass sich der Vorteil echter Agilität entfalten kann. Eine vereinfachte, beschränkte oder missverstandene Anwendung agiler Methoden kann dazu führen, dass das Scheitern eines Produktes oder Projektes eben diesen agilen Methoden zugerechnet wird: Agil haben wir schon probiert, das hat ja auch nicht funktioniert. Agil hat bei uns alles nur schlimmer gemacht. Scrum hat uns mit Problemen konfrontiert, die wir vorher gar nicht hatten. Können beide Welten effektiv nebeneinander existieren? Wie viel Agilität passt in die normativen Anforderungen? Welche agilen Praktiken eignen sich für einen regulierten Entwicklungsprozess? Die grundsätzliche Frage lautet: wie kann die Normkonformität agiler Prozesse und Methoden nachgewiesen werden? Dieses Dokument beschreibt den Prozess, mit dessen Hilfe die Anforderungen aus der IEC an den Software-Life-Cycle-Prozess zu konkreten agilen und traditionellen Praktiken transferiert wurden. Diese anwendbaren Praktiken werden im Detail beschrieben und können gesamtheitlich als reines Scrum betrachtet werden mit entsprechenden Erweiterungen, um die normativen Anforderungen an den Software-Life-Cycle abzubilden. Zukünftige Ausgaben dieses Dokumentes werden die Normen 14971, und e- benso einbinden und abgeleitete Praktiken beschreiben. Des weiteren ist die Einbindung von Praktiken geplant, welche einen agilen, FDA-konformen Entwicklungsprozess ermöglichen. Version 0.1 /

6 Das vorliegende Dokument beschreibt eine vollständige, IEC konforme Implementierung von Scrum als Projektmanagementmethode sowie agilen Entwicklungspraktiken aus dem Extreme Programming. Ich freue mich auf Fragen, Feedback und konstruktive Kritik der Leserschaft und bedanke mich vorab für das Interesse an der Thematik. Marc Bless Baden-Baden, Juni 2012 Version 0.1 /

7 Marc Bless Von der Norm zum Prozess: des Meta-Prozesses Um zu einem normkonformen Prozess zu gelangen, bin ich vorgegangen, wie im Folgenden beschrieben. Anforderungen an den Software-Life-Cycle-Prozess Zunächst habe ich die Struktur der IEC vollständig aufgebrochen. Aus den einzelnen Kapiteln, Sektionen und jedem darin enthaltenen Paragraphen habe ich die eigentlichen Anforderungen an einen Software-Life-Cycle-Prozess extrahiert. Abgeleitete Anforderungen: Der Prozess - Teil 1/2 IEC Kapitel & Sektionen Paragraphen Anforderungen Marc Bless Scrum und die IEC Wie soll das gehen? --- ScrumMed 2012, agile coach.de Die Struktur der Norm suggeriert einen sequentiellen Entwicklungsablauf, der einem agilen Ansatz im Wesen widerspricht. Gleichzeitig stecken in dieser Struktur viele redundante Anforderungen, die zu einem sequentiellen Ablauf eher orthogonalen Charakter haben, wie zum Beispiel das gesamte Thema Risikomanagement. agile coach.de Version 0.1 /

8 Aus diesem Grund ordnete ich die Anforderungen neuen Clustern zu, welche einzelne Entwicklungsthematiken inhaltlich abgeschlossen handhabbar machten. Eine für uns grundlegende Aussage der Norm lautet: agile Vorgehensweisen sind (erlaubt und) möglich. ( Jeder beliebige wasserfallartige, iterative oder evolutionäre Prozess kann verwendet werden. ) Dokumente und Prozesse Den Anforderungen in den Clustern wurden konkrete agile und klassische Praktiken und Artefakte zugeordnet. Die Zuordnungen einzelner Praktiken und Artefakte zu einzelnen Anforderungen habe ich so vollständig vorgenommen, dass die Gesamtmenge aller normativen Anforderungen vollständig erfüllt wird. Jede einzelne Zuordnung ist schriftlich begründet, um einen Nachweis der Anforderungserfüllung führen zu können. Das Ergebnis aller Praktiken und Artefakte mitsamt ihrer Begründungen findet sich im Hauptteil dieses Dokuments. Das wichtigste Prinzip für die Zuordnung von Praktiken und Artefakten ist Simplicity (Einfachheit) und bedeutet, die minimale, aber vollständige Befriedigung der normativen Anforderungen zu finden. Praktiken sind dabei im Wesentlichen Prozesse, Reviews, Meetings, Besprechungen und Workshops. Unter Artefakten verstehen wir sämtliche Dokumente, Ergebnisse, funktionierende Software, Pläne und en, welche im Entwicklungsverlauf entstehen und eine Rolle spielen. Nachweis der Normkonformität Der Nachweis der Normkonformität wird aus kopierrechtlichen Gründen nicht in diesem Dokument geführt. Da die Originalquellen und Anforderungen der Normen nicht bei den Zuordnungen der Praktiken und Artefakte beschrieben sind, mag es an manchen Stellen nicht offensichtlich sein, für welche Anforderung und aus welchem Grund eine bestimmte Praktik oder ein Artefakt Normkonformität herstellt. Der interessierte Leser darf sich gerne an den Autoren wenden, um mehr über das Thema Nachweis der Normkonformität zu erfahren. Grundsätzlich können zwei Anwendungsfälle unterschieden werden. Der Abgleich der normativen Anforderungen mit einem bestehenden (agilen oder klassischen) Life-Cycle-Prozess ist ein sehr aufwändiges, aber notwendiges Verfahren, um die Normkonformität des beste- Version 0.1 /

9 henden Prozesses nachzuweisen. Im Gegensatz dazu führt die Ableitung eines neuen, normkonformen Prozesses zu einer vollständigen Scrum-Umsetzung mit minimalem Tailoring. (Scrum steht hierbei nur für eine mögliche agile Referenzimplementierung, es können beliebige andere Vorgehensmodelle oder Prozessframeworks modelliert werden. Der in diesem Dokument vorgestellte Ansatz beschreibt eine vollständige Scrum-Implementierung.) Der Aufwand für diese Ableitung ist ebenfalls nicht unerheblich, wird jedoch durch die Gewissheit über die Normkonformität relativiert. Abgeleitete Anforderungen: Der Prozess - Teil 2/2 Anforderungen Dokumente Artefakte Prozesse Reviews Meetings Simplicity = Einfachheit: Minimale, aber vollständige Befriedigung der normativen Anforderungen Abgleich mit (bestehendem) Life-Cycle-Prozess Nachweis der Normkonformität Marc Bless Scrum und die IEC Wie soll das gehen? --- ScrumMed 2012, Abschließend lässt sich sagen: Scrum und die Norm IEC harmonieren perfekt miteinander, benötigen minimales Tailoring, widersprechen sich nicht und verfolgen ähnliche Zielsetzungen. Version 0.1 /

10 Überblick der Prozesse und Artefakte Das nachfolgende Diagramm zeigt den gesamten Überblick aller Prozesse und Artefakte, welche aus normativen und gewünschten agilen Gründen benötigt werden. Im folgenden Hauptteil dieses Dokumentes werden die einzelnen Praktiken und Artefakte im Detail beschrieben in jeweils eigenen Kapiteln. Die Struktur dieser einzelnen Kapitel ist folgendermaßen aufgebaut: - kurze Erklärung der Praktik oder des Artefaktes für das bessere Verständnis, welche Absicht dahintersteckt und welche Ergebnisse erwartet werden. - Liste der üblicherweise beteiligten Rollen für eine bessere Einschätzung, welche Rollen in einem bestehenden Unternehmenskontext für den Einsatz der Praktik oder des Artefaktes in Frage kommen. Die in diesem Dokument aufgeführten Rollen müssen nicht genau so übernommen werden, sie dienen eher dem Aufzeigen potentieller, sinnvoller Möglichkeiten. Version 0.1 /

11 - Liste von Büchern, Artikeln und Webseiten, welche sich mit der Praktik oder dem Artefakt detailliert auseinandersetzen. - Liste der direkt aus dem Normtext abgeleiteten Anforderungen an den Software-Life-Cycle-Prozess. Hinweis: aus Copyright-Gründen sind diese Listen mit Norminhalten nicht in diesem Dokument enthalten. - Durchzuführende Maßnahmen und Aktivitäten sowie Begründungen, weswegen die beschriebene Praktik oder das Artefakt zur Herstellung der Normkonformität benötigt wird. Version 0.1 /

12 Prozesse, Meetings, Reviews Version 0.1 /

13 Acceptance Testing Process Akzeptanz-Tests sind ein grundlegender Bestandteil von (agilen) Anforderungen. Durch ihre Einhaltung wird sichergestellt, dass (a) die gewünschten Anwenderbedürfnisse befriedigt werden, (b) die umgesetzte Funktionalität durch geprüfte Schnittstellen integriert werden kann und (c) die Anforderung als "fertig" (done) betrachtet werden kann. Product Owner Entwicklungs-Team Lisa Crispin - Agile Testing Mit Hilfe von definierten Akzeptanz-Tests wird sichergestellt, dass das erstellte Software- Produkt die Bedürfnisse der Anwender befriedigt und die Anforderungen korrekt umgesetzt wurden. Mit Hilfe von Akzeptanz-Tests wird sichergestellt, dass eine in Software umgesetzte Anforderung abgekapselt funktioniert und damit für eine Integration in andere Strukturen bereit ist. Durch Akzeptanztests wird sichergestellt, dass die entwickelte Software entsprechende Akzeptanzkriterien befriedigt. Akzeptanztests entsprechen Black-Box-Tests. Version 0.1 /

14 Clean Code / SOLID Principles Process Clean Code ist ein Wertesystem zur Professionalisierung der Software-Entwicklung. In ihm sind viele Good Practices und grundlegende Prinzipien enthalten, welche durch die Erfahrungen in den letzten Jahrzehnten als gültig und korrekt betrachtet werden können. Bekannter sind in erster Linie die fünf SOLID-Prinzipien: Single Responsibility Principle SRP Eine Klasse darf nur aus einem Grund geändert werden. Open Closed Principle OCP Eine Klasse muss offen sein für Erweiterungen, aber geschlossen gegen Modifikationen. Liskov Substitution Principle LSP Eine abgeleitete Klasse verhält sich immer so wie ihre Basisklasse. Interface Segregation Principle ISP Clients werden nicht mit Details versehen, die sie nicht benötigen. Dependency Inversion Principle DIP Klassen hoher Ebenen sollen nicht von Klassen niedriger Ebenen abhängig sein, sondern beide sollen von Interfaces/Abstraktionen abhängen. Interfaces sollen nicht von Details abhängen, sondern Details von Interfaces. Entwicklungs-Team Version 0.1 /

15 Robert C. Martin - Clean Code Durch die korrekte Anwendung objekt-orientierter Prinzipien wie "Separation of Concerns" und "Single Responsibility Principle" entstehen lose gekoppelte Architekturen. Durch die Anwendung objekt-orientierter Prinzipien wird die Aufteilung von Software-Einheiten in weitere Einheiten getrieben. Modernes Software-Engineering wird umgesetzt mit der Anwendung von Clean Code und SOLID-Prinzipien, TDD, Unit Tests, Design Patterns und vielen anderen Methoden, die hier nicht vollständig aufgeführt werden können. Version 0.1 /

16 Continuous Integration Process Kontinuierliche Integration beschreibt den Prozess des regelmäßigen, vollständigen Neubildens und Testens einer Anwendung. Jeder Entwickler checkt seine Änderungen früh und regelmäßig (mindestens täglich) in eine Versionsverwaltung ein. Von dort aus wird das gesamte System neu gebaut und automatisch getestet, damit die Entwickler schnellstmöglich auf vorhandene Fehler im System aufmerksam gemacht werden können. Entwicklungs-Team Konsequent angewandte Continuous Integration ist die Aktivität, durch welche eine frühzeitige Integration aller beteiligten Komponenten inklusive der dazugehörigen Integrationstests sichergestellt wird. Die einzelnen Software-Einheiten werden kontinuierlich integriert. Kontinuierliche Integration bedient sich eines Versionierungssystems, um jederzeit kleine Änderungen am System integrieren zu können. Kontinuierliche Integration benötigt eine funktionierende Test-Automatisierung, um ihren Nutzen entfalten zu können. Version 0.1 /

17 Early Integration / Early Testing Process Frühzeitige Integration und frühzeitiges Testen sind zum Einen Konzepte der kontinuierlichen Integration mit Test-Automation, zum Anderen können sie auch entwicklungsbegleitend manuell durchgeführt werden. Im Extremfall können Anforderungen vor ihrer eigentlichen Umsetzung bereits getestet werden (Test-First Development). Das darunterliegende Prinzip heißt "Schnelles Scheitern" (Fail Fast). Wir möchten so schnell wie möglich wissen, dass unser Vorhaben nicht erfolgreich sein kann. Entwicklungs-Team James Shore - The Art of Agile Development (Kapitel 13.2) Anforderungen können bereits vor ihrer endgültigen Umsetzung getestet und integriert werden. Frühe Integration bedient sich eines Versionierungssystems, um Änderungen am System sofort integrieren zu können. Version 0.1 /

18 Exploratory and Manual Testing Process Neben einer funktionierenden Test-Automation beschäftigen sich agile, entwicklungsbegleitende Tester mit explorativem und manuellem Testen des Systems. Entwicklungs-Team Lisa Crispin - Agile Testing Exploratives Testen entspricht Black-Box-Tests. Die benötigte Test Dokumentation wird mit den Ergebnissen der explorativen und manuellen Tests angereichert. Version 0.1 /

19 Integration Testing Process Integrations-Tests stellen sicher, dass sich die einzelnen Teile eines entwickelten System miteinander verbinden lassen und ein funktionierendes Ganzes entsteht. Entwicklungs-Team Lisa Crispin - Agile Testing Integrations-Tests entsprechen Black-Box-Tests bezüglich der Schnittstellen einzelner Systemkomponenten und White-Box-Tests bezüglich der System-Architektur. Die Software-Integration wird durch Integrationstests verifiziert. Die integrierten Software-Einheiten werden durch Integrationstests verifiziert. Durch Test- Automation kann eine Dokumentation der Testergebnisse erzeugt werden. Integrations- sowie System-Tests können mit Simulationen, Prototypen und Mocks durchgeführt werden. Version 0.1 /

20 Problem Communication Process Ein Problem-Kommunikationsprozeß wird dafür eingesetzt, Stakeholder, Anwender, Kunden und allgemein alle am Produkt interessierten Personen darüber zu informieren, welche Fehler und Probleme sich in dem Produkt befinden und behoben bzw. nicht länger benutzt werden sollten. Product Owner keine Probleme und deren Konsequenzen werden über einen "Problem Communication"-Prozeß an Anwender kommuniziert. Einzubindende Stakeholder werden durch einen "Problem Communication"-Prozeß über die Existenz eines Problems informiert. Version 0.1 /

21 Product Backlog Grooming Process Im Product Backlog Grooming Meeting wird von Product Owner und Team bewertet, welche Änderungen sich am Produkt durch Anforderungen (z.b. Änderungsanträge und User Stories) ergeben. Die Entscheidung darüber, welche Anforderungen umgesetzt werden sollen, liegt einzig und alleine beim Product Owner. Product Owner Entwicklungs-Team Scrum Master Im Product Backlog Grooming Meeting werden bestehende Anforderungen und User Stories im Product Backlog neu bewertet und aktualisiert. Der Product Owner läßt im Product Backlog Grooming Meeting neue und geänderte Anforderungen vom Team bewerten und erteilt deren Freigabe durch Aufnahme und Einsortierung in sein Product Backlog. Im Product Backlog Grooming Meeting werden neue und geänderte Anforderungen auf ihren Einfluß auf bestehende Produkte und Systeme untersucht. Version 0.1 /

22 Im Product Backlog Grooming Meeting durchlaufen neue und geänderte Anforderungen den Risikomanagement-Prozess, um neue Risiko-Maßnahmen abzuleiten. Im Product Backlog Grooming Meeting durchlaufen neue und geänderte Anforderungen den Risikomanagement-Prozess, um sie mit bestehenden Risiko-Maßnahmen abzugleichen. Im Product Backlog Grooming Meeting werden Fehler- und Problem-Berichte bewertet und ihr Einfluß auf die Sicherheit bestehender Produkte und Systeme festgestellt, um notwendige Anforderungsänderungen im Product Backlog abzuleiten. Im Product Backlog Grooming werden notwendige Änderungen am System diskutiert und für die Entwicklung freigegeben. Im Product Backlog Grooming werden Probleme und Fehler von bereits releaster Software besprochen. Im Product Backlog Grooming werden die Funktionalitäten und Performance-Anforderungen an einzusetzende SOUP-Komponenten definiert. Im Product Backlog Grooming werden Änderungen an der Software analysiert, bewertet und ins Product Backlog einsortiert. Damit durchlaufen Änderungen den gleichen Entwicklungsprozeß wie Anforderungen und User Stories. Im Backlog Grooming werden die Anforderungen an Hardware und Software identifiziert, welche durch den Einsatz von SOUP notwendig werden. Im Product Backlog Grooming wird das Product Backlog kontinuierlich überarbeitet und angepasst. Im Product Backlog Grooming werden User Stories erstellt, verfeinert, abgeschätzt, verworfen und in einzelne User Stories aufgesplittet. Version 0.1 /

23 Quality Management Prozess Process Ein zertifiziertes Qualitätsmanagementsystem (z.b. nach ISO 13485) für medizinische Produkte wird dafür genutzt, die Normkonformität für Medizinproduktentwicklungen nachzuweisen und damit deren Marktfreigabe zu erwirken. Qualitätsmanager Scrum Master ISO Ein Qualitäts-Management-Prozess ist definiert und wird eingesetzt. Version 0.1 /

24 Release Planning Meeting Process Im Release Planning wird regelmäßig darüber entschieden, welcher Inhalt/Scope in die Produktentwicklung einfließen soll und welche Zeiträume und Meilensteine sich daraus ergeben. Product Owner Entwicklungs-Team Im Release Planning findet die Vorbewertung und Priorisierung statt für Probleme und Fehler von bereits releaster Software. Das Release Planning unterscheidet nicht, ob ein Release aus neuen Anforderungen besteht oder aus Änderungen an einem bestehenden System. Im Release Planning wird festgelegt, ob ein Release als vollständiges System-Release erstellt wird oder als Patch zu einem bestehenden System-Release. Im Release Planning wird entschieden, welche Maßnahmen und Aktivitäten durchzuführen sind, um eine verläßliche Auslieferung der Software zu gewährleisten. Im Release Planning wird das Product Backlog initial erstellt bzw. in späteren Release Planning Meetings kontinuierlich überarbeitet und angepasst. Version 0.1 /

25 Risk Analysis and Management Process In einem Risiko-Management-Prozeß werden Gefährdungen für Menschen und Umwelt durch Gebrauch eines Medizinproduktes analysiert, bewertet, durch Maßnahmen reduziert und entsprechend kontrolliert. Der Risiko-Management-Prozeß findet während aller Entwicklungsaktivitäten und -phasen statt. Qualitätsmanager Product Owner Entwicklungs-Team Scrum Master ISO Im Sprint Planning Meeting wird sichergestellt, dass alle Maßnahmen aus der Risiko-Analyse einer in diesem Sprint geplanten Anforderung in das Product Backlog als Anforderung einfließen. Im Sprint Planning Meeting wird sichergestellt, dass alle Maßnahmen aus der Risiko-Analyse einer in diesem Sprint geplanten Anforderung in das Product Backlog als Anforderung einfließen. Version 0.1 /

26 Im Sprint Planning Meeting durchlaufen alle Anforderungen eine Risiko-Analyse, um notwendige Maßnahmen abzuleiten. In der Risiko-Analyse während des Sprint Planning Meetings werden alle Anforderungen auf möglichen Mißbrauch untersucht und entsprechende Maßnahmen abgeleitet. Notwendige Änderungen an der Software, die durch System-Tests erkannt werden, durchlaufen während des Sprint Plannings die notwendige Risikoanalyse. Im Sprint Planning Meeting werden Probleme und Fehler auf sicherheitsrelevante Aspekte mit Hilfe der Risikoanalyse untersucht. Die Sicherheitsklassifizierung wird im Sprint Planning für alle umzusetzenden Software-Einheiten überdacht und gegebenenfalls neu vergeben. Im Sprint Planning werden die Architektur und die Software-Einheiten der umzusetzenden Anforderungen definiert. Die identifizierten Software-Einheiten durchlaufen die Risiko-Analyse. Im Sprint Planning wird die Risiko-Analyse der umzusetzenden Architektur und ihrer Software-Einheiten durchgeführt. Im Sprint Planning werden für fehlerhaftes Verhalten der Software mögliche Ursachen in Hardware- und Software-Fehlern analysiert Im Sprint Planning werden User Stories daraufhin untersucht, ob sie zu einer Gefahrensituation beitragen können, die in der Risiko-Analyse enthalten ist. Im Sprint Planning werden die umzusetzenden Anforderungen und deren abgeleitete Software-Einheiten durch die Risiko-Analyse auf mögliche Gefährdungen hin untersucht. Im Sprint Planning werden Workflows und sequentielle Abfolgen von Events in der Software durch die Risiko-Analyse auf Gefahrensituationen untersucht. Im Sprint Planning werden die umzusetzenden Software-Einheiten durch die Risiko-Analyse auf Gefahrensituationen untersucht. Im Sprint Planning wird der zu erstellenden Software-Einheit eine Sicherheitsklassifizierung zugewiesen (A, B, C), welche weitere Details im Entwicklungsprozess bestimmt. Im Sprint Planning werden zu jeder Software-Einheit mit möglichen Gefahrensituationen entsprechende Maßnahmen identifiziert und festgehalten. Im Sprint Planning werden mögliche Ursachen für Fehlverhalten von SOUP durch die Risiko- Analyse identifiziert. Im Sprint Planning werden SOUPs und ihre bekannten Fehler/Abweichungen durch die Risiko-Analyse betrachtet. Risiko-Management wird in erster Linie im Sprint Planning durchgeführt. Risiko-Management wird im Sprint Planning Meeting durchgeführt. Im Sprint Planning wird jeder Anforderung und User Story (auf jeder Ebene) eine Sicherheitsklassifizierung zugeordnet durch die Anwendung der Risiko-Analyse. Version 0.1 /

27 Scrum Process Scrum ist ein Management-Framework für die empirische Prozeßkontrolle. Product Owner Entwicklungs-Team Scrum Master Ken Schwaber - Agiles Projektmanagement mit Scrum Roman Pichler - Scrum Scrum ist ein gültiges Prozeß-Framework für den Software-Life-Cycle. Version 0.1 /

28 Software Maintenance Process Process Der Software Maintenance-Prozess (Software Wartungsprozeß) beschreibt alle Aktivitäten, die für die Änderung von sich im Markt befindlichen Medizinprodukten notwendig sind. Dazu gehört das Einholen und Bewerten von Anwender-Feedback sowie ein installierter Fehlerbehebungsprozeß. Product Owner Entwicklungs-Team f-8982fc416138/entry/march_10_2012_11_27_am8?lang=en Über den Software Maintenance Prozeß erfolgt das Einholen des Feedbacks zu releaster Software innerhalb der eigenen Organisation. Über den Software Maintenance Prozeß erfolgt das Einholen des Feedbacks zu releaster Software von tatsächlichen Anwendern. Version 0.1 /

29 Sprint Planning Process Im Sprint Planning Meeting einigen sich der Product Owner und das Team auf ein Sprint-Ziel und das dafür umzusetzende Sprint Backlog. Im zweiten Teil des Sprint Plannings werden vom Team konkrete Architektur- und Umsetzungsaufgaben identifiziert und geplant. Product Owner Entwicklungs-Team Scrum Master Im Sprint Planning Meeting wird vom Team festgestellt, ob sich Anforderungen im Product Backlog widersprechen. Im Sprint Planning Meeting wird sichergestellt, dass über die Anforderungen ein einheitliches Verständnis bei allen Beteiligten herrscht. Im Sprint Planning Meeting wird sichergestellt, dass zu jeder Anforderung Akzeptanz-Kriterien für die Integration in andere Strukturen erstellt werden. Im Sprint Planning Meeting werden bestehende Anforderungen und User Stories im Product Backlog neu bewertet und aktualisiert. Version 0.1 /

30 Spätestens im Sprint Planning Meeting werden Anforderungen auf ihre korrekte und vollständige Definition geprüft. Im Sprint Planning Meeting werden vom Team alle Tasks identifiziert, welche für die Umsetzung einer Änderung (erneut) durchgeführt werden müssen. Im Sprint Planning erfolgt die Planung der Integrations-Tests sowie der System-Tests. Im Sprint Planning finden die notwendigen Risiko-Analysen sowie die Umsetzungsplanung statt für Probleme und Fehler von bereits releaster Software. Im Sprint Planning werden die Fehler- und Problemberichte analysiert. Im Sprint Planning werden für benötigte SOUP-Komponenten die Funktionalitäten und Performance-Anforderungen festgelegt. Im Sprint Planning werden die umzusetzenden Anforderungen in eine Architektur überführt und diese wiederum in Software-Einheiten runtergebrochen. Im Sprint Planning werden die Architektur und die Schnittstellen der umzusetzenden Software-Einheiten sowie der einzubindenden externen Software-Einheiten festgelegt. Die grundlegenden Software-Strukturen und Architektur-Entscheidungen können im Sprint Planning getroffen werden. Im Sprint Planning werden Software-Einheiten, die eine Risiko-Maßnahme umsetzen, genauso behandelt wie alle anderen Anforderungen und befolgen den definierten Entwicklungsprozeß. Im Sprint Planning Meeting wird das Sprint Backlog bzw. der Sprint Development Plan festgelegt. Im Sprint Planning werden die Iteration Notes (Sprint Notizen) angefangen. Im Sprint Planning Meeting wird in der zweiten Phase (Sprint Planning 2) die Architektur der umzusetzenden Anforderungen besprochen, skizziert und festgehalten. Version 0.1 /

31 Sprint Retrospective Process In der Sprint Retrospektive hat das Team die Möglichkeit, Verbesserungsmaßnahmen für die eigenen Prozesse und Strukturen zu identifizieren und zu beschließen. Product Owner Entwicklungs-Team Scrum Master Norman Kerth - Project Retrospectives Esther Derby, Diana Larsen - Agile Retrospectives Der Team Charter und die Working Agreements können vom Team im Sprint Retrospective Meeting an veränderte Situationen und gegebene Notwendigkeiten angepasst werden. Die Definition-of-Ready kann vom Team im Sprint Retrospective Meeting an veränderte Situationen und gegebene Notwendigkeiten angepasst werden. Die Definition-of-Done kann vom Team im Sprint Retrospective Meeting an veränderte Situationen und gegebene Notwendigkeiten angepasst werden. Der Software Development Plan kann vom Team im Sprint Retrospective Meeting an veränderte Situationen und gegebene Notwendigkeiten angepasst werden. Version 0.1 /