Was ist Ihrer Meinung nach die Hauptursache für Softwarefehler (und wie kann man sie minimieren)? [Geschlossen]

Ich definiere den Defekt als:

"Etwas innerhalb des Anwendungsdesigns oder Codes, das verhindert, dass es gemäß den Anforderungen funktioniert."

Ich suche nach Ideen zu den Ursachen von Fehlern, z. B. dem Faktor Mensch, fehlenden Tests, fehlenden Prototypen und möglichen Ideen, um diese zu mindern.

Die Hauptursache für Softwarefehler ist die Interpretation.

Die Interpretation eines Merkmals durch den Kunden unterscheidet sich von der Interpretation durch den Designer.

Die Interpretation des Designers unterscheidet sich von der Interpretation des Programmierers.

Die meisten Methoden haben Wege gefunden, um diesem Effekt entgegenzuwirken. Aber am Ende sind wir nur Menschen und wir sind nicht makellos. Außerdem herrscht oft Zeitdruck und die meisten Methoden werden oft übersprungen, wenn sie unter Druck stehen.

Tests können die Probleme nur frühzeitig erkennen. Aber auch Tester sind Menschen, und es ist unmöglich, 100% zu testen. Wenn du loslassen willst, bevor das Universum endet.

Ich betrachte die Hauptursache für Softwarefehler als Programmierer.

Das soll nicht nur lustig sein, sondern auch, weil eines der großen Probleme, die ich bei meiner Arbeit festgestellt habe, das Sammeln schlechter Anforderungen ist, verbunden mit einem schlechten Verständnis der Problemdomäne, was zu schwerwiegenden Fehlern und Usability-Problemen im Projekt führt.

Ein Teil davon ist darauf zurückzuführen, dass man nicht bereit ist, die Terminologie des Endbenutzers zu lernen / zu verstehen, was zu Missverständnissen führt.

Ein Teil davon rührt daher, dass zu früh im Prozess über Technologie gesprochen wird, wenn Leute keine Ahnung haben, wovon Sie sprechen oder warum es darauf ankommt.

Das beste Beispiel dafür war, als ich hörte, wie einer der Programmierer versuchte, herauszufinden, wie lange die Fragen / Antworten in Zeichen sein würden ... Ich wusste, dass er versuchte, herauszufinden, welche Feldgröße in der Datenbank verwendet werden sollte, aber das Die Abteilung, die dies anforderte, hatte nicht den geringsten Grund, warum das von Bedeutung war - oder dass Leerzeichen gezählt wurden. Für uns scheint das offensichtlich, aber für sie war es eine echte Offenbarung.

Die Hauptursache für Mängel ist schlechtes Management ;)

Im Ernst, ein Entwickler, der in gutem Zustand arbeitet, der nicht überarbeitet werden muss, der Qualität einschränkt, über geeignete Werkzeuge, ruhige Arbeitsbedingungen usw. verfügt, wird weniger Fehler produzieren als jemand, der unter starkem Druck arbeitet.

Das Management, das schlechte Entwickler einstellt, hilft auch dabei, die Anzahl der Fehler zu erhöhen.

Schlechtes Management .

(Haftungsausschluss: Ich soll Entwickler einstellen und verwalten)

Ich sehe keine primäre Ursache - aber eine Ursache, die nicht erwähnt wurde, ist die unbeabsichtigte Kopplung mit anderem Code . Das Schreiben von Code mit unsichtbaren Nebenwirkungen, das Durchbrechen von Abstraktionsebenen, die Annahme von Daten (Variablen werden nicht, Konstanten werden nicht und keine Benutzereingaben sind sicher) und das Unmengen von Dingen, die nicht betroffen sein müssen sich mit und so weiter.

Die meisten der von mir untersuchten Entwicklungspraktiken beschränken sich auf das Reduzieren N, da die Komplexität eines Programms zumindest O(N^2)und möglicherweise sehr hoch ist O(k^N). Das Definieren Nist eine Übung für den Leser, aber ich denke hier an Dinge wie die zyklomatische Komplexität. Das Einkapseln von Logik und Daten bewirkt das Reduzieren von N durch Unterteilen des Problems.

Die Unfähigkeit, an alles zu denken.

Unvollständig sein

Kommunikationslücke. In der Anforderungserfassung. Im Zeitplan. Im Designdokument. In funktionaler Spezifikation. Im Code (Lücke zwischen dem, was der Programmierer will und dem, was er dem Compiler sagt).

Soziale Etikette. Es ist sozial inakzeptabel, jemanden als unfähig zu bezeichnen.

Anstürmen in Dinge, ohne sie vollständig zu verstehen. Beginnen Sie mit dem Schreiben von Code, ohne die funktionalen Anforderungen oder die technische Architektur vollständig zu verstehen.

Die Programmierung sollte fast automatisch erfolgen, indem nur das notiert wird, was selbstverständlich ist und bereits im Kopf erarbeitet wurde. In der Praxis gibt es viele Fehler im Code, die versuchen, genau zu bestimmen, was der Code tun soll. Ich habe mich selbst oft schuldig gemacht.

