Introduction to

Software Capability Maturity Model


Chuck Connell



w   Why CMM matters

w   Historical background

w   Sports analogy

w   What is CMM ?

w   How you can use CMM

w   Details about CMM

w   Problems with CMM


Threads from this course

w   Iteration in design process

w   Choice of process for development

w   Is software different from other (physical) engineering fields?


Why CMM matters…

w   It is the most widespread and detailed software development model

w   It is a standard for much DoD work, which is a lot of software projects

w   It is being used by many non-DoD businesses

w   It is widely criticized, and has inspired several anti-CMM models

w   Your tax dollars paid for it



w   Begun in 1986 by DoD to help improve government software contractors.

w   Work started at Mitre, then at Software Engineering Institute (SEI) at Carnegie Mellon Univ.

w   Watts Humphrey was initial author, then Mark Paulk, Bill Curtis, and others.

w   Borrows heavily from general Total Quality Management (TQM) and work of Philip Crosby.

w   Under active development for 15+ years, ongoing…

w   Has gained significant interest among non-DoD software vendors.

w   All documents are public, and many are free.

w   Known as SW-CMM or CMM.


SW development and baseball

w   What happens when a ball is hit to a Little League team?

n    Everyone runs around at random.

n    They might do the right thing, or they might not.

n    The next time the ball is hit in the same place, they may do something different.

w   What happens when a ball is hit to a professional team?

n    Everyone moves in a coordinated fashion, based on practicing that play many times.

n    Sometimes they fail to make the right play, but they almost always try to do the right thing.

w   What happens when the team loses a star player?

n    Little League team gets much worse.

n    Professional team often has someone waiting to fill in.  

w   Self-improvement after a bad play…

n    Little League players don’t know what went wrong, or they blame each other.

n    Professional teams discuss their play and look for ways to improve. "The next time there is an infield hit with 2 outs, let’s do this instead."

w   A professional baseball team is more "mature" than a Little League team (not referring to age).

w   A professional team has self-perpetuating quality. They

n    Make good plays

n    Develop new players like themselves

n    Find ways to make better plays


What is CMM?

w   In the same way, high-quality SW organizations are different from low-quality orgs.

w   CMM tries to capture and describe these differences.

w   CMM strives to create software development organizations that are “mature”, or more mature than before applying CMM.

w   Describes five levels of SW process maturity.

w   Includes lots of detail about each level – we will look at some of it.


How to use CMM

w   Hire an officially certified CMM Assessor to conduct a formal evaluation.

n    To win government software contracts.

n    To find high-quality software subcontractors. (SA-CMM)

n    For pure development shops, to impress clients with your quality. (India)

w   Send your own people to official CMM training, then conduct internal assessments.

n    For a large organization where software process improvements have a big payoff.

w   Use CMM as a set of suggestions and apply as you see fit.

n    Every other software development organization, of all sizes.


Summary of levels

w   Level 1 – Initial. Anything at all. Ad-hoc and chaotic. Will have some successes, but will also have failures and badly missed deadlines.

w   Level 2 – Repeatable. SW processes are defined, documented, practiced, and people are trained in them. Groups across an organization may use different processes.

w   Level 3 – Defined. SW processes are consistent and known across the whole organization.

w   Level 4 – Managed. SW processes and results are measured quantitatively, and processes are evaluated with this data.

w   Level 5 – Optimizing. Continuous process improvement. Experimenting with new methods and technologies. Change processes when find something that works better.


Level 1 – Initial

w    Team tackles projects in different ways each time

w    Can have strong successes, but may not repeat 

w    Some time/cost estimates are accurate, many far off

w    Success comes from smart people doing the right things

w    Hard to recover from good people leaving

w    Frequent crises and "firefighting.” (Many believe this is standard for SW development. CMM says NO.)

w    Most SW development organizations are Level 1.

w    Estimating curve, process diagram.


Level 2 – Repeatable

w   Key areas

n    Requirements management

n    Software project planning

n    Project tracking and oversight

n    Subcontracts management

n    Quality assurance

n    Configuration management

w   Usually takes 18+ months. (Some ask for Level 1.5.)

w   Estimating curve

w   Process diagram


Level 3 – Defined

w   Key areas. Level 2, plus…

n    Organization-wide process focus

n    Organization-wide process definition

n    Training program in above

n    Integrated software management (above applied per project)

n    Software product engineering (coding, etc.)

n    Inter-group coordination

n    Peer reviews

w   Estimating curve

w   Process diagram


Level 4 – Managed

w   Key areas. Level 3, plus…

