Functionele maatmeetmethoden

Dit is het tweede deel van de blog dat zich richt op een aantal populaire methoden voor het meten van softwaregroottes en hun bruikbaarheid voor het schatten van softwareprojecten.. In dit tweede deel de functionele meetmethoden IFPUG, NESMA en COSMIC zijn gedekt. In toekomstige blogs zal ik niet-functionele meetmethoden en hybride methoden behandelen.

Lezers die geïnteresseerd zijn in dit onderwerp wordt sterk aangeraden om eerst de eerste deel van deze blog, voordat u dit tweede deel leest.

Voor een bepaalde meetmethode voor softwaregrootte die nuttig is voor het schatten van softwareprojecten, de volgende kenmerken moeten van toepassing zijn:

• De maatmeetmethode kan worden uitgevoerd in een objectief (onafhankelijk van de persoon die het doet), herhaalbare, verifieerbaar en dus verdedigbaar manier;
• Grootte op zich is alleen nuttig wanneer historische gegevens beschikbaar is van projecten gemeten in die maatmeetmethode;
• De methoden voor het meten van de maat moeten worden ondersteund door parametrische modellen en/of tools om nauwkeurig rekening te houden met projectspecifieke kenmerken die van invloed zijn op de schatting, zoals bijvoorbeeld COCOMO II, SLANK, SEER voor software of Ware planning.

Natuurlijk, elke meetmethode voor softwaregrootte die niet aan een of meer van deze criteria voldoet, kan nog steeds erg nuttig zijn voor een organisatie, op voorwaarde dat ze een procedure opstellen om herhaalbare maatmetingen te garanderen, historische gegevens verzamelen en analyseren en/of eigen schattingsmodellen bouwen op basis van de verzamelde gegevens. Wel voor deze blog, de focus ligt op de theoretische bruikbaarheid van de specifieke meetmethode voor schattingsdoeleinden van softwareprojecten in de context van organisaties die nog geen parametrisch schattingsproces hebben. Voor deze organisaties, die bereid zijn een maatmeetmethode te implementeren om softwareprojecten te schatten, deze blog kan dienen als leidraad om een ​​bepaalde methode te kiezen.

Ik moedig iedereen aan om opmerkingen en/of feedback op deze blog in te dienen.

Nesma FPA

