Wir werfen einen Blick auf die verschiedenen Möglichkeiten, die Softwaregröße zu messen

Die Dimensionierung von Software ist nicht einfach, da es Hunderte von Sprachen, Architekturen und Techniken zum Schreiben gibt. Die Branche hat im Laufe der Jahre viele verschiedene Ansätze ausprobiert, aber der effektivste ist ein Ansatz namens „Functional Sizing“. Die Größe zu kennen ist im Allgemeinen Dies ist am nützlichsten, bevor der Code geschrieben wird. Die Größe kann auch ein Indikator für den Umfang der beteiligten Geschäftsfunktionen sein. Techniken wie das Zählen von User Stories, das Zählen von Story Points und die führenden Methoden zur Funktionspunktanalyse: COSMIC-Funktionspunkte und traditionelle (IFPUG) Funktionspunkte werden hier besprochen. Es ist auch möglich, die Größe nach dem Schreiben des Codes zu beurteilen, was im Allgemeinen weniger nützlich ist.

Um es gleich auf den Punkt zu bringen: Wir empfehlen Ihnen, in den meisten Fällen COSMIC-Funktionspunkte zu verwenden. Warum? weil sie valide, zuverlässig, konsistent, unspielbar, schnell messbar und für agiles Arbeiten geeignet sind, bei dem die vollständigen Anforderungen möglicherweise nicht im Voraus bekannt sind.

Warum ist die Softwaredimensionierung wichtig?

Die Entwicklung von Software ist arbeitsintensive Wissensarbeit. Der größte Kostentreiber bei der Entwicklung von Software ist in der Regel der menschliche Aufwand, sie zu erstellen, zu entwerfen und zu testen. Im Allgemeinen möchten wir wissen, wie viel Aufwand und wie viel Zeit die Lieferung in Anspruch nehmen wird. Es gibt viele Faktoren, die den Zeit- und Arbeitsaufwand beeinflussen. Der wichtigste Faktor ist Softwaregröße.  Schauen wir uns also die verschiedenen Ansätze zur Dimensionierung von Software an. Oft verwechseln wir Größenbestimmung mit Aufwandsschätzung. Beispielsweise handelt es sich bei den Story Points und der T-Shirt-Größe eigentlich nur um eine Aufwandsschätzung, nicht um eine Größenbestimmung.

Zeilen von Code

Codezeilen werden von den meisten Codierungstools einfach und automatisch erstellt. Es gibt zwei Hauptwerte: die Bruttoanzahl der verwendeten Zeilen (LOC) und die Nettoanzahl der Zeilen des Funktionscodes (SLOC).

Das Zählen von Codezeilen hat im Softwareprojektmanagement nur begrenzte Vorteile. Stellen Sie sich zum Beispiel zwei Entwickler vor, die beide an einem Tag 50 Zeilen Code schreiben. Es könnte sein, dass einer der Entwickler knappen, effizienten Code schreibt, der die zugrunde liegenden Sprachfunktionen gut nutzt. Seine 50 Zeilen liefern erhebliche Funktionalität, möglicherweise sogar eine ganze (winzige) Anwendung, während der andere möglicherweise nur eine sehr einfache Validierung durchführt. Oberflächlich betrachtet sind beide genauso produktiv wie die anderen, beide schreiben 50 Zeilen pro Tag. Dies ist der Hauptgrund dafür, dass wir die Verwendung von SLOC für die Softwaredimensionierung einschränken. SCHNELL, INKONSISTENT, IRREFÜHREND

Geschichten zählen

Viele Menschen sind der Meinung, dass es so gut wie alles andere ist, nur die Anzahl der Geschichten zu zählen. Dies ist ein unzuverlässiger Ansatz, da es sich bei einigen User Stories um bedeutende Entwicklungsvorhaben handelt, wir könnten sie eigentlich Epics nennen, während andere User Stories so trivial sind, dass sie überhaupt keine für den Benutzer erkennbare Funktionalität beinhalten. Der Bereich, den wir normalerweise sehen, liegt zwischen 0 und 120 CFP. Wie Sie sehen, verwenden wir die COSMIC-Dimensionierungsmethode, um zu überprüfen, ob andere Ansätze sinnvoll sind. SCHNELL, INKONSISTENT, IRREFÜHREND

Story Points zählen

Story Points sind ein willkürlicher Indikator zur Größenmessung, der stets nur innerhalb eines Teams verwendet werden sollte. Sie sind weder ein gültiges Maß noch eine Messgröße, um den Fortschritt gegenüber der Mannschaft zu bestimmen. Denken Sie daran, dass sich Story Points im Laufe der Zeit ändern können und eine inkonsistente Meinung über die voraussichtliche Dauer einer Aktivität darstellen. Sie sind für diejenigen, die die Zählung vorgeben, sehr spielbar. Die Popularität von Story Points ist ein etwas bizarres Verhalten der Mehrheit der Softwarebranche – ihre Popularität ist nicht gerechtfertigt. Andererseits sind COSMIC Sizing und IFPUG Sizing beide formale, konsistente ISO-Standards zur Größenmessung.

