Recall

Name

Recall der Anteil der korrekt identifizierten positiven Fälle

Bereich
Künstliche Intelligenz / KI
Typ
Verhältniszahl
Beschreibung

Recall (auch als Sensitivität oder True Positive Rate bezeichnet) ist eine Metrik, die misst, wie gut ein Modell die tatsächlichen positiven Fälle erkennt. Mit anderen Worten, Recall gibt an, wie viele der tatsächlich positiven Fälle vom Modell korrekt als positiv klassifiziert wurden.

Formel

Recall = True Positives (TP) / [True Positives (TP) + False Negatives (FN)]

Häufigkeit

je nach Bedarf, in der Regel beim trainieren eines Neuen Klassifikationsmodells

Abgrenzung

Accuracy, Precision

Varianten

Precision fokussiert sich darauf, wie präzise die positiven Vorhersagen sind (wie viele der vorhergesagten positiven Fälle sind tatsächlich positiv?). Recall misst, wie gut das Modell tatsächlich alle positiven Fälle erkennt (wie viele der tatsächlichen positiven Fälle wurden als positiv erkannt?).

Beispiel

Im Beispiel der KPI Confusion Matrix wurden Spam E-Mails nicht als Spam erkannt, False Negatives (FN): 10 (E-Mails, die fälschlicherweise als Nicht-Spam markiert wurden, obwohl sie Spam sind) Recall = 30 / ( 30 + 10 ) = 30 / 40 = 0,75 = 75%. In diesem Beispiel bedeutet ein Recall von 75%, dass das Modell 75% der tatsächlich als Spam klassifizierten E-Mails korrekt erkannt hat.

Typische Werte

Fallabhängiger Recall bedeutet, dass das Modell möglichst viele positive Fälle findet, es kann aber möglicherweise mehr Fehler (False Positives) machen

Anwendung
Fachlich

Maßzahl zur Berechnung der Qualität beim erkennen der tatsächlichen positiven Fälle eines Modells

Organisatorisch
Softwareentwicklung

Confusion Matrix

Name

Fehler-Matrix
Confusion Matrix  

Bereich
Künstliche Intelligenz / KI
Typ
Trendzahl
Beschreibung

Eine Confusion Matrix (Verwechslungsmatrix oder Fehler-Matrix) ist ein nützliches Werkzeug zur Beurteilung der Leistung eines Klassifikationsmodells. Sie zeigt eine tabellarische Übersicht über die tatsächlichen und vorhergesagten Klassifikationen eines Modells und ermöglicht so eine detaillierte Analyse der Fehler.

Formel

Die Matrix hat in der Regel vier Hauptelemente für ein binäres Klassifikationsproblem (zwei Klassen): True Positive (TP): Fälle, bei denen die positive Klasse korrekt vorhergesagt wurde (das Modell sagt „positiv“ und das tatsächliche Ergebnis ist auch „positiv“). True Negative (TN): Fälle, bei denen die negative Klasse korrekt vorhergesagt wurde (das Modell sagt „negativ“ und das tatsächliche Ergebnis ist auch „negativ“). False Positive (FP) (auch bekannt als Type-I-Fehler): Fälle, bei denen fälschlicherweise eine positive Vorhersage gemacht wurde (das Modell sagt „positiv“, aber das tatsächliche Ergebnis ist „negativ“). False Negative (FN) (auch bekannt als Type-II-Fehler): Fälle, bei denen fälschlicherweise eine negative Vorhersage gemacht wurde (das Modell sagt „negativ“, aber das tatsächliche Ergebnis ist „positiv“).

Häufigkeit

je nach Bedarf, in der Regel beim trainieren eines Neuen Klassifikationsmodells

Abgrenzung

 

Varianten

Hat man beispielweise eine KI-Anwendung z. B. auf das Erkennen von Autos auf Bildern trainiert, wird diese Tabelle mit einer Anzahl von Datensätzen (Bildern) gefüttert, von denen vorab klar oder zumindest zweifelsfrei festgestellt ist, wie viele Bilder wirklich Autos enthalten und wie viele nicht und in welchem Bild diese Autos dargestellt sind und in welchen Bildern nicht. Nachdem die Anwendung nun die (bekannten) Bilder klassifiziert hat, erstellt man mit den gewonnenen Daten die Confusion Matrix.

