Invoering
Dit is het derde 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 derde deel worden de niet-functionele meetmethoden voor de maat behandeld. In de volgende en laatste blog over dit onderwerp toekomstige blogs zal ik de hybride methodes behandelen.
Lezers die geïnteresseerd zijn in dit onderwerp wordt sterk aangeraden om eerst de eerste deel en tweede deel van deze blog voordat u dit derde deel van de blogreeks 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 QSM SLIM, SEER voor software, TruePlanning of COCOMO II.
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.
Hoewel alles wat in deze blog is geschreven, is gebaseerd op persoonlijke ervaring en op openbaar beschikbare documentatie (waarnaar verwezen wordt), Dat wil ik benadrukken deze blog weerspiegelt alleen mijn persoonlijke opvattingen en overtuigingen en daarom beweer ik niet dat alles wat in deze blog geschreven is een absolute waarheid is. Mijn persoonlijke overtuigingen zijn niet noodzakelijkerwijs ook de overtuigingen van de organisaties waarbij ik ben aangesloten: Meters, Nesma en ISBSG.
Ik moedig iedereen aan om opmerkingen en/of feedback op deze blog in te dienen.
Meetmethoden voor niet-functionele afmetingen
Terwijl de meetmethoden voor functionele afmetingen alleen de omvang van de functionele gebruikersvereisten meten (wat de software de gebruiker moet bieden), de niet-functionele maatmeetmethoden meten (vaak onderdeel van de) niet-functionele gebruikersvereisten, dit kunnen technische gebruikerseisen en/of kwalitatieve gebruikerseisen zijn (hoe de software moet werken). Ook de meting van de geleverde code wordt beschouwd als een niet-functionele maatmeting.
De meest gebruikte niet-functionele groottemaatstaf is de broncoderegel (slocs).
Bronregels code (slocs)
Source Lines of Code spreken veel mensen en organisaties aan omdat het softwaresysteem er eenmaal klaar voor is, het kan automatisch worden geteld door broncodetellers. Vaak, de ontwikkeltools meten al tijdens het project de regels code.
Veel organisaties gebruiken de slocs-meting als input voor hun schattingsprocessen voor softwareprojecten. Dit is opmerkelijk, aangezien het aantal slocs pas na voltooiing kan worden gemeten. Dit betekent dat het gebruik van slocs bij softwareschatting, de slocs moeten worden geschat, niet gemeten. Meestal schat een team van experts samen het aantal broncoderegels voor het nieuwe project en/of gebruikt analogiemethoden met betrekking tot eerder voltooide projecten om tot een schatting te komen van de op te leveren softwareomvang.
Hoewel dit een goed idee lijkt, deze methode brengt grote risico's met zich mee voor de schatting van de inspanning. Er is geen ISO-norm (of een andere standaard) beschikbaar voor broncoderegels. Verschillende tools voor het tellen van codes retourneren a (soms helemaal) ander resultaat na het tellen van dezelfde code. Soms worden fysieke lijnen gemeten, maar in plaats daarvan worden ook vaak bronverklaringen meegeteld. Omdat een verklaring gemakkelijk op meerdere regels kan worden geschreven, dit wijst al op een groot probleem.
In aanvulling op, het aantal benodigde broncoderegels is afhankelijk van factoren zoals de technische omgeving, complexiteit en programmeermogelijkheden. Broncoderegels vertegenwoordigen ook niet echt waarde voor de gebruikers. Is het beter om meer regels code of minder regels code te krijgen?? Meer regels kunnen meer functionaliteit betekenen, maar als men een leverancier zou betalen op basis van een prijs per 1000 bronregels code één ding is zeker... de klant zou veel code krijgen! Codetellers mogen niet de code meten die wordt gegenereerd door de ontwikkeltools, maar in werkelijkheid is het voor deze tools onmogelijk om de gegenereerde code uit te sluiten van de meting.
Daarom is het meestal erg moeilijk om de slocs van een voltooid softwareproject te gebruiken als input voor het volgende softwareproject. Experts gebruiken om het totale aantal broncoderegels voor een nieuw project te schatten en vervolgens historische gegevens te gebruiken op basis van broncoderegels is uiterst riskant. Door op deze manier te schatten, er zit al een groot onzekerheidspercentage in de belangrijkste invoerparameter van de schatting.
Zo, waarom schatten veel organisaties hun projecten op deze manier in? Enkele publicaties, bijvoorbeeld ‘Oorsprong van softwaredefecten en verwijderingsmethoden‘ door Capers Jones, stellen dat het op deze manier inschatten van projecten een vorm van professionele wanpraktijken is. Het kan soms werken, maar het risico is enorm en falende projecten met enorme overschrijdingen kunnen waarschijnlijk niet worden vermeden. In werkelijkheid, dit is precies wat vaak over het hoofd wordt gezien. Bij grote projecten gaat er meestal veel mis, en uiteindelijk is het bijna altijd mogelijk om de schuld te geven aan een aantal operationele problemen die altijd optreden tijdens een softwareproject... een technisch probleem, of een product owner die niet genoeg betrokken was, of de OTAP-omgeving is niet snel genoeg geïmplementeerd, of de klant veranderde veel van zijn eisen tijdens het project... enzovoort. In de meeste gevallen echter softwarefouten, bij het analyseren van de werkelijke oorzaak, het bewijst dat het project begon met te optimistische verwachtingen... het team is te klein, de looptijd te kort, de kosten te laag. Deskundige schattingen, en schattingen die niet zijn gebaseerd op industriestandaarden en ervaringsgegevens beginnen meestal met optimistische verwachtingen. Organisaties die de relatie begrijpen tussen een realistische inschatting en het resultaat van het project, zal zich richten op het inzetten van instrumenten die hen in staat stellen het project zo goed mogelijk in te schatten, ook al te optimistische schattingen van bijvoorbeeld leveranciers niet belonen. Echter, organisaties moeten een bepaald niveau van volwassenheid bereiken om dit te begrijpen en dit niveau van volwassenheid is nog ver weg voor veel organisaties in de branche... zelfs voor degenen die zichzelf als behoorlijk volwassen beschouwen!
Theoretisch, broncoderegels zijn helemaal niet nuttig voor softwareschatting. Sommige mensen melden succesvolle projecten die op deze manier worden geschat, maar vanuit theoretisch oogpunt zou dit in plaats daarvan het resultaat kunnen zijn van toeval of geluk.
De kenmerken om het nut van deze methode voor de schatting van softwareprojecten te beoordelen, staan vermeld in de volgende tabel:
| kenmerk | Ja nee | Opmerkingen |
| Doelstelling, herhaalbare, verifieerbaar en verdedigbaar | Nee | Slocs kunnen pas worden gemeten nadat het project is voltooid. Voor projectschatting kunnen alleen 'geraden slocs' worden gebruikt. |
| Historische gegevens beschikbaar | Ja | ISBSG R13: 180 projecten. Echter, niet mogelijk om het type gemeten SLOC te verifiëren. |
| Ondersteund door modellen/tools | Ja | QSM SLIM, SEER voor software, TruePlanning, COCOMO II. ISBSG |
SNAP-punten
SNAP is de afkorting voor “Software Non-functional Assessment Process,” een meetmethode van niet-functionele softwaregrootte. SNAP-puntmeting is bedoeld als aanvulling op functiepuntmeting, die de functionele softwaregrootte meet. SNAP is een product van de Internationale Functiepunt Gebruikersgroep (IFPUG), en is gedimensioneerd met behulp van de Software Niet-functionele Assessment Practices Manual, nu in versie 2.2.
SNAP is losjes verbonden met de ISO 9126 en ISO 25010 normen voor softwarekwaliteit. Het probeert de niet-functionele vereisten die in een softwareproject worden geïmplementeerd, te meten. Hoewel dit een goed idee lijkt, de SNAP-methode lijkt zijn doel te missen. Het biedt geen integraal meetinstrument voor alle niet-functionele eisen en bovendien wordt een aantal zeer relevante niet-functionele eisen helemaal niet gemeten. Een aantal aanvullende opmerkingen:
- De meeste documentatie die in de branche wordt gebruikt, vermeldt niet expliciet de benodigde informatie over de niet-functionele vereisten die SNAP probeert te meten. In aanvulling op, het is niet duidelijk wat te doen als deze informatie ontbreekt. Tel toch iets ... of tel niets?
- Niet alle iso's 9126 of ISO 25010 categorieën van niet-functionele vereisten worden gemeten. Zelfs als de SNAP-punten kunnen worden gemeten met de methode zoals gepubliceerd, de niet-functionele vereisten waarvan mensen denken dat ze belangrijke kostendrijvers zijn (bv. prestatie of veiligheid, enzovoort), worden genegeerd;
- Het is niet duidelijk hoe de relatie tussen de verschillende SNAP-categorieën wordt bepaald en waarom dit geldig zou zijn. Waarom zou de UI-complexiteit (SNAP-punten = Aantal eigenschappen toegevoegd of geconfigureerd …2, 3 of 4 maal het aantal unieke UI-elementen) van gelijke...of meer...of kleinere niet-functionele omvang zijn dan de niet-functionele omvang gemeten voor batchprocessen (4 keer, 6 keer of 10 maal het aantal gegevensattributen). Er lijkt geen relevant verband te bestaan tussen de categorieën en de manier waarop de SNAP-punten worden gemeten lijkt willekeurig;
- Professor dokter Abran wees erop dat de statistisch bewijs van de SNAP-methode slaagt niet voor de gebruikelijke methodische validiteitstests, aangezien het erop lijkt dat uitschieters in de dataset die wordt gebruikt om de correlatie tussen SNAP-punten en inspanning aan te tonen, niet lijken te zijn verwijderd;
- Sommige van de niet-functionele vereisten die worden gemeten, zijn in feite functioneel en worden ook gemeten in NESMA- en/of IFPUG-methoden. Dit is vreemd voor een methode die claimt alleen niet-functionele eisen te meten.
Globaal genomen, hoewel IFPUG en veel beoefenaars de SNAP-methode bepleiten als een goede en valide methode om te gebruiken bij het schatten, vanuit praktisch en theoretisch oogpunt zijn er nog veel problemen die moeten worden aangepakt voordat deze methode bruikbaar kan worden als het gaat om projectschatting. Op dit moment zijn er zeer beperkte historische gegevens van projecten gemeten in SNAP beschikbaar. In 2013, de International Software Benchmarking Standards Group publiceerde een SNAP-gegevensverzamelingsformulier, maar tot nu toe zijn er geen projectinzendingen met SNAP-punten ontvangen.
Voor nu, het kan maximaal worden gebruikt om te proberen de verschillen in prestaties of productiviteit tussen voltooide projecten te begrijpen, maar het is nog niet geschikt voor projectschatting.
De kenmerken om het nut van deze methode voor de schatting van softwareprojecten te beoordelen, staan vermeld in de volgende tabel:
| kenmerk | Ja nee | Opmerkingen |
| Doelstelling, herhaalbare, verifieerbaar en verdedigbaar | Nee | De SNAP-handleiding moet zorgen voor objectieve meting, maar omdat het niet zeker weet wat te doen wanneer noodzakelijke informatie ontbreekt, meetinstrumenten zullen waarschijnlijk verschillende aannames doen, wat resulteert in een verschillende grootte. |
| Historische gegevens beschikbaar | Nee | ISBSG legt projecten vast in SNAP-punten, maar er zijn nog geen gegevens ingediend. Mogelijk zijn er gegevens beschikbaar in de IFPUG SNAP-groep. |
| Ondersteund door modellen/tools | Nee |
Volgende blog
In de volgende blog over dit onderwerp, Ik zal mijn mening geven over het nut van de belangrijkste methoden voor het meten van hybride afmetingen 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).