04205 Modellbasierte Tests
Die grafische Darstellung von Anforderungen
|
Durch den Umstieg auf agile Methoden hat sich der Umgang mit Anforderungen grundlegend verändert. User Stories und deren Akzeptanzkriterien ersetzen vorab spezifizierte Anforderungen, die nun meist inkrementell im Verlauf des Projekts erarbeitet werden. Dadurch droht jedoch der Überblick über das große Ganze verloren zu gehen. Hier hilft die grafische Darstellung von Zusammenhängen und Abläufen. Sie bildet die Grundlage für einen agilen System- und Abnahmetest und ergänzt andere agile Methoden wie Behavior-Driven Development.
Neben der Darstellung der konkreten Vorgehensweise werden auch praktische Tipps zur Methode und zu möglichen Werkzeugen gegeben. Arbeitshilfen: von: |
1 Medizintechnik im Wandel
Produktentwicklung in der Medizintechnik ist an sich schon eine große Herausforderung, da es sich um ein zunehmend stärker reguliertes Umfeld handelt. Erschwerend kommt hinzu, dass die Produkte immer komplexer werden. Doch was macht eigentlich die Komplexität eines Produkts aus und warum steigt sie in letzter Zeit derartig an?
Digitalisierung
Dafür gibt es vielfältige Gründe. Einerseits erleben wir eine zunehmende Digitalisierung sowohl der medizinischen Abläufe als auch der Medizinprodukte selbst. Dadurch und durch die zunehmende Vernetzung steigt der Anteil an Software im System. Deep-Learning-Systeme benötigen Zugriff auf die Cloud. Selbst für Medikamente gibt es inzwischen therapiebegleitende Apps. Spätestens jetzt haben wir es mit unterschiedlichen Endgeräten zu tun, die mit verschiedenen Betriebssystemen bzw. Betriebssystemversionen arbeiten.
Dafür gibt es vielfältige Gründe. Einerseits erleben wir eine zunehmende Digitalisierung sowohl der medizinischen Abläufe als auch der Medizinprodukte selbst. Dadurch und durch die zunehmende Vernetzung steigt der Anteil an Software im System. Deep-Learning-Systeme benötigen Zugriff auf die Cloud. Selbst für Medikamente gibt es inzwischen therapiebegleitende Apps. Spätestens jetzt haben wir es mit unterschiedlichen Endgeräten zu tun, die mit verschiedenen Betriebssystemen bzw. Betriebssystemversionen arbeiten.
Produktfamilien
Darüber hinaus steigt die Anzahl der Teilkomponenten vieler Produkte rasant an. Die zu entwickelnden Systeme werden tendenziell immer größer und bilden immer umfangreichere Arbeitsabläufe ab. Mehrstufige Hierarchien kommen zum Einsatz, wobei nicht alle Komponenten überall eingesetzt werden. Auf diese Weise entstehen Produktfamilien wie z. B. bildgebende Systeme, die entsprechend den Bedürfnissen (und finanziellen Mitteln) der Kliniken in unterschiedlichen Ausprägungen hergestellt werden. Die ISO 13485:2016 trägt dieser Entwicklung Rechnung und definiert einen neuen Begriff: die „Medizinproduktefamilie”.
Darüber hinaus steigt die Anzahl der Teilkomponenten vieler Produkte rasant an. Die zu entwickelnden Systeme werden tendenziell immer größer und bilden immer umfangreichere Arbeitsabläufe ab. Mehrstufige Hierarchien kommen zum Einsatz, wobei nicht alle Komponenten überall eingesetzt werden. Auf diese Weise entstehen Produktfamilien wie z. B. bildgebende Systeme, die entsprechend den Bedürfnissen (und finanziellen Mitteln) der Kliniken in unterschiedlichen Ausprägungen hergestellt werden. Die ISO 13485:2016 trägt dieser Entwicklung Rechnung und definiert einen neuen Begriff: die „Medizinproduktefamilie”.
Verteilte Entwicklung
Ein weiterer, häufig unterschätzter Komplexitätsfaktor ist die verteilte Entwicklung. Die verlängerte Werkbank senkt zwar unter Umständen die Entwicklungskosten, erfordert jedoch einen erhöhten Management- und Qualitätssicherungsaufwand.
Ein weiterer, häufig unterschätzter Komplexitätsfaktor ist die verteilte Entwicklung. Die verlängerte Werkbank senkt zwar unter Umständen die Entwicklungskosten, erfordert jedoch einen erhöhten Management- und Qualitätssicherungsaufwand.
Es wird daher immer schwieriger, alle Aspekte eines zu entwickelnden Produkts zu überschauen und sicherzustellen, dass alle Komponenten für sich genommen und im Zusammenspiel untereinander korrekt funktionieren. Hier ist eine effektive und effiziente Qualitätssicherung gefragt.
2 Qualitätssicherung von Anfang an
Jede Produktentwicklung beginnt mit den Anforderungen – und genau dort muss auch die Qualitätssicherung einsetzen. Wie bedeutend sie für den Projekterfolg sind, hat uns die Standish Group schon 1995 in ihrem ersten Chaos Report grausam vor Augen geführt. Seitdem hat sich auf dem Gebiet des Anforderungsmanagements viel getan. Inzwischen gibt es neben einer Reihe exzellenter Lehrbücher auch zertifizierte Schulungen des „International Requirements Engineering Board e. V.” („IREB® Certified Professional for Requirements Engineering”; kurz CPRE). Eine Übersicht über Inhalte, Voraussetzungen und Schulungsanbieter der CPRE-Kurse findet man übrigens auf den Internetseiten des IREBs [1].
Agilität
Seit Oktober 2020 gibt es eine neue, vollständig überarbeitete Version des IREB® CPRE-Lehrplans, in dem sequenzielle und agile Vorgehensweisen gleichermaßen behandelt werden. [2] Denn viele Hersteller sind auf agile Vorgehensmodelle umgestiegen (s. Kap. 11110, Kap. 11230, Kap. 11240). Scrum & Co haben unsere Entwicklungsprozesse reaktiver und geschmeidiger werden lassen. Damit hat sich die Art und Weise gewandelt, wie wir Anforderungen erfassen und dokumentieren.
Seit Oktober 2020 gibt es eine neue, vollständig überarbeitete Version des IREB® CPRE-Lehrplans, in dem sequenzielle und agile Vorgehensweisen gleichermaßen behandelt werden. [2] Denn viele Hersteller sind auf agile Vorgehensmodelle umgestiegen (s. Kap. 11110, Kap. 11230, Kap. 11240). Scrum & Co haben unsere Entwicklungsprozesse reaktiver und geschmeidiger werden lassen. Damit hat sich die Art und Weise gewandelt, wie wir Anforderungen erfassen und dokumentieren.
Anforderungen vs. User Stories
User Stories und Akzeptanzkriterien ersetzen die detaillierte Vorabplanung in Form einer Anforderungsspezifikation. Letztere entsteht häufig iterativ, inkrementell im Verlauf der Sprints oder wird gänzlich durch den Product Backlog ersetzt. Denn der puristische, rein agile Ansatz ist in der Medizintechnik schwierig. Obwohl uns Normen wie die IEC 62304 keine Vorschriften hinsichtlich der Vorgehensmodelle machen, werden eindeutig die Teststufen aus dem V-Modell gefordert. Außerdem sollen wir Software-Anforderungen aus Systemanforderungen ableiten und diese verifizieren. Denn gute Anforderungen sind die Grundlagen für gute Produkte.
User Stories und Akzeptanzkriterien ersetzen die detaillierte Vorabplanung in Form einer Anforderungsspezifikation. Letztere entsteht häufig iterativ, inkrementell im Verlauf der Sprints oder wird gänzlich durch den Product Backlog ersetzt. Denn der puristische, rein agile Ansatz ist in der Medizintechnik schwierig. Obwohl uns Normen wie die IEC 62304 keine Vorschriften hinsichtlich der Vorgehensmodelle machen, werden eindeutig die Teststufen aus dem V-Modell gefordert. Außerdem sollen wir Software-Anforderungen aus Systemanforderungen ableiten und diese verifizieren. Denn gute Anforderungen sind die Grundlagen für gute Produkte.
2.1 Was sind „gute” Anforderungen?
IEC 62304
Doch was macht eine „gute” Anforderung aus? Die IEC 62304 fordert in Abschnitt 5.2.6, dass Anforderungen vollständig (in Bezug auf Systemanforderungen und Risikokontrollmaßnahmen), widerspruchsfrei, möglichst eindeutig und objektiv prüfbar formuliert sind. Außerdem müssen sie eindeutig identifizierbar sein, d. h., sie müssen auf ihre Quelle zurückverfolgt werden können.
Doch was macht eine „gute” Anforderung aus? Die IEC 62304 fordert in Abschnitt 5.2.6, dass Anforderungen vollständig (in Bezug auf Systemanforderungen und Risikokontrollmaßnahmen), widerspruchsfrei, möglichst eindeutig und objektiv prüfbar formuliert sind. Außerdem müssen sie eindeutig identifizierbar sein, d. h., sie müssen auf ihre Quelle zurückverfolgt werden können.
2.1.1 Qualitätskriterien für Anforderungen
Das deckt sich teilweise, aber nicht vollständig mit den Qualitätskriterien für Anforderungen, die im bereits zitierten IREB® CPRE-Lehrplan definiert sind. Danach entsprechen qualitativ hochwertige Anforderungen den in Tabelle 1 aufgelisteten Kriterien.
Tabelle 1: Qualitätskriterien für Anforderungen (nach [2])
IREB®CPRE Kriterium | Beschreibung |
adäquat | Die Anforderung entspricht echten Bedürfnissen der Stakeholder (d. h. alle am System beteiligten bzw. vom System betroffenen Personen) und wurde auch mit diesen abgestimmt. |
notwendig | Es wird nur Funktionalität gefordert, die tatsächlich benötigt wird. |
eindeutig | Die Anforderungen sind so formuliert, dass sie möglichst eindeutig sind. |
vollständig | Die Anforderungen sind in sich abgeschlossen. |
verständlich | Die Anforderungen sind für alle Stakeholder verständlich formuliert. |
prüfbar | Anforderungen sind so beschrieben, dass sich daraus Testfälle ableiten lassen. |
2.1.2 Qualitätskriterien für User Stories
Die Kriterien in Tabelle 1 gelten für unsere klassischen Anforderungen. Für User Stories und deren Akzeptanzkriterien werden eher die sogenannten INVEST-Kriterien in den Vordergrund gestellt, wie sie von Bill Wake 2003 in einem Blog definiert wurden (s. Tabelle 2).