Alte Software macht alte Fehler …

Dr Markus Neumann

Dass solche Fehler zu vermeiden und vor Einsatz der Software zu finden und zu beheben sind, ist offensichtlich. Nichtsdestoweniger bleibt die vollständige Fehlerfreiheit ein frommer Wunsch. Die Aufgabe, Fehler zu identifizieren, ist dem Hersteller in Form der Validation und dem Anwender als Verifikation in der ISO 15189:2012 obligatorisch auferlegt. Die ISO 9000:2015 definiert dabei einen Fehler als Unterlassung, Fehlverhalten oder Fehlleistung („es wird nicht die gewünschte Handlung durchgeführt“) eines Menschen. Ursachen menschlicher Fehler sind dabei Nicht-Wissen, Nicht-Können oder Nicht-Wollen. Eine menschliche Fehlhandlung (Error), führt zu einem (mitunter nicht erkannten) Fehlzustand (Defect), der eine Fehlwirkung (Failure) nach sich ziehen kann. Als Beispiel sei die Programmanweisung „x = a/b“ angeführt: das Nichtberücksichtigen des Falles „b = 0“ bewirkt ein fehlerhaftes Programm und sollte nicht berücksichtigt werden, dass b den Wert 0 annimmt, führt das zum Absturz des Systems.

Softwareentwicklung als komplexer Prozess (Cynefin-Framework)

Warum ist das so? Ein gutes Arbeitsmittel, um Fehlern in der Software phänomenologisch auf die Spur zu kommen, ist das Cynefin-Framework. Hierbei handelt es sich um ein Wissensmanagement-Modell, das verwendet wird, um Probleme, Situationen und Systeme zu beschreiben. Es liefert eine Typologie von Kontexten, die einen Anhaltspunkt bietet, welche Art von Erklärungen und/oder Lösungen zutreffen könnten. Es geht darum, die evolutionäre Struktur komplexer Systeme zu veranschaulichen, einschließlich einer inhärenten Unsicherheit. Der walisische Begriff „Cynefin“ – mit habitat, haunt, acquainted, familiar nur unzureichend übersetzt – verweist darauf, dass menschliche Interaktion stark von Erfahrungen (persönlichen, aber auch kollektiven) beeinflusst, wenn nicht sogar bestimmt wird.

Bild 1: Domänen im Cynefin-Framework

Bild 1 zeigt die 4 Domänen (Kontexte) des Frameworks: diese unterscheiden sich durch den unterschiedlichen Grad der Wahrnehmung von Kausalität/Kopplung zwischen Ursache und Wirkung im betrachteten System. Beginnend bei „obvious“ und einer strikten Kopplung, nimmt diese gegen den Uhrzeigersinn ab, bis in chaotischen Systemen keine Beziehung zwischen Ursache und Wirkung mehr wahrnehmbar ist.

Je nach Einordnung einer Situation in eine dieser Domänen stehen verschiedene Handlungsoptionen zur Verfügung. So ergibt sich für medizinische Labore, dass Analytik und Diagnostik meistens als Complicated, die medizinische Forschung hingegen als Complex charakterisiert ist. Für das Verständnis von Fehlervermeidung und -findung bei medizinischer Software entscheidend ist der Effekt der eigenen Wahrnehmung des jeweiligen Kontexts: durch Lernen und Training ist es möglich, zu einem tiefergehenden Verständnis der Kausalität in einem Kontext zu kommen und sich dabei innerhalb der Domänen im Uhrzeigersinn zu bewegen. Für Softwarehersteller im Labor ist die Gegenrichtung ebenfalls bekannt: der Abfluss von Wissen durch den Weggang bewährter Mitarbeiter hat in jüngster Zeit bei einige Unternehmen an den Rand des Chaos gebracht.

Vor dem Hintergrund, dass sich in der Softwareentwicklung Beschäftigte laut eigener Einschätzung   zu über 50 Prozent ihrer Zeit in Complex- und Chaotic-Szenarien sehen, erscheint die Situation für ein Labor, das die Qualität seiner eingesetzten Software beurteilen soll, eher hoffnungslos. Glücklicherweise bietet das Framework auch hier Hinweise: so sind sowohl beste und gute Verfahren (best and good practices) nicht zielführend; vielmehr können in diesem Umfeld emergente und ganz neue Praktiken eingesetzt werden. Auch ist der Kontext „chaotic“ nicht als statisch anzusehen – vielmehr eröffnet er die Möglichkeit, durch die Anwendung sehr strikter und formaler Regeln die Reaktionen des Gesamtsystems vorhersagbar zu machen und damit den Kontext „obvious“ zu erreichen.

