- 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 Repository
eSell has been gathering a key repository, the PDB, containing project size, effort, and duration data since the measurement program was born. Today, two years later, the repository includes a wealth of data for almost 200 instances of function point counts and project estimates. For each implementation project, or for each product development project, the following types of data can be found in the repository:
Project name
Project contract information (if an implementation project)
FP counter specialist name
Project actual total size (FP)
Project actual total effort (SM, SD)
Project actual average productivity (FP/SM)
Project actual duration (in calendar months)
Various productivity factors for the project
Programming language used
Degree of back-end system integration
Level of reusability
Overall project risk
Project team makeup (was it mostly experienced or junior members, were implementation partners or client resources involved, and so on)
Miscellaneous extenuating circumstances (for example, this was the first time this back-end system was integrated)
Project team members' names, their roles on the team, their levels of experience as it relates to these roles, and the actual effort (SM) expended by each (by role, not by person)
Current project status
When we began to estimate our first project two years ago, however, none of the above data existed. The key missing component, the "yeast" for the new loaf of bread, was productivity data. With that, we could continue until we had enough actual data of our own. How did we bootstrap this process so we could begin to gather the data? We did so by taking advantage of two readily available sources of information.
Industry averages: In 1999, overall productivity for industries that were close to eSell's was in the range of 8 to 12 FP/SM. We knew that with RAD techniques, RAD tools, and higher-than-usual levels of reuse, we could assume a higher rate to start. So we started with 20–25 FP/SM.
Product development: In 1999, we had developed several products that gave us an opportunity to obtain some actual data. We did a full function point count on the released applications and went back to internal development team time sheets to capture effort and duration data. From that, actual productivity for this handful of projects was obtained. Ironically, it simply validated our 20–25 FP/SM extrapolation of the industry averages.
For the first few project estimations, then, we used a productivity of 20–25 FP/SM. Note that this single figure was assumed for all ability-to statements for the entire project. This average was an approximation for the various productivities actually achievable when measured on an ability-to basis.
As time wore on, the process evolved and we began to have enough actual data to make the PDB reasonable. We migrated our worksheets and processes to use productivity data from the PDB, and we began to apply different productivities to each ability-to, based on predefined (and premeasured) factors.
Ironically, after two years of estimation work, our PDB still shows overall average productivity to be in the range of 25–30 FP/SM—very close to the bootstrapping approximation we used at the outset.