Top Banner
Function Point Analysis
62
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Function Point Analysis

Function Point Analysis

Page 2: Function Point Analysis

2

Why Estimate?

A software project estimate, predicts the size of a new project, or the amount of effort required to complete the project

An estimate is a prediction based on probabilistic assessment

Page 3: Function Point Analysis

3

Factors of Wrong Estimation

Lack of formal process Person dependent estimation Inadequate or imprecise and changing

requirements Project contract is determined by

commercial or political interests There is a natural human tendency to

underestimate

Page 4: Function Point Analysis

4

Sizing Measures

KLOC FP Classes Objects Screens Reports …

Page 5: Function Point Analysis

5

Problems with KLOC as UoM

Higher level languages produce less LOC Better programming produce less LOC Actual LOCs are known too late to be

used for estimation No consistent method to count LOC

especially between languages

Page 6: Function Point Analysis

6

What is Function Point? Is a structured technique to classifying

components of a system Is a method to break systems into smaller

components, so they can be better understood and analyzed

Measures software by quantifying its functionality provided to the user based primarily on the logical design

A standard method for measuring software development from the customer point of view

Logical Functionality from a Sophisticated User view rather than a physical view

Page 7: Function Point Analysis

7

Brief History of FPA

Developed by Alan Albrecht at IBM in the late 1970’s

Grew out of an interest in the general problem of measuring productivity in systems development

The Function Point was created as an alternative to estimating KLOC

Function points exist at a more macro level than KLOC and rely on capturing information such as the number of input transaction type and the number of unique reports to be generated

Page 8: Function Point Analysis

8

Function Point Counting Process

Function point analysis follows specific steps for counting: Identification of the subsystem boundaries

Identification of the data functions (internal logical files and external interface files)

Identification of transactional functions (external inputs, external outputs and external inquiries)

Calculation of the Unadjusted Function Point (UAF) Count

Determination of the Value Adjustment Factor (VAF) using General System Characteristics (GSC)

Calculation of the final Function Point Count

Page 9: Function Point Analysis

9

Components of Function Points

Data Function Points Internal Logical Files (ILF) External Interface Files (EIF)

Transaction Function Points External Input (EI) External Output (EO) External Inquiry (EQ)

Page 10: Function Point Analysis

10

Application Boundaries

Human Resource

Application

User 1 User 1

New EmpInformation

(EI)

Employee Record(EO)

Request and DisplayEmp. Info.

(EQ)

Background Check(EIF)

Emp. Info. (ILF)

User 1

Page 11: Function Point Analysis

11

Definitions

Record Element Type (RET) - A RET is user recognizable sub-group of data elements within an ILF or an EIF. It is best to look at logical groupings of data to help identify them

Data Element Type (DET) - A DET is an unique user recognizable, non-recursive fields

File Type Referenced (FTR) - A FTR is a file type referenced by a transaction. An FTR must either be Internal Logical File or an External Interface File

Page 12: Function Point Analysis

12

Page 13: Function Point Analysis

13

Data Function Points

ILF – Internal Logical Files EIF – External Interface Files

Two inputs required RET – Record Element Type DET – Data Element Type

Page 14: Function Point Analysis

14

External Inputs

• Data crosses from Outside to inside

• Data may come from a data input screen or another application

• The data may be used to maintain one or more internal logical files.

• The graphic represents a simple EI that updates 2 ILF's (FTR's).

Page 15: Function Point Analysis

15

EI - External Input It is an elementary process that processes data or

control information that comes from outside the application boundary

The primary intent of an EI is to maintain one or more ILFs and / or to alter the behavior of the system

Each EI will maintain atleast one ILF Transactions are not be confused with file data

Transactions that cause the application files to change are counted as inputs, while files belonging to another application such as master files are not EIs.

Page 16: Function Point Analysis

16

EI – Identification Rules Each unique class of batch transaction is counted as 1

input type, even if many different classes come inside one file structure. These could be different record formats.

Add, modify and Delete will be 3 inputs Don’t count multiple occurrences of the same unique

logical data item more than once, eg. Repeating rows on a screen

Count data items not displayed but created as a result of input (error messages, confirmation messages, calculated fields etc)

Don’t count static information such as constants, screen prompts etc

Page 17: Function Point Analysis

17

External Outputs

