Sergey Nivens - Fotolia

23 Kennzahlen zur Softwareentwicklung, die Sie messen sollten

Leistungsstarke, ansprechende und sichere Apps entstehen nicht zufällig. Messen Sie diese KPIs, um den Softwareentwicklungsprozess und die Softwarequalität zu verbessern.

Softwareentwicklungsmetriken können Aufschluss darüber geben, wie eine Anwendung funktioniert und wie effektiv das Entwicklungsteam arbeitet.

IT-Organisationen verlassen sich auf eine Reihe dieser KPIs, um den Fortschritt der Softwareentwickler sowie die Softwarequalität, wie zum Beispiel Leistung und Benutzerzufriedenheit, vollständig zu verstehen. Die Bandbreite der möglichen Messungen umfasst vier Hauptkategorien:

  1. Entwicklerproduktivität
  2. Softwareleistung
  3. Fehler und Sicherheit
  4. Benutzererfahrung

Eine IT-Organisation muss zwar nicht jede Metrik tabellarisch erfassen, sollte aber diejenigen priorisieren und verfolgen, die für ihre Anforderungen und Ziele am wichtigsten sind. Sehen Sie sich diese 23 Softwareentwicklungsmetriken an und erstellen Sie eine Reihe von KPIs für die Softwarequalität.

Metriken zur Entwicklerproduktivität messen

Es gibt viele Möglichkeiten, die Effizienz eines Teams und die geleistete Arbeit zu besprechen oder zu bewerten. Produktivitätskennzahlen ermöglichen es Entwicklungsmanagern, Projekte besser zu steuern. Stellen Sie eine Mischung aus diesen Softwaremetriken zusammen, um den Fortschritt eines Projekts, die Produktivität der Entwickler, den Umfang der zusätzlich erforderlichen Entwicklungszeit und vieles mehr zu messen.

1. Durchlaufzeit. Die Durchlaufzeit gibt an, wie lange etwas von Anfang bis Ende dauert. In der Softwareentwicklung beginnt die Durchlaufzeit eines Projekts beispielsweise mit dem Angebot und endet mit der Lieferung.

2. Code-Umfang. Entwicklungsteams können anhand dieser Softwarekennzahl die Größe einer Anwendung bestimmen. Ist diese Kennzahl hoch, kann dies darauf hindeuten, dass die Entwickler bei ihren Programmierbemühungen produktiv waren. Allerdings ist diese Metrik nicht sinnvoll, wenn ein Entwicklungsteam versucht, zwei Projekte zu vergleichen, die in unterschiedlichen Programmiersprachen geschrieben wurden. Außerdem sollte man bedenken, dass mehr Code nicht immer effizienter oder effektiver ist, was später zu mehr Refactoring-Arbeit führen kann.

3. Work in Progress (WIP). Im Kontext der Softwareentwicklung ist WIP die Entwicklungsarbeit, mit der das Team begonnen hat und die sich nicht mehr im Backlog befindet. Ein Team kann Work in Progress in einem Burn-Down-Diagramm darstellen. Diese Diagramme sind ein gängiges Werkzeug für Agile und Scrum-Sprints und zeigen an, wie viel Arbeit das Team bereits abgeschlossen hat und wie viel Arbeit noch zu erledigen ist.

4. Agile Geschwindigkeit. Um die Geschwindigkeit zu berechnen, schaut sich ein agiles Softwareentwicklungsteam frühere Sprints an und zählt die Anzahl der User Stories oder Story Points, die im Laufe der Zeit abgeschlossen wurden. Agile Geschwindigkeit ist eine Schätzung, wie produktiv das Team innerhalb eines einzelnen Sprints sein wird.

Der agile Softwareentwicklungszyklus
Abbildung 1: Der agile Softwareentwicklungszyklus.

