CAPABILITY MATURITY MODEL(CMM)

By: Nazish Nouman

Basic rules in improvements (1)

where you are, “If you don’t know

a map won’t help”

Watts Humprey

Basic rules in improvements (2)

where you are, “You need to know

before you can decide where to go!”

Grosby

Common problems in SW projects

Project having always resource problems

Quality criterias not always met

Not enough competence in all projects

Unexpected surprises in projects

(technical & administrative)

Unstable input documents/products

Improvements not meeting the real work

. . .

Factors leading to the establishment of the SEI (Software Engineering institute) and later on creation of

CMM: Increasing cost of SW Quality problems in SW products Cost of SW maintenance Government put billions of dollars in SW acquisition Increasing rate of change in technology and SW

environment Typical SW project was a year late and exceeded two times

the budget

Increasing SW complexity

SW crisis

CMM was developed and is promoted by the Software Engineering Institute (SEI), a research and development center

The Software Engineering Institute (SEI) at Carnegie Mellon University has created the Capability Maturity Model (CMM) which systematically defines and refines software development efforts

In 1991, SEI released the Capability Maturity Model for Software version 1.0.

In 2001, SEI released the Capability Maturity Model – Integrated(CMMI), superseding the CMM for software.

6 of 31

CMM

The CMM for Software (SW-CMM) is a framework that described the key elements of an effective software process.

The CMM guides software organizations striving to gain control of their processes for developing and maintaining software, evolve toward a software engineering culture, and management excellence.

The CMM describes an evolutionary improvement path for software organizations from an ad hoc, immature process to a mature, disciplined one.

What is the CMM?

The Capability Maturity Model (CMM) is a methodology used to develop and refine an organization's software development process.

Strategy for improving the software process

Describes principles and practices

Helps organizations to create useful software

efficiently and consistently

The model describes a five-level evolutionary path of increasingly organized and systematically more mature processes.

What is CMM??

Organized as a set of maturity levels.

Provides organizations with guidance on how to gain control of their processes.

how to evolve toward a culture of software engineering and management excellence.

well-defined incremental stages toward the goal of software process maturity.

Focuses on the development of effective software processes.

9 of 31

Why CMM?

The difference between immature and mature software development

organizations is the existence and maturity of their software processes.

10 of 31

Mature vs immature software organization

Immature ◦ No objective basis for judging product quality◦ Activities that enhance qualities are curtailed when the project falls

behind on schedule

Mature◦ Well-planned and communicated process of managing and

maintaining software◦ Mandated processes are documented, usable, updated and consistent◦ Realistic estimates (cost and time) and active involvement by

everyone ◦ managers monitor the quality of the software products and customer

satisfaction in a quantitative manner, and have continuous refinement built into the process.

Immature vs. Mature Software Organizations

Levels 1 through 5 of the SW-CMM define a path toward

organizational improvement. The practices are 'graduated'

in the sense that the levels build on one another.

Bearing in mind that change cannot occur overnight, the

CMM induces change incrementally.

Five different levels are of maturity are defined and an

organization then advances slowly in a series of small,

evolutionary steps toward the higher levels of process

maturity12 of 31

Maturity Levels

1. Initial ------------ Ad hoc Process

2. Repeatable------ Basic Project management

3. Defined----------- Process definition

4. Managed===== Process Measurement

5. Optimizing==== Process Control

13 of 31

5-Levels of CMM

Maturity steps

Level 4:Managed

Level 4:Managed

Level 5:Optimising

Level 5:Optimising

Level 3:Defined

Level 3:Defined

Level2:Repeatable

Level2:Repeatable

Level 1:Initial

Level 1:Initial

Processdiscipline

ProcessdefinitionStandard, consistent process

Process control

Continuousprocessimprovement

Projectmanagement

Engineeringmanagement

Quantitativemanagement

Change management

CMM structure Level Key Process Areas Focus

5Optimizing

4Managed

3Defined

2Repeatable

1Initial

Defect PreventionTechnology InnovationProcess Change Management

Quantitative Process ManagementSW Quality Management

Organisation Process FocusOrganisation Process DefinitionPeer ReviewsTraining ProgramIntergroup CoordinationSW Product EngineeringIntegrated SW Management

SW Project PlanningSW Project TrackingSW Subcontract ManagementSW Quality AssuranceSW Configuration ManagementRequirements Management

