Effort Estimation Technique: Function Point Analysis (Part 1)

The Function Point Analysis technique was developed during the late seventies by IBM, which commissioned one of its employees, Allan Albrecht to develop this technique. In the early eighties, this technique was refined, and then a new organization, International Function Point Users Group (IFPUG), was founded to take the Function Point Analysis technique forward; while keeping the core spirit behind what Albrecht had proposed.
Function Point Analysis (FPA) is a sizing measure that uses a system of sizing as per clear business significance. Function Point Analysis is a structured technique of classifying components of a system. One of the primary goals of Function Point Analysis is to evaluate a system's capabilities from a user's point of view. It is a method used to break systems down into smaller components so that they can be better understood and analyzed. The main objectives of FPA are:
1. Measure software by quantifying the functionality requested by and provided to the customer.
2. Measure software development and maintenance independently of technology used for implementation.
3. Measure software development and maintenance consistently across all projects and organizations.
FPA uses functional, logical entities such as outputs, inputs, and inquiries that tend to relate more closely to the functions (that is, business needs) performed by the software as compared to other measures, such as lines of code. FPA has become generally accepted as an effective way to
* estimate a software project's size (and in part, duration)
* establish productivity rates in function points per hour
* normalize the comparison of software modules
* evaluate support requirements
* estimate system change costs
In the world of Function Point Analysis, systems are divided into five large classes and general system characteristics. The first three classes or components are External Inputs, External Outputs and External Inquires. Now, each of these components transact against files and are hence called transactions. The next two classes, Internal Logical Files and External Interface Files are where data is stored that is combined to form logical information. The general system characteristics assess the general functionality of the system.
Details of each one of these:
1. Data Functions → Internal Logical Files: This contains logically related data that resides entirely within the application’s boundary and is maintained through external inputs.
2. Data Functions → External Interface Files: The second Data Function a system provides an end user is also related to logical groupings of data. In this case the user is not responsible for maintaining the data. The data resides in another system and is maintained by another user or system.
3. Transaction Functions → External Inputs: This is an elementary process in which data crosses the boundary from outside to inside. This data may come from a data input screen or another application. The data may be used to maintain one or more internal logical files. The data can be either control information or business information.
4. Transaction Functions → External Outputs: an elementary process in which derived data passes across the boundary from inside to outside. The data creates reports or output files sent to other applications.
5. Transaction Functions → External Inquiries: The final capability provided to users through a computerized system addresses the requirement to select and display specific data from files. To accomplish this a user inputs selection information that is used to retrieve data that meets the specific criteria. In this situation there is no manipulation of the data. It is a direct retrieval of information contained on the files.