Object-Oriented and

Classical Software
Engineering
Eighth Edition, WCB/McGraw-Hill, 2011
 CHAPTER 9

PLANNING AND
ESTIMATING
9.1 Planning and the Software
Process
• Planning is a continuous process

• The entire project cannot be planned at the

start of the process because not enough
information is available to plan the entire
process

• In some situations, developers are required

to produce duration and cost estimates
before the specifications are drawn up
 Planning and the Software
Process (contd)

Figure 9.1

• The accuracy of estimation increases as

the process proceeds
 Planning and the Software
Process (contd)
• Example

– Cost estimate of $1 million during the

requirements workflow
• Likely actual cost is in the range ($0.25M, $4M)

– Cost estimate of $1 million at the end of the

requirements workflow
• Likely actual cost is in the range ($0.5M, $2M)

– Cost estimate of $1 million at the end of the

analysis workflow (earliest appropriate time)
• Likely actual cost is in the range ($0.67M, $1.5M)
 Planning and the Software
Process (contd)
• These four
points are
shown in the
cone of
uncertainty

Figure 9.2
9.2 Estimating Duration and
Cost
• Accurate cost estimation is a critical part of the
software project management plan
– Internal cost – Cost to the developers
• Salaries of the development teams, managers, etc.
• Cost of hardware and software
• Cost of overhead such as rent, utilities, etc.
– External cost – Price the client will pay

• Accurate duration estimation is another critical part

of any plan

• There are too many variables for accurate estimate

of cost or duration, including human factors
Estimating Duration and Cost
- Human Factors
• Human factors make cost and duration
estimation difficult
• Sackman (1968) measured differences of up to
28 to 1 between pairs of programmers
– He compared matched pairs of programmers with
respect to
• Product size
• Product execution time
• Development time
• Coding time
• Debugging time
• Critical staff members may resign during the
project
 9.2.1 Metrics for the Size of a
Product
• Lines of code
– Lines of Code (LOC)
– Thousand delivered source instructions
(KDSI)
• FFP
• Function Points
• COCOMO
Metrics for the Size of a Product
- Lines of Code (LOC)
• Alternative metric to LOC is
– Thousand delivered source instructions (KDSI)
• Problems
– Creation of source code is only a small part of
the total software effort
– Different languages lead to different numbers
of lines of code
– LOC is not defined for nonprocedural
languages (like LISP)

Continues on the next slide

 Metrics for the Size of a Product -
Lines of Code (LOC)
• Problems (continued)
– It is not clear how to count lines of code
• Executable lines of code?
• Data definitions?
• Comments?
• JCL statements (job control language)?
• Changed/deleted lines?
– Not everything written is delivered to the client
– A report, screen, or GUI generator can generate
thousands of lines of code in minutes
– Can only be determined when the product is
complete
Metrics for the Size of a Product
- Lines of Code (LOC)
• Estimation based on LOC is therefore
dangerous
– To start the estimation process, LOC in the
finished product must be estimated
– The LOC estimate is then used to estimate
the cost of the product — an uncertain input
to an uncertain cost estimator
 Metrics for the Size of a
Product
• Metrics based on measurable quantities
that can be determined early in the
software life cycle
– FFP metric
– Function points
Metrics for the Size of a Product
- FFP Metric
• For cost estimation of medium-scale data
processing products
• The three basic structural elements of data
processing products
– Files
• Collection of logically or physically related records permanently
resident in the product; transaction and temporary are
excluded
– Flows
• A data interface between the product and the environment,
e.g. a screen or a report
– Processes
• Functionally defined logical or arithmetic manipulation of data,
e.g. sorting, validating or updating
Metrics for the Size of a Product
- FFP Metric (contd)
• Given the number of files (Fi), flows (Fl), and
processes (Pr)
– The size (S), cost (C) are given by

S = Fi + Fl + Pr

C = dS

• The constant d (efficiency or productivity)

varies from organization to organization
Metrics for the Size of a Product
- Function Points
• Based on the number of inputs (Inp), outputs
(Out), inquiries (Inq), master files (Maf),
interfaces (Inf)

• For any product, the size in “function

points” is given by

FP = 4  Inp + 5  Out + 4  Inq + 10  Maf + 7  Inf

9.2.2 Techniques of Cost Estimation
• Expert judgment by similarity (analogy)
• Bottom-up approach
• Algorithmic cost estimation models
Expert Judgment by Analogy
• A number of experts are consulted
• Experts compare the target product to
completed products with which they were
actively involved
Expert Judgment by Analogy
• The Delphi technique is sometimes needed
to achieve consensus
– Experts work independently
– Each produce an estimate and rationale for
estimate
– These estimates and rationales are distributed
to all experts
– Experts now produce a second estimate
– Process continues until a consensus is
reached
– No group meetings take place during the
iteration process
Expert Judgment by Analogy
• Problems with Expert Judgment by Analogy
– Guesses can lead to hopelessly incorrect cost
estimates
– Experts may recollect completed products
inaccurately
– Human experts have biases