Beispiel

Ein Modell untersucht, ob eine E-Mail Spam ist oder nicht. Es gibt 100 E-Mails, von denen 40 tatsächlich Spam sind und 60 keine Spam-E-Mails (Ham). Nach der Vorhersage durch das Modell ergibt sich folgende Verteilung: Vorhersage: Spam Tatsächlicher Spam 30 (TP) Tatsächlicher Kein Spam 5 (FP) Vorhersage: Kein Spam 10 (FN) 55 (TN) In diesem Beispiel bedeutet das: 30 E-Mails wurden korrekt als Spam identifiziert (True Positives, TP). 10 E-Mails wurden fälschlicherweise als Nicht-Spam klassifiziert, obwohl sie Spam sind (False Negatives, FN). 5 E-Mails wurden fälschlicherweise als Spam klassifiziert, obwohl sie kein Spam sind (False Positives, FP). 55 E-Mails wurden korrekt als Nicht-Spam identifiziert (True Negatives, TN).

Typische Werte

Fallabhängig

Anwendung
Fachlich

Maßzahl zur Beurteilung der Leistung eines Klassifikationsmodells

Organisatorisch
Projekt

Vergeudete Anstrengung

Name

Vergeudete Anstrengung
Wasted Effort

Bereich
Softwareentwicklung
Typ
Verhältniszahl
Beschreibung

Die Metrik „Vergeudete Anstrengung“ misst die Zeit und die Ressourcen, die für Aufgaben aufgewendet werden, die nicht zum endgültigen Projekt oder zu den Unternehmenszielen beitragen.
Wenn das Team beispielsweise an einer Softwarefunktion gearbeitet hat, die nach zwei Wochen als irrelevant angesehen wurde, wäre der verschwendete Aufwand der Betrag, der allen Entwicklern für ihre Arbeit in diesen zwei Wochen gezahlt wurde.

Formel

vergeudete Anstrengung = (Gesamter verschwendeter Aufwand / Gesamtaufwand) X 100

Häufigkeit

je nach Bedarf, in der Regel je Projekt Durchführung

Abgrenzung

Fluss Effizienz

Varianten

 

Beispiel

Angenommen, ein Projektteam hat insgesamt 500 Stunden in ein Projekt investiert. Davon wurden 100 Stunden als verschwendeter Aufwand identifiziert, z. B. durch unnötige Aufgaben, Wartezeiten oder Überarbeitungen. Verschwendeter Aufwand = (Gesamter verschwendeter Aufwand / Gesamtaufwand) x 100 Verschwendeter Aufwand = (100 / 500) x 100 Verschwendeter Aufwand = 0,2 x 100 Verschwendeter Aufwand = 20% Das bedeutet, dass 20% des gesamten Arbeitsaufwands im Projekt als Verschwendung betrachtet werden können. Eine Reduzierung dieses Prozentsatzes würde die Effizienz des Projekts steigern.

Typische Werte

Fallabhängig, allerdings je höher die prozentuale Abdeckung, desto effektiver

Anwendung
Fachlich

Maßzahl zur Berechnung der unnötig verbrauchten Ressourcen

Organisatorisch
Softwareentwicklung

Fluss-Effizienz

Name

Fluss-Effizienz
Flow Efficiency

Bereich
Softwareentwicklung
Typ
Verhältniszahl
Beschreibung

Der Leistungsindikator für die Ablaufeffizienz verfolgt das Verhältnis von Gesamt- und aktiver Zeit, um einen Einblick in die Stillstandszeit zu geben und den Arbeitsablauf zu optimieren.

Formel

Fluss-Effizienz = (Wertschöpfungszeit / Durchlaufzeit) X 100

Häufigkeit

je nach Bedarf

Abgrenzung

Durchlaufzeit

Varianten

Wertsteigernde Zeit = Zeit, die für Aktivitäten aufgewendet wird, die direkt zu den Bedürfnissen des Kunden beitragen, wie Quellcode/Tests. Gesamte Durchlaufzeit = Zeit ab dem Zeitpunkt, an dem ein Workitem in das Kanban-System eingegeben wird, bis zur Lieferung an den Kunden.

Beispiel

