Project Estimation Techniques in Software Engineering

Keywords: project estimation techniques, estimation project management

The four major parameters that control the software projects are time, requirements, resources people, infrastructure/materials and money, and risks. This is one of the reasons why making good estimates of these variables like time and resources required for a project is very critical. But if the estimation is lower than the project needs it will affect the progress of the project due to the lack of enough time, money, infrastructure/materials, or people. At the same time even if the estimation is over estimated then the company will have to face losses due to the extra expenses or even if the project is sanctioned other projects don’t go on since there is less to go around.

For any successful project management, estimation is a vital part of project methodology. Estimation has numerous applications like justification of project which has to be applied in the initial stages of the project where in we need to anticipate the benefits which is compared with the costs incurred as well as to decipher comparisons and conclusions that has to be made with technical and functional teams involved in the project. Also, estimation plays a vital role in project management to implement the disciplines required. Estimates help in sharing the resources required to complete the project deliverables successfully.

Estimation process:

Definition: Project estimation is a process of forecasting or approximating the project parameters like cost, time, effort etc., for a successful completion of the project deliverables [4].

Overview of the Estimation Process:

The first point to be remembered about estimation is that it does not finish until the completion of project and is a process of a slow and gradual refinement. For many software projects a project manager can assist the team to create successful estimates by using sound techniques and understanding about what makes estimate more accurate. Staff required for a project estimation are taken from a pool of people who has some prior knowledge of the domain in which the new project is being developed.

When we want to start a project we need to know basic parameters required in advance like how long it will take, how many people it will require, how much effort it will require. In such cases it is hard to estimate because in many cases projects overrun or project would go over budget. Always a good estimation practices keep the project on track. In many cases, project estimation can be classified into three categories,

  • Expert opinion: Opinion from Qualified experts from within the organization or service partners is taken into account for estimation.
  • Analogy: A database where tasks previously completed are stored is taken into account. The new project would be decomposed into components/tasks, and compared with the corresponding tasks in the database.
  • Ratios: Whole project will be decomposed into Work Breakdown Structure (WBS), and estimating each component individually to produce an overall estimate.

When to estimate:

A rough estimate is needed at the initial stage of the project or probably even before the actual project starts. This is because, the final negotiations should be made with the customer, which needs the rough estimate of the cost, time and quality of the project.

Also, Estimation is a process of gradual refinement [2]. It should be performed in parallel with the project development, in several phases. Each estimate will be refined to give a converged estimate towards the end of the project.

Estimation should be carried out until the completion of project deliverables.

There are basically two approaches for estimating project parameters [4]. They are:

  1. Top-down estimation approach
  2. Bottom-up estimation approach

Top-down estimation approach:

Top-down estimation approach is usually used at the initial stages of the project. This estimation is usually carried out by the top managers who have little knowledge of the processes involved in the completion of the project. The input to this estimation is either information or the experience of the manager carrying out the estimation. These top-down estimation methods are often used to evaluate the project proposal. In most cases, the best results can be achieved in estimation only when one used both top-down and bottom-up estimation methods. However, it is practically not possible to carry out bottom-up methods until the Work Breakdown Structure (WBS) are clearly defined. In such cases, top-down estimates are used until the WBS becomes available.

Read also  XY Department Of Software Projects

There are many methods in top-down approach listed below [4]:

Consensus methods: This estimation method uses experience of a group of people to estimate the project parameters. This method involves project meetings, a place where these people can discuss, argue and finally come to a conclusion from their best guess estimate. The Delphi method comes under this category.

Ratio methods: These estimation methods use ratios to estimate project times and costs. For example, in a construction work, the total cost of the project can be estimated by knowing the number of square feet. Likewise, a software project is estimated by its complexity and its features.

Approximation methods: This estimation method is very useful when the project to be estimated is closely related to any of the previous projects in terms of its features and costs. By using the historical data of the estimates, good estimates can be approximated with very little effort.

Function point methods: Many software projects are usually estimated using weighted macro variables called “function points”. Function points can be number of inputs, number of outputs, number of inquiries, number of data files, and number of interfaces. These function points are weighted again with a complexity level and summed up to get the total cost or duration estimates of the project.

Bottom-up estimation approach:

