Software Quality Engineering

CT051-3-3

Estimating techniques

Software Engineering

Prepared by: xxx First Prepared on: xx-xx-xx Last Modified on: xx-xx-xx
Quality checked by: xxx
Copyright 2004 Asia Pacific Institute of Information Technology
 Topic & Structure of the lesson

• Software productivity
• Estimation techniques
• Algorithmic cost modelling
• Project duration and staffing

CT051-3-3 -Software Quality Engineering Requirement Analysis Part 1

 Learning Outcomes

• By the end of this lecture, YOU should be

able to:
– To introduce the fundamentals of software costing
and pricing
– To describe three metrics for software productivity
assessment
– To explain why different techniques should be
used for software estimation
– To describe the principles of the COCOMO 2
algorithmic cost estimation model

CT051-3-3 -Software Quality Engineering Requirement Analysis Part 1

 Fundamental estimation questions

• How much effort is required to complete

an activity?
• How much calendar time is needed to
complete an activity?
• What is the total cost of an activity?
• Project estimation and scheduling are
interleaved management activities.

CT051-3-3 -Software Quality Engineering Requirement Analysis Part 1

 Software cost components

• Hardware and software costs.

• Travel and training costs.
• Effort costs (the dominant factor in most
projects)
– The salaries of engineers involved in the project;
– Social and insurance costs.
• Effort costs must take overheads into account
– Costs of building, heating, lighting.
– Costs of networking and communications.
– Costs of shared facilities (e.g library, staff restaurant,
etc.).

CT051-3-3 -Software Quality Engineering Requirement Analysis Part 1

 Costing and pricing

• Estimates are made to discover the cost, to

the developer, of producing a software
system.
• There is not a simple relationship between
the development cost and the price charged
to the customer.
• Broader organisational, economic, political
and business considerations influence the
price charged.
CT051-3-3 -Software Quality Engineering Requirement Analysis Part 1
 Software pricing factors

CT051-3-3 -Software Quality Engineering Requirement Analysis Part 1

 Software productivity

• A measure of the rate at which individual

engineers involved in software development
produce software and associated
documentation.
• Not quality-oriented although quality
assurance is a factor in productivity
assessment.
• Essentially, we want to measure useful
functionality produced per time unit.

CT051-3-3 -Software Quality Engineering Requirement Analysis Part 1

 Productivity measures

• Size related measures based on some

output from the software process. This
may be lines of delivered source code,
object code instructions, etc.
• Function-related measures based on an
estimate of the functionality of the
delivered software. Function-points are the
best known of this type of measure.

CT051-3-3 -Software Quality Engineering Requirement Analysis Part 1

 Measurement problems

• Estimating the size of the measure (e.g.

how many function points).
• Estimating the total number of programmer
months that have elapsed.
• Estimating contractor productivity (e.g.
documentation team) and incorporating this
estimate in overall estimate.

CT051-3-3 -Software Quality Engineering Requirement Analysis Part 1

 Lines of code

• What's a line of code?

– The measure was first proposed when programs were
typed on cards with one line per card;
– How does this correspond to statements as in Java which
can span several lines or where there can be several
statements on one line.
• What programs should be counted as part of the
system?
• This model assumes that there is a linear
relationship between system size and volume of
documentation.

CT051-3-3 -Software Quality Engineering Requirement Analysis Part 1

 Productivity comparisons

• The lower level the language, the more

productive the programmer
– The same functionality takes more code to implement
in a lower-level language than in a high-level language.
• The more verbose the programmer, the higher
the productivity
– Measures of productivity based on lines of code
suggest that programmers who write verbose code are
more productive than programmers who write compact
code.

CT051-3-3 -Software Quality Engineering Requirement Analysis Part 1

 System development times

CT051-3-3 -Software Quality Engineering Requirement Analysis Part 1

 Function points

• Based on a combination of program characteristics

– external inputs (3,6) and outputs (4, 7);
– user interactions (3, 6);
– external interfaces (5, 10);
– files used by the system (7, 15).
• A weight is associated with each of these and the
function point count is computed by multiplying each
raw count by the weight and summing all values.

CT051-3-3 -Software Quality Engineering Requirement Analysis Part 1

 Function points

• The function point count is modified by complexity of the

project
• FPs can be used to estimate LOC depending on the
average number of LOC per FP for a given language
– LOC = AVC * number of function points;
– AVC (Average lines of codes) is a language-
dependent factor varying from 200-300 for assemble
language to 2-40 for a 4GL;
• FPs are very subjective. They depend on the estimator
– Automatic function-point counting is impossible.

CT051-3-3 -Software Quality Engineering Requirement Analysis Part 1

 Object points

• Object points (alternatively named application points) are

an alternative function-related measure to function points
when 4GLs or similar languages are used for
development.
• Object points are NOT the same as object classes.
• The number of object points in a program is a weighted
estimate of
– The number of separate screens that are displayed;
– The number of reports that are produced by the
system;
– The number of program modules that must be
developed to supplement the database code;

