Can Function Points deliver any thing beyond size & efforts?

I remember those early days in software industry, when we had preliminary understanding of Function Point concepts, and some of us used to recollect that we have studied Function Point Analysis as a part of our ‘Software Engineering’ syllabus. Project managers were hard pressed for the use of Function Points as a software sizing mechanism. We started realizing the importance of ‘Function Points’, for measuring our software size and subsequently effort estimation, as we started gaining more insight into it. Having a standard sizing mechanism across the organization was the motive behind adopting Function Points and in no time, the term “FP” became as popular as “OOAD”. Since then, most of us have developed good understanding of FP, and some of us have practiced it successfully in software projects.

But how many of us have realized the Real Power of FP? Have we thought about the fact that, are there any other useful side-effects of using FP, apart from producing the productivity figures for our projects and re-using it for future effort estimations. Let us try and see, what FP can offer apart from its known benefits. Before we take a closer look into FP side effects (as I would like to call it), let me explain the basic concepts of the FP, for the readers who are new to FP.?

Function Points is a unit of measure for software much like kilometers is to measuring distance or Celsius is to measuring temperature. Functions points measure software by quantifying its functionality provided to the user. Alan Albrecht introduced the basic concepts of what is now known as ‘Functional Size Measurement’ in 1979. Later on, IFPUG (International Function Point Users Group) was established in 1986 as a non-profit member governed organization and it endorses FPA as its standard methodology for software sizing. IFPUG Function Points measure the “logical” or “functional” size of software applications based on the Functional User Requirements (FUR). Functional Size is independent of how the software will operate and also of how it will be developed. Capers Jones cited in 1999 that “IFPUG counting rules are used by at least twice as many people as all other counting methods put together”. The International Software Benchmarking Standards Group (ISBSG) has demonstrated an even higher margin of usage – an overwhelming number of its projects are sized in IFPUG Function Points.

What is Functional Size?

Functional Size is the measurement of the software functionality, which is delivered to the user as a result of the software application development or enhancement. The word “User” in the context of Functional Size measurement means any person, other software or the department, which has the need to interface with the software under consideration. This definition of user is analogous to “Actor” in UML (Unified modeling Language) paradigm. IFPUG FPA measures the size of software functionality by breaking its Functional User Requirements down into five types of elementary components:

External Input (EI): It is an elementary process in which the data crosses the boundary from outside to inside. This data may come from a data input screen, electronically or from another application. The data can be either control information or business information. If the data is business information, it is used to maintain one or more internal logical files. If the data is control information, it controls the behavior of the application. It is rated into Low, Average or High and scores 3, 4 or 6 FP respectively.?

External Output (EO):

It is an elementary process in which derived data passes across the boundary from inside to outside. The data generates reports or output files sent to other applications. These reports or files are created from one or more internal logical files and/or external interface files.?IFPUG method rates it into Low, Average or High and scores 4, 5 or 7 FP respectively.

External Query (EQ): It is an elementary process with both input and output components that result in data retrieval from one or more internal logical files and/or external interface files. This information is sent outside the application boundary. The input process does not update any internal logical files and output side does not contain any derived data. It is rated as Low, Average or High and scores 3, 4 or 6 FP respectively.?

Internal Logical File (ILF): It is a user identifiable group of logically related persistent data that resides entirely within the application boundary and is maintained through external inputs. In other words, External Input is responsible for creating, updating & deleting this data. Each ILF is rated as Low, Average or High and a FP weight of 7, 10 or 15 FP is assigned to it.?

External Interface File (EIF): It is user identifiable group of logically related persistent data that is used for reference purpose. The data resides entirely outside the application boundary and is maintained by another application. This means an EIF counted for the application under consideration must be an ILF in another application. Each EIF is rated as Low, Average or High and assigned a weight of 5, 7 or 10 FP respectively.

Benefits and Uses of IFPUG Function Points

?Let us have a look at some well-known benefits of Function Points.?

• FP can be used to create an inventory of all user transactions and files of the project/application. This inventory can help measure scope creep and project growth at subsequent stages of the project.
• FP is useful for sizing software applications. Sizing is important for computing productivity (Number of staff hours per FP), estimating efforts and understanding unit cost of software application ($ per FP).
• Since FP is widely accepted and understood measure of software functionality, independent measurements of software size carried out at different times, generally produce same FP count within a reasonable margin of error.

And now, with the above background; we are all set to take a deeper dive into the world of ‘Function Points’. Let us see, if we could use ‘Function Points’ more innovatively in some other areas of software measurement and unleash the power of FP.?

• Using Function Points to estimate Test Cases

