copyright © 2002. the david consulting group, inc. 1 understanding and effectively using functional...

1Copyright © 2002. The David Consulting Group, Inc.

UNDERSTANDING and

EFFECTIVELY USINGFUNCTIONAL MEASUREMENT

Presented ByThe David Consulting Group

www.davidconsultinggroup.com

Stevens Institute of Technology


Function Point Overview

Effective Use of Function Points

Establishing a Function Point Program

PRESENTATION HIGHLIGHTS


FUNCTION POINT OVERVIEW

The Need for Sizing

The Function Point Methodology

A Sample Count


CRITICAL SOFTWARE ISSUES CRITICAL SOFTWARE ISSUES

Understanding the Customer’s Requirements

Effectively Sizing the Requirements

Accurately Estimating the Deliverable

Managing a Successful Delivery

PROCESS


THE NEED FOR SIZINGTHE NEED FOR SIZING

Quantitative (Objective) Measure

Basis for Comparison

Manage Expectations (Value)

Satisfies SPI Requirements


CHARACTERISTICS OF AN EFFECTIVE SIZING METRICCHARACTERISTICS OF AN EFFECTIVE SIZING METRIC

Meaningful to developer and user

Defined (industry recognized)

Consistent (methodology)

Easy to learn and apply

Accurate, statistically based

Available when needed (early)


TYPES OF SIZING METRICSTYPES OF SIZING METRICS

Lines of Code

Artifacts

Function Points

Common Sizing Metrics


MEASURING WITH LINES OF CODE

Can be counted consistently within organization

Available late in the life cycle

Lines of code not always available

No industry standard for counting lines of code

Limited ability to compare among various language groups

Internal use only, not meaningful to customer

The Pros and Cons of Using SLOC


SIZING FROM ARTIFACTS

Determine size (and estimate) based on an evaluation of existing or planned artifacts

Artifacts may include:

Document size

Number of screens, reports

Programs/modules

WBS


FUNCTION POINTS

Consistent method

Easy to learn

Available early in the lifecycle

Acceptable level of accuracy

Meaningful internally and externally

Results are normalized across different environments

Function Point Analysis is a standardized method for measuring the functionality delivered to an end user.


Function Point Analysis is a standardized method for measuring the functionality delivered to an end user.

Function Point Counts have replaced Lines of Code counts as a sizing metric that can be used consistently and with a high degree of accuracy.

FUNCTION POINTS IS AN EFFECTIVE SIZING METRIC


A vehicle to estimate cost and resources required for software development, enhancement and maintenance

A tool to quantify performance levels and to monitor progress made from software process improvement initiatives

A tool to determine the benefit of an application to an organization by counting functions that specifically match requirements

A tool to size or evaluate purchased application packages

BENEFITS OF USING FUNCTION POINTS


Purpose• To promote and encourage use of Function Points• To develop consistent and accurate counting guidelines

Benefits• Networking with other counters• IFPUG Counting Practices Manual• Research projects• Hotline• Newsletter• Certification

Utilization• Member companies include all industry sectors• Over 1200 members in more than 30 countries

INTERNATIONAL FUNCTION POINT USERS GROUP (IFPUG)


FUNCTION POINT ANALYSIS

Definition

Standard method for measuring software development from the customer’s point of view

Quantifies functionality provided to the user based primarily on logical design

Objectives

Measure software development and maintenance independently of technology used for implementation

Measure functionality that the user requests and receives


FUNCTION POINT ANALYSIS - A LOGICAL VIEW

Physical

Lines of code or

programs/modules

Physical database or files

Physical transactions (screens)

Logical

Functionality required

Logical groups of user data

Business processes


THE FUNCTION POINT METHODOLOGY


External Inputs

External Outputs

External Inquiries

Internal Logical Files

External Interface Files

External Input

External Inquiry

External Output

InternalLogical

Files

External Interface

File

Five key components are identified based on logical user view

Application


LOGICAL VIEW OF USER REQUIREMENT

USER

LIST OF MOLDSWORK CENTERS

PARTS

PLANT MOLDS

PLANT INFORMATION CENTER

USER

BILL OF MATERIALS

PARTS LISTING

USER

ORDERPARTS

USER

CHANGEBILL

External Inquiries


External Output

External Inputs

InterfaceVENDORSUPPLY

VENDOR INFORMATION


Complexity

RecordElement

Types