Top-down estimation approach can usually be put in practice once the project is defined or once there is some progress in the project. This means, this estimation is more into work package level, which are responsible for low-cost estimates and efficient methods. It is often recommended that this estimation is usually carried out by people most knowledgeable about the estimate needed. The cost, time, resource estimates from the work packages can be checked with the associated accounts to major deliverables. Also, these estimates in later stages can be consolidated into phased networks, resource schedules, and budgets that used for control. Additionally, customer will get an opportunity to compare the low-cost, efficient method with any imposed restrictions, using bottom-up approach [4].

There are many methods in top-down approach listed below [4]:

Template methods: If the project to be estimated is similar to any of the past projects, then estimates of the past projects can be used as starting point estimates for the new project. This is similar to approximation estimation in top-down approach.

Parametric procedures: These parametric procedures are same like ratio methods in top-down approach. However, here the parametric procedures are applied on specific tasks.

Detailed estimates for WBS work packages: This is usually most reliable method of all estimation methods. The reason for this is that here the estimates are performed by people responsible for the work packages in Work Breakdown Structure. These people have prior knowledge or experience upon the tasks they perform specified in WBS, because of which the estimates are usually most reliable.

In addition to the top-down and bottom-up approaches, there is another kind of estimating which is a hybrid of the above two approaches. This is called as Phase Estimating. When there is unusual amount of uncertainty is surrounded by the project, people go for phase estimating. In this approach, two-estimate system is used over the life-cycle of the project. The whole project is initially divided into phases. Then a detailed estimate is developed for the immediate phase, and a macro-estimate is mode for the remaining phases of the project.

Difficulties in Estimation:

There are two major cases where Estimation problems almost always boil down to estimates that are either too high or too low.

Padded estimates, where the team members intentionally over estimates in order to give themselves extra time to work, are a chronic source of estimates that are too high. In such case, the project will take at least as long as it had been estimated even though it was originally overestimated. According to Parkinson’s Law, “Work expands to fill available time”[1].

Other case arises when senior managers give unrealistic deadlines that are a chronic source of estimates that are too low. In such cases, the staff in the project development can burnout and produce low quality components. Also the credibility will be lost because, the deadlines would be missed.

Read also  Examining The National Disaster Management Policy Information Technology Essay

Both the cases can lead to morale problems.

Estimation Tools:

Software tools are very important for estimation. Estimation tools are the software packages implemented using any of the estimation methods as its algorithm, to make project manager’s life easy. These estimation tools help from skipping important tasks in a method. These tools are useful to organise, update and store the results of the estimates. Also, Estimation Tools are useful to [2]:

  • Estimate project size using Function Points or other metrics.
  • Derive effort and schedule from the project estimates using various algorithms and techniques.
  • Perform analysis with staffing, duration etc. and appreciate how realistic they are.
  • Produce and update results like Gantt charts and other tables easily.
  • Maintain and exploit a database of historic data.
  • Import data from other projects run in organisations with which you have no connection.
  • However, one should very carefully select the estimation tools for a particular project.
  • Principle: Required functional capabilities of estimation tools should match the needs and desired capabilities specific to the project.
  • In selecting an estimation tool, one should match the available tools with the overall requirements of the project. In general, estimation tools should:
  • Be very adaptive to any project’s development environment, so that one can customize the tool according to the project needs.
  • Be comparatively easy to understand, learn and use.
  • Be able to produce some early project estimates without waiting for the whole project to be completely defined & designed.
  • Be able to provide estimates for different phases and activities in the project, if it is classified so.
  • Understand and support wide range of languages and applications, as it is really important for a tool to provide estimates specific to the applications.
  • Be able to provide accurate schedule estimates, whose purpose is not only to predict task completion given task sequence and available resources, but also to establish starting and ending dates for the associated work packages and life-cycle phases.
  • Be able to provide maintenance estimates separately, which includes correcting errors, modifying the software to accommodate changes in requirements, and extending and enhancing software performance.

Evaluation of the estimation tools:

There are many tools in the market for project estimation. However, I am investigating a few and very efficient tools in the current market.

PROBE:

The name “PROBE” is derived from Proxy Based Estimating, introduced by Watts Humphrey (of the Software Engineering Institute at Carnegie Mellon University) [1].

Principle: If a component being built is similar to one built previously, then the effort it takes would be about the same as it did in the past.

It mainly helps individual software engineers monitor, test, and improve their own work. Each component in the database is assigned a type (“calculation,” “data,” “logic,” etc.) and a size (from “very small” to “very large”). Also, a database is used to store history of size and effort details of these individual components. Later on, when a new project must be estimated, it is broken down into tasks that correspond to these types and sizes. A formula based on linear regression is used to calculate the estimate for each task [1].