Errare humanum est

Zeitplan Druck ist certianly eine starke Quelle.

Eilige Entwickler nehmen sich nicht die Zeit, die Anforderungen vollständig zu spezifizieren oder die Absichten hinter den Anforderungen vollständig zu verstehen oder Alternativen vollständig zu untersuchen, um die beste Lösung zu finden, oder alle Randfälle und Wechselwirkungen der von ihnen vorgenommenen Änderungen vollständig zu überdenken, oder Entwickeln Sie einen vollständigen Satz von Testfällen oder führen Sie den gesamten Komponententest oder einen vollständigen Integrationstest durch oder berücksichtigen Sie Plattformabhängigkeiten vollständig, testen Sie das Installationsprogramm vollständig oder dokumentieren Sie vollständig, was sie getan haben, damit der nächste Entwickler verstehen kann ....

Eine andere Sache, die erwähnt werden sollte, ist, keinen Außenseitertest zu haben. Wenn der Entwickler die Tests schreibt und ausführt, testet er nur seine Interpretation, nicht die tatsächliche Anforderung. Während von den Entwicklern geschriebene Komponententests nützlich sind, um einige Fehler zu erkennen, haben die meisten Fehler diese Tests bestanden, entsprechen jedoch nicht den Wünschen oder Bedürfnissen des Benutzers. Jede Software, die nicht von einer anderen Person als dem Entwickler getestet wurde, wird nicht getestet (und damit meine ich nicht, nur die Tests des Entwicklers auszuführen).

Das liegt daran, dass Software-Engineering von Natur aus komplex ist. Der Aufsatz "No Silver Bullet" diskutiert dies.

Ironischerweise berühren viele der anderen Antworten in der Sprache dieses Aufsatzes Themen, die "aus Versehen komplex" sind, während in Wirklichkeit das meiste, was Softwareentwickler tun, "im Wesentlichen komplex" ist Software ist schwierig, Software wird Fehler enthalten, und wir müssen damit umgehen.

Das Versagen, Software als ein Netzwerk von Zustandsautomaten zu verstehen, die Prinzipien, die ihrem Betrieb zugrunde liegen (Zustände, ihre Bestimmung und Übergänge), und die Wechselwirkungen der Zustandsautomaten.

Schreiben von Code, der unbemerkt fehlschlägt, im Vergleich zu Code, der alle Fehler meldet.

Das Fehlen einer Überprüfung auf Dinge, die "nicht passieren können" oder wahrscheinlich nicht passieren werden, ist ein großes Problem. Manchmal ist das Vollkommene der Feind des Guten. Wenn es sich nicht lohnt, eine gut durchdachte Ausnahmehierarchie zu verwenden, ist eine schnelle und schmutzige Handhabung immer besser als nichts. Ich bin ein RieseFan von schnellem Scheitern, von Asserts und davon, Asserts zu hinterlassen, die einen vernachlässigbaren Einfluss auf die Leistung in Release-Builds haben. Sogar in schnellen und schmutzigen einmaligen Skripten, in denen ich alle Eingabedaten kontrolliere, habe ich eine schnelle / schmutzige Fehlerbehandlung vorgenommen, normalerweise nur mit einer Funktion, die dem Assert entspricht, aber die ganze Zeit aktiv bleibt. Meine Faustregel ist, dass, wenn es nicht wahrscheinlich ist oder Sie denken, dass es nicht passieren kann, es nicht ordnungsgemäß mit einer benutzerfreundlichen Fehlermeldung fehlschlagen muss, aber es sollte zumindest schnell mit einer Fehlermeldung fehlschlagen, die gibt einem Programmierer einige Hinweise, was schief gelaufen ist.

Bearbeiten: Eine nützliche Taktik besteht darin, Asserts als wichtiges Debugging-Tool zu verwenden und sie dort zu belassen, nachdem die Debugging-Sitzung beendet ist. Ab diesem Zeitpunkt verfügt Ihre Codebasis über einige integrierte Sicherheitsprüfungen, die es sehr schwer machen, dass verwandte Fehler jemals wieder auftreten. Dies ist besonders nützlich für Code, der schwer zu unittest ist.

Die Hauptursache für Softwarefehler ist das Schreiben von Code.

Schreib weniger Code und du wirst weniger Bugs haben ;-)

Auf einer Ebene Management. Aber es ist nicht nur die PHB. Es ist die Verwaltung des Codes selbst, die ein Spiegelbild der Unternehmensführung sein kann oder nicht.

Die Teilnehmer am gesamten "Lebenszyklus" müssen voll in Qualität investieren und ein Produkt herstellen, das einfach nicht stirbt . Software selbst hat das Versprechen, niemals zu brechen, vorausgesetzt, die Abstraktionszuverlässigkeit stimmt. Es ist nur eine Frage, ob die Software-Konstrukteure daran interessiert sind, diese perfekte Operation zu haben.