8

Project Management Estimation Methods – Function Point

Posted by mgocean on May 27, 2009 in Estimation, Project Management |

Almost all engineering disciplines depend on the basic premise of being able to measure the various parameters with which that specific branch of engineering deals. For example, civil engineers can measure various civil structures using the metric system of measurement; electrical engineers can measure through units like watts, volts, amperes, etc.; and mechanical engineers measure outputs through joules, horse power, and other measuring scales. But software engineering is relatively young and we are yet to arrive at a well-defined and universally acceptable unit of measurement for all software systems. Perhaps function points is the nearest to becoming a universal unit of measuring software systems, based on the business functions delivered by the application. Lines-Of-Code is a very poor alternative. (Parthasarathy, M. A. , 2007)

 

Function point analysis was developed to enable an individual with minimal programming experience and knowledge to estimate the size of a software development project. Using function point analysis, an estimator can determine a project’s size simply by analyzing its functional requirements which are analogous to a specification in a project to identify function points. A function point is a measure of software functionality based on the counted or estimated number of externals inputs, outputs, and interfaces of a system plus the estimated number of its internal files. Therefore, given the focus on what the system does functionally, the size of the effort can be estimated without having knowledge of how technical software should be developed to provide the functionality. Function points are divided into five categories:

1. External interfaces occur when a software system passes information to or receives information from any entity outside its boundaries. A distinguishing feature of infrastructure system software is the large number of external interfaces required to integrate the software with sensors and field devices. An example of an external interface in the VDOT ITS system is the code required to monitor and poll traffic detectors.

2. User inquires require immediate response from an operator in the form of prompts, interrupts, or calls. Common user inquiries in infrastructure system software include system alarms to alert operators that sensors indicate an unexpected condition. In the VDOT ITS software example, a user inquiry occurs when the software issues a possible incident alarm when vehicle detectors report abnormally low traffic speeds.

3. User outputs are data or files presented to a user after system processing is completed. System status reports are common in infrastructure system software. For example, these are often used to direct maintenance activities. A report of failed field devices ~such as vehicle detectors, dynamic message signs, etc.! is a user output in the VDOT ITS system.

4. User inputs are data or files that come into a system and require processing. Given the control/monitoring charge of most infrastructure system software, user inputs are often required to confirm that an operator has responded to a particular alarm. User inputs occur in the VDOT ITS system when operators enter information describing an accident that is reported by an outside source such as the police.

 

5. Internal interfaces occur when a system passes information to or receives information from within the system boundaries. Given the high reliance on databases in infrastructure system software, internal interfaces play a major role. For example, an internal interface occurs in the VDOT ITS system when a predefined message is retrieved from the database to display on a dynamic message sign. (Smith B. L., 2002, pp: 104 – 110)

Components of an application

 

Source: (Parthasarathy, M. A., 2007)

 

To complete the estimate of the software’s size, it is necessary to convert from function points to lines of code. Table 4‑5 contains accepted conversion factors used in software estimation tools, such as COCOMO. The contractor was required to develop the code in the American National Standards Institute’s ANSI’s! C11. Therefore, the lines of code conversion proceed as follows:

 

Function Point to Lines of Code Conversion – Jones 1998

Language

Source statements per function point

Assembler

320

C

150

FORTRAN

105

C11

53

SQL

12

 

 

 

 

COCOMO Complexity Weighting Factors

Function point category

Complexity Weights

Low Medium High
External interface

5

7

10

Internal interface

5

7

10

User inquiry

3

4

6

User output

4

5

7

Internal files

7

10

15

User input

3

4

6

 

(Smith B. L., 2002, pp: 104 – 110)

 

The following list introduces some of the direct uses and benefits that can be derived out of the Function Point Analysis method:

  • Because the FP count is technology independent, it can be effectively used and reused for sizing a wide variety of software applications.
  • Many other metric collection processes are well enabled by measures that are referenced to FP as a base. For example, productivity is measured as FP per person month, defect density per 1000 FP, and cost per FP.
  • Project schedules are better evaluated based on the number of FP that can be best delivered in a given timeframe.
  • Some of the software project contracts (RFP) are based on expected FP to be delivered. The dollars per FP is a measuring scale in these contracts.
  • Scope creep (increase in scope) during project execution is better measured and trapped using FP as a sizing tool.
  • Converting the FP count of a software project into total effort is simple, based on the productivity of the project team on the technology platform.

(Parthasarathy, M. A., 2007)

 

 

 

Objectives of developing the FPA method can be listed as;

  • Design an estimation method that was fairly easy to understand, both by the business users of the software as well as the developers.
  • Keep learning time to a minimum; ensure that repeated usage quickly builds expertise.
  • Make sure the estimated outputs generated through the FPA method are reliable and consistent. It was expected that sizing of existing applications would be within ±10% of actual size and for fresh development projects it would be within ±20% of the final product size.
  • Enable the estimated output (size) to be utilized to derive project effort in any technology because the method is independent of technology platform. The productivity on the selected technology would drive the overall effort figures.
  • Assure that verification of the output function points could be done by an independent, experienced assessor.

(Parthasarathy, M. A., 2007)

A quick overview of the function point process is:

  1. Count the functions in each category (categories are: outputs, inputs, inquiries, data structures, and interfaces).
  2. Establish the complexity of each—simple, medium, complex.
  3. Establish weights for each complexity.
  4. Multiply each function by its weight and then sum up to get total function points.
  5. Convert function points to LOC using the formula:

LOC = Points x ADJ x Conversion factor

where ADJ is an adjustment for the general characteristics of the application.

