Skip to Content

Read about function points:

Recommended reading:

Estimation of XI/PI projects (or any other project) is big challenge and this is very common fact that most of software projects overrun budget and schedule due to various reasons.

Casual discussion with colleagues prompts me to write this blog, he wants to estimate XI projects in term of Function points (FP) because customer wants all estimations in Function Points whether project is related to Java/.Net or XI.

My feeling was while FP works well in case of Java/.Net or any other coding intensive language it won’t work well for 4GL/5GL, in SAP world FP is possible for ABAP but it is not possible for projects related to PI/BI (list may be long).

So how to address this challenge, in practice and principle estimation of XI project using FP is not possible as per IFPUG (International Function Point Users Group) standards and guidelines.

So what are the options? One answer is reverse engineering practiced by various companies, based on experience and historic data calculate the average effort and convert effort to FP (sounds easy).

For Example: Sample Computation Table (hours and FP computation is indicative)


Hours (historic data) FP calculation (5 hours = 1 FP)

XI installation and Configuration



SLD configuration



Simple Interface design



Simple configuration



Medium Interface design



Medium configuration



Complex Interface design



Complex configuration





–          Classification of simple/medium/complex required detailed analysis which is not available in initial phase of project.

–          FP calculation from hours is different for different organization (here is challenge, for any given project FP are constant only hours per FP changes).

–          Tasks should be more granular for effective computation/estimation.

–          Cost of such estimation outweighs benefits.

 This work well for initial projects but this is not the right way to estimate because next time you need to convert FP to effort and schedule and there are higher possibility that given schedule/size/cost is incorrect due-to of inherit noise in historic data which needs to be perfected over period of time.

All integration projects required lot of communication between multiple teams/sites/users and all these factors can’t be covered using FP based estimation.

Another estimation approach could be “Direct Estimation Method” or “Expert Opinion Method” which is very effective (see section 3.1.1 in attached paper), although this approach is also used in our reverse engineering approach.

Well we also need to educate customer/sales people that everything can’t be measured using FP and there is need to be paradigm shift in project estimation and sizing.


–          FP based estimation won’t work well for SAP XI/PI based project.

–          For time being we can use reverse engineering but risk of incorrect estimation is very high.

–          We need to change perspective to use FP based estimation for every project.

–          It is possible to customize Function Point Analysis to suits our needs for quick, cost-effective and accurate estimation.

In followup blog I’ll try to tweak function point estimation to address needs of XI based projects.


Disclaimer: author is reasonably “OK” in FP analysis and views expressed by him are his personal.

Also see next part of this blog about estimating XI/PI projects using FP: XI/PI – Estimation: Function Point for Middleware (Version 0.1)

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Former Member
    We all experianced this situations, where we have to give solid base of estimation FP is the best, but for PI project mix blend of FP and history data (customised FP) is the right choice.
    1. Former Member Post author
      I am totally agree with you. The problem with current estimation process using FP is that they do the reverse engineering and correct size in FP is not possible using reverse engineering (FP suppose to remain constant regardless of technology used). We need to modify FP for middleware for better and correct estimation.


  2. Former Member
    As far as I see it, it is no so much the FPA that can or cannot be applied, but the lack of produtivity figures to translate the counting into an estimate in a particular customer setting. I feel the FPA counting methods can be applied to count the BI/XI and any other component of SAP for that matter.
    1. Former Member Post author
      thanks! interesting observation. In my opinion We need FP count first to get productivity figure (in FP) not vice-versa.
      For any given project FP count will be constant (within accepted variation) no matter who calculate it thats what make FP attractive. FPA can be done for middleware with certain adjustment in traditional FPA. See my next blog where I tilted traditional FPA to suits need of middleware and also derived productivity.
      Middlewares are much different than traditional applications hence it is not advised to use FPA for them.

Leave a Reply