Projektmanagement für Systeme im regulatorischen Umfeld

Transkript

1 Projektmanagement für Systeme im regulatorischen Umfeld Agilität beherrscht Komplexität Dr. Oliver Schütz Thomas Reuner Mitglieder der Arbeitsgruppe APS der GfSE

2 PM für Systeme im regulatorischen Umfeld Agilität beherrscht Komplexität Motivation Komplexität Agilität Regularien Praxisbeispiel 2 Arbeitsgruppe APS der GfSE 2012

3 Motivation Warum sind relativ wenig Projekte erfolgreich? Projekt * ) erfolgreiches Projekt kritisches Projekt gescheitertes Projekt Je komplexer ein Projekt, desto größer die Gefahr des Scheiterns. *) betrachtet aus Sicht der Entwicklung, nicht des Marktes 3 Arbeitsgruppe APS der GfSE 2012

4 Warum scheitern Projekte? Motivation Komplexität Agilität Regularien Praxisbeispiel 4 Arbeitsgruppe APS der GfSE 2012

5 Komplexität Definition aus der Systemtheorie (1) Komplexität Statische Komplexität: Anzahl & Vielfalt der Objekte Anzahl & Vielfalt der Objekt-Verbindungen (nicht-lineare Interaktionen, Rückkopplungseffekte, ) Dynamische Komplexität: Objekte verändern sich. Verbindungen / Beziehungen verändern sich. Emergenz tritt auf. (neuronale Netzwerke, soziale Netzwerke, Wirtschaft, ) Diese Definition ist nicht ausreichend. 5 Arbeitsgruppe APS der GfSE 2012

6 Komplexität Definition (2) Komplexe Systeme/Situationen zeichnen sich dadurch aus, dass das Wissen, dass man über das System zu einem Zeitpunkt hat, unvollständig ist. Informationen sind im Überfluss vorhanden Informationen fehlen Die fünf Situationen des Nicht-Wissens Informationen sind unverständlich Informationen sind widersprüchlich Informationen sind nicht vertrauenswürdig 6 Arbeitsgruppe APS der GfSE 2012

7 Komplexität Warum steigt die Komplexität? Produkte Mehr Funktionalität Neue Technologien Höhere Qualität & Sicherheit Preisdruck Prozesse Verteilte Entwicklung (national & international) Gesetze und Normen Entwicklungsmethoden und -tools Entwicklungsressourcen (Zeit, Geld, Mitarbeiter) Firmenkultur Personen Mitarbeiter, Management, Stakeholder Persönliche Netzwerke Offizielle Firmenhierarchie, Organisation Konkurrenz, Leistungsdruck, offene Märkte 7 Arbeitsgruppe APS der GfSE 2012

8 Komplexität Produkt-Entwicklungsphasen erhöhen auch die Komplexität Komponente Spezifik. & Entwickl. Komponente Spezifik. & Entwickl. System Definition System Spezifikation Komponente Spezifik. & Entwickl. System Integr. & Test Komponente Spezifik. & Entwickl. Komponente Spezifik. & Entwickl. Produktdefinition Produktrealisierung 8 Arbeitsgruppe APS der GfSE 2012

9 Komplexität Fazit Komplexität muss betrachtet werden: auf allen P-Ebenen (Produkte-Prozesse-Personen) in allen Entwicklungsphasen Komplexität kann reduziert werden: Nicht-Wissen reduzieren. Destruktive Dynamik reduzieren Reaktionszeiten reduzieren. 9 Arbeitsgruppe APS der GfSE 2012

10 Warum und wie hilft Agilität Motivation Komplexität Agilität Regularien Praxisbeispiel 10 Arbeitsgruppe APS der GfSE 2012

11 Agilität Zusammenhang: Komplexitätsreduktion und agile Methoden Komplexitätsreduktion Nicht-Wissen reduzieren Destruktive Dynamik reduzieren Reaktionszeiten reduzieren Agile Methoden Regelmäßige Kurz-Meetings Team klärt offene Punkte Regelmäßiges Kundenfeedback Selbstorganisation Im Sprint keine Änderungen Präsentierbares Sprint-Ergebnis (Feedback) 11 Arbeitsgruppe APS der GfSE 2012

12 Agilität Agiles SW-Modell übertragen auf Systemprojekte Sprint Backlog Backlog Task Sprintzyklus Sprint Ergebnis Product Backlog Spezifikation, Realisierung und Test erfolgen pro Sprint. System Definition System Spezifikation System Entwicklung System Integr. & Test 12 Arbeitsgruppe APS der GfSE 2012

13 Agilität Fazit Agile Methoden reduzieren Komplexität. Agile Methoden reduzieren destruktive Dynamik. Je weniger Komplexität gegeben ist, desto weniger sind agile Vorgehen die erste Wahl. 13 Arbeitsgruppe APS der GfSE 2012

