project planning
DESCRIPTION
Project Planning. CS169 Lecture 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. - PowerPoint PPT PresentationTRANSCRIPT
Prof. Aiken CS 169 Lecture 6 1
Project Planning
CS169Lecture 6
Prof. Aiken CS 169 Lecture 6 2
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
Prof. Aiken CS 169 Lecture 6 3
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
Prof. Aiken CS 169 Lecture 6 4
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
Prof. Aiken CS 169 Lecture 6 5
Back To Reality
• It’s hard, but we can’t ignore it
• We still need to make plans . . .
Prof. Aiken CS 169 Lecture 6 6
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
Prof. Aiken CS 169 Lecture 6 7
Recommendations for Planning
Prof. Aiken CS 169 Lecture 6 8
One Approach
• Recommend one approach– Because I believe it is reasonably realistic– And widely practiced
Prof. Aiken CS 169 Lecture 6 9
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
Prof. Aiken CS 169 Lecture 6 10
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
Prof. Aiken CS 169 Lecture 6 11
Dependency Graph
• Write down dependencies for each task– What tasks already must have been done?
• Build a dependency graph– Nodes are tasks: This is not right, see next
viewgraph– Edge (A,B) if A must be completed before B
Prof. Aiken CS 169 Lecture 6 12
PERT chart (Program Evaluation and Review Technique)
• Nodes: Milestones = Events• Edges: Tasks = Activities = Jobs• Edge weight: Task duration• If edge (u,v) enters vertex v and edge (v,x)
leaves v, then task (u,v) must be performed prior to task (v,x).
Prof. Aiken CS 169 Lecture 6 13
Example Graph
A
B
C
D
G
F
E
H
I
Done
Prof. Aiken CS 169 Lecture 6 14
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
Prof. Aiken CS 169 Lecture 6 15
Example Graph
A
B
C
D
G
F
E
H
I
3 days
1 day
5 days5 days
2 days
3 days
2 days
2 days
4 days
4 days
Done2 days
1 day
Prof. Aiken CS 169 Lecture 6 16
Example PERT chart for a DAJ project
start
10
30
20
40
60
50
70
80
cd
V1
s1AM1
AM2
AS2
AS3
UC1
s2
V3
DoneAS1
UCE1V2
Prof. Aiken CS 169 Lecture 6 17
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?
Prof. Aiken CS 169 Lecture 6 18
Critical Path
A
B
C
D
G
F
E
H
I
3 days
1 day
5 days5 days
2 days
3 days
2 days
2 days
4 days
4 days
Done2 days
1 day
19 days
Prof. Aiken CS 169 Lecture 6 19
Resources
• Each task requires resources– Particular people– Money – Perhaps special hardware, etc.
• Make sure these will be available– E.g., one person isn’t expected to be doing two
tasks at the same point in the schedule
Prof. Aiken CS 169 Lecture 6 20
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
Prof. Aiken CS 169 Lecture 6 21
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.
Prof. Aiken CS 169 Lecture 6 22
Measuring Progress: A Key Principle
Move from working system to working system
Prof. Aiken CS 169 Lecture 6 23
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
Prof. Aiken CS 169 Lecture 6 24
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 don’t get to lower-priority builds
late in the schedule
Prof. Aiken CS 169 Lecture 6 25
Builds
A
B
C
D
G
F
E
H
I
3 days
1 day
5 days5 days
2 days
3 days
2 days
2 days
4 days
4 days
Done2 days
1 day
19 days
Build 1 Build 2 Build 3
Prof. Aiken CS 169 Lecture 6 26
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 aren’t completing lots of tasks
without checking that everything works together!
• Another form of false progress