I want to argue here for a new FPA manual v3.0. The proposed changes are:

  • Abolish the detailed analysis
  • Rename the high-level (global) analysis to FPA analysis
  • Introduce an indicative analysis, based on the function model, in addition to the current indicative analysis, based on the data model

The reasons for abolishing the detailed analysis (and renaming the high-level analysis) are as follows:

For a project calculation purposes a detail count is irrelevant

To create project calculations there are two main variables, the product size (function points) and the Product Delivery Rate (hours per function point). Product Delivery Rates are very inaccurate, usually 10% or more. The difference in inaccuracy between a high-level analysis and a detailed analysis is 1%. Because mostly the product size will vary in time, this inaccuracy difference is negligible.

Detailed analysis is (often) not possible

A detailed analysis requires insight into entities and attributes. At a global design that is not available. Many features in the (current) detailed designs also contain insufficient detail information for a detail count.

Detailed analysis increases complexity and reduces accountability

There is a balance between complexity (more details) and accountability (overview). A detailed analysis increases the complexity and greatly reduces the accountability (understanding from the end users). A detailed analysis costs much more (extra) effort, while it delivers less value.

The FPA Manual is needlessly complex and therefore FPA is less used

By removing the detailed analysis from the FPA Manual this manual will become less complex and therefore more accessible.

The reasons for the introduction of an indicative analysis, based on a global function model are:

At the start of a project there is more often a function model than a data model. An indicative analysis, based on a mathematical function model would help. The principles for such a model are:

  • Estimate and / or count all input and output functions
  • Calculate the product size based on all functions * (xxx function points)
  • Determine the inaccuracy of the estimate product size

I would also like to know if there are other suggestions for improvements for a new FPA manual version 3.0.

About the author

Marten Eisma is Information Architect at CGI in the Netherlands and is a member of the Nesma Basis of Estimate committee.

A blog post represents the personal opinion of the author
and may not necessarily coincide with official Nesma policies.
Note from the Nesma board

The Nesma board wishes to make it explicitly clear that this is not the official strategy of Nesma. Currently the ISO/IEC 24570:2005 is in review. This will clarify a number of issues that are sometimes conceived as complex. The Counting Practices Committee, the Experienced Analysts round table and the Board are working on the next generation of the Manual and are open for ideas like this. Yet it is too early to tell whether all these suggestions will become part of a future version of the Manual. The board is looking forward to the discussions as a result of this blog post.

Share this post on:


Leave a Comment
  1. Totally agree with these suggestions, which align with the daily practices and difficulties I have with the current FPA manual. Even when detailed analysis is possible, we don’t use it in our projects for the reasons you already mentioned. Also, when introducing FPA to product owners or business users etc (not FPA specialists) it’s always difficult to motivate them to learn measuring or understanding FPA with all the little details and exceptions, which mostly don’t have that big of an impact on the total measurement.

    The main goal of FPA usage for us is for budgeting and planning purposes and then monitoring the progress and evaluation at the end, so we need comparable reference points like function points. We also try to keep the measurement details the same over the project timeline, so we don’t want to mix indicative with global with detailed analysis in the same project but at different points in time, because that could lead to different discussions and perspectives on how and what to count.

    Another argument against the use of detailed analysis is the maintainability of the measurement itself (not just the initial measurement and administrative efforts needed). Especially with continuous deployment and the increasing pace of changes (Agile approaches), all the data field changes etc are just too much to monitor and update in the measurements without automation tools and a final manual check.

  2. Great idea! In practice I only see global counts. Detailed counts are simply – the name says it – too detailed.

Leave a Reply