Softwaregrootte is de belangrijkste drijfveer voor de schatting van projectkosten

Verreweg de meeste kostenramingsmodellen voor softwareontwikkeling, Verbeterings- of onderhoudsprojecten gebruiken de softwaregrootte als de belangrijkste invoerparameter. Softwaregrootte wordt algemeen erkend als een belangrijke kostenfactor voor de inspanning en kosten die nodig zijn voor softwareprojecten. In tegenstelling tot veel fysieke objecten, er zijn geen universele meetstandaarden om de softwaregrootte te meten. Terwijl een schilder die de kosten van het schilderen van een muur moet schatten, de grootte van deze muur meestal in vierkante voet of vierkante meter meet als input voor zijn schatting, het meten van de softwaregrootte is moeilijk vanwege het feit dat het geen echte fysieke vorm heeft. Echter, er zijn een aantal methoden beschikbaar in de branche die kunnen worden gebruikt om de softwaregrootte te meten. Voor kostenramers die echter geen experts zijn op het gebied van software-dimensionering, het kan moeilijk zijn om de voor- en nadelen van de beschikbare methoden te begrijpen en daarom vinden ze het misschien moeilijk om de beste methode voor hun doel te kiezen. In deze blog, er wordt een overzicht gegeven van de meest gebruikte methodes voor software-dimensionering die beschikbaar zijn voor de industrie. Ook de voor- en nadelen van deze methoden, evenals aanbevelingen van welke methoden te gebruiken voor welke soorten softwareprojecten schattingen worden gegeven. In de volgende tabel worden de meetmethoden voor softwaregrootte weergegeven die in deze blog worden behandeld.

Maatregel software	Metingsbereik	Grootte
SLOC	Fysiek software-object	Technische omvang in SLOC's
IFPUG	Functionele gebruikersvereisten	Functionele grootte in FP
Nesma	Functionele gebruikersvereisten	Functionele grootte in FP
COSMIC	Functionele gebruikersvereisten	Functionele maat in CFP
SNAP	Onderdeel van de niet-functionele gebruikersvereisten	Niet-functionele grootte in SNAP-punten
Use Case Points	Usecases, technische projectkenmerken, kenmerken van milieuprojecten	‘Combinatie inspanning / grootte’ in Usecase-punten
Snelle functiepunten	Functionele gebruikersvereisten en configuratiegrootte	Gartner FFP
Story Points	Backlog-items, functioneel en niet-functioneel	'Inspanning / Complexiteit combinatie' in Verhaalpunten

Software project kostenraming

In softwareproject kostenraming, de focus ligt meestal op het inschatten van de inspanningsuren van de mensen in het team. De reden hiervoor is dat de inspanningsuren meestal de totale kosten van het project bepalen. Uiteraard zijn er nog andere kosten aan verbonden, bv. licenties, werkplekken, infrastructuur, et cetera, maar deze kosten worden niet bepaald door de softwaregrootte en kunnen ook op een eenvoudigere manier worden berekend.

EEN (vereenvoudigd) schattingsmodel wordt weergegeven in de volgende afbeelding.

De omvang van de te ontwikkelen software is de belangrijkste inputparameter voor de projectraming. Het is cruciaal voor de nauwkeurigheid van de schatting dat de maat nauwkeurig wordt gemeten. Het selecteren van een realistische productiviteit is ook een zeer belangrijke stap. Dit moet gebeuren op basis van historische gegevens of met behulp van professionele parametrische tools die zijn gebaseerd op relevante branchegegevens. Het gebruik van bedrijfsgegevens heeft doorgaans de voorkeur, omdat dit de feitelijke capaciteiten van de organisatie laat zien die mogelijk zijn (veel) beter of (veel) slechter dan het branchegemiddelde. Projectspecifieke kenmerken kunnen ook belangrijk zijn om te overwegen, bv. schema druk, team grootte, kwaliteitsbeperkingen, et cetera. daarom, parametrische tools zijn meestal erg handig in deze stap van een projectraming.

Vermenigvuldiging van de grootte met productiviteit, de bruto inspanningsuren worden berekend. Meestal zijn er enkele aanpassingen nodig op basis van een risicoanalyse. Als het nodig is 99% zeker dat de kosten niet worden overschreden, bijvoorbeeld, de inspanningsuren zullen waarschijnlijk worden aangepast om een ​​onvoorziene gebeurtenis te creëren.

Classificatie van meetmethoden voor softwaregrootte

Er is een belangrijk onderscheid tussen meetmethoden voor functionele afmetingen en andere (niet-functionele maatmeetmethoden of hybride methoden). Functionele maatmeetmethoden meten de functionaliteit (‘Wat doet de software’) dat de software zijn gebruikers biedt en dit op een of andere manier kwantificeert. Hoe meer functionaliteit de gebruiker kan gebruiken, dit vergroot de omvang van de software. Een van de belangrijkste voordelen van dit soort methoden is dat de grootte onafhankelijk is van de gebruikte technologie (bv. Java, .Netto, Orakel) en gebruikte implementatiemethode (COTS, waterval ontwikkeling, soepele ontwikkeling, enzovoort.).

