CSC444 Software Engineering

1. CSC444Software Engineering Lecture 2: Planning 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 2

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

3. CMM Levels Lecture 2

4. Lecture 2

5. 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 Lecture 2

6. 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 Lecture 2

7. Planning • Most important aspect of CMM Level 2 • Common flaws: • Make no plans • Make a plan, but don’t track it • Use Microsoft Project Lecture 2

8. 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” Lecture 2

9. Crossing the Chasm, Geoffrey Moore (1991) Lecture 2

10. Gantt Charts Considered Harmful Lecture 2

11. Planning Essentials • What are we building? • By when will it be ready? • How many people do we have? 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?” Lecture 2

12. 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 Lecture 2

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

14. 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 Lecture 2

15. 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 Lecture 2

16. The Difficult Question • What are we building? • May be hard for 1st 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 many developers? • Usually fixed for next release • Difficult question • Can we do all 3 at once? Lecture 2

17. 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”. Lecture 2