imported>Valeee04: Die letzte Textänderung von ~2025-34770-77 wurde verworfen und die Version 261232956 von Graph Pixel wiederhergestellt. Grund: Es war kein Tippfehler vorhanden

2025-11-19T11:52:32Z

Die letzte Textänderung von ~2025-34770-77 wurde verworfen und die Version 261232956 von Graph Pixel wiederhergestellt. Grund: Es war kein Tippfehler vorhanden

Neue Seite

'''Fehler[[quotient]]''' (auch '''Fehlerdichte''', '''Fehlerrate''', '''Fehlerquote''' oder '''Fehlerhäufigkeit''') ist im [[Qualitätsmanagement]] der [[Relative Häufigkeit|relative Anteil]] von fehlerhaften Elementen im Verhältnis zur Gesamtheit, also die relative Häufigkeit, mit der ein [[Fehler]] bei einem [[Produkt (Wirtschaft)|Produkt]], einer [[Dienstleistung]], einem [[Produktionsprozess]] oder der [[Arbeitsqualität]] auftaucht.

== Allgemeines ==
Eine einwandfreie [[Produktqualität]] und [[Dienstleistungsqualität]] trägt sowohl zur [[Produktsicherheitsgesetz (Deutschland)|Produktsicherheit]] als auch zur [[Kundenzufriedenheit]] bei. [[Fehlproduktion]]en hingegen führen zu erhöhten [[Kosten]] ([[Fehlerkosten]], [[Reparatur]]en, [[Produkthaftung]]) und zu etwaigen [[Image]]problemen für den [[Hersteller]]. Deshalb soll das Qualitätsmanagement dafür sorgen, dass Fehlproduktion nach Möglichkeit vermieden und die Fehlerquote möglichst gering gehalten wird.

