Software Cost Estimating ModelsThere are several models can be found in the literature that deal with software cost estimation. At a very high level, these models estimate software costs in three main steps: (i) they somehow estimate/predict the software size (ii) then they determine the effort required using some productivity rate (iii) once size and effort have been determined, they convert these quantities into dollar figures and duration.

All these software cost estimation models can broadly be divided into two groups:

  1. Algorithmiccost estimation models, and
  2. Non-algorithmic models.

Algorithmic cost estimation models: These models are primarily based on a number of mathematical relations or formulae coupled with some historical data relating to software size metrics. Almost all algorithmic estimation models use parameter(s) associated with software size. Therefore, software size arguably is the most important metrics for software estimation. It is important to note that costs do not normally increase linearly with project size. As the size of the project increases, additional costs are incurred because of the communication overhead of larger teams, more complex configuration management, more difficult system integration, and so on. Cost tends to increase exponentially with increase in software size. Similar non-linear relationships exist between size and other related metrics: duration, effort, and defects. Examples of some algorithmic cost estimation models are: Function Point method, Use Case Point method, COCOMO/COCOMO II, the Putnam model etc.

Non-algorithmic cost estimation models: Contrary to the Algorithmic models, members of this group are based on analytical comparisons and inferences. Some examples are: By Analogy, Expert (individual and group) Judgement, Machine Learning (Neural Networks, Fuzzy methods) etc.

A special type of software cost estimation model is “Bottom-up”. In this model, the project is broken down into smaller, more manageable components and costs are calculated at these smaller component levels. Component costs can be calculated using any of the algorithmic or non-algorithmic models mentioned above. All breakdown estimates are then summed up to reach at the final project estimate.

The table below further describes these three types of estimation models and highlights their pros and cons.

Model Description Pros Cons
Algorithmic models Models in this category determine development effort based on anticipated size and productivity rates. Adjustments are made for management and technical factors. Leads to repeatable estimations; the whole process can easily be automated. Most models allow customization of parameters to better suit individual organization. Estimate is predominantly based on software size; the accurate size of a software, however, can only be known when the project is completed.

Does not account for all work, need to know details of the project’s development process. Most models are unable to deal with exceptional conditions.

Non-algorithmic models Most models in this category follow a top down approach – the cost is computed by comparing the current project to a similar past project(s)(reference project) ideally in the same application domain. The reference project can come from organization’s historical data repository or from the memory of an expert or group of experts. Accurate, if the reference project data is reliable.

Relatively cheap and leads to fast estimation process.

Impossible if no reference project is available.

Needs systematically maintained historical cost data.

Leads to good estimate only when the current and reference projects are similar.

Bottom Up In this method, the project is broken down into its Application Breakdown Structure (ABS) and Work Breakdown Structure (WBS) and the effort, resources, and durations needed to complete each breakdown are determined. All breakdown estimates are then added to reach a final estimate. Very accurate, flexible, and intuitively logical. Can be expensive and time consuming. May overlook some system level costs.

Ideally needs a project management software such as: MS Project or PrimaVera.

Whether you use an algorithmic or non-algorithmic cost estimation model, remember all models have their inherent strengths and weaknesses. Therefore when possible, try to use more than one cost estimation models and compare the results, especially for large and complex projects. If the models used predict radically different costs, either you do not have enough information about the final product or probably you made mistakes somewhere. Review your estimate and look for more information and repeat the costing exercise until the estimates converge.

Also remember, as I mentioned earlier, software size is a key consideration when it comes to cost estimation and it is the biggest cost driver for IT projects. There are several proxies (an easily countable/usable measure that substitutes for size) used in the industry for software size. Source Lines of Code (SLOC), Function Points (FP), Use Case Points (UCP), User Stories are a few examples of such proxies. Other factors that contribute to the increase in costs include complexity and features set; therefore, it is important to define these two parameters for each component of your project.

As mentioned, there are a number of software cost estimation models which can be organised into two main groups. All these models have their inherent strengths and weaknesses, and none of them are perfect. The choice of a specific method, in most cases, is a personal preference and judgement of the cost estimator. You will learn with experience to choose a model that is most appropriate for the IT cost estimate project you are working on.

The image attached shows when to use a particular type of model based on the project size and complexity and where you are in the life cycle of the project. The figure shows that the models overlap, meaning, they are not mutually exclusive. So, you have the option of using more than one model for your project. As mentioned earlier, using more than one method provides increased confidence and is often considered a best practice.

As you can see from the figure, non-algorithmic models (shown in the figure by black circles) are well suited for small and low complexity projects, regardless of where you are in the project life cycle. By Analogy, Individual Expert Judgement, Group Expert Judgement etc. are a few examples of non-algorithmic models. They can also be applied to big and complex projects as long as the project is at the early stage of its life cycle.

Algorithmic models (Function Point, Use Case Point, COCOMO/COCOMO II, the Putnam model etc.), on the other hand, can be used to estimate any projects – complex or simple and large or small (and anything in between). However, they can only be applied at a relatively advanced stage of the project life cycle. You usually do not have the required data/information at the early stage of project life cycle to properly use these models. These models are represented in the figure with red circles.

The bottom up method (blue circles) can be used when the project is at the advanced stage in its life cycle, regardless of its size and complexity level. Bottom up method requires detailed project information that you won’t have at the early stage of your project’s life cycle.

What do you think? Do you have any comments, inputs, feedback or ideas that you would like to share with us? Please feel free to use the form below. We would love to hear from you!

Posting Guidelines: We encourage all readers to share their views on articles and blog posts published in the Red Monster Consulting (RMC) website. We hope each conversation thread within the RMC website is constructive, thought-provoking, and contributes to further enrichment of knowledge. We DO NOT require readers to sign in or register to comment. However, in order to ensure the quality of the discussion, we reserve the right to edit them for clarity, length, and relevance; comments that are abusive, overly promotional, mean-spirited, or off-topic will be deleted. All postings become the property of RMC.

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *