The 'Zero Function Point' Problem

0Copyright © 2009 Booz Allen Hamilton

The The ““Zero Function Zero Function PointPoint”” ProblemProblem

Ian Brown, CFPSBooz Allen Hamilton8283 Greensboro Dr.

McLean, VA 22102USA

2009 International Software Measurement and Analysis Conference


AgendaAgendaFunction Points: A Quick Review

What Is the “Zero Function Point Problem?”

Problem: Actual or Perceived?

The Real Problem

One Possible Methodology


Function Points: A Quick ReviewFunction Points: A Quick Review


Function points measure software size based on the Function points measure software size based on the functionality requested by and provided to the end userfunctionality requested by and provided to the end user

Function points represent Function points represent logicallogical size, as opposed to size, as opposed to physicalphysicalsize (like SLOC or objects)size (like SLOC or objects)

Function Point Counting Resources

User/analyst interviewsRequirements documentsDesign documentsData dictionariesUse casesUser guidesScreen capturesActual softwareEntity-relationship modelsSemantic object models


More complex functions contribute a higher number of More complex functions contribute a higher number of function points to the logical sizefunction points to the logical size

Data functions represent logical groupings of the data end users need to do their jobs– Internal data maintained by the application– External data referenced by the application– Complexity is based on number of data elements and logical sub-groupings

Transactional functions are the processes and actions end users utilize to manipulate and manage that data in the course of doing their jobs– Inputs (add, edit, delete, etc.)– Outputs (reports, etc.)– Inquiries (search, retrieve, etc.) – Complexity is based on number of

data elements and files refereanced

Function Low Ave HighInternal Logical File 7 10 15

External Interface File 5 7 10External Input 3 4 6

External Output 4 5 7External Inquiry 3 4 6

Complexity

Function Point Complexity Matrix

Function Low Ave HighInternal Logical File 7 10 15

External Interface File 5 7 10External Input 3 4 6

External Output 4 5 7External Inquiry 3 4 6

Complexity

Function Point Complexity Matrix


Function point analysis (FPA) provides a consistent, Function point analysis (FPA) provides a consistent, documentable, repeatable measurement methodologydocumentable, repeatable measurement methodology

Standards are established and managed by International Function Point Users Group (IFPUG)

Function points accepted as a standard size measure by ISO (ISO 20926:2003)

Certified Function Point Specialist (CPFS) professional certification program recognizes trained experts

Measures size independent of technology, platform, language

Because it is linked directly to system requirements and functionality, FPA puts size analysis into terms that a client or end user can understand – Function points can help with communications between the end user

community and the developer• A client would never say, “I need a system that is 20,000 lines of code”• A client says, “Build me a system that does…and supports these processes”


The standard function point counting methodology is set The standard function point counting methodology is set forth in the IFPUG forth in the IFPUG Counting Practices ManualCounting Practices Manual

Determine type of function

point count

Determine type of function

point count

Identify counting scope and application

boundary

Identify counting scope and application

boundary

Identify data functions and

their complexity

Identify data functions and

their complexity

Identify transactional functions and

their complexity

Identify transactional functions and

their complexity

Determine unadjusted

function point count

Determine unadjusted

function point count

Determine value

adjustment factor

Determine value

adjustment factor

Calculateadjusted function

point count

Calculateadjusted function

point count


The Application Boundary The Application Boundary

Indicates the border between the software being measured and the user– Defines what is external to the application– Is dependent on the user’s business view of the

application– Is independent of technical and implementation

considerations– Is the conceptual interface between the “internal”

application and the “external” user world– Acts as a “membrane” through which data

processed by transactions pass into and out of the application

– Encloses the logical data maintained by the applications

– Assists in identifying the logical data referenced by but not maintained within the application under consideration

User

DealershipHR

Application

Automobile DealerSales Application(application being

counted)

Regional Sales

Application

Application Boundary

User

DealershipHR

Application

DealershipHR

Application

Automobile DealerSales Application(application being

counted)

Regional Sales

Application

Regional Sales

Application

Application Boundary


