CS3302

Project Planning
CS 3302
Lecture 4

David Smith
dmsmith@cc.gatech.edu

Planning 1
 Course Overview
CS3302

Week 2
Concept
Weeks 3-4
Requirements
Weeks 5-6
Design
Process Weeks 7-8
Management Code
Analysis Scheduling & Week 9
Planning Tracking Test
Week 10
Risk Management OO Concepts Slack Time
SW Design OO Design

Measurement
Testing
Requirements Design for Real-
Review Software Quality
Time
Software Re-Use

Design
Review Modeling
Summary
Demo
Planning 2
 Project Planning
CS3302

Software project planning is the most important, hardest

and least implemented aspect of a software project.

• Background
• Estimation
 Scoping the problem
 Resource planning
 Project estimation
• Decomposition Techniques
• Empirical Estimation Models
• Deciding on Metrics
Planning 3
 Let’s be Reasonable...
CS3302

“Today, a software cost estimation model is doing well if it can

estimate software development costs within 20% of the actual
costs, 70% of the time, and on its own turf (that is, within the
class of projects to which it has been calibrated) . . . . This is not
as precise as we might like, but it accurate enough to provide a
good deal of help in sofware engineering economic analysis and
decision making.

Barry Boehm: “Software Engineering Economics”

Planning 4
 Background
CS3302

Empirical: relying on practical experience or observation without

the benefit of scientific knowledge or theory

• Not becoming obsessive about planning accuracy is

not an excuse for failing to plan at all.
• Planning produces estimates of resources, cost and
schedule
 best case numbers from managers
 worst case numbers from engineers
 hope reality lies in between
• The plan becomes the basis for measuring progress
• Why is the first plan going to be flawed?
 Limited time frame at beginning of project
 Limited view of the project scope
Planning 5
 What should you do with this plan?
CS3302

• Stick it on the shelf and ignore it

• Make it hard to change
• Change it every week to reflect how things are
going
• Express it electronically where it is
 accessible to change
 under configuration control
• know who changed it
• know why they changed it

Planning 6
 Scoping the Problem
CS3302

• Identify the customer

• Customer discussions:
 Who is the end user [often not the customer]?
 Who has the authority to accept the finished product?
 What problem are we addressing?
 What documentation will be required?
 When does he believe he needs the product?
 Where is the work to be done?
 Why does he need the product?
 How will the product be developed / acquired?
• Identify the systems environment
• Identify necessary tools
• Identify potential re-use

Planning 7
 Resources
CS3302

• What people are available?

• What software can you really re-use?
 how much must be modified?
• if over 20% modification, consider starting afresh
 is the documentation sufficient for this customer?
• if not or marginal, cost of re-use gets very high
 what aspects can you re-use?
• code
• design
• design concepts
• requirements
• What tools are available? Are they adequate?

Planning 8
 Software Project Estimation
CS3302

• Never (C.D.: until the project is complete) an exact science

• Reduce to series of steps which will result in a useable
estimate:
 based on similar projects already completed
• presumes a set of metrics permitting comparison
• presumes sufficient similarity for useful comparison
 decompose problem into manageable pieces (more later)
 use “recognized” empirical models for estimating cost and
effort
• such models require considerable expertise in setting
parameters necessary to produce realistic plans
• “Mix and match” available techniques to cross-check answers
• Involve the developers in the planning process
 credibility of the estimates
 buy-in to the final plan
Planning 9
 Problem decomposition
CS3302

• “Fuzzy logic” sizing

 when you have no idea what you are doing
• Function point sizing
 when you know roughly the overall behavior of the
software
 see example later
• Standard component sizing
 when you know roughly what the solution looks like
• Change sizing
 when you are several (>2) cycles into the spiral model
• Process based decomposition
 necessary on big projects because different process
steps might be performed by different people
Planning 10
 Function Point Estimation Example
CS3302

Information Domain Value Count Weight FP Count

number of inputs 24 4 96
number of outputs 16 5 80
number of inquiries 22 4 88
number of files 4 10 40
number of external interfaces 2 7 14
count total 318

• Can use expected value computation for Count (Pressman P.114)