Angenommen, in einem Produktionsprozess benötigt ein Produkt 10 Stunden für die gesamte Durchlaufzeit (vom Start bis zur Fertigstellung). Von diesen 10 Stunden sind jedoch nur 4 Stunden echte Wertschöpfungszeit (also die Zeit, in der aktiv am Produkt gearbeitet wird). Fließeffizienz = (Wertschöpfungszeit / Durchlaufzeit) x 100 Fließeffizienz = (4 / 10) x 100 Fließeffizienz = 0,4 x 100 Fließeffizienz = 40% Das bedeutet, dass 40% der Zeit in diesem Prozess tatsächlich wertschöpfend sind, während die restlichen 60% Wartezeiten oder andere nicht-wertschöpfende Aktivitäten darstellen. Eine höhere Fließeffizienz zeigt eine effizientere Nutzung der Durchlaufzeit.

Typische Werte

Fallabhängig, allerdings je höher die prozentuale Abdeckung, desto effektiver

Anwendung
Fachlich

Maßzahl zur Berechnung der effizienten Nutzung der Durchlaufzeit

Organisatorisch
Softwareentwicklung

Defect Detection Rate

Name

Defect Detection Rate

Bereich
Softwareentwicklung
Typ
Verhältniszahl
Beschreibung

Das DDR-Verhältnis misst die Anzahl der vor der Freigabe gefundenen Fehler im Vergleich zu denen, die nach der Freigabe gefunden wurden.
Verwendet wird die DDR-Kennzahl, um die Anzahl der vom Testteam übersehenen und von den Kunden festgestellten Fehler zu bewerten, die sich negativ auf deren Erfahrung auswirken.

Formel

Defect Detection Rate = (in einer Phase gefundene Fehler / Gesamtfehler) X 100

Häufigkeit

je nach Bedarf, in der Regel nach jedem Deployment der ähnlichem

Abgrenzung

Codeabdeckung

Varianten

 

Beispiel

Angenommen, in der Testphase eines Projekts werden 80 Fehler gefunden. Insgesamt gibt es 100 bekannte Fehler im gesamten Entwicklungsprozess. Defect Detection Ratio = (in einer Phase gefundene Fehler / Gesamtfehler) x 100 Defect Detection Ratio = (80 / 100) x 100 Defect Detection Ratio = 0,8 x 100 Defect Detection Ratio = 80% Das bedeutet, dass 80% der Gesamtfehler in dieser speziellen Phase entdeckt wurden, was eine hohe Fehlererkennungsrate während der Testphase anzeigt.

Typische Werte

Fallabhängig, allerdings je höher die prozentuale Abdeckung, desto qualitativer

Anwendung
Fachlich

Maßzahl zur Berechnung der Effektivität eigener Tests

Organisatorisch
Softwareentwicklung

Code Abdeckung

Name

Code Abdeckung
Code Coverage

Bereich
Softwareentwicklung
Typ
Verhältniszahl
Beschreibung

Die Codeabdeckung, auch Testabdeckung genannt, misst den Prozentsatz des getesteten Codes. Diese DevOps-Kennzahl misst die Softwarequalität für Produktions- und Testzwecke.
Sie priorisiert die testgetriebene Entwicklung (TDD) und identifiziert Fehler in Codes. Je höher die Codeabdeckung ist, desto geringer ist die Wahrscheinlichkeit von Fehlern.

Formel

Code-Abdeckung = (Anzahl der von Tests ausgeführten Codezeilen / Gesamtzahl der Codezeilen) X100

Häufigkeit

je nach Bedarf, in der Regel vor jedem Deployment der ähnlichem

Abgrenzung

Testabdeckung

Varianten

 

Beispiel

Angenommen, ein Softwareentwickler hat ein Programm geschrieben, das insgesamt 10.000 Codezeilen umfasst. Von diesen Codezeilen werden 7.500 durch automatisierte Tests ausgeführt. Codeabdeckung = (Anzahl der von Tests ausgeführten Codezeilen / Gesamtzahl der Codezeilen) x 100 Codeabdeckung = (7.500 / 10.000) x 100 Codeabdeckung = 0,75 x 100 Codeabdeckung = 75% Das bedeutet, dass 75% des Codes von den Tests abgedeckt werden. Eine höhere Codeabdeckung deutet darauf hin, dass der Code umfangreich getestet wurde, was in der Regel die Qualität und Stabilität der Software verbessert.