What is the What is the ““Zero Function Point Zero Function Point Problem?Problem?””


The Zero Function Point ProblemThe Zero Function Point Problem

We’re implementing a COTS solution, so function points don’t apply

We’re reusing components that already exist, so there are no function points to be counted

We’re performing maintenance/enhancement work on internal code (stored procedures, triggers, database, etc.) so no function points are impacted


The Zero Function Point ProblemThe Zero Function Point Problem

If function points aren’t applicable, then how can I size my software with that method?

If I can’t size with function points, how do I estimate cost and schedule?


Problem: Actual or Perceived?Problem: Actual or Perceived?


Perception is RealityPerception is Reality

If the common wisdom out there is that function points cannot be used in these situations, then there is a problem– Estimators are left to seek alternative means of sizing and

cost estimation, which makes the problem very real

Does this mean that function points truly cannot be used in these instances, or is it a matter of training, education, communication, and experience?

LetLet’’s take a looks take a look……


WeWe’’re implementing a COTS solution, so function points re implementing a COTS solution, so function points dondon’’t applyt apply

Two key points– Function points measure software size based on the functionality

requested by and provided to the end user– Function points measure size independent of technology, platform,

language

Example: SAP – Business Process Master List (BPML) or Business Process Execution Language (BPEL)– Describes the functionality that must be implemented to meet users’

business needs– If defined down to the transaction/data level, then function points can

absolutely be applied to size the software

FALSE


WeWe’’re reusing components that already exist, so there re reusing components that already exist, so there are no function points to be countedare no function points to be counted

How do you know that the reused software will meet the functional needs of the end users?– Better have a set of requirements and have done some analysis of the

reused software against those requirements

Will the reused software meet ALL of the functional user requirements? Probably not…so you may need– Modifications to the reused component– New functionality that needs to be developed to meet additional

requirements

If functional requirements exist, function points can be counted or estimated

FALSE


WeWe’’re performing maintenance/enhancement work on re performing maintenance/enhancement work on internal code so no function points are impactedinternal code so no function points are impacted

Applying strict function point counting rules, no function points are being impacted by this maintenance/enhancement work– We just need to fix a stored procedure or a

database call

If a user has identified functionality that is not working, then function points can be applied to size that functionality

Question: How do you know something is broken and needs

fixing? Answer: a user has indicated that the system is not producing the expected result.

FALSE


The Real Problem The Real Problem


OK, I can size these with function points, but now what?OK, I can size these with function points, but now what?

Just counting function points does not provide value in and of itself

Must be able to estimate cost and schedule or perform other measurement activities with function points

These situations are not the same as “New Development” projects– Historical data – is it applicable for analogies– Do our CERs apply to COTS/reuse situations?

• We would expect higher productivity/lower unit cost for COTS/reuse projects

– Can parametric tools estimate COTS implementation/configuration?– How well do parametric tools handle reuse?


One Possible MethodologyOne Possible Methodology


Methodology Overview Methodology Overview

Size the project

Allocate requirements/size to

appropriate acquisition method categories

Build WBS and populate size inputs

Tailor model parameters and

crosscheck


Step 1: Size the Project Step 1: Size the Project

Any robust software estimation methodology includes some means of estimating and measuring software size

Many different ways to define size– Source lines of code– Objects– Function points

Requirements

Function Point Size

IFPUG standard function points work best with this methodologyIFPUG standard function points work best with this methodology

Size the projectSize the project

This step should be done in the case of COTS implementations as well


Step 1: Size the Project (cont.)Step 1: Size the Project (cont.)

Where “internal” work is involved (e.g. changes to stored procedures, etc.), the identified defect should be traced back to the functionality in which the problem surfaced (e.g. incorrect data on a report, or an inability to enter data as expected)


appropriate Acquisition Method categories



– Refer to the defect reports (DRs), trouble reports (TRs) or Change requests (CRs)

– Identify which functions (and the associated function points) will be impacted by the maintenance effort

Having a baseline application count to start with is extremely hHaving a baseline application count to start with is extremely helpfulelpful

