Challenges in Software Project Estimation

imagesEnsuring timely and in-budget completion of software development is a direct function of accurate estimation of the process. Software estimation is a framework to have a control over the software development process.

“It’s better to be approximately right than precisely wrong”. Warren Buffet.

More often, different team members might provide estimates on personal judgement or without a thorough analysis. This could drastically affect the work-flow, budgeted time, cost and hence the development on a whole. Accurate and precise estimation involves both technical and artistic endeavour related to size, effort and time of a software project. Accuracy and precision of the estimate should be matched to overcome dangerous miscalculation and overconfidence in estimation.

This article tends to briefly deal with some challenges in software project estimation.

Knowledge and Experience

Although the entire team is responsible for the development process, estimation involves experience and knowledge of working over different categories of projects. Involving junior level analysts or less experienced team members can result in poor or faulty estimates.

Having said that, developers having good but small project experience would not be adroit enough to estimate a large project as effort estimates are not directly related to project size. On the contrary as per various studies, effort estimates vary non-linearly with respect to project size due to enhanced integration requirements between various project components pertaining to a larger team. This is exacerbated with effects of various elements such as enhanced project coordination and team communication. [1]

Level of project experience has a direct bearing on estimation. Teams having experience in system software will have to estimate differently for application software. Analysts with sole experience in just one category may end up estimating incorrectly for the other category. Even within a specific category, for example applications, different levels of estimation should be done. Hence a desktop application and web application will have different levels of estimation which again depends upon the analyst/organizational experience in handling the specific project.

Problem of Re-estimation

A software project involves various phases starting from idea inception, requirement analysis, design decision, development process, testing to final software release. Carrying out exact manual estimation at the very first stage i.e. idea inception is not only difficult but might also turn out to be incorrect. As the project progresses, requirements change and new features or requirements might get added as per customer/client demands. With such an uncertain environment, incorrect estimation at the beginning affects overall product development, budget and analysis.

Incorrect or re-estimation at a later stage might shoot up the budget and time requirement. It can put undue pressure on analysts thereby affecting their morale and satisfaction level. Re-estimation can however yield better estimates at a later stage of software development as estimation is an on-going activity. Re-estimation should be done with every new development, additional information or requirement update. Hence irrespective of the model of development (iterative or waterfall), planning is a dynamic process and so is estimation throughout the project period.

Uncertainty and Related Estimation Error

Uncertainty in a software development environment arises due to several reasons such as: varied level of analyst productivity, programming tools employed, creative nature of software development and unquantifiable and highly dynamic nature of the elements of the software project as a whole. Estimates therefore are always closely related to the term ‘uncertainty’ and ‘variability’.

Although probability associated with estimates (best, worst and most likely outcome) tends to lower the element of uncertainty to some extent, the cone of uncertainty (as per the research by Barry Boehm) suggests a measure of estimation error based on the development phase of the software project. It shows estimation error can be significantly high in various stages of software development (as high as 400% above or below correct estimates). The estimation error might get even bigger considering changes in requirements during the software development life cycle. At later stages, factors such as inaccurate requirement analysis, poor user involvement, poor design and design practice would result in poor accuracy of effort, time and cost estimate. This would mean even failure of the overall project.[2]

Availability of Developers

A developer might be alternatively involved in a number of projects. Estimation of the available time of all developers associated with a specific project requires correct analysis of the developer’s work flow, various projects they are involved into and level of completion and urgency associated with the different projects. Hence although associated with a new project, a developer might be having an urgent presence in some other project. Calculating time availability (for time estimates) keeping these factors into consideration is necessary for correct time estimation for a project.[3]

Loose Estimation Loses Control

Inaccurate estimation of time, effort and cost leads to inaccurate resource allocation and affects performance measurement. Since estimation establishes control and forms a basis for future project planning, inaccuracy would lead to ineffective problem management, risk handling and desired project progress.

Function Point Analysis (FPA) to be followed by Phase Estimation

Function points are the units to measure the software and function point analysis is the technique to measure the system software by breaking and classifying its components. This enables better understanding and analysis of the components thus providing a structured methodology for problem solving. Function Point Analysis can provide a methodology to monitor and track scope creep. The function points count at the end of the requirements. Analysis, coding testing and implementation can be compared and contrasted to actual function points that have been delivered. The growth in project would denote a scope creep and would help to evaluate the estimation errors with respect to requirements analysis. 4

First function point helps in providing sizing for estimation. This calculation is used at the start of the development phase for estimation of size of software as LOC (line of code) cannot be determined in the beginning. Function point can help determine LOC for implementing function point depending upon programming language used. Effort estimation can be done once size is analyzed in units of analyst-month analyst-week or man-hour to arrive at the schedule of project completion. Schedule estimation is in months/weeks.

The estimation should be a continuous process and at later stages should be split-up to different levels throughout the lifecycle of the project to reduce complexity and error of miscalculation. Phased out estimation is always preferable and should be followed as compared to complete estimation in the beginning itself and leaning into re-estimation issues. The time taken for accurate and precise estimation is a direct function of the scope of the software project. This would mean the more complex a project is, the greater time it would take for estimation. Trying to estimate a large and complex project all at once is detrimental to building a robust project.

It is recommended to provide a high degree of estimates for the overall project to maintain the scope which can thereafter be followed by moving into the estimation phase – to be necessarily included into the software development project. The success of a software project depends upon accurate estimates in the early phase of the project with high levels of precision which calls for in-depth analysis of low-level function point estimates. At later stages, these can be further appended with varied levels of complex elements, skill, level and historical data of past project experience to calculate more structured and accurate estimates which can definitely counter the challenges and increase estimation accuracy to great extents for successful software development.

References

Asproni, G. (2008).

Fingers in the air: a Gentle Introduction to Software Estimation.” Retrieved 2015 йил 23-October from Methods and Tools: http://www.methodsandtools.com/archive/archive.php?id=79

Introduction To Function Point Analysis. (n.d.). Retrieved 2015 йил 29-October from SoftwareMetrics.com: http://www.softwaremetrics.com/fpafund.htm

Umairomee, M. (2013 йил 26-December).

Software Estimation by example. Retrieved 2015 йил 23-October from Code Project: http://www.codeproject.com/Articles/701642/Software-Estimation-by-example

http://www.softwaremetrics.com/fpafund.htm
[1]http://www.codeproject.com/Articles/701642/Software-Estimation-by-example
[2]http://www.methodsandtools.com/archive/archive.php?id=79
[3]http://www.codeproject.com/Articles/701642/Software-Estimation-by-example