Diskussion:Programmfehler/Archiv/2020

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Programmfehler/Archiv/2020#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:Programmfehler/Archiv/2020#Thema_1

Fehler pro Zeilen Quellcode

Ich sehe keinen Sinn darin, die Stabilität an der Anzahl Fehler pro Zeilen Quellcode zu definieren, und noch weniger darin, einen fixen Schwellwert anzugeben. Dass Zeilenanzahl generell eine wenig aussagekräftige Softwaremetrik ist, hat sich in der Branche längst herumgesprochen, und die Stabilität kann auch nicht sinnvollerweise durch die Fehleranzahl definiert werden, da ein Fehler ganz unterschiedliche Auswirkungen auf die Stabilität haben kann. Da ausserdem keine Quelle angegeben ist, lösche ich den Satz einfach mal raus. --Zumbo (Diskussion) 09:44, 12. Mär. 2020 (CET)

Ich gebe dir grundsätzlich Recht: Vor allem auch deshalb, weil die Aussage ohne Bezug auf eine Programmiersprache getätigt wird. Trotzdem denke ich, dass in eine Messgröße für Fehlerdichte in irgendeiner Weise die Größe des Programms einfließen muss; denn es ist ein Unterschied, ob z.B. "2 Fehler" in einem 100 Statement-Programm (Modul?) oder in einem mit 5000 Statements existieren. Zusätzlich: Diese Größe muss unterstellen, dass es sich um "bisher gefundene Fehler" (was auch immer der Zeitbezug ist) handeln kann. Weiterhin müsste man nur echte Anweisungen (keine Kommentare etc.) als Grundlage heranziehen. Vielleicht kann man die Quelle finden - die dann Konkreteres belegen sollte. --VÖRBY (Diskussion) 11:02, 12. Mär. 2020 (CET)

Der Abschnitt Fehlerquotient#Fehlerdichte in der Informatik geht näher auf diese Metrike ein und enthält auch zahlreiche Quellenangaben. Ich denke, man sollte auf diesen Artikel per 'Hauptartikel'-Link verweisen - oder auf eine der dortigen Referenzen. --VÖRBY (Diskussion) 16:41, 12. Mär. 2020 (CET)

In [1] wird u.a. die Messgröße 'lines of Code' behandelt und diskutiert. Sie sei "im praktischen Einsatz meist ungenau" und "nur ein grobes Maß für die ,,Menge`` an Software". Ihre Definition werde "eventuell durch das Weglassen von leeren Zeilen und Kommentarzeilen, eventuell auch Deklarationszeilen modifiziert". Sie sei "nur für den gleichen Programmierer im gleichen Problembereich und mit der gleichen Programmiersprache direkt vergleichbar". Das sollte man in 'Fehlerquotient' nachtragen, bei Programmfehler auch die Aussage, dass alternativ "Function Points" als Bezugsgröße für die Fehleranzahl verwendet wird. --VÖRBY (Diskussion) 17:08, 12. Mär. 2020 (CET)

Es geht um den Satz: "Programme mit einer Fehlerdichte von weniger als 0,5 Fehlern pro 1000 Zeilen Quelltext gelten als stabile Programme."

In Fehlerquotient#Fehlerdichte in der Informatik steht dazu was inkl. jeder Menge Belege. Sollte mMn hier auch eingebaut bleiben. Hab größtenteils ich dort belegt (d.h. ich hab auch Zugriff auf die Literatur) und auch teilweise geschrieben.

Zu den von euch geäußerten Kritikpunkten:

