How do you do your software estimation?
Software estimation is a complex subject. Even today it is solely responsible for maximum numbers of project failures. Software estimation plays a critical role in project success. If software is not estimated properly, it poses several challenges to the team and convert the project into a struggle.
The main disadvantage for software development team is that most of the software estimation techniques directly estimate the efforts without estimating the size of the software. It is not only inaccurate but also make it difficult to re-estimate the efforts when a change occurs.
It is better to measure software size first before arriving on the efforts estimations. Take an example of wall painting. The painter first measures the surface area that is the size of the work and then applies productivity on it based on resources to be used and kind of paint to be applied to workout efforts and cost.
Click here to learn Function Point Analysis to estimate software
However in software, most of the techniques do not measure the size and directly estimate the efforts which varies a lot depending upon experience and perception of estimator and bring trouble for the project team later. You take WBS estimate or use case point estimate or latest in this line story point estimates for agile, all of them need experts to find how complex a module or story is to estimate the efforts.
Software size is estimated only in two ways – lines of code (LOC) and function points (FP). There is no structural method to estimate lines of code and therefore is error prone. Also since object oriented programming is introduced, LOC is no more right measure of software size and its complexity. It is only Function Point Analysis which actually estimate the software size based on its functionality and complexity. FPA technique first measures software size in functional points and then applies productivity based on resource and technology to be used to workout efforts and cost. This makes Function Point Analysis independent of technology and methodology to be used in software development. Function Points size will remain same while efforts differ based on the resources productivity on different technology to be used.
Because FPA does not depend upon technology or methodology, you can estimate size of any type of software – legacy to modern mobile applications, Cobol to java or dot net and waterfall to agile. Because it is driven by complexity of functionality to be delivered to user, it is independent of experts’ own experience and perception and therefore more accurate.
I always suggest to use FPA to estimate software project as it is the only scientific method available away from individual’s perceptions to estimate software size. Learn, use and let me know you experience using FPA.
Very good article. Infact to add to your article, once the estimate is drawn from FPA, it must also be analyzed depending upon the complexity. For a example simple, medium and complex use cases with varying efforts. This could be a hybrid approach and would be accurate.
Hello Pradeep,
Thanks for your comment. I don’t think you need do any kind of Simple/Medium/Complex analysis after FPA. Complexity assessment is in inbuilt in FPA. You don’t need a hybrid approach. FPA itself is sufficient and you get quite accurate estimates.