Africa Studio - stock.adobe.com

23 kritische Metriken für erfolgreiche Entwicklungsprojekte

Leistungsstarke, ansprechende und sichere Apps entstehen nicht zufällig. Hier sind 23 KPIs, um den Softwareentwicklungsprozess und die Softwarequalität zu verbessern.

Softwareentwicklungsmetriken können Aufschluss darüber geben, wie sich eine Anwendung verhält 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 (UX)

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. Studieren Sie folgende 23 Metriken und erstellen Sie ein Set von KPIs für die Softwarequalität.

Metriken zur Entwicklerproduktivität

Es gibt viele Möglichkeiten, die Effizienz des Teams und die geleistete Arbeit zu diskutieren oder zu bewerten. Produktivitätsmetriken ermöglichen es Entwicklungsmanagern, Projekte besser zu steuern. Stellen Sie eine Mischung aus diesen Softwaremetriken zusammen, um unter anderem zu messen, wie weit ein Projekt fortgeschritten ist, wie hoch die Produktivität der Entwickler ist und wie viel zusätzliche Entwicklungszeit nötig ist.

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

2. Menge des Codes. Entwicklungsteams können anhand dieser Softwarekennzahl die Größe einer Anwendung bestimmen. Wenn dieser KPI hoch ist, 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. Denken Sie auch daran, dass mehr Code nicht immer zu effizientem Code führt, was später mehr Refactoring-Arbeit erfordern kann.

3. Work in Progress (WIP). In einem Software-Engineering-Kontext ist WIP die Entwicklungsarbeit, mit der das Team begonnen hat und die sich nicht mehr im Backlog befindet. Ein Team kann den WIP 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 Software-Entwicklungsteam frühere Sprints an und zählt die Anzahl der User Stories oder Story Points, die im Laufe der Zeit fertiggestellt 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 fertig entsprechen – dem Schwellenwert, den ein Projekt erfüllen muss –, damit eine Organisation es als abgeschlossen betrachtet. Wenn die Iteration die Definition von fertig erfüllt, ist sie ein Erfolg.

6. Anzahl der Software-Releases. Agile und DevOps-Teams legen Wert auf häufige, kontinuierliche Software-Releases. Mit dieser Metrik können Teams verfolgen, wie häufig sie Software freigeben, 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

Software-Performance bezieht sich auf quantitative Maße für das Verhalten eines Softwaresystems. Leistungsmetriken 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 Software-Leistungskennzahlen 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

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 Häufigkeit von Defekten zu bewerten.

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

13. Prozentsatz der Fehlererkennung. Diese Metrik ist ein Verhältnis zwischen der Anzahl der vor Software-Releases gefundenen Fehler und der Anzahl der nach dem Release gefundenen Fehler. 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 Anteil der Fehler gefunden wurde, bevor die Kunden die Software verwendet haben.

14. Technical Debt. 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. Behandeln Sie die Zufriedenheit der Mitarbeiter oder des Teams als einen weiteren nützlichen Indikator für die Produktivität und den Erfolg des Teams. Sie könnte genauso wichtig sein, wie jede technische Metrik oder Softwarequalitäts-KPI. Gestresste oder unzufriedene Teammitglieder können die Arbeitsproduktivität und letztlich auch die Softwareleistung beeinträchtigen. Behalten Sie Zahlen wie die Fluktuation von Teammitgliedern im Auge. Eine niedrigere Zahl bedeutet wahrscheinlich, dass die Mitarbeiter im 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. Dieser KPI zählt die Anzahl der Fälle, in denen ein Hacker eine Sicherheitslücke in der Software ausnutzt. Verfolgen Sie, wie oft diese Verstöße auftreten, die Schwere des Angriffs, zum Beispiel, welche Daten gestohlen wurden, und die Dauer des Vorfalls. IT-Organisationen verwenden verschiedene Durchschnittswerte, um das Auftreten von Softwarefehlern oder -defekten zu berechnen.

18. Mittlere Zeit bis zur Fehlerentdeckung. Die mittlere Zeit bis zur Entdeckung 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 Benutzerfreundlichkeit und Benutzererfahrung

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

Fortsetzung des Inhalts unten

Erfahren Sie mehr über Softwareentwicklung

ComputerWeekly.de
Close