UNIT 4

SOFTWARE PROJECT PLANNING

Satya Bahadur Maharjan

satya.maharjan@lacm.edu.np
Software Project Planning
 Software project management begins with a
set of activities that are collectively called
project planning.
 Before the project can begin, the manager
and the software team must estimate the
work to be done, the resources that will
be required, and the time that will
elapse from start to finish.
 Whenever estimates are made, we look into
the future and accept some degree of
uncertainty as a matter of course
Observation of Estimate
Estimation of resources, cost,
and schedule for a software
engineering effort requires
experience, access to good
historical information, and the
courage to commit to
quantitative predictions when
qualitative information is all that
exists.
 Estimation carries inherent risk
and this risk leads to uncertainty.
Observation of Estimate
Project complexity
Project size
The degree of structural
uncertainty
The availability of historical
information
Risk
PROJECT PLANNING
OBJECTIVES
 The objective of software project planning is
to provide a framework that enables the
manager to make reasonable estimates of
resources, cost, and schedule.
 These estimates are made within a limited
time frame at the beginning of a software
project and should be updated regularly as
the project progresses.
 In addition, estimates should attempt to
define best case and worst case
scenarios so that project outcomes can be
bounded.
ACTIVITIES ASSOCIATED WITH
PROJECT PLANNING
Software scope
resources
project estimation
decomposition
1. SOFTWARE SCOPE
Software scope describes the
data and control to be
processed, function,
performance, constraints,
interfaces and reliability.
SOFTWARE SCOPE
Software scope can be obtained
from:

◦ Obtaining Information Necessary for

Scope
◦ Feasibility
 2. RESOURCES
Must estimate resources required to
accomplish the development effort.

Fig: Project Resource

a. HW AND SW TOOLS
foundation of resources pyramid,
provides infrastructure to support
development
sw engineering environment
must prescribe the time-frame
required for hw and sw
verify that these resources will be
available
b. REUSABLE SW COMPONENTS
next level, can reduce
development costs
reuse considerations often
ignored
can greatly reduce development
time
c. PEOPLE - TOP OF
PYRAMID
select skills needed
EACH RESOURCE SPECIFIED WITH
4 CHARACTERISTICS
1. description of resource
2. statement of availability
3. chronological time resource
will be needed
4. duration of time resource used
3. PROJECT ESTIMATION
cost estimates must be provided
up front
but... the longer we wait, the
more we know, and the better
our estimates
a. USE OF DECOMPOSITION
TECHNIQUES
divide and conquer approach
decompose project into major
functions and related swe
activities
cost and effort estimates
performed in stepwise fashion
b. EMPIRICAL ESTIMATION
MODELS
can complement decomposition
techniques or used alone
model is based on historical data
examples: LOC, FP
SW cost estimation relies on
good historical data
4.DECOMPOSITION TECHNIQUES
decompose the problem (i.e., sw
project estimation) into set of smaller
problems
2 types of decomposition
 a. decomposition of the problem
 b. decomposition of the process
before decomposition, must
understand project scope and
generate estimate of project size
accuracy of estimate strongly
influenced by accuracy of size
 1. Software Sizing
The accuracy of a software project estimate is
predicated on a number of things:
1. The degree to which the planner has properly
estimated the size of the product to bebuilt
2. The ability to translate the size estimate into
human effort, calendar time, and dollars (a function
of the availability of reliable software metrics from
past projects)
3. The degree to which the project plan reflects the
abilities of the software team
4. The stability of product requirements and the
environment that supports the software
engineering effort.
 2. PROBLEM-BASED ESTIMATION
direct measure - LOC
indirect measure – FP (Function points)
a. begin with bounded statement of sw scope
b. decompose sw into problem functions that
can each individually be estimated
c. apply sizing measure to each function

◦ e.g. LOC, FP, OO (classes, objects)

d. apply baseline productivity metrics (e.g.,
LOC/pm, FP/pm)
DECOMPOSITION
decomposition is different for
LOC vs. FP:
for LOC - decomposition must be
detailed
for FP - looking at input, output,
inquiries, data files, interfaces
etc.
planner uses historical data or
intuition (not recommended)
For eg: ESTIMATION TABLE FOR
THE LOC METHOD
For eg: FP-Based
Estimation
PROCESS-BASED
ESTIMATION
a. determine sw functions using
project scope document
b. meld sw process activities and
functions
 determine sw process activities
that must be performed for each
function
 Process-based estimation
c. apply average labor rates to the
effort estimated for each process
activity
d. compute costs and effort for each
function and software process activitey
can perform process-based estimate
independently of LOC or FP
 then have 2-3 estimates of cost and
