Project Planning

Prof. Aiken CS 169 Lecture 6 1

Project Planning

CS169Lecture 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?

• Hard to achieve objectives in a timely manner otherwise

• Imagine building a skyscraper or a bridge without a time/resource plan


Motivation (Cont.)

• Planning continues during later phases. Why?

• Initial plan (after specs) is not accurate enough

• Accuracy of estimation increases as process proceeds


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


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


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


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


Back To Reality

• It’s hard, but we can’t ignore it

• We still need to make plans . . .


Metrics for Size of Product

• Use size of product as basis for time/cost

• Typical metric is KLOC– Thousands of Lines of Code


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!


Modern Metrics

• Newer metrics try to gauge software “size” without referring to the code

• Use specification– Size/complexity of interfaces, inputs, outputs


Function Points

• Formula based on– number of inputs– outputs– inquiries – files– interfaces

• Weights determined by regression


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 = 0.65 + 0.1 * (sum of 14)

3. Compute function points FP = UFP x TCF

Component Simple Average Complex

Input 3 4 6

Output 4 5 7

Inquiry 3 4 6

File 7 10 15

Interface 5 7 10


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)


Other Metrics

• Many variations on FP approach– Identify important, quantifiable variables– Use historical data to fit a formula

• Some claim close fit with practice


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


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


Recommendations for Planning


One Approach

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


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


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


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


Example Graph

A

B

C

D

G

F

E

H

I

Done


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


Example Graph

A

B

C

D

G

F

E

H

I

3 days

1 day

5 days5 days

2 days

3 days

2 days

2 days

4 days

4 days

Done2 days

1 day


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?


Critical Path

A

B

C

D

G

F

E

H

I

3 days

1 day

5 days5 days

2 days

3 days

2 days

2 days

4 days

4 days

Done2 days

1 day

19 days


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


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


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.


Measuring Progress: A Key Principle

Move from working system to working system


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


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


Builds

A

B

C

D

G

F

E

H

I

3 days

1 day

5 days5 days

2 days

3 days

2 days

2 days

4 days

4 days

Done2 days

1 day

19 days

Build 1 Build 2 Build 3


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

Project Planning

Documents

Transcript of Project Planning