• Derived data crosses from inside to outside

• Data creates reports or output files sent to other applications.

• These reports and files are created from one or more internal logical files and external interface file.

• The graphic represents a simple EO with two FTRs.

Page 18: Function Point Analysis

18

EO – External Output

It is an elementary process that sends data or control information outside the application boundary

The primary intent of an EO is to present information to a user through processing logic other than, or in addition to, the retrieval of data or control information

Derived data is the data that is processed beyond direct retrieval and editing of information from ILF or EIF

Page 19: Function Point Analysis

19

EO – Identification Rules The processing logic must contain atleast one

mathematical formula or calculation or create derived data

It may create report of output files to be sent to another application

It uses atleast one ILF or EIF Each unique batch transaction type being sent to another

application is counted as 1 type Each medium output is counted as 1 EO Multiple occurrences of the same unique logical data item

are not be counted more than once (repeating rows) Static information or system generated information like

report headings, data / time stamps, automatic page numbers are not counted

Page 20: Function Point Analysis

20

External Inquiries

• An elementary process with both input and output components that result in data retrieval from one or more internal logical files and external interface files.

• The input process does not update any Internal Logical Files, and the output side does not contain derived data.

• The graphic below represents an EQ with two ILF's and no derived data.

Page 21: Function Point Analysis

21

EQ – External Inquiry

It 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 from an ILF or EIF

Page 22: Function Point Analysis

22

EQ – Identification Rules

An EQ is made up of input and output It requests immediate retrieval of data and

does not result in any updates of ILF EQ may use one or more ILF / EIF An EQ can not have calculated or derived

data No ILF is maintained in the process

Page 23: Function Point Analysis

23

Unadjusted FP

After the components have been classified as one of the five major components (EI’s, EO’s, EQ’s, ILF’s or EIF’s), a ranking of low, average or high is assigned. For transactions (EI’s, EO’s, EQ’s) the ranking is based upon the number of files updated or referenced (FTR’s) and the number of data element types (DET’s).

For both ILF’s and EIF’s files the ranking is based upon record element types (RET’s) and data element types (DET’s). A record element type is a user recognizable subgroup of data elements within an ILF or EIF. A data element type is a unique user recognizable, nonrecursive, field.

Page 24: Function Point Analysis

24

Unadjusted FP …..

Each of the following tables assists in the ranking process (the numerical rating is in parentheses). For example, an EI that references or updates 2 File Types Referenced (FTR’s) and has 7 data elements would be assigned a ranking of average and associated rating of 4. Where FTR’s are the combined number of Internal Logical Files (ILF’s) referenced or updated and External Interface Files referenced.

Page 25: Function Point Analysis

25

Unadjusted FP …..

Page 26: Function Point Analysis

26

Unadjusted FP …..

Page 27: Function Point Analysis

27

Unadjusted FP …. Like all components, EQ’s are rated and scored. Basically,

an EQ is rated (Low, Average or High) like an EO, but assigned a value like and EI. The rating is based upon the total number of unique (combined unique input and out sides) data elements (DET’s) and the file types referenced (FTR’s) (combined unique input and output sides). If the same FTR is used on both the input and output side, then it is counted only one time. If the same DET is used on both the input and output side, then it is only counted one time.

For both ILF’s and EIF’s the number of record element types and the number of data elements types are used to determine a ranking of low, average or high. A Record Element Type is a user recognizable subgroup of data elements within an ILF or EIF. A Data Element Type (DET) is a unique user recognizable, nonrecursive field on an ILF or EIF.

Page 28: Function Point Analysis

28

Unadjusted FP ….

Page 29: Function Point Analysis

29

Unadjusted FP ….

The counts for each level of complexity for each type of component can be entered into a table such as the following one. Each count is multiplied by the numerical rating shown to determine the rated value. The rated values on each row are summed across the table, giving a total value for each type of component. These totals are then summed across the table, giving a total value for each type of component. These totals are then summoned down to arrive at the Total Number of Unadjusted Function Points.

Page 30: Function Point Analysis

30

Unadjusted FP ….

Page 31: Function Point Analysis

31

VAF

