csc444f'05lecture 21 lecture will start at 7pm no tutorial today

CSC444F'05 Lecture 2 1

Lecture will start at 7pm

No Tutorial Today


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/


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)

Lecture Date Topics Chapters

1 Sep 12 Top-10 Practices, Introduction to Planning 1,2

2 Sep 19 Release Planning Overview, Capacity Constraint 3,4

3 Sep 26 Discipline in Programming (practicum intro)

4 Oct 3 Quantitative Capacity Constraint, Sample RP 5,A,C

Oct 10 Thanksgiving – no lecture

5 Oct 17 Stochastic Capacity Constraint, Sample SRP 6,B,C

6 Oct 24 Releases, Versions 7,8

7 Oct 31 MIDTERM Source Control, Build, Testing 9,10

8 Nov 7 Defect & Feature Tracking 11,12

9 Nov 14 Spillover / Process Control 13

10 Nov 21 Architectural Clarity 14

11 Nov 28 Business Aspects 15,16


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


CMM Levels


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


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


Planning

• Most important aspect of CMM Level 2

• Common flaws:– Make no plans

– Make a plan, but don’t track it

– Use Microsoft Project


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”


Crossing the Chasm, Geoffrey Moore (1991)


Gantt Charts Considered Harmful


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


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


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


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


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


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 any developers?– Usually fixed for next release

• Difficult question– Can we do all 3 at once?


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”.

csc444f'05lecture 21 lecture will start at 7pm no tutorial today

Documents