Handreichung für den Anwender

BIld 2: Typische Aktivitäten in der Software-Entwicklung in Bezug auf die Domänen des Cynefin-Frameworks

Folgende Vorgehensweisen bieten sich an:

• Lieferanten-Audit: bevor man sich auf eine längere vertragliche Bindung mit einem Softwareanbieter einlässt, sollte zunächst geprüft werden, ob dieser zu einem selbst passt. Dabei kann zudem festgestellt werden, ob sich der Hersteller der Komplexität seiner Aufgabe bewusst ist und wie er diese meistert.  
• Verifikation: in den Kontextbereichen Complex und Chaotic sollten emergent and novel practices angewandt werden, in anderen Worten, es sollte „ausprobiert“ (probe) oder „einfach getan“ (act) werden. Ziel ist es, durch Programmeingaben Bedingungen zu erzeugen, die einen Absturz (failure) erzwingen und damit einen defect des Programmcodes offenlegen. Es zeigt sich, dass Softwareprodukte, bedingt durch die Programmiersprache, verwendete Werkzeuge, die beteiligten Personen und nicht zuletzt durch die beabsichtigte Funktion dazu neigen, bestimmte Fehlertypen zu reproduzieren; eine detaillierte Aufzeichnung und Kategorisierung gefundener Fehler ist für die Verifikation ein nicht zu unterschätzendes Hilfsmittel.
• Statistik: einen weiteren Hinweis auf die Stabilität der Software erhält man durch die quantitative Auswertung der Anzahl der während der Verifikation gefundenen Fehler; wie für jedes Ingenieursprodukt folgt auch diese über die Produktlebenszeit einem ähnlichen Verlauf (Badewannenkurve) und ermöglicht dem Anwender eine Einschätzung des „Softwarealters“ und damit eine Vorhersage, ob die eingesetzte Software in nächster Zeit einen Zustand erreicht, in dem der Weiterbetrieb aufgrund einer zu hohen Zahl von Fehlern nicht mehr effizient ist.

Ausblick auf neue Software(-Fehler)

Ausfallverteilung ("Badewannen-Kurve") als Schätzwert für die Fehlerrate von Software während seiner Lebensdauer

Neue Anforderungen an die Software in Laboratorien werden zunehmend durch neue Technologien in Betrieb und Entwicklung dieser Software beantwortet. Die Therapieentscheidung orientiert sich zunehmend am individuellen Patienten mit seinem komplexen biologischen Profil. Ermittlung und Bewertung des Profils erfordern stetig eine größere Verarbeitungskapazität der IT-Anlagen. Sie erfordern auch den Einsatz neuer Paradigmen und Algorithmen wie Mustererkennung und Machine Learning – oft unter dem Begriff „Artificial Intelligence“ zusammengefasst.

Die neuen Soft- und Hardware Paradigmen führen zu einer neuen Art von Komplexität und damit zu neuen Fehlern. Beim Machine Learning schafft der „Mensch“ nur noch die Grundlage des Lernens; das Lernen selbst ist bestimmt vom „Lernumfeld“ der Maschine und ihren Trainingsdatensätzen, deren Qualität wiederum die Möglichkeiten des Systems beeinflussen, zwischen gesund und krank zu unterscheiden. Ein Fehler in dieser Kategorisierung kann also Ursachen auf allen Ebenen des Gesamtsystems haben – im Extremfall hat das System das Falsche gelernt und die Aufgabe der Validation wird wie bisher sein, die Auswirkung dieses „defect!“ zu erfassen, um notwendige Handlungen (zur Behebung) abzuleiten.

Auch führt die Definition von Fehlern im Bereich der AI-Algorithmen zu einer Schärfung des Begriffs der menschlichen Verantwortung: Fehler sind immer auf das Handeln von Menschen zurück zu führen, weil eine AI keine eigenen Fehler machen kann. Handelt sie für den Menschen unvorhersagbar, ergibt sich daraus eine ungleich höhere ethische Verantwortung für den Bau von IT-Systemen, das Training, insbesondere die Trainingsdaten und den Einsatz am Patienten. Deshalb sollte jegliche Aktivität in dieser Richtung detailliert aufgezeichnet werden, um Patienten, Prüfstellen und der Öffentlichkeit gegenüber jederzeit nachweisen zu können, dass der Sorgfaltspflicht nachgekommen wurde.

27.09.2019

• IT (723)
• Labbook (6)
• Labor (403)
• LIS (17)