Function Point Analysis

document.doc Page 1 of 61 4/8/2023

Function Point

Analysis

Table of content

1. Software Estimation – An Introduction...........................................................5

What is Software?................................................................................................5

Software Engineering..........................................................................................5

Goal of Software Engineering..............................................................................5

Software Development Life Cycle........................................................................6

Different Approaches to Software Development Life Cycle..................................7

Software Estimation and Software Development Life Cycle.................................8

Software Estimation – a challenge.....................................................................10

2. Understanding Software Estimation............................................................11

Estimate – Definition..........................................................................................11

Components of Software Estimation..................................................................11

Size Estimate.....................................................................................................11

Effort Estimate...................................................................................................12

Schedule Estimate.............................................................................................12

Cost Estimate....................................................................................................12

Hurdles in successful estimation process..........................................................12

Estimation methods...........................................................................................13

3. Using Function Points..................................................................................15

Function Points..................................................................................................15

Definition...........................................................................................................15

Data in motion................................................................................................15

Data at rest....................................................................................................16

Uses of Function Points......................................................................................16

What FPA is unfit for..........................................................................................17

Types of Function Point Counts..........................................................................17

Development Project Function Point Count.....................................................17

Enhancement Project Function Point Count....................................................17

Application Function Point Count....................................................................18

Function points and software metrics................................................................18

Advantages of Function Points...........................................................................18

Disadvantages of Function Points......................................................................19

4. Counting Development Function Points.......................................................20

Diagrammatic Representation of FPA................................................................20


Technology Issues:............................................................................................21

Internet/Intranet Applications.........................................................................21

Client/Server...................................................................................................21

FPA Steps for Data Functions:............................................................................22

Internal Logical Files..........................................................................................24

Rating:............................................................................................................24

Standard Documentation:...............................................................................24

External Interface Files......................................................................................26

Rating.............................................................................................................26


Unadjusted Function Points for Data functions..................................................28

FPA Steps for Transactional Function Types:.....................................................29

DET’s for GUI..................................................................................................30

External Input....................................................................................................33

Data Elements:...............................................................................................33

Rating:............................................................................................................34


External Output.................................................................................................36

Data Elements:...............................................................................................37

Rating:............................................................................................................38


External Inquiries...............................................................................................40

Data Elements:...............................................................................................40

Rating:............................................................................................................42


Unadjusted Function Points for Transaction functions.......................................44

Compute Unadjusted Function Points................................................................46

Rate on 14 General System Characteristics.......................................................46

Definition:.......................................................................................................46

Rating:............................................................................................................46

Tabulating:.....................................................................................................47

GSC’s at a Glance:..........................................................................................47

Considerations for GUI Applications................................................................48

Compute the Adjusted Function Points..............................................................49

5. Other Function Points Extensions................................................................50


Mark II method..................................................................................................50

Feature Points....................................................................................................51

Object Points.....................................................................................................51

6. Effort, Cost, Schedule Estimates..................................................................52

Productivity.......................................................................................................52

Factors impacting Productivity.........................................................................53

Size and Effort................................................................................................53

Schedule and effort........................................................................................53

Quality Versus Effort and Schedule................................................................53

Other Factors..................................................................................................53

Approach to Effort and schedule Estimation......................................................54

Work Breakdown Structure(WBS)...................................................................54

Cost Estimation..................................................................................................55

Understanding Different Costs:.......................................................................55

Cost Estimation Sheet....................................................................................56

7. Making the estimation process effective.....................................................57

A high maturity estimation process...................................................................58

Database for Estimation....................................................................................58

Database Contents.........................................................................................59

Estimation Tools................................................................................................59

8. Industry Resources......................................................................................60

Brief History:......................................................................................................60

Growth and Acceptance of Function Point Analysis...........................................60

More Information about IFPUG:..........................................................................60

Weblinks............................................................................................................61


1. Software Estimation – An Introduction

What is Software?

Software is not merely a set of programs.

Software is a collection of computer programs, procedures,business rules and

associated documentation and data.

Software Engineering

As we are aware, software is not just code but it also includes the data structures

that enable the programs to hold data and manipulate it, and the documents that

describe the system and the use of programs.

A software system is made for problem resolution. Making software begins with

understanding problem statement and then, designing the proposed solution and

implementing the same to solve the problem.

To develop a better quality software system, one must have a systematic

approach towards all engineering activities and all the umbrella activities that

monitor the entire process.

IEEE, (610.12-1990) defines software engineering as

(1) The application of a systematic, disciplined, quantifiable approach to the

development, operation and maintenance of software

(2) The study of approaches as in (1).

Goal of Software Engineering

The common symptoms of projects that fail :

Delayed schedules

Inaccurate understanding of user needs

Inability to deal with changing requirements

Modules that don’t fit together

Software that is hard to maintain and extend


Late discovery of serious project flaws

The projects usually fail due to root causes like :

Ad hoc requirements management

Ambiguous and imprecise communication

Undetected inconsistencies in requirements, designs, and implementations

Insufficient testing

Failure to attack risk

The goal of software engineering is to produce high quality software at low cost.

Software Development Life Cycle

The basic phases in Software Development Process are Requirements Analysis,

Design, Coding and Testing.

The project outputs in Software development effort are :

Requirements document

Project Plan

System Design document

Detailed design document

Test Plan and test report

Final code

Software Manuals

Review reports

A software development process model specifies how these activities are

organised in software development effort to produce desired results.

The software development process has four roles :

1. Provide guidance as to the order of a team’s activities.

2. Specify which deliverables should be developed and when they should be

developed (helps in generation of Work Breakdown Structure)

3. Direct the tasks of individual developers and the team as a whole


4. Offer criteria for monitoring and measuring the project’s products and

activities.

Different Approaches to Software Development Life Cycle

Waterfall model

This model suggests a systematic, sequential approach which begins at system

level feasibility study and progresses thru analysis, design ,coding, testing and

maintenance. A project begins with feasibility study. On successfully

demonstrating the feasibility of the project, the requirements analysis and project

planning starts. The design starts after the requirements analysis is complete and

coding begins after the design is complete. Once the programming is completed,

the code is integrated and testing is done. On successful completion of testing,

system in installed. After this, the regular operation and maintenance of the

system takes place.

Prototyping

The waterfall model assumes that the requirements of the system can be frozen

which may not be practically possible. In the prototyping approach, a prototype is

developed based on the currently known requirements. Development of prototype

undergoes informal design, coding and testing phases. Interactions with this

prototype can help customer better understand the requirements of desired

system. Once the clarity on requirements is achieved, the design, coding and