Research shows a strong relationship between Function Points and number of test cases. Capers Jones has estimated that, total number of test cases will approximately equal the number of Function Points raised to the 1.2 power (FP 1.2). Data gathering and laboratory findings indicate that, Number of acceptance test cases is equal to 1.2 times the FP count. This reveals an interesting fact that; test cases grow at a faster rate than FP. I suppose this is intuitive because as an application grows the number of interrelationships within the application becomes more complex, hence multi-fold increase in test cases. Understanding the number of test cases leads to the logical analysis of comparing actual test cases with expected test cases. If actual test cases fall short of expected test cases, then there is inadequate test coverage, which often leads to more defects being leaked to the customer. Thus, we can effectively use the FP count, to estimate number of test cases, and thus one can understand & control the potential defects leaked to the customer.

• Understand wide productivity ranges across projects

Productivity is defined as the ratio of outputs / inputs i.e., Number of FPs per staff month, or alternatively it can be expressed as number of hours per FP. Organizations suffer from wider productivity ranges across projects, due to various reasons. Projects not following standard software development process could be one of the causes of these variations. Over and above this, having various sizing mechanisms for different project categories, often lead to multiple sizing units making the job of computing average productivity figures even more difficult.?Since Function Point is independent of software platform, development technology and language, it helps to size various project categories using the same sizing mechanism, thus help generate consistent data at organizational level.

• Understanding Scope Creep

Beauty of Function point is that it can be counted as early as during the detail requirement analysis stage of the software project. This allows us to compare the FP count, at the end of detail requirement and/or design phase, to the FP count actually delivered to the customer. If the number of function points has increased, it can be assumed that either the project has been better defined or the project has actually grown in size. The amount of growth is indications of how well requirements was gathered and/or were communicated to the project team. Generally, the amount of project growth declines over time, indicating that, communication with the end-user has improved.

• Effectively Calculate true cost of software

Total cost of software is the sum of all the costs incurred during the life cycle of the project including the enhancement & maintenance costs. Generally, good investment in analysis & design often results in lesser maintenance costs. It is important to have a unit cost (in terms of hours/FP or $/FP) to properly evaluate initial investment and compare this to future expenditures. Adequate amount of investment in ‘up front’ design, often results in reduced per unit cost for enhancement & maintenance activities.

• Use FP count to help understand Maintenance Costs

If the amount of new functionality is tracked and added to base product, the unit maintenance cost may actually fall while maintenance expenditures remaining constant or increase. If maintenance costs are increasing at a rate less than function point growth, then it means that, maintenance cost is actually falling. Let us understand this with an example. If an organization spends $100,000 to maintain 10,000 function points or $10 per function point, but the number of function points grow by 10% to 11,000 and maintenance dollars remain constant, then maintenance costs per function point actually falls to $9. So knowing the unit cost ($/FP) of software application helps to understand this concept well.

• Use Function Points to help with Contract Negotiations

Contract managers can use their knowledge of function points to construct and manage projects based on the price per FP, as well as comparing vendor pricing. FP count can be used with Fixed Price contracts, since successful management of fixed price contracts depends on accurate representation of effort. Normalized metric such as $/FP for the entire life cycle of the project, can be applied effectively to decide the contract price.

Thus, FP Analysis provides the best objective method for sizing software projects, and for managing the size of the software project during development. It is also the best method for managing risk, since the client or the user can more readily accept the risk for a given software size (in function points) and also the developer can more readily accept the risk for the cost of production (the cost per FP).

Also, if the software developer knows exactly what their internal cost is to develop a function point, they can incorporate it into the costing algorithms used to decide the price of “external software”. So with clear understanding of time, effort and cost per FP, pricing “third party software packages” could become easier.

• Function Points can help develop standard set of metrics

Productivity / Cost metrics are used to demonstrate the rate and cost of functionality that is being delivered. Quality metrics are useful to demonstrate existing Quality level and help track continuous improvement efforts in the software development process. Following metrics are found useful:

Productivity / Cost Metrics

(1) Cost per FP: measures the average cost to deliver or maintain a function point. This data can be used to estimate future projects.

(2) Function Points per Calendar Month: measures the average amount time taken to deliver a function point with given staffing levels.

(3) Function Points per Staff Month: measures the average number of function points delivered for applied month of effort.

Quality Metrics

(1)?Defects per Installed Function Points: co-relates the quality of the software to the size of the application.

(2) Maintenance hours per Installed Function Points: co-relates support effort to application size, for currently installed software. Here, applications with higher maintenance hours per FP could be probable candidates for re-engineering or replacement.

(3) Defects per New Installed Function Points: evaluates the quality of new software to ensure that improvements in the software delivery process are effective.

These metrics are often indicators of performance and generally indicate useful trends and could help in identifying the problem areas and also helpful in demonstrating the progress.

To summarize, we have seen how to use function points beyond what they are generally known for and to use them more effectively for various aspects of the software project management, in addition to Size & Effort Estimation. With ISO/IEC and IFPUG now publishing ISO/IEC 20926:IFPUG Function Point Counting Practices 4.3.1 unadjusted as an International standard, ‘Function Points’ have already become popular software sizing mechanism and are contributing to ‘Functional Size Measurement’ as an emerging software engineering practice.

Gunesh Apte, PMP