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.
Global Association of Risk Professionals, Inc. (GARP®) does not endorse, promote, review or warrant the accuracy of the products or services offered by EduPristine for FRM® related information, nor does it endorse any pass rates claimed by the provider. Further, GARP® is not responsible for any fees or costs paid by the user to EduPristine nor is GARP® responsible for any fees or costs of any person or entity providing any services to EduPristine Study Program. FRM®, GARP® and Global Association of Risk Professionals®, are trademarks owned by the Global Association of Risk Professionals, Inc
CFA Institute does not endorse, promote, or warrant the accuracy or quality of the products or services offered by EduPristine. CFA Institute, CFA®, Claritas® and Chartered Financial Analyst® are trademarks owned by CFA Institute.
Utmost care has been taken to ensure that there is no copyright violation or infringement in any of our content. Still, in case you feel that there is any copyright violation of any kind please send a mail to firstname.lastname@example.org and we will rectify it.
2015 © Edupristine. ALL Rights Reserved.