IFPUG nieuwsaankondiging
Nu dat IFPUG is gepubliceerd Utip #3, de gebruikers van de IFPUG-methode hebben nu officieel groen licht gekregen om schattingsmethoden voor de grootte te gebruiken die eerder in de levenscyclus van het softwareproject kunnen worden gebruikt dan op het moment van een voltooid functioneel ontwerp. In uTip #3 de methoden High Level FPA (In Nesma vaak ‘wereldwijde FPA’ of ‘geschatte FPA’ genoemd) en indicatieve FPA worden beschreven. Het zijn inderdaad zeer nuttige methoden om de omvang van een applicatie te schatten (of project) en veel commerciële organisaties en regeringen over de hele wereld gebruiken deze methoden al jaren. In feite, in de praktijk is functionele documentatie zeer zelden volledig en gedetailleerd genoeg om een gedetailleerde FPA uit te voeren zo vroeg in de levenscyclus van het softwareproject, aangezien dit nodig is om het project te schatten. Dit is eigenlijk een argument van veel projectmanagers om geen gebruik te maken van FPA, omdat ze er ten onrechte van uitgaan dat een FPA-meting alleen kan worden uitgevoerd op een volledig functioneel ontwerp, wat te laat is in de levenscyclus van het project om voor hen bruikbaar te zijn voor schattingsdoeleinden.
Vooral nu de industrie afstapt van de traditionele ontwikkelingsmethodologieën naar de meer flexibele methodologieën, functionele documentatie die volledig en gedetailleerd genoeg is om een gedetailleerde FPA uit te voeren, wordt steeds zeldzamer, men heeft dus geen andere keuze dan een geschatte methode te gebruiken om de functionele omvang te kunnen meten / schatten.
Natuurlijk, bij elke schatting van iets ... men moet zich afvragen wat de nauwkeurigheid van de schatting zou zijn en wat is de onzekerheid die wordt geïntroduceerd vanwege de schatting. Het goede nieuws is dat er studies zijn gepubliceerd waarin de nauwkeurigheid van de High Level FPA-methode en de Indicatieve methode vergeleken met een gedetailleerde FPA zijn bestudeerd. In Sogeti Nederland bijvoorbeeld, de afdeling Maatvoering, Het schatten & Controle (SEC) presenteerde een papier op het Software Measurement European Forum in Rome (Italië), in juni 2009, waarin de nauwkeurigheidsverlies en de moeite die wordt bespaard over het gebruik van FPA op hoog niveau en indicatieve FPA van 42 projecten werden vergeleken met gedetailleerde FPA-metingen.
Hoewel voor dit onderzoek de Nesma-methode is gebruikt, de resultaten van dat onderzoek zouden ook vergelijkbaar moeten zijn met de IFPUG-methode, zoals er zijn heel weinig verschillen tussen de twee methoden in de praktijk tegenwoordig.
De papier, inclusief de meetgegevens, is beschikbaar op de Lidwoord bladzijde. De belangrijkste conclusies van het onderzoek staan in de onderstaande tabel:
| Methode | Nauwkeurigheid | Nauwkeurigheidsverlies | Inspanning | Inspanning winst |
|---|---|---|---|---|
| Gemiddelde | Gemiddelde | |||
| Gedetailleerd | 100% | 100 norm uren | ||
| Hoog niveau* | 98.5% | 1.5% | 67 norm uren | 33% |
| Indicatief | 83.5% | 16.5% | 18 norm uren | 82% |
* De FPA op hoog niveau wordt in de Nesma-methode ook wel 'wereldwijde FPA' of 'geschatte FPA' genoemd
Het blijkt dat het gebruik van de High Level FPA-methode gemiddeld alleen resulteert in 1,5% nauwkeurigheidsverlies, wat meestal niet echt een probleem is in het begin van de levenscyclus van een softwareproject. De indicatieve methode is gemiddeld iets minder nauwkeurig, maar aangezien deze methode zelfs eerder in de levenscyclus van het softwareproject kan worden gebruikt (wanneer alleen het aantal logische bestanden bekend is of kan worden bepaald), deze methode is erg handig om een vroege ‘ruwe orde van grootte te creëren (rom)’Schatting van de verwachte functionele omvang.
De kolom inspanningsuren toont genormaliseerde uren in plaats van echte uren. Dit betekent dat de geschatte methode gemiddeld duurt 67% van de tijd om te meten in vergelijking met een gedetailleerde FPA-meting. De indicatieve FPA-methode duurt gemiddeld 18% van de inspanning van een gedetailleerde FPA-meting.
Over de Auteurs
Harold van Heeringen, Edwin van Gorp en Theo Prins zijn software metrics consultants / software cost engineers voor Sogeti Nederland B.V. Ze publiceren regelmatig op internationale conferenties over praktische aspecten van softwaremeting. De meeste van hun artikelen zijn te vinden op de Lidwoord bladzijde.
Welk percentage van uw FP-analyses is met behulp van de gedetailleerde methode? Laat het ons weten op de forum.
Harold en Theo: Bedankt voor het plaatsen van dit.
Ik heb de afgelopen tien jaar de lichte FPA-methode gebruikt om een aantal redenen:
– Vroege schattingen vereisen een hoog niveau van de functionele omvang. Gedetailleerde fp-analyse zou doen vermoeden dat er nauwkeurigheid is waar die niet kan zijn.
– Zelfs in een nulanalyse, mijn klanten kunnen vaak geen gedetailleerd overzicht geven van de implementatie van enkele attributen. Gebrek aan documentatie, gebrek aan kennis, gebrek aan iets…. de redenen zijn talrijk.
– Ik bied meestal vaste prijsopgaven, dus om kostenefficiënt te zijn, analyse op hoog niveau is de beste keuze.
– Ik wil het publiek niet vervelen. Klanten zijn best tevreden als ik binnen een enorme SAP-applicatie afrond 2 dagen (“We dachten altijd dat het weken zou duren, … hoe kan het dat schatten maar duurt 2 dagen….”). En we willen niet allemaal tevreden klanten?
Slechts een keer begon ik bijna te zweten: Ik had mensen van een groot telecombedrijf opgeleid in licht-FPA-analyse. We hadden de omvang van de ontwikkelingsresultaten van de organisatie gedurende 12 maanden geteld. Na het rapporteren van de FP-resultaten, het management durfde mij noch hun eigen personeel te vertrouwen, wie weet? Dus vlogen ze in een ander metrics-bedrijf (ze vliegen ze altijd van ver naar binnen, in de hoop dat dit het effectiever maakt) om de hele analyse opnieuw uit te voeren met behulp van de gedetailleerde IFPUG-methode.
Je raadt wat er toen gebeurde, niet jij? Ze vonden minder dan 1% afwijking tussen onze lichtanalyse en hun gedetailleerde analyse!
Ik denk dat de gerapporteerde inspanningstoename nogal conservatief is en kan afhangen van uw rapportagestandaarden. In haar vergelijking (2 weken vs 2 dagen) Eva toont een inspanningstoename van 80% voor een analyse op hoog niveau. Mijn ervaring is vergelijkbaar: een analyse op hoog niveau is tenminste 4 keer sneller dan een gedetailleerde analyse.
Op de IT-vertrouwensconferentie (Tokio, oktober 2014), Er werd een presentatie gegeven door Japanse onderzoekers die de Nesma High Level FPA-methode verklaarden verantwoordelijk te zijn voor de toegenomen belangstelling voor het gebruik van functionele dimensionering in de Japanse industrie. Ik probeer de presentatie te krijgen, maar er is al een korte paper beschikbaar, ook via ISBSG slideshare: http://www.slideshare.net/ISBSG/matsumoto-towards-an-early-software-effort-estimation-based-on-the-nesma-method-estimated-fp
Ik was erg verrast om te horen dat IFPUG FPA uTIP # 3 ‘Early FPA’ heeft aangekondigd. Meer dan 10 jaar NESMA's ‘geschatte analyse’ (die identiek is aan de analyse op hoog niveau) is gebruikelijk in de Nederlandse metrics consultancy scene.
De tabellen in de blog laten ondubbelzinnig zien dat er slechts een klein verschil in grootte is tussen gedetailleerde analyse en geschatte analyse. Dus kan worden geconcludeerd dat de nauwkeurigheid van ‘hoog niveau’ analyse is bijna net zo goed als gedetailleerde analyse, met een aanzienlijke winst in inspanning.
Naar mijn mening is het echte voordeel dat ‘hoge niveau’ FPA kan worden toegepast op grofkorrelige spec's, dus eerder in het project. In mijn praktijk betekent dit dat aan het einde van de Requirements Analysis snel een redelijk nauwkeurige schatting van de grootte en een projectschatting kan worden opgeleverd (en voor Gedetailleerd Ontwerp). Ik ben erg benieuwd naar de ‘Consistent Cost Estimating’ van IFPUG.
Bedankt voor dit bericht; het is best handig. We hebben in veel situaties Quick FPA gebruikt, en de nauwkeurigheid van de schatting wordt altijd besproken. Deze analyse zou van pas komen!