Software Cost and Effort Esitmation

BY: Taqi Shah Page 1
Table of Contents
1. What is Costs Estimation?.....................................................................................................................................2
1.1. Types of Cost Estimate.................................................................................................................................2
1.1.1. Conceptual Estimate............................................................................................................................2
1.1.2. Detailed Estimate ................................................................................................................................2
2. Why Costs Estimation? .........................................................................................................................................2
3. How to Make Cost Estimation?.............................................................................................................................4
3.1. Non-algorithmic Methods............................................................................................................................5
3.1.1. Analogy costing: ..................................................................................................................................5
3.1.2. Expert judgment:.................................................................................................................................6
3.1.3. Parkinson’s Method ............................................................................................................................6
3.1.4. Price-to-Win Model .............................................................................................................................6
3.1.5. The Definitive Estimate (or bottom-up estimate) ...............................................................................7
3.1.6. The Budget Estimate (or top-down estimate).....................................................................................7
3.1.7. Reserve Analysis:.................................................................................................................................7
3.2. Algorithmic methods....................................................................................................................................7
3.2.1. Cost factors..........................................................................................................................................8
3.2.2. Linear models ......................................................................................................................................8
3.2.3. Power function models .......................................................................................................................8
3.2.4. COCOMO 1 ..........................................................................................................................................8
3.2.5. COCOMO 2 ........................................................................................................................................11
4. Effort Estimation? ...............................................................................................................................................13
5. Why Effort Estimation?.......................................................................................................................................13
6. How Effort Estimating?.......................................................................................................................................13
6.1. Deductive or Top-down Methods..............................................................................................................15
6.2. Inductive or Bottom-up Methods ..............................................................................................................15
6.2.1. Factor Analysis:..................................................................................................................................15
6.2.2. Multiplication Method: .....................................................................................................................15
6.2.3. Analogy Method:...............................................................................................................................15
6.2.4. Function Point Method: ....................................................................................................................16
6.2.5. Delphi Method: .................................................................................................................................16

1. What is Costs Estimation?
In a book 'How to be a Better Project Manager', Trevor L Young defines estimating as;
"A decision about how much time and resource are required to carry out a piece of work to acceptable standards
of performance."
And Cost Estimate as;
“The process of forecasting a future result in terms of cost, based upon information available at the time."
Projects normally have a budget, and continual cost estimation is necessary to ensure that spending is in line with
the budget. Accurate software cost estimates are critical to both developers and customers. It answers the
questions what are the costs associated with the effort required to produce each major deliverables, what are the
costs associated with hardware and software, what other non-labor costs need to be considered, and what
operating costs need to be considered and identified.
1.1.Types of Cost Estimate
Cost estimates fall into two groups: conceptual estimates and detailed estimates. Each can be broadly defined as
follows:
1.1.1. Conceptual Estimate
Conceptual estimating or parametric estimating is the process of establishing a project’s cost, often before any
graphical representation of a facility has been developed.
1.1.2. Detailed Estimate
The detailed construction estimate is the product of a process whereby the cost of a proposed construction project
is predicted. The estimate is prepared by breaking down the items of work in an orderly and logical basis,
determining the cost of each item from experience, and summarizing the total.
2. Why Costs Estimation?
IT suffers from a universal law: the first-time, first-use penalty. The concept of the first-time, first-use penalty is
that it's next to impossible to accurately estimate the cost of something that has never been attempted. IT is so
unique, so multifaceted, and has so many fronts that the constant movement of its variables creates a love-hate
relationship for any organization trying to create an IT cost estimate.
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-O-
N-E-Y."
Sponsors demand a speedier schedule. We respond, "Thank you, no. I'll take some M-O-N-E-Y."

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 = m x + 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
To avoid project cost overruns.
Minimizing the differences between preliminary project planning cost estimates and final project design
cost estimates.
Accurate cost estimation is important because It can help to classify and prioritize development projects
with respect to an overall business plan.

3. How to Make Cost Estimation?
The actual cost estimation process involves seven steps:
1) Establish cost-estimating objectives
2) Generate a project plan for required data and resources
3) Pin down software requirements
4) Work out as much detail about the software system as feasible
5) Use several independent cost estimation techniques to capitalize on their combined strengths
6) Compare different estimates and iterate the estimation process
7) After the project has started, monitor its actual cost and progress, and feedback results to project
management No matter which estimation model is selected, users must pay attention to the following to
get best result.
Many techniques, books and software packages exist to help with estimating project costs. A few simple rules will
also help ensure you create an accurate and realistic estimate.
Assume resources will only be productive for 80 percent of their time.
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.
Make use of other people's experiences and your own.
Get an expert view.
Include management time in any estimate.
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.
Communicate any assumptions, exclusions or constraints you have to your customer.
Provide regular budget statements to your customer, copying your team, so they are always aware of the
current position.

