Methoden zur Messung funktioneller Größen

Dies ist der zweite Teil des Blogs, der sich auf eine Reihe gängiger Methoden zur Messung der Softwaregröße und deren Nützlichkeit für die Schätzung von Softwareprojekten konzentriert. In diesem zweiten Teil werden die Methoden zur Messung der Funktionsgröße IFPUG beschrieben, NESMA und COSMIC sind abgedeckt. In zukünftigen Blogs werde ich nicht-funktionale Größenmessmethoden und Hybridmethoden behandeln.

Lesern, die sich für dieses Thema interessieren, wird dringend empfohlen, zuerst die erster Teil dieses Blogs, bevor Sie diesen zweiten Teil lesen.

Damit eine bestimmte Methode zur Messung der Softwaregröße für die Schätzung von Softwareprojekten nützlich ist, Folgende Eigenschaften sollten zutreffen:

• Die Größenmessmethode kann in einem Objektiv durchgeführt werden (unabhängig von der Person, die es tut), wiederholbar, überprüfbar und daher vertretbar Weg;
• Größe an sich ist nur sinnvoll, wenn historische Daten ist von Projekten verfügbar, die mit dieser Größenmessungsmethode gemessen wurden;
• Die Größenmessmethoden sollten unterstützt werden durch parametrische Modelle und/oder Werkzeuge um projektspezifische Besonderheiten, die die Schätzung beeinflussen, genau zu berücksichtigen, wie zum Beispiel COCOMO II, SCHLANK, SEER für Software oder Wahre Planung.

Na sicher, Jede Methode zur Messung der Softwaregröße, die eines oder mehrere dieser Kriterien nicht erfüllt, kann für ein Unternehmen dennoch sehr nützlich sein, sofern sie ein Verfahren erstellen, um wiederholbare Größenmessungen zu gewährleisten, historische Daten sammeln und analysieren und/oder eigene Schätzmodelle auf der Grundlage der gesammelten Daten erstellen. Für diesen Blog jedoch, Der Fokus liegt auf der theoretischen Nützlichkeit der spezifischen Messmethode für die Schätzung von Softwareprojekten im Kontext von Organisationen, die noch keinen parametrischen Schätzungsprozess haben. Für diese Organisationen, die bereit sind, eine Größenmessmethode zu implementieren, um Softwareprojekte zu schätzen, Dieser Blog kann als Richtlinie für die Auswahl einer bestimmten Methode dienen.

Ich ermutige jeden, Kommentare und/oder Feedback zu diesem Blog abzugeben.

Nesma FPA

Nesma FPA ist IFPUG sehr ähnlich, da es die gleichen grundlegenden Funktionskomponenten misst (BFCs [24]) (ILF, EIF, NEIN, ES IST DAS, EQ) und es gibt mittlerweile nur noch sehr wenige Unterschiede zwischen den Zählrichtlinien der beiden Methoden. Viele Experten verwenden die in IFPUG-Funktionspunkten gemessene Größe als gleich der Größe in Nesma FP. Der Hauptvorteil von Nesma gegenüber IFPUG für Schätzzwecke ist die Verfügbarkeit einer Reihe abgeleiteter Methoden, die als Teil des ISO/IEC-Standards gelten:

• Indikative FPA – Diese Methode kann sehr früh im Projektlebenszyklus verwendet werden, wenn nur das Datenmodell spezifiziert wird. Die Genauigkeit ist nicht sehr hoch (-30% / +50%), aber normalerweise ausreichend, um in einer frühen Phase des Projektlebenszyklus nützlich zu sein, wenn nur eine ROM-Schätzung erforderlich ist.
• FPA auf hohem Niveau (a.k.a.. geschätzte FPA) – Diese Methode gilt heutzutage als die Hauptmethode, da den meisten funktionalen Dokumentationen die Details fehlen, um das Standard-Nesma verwenden zu können (oder IFPUG) FPA. Die High-Level-FPA verwendet eine feste Komplexitätsbewertung pro Basisfunktionskomponente: geringe Komplexität für logische Dateien und durchschnittliche Komplexität für Funktionen. Diese Methode kann verwendet werden, wenn das Datenmodell und die Funktionen bekannt sind, aber die Details darüber, welche Attribute in welchen Funktionen verwendet werden, fehlen oder sind unvollständig (was oft der Fall ist). Die Genauigkeit dieser Methode liegt bei ca -8% zu +15% (sehen dieses Papier).