COCOMO:

The COCOMO is the most used estimation tool in the market for cost and schedule estimating. The COCOMO is derived from Constructive Cost Model, developed by Barry Boehm in the early 1980s [1].

Principle: The model developed empirically by running a study of many software development projects and statistically analyzing their results. There by developing a database of the analysed details.

Boehm developed COCOMO empirically by running a study of 63 software development projects and statistically analyzing their results. COCOMO II was developed in the 1990s as an updated version for modern development life cycles, and it is based on a broader set of data [1]. The COCOMO calculation incorporates 15 cost drivers, variables that must be provided as input for a model that is based on the results of those studied projects. These variables cover software, computer, personnel, and project attributes. The output of the model is a set of size and effort estimates that can be developed into a project schedule [1].

The Planning Game:

The Planning Game is the software project planning method from Extreme Programming (XP), a lightweight development methodology developed by Kent Beck in the 1990s at Chrysler [1]. It is a method used to manage the negotiation between the engineering team (“Development”) and the stakeholders (“Business”). It gains some emotional distance from the planning process by treating it as a game, where the playing pieces are “user stories” written on index cards and the goal is to assign value to stories and put them into production over time [1].

Read also  Human Implanted Microchip Authentication System

Unlike PROBE, COCOMO and Delphi, the Planning Game does not require a documented description of the scope of the project to be estimated [1]. Rather, it is a full planning process that combines estimation with identifying the scope of the project and the tasks required to complete the software. Like much of XP, the planning process is highly iterative. The scope is established by having Development and Business work together to interactively write the stories. Then, each story is given an estimate of 1, 2, or 3 weeks. Stories that are larger than that are split up into multiple iterations. Business is given an opportunity to steer the project between iterations. The estimates themselves are created by the programmers, based on the stories that are created. Finally, commitments are agreed upon. This is repeated until the next iteration of the project is planned.

Critical analysis:

In order to have the best estimates of a project, it is better to make some rough top-down estimates initially, develop the WBS, using which make bottom-up estimates, and develop schedules and estimates and finally, reconcile the differences between top-down and bottom-up approaches. Also for ideal results, the project manager should allow some time to carry out top-down and bottom-up estimates, there by reliable estimates can be offered to the customer. This will in turn reduce the false expectations for stakeholders.

If we compare estimation approaches, there are some uses to use some approaches depending on the context of the estimation. Top-down approaches are preferable over bottom-up approaches in case of highly uncertain projects, whose scope is also unstable. Also, in case of internal and small projects, it is not worth spending lots of time and effort to go for bottom-top estimates. Therefore, in such cases, top-down approaches are preferable. Also, at the initial stages of the project when the decisions and negotiations should be made with the customer, top down is mandatory, due to lack of WBS to that particular project.

However, in case of cost and time estimates are really important and plays vital role in the project development, one should go for bottom-up estimates. In case of fixed-price contracts and when the customer demands for exact details of the project development, one should go for bottom-up estimation methods, due to its highly reliable results. Also, Phase estimation approach is much useful in the projects, whose final nature (shape, size, features) is highly uncertain. However, both these methods largely depend on expert’s opinions. In case if the expert’s knowledge in a particular domain is insufficient to estimate, one should go for analytical estimation technique which is used in estimation tools like PROBE.

In case of estimation tools, PROBE is useful to the early engineers who are in their learning stage. They can perform wide range of experiments and gain knowledge of the previous projects, thereby gaining the real-time experience in Estimation. However, COCOMO series of tools are more of professional kind because of its complex and wide range of applications. COCOMO is useful in many decision making situations including, all kinds of estimates, like cost, time, effort, maintenance. Also, using these estimates COCOMO can produce budgets and schedules.

Conclusion:

Project estimation plays a vital role in the planning of any project. Estimation of project cost, time, effort and quality act like input for project scheduling and budgeting. Therefore, the domain of the project to be developed should be initially studied carefully to make a decision in selecting the right methods and tools for a good project estimation. In this document, an investigation report on project estimation is explained in detail. Also, all types of estimation methods and estimation tools are critically evaluated and analysed. Therefore, this document could be helpful in the selection of good estimation methods and tools for successful project estimation, in order to make a good project planning for a successful project management.

Order Now

Order Now

Type of Paper
Subject
Deadline
Number of Pages
(275 words)