testing phases are followed sequentially as in Waterfall model.

Iterative

Here the basic idea is that the software is developed in increments, each

increment adding some functional capability to the system , till the full system is

implemented. At each step, requirement extensions and design modifications can

be made. Initially, a project control list is created that contains all the tasks that

should be performed to obtain the final implementation. Each step consists of

removing the next step from the list, designing the implementation for the

selected task, coding and testing the implementation and performing the analysis


of the partial system obtained after this step and updating the list as a result of

analysis.

Software Estimation and Software Development Life Cycle

Any software order typically follows the following cycle :

(1) Order Acquisition

The marketing team is responsible for this phase. They identify

prospective clients from the marketplace. Once such prospect has a

requirement for software development, marketing team react to it by

initiating the process of Proposal preparation. With the macro-level

knowledge of the requirement, technical support team tries to reach to a

estimate about the size of the software effort. As per the productivity

standards of the organization, the effort and cost for the project

determined. The proposal is then submitted to the client. After the rounds

of negotiation, finally the contract is awarded for software development.

(2) Planning (umbrella activity)

The project plan is developed at the beginning of the job and is

successively refined as the work progresses. The project plan defines the

work and how it will be done. It provides a definition of each major task,

an estimate of the time and resources required and a framework for

management review and control.

It also covers the plan for implementing quality assurance related

activities and configuration management activities.

(3) Order Execution

Requirements specification is the starting step for development activities.

During the requirements specification, the goal is to produce a user


requirements specification document. This document forms the basis for

the development and software validation.

There are two basic activities in requirements phase. The first is problem

or requirements analysis. The goal of this activity is to understand

different aspects as the requirements of the problem, its context and how

it fits in the client’s organisation. The second activity is requirements

specification, during which the understood problem is specified and

written, producing user requirement specification (URS).

At the end of URS, a complete picture of the micro-level requirements is

known and hence the effort and cost estimates are revisited to get the

correct picture of the estimates.

The software is then further completed thru high level design, detailed

design, coding and testing.

(4) Order Delivery

When the software is implemented at the customer’s site, the users

come up further defects that were not identified in testing phase or may

come up with further modifications/ enhancement. As a result, the

software undergoes the change. Change management is one of the most

fundamental activities of software engineering. Changes to requirements

drive design and design changes affect the code. For even modest-sized

projects, the number of people involved and the change volume generally

require a formal change management system. Hence, the need for

software configuration management (SCM).

During this phase, estimation is used to determine the impact(size) of the

change and identify addition effort and cost estimates.

(5) Order Closure

When all the software activities as mentioned in the contract are over, the

order is closed after noting the lessons learnt in project database where

the effort and size variances are specifically noted.

So as one can see, Software Estimation activity starts during the order acquisition

phase itself. The estimates are then revisited once the order is acquired and the

planning begins for the execution of the project. As more insights about project


scope are gained during the order execution phase, estimates are once again

revisited to check the validity of initial estimates. References to estimation

continues to happen till the order is closed.

Software Estimation – a challenge

The flaws in estimates typically become evident when the project proceeds to the

stages of detailed planning and execution. Improper estimates lead to a variety of

problems for both the software organization and user organization e.g.

a) in case of over estimates, the bidding software organization may lose the

project, because a competing software organization has estimated more

accurately and quoted lower.

b) In case of an under estimate, the software organization will make a loss

and also deadly the delivery of the software.

Estimation often suffers due to incomplete knowledge, lack of time and various

market and business pressures that are directly and indirectly put on the

estimator to arrive at more ‘business acceptable’ estimates.

On the other hand, accurate estimates for the size, effort, schedule and cost

ensure that commitments made to customers and budgets that are allocated are

realistic. This reduces the pressure on the project team to take short-cuts, thereby

increasing the probability of delivering on time, within budget and fulfilling user

requirements.


User Requirement

Specification

2. Understanding Software Estimation

Estimate – Definition

A tentative judgement of the approximate value, worth, cost, size or other

attributes of significance.

Components of Software Estimation

A simple estimation model relating size, effort, schedule and cost is depicted

below:

Size Estimate

For a software project, we are interested primarily in estimating the cost and

duration of the project. A project estimate is only as good as the estimate of the

size of the work.


Size Estimation

Schedule

Estimation

Effort Estimation

Cost Estimation

Organisatio

n Project

database

Other Cost

Component

s

Contractual

schedule

commitmen

ts

Because a project estimate is only as good as the estimate of the size of the work

to be accomplished, sizing represents the project planner’s first major challenge.

In the context of project planning, size refers to a quantifiable outcome of the

software project. Size can be measured in Lines of code or Function Points.

Effort Estimate

The estimate for the manpower that is required for the software product. Along

with the schedule estimate, it determines the team size and effort allocation.

Effort is normally measured in terms of person-days or person-months.

Effort estimate is driven by size and many project related factors such as skill and

capability of the team, the language and platform to be used, the availability and

suitability of the platform, the stability of the team etc.

Schedule Estimate

Schedule is the duration between the start of the project and the end of the

project. This is normally represented in terms of calendar months. It is influenced

by the contractual schedule commitments.

Cost Estimate

This is the estimate of the costs for a software project. A major component of

costs in software project is manpower cost which is based on effort estimation.

Apart from this, there are few additional cost components, e.g. infrastructural

costs, travel, communication facilities, Project specific training, outsourcing

resources.

Hurdles in successful estimation process

1. Estimate in a hurry

2. Ambiguous requirements

3. Lack of historical information

4. Ignorance of the fact that Productivity is inversely related to the size of the

software.

5. Other important factors not considered like

a. Availability and stability of the development environment


b. Team Capability and experience

c. Team Stability

d. Maturity of the processes

e. Availability of reusable software components etc.

6. Poor tracking of estimates during project execution

Estimation methods

To reduce the judgemental value of estimation and make it a scientific process,

software estimation needs to be based on estimation methods. The estimation

methods selected should be of following characteristics :

1. Should be able to convert requirements into one or more size estimates.

2. Should specify how effort, schedule and cost can be derived from the size

estimates and other project characteristics.

3. Should take into consideration project specific characteristics like SDLC

followed, skill level, requirements stability, process maturity of the

organization, automation during Software development.

4. Must be person independent

5. Must qualify the estimates with a certain degree of accuracy or tolerance.

6. Must support re-estimation at various phases of SDLC.

Direct method for Software sizing is Lines of code. The indirect method is Function

Points.

Lines of code is a technical measure as it measures the software from the

developer’s point of view and not from the user’s point of view. LOC as a measure

of the system size has various drawbacks.

