Functional software-sizing methods

Historically, the most common software sizing methodology has been counting the lines of code written in the application source. Another approach is to do Functional Size Measurement, to express the functionality size as a number by performing function point analysis. The original sizing method is the IFPUG. The IFPUG FPA functional sizing method (FSM) has been used successfully – despite being less accurate in estimating complex algorithms and being relatively more difficult to use than estimating lines of code. Adaptations of the original Functional Size Measurement methodology have emerged, and these standards are: COSMIC Function Points, Mk II Function Points, Nesma Function Points, and FiSMA Function Points. Other variants of these standards include Object-Oriented Function Points (OOFP) and newer variants as Weighted Micro Function Points, which factor algorithmic and control-flow complexity.

The best Functional Sizing Method depends on a number of factors, including the functional domain of the applications, the process maturity of the developing organization and the extent of use of the FSM Method.^[1][2] There are many uses and benefits of function points^[3] beyond measuring project productivity and estimating planned projects, these include monitoring project progress and evaluating the requirements coverage of commercial off-the-shelf (COTS) packages.

Other software sizing methods include Use Case-based software sizing, which relies on counting the number and characteristics of use cases found in a piece of software, and COSMIC functional size measurement, which addresses sizing software that has a very limited amount of stored data such as 'process control' and 'real time' systems.

Both the IFPUG Method and the COSMIC Methods are ISO/IEC standards.

Non-functional software-sizing method

The IFPUG method to size the non-functional aspects of a software or component is called SNAP, therefore the non-functional size is measured by SNAP Points. The SNAP model consists of four categories and fourteen sub-categories to measure the non-functional requirements. Non-functional requirement are mapped to the relevant sub-categories. Each sub-category is sized, and the size of a requirement is the sum of the sizes of its sub-categories. The SNAP sizing process is very similar to the function point sizing process. Within the application boundary, non-functional requirements are associated with relevant categories and their sub-categories. Using a standardized set of basic criteria, each of the sub-categories is then sized according to its type and complexity; the size of such a requirement is the sum of the sizes of its sub-categories. These sizes are then totaled to give the measure of non-functional size of the software application.

Additional information

Several software quality standards mandate the use of a valid sizing method as part of the organization's standard software engineering life cycle. For instance, Capability Maturity Model Integration (CMMI) poses such a requirement. An organization cannot be appraised (certified) as CMMI level 2 or level 3 unless software sizing is adequately used.