Title: Software Project Planning
1Software Project Planning
2SWE economics analysis (Boehm, 84)
- throughout the software lifecycle, there are many
decision situations involving limited resources
3Examples
- 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?
4Analyzing 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
5Question must ask
- How much information-buying is enough?
6Project 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
7project estimation
- first step in project planning
- estimate resources, cost, and schedule for sw
development project - requires experience and access to historical
information
8project 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
9project 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
10Activities associated with project planning
- Software scope
- resources
- project estimation
- decomposition
111. software scope
- want to establish a project scope that is
unambiguous and understandable at management and
technical levels - describes
- function
- performance
- constraints
- interfaces
- reliability
122. resources
- must estimate resources required to accomplish
the development effort - fig. 5.2 development resources pyramid
13a. 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
14b. reusable sw components
- next level, can reduce development costs
- reuse considerations often ignored
- can greatly reduce development time
15c. people - top of pyramid
16each 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
173. project estimation
- cost estimates must be provided up front
- but... the longer we wait, the more we know, and
the better our estimates
18a. 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
19b. 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
204. 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
21Problem-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)
22decomposition
- 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)
23estimation
- 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)
24Process-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
25Process-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
26Process-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
275. empirical estimation models
- The COCOMO Model Constructive Cost Model Boehm,
1984 - hierarchy of 3 increasingly detailed software
estimation models
28model 1
- Basic COCOMO model
- computes effort and cost estimated as LOC
29model 2
- Intermediate COCOMO model
- computes effort and cost using a set of cost
drivers - includes subjective assessments of product, hw,
personnoel, and project attributes
30model 3
- Advanced COCOMO model
- incorporates the intermediate version with an
assessment of the cost dirvers impact on each
step (analysis, design, etc.)
31Steps for intermediate level (see Boehm, 1984 for
detailed example)
32Step 1 - Nominal effort estimation
- determine projects development mode (organic,
semidetached, embedded) - estimate size of the project
33Step 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
34Step 3 - Estimate development effort
- compute estimated development effort nominal
effort X product of effort multipliers for 15
cost driver attributes
35Step 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
369 Management Guidelines for better cost
estimating (Lederer and Prasad)
- paper reports results of survey on cost
estimating practices of 115 computer
professionals
37Need 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
38Guidelines
- Based on results of survey, authors developed 9
guidelines for better cost estimation
391. 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
402. 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!
413. 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!
424. Monitor the progress of the proposed project
435. 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
446. 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
457.Computing management should carefully study and
approve the cost estimate
- need to conduct a cost/benefit review before
system development begins
468. 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
479. Dont rely on cost estimating software for an
accurate estimate.
- packages dont improve estimation, and lower the
satisfaction level of the estimators
48Words 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
49Words 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
50Words 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