Software-Benchmarking

Software-Benchmarks für Projektvorhersehbarkeit

Sie möchten Ihre Leistung mit anderen vergleichen, intern oder mit Teams in anderen Organisationen. Für Vergleiche zwischen internen Teams können Sie Ihre eigenen internen Benchmarks erstellen, während Sie für den Vergleich mit anderen in der Softwarebranche nach Branchen-Software-Benchmarks suchen. Dieser Artikel konzentriert sich auf angemessenes Benchmarking der Softwarearbeit damit Sie die Leistung Ihrer Teams mit denen anderer vergleichen können. 

Nb. In diesem Artikel geht es nicht um das Benchmarking der Softwareleistung (Geschwindigkeit).

Software-Benchmarking kann Unternehmen helfen zu verstehen, wie gut sie abschneiden und wo sie sich verbessern könnten. Auch mit Benchmarks können Manager die entscheidenden Fragen zu einem Softwareprojekt beantworten "Wie lange wird es dauern?" Und "Wie viel wird es kosten?"   Benchmarks können auch dazu verwendet werden, wertvolle Geschäftsentscheidungen darüber zu treffen, auf welche Softwarearbeit man sich konzentrieren sollte.

Hintergrund

Software wird in den meisten Branchen zum entscheidenden Unterscheidungsmerkmal zwischen erfolgreichen und erfolglosen Unternehmen. Die Fähigkeit, qualitativ hochwertige, innovative und differenzierende Softwarefunktionen schneller als die Konkurrenz zu entwickeln, ist einer der Schlüssel dafür, dass ein Unternehmen seine Konkurrenten schlägt. Letztendlich könnte es zu einem entscheidenden Faktor für das Überleben von Unternehmen werden, was für technologiebasierte Unternehmen bereits der Fall ist.

Es wird immer wichtiger zu wissen, wie Ihr Unternehmen im Vergleich zu anderen hinsichtlich seiner Fähigkeit, Softwarefunktionen bereitzustellen, abschneidet. Hier kommt Benchmarking ins Spiel.

Benchmarking der Entwicklerproduktivität

Der Fokus liegt tendenziell auf Entwicklerproduktivität, und zwar aus drei Gründen:

1. Variable. Die Produktivität der Entwickler variiert erheblich – die erfahrensten Entwickler sind 100-mal produktiver als die am wenigsten qualifizierten.
2. Bedeutsam. Die Entwicklerkosten sind in der Regel der größte Kostenfaktor bei der Bereitstellung von Software.
3. Wertvoll. Um wettbewerbsfähig zu bleiben, sind Unternehmen auf die Bereitstellung von Software angewiesen. Daher ist die Geschwindigkeit, mit der diese bereitgestellt werden kann, für ein Unternehmen von Bedeutung.

Das grundlegende Maß für die Leistung ist die funktionale Größe, aber die Qualität darf nicht außer Acht gelassen werden.

Das nützlichste Basismaß für den Output ist die Menge Vom Benutzer erkennbare Funktionalität die von einem Entwickler oder einem Entwicklungsteam in hoher Qualität geliefert werden können. Der beste Weg, dies festzustellen, ist nicht das Zählen der Codezeilen, sondern die funktionale Größe der gelieferten Software. Die funktionale Größe wird mithilfe des ISO-Standards COSMIC Function Point (CFP) gemessen. Der CFP ist das modernste und universellste Standardmaß für die Softwaregröße. Es handelt sich um ein technologieunabhängiges Maß für die vom Benutzer erkennbare Größe. Die Produktivität von Entwicklern und Entwicklungsteams kann als durchschnittlicher CFP pro Monat oder durchschnittlicher CFP pro Sprint verglichen werden.

Benchmarks zur Entwicklerproduktivität

Jeder Entwickler oder jedes Team kann einem Benchmarking unterzogen werden CFP pro Sprint.

Warnung: Produktivitätskennzahlen müssen eine Überprüfung der Qualität erfordern.