Die Größe einer User Story kann erheblich variieren. Eine Geschichte kann in wenigen Minuten geliefert werden, für eine andere kann ein ganzes Team einen Monat lang arbeiten müssen. Das Zählen von Geschichten unterschiedlicher Größe ist ein Hinweis auf den Fortschritt, aber kein gültiges Maß für den Fortschritt.  LANGSAM, INKONSEQUENT, IRREFÜHREND

Die von ScopeMater automatisierte Funktionspunktdimensionierung ist ein bahnbrechender Ansatz, um Sicherheit in Softwareprojekte zu bringen

Wie hilft die Größenbestimmung von Funktionspunkten?

Der bedeutendste Kostentreiber bei Software ist Bemühung (menschliche Arbeit beim Spezifizieren, Entwerfen, Entwickeln und Testen) von Software. Der beste Vorwärtsindikator für den erforderlichen Aufwand ist Größe, insbesondere die Größe in Funktionspunkte . Wenn Sie die Größe kennen, können Sie den Aufwand vorhersagen. Sie können tatsächlich mit Sicherheit vorhersagen, wie viel Personal benötigt wird, wie viel Zeit benötigt wird und wie viele Mängel Sie finden und beheben müssen.  Diese Vorhersehbarkeit hilft Managern, effektiv zu planen.  Natürlich wird es einige Unbekannte geben, aber nicht so viele, wie die meisten behaupten würden.

Verschiedene Möglichkeiten zur Größenanpassung von Software

Empfohlen:

  • KOSMISCHE Funktionspunkte
  • IFPUG-Funktionspunkte

Kann nützlich sein:

  • RICEFW
  • Objektanzahl
  • Zeilen von Code
  • DB-Tabellen zählen
  • Zählen Sie OO-Klassen

Nicht empfohlen:

  • Story-Punkte
  • Geschichten zählen
  • T-Shirt-Größen

Funktionspunktanalyse

ISO-Standard-Funktionsgrößenbestimmung

Die einzige konsistente Methode zur Messung der Softwaregröße (Stand 2023) ist die funktionale Dimensionierung. Es gibt zwei führende Standards für funktionale Größen:   IFPUG-Funktionspunkte (1. Generation) und  KOSMISCHE Funktionspunkte Punkte (2. Generation).

Beide Function Point-Standards sind ausgereift, gültig und bewährt (IFPUG:1974, COSMIC:1998). Sie sind eine konsistente, benutzerzentrierte Beschreibung und Messung der Funktionalität in Bezug auf Ein- und Ausgänge sowie gespeicherte Daten. Sie werden gezählt, indem die Anforderungen untersucht und einige Regeln/Prinzipien angewendet werden, um die Datentypen zu bestimmen, die verschoben und gespeichert werden. Beide Standards sind ausgereift, werden unabhängig gepflegt und sind kostenlos bzw. kostengünstig zu erlernen. Wir empfehlen die COSMIC-Größenbestimmungsmethode der 2. Generation. Die Einheiten der COSMIC-Dimensionierungsmethode sind der COSMIC Function Point (CFP). Die Arbeit zur Durchführung der Funktionspunktgrößenbestimmung wird als Funktionspunktanalyse (FPA) bezeichnet.

Cosmic- und ifpug-Software-Messstandards für die Größenbestimmung von Funktionspunkten

KOSMISCHE Funktionspunkte. EMPFOHLEN

Zu den wichtigsten Vorteilen des COSMIC FP-Standards gehören:

  1. COSMIC Sizing basiert auf Prinzipien des Softwaredesigns. Standardmäßig ist keine Optimierung erforderlich, wenn es auf verschiedene Arten von Software angewendet wird (kundenspezifische Codierung, Middleware, Web-Apps, mehrschichtige Software, Systemsoftware, eingebettete Systeme oder Data-Warehouse-Projekte).
  2. COSMIC gibt uns eine Definition eines einzelnen Funktionspunkts. Jede Bewegung einer Datengruppe (Eintritt, Austritt, Lesen, Schreiben) zählt als 1 CFP.
  3. CFP kann anhand unvollständiger Anforderungen genau gemessen werden, wodurch sie für Agile und verschiedene Formen skalierter Agile-Arbeit geeignet sind.
  4. CFP sind schneller und einfacher zu erlernen als IFPUG FP. (1/3 der Seitenanzahl für den gesamten Methodenlehrplan)
  5. COSMIC FP kann über eine automatisierte Anforderungsanalyse automatisiert und mit höherer Präzision ermittelt werden als IFPUG.

Um mehr über COSMIC Sizing zu erfahren, empfehlen wir Der Leitfaden zur Softwaredimensionierung von Charles Symons

IFPUG-Funktionspunkte

