3

We've been using Function Point Analysis (FPA) estimation for new software development projects and medium sized changes that involves development efforts for code involving database entities as well (where we plug in EIF, ILF, EI, and EQ information). This process seems to be working out very well for us organization wide.

However, what are the best estimation methods to estimate minor changes such as :

  1. Simple server side scripting changes that don't involve any database components.
  2. Trivial change requests that have very little code changes, for example UI design, realigning fields, changing error messages, and those sorts of changes.

Even though these changes are trivial, testers have to test it, leads have to review it, manager have to schedule it, and releases need to be planned for pre-production and production deployments.

5
  • Defintion of Function Point is: A function point is a unit of measurement to express the amount of business functionality an information system provides to a user. The OP may want to edit the question to reduce acronym density.
    – Todd A. Jacobs
    Commented Aug 8, 2013 at 17:24
  • Related FPA tutorial.
    – Todd A. Jacobs
    Commented Aug 8, 2013 at 17:32
  • Can you expand on your question a little to explain in what way your current process is not meeting your objectives? There are lots of estimation methods; what's "best" will vary based on your unique challenges.
    – Todd A. Jacobs
    Commented Aug 8, 2013 at 17:35
  • @CodeGnome - Added some more detail, thanks!
    – Dodz
    Commented Aug 8, 2013 at 18:21
  • Welcome to PMSE! What will these estimates be used for? Seems like the cost of estimating them individually could be bigger than the value it provides. Commented Aug 8, 2013 at 20:28

3 Answers 3

1

My understanding is that the FP tables/data published by IFPUG, ISBSG etc are based on historical data. Do you have any records of how long the changes take?

If not, consider setting a fixed point value and then periodically updating its value as time goes on.

For example, you might set minor serverside script changes at 0.1; UI changes at 0.2. After a while you can review your estimates and actuals to see if there was divergence in those headings, then adjust your local FP settings.

2
  • We do categorize changes into L/M/H complexity changes. However to estimate the effort within these categories has been a typical problem that I want to streamline. For now, we living with the legacy Wideband Delphi technique.
    – Dodz
    Commented Aug 9, 2013 at 18:37
  • Wideband delphi is a heavyweight estimation process for minor changes. I think you'd be better off developing a simple points scheme on the basis I've outlined, by building a simple mean+/-std dev of each category. Commented Aug 10, 2013 at 1:11
1

One can look at using relative estimation using points. The are of estimation is more about consistency in estimation than accuracy. If consistent, one can make a ratio adjustment (velocity) to achieve better accuracy. However if not consistent, then ones accuracy is just a lucky guess.

1

We used to estimate by using Software Problem Report Complexity Method (SPRCM). This method of estimation calculates the size by taking into consideration the Software problem Report (SPR) as basis. This sizing technique determines the size of a project in terms of complexity index (CI). For each SPR given, it is classified to fit in one of the categories like Very Simple, Simple, Medium, Complex and Very Complex. A complexity factor is given to all the 5 categories taking Very complex as the base. Very Simple (0.08), Simple (0.16), Medium (0.8), Complex (0.5), Very Complex (1). Then Complexity Index (CI) which represents number of very complex programs is calculated as follows: Complexity Index = (0.08 * VS) + (0.16 * S) + (0.4 * M) + (0.5* C) + (1 * VC)
Where VS = number of Very Simple SPRs
S = number of Simple SPRs
M = number of Medium SPRs
C = number of Complex SPRs
VC = number of very Complex SPRs
Taking coding as the base, the effort for coding is derived as:
Effort per CI = 6 man days for all environments
Total efforts in man days for coding = 6 * CI

This is one of the ways. It used to work well for us. Again once the SPR is completed we also capture actual effort and improve our estimation based on the learning’s continuously.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.