Function Point Analysis

Greater Accuracy in FPA estimation compared to IFPUG static FP counts using Coefficient Index

We use coefficient index to obtain an accurate estimate and also to avoid the static range of FP values and provide a dynamically computed function point value based on the IFPUG FP Reference Index.

To illustrate the difference the FP values are plotted below

Given a scenario of a user input form with 4 DETs and 2 FTR in a function, the UFP count is 3FP as shown in the table above, 2 DETs will result in 1.5 FP in Progressive FP instead of 3 in standard FPA.  The immediate benefit is that there is greater accuracy though it results in a lower count.  The primary benefit of having coefficient index is there is no high value cut off.  A user input page having 32 DETs which may be 31 user input fields and 1 save command with 2 FTRs may be counted with complexity level of High and allocated an FP value of 6 as per IFPUG standard.  In progressive FP the value is computed as 32 x .375 =12 FP.  Any value above 16 DETs with 3 RETs are considered as High value FP and assigned a static value of 6.  This causes sizing problems in projects where there are many complex forms with consistently higher number of inputs/outputs than present in the standard IFPUG range.

Inclusion of Workflows within each Data & Transaction Function

Process flows are operations performed within each data and transaction function.  For most simple CRUD (Create, Read, Update, and Delete) operations, there are single step process flows and hence it does not cause any estimation drawbacks.  In larger projects with many business processes, rules and alternative flows, the lack of counting the process steps in a function leads to under estimation of effort and size of the project.

In a user login process flow there are only two inputs the username and password, 2 DETs however there may be 10 or more process calls.  In a standard IFPUG FP count is 3 FP for any DETs below 4, 2 DETs results in lesser count of 1.5 for Progressive FP count, but when adding the process count with the actual progressive FP count, the total value is 4+ FP as illustrated below.  The difference is that both the input variables and process steps are considered in the equation thus gives a better sizing estimate and effort.

It is required to list the steps in the process flow and may be followed up with an simple activity diagram, this provides a clear blueprint on the approach and ensures that the developer is provided with a guideline to follow.

The process steps are as follows:

1. Encrypt Password
2. Validate Failed Login Count
3. Login User
4. Create SAML Request
5. Authenticate
6. Parse SAML Response
7. Store Key to Session
8. Redirect to Cutomer Page (or)
9. Increment Failed Login Count
10. Reset Page

We have 3 swim-lanes which are identified as LCS participants (User, SessionManager, IAM).