Allerdings sind COSMIC FP den traditionellen IFPUG FP vorzuziehen, letztere profitieren von größeren Mengen veröffentlichter und verfügbarer Benchmark-Daten. Die IFPUG-Dimensionierungsmethode wurde in den 1970er Jahren entwickelt, als das Softwaredesign weniger vielschichtig und getrennt war als heute. Die Standards bleiben gegenüber ihrem ursprünglichen Konzept weitgehend unverändert. Wir mögen IFPUG FP, aber wir bevorzugen COSMIC FP. Simple Function Points ist eine Annäherung an IFPUG FP, die von der Organisation im Jahr 2019 übernommen wurde. ScopeMaster schätzt beides IFPUG Und Einfaches FP.

Funktionspunkte manuell zählen

Bisher war das Zählen von Funktionspunkten ein mühsamer manueller Prozess. Sie müssen die Anforderungen lesen und dann die Anzahl der Funktionspunkte auf Papier oder in einer Tabelle aufzeichnen. Genaue und konsistente Zählungen werden nur erreicht, wenn die Zählung von einem zertifizierten und erfahrenen Funktionspunktspezialisten durchgeführt wird. Im Durchschnitt kann ein zertifizierter Messgeräter bis zu 2000 FP/Woche messen, das entspricht etwa $2m Software.  LANGSAM, GENAU

Schätzen der Funktionspunktgröße

Mithilfe einiger Faustregeln können geschätzte FP-Zahlen ermittelt werden, indem eine Reihe von Faktoren berücksichtigt werden. Wenn es sich bei Ihrer Anwendung überwiegend um eine Datenbankanwendung handelt, können Sie die Anzahl der Datenbanktabellen mit Daten zählen, die von der Anwendung verwaltet werden. Anschließend multiplizieren Sie die Anzahl der Tabellen mit 27–30, um eine IFPUG-Schätzung zu erhalten. Dies ist nur eine von vielen nützlichen Faustregeln, auf die man sich nur bei großen Levelgrößen verlassen sollte. Zählgeschwindigkeit: 5.000 – 50.000 FP / Personenwoche  SCHNELL, UNGENAU

Funktionspunkte aus Codezeilen nach hinten losgehen

Die meisten Softwaresprachen haben Durchschnittswerte für Codezeilen pro Funktionspunkt veröffentlicht. Beispielsweise entsprechen 50 Java-Zeilen im Durchschnitt einem Funktionspunkt. Das Zählen der Codezeilen und das Teilen durch diese Zahl wird als „Rückschlag“ bezeichnet. Das ist nützlich nach Der Code wurde geschrieben. Sie müssen bei diesem Ansatz vorsichtig sein, insbesondere wenn Sie große Mengen vorgefertigter Frameworks verwenden, die möglicherweise von der Zählung benutzerdefinierten Codes ausgeschlossen werden müssen. Zählgeschwindigkeit: bis zu 5.000 FP/Personenwoche.  SCHNELL, UNGENAU, IRREFÜHREND

Automatisierte Funktionspunktzählung aus Code

Es ist jetzt möglich, die Funktionspunktzählung aus dem Code zu automatisieren. Das Unternehmen Cast Software hat Software entwickelt, die eine zuverlässige automatisierte Funktionspunktzählung basierend auf vorhandenem Anwendungscode durchführt. Es erfordert einige Anstrengungen, den Code so vorzubereiten, dass er interpretiert werden kann. Anschließend kann eine zuverlässige Zählung erreicht werden. Dies ist dem Backfire-Ansatz weit überlegen. Es hat den zusätzlichen Vorteil, dass es einen tiefen Einblick in den Anwendungscode bietet.   SCHNELL, KONSEQUENT, GENAU

Automatisierte COSMIC-Funktionspunktgröße

Mit ScopeMaster® können Sie innerhalb weniger Minuten von einer automatisierten COSMIC-Funktionspunktzählung profitieren. Durch die Analyse des Textes der Benutzeranforderungen können wir die funktionale Größe (Datenbewegungen) ermitteln. ScopeMaster® liefert ein konsistentes Ergebnis mit einer Genauigkeit von mehr als 85% im Vergleich zu einer manuellen Zählung durch einen Experten.

Die Ergebnisse sind konsistent Und transparent. In Kombination mit einer manuellen Überprüfung durch einen Funktionspunktspezialisten sehen wir Zählraten von 10.000 – 20.000 FP / pro Mannwoche. (ungefähr $10–$20m Software) SCHNELL, KONSEQUENT, ZIEMLICH GENAU

Von ScopeMaster® generierte Funktionspunktinformationen

Einige der Größenanalysen ScopeMaster® generiert automatisch aus Ihren geschriebenen User Stories.

Abschluss

Wenn Sie die Größe einer Anwendung bestimmen möchten aus den schriftlichen Anforderungen Sie haben im Wesentlichen zwei Möglichkeiten: Funktionspunkte manuell zählen oder ScopeMaster® verwenden, um sie für Sie zu zählen. Wenn Sie bereits über Anwendungscode verfügen, den Sie messen möchten, gibt es weitere Möglichkeiten: Backfire anhand der Codezeilen, Schätzung anhand technischer Komponenten (z. B. basierend auf der Anzahl einer Datenbanktabelle) oder schauen Sie sich die Automatisierung der Funktionsdimensionierung von CAST Software an .