function point overview (1)

8/10/2019 Function Point Overview (1)

1/47

An Overview of Function Point Metrics

For

Software Engineering


2/47

Introduction

Function Point History

Function Point Variations

Problems with Lines of Code

What are Function Points?

Objectives of Function Points

How do Function Points Overcome LOCProblems?


3/47

Uses of Function Points

When Should You Count Function

Points?Who Should Count Function Points?

Function Point Counting

Function Point Counting ExampleReferences


4/47


5/47

Controls The Other Factors

Reduce Scope to Reduce Size and Complexity?

Bound The Problem

Manage Scope Early Develop Clear and Crisp Requirements

Design Adaptable Architecture

Build Models Before Committing to Code

We can still be Agile

Bound the Problem

Clear Use Cases


6/47


7/47

Architecture

Degree of Coupling

Interoperability

Linguistic Models

How many different programming

languages?

Human Factors

Use cases

and use case actors


8/47

Software Metric Techniques

Lines of code (KSLOC)

Estimate Relative DifficultyFunction points

Feature point

Wild (A) Guess


9/47

Varies by Programming Language

KSLOC

How Do We Determine Estimate?

What Does It Tell Us?

1. KSLOC does not inform about quality.

2. Large KSLOC might imply inefficient programming.

3. Cannot judge language choice by KSLOC


10/47


11/47

Level estimate according program typeReport generating program versus

Master-file update program

Consider Simple Scale 1 to 10Real-time with hard deadlines = 10

Creating a simple, line-by-line report = 1

Everything in between = 2 through 9 Useful in Agile Methods

Good for first level estimates


12/47

Developed in Aerospace Industry Boeing and others

More Detail Later in this Presentation

Alternative to Function Point Metrics


13/47

Developed At IBM

Albrecht, et al More Detail Later in this Presentation


14/47


15/47

Allan Albrecht, late 1970s at IBMRefined, ~1980s, GUIDE (IBM)

IFPUG founded late 1980s

~ 1988 IFPUG Counting Practices Manual1994, IFPUG, Release 4.0 the manual

1999 IFPUG, Release 4.1

Now IFPUG Conferences Used by Large Organizations

Still Controversial


16/47

Mk II Function Points

Discovered weaknesses in Albrecht's approach

Feature Points

Function points were not working for all classes of

applications

3D Function Points

Designed to solve two problems with Albrecht approach


17/47


18/47

Quantify Design based onLogical Design Functional Specifications

Quantifies in terms of:Functions system delivers to the user Relationships of those functions

Properties of each function

Independent of:the computer language, development methodology,

technology

capability of the project team


19/47

Measure business applicationsSmall of know algorithmic complexity

Container Management

Input-output managementHuman interactions

Scientific applications

algorithmic complexityresearch emphasis

engineering problems


20/47

Independent of the implementation tools andenvironment.

Can estimate size early in project

Non-technical users have a betterunderstanding of what function points aremeasuring

Can revisit a design with excessive FPs.


21/47

Measure productivity Number of function points achieved per work hour

expended)

Estimate development and support cost benefit analysis, staffing estimation)

Monitor outsourcing agreements Ensure that the outsourcing entity delivers the level of

support and productivity gains that they promise)

Drive IS related business decisions Allow decisions regarding the retaining, retiring and

redesign of applications to be made)

Normalize other measures Other measures, such as defects, frequently require the size

in function points)


22/47

Cannot manage internally what cannot be

measured,

Approximately 40% of all projects fail due to

lack of management control

(Coopers & LybrandSept. 1995) Measurement is a tool to communicate:

to stakeholders the size of their request,

extrapolate productivity, quality and estimating

accuracy Competitive edge

Metrics can help improve the processes

Can help manage risk


23/47

Measure functionality that the user requests andreceives

Measure software development and maintenanceindependently of technology used forimplementation

Simple enough to minimize the overhead of themeasurement process

A consistent measure among various projects andorganizations


24/47


25/47

Recommended: One day class and on-the-jobtraining by an experienced counter

Technical people have long been the mainfunction point counters

Senior level users can also be trained to countfunction points

For a large organization, a small groupinvolved with function point counting andother estimating activity is ideal Count frequently enough to stay current with the

rules Independent of the projects/ less biased feedback Consistent counting and help from other group

members


26/47

Determine the type of function point count

Identify the counting scope and

application boundary

Determine the Unadjusted Function PointCount

Count Data Functions

Count Transactional Functions Determine the Value Adjustment Factor

Calculate the Adjusted Function Point

Count


27/47

27


28/47

Determine the type of function point count Development project

Enhancement project

Application

Identify the counting scope and applicationboundary


29/47

The unadjusted function point count (UFP)reflects the specific countable functionalityprovided to the user by the project orapplication.

The UFP calculation is broken into twocategories with five sub-categories:Data Functions

Internal Logical Files

External Interface FilesTransactional Functions

External Inputs

External Outputs

External Inquiries


30/47

Data functions represent the functionality provided tothe user to meet internal and external datarequirements

