CS451 Lecture 5: Software Project Planning Pressman, Chap 47

1
CS451Lecture 5 Software Project
PlanningPressman, Chap 4-7

• Yugi Lee
• STB 555
• [phone]
• leeyu_at_umkc.edu
• www.sice.umkc.edu/leeyu

2
Software Project Planning

• The overall goal of project planning is to
  establish a pragmatic strategy for controlling,
  tracking, and monitoring a complex technical
  project.
• Why?
• So the end result gets done on time, with quality!

3
The Steps

• Scopingunderstand the problem and the work that
  must be done
• Estimationhow much effort? how much time?
• Riskwhat can go wrong? how can we avoid it? what
  can we do about it?
• Schedulehow do we allocate resources along the
  timeline? what are the milestones?
• Control strategyhow do we control quality? how
  do we control change?

4
Write it Down!
Project Scope Estimates Risks Schedule Control
strategy
Software Project Plan
5
To Understand Scope ...

• Understand the customers needs
• understand the business context
• understand the project boundaries
• understand the customers motivation
• understand the likely paths for change
• understand that
• Even when you understand,
• nothing is guaranteed!

6
Cost Estimation

• project scope must be explicitly
• task and/or functional decomposition is necessary
• historical measures (metrics) are very helpful
• at least two different techniques should be used
• remember that uncertainty is inherent

7
Functional Decomposition
functional decomposition
Statement
perform
of Scope
a
"grammatical
parse"
8
Creating a Task Matrix
Obtained from process framework
framework activities
application functions
Effort required to accomplish each framework
activity for each application function
9
Conventional Methods LOC/FP Approach

• compute LOC/FP using estimates of information
  domain values
• use historical effort for the project

10
Normalization for Metrics
Normalized data are used to evaluate the process
and the product (but never individual people)
size-oriented normalization
the line of code approach

function-oriented normalization
the function point
approach
11
Typical Size-Oriented Metrics

• errors per KLOC (thousand lines of code)
• defects per KLOC
• per LOC
• page of documentation per KLOC
• errors / person-month
• LOC per person-month
• / page of documentation

12
CAD System Example LOC Approach
LOC/pm (line of code per month)Organizational
average productivity for systems of this type
UICF User interface and control facilities,
2DGA Two-dimensional geometric analysis 3DGA
Three-dimensional geometric analysis, DBM
Database management CGDF Computer graphics
display facilities, PCF Peripheral control
function DAM Design analysis modules
13
Typical Function-Oriented Metrics

• errors per FP (thousand lines of code)
• defects per FP
• per FP
• pages of documentation per FP
• FP per person-month

14
Why Opt for FP Measures?
15
Computing Function Points
16
Example FP(function point) Approach
17
Tool-Based Estimation
project characteristics
calibration factors
LOC/FP data
18
Empirical Estimation Models
General form
exponent
effort tuning coefficient size
usually derived
empirically
as person-months
derived
of effort required
usually LOC but
may also be
function point
either a constant or
a number derived based
on complexity of project
19
Estimation Techniques

• past (similar) project experience
• conventional estimation techniques
• task breakdown and effort estimates
• size (e.g., FP) estimates
• tools (e.g., Checkpoint)

20
Estimation Guidelines
estimate using at least two techniques

get estimates from independent sources

avoid over-optimism, assume difficulties
you've arrived at an estimate, sleep on it

adjust for the people who'll be doing the

jobthey have the highest impact

21
The Make-Buy Decision
22
Computing Expected Cost
expected cost
(path probability) x (estimated path cost)
i
i
For example, the expected cost to build is

expected cost 0.30(380K)0.70(450K)

build
429 K

similarly,


expected cost 382K
reuse

expected cost 267K
buy

expected cost 410K
contr
23

• Risk Management
• Pressman chap 6

24
Project Risks
What can go wrong?
What is the likelihood?
What will the damage be?
What can we do about it?
25
Reactive Risk Management

• project team reacts to risks when they occur
• mitigationplan for additional resources in
  anticipation of fire fighting
• fix on failureresource are found and applied
  when the risk strikes
• crisis managementfailure does not respond to
  applied resources and project is in jeopardy

26
Proactive Risk Management

• formal risk analysis is performed
• organization corrects the root causes of risk
• TQM concepts and statistical SQA
• examining risk sources that lie beyond the bounds
  of the software
• developing the skill to manage change

