Dani! hat geschrieben: ↑27. Sep 2023, 19:33
@Mike
Eine Firmware ändert man nicht einfach mal eben. Manchmal steckt das Übel in einem Detail, das überall im Hörgerät verwendet wird. Wenn man dort etwas verändert, könnten andernorts Seiteneffekte auftreten, die man nicht erwartet hätte. Zumal es ja offenbar einen Weg für den Akustiker gibt, es richtig zu machen. Vorausgesetzt, man ist Akustiker. Dass es andere nicht verstehen ist nachvollziehbar.
Ich vermute, daß der Fehler durch einen Softwarefehler ausgelöst wird, der nicht behandelt wird. Die Software liefert eine unbekannte Exception, und als Maßnahme erfolgt einfach ein Warmstart des Geräts. Wir sprechen hier über ein medizinisches Gerät, für das es gesetzliche Vorgaben gibt, zum Beispiel in Form von Sicherheitsstandards. Die kenne ich nicht im Detail, aber ich nehme an, daß sie zumindest einen geordneten, dokumentierten und überwachten Entwicklungsprozeß nach Stand der Technik erwarten.
Schauen wir mal, wo man das hätte finden können.
Zunächst in der Systemanalyse. Ein Domänenexperte analysiert alle möglichen Szenarien und leitet daraus Anforderungen ab. Dabei sollte er nicht nur den Gutfall, sondern auch alle möglichen Fehlerfälle betrachten. Extrem wäre eine FMEA, die aber nur bei sicherheitskritischer SW gemacht wird.
Dann in der SW-Architektur. Hier könnte man eine andere Reaktion als einen Warmstart vorsehen. Man könnte eine allgemeine, sanftere Fehlerbehandlungsroutine einplanen. Nützlich wäre auch eine Komponente, die solche Fehler in einen internen Speicher schreibt, den der Akustiker auslesen kann.
Du sprichst Seiteneffekte an. Das sollte durch eine gute SW-Architektur vermieden werden. Ich sage nur: Kapselung, Kohäsion und Kopplung - die drei K, die die SW-Architektur qualitativ charakterisieren.
Danach in der Implementierung, Stichwort defensive Programmierung. Der Fall einer unbekannten, unbehandelten Exception sollte nicht auftreten. Vielleicht stammt der Fehler auch aus einer dazu gelinkten Open-Source-Routine, die Oticon gar nicht selbst entwickelt hat? Auch das könnte man untersuchen.
Als nächstes kommt der Unit-Test. Offensichtlich wurde nicht ausreichend getestet, sonst hätte man diesen Fehlerfall gefunden und behoben.
Dann kommt der Integrations-/Systemtest. Ich gehe davon aus, daß Testgeräte intensiv und systematisch geprüft wurden. Erstaunlich, daß dieser Fall dort nie aufgetreten ist, während er hier bei mehreren Nutzern relativ häufig auftritt.
Und zuletzt kommt die Maintenance während der Nutzungsphase. Offensichtlich weiß Oticon ja von den Nutzern, daß dieser Fehler auftritt. Sie haben sich aber entschieden, ihn nicht zu beheben, sondern einen Workaround anzubieten.
Es gibt ja immer wieder Updates. Da könnte Oticon zum Beispiel einen Zeitpunkt mitteilen, bis zu dem der Fehler behoben sein wird. Das machen andere Firmen so.
Eine professionelle Softwareentwicklung sollte schon in der Lage sein, solche Fehler gar nicht erst einzubauen, Fehler durch systematische Tests zu finden und zu beheben und Fehler während der Nutzungsphase durch Updates zu beheben. Und sie sollte in der Lage sein, Seiteneffekte von Fehlerbehebungen zu identifizieren und im besten Fall zu vermeiden.
Jeder dieser Schritte kostet Geld. Gute Software ist richtig, richtig teuer. Deshalb ist es wirtschaftlich, einzelne Schritte abzukürzen. Das kann man machen, wenn man sich der Konsequenzen bewußt ist. Dafür habe ich durchaus Verständnis. Sie müssen schließlich Geld verdienen, das ist der Zweck einer Firma. Als Kunde kann ich dann meine Konsequenz ziehen und das nächste Mal zu einer anderen Marke wechseln. Oder ich halte den Ball flach und ärgere mich nicht über die Neustarts, die ja nur eine kleine Komforteinschränkung darstellen.
Ich bin der Meinung, daß Oticon hier zumindest etwas kundenfreundlicher agieren sollte. Die Geräte sind schweineteuer. Ich habe auch nicht nur mit den Hörgeräten, sondern auch mit dem ConnectClip Probleme, die von der Software verursacht sind. Ich denke, sie investieren zu wenig in ihren Software-Prozeß.