Bottleneck Systemverifizierung: Späte Änderungen an den Produktanforderungen

In der traditionellen Entwicklung von komplexen medizinischen Systemen stehen die Systemanforderungen häufig bereits fest, bevor überhaupt eine Zeile Softwarecode entstanden ist oder ein Bauteil aus einem Werkzeug gefallen ist. Dies führt logischerweise dazu, dass in der Projektplanung häufig die Testentwicklung (formale Systemtests) parallel zur Entwicklung eingeplant wird. Dies soll grundsätzlich zur Entlastung des Bottlenecks der formalen Verifizierung führen und das Projektrisiko reduzieren. Leider wird diese Planung häufig zum Bumerang und sorgt für Verzögerungen im Projekt und Blindleistungen in der Verifizierung. Diese Probleme möchte ich im folgenden vierten Teil der Blogreihe „Bottleneck Systemverifizierung“ darstellen und mögliche Gegenmaßnahmen aufzeigen.

In der Theorie geht man davon aus, dass im Rahmen der „traditionellen“ Entwicklung eines neuen komplexen medizinischen Systems frühzeitig stabile und vollständige Systemanforderungen aus den Produktanforderungen abgeleitet wurden. Dadurch sollte bereits vor der ersten Zeile Softwarecode oder dem ersten Prototyp klar sein, was und vor allem wie entwickelt werden soll. Dieses Vorgehen ist dahingehend nachvollziehbar, weil es die Entwicklung planbar macht und dies von den zulassenden Behörden akzeptiert und sogar gefordert wird.

Die frühzeitig feststehenden Anforderungen legen natürlich nahe, dass man die Testfallentwicklung (Testdesign) mit der Entwicklung/Entstehung des komplexen medizinischen Systems parallelisieren kann. Dadurch wird in der Theorie das Produktrisiko und im Idealfall sogar die Entwicklungszeit reduziert.

Theorie vs. Praxis

Warum zeigt sich nun in der Praxis also oft ein gegenteiliges Bild? Warum sieht man häufig eine Verzögerung bei der Entwicklung und Fertigstellung von komplexen medizinischen Systemen? Woran liegt das?

Neben den allgemein bekannten Problemen (technische Herausforderungen, personelle Kapazitätsengpässe etc.) spielt auch die Änderungsrate bei den Anforderungen eine wesentliche Rolle, wodurch die Entwicklung und das Fertigstellen des komplexen medizinischen Systems verzögert wird. Deshalb sollte die Änderungsrate der Anforderung als Metrik während des Projektverlaufs getrackt und ausgewertet werden .

Betrachtet man den zeitlichen Verlauf der Änderungsrate der Anforderungen und die Testdesignaufwände, erwartet man zurecht, dass zu Beginn der Entwicklung eine hohe Änderungsrate bei den Anforderungen zu beobachten ist, es werden in der Konzeptphase technische Lösungen erarbeitet und entsprechend auch in den Systemanforderungen spezifiziert. Sobald sich diese Änderungsrate der Anforderungen aber auf einem niedrigen Niveau stabilisiert hat, sollte die Verifizierung mit der Spezifizierung der Testfälle (formale Systemtests) basierend auf stabilen Anforderungen beginnen. In der Regel werden jetzt nur noch wenige Änderungen an den Systemanforderungen erwartet und somit eine geringe Änderungsrate der Anforderung.

Leider zeigt sich in der Praxis ein anderer zeitlicher Verlauf: Sobald von stabilen Systemanforderungen ausgegangen wird, beginnt die Verifizierung mit der Entwicklung der Testfälle (formale Systemtests). Und genau hier zeigt sich der Fehler in der Theorie. Entgegen der Erwartung, dass die Änderungsrate der Anforderungen stabil ist oder nur minimal steigt mit dem Beginn der Testdesignaktivitäten, zeigt sich häufig in der Praxis eine explosionsartige Steigerung der Änderungsrate der Anforderungen. Dies ist häufig auf folgende Punkte zurückzuführen:

• Unvollständige Anforderungen

• Widersprüchliche Anforderungen

• Nicht testbare Anforderungen

• Nicht normkonforme Umsetzung der Implementierung

Diese Gründe sind nahezu vollständig auf die späte Einbindung der Verifizierung in die Entwicklung von komplexen medizinischen Systemen zurückzuführen. Letztendlichen mildert eine frühe Einbindung jedoch häufig nur diesen Effekt, verhindert werden kann er dadurch nicht.