• Use Complexity Weighting Factors (Pressman P.87)
• Compute FP est = count_total * ( 0.65 + 0.01 *Fi )
• Compute labor months = FP est * 6.5
• Compute cost = labor hours * labor rate

Planning 11
 LOC Based Estimation Example
CS3302
Function Est. LOC
user interface and control (UIC) 2,300
2-D geometric analysis (2DGA) 5,300
3-D geometric analysis (3DGA) 6,800
data base management (DBM) 3,350
graphics displays (GD) 4,950
peripheral control (PC) 2,100
design analysis (DA) 8,400
estimated LOC 33,200

• Can use three point estimation

• Use historical data (or something) to compute effort based
on estimated LOC / pm
• Compute software cost from labor cost

Planning 12
 Empirical Estimation Models
CS3302

• General Structure:

Effort = A + B * (est_var) C

where A, B and C are constants and

est_var is either LOC or FP

• Listed on Pfleeger P. 112

• Produce widely differing results

 Moral: Nobody can do vicarious estimating

Planning 13
 COCOMO Models
CS3302

• Constructive Cost Model (Pfleeger P. 105 ff)

 Still uses “arbitrary” factors
• Estimates duration as well as effort
• Applies to three different circumstances:
 organic, semi-detached, embedded
• Three different models:
 Basic - similar structure to other models
 Intermediate - multiplies by “effort adjustment factor” to
cover special circumstances (0.9 -> 1.4)
 Advanced - partitions estimation across the life cycle
(see Process based Decomposition)

Planning 14
 The Software Equation
CS3302

t min = 8.14 * ( LOC / P ) 0.43 [mos; t min > 6 mo]

E = 180 * B * t 3 [person mos; t in years]
• Use this throughout this project:
 B = 0.15; P = 12,000
 Initially, scope number of lines of code
 Refine LOC and effort estimates during design
 Compute actual constants on project completion
• For this to be effective, each team member must report all
effort directly related to the software project
 All project phases
 All project tasks including team building, management
and metrics
• Future generations will thank you for your diligence!

Planning 15
 Your Project Plan
CS3302

• Schedule of Tasks with progress indication

• Metrics to be estimated and tracked; as a minimum:
 effort expended by project phase
 number of requirements
 requirements quality
 function points or lines of code
 number of test cases
 tests completed

Planning 16
 Application
CS3302

• For your projects, you should use these techniques to

determine the likelihood of your producing the product
• If the likelihood is low, now is an awefully good time to re-
scope the project
• Note: “you should use XXX” means “I expect to see the
results of XXX in your project documentation.”

Planning 17
 Project Deliverables
CS3302
Project Plan
1
Week 2
Concept Weeks 3-4 2 3
Requirements
Weeks 5-6
Design
Weeks 7-8
1 Code
2 Week 9
Test

Requirements
Specification Design
Description
Code
Test
Report

Personal Activity Reports

Planning 18
 Project Plan
CS3302

1 Introduction
<copy and paste directly from requirements specification>
2 Project Estimates
<describe estimation technique>
<table of module name, estimated effort>
3 Risk Management NOT YET
<identify all risks>
<table of risk, severity, consequences, detection, remediation>
4 Schedule NOT YET
<identify each task (1 week granularity)>
<identify starting and ending triggers for each task>
<list of tasks on project time line>
<include opportunities to review work products>
5 Resources
5.1 Resources Available
<table of person name intended hours task assignment>
5.2 Resource Loading NOT YET
<diagram mapping resource allocation onto the schedule>

Planning 19
 Project Estimation
CS3302

• You can read Pfleeger Section 3.3 if you suffer from insomnia
• If you really want to waste some energy, do a complete Function
Point analysis
• Try the Smith estimation principle:
 For each of the capabilities in the Requirements Spec Sections
3 and 5.3, guess at the number of Source Lines of Code
(SLOC)
 Add up the estimates
 Divide by 6 to convert to Student Hours for the total project
 Compare this total to the amount of time your team has
committed
 Adjust estimates / requirements to make these match.
 Continue revising these estimates as the project proceeds

Planning 20