A system’s LOC cannot be correctly known till the system is developed and LOC

estimates cannot be accurate till the design is complete for any system.

Expressing the size of a project in LOC at an early stage is almost impossible for

large systems.

LOC are more difficult to visualize in modern environments with interactive front

end development and auto generated code.

The LOC approach is basically more a developers approach and end user can not

directly relate to it.


With the introduction of more complex systems, and use of visual languages with

the versions of system software changing so rapidly, in initial stages of SDLC

Function Point becomes a preferred method for estimation.


3. Using Function Points

Function Points

Human beings solve problems by breaking them into smaller, understandable

pieces. Problems that may initially appear to be difficult are found to be simple

when dissected into their components, or classes. When the objects to be

classified are the contents of software systems, a set of definitions and rules, or a

scheme of classification, must be used to place these objects into their

appropriate categories. Function point analysis is one such technique: FPA is a

method to break systems into smaller components, so they can be

better understood and analyzed. It also provides a structured technique for

problem solving.

There are a variety of different methods used to count function point, like rules

developed by the Alan Albrecht and later revised by the International Function

Point User Group (IFPUG). Another method is Mark II Function Points developed

by Charles Symon. Feature points is another sizing method developed by Capers

Jones.

Definition

Function Point Analysis tries to understand the dynamic relationship between

transactions and data stores. On a conceptual level, function point analysis helps

define two abstract levels of data - data at rest and data in motion.

Data in motion

Data in motion is handled via transactional function types or transactions. All

software applications will have numerous elementary processes or independent

processes to move data. Transactions that bring data from outside the

application domain (or application boundary) to inside that 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 (or application

boundary) are referred as either an external outputs or external inquiries.


Data at rest

Applications store 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.

Uses of Function Points

1. Function points can be used to establish an inventory of all transactions

and files of a current project or application. This inventory can be used as

a means of evaluation of an application. If an inventory is conducted for a

development project or enhancement project, then this same inventory

could be used to help maintain scope creep and to help control project

growth. Even more important this inventory helps understand the

magnitude of the problem.

2. Function Points can be used to size software applications. Sizing is an

important component in determining productivity (outputs/inputs),

predicting effort, understanding unit cost, so on and so forth.

3. Unlike some other software metrics, different people can count function

points at different times, to obtain the same measure within a reasonable

margin of error. That is, the same conclusion will be drawn from the

results.

4. FPA can help organizations understand the unit cost of a software

application or project. Once unit cost is understood tools, languages,

platforms can be compared quantitatively instead of subjectively. This type

of analysis is much easier to understand than technical information. That

is, a non-technical user can easily understand Function Points.


What FPA is unfit for

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.

FPA is not useful to size Web Design. FPA is useful to size web development, but

not web design. FPA is concerned with the dynamic relationship between

transactions and files. FPA is not useful in estimating the time it will take to create

graphics, images, page layouts, so on and so forth.

Types of Function Point Counts

There are three different types of function point counts (Development,

Enhancement and Application).

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. Scope creep can be tracked and

monitored by understanding the functional size at all phase of a project.

Frequently, this type of count is called a baseline function point count.

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 size enhancement projects. All production

applications evolve over time. By tracking enhancement size and associated

costs a historical database for your organization can be built. Additionally, it is

important to understand how a Development project has changed over time.

Application Function Point Count

Application counts are done on existing production applications. This “baseline

count” can be used with overall application metrics like total maintenance hours.

This metric can be used to track maintenance hours per function point. This is an

example of a normalized metric. It is not enough to examine only maintenance,


but one must examine the ratio of maintenance hours to size of the application to

get a true picture.

Function points and software metrics

In the process of striving for quality thru continuous process improvement,

various metrics are collected using FP for defining baselines for organisation. They

are also considered to be normalizing measure that allows for comparisons among

industry segments.

Common Software Measures are :

Type Metrics Measure

1. Productivity FP / Effort FP per person month

2. Responsiveness FP / Duration FP per calendar

month

3. Quality Defects / FP Defects Density

4. Business Costs / FP Cost per FP

Advantages of Function Points

Advantages of FP as seen by the users of this method are :

1. FP counts are independent of the technology (Operating system, language

and database), developer productivity and methodology used.

2. FP very strongly relates to the requirements gathered from the users

which are the foundation of any software development effort.

3. FP are simple to understand and can be used for scope and requirements

related discussions with the users.

4. FP being independent of technology and productivity can be very

effectively used as a software metrics across diverse teams and

technologies.

Disadvantages of Function Points

1. FPAs are subjective in the areas of identification of RETs and ranking GSCs.


2. According to FPA , by decomposing the functionality of the system and

analyzing each part, then totaling , the total reflects the whole system. It

ignores the integration aspects of combining smaller parts to form a bigger

system.

3. FPA doesnot give due importance to processing logic involving complex

algorithms and calculations.

4. FPA is insensitive to extremes since highest complexity measures remain

the same for very large number of items in that category.


4. Counting Development Function Points

Diagrammatic Representation of FPA

It I necessary to establish the boundary or scope of the application to begin with.

In the first two steps based on URS, we identify the various functions in the

system. From the FPA point of view, functions could be either data functions or

transaction functions. Only user requested and user identifiable functions are

identified.

The documentations referred to for identifying the scope of the application

include :


User

Requirement

Specification

Identify Data Functions

Determine Complexity

thru DETs and RETs

Internal Logical Files

External Interface Files

Identify Transaction

Functions

Determine Complexity

thru DETs, FTRs

External Input

External Output

External Enquiry

Compute Unadjusted Function Points (UFP)

Rate on 14 General System Characteristics

Compute Value Adjustment factor (VAF)

Compute Adjusted Function Points (AFP)

System Specification Documents

Interface Documents

Interviews with the users

User Documentation

Design Documentation

Requirements

Data flow diagrams

Business flow diagrams

The total process used to size Function Points can be summarized by the following

seven steps :

1. Determine the type of function point

2. Identify Application Boundary

3. Identify all Data Functions and their complexity

4. Identify all transaction functions and their complexity

5. Determine the unadjusted function point count

6. Determine the value adjustment factor

7. Calculate the final FP count.

Technology Issues:

Internet/Intranet Applications

The boundary for an Internet/Intranet application is defined in a similar way for

traditional applications. For traditional applications the boundary is not drawn just

around the user interface or a group of screens but around the entire application.

Frequently, Internet/Intranet applications are just extensions to current and

existing applications.

Client/Server

The boundaries for client/server applications need to be drawn around both the

client and server. The reason is that neither the client nor server supports a users

(or sophisticated) view. That is, one alone does not represent a total application.