What if there are What if there are ““00”” function points to count?function points to count?


Step 2: Allocate requirements to appropriate Step 2: Allocate requirements to appropriate Acquisition Method categoriesAcquisition Method categories

This step involves working sessions between cost analysts, developers, and system analysts who are knowledgeable of existing functionality as well as the requested enhancements– Identify what Acquisition Method

categories are applicable to the given project

– Use the detailed definitions provided in SEER for Software help as guidance for the discussion

– Link requirements with the Acquisition Method category that best describes the type of work necessary to make the project work





Engaging in this dialogue helps the technical staff think about Engaging in this dialogue helps the technical staff think about the the problem and approach in a way that is meaningful to the cost anaproblem and approach in a way that is meaningful to the cost analystlyst


Step 2: Allocate requirements to appropriate Step 2: Allocate requirements to appropriate Acquisition Method categories (cont.)Acquisition Method categories (cont.)

If the project involves COTS, those requirements that will be met by COTS configuration/integration should be identified– Allocate these to the appropriate COTS-related acquisition method categories






Step 2: Allocate requirements to appropriate Step 2: Allocate requirements to appropriate Acquisition Method categories (cont.)Acquisition Method categories (cont.)

Again, for the “internal” work, refer to the defect reports (DRs), trouble reports (TRs) or Change requests (CRs)

Allocate these to the appropriate categories based on the expected amount of rework required to fix the problems






Step 3: Build the WBS and populate the size Step 3: Build the WBS and populate the size parametersparameters

If more than one application is included in the project, insert separate Program WBS elements for each

Insert a Component WBS element for each Acquisition Method category

Enter allocated size estimates into respective WBS elements

– If functionality is completely new, enter function points as NEW functionality

– If functionality is modified/reused, enter function points as PRE-EXISTING functionality (either designed for reuse or not designed for reuse)




Step 3: Build the WBS and populate the size Step 3: Build the WBS and populate the size parameters (cont.)parameters (cont.)



When COTS is involved, insert a Component WBS element for each Acquisition Method category

Enter allocated size estimates into respective WBS elements– If functionality will be custom developed,

enter function points as NEW functionality– If functionality will be implemented with

COTS, enter function points as PRE-EXISTING functionality, designed for reuse

The tool calculates “effective”function point size based on the reuse parameters defined in the knowledge base


Step 4: Tailor model parameters and Step 4: Tailor model parameters and crosscheckcrosscheck

Review the other SEER for Software input parameters to make sure settings are appropriate– If the initial application was estimated in

SEER for Software, start with the parameter assumptions in that model and make modifications from there

– Pay special attention to Personnel Capabilities & Experience and Development Support Environment to identify any differences in the enhancement project

Crosscheck results with benchmarks, analogies, second estimates, or actuals from past projects to gauge realism of estimate– Risk Report and Charts facilitate value-

added crosschecks


crosscheck


crosscheck

Cost Range

0.0

10.0

20.0

30.0

40.0

50.0

60.0

70.0

80.0

90.0

1% 10% 20% 30% 40% 50% 60% 70% 80% 90% 99%

Certainty LevelC

ost (

$ M

illio

ns)

Proposal B

Proposal A

Proposal C


Example: Client wanted to revalidate and retest entire Example: Client wanted to revalidate and retest entire installed baseline applicationinstalled baseline application

Installed Application Size: 1,248

function points


Example: Client planned on installing COTSExample: Client planned on installing COTS--based time based time and attendance system with some customizationand attendance system with some customization

Specific vendor had not yet been selected, amount of customization was still variable

Conducted function point analysis on complete set of baseline requirements

Developed multiple models with varying amounts of customization versus COTS configuration

Modeled custom function points as “new development” and COTS function points as “Integration with Configuration” (pre-existing, designed for reuse)

Also created a cost estimate for 100% custom development for reference


Contact InformationContact Information

Ian Brown, Senior AssociateMcLean, VA (703) [email protected]

The 'Zero Function Point' Problem

Documents

Transcript of The 'Zero Function Point' Problem