Transcript Software Project Planning - Pennsylvania State University

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