• Failure to properly estimate what you are building is

a recipe for a complete and unmitigated disaster of

Biblical proportions.
• Cost and Schedule estimation
– The first Software Engineering task is the estimation of the
cost and schedule for the development of a software
system.

• The development of software is an economic activity first and

foremost.
– Economic activities have to result in a net gain to the
sponsoring entity.

– The basis of capitalism is to realize a return on a product

sale that exceeds the cost of the product.

– To realize a return the developed product has to meet a

market expectation that is moving at high velocity.
• Late to market is effectively to be out of the market.
• Software Cost/Schedule estimation
– To render a valid business decision the individuals planning
to develop software first have to determine how much the
proposed system will cost and how long it will take to
develop it.
• This is critical to the basic business equation for how else can
market criticality and selling price be determined?
– This implies that there must be some way to translate a set
of requirements into man-months of effort (cost and time).

– Most project managers use ‘guestimation’ techniques to

determine the answer to the how long/how much question.
• For smaller efforts this approach, when provided by an
experienced, domain expert can be quit effective.
– The worst way to cost/schedule software development is to
use the “we have to have it by this time for this much
money therefore make it happen” approach.
• Cost Estimation
– Unfortunately our understanding of software is so poor that
we are not even sure how to size it (or measure it).
– LOC? (Lines of Code)
– FP? (Function Points)

– The problem with the LOC approach is that certain

languages and coding styles are more wordy than others.
• One line of ‘c’ code can do the same work as 100 lines of
Assembly Language ( fprintf )

– In addition if effort is measured by LOC then how do you

measure an ‘improvement’ to the design that reduces the
LOC?
• Is a NOP the same as JMPR?
• Guestimation
– A very useful technique when the sales staff first
bring a client to the corporation.
– The Software Engineer must actively participate in
the initial sales consultation meetings.
– From the joint work of the Project Manager and
Software Engineer will come the decision of
whether or not the particular project is
economically viable.
– From these first meetings the project will receive
a ‘rough’ sizing.
– These guestimates are essential and often quite
accurate (within 15% of final size).
• Software Engineering
– "You cannot manage what you cannot measure." In order
for any process to be manageable, there must exist sizing
metrics that can be put to good use.

– Development effort is exponentially proportional to

size: Software size is an important metric when it comes to
process measurement. This size metric is often related and
compared to other metrics in the process. Many calculated
metrics like productivity and defect rates are functions that
have software size as one of their domains. The metrics
data from previous projects is stored in a database and can
be applied in estimating future projects.

– Better project tracking: A quality size estimation process

provides the ability us to track the progress of the project
through techniques like the earned value analysis.
• Software Cost/Schedule
– Better planning: However, the most important
reason to estimate software size is to provide the
ability to make better project plans. A proper size
estimate leads to a quality development plan.
With a proper estimate of a project size, there
exists the base for determining the effort required
and the calculation of a price quotation. Once the
required effort is determined, a schedule can then
be produced accordingly.
– Probably the most effective direct measurement
for software size is to do a count of the number of
lines of source code that have been implemented.
Lines of Code, or SLOC, is the metric that has
been adopted by the Software Engineering
Institute and in turn, it has shown in the Personal
Software Process, or PSP.
• Software Cost/Schedule Analysis
– Historical databases from many programmers and firms
show that the time and effort involved in implementing a
software program is exponentially related to the software
size in lines of code. This linear relationship is strongest for
lower level programming languages like C, but is still extant
for the highest level fourth generation languages.

– Lines of code can also be easily applied to company

statistics such as productivity (LOC per programmer hour),
defect rates (number per 1000 LOC). LOC can also be used
in determining the effectiveness of product reviews and
inspections. Choose ONE below:
• Only new and modified LOC should counted towards
productivity.
• Allowing all code lines to be countable brings in a psychological
factor to maximize productivity through reuse.
• Software Cost/Schedule Estimation
– Advantages of using LOC as a metric.
– LOC is a direct measure of software size.
– LOC is easily counted.
– Counting can be easily automated.
– Simplicity of categorizing code into reusable, new, changed,
and reused.
– Disadvantages of LOC as a metric.
– A lack of agreement on standards in the software industry.
– LOC counts vary with language.
• 100 lines 4 G L may equal 1500 lines C and 15000 lines
of assembler.
– It is very difficult to visualize Lines of code early in the
development.
– The same automatic counter may not work for all
programming styles in the same language.
– A line of code is a strange term to most clients.
– Some stats using LOC can be misleading.
– Are SLOC a useful way to determine software cost and
development schedule?

– Source lines of code (SLOC) is perhaps the oldest of

