| Author | Message | ||
     Ashok Kumar |
Here reference is no to count Function Points. Is anybody practicing Estimation of Function Points and would like to share the techniques used? I'll appreciate real world case experiences and not from merely conceptual angle. Ashok | ||
| Gregory S. Jonesku |
The Fortune 50 company at which I am engaged baselined all their applications (600+) in 2005 using the estimating process described below. All countable components are assumed to be of Average FP Complexity, except: EIF's are assumed to be Low Complexity; Control EI's are assumed to be Low Complexity; and, List Box EQ's are assumed to be Low Complexity. To evaluate this technique, a small number of a cross-section of applications were counted. The counts were then converted to estimates. The average variance between estimating and counting was +/- 7 percent. | ||
| Ashok Kumar |
Greg, Thanks for sharing your FP Estimation experience. +/- 7 % average variance between estimating and counting has drawn my attention. Would you please describe how it was calculated i.e. the basis of selecting sample projects and the sample size etc. Ashok | ||
| Pranay Srivastava |
Hi Greg, You are using a modification of Quick Function Point. Quick Function Point has an inbuilt maximum possible error of around 40% (you could count something as average complexity when it is really high complexity or when it was low complexity). I have used it in the past but we never did an analysis of the amount of error. Glad to know that it was only 7% in your case. Could you share - Number of projects - Range of size - Range of error (I am sure some projects had more variation) | ||
| Charley Tichenor |
Here are two ideas than can be used to estimate function point counts. Both have worked very well for me. Roughly 1991, a paper was published out of McDonnell Douglas called “FP-S Function Point Simplified.” It detailed their method of estimating function point counts with a small margin of error. When I was at IRS, we tweaked that process for our systems. Basically, we counted a statistically large number of applications (over 30) and determined that the mean value of our EIs was 3.18, the mean EO was 5.33, the mean EQ was 3.92, the mean ILF was 8.41, and the mean EIF was 5.54. The degree of statistical significance was r^2 = .99. Once these means were determined, we then counted almost all of the rest of our applications by just counting the function types and then using these mean factors; we counted the GSCs normally. For the application portfolio of over 400 applications, the total margin of error in terms of portfolio size was essentially zero, and the time required for such a “fast count” was about 20% of the standard IFPUG method. I am no longer with IRS, but we have done the same statistically studies here and although the exact values we use are proprietary the overall effect is the same. This method works very well when one has to count a large portfolio as quickly and cheaply as possible. Another method I can recommend is to use the “ILF Model” (or sometimes called the “One File Model”). Again, count at least 30 applications using the standard IFPUG method. Then, plot the number of ILFs per application on the x-axis, and the corresponding number of function points on the y-axis. Then, do a regression (thru the origin method) to find the best-fit equation relating the number of ILFs and the function point count. For our applications, we tried plotting unadjusted function points on the y-axis, and then plotted adjusted function points on the y-axis. What worked best for us was adjusted, and we have an r^2 of .87. There are a variety of values across organizations for the number of function points per ILF so each organization should try this out for themselves. I think values around 30-40 are typical. The ILF Model can be used very early in the life cycle -- when just the ILFs are identified, and before those ILFs are structured. | ||
| Gregory S. Jonesku |
The analysis was done by the previous Metrics Department Manager who is no longer here. I was not invloved in the analysis, so I don't have the details. My recollection is that we took a cross-section of applications from each of the IT Departments that provide application maintenance support. After reading Charley Tichenor note about the McDonnell Douglas / IRS technique, my "gut" tells me that would be a better way to go. | ||
| Sudhakar Rao Beesabathuni |
I have valid values A,B and C for a field- now our situation is, we're not adding a new value but rather making the field optional field instead of a mandatory field. So that, the fact is this field now allowed to NOT be populated (making the actual value NULL). NULL will not be listed as a valid value for the field on the interface, but the field will be changed from MANDATORY to OPTIONAL which is what would allow a NULL to be passed to our application. Now, my question is, this willl be counted or not from FP perspective? | ||
| Charley Tichenor |
Sudhakar -- If one has the capability of entering data into a field -- whether the field is optional or not -- then count the field. Charley | ||
| Smriti Kaul |
Hi Sudhakar, As per the given situation I feel yes this field will be counted irrespective of the values which tend to make it Mandatory / optional. As in itself this field is countable. Regards, Smriti |