Und dazu, Nesma unterscheidet zwischen Projektgröße (die Anzahl der Funktionspunkte, die einem bestehenden System hinzugefügt werden, zuzüglich der Anzahl der im System geänderten Funktionspunkte, plus die Anzahl der gelöschten Funktionspunkte, plus Funktionspunkte der Software, die zur Realisierung des Projekts erforderlich sind, zum Beispiel Konvertierungssoftware) und Produktgröße (die funktionale Größe der Anwendung, die den Benutzern bereitgestellt wird).

Nesma ist eine sehr aktive Gemeinschaft von Freiwilligen, die ständig an neuen Möglichkeiten arbeitet, die Methode auf neue Arten oder spezielle Arten von Softwareprojekten anzuwenden. Obwohl diese nicht offiziell Teil des ISO/IEC-Standards sind, Diese Methoden können für Softwareschätzungszwecke sehr nützlich sein. Weit verbreitete Richtlinien sind zum Beispiel:

• FPA zur Softwareverbesserung
  In einigen Ländern ist die Verwendung dieser Methode für Auftragnehmer sogar verpflichtend, um bei Regierungsprojekten bieten zu können.
• FPA in SOA-Umgebungen (nur auf niederländisch)
• FPA in Data Warehouse-Projekten
• FPA in den frühen Phasen des Projektlebenszyklus
• FPA gilt für Usecase / UML-Dokumentation

Das Grundlage der Schätzung (BoE) für Softwaredienste, wie sie von Nesma und dem veröffentlicht werden AACE International, die Kompetenz für das Gesamtkostenmanagement, ist eine sehr nützliche Möglichkeit, eine Grundlage für die Kostenschätzung eines Softwareprojekts zu erstellen, Gleichzeitig wird nachgewiesen, dass der Schätzer alle wichtigen Aspekte bei seiner Schätzung berücksichtigt hat. Die Nesma (IFPUG) Die Methode wird von den meisten kommerziellen und nichtkommerziellen parametrischen Software-Schätzmodellen und -Tools unterstützt.

Die Merkmale zur Bewertung der Nützlichkeit dieser Methode für die Schätzung von Softwareprojekten sind in der nächsten Tabelle aufgeführt:

Charakteristisch	J/N	Bemerkungen
Zielsetzung, wiederholbar, überprüfbar und vertretbar	Ja	ISO / IEC 24570:2004
Historische Daten verfügbar	Ja	ISBSG R13: 187 Projekte (5433 in Kombination mit IFPUG)
Unterstützt von Modellen/Tools	Ja	QSM, SEER-SEM, Wahre Planung, COCOMO II, ISBSG

 

IFPUG

Die IFPUG-Methode ist die am weitesten verbreitete Methode zur funktionellen Größenmessung. Von allen Anforderungen, Es misst nur die funktionalen Benutzeranforderungen und tut dies auf die Art und Weise, wie interne logische Dateien (ILF), externe Schnittstellendateien (EIF), externe Eingabefunktionen (NEIN), externe Ausgabefunktionen (ES IST DAS) und externe Anfrage (EQ) Funktionen werden identifiziert und nach Komplexität klassifiziert. Die Komplexität der Software wird wie folgt klassifiziert: Niedrig, Mittel oder Hoch, abhängig von Elementen wie der Anzahl der beteiligten Datenattribute, die Anzahl der referenzierten Dateien oder die Anzahl der Datensatztypen, die Teil der logischen Datei sind. Für eine interne logische Datei (ILF) zum Beispiel, Die Anzahl der Funktionspunkte, die mit einem ILF geringer Komplexität verbunden sind, beträgt 7 Funktionspunkte (FP), ein ILF mittlerer Komplexität bekommt 10 FP und ein ILF hoher Komplexität erhält 15 FP. Es gibt eine Mindestpunktzahl pro Funktion und eine Höchstpunktzahl pro Funktion. Allerdings vereinfacht dies den Analyseprozess etwas, Es wird als Nachteil empfunden, dass die Größe verschiedener logischer Dateien und Funktionen möglicherweise nicht ausreichend abgestuft ist. Zum Beispiel, Die Größe einer komplexen externen Eingabefunktion beträgt 6 FP, aber er ist von der Größe her ein sehr komplexes EI 6 Punkte sowie die Größe eines äußerst komplexen EI 6 FP.

