UNIT-17FUNCTION POINTS

UNIT STRUCTURE17.1 Introduction and Review of Function Points17.2 Data in Motion17.3 Data at Rest 17.4 Function Point Extensions 17.4.1 Feature Point17.4.1 Object Point 17.4.2 3-D Function Points17.5 Advantages of Function Points 17.6 Methodology of Function Point Analysis to a software product

17.6.1 Determination of type of function point count17.6.2 Determination of the application boundary176.6.3 Components of Function Points17.6.3.1 Function types17.6.4 Determination of the Value Adjustment Factor

(VAF)17.6.5 Calculation of the adjusted function point count

• INTRODUCTION TO THE UNIT• This chapter covers the estimation of function points and their applications towards

software industry. The function point types and procedure is explained in detail. Further the calculation of the unadjusted function point count and function point is calculated using the value adjustment factor is also covered.

• UNIT LEARNING OBJECTIVES• After reading this chapter the learner will have a wide knowledge in estimation of

function points in particular towards the software products or projects. The components covered can give good scope for estimation. The following are the details of the function point component:

• Introduction and Review of Function Points• Data in Motion• Data at Rest • Function Point Extensions • Feature Point• Object Point • 3-D Function Points• Advantages of Function Points • Methodology of Function Point Analysis to a software product• Determination of type of function point count• Determination of the application boundary• Components of Function Points• Function types• Determination of the Value Adjustment Factor (VAF)• Calculation of the adjusted function point count

• 17.1 Introduction and Review of Function Points

• Function Point was developed by Albrecht (1979) at IBM in the late 1970’s. This is a method to break systems into smaller components, so that they can be understood and analyzed. It also provides a structured technique for problem solving. Function Point Analysis is very similar to completing a functional decomposition. Function Point measures software by quantifying its functionality provided to the user primarily based on the logical design.

• A relatively small number of factors have the greatest potential in affecting reliability, and recommendations are made for using these results to improve reliability of function point counting in organizations (Chris and Benjamin 1992). The Lines of Code Measure Checklist for the system definition, report forms and supplemental forms to support measurement definitions has been developed by Park (1992). Taghi et al (1992) have introduced two new estimation producers and compares their performance in terms of predictive quality and the quality of fit with more traditional least squares and absolute value estimation techniques. Several published statistical regression models that relate software development effort to software size measured in function points are available. Tridas and Sunder (1992) have suggested the use of the COCOMO and Function points based approach for early software cost estimation.

• To overcome the problems with the current methods for measuring function points that constrain the effective use of function point’s regression models a modification to the approach has been suggested which should enhance the accuracy of prediction models based on function points in the future (Jack et al 1994).

• Software cost estimation models are calibrated on data sets from a large air force database. The development effort accuracy of each model has been evaluated before and after calibration using a hold-out sample, or data not used in calibration. Results on a variety of data sets showed that calibrating the checkpoint model improved its accuracy for development effort. The accuracy of model was especially noteworthy on data sets that used function points as a measure of size (Karen et al 1997).

• David Longstreet (2002) has described that function points are a method to break systems into smaller components, so that can be better understood and analyzed. Function Points measure software by quantifying its functionality provided to the user based primarily on the logical design. Function Point counts to not depend on the source language used. It can be obtained early in the development cycle. Function Point counts are oriented toward the customers view rather than the producer’s view; this emphasis as the focus on value received rather than on the particular design that is employed. Function point counts are not equally applicable to all kinds of software. Although effective in business environments, they have not enjoyed wide spread success in embedded systems or heavily computational applications.

• Organizations can apply Function Point Analysis as:• 1. A tool to determine the size of a purchased application package by counting all the

• functions included in the package.• 2. A tool to help users to determine the benefit of an application package to their • organization by counting functions that specifically match their requirements. • 3. A tool to measure the units of a software product to support quality and

productivity • analysis. • 4. A vehicle to estimate cost and resources required for software development and

• maintenance.• On a conceptual level, Function point analysis helps to define two abstract levels of

data.• • Data in Motion• Data at Rest

• 17.2 Data in Motion• Data in Motion is handled via transactional function types or transactions. All software application

will have numerous elementary processes or independent processes to move data. Transactions (or elementary processes) that bring data from outside the application domain (or application boundary) to inside application boundary are referred to as external inputs. Transactions that take data from a resting position (normally on a file) to outside the application domain are referred to as either an external outputs or external inquiries.

• • 17.3 Data at Rest • Applications stored information for processing at a later time. Data at rest that is maintained by

the application in question is classified as internal logical files. Data at rest that is maintained by another application are classified as external interface files.

• • 17.4 Function Point Extensions • The concepts of Function Point Analysis can be used for any type of software project, and it is

consider most effective while sizing Management Information System applications. An extension is usable only if tested on a sufficiently large base of applications and suitably calibrated. The extensions of the Function Point Analysis are:

