Erich Ganspoeck wrote:<br>> <br>> August Hörandl wrote:<br>> <br>> > ist doch eine gute Ausrede: "der Computer macht das falsch" - nur <br>> > leider machen Computer keine Fehler<br>> <br>> Na ja. Da gab es einmal einen Pentium, der machte bei einigen Befehlen <br>> tatsächlich Fehler. Auf die ist der Normalverbraucher gar nicht <br>> gekommen, sondern erst ein Spezialist, dem manches Ergebnis nicht <br>> gefiel.<br><br>der pentium machte keinen fehler - die maske war falsch; da aber das niemand bei intel "ausprobiert" (im sinn von testen) hat ...<br><br>warum zerstört zb. bmw jährlich mehrere 100 schöne autos um die sicherheit zu testen ? wenn es nicht geht wird es schon jemand merken und eine fehler melden ...<br><br>> > nur die Programmierer die auch nur Menschen sind<br>> <br>> Genau. So habe ich es auch im Prinzip gemeint.<br>> <br>> > kann<br>> > man fehlerfreie Programme sehr wohl schreiben bzw. die Fehler im <br>> > Griff haben. Und Tests vor der Ausführung durchführen.<br>> <br>> Da muss ich jetzt deutlich widersprechen. Wir sind uns wohl einig, <br>> dass ich nicht vom berühmten Programm sprach, das "Hello World" am <br>> Bildschirm produziert. Große Applikationen mit Tausenden Befehlszeilen <br>> enthalten Fehler, glauben Sie mir das.<br><br>ich glaube es gerne - nur welches naturgesetzt bestimmt das ?<br><br>> (Ich hoffe, dass sich in diesem Forum auch Experten melden und die <br>> üblichen Fehlerraten angeben.)<br><br>ich fühle mich als experte - ich habe bei der fa. alcatel 5 jahre software für eisenbahnstellwerke programmiert; da muss man beweisen das man keine fehler hat, sonst darf man nicht einmal einschalten (und eisenbahnstellwerke sind sicherheitstechnisch in der gleichen klasse wie atomkraftwerke, viel sicherer als flugzeuge)<br><br>ist immer eine frage des aufwands<br><br>http://www.fastcompany.com/online/06/writestuff.html<br># But how much work the software does is not what makes it remarkable. What makes # it remarkable is how well the software works. This software never crashes. It <br># never needs to be re-booted. This software is bug-free. It is perfect, as # perfect as human beings have achieved. Consider these stats : the last three <br># versions of the program -- each 420,000 lines long-had just one error each. The <br># last 11 versions of this software had a total of 17 errors. Commercial programs <br># of equivalent complexity would have 5,000 errors. <br><br>ok - so ein Aufwand wie die nasa treiben wenige; aber der faktor 5000 sollte einem zu denken geben; und unter diesem vorwand kann eine firma 100*5000 so viele fehler machen - ist halt pech ;-) das kann es wohl nicht sein<br> <br>und es kann nur niemand nachweisen - welcher programmierer weiss schon wie viele fehler er macht -- software engineering ist ein märchen<br><br>> > Oder wie funktionieren Autopiloten, Steuerungen von Atomkraftwerken <br>> > sonst ?<br>> <br>> Soviel ich weiß, haben moderne Flugzeuge drei unabhängige Systeme, die <br>> ihre Ergebnisse ständig miteinander vergleichen und nach <br>> Majoritätsentscheidungen agieren.Über die Sicherheit von <br>> Atomkraftwerksteuerungen wage ich keine Aussage.<br><br>das ist ein punkt - aber wenn die drei systeme viele fehler haben, dann stellt sich die zwei fragen: <br><br>- wie stellt man sicher das nicht 2 gleichzeitig einen blödsinn machen ? die <br>  dafür wichtige nebenbedingung: alle 3 systeme müssen fast fehlerfrei<br>  sein<br><br>- und wenn sich jetzt einer irrt - was dann ? den bösen ausschalten -dann <br>  hat man nur noch zwei, und beim nächsten fehler ein ganz grosses <br>  problem (darum hat das shuttle teilweise 5 systeme - weil ein space shuttle<br>  so schwer stoppen und dann neu zu starten ist ;-))<br><br>Anmerkung:<br>genau so etwas habe ich programmiert - und ich bin stolz darauf, das es von mir software gibt die zig fach eingesetzt ist und seit über 5 jahren keine neue version erfordert hat -- und wenn sie aus salzburg mit dem zug ausgefahren sind, dann haben sie sie auch schon einmal "benutzt"<br><br>> >Oder eine Beispiel für ein "normales" Programm: Tex - seit1995 wurde <br>> >kein<br>> Fehler >gefunden<br>> <br>> OK, das freut mich natürlich. Aber um jetzt zu zeigen, wie ich das <br>> meine: wenn Sie beispielsweise die Taste F10, S und Entf gleichzeitig <br>> drücken, läuft dann das Programm in jeder Situation fehlerfrei weiter? <br>> Wenn mitten in einer Eingabe der Strom ausfällt, läuft dann das <br>> Programm fehlerfrei nach Wiedereinschalten<br><br>das ist jetzt an den haaren herbeigezogen - aber eisenbahnstellwerke müssen auch dann noch reagieren und die züge zum stehen bringen -- wenn es gefordert wird kann man so etwas auch realisieren<br><br>> weiter? Und was ist, wenn Sie die Tasten 4 und Pos1 gleichzeitig <br>> drücken, wenn .... Wollen Sie wirklich versuchen, alle möglichen <br>> Tastenkombinationen an allen möglichen Programmstellen auszutesten? <br>> Und das sind nur die äußeren<br><br>1) nächster prizipieller fehler: mit einem test kann man nur fehler nachweisen,<br>   niemals aber die fehlerfreiheit da man nie "alle" varianten testen kann<br><br>2) gute programmier rechnen mit jeder dummheit des benutzers - es muss nur eine sinnvolle behandlung aller "jetzt nicht zu drückenden" tasten geben, dann ist selbst das testbar<br><br>> Einflussmöglichkeiten. Das meine ich, wenn ich sage, dass niemand <br>> sicher sagen kann, dass ein Programm fehlerfrei läuft.<br><br>"meine" eisenbahnstellwerke werden auch mit compilerfehlern, kippenden bits (bei 30 jahre laufzeit kommt so etwas vor) etc. fertig - und da gibt es leute die <br>unterschreiben und haften dafür<br> <br>> > Es gibt keine Testfälle (ein oder mehrere Eingabefiles und <br>> > kontrollierte Ausgabedatein dazu) die automatisch bei jeder Version <br>> > durchlaufen werden. Wobei diese Testfälle auch alle Sonderfälle und <br>> > Fehler der vorigen Versionen umfassen<br>> <br>> Ich verstehe leider nicht ganz, was Sie hier meinten. Vielleicht passt <br>> aber das<br>> folgende:<br>> Nach welchen Gesichtspunkten legen Sie diese Testprogramme an? Nach welcher<br>> statistischen Wahrscheinlichkeit können Sie dann festlegen, dass das gesamte<br>> Programm mit allen Sonderregelungen (unser Gehaltsprogramm beispielsweise muss<br>> angesichts der tausenden verschiedenen Fallmöglichkeiten so ein Ungetüm sein)<br>> fehlerfrei läuft?<br><br>mit der argumentation beweisen sie das es so ein programm nicht geben kann - und das ist sicher falsch<br><br>dann muss man entweder besser entwurfsverfahren verwenden oder vielleicht schon bei der erstellung der anforderungen auf die "berechenbarkeit" achten<br><br>bei den stellwerken hat die alcatel der oebb fehler in den anforderungen nachgewiesen indem das "fertige" programm verweigert hat - bis zu einem gewissen grad sind auch anforderungen testbar<br><br>was ich aber meine:<br> ein eingabe file - mit vielen sonderfällen - die ausgabe des programms wird  kontrolliert. gemeldete bugs werden zum file als weitere sonderfälle dazugefügt.  bei der nächsten programmänderung wird das eingabefile nachmals verwendet und  die ausgabe wieder verglichen - das wäre ein minimaler ansatz<br><br> wenn eine neue version bei dingen, die frühere versionen konnten, probleme  haben, dann ist das ein "testproblem"<br><br>> Trotzdem bleibe ich optimistisch, dass alle Programme, die ich <br>> verwende, bei meinen Anwendungen keine Fehler machen. Beim <br>> Gehaltsprogramm bin ich allerdings gezwungen, dies zu glauben. Das <br>> macht mich schon nervös.<br><br>sie verlassen sich so oft am tag darauf das programme keine fehler<br>machen: vom<br>aufzug, über die ampel, die steuerung der strassenbahn/u-bahn/eisenbahn ...<br><br>mfg<br>August Hörandl<br><br>-- <br>August Hörandl              august.hoerandl@gmx.at<br>Linux. It is now safe to turn on your computer.<br>--<br>Diese Liste wird vom Computer Communications Club (http://www.ccc.at) betrieben. Um sich aus der Liste austragen zu lassen, senden Sie ein e-mail an majordomo@ccc.at mit dem Befehl "unsubscribe lehrerforum" im Nachrichtentext.<br>