Fehlerwahrscheinlichkeiten
-
Hallo zusammen,
ich suche nach Methoden um die Fehlerwahrscheinlichkeit einer Software zu bestimmen. Also einer Methode um zu sagen, bei absolut perfekter Hardware wird die entwickelte Software in x % ausfallen.
Aus meiner Sicht muss man davon ausgehen, dass eine Software nicht von Fehlern befreit ist und somit auch ausfällt bzw. einen Fehler auslöst. Gibt es Methoden solche Fehlerwahrscheinlichkeiten von Software zu bestimmen?
-
Wenn die Hardware perfekt ist, wird die Software ganz exakt das machen, was ihr Code vorschreibt. Ob dies dann das ist, was der Anwender will, ist eine andere Frage, aber "falsch" kann man es eigentlich nicht nennen.
-
Naja die Aussage halte ich für nicht tragbar. Die Software wird zwar das machen was im Code steht, ob dies jedoch den Anforderungen entspricht ist fraglich. Sonst wären Qualitätssicherungsmaßnahmen überflüssig. Ich gehe auch davon aus, dass ein Entwickler nicht perfekt ist und grundsätzlich Fehler macht.
Ich habe an etwas in der Art gedacht:
Man beobachtet die Fehlerrate, die bei den Tests aufgedeckt wird. Aufgrund dieser Fehlerrate läßt sich ein Rückschluss auf vorhandene Fehler schließen. Die Wahrscheinlichkeit, ob Fehler vorhanden sind, ob diese auftreten muss irgendwie auch mit einfließen. Daraus ergibt sich dann die "Ausfallrate" der Software.Bei der Aussage von SeppJ verstehe ich, dass zwar Software das macht, was man ihr sagt... das ist Qualitätssicherung (Prüfung, ob die Anforderungen erfüllt werden). Ich suche aber vielmehr eine Methode um Rückschlüsse auf die Fehlerwahrscheinlichkeit (bzw. das die Software sich aufhängt) zu finden.
Danke nochmals für Antworten...
-
Irgendwie irritiert mich bei deiner Frage das Wort "Wahrscheinlichkeit". Wenn die Hardware perfekt ist, wird das Programm bei einer bestimmten Eingabe a) immer durchlaufen oder b) sich immer aufhängen. Wahrscheinlichkeit eines Fehlers ist also 0 im ersten Fall und 1 im zweiten Fall. Deine Fehler"wahrscheinlichkeit" hängt also ganz davon ab, wie die Eingabe aussieht.
-
SeppJ schrieb:
Wenn die Hardware perfekt ist, wird das Programm bei einer bestimmten Eingabe a) immer durchlaufen oder b) sich immer aufhängen.
Und die Frage ist wie es berechnet werden soll...
http://de.wikipedia.org/wiki/Halteproblem
-
Ich weiß warum ich theoretische Informatik nicht mag.
-
witte schrieb:
Verstehe ich nicht, was das damit zu tun haben soll
Magst du's kurz erläutern?
-
Unix-Tom schrieb:
Ich weiß warum ich theoretische Informatik nicht mag.
Weil sie auf Probleme angewendet wird, wo sie nichts zu suchen hat?
-
Na, ich weiß einfach nicht wie er es berechnen will, ob sich das Programm aufhängt bzw. wie er zu eine prozentualen Wahrscheinlichkeit kommen will.
-
SeppJ schrieb:
Irgendwie irritiert mich bei deiner Frage das Wort "Wahrscheinlichkeit". Wenn die Hardware perfekt ist, wird das Programm bei einer bestimmten Eingabe a) immer durchlaufen oder b) sich immer aufhängen. Wahrscheinlichkeit eines Fehlers ist also 0 im ersten Fall und 1 im zweiten Fall. Deine Fehler"wahrscheinlichkeit" hängt also ganz davon ab, wie die Eingabe aussieht.
Naja zunächst einmal stimmt die Aussage mit Eingabe und gleichem Verhalten nicht bei Multi-Threaded-Applications... aber das ist ein anderes Thema.
Deine Aussage bzgl. eines Fehlers ist bestimmt korrekt. Ich versuche dennoch das was ich berechnen will bzw. wofür ich eine Methode suche (da gibt es bestimmt was von irgendeinem Prof oder so zu).
Also nehmen wir an ich entwickle eine hochkomplexe Anwendung (ja eventuell sogar multithreaded). Nun gibt es irgendwann einen Zeitpunkt in der wir die Software dann mal verkaufen wollen. Also entscheiden wir uns den Code einzufrieren (wir haben sogar während der Entwicklung auf UnitTests nicht verzichtet etc.). Wir geben die Software also nach dem Entwicklungsfreeze nun an unsere Qualitätssicherung die prüft, ob die Software die Anforderungen erfüllt. Und die Qualitätssicherung sagt, dass die Software ausgeliefert werden kann (sehr wahrscheinlich treten sogar trotz unserer UnitTests etc. Fehler auf die wir noch schnell Bugfixen).
Nun würde ich gerne dem Kunden sagen, hier ist deine Software, diese Software wurde nach bestem Gewissen geprüft, qualitätsgesichert etc. Nichts desto trotz besteht eine Wahrscheinlichkeit von 205% das wir einen Fehler übersehen haben, der kritisch ist und die Software (unabhängig von Hardware) zum Absturz bringen wird.Wie kommen wir auf die Wahrscheinlichkeit - nun denke ich mir einfach mal eine Methode aus (irgendwas triviales, ich hoffe das es dort ja etwas "vernünftiges" gibt). Also die Methode sieht so aus, wir haben vor dem Code-Freeze 5 kritische Fehler in das System eingebaut. Nun zählen wir wie viele dieser Fehler durch die Qualitätssicherung gefunden werden. Sagen wir einfach mal das es 4 waren. Insgesamt können wir also davon ausgehen, dass die Qualitätssicherung 4 von 5 (also ganze 80%) gefunden hat. 20% der kritischen Fehler sind also auch nach Qualitätssicherung noch in der Anwendung. Nun gebe ich zu, dass es nicht ganz so trivial ist (deswegen Frage ich hier nach einer Methode ;)).
@witte
Deinen Hinweis auf das Halteproblem der Turing-Machine sehe ich als keine Methode, sondern als Hinweis der Untestbarkeit auf Fehlerfreiheit. Ich glaube ich habe oben eine triviale Lösung gegegeben eine solche Wahrscheinlichkeit zu berechnen.Nochmals vielen Dank für eine weitere Diskussion bzw. Antworten
-
205% sollte natürlich 20% heißen :D...
-
Error... schrieb:
Wie kommen wir auf die Wahrscheinlichkeit - nun denke ich mir einfach mal eine Methode aus (irgendwas triviales, ich hoffe das es dort ja etwas "vernünftiges" gibt). Also die Methode sieht so aus, wir haben vor dem Code-Freeze 5 kritische Fehler in das System eingebaut. Nun zählen wir wie viele dieser Fehler durch die Qualitätssicherung gefunden werden. Sagen wir einfach mal das es 4 waren. Insgesamt können wir also davon ausgehen, dass die Qualitätssicherung 4 von 5 (also ganze 80%) gefunden hat. 20% der kritischen Fehler sind also auch nach Qualitätssicherung noch in der Anwendung. Nun gebe ich zu, dass es nicht ganz so trivial ist (deswegen Frage ich hier nach einer Methode ;)).
Ahh, nun verstehe ich worauf du hinaus willst. Das Problem ist jedoch wie du selbst gesagt hast, nicht ganz einfach. Es sind jedoch mehr Daten nötig, als die reine Anzahl der gefundenen Fehler um zu einer fundierten Aussage zu kommen. Da ich nicht genau weiß, wie die Qualitätssicherung bei wirklich großen Projekten arbeitet, will ich nicht herumspekulieren sondern mal gegenfragen: Welche Daten sind denn verfügbar? Gibt es zum Beispiel sowas wie 'gefundene Fehler pro Kontrollgang'? Oder empirische Daten wie viele Fehler von der QS in der Vergangenheit gefunden/übersehen wurden?
-
SeppJ schrieb:
Ahh, nun verstehe ich worauf du hinaus willst. Das Problem ist jedoch wie du selbst gesagt hast, nicht ganz einfach.
Mist, habe ich mir doch gedacht
SeppJ schrieb:
Es sind jedoch mehr Daten nötig, als die reine Anzahl der gefundenen Fehler um zu einer fundierten Aussage zu kommen. Da ich nicht genau weiß, wie die Qualitätssicherung bei wirklich großen Projekten arbeitet, will ich nicht herumspekulieren sondern mal gegenfragen: Welche Daten sind denn verfügbar? Gibt es zum Beispiel sowas wie 'gefundene Fehler pro Kontrollgang'? Oder empirische Daten wie viele Fehler von der QS in der Vergangenheit gefunden/übersehen wurden?
Also die QS hat einige Daten. z.B. die der gefundenden Fehler pro Kontrollgang, ja sogar Daten über die schwere der Fehler. Empirische Daten hat eine QS natürlich dann, wenn Routine und Erfahrung sich treffen. Aber solche empirischen Daten wären für mich auf jeden Fall schon einmal sehr interessant. Hat da jemand Erfahrung, Informationen?
Gruß und Dank
-
Ich denke dass die Fehlerwahrscheinlichkeit ziemlich stark von der QS abhängt. Wenn die Testreihen 99% aller möglichen Anwendungen/Anforderungen abdeckt, dürfte man schon geringe Fehlerwahrscheinlichkeiten erreichen. Insbesondere dann, wenn man Teile des Code mittels symbolische Ausführung oder hoarschem Kalkül verifiziert. Aber gerade bei Multithreaded Anwendungen sind diese Tests oftmals überfragt, weil Zeitapsekte zwischen zwei Codezeilen eine Rolle spielen.
Also dürfte die Wahrscheinlichkeit eines Fehlers von der Wahrscheinlichkeit dass der Fehler nicht getestet wurde und der Wahrscheinlichkeit dass ein Multithreaded Problem auftaucht abhängen. Apropo, da fällt mir ja die FMEA Analyse (http://de.wikipedia.org/wiki/FMEA) noch ein, die genau diese Vorgehensweise beschreibt.
-
Error... schrieb:
Man beobachtet die Fehlerrate, die bei den Tests aufgedeckt wird. Aufgrund dieser Fehlerrate läßt sich ein Rückschluss auf vorhandene Fehler schließen. Die Wahrscheinlichkeit, ob Fehler vorhanden sind, ob diese auftreten muss irgendwie auch mit einfließen. Daraus ergibt sich dann die "Ausfallrate" der Software.
Ich koennt mir vorstellen, dass die Anzahl der noch im Code vorhandenen Fehler Exponentialverteilt ueber die Anzahl der Code-Reviews/Tests ist (wenn du Daten hast, koenntest du das ja mal Testen), aber aus der Anzahl der gefundenen Fehler Rueckschluesse ueber die Anzahl der noch vorhandenen Fehler zu schliessen, ist IMO sehr gewagt.
just my 0.02 cents