14 Verhindern MDD und FDA die Anwendung von agilen Methoden bei der Systementwicklung? Motivation Komplexität Agilität Regularien Praxisbeispiel 14 Arbeitsgruppe APS der GfSE 2012

15 Regularien Medizinprodukte im regulierten Umfeld von MDD und FDA Für die Entwicklung von Medizinprodukten sind verbindlich vorgeschrieben: ISO (Anforderungen für das QM-System für Medizinprodukte in Anlehnung an die ISO 9001 aber mit zusätzlichen Anforderungen für die Dokumentation und Unterschriften) MDD (Medical Device Directive) US CFR 820 (United States, Code of Federal Regulations) In diesen Dokumenten wird die Entwicklung von Medizinprodukten im jeweiligen Kapitel "Design Control" beschrieben und die Anforderungen festgelegt. Dazu gehören auch die Anforderungen zur Dokumentation. 15 Arbeitsgruppe APS der GfSE 2012

16 Regularien Verbindlichkeit der Interpretationen und Guidance Dokumente Alle Interpretationen und Guidance Dokumente sind verbindlich. Alle Vorschriften haben mindestens eine Interpretation, bei FDA sind es sogar deutlich mehr als eine. Begleitet werden diese Anforderungen jedoch mit den Erläuterungen und Interpretationen der FDA und der Notified Bodies: FDA: Fragen und Antworten zur QSR, FDA: Guidance für die Durchführung ihrer Audits zum Kapitel Design Control und der Notified Bodies: Interpretationen in den NB-Med s. Und nicht zu vergessen, die praktische Erfahrung in den Audits. Können wir überzeugend die korrekte Anwendung der Anforderungen in einem Audit nachweisen, MDD und FDA? 16 Arbeitsgruppe APS der GfSE 2012

17 Regularien Was sind die Regulatorischen Anforderungen? Das bei allen Behörden anerkannte Vorgehensmodell ist das V-Modell. Dieses deckt die Anforderungen der Behörden vollständig ab. Diese wesentlichen Punkte des V-Modells finden sich im agilen Modell wieder: Ist das Vorgehen geplant (Trennung der verschiedenen Phasen)? Ist das Vorgehen nachweisbar (Dokumentation in jeder einzelnen Phase)? Ist die jeweilige Aussage verbindlich (Freigabe jeder Phase)? Ist alles berücksichtigt und nichts vergessen (Traceability über die verschiedenen Phasen)? Fazit: Audits zeigen, dass agile Verfahren akzeptiert werden. 17 Arbeitsgruppe APS der GfSE 2012

18 Praxisbeispiel: Iterative und agile Integration von Systemen als ein möglicher Lösungsansatz Motivation Komplexität Agilität Regularien Praxisbeispiel 18 Arbeitsgruppe APS der GfSE 2012

19 Randbedingungen für das Praxisbeispiel Entwicklung im regulierten Umfeld der Medizintechnik. Nahezu komplette Neuentwicklung eines Röntgensystems Mechanik, embedded Sub-Systeme und Software Ca. 50 direkte Teammitglieder, davon ca. 50 % in der SW Entwicklung und ca. 50% in der HW Entwicklung und andere Themen. Einbindung vieler int. & ext. Zulieferer in der HW und SW. Ein großer Teil der SW Entwicklung arbeitet bereits agil. 19 Arbeitsgruppe APS der GfSE 2012

20 Die Komplexität in allen Bereichen muss beherrschbar sein Produkte Komplett neue Bildverarbeitung Neue HW und SW für die Systemsteuerung Neue, bisher nur prototypisch erprobte, Aufnahme von Bilddaten Prozesse Verteilte Entwicklung Agile SW-Entwicklung bei der Bildverarbeitung Andere Bereiche arbeiten nach Wasserfall Modell Personen Verteilte Verantwortlichkeiten und starke Subteams Kein echtes Systems Engineering aber eine hohe Bereitschaft im Kernteam für Veränderungen 20 Arbeitsgruppe APS der GfSE 2012

21 Iteratives agiles Projektmanagement im Produktentstehungsprozess (PEP) M1 M2 M3 M4 Produktdefinition Qualitätsrichtlinien QM aus regulatorischer Sicht Businessmanagement Markt & Wirtschaftlichkeit Produktentwicklung Meilensteine und Quality Gates als Entscheidungs- und Synchronisationspunkte im Projektablauf Requirements Engineering Systems Engineering Technik HW Entwicklung Prototyping / Pre IT s SW Entwicklung Integration Projektmanagement Projekt definieren, planen, kontrollieren und abschließen 21 Quelle: Pro F&E GmbH 2011 Arbeitsgruppe APS der GfSE 2012

22 Agilität Erweiterte Definition des Iterationsergebnisses Lauffähige, getestete, inkrementell verbesserte Software. gültig für Phase der SW-Realisierung Lauffähiges, getestetes, inkrementell verbessertes System. gültig für Phase der System-Realisierung Getestetes, inkrementell verbessertes System und Entwicklungsartefakte. gültig für alle Phasen der Systementwicklung (HW, SW, Dokumente, sonstige Artefakte) 22 Arbeitsgruppe APS der GfSE 2012