• However, the results of estimation by a

broad group of experts may be accurate
 Bottom-up Approach
• Break the product into smaller components
– Cost and duration estimates are made for each
component and combined for an overall figure
• Advantages
– Quicker and more accurate
– Likely to be more detailed
• Weakness
– A product is more than the sum of its parts
• When using the object-oriented paradigm
– The independence of the classes helps the
bottom-up approach
– However, the interactions among the classes
complicate the estimation process
Algorithmic Cost Estimation Models
• A metric is used as an input to a model for
determining product cost
– An algorithmic model is unbiased, and therefore
superior to expert opinion
– However, estimates are only as good as the
underlying assumptions

• COCOMO is a hybrid algorithmic cost

estimation model
 9.2.3 Intermediate COCOMO
• COnstructive COst MOdel (COCOMO)

• Step 1. Estimate the length of the product in KDSI (Thousand

delivered source instructions )

• Step 2. Estimate the product development mode

– Organic: Small and straightforward
– Semidetached: Medium sized
– Embedded: Complex
 Intermediate COCOMO
• Step 3. Compute the nominal effort

• Example:
– Organic product
– 12,000 delivered source statements (12 KDSI)
(estimated)

Nominal effort = 3.2  (KDSI)1.05 person-months

Nominal effort = 3.2  (12)1.05 = 43 person-

months
 9.2.4 COCOMO II
• Read through this section!
 9.2.5 Tracking Duration and Cost
Estimates
• Whatever estimation method used, careful
tracking is vital
– Deviations from estimation can serve as early
warning that something has gone wrong and
corrective action is required
 9.3 Components of a Software
Project Management Plan
• A software project management plan
(SPMP) has three main components
– The work to be done
– The resources with which to do it
– The money to pay for it
 Resources
• Software development requires resources

• Resources needed for software

development:
– People who will develop the software
– Hardware on which the software is run
– Support software, such as operating system,
text editors and version control software
 Work Categories
• Work that must be done falls into two
categories

– Project function
– Activity or task
 Work Categories
• Project function
– Work that continues throughout the project and
does not relate to a specific workflow
– Examples:
• Project management
• Quality control
 Work Categories
• Activity
– Work that relates to a specific workflow
– A major unit of work,
– With precise beginning and ending dates,
– That consumes resources such as computer
time or person-days, and
– Results in work products like the budget, design
documents, schedules, source code, or user’s
manual
• Task
Work Categories
– An activity comprises a set of tasks (the
smallest unit of work subject to management
accountability)

• Therefore, there are three kinds of work in

SPMP
– Project functions
– Activities
– Tasks
Completion of Work Products
• Milestone: The date on which the work
product is completed and passes review
• It must first pass reviews performed by
– Fellow team members
– Management
– The client
• Once the work product has been reviewed
and agreed upon, it becomes a baseline
and can only be changed through formal
procedures
 Work Package
• Work product, plus
– Staffing requirements
– Duration
– Resources
– The name of the responsible individual
– Acceptance criteria for the work product
 Money
• The detailed budget as a function of time,
allocated to
– Project functions
– Activities
 9.4 Software Project
Management Plan Framework

Figure 9.9
 9.5 IEEE Software Project
Management Plan
• Section 9.5 describes the IEEE Software Project
Management Plan in detail
 9.6 Planning Testing
• The SPMP must explicitly state what testing is
to be done
– What resources are needed
– Indicate testing to be done in each workflow
• Traceability is essential
• All black box test cases must be drawn up by
the SQA group as soon as possible after the
specifications are complete
– Code is run against test cases drawn up from the
specifications
• Every test plan must specify what testing is to
be performed, when it is to be performed and
how it is to be performed
9.7 Planning Object-Oriented
Projects
• An object-oriented product consists of
largely independent pieces

• Consequently, planning is somewhat

easier

• The whole is more than the sum of its

parts
 9.8 Training Requirements
• Training is not only needed by the users
but in some instances by the developers
as well

• Once the training needs have been

determined and the training plan drawn
up, the plan must be incorporated into the
SPMP
9.9 Documentation Standards
• Types of Documentation
– Planning
– Control
– Financial
– Technical
– Source code
– Comments within source code
 Documentation Standards
(contd)
• Reduce misunderstandings between team
members
• Aid SQA
• Only new employees have to learn the
standards
• Standards assist maintenance
programmers
• Standardization is important for user
manuals
 Documentation Standards
(contd)
• As part of the planning process
– Standards must be set up for all
documentation

• In a very real sense, the product is the

documentation
9.10 CASE Tools for Planning
and Estimating
• Read through this section!
 9.11 Testing the SPMP
• It is critical that the development
organization neither overestimate nor
underestimate the cost of the project or its
duration
– For this reason, the entire SPMP must be
checked by the SQA group before estimates
are given to the client
• We must check the SPMP in detail
– Paying particular attention to the duration and
cost estimates