Die IFPUG-Methode eignet sich am besten als Dimensionierungsmethode zur Schätzung von Projekten, die die folgenden Merkmale erfüllen (nicht limitiert):

• Die Software ist datenorientiert, viele CRUD (Erstellen, Lesen, Aktualisieren, Löschen) Funktionen angegeben sind
• Die Software ist administrativ ausgerichtet
• Es liegt ein detaillierter Funktionsentwurf vor, bei dem das Datenmodell vollständig und übersichtlich ist und für alle Funktionen klar ist, welche Datenattribute verwendet werden

Wenn die Größe der funktionalen Anforderungen gemessen wird, Es gibt zahlreiche Möglichkeiten, es in eine Schätzung umzuwandeln. Die Verwendung historischer Daten der Organisation, die die Software implementieren wird, ist normalerweise der beste Weg, vorzugsweise unterstützt durch professionelle Schätzungstools. Wenn keine historischen Daten verfügbar sind, Die offene Datenbank der International Software Benchmarking Standards Group kann sich als sehr hilfreich erweisen. Es enthält über 6700 Projekte (Veröffentlichung 13) und viele davon wurden in IFPUG gemessen. Die IFPUG-Methode wird von den meisten kommerziellen und nichtkommerziellen parametrischen Software-Schätzmodellen und -Tools unterstützt.

Die Merkmale zur Bewertung der Nützlichkeit dieser Methode für die Schätzung von Softwareprojekten sind in der nächsten Tabelle aufgeführt:

Charakteristisch	J/N	Bemerkungen
Zielsetzung, wiederholbar, überprüfbar und vertretbar	Ja	ISO / IEC 20926:2009
Historische Daten verfügbar	Ja	ISBSG R13: 5244 Projekte
Unterstützt von Modellen/Tools	Ja	QSM, SEER-SEM, Wahre Planung, COCOMO II, ISBSG

 

COSMIC

Das Common Software Measurement International Consortium (COSMIC) ist eine freiwillige, weltweiter Zusammenschluss von Software-Metrik-Experten. Gestartet in 1998, COSMIC hat eine Methode zur Messung der funktionalen Größe von Software entwickelt, die darauf ausgelegt ist, einige der wahrgenommenen Mängel von Nesma und IFPUG FPA zu überwinden. Während Nesma und IFPUG hauptsächlich zur Messung der Größe von Verwaltungssoftware verwendet werden, COSMIC eignet sich auch zur Messung der Größe von Echtzeit- und Infrastruktursoftware. Die Methode ist völlig „offen“; Die gesamte Methodendokumentation steht im öffentlichen Bereich zum kostenlosen Download zur Verfügung.

Einer der Hauptvorteile der COSMIC-Methode besteht darin, dass sie dem Messspezialisten die Aufteilung der Software in Softwareschichten und Peer-Komponenten ermöglicht, Dies ermöglicht die Messung der funktionalen Größe der Software, die sich in separaten Architekturschichten oder in verschiedenen Komponenten befindet, die miteinander kommunizieren. Dadurch wird einer der wahrgenommenen Nachteile der Nesma- und IFPUG-Methoden überwunden, die eine solche Aufteilung der Software nicht zulassen.

Ein weiterer wichtiger Vorteil ist die Tatsache, dass die Methode einer Verhältnisskala folgt. Daher kann die funktionale Größe pro funktionalem Prozess eine beliebige Größe dazwischen betragen 2 KOSMISCHE Funktionspunkte (der Mindestwert pro Funktionsprozess) und (theoretisch) Unendlichkeit.