Dies sind Werte, die der Autor bei Dutzenden kleineren Projekten (250–1500 CFP) beobachtet hat. Sie sollten Ihre eigenen Benchmarks festlegen und pflegen. Sie werden oft auch als Kehrwert ausgedrückt, als CFP, das pro Zeiteinheit geliefert wird. Z.B. 20 CFP pro Monat.

Faustregel: Als allgemeine Faustregel gelten 10–20 CFP pro Entwickler und Monat. Die beobachtete Entwicklerproduktivität liegt je nach Umständen, Domäne, Tools und Kompetenz zwischen 2 und 200 CFP pro Entwickler und Monat.

Benchmarks zur Teamproduktivität

Als allgemeiner Richtwert gilt, dass bei einem Team von sieben, vier Entwicklern, zwei Testern und einem Business-Analysten im Durchschnitt 4 Stunden pro CFP produziert werden, d. h. 80 CFP pro zweiwöchigem Sprint. Dies kann reduziert werden, wenn Fehler aus früheren Sprints übertragen werden, die behoben werden müssen.

Faustregel: 70 CFP pro Sprint sind eine vernünftige erste Schätzung, aber Sie sollten Ihre eigenen Benchmarks festlegen.

Die meisten Manager möchten wissen, wie ihr Team und ihr Unternehmen im Vergleich zu anderen abschneiden:

• Produktivität der Softwareentwicklung
• Softwarequalität
• Softwareausgaben
• Preis-Leistungs-Verhältnis der Software

Beim internen Software-Benchmarking werden verschiedene Teams oder Projekte innerhalb einer Organisation verglichen. Beim externen oder Branchen-Software-Benchmarking werden diese Merkmale mit externen Normen verglichen.

In diesem Artikel wird untersucht, welche Software-Metriken einem Benchmarking unterzogen werden können und welche Metriken verwendet werden sollten, um keine unbeabsichtigten Konsequenzen hervorzurufen.

Die dargestellten tatsächlichen Benchmark-Werte dienen nur zur Orientierung und sollten nicht als endgültige Benchmarks betrachtet werden. In allen Fällen sind interne Benchmarks am besten, die aus früheren Arbeiten in Ihrer Organisation zusammengestellt werden.

Beim Schreiben dieses Beitrags wurde keine KI eingesetzt.

Software-Ressourcen-Benchmarks

Für die Teamplanung müssen Führungskräfte wissen, was das ist ideale Menge an Arbeit, die jemand bewältigen kann. Software ist Wissensarbeit und die kognitiven Einschränkungen der Entwickler sind so groß, dass sie nur mit einer bestimmten Menge an Funktionalität vernünftig umgehen können. Unsere Beobachtungen gehen davon aus, dass dies etwa 150 CFP beträgt. Das bedeutet, dass Sie unabhängig von der Größe Ihres Projekts wahrscheinlich mehr als einen Entwickler benötigen, wenn Ihr Gesamtumfang mehr als 180 CFP beträgt. Die folgende Tabelle ist eine Richtlinie für die typische Kapazität nach Rolle.

Für ein 1000-CFP-Projekt sind beispielsweise 1 Projektmanager, 2 Business-Analysten, 3 Tester und 5 Entwickler erforderlich. Diese Zahlen hängen von der Kompetenz und dem Fachwissen der Beteiligten ab. Wo immer möglich, ist es am besten, kleinere Teams mit hochkompetenten Personen anzustreben.

Beachten Sie, dass ein einzelner Entwickler für Softwarewartungsarbeiten in der Regel mehr als 180 CFP bewältigen kann. Normalerweise ist für die Wartung ein Vollzeitentwickler pro 1500–2500 CFP erforderlich.

Software-Qualitäts-Benchmarks

Softwarequalität ist eine Frage des kommerziellen Vorteils. Das Unternehmen, das stets qualitativ hochwertige Software liefert, die für Kunden nützlich ist, wird seine Konkurrenten wahrscheinlich übertreffen. Das Benchmarking von Software-Qualitätsmetriken wird daher zu einem wichtigen Vergleichsinstrument für Unternehmen.

