MST013 – Regulatory: Prozesse IEC 62304

MP3 Audio [27 MB]MPEG-4 AAC Audio [20 MB]Ogg Vorbis Audio [22 MB]Ogg Vorbis Audio [22 MB]Opus Audio [12 MB]Opus Audio [12 MB]DownloadShow URL

Rückblick

• 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

Prozesse der IEC 62304

1. Software Entwicklungsprozess
2. Software Wartungsprozess
3. Software Risikomangement Prozess
4. Software Problemlösungsprozess
5. Software Konfigurationsmanagement Prozess

Software Entwicklungsprozess – Planung

Erste Teilaktivität des Software Entwicklungsprozesses

Planung – Allgemein

Aktivität: Planung der Softwareentwicklung

Output: Software Entwicklungsplan

1. Rollen und Verantwortlichkeiten
2. Software Entwicklungsmodell
   • Projektphasen
     • Outputs in den Phasen
     • Review-Kriterien der Outputs
3. Verweis auf weitere Prozesse der IEC 62304
4. Software Entwicklungsprozess im Projekt
   • Allgemein
     • Tooling
       • Compiler, Interpreter, Entwicklungsumgebung, Versionskontrollsystem…
     • Coding Guidelines
5. Planung der Software Anforderungen
6. Planung der Software Architektur und des Detail Design
7. Planung der Implementierung
8. Planung der Software Unit Verifikation
9. Planung der Software Integration
10. Planung der Software System Verifikation
11. Planung des Software Release

Planung – Softwareanforderungen

1. Wo werden die Softwareanforderungen erfasst?
   • Word, Excel, IBM Doors, Redmine, Polarion, OpenProject, CodeBeamer, HelixALM, JIRA, Greenlight guru GO, …
2. Evtl. Satzschablonen verwenden
   • Use Cases oder “Requirement-Schablone” (shall, should, may)
3. Sicherstellen der Traceability
   • von den Systemanforderungen zur Architektur und Verifikation
4. Festlegen des zu unterstützendes Betriebssystems
5. Festlegen der zu unterstützende Hardware
6. Sicherstellen der Verifizierbarkeit
7. Sicherstellen, dass die Softwareanforderungen widerspruchsfrei und vollständig sind
   • Review und Freigabeprozess
8. Granularitär / Detailierungsgrad der Anforderungen festlegen
9. Wertebereiche, Datentypen und Reaktionen des Systems (auch bei Fehleingaben)
10. Schnittstellen zu anderen Systemen
    • Reaktionszeiten
    • Interoperabilität
    • Datenvolumen und Last auf dem System

Planung – Architektur und Detailliertes Design

1. Wo wird die Software Architektur erfasst?
2. Definition Software-System, -Item und -Unit
3. Beschreiben was für Software Item und Units dokumentiert werden muss
   • Static View
   • Dynamic View
   • Interfaces

Planung – Implementierung

1. Commit Workflows
2. Anwendung der Tools

Planung – Software Unit Verifikation

1. Planung der Verifikation der Schnittstellen von Software-Unit
   • Statische Code-Analyse
   • Code Reviews
   • Dynamische Analyse
2. Beschreiben in welchem System die Software Units verifiziert wird
3. Akzeptanzkriterien festlegen (beim Verhalten der Schnittstellen)
4. Testabdeckung festlegen

Planung – Software Integration

1. Integration Strategy (Top-down, bottom-up, …)
2. Beschreiben in welchem System die Integration und Integrationstest durchgeführt wird
3. Festlegen was in den Testplan und -Bericht kommt
4. Akzeptanzkriterien festlegen
   • Zuverlässigkeit und Robustheit
   • Performance
   • Kompatibilität und Wartbarkeit
5. Festlegen wie Anomalien in den Problemlösungs-Prozess einfließen

Planung – Software System Verifikation

