Fehlerquotient

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

Eine einwandfreie Produktqualität und Dienstleistungsqualität trägt sowohl zur Produktsicherheit als auch zur Kundenzufriedenheit bei. Fehlproduktionen hingegen führen zu erhöhten Kosten (Fehlerkosten, Reparaturen, Produkthaftung) und zu etwaigen Imageproblemen 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 pro Los, Prozent, Promille, ppm oder der sogenannte Sigma-Level als Streuungsmaß.

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:

${\displaystyle {\frac {11}{400}}=0{,}0275=2{,}75\,\%}$

Allgemein lässt sich schreiben:

${\displaystyle {\frac {\text{Fehler}}{\mathrm {W{\ddot {o}}rter} }}={\frac {{\text{Fehler}}\cdot 100}{\mathrm {W{\ddot {o}}rter} }}\,\%}$

Anhand des Fehlerquotienten – in diesem Beispiel wären es 2,75 % – kann der Lehrer eine Note bezüglich der Rechtschreibung vergeben.

Ein Arbeitnehmer genügt seiner Vertragspflicht aus dem Arbeitsvertrag, wenn er unter angemessener Ausschöpfung seiner persönlichen Leistungsfähigkeit arbeitet. Bei einer negativen Abweichung von der geschuldeten Arbeitsleistung liegt Schlechtleistung vor, die den Arbeitgeber zu arbeitsrechtlichen Maßnahmen bis hin zur Kündigung berechtigen kann.^[1] Eine Kündigung wegen schlechter Arbeitsqualität ist einem Urteil des Bundesarbeitsgericht (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.^[2] 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.

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.^[3]

In der Datenverarbeitung sind die Ursachen für Datenverlust 44 % Hardwarefehler, gefolgt von 32 % Anwenderfehlern, 7 % Computerviren, 4 % Softwarefehlern, 3 % Naturereignissen und 10 % sonstiger Fehlerursachen.^[4]

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.^[5]

Während der Entwicklung entstehen programmiersprachenunabhängig zwischen 30 und 50 Fehler pro 1000 Zeilen Code^[6], 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.^[7] 10 % der Restfehler haben üblicherweise ernsthafte Konsequenzen und führen zu einem Deadlock oder Absturz des Systems.^[7] Für den Zeitpunkt Produktivsetzung ist üblicherweise eine Fehlerdichte von < 2 anzustreben, bei sicherer Software < 1 wenn nicht < 0,5.^[5] 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.^[8] Kommerzielle Software hat eine durchschnittliche Fehlerdichte von 1 bis 30 Fehlern pro 1000 Zeilen Code^[9][10] beziehungsweise 0,75 Fehler je Function Point.^[11] Erfolgreiche Projekte haben eine geringere Fehlerdichte (0,2 Fehler je Function Point),^[12] größere Projekte eine höhere Fehlerdichte^[13].^[14] 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.^[15] Linux hat eine Fehlerdichte von 0,47, PostgreSQL von unter 0,1.^[16]

Es gibt unterschiedliche Techniken, um geringe Fehlerdichten zu erreichen. Mittels der von Harlan Mills vorgeschlagenen „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.^[17] Kombiniert man die besten Fehlervermeidungs- und -behebungstechniken kommt man auf 0,08 Fehler pro Function Point.^[18] 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 formaler Entwicklungsmethoden, Peer-Reviews und statistisches Testen erreicht.^[9]

Die Fehlerdichte kann auch zur Klassifizierung der Produktreife von Software herangezogen werden:^[19][8]

• Erstausbeute
• Modulationsfehlerrate

• Patentanmeldung DE19850969A1: Verfahren zum Anzeigen der Fehlerhäufigkeit und der Fehlerfrequenz bei einem taktweise arbeitenden Fehlerinspektionssystem. Angemeldet am 5. November 1998, veröffentlicht am 31. Mai 2000, Anmelder: Basler AG.‌

1. ↑ Oliver Vollstädt, Daniela Turck, Patrick Wiederhake, Ivonne Faerber: Umgang mit schwierigen Mitarbeitern. 3. Auflage. Haufe Gruppe, Freiburg, München, Stuttgart 2016, S. 57 (eingeschränkte Vorschau in der Google-Buchsuche). 
2. ↑ BAG, Urteil vom 17. Januar 2008, Az.: 2 AZR 536/06
3. ↑ Fehlerhäufigkeit in der Datenkommunikation. In: ITWissen.info. 9. Juni 2009, abgerufen am 27. September 2020. 
4. ↑ Fehlerhäufigkeit bei Datenverlust. In: datenrettung-profi.de. 2008, archiviert vom Original am 1. Januar 2013; abgerufen am 27. September 2020. 
5. ↑ ^{a b} Linda M. Laird, M. Carol Brennan: Software Measurement and Estimation: A Practical Approach. Hrsg.: IEEE Computer Society. John Wiley & Sons, Hoboken NJ 2006, ISBN 0-471-67622-5, S. 135 (englisch): “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” 
6. ↑ Georg Erwin Thaller: ISO 9001:2000 - Software-Entwicklung in der Praxis. Hrsg.: Heise Medien. 3. Auflage. Hannover 2001, ISBN 978-3-88229-189-6 (396 S.). 
7. ↑ ^{a b} Georg Erwin Thaller: Drachentöter: Risikomanagement für Software-Projekte. Hrsg.: Heise Medien GmbH. 2013, ISBN 978-3-936931-11-2 (214 S.). 
8. ↑ ^{a b} Frank Witte: Testmanagement und Softwaretest. Springer-Verlag, 2015, ISBN 978-3-658-09963-3, 11.10 Schätzungen für die Fehlerdichte, S. 111 (288 S.): „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“ 
9. ↑ ^{a b} Steve McConnell: Code Complete A Practical Handbook of Software Construction. 2. Auflage. Microsoft Press, 2004, ISBN 978-0-7356-1967-8, 22.4 Typical Errors, S. 521 (englisch): “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!)” 
10. ↑ Carnegie Mellon University’s CyLab Sustainable Computing Consortium: commercial software typically has 20 to 30 bugs for every 1,000 lines of code
11. ↑ Capers Jones: Software Engineering Best Practices. Lessons from Successful Projects in the Top Companies. S. 574
12. ↑ Capers Jones: Software Engineering Best Practices. Lessons from Successful Projects in the Top Companies. S. 131
13. ↑ Capers Jones: Program Quality and Programmer Productivity. 1977
14. ↑ Capers Jones: Estimating Software Costs. 1998
15. ↑ Peter Moore, Microsoft Visions, 1992
16. ↑ Mel Llaguno: 2017 Coverty Scan Report. (PDF) synopsis, S. 16, abgerufen am 31. Juli 2018 (englisch). 
17. ↑ R. H. Cobb, Harlan D. Mills: Engineering Software under Statistical Quality Control. In: IEEE Software, 7(6), 1990, S. 44–54
18. ↑ Capers Jones: Software Engineering Best Practices. Lessons from Successful Projects in the Top Companies. S. 575
19. ↑ Capers Jones: Programming Productivity. McGraw-Hill, New York 1986, ISBN 0-07-032811-0, S. 268 (englisch, archive.org [PDF; abgerufen am 26. September 2020]): 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)