Data Elements (# of unique data fields)

or File Types Referenced

Low Average High Low

Low Average

HighAverage High

Components: Low Avg. High Total

Internal Logical File (ILF) __ x 7 __ x 10 __ x 15 ___

External Interface File (EIF) __ x 5 __ x 7 __ x 10 ___

External Input (EI) __ x 3 __ x 4 __ x 6 ___

External Output (EO) __ x 4 __ x 5 __ x 7 ___

External Inquiry (EQ) __ x 3 __ x 4 __ x 6 ___

___Total Unadjusted FPs

Data Relationships

Each identified component is assigned a Function Point size value based upon the make-up and complexity of the data

1 3

3




General System Characteristics

Data Communication On-Line Update

Distributed Data Processing Complex Processing

Performance Objectives Reusability

Heavily Used Configuration Conversion & Install Ease

Transaction Rate Operational Ease

On-Line Data Entry Multiple-Site Use

End-User Efficiency Facilitate Change

The final calculation is based upon the Unadjusted FP count X VAF

14 General Systems Characteristics are evaluated and used to compute a Value Adjustment Factor (VAF)




WHEN TO COUNT FUNCTION POINTS

CORRECTIVEMAINTENANCE

PROPOSAL DESIGN TESTING DELIVERY REQUIREMENTS

CONSTRUCTION

SIZING

Initial UserRequirements

Initial TechnicalRequirements

FinalFunctionalRequirements

FeasibilityStudy

SIZING SIZING

ChangeRequest

ScopeAdjustment

SIZING SIZING


BASIC COUNTING PROCESS

Determine the type of function point count

Identify the boundary for counting

Count the data function types

Count the transactional function types

Determine the Function Point count


Definition:

Indicates the border between the project or application being measured and external applications or user domain

Functionality: What Does a User See?

Data going into an application -- inputs

Data coming out of an application -- outputs, inquiries

Data, inside or outside an application -- logical files

Data

Data

InputsOutputs

Application

References/Feeds

IDENTIFY THE BOUNDARY FOR COUNTING


An External Input (EI) processes data that comes from outside the application’s boundary.

1.0

Transaction

ON-LINE ENTRY

Multi-Screen

UPDATECUSTOMER

INFORMATION

CUSTOMER INFO FILE

DEFINITION OF AN INPUT

External Input


DEFINITION OF AN OUTPUT

An External Output (EO) generates data that is sent outside the application boundary.

END USER

Summary SUMMARIZECUSTOMER

INFO

1.0

CUSTOMER INFO FILE

External Output


DEFINITION OF AN INQUIRY

An External Inquiry (EQ) is an output that results in data retrieval. The result contains no derived data.

DISPLAYCUSTOMER

INFO

1.0

END USER

Selected Customer

Info

CUSTOMER INFO FILE

External Inquiry


DEFINITION OF A FILE

An Internal Logical File (ILF) is a user-identifiable group of logically related data that is maintained within the boundary of the application.

UPDATECUSTOMER

INFO

1.0

CUSTOMER INFO FILE

END USER

Customer Info

Updated Customer Info

Internal Logical File


DEFINITION OF A INTERFACE FILE

An External Interface File (EIF) is a user-identifiable group of data referenced by the application, but maintained within the boundary of another application.

UPDATES

ZIP CODE TABLE

ENDUSER

1.0

VALIDATEZIP CODE &

UPDATE CUSTOMER

INFO

CUSTOMER INFO FILE

UPDATES

VALID ZIP CODES

External Interface File



Internal Logical File (ILF) X 7 2 X 10 1 X 15 35

External Interface File (EIF) X 5 X 7 X 10 0

External Input (EI) X 3 X 4 2 X 6 12

External Output (EO) 1 X 4 X 5 X 7 4

External Inquiry (EQ) X 3 2 X 4 X 6 8 59

COMPONENTS ARE ASSESSED BASED UPON COMPLEXITY:

Data Element Types (Fields or Attributes)

File Types Referenced (ILFs or EIFs) Record Element Types (Data Sub-Groups)

Function Point Count

Complexity

DETERMINE THE FUNCTION POINT COUNT


AN EXERCISE IN COUNTING

External Input

External Inquiry

External Output

InternalLogical

Files

External Interface

File

Application


USEFUL PROJECT/APPLICATION DOCUMENTATION

High Level System Diagrams

Logical Data/Process Models

Entity Relationship Models

Design Specifications

Requirements

Functional Specifications

Detailed Design

Layouts of Files and Databases

On-Line Screen Prints

User Manuals


LOGICAL VIEW OF USER REQUIREMENT

USER

ADD, CHG INVOICES

PAYMENTS

VENDOR

INVOICES

ACCOUNTS PAYABLE

USER

PAYMENTS

USER

PAYMENTSTATUS

USER

PAIDINVOICES

PURCHASEORDER INFO

PURCHASEORDERSYSTEM


Definition:

Indicates the border between the project or application being measured and external applications or user domain

APPLICATION BOUNDARY

USER

ADD, CHG INVOICES

PAYMENTS

VENDOR

INVOICES

ACCOUNTS PAYABLE

USER

PAYMENTS

USER

PAYMENTSTATUS

USER

PAIDINVOICES

PURCHASEORDER INFO

PURCHASEORDERSYSTEM

External Interface FileExternal Inputs

External Input

External Inquiry

External Output




Internal Logical File (ILF) X 7 3 X 10 X 15 30

External Interface File (EIF) X 5 1 X 7 X 10 7

External Input (EI) X 3 3 X 4 X 6 12

External Output (EO) X 4 1 X 5 X 7 5

External Inquiry (EQ) X 3 1 X 4 X 6 4 58

COMPONENTS ARE ASSESSED BASED UPON COMPLEXITY:

Data Element Types (Fields or Attributes)

File Types Referenced (ILFs or EIFs) Record Element Types (Data Sub-Groups)

Function Point Count

Complexity

DETERMINE THE FUNCTION POINT COUNT


COMMON CRITICISMS WITH FUNCTION POINTS

FP methodology terms are confusing

Too long to learn, need an expert

Need too much detailed data

Does not reflect the complexity of the application

“I did more work than I am getting credit for”

Does not fit with new technologies

Takes too much time

We tried it before


EFFECTIVE USE OF FUNCTION POINTS

Requirements Management

Estimating

Benchmark Comparisons

Managing Change


Functionality requested by the user may be organized into

logical parts that match the five function point components

MANAGING REQUIREMENTS

USER

ADD, CHG INVOICES

PAYMENTS

VENDOR

INVOICES

ACCOUNTS PAYABLE

USER

PAYMENTS

USER

PAYMENTSTATUS

USER

PAIDINVOICES

PURCHASEORDER INFO

PURCHASEORDERSYSTEM

External Interface FileExternal Inputs

External Input

External Inquiry

External Output



DEFINITION CAPABILITY ESTIMATE

Sc

he

du

le

Effort Costs

PROJECTSIZE

X X RISKFACTORS

PROJECTCOMPLEXITYREQUIREMENT

ESTIMATING MODEL

SLOCArtifacts

FUNCTION POINTS


COMPLEXITY FACTORSCOMPLEXITY FACTORS

Estimates are influenced by size and other factors such as complexity variables noted below:

Logical and mathematical algorithms Code structure Data relationships Reuse Memory Security Warranty


RISK FACTORSRISK FACTORS

Estimates will also vary based upon a variety of

risk factors: Technology Applied such as tools, languages, reuse, platforms Process/Methodology including tasks performed, reviews,

testing, object oriented Customer/User and Developer skills, knowledge, experience Environment including locations, office space System Type such as information systems; control systems,

telecom, real-time, client server, scientific, knowledge-based, web

Industry such as automotive, banking, financial, insurance, retail, telecommunications


DEFINITION CAPABILITY ESTIMATE

Sc

he

du

le

Effort Costs

PROJECTSIZE

X X RISKFACTORS

PROJECTCOMPLEXITYREQUIREMENT

ESTIMATING MODEL

PROFILE

Data RelationshipsCode StructureAlgorithmic Compl.Performanceetc.

TechnologySkill LevelsSQAProject Managementetc.


QUALITATIVE ASSESSMENT

MEASURE ASSESS

SizeEffort

DurationDefects

EnvironmentDefinition

DesignBuildTest

Management

PerformanceProductivity

CapabilityProfiles

Software Excellence


D

DEVELOPING A BASELINE OF DATA

ProductDeliverable Performance

IndicatorsRiskFactors

Time to Deliver - Duration - Number of days

ManagementDefinitionDesignBuildTestEnvironment

SIZEPRODUCTIVITYMEASURES

PROFILES

PROFICIENCIES

INADEQUACIES

A

BC

D

A

BC

D

:

136

276

435558759

10 mnths

11 mnths10 mnths26 mnths32 mnths


Rate of DeliveryFunction Points per Person Month

0200

400600800

100012001400

1600

180020002200

0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36

SoftwareSize

ESTABLISHING A BASELINE

Performance Productivity

A representative selectionof projects is measured

Size isexpressedin terms of functionalitydelivered to theuser

Rate of delivery is a measure of productivity

Organizational Baseline


MONITORING IMPROVEMENTS

Track Progress


0200

400600800

100012001400

1600

180020002200

0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36

SoftwareSize

Year 2 grouping of projects


COMPARISONS TO INDUSTRY

Industry Baseline Performance


0200

400600800

100012001400

1600180020002200

0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36

SoftwareSize


ESTIMATING USING DELIVERY RATES

PROJECTSIZE =DELIVERY

RATE

ESTIMATES

– EffortPROJECT

COMPLEXITY

DEFINITION CAPABILITY

Function Points Profiles


ESTIMATING BEST PRACTICESESTIMATING BEST PRACTICES

The Software Engineering Institute (SEI) requirements for good estimating: Corporate historical database Structured processes for estimating product

size and reuse Mechanisms for extrapolating benchmark

characteristics of past projects Audit trails Integrity in dealing with dictated costs and

schedules Data collection and feedback processes foster

correct data interpretation


ESTIMATING PROCESS

SIZEREQUIREMENT

REQUIREMENT

Analyst

ESTABLISHPROFILE

SELECT MATCHING

PROFILE

GENERATE ESTIMATE

WHAT IFANALYSIS

ACTUALS

Counter ProjectManager Software PM / User Metrics

DataBase

Plan vs. ActualReport

ProfileSize Time

The estimate is based on the best available information.A poor requirements document

will result in a poor estimate

Accurate estimating is a function of using historical data with an effective

estimating process.


CHANGE OF SCOPE MANAGEMENT

Initial InterimEstimate Estimate Estimate Variance

Function Points 500 650 +150

Effort (months) 33 43 +10

Schedule (months) 11 14 +3

Staffing Levels (FTE) 3 3 -0-

Production Rate (FP/mo) 15 15 -0-


Change of Scope Inputs Outputs Inquiries Files Interfaces Total

Add vendor function 6 - 4 3 2 100

Graphical display - - 5 - - 20

Banking System 3 1 1 1 - 20

Mandatory Changes - 2 - - - 10

Total 150

COMMUNICATING CHANGES IN SCOPE

Function Point

Change of Scope Summary


Additional Additional AdditionalFP Effort Cost Schedule

Change in Scope Count (staff mo.) ($000)___ (calend. mo.)

Add Vendor Function 100 7 100 2.0

Graphical Displays 20 1.2 20 .4

Banking System 20 1.2 20 .4

Mandatory Changes 10 .6 10 .2

Total 150 10 $150 3.0 mos.

COMMUNICATING IMPACT AND OPTIONS

OPTIONS

1. Increase funding level and schedule

2. Reduce functionality, or do not accept change

3. Trade off quality and maintenance costs for schedule

4. Delay delivery of change


FUNCTION POINT PROGRAM

Organizational Needs

Benchmark Performance

Measurement Selection

Roadblocks


A SUCCESSFUL SOFTWARE MEASUREMENT PROGRAM

FOCUS ON BUSINESS NEEDS ESTABLISH PERFORMANCE LEVELS PLAN WHAT TO MEASURE DEFINE A MEASUREMENT PROCESS BUILD A STRONG INFRASTRUCTURE AUTOMATE


BUSINESS NEEDS: SELECTION CRITERIA FOR MEASUREMENT

Align with business needs and the needs of the development organization

Select only a few metrics to implement initially

Create measures that are realistic and measurable

Use industry standard metrics to facilitate comparisons

Allow metrics to change and evolve as the organization matures


FOCUS ON BUSINESS NEEDS

Use of Goal-Question-Metric paradigm helps to identify the “right” measures

Goal: Ensure that the correct goals are identified in support of the organization’s business drivers

Question: Validated goals through a series of questions that ensure that the data collected will effectively measure the strategic goals

Metric: The result is a metrics positioning statement which describes how the identified metrics support strategic business goals


DETERMINE ORGANIZATION OBJECTIVES FOR EACH GOAL

Example of using the Goal-Question-Metric paradigm

Goal Improve application development productivity

Questions Do we have a methodology for tracking productivity? Do we want to collect data on new and/or enhancement

projects? Do we have time tracking capabilities?

Metric By tracking the hours throughout the life cycle of a project,

we can use the productivity rate metric to determine if we are meeting our goal


BASELINE CURRENT LEVELS OF PERFORMANCE

What is baselining?• A process involving the collection, analysis and reporting of

performance data

A performance baseline will: Establish a "stake in the ground" from which improvement

programs can be identified Display qualitative data regarding the effectiveness of the

techniques and methods currently being used Permit the measurement of the impact of new tools, techniques

and methods

SSB Baseline Levels of performance were established for productivity, work

effort, duration and staffing levels


BASELINE CURRENT LEVELS OF PERFORMANCE

PERFORMANCEPRODUCTIVITY

CAPABILITIES

PERFORMANCE

SOFTWAREPROCESS

IMPROVEMENT

TIME TO MARKET

EFFORT

DEFECTSMANAGEMENT

SKILL LEVELS

PROCESS

TECHNOLOGYPRODUCTIVITY

IMPROVEMENT INITIATIVES / BEST PRACTICES

RISKS

MEASUREDBASELINE

0.00

5.00

10.00

15.00

20.00

25.00

30.00

35.00

0 100 200 400 800 1600 3200 6400

SubPerformance

BestPractices

IndustryAverages

Organization Baseline


PLAN WHAT TO MEASURE

Customer based metrics-- impact, value added

Delivery metrics – responsiveness, quality

Project metrics – effort, cost, duration

Demand metrics -- backlog, type of work


IMPACT MEASURES

Measure Name Calculation Notes Example Median

Industry Median)

