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
About the author
Marten Eisma is Information Architect at CGI in the Netherlands and is a member of the Nesma Basis of Estimate committee.
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.
Totally agree!
Great idea! In practice I only see global counts. Detailed counts are simply – the name says it – too detailed.