Hauptmenü öffnen

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.

Inhaltsverzeichnis

AllgemeinesBearbeiten

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ß.

AnwendungenBearbeiten

SchuleBearbeiten

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:
 
Allgemein lässt sich schreiben:
 
Anhand des Fehlerquotienten – in diesem Beispiel wären es 2,75 % – kann der Lehrer eine Note bezüglich der Rechtschreibung vergeben.

ArbeitBearbeiten

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.

Fehlerquotienten in Datenkommunikation und -verarbeitungBearbeiten

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]

Fehlerdichte in der InformatikBearbeiten

In der Informatik bezeichnet die Fehlerdichte die Anzahl an Fehlern pro 1.000 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. Anzustreben ist daher eine möglichst geringe, zu den Anforderungen der Software passende Fehlerdichte – 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 1.000 Zeilen Code angestrebt.

Anzustreben ist üblicherweise eine Fehlerdichte von < 2, bei sicherer Software < 1 wenn nicht < 0,5. Normal ist 2–6 und akzeptabel, aber nur im Webbereich, ist 6–10. Eine Fehlerdichte über 10 gilt als malpractice und kann vor einem Gericht zur Kompensationszahlung führen.[5] Kommerzielle Software hat eine durchschnittliche Fehlerdichte von 15 bis 50 Fehlern pro 1.000 Zeilen Code[6][7] beziehungsweise 0,75 Fehler je Function Point.[8] Erfolgreiche Projekte haben eine geringere Fehlerdichte (0,2 Fehler je Function Point),[9] größere Projekte eine höhere Fehlerdichte[10].[11] Bei Microsoft-Anwendungen wurden 10 bis 20 Fehler pro 1.000 Zeilen Code im Test gefunden, nach Veröffentlichung der Software beträgt die Fehlerdichte 0,5.[12] Linux hat eine Fehlerdichte von 0,47, PostgreSQL von unter 0,1.[13]

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 1.000 Zeilen Code erreicht werden, welche durch das In-House-Testen bis zur Veröffentlichung der Software noch auf 0,1 reduziert werden können.[14] Kombiniert man die besten Fehlervermeidungs- und -behebungstechniken kommt man auf 0,08 Fehler pro Function Point.[15] 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.[6]

Die Fehlerdichte kann auch zur Klassifizierung der Produktreife von Software herangezogen werden:[16]

Fehlerdichte Klassifizierung der Programme
< 0,5 stabile Programme
0,5 … 3 reifende Programme
3 … 6 labile Programme
6 … 10 fehleranfällige Programme
> 10 unbrauchbare Programme

WeblinksBearbeiten

EinzelnachweiseBearbeiten

  1. Oliver Vollstädt/Daniela Turck/Patrick Wiederhake/Ivonne Faerber, Umgang mit schwierigen Mitarbeitern, 2016, S. 57
  2. BAG, Urteil vom 17. Januar 2008, Az.: 2 AZR 536/06
  3. Fehlerhäufigkeit in der Datenkommunikation
  4. Fehlerhäufigkeit bei Datenverlust (Memento des Originals vom 1. Januar 2013 im Internet Archive)   Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/www.datenrettung-profi.de
  5. 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. a b Steve McConnell: Code Complete A Practical Handbook of Software Construction. 2. Auflage. Microsoft Press, 2004, ISBN 978-0-7356-1967-8 (englisch).
  7. Carnegie Mellon University’s CyLab Sustainable Computing Consortium
  8. Capers Jones: Software Engineering Best Practices. Lessons from Successful Projects in the Top Companies. S. 574
  9. Capers Jones: Software Engineering Best Practices. Lessons from Successful Projects in the Top Companies. S. 131
  10. Capers Jones: Program Quality and Programmer Productivity. 1977
  11. Capers Jones: Estimating Software Costs. 1998
  12. Peter Moore, Microsoft Visions, 1992
  13. Mel Llaguno: 2017 Coverty Scan Report. (PDF) synopsis, S. 16, abgerufen am 31. Juli 2018 (englisch).
  14. R. H. Cobb/Harlan D. Mills: Engineering Software under Statistical Quality Control. In: IEEE Software, 7(6), 1990, S. 44–54
  15. Capers Jones: Software Engineering Best Practices. Lessons from Successful Projects in the Top Companies. S. 575
  16. Carper Jones: Programming Productivity. McGraw-Hill, New York 1986