primarily Level 3 organizations

Goal by 2003

Estimating Accuracy - Effort

(actual labor hours - estimated) / estimated

positive values represent overruns; negative underruns

(1000-500)/500 = +100% overrun +22% 0% 18%

Estimating Accuracy - Schedule

(actual calendar months - estimated) / estimated

positive values represent overruns; negative underruns

(4 - 3)/3 = +33% overrun +21% 0% 18%

Unit Cost dollars / function points

Dollars are estimated from labor hours @ $110 per hour

* 145 hrs per staff month$200,000/100 =

$2,000 $938 $613 $800

System Delivery Rate

function points / calendar months

QSM value is a mean - median not available

100 FPs/ 2 calendar months =

50 32 49 40

Requirements Volatility

added, changed, deleted / total baselined rqts

For all but one project, data not available. Project

manager gave an estimate10 changed / 100 baselined = 10% 20% 10% 15%

Client Satisfaction ratings by project manager

For all but three projects, ratings by clients

unavailable.

5 = very satisfied 1 = very

unsatisfied 4 Not available 4

System Test Effectiveness

defects found in system test / total defects

total defects = defects found in system test + defects

found in production (first 30 days) 40 / 50 = 90% 83% 90% 90%

Delivered Defect Density (Defects per 100 function points)