5. Sprint-Ziel-Erfolgsrate. Diese Softwaremetrik berechnet den Prozentsatz der Elemente, die das Entwicklungsteam im Sprint-Backlog abgeschlossen hat. Es kann sein, dass ein Team während eines bestimmten Sprints nicht 100 Prozent der Arbeit abschließt. Der Fortschritt des Teams kann jedoch immer noch der Definition von erledigt entsprechen – dem Schwellenwert, den ein Projekt erfüllen muss, damit eine Organisation es als abgeschlossen betrachtet. Wenn die Iteration der Definition von erledigt erfüllt, ist sie ein Erfolg.

6. Anzahl der Software-Releases. Agile und DevOps-Teams priorisieren häufige, kontinuierliche Software-Releases. Mit dieser Metrik können Teams verfolgen, wie häufig sie Software veröffentlichen, ob monatlich, wöchentlich, täglich, stündlich oder in einem anderen Zeitrahmen, und ob diese Kadenz letztendlich genügend Geschäftswert liefert.

Metriken zur Softwareleistung messen

Software-Performance bezieht sich auf quantitative Messungen des Verhaltens eines Softwaresystems. Leistungskennzahlen messen nicht-funktionale Attribute, das heißt wie eine Anwendung funktioniert, nicht was sie tut.

7. Aspekte der Softwareleistung. Leistungstests können die folgenden Eigenschaften einer Anwendung bewerten:

  • Skalierbarkeit
  • Stabilität
  • Reaktionsfähigkeit
  • Geschwindigkeit
  • Verfügbarkeit

Weitere wichtige Ausprägungen von Softwareleistungskennzahlen sind folgende:

8. Durchsatz. Der Durchsatz ist die Anzahl der Dateneinheiten, die ein System in einer bestimmten Zeitspanne verarbeitet.

9. Reaktionszeit. Die Reaktionszeit (Reponse Time) misst, wie viel Zeit ein System benötigt, um auf eine Anfrage oder Anforderung zu reagieren.

10. Zuverlässigkeit, Verfügbarkeit und Wartung. Dies bezieht sich auf die Fähigkeit einer Software, ihre Spezifikationen dauerhaft zu erfüllen; wie lange sie im Verhältnis zum erwarteten Umfang funktioniert; und wie leicht sie repariert oder gewartet werden kann.

Das Test-Manifest
Abbildung 1: Das Test-Manifest

Metriken zu Fehlern und Sicherheit messen

Entwicklungsteams müssen verstehen, wie und warum Anwendungen abstürzen, um sie besser entwickeln zu können. Diese Metriken zur Softwareentwicklung bewerten Fehler und Schwachstellen.

11. Fehlerdichte. Auf Code-Ebene können Entwickler die Anzahl der Fehler pro eintausend Codezeilen tabellarisch erfassen, um die Fehlerhäufigkeit zu bewerten.

12. Code-Abdeckung. Dies ist der Anteil des Quellcodes, den automatisierte Tests abdecken. Anhand dieser Metrik können Tester bestimmen, welche Bereiche des Codes sie noch nicht richtig getestet haben.

13. Fehlererkennung in Prozent. Diese Kennzahl ist das Verhältnis der Anzahl der Fehler, die vor der Veröffentlichung der Software gefunden wurden, im Vergleich zur Anzahl der Fehler, die nach der Veröffentlichung gefunden wurden. Um den Prozentsatz zu berechnen, nehmen Sie die Anzahl der Fehler, die vor der Veröffentlichung gefunden wurden (x), und die Anzahl, welche die Benutzer nach der Veröffentlichung vorgefunden haben (y), und berechnen Sie dann x/(x + y). Ein hoher Prozentsatz ist vorzuziehen, da dies bedeutet, dass ein größerer Teil der Fehler gefunden wurde, bevor die Kunden die Software verwendet haben.

14. Technische Schulden. Technische Schuld ist eine Metapher, die den langfristigen Aufwand sowie die zeitlichen und finanziellen Kosten widerspiegelt, die entstehen, wenn Entwickler ein Entwicklungsproblem nicht gleich beim ersten Auftreten angehen.