software metrics, and still a benchmark for evaluating new
ones.
– Despite the extensive experience with the SLOC metric,
there are still a number of misconceptions about it.
– (1) that the format of SLOC is relevant to how to properly
count it (a simple experiment shows that, in fact, it does
not matter),
– (2) that SLOC is most useful as a predictor of software
quality (in fact, it is most useful as a covariate of other
predictors), and
– (3) that there is an important inverse relationship between
defect density and code size (in fact, this is an arithmetic
artifact of plotting bugs-per-SLOC against SLOC).  
• Function Points as a sizing metric
– In the late seventies, IBM felt the need to develop a
language independent approach to estimating software
development effort. It tasked one of its employees, Allan
Albrecht, with developing this approach. The result was the
function point technique.
– Function points are a measure of the size of computer
applications and the projects that build them. The
size is measured from a functional, or user, point of
view.
– It is independent of the computer language,
development methodology, technology or capability
of the project team used to develop the application.
– The fact that Albrecht originally used it to predict
effort is simply a consequence of the fact that size is
usually the primary driver of development effort. The
function points measured size.
• How does the use of function points compare
to the use of SLOC?

• The number of lines of code is the traditional way of

gauging application size. Some people claim it is still
relevant because it measures what software
developers actually do, that is, write lines of code.
They will use lines of code either instead of or in
addition to function points.
• Other practitioners say lines of code are irrelevant.
Capers Jones has declared "the use of lines of code
metrics for productivity and quality studies to be
regarded as professional malpractice starting in
1995."
• When the number of lines of code is your primary measure of
productivity, you often get it by having developers use less
powerful languages and ignore opportunities for reuse. When
the number of function points is your primary measure of
productivity, you tend to get increased and often unnecessary
additions of functionality.

•
• No matter which metric you use people will work to
excel at that metric
– Russian Nail factories
– Metric Factories.

• In reality the best solution is to use the strong

points of both approaches.
• Capers Jones has produced tables that indicate how
many statements of code it takes to implement a
function point. Obviously, this figure varies by
computer language

• For example, if you had an application consisting of

91,000 line COBOL program, these tables would lead
you to believe that you had a 1,000 function point
system. This is the backfiring technique. Many
people use it to get a rough size measure for a
portfolio of applications. .
• This approach is often the basis for
guestimations
• Now that a ground on software size metrics has
been covered, it is time to look at the actual size
estimation process.
• The size estimation is the first and most important
part of the project planning phase.
• This size estimate will dictate the rest of the project
plans, including the cost quote, time, and scheduling
of human and machine resources to complete the
task.

• The question that is most important is: How do

I perform a size estimation when I do not even
have a requirements document?
• COCOMO Constructive Cost Model.
– COCOMO II is a model that allows one to estimate the
cost, effort, and schedule when planning a new software
development activity.
– It consists of three submodels, each one offering increased
fidelity the further along one is in the project planning and
design process.
– Listed in increasing fidelity, these submodels are:
• Applications Composition,
• Early Design
• Post-Engineerure models.

–
• Rule of the World:
– The worst estimates are made at precisely the time when
we need the best.

– The COCOMO model is based on a set of equations that

reflect the non-linear communication overhead associated
with software development.

– LARGE PROJECTS

EFFORT = a * SIZEb

– SMALL PROJECTS

EFFORT = a * SIZE + b
• COCOMO
– The COCOMO cost estimation model is used by thousands of
software project managers, and is based on a study of
hundreds of software projects. Unlike other cost estimation
models, COCOMO is an open model, so all of the details are
published, including:

• The underlying cost estimation equations

