Die Größe der Software ist der Haupttreiber für die Schätzung der Projektkosten

Bei weitem die meisten Kostenschätzungsmodelle für die Softwareentwicklung, Erweiterungs- oder Wartungsprojekte verwenden die Softwaregröße als Haupteingabeparameter. Die Softwaregröße wird allgemein als wichtiger Kostenfaktor für den Aufwand und die Kosten von Softwareprojekten anerkannt. Im Gegensatz zu vielen physischen Objekten jedoch, Es gibt keine universellen Messstandards zur Messung der Softwaregröße. Während ein Maler, der die Kosten für das Streichen einer Wand schätzen muss, normalerweise die Größe dieser Wand in Quadratfuß oder Quadratmetern als Eingabe für seine Schätzung messen würde, Die Messung der Softwaregröße ist schwierig, da sie keine echte physische Form hat. jedoch, In der Branche gibt es eine Reihe von Methoden, mit denen die Softwaregröße gemessen werden kann. Allerdings für Kostenschätzer, die keine Experten für Software-Dimensionierung sind, Es kann schwierig sein, die Vor- und Nachteile der verfügbaren Methoden zu verstehen, und daher fällt es ihnen möglicherweise schwer, die beste Methode für ihren Zweck auszuwählen. In diesem Blog, Es wird ein Überblick über die am weitesten verbreiteten Methoden zur Softwaredimensionierung gegeben, die der Industrie zur Verfügung stehen. Auch die Vor- und Nachteile dieser Methoden sowie Empfehlungen, welche Methoden für welche Arten von Softwareprojektschätzungen anzuwenden sind, werden gegeben. In der folgenden Tabelle werden die in diesem Blog behandelten Methoden zur Messung der Softwaregröße angezeigt.

Software-Größenmessung	Messbereich	Größe
SLOCK	Physisches Softwareobjekt	Technische Größe in SLOCs
IFPUG	Funktionale Benutzeranforderungen	Funktionale Größe in FP
Nesma	Funktionale Benutzeranforderungen	Funktionale Größe in FP
COSMIC	Funktionale Benutzeranforderungen	Funktionale Größe in CFP
SNAP	Teil der nicht funktionalen Benutzeranforderungen	Nicht funktionale Größe in SNAP-Punkten
Anwendungsfallpunkte	Anwendungsfälle, technische Projekteigenschaften, Eigenschaften von Umweltprojekten	„Aufwand/Größen-Kombination“ in Usecase-Punkten
Schneller Function Points	Funktionale Benutzeranforderungen und Konfigurationsgröße	Gartner FFP
Story Points	Backlog-Elemente, funktional und nicht funktional	'Aufwand/Komplexität-Kombination' in Story Points

Kostenschätzung für Softwareprojekte

Bei der Kostenschätzung von Softwareprojekten, Der Fokus liegt in der Regel auf der Schätzung der Arbeitsstunden der Personen im Team. Der Grund dafür ist, dass die Aufwandsstunden in der Regel die Gesamtkosten des Projekts treiben. Natürlich fallen noch weitere Kosten an, z.B.. Lizenzen, Arbeitsplätze, Infrastruktur, usw, Diese Kosten sind jedoch nicht von der Softwaregröße getrieben und können auch einfacher berechnet werden.

A (vereinfacht) Schätzmodell ist in der folgenden Abbildung dargestellt.

Der Umfang der zu entwickelnden Software ist der Haupteingangsparameter für die Projektschätzung. Entscheidend für die Genauigkeit der Schätzung ist, dass die Größe genau gemessen wird. Die Auswahl einer realistischen Produktivitätsrate ist ebenfalls ein sehr wichtiger Schritt. Dies sollte auf Basis historischer Daten oder mit Hilfe professioneller parametrischer Tools erfolgen, die auf relevanten Branchendaten basieren. Die Verwendung von Unternehmensdaten wird in der Regel bevorzugt, da dies die tatsächlichen Fähigkeiten der Organisation zeigt, die sein können (viel) besser bzw (viel) schlechter als der Branchendurchschnitt. Projektspezifische Merkmale können ebenfalls wichtig sein, z.B.. Termindruck, Teamgröße, Qualitätsbeschränkungen, usw. Deshalb, Parametrische Werkzeuge sind in diesem Schritt einer Projektschätzung normalerweise sehr nützlich.

Multiplikation der Größe mit der Produktivität, die Bruttoaufwandsstunden werden berechnet. Normalerweise sind einige Anpassungen auf der Grundlage einer Risikoanalyse erforderlich. Wenn es sein muss 99% sicher, dass es zum Beispiel nicht zu einer Kostenüberschreitung kommt, Die Aufwandsstunden werden wahrscheinlich angepasst, um eine Eventualität zu schaffen.

Klassifizierung von Methoden zur Messung der Softwaregröße

Es gibt einen wichtigen Unterschied zwischen Methoden zur Messung der funktionellen Größe und anderen (nichtfunktionale Größenmessverfahren oder Hybridverfahren). Methoden zur Messung der funktionalen Größe messen die Funktionalität („Was macht die Software“) die die Software ihren Benutzern bietet und quantifiziert dies in irgendeiner Weise. Je mehr Funktionen der Benutzer nutzen kann, Dies erhöht die Größe der Software. Einer der Hauptvorteile dieser Art von Verfahren besteht darin, dass die Größe unabhängig von der verwendeten Technologie ist (z.B.. Java, .Netz, Orakel) und angewandte Implementierungsmethode (Kinderbetten, Wasserfall Entwicklung, agile Entwicklung, etc.).