• Ja Zeilenanzahl ist keine perfekte Metrik, ist aber die Metrik zu der es mit Abstand am meisten Untersuchungen gibt. Es gibt jede Menge Untersuchungen an teils zig tausenden Projekten hinsichtlich Zeilenanzahl. Einige Dinge korrelieren eindeutig mit Zeilenanzahl, einige Dinge nicht.
• Mit Stabilität (in der Literatur steht wirklich "stable") kann vieles gemeint sein - in der Literatur wird hinsichtlich Fehlerrate Software in stabil, reifend, labil, fehleranfällig und unbrauchbar unterschieden. Gebe @Zumbo: aber recht, "stabil" kann was ganz was anderes auch bedeuten und sollte erklärt werden.
• Ja die Metrik ist unabhängig von Programmiersprachen. Liegt vermutlich an den 10 bis 50 Codezeilen je Mitarbeiter und Tag (siehe Lines of Code.
• Da es um 0,5 Fehler pro 1000 Zeilen geht, ist der Unterschied 100 vs. 5000 Statements damit eh implizit
• Es geht nicht um "bisher gefundene Fehler", sondern insgesamt um Fehler, die (noch) in der Software sind.
• Grundlage für die Berechnung ist immer (source) lines of code (d.h. ohne Kommentarzeilen oder Leerzeilen) --> sollte wie VÖRBY schreibt auch dort nachgetragen werden...

--Sebastian.Dietrich ✉ 17:15, 12. Mär. 2020 (CET)

Der Kritik in [2] gibts sicher noch einiges hinzuzufügen: generierter Code, Bezahlung nach Lines of Code, ... verfälscht das alles. Aber klar, wenn ich will, kann ich jede Metrik bewusst verfälschen. Für "Menge an Fachlichkeit" ist LOC auch keine geeignete Metrik, sehr wohl aber für "Größe der Software" und eben indirekt "Anzahl Fehler in der Software"... --Sebastian.Dietrich ✉ 17:19, 12. Mär. 2020 (CET)

Ich würde HIER im Artikel die bisherige Aussage allgemeiner ausdrücken (~"Je nach Art und Zweck der Software gelten unterschiedliche Fehleranzahlen, z.B. 0,5 pro 1000 LOC, als angemessen"), die Details aber (an einer zentralen Stelle) in Fehlerquotient belassen. Alternativ könne man die Details HIER einstellen und DORT nur verweisen; an beiden Stellen dasselbe wäre wohl Redundanz. --VÖRBY (Diskussion) 17:52, 12. Mär. 2020 (CET)

Textvorschlag: Als Qualitätsmerkmal für Programme kennt man u. a. die Fehlerdichte. Sie wird als Prozentwert in der Software noch vorhandener Fehleranzahlen im Verhältnis zur Gesamtanzahl der Programmzeilen ausgedrückt. Je nach Art und Zweck der Software gelten unterschiedliche Prozentsätze als Obergrenze anzustreben, z. B. 0,5% für kritische Anwendungen (etwa Militär, Krankenhaus). Alternativ nennt man die Fehleranzahl je Function Point. Weitere Details hierzu siehe Hauptartikel Fehlerqoutient.

Bitte QS, dann Aufnahme in den Artikel. Rest in Fehlerquotient einarbeiten? --VÖRBY (Diskussion) 18:46, 12. Mär. 2020 (CET)

+1 aber mit folgenden Kritikpunkten:

• Das Wort "Fehlerdichte" ist in der IT gängiger als "Fehlerquotient" (da es eben kein quotient ist - siehe nächster Punkt)
• Sie ist kein Prozentwert sondern pro KLOC (also z.B. "0,5 Fehler pro KLOC")
• Man muss die Einheit immer dazuschreiben "Fehler pro KLOC" oder "Fehler pro FPoint"
• Man kann auch die Fehlerdichte vor dem Test beschreiben - "noch vorhanden" stimmt also nicht immer.
• Der Satz mit der Alternative je Functionpoint ist unnötig, da drüber ohnedies "bzw. je Functionpoint" steht
• Lines of Code sollte genauso wie Function Point verlinkt werden und wenn schon englisch dabei idealerweise gleich die exaktere Bezeichnung SLOC nehmen und vielleicht gleich den Begriff KLOC reinbringen. Quellcode klingt mMn auch mehr nach SLOC als nach LOC

darum

Textvorschlag 2: Als Qualitätsmerkmal für Programme kennt man u. a. die Fehlerdichte. Sie bezeichnet die Anzahl an Fehlern pro 1.000 Zeilen Quellcode (Kilo Source Lines of Code oder KLOC) bzw. je Function Point. Je nach Art und Zweck der Software gelten unterschiedliche Zahlen als Obergrenze anzustreben, z. B. 0,5 pro KLOC für kritische Anwendungen (etwa Militär, Krankenhaus). Weitere Details hierzu siehe Hauptartikel Fehlerqoutient.

Kürzere Alternative, da der Satz ja in der Einleitung steht:

Textvorschlag 3: Als Qualitätsmerkmal für Programme kennt man u. a. die Fehlerdichte. Sie bezeichnet die Anzahl an Fehlern pro 1.000 Zeilen Code (Kilo Source Lines of Code) bzw. je Function Point.

--Sebastian.Dietrich ✉ 06:22, 13. Mär. 2020 (CET)

TV3 erscheint mir als guter Vorschlag. Ich würde auf jeden Fall noch auf den Hauptartikel verweisen wollen - und dort die oben diskutierten Zusätze mit der neuen Quelle ergänzen.

Man könnte dort auch noch anmerken, dass diese Messgröße irgendwie immer fiktiv bzw. nur ein Hoffnungs-/Zielwert ist, der erst nachträglich verifiziert/bewiesen werden kann - zB wenn man (wieder mal) Fehler gefunden hat. Sowohl als Zielwert als auch als ermittelte Größe gehört deshalb wohl zur Definition, dass die FD ab einem bestimmten Zeitpunkt gemeint ist; Fehlermengen zu Beginn des Testens sind anders zu sehen als im Produktionsbetrieb (etwa seit Abnahmetest; ist das implizit die 'gängige' Definition?).

Machst Du? Danke. --VÖRBY (Diskussion) 10:42, 13. Mär. 2020 (CET)

Gerne - ich versteh aber deinen ersten Satz "TV3..." nicht. Was meinst du mit verweisen (Link auf Hauptartikel macht mMn keinen Sinn, da es erst ab Fehlerdichte um Programmfehler geht)? Ich vermute du meinst Einbau der oben diskutierten Zusätze mit der neuen Quelle - das kann ich gerne machen.

@Fiktiv - ja. Man kanns zwar mit recht großer Bandbreite schätzen, aber richtig verifizieren kann mans nur mit formaler Spezifikation/Verifikation (auch wenn die Software schon ewig im Einsatz ist, hat sie u.U. noch Fehler)

@bestimmter Zeitpunkt - jein. Die Fehlerdichte ändert sich natürlich mit der Zeit, aber die dort genannten Zahlen beziehen sich immer auf die Fehlerdichte zum Zeitpunkt der Produktivsetzung. Das ("Zeitpunkt der Produktivsetzung") kann ich aber ergänzen und ich könnte auch noch Zahlen zur üblichen Fehlerdichte vor dem Test liefern... --Sebastian.Dietrich ✉ 20:23, 13. Mär. 2020 (CET)

Hallo, TV3 ist dein Textvorschlag3. Weil in 'Fehlerquotient' (#Informatik, dorthin sollte auch der Link zeigen) derzeit die meisten und wichtigsten Details behandelt sind, ist das der eigentliche 'Hauptartikel'. Oder wir drehen das um und nehmen das meiste der dortigen Aussagen hier bei Programmfehler auf - und verweisen aus ..Quotient nach Programmfehler. Aber auch in Programmfehler wären die Texte zu Dichte nur ein Nebenaspekt; insofern könnten wir die bisherige Textverteilung auf 2 Artikel auch so lassen. Egal wie: Die zahlreichen Detailaspekte von 'FD' sollten m.E. an einer Stelle stehen, in anderen Artikeln nur kurze Zusammenfassung(en) und Link auf den Hauptartikel(#Abschnitt). --VÖRBY (Diskussion) 09:28, 14. Mär. 2020 (CET)

Sebastian, danke für die Ergänzung. Der Link auf 'Fehlerdichte' ist ausreichend, ein zusätzlicher HA-Verweis deshalb überflüssig. ERLEDIGT!? Servus!--VÖRBY (Diskussion) 18:34, 14. Mär. 2020 (CET)

Ja mMn. mMn sollte der Hauptartikel weiterhin dort bleiben, weil dort spezifischer.

Mit dem Einbau der Kritik in [3] habe ich aber meine Schwierigkeiten, da sie 1) besser zu Lines of Code als zu Fehlerdichte passt (Fehlerdichte ist ja nur eine der Metriken, die auf LOC basiert) und 2) als Kritik nicht so geeignet ist, da sie unter 1.5.4 und 1.5.5. eigentlich beschreibt wie gut sie hier passen und 3) es meines Wissens nach überhaupt keine Metriken gibt, die exakt was aussagen, LOC somit nicht schlechter ist als alles andere... --Sebastian.Dietrich ✉ 20:02, 14. Mär. 2020 (CET)

