project planning
Download
Skip this Video
Download Presentation
Project Planning

Loading in 2 Seconds...

play fullscreen
1 / 26

Project Planning - PowerPoint PPT Presentation


  • 237 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Project Planning' - beau-malone


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
project planning

Project Planning

CS169

Lecture 6

Prof. Aiken CS 169 Lecture 6

example denver airport
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

example air traffic control system
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

ibm survey of distributed systems
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

back to reality
Back To Reality
  • It’s hard, but we can’t ignore it
  • We still need to make plans . . .

Prof. Aiken CS 169 Lecture 6

talent
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

recommendations for planning

Recommendations for Planning

Prof. Aiken CS 169 Lecture 6

one approach
One Approach
  • Recommend one approach
    • Because I believe it is reasonably realistic
    • And widely practiced

Prof. Aiken CS 169 Lecture 6

planning in four easy parts
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

plan from design
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

dependency graph
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

pert chart program evaluation and review technique
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

example graph
Example Graph

E

Done

D

A

I

F

C

B

H

G

Prof. Aiken CS 169 Lecture 6

estimating time
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

example graph1
Example Graph

2 days

E

4 days

Done

3 days

D

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

Prof. Aiken CS 169 Lecture 6

example pert chart for a daj project
Example PERT chart for a DAJ project

AS1

s2

50

Done

cd

20

UCE1

V3

start

V2

80

60

AS3

V1

30

UC1

AS2

AM1

10

s1

70

40

AM2

Prof. Aiken CS 169 Lecture 6

notes
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

critical path
Critical Path

2 days

E

4 days

Done

3 days

D

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

Prof. Aiken CS 169 Lecture 6

resources
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

fudge factor
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

measuring progress
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

measuring progress a key principle
Measuring Progress: A Key Principle

Move from working system to working system

Prof. Aiken CS 169 Lecture 6

make the plan a sequence of builds
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

slide24
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

builds
Builds

Build 3

Build 1

Build 2

2 days

E

4 days

Done

3 days

D

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

Prof. Aiken CS 169 Lecture 6

summary
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

Prof. Aiken CS 169 Lecture 6

ad