The value adjustment factor (VAF) is based on 14 general system characteristics (GSC's) that rate the general functionality of the application being counted. Each characteristic has associated descriptions that help determine the degrees of influence of the characteristics. The degrees of influence range on a scale of zero to five, from no influence to strong influence. The IFPUG Counting Practices Manual provides detailed evaluation criteria for each of the GSC'S, the table below is intended to provide an overview of each GSC.

Page 32: Function Point Analysis

32

GSC – General System Characteristics

There are 14 General System Characteristics (GSC’s) that rate the general functionality of the application being counted

Each characteristic has associated description that help determine the degree of influence of the characteristics

The Degrees of Influence range on a scale of Zero to Five, from no influence to strong influence. The Ratings are: 0 - Not Present, or No Influence 1 - Incidental Influence 2 - Moderate Influence 3 - Average Influence 4 - Significant Influence 5 - Strong Influence Throughout

Page 33: Function Point Analysis

33

The 14 GSCs … 1 thru 8

Data communication Distributed data processing Performance Heavily used configuration Transaction rate Online data entry End user efficiency Online update

Page 34: Function Point Analysis

34

GSC Brief DescriptionData communications How many communication facilities are there to aid in

the transfer or exchange of information with the application or system?

Distributed data processing

How are distributed data and processing functions handled?

Performance Was response time or throughput required by the user?

Heavily used configuration

How heavily used is the current hardware platform where the application will be executed?

Transaction rate How frequently are transactions executed daily, weekly, monthly, etc.?

On-Line data entry What percentage of the information is entered On-Line?

End-user efficiency Was the application designed for end-user efficiency?

On-Line update How many ILF’s are updated by On-Line transaction?

Page 35: Function Point Analysis

35

GSC Brief Description

Complex processing Does the application have extensive logical or mathematical processing?

Reusability Was the application developed to meet one or many user’s needs?

Installation ease How difficult is conversion and installation?

Operational ease How effective and/or automated are start-up, back-up, and recovery procedures?

Multiple sites Was the application specifically designed, developed, and supported to be installed at multiple sites for multiple organizations?

Facilitate change Was the application specifically designed, developed, and supported to facilitate change?

Page 36: Function Point Analysis

36

Calculating Adjusted Function Points

FPC = UFP * VAF Where VAF = [ (ΣGSC * 0.01) + 0.65]

Where FPC – Adjusted function point count UFP – Unadjusted function points VAF – Value adjustment factor ΣGSC – Sum total of ratings of all 14 GSCs

Page 37: Function Point Analysis

37

Estimating Efforts based on Size Estimation

Convert FPC into PDs based on productivity of the technology under consideration

Productivity = Size / Efforts

Efforts = Size / PRoductivity

Page 38: Function Point Analysis

38

Mapping Efforts to Schedule

Analysis 15% High Level Design 15% Low Level Design 10% Coding 35% Unit Testing 11% Integration & System Testing 10% Project Management 4%

Page 39: Function Point Analysis

39

Thank You

Page 40: Function Point Analysis

40

DET – Data Element Type

A DET is a unique attribute or a field

It has information that is dynamic and not static

Page 41: Function Point Analysis

41

DET – Counting Rules Count a DET for each unique user

recognizable, non-repeating field maintained in the ILF or retrieved from the EIF through the execution of an elementary process

When two applications maintain and / or reference the same ILF / EIF, but each maintains/references separate DET’s, count only the DET’s being used by each application to size the ILF / EIF

Count each DET for each piece of data required by the user establish relationship with another ILF / EIF

Page 42: Function Point Analysis

42

RET – Record Element Type

A RET is a user recognizable subgroup of data elements within the ILF or EIF

Counting Rules Count a RET for each optional or mandatory

subgroup of the ILF / EIF If there are no subgroups, count the ILF or

EIF as a RET

Page 43: Function Point Analysis

43

ILF – Internal Logical Files

It is a user identifiable group of logically related data or control information maintained within an application boundary

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

Page 44: Function Point Analysis

44

ILF – Identification Rules Group of Data or control information is logical, user

identifiable, and fulfils specific user requirements

Data is maintained within the application boundary

Data is modified via an elementary process (One or more EI’s)

Has not been counted as an EIF for the application

Each ILF is counted only once in the application

Page 45: Function Point Analysis

45

ILF - Ruling

RET DET 1 – 19 DET 20 – 50 DET 51 +

0 – 1 LOW LOW AVG

2 – 5 LOW AVG HIGH

6 + AVG HIGH HIGH

Page 46: Function Point Analysis

46

EIF – External Interface File

A user identifiable group of logically related data that resides entirely outside the applications boundary and is not maintained by the application

An EIF is an ILF for another application

Page 47: Function Point Analysis

47

EIF – Identification Rules Group of data or Control information is a logical,

user identifiable, and fulfils specific user requirements

Group of data is referenced by, and external to, the application being counted

Group of data has not been counted as an ILF by the application

Each EIF is counted only once in the application

Page 48: Function Point Analysis

48

EIF - Rating

RET DET 1 – 19 DET 20 – 50 DET 51 +

0 – 1 LOW LOW AVG

2 – 5 LOW AVG HIGH

6 + AVG HIGH HIGH

Page 49: Function Point Analysis

49

Things to remember

Stand alone systems will not have an EIF

Same file cannot be an ILF and EIF in the same application

Same file can be EIF for multiple applications

Same file can be ILF for multiple applications, if all these applications are updating the file

Page 50: Function Point Analysis

50

ILF and EIF

Do not count system files, like sort files, index files etc

Consider an un-normalized view of the file Any ILF/EIF may become multiple tables

after normalization Every EIF must be an ILF in atleast one

other application

Page 51: Function Point Analysis

51

Transaction Function Points

Transaction function points are contributed by External Inputs (EI) External Outputs (EO) External Inquiries (EQ)

Two inputs required FTR – File Type Referenced DET – Data Element Type

Page 52: Function Point Analysis

52

FTR – File Type Referenced

FTR is a file type referenced by a transaction

FTR must also be an ILF or EIF

Counting Rules Count a FTR for each ILF maintained Count only one FTR for each ILF maintained

and read in the transaction

Page 53: Function Point Analysis

53

EI - Rating

FTR DET 1 - 4 DET 5 - 15 DET 16 +

0 - 1 LOW LOW AVG

2 LOW AVG HIGH

3 + AVG HIGH HIGH

Page 54: Function Point Analysis

54

EO – Rating

FTR DET 1 – 4 DET 5 – 19 DET 20 +

0 – 1 LOW LOW AVG

2 – 3 LOW AVG HIGH

4 + AVG HIGH HIGH

Page 55: Function Point Analysis

55

EQ – Rating

FTR DET 1 – 4 DET 5 – 19 DET 20 +

0 – 1 LOW LOW AVG

2 – 3 LOW AVG HIGH

4 + AVG HIGH HIGH

Page 56: Function Point Analysis

56

Calculating Unadjusted Function Points

Element Low Average High Total

EI __ x 3 __ x 4 __ x 6

EO __ x 4 __ x 5 __ x 7

EQ __ x 3 __ x 4 __ x 6

ILF __ x 7 __ x 10 __ x 15

EIF __ x 5 __ x 7 __ x 10

Unadjusted Function Points (UFP)

Page 57: Function Point Analysis

57

Recap

Count data function points (data at rest) ILF - Internal Logical Files EIF – External Interface Files

Count transaction function points (data on move) EI – External Inputs EO – External Outputs EQ – External Inquiries

Page 58: Function Point Analysis

58

The 14 GSCs … 9 thru 14

Complex processing Reusability Installation ease Operational ease Multiple sites Facilitate change

Page 59: Function Point Analysis

59

Quick FPA

Carried out at a very early stages of project May be at the time of proposal preparation stage

Carried out because Lack of time Lack of information

Assumptions Difference between High and Low is not much,

hence Average is used for calculation Use a judgment call for overall complexity

Page 60: Function Point Analysis

60

Quick FPA - Calculation

Identify and count EIs, EOs, EQs, ILFs and EIFs Do not count RETs, DETs and FTRs Classify all functions as average To calculate unadjusted function points, use the

coefficients EI – 4 EO – 5 EQ – 4 ILF – 10 EIF – 7

VAF = 0.65 to 1.35 FPC = UFC * VAF

Page 61: Function Point Analysis

61

Quick FPA - Accuracy

With al information Quick FPA gives a result which is + / - 10 % of detailed FPA

It is INEFFECTIVE if used by persons who do not have expertise in detailed FPA

Page 62: Function Point Analysis

Questions ???