1. Beschreiben in welchem System die Software System Verifikation durchgeführt wird
2. Sicherstellen, dass alle Software-Anforderungen verifiziert werden
3. Festlegen was in den Testplan und -Bericht kommt
4. Akzeptanzkriterien festlegen
5. Festlegen wie Anomalien in den Problemlösungs-Prozess einfließen

Planung – Software Release

1. Beschreiben in welchem System das Software Release durchgeführt wird
2. Festlegen wo die Software-Releases abgelegt werden
3. Festlegen wo offenen Anomalien und Bugs dokumentiert und bewertet werden
4. Schema der Software-Versionsnummern festlegen
5. Sicherstellen, dass alle zuvor genannten Aktivitäten durchgeführt wurden
   • Mittels Checkliste durch die technische Dokumentation gehen und Review durchführen

Allgemeine Software Entwicklungsmodelle

Vorgehensmodelle

• Es gibt keine Vorgabe in der Norm IEC 62304
• Forderung: Betrachtung der Abhängigkeiten zwischen den Aktivitäten
  • Erst die Anforderungen und die Software Archtektur abschließen, dann die Risikoanalyse abschließen.
• Mehrere Vorgehensmodell sind denkbar.
• Die IEC 62304 zählt u.a Wasserfallmodell, iterativ-inkrementell, evolutionär etc. auf.
• Entwicklungsmodelle können textuell oder als Flowchart beschrieben werden.

Wasserfallmodell

• Alle Entwicklungsschritte des Wasserfallmodells werden nacheinander durchgeführt.
• Phasenbasiert, erst eine Phase abschließen, dann Beginn der nächsten Phase
• Review der Ergebnisse zwischen den Phasen
• Vorteile
  • Einfach.
  • Phasenabschlüsse geben Sicherheit über den Projektfortschritt.
  • Klare Abschätzung von Kosten und Umfang bei stabilen Anforderungen.
• Nachteile
  • Fehler werden meistens erst spät entdeckt.
  • Wiederholung von Phasen im Fehlerfall.
  • Unflexibel gegenüber Änderungen im Projekt.

V-Modell

• Weiterentwicklung des Wasserfallmodells
  • Jetzt: Jede Phase hat eine gegenüberliegende Testphase
• Vorteile
  • Testaspekte können früher betrachtet werden.
  • Fehler in der Spezifikation oder im Design können früher gefunden werden.
  • Durch Berücksichtigung von Testaspekten ist die Dokumentation besser.
• Nachteile
  • Implementierungsfehler werden erst beim Testen entdeckt, meistens sehr spät.
  • Auch hier: Im Fehlerfall müssen Phasen wiederholt werden, was sehr zeitaufwändig ist.

Iterativ-inkrementelle Modelle

• Iterativ: Einzelne Phasen werden direkt durchlaufen
• Inkrementell: Pro Durchlauf wird der Funktionsumfang erweitert
• Fehler, die am Ende jedes Phasendurchlaufs entdeckt werden, werden im nächsten Durchlauf behoben.

Agiles Entwicklungsmodell

• Die Basis agiler Softwareentwicklung ist das iterativ-inkrementelle Modell.
• Ziel ist es, bürokratische Strukturen abzubauen und den Fokus auf die kundennahe Entwicklung zu richten.
• Weitverbreitet ist dabei Scrum.
• Mit der IEC 62304 ist dieses Modell zwar vereinbar, wird allerdings noch etwas zögerlich eingesetzt, da die Norm sehr V-Modell-artig aufgebaut ist. Viele schrecken vor der Kombination aus agiler Welt und V-Modell-Welt noch zurück.

Quellen

SW Entwicklungsplanung:

• IEC 62304:2015

SW Entwicklungsmodelle:

• https://de.wikipedia.org/wiki/Wasserfallmodell
• https://de.wikipedia.org/wiki/V-Modell
• https://de.wikipedia.org/wiki/Inkrementelles_Vorgehensmodell
• https://de.wikipedia.org/wiki/Scrum
• SW Entwicklung für Medizinprodukte – SW-Lebenszyklus-Prozesse; Prof. Dr. Michael Munz, HS Ulm