• Every assumption made in the model (e.g. "the project will
enjoy good management")
• Every definition (e.g. the precise definition of the Product
Design phase of a project)
• The costs included in an estimate are explicitly stated (e.g.
project managers are included, secretaries aren't)
• COCOMO
– Because COCOMO is well defined, and because it doesn't
rely upon proprietary estimation algorithms COCOMO offers
these advantages to its users:
• COCOMO estimates are more objective and repeatable than
estimates made by methods relying on proprietary models
• COCOMO can be calibrated to reflect your software
development environment, and to produce more accurate
estimates
– Typically, you'll start with only a rough description of the
software system that you'll be developing, and you'll use
COCOMO to give you early estimates about the proper
schedule and staffing levels.
– As you refine your knowledge of the problem, and as you
design more of the system, you can use COCOMO to
produce more and more refined estimates.
Introduction to the COCOMO Model
• The most fundamental calculation in the COCOMO model is the
use of the Effort Equation to estimate the number of Person-
Months required to develop a project. Most of the other
COCOMO results, including the estimates for Requirements and
Maintenance, are derived from this quantity.
– Source Lines of Code
• The COCOMO calculations are based on your estimates of a
project's size in Source Lines of Code (SLOC). SLOC is defined
such that:
• Only Source lines that are DELIVERED as part of the product
are included -- test drivers and other support software is
excluded
• SOURCE lines are created by the project staff -- code created
by applications generators is excluded
• One SLOC is one logical line of code
• Declarations are counted as SLOC
• Comments are not counted as SLOC
COCOMO
– In the COCOMO II model, some of the most important
factors contributing to a project's duration and cost are the
Scale Drivers. The 5 Scale Drivers are set to describe the
project; these Scale Drivers determine the exponent used in
the Effort Equation.
– The 5 Scale Drivers are:
• Precedentedness
• Development Flexibility
• Engineerure / Risk Resolution
• Team Cohesion
• Process Maturity
• COCOMO
– Cost Drivers
– COCOMO II has 17 cost drivers.
– Assess the project, development environment, and team to
set each cost driver.
– The cost drivers are multiplicative factors that determine
the effort required to complete a software project.
– For example, if the project will develop software that
controls an airplane's flight, the Required Software
Reliability (RELY) cost driver would be set to Very High.
That rating corresponds to an effort multiplier of 1.26,
meaning that the project will require 26% more effort than
a typical software project.
• Analyst Capability •Platform Factors 
• Applications Experience •Execution Time Constraint
• Programmer Capability •Main Storage Constraint
• Programming Language Experience •Computer Turnaround Time
• Virtual Machine Experience •Virtual Machine Volatility
• Personnel Capability •Virtual Machine Volatility: Host
• Personnel Experience •Virtual Machine Volatility: Target
• Personnel Continuity •Platform Volatility
• Platform Experience •Platform Difficulty
• Language and Tool Experience •Platform 
•  
• Product Factors 
• Required Software Reliability
• Database Size
• Software Product Complexity
• Required Reusability
• Documentation Match to Life-Cycle Needs
• Product Reliability and Complexity 
•  
•  
• Project Factors 
• Use of Software Tools
• Modern Programming Practices
• Required Development Schedule
• Classified Security Application
• Multisite Development
• Facilities
• Requirements Volatility
• COCOMO II Effort Equation
– The COCOMO II model makes its estimates of required effort
(measured in Person-Months – PM) based primarily on the
estimate of the software project's size (as measured in thousands
of SLOC, KSLOC)):

     Effort = 2.94 * EAF * (KSLOC)E

Where
    EAF   Is the Effort Adjustment Factor derived from the Cost
Drivers
    E        Is an exponent derived from the five Scale Drivers

As an example, a project with all Nominal Cost Drivers and Scale

Drivers would have an EAF of 1.00 and exponent, E, of 1.0997.
Assuming that the project is projected to consist of 8,000 source
lines of code, COCOMO II estimates that 28.9 Person-Months of
effort is required to complete it:

    Effort = 2.94 * (1.0) * (8)1.0997 = 28.9 Person-Months

• Effort Adjustment Factor
• The Effort Adjustment Factor in the effort equation is simply
the product of the effort multipliers corresponding to each of
the cost drivers for a project.

For example, if the project is rated Very High for Complexity

(effort multiplier of 1.34), and Low for Language & Tools
Experience (effort multiplier of 1.09), and all of the other cost
drivers are rated to be Nominal (effort multiplier of 1.00), the
EAF is the product of 1.34 and 1.09.

    Effort Adjustment Factor = EAF = 1.34 * 1.09 = 1.46

    Effort = 2.94 * (1.46) * (8)1.0997 = 42.3 Person-Months

• The COCOMO II schedule equation predicts the number of
months required to complete a software project. The duration
of a project is based on the effort predicted by the effort
equation:

    Duration = 3.67 * (Effort)SE

    Effort   Is the effort from the COCOMO II effort equation
    SE        Is the schedule equation exponent derived from the
five Scale Drivers

Substituting the exponent of 0.3179 that is calculated from the

scale drivers, yields an estimate of just over a year, and an
average staffing of between 3 and 4 people:

    Duration = 3.67 * (42.3)0.3179 = 12.1 months

    Average staffing = (42.3 Person-Months) / (12.1 Months) =

3.5 people
– The SCED Cost Driver
– The COCOMO cost driver for Required Development
Schedule (SCED) is unique, and requires a special
explanation.

The SCED cost driver is used to account for the observation

that a project developed on an accelerated schedule will
require more effort than a project developed on its optimum
schedule.
– A SCED rating of Very Low corresponds to an Effort
Multiplier of 1.43 (in the COCOMO II.2000 model) and
means that you intend to finish your project in 75% of the
optimum schedule (as determined by a previous COCOMO
estimate).
• SCED COST DRIVER
– Continuing the example used earlier, but assuming that
SCED has a rating of Very Low, COCOMO produces these
estimates:

    Duration = 75% * 12.1 Months = 9.1 Months

    Effort Adjustment Factor = EAF = 1.34 * 1.09 * 1.43 =

2.09

    Effort = 2.94 * (2.09) * (8)1.0997 = 60.4 Person-Months

    Average staffing = (60.4 Person-Months) / (9.1 Months)

= 6.7 people
• Assignment
– Develop a program which will scan another
program and develop a ‘complexity’
evaluation.
– Obvious candidates for increasing
complexity are the number of calls,
number of calls to other objects, depth of
nesting of program sequence control
instructions.
– Use your imagination.
– Complexity is NOT a linear relationship – it
is exponential O Nn