Non-functional complexity threshold in function points delivery rates

How to improve the distribution of productivity risks between business areas and software development organizations; simplify work monitoring and control by including non-functional measurement for functions intrinsically with high delivery rates due to design responses and implementation to non-functional requirements in organizations with mature IT governance practices.

Publication

IFPUG Metric Views | Vol. 14th | Issue 1

Date

March / 2020

author

Carlos Eduardo Vazquez

Why it’s important

Estimates at function points are optimal when average delivery rates are significant. However, it is not uncommon for there to be some application functionality with very high delivery rates. Because how many functions carry this low productivity and how low it is, it is a matter of risk management; and this adds unnecessary variability when estimating now that we have IFPUG SNAP. You have the benefit of less variability when using a strategy like insurance deductible without the added cost of measuring each functionality with SNAP.

When it applies

The average delivery rate estimation model is the simplest means of estimating from function points.
Once the delivery rate is chosen by similarity, it is multiplied by the measured or approximate function points to plan or monitor work performance. The greatest variability is weak point of this simple model. Variability is mostly due to “non-functional complexity” if we disregard performance issues. This content is useful when there is a need to quantify the “complexity felt, but not measured by the APF”.