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 Testentwicklung (formale Systemtests) parallel zur Entwicklung eingeplant wird. Das soll grundsätzlich zur Entlastung des Bottlenecks der formalen Verifizierung führen und 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.

Späte Änderungen an den Produktanforderungen

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 häufig ein gegenteiliges Bild? Häufig sieht man 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 Fertigstellung des komplexen medizinischen Systems verzögert werden. 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 erarbeiten und entsprechend auch in den Systemanforderungen spezifiziert. Sobald sich diese Änderungsrate der Anforderungen aber auf einem niedrigen Niveau stabilisiert hat, sollte die die Verifizierung mit der Spezifizierung der Testfälle (formale Systemtests) basierend auf stabilen Anforderungen beginnen. In der Regel werden jetzt nur noch wenige Änderungen in an den Systemanforderungen erwartet und somit eine geringe Änderungsrate der Anforderungen.
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 (siehe Blogeintrag 2) in die Entwicklung von komplexen medizinischen System zurückzuführen. Letztendlichen mildert eine frühe Einbindung jedoch häufig nur diesen Effekt, verhindert wird 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 unwesentlich 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.

Blindleistung minimieren

Häufig wird den hohen Aufwänden in der Verifizierung mit der 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, man sie jedoch nicht komplett verhindern kann. Dies ist der Tatsache geschuldet, dass die Projektlaufzeit relativ lang ist und dadurch Anforderungsänderungen notwendig werden, bei denen der Nutzen die Kosten überwiegt (zum Beispiel angepasste Kundenanforderungen).
Für die Minimierung der Blindleitungen gibt es eine Vielzahl von möglichen Ansätzen/Lösungen.
In der Praxis haben sich die folgenden Ansätze/Lösungen 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 Anforderungsspezifikation/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 sollte niemals die Entscheidung eines Einzelnen innerhalb des Projekts sein, sondern immer durch ein Gremium aus den verschiedenen Fachvertretern entschieden werden. Auch der Blick von außen durch einen externen Testing-Partner ist eine sinnvolle Unterstützung, wenn es um eine rationale Einschätzung der Notwendigkeit von Änderungen geht.
[toggle type=”” title=”Über die test.it”]Als Plattform für den branchenübergreifenden Austausch von Test- und Entwicklungsexperten veranstaltet SCOPE Engineering regelmäßig Tagungen, Stammtische und Vorträge rund um aktuelle Trends und Themen aus dem breiten Spektrum der Softwarequalitätssicherung. Die nächste Veranstaltung soll im November 2018 in Kiel stattfinden. Bei einer gemütlichen Tasse Tee oder Kaffee bekommen Interessierte in einem kurzen Vortrag neue Impulse und anschließend viel Zeit für den fachlichen Austausch mit unterschiedlichsten Testexperten. Alle Informationen zu der Veranstaltung gibt es auf www.entwicklung-komplexer-systeme.de/test-it.[/toggle]