Met niet-functionele maatmeetmethoden worden de technische artefacten van de software gemeten, meestal de softwarecode die is opgebouwd. Er zijn ook hybride methoden beschikbaar die functionele aspecten meten, technische aspecten en soms ook milieuaspecten van het softwareproject om tot een omvang te komen, bv. Use Case Points. Echter, De meeste methoden meten de functionele omvang of de technische omvang van software.

Meetmethoden voor functionele afmetingen - voor- en nadelen

Over het algemeen, de belangrijkste voordelen van alle ISO / IEC-normen voor het meten van functionele afmetingen zijn:

• De maatmeting wordt op een objectieve manier uitgevoerd. Twee gecertificeerde meetinstrumenten moeten dezelfde maat hebben bij het meten van dezelfde functionele gebruikersvereisten;
• De maatmeting is herhaalbaar en verifieerbaar. Of er aannames zijn gedaan door de meetspecialist, deze moeten worden gedocumenteerd als onderdeel van de maatmeting;
• De maatmeting is verdedigbaar. Dit is erg belangrijk omdat functionele grootte vaak wordt gebruikt in contracten met eenheidsprijzen tussen leveranciers en klanten. Prijs per functiepuntcontracten zijn alleen mogelijk als de functionele omvang zonder geschil kan worden bepaald;
• Sommige van de methoden bieden afgeleide methoden waarmee kostenschatters vrij nauwkeurig de functionele omvang vrij vroeg in de levenscyclus van het project kunnen meten. Bijvoorbeeld de Nesma indicatieve methode kan worden gebruikt na de fase van de vereistenanalyse en biedt een snelle manier om een ​​indicatie te krijgen van de functionele omvang (+50% / -30% nauwkeurigheid).
• Functionele omvang kan worden herkend als ‘waarde’ voor gebruikers en klanten van het softwaresysteem. Meer functionaliteit betekent meer waarde en dus hogere kosten. Dit bijvoorbeeld in vergelijking met technische omvang zoals broncode regels (slocs) waar het onduidelijk is of meer slocs meer waarde betekenen voor de gebruiker en / of het bedrijf.
• Vanwege de standaardisatie, het belangrijkste voordeel is dat het mogelijk wordt om de gegevens van voltooide projecten op te slaan om te gebruiken in schattingen voor nieuwe projecten. Net als de schilder die gegevens heeft van zijn productiviteit in uren per vierkante voet voor specifieke soorten wanden, organisaties zijn in staat om inzicht te krijgen in hun productiviteit in termen van uren per functiepunt. Dit maakt benchmarking mogelijk, bijvoorbeeld tegen de open branchedatabase van de International Software Benchmarking Standards Group (ISBSG).

Enkele van de nadelen van het gebruik van functionele meetmethoden voor de grootte en schatting van software zijn:

• Functionele maatmeting vereist mensen met de expertise om deze activiteit uit te voeren. Omdat het zo'n belangrijke activiteit is, het is echt aan te raden om alleen gecertificeerde meetinstrumenten de dimensionering te laten doen en zelfs dan een goed beoordelingsproces te hebben. Er zijn enkele initiatieven om automatisch de functionele omvang van software te meten, maar tot nu toe zijn deze niet erg nauwkeurig;
• Functionele maatmeting kost wat tijd en kost moeite. Meestal is dit minder dan 1% van het projectbudget en verreweg de meeste projecten kunnen binnen worden gemeten 1 week van duur. Gewoonlijk wegen de voordelen van het meten van functionele afmetingen vele malen op tegen de kosten, omdat het de belanghebbenden in staat stelt om meer realistische plannen op te stellen en overschrijding en mogelijke vernedering te voorkomen;
• Functionele maatmeetmethoden meten de functionele gebruikersvereisten die zijn gespecificeerd in functionele documentatie. Er zijn enkele vereisten aan deze documentatie om ervoor te zorgen dat de meetinstrumenten deze kunnen meten. Echter, als niet aan deze vereisten wordt voldaan, het project is waarschijnlijk toch gedoemd, aangezien de programmeurs niet kunnen coderen en de testers niet kunnen testen met deze documenten. Een functionele maatmeting is in feite een krachtige statische test op de eisen, in veel gevallen worden ernstige gebreken en weglatingen ontdekt, waardoor een vroege aanpassing van de specificaties mogelijk is en daardoor de kosten van latere detectie en correctie van de defecten worden voorkomen.

De functionele omvang van softwareprojecten kan worden gebruikt in de meest gebruikte parametrische schattingsinstrumenten en -modellen, bv. QSM SLIM, Galorath ZIE, Prijssystemen Trueplanning en COCOMO II.

Volgende blog

In de volgende blog over dit onderwerp, Ik zal mijn mening geven over de voor- en nadelen als het gaat om de kostenraming van softwareprojecten van de methoden die in de tabel worden vermeld.

 

 

Over de auteur

Harold van Heeringen is een senior consultant software metrics / senior software cost engineer voor Sogeti Nederland B.V. Behalve voor zijn werk voor de afdeling Maatvoering, Het schatten & Controle over Sogeti, hij is betrokken bij Nesma (bestuurslid), de International Software Benchmarking Standards Group (ISBSG, huidige president) en het Common Software Metrics International Consortium (COSMIC, Internationale adviesraad, namens Nederland).

Een blogpost vertegenwoordigt de persoonlijke mening van de auteur
en hoeft niet noodzakelijkerwijs samen te vallen met het officiële Nesma-beleid.