Professional Documents
Culture Documents
Software Cost and Effort Estimation in Software Engineering Process
Software Cost and Effort Estimation in Software Engineering Process
Table of Contents
What is Costs Estimation?.....................................................................................................................................2
1.1.
1.1.1.
Conceptual Estimate............................................................................................................................2
1.1.2.
2.
3.
3.1.1.
3.1.2.
3.1.3.
3.1.4.
3.1.5.
3.1.6.
3.1.7.
3.2.
3.2.1.
3.2.2.
3.2.3.
3.2.4.
COCOMO 1 ..........................................................................................................................................8
3.2.5.
COCOMO 2 ........................................................................................................................................11
4.
5.
6.
6.2.
6.2.1.
Factor Analysis:..................................................................................................................................15
6.2.2.
6.2.3.
6.2.4.
6.2.5.
Page 1
Management asks, "Would you like more time?" We respond, "Thank you, no. I'll take some M-O-N-E-Y."
Customers offer, "Would you like to reduce the scope?" We answer, "Thank you, no. I'll take some M-ON-E-Y."
Sponsors demand a speedier schedule. We respond, "Thank you, no. I'll take some M-O-N-E-Y."
Page 2
From IT to construction, most projects have to purchase materials: routers and cables, shingles and cement, and so
on. We almost always must buy some things to complete the project work.
Regardless of scope or schedule, projects need funds to complete the work. Technically, even projects that use
only labor have funds attached to them; someone, somewhere is paying for that labor. What happens if you don't
have the correct amount of funds to complete the project scope? Your project is doomed.
The ultimate goal of cost estimation is to determine the amount of fixed and variable costs so that a cost
equation can be used to predict future costs. The function that represents the equation of a line will
appear in the format of:
y=mx+b
Where y = total cost
m = the slope of the line, i.e., the unit variable cost
x = the number of units of activity
b = the y-intercept, i.e., the total fixed costs
Page 3
Resources working on multiple projects take longer to complete tasks because of time lost switching
between them.
People are generally optimistic and often underestimate how long tasks will take.
Always build in contingency for problem solving, meetings and other unexpected events.
Cost each task in the Work Breakdown Structure to arrive at a total, rather than trying to cost the project
as a whole.
Agree a tolerance with your customer for additional work that is not yet defined.
Provide regular budget statements to your customer, copying your team, so they are always aware of the
current position.
Page 4
These are some of the common mistakes that can lead to inaccurate estimates.
Starting with an amount of money and making the project cost fit it.
There are two major types of cost estimation methods: algorithmic and non-algorithmic.
Algorithmic models vary widely in mathematical sophistication. Some are based on simple arithmetic formulas
using such summary statistics as means and standard deviations. Others are based on regression models and
differential equations. To improve the accuracy of algorithmic models, there is a need to adjust or calibrate the
model to local circumstances. These models cannot be used off-the-shelf. Even with calibration the accuracy can
be quite mixed.
We first give an overview of non-algorithmic methods.
3.1.Non-algorithmic Methods
3.1.1. Analogy costing:
An analogy costing model is a non-algorithmic costing model that estimates the cost of a project by relating it to
another similar completed project. 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 system 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.
Take a completed project, similar in scope, size, structure, environment, constraints, and functions to the current
project as its benchmark. Use reasoning and analogy to relate the actual costs incurred for elements of the
completed project to similar elements in the current project. Such estimation may be conducted either top-down
or bottom-up.
This method has the advantage of assessing costs based on actual project experience rather than theoretical
assumptions. Success, however, depends on the extent to which the previous project bears resemblance to the
current project, and such relation remains subjective.
Page 5
A related method is the parametric estimation model, or taking historical information as the base, making
assumptions regarding changes, and extrapolating the information to the preset project
Page 6
3.2.Algorithmic methods
The algorithmic methods are based on mathematical models that produce cost estimate as a function of a number
of variables, which are considered to be the major cost factors. Any algorithmic model has the form:
Effort = f(x1, x2, , x)
Denote the cost factors. The existing algorithmic methods differ in two aspects: the selection of cost factors, and
the form of the function f. We will first discuss the cost factors used in these models, then characterize the models
according to the form of the functions and whether the models are analytical or empirical.
Page 7
Product factors: required reliability; product complexity; database size used; required reusability;
documentation match to life-cycle needs;
Computer factors: execution time constraint; main storage constraint; computer turnaround constraints;
platform volatility;
Project factors: multisite development; use of software tool; required development schedule. The above
factors are not necessarily independent, and most of them are hard to quantify. In many models, some of
the factors appear in combined form and some are simply ignored. Also, some factors take discrete
values, resulting in an estimation function with a piece-wise form.
3.2.4. COCOMO 1
The most popular algorithmic cost estimation model for software projects is the Constructive Cost Model
(COCOMO II), developed by Barry Boehm and Ellis Harrowitz in 2000.
3.2.4.1. The basic COCOMO'81
It is a simple static model that considers the software development cost as a function of a program's size
expressed in estimated lines of code.
Page 8
It computes software development effort (and cost) as a function of program size expressed in estimated lines of
code (LOC). The basic COCOMO estimation model is given by the following expressions:
Effort = a * (KLOC)b PM
Tdev = 2.5 * (Effort)c Months
here
KLOC is the estimated size of the software product expressed in Kilo Lines of Code
Effort is the total effort required to develop the software product, expressed in person months (PMs)
The effort estimation is expressed in units of person-months (PM).
The value of the constants a, b, c are given below:
Software project
Organic
2.4
1.05
0.38
Semi-detached
3.0
1.12
0.35
Embedded
3.6
1.20
0.32
Page 9
The intermediate COCOMO model recognizes this fact and refines the initial estimate obtained using the basic
COCOMO expressions by using a set of 15 cost drivers (multipliers) based on various attributes of software
development. For example, if modern programming practices are used, the initial estimates are scaled downward
by multiplication with a cost driver having a value less than 1.
Each of the 15 attributes receives a rating on a six-point scale that ranges from "very low" to "extra high" (in
importance or value) as shown below. An effort multiplier from the table below [i] applies to the rating. The
product of all effort multipliers results in an Effort Adjustment Factor (EAF).
Page 10
Regardless of the cost estimation model chosen, success depends on a good understanding of how the model
works and how to apply it to determine project costs. A project manager is better off adopting a familiar yet
limited albeit suitable model rather than another model, which may enjoy better industry recognition but which
the project manager remains incompetent to handle.
The following development project can be considered as an example application of the complete COCOMO model.
A distributed Management Information System (MIS) product for an organization having offices at several places
across the country can have the following sub-components:
Database part
Communication part
Of these, the communication part can be considered as embedded software. The database part could be semidetached software, and the GUI part organic software. The costs for these three components can be estimated
separately, and summed up to give the overall cost of the system.
3.2.5. COCOMO 2
Cocomo 2 consists of two models; the Early Design Model and the Post-Architecture model.
The Early design model is a high-level model and can be used in the architectural design stage to explore
architectural alternatives or incremental development strategies. This model is closest to the original COCOMO.
The Post-Architectural model on the other hand is a more detailed model that can be used for the actual
development stage and maintenance stage. It is the most detailed version of COCOMO 2.
Both the early Design model and the Post-Architecture model use the same formula to estimate the amount of
effort required to develop a software project. Besides these two models also the Application Composition model is
described by B. Bohem.
The Application Composition model can be used as sizing metric for application composition; and the estimation is
based on the number of screens, reports and 3GL components.
Page 11
Formula:
Page 12
4. Effort Estimation?
Effort can be measured in staff-hours or staff-months (Used to be known as man-hours or man-months).
Effort estimation is answering two basic questions about testing:
I.
II.
An estimate of
Cost
An estimate of
Before we can plan the project schedule we have to estimate effort and duration of all the work packages of
the WBS. Effort estimation will generate a lot more information than only effort and duration:
Page 13
Page 14
There are two categories of estimating the effort of each work package: deductive and inductive methods.
For example, the effort of a work package "Develop hardware control unit" is influenced by
the number of people involved, P=4,
the number of interfaces, S=5,
the number of functional blocks, B=10.
From earlier projects with similar control units we might know the correlation coefficients. For example, cP=2.5,
cS=2, cB=1.5, cU=2.0. Our formula could look like this
Effort = f(P, S, B) = cP*P + cS*S*S + cB*B =
= 10 + 50 + 15 =
= 75 (working days)
Page 15
Page 16