Fehlerfrei programmieren möglich?
-
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.
-
Fehlerfreie Software ist veraltet
-
Hi,
letztlich zählt nicht, ob eine Software "fehlerfrei" ist, sondern ob der Kunde zufrieden ist. Da hilft es zwar immer, wenn ein Programm wenig Fehler macht ... aber es reicht sowieso nicht.
... und wenn der Kunde gute Benutzerführung/Funktionalität/Performance, kurze Fehlerbehebungszeiten, freundliche und kompetente Support, kulanten Vertrieb, ... erlebt, spielt es eine geringere Rolle, ob das Programm noch ein den einen oder andern Fehler hat.Gruß,
Simon2.
-
Simon2 schrieb:
letztlich zählt nicht, ob eine Software "fehlerfrei" ist, sondern ob der Kunde zufrieden ist.
Aha, das ist schon fast eine Tautologie. Problem ist, dass der Kunde in dem Moment nicht mehr zufrieden ist, in dem ein wirklich kritischer Fehler auftritt, an dem richtige Sachschäden oder gar Personenschäden hängen.
-
Bashar schrieb:
Simon2 schrieb:
letztlich zählt nicht, ob eine Software "fehlerfrei" ist, sondern ob der Kunde zufrieden ist.
Aha, das ist schon fast eine Tautologie. Problem ist, dass der Kunde in dem Moment nicht mehr zufrieden ist, in dem ein wirklich kritischer Fehler auftritt, an dem richtige Sachschäden oder gar Personenschäden hängen.
Ist keine Tautologie, weil "Fehlerfreiheit" weder automatisch Kundenzufriedenheit bedeutet noch zwingende Voraussetzung für sie ist.
Ich bin immer noch der Ansicht: Hauptziel MUSS "Kundenzufriedenheit" bedeuten und nicht "Fehlerfreiheit".
Es gibt genug "fehlerfreie" Software, mit der der Kunde unzufrieden ist (bzw. solche die auf dem Weg zur "Fehlerfreiheit" eingestampft wird) als auch "fehlerbehaftete", die den Kunden glücklich macht.Gruß,
Simon2.
-
CengizS schrieb:
Fehlerfreie Software ist veraltet
Sehr schön doppeldeutig in diesem zusammenhang.
-
Simon2 schrieb:
Ist keine Tautologie, weil "Fehlerfreiheit" weder automatisch Kundenzufriedenheit bedeutet noch zwingende Voraussetzung für sie ist.
Das hab ich gar nicht behauptet.
-
Bashar schrieb:
Simon2 schrieb:
Ist keine Tautologie, weil "Fehlerfreiheit" weder automatisch Kundenzufriedenheit bedeutet noch zwingende Voraussetzung für sie ist.
Das hab ich gar nicht behauptet.Klang mir halt so.
Gruß,
Simon2.