• 17.4.1 Feature Point• Feature Points is a method developed by Caper Jones (1988) at Software Productivity Research,

Inc. to apply function point logic to software such as system software, communication software, etc. Feature point extends the function points to include algorithms as a new class. An algorithm is defined as a set of rules, which must be completely expressed to solve a significant computational problem. For example, a square root routine can be considered as an algorithm. Each algorithm used is given a weight ranging from 1 (elementary) to 10 (sophisticated algorithms) and the future point is the weighted sum of the algorithms plus the function points. This measurement is especially useful for system with few input/output and high algorithmic complexities, such as mathematical software, discrete simulations, and military applications.

• • Another extension of function points is Full Function Point (FFP) used for measuring real-time

applications, by also taking into consideration the control aspect of such applications. FFP introduces two new control data function types and four new control transaction function types.

• Object Point • While future point and FFP extend the function point, the object point

(Pfleeger 1989) measures the size from a different dimension. This measurement is based on the number and complexity of the following objects such as screens, reports and 3GL (Generation language) components. Each of these objects is counted and given a weighted sum of all these objects. This is a relatively new measurement and it has not been very popular. But because it is easy to use at the early phase of the development cycle and also measures software size reasonably well, this measurement has been used in major estimation models such as COCOMO II.

• 3-D Function Points• 3-D function points (Whitmire 1992) were proposed in the internal paper

at the Boeing Company and published in 1992 at the Pacific Northwest Software Quality Conference. It addresses the problem of applying function points to scientific and real-time applications. The model uses three dimensions to measure-data, function and control. Transformation and algorithms are counted for using the “function” dimension, while changes to the state of the application are handled by the “control” dimension. It has also been claimed that the model is suitable for object oriented development.

•

• 17.5 Advantages of Function Points • Function points offer several significant advantages over lines of code counts:• • It is possible to estimate them early in the life cycle, at the time of the requirements definition.• They avoid the effects of language and other implementation differences.• It is easier to demonstrate to the sponsor the impact of a seemingly little change to the

requirements has on the project.• The function point count is a good basis for a quality measure. The number of bugs per function

point is more meaningful than the number of bugs per 1,000 lines of code.• Function points can also be more useful in measuring programmer productivity.• The average number of function points produced per day is more meaningful than the average

number of lines of code produced per day because the latter will depend on Programming language and programming style. Proponents maintain that an early function point analysis based on a project’s initial requirements definition can give developers a good first-pass estimate of its size. However, that estimate may vary by as much as plus or minus 35% or more. Because the function point counts are based on features of the system to be developed, estimates made before the logical design are really of little value. However, the accuracy improves to about 10% by the time development reaches the design definition stage.

• Counting function point is not a trivial matter. Evaluating each function point for its correct complexity and size can be quite laborious. It is easy to undercount functions, and the error can have a ripple effect on the calculations. Analysts who are expected to perform FPA require extensive training. Until they become experienced, an experienced consultant or other FPA expert should assist them.

• There are many excellent tools to help automate FPA. MicroMan Esti-Mate, first CASE, size plus and Project Bridge are just a few of the many software development project estimating tools in the market today that incorporate some type of FPA. There are also a number of organizations dedicated to the promotion and use of Function Points. The advantage of the function-point measurement is that it can be obtained based on the system requirement specification in the early stage of software development of FPA.

• 17.6 Methodology of Function Point Analysis to a software product

• Function point analysis applicable to a software product consists of the following steps (IFPUG 1999)

• 1. Determination of type of function point count.• 2. Determination of the application boundary.• 3. Identify the components of Function Points.• (a) Identify and rate data function types to

determine their contribution to the unadjusted function point count.• (b) Identify and rate transactional function

types to determine their contribution to the unadjusted function point count.

• 4. Determination of the value adjustment factor (VAF).• 5. Calculate the adjusted function point count.• The schematic diagram (Figure 4.1) shows the procedure to

determine the function point count in a software project.

Determine type of count

Identify scope and application

boundary

Count data

Count transaction

Determine VAF

Determine Unadjusted

Function Point Count

Calculate Adjusted Function

Point Count

Figure 17.1 Function Point Analysis Procedure

• 17.6.1 Determination of type of function point count• Function point counts can be associated with either projects or

application software. There are 3 types of function point counts.• (a) Development project function point count• Function points can be counted at all phases of a development

project from requirements up to and including implementation. This type of count is associated with new development work.

• (b) Enhancement project function point count• It is common to enhance software after it has been placed into

production. This type of function point count tries to determine the size of enhancement projects.

• (c) Application function point count• Application counts are done on existing production applications.

This ‘base like count’ can be used with overall application metrics like total maintenance hours.

• 17.6.2 Determination of the application boundary• The boundary indicates the border between the project or

application being measured and the external applications or user domain. The application boundary is identified by the following:

• Review the purpose of the function point count• Look at how and which applications maintain data• Identify the business areas that support the applications