23 Systemintegration als iterativer Prozess Grundprinzipien des iterativen Vorgehens: Nach einer initialen Grobplanung, erfolgt die Verfeinerung der Planung und Realisierungsdetails mit einem Vorlauf von 2-3 Iterationen. Die Iteration schließt dokumentierte Tests auf der Subsystemebene ein. Alle Iterationen werden vom System-Integrations-Test Team begleitet und bewertet. Am Ende einer Iteration liegt ein den Stakeholdern präsentierbares Ergebnis vor. 23 Arbeitsgruppe APS der GfSE 2012

24 Iterationen werden nach gewissen Regeln aufgesetzt Es sind testbare Systemworkflows vorhanden Innerhalb der Iteration wurden Systemworkflows realisiert, die als Ganzes getestet werden können (White-Box-Testing, maximal Grey-Box-Testing) Es besteht erhöhtes Risikopotential bei der Umsetzung Das Risikopotential von geforderten oder notwendigen Funktionalitäten des Workflows für das Projekt ist hoch, so dass eine frühzeitige Erkennung von und Reaktion auf Projektrisiken notwendig ist. Es besteht ausreichend Reaktionszeit auf mögliche Veränderungen Der Termin der Iteration erlaubt generell ausreichend Reaktionszeit, falls größere Änderungen notwendig werden. Dies betrifft insbesondere Long-Leading-Items z.b. in der HW. Die Iteration endet synchron mit einem SW Sprint Hard- und Software-Zulieferungen sind abgestimmt und zugesichert. Eine System Iteration endet zu einem Vielfachen der Software Iteration. Das Ergebnis der Iteration ist präsentierbar Wenn möglich, ist das Ergebnis der Iteration Stakeholdern präsentierbar und kann zusammen zwischen Entwicklung / Test und Stakeholdern bewertet werden 24 Arbeitsgruppe APS der GfSE 2012

25 Komplexitätsreduktion bringt mehr Sicherheit bei der Einschätzung des Projektstatus Komplexitätsreduktion Nicht-Wissen reduzieren Destruktive Dynamik reduzieren Reaktionszeiten reduzieren Agil Zu jedem Integrationsschritt ist ein (in Teilen) funktionierendes Gesamtsystem vorhanden Spezifikationen werden sehr konkret basierend auf Ergebnissen verfeinert Testaktivitäten und Integration sind pro Schritt aufeinander abgestimmt. Stakeholder können sehr früh Feedback anhand von konkreten Arbeitsergebnissen geben 25 Arbeitsgruppe APS der GfSE 2012

26 Praxisbeispiel Fazit Ein agiles Vorgehen auf Systemebene ist während der Integrationsphase möglich. Das Wissen über den Stand der Systementwicklung ist für alle Projektbeteiligten deutlich erhöht. Risiken können frühzeitig erkannt und entsprechend reagiert werden. Eine Ausweitung des agilen Vorgehens auf weitere Projektphasen erscheint sinnvoll. 26 Arbeitsgruppe APS der GfSE 2012

27 PM für Systeme im regulatorischen Umfeld Agilität beherrscht Komplexität Projekte scheitern wegen ihrer Komplexität. Wesentliche Ursache von Komplexität ist Nicht-Wissen. Hauptfokus von agilen Verfahren ist Selbstorganisation und Wissensdefizite reduzieren. Agiles Projektmanagement im regulatorischen Umfeld ist erfolgreich umsetzbar. Agiles Projektmanagement bei der Systemintegration erlaubt es effizienter Risiken zu managen und Ergebnisse abzusichern. 27 Arbeitsgruppe APS der GfSE 2012

28 PM für Systeme im regulatorischen Umfeld Agilität beherrscht Komplexität Arbeitsgruppe APS der GfSE Oliver Schütz 1 oliver.schuetz@siemens.com Thomas Reuner 2 thomas.reuner@siemens.com Gerhard Buchholtz 3 gerhard.buchholtz@pro-f-und-e.de Jürgen Buckow 4 juergen.buckow@siemens.com Christian Denger 5 christian.denger@siemens.com Katja Landgraf 6 landgraf@slitisa.de Anton Rüttinger 7 anton.ruettinger@siemens.com Tim Weilkiens 8 tim.weilkiens@oose.de 1,2,4,5,7 Siemens AG, Healthcare Sector, Henkestrasse 127, Erlangen, Deutschland 3 Pro F&E GmbH, Im Heuschlag 26, Erlangen, Deutschland 6 Slitisa, Schwarzer Stock 8, Schlitz, Deutschland 8 oose Innovative Informatik GmbH, Straßenbahnring 7, Hamburg, Deutschland 28 Arbeitsgruppe APS der GfSE 2012