(defects found in production / function points) * 100 production = first 30 days

(5 defects / 200 FPs) * 100 = 2.5 2.3 1.3 1.8

20100 FPs/4 staff

months = 25 17 26Productivity function points / labor months varies with project size


MEASUREMENT MATURITY

Measures:

Purpose:

Business Metrics

Customer Metrics

Technology Metrics

Project Focused Customer Focused Business Focused

IT Efficiency Organizational Impact Business Impact

Level 1 Level 2 Level 3

Effort/CostPlan vs. ActualProduction ProblemsOperational

Customer SatisfactionTime to MarketSize and ComplexityPortfolio ManagementDefect Tracking

Cost ReductionIncreased Profitability Revenue GenerationProcess Improvement


Recognizing And Overcoming Roadblocks, Challenges And Hurdles

In order for your metrics program to not only survive, but flourish, adhere to the following: Always have management and executive support Choose your metrics personnel carefully, making sure that:

They will be enthusiastic supporters of the program They have the determination to see the program succeed They have the tenacity to keep pursuing individuals and project

teams who are not cooperative Properly set and manage expectations

Takes six months to begin collecting data, takes six more months to have data accuracy


Be consistent and persistent Make sure that everyone understands that this is not just “the

flavor of the month” and that the metrics program is there to stay

Educate! Personnel includes executives, management, project leaders and

the project team Subjects include function points and metrics

Share success Communicate success stories to everyone in the organization



Most Important…

Participants need to know what’s in it for them Project team members need to be shown how the

correct utilization of metrics can help them institute processes that will go a long way in creating projects that are “better, cheaper, faster”

This in turn can translate into project team recognition and rewards



INFRASTRUCTURE ORGANIZATIONAL ISSUES

Organizing for a Successful Function Point Program

Centralization vs DecentralizedFunction Point counting is provided as a service vs. everyone(Project Managers) does the counting

Policy and ProceduresPolicies define what gets counted (type, size)Procedures define how it gets counted (guidelines, lifecycle)Determine what gets counted

ResponsibilityWho in the organization is involved in counting and what level of expertise do they require

CertificationFunction Point Certification (CFPS) - IFPUG.org

ToolsCounter, DDB Software Function Point Workbench, Charismatek

copyright © 2002. the david consulting group, inc. 1 understanding and effectively using functional...

Documents

david consulting group

function point counts

early slide

sloc slide

effective sizing metric

end user

sample count slide

user requests