Blindleistung entsteht

Eine hohe Änderungsrate der Anforderung bedeutet auch, dass in der Verifizierung hohe Aufwände entstehen, weil für das formale Testfalldesign jede Anforderungsänderung in den Testfall eingearbeitet und formal im Vier-Augen-Prinzip freigegeben werden muss. Darüber hinaus sollten die entstandenen Testfälle in einer Probeverifizierung durchgeführt und getestet werden. Es entsteht eine nicht unwesentliche hohe Blindleistung in der Verifizierung für die Anpassungen der Testfälle. Und genau diese Zeit fehlt, damit die Verifizierung effektiv mit ihrer Expertise die Entwicklung unterstützen kann.

Das Ziel: Blindleistung minimieren

Häufig wird den hohen Aufwänden in der Verifizierung mit einer Erhöhung der personellen Kapazitäten entgegengesteuert. Diese Maßnahme ist jedoch weder effizient noch für jede Betriebsgröße zu leisten.

Deshalb sollte das Ziel innerhalb der Entwicklung von komplexen medizinischen Systemen unter anderem sein, die Blindleistung der Verifizierung zu minimieren und somit die Expertise der Verifizierung innerhalb der Entwicklung effektiv nutzen zu können. Man muss sich jedoch darüber im Klaren sein, dass sich diese Blindleistung und Verzögerung innerhalb der Entwicklung von komplexen medizinischen Systemen lediglich minimieren lässt, jedoch nicht komplett verhindert werden kann. Dies ist der Tatsache geschuldet, dass die Projektlaufzeit relativ lang ist und dadurch Anforderungsänderungen notwendig werden bei denen der Nutzen den Kosten überwiegt (zum Beispiel angepasste Kundenanforderungen).

Für die Minimierung der Blindleistungen gibt es eine Vielzahl von möglichen Ansätzen/Lösungen.

In der Praxis haben sich die folgenden als effektiv und nachhaltig erwiesen:

• Frühe Einbindung der Verifizierung bereits in die Entwicklung der Anforderungen (lesen Sie hierzu meinen alten Blogeintrag)

• Tracken der Änderungsrate der Anforderung während der Entwicklung von komplexen medizinischen Systemen und Festlegung von Grenzwerten für den Beginn der Testfallerzeugung

• Sinnvolle Aufteilung des komplexen Systems in einzelne Komponenten/Features und tracken der Änderungsrate der Anforderungen für diese Komponenten/Features

• Konsequentes Anwenden der agilen Methoden während der Entwicklung des komplexen Systems, wodurch die Kommunikation deutlich verbessert wird.

• Klare Abgrenzung des Spezifikationslevels: Was muss tatsächlich auf Systemebene spezifiziert werden?

• Einplanung von Testdesignänderungen nach Ende der Implementierung und Abschluss der Anforderungsspezifikation. Testfalldesignende und Anforderungsspezifikations-/Implantierungsende sind in der Praxis nicht zeitgleich zu erreichen

• Prozessgesteuerte Anforderungsänderung über ein Trackingtool wie zum Beispiel Jira oder ClearQuest durchführen

Kommunikation verbessern, Verständnis für Anforderungsänderungen schärfen

Zusammenfassend ist eine Steigerung der Kommunikation im Projekt und ein Verständnis für die Folgen von späten Änderungen von Anforderungen notwendig. Es ist immer eine Kosten/Nutzen- Abwägung bei Anforderungsänderungen notwendig, bevor diese durchgeführt werden und gegebenenfalls zu Blindleistungen in der Verifizierung führen. Die späten Änderungen von Anforderungen sollten niemals die Entscheidung eines Einzelnen innerhalb des Projekts sein, sondern immer durch ein Gremium aus den verschieden Fachgremien entschieden werden.

Nutzen Sie Shared-Testing

Hierbei bietet das Shared-Testing-Konzept die skalierten Lösungen, um Maßnahmen und Prozesse zu etablieren, die das Projektrisiko minimieren und Blindleistung in der Verifizierung verhindert.

Zögern Sie nicht, weitere Informationen zum Thema Shared-Testing bei ihrem SCOPE Ansprechpartner zu erfragen oder sichern Sie sich direkt ein Ticket für die erste test.it Fachtagung in Kiel, bei der Sie die Experten persönlich kennenlernen können.

#Verifizierung #formaleVerifizierung #komplexemedizinischeSysteme #anforderungsmanagement #Systemanforderungen #Systemtest #Testdesign #SharedTesting