The Zero Function Point Problem Ian Brown, CFPS Booz Allen Hamilton 8283 Greensboro Dr. McLean, VA 22102 USA 2009 International Software Measurement and Analysis Conference 0
Agenda Function Points: A Quick Review What Is the Zero Function Point Problem? Problem: Actual or Perceived? The Real Problem One Possible Methodology 1
Function Points: A Quick Review 2
Function points measure software size based on the functionality requested by and provided to the end user Function Point Counting Resources User/analyst interviews Requirements documents Design documents Data dictionaries Use cases User guides Screen captures Actual software Entity-relationship models Semantic object models Function points represent logical size, as opposed to physical size (like SLOC or objects) 3
More complex functions contribute a higher number of function 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.) Complexity Function Low Ave High Outputs (reports, etc.) Internal Logical File 7 10 15 Inquiries (search, retrieve, etc.) External Interface File 5 7 10 Complexity is based on number of External Input 3 4 6 data elements and files refereanced External Output 4 5 7 External Inquiry 3 4 6 Function Point Complexity Matrix 4
Function point analysis (FPA) provides a consistent, documentable, 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 5
The standard function point counting methodology is set forth in the IFPUG Counting Practices Manual Determine type of of function point count Identify counting scope and application boundary Identify data functions and their complexity Identify transactional functions and their complexity Determine unadjusted function point count Determine value adjustment factor Calculate adjusted function point count 6
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 Application Boundary Automobile Dealer Sales Application (application being counted) Dealership Regional HR Sales Application Application 7
What is the Zero Function Point Problem? 8
The 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 9
The 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? 10
Problem: Actual or Perceived? 11
Perception 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? Let s s take a look 12
We re implementing a COTS solution, so function points don t t apply Two key points FALSE 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 13
We re reusing components that already exist, so there are 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 14
We re performing maintenance/enhancement work on internal 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 FALSE 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. If a user has identified functionality that is not working, then function points can be applied to size that functionality 15
The Real Problem 16
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? 17
One Possible Methodology 18
Methodology Overview Size the project Allocate requirements/size to appropriate acquisition method categories Build WBS and populate size inputs Tailor model parameters and crosscheck 19
Step 1: Size the Project 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 This step should be done in the case of COTS implementations as well Function Point Size Requirements IFPUG standard function points work best with this methodology 20
Step 1: Size the Project (cont.) Allocate requirements/size to appropriate Acquisition Method categories 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) 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 What if there are 0 function points to count? Having a baseline application count to start with is extremely helpfulh 21
Step 2: Allocate requirements to appropriate Acquisition 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 Engaging in this dialogue helps the technical staff think about the problem and approach in a way that is meaningful to the cost analyst 22
Step 2: Allocate requirements to appropriate Acquisition Method categories (cont.) Allocate requirements/size to appropriate Acquisition Method categories 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 23
Step 2: Allocate requirements to appropriate Acquisition Method categories (cont.) Allocate requirements/size to appropriate Acquisition Method categories 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 24
Step 3: Build the WBS and populate the size parameters Build WBS and populate size inputs 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) 25
Step 3: Build the WBS and populate the size parameters (cont.) 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 26
Step 4: Tailor model parameters and crosscheck Tailor model parameters and crosscheck 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 valueadded crosschecks Cost ($ Millions) 90.0 80.0 70.0 60.0 50.0 40.0 30.0 20.0 10.0 0.0 Cost Range Proposal C Proposal B Proposal A 1% 10% 20% 30% 40% 50% 60% 70% 80% 90% 99% Certainty Level 27
Example: Client wanted to revalidate and retest entire installed baseline application Installed Application Size: 1,248 function points 28
Example: Client planned on installing COTS-based time and 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 (preexisting, designed for reuse) Also created a cost estimate for 100% custom development for reference 29
Contact Information Ian Brown, Senior Associate McLean, VA (703) 902-4971 brown_ian@bah.com 30