n    Quantitative process management (data gathering)

n    Quality management (data-driven quality improvement)

w   Estimating curve

w   Process diagram


Level 5 – Optimizing

w   Key areas. Level 4, plus…

n    Defect prevention

n    Technology change management (bring in new methods)

n    Process change management (improve processes)

w   Estimating curve

w   Process diagram


Structure of the Levels

w   Maturity Levels (5)

n    Key Process Areas (2-7)

w  Goals (2-4)

w  Commitment to perform

w  Ability to perform

w  Measurement and analysis

w  Verification

w  Activities performed

n   Key practice #1
n   Key practice #2

w   Main idea: Saying you will do something is not enough.



w   CMM contains a lot of verbiage.

w   Can seem like just a word game, which it might be to some extent.

w   If you get beyond the verbiage however, CMM does describe some important methods for running software projects.


“Maturity suite”

n    Personal Software Process (PSP)

n    Team Software Process (TSP)

n    People CMM (P-CMM)

n    Software Acquisition CMM (SA-CMM)

n    System Engineering CMM (SE-CMM)

n    Integrated Product Development CMM (IPD-CMM)

n    CMM Integration (CMMI): SW + SE + IPD


Problems with CMM

w   It is a goal, not a method

w   Being used just as stamp of approval

w   Doesn’t say anything about software!

w   Doesn’t help in a crisis

w   Only for repetitive tasks


CMM is a goal, not a method

w    Organizations often look to CMM as a method or formula for improvement

n     Tempting to want easy answers.

w    CMM is actually a management framework, with many details left out

n     Example: “You must have peer reviews.” But how should the reviews be run?

w    If you say, "we do CMM just like the book", you aren't doing CMM

w    To use CMM, you have to think

n     You must be flexible, be creative, and integrate the goals of CMM with the realities of your business.

w   Related to this point, some organizations are rigid about mandating CMM to their employees

w   This has given CMM a bad reputation as an onerous, inflexible method

w   The problem here (usually) is misunderstanding CMM, not its rigidity


Becoming stamp of approval

w   Some organizations want CMM only as a stamp of approval, without a high-level commitment to process improvement or quality

w   Want to find easiest way to get certified as Level 2 (or 3) without really changing

w   I talked to the first CMM assessor in the world. She was tired and disillusioned. Why?

n    She wanted companies to say, “Let’s work together to improve our software processes.”

n    Instead, they say, “Just tell us what to do to get Level 2, so we can get back to work."


Not about software!

w   CMM is, by design, a model for managing software projects

n    They claim most software failures are due to management problems rather than technical barriers (I agree)

w   But CMM goes too far in this direction

w   An organization could write lousy code (consistently) and be rated highly by CMM

w   This is counter-intuitive, since good code is the goal of software development


Does not help in a crisis

w   CMM does not help projects that are in crisis right now

n    Trying to apply it then would make things worse

w   Unfortunately, this is often when companies look for help with their software processes

w   Analogy: For long-term cardiac health…

n    Eat lots of fruits and veggies, quit smoking, get exercise, reduce stress

w   But suppose you are having a heart attack now. Will these actions help?

n    It is too late for preventive measures. You need some other kind of intervention.


Only for repetitive tasks

w   CMM is based on re-using past results for future software projects

n    In management activities, quality measurements, development processes

w   But, this only makes sense for relatively repetitive projects

n    Example: MS Word team creating V7 after V1-6

w   To create brand-new software of unknown size, with unknown hurdles, using human creativity, CMM is clearly not the right model.


Official CMM information

w   Software CMM home, summary paper, detailed paper

w   Using CMM in small organizations

w   Software Acquisition CMM home, paper

w   Team Software Process

w   Personal Software Process

w   System Engineering & Product Development CMMs

w   CMM Integration

w   Comparison of CMM to ISO 9001


Other authors about CMM

w     The Essence of the CMM, Judy Bamberger. Computer, 6/97. Worth reading, by one of the authors of CMM.

w     The Immaturity of CMM, James Bach. American Programmer, 9/94. This article, and the next, articulate common complaints about CMM.

w     Enough About Process: What We Need are Heroes, James Bach. IEEE Software, 2/95.

w     Agile software development (anti-CMM):  and

w     A Critical Look at Software Capability
Evaluation, Bollinger and McGowan. IEEE Software, 4/91.

w     Process Assessment Considered Wasteful, Fayad and Laitinen. Communication of the ACM, 11/97.

w     Software Quality and the Capability Maturity Model, Herbsleb et. al. Communication of the ACM, 6/97.