Software Engineering Concepts
Estimation for software project
Chapter 26 , Software Engineering Practitioner’s Approach by Roger S. Pressman 7th ed
Software Estimation
• What is it?
Your attempt to determine how much money, effort, resources, and time it will take to build a specific
software-based system or product.
• Who does it?
Software project managers—using information solicited from project stakeholders and software metrics
data collected from past projects.
• Why is it important?
Would you build a house without knowing how much you were about to spend? reasonable to develop an
estimate before you start
2
What is the work product?
Can be a simple table showing the tasks to be performed and the cost, effort, and time involved for each
task.
How do I ensure that I’ve done it right?
That’s hard, because you won’t really know until the project has been completed
However, if you have experience and follow a systematic approach, generate estimates using solid
historical data
3
Project Planning
You should use three main parameters when computing the costs of a software
development project
1. Effort costs (the costs of paying software engineers and managers);
2. Hardware and software costs, including hardware maintenance and software support;
3. Travel and training costs.
biggest cost ->effort cost.
travel costs->usually a small fraction of the effort costs, the time spent traveling is often wasted and adds significantly to the
effort costs of the project.
4
The Estimation Process
You need first to scope the project even
if you do not have the full detailed
requirements but you can assume some
of them or add margins later.
You will need to break your software
into smaller components and functions
and you can categorize them to a
different set of elements,
Decomposition: Dividing the project into smaller parts
Sizing: Calculating the time and work required to
complete various tasks.
5
Resource Estimation
Human Resources
The planner begins by evaluating software scope and selecting the skills required to complete
development. organizational position (e.g., manager, senior software engineer).
For relatively small projects (a few person-months), a single individual may perform all software
engineering tasks, consulting with specialists as required. For larger projects, the software team may be
geographically dispersed across a number of different locations. Hence, the location of each human
resource is specified.
6
Project resources
Difference Between
COTS Components: Commercial off-the-
shelf are pre-built software products available
for general use and purchase in the market.
They are designed to meet a broad range of
requirements for various users without
significant modification. Eg Microsoft Office.
New Reusable Components: These are
custom-developed software modules or
libraries specifically created with reuse in
mind, often tailored to meet specific
organizational or project needs. They are
typically built during the software development
lifecycle.
Eg . A custom-built algorithm library designed
for predictive analytics in a company.
7
Reusable Software Resources
Off-the-shelf components.
Existing software that can be acquired from a third party or from a past project. COTS (commercial
off-the-shelf) components are purchased from a third party, are ready for use on the current project,
and have been fully validated
Full-experience components.
Existing specifications, designs, code, or test data developed for past projects that are similar to the
software to be built for the current project
Partial-experience components.
Existing specifications, designs, code, or test data developed for past projects that are related to the
software to be built for the current project but will require substantial modification
New components.
Software components must be built by the software team specifically for the needs of the current
project.
8
Software Project Estimation
Software cost and effort estimation will never be an exact science
To achieve reliable cost and effort estimates, a number of options arise:
1. Delay estimation until late in the project (obviously, we can achieve 100 percent accurate estimates
after the project is complete!). however attractive, it is not practical
2. Base estimates on similar projects that have already been completed.
Only if the current project is quite similar to past efforts
3. Use relatively simple decomposition techniques to generate project cost and effort estimates.
4. Use one or more empirical models for software cost and effort estimation
9
Decomposition techniques
Software sizing
• If a direct approach is taken, size can be measured in lines of code (LOC).
• If an indirect approach is chosen, size is represented as function points
(FP).
(The function point (FP) metric can be used effectively as a means for measuring the
functionality delivered by a system.)
10
An Example of Estimation
• The software will accept two- and three-dimensional geometric data from an
engineer. The engineer will interact and control the system through a user interface
that will exhibit characteristics of good human/machine interface design. All
geometric data and other supporting information will be maintained in a (computer-
aided design) CAD database.
• Design analysis modules will be developed to produce the required output, which
will be displayed on a variety of graphics devices. The software will be designed to
control and interact with peripheral devices that include a mouse, digitizer, laser
printer, and plotter.
11
Estimation table
Example: Consider the software has 33,200 lines of codes as listed in below. We can calculate an estimated
project cost by using LOC method.
12
Example cont.
A review of historical data indicates that the organizational average productivity for systems of this type
is 620 LOC/pm.
Based on a burdened labor rate of $8000 per month, the cost per line of code is approximately
$13. (8000/620)
Based on the LOC estimate and the historical productivity data, the total estimated project cost is
$431,000 . (13* 33200)
13
Question
• A software project is estimated to require 80,000 lines of code (LOC) for
completion. During the development process, it is found that the actual
number of lines of code produced is 90,000.
• If the productivity rate of the development team is 75 lines of code per
person-day, determine the following:
a) The estimated person-days initially allocated for the project.
b) The actual person-days required to complete the project.
c) The percentage variance between the estimated and actual person-days.
14
Answer
• A) initially estimated person-days for the project, = Total lines of code / Productivity rate Initial = 80,000
LOC / 75 = 1066.67 person-days (rounded to 1067)
• b) Actual person-days required to complete the project: = Actual lines of code produced / Productivity rate
Actual person-days = 90,000 LOC / 75 = 1200 person-days
• c) Variance between the estimated and actual person-days: Variance = |Initial estimated person-days - Actual
person-days| = |1067 person-days - 1200 person-days| = 133 person-days
Percentage Variance = (Variance / Initial estimated person-days) * 100 = (133 / 1067) * 100 ≈ 12.50%
Therefore:
• a) The initially estimated person-days allocated for the project were approximately 1067 person-days.
• b) The actual person-days required to complete the project were 1200 person-days.
• c) The percentage variance between the estimated and actual person-days is approximately 12.50%.
15
The Make buy Decision
In many software application areas, it is often more cost effective to acquire rather
than develop computer software
The software engineering organization can
(1) Build system X from scratch,
(2) reuse existing partial-experience components to construct the system,
(3) buy an available software product and modify it to meet local needs, or
(4) contract the software development to an outside vendor
16
Outsourcing
Why outsourcing
“Is there a way that we can get the software and systems we need at a
lower price and resources?
outsourcing is extremely simple. Software engineering activities are
contracted to a third party who does the work at lower cost and,
hopefully, higher quality.
17