15. Zufriedenheit der Entwickler. Betrachten Sie die Zufriedenheit von Mitarbeitern oder Teams als einen weiteren nützlichen Indikator für die Produktivität und den Erfolg des Teams. Sie kann genauso wichtig sein wie technische Kennzahlen oder Softwarequalitätskennzahlen. Gestresste oder unzufriedene Teammitglieder können die Arbeitsproduktivität und letztlich die Softwareleistung beeinträchtigen. Behalten Sie Zahlen wie die Fluktuation von Teammitgliedern, auch Mitarbeiterfluktuation genannt, im Auge. Eine niedrigere Zahl bedeutet wahrscheinlich, dass die Mitarbeiter mit dem Unternehmen zufrieden sind.

16. Sicherheitsschwachstellen. Schwachstellenscans identifizieren Sicherheitsschwachstellen in einer Anwendung. Je geringer die Anzahl der gefundenen Schwachstellen ist, desto sicherer ist die Software.

17. Tatsächliche Sicherheitsvorfälle. Hierbei wird gezähl, wie oft ein Hacker eine Schwachstelle in der Software ausnutzt. Verfolgen Sie, wie oft diese Sicherheitsverletzungen auftreten, wie schwerwiegend der Angriff ist – zum Beispiel welche Daten gestohlen wurden – und wie lange der Vorfall gedauert hat.

IT-Organisationen verwenden verschiedene Durchschnittswerte, um das Auftreten von Softwarefehlern oder -mängeln zu berechnen.

18. Mittlere Zeit bis zur Fehlerentdeckung. Die mittlere Zeit bis zur Fehlerentdeckung ist ein Durchschnittswert, der angibt, wie lange es dauert, bis ein Team ein Problem oder einen Fehler bemerkt.

19. Mittlere Zeit zwischen Fehlern. Diese Metrik ist eine Berechnung, wie häufig ein Programm ausfällt.

20. Mittlere Zeit bis zur Behebung. Die mittlere Zeit bis zur Behebung ist ein Durchschnittswert, der angibt, wie schnell ein Team Fehler behebt.

Metriken zur Benutzererfahrung und -freundlichkeit messen

Benutzer erleben und interagieren mit Software auf unterschiedliche Weise. Genauso wie es schwierig ist, die Emotionen von Menschen zu klassifizieren, ist es auch eine Herausforderung, ihre Reaktion auf Software zu bewerten. Während keine einzelne Softwaremetrik die Gesamtheit der Benutzererfahrung (User Experience, UX) kommunizieren kann, gibt es dennoch ein paar hilfreiche Metriken.

21. UX-Kennzahlen. Messungen der Benutzererfahrung sind oft qualitativ und können die emotionalen oder körperlichen Reaktionen der Benutzer einbeziehen, zum Beispiel wie sehr sie der Software vertrauen und wie sich ihre Augen über eine Benutzeroberfläche bewegen.

22. Metriken zur Benutzerfreundlichkeit. Die Benutzerfreundlichkeit misst, wie gut die Software es den Kunden ermöglicht, ihre Ziele zu erreichen. Usability kann in kleinere Komponenten unterteilt werden, wie zum Beispiel:

  • Auffindbarkeit
  • Effizienz
  • Einprägsamkeit
  • Erlernbarkeit
  • Zufriedenheit
  • Barrierefreiheit, insbesondere digitale Barrierefreiheit

23. Net Promoter Score (NPS). Diese Softwaremetrik spiegelt die Bereitschaft der Kunden wider, eine Anwendung weiterzuempfehlen. Der Net Promoter Score wird als Zahlenbereich von 0 - 10 dargestellt. Kunden mit einem Wert von 0 bis 6 sind Detraktoren, 7 und 8 sind Passive oder Indifferente und 9 und 10 sind Promotoren.

Erfahren Sie mehr über Softwareentwicklung