Nichtfunktionale Methoden zur Größenmessung messen die technischen Artefakte der Software, normalerweise der Softwarecode, der konstruiert wird. Es stehen auch hybride Methoden zur Verfügung, die funktionelle Aspekte messen, technische Aspekte und manchmal auch Umweltaspekte des Softwareprojekts, um auf eine Größe zu kommen, z.B.. Anwendungsfallpunkte. jedoch, Die meisten Methoden messen entweder die funktionale Größe oder die technische Größe von Software.

Methoden zur Messung der Funktionsgröße – Vor- und Nachteile

Allgemein, Die Hauptvorteile aller ISO/IEC-Normen für die funktionelle Größenmessung sind:

• Die Größenmessung erfolgt auf objektive Weise. Zwei zertifizierte Messer sollten bei der Messung der gleichen funktionalen Benutzeranforderungen auf die gleiche Größe kommen;
• Die Größenmessung ist wiederholbar und überprüfbar. Wenn vom Messspezialisten Annahmen getroffen wurden, diese sollten im Rahmen der Größenmessung dokumentiert werden;
• Die Größenmessung ist vertretbar. Dies ist sehr wichtig, da die funktionale Größe häufig in Einzelpreisverträgen zwischen Lieferanten und Kunden verwendet wird. Preis-pro-Funktionspunkt-Verträge sind nur möglich, wenn die Funktionsgröße unstreitig bestimmt werden kann;
• Einige der Methoden bieten abgeleitete Methoden, die es Kostenschätzern ermöglichen, die Funktionsgröße recht früh im Projektlebenszyklus ziemlich genau zu messen. Zum Beispiel die Nesma Richtmethode kann nach der Phase der Anforderungsanalyse verwendet werden und bietet eine schnelle Möglichkeit, einen Hinweis auf die funktionale Größe zu erhalten (+50% / -30% Genauigkeit).
• Die funktionale Größe kann als „Wert“ für Benutzer und Kunden des Softwaresystems erkannt werden. Mehr Funktionalität bedeutet mehr Wert und damit höhere Kosten. Dies zum Beispiel im Vergleich zur technischen Größe wie Quellcodezeilen (slocs) wo unklar ist, ob mehr Slocs mehr Wert für den Benutzer und/oder das Unternehmen bedeuten.
• Wegen der Standardisierung, Der wichtigste Vorteil besteht darin, dass es möglich wird, die Daten abgeschlossener Projekte zu speichern, um sie in Kostenvoranschlägen für neue Projekte zu verwenden. Genauso wie der Maler, der Daten über seine Produktivität in Stunden pro Quadratfuß für bestimmte Wandtypen hat, Unternehmen erhalten einen Einblick in ihre Produktivität in Stunden pro Funktionspunkt. Dies ermöglicht ein Benchmarking, beispielsweise gegen die offene Branchendatenbank der International Software Benchmarking Standards Group (ISBSG).

Einige der Nachteile der Verwendung von Methoden zur Messung der funktionalen Größe für die Größenbestimmung und Schätzung von Software sind::

• Die Messung der funktionellen Größe erfordert Personen mit dem Fachwissen, um diese Aktivität auszuführen. Da es eine so wichtige Aktivität ist, Es wird wirklich empfohlen, die Größenbestimmung nur von zertifizierten Vermessern durchführen zu lassen und selbst dann einen ordnungsgemäßen Überprüfungsprozess einzurichten. Es gibt einige Initiativen, um die Funktionsgröße von Software automatisch zu messen, aber bisher sind diese nicht sehr genau;
• Die Messung der Funktionsgröße nimmt einige Zeit in Anspruch und kostet Aufwand. Normalerweise ist dies weniger als 1% des Projektbudgets und bei weitem die meisten Projekte können darin gemessen werden 1 Woche Dauer. Normalerweise überwiegen die Vorteile einer funktionalen Größenmessung die Kosten um ein Vielfaches, da es den Beteiligten ermöglicht, realistischere Pläne zu erstellen und Überschreitungen und mögliche Demütigungen zu vermeiden;
• Messmethoden für die funktionale Größe messen die funktionalen Benutzeranforderungen, die in der funktionalen Dokumentation angegeben sind. Es gibt einige Anforderungen an diese Dokumentation, damit die Vermesser sie messen können. jedoch, wenn diese Voraussetzungen nicht erfüllt sind, Das Projekt ist wahrscheinlich ohnehin zum Scheitern verurteilt, da die Programmierer nicht in der Lage sein werden zu codieren und die Tester nicht mit diesen Dokumenten testen können. Eine funktionale Größenmessung ist in der Tat ein aussagekräftiger statischer Test der Anforderungen, in vielen Fällen werden schwerwiegende Mängel und Auslassungen festgestellt, eine frühzeitige Anpassung der Spezifikationen zu ermöglichen und somit die Kosten für eine spätere Erkennung und Behebung der Mängel zu vermeiden.

Die funktionale Größe von Softwareprojekten kann in den am weitesten verbreiteten parametrischen Schätzungswerkzeugen und -modellen verwendet werden, z.B.. QSM SLIM, Galorath SEHER, Preissysteme Trueplanning und COCOMO II.

Nächster Blog

Im nächsten Blog zu diesem Thema, Ich werde meine Meinung zu den Vor- und Nachteilen bei der Kostenschätzung von Softwareprojekten der in der Tabelle aufgeführten Methoden abgeben.

 

 

Über den Autor

Harold van Heeringen ist Senior-Berater für Softwaremetriken / Senior Software Cost Engineer für Sogeti Nederland B.V. Abgesehen von seiner Arbeit für die Abteilung Sizing, Abschätzen & Kontrolle über Sogeti, 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.