Data functions are either internal logical files orexternal interface files.

An internal logical file (ILF) is a user identifiable group

of logically related data or control informationmaintained within the boundary of the application

An external interface file (EIF) is a user identifiablegroup of logically related data or control informationreferenced by the application, but maintained withinthe boundary of another application

Assign each identified ILF and EIF a functionalcomplexity based on the number of data elementtypes (DETs) and record element types (RETs)associated with the ILF or EIF


31/47

31


32/47

32


33/47

Transactional functions represent the functionality

provided to the user to process data Transactional functions are either external inputs,

external outputs, or external inquiries

An external input (EI) is an elementary process thatprocesses data or control information that comes from

outside the applications boundary

An external output (EO) is an elementary process thatsends data or control information outside theapplications boundary

An external inquiry (EQ) is an elementary process thatsends data or control information outside theapplication boundary

Assign each identified EI, EO and EQ a functionalcomplexity based on the number of file typesreferenced (FTRs) and data element types (DETs)


34/47

The value adjustment factor (VAF)indicates the general functionalityprovided to the user of the application

The VAF is comprised of 14 general

system characteristics (GSCs) that assessthe general functionality of the application

Each characteristic has associateddescriptions that help determine the

degree of influence of the characteristic The degrees of influence range on a scaleof zero to five, from no influence to stronginfluence


35/47

Data

Communications

Distributed Data

Processing

Performance Heavily Used

Configuration

Transaction Rate Online Data Entry

End-User

Efficiency

Online Update

Complex

Processing

Reusability

Installation Ease

Operational Ease

Multiple Sites Facilitate Change

35


36/47

0 Not present, or no influence 1 Incidental influence

2 Moderate influence

3 Average influence

4 Significant influence

5 Strong influence throughout


37/47

Evaluate each of the 14 general system characteristics ona scale from zero to five to determine the degree ofinfluence (DI)

Add the degrees of influence for all 14 general systemcharacteristics to produce the total degree of influence(TDI)

Insert the TDI into the following equation to produce thevalue adjustment factor.

VAF = (TDI * 0.01) + 0.65

For example, the following value adjustment factor iscalculated if there are three degrees of influence for each

of the 14 GSC descriptions (3*14)VAF = (42 * 0.01) + 0.65

VAF = 1.07


38/47

The adjusted function point count is calculatedusing a specific formula for a development project,

enhancement project, or application (system

baseline) function point count


39/47

The development project function point calculationconsists of three components of functionality:

Application functionality included in the user requirements

for the project

Conversion functionality included in the user requirements

for the project

Application value adjustment factor


40/47

Development project function point

formula

DFP = (UFP + CFP) * VAF

DFP is the development project functionpoint count

UFP is the unadjusted function point count

for the functions that will be available after

installationCFP is the unadjusted function points

added by the conversion unadjusted

function point count

VAF is the value adjustment factor


41/47


42/47

42


43/47

43


44/47

44


45/47

45


46/47

Function point analysis is a method of quantifyingthe size and complexity of a software system interms of the functions that the system delivers to theuser

Function point analysis is a complex process

that provides many benefits if it can beimplemented correctly

Function point analysis has been aroundsince the late 1970s and is still used by many

organizations today


47/47

http://www.ifpug.org

Function Point Counting Practices Manual Release 4.1, TheInternational Function Point Users Group, 1999.http://www.carfield.com.hk/document/software_engine/fpa.pdf

Matson, Jack E., Barrett, Bruce E., Software Development CostEstimation Using Function Points, IEEE Transactions on SoftwareEngineering, Volume 20, No. 4, April 1994.

Furey, Sean, Why We Should Use Function Points, IEEE Magazine,

March/April 1997, pp.28-31. Orr, George, Reeves, Thomas E., Function point counting: one

programs experience, The Journal of Systems and Software,Volume 53, 2000, pp.239-244.

Jeffery, D.R., Low, G.C., A Comparison of Function Point CountingTechniques, IEEE Transactions on Software Engineering, Volume19, No. 5, May 1993.

Probasco, Leslee, Dear Dr. Use Case: What About Function Pointsand Use Cases?, The Rational Edge e-zine, 2002.

http://ourworld.compuserve.com/homepages/softcomp/fpfaq.htm

http://www.qpmg.com/fp-intro.htm

http://www.ifpug.com/fpafund.htm
http://www.ifpug.org/http://www.carfield.com.hk/document/software_engine/fpa.pdfhttp://ourworld.compuserve.com/homepages/softcomp/fpfaq.htmhttp://www.qpmg.com/fp-intro.htmhttp://www.ifpug.com/fpafund.htmhttp://www.ifpug.com/fpafund.htmhttp://www.qpmg.com/fp-intro.htmhttp://www.qpmg.com/fp-intro.htmhttp://www.qpmg.com/fp-intro.htmhttp://ourworld.compuserve.com/homepages/softcomp/fpfaq.htmhttp://www.carfield.com.hk/document/software_engine/fpa.pdfhttp://www.ifpug.org/

function point overview (1)

Documents