27
Risk Management Paradigm
control
track
RISK
identify
plan
analyze
28
Building a Risk Table
Risk
Probability
Impact
RMMM
Risk Mitigation Monitoring Management
29
Risk Mitigation, Monitoring, Management

• mitigationhow can we avoid the risk?
• monitoringwhat factors can we track that will
  enable us to determine if the risk is becoming
  more or less likely?
• managementwhat contingency plans do we have if
  the risk becomes a reality?

30
Risk Due to Product Size
Attributes that affect risk
estimated size of the product in LOC or FP?

estimated size of product in number of
programs,
files, transactions?

percentage deviation in size of product from
average for previous products?

size of database created or used by the
product?

number of users of the product?

number of projected changes to the
requirements
for the product? before delivery? after delivery?

amount of reused software?
31
Risk Due to Business Impact
Attributes that affect risk
affect of this product on company revenue?
visibility of this product by senior
management?
reasonableness of delivery deadline?
number of customers who will use this product
interoperability constraints
sophistication of end users?
amount and quality of product documentation
that
must be produced and delivered to the customer?

governmental constraints
costs associated with late delivery?
costs associated with a defective product?
32
Risks Due to the Customer
Questions that must be answered
Have you worked with the customer in the past?
Does the customer have a solid idea of
requirements?
Has the customer agreed to spend time with
you?
Is the customer willing to participate in
reviews?
Is the customer technically sophisticated?
Is the customer willing to let your people do
their
jobthat is, will the customer resist looking
over your
shoulder during technically detailed work?
Does the customer understand the software
engineering process?
33
Risks Due to Process Maturity
Questions that must be answered
Have you established a common process
framework?
Is it followed by project teams?
Do you have management support for software
engineering?
Do you have a proactive approach to SQA?
Do you conduct formal technical reviews?
Are CASE tools used for analysis, design and
testing?
Are the tools integrated with one another?
Have document formats been established?
34
Technology Risks
Questions that must be answered
Is the technology new to your organization?
Are new algorithms, I/O technology required?
Is new or unproven hardware involved?
Does the application interface with new
software?
Is a specialized user interface required?
Is the application radically different?
Are you using new software engineering methods?
Are you using unconventional software
development
methods, such as formal methods, AI-based
approaches,
artificial neural networks?
Are there significant performance constraints?
Is there doubt the functionality requested is
"do-able?"
35
Staff/People Risks
Questions that must be answered
Are the best people available?
Does staff have the right skills?
Are enough people available?
Are staff committed for entire duration?
Will some people work part time?
Do staff have the right expectations?
Have staff received necessary training?
Will turnover among staff be low?
36
Recording Risk Information
Project Embedded software for XYZ system Risk
type schedule risk Priority (1 low ... 5
critical) 4 Risk factor Project completion
will depend on tests which require hardware
component under development. Hardware component
delivery may be delayed Probability 60
Impact Project completion will be delayed for
each day that hardware is unavailable for use in
software testing Monitoring approach
Scheduled milestone reviews with hardware
group Contingency plan Modification of
testing strategy to accommodate delay using
software simulation Estimated resources 6
additional person months beginning 7-1-96
37
Project Scheduling and Tracking
Pressman Chap 7
38
Why Are Projects Late?

• an unrealistic deadline established by someone
  outside the software development group
• changing customer requirements that are not
  reflected in schedule changes
• an honest underestimate of the amount of effort
  and/or the number of resources that will be
  required to do the job
• predictable and/or unpredictable risks that were
  not considered when the project commenced
• technical difficulties that could not have been
  foreseen in advance
• human difficulties that could not have been
  foreseen in advance
• miscommunication among project staff that results
  in delays
• a failure by project management to recognize that
  the project is falling behind schedule and a lack
  of action to correct the problem

39
Scheduling Principles

• compartmentalizationdefine distinct tasks
• interdependencyindicate task interrelationshipsff
  ort validationbe sure resources are available
• defined responsibilitiespeople must be assigned
• defined outcomeseach task must have an output
• defined milestonesreview for quality

40
Defining Task Sets

• determine type of project
• assess the degree of rigor required
• identify adaptation criteria
• compute task set selector (TSS) value
• interpret TSS to determine degree of rigor
• select appropriate software engineering tasks

41
Example
42
Define a Task Network
43
Effort Allocation

• front end activities
• customer communication
• analysis
• design
• review and modification
• construction activities
• coding or code generation
• testing and installation
• unit, integration
• white-box, black box
• regression

40-50
15-20
30-40
44
Tools Timeline Chart