- Introduction
- B2B E-Commerce Primer
- Overall Function Point Counting and Estimation Methodology
- Benefits of Function Point Counting and Estimation
- Extensions to IFPUG CPM 4.1
- The Function Point Counting and Estimation Repository
- The Function Point Counting and Estimation Team-based Process
- Function Point Estimation Worksheet Example Segment
- Other Applications
- Internal Challenges at eSell
- Summary and Conclusions
- Final Questions to Ponder
This chapter is from the book
This chapter is from the book
This chapter is from the book
The Function Point Counting and Estimation Team-based Process
How is this counting and estimation process done? The overall process is in the form of a feedback loop, and looks something like this:
At each implementation project kick-off, the end-user ability-to functional requirements are gathered. They are then organized, documented, and listed in a function point estimation (FPE) worksheet. At this point it is time to convene an FP estimation session. The goal is to build and deliver a complete FPE worksheet that has all the ability-to statements and the estimated size, dollar cost, and effort cost for each (see Figure 41-1).
Figure 41-1: Function point estimation worksheet excerptAttendees for the FPE session include:
Project manager: Represents the client's and the client's end user's perspective of each piece of functionality
Senior architect: Represents the overall technology, interfaces, systems, data models, and capabilities of the existing products and services
ERP functional expert: Represents the overall configuration of the customer's back-end systems and how it maps to our assumptions of what is required to function without customization
Senior FPE specialist/architect: Provides the expertise on how to do the estimate, serves as design reviewer, and drives the FPE process
For each ability-to, the FPE team discusses the architectural, business, logical, and software implications of the function and agrees to and documents the following:
Estimated functional size in FP of the ability-to requirement (EI/EO/EQ/ ILF/EIF) based on the transactional and data functionality and complexity involved
Various productivity enhancement and reduction factors expected for that piece of the development, such as
Type of technology involved
Amount of back-end integration required
Degree of reuse that can be leveraged
Team's subjective impression of overall risk and comfort level, based on the assumptions documented
Team make-up (experience, seniority, internal versus partner, and so on)
Customer team involvement
Of equal importance, a detailed summary of the risk factors, assumptions, design considerations, architectural notes, open issues, and other comments related to this ability-to—including work expected to be done by the customer
The worksheet takes this data and automatically calculates the following estimates for this ability-to:
Estimated size (FP)
Estimated average productivity (FP/staff-month)
Estimated effort (staff-months and staff-days)
The worksheet automatically maintains the following estimated project totals:
Estimated total project size (FP)
Estimated average project productivity (FP/SM)
Estimated total project effort (SM, SD)
The customer reviews the FPE worksheet with the eSell project manager. The list of end-user functionality is validated as correct and complete. The assumptions are also adjusted and accepted. Based on dollar, resource, and time budgets, the customer then exercises line-item-veto privileges on any ability-to. For functionalities either removed or deferred, only that ability-to's size/effort estimate is removed from the total project plan. Sometimes, these changes warrant another FPE session to adjust the estimates.
Development begins to the first incremental milestone.
The first focus group meets soon after. During this meeting, the actual ultimate end-users are invited. The first agreed-on block of functionality is delivered, demonstrated, and reviewed by this extended project team. Change requests are captured. The ability-to list is updated, and another FPE session is held to re-compute the size and effort based on the agreed-on prioritized changes. Steps 1–6 iterate until the application goes into production.
At the end of this project's deployment and after the application is successfully in live production, an FP counting session is convened, with approximately the same makeup as the FPE session in step 1. This team examines the live application (previously estimated) and does a full application count. Each transaction, screen, data element, data store, field, and such is examined in accordance with standard CPM rules (as extended by eSell). Actual time sheets from the project team by role are accumulated. Data is obtained for actual size (FP), effort (SM), average productivity (FP/SM), and various other productivity factors. (Review the earlier description of the PDB.)
All data is placed in the PDB to increase the "reality" of future FPEs.
Repeat from step 1.
)
Figure 41-1