360 likes | 469 Vues
Project Planning. CS169 Lecture 6. 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. Motivation. Why do we plan?
E N D
Project Planning CS169 Lecture 6 Prof. Aiken CS 169 Lecture 6
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
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
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
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
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 • 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 • 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 • It’s hard, but we can’t ignore it • We still need to make plans . . . Prof. Aiken CS 169 Lecture 6
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
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
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
Function Points • Formula based on • number of inputs • outputs • inquiries • files • interfaces • Weights determined by regression Prof. Aiken CS 169 Lecture 6
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
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
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
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
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 Prof. Aiken CS 169 Lecture 6
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 • 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 • 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 • 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
Example Graph E Done D A I F C B H G Prof. Aiken CS 169 Lecture 6
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 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
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 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 • 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 • 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 • 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 Move from working system to working system Prof. Aiken CS 169 Lecture 6
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
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 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 • 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