Cost Estimation

Software cost estimation is the process of predicting the effort required to develop a software
system. Accurate estimates are important to both developers and customers. They can be used
for generating request for proposals, contract negotiations, scheduling, monitoring and
control. Underestimating the costs may result in management approving proposed systems
that then exceed their budgets, with underdeveloped functions and poor quality, and failure to
complete on time. Overestimating may result in too many resources committed to the project
or failing to win the contract, which can lead to loss of jobs.

There are three parameters involved in calculating the total cost of a software development
project:

- Hardware and software costs including maintenance,

- Travel and training costs,
- Effort costs.

Calculating software productivity is very important in estimating software cost. Productivity

estimates are normally based on measuring attributes of the software and dividing this by the
total effort required for development (Somerville, 2008). The two types of metric used are
size-related metrics and function-related metrics.

Lines of source code per programmer-month (LOC/pm) is a widely used software

productivity metric. To calculate LOC/pm, count the total number of lines of source code that
are delivered, then divide the count by the total time in programmer-months required to
complete the project. Total time includes time spent on requirements, design, coding, testing
and documentation.

Comparing productivity with different programming languages can give misleading

impressions of programmer productivity. If one language requires more lines than another to
implement the same functionality, productivity estimates will be anomalous.

Alternative to using code size is to use some measure of the functionality of the code.
Functionality is independent of implementation language. A function point is calculated by
combining several different estimates. To calculate function point we need to estimate the
external inputs and outputs; user interactions; external interfaces; and files used by the
system.

Object points (Bamker, et al., 1994) are an alternative to function points. They can be used
with languages such as database programming languages or scripting languages. The
advantage of object points over function points is that they are easier to estimate from a high-
level software specification. Object points are only concerned with screens, reports and
modules.

Estimation Techniques

There is no simple way to make an accurate estimate of the effort required to develop a
software system. We have to make initial estimate based on a high level user requirements. It
is impossible to estimate development costs accurately at this stage. The following techniques
can be used for cost estimation.

Expert Judgement

In this technique, several experts are consulted. They provide estimates using their own
methods and experience. These estimates are then compared, discussed and resolved the
inconsistencies using mechanisms such as Delphi. The estimation process is repeated until an
agreed estimate is reached.

Estimation by Analogy

This method requires one or more completed projects that are similar to the new project and
project cost is estimated by analogy with these completed projects. Estimation by analogy
can be done either at the total project level or at subsystem level. The total project level has
the advantage that all cost components of the systems will be considered while the subsystem
level has the advantage of providing a more detailed assessment of the similarities and
differences between the new project and the completed projects. Another advantage is that
the estimate is based on actual project experience. However, it is not clear to what extent the
previous project is actually representative of the constraints, environment and functions to be
performed by the new system.

Parkinson’s Law

Parkinson’s Law states that work expands to fill the available time. The cost is determined by
the available resources rather than based on an objective assessment. For example, if the
software has to be delivered in 12 months and 5 people are available, the effort is estimated to
be 60 person-months (5 x 12 = 60). Although it sometimes gives good estimation, this
method is not recommended as it may provide very unrealistic estimates.

Pricing To Win

In this technique, the software is estimated to be the best price to win the project. The
estimation is based on the customer’s budget instead of the software functionality. This
technique is not a good since it is very likely to cause a bad delay of delivery or force the
development team to work overtime.

Algorithmic Cost Modeling

Algorithmic cost modeling uses a mathematical formula to predict project costs based on
estimates of the project size, the number of software engineers, and other process and product
factors (Sommerville, 2008). An algorithmic cost model can be built by analyzing the costs
and attributes of completed projects and finding the closest fit formula to actual experience.
COCOMO is an example of this model.

An algorithmic cost estimate for software cost can be expressed as:

Effort = A X SizeB X M

A is a constant factor that depends on local organizational practices and the type of software
that is developed. Size may be either an assessment of the code size of the software or a
functionality estimate expressed in function or object points. The value of exponent B is
usually lies between 1 and 1.5. M is a multiplier made by combining process, product and
development attributes, such as dependability requirements for the software and the
experience of the development team.

All algorithmic models suffer from the same fundamental difficulties:

1. It is often difficult to estimate Size at an early stage in a project when only a

specification is available. Function-point and object-point estimates are easier to produce
than estimates of code size but are often still inaccurate.

2. The estimates of the factors contributing to B and M are subjective. Estimates vary
from one person to another, depending on their background and experience with the type of
system that is being developed.

The accuracy of the estimates produced by an algorithmic model depends on the system
information that is available. As the software process proceeds, more information becomes
available so estimates become more and more accurate.

Justification of Chosen Technique

We choose algorithmic cost modeling technique for this project because it is based on
historical cost information, plus the formula which is used estimate cost takes into account
factors such as software size, the number of software engineers, and other process and
product factors. Thus makes estimates more accurate as compared to other techniques.

The COCOMO Model

This is an empirical model that was derived by collecting data from large number of software
projects. These data were analyzed to discover formulae that were the best fit to the
observations. These formulae link the size of the system and product, project and team factors
to the effort to develop the system. We chose this model because it is well documented,
available in the public domain and supported by public domain and commercial tools. It is
also widely used and evaluated in a range of organizations.

The formula for the basic COCOMO model (Sommerville, 2001):

Formula Description
Well-understood applications developed by small teams like our
PM = 2.4 (KDSI)1.05 x M
proposed system for DEC.

M is a multiplier made by combining process, product and development attributes, such as

the dependability requirements for the software and the experience of the development team.

KDSI is number of thousands of delivered source instruction

For this project we have made the basic COCOMO estimate of around RM25000.

Algorithmic cost models in project planning

One of the most valuable uses of algorithmic cost modeling is to compare different ways of
investing money to reduce project costs. This is very important when we have to make
hardware/software cost trade-offs and where we have to recruit new staff with specific
project skills. The algorithmic cost model helps to asses risks of each option. Applying the
cost model reveals the financial exposure that is associated with different management
options.

Conclusion

Today, almost no model can estimate the cost of software with a high degree of accuracy.
This state of the practice is created because:

1. there are a large number of interrelated factors that influence the software
development process of a given development team and a large and a large number of
project attributes, such as number of user screens, volatility of system requirements
and the use of reusable software components.
2. the development environment is changing continuously.
 3. the lack of measurement that truly reflects the complexity of a software system.

To produce a better estimate, we must improve our understanding of these project attributes
and their relationships, model the impact of changing environment, and develop effective
ways of measuring software complexity. To improve the algorithmic models, there is a greate
need for the industry to collect project data on a wider scale.

With new types of applications and new development tools, cost estimators are facing great
challenges in applying known estimation models. Historical data may prove to be irrelevant
for the future projects. The search for reliable, accurate and low cost estimation methods must
continue.