A complete application needs both data at rest (server) and data in motion

(client).


FPA Steps for Data Functions:

F1.Application

documentation and file rules

are used to identify files.

F2. The application

documentation (transaction

model and data model) is

used to determine type of

transaction (either external

interface file or internal

logical file).

F3. With the help of application documentation (data model) and file rules the

number data elements and record element types are determined.

F4. Each identified file is assigned a value of low, average or high based upon

type, data elements and record types.

F5. A distinct numerical value is assigned based upon type and value (low,

average, or high).

F6. All files are summed to create a file unadjusted function point count.

Data function types represent functionality provided to the user to meet internal

and external data requirements. Internal Logical Files (ILF) and External Interface

Files (EIF) are the two data function types.

To determine the complexity of ILFs and EIFs, the number of Data Element Types

(DETs) and Record Element Types (RETs) in each ILF and EIF are identified. A DET

is a user recognizable unique and non-recursive field. (also called Column,

Attribute, Data Field) in the ILF/EIF. A user recognizable sub-group of DETs within

an ILF/EIF is a RET (also called data structure, logical group of fields).

While identifying RETs look for a group of :


1. DETs which are typically updated at the same time

2. DETs that are of interest to different departments in user organization

3. DETs that are repeating groups

4. DETs that describe a sub-entity.



An ILF is a group of information stored in the system and maintained by the

system. It should be a user identifiable group. An ILF is a logical grouping of the

data or control information that is stored in the system, used within it and

maintained by it. The user may use it for generating outputs, or in inquiries or

process it using External Inputs.

An ILF should have at least one external output and/or external inquiry. That is,

at least one external output and/or external inquiry should include the ILF as an

FTR. Simply put, information is stored in an ILF, so it can be used later. The EO or

EQ could be from another application.

Rating:

Like all components, ILF’s are rated and valued. The rating is based upon the

number of data elements (DET’s) and the record types (RET’s). The table below

lists both the level (low, average or high) and appropriate value (7, 10 or 15).

Record Element Types

(RET)

Data Elements

1 to 19 20 - 50 51 or More

1 RET Low (7) Low(7) Average (10)

2 to 5 RET Low (7) Average (10) High (15)

6 or More RET Average (10) High (15) High (15)

Standard Documentation:

Table Layouts

Database descriptions

Logical data models

Field sizes and formats


Functional Specifications

User Requirements




An EIF is a unique file that is shared between the system and some external

application(s). It is a user identifiable logical group of data referenced by the

system but not maintained by it.

The data resides entirely outside the application boundary and is maintained by

another applications external inputs. The external interface file is an internal

logical file for another application.

Each EIF included must have at least one transaction, external input, external

output or external inquiry against it. In other words there must at least one

transaction that includes the EIF as a FTR. If the EIF does not have one

transaction, then one must wonder what is the purpose of the EIF and how was

the information retrieved.

Only count the part of the file that is used by the application being counted not

the entire file. The internal logical file, of another application, that you access

may have a large amount of DET’s and RET’s, but only consider the DET’s and/or

RET’s that are used when rating an EIF.

Rating

The table below lists both the level (low, average or high) and appropriate value

(5, 7 or 10 unadjusted function points).

Record Element Types

(RET)

Data Elements

1 to 19 20 - 50 51 or More

1 RET Low (5) Low(5) Average (7)

2 to 5 RET Low (5) Average (7) High (10)

6 or More RET Average (7) High (10) High (10)



Table Layouts

Interface Diagrams


Logical data models




User Requirements


Unadjusted Function Points for Data functions

At the end of this step, the ILF and EIF tables should be filled up.

Unadjusted Function Point Calculation


Sr. No. Name

of ILF

#RETs #DETs Complexity level (Tick one) UFPs

Simple Average Comple

x

Total ILF UFPs



Sr. No. Name

of EIF

#RETs #DETs Complexity level (Tick one) UFPs


x

Total EIF UFPs


FPA Steps for Transactional Function Types:

Each transaction must be an elementary process. An elementary process is the

smallest unit of activity that is meaningful to the end user in the business. It must

be self-contained and leave the business in consistent state.

T1. Application

documentation and transaction

rules are used to identify

transactions.

T2. The application

documentation and

transaction rules are used to

determine type of

transaction (external input,

external output, or external

inquiry).

T3. With the help of application documentation (data model and transaction

model) and transaction rules the number data elements and file type referenced

are determined.

T4. Each identified transaction is assigned a value of low, average or high based

upon type, data elements, and files referenced.

T5. A distinct numerical value is assigned based upon type and value (low,

average, or high).

T6. All transactions are summed to create a transaction unadjusted function point

count.

Transaction function types represent the functionality provided to the user to

process data by the application and comprise External Inputs(EI), External

Outputs(EO), and External Inquiries(EQ).


The complexities of EI,EO and EQ are determined by the number of Data Element

Types (DETs) and File Types Referenced (FTRs).

Examples of DET :

External Inputs: Data Input Fields, Error Messages, Calculated Values, Buttons

External Outputs: Data Fields on a Report, Calculated Values, Error Messages, and

Column Headings that are read from an ILF or EIF. Like an EQ and EO can have an

input side and output sides.

External Inquiries: Input Side - field used to search by, the click of the mouse.

Output side - displayed fields on a screen. DET’s for an EQ must come from either

an EIF or ILF.

DET’s for GUI

Using the strict definition of a data element provided by IFPUG’s Counting

Practices Manual. “A data element is a user recognizable, non recursive field.” In

GUI applications, a data element is information that is stored on an internal logical

file or that is used to invoke a transaction.

Radio Buttons

Radio Buttons are treated as data element types. Within a group of, a frame,

radio buttons the user has the option of selecting only one radio button; so only

one data element type is counted for all the radio buttons contained in the frame.

Check Boxes

Check Boxes differ from radio buttons in that more than one check box can be

selected at a time. Each check box, within a frame, that can be selected should

be treated as a data element.

Command Buttons

Command buttons may specify an add, change, delete or inquire

action. A button, like OK, may invoke several different types of

transactions.


According to IFPUG counting rules each command button would be counted as a

data element for the action it invokes. In practice this data element will not

impact the rating of the transaction, but it does help understand and dissect a

screen full of transactions.

A button like next may actually be the input side of an

inquiry or another transaction.

For example, a simple application to track distributors could have fields for

Distributor Name, Address, City, State, Zip, Phone Number, and Fax Number. This

would represent seven fields or (seven data elements) and the add command

button would represent the eighth data element. In short, the “add” external

input represents a one external input with eight data elements, the “change”

