This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
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)
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
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
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
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?
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
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
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.
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?
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?
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
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 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-
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