Prof. Aiken CS 169 Lecture 61 Project Planning CS169 Lecture 6

Prof. Aiken CS 169 Lecture 62 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 63 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 64 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 65 Back To Reality It’s hard, but we can’t ignore it We still need to make plans...

Prof. Aiken CS 169 Lecture 66 Talent What about programmer productivity? Productivity differences of 10-1 to –Some programmers simply much better than others These differences can swamp all others –Especially in small teams

Prof. Aiken CS 169 Lecture 67 Recommendations for Planning

Prof. Aiken CS 169 Lecture 68 One Approach Recommend one approach –Because I believe it is reasonably realistic –And widely practiced

Prof. Aiken CS 169 Lecture 69 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 610 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 611 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 612 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 613 Example Graph A B C D G F E H I Done

Prof. Aiken CS 169 Lecture 614 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 615 Example Graph A B C D G F E H I 3 days 1 day 5 days 2 days 3 days 2 days 4 days Done 2 days 1 day

Prof. Aiken CS 169 Lecture 616 Example PERT chart for a DAJ project start cd V1 s1 AM1 AM2 AS2 AS3 UC1 s2 V3 Done AS1 UCE1 V2

Prof. Aiken CS 169 Lecture 617 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 618 Critical Path A B C D G F E H I 3 days 1 day 5 days 2 days 3 days 2 days 4 days Done 2 days 1 day 19 days

Prof. Aiken CS 169 Lecture 619 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 620 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 621 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 622 Measuring Progress: A Key Principle Move from working system to working system

Prof. Aiken CS 169 Lecture 623 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 624 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 625 Builds A B C D G F E H I 3 days 1 day 5 days 2 days 3 days 2 days 4 days Done 2 days 1 day 19 days Build 1 Build 2 Build 3

Prof. Aiken CS 169 Lecture 626 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