The conversion factor, based on historical experience for the application and programming language, represents the average number of lines of code to implement a simple function. The last step is done because most automated tools that estimate effort, cost, and schedule require LOC as input.

Figure 4‑9 Basic Steps in Function Point AnalysisFigure 4‑9 shows the basic steps in counting function points; each will be described later. Each step has an output that is used in the next step. Table 4‑7 shows the input, transformation, and output of each step in FP counting. This worksheet is left blank, as a template for your future use.

 

Basic Steps in Function Point Analysis

Source: (Futrell R.T., Shafer D.F. & Safer L. I., 2002)

 

 

Function Point Analysis Worksheet

Step 1. Count Number of Functions in Each Category
Step 2. Apply Complexity Weighting Factors

Simple Average Complex

Function Points

Number of Outputs ____ x 4 ____ x 5 ____ x 7

Number of Inputs ____ x 3 ____ x 4 ____ x 6

Number of Inquiry Outputs ____ x 4 ____ x 5 ____ x 7

Number of Inquiry Inputs ____ x 3 ____ x 4 ____ x 6  
Number of Files ____ x 7 ____ x 10 ____ x 15  
Number of Interfaces ____ x 5 ____ x 7 ____ x 10  

Total (FP):

Step 3. Apply Environmental Factors

Environmental Factor

Rating (0, 1, 2, 3, 4, 5)

Data Communications  
Distributed Computing  
Performance Requirements  
Constrained Configuration  
Transaction Rate  
Online Inquiry and/or Entry  
End-User Efficiency  
Online Update  
Complex Processing  
Reusability  
Ease of Conversion/Install  
Ease of Operation  
Used at Multiple Sites  
Potential for Function Change  

Total (N):

Step 4. Calculate Complexity Adjustment Factor (CAF)
CAF = 0.65 + (0.01 x N) =
Step 5. Compute Adjusted Function Points (AFP)
AFP = FP (Raw) x CAF =
Step 6. Convert to LOC (Optional)
LOC = AFP x LOC/AFP =

 

 

 

 

Conversion from Programming Language to Basic Assembler SLOC to SLOC per Function Point

Language

Basic Assembler SLOC (Level)

Average SLOC per Function Point

Basic Assembler

1

320

Autocoder

1

320

Macro Assembler

1.5

213

C

2.5

128–150

DOS Batch Files

2.5

128

Basic

3

107

LOTUS Macros

3

107

ALGOL

3

105–106

COBOL

3

105–107

FORTRAN

3

105–106

JOVIAL

3

105–107

Mixed Languages (default)

3

105

Pascal

3.5

91

COBOL (ANSI 85)

3.5

91

RPG

4

80

MODULA-2

4.5

80

PL/I

4.5

80

Concurrent PASCAL

4

80

FORTRAN 95

4.5

71

BASIC (ANSI)

5

64

FORTH

5

64

LISP

5

64

PROLOG

5

64

LOGO

5.5

58

Extended Common LISP

5.75

56

RPG III

5.75

56

C++

6

53

JAVA

6

53

YACC

6

53

Ada 95

6.5

49

CICS

7

46

SIMULA

7

46

Database Languages

8

40

CLIPPER DB and dBase III

8

40

INFORMIX

8

40

ORACLE and SYBASE

8

40

Access

8.5

38

DBase IV

9

36

FileMaker Pro

9

36

Decision Support Languages

9

35

FOXPRO 2.5

9.5

34

APL

10

32

Statistical languages (SAS)

10

32

DELPHI

11

29

Object-Oriented Default

11

29

OBJECTIVE-C

12

27

Oracle Developer/2000

14

23

SMALLTALK

15

21

awk

15

21

EIFFEL

15

21

UNIX Shell Scripts (PERL)

15

21

4th Generation Default

16

20

Application Builder

16

20

COBRA

16

20

Crystal Reports

16

20

Datatrieve

16

20

CLIPPER

17

19

Database Query Languages (SQL)

25

13–16

HTML 3.0

22

15

Information Engineering Facility (IEF)/Information Engineering Workbench (IEW)

23

14

EASYTRIEVE+

25

13

SQL (ANSI)

25

13

Spreadsheet Languages (EXCEL)

50

6

QUATTRO PRO

51

6

Graphic Icon Languages

75

4

 

(Futrell R.T., Shafer D.F. & Safer L. I., 2002)

The confidence level of Function Point Analysis is higher than other methods. Function points are independent of the programming language, methodologies or tools used for implementation. Also non-technical users have better understanding of what function points are measuring because function points are based on the user’s external view of the system.

 

There are also some disadvantages or risks of Function Point Method. The method depends on subjective weight given by the estimator. The method needs a trained person to do. The manual process of counting function points needed is a large process. Also the measuring rules and business logic is more complex than other estimation methods.

 

Function points are not a very good measure when sizing maintenance efforts (fixing problems) or when trying to understand performance issues. Much of the effort associated with fixing problems (production fixes) is due to trying to resolve and understand the problem (detective work). Another inherent problem with measuring maintenance work is that much of maintenance programming is done by one or two individuals. Individual skill sets become a major factor when measuring this type of work. The productivity of individual maintenance programmers can vary as much as 1,000 percent. Performance tuning may or may not have anything to do with functionality. Performance tuning is more a result of trying to understand application throughput and processing time. There are better metrics to utilize when measuring this type of work. (Longstreet D., 2008)

 

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

8 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

Copyright © 2006-2019 Güzel Blog All rights reserved.
This site is using the Desk Mess Mirrored theme, v2.0.3, from BuyNowShop.com.