Function Point Calcution

8/3/2019 Function Point Calcution

1/18

Project Planning PhaseConsists of:

EstimationEffort =The amount of work involved in a project = no. of people x time

Units man-days, man-hours, man-months etc.

E.g.

if a project takes 6 people 100 days to complete, then the effort estimate is 600 man-days = 600*8 man-hours (considering 8 hours of work per day) = 600/23 man-months(23 working days per month). There are many methods of estimating the effort fromthe given requirements, some of which will be covered here. The very first thingdetermined in project planning is effort estimate. After the effort is known, the costand time can be easily calculated. Also, scheduling of the work and resourceallocation can be done.

s

Tasks Involved in Software Development

The following tasks are involved in the development of each screen, report, object, DBtable etc. Each task takes time according to the complexity of the item. So, youcannot say that you will make one screen for displaying data within 1 or 2 hours. Ifyou do so, then that item will not do most of the important functions. You need timefor each of the following:

Tasks Required for Screen Coding:

Project Planning

Estimation Scheduling Resource Allocation Risk Analysis

Risk Resolution

Effort Cost TimeHW / SW

Res Alloc

Human

Res Alloc


2/18

1. Screen layout design

2. Input data validation, (e.g. valid phone number, email address, numeric fields, dateetc)

3. Output data formatting (e.g. currency format, date format etc.)

4. Calculation of auto-calculated fields, such as totals etc,

5. Database queries for displaying a list of records, for displaying each record, forinserting a new record and for updating an existing record, and for deleting records

6. Code for Functions for each button on the screen. Enabling and disabling of buttonsin different states

7. Any other business logic and calculation formulas

8. Field tab sequences

Tasks Required for Report Coding

1. Search Parameter Screen for each report to input the search fields

2. Output data formatting

3. Very complex database queries to search, collect information from the wholedatabase, perform calculations and output the required results (business logic andcalculation formulas)

4. Report layout design5. Drill-down features, such that if you click on one number or item in a report, it

opens another report showing the details or calculation of that item.

Tasks Required for Object Coding

1. Object Definition

2. Code for all of the object functions (business logic and calculation formulas)

3. Constructors and destructors

4. Getter and Setter Functions

5. Access restrictions

Tasks Required for Database Tables

1. Table creation

2. Table relationships

3. Table and field properties (e.g. nullable, unique, valid ranges of values etc)

4. Access Restrictions


3/18

5. Creation of views, indexes, and other fast access methods

Tasks Required for Procedures and Functions Coding

Can be object functions, structured programming functions, or databaseprocedures/functions

1. The entire complex business logic and calculation formulas which need to beimplemented

2. Can be thousands of lines, and can all several functions to do parts of the work

External System Interfaces

Perform data input from or output to other external systems, which are not part of thissystem, e.g. purchasing and sale systems need to post financial vouchers in theaccounting system, and stock update records in the inventory system. If all these areseparate systems, then external system interfaces are required.These can be in some standard format, such as web services, CORBA etc, or any otherremote API, in which one system can remotely call the functions of another system, orcan be through writing the necessary information into temporary database tablesfrom which the other system reads it, or can be through generation of text or binaryfiles of the information, which are read by the other system. In every case, the systemrunning on one machine needs to either call functions of or access data written byanother system running on another machine


4/18

Effort Estimation Method 1: Based on Screens, Reports, Functions

This method estimates the programming effort required for the known number ofitems to be developed, and uses percentage distribution of effort to estimate the workin all other phases of software development

The following are the numbers of items to be developed in a project or in a module of

a project. These can be easily obtained from the requirements. (the estimate can bemodule-wise or of the whole project) (numbers are only examples, you fill thenumbers for your own project)

Number of Items to be Developed

Item Simple Medium Complex

Screens 5 10 3

Reports 8 5 10

Objects 12 15 20

Functions orProcedures

Database Tables

External SystemInterfaces

Anything else

Count the number of simple, medium and complex items required from the softwarerequirements and design, and fill the above table.

The effort estimate for each item

Again, these are examples. You fill in the number of man-days required by your team

for the specific technology you are using)