These are some of the common mistakes that can lead to inaccurate estimates.
Not understanding what is involved to complete an item of work.
Starting with an amount of money and making the project cost fit it.
Assigning resources at more than 80 percent utilization.
Failing to build in contingency.
Failing to adjust the estimate following changes in scope.
Dividing tasks between more than one resource.
Providing estimates under pressure in project meetings.
Giving single-data-point estimates rather than range estimates.
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.

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
3.1.2. Expert judgment:
The expert judgment costing model makes the assessment of costs by leveraging the experience of one or more
subject matter experts (SME).
A common expert judgment model is the Delphi technique, which involves constituting an expert panel,
conducting a survey where each expert states their opinion, followed by discussion, and repeating the exercise
multiple rounds until all the experts develop a consensus to identify a common cost estimate.
Agile projects rely on the experience of people who actually undertake the work and remain familiar with actual
costs, rather than theoretical or boardroom experts detached from the actual operations.
Expert judgment methods are grounded in practical realities but remain highly subjective. Success depends wholly
on the skills and competence of the experts chosen.
3.1.3. Parkinson’s Method
Parkinson’s Law holds that “work expands to fill the available volume or time.” Using this percept, cost estimation
is based on identifying available resources rather than any objective assessment or estimates. For instance, the
cost estimate for a software project with a timeframe of 12 months and personnel requirement of five entails
direct calculation of the wages of five people for 12 months. This method, though simple and straightforward, may
create unrealistic estimates and may not cover all bases. Although it sometimes gives good estimation, this
method is not recommended as it may provide very unrealistic estimates. Also, this method does not promote
good software engineering practice.
3.1.4. Price-to-Win Model
The price-to-win model estimates cost based on the customer’s budget rather than internal resources or
capabilities, and by extension depends on the product pricing, which in turn depends on market forces.
This is a practical approach, for ultimately the net cost is what the customer pays, minus profits, and any excess
scope or size invariably gets toned down to match customer budgets. For instance, if a software project was
estimated at 500 person-months, it would invariably be toned down to 300 person-months if the customer could
afford only that much. On the flip side, this approach does not consider the possibility of projects incurring loss
owing to scope creep or any other reason.
This is again not a good practice since it is very likely to cause a bad delay of delivery or force the development
team to work overtime.

3.1.5. The Definitive Estimate (or bottom-up estimate)
It is the most accurate of the estimate types, but takes the most time to create. The definitive estimate requires a
work breakdown structure (WBS). A WBS is not a list of activities. A WBS is a deliverables-oriented decomposition
of the project scope. That's decomposition of the deliverables that your project will create for the customer.
Then each component of the software system is separately estimated and the results aggregated to produce an
estimate for the overall system. The requirement for this approach is that an initial design must be in place that
indicates how the system is decomposed into different components
3.1.6. The Budget Estimate (or top-down estimate)
It is a bit more accurate. Formulated fairly early in the project's planning stage, the budget estimate is most often
based on analogous estimating, taking budget lessons learned from a similar project and applying them to the
current project. Do a little maths magic and we've got ourselves a budget estimate.
With the budget estimate, we start at the top and work our way down into the project details. This estimate
should include conditions, a range of variance, and any assumptions that went into your calculations. A budget
estimate is quick, but not very accurate. The range of variance on the budget estimate is from -10 percent to +25
percent. This approach is more suitable for cost estimation at the early stage.
3.1.7. Reserve Analysis:
The method deals with unforeseen circumstances in a project environment, which necessitates the
establishment of reserves for the project activities. These reserves are also called contingency
allowances that are utilized for reducing risks, and countering threats. Characteristics of a cost
estimating system are to ensure that the cost estimates are accurate. If the funds are not adequate,
then the reserves are used for the project activities.
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) where {x1, x2, …, xn}
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.

3.2.1. Cost factors
Besides the software size, there are many other cost factors. The most comprehensive set of cost factors are
proposed and used by Boehm et al in the COCOMO II model. These cost factors can be divided into four types:
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;
Personnel factors: analyst capability; application experience; programming capability; platform
experience; language and tool experience; personnel continuity;
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.2. Linear models
Linear models have the form:
Where,a1,a2..,an are selected according to the project information.
work of Nelson belongs to this type of models [26]. We agree with Boehm's comment that "there are too many
nonlinear interactions in software development for a linear model to work well”.
3.2.3. Power function models
Power function models have the general form:
Effort = aSb
Where S is the code-size, and a, b are (usually simple) functions of other cost factors. This class contains two of the
most popular algorithmic models in use, as follows:
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.

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
a, b, c are constants for each category of software products
Tdev is the estimated time to develop the software, expressed in months
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 a b c
Organic 2.4 1.05 0.38
Semi-detached 3.0 1.12 0.35
Embedded 3.6 1.20 0.32
3.2.4.2. The intermediate COCOMO'81 model
It computes software development cost as a function of program size and a set of four subjective cost drivers:
product factors, computer factors, constraints, and personnel factors. Product factors include aspects such as
required reliability, complexity, usability, size of database, and more. Computer factors include constraints such as
execution time, storage, turnaround, and platform volatility. Personnel factors include capability of the analyst,
application, language, and tool experience, personnel continuity, and more. Project factors include multi-site
development, software tools and more.
The basic COCOMO model assumes that effort and development time are functions of the product size alone.
However, many other project parameters apart from the product size affect the development effort and time
required for the product. Therefore, in order to obtain an accurate estimation of the effort and project duration,
the effect of all relevant parameters must be taken into account.

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).
EAF is used to refine the estimates obtained by basic COCOMO as follows:
Effort|corrected = Effort * EAF
Tdev|corrected = 2.5 * (Effort|corrected) c
3.2.4.3. The detailed COCOMO'81 model
It incorporates all characteristics of the intermediate version and also incorporates an assessment of the cost
driver’s impact on each step of the software engineering process.

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
Graphical User Interface (GUI) part
Communication part
Of these, the communication part can be considered as embedded software. The database part could be semi-
detached 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.

