Software Project Planning

Infsy 570
Dr. R. Ocker
SWE economics analysis
(Boehm, 84):
 throughout the software lifecycle, there
are many decision situations involving
limited resources
 Examples
 feasibility phase
– how much should we invest in analyses?
 plans and requirements phase
– how rigorously should we specify
requirements?
 design phase:
– should we use existing sw which does not
completely meet the requriements?
 test phase:
– how much testing is enough?
Analyzing risk and uncertainty
 can apply basic micro economic
analysis to these questions
 in sw engineering, must make decisions
under conditions of uncertainty
 can reduce uncertainty, and therefore
make better decisions, by buying
information
 e.g. prototyping is a way of buying
information to reduce uncertainty about
risky functionality
Question must ask:

 How much information-buying is

enough?
Project Planning

 sw project management process begins

with project planning

 objective of sw project planning - to

provide a framework for manager to
make reasonable estimates of
resources, costs and schedules
project estimation

 first step in project planning

 estimate resources, cost, and schedule

for sw development project
 requires experience and access to
historical information
project estimation

 estimation is risky business - lots of

uncertainty due to:
– project complexity
– project size
– degree of structural uncertainty - degree to
which requirements are solidified
– availability of historical information
 risk - measured by degree of
uncertainty in quantitative estimates
project estimation

 evolutionary process models - iterative

view of development
 possible to revise the estimate
 estimates made at beginning of sw
project
 should be updated regularly
 estimates should define “best case” and
“worst case”
Activities associated with
project planning
 Software scope
 resources
 project estimation
 decomposition
1. software scope

 want to establish a project scope that is

unambiguous and understandable at
management and technical levels
 describes:
– function
– performance
– constraints
– interfaces
– reliability
2. resources

 must estimate resources required to

accomplish the development effort

 fig. 5.2 development resources

pyramid
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
 from chp. 3 - 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 estimate
Problem-based estimation

 direct measure - LOC

 indirect measure - FP
 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)
estimation

 make 3 estimates for each function:

 optimistic, most likely, pessimistic
 then compute 3 point or expected value
 see 5.1
 then apply historical LOC or FP
productivity data (e.g. FP/pm)
Process-based estimation

 most common technique for estimating

project
 process is decomposed into a small set
of activities or task
 effort required to complete each is
estimated
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
 functions and process activities can
be part of a table - see fig 3.2
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
5. empirical estimation models

 The COCOMO Model: Constructive

Cost Model [Boehm, 1984]

 hierarchy of 3 increasingly detailed

software estimation models:
model 1

 Basic COCOMO model

 computes effort and cost estimated as
LOC
model 2

 Intermediate COCOMO model

 computes effort and cost using a set of
cost drivers
 includes subjective assessments of
product, hw, personnoel, and project
attributes
model 3

 Advanced COCOMO model

 incorporates the intermediate version
with an assessment of the cost dirver’s
impact on each step (analysis, design,
etc.)
Steps for intermediate level (see
Boehm, 1984 for detailed example):
 Four steps
Step 1 - Nominal effort
estimation
 determine project’s development mode
(organic, semidetached, embedded)
 estimate size of the project
Step 2 - Determine effort
multipliers
 15 cost drivers within model - each has
a rating scale and a set of effort
multipliers which modifies step 1
estimate
Step 3 - Estimate development
effort
 compute estimated development effort =
nominal effort X product of effort
multipliers for 15 cost driver attributes
Step 4 - Estimate related project
factors
 model has additional costing estimation
relationships for computing dollar cost
of project and for breakdown by lifecycle
phase and by type of project acitivity
 can estimate project schedule
9 Management Guidelines for better
cost estimating (Lederer and Prasad)

 paper reports results of survey on cost

estimating practices of 115 computer
professionals
Need for better estimates

 63% of all large projects (over $50,000)

significantly overrun cost estimates
 only 25% of projects completed at cost
reasonably close to project estimate
Guidelines

 Based on results of survey, authors

developed 9 guidelines for better cost
estimation
1. Assign the initial estimating
task to the final developers
 2 approaches:
 a. separate-function approach
– use experienced group of estimators to
conduct the feasibility study and prepare
initial project estimate
 b. combined-function approach
– final analysts and programmers prepare
initial estimate during feasibility study
– get more accurate estimates with this
approach
2. Delay finalizing the initial estimate
until the end of a thorough study

 often prepare initial cost estimate at

beginning of project and then revise it
(repeatedly) during the project
 found that revision of estimate does not
increase accuracy
 people seem to look to the original
estimate, not the revised estimate,
when judging cost estimation accuracy -
- so better to be right the first time!
3. Anticipate and control user
changes
 when lots of changes, like trying to
estimate cost of a moving target
 estimators need to thoroughly
understand user requirments before
they estimate its cost
– should be able to reduce and control
frequent change requests
– discourage unnecessary user changes -
charge extra!
4. Monitor the progress of the
proposed project
5. Evaluate project progress by
using independent auditors
 most projects usually monitored by
those involved in it
 more accurate estimates occur when
independent auditors are present
6. Use the estimate to evaluate
project personnel
 cost estimating used more for project
planning and control than for evaluation
of personnel
 could use positive rewards for
personnel who provide accurate
estimates and for those that meet the
estimates
7.Computing management should
carefully study and approve the cost
estimate
 need to conduct a cost/benefit review
before system development begins
8. Rely on documented facts, standards, and
simple arithmetic formulas rather than guessing,
intuition, personal memory, and complex formulas.

 greater accuracy found when do the

above
 less accuracy when rely on intuition and
personal memory, which is customary
9. Don’t rely on cost estimating
software for an accurate estimate.
 packages don’t improve estimation, and
lower the satisfaction level of the
estimators
Words of wisdom

 there is no way a cost estimation

technique can compensate for the lack
of definition or understanding of the sw
job to be done
Words of wisdom

 there is no magic formula that will

provide an easy and accurate substitute
for the process of thinking through and
fully understanding the nature of the
software product to be developed
Words of wisdom

 unless a software project has clear

definitions of its key milestones and
realistic estimates of the time and
money it will take to achieve them, there
is no way that a project manager can
tell whether the project is under control
or not