CSC444F'05Lecture 31 Release Planning Methodology Overview

CSC444F'05 Lecture 3 1

Release Planning Methodology Overview


Release Planning Framework

• Provide a software release planning framework– that balances

• business concerns• software development concerns

– provides better predictability of• end-date• delivered debugged feature set

– provides early notification of slips– allows for re-planning as events unfold– deals explicitly with uncertainty


The Product Lifecycle


Follow on Lifecycles

R1.0 R1.1 R1.2 R2.0

Continuous requirements gather

Initial release Follow-on releases

R1.0.1

R1.0.2

R1.0.3 R1.0.1a

point releases


Eliciting Potential Requirements

Potential Requirements

?

Next Release

• Starts with a wish list• Stated as business requirements

– Features or architectural enhancements


Sizing Potential Requirements

30 36 43

• Cost / Benefit analysis– Cost: financial + opportunity = person days

• Sizing in ECDs– Inherent size of the work item

– Who will work on it

– The productivity of that person on that work item

• Ensure units are well-understood (more later)


Sizing the Available Resources

• Who can work on the next release?– Must have skills and familiarity to contribute

• For how long?– Must count workdays in the coding phase

– Each resource available all that time?

– Subtract estimated vacation

• How dedicated to the next release– Work factor = w

– Converts 8-hour (nominal, arbitrary) days to time available to code and unit test during the coding phase

– E.g. w=0.6 means can dedicate 0.6x8 = 4.8 hours/workday

– Accounts for• Other tasks, sickdays, meetings, weekends, ...

– Range is 0 .. 9, usually 0.6 or so


The Capacity Constraint

• After all is done in a release

Actual Resource Used == Sum of Actual Times for Features

• This is always true. It is a constraint.

• In planning, knowing that this must work out at the end, can estimate both sides and force the estimates to be equal

Resource Estimate == Sum of Feature Estimates


A Geometric Analogy - Capacity

1 person-day

days

persons


A Geometric Analogy - Requirement

30 36 43


A Geometric Analogy - Capacity Constraint

days

p e r s o n s


A Simple Release Plan

Dates: Coding phase: Jul.1—Oct.1Beta availability: Nov.1General availability: Dec.1

Capacity: days availableFred 31 ecdLorna 33 ecd… …Bill 21 ecdtotal 317 ecd

Requirement: days requiredAR report 14 ecdDialog re-design 22 ecd… …Thread support 87 ecdtotal 317 ecd

Status: Capacity: 317 effective coder-daysRequirement: 317 effective coder-daysDelta: 0 effective coder days


Non-Coding Time and Resource• In RP, we explicitly plan coding only.

– Other• types of resources:

– Testers, documenters, managers

• phases:– Specification, testing

– These are sized relative to the coding phase and the coding resource

• Why?– Debugged code is the ultimate target

• Can’t be 90% done on that and still ship intended feature set

– How much time to devote to documentation?– How much time to devote to testing?– When is enough, enough?

• How?– Establish ratios– Measure what works for ratios for a given product– Adjust next time around– Converges rapidly– Initial guess is usually pretty good


Resource Ratios

1 CODERS

1:3 TESTERS

1:4 DOCS

• Typical ratios I have used• Adjust to taste• Assumes availability throughout the (overlapping)

release cycle.


Phase Length Ratios

• Typical ratios I have used

• Adjust to taste

specification & design

alpha test

code & unit test

beta test

3 2 2 1


Release Overlap

• Overlapping release cycles smoothes resource utilization


alpha test

code & unit test

beta test


code & unit test

R1.2

R1.3 requirements gather

maintenance


Shipping The Release

• After dcut, proactive management is gone.

• Can only watch defect arrivals and hope for the best.– If your ratios are off: forgetaboutit,

alpha test

beta test

GA release

first point release second

point release

third point release

defect arrival rate

shipping threshold

Documents

CSC444F'05Lecture 31 Release Planning Methodology Overview