Fehlerfrei programmieren möglich?



  • 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.


Anmelden zum Antworten