January 7, 2015
In the second part on the blog series on estimation, we dive into understanding the various techniques available for estimation. We talked about Project estimation challenges in the first part
Estimation is a tough nut to crack, even for a seasoned programmer. The reason being every project brings its own unique set of challenges, domain, technologies, people and other complexities. Software domain experts have explored different approaches, systemic and others, to compute project effort. In this article, we introduce some of the common methods that are used for estimation.
Though PERT is a methodical approach, many still consider this as a guess, because there is no actual logic or reference for the calculation of O, M and P – they are still based on individual judgement.
A good understanding of the input, output and storage are important to estimate the FP of a project. The key components that are considered here are External Input, External Output, External Inquiries, Internal Logical files and External Interface files. For each of these components, based on the data element types (DETs), return values, the complexity (low/medium/high) is evaluated and function points are calculated appropriately. The summation of FP of each of these five components gives the total FP number.
Since it’s a unit of measure of estimation like hours or miles, function point is very useful to compare against previous projects, especially in huge firms which have repositories of past project data. It is also a good tool for allocating project cost and mapping other metrics (E.g. number of defects/FP). FP estimation is good for large projects and to come up with a high level estimate and cost calculation at the beginning of the project. It is not found to work well for maintenance projects.
UCP = TCF * ECF * UUCP * PF
Technical Complexity Factor (TCF), Environment Complexity Factor (ECF), Unadjusted Use Case Points (UUCP), Productivity Factor (PF)
This method relies on having a lot of technical and design details in place before going ahead with the estimation. So, that makes it a bit difficult to use this method in the beginning stages of a project.
Typically, people find that use case points are quite larger than the actual effort because of the exhaustive list of technical end environmental factors that are being considered. This is probably good in that there is some inherent padding available, but experts usually tend to take a look at the use case points and apply their knowledge and experience to it.
A slight deviation from this is test case point calculation which is used for testing projects where the reference is test cases instead of use cases.
In this article, we discussed a few frequently used estimation methods. Certainly, the list is not exhaustive as there are other methods like COCOMO, Monte Carlo, story points, etc.
One thing that should be obvious by now is that usually a mix of models are used based on the situation you find yourself in. For example, in some scenarios, a bottoms-up approach is used whereas in some others, a top-down approach is found convenient.
Usually, at the start of a project, FP may be used but at a later stage when a detailed WBS is available, Delphi could be used at a module level to narrow down the range. Also, the approach varies based on whether you are working on a from-the-scratch project versus a maintenance project or large scale versus small scale or external versus internal projects.
Watch this space for the next part in this blog series, in which we will focus specifically on Agile estimation methods.