Normalerweise ist die COSMIC-Methode sehr gut für den Einsatz in Projekten anwendbar, die mit einer agilen Methodik entwickelt wurden. Die Art der Dokumentation, die diese Art von Projekten häufig liefert (z.B.. benutzergeschichten, Anwendungsfälle, Aktivitätsdiagramme, Sequenzdiagramme, Klassendiagramme) sind mit COSMIC in der Regel einfach und sehr genau zu messen.

Obwohl die Nutzung von COSMIC zunimmt und auch die Zahl der zertifizierten Praktiker zunimmt, Es sind immer noch nicht viele offene Benchmarking-Daten verfügbar. Die ISBSG-Repository-Version für neue Entwicklungen und Erweiterungen 13 (im Februar veröffentlicht 2014) enthält ca 500 Projekte gemessen in COSMIC, während die Anzahl der Projekte, gemessen in IFPUG-Funktionspunkten, deutlich darüber liegt 5000 Projekte.

Die COSMIC-Methode ist in der Regel besonders gut anwendbar, wenn die funktionale Größe zur Schätzung der folgenden Projekttypen verwendet wird:

• Echtzeit-Softwareprojekte;
• Softwareprojekte für mobile Apps;
• Infrastruktur-Softwareprojekte;
• Softwareprojekte, die Software in einer mehrschichtigen Architektur bereitstellen;
• Verwaltungssoftwareprojekte.

Die funktionale Dokumentation sollte zumindest die funktionalen Prozesse, die durch die Software implementiert werden, und die Datenbewegungen zwischen den Benutzern und der Software aufzeigen.

Die Merkmale zur Bewertung der Nützlichkeit dieser Methode für die Schätzung von Softwareprojekten sind in der nächsten Tabelle aufgeführt:

Charakteristisch	J/N	Bemerkungen
Zielsetzung, wiederholbar, überprüfbar und vertretbar	Ja	ISO / IEC 19761:2003
Historische Daten verfügbar	Ja	ISBSG R13: 488
Unterstützt von Modellen/Tools	Ja	QSM, SEER-SEM, Wahre Planung, ISBSG

Es gibt zwei weitere ISO/IEC-Standards zur funktionalen Größenmessung, FISMA und Mark II, Da diese Methoden jedoch nur in bestimmten lokalen Gemeinden angewendet werden, Sie werden in diesem Artikel nicht besprochen.

Alle Methoden zur funktionalen Größenmessung eignen sich sehr gut für die Schätzung von Softwareprojekten. Die Softwaregröße ist jedoch nur ein Teil der Schätzung. Die Größe sollte anhand relevanter historischer Produktivitätsdaten in eine Schätzung umgewandelt werden. Wenn die funktionale Größe in Funktionspunkten bekannt ist, Sie sollte mit der wahrscheinlichsten Anzahl an Stunden pro Funktionspunkt multipliziert werden, die voraussichtlich im Projekt benötigt werden. Obwohl es mehrere professionelle parametrische Werkzeuge gibt, und auch Datenbanken mit historischen Daten können problemlos beschafft werden, Viele Unternehmen sind der Meinung, dass die Messung der funktionalen Größe kompliziert und zeitaufwändig ist, und es fällt ihnen schwer, eine genaue Produktivitätsrate für die Projekte zu ermitteln, die sie schätzen müssen. Sie bevorzugen weniger zeitaufwändige oder einfacher anzuwendende Methoden. Unglücklicherweise, Dies bedeutet auch, dass diese Methoden möglicherweise nicht so genau sind.

Nächster Blog

Im nächsten Blog zu diesem Thema, Ich werde meine Meinung zur Nützlichkeit der wichtigsten nichtfunktionalen Größenmessmethoden für die Schätzung von Softwareprojekten äußern.

 

Über den Autor

Harold van Heeringen ist Senior Benchmarking Consultant bei Metri. Abgesehen von seiner Arbeit für Metri, er ist an Nesma beteiligt (Vorstandsmitglied), die International Software Benchmarking Standards Group (ISBSG, aktueller Präsident) und das Common Software Metrics International Consortium (COSMIC, Internationaler Beirat, die Niederlande vertreten).

Ein Blogbeitrag repräsentiert die persönliche Meinung des Autors
und muss nicht unbedingt mit den offiziellen Nesma-Richtlinien übereinstimmen.