2.3 COMPLEXITY ASSESSMENT

< Day Day Up >

Both IFPUG and Mark II FPA have historically defined additional mechanisms for general system complexity assessment. It is now generally accepted that the approaches used are less than adequate, mainly because they are overly simplistic and often the factors used end up balancing each other out, so most practitioners do not use these unless they have to.

Finally, do not fall into the trap of looking upon FPA as the totality of a metrics initiative — it never is. FPA is a very widely used technique but all it provides is a measure of software system size. How you use that data to manage and improve your process is what really counts.

To finish off this chapter we should return to the point of contention around FPA. Put simply, some people express doubt as to the effectiveness of the measure, the validity of the underlying measurement model and, in some cases, the theoretical veracity of FPA. I do believe that we have to return to my first principle of Software Metrics: pragmatism and compromise. I do not wish to enter into an argument around the concerns held by some individuals but I will make the following point.

Size is a fundamental component of almost all Software Metrics initiatives. The only candidate size measures with any validity today are FPA or Lines of Code, which has many other issues associated with it. I am very happy to consider any viable alternative but I am not aware of any being used across a number of companies or organizations today. So the bottom line for me is, if you don't want to use FPA then you have to use Lines of Code or find something better.

< Day Day Up >