Item Simple(man-days)

Medium (man-days)

Complex (man-days)

Screens 1 2 4

Reports 1 2 4

Objects 1 2 4

Functions orProcedures

1 2 4

Database Tables 0.25 0.5 1


5/18

External SystemInterfaces

3 5 10

Anything else ? ? ?

Total Coding Effort

Multiply the numbers in table 1 and table 2 to get the total effort. Add for all itemsand for simple, medium and complex. e.g. screen effort = 5*1 + 10*2 + 3*4 man-days

Effort for all Phases

Use a percentage breakdown of effort for all phases. The below is only an example.Fill the percentages which are suitable for your team and your type of project.

Phase % effort Example with Codingeffort = 100 man-days

Requirements 8% 33

Specifications 8% 33

Project Planning 8% 33

Project Management 8% 33

Architecture 4% 17

Design 12% 50

Coding 24% 100

Integration 4% 17

User Documentation 4% 17

QA 20% 83

Total 417

Add time for otheractivities, such asdeployment, training,client acceptancetesting etc.

Suppose the total coding effort for a project is 100 man-days. The table above showsthe example results for all other phases

The total effort for all phases = coding effort *100 / coding percentage = 100 *100/24= 417 man-days


6/18

The effort for each phase = total effort * phase percentage / 100 = 417 *8 / 100 = 33man-days

Unless you spend this amount of effort on all phases, a well-designed and goodquality software will not be developed.


7/18

Function Point Analysis

Definition: Function points are a measure of the size of computer applications and theprojects that build them. The size is measured from a functional, or user, point ofview. It is independent of the computer language, development methodology,technology or capability of the project team used to develop the application.

FP Analysis tries to quantify data in motion and data at rest.

The software to be developed has the following components:

Transactional Function Points (Data in Motion)

1. EI External Input a data input screen with record insert or modify functions

2. EO External Output a data / results calculation and display screen or report,with query and view of records and with some calculated results or logical

processing

3. EQ External Query a data display screen or report, with no calculated results,but just data queried and displayed from a database, such as a record view andsearch function

Data Function Points (Data at Rest)

4. ILF Internal Logical File A file or database table for saving the data within thesystem

5. EIF External Interface File a file or table belonging to an external system, fromwhich our system accesses and uses the data. The responsibility of inputting andmaintaining data in the EIF is of the external system. Our system only reads anduses the data of the EIF. E.g. if a purchasing system needs the account codes forbilling, it reads the account codes from the accounting system. The account codesbelong to, and are saved and modified by the accounting system, not by thepurchasing system. For the accounting system, they are an ILF, but for thepurchasing system, they are an EIF.

If a single screen has read as well as write functions insert, modify, view, search,then it will be counted as both EI as well as EO or EQ (i.e. either EI and EO, or EIand EQ).

A screen cannot be counted as both EO and EQ. If it has any calculated + querieddata, then it is counted as EO, otherwise if it has only queried data, then it iscounted as EQ.

The above components can have the following characteristics:

1. DETs Data Element Types.

All of the above components can have DETs.


8/18

1.1.For screens (EI, EO, EQ), DETs are the data fields + Error Messages + 1 DET forall of the buttons on the screen, including 1 DET for each calculated value.

1.2.Each error message that the screen can produce, (e.g. each validity check ofthe fields) counts as a DET.

1.3. A group of radio buttons, that together present a single choice field countas one DET. However, separate check boxes which provide independent

choices count as separate DETs.1.4. All command buttons on the screen together count as a single DET.

1.5. For Reports (EO / EQ), DETs are the no of data fields.

1.6.For tables or files (ILF, EIF), DETs are the data fields

2. RETs Record Element Types.

These are the number of logical entities within one file or table. It is a user

recognizable subgroup of data elements within a file or table. In case of normalizedtables, there is only one RET in each table. In case of un-normalized tables, therecan be multiple entities or RETs in one table

E.g. Un-normalized sale table:

SaleID, SaleDate, SaleType, Customer ID, CustomerName, CustomerPhone, Item,Quantity, Price, Total. This contains 3RETs: Sale, Customer, and Sale Items.

