Fehlerfrei programmieren möglich?
-
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.
-
Marc++us schrieb:
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.
Naja, so ne theoretische Betrachtung bringt in der Praxis natürlich nichts. Außerdem stimmts nur, wenn die Spezifikation fehlerfrei ist.
-
thordk schrieb:
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 ^^
Den letzten Satz unterschreibe ich sofort...
Ich musste fuer meine Schule mal ein Programm schreiben, dass das spielen von 'Killerspielen' verboten hat. Prinzip ist einfach - Liste mit bekannten Dateinamen und Fenstertiteln von spielen erstellen und falls sowas gestartet wurde: Holzhammer. Erst Programm beenden und warnen. Nochmal Programm beenden letztes mal warnen - System neustarten.
Leider haben sich einige Lehrer danach bei mir beschwert, dass bei vielen Schuelern dauernd die rechner im Infounterricht ausgingen.
Kurzes log spaeter stellte sich heraus, dass das in allen faellen an HalfLife lag...Fehler sind definitv subjektiv..
-
Von TeX behauptet man, es sei fehlerfrei...
-
uhu uhu lolol schrieb:
Marc++us schrieb:
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.
Naja, so ne theoretische Betrachtung bringt in der Praxis natürlich nichts. Außerdem stimmts nur, wenn die Spezifikation fehlerfrei ist.
*g*
Das ist keine theoretische Betrachtung, sondern die Zusammenfassung der Praxis in eine Formelschreibweise. Allerdings wird das von Nicht-Praktikern häufig als Theorie betrachtet - mangels Verständnis für Theorie und Praxis.