Software is the output product from the software development and/or enhancement activity that is delivered and/or supported by IT. It makes sense to be able to objectively ‘quantify’ this product in order to establish its relative size with respect to other software products in our portfolio.
Traditionally the ‘amount of product’ produced from a software development project was perceived as being the amount of programming source code written. I.e. Source s of Code (SLOC or KLOC). In early homogeneous software development environments the amount of SLOC and the perceived relative size of software had a fairly direct relationship. However, as technology progressed, and software was built using hybrid languages, re-usable modules, COTs components, utilities, code generators and high level languages, the relationship between the SLOC and the relative size of the software became less predictable.
Developers need to be able to accurately estimate the effort and cost to deliver a software product and to compare different solutions, technology and tools for their efficiency and cost effectiveness. But in order to do this they needed to be able to quantify ‘what’ they are building i.e. how ‘much’ software, since the resources required are related to ‘how much’ software is built or maintained.
In the late 1970s Allan Albrecht from IBM established that there was a fairly predictable relationship between the resources required to build and/or support a software product and the number, type and complexity of the functions in that software product. I.e. The effort to build an ‘amount of software’ to satisfy the functional requirements of the User was proportional to the ‘size of the functional requirements’. He developed a method to size the functional requirements, called Function Point Analysis. This concept of sizing the functional user requirements to establish relative size of software has advanced over the past three decades so that now the concept has been transformed into an ISO standard called “Functional Size Measurement”.
There are four ISO Methods for Functional Sizing, that fall into two main groups, those derived from Albrecht’s original methodology (IFPUG Function Point Analysis, and NESMA Function Point Analysis) and those that derive from extensions of his method (MK II and COSMIC Functional Sizing Methods).
Functional Size Measurement (FSM) is the only internationally recognised and ISO standardised technique to measure the size of the Users Functional Requirements. Since Functional Requirements are independent of any constraints of how the software is built (i.e. Independent of the non-functional technical and quality requirements), then it enables software to be measured accurately and repeatedly over time, as developers utilise different tools, techniques and technologies to build software.
FSM also enables comparisons of IT efficiency and cost effectiveness using different development environments and strategies.
The recognition of the value of Functional Size Measurement is such that it is the only measurement unit for software development and support processes that has been formalised to be the level of an ISO standard. All other common measures such as effort, duration, defects or speed of delivery do not have an internationally agreed method of collection, validation, and comparison.