Project Planning

1. Project Planning CS169 Lecture 6 Prof. Aiken CS 169 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 Prof. Aiken CS 169 Lecture 6

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

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

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

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

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

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

9. Back To Reality • It’s hard, but we can’t ignore it • We still need to make plans . . . Prof. Aiken CS 169 Lecture 6

10. Metrics for Size of Product • Use size of product as basis for time/cost • Typical metric is KLOC • Thousands of Lines of Code Prof. Aiken CS 169 Lecture 6

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

12. Modern Metrics • Newer metrics try to gauge software “size” without referring to the code • Use specification • Size/complexity of interfaces, inputs, outputs Prof. Aiken CS 169 Lecture 6

13. Function Points • Formula based on • number of inputs • outputs • inquiries • files • interfaces • Weights determined by regression Prof. Aiken CS 169 Lecture 6

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

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

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

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

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

19. Recommendations for Planning Prof. Aiken CS 169 Lecture 6

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

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

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

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

24. Example Graph E Done D A I F C B H G Prof. Aiken CS 169 Lecture 6

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

26. 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

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

28. 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

29. 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

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

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

32. Measuring Progress: A Key Principle Move from working system to working system Prof. Aiken CS 169 Lecture 6

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

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 don’t get to lower-priority builds late in the schedule Prof. Aiken CS 169 Lecture 6

35. 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

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 aren’t completing lots of tasks without checking that everything works together! • Another form of false progress Prof. Aiken CS 169 Lecture 6