Formula:

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. What will be done?
II. How much effort would it take?
A project manager has to produce:
An estimate of the effort.
An estimate of the activity durations.
An estimate of
effort affects ------- Cost
An estimate of
activity durations affects The delivery time
5. Why Effort Estimation?
Estimating the effort of software development is fraught with difficulties, and it is clear that effort should be
invested in improving the accuracy and the reliability (consistency) of effort estimates, as well as the assessment of
estimate uncertainty. However, it is less clear where to target such improvement efforts.
6. How Effort Estimating?
Effort estimation represents step 3 of the project planning process.
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:

• Who will be responsible for each work package?
• What is the work package specification?
• What are the expected results of each work package?
• How is the achievement of the results measured?
• What are the prerequisites for the work package?
• What are the conditions under which the work has to be done?
• What are the required start and end times?
• What and how much material is needed for each work package, at what cost?
• What tools are needed for each work package, at what rates?
Obviously, effort estimation needs expertise on a work package specific level to accomplish this transition.

There are two categories of estimating the effort of each work package: deductive and inductive methods.
6.1.Deductive or Top-down Methods
Assume the total cost for the project is given. From there we assign the cost, and thus, the effort of individual work
packages based on estimated percentages derived from earlier, similar projects with similar work packages. The
advantage of deductive methods is a simple and rapid cost allocation, the disadvantage is that they only work for
projects that consist of work packages we already know from earlier, similar projects.
6.2.Inductive or Bottom-up Methods
The basic idea of inductive methods is to start effort estimation with the work packages individually,
with support of experts, or knowledge of similar work packages of earlier projects, and then summarize
bottom up, following the structure of the WBS.
6.2.1. Factor Analysis:
For a certain work package, we know all the variables or factors, how they influence the work, and how these
factors correlate with each other. Then we can calculate the effort based on a mathematical formula which reflects
that influences and correlations.
Effort = f (influencing variables, correlation coefficients).
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)
6.2.2. Multiplication Method:
If we can divide a work package into a number of equal parts then, we can estimate the total effort by estimating
one part and then multiplying this value by the number of parts.
Total Effort = Effort of one part * number of parts
6.2.3. Analogy Method:
This method again applies the knowledge from similar work packages. We interpolate or extrapolate the effort for
the work package from a similar one. For example, for the work package “Install electrical wiring in an apartment
of 100 sqm” we could guess the effort by interpolation from similar work for apartments of 150 sqm, 10 working
days, and 50 sqm, 6 working days:

Effort(100 sqm) = (10 + 6) / 2 = 8 working days.
6.2.4. Function Point Method:
For IT or software design related work packages we can apply the function point method. The prerequisite is that
we need to have a lot of knowledge about the effort of work packages of similar scope and degree of difficulty,
based on observation. Then the experts compile this knowledge into so called “function curves” which we can use
to estimate effort for new work packages. In the following example we estimate the effort of work about creating
100, 500, and 800 lines of code. We obtain the effort via the corresponding function points on the function curve,
5, 16, and 33 working days, respectively.
6.2.5. Delphi Method:
For most of our work packages we use the Delphi method. We just ask the experts for each work package for their
best guess, normal guess, and worst guess. Thus we obtain three figures for the expected effort: E(optimistic),
E(normal), and E(pessimistic), then combine them with this formula
Effort = (E(optimistic) + 4*E(normal) + E(pessimistic)) / 6.
If we can ask ten or more experts, we could even calculate the mean values and apply mathematical statistics with
the concept of standard deviation.
Usually, we ask all the experts to join an effort estimation workshop which can be combined with a risk
management workshop, of two, three, or more days depending on the number of work packages that have to be
estimated.

Software Cost and Effort Esitmation

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Software Cost and Effort Esitmation

Ähnlich wie Software Cost and Effort Esitmation (20)

Mehr von Muhammad Taqi

Mehr von Muhammad Taqi (7)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Software Cost and Effort Esitmation