Function Points

1. Function Points Addams England 2/23/2004 CIS 6516 Dr. Roggio

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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.

8. 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

9. 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

10. 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 user’s external view of the system, non-technical users of the software system have a better understanding of what function points are measuring

11. 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)

12. 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

13. 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

14. 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

15. 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

16. 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

17. Function Point Counting Diagram

18. Early Counting Steps • Determine the type of function point count • Development project • Enhancement project • Application • Identify the counting scope and application boundary

19. Determine the Unadjusted Function Point Count • The unadjusted function point count (UFP) reflects 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 • Transactional Functions • External Inputs • External Outputs • External Inquiries

20. 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

21. Count Data Functions…

22. Count Data Functions…

23. 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 application’s boundary • An external output (EO) is an elementary process that sends data or control information outside the application’s 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)

24. 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

25. Data Communications Distributed Data Processing Performance Heavily Used Configuration Transaction Rate Online Data Entry End-User Efficiency   Online Update Complex Processing Reusability Installation Ease Operational Ease Multiple Sites Facilitate Change Value Adjustment Factor 14 Characteristics

26. Degrees of Influence • 0 Not present, or no influence • 1 Incidental influence • 2 Moderate influence • 3 Average influence • 4 Significant influence • 5 Strong influence throughout

27. 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

28. 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

29. 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

30. 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

31. Development Project Function Point Count Example

36. 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

37. 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 program’s 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