external input represents another external input with eight (seven data elements

plus the “change” command button), and the “delete” external input represents

the last external input with eight data elements (seven fields plus the “delete”

command button).

Display of Graphical Images or Icons

A display of a graphical image is simply another data element. An inventory

application, for example, may contain data about parts. It may contain part

name, supplier, size, and weight and include a schematic image of the part. This

schematic is treated as a single data element.

Sound Bytes

Many GUI applications have a sound byte attached. This represents one data

element. The number of notes played is simply recursive information. If the

length of the sound byte increases, then the data element remains one. For

example, you can play the “Star Spangled Banner” for two seconds or four

seconds, but you’ll still count the sound bytes as one data element. The longer it

is played the more recursive information it has.


Photographic Images

A photographic image is another data element, and is counted as one. A human

resource application may display employee name, start date, etc. and a

photograph of the employee. The photograph is treated the same as employee

name or employee start date. The photograph is stored and maintained like any

other piece of information about the employee.

Messages

There are three types of messages that are generated in a GUI application: error

messages, confirmation messages and notification messages. Error messages and

confirmation messages indicate that an error has occurred or that a process will be or have

been completed. They are not an elementary or independent process alone, but they are

part of another elementary process. A message that would state, “zip code is required”

would be an example of an error message. A message that would state, “are you sure you

want to delete customer” is an example of a confirmation message. Neither type of

message is treated as a unique external output, but each is treated as a data element for

the appropriate transaction.

On the other hand, a notification messages is a business type message. A

notification is an elementary process, has some meaning to the business user and

is independent of other elementary processes. It is the basis of processing and a

conclusion being drawn. For example, you may try to withdraw from an ATM

machine more money than you have in your account and you receive the dreaded

message, “You have insufficient funds to cover this transaction.” This is the result

of information being read from a file regarding your current balance and a

conclusion being drawn. A notification message is treated as an External Output.


External Input

An external input is to be counted for each instance where:

1. the input crosses the external boundary to come into the system

2. it causes some change in the data of the system

An external input has to be unique and not just an extension. If all the fields of a

business transaction cannot fit on one screen and therefore split into two screens,

the two screens count as a single External Input.

EIs may be input to the system through data entry screens, or input in terms of a

electronic files created by some other system.

An EI may reference ILFs (read or insert or update or delete) and EIFs (read only).

An FTR is counted for each ILF maintained by an EI. An FTR is counted for each ILF

or EIF read while processing an EI. A file that is both read and maintained by the

same EI is counted as one FTR for that EI. For example, an External Input may

update an internal logical file, but must also reference a “security file” to make

sure that the user has appropriate security levels. This would be an example of

two FTR’s.

DET is counted as a user recognizable unique and non-recursive field that is

maintained on an ILF by an EI.

Data Elements:

Unique sets of data elements help distinguish external input from other external

input. It is the set of DET’s combined that create the elementary process called

an EI. The following are examples of DET’s.

Data Input Fields

Calculated Values that are stored

Error Messages

Confirmation Messages

Recursive fields are only counted as one DET.

Action keys (command buttons such as OK, Next, so on and so forth)


Multiple Action Keys that perform the same function are counted only as one

DET

Rating:

Like all components, EI’s are rated and valued. The rating is based upon the

number of data element types (DET’s) and the file types referenced (FTR’s).

The table below lists both the level (low, average or high) and appropriate value

(3, 4 or 6 unadjusted function points).

Files Type Referenced

(FTR)

Data Elements

1-4 5-15 Greater than

15

Less than 2 Low (3) Low (3) Average (4)

2 Low (3) Average (4) High (6)

Greater than 2 Average (4) High (6) High (6)


A good source of information to determine external inputs is Screen Layouts,

Screen Formats & dialogs, and layouts of any input forms. Additional inputs from

other applications should be inventoried here. Inputs from other applications

must update internal logical files of the application being counted.

Screen Layouts

Screen Dialogs



User Requirements

Any Input Forms

Context Diagrams

Data Flow Diagrams


The following words are associated with external input or “inputs.” While reading

textual document or application description look for these type of words, they

may indicate an add, change or delete aspect of an external input.

Add

Activate

Amend (change and delete)

Cancel

Change

Convert (change)

Create (add)

Delete

Deassign

Disable

Disconnect (change or delete)

Enable

Edit (change)

Insert ( add and change)

Maintain (add, change, or delete)

Memorize (add)

Modify (change)

Override (change)

Post (add, change and delete)

Remove (delete)

Reactivate (change)

Remit

Replace (change)

Revise (change and delete)

Save (add, change or delete)

Store (add)

Suspend (change or delete)

Submit (add, change or delete)

Update (add, change or delete)

Voids (change and delete)


External Output

Typically, reports would be identified as External Outputs.

An External output is to be counted for each instance where :

1. the data crosses the external boundary to leave the system

2. it requires some processing in the system

External Outputs (EO) - an elementary process in which derived data passes

across the boundary from inside to outside. Additionally, an EO may update an

ILF. The data creates reports or output files sent to other applications. These

reports and files are created from information contained in one or more internal

logical files and external interface files.

Derived Data is data that is processed beyond direct retrieval and editing of

information from internal logical files or external interface files. Derived data is

usually the result of algorithms, or calculations. Derived data occurs when one or

more data elements are combined with a formula to generate or derive an

additional data element(s). This derived data does not appear in any FTR

(internal logical file or external interface file).

The definition states that an EO contains information, which derived data passes

across the boundary from inside to outside. Some confusion may arise because

an EO has an input side. The confusion is the definition reads data passes across

the boundary from inside to outside. The input side of an EO is search criteria,

parameters, etc does not maintain an ILF. The information that a cross from

outside to inside (input side) is not permanent data, but it is transient data. The

intent of the information coming from outside the application (input side) is not to

maintain an ILF.

Notification Messages are considered EO’s. A notification message differs from an

error message. A notification message is an elementary process, while an error

message (or confirmation message) is part of an elementary process. A

notification message is the result of some business logic processing. For

example, a trading application may notify a broker that the customer trying to

place an order does not have adequate funds in their account.


Derived Data displayed in textual fashion (rows and columns) and graphical

format is an example of two external outputs.

Data Elements:

Unique sets of data elements help distinguish one external output from another.

Keep in mind that a DET is something that is dynamic not a static field (A DET is a

unique user recognizable, non-recursive (non-repetitive) field).

Error Messages


Calculated Values (derived data)

Values on reports that are read from an internal logical file or external

interface file.

Recursive values or fields (count only once)

Generally, do not count report headings (literals) as data elements unless they