3. FTRs - File Type Referenced.

A FTR is a file type referenced by a transaction. An FTR must also be a internallogical file or an external interface file. It is the number of logical entities that areused in a transaction.

Examples


9/18

Hawk P

Item1

EIILFA


10/18

Function Point CalculationUFP=Unadjusted Function Points

EI Table Shared EO and EQ Table UFP


11/18

Data Elements FTRs Data Elements Rating UFP

1-4 5-15 > 15 1-5 6-19 > 19 EO EQ EI

0-1 Low Low Ave 0-1 Low Low Ave Low 4 3 3

2-3 Low Ave Hig

h

2-3 Low Ave Hig

h

Average 5 4 4

> 3 Ave High Hig

h

> 3 Ave Hig

h

Hig

h

High 7 6 6

ILF / EIF Table

RETs Data Elements Rating UFP

1-19 20-50 > 50 ILF EIF

1 Low Low Ave Low 7 5

2-5 Low Ave High Average 10 7

>5 Ave High High High 15 10


12/18

Value Adjustment Factor (VAF)14 general characteristics to be ranked by degree of influence from 0-5

Degree of Influence Measures

Not Present, or no influence present =0

Insignificant Influence =1

Moderate Influence =2

Average Influence =3

Significant Influence =4

Strong influence, throughout =5

14 General Characteristics:

1. Data Communications

2. Online Update

3. Distributed Functions

4. Complex Processing

5. Performance

6. Reusability

7. Heavily Used Configuration8. Installation Ease

9. Transaction Rate

10. Operational Ease

11. Online Data Entry

12. Multiple Sites

13. End User Efficiency

14. Facilitate Change

15.

Result:

Total Degrees of Influence(DI) = sum of above factors (total 0to 70)

VAF = 0.65+0.01 x DI (VAF value from 0.65 to 1.35)

Adjusted Function Points AFP = UFP x VAF

Benefits1. Is a structured technique of classifying components of a system based upon

systematic rules.


13/18

2. Measures software by quantifying its functionality provided to the user basedprimarily on the logical design instead of the implementation

3. A standard method for measuring software development from the customers pointof view

4. Can be used to size software applications accurately.

5. Can be counted by different people, at different times, to obtain the same measurewithin a reasonable margin of error.

6. Are easily understood by the non technical user.


14/18


15/18

to bid $100,000, since you can also get the contract, as well as more money bybidding higher.

Time EstimateAgain, the basic time estimate is very easy, if the effort estimate is known. Time =Effort / People

e.g. Effort 100 man-days, people = 10, time = 10 days.

Public holidays and week-ends must be considered in calculating the calendar days.