• 17.6.3 Components of Function Points• 17.6.3.1 Function types• Function Point Analysis defines data as Data in Motion or Transactional function types and Data at

Rest or Data Function types. Transactional function types include External Inputs, External Outputs and External Inquiries. Data Function types include Internal Logical Files and External Interface Files.

• (a) Internal Logical Files (ILF)• An ILF is a user identifiable group of logically related data or control information maintained within the

boundary of the application. The primary intent of an ILF is to hold data maintained through one or more elementary processes of the application being counted.

• (b) External Interface Files (EIF)• An 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. The primary intent of an EIF is to hold data referenced through one or more elementary processes within the boundary of the application counted.

• (c) External Inputs (EI)• An EI is an elementary process that processes data or control information that comes from outside

the application’s boundary. The primary intent of an EI is to maintain one or more ILFs and/or to alter the behavior of the system.

• (d) External Outputs (EO)• An EO is an elementary process that sends data or control information outside the application’s

boundary. The primary intent of an external output is to present information to the user through processing logic other than or in addition to the retrieval of data or control information. The processing logic must contain at-least one mathematical formula or calculation, or create derived data.

• (e) External Inquiries (EQ)• An EQ is an elementary process that sends data or control information outside the application

boundary. The primary intent of an external inquiry is to present information to a user through the retrieval of data or control information. The processing logic contains no mathematical formula or calculation, and creates no derived data.

• To determine the complexity and the contribution of the Data and Transactional Function types the following terms need to be defined:

• (i) Record Element Type (RET): A RET is user recognizable sub group of data elements within an ILF or an EIF. Logical grouping of data help to identify them.

• (ii) File Type Referenced (FTR): A FTR is a file type referenced by a transaction. An FTR must also be an ILF or EIF.

• (iii) Data Element Type (DET): A DET is a unique user recognizable, non-recursive (non-repetitive) field.

• 17.6.4 Determination of the Value Adjustment Factor (VAF)• The VAF indicates the general functionality provided to the user for the

application. The VAF comprises of 14 general system characteristics that assess the general functionality of the system. Each characteristic has associated description that helps to determine the degree of influence of the characteristics. The degrees of influence range on a scale of 0 to 5, from no influence to strong influence. Appendix 2 (Figure A2.8) shows the details of estimating VAF.

• 17.6.5 Calculation of the adjusted function point count• The adjusted function point count is calculated using specific formulae for

development, enhancement and application function point counts. The final function point count is obtained by multiplying the VAF with the Unadjusted Function Point (UAF). The function point equation is given by.

•• FP = UAF x VAF

(1) • where,• FP = Adjusted Point Count• UAF = Unadjusted Function Points• VAF = Value Adjustment Factor • = 0.65 + 0.01 Ci • Ci = Rating of the ith general system characteristic

Table 17.1 Rating of general system characteristics

S No System Characteristics Rating

1. Data Communications 3

2. Distributed Data Processing 2

3. Performance 2

4. Heavily Used Configuration 2

5. Transaction Rate 3

6. On-line data entry 0

7. End User Efficiency 4

8. On-line Update 4

9. Complex Processing 3

10. Reusability 5

11. Installation Ease 1

12. Operational Ease 5

13. Multiple Sites 0

14. Facilitate Change 4

• Summary• This chapter has covered the in-depth in function point definition,

methodology, applications, and determination of function point count to software industry. The reader will a very good scope and knowledge in estimation of function points.

• Review Questions• 1. Highlight the various contributions of function points in the estimation of

software products.• 2. Define data in motion and rest. • 3. Explain in detail about the Function Point Extensions with suitable

example?• 4. List out the advantages of Function Points? • 5. Describe the methodology of Function Point Analysis to a software

product?• 6. Explain the determination of type of function point count?• 7. How will you determine the application boundary in function points?• 8. What are the Components of Function Points?• 9. Explain the Function types of function points?• 10. Briefly explain the determination of the Value Adjustment Factor (VAF)?• 11.How will you calculate the adjusted function point count?

• References• 1. Caper Jones (1988), ‘A Short history of Function Points and

Features Incorporated’, Mimeo Version, 2.0.• 2. Danfeng Hong, ‘Software Cost Estimation’, Department of

Computer Science, University of Calgary.• http://pages.cpsc.ucalgary.ca/~hangd/SENG/621/

report.html.• 3. IFPUG. (1999), ‘Function Point Counting Practices Manual:

Release 4.1’, Counting Practices Committee. • http://

www.carfield.com.hk/document/software.engine/fpa.pdt.• 4. Tong (Leo) Chen, Harprit Grewal and Jerrall Prakash,

(2003), ‘Software Cost Estimation’, SENG 621 9W03, Dept of Computer Science, University of Calgary

• 5. Tridas Mukhopadhyay and Sunder Kekre (1992), ‘Software Effort Models for early estimation of process control applications’, IEEE Transactions on Software Engineering, Vol.18, No.10.