are dynamic. That is, if the report headings are read from files that are

maintained they may be DET’s also.

System generated dates that are on the tops or reports or are displayed are

normally not counted as DET’s. If system generated dates are part of

business information of the external output they should be counted as DET’s.

For example, the date an invoice is printed or the date a check is printed.

Unique FTR’s help distinguish one external output from another. An FTR must be

either an Internal Logical File and/or External Interface File. Each EO must have

at least one FTR (either ILF or EIF). If the EO does not reference at least one FTR,

then where did the information (DET’s) come from?

The elementary process associated with an external output may update an

internal logical file or external interface file. For example, the elementary process

that produces a payroll check may include an update to a file to set a flag to

indicate that the payroll check was produced. This is not the same as

maintaining the file. Maintained is the process of modifying data (adding,

changed and deleting) via an elementary process (via an External Input). The

primary intent of an EO is not to maintain an ILF.


Rating:

Like all components, EO’s are rated and valued. The rating is based upon the

number of data elements (DET’s) and the file types referenced (FTR’s). 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). DET’s and FTR’s were discussed earlier. The

table below lists both the level (low, average or high) and appropriate value (4, 5

or 7 unadjusted function points).

File Types Referenced

(FTR)

Data Elements


19

less than 2 Low (4) Low (4) Average (5)

2 or 3 Low (4) Average (5) High (7)



Report Layouts



User Requirements


Field Sizes and Formats

Graphical Report Layouts

The following words are associated with an “external outputs.” While reading

textual documents or application descriptions look for these types of words. They

may indicate an external output.

Browse

Display

Get

Reports

Request

Retrieve


On-lines

Output

Print

Query

Seek

Select

View


External Inquiries

EQ is a unique combination of an input and an output where the input causes the

immediate generation of the output. An EQ implies data retrieval.

EQ implies

1. no change is made to any internal data

2. the processing and output generation resulting from the input is

immediate.

External Inquiry (EQ) - 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 or maintain any FTR’s

(Internal Logical Files or External Interface Files) and the output side does not

contain derived data.

There are a lot of commonalities between an EO and EQ. Both have input and

output sides, but an EQ cannot have derived data. An EQ cannot update an ILF.

An EQ is basically a read from a FTR

Data Elements:

Unique sets of data elements help to distinguish one external inquiry from

another external inquiry.

Input Side

Click of a the mouse

Search values

Action keys (command buttons)

Error Messages

Confirmation Messages (searching)

Clicking on the an action key

Scrolling

Recursive fields are counted only once.

Outside

Values read from an internal logical file or external interface file

Color or Font changes on the screen


Error Messages


Recursive fields are counted only once.

The combined (unique) total input and outside DET’s are used when rating

EQ’s.

Like an EI, action keys that perform the same function but appear multiple times

are counted as only one DET.

Error Messages and confirmation messages can and do occur on either the input

side and/or output side. If a user initiates a search and a message is displayed,

“please wait searching” is an example of a confirmation message on the input

side. The message “all fields must be populated” is another example of an

error message on the input side. On the other hand, if the message is

“customer not found” is an example of an error message on the output side.

That is, the input side contained no problems. The database was searched and

the “error” has occurred on the output side of the transaction.

Unique FTR’s help distinguish one external inquiry from another external inquiry.

Every EQ must have at least one associated FTR (either ILF or EIF). If the EQ does

not have an associated FTR, then where did the information (DET’s that appear on

the EQ) come from?

Both the input side and output side must be considered when evaluating the

FTR’s used by an external inquiry. Normally they are the same but there are

instances where they may not be the same. The combined total should be used

when evaluating an EQ. For example, a security check may be done on the input

side of an external inquiry. The security check is done to make sure the user of

the application has the appropriate level of authority to view the data.

Rating:

Like all components, EQ’s are rated and valued. 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.

Functional rating table (shared table between EO and EQ)

File Types Referenced

(FTR)

Data Elements


19

less than 2 Low (3) Low (3) Average (4)

2 or 3 Low (3) Average (4) High (6)


EQ’s can contain business data, control data and rules based data.

Business Applications: An example of Business data is customer names,

addresses, phone number, so on and so forth. An example of Rules Data is a table

entry that tells how many days a customer can be late before they are turned

over for collection.

Drop Down List (a listing of customers by name) would be an example of an EQ.

A screen full of customer address information would be an example of an EQ.


Screen Layouts



Table Layouts

User Requirements


Pick lists



The following words are associated with an “external inquiry.” While reading

textual document or application description look for these type of words. They

may indicate an external inquiry.

Browse

Display

Extract

Fetch

Find

Get

Drop Down

Lists

Look Ups

On-lines

Output

Pick Lists

Print

Query

Scan

Seek

Select

Show

View

Reports


Unadjusted Function Points for Transaction functions

At the end of this step, the EI,EO and EQ tables should be filled up.


External Inputs(EIs)

Sr. No. Name

of EI

#FTRs #DETs Complexity level (Tick one) UFPs


x

Total EI UFPs


External Output (EO)

Sr. No. Name

of EO



x

Total EO UFPs



External Inquries (EQ)

Sr. No. Name

of EQ



x

Total EQ UFPs


Compute Unadjusted Function Points

The unadjusted function points for the system is calculated as follows :

UFP = UFPEI + UFPEO+ UFPEQ + UFPILF + UFPEIF

Rate on 14 General System Characteristics

Describe and define the concepts necessary to rate the General System

Characteristics (GSC’s) to determine the overall Value Adjustment Factor (VAF).

Multiplying the VAF by the unadjusted function point count equals the “adjusted

function point count.” Up to this point in time only the unadjusted function point

count has been discussed.

Definition:

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.

Rating:

The degrees of influence range on a scale of zero to five, from no influence to

strong influence. Each characteristic is assigned the rating based upon detail

descriptions provided by the IFPUG 4.1 Manual. 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


Tabulating:

Once all the 14 GSC’s have been answered, they should be tabulated using the

IFPUG Value Adjustment Equation (VAF) --

14

VAF = 0.65 + [( å Ci) / 100]

i =1

where: Ci = degree of influence for each General System Characteristic

. i = is from 1 to 14 representing each GSC.

å = is summation of all 14 GSC’s.

GSC’s at a Glance:

General System

Characteristic

Brief Description

1. Data communications How many communication facilities are there to

aid in the transfer or exchange of information

with the application or system?

2. Distributed data

processing

How are distributed data and processing

functions handled?

3. Performance Did the user require response time or

throughput?

4. Heavily used

configuration

How heavily used is the current hardware

platform where the application will be

executed?