Fehlerpotenziale

Die Anzahl der Fehler in einer Software kann vorhergesehen werden. Die Fehler können anhand der Größe der Software vorhergesagt werden. Es liegt auf der Hand, dass eine größere Software das Potenzial hat, fehlerhafter zu sein als eine kleine Software. Der Defektpotenzial ist das Konzept der Anzahl von Fehlern, die wahrscheinlich in einer Software vorhanden sind, bevor wir mit Maßnahmen zur Fehlererkennung/-vermeidung/-beseitigung beginnen.

Typische Fehlerpotenziale liegen bei 4–5 Fehlern pro CFP. Diese Mängel variieren in ihrer Schwere und in ihrer Ursache. Typischerweise wie folgt:

Quelle: Capers Jones, The Economics of Software Quality, 2011.

Dies bedeutet, dass es wahrscheinlich 5 Mängel pro CFP gibt, es sei denn, wir führen Qualitätsverbesserungsmaßnahmen durch, um Mängel in jedem dieser Bereiche zu finden und zu beheben.

Das Bewusstsein für das Fehlerpotenzial hilft bei der Beantwortung dieser Fragen:

• Wie viele Fehler müssen wir finden, um eine angemessene Qualität zu erreichen?
• Wie viele Mängel sind voraussichtlich offen?
• Wie viele Tests müssen wir noch durchführen?
• Sind wir bereit, live zu gehen?

Effizienz der Fehlerbeseitigung

Die Qualität eines Softwareprodukts wird im Allgemeinen als die Anzahl der bei der Produktion auftretenden Fehler definiert. Die Anzahl der „neuen“ Mängel nimmt in den ersten 3 Monaten ab, sodass wir sagen können, dass die Die Effizienz der Fehlerbeseitigung wird durch die Anzahl der in den ersten drei Monaten der Nutzung festgestellten Fehler als Prozentsatz des Fehlerpotenzials bestimmt, das auf der Menge der bereitgestellten Funktionalität basiert.

Software-Benchmarking – Zeitpläne

Der Zeitplan oder die Zeit, die für die Bereitstellung der Software benötigt wird, ist eine direkte Folge der Produktivität des Teams, das an der Software arbeitet. Wir haben die Entwicklerproduktivität im Hinblick auf die Teamleistung pro Sprint mit etwa 70 CFP pro zweiwöchigem Sprint oder 140 CFP pro Monat untersucht. Dies gibt uns einen klaren Leitfaden zur Beantwortung der Frage. "Wann wird es fertig sein?"

Faustregel: Bei kleinen Projekten mit weniger als 1000 CFP: Ein Team liefert normalerweise 140 CFP pro Monat.

Faustregel: Bei großen Projekten mit über 1000 CFP+ nimmt die Produktivität mit der Größe ab: Anzahl der zu liefernden Monate = CFP ^ 0,4

Beachten Sie, dass die Bereitstellung von Funktionen in schlechter Qualität das Projekt insgesamt verlangsamt. Nur mit hoher Qualität können schnellste Zeitpläne erreicht werden.

Tipp: Wenn ein CFP geliefert wurde, aber in einem nachfolgenden Sprint ein Fehler entdeckt wird, zählen Sie es nicht als geliefert.

Benchmarking des gelieferten Werts

Wenn ein Unternehmen $1000 für die Bereitstellung von 1 CFP neuer Funktionalität ausgibt. Man geht davon aus, dass der Gesamtgeschäftswert dieser Funktionalität kurz- und langfristig die Kosten von $1000 übersteigt. Der Wert pro CFP variiert, aber Unternehmen sollten eine Wertrendite von 1–3 Jahren im Sinne eines Vielfachen der Kosten pro CFP in Betracht ziehen. Der dreijährige kommerzielle Nutzen pro CFP ist eine nützliche Kennzahl zur Nachverfolgung und kann als Benchmark herangezogen werden.

