Function Points

Addams England Click to edit Master subtitle style 2/23/2004 CIS 6516 Dr. Roggio

Overview

Introduction Function Point History Function Point Variations Problems with Lines of Code What are Function Points? Objectives of Function Points How do Function Points Overcome LOC Problems? Uses of Function Points When Should You Count Function Points? Who Should Count Function Points? Function Point Counting Function Point Counting Example References

Introduction
Increasingly important facet of software development is the

ability to estimate the associated cost of development early in the development process Estimating software size is a difficult problem that requires specific knowledge of the system functions in terms of Scope Complexity Interactions Most frequently cited sources of software size metrics are Lines of code Function point analysis

Function Point History

Developed by Allan Albrecht in the late 1970s while

working at IBM The function point technique was refined and a counting manual was produced by IBM's GUIDE organization in the early 1980s The International Function Point Users Group (IFPUG) was founded in the late 1980s and produced its own Counting Practices Manual In 1994, IFPUG produced Release 4.0 of its Counting Practices Manual The Function Point Counting Practices Manual 4.1 was released in 1999

Function Point Variations

Mk II Function Points Discovered weaknesses in Albrecht's approach Feature Points Function points were not working for all classes of applications 3D Function Points Designed to solve two problems with Albrecht approach

Problems with Lines of Code

Lack of a universally accepted definition for

exactly what a line of code is Language dependence (high-level versus low-level programming languages) It is difficult to estimate the number of lines of code that will be needed to develop a system from information that is available in analysis and design phases Lines of code places all emphasis on coding, which is only part of the implementation phase of a software development project

Why IFPUG Thinks You Should Not Use LOC?

Lines of code tend to reward profligate design and

penalize concise design There is no industry standards (ISO or otherwise) for lines of code Lines of code cannot be used for normalizing across platform, language or by organization Some 4GL do not even use lines of code Lines of code can be positively misleading refer to Capers Jones Productivity Paradox.

What Are Function Points?

Function Points measure software size by

quantifying the functionality provided to the user based solely on logical design and functional specifications Function point analysis is a method of quantifying the size and complexity of a software system in terms of the functions that the system delivers to the user It is independent of the computer language, development methodology, technology or capability of the project team used to develop the application

What Are Function Points?

Function point analysis is designed to

measure business applications (not scientific applications) Scientific applications generally deal with complex algorithms that the function point method is not designed to handle

How Do Function Points Overcome LOC Problems?

Function points are independent of the language,

tools, or methodologies used for implementation (ex. Do not take into consideration programming languages, DBMS, or processing hardware) Function points can be estimated early in analysis and design Since function points are based on the system users external view of the system, non-technical users of the software system have a better understanding of what function points are measuring

Uses of Function Points

Measure productivity (ex. Number of function points

achieved per work hour expended) Estimate development and support (cost benefit analysis, staffing estimation) Monitor outsourcing agreements (Ensure that the outsourcing entity delivers the level of support and productivity gains that they promise) Drive IS related business decisions (Allow decisions regarding the retaining, retiring and redesign of applications to be made) Normalize other measures (Other measures, such as defects, frequently require the size in function points)

Why IFPUG Says We Should Use Function Points?

You cannot manage internally what you do not

measure Approximately 40% of all projects fail due to lack of management control (Coopers & Lybrand Sept. 1995) Measurement gives you a tool to communicate to your customers the size of their request, and extrapolate productivity, quality and estimating accuracy Many competitors may already have these insights You measure to understand and improve your processes

Objectives of Function Point Counting

Measure functionality that the user requests

and receives Measure software development and maintenance independently of technology used for implementation Simple enough to minimize the overhead of the measurement process A consistent measure among various projects and organizations

When Should You Count Function Points?

Early and often The sooner you can quantify what a project is

delivering, the sooner it is under control Under IFPUG 4.1, there are rules and guidelines that make it possible to count function points once the requirements have been finalized During requirements gathering the estimate of size in function points can be refined continuously Function points should be recounted throughout the development process and counts can be compared to measure scope creep and breakage

Who Should Count Function Points?

Recommended: One day class and on-the-job

training by an experienced counter Technical people have long been the main function point counters Senior level users can also be trained to count function points For a large organization, a small group involved with function point counting and other estimating activity is ideal

Count frequently enough to stay current with the rules Independent of the projects/ less biased feedback Consistent counting and help from other group members

Function Point Counting Steps

Determine the type of function point count Identify the counting scope and application

boundary Determine the Unadjusted Function Point Count Count Data Functions Count Transactional Functions Determine the Value Adjustment Factor Calculate the Adjusted Function Point Count

Function Point Counting Diagram

Early Counting Steps