5. Transaction rate How frequently are transactions executed daily,

weekly, monthly, etc.?

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

On-Line?

7. End-user efficiency Was the application designed for end-user

efficiency?

8. On-Line update How many ILF’s are updated by On-Line

transaction?

9. Complex processing Does the application have extensive logical or

mathematical processing?


10. Reusability Was the application developed to meet one or

many user’s needs?

11. Installation ease How difficult is conversion and installation?

12. Operational ease How effective and/or automated are start-up,

back up, and recovery procedures?

13. Multiple sites Was the application specifically designed,

developed, and supported to be installed at

multiple sites for multiple organizations?

14. Facilitate change Was the application specifically designed,

developed, and supported to facilitate change?

Considerations for GUI Applications

GSC items such as Transaction Rates, End User Efficiency, On Line Update, and Reusability

usually value higher for GUI applications than on traditional applications. On the other

hand, Performance, Heavily used configuration, multiple sites, will value lower for GUI

applications than traditional applications.


Compute the Adjusted Function Points

For a development project, the function point count is computed as

AFP = UFP x VAF

Where,

AFP = Adjusted Function Point

UFP = Unadjusted function point

VAF = Value Adjustment Factor

Function Point Calculation Summary is then prepared as follows :

Function Point Calculation Summary

VAF =

Function Type # of Functions UFPs AFP = UFP x VAF

Internal Logical Files (ILF)


Sub-Total for Data

Functions

External Input

External Output

External Inquiry

Sub-total for Transaction

functions

Total for System


5. Other Function Points Extensions

Mark II method

This method was developed by Mr. Charles Symons in 1988.

Mark II treats the system as a collection of logical transactions, where a logical

transaction is triggered by a unique event. Each logical transaction consists of

Input across the boundary (input data elements)

Processing involving stores data within the boundary (number of entities

referred)

Output back across the boundary (output data elements)

Each logical transaction is computed as :

Weight for input elements (Wi) x Number of input data elements

+ Weight for entities referenced (We) x Number of entities referenced

+ Weight for output elements (Wo) x Number of output data elements

For Version 1.3 of the model ,

Wi = 0.58, We = 1.66, Wo = 0.26

Sum this for all logical transactions to get MkII Function Point Index.

Six more GSC are defined viz.

15. Requirements of other applications

16. Security, Privacy and Auditability

17. User training

18. Direct use by third parties

19. Documentation

Using these 19 GSCs, degree of influence is calculated.

To compute Adjusted MkII Function Point , Technology Complexity Adjustment

(TCA) is calculated.

TCA = 0.65 + C * (sum of degree of influence for the characteristics)

Where C = 0.005.


Adjusted MkII Function Point = MkII FPI * TCA.

Feature Points

The feature point method is a superset of the function point method. It is used

widely for scientific systems.

It makes use of an additional component , Algorithms , adding to the set of the

five FP components. The algorithm component is assigned a weighted value of 3.

When using this method, IFPUG values attached to internal files are reduced.

Object Points

In the object point model, the term object is used for objects like screens, reports

and 3GL componenets.

Screens are classified on the number of views and sources while reports are

classified based on the number of sections and sources. Weight are used for all

three types to determine the total object point count.

Once the object points are obtained, the percentage reuse is estimated.

Depending on the percentage reuse, the New object points (NOP) are computed

next.

NOP = (Object points) x (100- %reuse) / 100

This model closely works with COCOMO II model of effort estimation.


6. Effort, Cost, Schedule Estimates

Once the software size is known, the next step in estimation process is to

determine the effort it will take to make the software and the calendar time that

is required to complete the project. To determine the effort required, productivity

of the organization is required to be known.

Productivity

The definition of productivity is the output-input ratio within a time period with

due consideration for quality.

Productivity = outputs/inputs (within a time period, quality considered)

The formula indicates that productivity can be improved by (1) by increasing

outputs with the same inputs, (2) by decreasing inputs but maintaining the same

outputs, or (3) by increasing outputs and decreasing inputs change the ratio

favorably.

The output of a software project is functionality or function points. The input is

the effort required to develop the functionality.

Software Productivity = Function Points / Effort of project team

Many organizations over the years build up productivity rates for Function Points

per person month/person day for the various development environments they

work on and then use these productivity figures from effort estimation. Many

research organizations like Software Productivity Research publish productivity

figures for the use by software industry.

Factors impacting Productivity

Size and Effort

Data from many projects has shown that productivity and size are inversally

proportional to each other. As the size of the software increases, the number of


components of the software and the interfaces among these components also

increase. Thereby, affecting the productivity adversely.

Schedule and effort

Schedule is estimated by assuming a team size and dividing the estimated effort

by the assumed team size. The basic principle is man and months are not

interchangeable. As the team size grows, communication channels increase

thereby generating more noise between knowledge transfer.

Also, software activities require specific skills hence the tasks are not

interchangeable easily.

Quality Versus Effort and Schedule

If high quality software is desired, then the software engineering process followed

to build the software needs to be more systematic & rigorous. That means :

1. A higher effort and longer schedule is required to incorporate the quality

related activities like reviews, testing which are required to produce high

quality software.

2. A undue reduction in effort and schedule will result in poorer quality of

software. This is due to less time allotted to the quality activities to

manage the schedule for completing life cycle activities.

Other Factors

In addition to above factors, following are some of the factors which also have

significant impact on the productivity.

1. Availability and stability of development environment

2. Team skill, capability and experience

3. Process maturity

4. Employee turnover

5. Software reusability etc.

So, any estimation model we select must take into consideration

1. inversely proportionate relationship between size & effort

2. impact of schedule underestimation on productivity

3. expected software quality attributes

4. impact of other factors on productivity


Approach to Effort and schedule Estimation

Bottom-up estimation technique takes the realm of Project planning. The project

is broken into smaller activities and tasks. An effort is made for each lower level

task. The effort estimates of all low level tasks are added to give estimate for the

phase and the project.

Work Breakdown Structure(WBS)

The WBS becomes the basis for bottom-up estimation approach. While

constructing the software WBS, there are two hierarchies to consider.

1. Product hierarchy

2. Process hierarchy

The process used to build WBS is iterative. The WBS gives us the tasks that need

to be estimated and scheduled. Effectiveness of WBS depends on the

completeness of the task list. Apart from the normal project activities and

components, one should include

1. Preparation and review of documents activity

2. Project planning and tracking

3. Client interactions

4. Project specific training

Having obtained this task list, each task is then estimated. The inter task

interdependencies are next understood using techniques like PERT-CPM and

schedule is made taking into account the effort required for the task and

dependencies between tasks.

