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

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

Prof. Aiken CS 169 Lecture 610 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 611 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 612 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 613 Function Points Formula based on –number of inputs –outputs –inquiries –files –interfaces Weights determined by regression

Prof. Aiken CS 169 Lecture 614 Function Points in 3 Easy Steps 1.Unadjusted Function Points –Classify each component Simple, average, complex –Assign unadjusted FPs to each –UFP = sum of numbers 2. Technical Complexity Factor –14 factors –Each 0 (none) to 5 (strong) Transaction rates, portability –TCF = * (sum of 14) 3. Compute function points FP = UFP x TCF ComponentSimpleAverageComplex Input346 Output457 Inquiry346 File71015 Interface5710

Prof. Aiken CS 169 Lecture 615 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 616 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 617 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 618 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 619 Recommendations for Planning

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

Prof. Aiken CS 169 Lecture 621 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 622 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 623 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 624 Example Graph A B C D G F E H I Done

Prof. Aiken CS 169 Lecture 625 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 626 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 627 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 628 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 629 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 630 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 631 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 632 Measuring Progress: A Key Principle Move from working system to working system

Prof. Aiken CS 169 Lecture 633 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 634 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 635 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 636 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