Messages posted by: caroldekkers

Hello,

The VAF has NOT been removed - it simply has become an optional adjustment step because ISO/IEC standards have defined "Functional Size Measurement" as being purely the functional size of software based on an evaluation of the Functional User Requirements.

The usage of the VAF is varied amongst practitioners of the IFPUG FP method: some companies find value in using the adjustment factor; others have a homogeneous portfolio where most of their software development has the same "non-functional requirements" that are covered by the VAF so they choose not to use it. Still others use FP as an input variable of size in estimating tools (such as COCOMO II and SLIM and others) which cover the non-functional and technical requirements through various input variables.

The IFPUG IT Performance Committee is working on an additional adjustment evaluation scheme called SNAP (Software Non-functional Assessment Process) that takes a look at the variety of non-functional requirements that can affect effort and cost estimating - and a preliminary draft release of this methodology (not a replacement for the VAF) is available for download from www.ifpug.org.

A long answer to your short question - but no, IFPUG has not abandoned the VAF, simply set it aside to meet the conformity requirements of a "Functional Size Measurement" method in ISO.

unAdjusted FP = functional size
VAF = non-functional adjustment factor
Adjusted FP = adjusted FP size (no longer called purely "Functional Size")

Hopefully this all makes sense.
Carol

This is a great question and there is more to it than a question of pure accuracy.

When you report a number (like adjusted FP) that is based on components that are made up of integers (3,4,6, 4,5,7, 7,10,1, 5,7,10) it is statistical folly to even profess an accuracy (or precision!) that is closer than +/- 50% of the largest granularity number that goes into the mix. (I.e., +/- 50% of 15 is 7.5 so uFP is really no more accurate than +/- 7.5 FP).

When you then multiply the uFP by a two decimal point number, it is even more misguided to introduce a decimal point into the mix - this "pretends" we have some magical accuracy out of the multiplication process (ref: How to lie with statistics!) As if you can gauge even a single FP let alone a fraction of one.

It gets even worse when we are "estimating" thee function points from incomplete requirements which further introduces inaccuracies into the mix. We are doing our customers a disservice when we report anything but integer results.

No wonder when people say that their estimate is 100.1 FP that the project team rolls their eyes and management thinks we are wizards! We have to start acting our age when it comes to metrics and what we communicate!

This is a long answer to your short question, but I would never report the decimal place. Go with 100 FP and you'll find that the consequences lead to higher reliability on the part of the business and to your credibility.

I agree with Glanza, there is no ILF or EIF to count in this situation because the data and the maintenance are not within the boundary of the software being counted or another application boundary.

Carol