Wendet sich die Badewannenkurve an moderne Software? [geschlossen]
Natürlich verschleißt Software nicht, aber vor ein paar Jahrzehnten wurde allgemein angenommen, dass spät in der Lebenszyklus-Code-Wartung des Programms mehr Bugs eingeführt werden, als es behebt.
Aber gilt die Badewannenkurve auch für die moderne Software, die mit modernen Software-Engineering-Methoden entwickelt wurde?
5 Antworten
Kurze Antwort ist "Ja". Lange Antwort ist, dass die Verteilung der Badewanne kein sehr gutes Modell ist, wegen der mangelnden Kontinuität in der Art, wie Fehler funktionieren. Sagen wir zum Beispiel, dass ein Eingabewert von 42 einen Fehler durch Division durch Null verursacht; dann ist die Verteilung dieser Fehler genau die Verteilung von 42 Werten in der Eingabe. Es ist nicht wie Hardware, wie du sagst: Software versagt nicht im Laufe der Zeit, sie versagt, wenn sie falsch ist.
Nun könnte es sein, dass Sie die Wörter hier missbrauchen: Sie meinen einen Fehler und nicht einen Fehler . Ein Fehler ist ein Auftreten von falschem Verhalten. Ein Defekt ist ein Fehler in der Implementierung, ein "Bug".
Das Auftreten von Defekten in Software tendiert dazu, eine badewannenartige Verteilung zu haben, aber es ist wirklich nicht annähernd so sauber wie Ihr Bild: Bugs werden eher früh beobachtet und verschwinden, dann spike auf Patches und neuen Releases, mit einem allgemeinen Aufwärtstrend beginnend weiter in das Leben der Software. Aber selbst das erfordert eine sorgfältige Definition, da es sich tatsächlich um Defekte handelt, die pro Zeiteinheit beobachtet werden.
Nachdem wir das gesagt haben, neigen moderne SE-Praktiken dazu, die tatsächlichen Raten zu ändern, nicht aber die Verteilung der beobachteten Defekte im Laufe der Zeit. "Modern" ist auch hier eine kleine Definition wert: Die Space Shuttle HAL-Software hat sehr geringe Fehlerraten, indem sie SE-Techniken verwendet, die vor 20 Jahren "modern" waren: starke Spezifikation, strukturierte Programmierung, strenge Überprüfung und OCD-Versionskontrolle. Extreme Programming tendiert dazu, niedrige "Fehlerraten" zu haben, aber viele der Dinge, die traditionellere Methoden als "Fehler" bezeichnen, nennt XP "User Input" - da es keine endliche und rigorose Definition dessen gibt, was tun sollte Ein "Defekt" ist nur eine andere Geschichte.
Es hat anständige Studien gegeben, die zeigen, dass XP / TDD zu niedrigen Fehlerraten führt, aber ich wäre sehr überrascht, wenn die Defekte / Zeiteinheitsverteilung eine andere Form hat.
Die Badewannenkurve ist wirklich ein Deskriptor für Hardwarefehler (und zwar ein guter, nicht Software).
Es gibt jedoch etwas Ähnliches mit der Software. Im Allgemeinen hat unsere Fähigkeit, Komplexität zu erzeugen, in den meisten Software-Produktionen unsere Fähigkeit, damit umzugehen, leicht übertroffen --- i.o.w. Es gibt eine Art von Peter Principal bei der Arbeit, wo Software-Systeme (kollektiv) in Komplexität wachsen, bis sie nicht mehr handhabbar sind und dann dort bleiben. Während wir heute einige der systemischen Probleme der 1990er viel besser bewältigen können, als wir damals waren, sind wir nicht viel besser im Umgang mit den systemischen Problemen der 00er Jahre. So ist das Leben.
Ich denke aber, das sieht nicht ganz nach einer Badewanne aus.
Nicht wirklich, die meisten Fehler werden während der anfänglichen Bereitstellung der Software gefunden. Danach ist es in der Regel eine schrittweise Reihe von Fehlern, meist durch Änderungen am Code oder durch Hinzufügen neuer Funktionen. Nichts wie die ursprüngliche Codeversion. Wenn die Entwickler, die das ursprüngliche Produkt hergestellt haben, absterben und die Upgrades aufhören, werden auch die Bugs zum Stillstand kommen.
Ich denke, es gibt eine (kleine) Wahrheit in der Grafik. Nach der ersten oder zweiten Veröffentlichung, haben Sie neue Funktionen und neue Bugs eingeführt, zusammen mit den Bugfixes früherer Bugs. Ich denke, Sie haben ständig neue Bugs. Aber nach einiger Zeit wird die Codebasis fragil und schwer zu pflegen, und so glaube ich, dass der Fluss neuer Bugs stark ansteigt. Dann können Sie (hoffentlich) endlich Ihre Chefs dazu bringen, mit dem Patchen aufzuhören und mit dem Reengineering zu beginnen.
Ich denke, vieles hängt davon ab, wie gut es gepflegt wird. Ich habe eine große GUI-Anwendung, bei der ich praktisch der einzige Programmierer bin, der es verwaltet hat, und seine Fehlerhäufigkeit hat im Laufe der Jahre stetig abgenommen, und ich erwarte nicht, dass es irgendwann in der Zukunft hochgehen wird.
>Aber hätte ich es einem Junior-Programmierer überlassen, würde ich das nicht genauso fühlen, da es eine große Versuchung für einen Maintenance-Programmierer gibt, eine "gute" und nicht die "richtige" Lösung zu programmieren. Ich kann ihm nicht die Schuld geben, er hat wahrscheinlich nicht den Code, den der ursprüngliche Programmierer gemacht hat.
Was die rechte Seite der Badewanne betrifft, so kann es, wenn Sie externe Faktoren wie Betriebssysteme berücksichtigen, eine gewisse Korrelation geben, da ich einige Apps hatte, die neuere Windows-Versionen kaputt machten, normalerweise ohne Fehler durch die App . Aber das ist eine relativ kleine Zahl.
Tags und Links qa