Continuous processimprovement

Product and processquality managed by facts

Standardised SWengineering process

Disciplined project management

The commitment process

Heroes

(Version 1.1)

At the initial level, processes are disorganized, even chaotic. Success is likely to depend on individual efforts, and is not considered to be repeatable, because processes would not be sufficiently defined and documented to allow them to be replicated.

No formal procedures No cost estimates No project plans No key processes Weak management practices Poorly controlled commitments processes are ad hoc practices are sacrificed for schedule Practitioners resist discipline Results are unpredictable

16 of 31

Level 1: Initial –

Good performance is possible – but

Requirements often misunderstood, uncontrolled

No change control Teams not coordinated, not trained Defects proliferate(grow)

Software installation and maintenance often

present serious problems No design and code reviews No test data analysis

17 of 31

Level 1: the “Initial” Level Success depends on heroes

At the repeatable level, basic project management techniques are established, and successes could be repeated, because the requisite processes would have been made established, defined, and documented.

Project management structures and controls begin here. Basic project management processes are established to track cost,

schedule, and functionality. Project management is strong and lays foundation for

process discipline

Project activities are planned and followed

Project ensures that practices are performed

Corrective actions are made when necessary

Project “own” its commitments

Commitments are clear and communicated

Necessary baselines are build and controlled

Level 2: Repeatable

What Happens During Level 2 Processes become easier to digest and

understand Managers and team members spend less time

explaining how things are done and more time doing

Projects are better estimated, better planned, and more flexible

Quality is integrated into the project Costs may go up initially, but do go down over

time And yes, there may be more documentation and

paper

Requirements Management

Software Project Planning

Software Project Tracking and Oversight

Software Quality Assurance

Software Configuration Management

21 of 31

The key components of project management at level -2 are:

At the defined level, an organization has

developed its own standard software

process through greater attention to

documentation, standardization, and

integration.

22 of 31

Level 3: Defined

The software process for both management and engineering activities is documented, standardized, and integrated into a standard software process for the organization.

Activities include peer reviews, product engineering, CASE tool usage,

testing standards, and full lifecycle configuration management.

Software methodology is customized for each specific project

Training program is implemented

All projects use an approved, tailored version of the organization's

standard software process for developing and maintaining software. Training plans are created and followed

(project and organisation levels) More systematic technical coordination between different project

groups

23

Level 3: Defined

What Happens During Level 3 Process Improvement becomes the

standard – Cross-Functional teams look for ways to “short-cut” the system

Solutions go from being “coded” to being “engineered”

Quality gates appear throughout the project effort with the entire team involved in the process, reducing rework

Risks are managed and don’t take the team by surprise

The key process areas at level 3 address both project and organizational issues. The expected activities are:

Organization Process Definition Training Program Intergroup Coordination Peer Reviews

25

key process areas at level 3

At the managed level, an organization monitors and controls its own processes through data collection and analysis.

Detailed time, cost, defect rates and other metrics are collected and used to quantitatively manage software development throughout the software process of every project. The organization has a quality focus, with tools and training to support development.

26

Level 4: Managed

Processes and products are on statistical control

The process information is stored in a central repository

Quantitative limits are established for process performance

Process performance is managed (I.e. quantitatively

controlled)

Organizations predict software development efforts and quality

Data is actively used as a base in decision making

Detect and correct variations from the expected performance.

This level sets the foundations of a truly quality oriented

organization.

Level 4: Managed

At the optimizing level, processes are constantly being improved through

monitoring feedback from current processes and introducing innovative

processes to better serve the organization's particular needs.

Continuous process improvement in place through quantitative management

At this level the entire organization is structured around a quality focus.

Processes and technology are continuously evaluated

Processes such as software inspection, code walkthroughs, automatic metrics

collection, and technology review are part of the standard development

methodology.

Individuals are empowered to improve their processes

The causes of defects are eliminated as part of preventive quality work

New technologies can be utilized effectively to improve process capability

The knowledge gained from each from each project is utilized in future projects.

The process incorporates a positive feedback loop, resulting in a steady

improvement in productivity and quality.

Level 5: Optimizing

CMMINew version of CMM

CMMI is the successor of the Capability

Maturity Model (CMM) or Software CMM.

The CMM was developed from 1987 until

1997. In 2002, CMMI Version 1.1 was

released.