Nesma FPA lijkt erg op IFPUG omdat het dezelfde functionele basiscomponenten meet (BFC's [24]) (ILF, EIF, NIET, EO, EQ) en er zijn nu zeer weinig verschillen tussen de telrichtlijnen van de twee methoden. Veel experts gebruiken de grootte gemeten in IFPUG-functiepunten als gelijk aan de grootte in Nesma FP. De belangrijkste voordelen van Nesma ten opzichte van IFPUG voor schattingsdoeleinden is de beschikbaarheid van een aantal afgeleide methoden die worden beschouwd als onderdeel van de ISO/IEC-standaard:

• Indicatieve FPA – Deze methode kan zeer vroeg in de projectlevenscyclus worden gebruikt wanneer alleen het datamodel is gespecificeerd. De nauwkeurigheid is niet erg hoog (-30% / +50%), maar meestal voldoende om bruikbaar te zijn in een vroeg stadium van de projectlevenscyclus wanneer alleen een ROM-schatting nodig is.
• FPA op hoog niveau (aka. geschatte FPA) – Deze methode wordt tegenwoordig als de belangrijkste methode beschouwd, aangezien de meeste functionele documentatie de details mist om de standaard Nesma te kunnen gebruiken (of IFPUG) FPA. De FPA op hoog niveau gebruikt een vaste complexiteitsbeoordeling per functionele basiscomponent: lage complexiteit voor logische bestanden en gemiddelde complexiteit voor functies. Deze methode kan worden gebruikt wanneer het datamodel en de functies bekend zijn, maar de details van welke attributen worden gebruikt in welke functies ontbreken of onvolledig zijn (wat vaak het geval is). De nauwkeurigheid van deze methode is rond -8% naar +15% (Er waren een paar dingen in je blog en de reactie waar ik op wil reageren dit papier).

In aanvulling op, Nesma maakt onderscheid tussen projectgrootte (het aantal functiepunten toegevoegd aan een bestaand systeem, plus het aantal gewijzigde functiepunten in het systeem, plus het aantal verwijderde functiepunten, plus functiepunten van software die nodig zijn om te realiseren om het project te voltooien, bijvoorbeeld conversiesoftware) en product grootte (de functionele omvang van de applicatie die aan de gebruikers wordt geleverd).

Nesma is een zeer actieve gemeenschap van vrijwilligers die voortdurend werken aan nieuwe manieren om de methode te gebruiken bij nieuwe soorten of speciale soorten softwareprojecten. Hoewel deze officieel geen deel uitmaken van de ISO/IEC-standaard, deze methoden kunnen erg handig zijn voor softwareschattingsdoeleinden. Veelgebruikte richtlijnen zijn bijv:

• FPA voor softwareverbetering
  het gebruik van deze methode is in sommige landen zelfs verplicht voor aannemers om te kunnen bieden op overheidsprojecten.
• FPA in SOA-omgevingen (alleen in het Nederlands)
• FPA in datawarehouse-projecten
• FPA in de vroege fasen van de projectlevenscyclus
• FPA toegepast op Usecase / UML-documentatie

De Basis van Estimate (BoE) voor softwarediensten zoals gepubliceerd door Nesma en de AACE International, de autoriteit voor totale kostenbeheersing, is een erg handige manier om een ​​schatting van een softwareproject te baseren, terwijl hij ook aantoont dat de schatter rekening heeft gehouden met alle aspecten die bij zijn schatting van belang zijn. De Nesma (IFPUG) methode wordt ondersteund door de meeste commerciële en niet-commerciële parametrische software schattingsmodellen en tools.

De kenmerken om het nut van deze methode voor de schatting van softwareprojecten te beoordelen, staan ​​vermeld in de volgende tabel:

kenmerk	J/N	Opmerkingen
Doelstelling, herhaalbare, verifieerbaar en verdedigbaar	Ja	ISO / IEC 24570:2004
Historische gegevens beschikbaar	Ja	ISBSG R13: 187 projecten (5433 in combinatie met IFPUG)
Ondersteund door modellen/tools	Ja	QSM, SEER-SEM, Ware planning, COCOMO II, ISBSG

 

IFPUG

De IFPUG-methode is de meest gebruikte methode voor functionele maatmeting. Van alle eisen, Het meet alleen de functionele gebruikerseisen en doet dat op de manier waarop interne logische bestanden dat doen (ILF), externe interfacebestanden (EIF), externe invoerfuncties (NIET), externe uitgangsfuncties (EO) en extern onderzoek (EQ) functies worden geïdentificeerd en geclassificeerd in complexiteit. De complexiteit van de software wordt op de volgende manier ingedeeld: Laag, Gemiddeld of hoog, afhankelijk van items zoals het aantal betrokken gegevensattributen, het aantal bestanden waarnaar wordt verwezen of het aantal recordtypen dat deel uitmaakt van het logische bestand. Voor een intern logisch bestand (ILF) bijvoorbeeld, het aantal functiepunten dat is verbonden met een ILF met lage complexiteit 7 functiepunten (FP), een ILF van gemiddelde complexiteit krijgt 10 FP en een ILF van hoge complexiteit krijgen 15 FP. Er is een minimum aantal punten per functie en een maximum aantal punten per functie. Hoewel dit het analyseproces enigszins vereenvoudigt, het wordt als een nadeel ervaren dat er mogelijk niet genoeg nuance is tussen de grootte van verschillende logische bestanden en functies. Bijvoorbeeld, de grootte van een complexe External Input-functie is 6 FP, maar de grootte van een zeer complexe EI is 6 punten en de grootte van een extreem complexe EI ook 6 FP.

De IFPUG-methode is het nuttigst als dimensioneringsmethode om projecten te schatten die voldoen aan de volgende kenmerken (niet gelimiteerd):

• De software is data-georiënteerd, veel CRUD (creëren, Lezen, Update, Delete) functies zijn gespecificeerd
• De software is administratief georiënteerd
• Er is een gedetailleerd functioneel ontwerp beschikbaar waarin het datamodel compleet en overzichtelijk is en voor alle functies duidelijk is welke data attributen worden gebruikt

Wanneer de omvang van de functionele eisen wordt gemeten, er zijn tal van manieren om het om te zetten in een schatting. Het gebruiken van historische data van de organisatie die de software gaat realiseren is meestal de beste manier, bij voorkeur ondersteund door professionele schattingstools. Als er geen historische gegevens beschikbaar zijn, de open database van de International Software Benchmarking Standards Group kan hierbij erg behulpzaam zijn. Het bevat meer dan 6700 projecten (Vrijlating 13) en veel hiervan werden gemeten in IFPUG. De IFPUG-methode wordt ondersteund door de meeste commerciële en niet-commerciële parametrische softwareschattingsmodellen en -tools.

De kenmerken om het nut van deze methode voor de schatting van softwareprojecten te beoordelen, staan ​​vermeld in de volgende tabel:

kenmerk	J/N	Opmerkingen
Doelstelling, herhaalbare, verifieerbaar en verdedigbaar	Ja	ISO / IEC 20926:2009
Historische gegevens beschikbaar	Ja	ISBSG R13: 5244 projecten
Ondersteund door modellen/tools	Ja	QSM, SEER-SEM, Ware planning, COCOMO II, ISBSG

 

COSMIC

Het Common Software Measurement International Consortium (COSMIC) is een vrijwillige, wereldwijde groep van experts op het gebied van softwaremetrie. Startte in 1998, COSMIC heeft een methode ontwikkeld om de functionele omvang van software te meten die is ontworpen om enkele van de waargenomen gebreken van Nesma en IFPUG FPA te verhelpen. Terwijl Nesma en IFPUG vooral worden gebruikt om de grootte van administratieve software te meten, COSMIC is ook toepasbaar om de omvang van real-time en infrastructuursoftware te meten. De werkwijze is geheel ‘open’; alle methodedocumentatie is gratis te downloaden in het publieke domein.

Een van de belangrijkste voordelen van de COSMIC-methode is dat de meetspecialist de software kan opdelen in softwarelagen en peer-componenten, wat de mogelijkheid biedt om de functionele omvang te meten van de software die zich in afzonderlijke architectuurlagen bevindt of in verschillende componenten die met elkaar communiceren. Dit overwint een van de waargenomen nadelen van de Nesma- en IFPUG-methoden, waardoor de software niet op een dergelijke manier kan worden verdeeld.

Een ander belangrijk voordeel is het feit dat de methode een verhoudingsschaal volgt. Daarom kan de functionele omvang per functioneel proces elke grootte zijn 2 COSMIC-functiepunten (de minimale waarde per functioneel proces) en (theoretisch) oneindigheid.

Doorgaans is de COSMIC methode zeer goed toepasbaar in projecten ontwikkeld met een agile methodiek. Het soort documentatie dat dit soort projecten vaak opleveren (bv. verhalen van gebruikers, gebruiksgevallen, activiteiten diagrammen, volgorde diagrammen, klasse diagrammen) zijn meestal eenvoudig te meten met COSMIC op een zeer nauwkeurige manier.

Hoewel het gebruik van COSMIC toeneemt en ook het aantal gecertificeerde beoefenaars toeneemt, er zijn nog steeds niet veel open benchmarkgegevens beschikbaar. De repository-release van ISBSG New Developments and Enhancements 13 (februari uitgebracht 2014) bevat ongeveer 500 projecten gemeten in COSMIC, terwijl het aantal projecten gemeten in IFPUG-functiepunten er ruim boven ligt 5000 projecten.

De COSMIC-methode is meestal bijzonder goed toepasbaar bij het gebruik van de functionele omvang om de volgende soorten projecten te schatten:

• Realtime softwareprojecten;
• Softwareprojecten voor mobiele apps;
• Infrastructuursoftwareprojecten;
• Softwareprojecten die software opleveren in een gelaagde architectuur;
• Administratieve software projecten.

De functionele documentatie dient in ieder geval de functionele processen weer te geven die door de software worden geïmplementeerd en de dataverplaatsingen tussen de gebruikers en de software.

De kenmerken om het nut van deze methode voor de schatting van softwareprojecten te beoordelen, staan ​​vermeld in de volgende tabel:

kenmerk	J/N	Opmerkingen
Doelstelling, herhaalbare, verifieerbaar en verdedigbaar	Ja	ISO / IEC 19761:2003
Historische gegevens beschikbaar	Ja	ISBSG R13: 488
Ondersteund door modellen/tools	Ja	QSM, SEER-SEM, Ware planning, ISBSG

Er zijn nog twee ISO/IEC-normen voor functionele maatmeting, FiSMA en Mark II, maar omdat deze methoden alleen in specifieke lokale gemeenschappen worden gebruikt, ze worden in dit document niet besproken.

Alle methoden voor het meten van functionele afmetingen zijn zeer geschikt voor het schatten van softwareprojecten. De grootte van de software is echter slechts een deel van de schatting. De grootte moet worden geconverteerd naar een schatting met behulp van relevante historische productiviteitsgegevens. Wanneer de functionele omvang in functiepunten bekend is, het moet worden vermenigvuldigd met het meest waarschijnlijke aantal uren per functiepunt dat waarschijnlijk nodig zal zijn in het project. Hoewel er verschillende professionele parametrische tools beschikbaar zijn, en ook databases met historische gegevens kunnen gemakkelijk worden verkregen, veel organisaties vinden het ingewikkeld en tijdrovend om functionele maatmeting te gebruiken en vinden het moeilijk om een ​​nauwkeurig productiviteitspercentage te bepalen voor de projecten die ze moeten inschatten. Ze geven de voorkeur aan minder tijdrovende methoden of methoden die gemakkelijker toe te passen zijn. helaas, dit betekent ook dat deze methoden mogelijk niet zo nauwkeurig zijn.

Volgende blog

In de volgende blog over dit onderwerp, Ik zal mijn mening geven over het nut van de belangrijkste niet-functionele meetmethoden voor het schatten van softwareprojecten.

 

Over de auteur

Harold van Heeringen is a senior benchmarking consultant at Metri. Behalve voor zijn werk voor Metri, 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.