Ich hatte die o.a. Ergänzungen weniger als Kritik empfunden denn als Präzisierung der Definition und Erweiterung um wesentliche Aspekte.

Ob sie besser zu LOC oder zu Fehlerdichte passen? Bisher sind die Details im wesentlichen bei FD beschrieben, was wohl auch ok ist. Insofern sollte man auch in FD ergänzen, um so ein vollständiges Bild zu bekommen.

Nochmal zu 'Zeitpunkt': Die Messgröße ist solange ein hypothetischer Erwartungswert, bis die Fehleranzahl bekannt ist - und das gilt dann immer für einen zurückliegenden Zeitraum, zB n Fehler seit Produktionssetzung (das wärend also erkannte!). --VÖRBY (Diskussion) 09:24, 15. Mär. 2020 (CET)

Eigentlich beschreibts nicht die erkannten Fehler, sondern alle. D.h. bleibt de facto für größere Programme immer hypothetisch, weil in der Praxis nie alle Fehler auftauchen. --Sebastian.Dietrich ✉ 19:25, 15. Mär. 2020 (CET)

Die Bestätigung ist also immer nur nachträglich möglich (Zielgröße=X > Realität=Y). Ich habe die m.E. für den Hauptartikel relevanten Elemente/Kriterien (in meinen Disk-Beiträgen) fett markiert, z.K. Machs gut, trotz Virus!--VÖRBY (Diskussion) 09:13, 16. Mär. 2020 (CET)

