Project Planning - PowerPoint PPT Presentation

About This Presentation
Title:

Project Planning

Description:

There is a lot of pseudo-science in planning. More so even than in other SE subfields ... Imagine building a skyscraper or a bridge without a time/resource plan ... – PowerPoint PPT presentation

Number of Views:40
Avg rating:3.0/5.0
Slides: 37
Provided by: alex256
Category:

less

Transcript and Presenter's Notes

Title: Project Planning


1
Project Planning
  • CS169
  • Lecture 6

2
Opinions on Planning
  • There is a lot of pseudo-science in planning
  • More so even than in other SE subfields
  • Will cover standard metrics
  • And critique them
  • Given some thoughts culled from
  • Professionals
  • Personal experience

3
Motivation
  • Why do we plan?
  • Hard to achieve objectives in a timely manner
    otherwise
  • Imagine building a skyscraper or a bridge without
    a time/resource plan

4
Motivation (Cont.)
  • Planning continues during later phases. Why?
  • Initial plan (after specs) is not accurate enough
  • Accuracy of estimation increases as process
    proceeds

5
Estimating Duration Cost
  • Accurate duration estimation critical
  • credibility, penalty clauses
  • Accurate cost estimation critical
  • difference between making a profit or a loss
  • internal costs vs. external costs (cost to
    client)
  • But, hard to estimate accurately

6
Example Denver Airport
  • Opening delayed entirely by software bugs in
    baggage handling system
  • After 9 month delay, admitted they did not know
    when the airport would open
  • Delay cost 1.1M/day
  • Initial development of baggage system 193M

7
Example Air Traffic Control System
  • FAA contracted with IBM
  • IBM blamed for poor management
  • FAA blamed for altering requirements
  • Four part project
  • Two parts cancelled after 144M spent
  • Unreliable and over budget
  • Fourth part 1B over budget and 5 years late
  • And still not completed

8
IBM Survey of Distributed Systems
  • 55 of projects over budget
  • 68 over schedule
  • 88 had to be redesigned
  • Note Distributed systems are harder than many
    other systems to build

9
Back To Reality
  • Its hard, but we cant ignore it
  • We still need to make plans . . .

10
Metrics for Size of Product
  • Use size of product as basis for time/cost
  • Typical metric is KLOC
  • Thousands of Lines of Code

11
Problems with Code Size
  • Source code only part of effort
  • Sensitive to programming language
  • How do we count lines of code?
  • executable lines? data declarations? comments?
    reused/changed code? inherited code?
  • Estimate time/duration using KLOC estimate!

12
Modern Metrics
  • Newer metrics try to gauge software size
    without referring to the code
  • Use specification
  • Size/complexity of interfaces, inputs, outputs

13
Function Points
  • Formula based on
  • number of inputs
  • outputs
  • inquiries
  • files
  • interfaces
  • Weights determined by regression

14
Function Points in 3 Easy Steps
  • Unadjusted Function Points
  • Classify each component
  • Simple, average, complex
  • Assign unadjusted FPs to each
  • UFP sum of numbers
  • Technical Complexity Factor
  • 14 factors
  • Each 0 (none) to 5 (strong)
  • Transaction rates, portability
  • TCF 0.65 0.1 (sum of 14)
  • 3. Compute function points
  • FP UFP x TCF

15
Function Points
  • Translate FPs into person-months of labor
  • Derived by regression
  • How well does this work?
  • Usually better than KLOC, but still not accurate
  • Errors in excess of 800 counting KDSI, but only
    200 in counting function points (Jones, 1987)

16
Other Metrics
  • Many variations on FP approach
  • Identify important, quantifiable variables
  • Use historical data to fit a formula
  • Some claim close fit with practice

17
Opinion
  • All FP-like metrics are weak
  • Models have (too) many variables
  • Easy to fit old data
  • Chosen variables have some bearing on size of
    task
  • So some fit is not surprising
  • But
  • Not clear all important variables are modeled
  • What is important changes

