Fehlerfrei programmieren möglich?
-
Weil ein Softwarefehler (Logisch),
kann sich gegen ein anderen aufheben, oder
kann andere Fehler verschlimmern, evtl
führt dich unter anderem flasche Schlusskommt aber immer an in welchen Kontext der Fehler auftitt.
-
busse schrieb:
Einfache addition: 1 + 3 = 4, 2 + 3 = 5, 4 + 2 = 6
Jede einzelne dieser Teiladditionen ist offensichtlich fehlerfrei.1 + 3 + 2 + 3 + 4 + 2 = 15
der "Theorie" zufolge müßte dann in dem Zusammenschluß vieler Additionen automatisch ein Fehler entstehen, auch dann wenn alle Einzeladditionen richtig sind... Also stelle ich die Frage wieder, warum "muss" der Zusammenschluß einzelner, fehlerfreieer Module automatisch zu Fehlern führen?
Du verwendest dassselbe Modul mehrfach! Nehmen wir zwei verschiedene Module, einmal Addition, einmal Multiplikation. Bei beiden sei die Korrektheit bewiesen. Jetzt schalte ich sie zusammen: a + b * c. Und stelle fest, dass ich nicht an die Priorisierung gedacht habe. Beim Zusammenschluss verschiedener Module entstehen automatisch zusätzliche Anforderungen.
Dein Argument läßt sich noch viel leichter widerlegen. Eine CPU beispielsweise beherrscht eine Menge elementarer Funktionen, die normalerweise alle fehlerfrei sind, z.B. auch Additionen. Softwarefehler entstehen erst beim Zusammenschalten dieser Module.
-
Naja, theoretisch kann wohl jede Software fehlerfrei sein.. Die Wahrscheinlichkeit, irgendwas übersehen zu haben, ist einfach nur irre groß. Und ich denke nicht, dass man bei "fehlerfreier Software" die Fehler der Hardware einberechnen sollte. Man muss sich schließlich darauf verlassen können, dass der Prozessor richtig rechnet.
-
windox schrieb:
Nachtwind schrieb:
Man koennte damit antworten: Schau dir mal grosse Software an - faellt dir auf anhieb auch nur eine Software ein, die Fehlerfrei ist?
Linux?
*lol*
-
Hat hier eigentlich schon jemand mal überlegt, was ein "Fehler" überhaupt ist ?
Die "Fehler" unserer Software waren jedenfalls zu 70% Aspekte, die
- genauso funktionierten wie vom Kunden gefordert,
- ihm aber (wie wir ihm vorausgesagt hatten) nicht wirklich weiterhalfen/überforderten und
- später (auf seine Kosten) durch Brauchbares ersetzt werden mussten.
Gruß,
Simon2.
-
Simon2 schrieb:
Hat hier eigentlich schon jemand mal überlegt, was ein "Fehler" überhaupt ist ?
Die "Fehler" unserer Software waren jedenfalls zu 70% Aspekte, die
- genauso funktionierten wie vom Kunden gefordert,
- ihm aber (wie wir ihm vorausgesagt hatten) nicht wirklich weiterhalfen/überforderten und
- später (auf seine Kosten) durch Brauchbares ersetzt werden mussten.
Gruß,
Simon2.
bezeichnet ihr change requests als bugs?
-
Laut ITIL werden auch Bugs als CRs geführt.
-
wayne gf schrieb:
...bezeichnet ihr change requests als bugs?
Nein - aber unsere Kunden.
"Ey ! Tut ja gar nicht !!! Soooo haben wir das aber nicht gewollt - könnt Ihr eigentlich keine fehlerfreie Software machen ?"
Es ging mir mit meinem Beispiel auch nur darum, dass der Begriff "Fehler" recht dehnbar ist ... letztlich ist kein Programm "falsch", weil es immer das tut, was in seinem Quellcode steht. Aber evtl. steht im Quellcode etwas anderes als der Programmierer, sein Kollege/Chef/Kommunikationspartner/Kunde/... gedacht hat ... oder inzwischen gerne hätte.
Gruß,
Simon2.
-
na klar.. ich Programmiere immer Fehlerfrei..
Wer denkt das nich;)
-
Hallo
Ich.
chrische
-
sagen wir mal change request sind kommunikationsbugs.
-
BorisDieKlinge schrieb:
na klar.. ich Programmiere immer Fehlerfrei..
Wer denkt das nich;)Leider ist viel weniger witzig als es scheint... Wiel viele Programmierer so denken und man oft unnötige Zeit damit verbringen muß diesen Leuten zu "beweisen" das sie doch einen Fehler gemacht haben bis sie sich dann dazu bequemen diesen zu beseitigen...
-
wayne gf schrieb:
sagen wir mal change request sind kommunikationsbugs.
Selbst das stimmt nicht immer. Schließlich "dreht sich die Welt weiter", so dass neue Features gebraucht, Richtlinien umgesetzt, ... werden müssen.
Und schließlich gibt es auch noch "mangelnde Kompentenz" als Auslöser für spätere CRs... dabei ist "mangelnde Kompetenz" bisweilen zwangsläufig bei neuen Verfahren.Gruß,
Simon2.
-
Naja, also wenn man was neues braucht, würde ich nicht mehr von bug sprechen.
-
wayne gf schrieb:
Naja, also wenn man was neues braucht, würde ich nicht mehr von bug sprechen.
Aber von einem "Change Request", oder ?
Es bleibt einfach dabei, dass CRs und bugs zwar eine gemeinsame Schnittmenge haben, aber nicht das eine durch das Andere definiert werden kann.Gruß,
Simon2.
-
wayne gf schrieb:
Naja, also wenn man was neues braucht, würde ich nicht mehr von bug sprechen.
Du mußt das anders sehen - unter Umständen folgt eine Funktion im Programm genau der Spezifikation der Anwender, wird aber später dann als "umständlich" oder "anders" empfunden, weil sie nun dynamisch wahrgenommen wird. Ein Benutzer wird das Programm dann als fehlerhaft bezeichnen, obwohl es perfekt funktioniert.
Diesen Fehlertyp "korrekte Implementierung bei falscher Spezifikation" habt Ihr noch gar nicht berücksichtigt. Auch das gehört zum Thema Programmierfehler, man darf nicht immer nur Abstürze denken. Bei diesen Abweichungen spielt es kaum eine Rolle, ob nun der Programmierer die Anwender falsch verstanden hat, oder sich der Anwender falsch ausdrückte, oder ob sich die Anforderungen im Laufe der Zeit geändert haben. Es gibt am Ende eine Abweichung des Ist-Verhaltens vom benötigen Soll-Verhalten, landläufig also "Softwarefehler".
-
Ach Marc++us !
Endlich jemand, der mich versteht !
Gruß,
Simon2.
-
Also stellen wir nur bugs her, weil man ja immer was neues und besseres machen kann
-
hab vor paar jahren mal an ner software mitgearbeitet, die benutzt wurde, um bestimmte klientendaten zu erfassen. in einer version hatten wir auf wunsch einiger kunden eine "drastische" änderung vorgenommen: vorher hat das programm jede eingabe sofort gespeichert. nach der änderung erst nachdem man explizit das aktuelle "projekt" gespeichert hat (wie man es halt aus der meisten standardsoftware kennt).
nach dieser änderung bekamen wir so dermaßen viele "bugreports", dass die anwendung nicht mehr korrekt speichert, dass wir es rückgängig machen mussten.
viele fehler sind subjektiv ^^
-
wayne gf schrieb:
Also stellen wir nur bugs her, weil man ja immer was neues und besseres machen kann
Das ist durchaus ein bedenkenswerter Einwand!
Trotzdem nicht zutreffend, man sollte eindeutig sagen:
Abweichung des Programms zum Zeitpunkt t(x) von der Spec zum Zeitpunkt t(0) ist ein Programmfehler. Eine neue Spec zum Zeitpunkt t(x) und die daraus folgende Abweichung zum Programm zum Zeitpunkt t(x) ist kein Fehler.