Beispielvideo

Beispiel für einen grafischen Programmfehler

Ich fand das von PantheraLeo eingebaute Beispielvideo sehr gut. Natürlich gibt es Millionen verschiedene Beispiele von Bugs, das Video zeigt aber ein Beispiel direkt aus der Wikipedia und etwas, was auf den ersten Blick den Artikelinhalt veranschaulicht. Daher möchte ich die Pauschalbegründung für den Revert, "ein Bsp von zig-Tausend - hier irrelevant", zurückweisen. --Wikiolo (D) 16:17, 31. Mai 2020 (CEST)

Der Artikel hier behandelt Programmfehler in ihrer Gesamtheit, siehe z.B. Abschnitt 'Arten von Programmfehlern'. Es werden u.a. die Ursachen beschrieben oder worin der Fehler konkret besteht - was das Video nicht zeigt. Es ist lediglich eine Erscheinungsform eines evtl. Fehlers. Der Ausdruck 'grafischer Fehler' kommt im Artikel auch nicht vor; was ist das? Das Video gleich in der Einleitung zu positionieren, entspricht auch nicht der Bedeutung des Artikels. Beispiele für konkrete Fehler zeigt (und beschreibt!!!) die Liste von Programmfehlerbeispielen.--VÖRBY (Diskussion) 17:13, 31. Mai 2020 (CEST)

Das Video soll ein Beispiel geben, wie sich ein Programmfehler auswirken kann und kann daher als Beispiel für ein Programmfehler in seiner Gesamtheit verwendet werden. Es ist auch nicht der Sinn einer eingearbeiteten Datei, ein gesamtes Thema darzustellen; das muss aus dem Artikel selbst hervorgehen. Gerne kann die Videobeschreibung angepasst werden, z.B. Auswirkungsbeispiel eines Programmfehlers. --Wikiolo (D) 18:08, 31. Mai 2020 (CEST)

Eine Grafik oder ein Video bei der Einleitung sollte nicht ein spezielles Thema oder nur einen Teilaspekt zeigen.

Wenn "Einleitung", dann muss es auch (möglichst belegt!) echt typisch sein, oder tatsächlich (so ziemlich) alle Aspekte zeigen.

Ansonsten bitte an die geeignete Artikelstelle, oder eben ganz raus.

--arilou (Diskussion) 14:54, 13. Nov. 2020 (CET)

Habe das Video mal verschoben und in 'Laufzeitfehler' eingestellt; das ist es wohl. Da aber dort wirklich nur "ein Beispiel von Milliarden" gezeigt wird, und dazu ohne konkreten Bezug zu Artikelinhalten, könnte man das m.E. auch löschen.--VÖRBY (Diskussion) 18:14, 13. Nov. 2020 (CET)