Many critics of the technique claim that FSM:
Some of these comments are valid criticisms and others are excuses for avoiding the hard work of measurement. We have addressed each of these points in turn below.
FSM has become the method of choice for organisations worldwide to measure their software development product. It has been unequivocally proven to be the most reliable and effective method to estimate software and to compare productivity. Whilst its exponents admit it is still not perfect, there continues to be teams of experts around the world, working daily on improving and certifying FSM related methods, tools, training, and standards. Its usage has grown from just the USA, Netherlands, UK and Australia in the late 1980s to being used in nearly every software development country in the world today, including China, South Korea, Brazil, India and most of Western Europe.
Since the Functional User Requirements are independent of the development environment, then the measurement of these requirements is not influenced by ‘how’ the software is built. However the effort and cost to build and support is influenced by the environment; therefore for estimation and comparison purposes, different productivity factors are applied for the different environments. Just as in the building industry, where the size of the house is independent of the technology and tools used to build it, but the dollar cost per square metre is adjusted accordingly. The size of the house is independent of the technology, just as the size of the functional requirements of the software is independent of its build environment, so FSM is as valid today as it was in the past.
Since FSM measures the Functional User Requirements, then as long as there are requirements, they can then be measured. However different software can have different types of requirements and this is why we have different Functional Size Measurement Methods. Different methods are attuned to measuring different types of requirements. Identify the functional domain of the software you are building and select the appropriate FSM method.
All the current ISO Standard FSM Methods, measure the relative size of software functions based on the amount of different data types processed (enter, leave, read and written to storage) by the function. The intermediate algorithmic transformations, translations and conversions of those data types are not included in the measurement. Only the actual individual data movements from one form to another are considered. The reason for not considering algorithms is because there is no internationally accepted way of defining or quantifying their complexity. In reality for most applications, complex algorithms only exist in a very small proportion of the software. One commonly accepted way to address the impact of the algorithms on effort and cost is to isolate the functional area and apply a different cost factor to those requirements that have algorithmic complexity.
The act of measuring requires the dissection of the Functional Requirements into their elementary processes, which are in turn catalogued and assessed for size. The effort to do this will be directly proportional to the magnitude of the Functional Requirements, but will be also be strongly influenced by the quality (completeness, ambiguity, consistency) of the specification of those requirements. Actually doing the measurement, highlights any gaps in the requirements and is often the only fully documented list of functions for an implemented system. Time consumed in the measurement is in most cases compensated by the time saved by identifying requirements defects early in the life cycle of a project.
Typically an experienced functional size measurement expert can measure, document and report between 200 and 300 function points per day. This is equivalent to a project that would consume 12 to 18 person months of effort. I.e. Measurement is < 0.5% of project effort.
However in our experience, the cost of measurement is far outweighed by the benefits the measurement provides the project manager in optimising the success of the project and minimising risk of project failure .
This is a ‘chicken and egg’ problem, where a project manager needs to estimate a high risk project but even if they measure the functional size, it will be of little benefit if they have no idea of how many hours or dollars it take to build a functional software unit.
We recommend to start measuring now and with time you will build your own metrics repository. This will enable you to know, for each development environment, your organisations number of effort hours to build or change a functional unit and the relative cost per unit. However, until you can collect enough data, there is always industry data available to assist in project estimations and productivity comparisons. For example the International Software Benchmarking Standards Group (ISBSG) has freely available productivity data on over 4,000 projects and all the latest development environments.
Whilst accurate Functional Sizing does require detailed functional specifications to identify each data group used by a functional process, there are ways to do less accurate sizing with less detailed specifications. Since the accuracy of the measured size is directly related to the accuracy and completeness of the specification, then these less accurate ‘approximation’ methods will result in a size that is anywhere between 15% to 30% different from true value. However, at early cost benefit analysis of a project, a ball-park size provides valuable information when assessing the viability of a project budget or schedule.
The use of FSM world wide is increasing daily, from India, China, and Brazil to the United Kingdom and the USA. In terms of methods to size software it is estimated to have >99% of market share. All Functional Sizing methods work on the same principle i.e. to measure the functionality delivered by the software. Whether they do this by measuring Use Cases or by identifying elementary processes, the principle is the same. The advantage of using the ISO standard Functional Size Methods is that the functional process measured by these methods is clearly defined such that requirements can be accurately and repeatedly decomposed to the elementary process level, no matter how they are specified. This is also true for implemented software, it can be analysed and decomposed to this same elementary process level. The methodology to measure Use Cases and assign points, has the limitation that there is no internationally accepted standardised level of granularity for defining Use Cases and as such there tends to be no external consistency in the measured size, making it difficult to compare externally or utilise industry data.
FSM only measures the functional requirements; it does not take into account variations in quality and technical requirements. Just as in the building industry the size of a house is based on the functionality defined in the plans, but the house does not increase in square metre size because it is built in brick on the side of a cliff compared to timber on flat ground; software size however, is based only on functionality delivered. When estimating the cost of the house to be built with different quality and technical constraints the builder changes the dollar charge rate to build a square metre, likewise in software development the productivity rate is adjusted relative to the impact of the quality and technical constraints. The degree of adjustment can be determined from similar projects available in Industry Data.