Typische Werte

Fallabhängig, allerdings je höher die prozentuale Abdeckung, desto qualitativer

Anwendung
Fachlich

Maßzahl zur Berechnung der getesteten Code-Teile

Organisatorisch
Softwareentwicklung

Testabdeckung

Name

Testabdeckung
Test Coverage

Bereich
Qualitätsmanagement
Softwareentwicklung
Typ
Verhältniszahl
Beschreibung

Die Testabdeckung ist eine Kennzahl aus dem Qualitätsmanagement. Sie bezeichnet das Verhältnis zwischen dem Umfang der aus einem Test ge­troffenen Aussagen zu den theoretisch möglichen Aussagen bzw. der Men­ge der gewünschten Aussagen. In der Softwareentwicklung wird die Testab­deckung für unterschiedliche Bereiche ermittelt. Dazu gehören vor allem Fachlichkeit, Daten und Code. Für eine möglichst hohe Testabdeckung wer­den idealerweise Testfälle definiert, die gleichzeitig unterschiedliche Berei­che und Domänen ansprechen.

Formel

\text {Testabdeckung} = \frac {\text{getroffene Aussagen}}{\text{m\"ogliche bzw. gew\"unschte Aussagen}}100\%

Häufigkeit

Im Rahmen der Testplanung und Testdurchführung nach Bedarf

Abgrenzung
  • Codeabdeckung
  • Line/Branch Coverage
  • Unit Test Coverage
Varianten
bezogen auf:
Fachlichkeit
Daten
Code
Beispiel

Von 200 möglichen Testfällen werden über die tatsächlich durchgeführten Tests 150 abgedeckt. Damit ergibt sich eine Testabdeckung von
150 / 200 * 100% = 75%

Typische Werte

Gerade bei komplexen Systemen wird keine Testabdeckung von 100% er­reicht. Die tatsächlich gewählte Testabdeckung hängt stark von den Quali­tätsanforderungen und damit auch von der Kritikalität der Systeme ab.

Anwendung
Fachlich
  • Planung des Qualitätsniveaus
  • Bestimmung des über Tests abgedeckten Umfangs
Organisatorisch
Qualitätsmanagement
Softwareentwicklung
Testmanagement

Fehler pro Funktionspunkt

Name

Fehler pro Funktionspunkt
Errors per function point

Bereich
Qualitätsmanagement
Softwareentwicklung
Typ
Trendzahl
Beschreibung

Die Kennzahl ist ein Indikator für die Qualität in der Softwareentwicklung. Sie setzt die Anzahl der gefundenen Fehler mit der Komplexität einer Soft­ware, ausgedrückt in Funktionspunkten (Function Points, FP) in Beziehung. Die Anzahl der Fehler spiegelt dabei diejenigen wieder, die im Rahmen der Tests gefunden werden. Zur Ermittlung der FP wird die Komplexität einer Anwendung aus der Sicht des Benutzers bewertet und berücksichtigt (bei­spielsweise Transaktionen und verwendete Daten).

Formel

\text {Fehler pro Funktionspunkt} = \frac {\text{Anzahl Fehler}}{\text{1000 Funktionspunkte}}

Häufigkeit

Monatlich, jährlich, je nach Projekt

Abgrenzung

Fehler in Produktion / 1000 FP (Verlässlichkeit einer Software)

Varianten
bezogen auf:
Module
Plattform / Technologie
Organisationseinheit
Beispiel

Eine Eingabemaske für Adressen hat 38 FP, bei den Tests werden 2 Fehler gefunden: 1000 * 2 /38 = 52,6

Typische Werte

Die zu erwartenden Werte hängen sehr stark von der Erfahrung der Ent­wickler und der Reife der verwendeten Plattform ab. Eine erste Näherung ist im mittleren zweistelligen Bereich zu suchen.

Anwendung
Fachlich

Indikator für

  • die Entwicklungsqualität
  • die Testqualität
Organisatorisch
Projekt
  • Projektmanagement
Qualitätsmanagement
  • Führung
Softwareentwicklung
  • Entwicklungsleitung
Testmanagement