18
Talent
  • What about programmer productivity?
  • Productivity differences of 10-1 to 100-1
  • Some programmers simply much better than others
  • These differences can swamp all others
  • Especially in small teams

19
Recommendations for Planning
20
One Approach
  • Recommend one approach
  • Because I believe it is reasonably realistic
  • And widely practiced

21
Planning in Four Easy Parts
  • Break project into tasks
  • Requires a good design with good interfaces
  • Allows tasks to be correctly enumerated
  • Allows places for parallel development to be
    identified
  • Again, interfaces have to be right or unexpected
    dependencies will be discovered later!
  • Realism in estimating task length
  • Observable completion
  • Tasks are clearly done or not done
  • Prioritization

22
Plan from Design
  • Start with the design
  • Break project into tasks
  • Indivisible units of work for one person
  • Rules of thumb
  • Nothing less than a day is a task
  • Anything more than a week is at least two tasks
  • Longer tasks harder to estimate
  • Need to think about how to break it into logical
    pieces

23
Dependency Graph
  • Write down dependencies for each task
  • What tasks already must have been done?
  • Build a dependency graph
  • Nodes are tasks
  • Edge (A,B) if A must be completed before B

24
Example Graph
E
Done
D
A
I
F
C
B
H
G
25
Estimating Time
  • Assign tasks to people
  • Individuals estimate time for their own tasks
  • They know their own abilities best
  • Genuine commitment to their own promises

26
Example Graph
2 days
E
4 days
Done
D
3 days
1 day
4 days
A
I
F
2 days
1 day
C
2 days
3 days
5 days
B
5 days
H
G
2 days
27
Notes
  • Durations go on the edges, not the nodes
  • Some dependencies may be satisfied before a task
    is complete
  • Dummy Done node
  • Shows when everything is completed
  • Graph is useful for analysis
  • E.g., what is the critical path?

28
Critical Path
2 days
E
4 days
Done
D
3 days
1 day
4 days
A
I
F
2 days
1 day
C
2 days
3 days
5 days
B
5 days
H
G
2 days
19 days
29
Resources
  • Each task requires resources
  • Particular people
  • Money
  • Perhaps special hardware, etc.
  • Make sure these will be available
  • E.g., one person isnt expected to be doing two
    tasks at the same point in the schedule

30
Fudge Factor
  • Scale estimated time by a fudge factor
  • Allows for the inevitable unexpected problems
  • I take the time estimated to complete all the
    tasks and double it.
  • - Silicon Valley VPE

31
Measuring Progress
  • Checking off tasks gives illusion of progress
  • Real progress only if task completion is
    observable
  • Bad
  • Task 1 10 of feature, task 2 20 of feature
  • What does 10 mean?!
  • Good
  • Task 1 All menus implemented and respond
    correctly to mouse clicks.

32
Measuring Progress A Key Principle
  • Move from working system to working system

33
Make the Plan a Sequence of Builds
  • Get the first build up as soon as possible
  • After that, always maintain a working system
  • System grows as tasks are checked off
  • Move from build to build

34
Why?
  • Can observe true progress
  • If nothing runs, hard to know if we are close to
    running
  • Makes changes in plan easier
  • Each build provides a natural point for changes
  • Allows priorities
  • Put most critical features in first build
  • If schedule slips, just dont get to
    lower-priority builds late in the schedule

35
Builds
Build 3
Build 1
Build 2
2 days
E
4 days
Done
D
3 days
1 day
4 days
A
I
F
2 days
1 day
C
2 days
3 days
5 days
B
5 days
H
G
2 days
19 days
36
Summary
  • Tasks are unit of work
  • But tasks need to make sense
  • Realistic duration, know when they are done
  • Group tasks into builds
  • Guarantees we arent completing lots of tasks
    without checking that everything works together!
  • Another form of false progress
Write a Comment
User Comments (0)
About PowerShow.com