Function Point Analysis (FPA) by Dr. B. J. Mohite

23
Activities During Software Project Management Size Estimation Cost Estimation Development Time Resources Requirements Project Scheduling By. Dr. B. J. Mohite 9850098225

Transcript of Function Point Analysis (FPA) by Dr. B. J. Mohite

Activities During Software Project Management

Size Estimation

Cost Estimation Development Time

Resources

Requirements

Project

Scheduling By. Dr. B. J. Mohite 9850098225

Process For Successful Projects

• Scope of work to be done

• The risk to be incurred

• The resources required

• The task to be achieved

• The cost to be expended

• The schedule to be followed.

Size Estimation

• IT is beginning step of estimation.

• Critical and difficult area of project planning.

• Difficult to establish units of size measuring.

• It is divided into two types like

1. LOC (Lines of Code)

2. Function Count

Lines Of Code

A line of code is any line of program text that

is not a comment or blank line, regardless of

the number of statements or fragments of

statements on the line. This specifically

includes all lines containing program header,

declarations, and executable and non-

executable statements.

Function Count

• Developed by Alan Albrecht in 1970 in IBM.

• Develop this technique is called as Function

Point Analysis.

• Used for problem size measurements.

• Function point measures functionality from

users point of view , that is , on the basis of

what the user requests and receives in return

from the system.

FUNCTION POINT ANALYSIS

FPA is decomposed into five functional units are

• Inputs: Information entering in the system

• Outputs: Information leaving in the system

• Enquiries: Request to access information

• Internal logical files: Information held within the system

• External interface files: Information held by other

systems that is used by the system being analyzed.

FPA’s fu ctio al u its

SYSTEM

OTHER

APPLICATION USER

EIF

USER

ILF INPUTS

OUTPUTS

ENQUIRIES

FPA’s functional units

Two categories of functional units

1. Data Function Types:

• Internal logical files(ILF): A user identifiable group of logically related data or control information maintained within system.

• External Interface files(EIF):A user identifiable group of logically related data or control information referenced by system,but maintained within another system .

(note: EIF counted for one system,ILF may be in another system)

Two categories of functional units

2. Transactional function Types

• External Input (EI): Process the data or control the

information that comes from the outside of the

system.

• External output (EO): Generates the data or control

information to be sent outside of the system.

• External Enquiry (EQ): Elementary process that is

made up of an input-output combination.

Counting function points

Functional units

Weighting factors

Low Average High

External Inputs (EI) 3 4 6

External Output (EO) 4 5 7

External Enquiries (EQ) 3 4 6

Internal Logical Files (ILF) 7 10 15

External Interface Files (EIF) 5 7 10

These function-point counts are then weighed (multiplied) by their degree of complexity:

Computing function points

Rate each factor on a scale of 0 to 5

Minimum Maximum Incidental Moderate Average Significant

0 1 2 3 4 5

UPF calculation table

Functional Units

Count Complexity

Complexity Totals

Functional unit totals

External inputs (EIs)

EI

External outputs(Eos)

EO

External enquiries EQs)

EQ

Internal logical files (ILFs)

ILF

External

Interface files

(EIFs)

EIF

Total unadjusted function point count

EXTERNAL INPUTS

Count Complexity

Complexity totals

FUNCTIONAL UNIT

TOTALS

LOW * 3 =

AVERAGE * 4 =

HIGH * 6 =

Back to UPF

EXTERNAL OUTPUTS

Count Complexity

Complexity totals

FUNCTIONAL UNIT

TOTALS

LOW * 4 =

AVERAGE * 5 =

HIGH * 7 =

Back to UPF

EXTERNAL ENQUIRIES

Count Complexity

Complexity totals

FUNCTIONAL UNIT

TOTALS

LOW * 3 =

AVERAGE * 4 =

HIGH * 6 =

Back to UPF

INTERNAL LIGICAL FILES

Count Complexity

Complexity totals

FUNCTIONAL UNIT

TOTALS

LOW * 7 =

AVERAGE * 10 =

HIGH * 15 =

Back to UPF

EXTERNAL INTERFACE FILES

Count Complexity

Complexity totals

FUNCTIONAL UNIT

TOTALS

LOW * 5 =

AVERAGE * 7 =

HIGH * 10 =

Back to UPF

Function Point Analysis

A simple example:

inputs

3 simple X 2 = 6

4 average X 4 = 16

1 complex X 6 = 6

outputs

6 average X 5 = 30

2 complex X 7 = 14

files

5 complex X 15 = 75

inquiries

8 average X 4 = 32

interfaces

3 average X 7 = 21

4 complex X 10 = 40

Unadjusted function points 240

Function Point Analysis

In addition to these individually weighted function points, there are factors that affect the project and/or system as a whole. There are a number (~35) of these factors that affect the size of the project effort, and each is ra ked fro 0 - o i flue ce to 5 - essential.

The following are some examples of these factors:

• Is high performance critical?

• Is the internal processing complex?

• Is the system to be used in multiple sites and/or by multiple organizations?

• Is the code designed to be reusable?

• Is the processing to be distributed?

• and so forth . . .

Function Point Analysis

Continuing our example . . . Complex internal processing = 3 Code to be reusable = 2 High performance = 4 Multiple sites = 3 Distributed processing = 5 Project adjustment factor = 17 Adjustment calculation: Adjusted FP = Unadjusted FP X [0.65 + (adjustment factor X 0.01)] = 240 X [0.65 + ( 17 X 0.01)] = 240 X [0.82] = 197 Adjusted function points

Function Point Analysis

But how long will the project take and how much will it cost?

• As previously measured, programmers in our organization average 18 function points per month. Thus . . .

197 FP divided by 18 = 11 man-months

• If the average programmer is paid $5,200 per month (including benefits), then the [labor] cost of the project will be . . .

11 man-months X $5,200 = $57,200

Function Point Analysis

Because function point analysis is independent of language used, development platform, etc. it can be used to identify the productivity benefits of . . .

• One programming language over another

• One development platform over another

• One development methodology over another

• One programming department over another

• Before-and-after gains in investing in programmer training

• And so forth . . .

Function Point Analysis

But there are problems and criticisms:

• Function point counts are affected by project size

• Difficult to apply to massively distributed systems or to systems with very complex internal processing

• Difficult to define logical files from physical files

• The validity of the weights that Albrecht established – and the consistency of their application – has been challenged

• Different companies will calculate function points slightly different, making intercompany comparisons questionable