Determine the type of function point count Development project Enhancement project Application Identify the counting scope and application

boundary

 The unadjusted function point count (UFP) reflects

Determine the Unadjusted Function Point Count

the specific countable functionality provided to the user by the project or application. The UFP calculation is broken into two categories with five sub-categories:

Data Functions

Internal Logical Files External Interface Files External Inputs External Outputs External Inquiries

Transactional Functions

Count Data Functions

Data functions represent the functionality provided to the

user to meet internal and external data requirements Data functions are either internal logical files or external interface files. An internal logical file (ILF) is a user identifiable group of logically related data or control information maintained within the boundary of the application An external interface file (EIF) is a user identifiable group of logically related data or control information referenced by the application, but maintained within the boundary of another application Assign each identified ILF and EIF a functional complexity based on the number of data element types (DETs) and record element types (RETs) associated with the ILF or EIF

Count Data Functions

Count Data Functions

Count Transactional Functions

Transactional functions represent the functionality provided to the

user to process data Transactional functions are either external inputs, external outputs, or external inquiries An external input (EI) is an elementary process that processes data or control information that comes from outside the applications boundary An external output (EO) is an elementary process that sends data or control information outside the applications boundary An external inquiry (EQ) is an elementary process that sends data or control information outside the application boundary Assign each identified EI, EO and EQ a functional complexity based on the number of file types referenced (FTRs) and data element types (DETs)

Determine the Value Adjustment Factor

The value adjustment factor (VAF) indicates the

general functionality provided to the user of the application The VAF is comprised of 14 general system characteristics (GSCs) that assess the general functionality of the application Each characteristic has associated descriptions that help determine the degree of influence of the characteristic The degrees of influence range on a scale of zero to five, from no influence to strong influence

Value Adjustment Factor 14 Characteristics

Data Communications Online Update Distributed Data Processing Complex Processing Performance Reusability Heavily Used Configuration Installation Ease Transaction Rate Operational Ease Online Data Entry Multiple Sites End-User Change Facilitate Efficiency

Degrees of Influence
0 1 2 3 4 5

Not present, or no influence Incidental influence Moderate influence Average influence Significant influence Strong influence throughout

Procedures to Determine the VAF

Evaluate each of the 14 general system characteristics on a

scale from zero to five to determine the degree of influence (DI) Add the degrees of influence for all 14 general system characteristics to produce the total degree of influence (TDI) Insert the TDI into the following equation to produce the value adjustment factor. VAF = (TDI * 0.01) + 0.65 For example, the following value adjustment factor is calculated if there are three degrees of influence for each of the 14 GSC descriptions (3*14) VAF = (42 * 0.01) + 0.65 VAF = 1.07

Calculate the Adjusted Function Point Count

The adjusted function point count is

calculated using a specific formula for a development project, enhancement project, or application (system baseline) function point count

Development Project Function Point Calculation

The development project function point

calculation consists of three components of functionality:

Application functionality included in the user requirements for the project Conversion functionality included in the user requirements for the project Application value adjustment factor

Development Project Function Point Calculation

Development project function point formula DFP = (UFP + CFP) * VAF DFP is the development project function point count UFP is the unadjusted function point count for the functions that will be available after installation CFP is the unadjusted function points added by the conversion unadjusted function point count VAF is the value adjustment factor

Development Project Function Point Count Example

Conclusions
Function point analysis is a method of

quantifying the size and complexity of a software system in terms of the functions that the system delivers to the user

Function point analysis is a complex process that

provides many benefits if it can be implemented correctly Function point analysis has been around since the late 1970s and is still used by many organizations today

References
http://www.ifpug.org Function Point Counting Practices Manual Release 4.1, The International

Function Point Users Group, 1999. http://www.carfield.com.hk/document/software_engine/fpa.pdf Matson, Jack E., Barrett, Bruce E., Software Development Cost Estimation Using Function Points, IEEE Transactions on Software Engineering, Volume 20, No. 4, April 1994. Furey, Sean, Why We Should Use Function Points, IEEE Magazine, March/April 1997, pp.28-31. Orr, George, Reeves, Thomas E., Function point counting: one programs experience, The Journal of Systems and Software, Volume 53, 2000, pp.239-244. Jeffery, D.R., Low, G.C., A Comparison of Function Point Counting Techniques, IEEE Transactions on Software Engineering, Volume 19, No. 5, May 1993. Probasco, Leslee, Dear Dr. Use Case: What About Function Points and Use Cases?, The Rational Edge e-zine, 2002. http://ourworld.compuserve.com/homepages/softcomp/fpfaq.htm http://www.qpmg.com/fp-intro.htm http://www.ifpug.com/fpafund.htm