Cost Estimation

Understanding Different Costs:

A fixed cost is a cost that remains constant, in total, regardless of changes in

activity. Consequently as the activity rises or falls fixed costs remain constant.


The capital expenditure on PC’s for a software project is considered a fixed cost.

Salaries paid to software develops can be treated as fixed costs for the

organization because the salaries remain constant and must be paid regardless of

productivity levels. A variable cost is a cost that varies, in total, in direct

proportion to changes in the level of activity. The activity can be expressed in

many ways such as number of hours. Software metrics are concerned with

project costs and not overall organizational costs. Hence software development

has very low fixed costs, but very high variable costs.

Overhead costs are those cost that cannot be directly attributed to a particular

software project. For example, the cost to keep the LAN up in running is an

overhead cost. Executive salaries would be another example of overhead costs

since their salaries cannot be attributed to a specific project.

Average cost is total cost divided by to number of units produced. Total costs

for a project divided by the number of function points gives us the dollars per

function point. Average hours are the total number of hours divided by the total

number of function points, which yields hours per function point. Marginal cost

is the change in total cost attributable to a one-unit change in output. Another

characteristic is that as software projects become large marginal cost goes up.

That means that unit costs rises as software projects become larger. There are

not many economies of scale with the development of software.

When software projects are estimated all direct and indirect costs need to be

included in the cost of the software project. Direct materials are those materials

that are directly related to the development of a software project. Indirect

materials are those materials that are not directly related to the cost of the

software development project. An example of indirect costs is the cost to run and

maintain an internal network. Direct labor is labor costs that can be traced to an

individual task associated with the development, maintenance or enhancement of

a software product. Indirect labor cannot be traced to a specific task associated

with the software project.

Cost Estimation Sheet


Component Item Quantity in

person-

days

Rate/

Person-day

Cost Remarks

Personnel

Resources

Programmer/Tester

Analyst/Designer

Project Leader

Project Manager

Quality team

Hardware

Software

Communicatio

n

Travel & Stay

Project team

training

Other items External

Consultant

Recruitment

Books/magazines

Conveyance

Subtotal

Add Buffer

Total


7. Making the estimation process effective

Organisations process maturity governs the effectiveness and maturity with which

they handle estimation. Typically, organizations at level 1 of maturity start with

little or no procedures for estimation. With more experience and project

difficulties, the need to have better processes for estimation is felt and the

processes are established and improved.

Estimation Process improvement

Improvement of estimation process has three dimentions :

1. Estimates calculation

This covers estimating size, effort, cost and schedule and reviewing these

estimates in a project at the project initiation phase.

2. Monitoring and tracking estimates

This covers the monitoring and tracking estimates as the project

progresses and take action. Metrics collected on size, effort and schedule

variance thru project status reports and milestone reports.

3. Estimation process establishment

This includes setting up of consistent estimation processes, measuring the

capability of these processes, re-using data from estimation database,

bringing in new technology into the estimation process and managing

changes to the process in a controlled manner.

The process of estimation can be made more effective as follows :

1. Active participation of Sr. Management thru reviews of estimation related

activities for process compliance.

2. Independent SQA group reviews estimation related activities for process

compliance.

3. Identification of person responsible for estimation, for tracking the actual

data against planned and for re-estimation.

4. Tools required to facilitate estimation, to track actual data and to re-

estimate are explicitly defined, made available and used.

5. Persons performing estimation and its tracking are trained in the

application domain and the estimation process.


6. Tools and resources are made available to be able to maintain up-to-date

database of the past projects that is used for estimation.

A high maturity estimation process

Database for Estimation

To have the effective estimation done, past project data and statistics are of

immense help. The database used for estimation could be :

1. Industry-wide database of completed software projects

2. Database of organisation’s own completed projects


Process improvement

Estimation Processes

Procedures, Templates,

Guidelines, Checklists,

Tools/methods

Size Estimation

Effort Estimation

Schedule Estimation

Cost Estimation

Monitoring and tracking

estimates thru Project

status meetings

Organisationwide

Database of projects

Estimate

Database Contents

Following is the type of data an organization should build to develop organization-

wide database of completed projects. This data is gathered by projects during the

project tracking and also at the project closure.

1. Project Application domain

2. Project deliverables

3. Project life cycles and phases

4. Project development platform

5. Project Size (estimated and actual)

6. Project effort (estimated and actual)

7. Project schedule (estimated and actual)

8. Project Characteristics (GSM related)

9. Project task breakdown

10. Project development approach

11. Risk related information

12. Quality related data

Estimation Tools

Tool Website

Function Point Workbench www.spr.com

PQMPlus www.uptweb.com

Function Point Manager www.abtcorp.com


http://www.abtcorp.com/

http://www.uptweb.com/

http://www.spr.com/

8. Industry Resources

Brief History:

Function Point Analysis was developed first by Allan J. Albrecht in the mid 1970s.

It was an attempt to overcome difficulties associated with lines of code as a

measure of software size, and to assist in developing a mechanism to predict

effort associated with software development. The method was first published in

1979, then later in 1983. In 1984 Albrecht refined the method and since 1986,

when the International Function Point User Group (IFPUG) was set up, several

versions of the Function Point Counting Practices Manual have been published by

IFPUG.

Growth and Acceptance of Function Point Analysis

The acceptance of Function Point Analysis continues to grow. This is indicated by

the growth of the International Function Point User Group (IFPUG). Since 1987

membership in IFPUG has grown from 100 members to nearly 600 members in

1997. Additionally, in less than six years conference attendance has grown from

125 in 1988 to over 300 by 1997. Examination of IFPUG clearly indicates that the

majority of its is members are from North America, but Function Point analysis

growth outside North America is strong. This is evident by the growing number

of function point organizations worldwide. There are numerous affiliate

organizations of IFPUG. There are affiliate organizations in Italy, France,

Germany, Austria, India, The Netherlands, Australia, Japan, and several other

countries.

More Information about IFPUG:

More information about joining IFPUG, conferences, committees can be obtained

by contacting the IFPUG.

Website: www.IFPUG.Org

Email: [email protected]

Weblinks

www.softwareMetrics.com


http://www.softwareMetrics.com/

www.qaiindia.com

www.iso.ch

www.sei.cmu.edu

www.isbsg.org.au (Benchmarking)

This document takes the inputs from FPA counting manual by IFPUG.


http://www.isbsg.org.au/

http://www.sei.cmu.edu/

http://www.iso.ch/

http://www.qaiindia.com/

Date post:	23-Nov-2014
Category:	Documents
Upload:	shilpwagh
View:	457 times
Download:	4 times