CT051-3-3 -Software Quality Engineering Requirement Analysis Part 1

 Object point estimation

• Object points are easier to estimate from a

specification than function points as they are
simply concerned with screens, reports and
programming language modules.
• They can therefore be estimated at a fairly
early point in the development process.
• At this stage, it is very difficult to estimate the
number of lines of code in a system.

CT051-3-3 -Software Quality Engineering Requirement Analysis Part 1

 Productivity estimates

• Real-time embedded systems, 40-160

LOC/P-month.
• Systems programs , 150-400 LOC/P-month.
• Commercial applications, 200-900
LOC/P-month.
• In object points, productivity has been
measured between 4 and 50 object
points/month depending on tool support and
developer capability.

CT051-3-3 -Software Quality Engineering Requirement Analysis Part 1

 Factors affecting productivity

CT051-3-3 -Software Quality Engineering Requirement Analysis Part 1

 Quality and productivity

• All metrics based on volume/unit time are

flawed because they do not take quality into
account.
• Productivity may generally be increased at the
cost of quality.
• It is not clear how productivity/quality metrics
are related.
• If requirements are constantly changing then an
approach based on counting lines of code is not
meaningful as the program itself is not static;

CT051-3-3 -Software Quality Engineering Requirement Analysis Part 1

 Estimation techniques

• There is no simple way to make an accurate

estimate of the effort required to develop a software
system
– Initial estimates are based on inadequate information in
a user requirements definition;
– The software may run on unfamiliar computers or use
new technology;
– The people in the project may be unknown.
• Project cost estimates may be self-fulfilling
– The estimate defines the budget and the product is
adjusted to meet the budget.

CT051-3-3 -Software Quality Engineering Requirement Analysis Part 1

 Changing technologies

• Changing technologies may mean that previous

estimating experience does not carry over to new
systems
– Distributed object systems rather than mainframe
systems;
– Use of web services;
– Use of ERP or database-centred systems;
– Use of off-the-shelf software;
– Development for and with reuse;
– Development using scripting languages;
– The use of CASE tools and program generators.

CT051-3-3 -Software Quality Engineering Requirement Analysis Part 1

 Estimation techniques

• Algorithmic cost modelling.

• Expert judgement.
• Estimation by analogy.
• Parkinson's Law.
• Pricing to win.

CT051-3-3 -Software Quality Engineering Requirement Analysis Part 1

 Estimation techniques

CT051-3-3 -Software Quality Engineering Requirement Analysis Part 1

 Pricing to win
• The project costs whatever the customer
has to spend on it.
• Advantages:
– You get the contract.
• Disadvantages:
– The probability that the customer gets the
system he or she wants is small. Costs do not
accurately reflect the work required.

CT051-3-3 -Software Quality Engineering Requirement Analysis Part 1

 Pricing to win

• This approach may seem unethical and un-

businesslike.
• However, when detailed information is lacking it
may be the only appropriate strategy.
• The project cost is agreed on the basis of an
outline proposal and the development is
constrained by that cost.
• A detailed specification may be negotiated or an
evolutionary approach used for system
development.

CT051-3-3 -Software Quality Engineering Requirement Analysis Part 1

 Top-down and bottom-up estimation

• Any of these approaches may be used top-

down or bottom-up.
• Top-down
– Start at the system level and assess the
overall system functionality and how this is
delivered through sub-systems.
• Bottom-up
– Start at the component level and estimate the
effort required for each component. Add these
efforts to reach a final estimate.

CT051-3-3 -Software Quality Engineering Requirement Analysis Part 1

 Top-down estimation
• Usable without knowledge of the system
architecture and the components that
might be part of the system.
• Takes into account costs such as
integration, configuration management
and documentation.
• Can underestimate the cost of solving
difficult low-level technical problems.

CT051-3-3 -Software Quality Engineering Requirement Analysis Part 1

 Bottom-up estimation
• Usable when the architecture of the
system is known and components
identified.
• This can be an accurate method if the
system has been designed in detail.
• It may underestimate the costs of system
level activities such as integration and
documentation.

CT051-3-3 -Software Quality Engineering Requirement Analysis Part 1

 Estimation methods
• Each method has strengths and weaknesses.
• Estimation should be based on several methods.
• If these do not return approximately the same
result, then you have insufficient information
available to make an estimate.
• Some action should be taken to find out more in
order to make more accurate estimates.
• Pricing to win is sometimes the only applicable
method.

CT051-3-3 -Software Quality Engineering Requirement Analysis Part 1

 Key points
• There is not a simple relationship between
the price charged for a system and its
development costs.
• Factors affecting productivity include
individual aptitude, domain experience, the
development project, the project size, tool
support and the working environment.
• Software may be priced to gain a contract
and the functionality adjusted to the price.
CT051-3-3 -Software Quality Engineering Requirement Analysis Part 1
 Key points
• Different techniques of cost estimation should
be used when estimating costs.
• The time to complete a project is not
proportional to the number of people working on
the project.

CT051-3-3 -Software Quality Engineering Requirement Analysis Part 1