The size of the software needs to be estimated to figure out the time needed in terms of calendar and man months as well as the number and type of resources required carrying out the job. The time and resources estimation eventually plays a significant role in determining the cost of the project.
Most organizations use their previous experience to estimate the size and hence the resource and time requirements for the project. If not quantified, this estimate is subjective and is as good as the person who is conducting this exercise. At times this makes it highly contentious. It is therefore imperative for a government organization to adopt an estimation mechanism that is:
1. Objective in nature.
2. It should be an acceptable standard with wide spread use and acceptance level.
3. It should serve as a single yardstick to measure and make comparisons.
4. Must be based upon a deliverable that is meaningful to the intended audience.
5. It should be independent of the tool and technology used for the developing the software.
A number of techniques and tools can be used in estimating the size of the software.
These include:
1. Lines of code (LOC) 2. Number of objects 3. Number of GUIs
4. Number of document pages 5. Functional points (FP) Comparison of LOC and FPA
Out of these 5, the two most widely used metrics for the measurement of software size are FP and LOC. LOC metric suffer from the following shortcomings:
1. There are a number of questions regarding the definition for lines of code. These include:
a. Whether to count physical line or logical lines?
b. What type of lines should be counted? For example, should the comments, data definitions, and blank lines be counted or not?
2. LOC is heavily dependent upon the individual programming style.
3. It is dependent upon the technology and hence it is difficult to compare applications developed in two different languages. This is true for even seemingly very close languages like in C++ and Java.
4. If a mixture of languages and tools is used then the comparison is even more difficult. For example, it is not possible to compare a project that delivers a 100,000-line mixture of Assembly, C++, SQL and Visual Basic to one that delivers 100,000 lines of COBOL.
FP measures the size of the functionality provided by the software. The functionally is measured as a function of the data and the operations performed on that data. The measure is independent of the tool and technology used and hence provides a consistent measure for comparison between various organizations and projects.
The biggest advantage of FP over LOC is that LOC can be counted only AFTER the code has been developed while FP can be counted even at the requirement phase and hence can be used for planning and estimation while the LOC cannot be used for this purpose.
Another major distinction between the FP and LOC is that the LOC measures the application from a developer's perspective while the FP is a measure of the size of the functionality from the user's perspective. The user's view, as defined by IFPUG, is as follows:
A user view is a description of the business functions and is approved by the user. It represents a formal description of the user’s business needs in the user’s language. It can vary in physical form (e.g., catalog of transactions, proposals, requirements document, external specifications, detailed specifications, user handbook). Developers translate the user information into information technology language in order to provide a solution. Function point counts the application size from the user’s point of view. It is accomplished using the information in a language that is common to both user(s) and developers.
Therefore, Function Point Analysis measures the size of the functionality delivered and used by the end user as opposed to the volume of the artifacts and code.
The Paradox of Reversed Productivity for High-Level Languages Consider the following example:
Assembler
Version Ada Version Difference
Source Code Size 100,000 25,000 -75,000
Activity - in person months
Requirements 10 10 0
Design 25 25 0
Coding 100 20 -80
Documentation 15 15 0
Integration and Testing 25 15 -10
Management 25 15 -10
Total Effort 200 100 -100
Total Cost $1,000,000 $500,000 -$500,000
Cost Per Line $10 $20 $10
Lines Per Person-Month 500 250 -250
In this example, it is assumed that the same functionality is implemented in Assembly and Ada. As coding in Assembly is much more difficult and time consuming as compared to Ada, it takes more time and it is also lengthy. Because there is a huge difference in the code size in terms of Lines of Code, the cost per line in case of Assembly is much less as compared to Ada. Hence coding in Assembly appears to be more cost effective than Ada while in reality it is not. This is a paradox!
Function Point Analysis - A Brief History and Usage
In the mid 70's, IBM felt the need to establish a more effective and better measure of system size to predict the delivery of software. It commissioned Allan Albrecht to lead this effort. As a result he developed this approach which today known as the Function Point Analysis. After several years of internal use, Albrecht introduced the methodology at a joint/share conference. From 1979 to 1984 continued statistical analysis was performed on the method and refinements were made. At that point, a non-profit organization by the name of International Function Point User Group (IFPUG) was formed which formally took onto itself the role of refining and defining the counting rules. The result is the function point methodology that we use today.
Since 1979, when Albrecht published his first paper on FP, its popularity and use has been increasing consistently and today it is being used as a de facto standard for software measurement. Following is a short list of organizations using FP for estimation:
1. IEEE recommends it for use in productivity measurement and reporting.
2. Several governments including UK, Canada, and Hong Kong have been using it and it has been recommended to these governments that all public sector project use FP as a standard for the measurement of the software size.
3. Government of the Australian state Victoria has been using FP since 1997 for managing and outsourcing projects to the tune of US$ 50 Million every year.
4. In the US several large government departments including IRS have adopted FP analysis as a standard for outsourcing, measurement, and control of software projects.
5. A number of big organizations including Digital Corporation and IBM have been using FP for their internal use for the last many years.
Usage of FP includes:
Effort Scope Estimation
Project Planning
Determine the impact of additional or changed requirements
Resource Planning/Allocation
Benchmarking and target setting
Contract Negotiations
Following is a list of some of the FP based metrics used for these purposes:
Size – Function Points
Defects – Per Function Point
Effort – Staff-Months
Productivity – Function Points per Staff-Month
Duration – Schedule (Calendar) Months
Time Efficiency – Function Points per Month
Cost – Per Function