Eigentumsgesamtkosten

Über die anfänglichen $1000-Baukosten einer CFP hinaus sollten Unternehmen die Gesamtbetriebskosten über die Lebensdauer dieser Software einkalkulieren. Beispielsweise werden in den ersten beiden Jahren nach dem ersten Bau wahrscheinlich erhebliche Verbesserungen vorgenommen, etwa 201 TP3T im ersten Jahr und weitere 151 TP3T im zweiten Jahr, danach typischerweise 81 TP3T pro Jahr. Sie können intern Ihre eigenen Benchmarks für die Gesamtbetriebskosten von Softwareanwendungen in Ihrem Portfolio festlegen. Diese Daten helfen bei Entscheidungen über Systemaustauschpläne.

Faustregel: Die 5-Jahres-Gesamtbetriebskosten betragen in der Regel das Zwei- bis Dreifache der Anschaffungskosten.

Benchmarking-Umfangsänderung

Im Laufe eines Projekts entstehen neue Anforderungen oder werden offensichtlich. Während einiges davon von vornherein erkennbar ist, ist es bei anderen nicht so. Diejenigen Organisationen, die ausreichend Geld für die Anforderungsarbeit ausgeben (15% oder mehr für kundenspezifische Entwicklung, mehr für Paketimplementierungen wie ERPs), werden nicht nur kürzere Zeitpläne erreichen, sondern auch weniger Umfangsänderungen während des Projekts erleben. Kapern Jones

Faustregel: 1-2% Umfangsänderung pro Monat während eines Projekts.

Faustregel: 8% pro Jahr Umfangsänderung nach der Implementierung.

 

Benchmarking technischer Schulden

Unter technischen Schulden versteht man die Nacharbeit, die sich aus neuen Anforderungen ergibt, die beim ersten Schreiben des Codes noch nicht bekannt waren. Um technische Schulden zu quantifizieren und zu bewerten, muss zunächst die Nacharbeit sorgfältig klassifiziert werden, die verursacht wird durch:

• Fehler im Code (keine technischen Schulden)
• Abkürzungen für eine schnelle Bereitstellung (keine technische Schuld im ursprünglichen Konzept, wird aber allgemein als solche angenommen)
• Überarbeitung, da unzureichende Anforderungen an die Arbeit durchgeführt wurden (erkennbare Unbekannte ergeben sich später). Das sind vermeidbare technische Schulden.
• Nacharbeiten, da später Anforderungen auftauchen, die früher nicht erkennbar waren. (Dies ist die unvermeidliche echte technische Schuld.)

Die meisten Organisationen halten sich nicht an die oben genannten Klassifizierungen und werden daher Schwierigkeiten beim Benchmarking technischer Schulden haben.

 

Eigentumsgesamtkosten

Über die anfänglichen Baukosten von $1000 hinaus sollten Unternehmen die Gesamtbetriebskosten über die Lebensdauer dieser Software einkalkulieren. In den ersten beiden Jahren nach dem ersten Bau wird es voraussichtlich erhebliche Verbesserungen geben, etwa 201 TP3T im ersten Jahr und weitere 151 TP3T im zweiten und 81 TP3T pro Jahr danach. Darüber hinaus erfolgt die jährliche Wartung der Software, entweder um sie auf einer sich ständig ändernden Infrastruktur funktionsfähig zu halten oder um auftretende Fehler zu beheben. Kapern Jones

Faustregel: Die 5-Jahres-Kosten betragen normalerweise das Dreifache der anfänglichen Kosten.

Andere Benchmarks für Software-Arbeit

Ingenieure pro Kunde/Benutzer

Diese Zahl wird häufig von Saas-Verbraucherprodukten wie Facebook und Twitter genannt. Häufiger wird sie in Tausenden von Benutzern pro Ingenieur ausgedrückt. Dies ist eine nützliche Kennzahl für solche Organisationen.

Umsatz pro DevOps-Ingenieur