effort to compare and reconcile
EMPRICAL ESTIMATION MODELS
An estimation model for software
uses empirically derived formulas
to predict effort as a function of
LOC or FP.
The MODELS are:
1. The structure of estimation
models
2. The COCOMO model
3. The software equation
 1. The structure of estimation
models
A typical estimation model is derived using
regression analysis on data collected from
past software projects. The overall structure
of such models takes the form [MAT94]
E = A + B x (ev)C
where A, B, and C are empirically derived
constants, E is effort in person-months, and
ev is the estimation variable (either LOC or
FP).
Among the many LOC oriented
estimation models proposed in
the literature are:
2. The COCOMO Model
COnstructive COst MOdel
(COCOMO)
Predicts the effort and schedule for
a software development projects.

Based upon inputs:

 Size of software (KLOC)
 Number of cost drivers that affect
productivity
COCOMO was developed by Dr.
Barry Boehm in 1981
 Cont..
The basic COCOMO estimation model is given by the
following expressions:

Effort = a1 х (KLOC)a2 PM
Tdev = b1 x (Effort)b2 Months
Where

• KLOC is Kilo Lines of Code (size of project),

• a1, a2, b1, b2 are constants for each category of
project,
• Tdev is the estimated time to develop the software,
• Effort expressed in person months (PMs).
Person-Month
•The effort estimation is expressed in
units of person-months (PM).
•It should be carefully noted that an effort
of 10 PM does not imply
10 persons should work for 1 month
1 person should be employed for 10 months

•What it means :
 10 person effort typically
in 10 months
Constants of projects
The values of a1, a2, b1, b2 for different
categories of products :
 Example
 Wehave determined our project fits the
characteristics of Semi-Detached mode

 We estimate our project will have 32,000

Delivered Source Instructions.

 Using the formulas, we can estimate:

◦ Effort = 3.0*(32)^1.12 = 146 PM
◦ Schedule = 2.5*(146) ^0.35 = 14 months
◦ Cost required = 146*15000 = Rs.2,19,000 \-
◦ Average Staffing = 146 PM /14 months = 10
3. The Software Equation
Itis a dynamic multivariable
model that assumes a specific
distribution of effort over the life
of a software development
project.
Estimation model is:
Make/Buy Decision
 In many software application areas, it is often
more cost effective to acquire than develop
computer software.
 Software engineering managers are faced with a
make/buy decision that can be further
complicated by a number of acquisition options:
(1) Software may be purchased (or licensed) off-the-
shelf
(2) “Full experience” or “partial-experience” software
components may be acquired and then modified
and integrated to meet specific needs
(3) Software may be custom built by an outside
contractor to meet the purchaser‘s specifications.
Make/Buy Decision
Two ways for decision
◦ Creating a decision tree
◦ Outsourcing
1. Creating a Decision
Tree
The decision of make/buy can be
decided using the decision tree
as
Outsourcing
Fundamental question: “Is there a
way that we can get the software
and systems we need at a lower
price?”
Software engineering activities are
contracted to a third party who does
the work at lower cost and
hopefully, higher quality.
The decision to outsource can be
either strategic or tactical.
Scheduling and Error
Tracking
Comments on “Lateness”
What should we do when
management demands that we make
a deadline that is impossible?
Basic Principles
Software project scheduling is an
activity that distributes estimated effort
across the
planned project duration by allocating the
effort to specific software engineering
tasks.

Macroscopic schedule- identifies all

major software engineering activities and
the product functions to which they are
applied.
basic principles guide
software project scheduling:
Compartmentalization
Interdependency
 Time allocation
 Effort validation
 Defined responsibilities
 Defined outcomes
 Defined milestones
Tools of Scheduling
PERT (Program Evaluation and
Review Technique)
CPM (Critical Path Method)
GANTT Chart
Tracking Errors
Throughout the software process, a project
team creates work products
But the team also creates (and hopefully
corrects) errors associated with each work
product.
If error related measures and resultant
metrics are collected over many software
projects, a project manager can use these
data as a baseline for comparison against
error data collected in real time.
Error tracking can be used as one means for
assessing the status of a current project.
 Defect removal efficiency has been defined
as DRE = E/(E + D)
DRE is a process metric that provides a
strong indication of the effectiveness of
quality assurance activities

But DRE and the error and defect counts

associated with it can also be used to assist
a project manager in determining the
progress that is being made as a software
project moves through its scheduled work
tasks.
 developed averages for the following
metrics:
◦ Errors per requirements specification
page, Ereq
◦ Errors per component—design level,
Edesign
◦ Errors per component—code level, Ecode
◦ DRE—requirements analysis
◦ DRE—architectural design
◦ DRE—component level design
◦ DRE—coding