1. CSC444F'05Lecture 21 Lecture will start at 7pm No Tutorial Today

2. CSC444F'05Lecture 22 Planning (Course Web Site: http://ccnet.utoronto.ca/20059/csc444h1f/) Read chapters 1 & 2 from PSP for next week. Read chapters 1-5 from PSD for Oct.3 http://ccnet.utoronto.ca/20059/csc444h1f/

3. CSC444F'05Lecture 23 Lectures I wrote a manuscript for you guys: –Professional Software Development, 2005. –I will be following it closely –Tentative Schedule (first time course - may vary significantly) LectureDateTopicsChapters 1Sep 12Top-10 Practices, Introduction to Planning1,2 2Sep 19Release Planning Overview, Capacity Constraint3,4 3Sep 26Discipline in Programming (practicum intro) 4Oct 3Quantitative Capacity Constraint, Sample RP5,A,C Oct 10Thanksgiving – no lecture 5Oct 17Stochastic Capacity Constraint, Sample SRP6,B,C 6Oct 24Releases, Versions7,8 7Oct 31MIDTERMSource Control, Build, Testing9,10 8Nov 7Defect & Feature Tracking11,12 9Nov 14Spillover / Process Control13 10Nov 21Architectural Clarity14 11Nov 28Business Aspects15,16

4. CSC444F'05Lecture 24 Capability Maturity Model Developed at Carnegie-Melon Software Engineering Institute by Watts Humphrey. Classifies an organization’s process maturity into 5 levels. –Each level is a group of practices. –The CMM is a roadmap for process improvement. –Should have substantially all practices in place for a lower level before proceeding to the next Can be certified to a certain CMM level –Some similarities to Malcolm Baldrige ISO 9000 Not universally agreed to be a good thing –But everyone agrees to pretend

5. CSC444F'05Lecture 25 CMM Levels

6. CSC444F'05Lecture 26

7. CSC444F'05Lecture 27 Relationship to ISO9000 ISO 9000 –Set of quality standards –Subset relate to software development In essence –Must document the process –Must maintain “quality records” These are auditable to ensure the process is being carried out The process can be anything

8. CSC444F'05Lecture 28 Relationship to Top10 Practices necessary to achieve CMM Level 2 (Repeatable). With enough Level 3 (defined) added to attain ISO9000. With some Level 4 (quantitatively managed) sprinkled in where most effective: –Defect arrival / departure rates –Estimates versus actuals –Metrics on process step completion –Defect attribution

9. CSC444F'05Lecture 29 Planning Most important aspect of CMM Level 2 Common flaws: –Make no plans –Make a plan, but don’t track it –Use Microsoft Project

10. CSC444F'05Lecture 210 Why Plan? Not always a good thing –If no expected date –If no other expectations (e.g., expected functionality) –Planning can only slow you down Required when –External pressures come to bear on release dates Usually only happens a bit later in a software company’s business evolution –Not right at the start –Necessary for “crossing the chasm”

11. CSC444F'05Lecture 211 Crossing the Chasm, Geoffrey Moore (1991)

12. CSC444F'05Lecture 212 Gantt Charts Considered Harmful

13. CSC444F'05Lecture 213 Planning Essentials What are we building? By when will it be ready? How many people will it take? Answer these and nothing more: not “who will be doing what?” nor “what are the detailed tasks required?” nor “in what order must the tasks be performed?”

14. CSC444F'05Lecture 214 Implementation Plans Once planning is complete can then transform into a detailed plan –E.g., Microsoft Project Detailed plan should not contradict the release plan Not all of the project needs details beyond –Who do we assign it to –But some parts do These plans may not be necessary –If no great inter-dependencies that can’t be worked out as you go They hinder change as they are so cumbersome to change

15. CSC444F'05Lecture 215 Of Mice and Men The essence of planning is uncertainty –Plans never “go according to plan” –Must embrace change, not close our eyes to it Therefore: –Must track the plan always –Must react quickly to adverse situations –Must embrace changes in direction –Must re-plan quickly

16. CSC444F'05Lecture 216 Internal Changes Estimation errors –Initial estimates contain a significant (one-sided) margin of error. –As plan progresses, variance in estimates lower Developer-power leaving the project –Illness –Parental leave –Resignations –Budget cuts –Unexpected vacation plans –Unexpectedly low work hours –Unexpectedly low productivity

17. CSC444F'05Lecture 217 External Changes New (big) customer desiring new functionality Competitor release a product Collaboration opportunities Acquisitions and mergers Sudden changes in customer needs –E.g., regulatory changes affecting them

18. CSC444F'05Lecture 218 The Difficult Question What are we building? –May be hard for 1 st release –Subsequent releases will have a big wish list –Pick the best looking ones, most demanded ones –Marketing product management decision What will make us the most sales? By when will it be ready? –Too soon: Customers won’t be ready for a new release –Won’t want to install –Won’t want to learn –Won’t want to pay for it –Too late Customers will forget about you Competitors will pass you Foregone revenues How any developers? –Usually fixed for next release Difficult question –Can we do all 3 at once?

19. CSC444F'05Lecture 219 A Common Happening Often organizations will answer all three questions, but not address the difficult one! Development management will want to please their masters, and will tend to agree to too much in a spirit of “gung-ho!” –Some managers firmly believe that over-commitment is the road to productivity. –“It’s a stretch, but we’ll pull it off” Coders will say “it can’t be done” –but “that’s all they ever say”. Massive sate of denial will set in. –Everybody will hope for a miracle Nobody will accept any blame –Development management: we told you it would be a stretch –Coders: we said it could never be done –Marketing: you should have said something earlier –CEO: you all told me it was going fine –Yourdon’s “Death March”.