In softwareintensiven Unternehmen, in denen das technische Personal einen der Hauptkosten des Unternehmens darstellt, ist die Verfolgung des Gesamtumsatzes pro DevOps-Ingenieur ein umfassender Indikator für die technische Effizienz.

DORA-Metriken

Bereitstellungshäufigkeit

Ist ein Maß dafür, wie oft neuer Code (in beliebiger Menge) für die Produktion freigegeben wird. Es ist ein nützlicher, einmaliger Indikator für die Wiederholbarkeit des Entwicklungs-/Testzyklus. Die Bereitstellungshäufigkeit sollte in Stunden oder Tagen und nicht in Wochen gemessen werden.

Mittlere Wiederherstellungszeit

Mit „Mean Time to Restore“ wird die verstrichene Zeit erfasst, die zur Wiederherstellung des Dienstes nach einem Produktionsausfall benötigt wird. Dies ist ein Indikator für die Fähigkeit einer Mannschaft, sich von einem Fehler zu erholen. Es sollte in Minuten oder Stunden gemessen werden, nicht in Tagen.

Vorlaufzeit für Änderungen

Die Vorlaufzeit für Änderungen erfasst die Zeit, die der Code benötigt, um von der Verpflichtung zur erfolgreichen Ausführung in der Produktion zu gelangen. Dabei werden das Ausmaß, der Wert und die Komplexität der Änderung nicht berücksichtigt. Es geht mehr um die Bereitstellungseffizienz als um die Entwicklungseffizienz.

Ausfallrate ändern

Die Änderungsfehlerrate ist ein Indikator für die Qualität des bereitgestellten Codes.

Vorteile von DORA-Metriken

Sie sind leicht zu verfolgen

Sie konzentrieren sich auf DevOps-Aktivitäten.

Nachteile von DORA-Metriken

Sie konzentrieren sich auf Änderungsraten, unabhängig von Größe oder Kundenwert.

Für die Projektplanung, Dimensionierung und Nachverfolgung sind sie meist ungeeignet

Sie eignen sich lediglich zum Benchmarking von DevOps- oder DevSecOps-Aktivitäten,

Schädliche Benchmarks für Software-Arbeit

Organisationen erfassen häufig fälschlicherweise Kennzahlen, die zu unbeabsichtigten Konsequenzen führen können. Diese sollten mit großer Vorsicht verwendet oder ganz vermieden werden und darüber hinaus nicht als Grundlage für Benchmarking verwendet werden.

Pro Ingenieur erstellte Codezeilen

Dies kann dazu führen, dass Entwickler ausführlichen Code anstelle von effizientem oder wiederverwendetem Code schreiben. Stattdessen verwenden Pro Ingenieur produziertes CFP

• Pro Monat pro Ingenieur auftretende Fehler
  • Die Anzahl der erzeugten Fehler sollte im Kontext der Ausgabe berücksichtigt werden. Ein Entwickler, der 1 Fehler pro Monat und nur 1 CFP produziert, ist weniger leistungsfähig als einer, der 2 Fehler pro Monat in 10 CFP produziert. Stattdessen verwenden Fehler pro produziertem CFP pro Ingenieur.
• Kosten für die Feststellung eines Mangels
  • Je höher die Qualität der Software, desto aufwendiger ist die Fehlersuche. Hohe Kosten pro Fehlerentdeckung können bedeuten, dass die Software bereits einen hohen Wert hat.

Interne Benchmarking-Tipps

1. Geben Sie die Namen von Projekten im Rahmen interner Vergleichsbenchmarks bekannt
2. Zeigen Sie Komponentenmetriken an, nicht nur die Gesamtwerte.
3. Beziehen Sie nicht-kodierende Aktivitäten ein.
4. Beziehen Sie menschliche Aspekte ein.
5. Verwenden Sie funktionale Größenmetriken.
6. Nutzen Sie die Daten nicht zur Festlegung abstrakter Ziele.

Zusammengefasst von Capers Jones Präsentation zum Thema Benchmarking