Maße für die Fehlerquotienten als [[Gliederungszahl]] sind beispielsweise [[Stück (Mengeneinheit)|Stück]] pro [[Los (Produktion)|Los]], [[Prozent]], [[Promille]], [[parts per million|ppm]] oder der sogenannte [[Six Sigma#Erwarteter Fehleranteil beim Six-Sigma-Level|Sigma-Level]] als [[Streuung (Statistik)|Streuungsmaß]].

== Anwendungen ==
=== Schule ===
Der Fehlerquotient könnte beispielsweise in der [[Schule]] zur Verwendung kommen:
: Beim Verfassen eines Textes von 400 Wörtern hat ein Schüler elf [[Rechtschreibfehler]] gemacht. Um den Fehlerquotienten zu erhalten, teilt man die Anzahl der Fehler durch die Gesamtzahl der Wörter. Er lautet also:
::<math>\frac{11}{400} = 0{,}0275 = 2{,}75\,\%</math>
: Allgemein lässt sich schreiben:
::<math>\frac{\text{Fehler}}{\mathrm{W\ddot orter}} = \frac{\text{Fehler}\cdot 100}{\mathrm{W\ddot orter}}\,\%</math>
: Anhand des Fehlerquotienten – in diesem Beispiel wären es 2,75 % – kann der Lehrer eine [[Schulnote|Note]] bezüglich der Rechtschreibung vergeben.

=== Arbeit ===
Ein [[Arbeitnehmer]] genügt seiner Vertragspflicht aus dem [[Arbeitsvertrag (Deutschland)|Arbeitsvertrag]], wenn er unter angemessener Ausschöpfung seiner persönlichen [[Körperliche Leistungsfähigkeit|Leistungsfähigkeit]] arbeitet. Bei einer negativen Abweichung von der geschuldeten Arbeitsleistung liegt [[Schlechtleistung]] vor, die den [[Arbeitgeber]] zu [[Arbeitsrecht (Deutschland)|arbeitsrechtlichen]] Maßnahmen bis hin zur [[Beendigung des Arbeitsverhältnisses|Kündigung]] berechtigen kann.<ref>{{Literatur |Autor=Oliver Vollstädt, Daniela Turck, Patrick Wiederhake, Ivonne Faerber |Titel=Umgang mit schwierigen Mitarbeitern |Datum=2016 |Seiten=57 |Auflage=3 |Verlag=Haufe Gruppe |Ort=Freiburg, München, Stuttgart |Online={{Google Buch|BuchID=JdlcDAAAQBAJ |Seite=57 |Hervorhebung=Arbeitsqualität Schlechtleistung}}}}</ref> Eine Kündigung wegen schlechter Arbeitsqualität ist einem Urteil des [[Bundesarbeitsgericht]]s (BAG) vom Januar 2008 zufolge rechtlich nur zulässig, wenn der Arbeitnehmer über einen längeren Zeitraum hinweg unterdurchschnittliche Leistungen erbringt und dabei entweder weniger produziert oder erheblich mehr Fehler macht als der Durchschnitt der Arbeitnehmer im Betrieb oder wenn er nach seinen persönlichen Fähigkeiten zu einer besseren Leistung in der Lage ist.<ref>[https://lexetius.com/2008,1014 BAG, Urteil vom 17. Januar 2008, Az.: 2 AZR 536/06]</ref> Im zitierten Fall ging es um eine Versandarbeiterin in einem Versandkaufhaus, die eine Fehlerquote zwischen 4,01 ‰ und 5,44 ‰ aufwies, während die durchschnittliche Fehlerquote der 209 eingesetzten vergleichbaren Mitarbeiter demgegenüber nur 1,34 ‰ erreichte. Im Urteil machte das BAG deutlich, dass die längerfristige deutliche Überschreitung der durchschnittlichen Fehlerquote je nach tatsächlicher Fehlerzahl, Art, Schwere und Folgen der fehlerhaften [[Arbeitsleistung]] ein Anhaltspunkt dafür sein kann, dass der Arbeitnehmer vorwerfbar seine vertraglichen Pflichten verletzt.

== Fehlerquotienten in Datenkommunikation und -verarbeitung ==
Den Fehlerquotient bei der Speicherung und Übertragung binärer Daten nennt man [[Bitfehlerhäufigkeit]].

In der [[Datenkommunikation]] versteht man unter Fehlerhäufigkeit das Verhältnis von fehlerhaft empfangenen Symbolen, Wörtern oder Blöcken zur Gesamtzahl der empfangenen Symbole, Wörter oder Blöcke. Dabei handelt es sich um die Angabe einer relativen Häufigkeit, die innerhalb einer bestimmten endlichen Messzeit ermittelt wurde.<ref>{{Internetquelle |url=https://www.itwissen.info/Fehlerhaeufigkeit-error-ratio.html |titel=Fehlerhäufigkeit in der Datenkommunikation |datum=2009-06-09 |werk=ITWissen.info |abruf=2020-09-27}}</ref>

In der [[Datenverarbeitung]] sind die Ursachen für [[Datenverlust]] 44 % [[Hardwarefehler]], gefolgt von 32 % [[Anwenderfehler]]n, 7 % [[Computervirus|Computerviren]], 4 % [[Softwarefehler]]n, 3 % [[Naturereignis]]sen und 10 % sonstiger Fehlerursachen.<ref>{{Internetquelle |url=http://www.datenrettung-profi.de/datenverlust/ |archiv-url=http://web.archive.org/web/20130101111819/http://www.datenrettung-profi.de/datenverlust/ |titel=Fehlerhäufigkeit bei Datenverlust |archiv-datum=2013-01-01 |datum=2008 |werk=datenrettung-profi.de |abruf=2020-09-27}}</ref>

== Fehlerdichte in der Informatik{{Anker|Fehlerdichte}} ==
In der [[Informatik]] bezeichnet die Fehlerdichte die Anzahl an Fehlern pro 1000 Zeilen Code ([[Lines of Code]]) bzw. je [[Function Point]]. Fehlerfreie Software ist aus betriebswirtschaftlichen und technischen Gründen in der Praxis unmöglich zu erstellen (siehe dazu [[Korrektheit (Informatik)]]). Anzustreben ist daher vor Produktionseinsatz einer Software eine möglichst geringe, zu den Anforderungen der Software passende Fehlerdichte zu erreichen. Die angestrebte Fehlerdichte ist somit während der Analysephase zu definieren. Bei Software, deren Ausfall Menschenleben kosten könnte (wie bspw. Militär- oder Krankenhaussysteme), wird üblicherweise eine Fehlerdichte von < 0,5 Fehlern pro 1000 Zeilen Code angestrebt.<ref name="software measurement and estimation"/>

Während der Entwicklung entstehen programmiersprachenunabhängig zwischen 30 und 50 Fehler pro 1000 Zeilen Code<ref name="iso">{{Literatur |Autor=Georg Erwin Thaller |Titel=ISO 9001:2000 - Software-Entwicklung in der Praxis |Hrsg=Heise Medien |Auflage=3 |Ort=Hannover |Datum=2001-09-01 |Sprache=de |Umfang=396 |ISBN=978-3882291896}}</ref>, die idealerweise zum größten Teil mittels Tests gefunden werden. Bei guten Organisationen kann nach dem Test mit einer Fehlerdichte von 1 bis 3 Restfehlern pro 1000 Zeilen Code gerechnet werden.<ref name="drache">{{Literatur |Autor=Georg Erwin Thaller |Titel=Drachentöter: Risikomanagement für Software-Projekte |Hrsg=Heise Medien GmbH |Datum=2013-11-27 |Sprache=de |Umfang=214 |ISBN=978-3936931112}}</ref> 10 % der Restfehler haben üblicherweise ernsthafte Konsequenzen und führen zu einem [[Deadlock (Informatik)|Deadlock]] oder [[Absturz (Computer)|Absturz]] des Systems.<ref name="drache" /> Für den Zeitpunkt Produktivsetzung ist üblicherweise eine Fehlerdichte von < 2 anzustreben, bei sicherer Software < 1 wenn nicht < 0,5.<ref name="software measurement and estimation">{{Literatur |Autor=Linda M. Laird, M. Carol Brennan |Hrsg=IEEE Computer Society |Titel=Software Measurement and Estimation: A Practical Approach |Verlag=John Wiley & Sons |Ort=Hoboken NJ |Datum=2006 |ISBN=0-471-67622-5 |Seiten=135 |Sprache=en |Zitat=Good software should be less than 2 defects per KLOC. Safe software should be at least less than 1, if not 0.5 defects per KLOC}}</ref> Als normal gilt 2 bis 6, im Webbereich akzeptabel gilt 6 bis 10. Eine Fehlerdichte über 10 gilt als ''malpractice'' und kann vor einem Gericht zur Kompensationszahlung führen.<ref name="Testmanagement und Softwaretest">{{Literatur |Autor=Frank Witte |Titel=Testmanagement und Softwaretest |Verlag=Springer-Verlag |Datum=2015-11-23 |ISBN=978-3658099633 |Seiten=111 |Kapitel=11.10 Schätzungen für die Fehlerdichte |Umfang=288 |Sprache=de |Zitat=Bei Software, deren Ausfall Menschenleben kosten könnte (wie beispielsweise sicherheitskritische Militärsysteme oder medizinische Geräte, z. B. eine Herz-Lungen-Maschine), wird üblicherweise eine Fehlerdichte von < 0,5 Fehlern pro 1000 Zeilen Code angestrebt. Anzustreben ist üblicherweise eine Fehlerdichte von < 2 (etwa für kaufmännische Anwendungen), normal ist 2 bis 6 und gerade noch akzeptabel (z. B. für eine Informationsseite im Web oder für eine kleine App) ist der Bereich von 6 bis 10. Über 10 gilt als „Malpractice“ und kann vor einem Gericht zu Kompensationszahlungen führen. Die Fehlerdichte (Tab. 11.2) kann auch zur Klassifizierung der Produktreife von Software herangezogen werden. Tab. 11.2 Fehlerdichte und Stabilität von Programmen: < 0,5 Stabile Programme; 0,5 bis 3 Reifende Programme; 3 bis 6 Labile Programme; 6 bis 10 Fehleranfällige Programme; >10 Unbrauchbare Programme}}</ref> Kommerzielle Software hat eine durchschnittliche Fehlerdichte von 1 bis 30 Fehlern pro 1000 Zeilen Code<ref name="Code Complete">{{Literatur |Autor=Steve McConnell |Titel=Code Complete A Practical Handbook of Software Construction |Auflage=2 |Verlag=Microsoft Press |Datum=2004 |ISBN=978-0-7356-1967-8 |Sprache=en |Seiten=521 |Kapitel=22.4 Typical Errors |Zitat=Industry average experience is about 1 to 25 errors per 1000 lines of code for delivered software. […] Cases that have one-tenth as many errors as this are rare; cases that have 10 times more tend not to be reported. (They probably aren’t ever completed!)}}</ref><ref>Carnegie Mellon University’s CyLab Sustainable Computing Consortium: commercial software typically has 20 to 30 bugs for every 1,000 lines of code</ref> beziehungsweise 0,75 Fehler je Function Point.<ref>Capers Jones: ''Software Engineering Best Practices. Lessons from Successful Projects in the Top Companies''. S. 574</ref>
Erfolgreiche Projekte haben eine geringere Fehlerdichte (0,2 Fehler je Function Point),<ref>Capers Jones: ''Software Engineering Best Practices. Lessons from Successful Projects in the Top Companies''. S. 131</ref> größere Projekte eine höhere Fehlerdichte<ref>Capers Jones: ''Program Quality and Programmer Productivity''. 1977</ref>.<ref>Capers Jones: ''Estimating Software Costs''. 1998</ref> Bei Microsoft-Anwendungen wurden 10 bis 20 Fehler pro 1000 Zeilen Code im Test gefunden, nach Veröffentlichung der Software beträgt die Fehlerdichte 0,5.<ref>Peter Moore, ''Microsoft Visions'', 1992</ref> [[Linux]] hat eine Fehlerdichte von 0,47, [[PostgreSQL]] von unter 0,1.<ref>{{Internetquelle |autor=Mel Llaguno |url=https://www.synopsys.com/content/dam/synopsys/sig-assets/reports/SCAN-Report-2017.pdf |titel=2017 Coverty Scan Report |werk= |hrsg=synopsis |datum= |archiv-url= |archiv-datum= |abruf=2018-07-31 |abruf-verborgen= |format=PDF |sprache=en |offline= |seiten=16}}</ref>

Es gibt unterschiedliche Techniken, um geringe Fehlerdichten zu erreichen. Mittels der von Harlan Mills vorgeschlagenen „[[Cleanroom Software Engineering|Cleanroom Development]]“-Technik könnten während der Entwicklung Fehlerdichten von 3 Fehlern pro 1000 Zeilen Code erreicht werden, welche durch das In-House-Testen bis zur Veröffentlichung der Software noch auf 0,1 reduziert werden können.<ref>R. H. Cobb, Harlan D. Mills: ''Engineering Software under Statistical Quality Control''. In: ''IEEE Software'', 7(6), 1990, S. 44–54</ref> Kombiniert man die besten Fehlervermeidungs- und -behebungstechniken kommt man auf 0,08 Fehler pro Function Point.<ref>Capers Jones: ''Software Engineering Best Practices. Lessons from Successful Projects in the Top Companies''. S. 575</ref> Nur wenige Projekte, beispielsweise die Software für das [[Space Shuttle]] (das ''Primary Avionics Software System''), erreichen Fehlerdichten von 0 Fehlern bei 500.000 Lines of Code. Derartiges wird beispielsweise durch ein System [[Formale Methode|formaler Entwicklungsmethoden]], [[Peer-Review]]s und statistisches Testen erreicht.<ref name="Code Complete" />

Die Fehlerdichte kann auch zur Klassifizierung der Produktreife von Software herangezogen werden:<ref>{{Literatur |Autor=Capers Jones |Titel=Programming Productivity |Verlag=McGraw-Hill |Ort=New York |Datum=1986 |Sprache=en |ISBN=0-07-032811-0 |Seiten=268 |Online=https://archive.org/details/programmingprodu0000jone |Format=PDF |Abruf=2020-09-26 |Zitat=''stable system (< 0,5 defects per KLOC per year), stabilizing systems (< 3.0 defects per KLOC per year), unstable system (> 3.0 defects per KLOC per year), error-prone system (> 6.0 defects per KLOC per year), hazardous system (>10.0 defects per KLOC per year)''}}</ref><ref name="Testmanagement und Softwaretest"/>
{| class="wikitable"
|-
! Fehlerdichte !! Klassifizierung der Programme
|-
| align="center" | < 0,5 || stabile Programme
|-
| align="center" | 0,5 … 3 || reifende Programme
|-
| align="center" | 3 … 6 || labile Programme
|-
| align="center" | 6 … 10 || fehleranfällige Programme
|-
| align="center" | > 10 || unbrauchbare Programme
|}

== Siehe auch ==
* [[Erstausbeute]]
* [[Modulationsfehlerrate]]

== Weblinks ==
* {{Patent| Land=DE| V-Nr=19850969| Code=A1| Typ=Patentanmeldung| Titel=Verfahren zum Anzeigen der Fehlerhäufigkeit und der Fehlerfrequenz bei einem taktweise arbeitenden Fehlerinspektionssystem| A-Datum=1998-11-05| V-Datum=2000-05-31| Anmelder=Basler AG}}

== Einzelnachweise ==
<references />

[[Kategorie:Fehlergröße]]
[[Kategorie:Qualitätsmanagement]]

Fehlerquotient - Versionsgeschichte

imported>Valeee04: Die letzte Textänderung von ~2025-34770-77 wurde verworfen und die Version 261232956 von Graph Pixel wiederhergestellt. Grund: Es war kein Tippfehler vorhanden