Fehlerfrei programmieren möglich?
-
Zwergli schrieb:
Software kann niemals fehlerfrei sein ab einer bestimmten größe. Da gibst wissenschaftliche abhandlungen drüber und es ist mathematisch bewiesen. Natürlich kann man durch qualitätsmanagement die fehlerzahl minimieren, aber wer behauptet seine software ist fehlerfrei der hat nur nicht genug getestet. Und wenn viel getestet wird, wer testet die testfälle? Usw. Dann kommt noch die hardware mit dazu die immer unvorhersagbare fehler produzieren kann...
Naja, wissenschaftliche Abhandlungen sind so ne Sache... Man muß auch auf dem Gebiet nicht allem glauben schenken was geschrieben wurde... Man kann jedes große System in mehrere kleinere Einzelsysteme zerlegen. Wenn die Einzelsysteme nur klein genug werden, sind sie durchaus fehlerfrei zu bekommen. Also warum sollte jetzt der Zusammenschluß einzelner, fehlerfreier Systeme auf einmal wieder fehler produzieren? Entropie?
Klar ist moderne Software voller Fehler, aber schonmal dran gedacht das dies einfach darauf basiert das man so mehr Profit machen kann? Zum einen kostet schlampige Arbeit mit billigen Entwicklern und ohne QS weniger Geld. Zum anderen hat man so immer die Rechtfertigung wenn man ein paar Jahre später dann ein neues, vorgeblich verbessertes Produkt auf den Markt wirft...
Nimm mal als Gegenbeispiel so einen modernen Airbus. Das ist hochkomplexe Hardware mit ausgefeilter Software. Und ich denke das es weder Glück noch Zufall die Dinger in der Luft hält...
-
früher, als die leute noch mit lochkarten programmiert haben, gabs nicht so komfortable debugger wie heute
die haben ihren "source" (also ihre löcher) mehr als einmal gelesen
es gibt auch sourcen die erstmal von 2 firmen "korrekturgelesen" werden. zB bei bankautomaten-software. also müsste es theoretisch möglich sein fehlerfreie software zu schreiben... aber wer will das schon?wie heisst es so schön:
wenn debuggen der prozess ist, fehler dem programm auszubauen,
so ist programmieren der prozess, fehler in das programm einzubauen
-
busse schrieb:
Also warum sollte jetzt der Zusammenschluß einzelner, fehlerfreier Systeme auf einmal wieder fehler produzieren? Entropie?
Du hast offenbar keine Ahnung von größerer Software ^^
-
kenner der noobs schrieb:
busse schrieb:
Also warum sollte jetzt der Zusammenschluß einzelner, fehlerfreier Systeme auf einmal wieder fehler produzieren? Entropie?
Du hast offenbar keine Ahnung von größerer Software ^^
Oder aber ich stelle nur etwas in Frage das alle als Naturgesetz hinnehmen..
Beispiel:
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?
Das "größere" Software auch fast garantiert Fehler hat liegt eher daran, daß dort fast immer auch viele Menschen zusammenarbeiten und diese es nicht schaffen auch wirkich fehelrfreie Einzelmodule zu produzieren. Amlabgesehen davon das oft schon die Grundlage (Betriebssystem, Compiler, Libraries) bereits so dermassen Fehlerbehaftet ist das es unmöglich ist darauf fehelrfreie Software zu entwicklen.
Die meisten machen sich das aber sehr leicht: Es ist halt so, und ergo muß man gar keine Anstrengungen unternehmen daran etwas zu ändern, weil es ja ein Naturgesetz ist... Eines der aktuellsten Beispiele dafür war Sigil (Vanguard of Heroes) die mal eben 20 Millionen Dollar versenkt haben und für das ganze Projekt EINEN (!) QS-Mitarbeiter hatten. Begründung des Verantwortlichen: Morgs sind so komplex, die kann man eh nicht testen...
-
busse schrieb:
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?
Weil man Module nicht additieren kann. Der Addtionsbefehl geht fehlerfrei, ein Vergleich auch, eine Zuweisung auch usw., aber wieso gibts dann Fehler, wenn man alle diese einzelnen Befehle zusammenfügt.
-
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.