Upload
others
View
6
Download
0
Embed Size (px)
Citation preview
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
1Copyright © 2009 Booz Allen Hamilton
AgendaAgendaFunction Points: A Quick Review
What Is the “Zero Function Point Problem?”
Problem: Actual or Perceived?
The Real Problem
One Possible Methodology
2Copyright © 2009 Booz Allen Hamilton
Function Points: A Quick ReviewFunction Points: A Quick Review
3Copyright © 2009 Booz Allen Hamilton
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
4Copyright © 2009 Booz Allen Hamilton
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
5Copyright © 2009 Booz Allen Hamilton
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”
6Copyright © 2009 Booz Allen Hamilton
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
7Copyright © 2009 Booz Allen Hamilton
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
8Copyright © 2009 Booz Allen Hamilton
What is the What is the ““Zero Function Point Zero Function Point Problem?Problem?””
9Copyright © 2009 Booz Allen Hamilton
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
10Copyright © 2009 Booz Allen Hamilton
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?
11Copyright © 2009 Booz Allen Hamilton
Problem: Actual or Perceived?Problem: Actual or Perceived?
12Copyright © 2009 Booz Allen Hamilton
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……
13Copyright © 2009 Booz Allen Hamilton
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
14Copyright © 2009 Booz Allen Hamilton
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
15Copyright © 2009 Booz Allen Hamilton
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
16Copyright © 2009 Booz Allen Hamilton
The Real Problem The Real Problem
17Copyright © 2009 Booz Allen Hamilton
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?
18Copyright © 2009 Booz Allen Hamilton
One Possible MethodologyOne Possible Methodology
19Copyright © 2009 Booz Allen Hamilton
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
20Copyright © 2009 Booz Allen Hamilton
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
21Copyright © 2009 Booz Allen Hamilton
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)
Allocate requirements/size to
appropriate Acquisition Method categories
Allocate requirements/size to
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?
22Copyright © 2009 Booz Allen Hamilton
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
Allocate requirements/size to
appropriate Acquisition Method categories
Allocate requirements/size to
appropriate Acquisition Method categories
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
23Copyright © 2009 Booz Allen Hamilton
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
Allocate requirements/size to
appropriate Acquisition Method categories
Allocate requirements/size to
appropriate Acquisition Method categories
24Copyright © 2009 Booz Allen Hamilton
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
Allocate requirements/size to
appropriate Acquisition Method categories
Allocate requirements/size to
appropriate Acquisition Method categories
25Copyright © 2009 Booz Allen Hamilton
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)
Build WBS and populate size inputs
Build WBS and populate size inputs
26Copyright © 2009 Booz Allen Hamilton
Step 3: Build the WBS and populate the size Step 3: Build the WBS and populate the size parameters (cont.)parameters (cont.)
Build WBS and populate size inputs
Build WBS and populate size inputs
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
27Copyright © 2009 Booz Allen Hamilton
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
Tailor model parameters and
crosscheck
Tailor model parameters and
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
28Copyright © 2009 Booz Allen Hamilton
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
29Copyright © 2009 Booz Allen Hamilton
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
30Copyright © 2009 Booz Allen Hamilton
Contact InformationContact Information
Ian Brown, Senior AssociateMcLean, VA (703) [email protected]