CSC444 Software Engineering

1. CSC444Software Engineering Lecture 3: Release Planning Methodology Overview Prof. David A. Penny Lectures run 7:10 pm to 9:00 pm or thereabouts 10 minute break at 8:00 pm, Resume at 8:10 pm Please purchase a book for $40. Course Website: http://ccnet.utoronto.ca/20069/csc444h1f Lecture 3

2. Release Planning Framework • Provide a software release planning framework • that balances • business concerns • software development concerns • provides better predictability of • end-date • Delivered defect-minimized feature set • provides early notification of slips • allows for re-planning as events unfold • deals explicitly with uncertainty Lecture 3

3. The Product Lifecycle Lecture 3

4. Follow on Lifecycles Lecture 3

5. ? Next Release Potential Requirements Eliciting Potential Requirements • Starts with a wish list • Stated as business requirements • Features or architectural enhancements Lecture 3

6. Sizing Potential Requirements • 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) Lecture 3

7. 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 Lecture 3

8. 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 Lecture 3

9. p e r s o n s days 1 person-day A Geometric Analogy - Capacity Lecture 3

10. A Geometric Analogy - Requirement Lecture 3

11. A Geometric Analogy - Capacity Constraint Lecture 3

12. A Simple Release Plan Dates: Coding phase: Jul.1—Oct.1 Beta availability: Nov.1 General availability: Dec.1 Capacity: days available Fred 31 ecd Lorna 33 ecd … … Bill21 ecd total317 ecd Requirement: days required AR report 14 ecd Dialog re-design 22 ecd … … Thread support87 ecd total317 ecd Status: Capacity: 317 effective coder-days Requirement: 317 effective coder-days Delta: 0 effective coder days Lecture 3

13. 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 Lecture 3

14. Resource Ratios • Typical ratios I have used • Adjust to taste • Assumes availability throughout the (overlapping) release cycle. Lecture 3

15. Phase Length Ratios • Typical ratios I have used • Adjust to taste Lecture 3

16. Release Overlap • Overlapping release cycles smoothes resource utilization Lecture 3

17. 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, Lecture 3