The above is valid as long as the work consists of small pieces which can be easilydivided between the team members. (e.g. if 20 screens and 20 reports are to bedeveloped which are not dependent on each other, then each developer can developX screens and X reports.

However, for a large team size, you cannot achieve a very small completion time, e.g.for 100 man-days effort, with 50 people, the work cannot be completed in 2 days. Thisis because for each person, there is some overhead of understanding the project and

the work to be performed, as well as there is communication overhead, whichincreases as the team becomes larger. So for large team size, the effort estimateincreases. E.g.

Team Size Effort Estimate (oractual amount of workto be done) man-days

Time

days

1 50 50

5 50 10

10 75 7.5

20 100 5

There is no formula for these numbers, and they may be different for your project.They have to be estimated from experience.


16/18

Intermediate COCOMOThe Constructive COst Model developed by Boehm.

This is an effort estimation technique based on the lines of code required in asoftware. If the number of lines of code can be estimated by some other method, thenCOCOMO gives the effort estimate for those lines of code in man-days.

There are 4 types of COCOMO, Basic, Intermediate, Detailed, and COCOMO-II (arevised and extended version) They use different formulas and parameters for effortestimation. For a detailed explanation of all types, See Futrell, Ch. 11. Here, we willstudy Intermediate COCOMO briefly.

Input: KLOC = 1000 line of code

Effort E (man-months) = a x KLOCb x fifteen multipliers

There are 3 types of projects which have different values of a and b. The definitionsand formulas of those types of projects are given below:

ProjectType

Code Size ProjectSize

Innovation DeadlineandConstraints

Developmentenvironment

Organic 2-50 KLOC Small Little(well-knownproject)

Not tight Stable,well-known

Semi-detatched

50-300KLOC

Medium Medium Medium Medium

Embedded Over 300KLOC

Large Large(new,innovative

)

Severe Complex

ProjectType

Definition Effort Estimate formula

Organic Simple systems, small projects, e.g.payroll, inventory, scientificcalculation etc

3.2 x KLOC1.05 x fifteenmultipliers

Semidetatched

More complex systems, largerprojects, e.g. operating system,compilers, databases (oracle etc)



17/18

Embedded Very complex Real time systems,such as medical, aerospace, militaryetc.


Example, for an organic project, with all multiplying factors =1, it takes 3.2 man-months for 1000 lines of code, or approx 13-14 lines of code per day. Note that this

is the total effort for the project, for all phases not just the coding effort.The effort for each phase can be estimated using the percentage distribution of effortbetween phases.

In many books, the lines of code is called as KDSI (1000 delivered source instructions)instead of KLOC, and it includes counting of each computer instruction separately.There may be more than one instructions in a line, e.g. c=d++ has 2 instructions.

Cost Drivers

The fifteen multipliers in the formula are called cost drivers, which give somemultiplying factors depending on certain properties of the project, the language and

the team. These factors are all multiplied in the above formula to get the final effortestimate.

The cost drivers or multiplying factors are as follows

Cost Drivers andCategories

VeryLow

Low Nominal

High VeryHigh

ExtraHigh

Product Attributes

Required SoftwareReliability

.75 .88 1.00 1.15 1.4

Database Size .94 1.00 1.08 1.16

Product Complexity .7 .85 1.00 1.15 1.3 1.65

Computer Attributes

Execution TimeConstraint

1.00 1.11 1.3 1.66

Main Storage Constraint 1.00 1.06 1.21 1.56

Virtual MachineVolatility

.87 1.00 1.15 1.3

Computer TurnaroundTime

.87 1.00 1.07 1.15

Personnel Attributes

Analyst Capability 1.46 1.19 1.00 .86 .71

Application Experience 1.29 1.13 1.00 .91 .82

Programmer Capability 1.42 1.17 1.00 .86 .7Virtual MachineExperience

1.21 1.1 1.00 .9


18/18

Programming LanguageExperience

1.14 1.07 1.00 .95

Project Attributes

Use of modernprogramming practices

1.24 1.1 1.00 .91 .82

Use of software tools 1.24 1.1 1.00 .91 .82Required developmentschedule

1.23 1.08 1.00 1.04 1.1

Disadvantages of COCOMO

1. This is not really an estimation method, as you cannot determine the effort fromthe requirements given. You still need another method to estimate the number oflines of code required. However, lines of code can again be estimated fromexperience from the number of screens, reports, objects, procedures etc requiredand their complexity. E.g. how many lines of code are required for a simple,medium or complex screen, report, procedure etc. These can be totaled for all thedevelopment items required.

2. The lines of code required for the same task vary greatly with the selecteddevelopment environment and language, and also the time/effort taken for thesame number of lines of code varies with the development environment andlanguage, depending on the automation and facilities in the tool being used.

3. Nowadays, a huge amount of code is auto-generated using a wizard, and onlysome specific user-defined logic is added by hand. So, the auto-generated codeshould be excluded from the effort, since it does not take manual effort or time

4. Different developers would perform exactly the same task in different number oflines, e.g. some developers will often combine 2 or 3 lines in one line e.g. if((c=a++)==0). So it is very difficult to estimate (a) how many lines of code a particulardeveloper will use for a task and (b) how much time it will take.

Comments are often included in the lines of code, and they should be excluded fromcounting lines of code, so counting the lines of code needs a tool which can analyze

the lines and count. However, adding detailed comments also takes some extratime/effort.

Date post:	06-Apr-2018
Category:	Documents
Upload:	khunshan-s-ahmad
View:	230 times
Download:	0 times

Function Point Calcution

Documents