The Capability Maturity Model

in Software Development

CMM, CMMI, level, characteristics, benefits, Pitfall

The Capability Maturity Model
 What is the Capability Maturity Model (CMM)?
 CMMI was developed and is promoted by the Software
ENGINEERING Institute (SEI) a research and development center.
 Its is not a software process model, CMM is used as a bench mark to
measure the maturity of an organization software process
 The model describes a five level evolutionary path of increasingly
organized and systematically more mature processes.
The Capability Maturity Model
 What is the Capability Maturity Model (CMM)?
 The application of process management and quality improvement
concepts to software development and maintenance.
 A guide for evolving toward a culture of engineering excellence.
 A model for organizational improvement.
Capability Maturity Model

 Focuses on practices that are under control of the software

group
 Presents a minimum set of recommended practices that have
been shown to enhance a software development and
maintenance capability
 It defines the expectation (the “what”)
 Without overly constraining the implementation (the “how”)
Why We Chose CMM
 CMM today serves as a “seal of approval” in software development
 CMM helped guide us towards standard, repeatable processes – reduced
learning time on how to get things done
 Standard practices mean time savings to our team - everyone knows what to
expect and what to deliver
 Our quality activities became more aligned within the project rather than
thought of as a separate event
 We rely on our processes and our people together, not just one or the other
 Ideas in CMM creates an environment of improvement – if you don’t like
things one way, make it better!
The Capability Maturity Model- Levels
Level 1 - Initial

 Work is performed informally

A software development organization at this level is
characterized by ad hoc activities (Organization is not planned
in advance)
Level 1: the “Initial” Level

Good performance is possible - but

 Requirements often misunderstood, uncontrolled

 Schedules and budgets frequently missed

 Progress not measured

 Product content not tracked or controlled

 Engineering activities nonstandard, inconsistent

 Teams not coordinated, not trained

 Defects proliferate
Level 2 – Repeatable(Managed)

 Work is planned and Tracked

This level of Software Development Organization has a basic

and consistent project management processes to track cost,
schedule and functionality. The process is in place to repeat the
earlier successes on projects with similar applications.
 CMMI Level 2: “Managed”
7 Process Areas
CLARIFY REQUIREMENTS
Baseline the product requirements  Requirements Management (REQM)
DOCUMENT PLANS
Estimate project parameters, Project Planning (PP)
TRACKDevelop
PROGRESS
plans and processes

Measure actual progress to enable  Project Monitoring

timely corrective action and Control (PMC)
Measure for mgmt. info needs  Measurement & Analysis (M&A)
Verify adherence of processes  Process & Product
CONTROL
and products
PRODUCTS to requirements Quality Assurance (PPQA)

Identify and control products,  Configuration

changes, problem reports Management (CM)
Select qualified suppliers / vendors;  Supplier Agreement
manage their activities Management (SAM)
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
Level 3 – Defined

 Work is well defined

At this level the software process for both management and
engineering activities are defined and documented
CMMI Level 3: “Defined”
11 Process Areas*
ENGINEER THE PRODUCT
 Clarify customer requirements  Requirements Definition
 Solve design requirements; develop (RD)
implementation processes  Technical Solution
 Assemble product components, deliver (TS)
 Ensure products meet requirements
 Ensure products fulfill intended use  Product Integration (PI)
 Analyze decisions systematically  Verification
(Ver)
MANAGE THE PROCESSES  Validation
 Follow integrated, defined processes (Val)
 Identify and control potential problems  Decision Analysis
& Resolution
PROVIDE ORG. INFRASTRUCTURE (DAR)
 Establish org. responsibility for PI
 Define the org’s best practices  Integrated Project Mgmt
 Develop skills and knowledge (IPM)
 Risk Management
(RSKM)

 Org. Process Focus

What Happens During Level 3
 Process Improvement becomes the standard
 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
Level 4 – Managed (Quantitatively)
 Work is Quantitatively Controlled
Software Quality Management: Management can effectively
control the software development effort using the precise
measurements. At this level, organization set a quantitative
quality goal for both software process and software
maintenance
Quantitative Process Management: At this maturity level, the
performance of process is controlled using statistical and other
quantitative techniques and is quantitatively predictable
 CMMI Level 4: “Quantitatively Managed”

2 Process Areas
MANAGE PROJECTS QUANTITATIVELY
 Statistically manage the project’s  Quantitative Project
processes and sub-processes Management
(QPM)
MANAGE THE ORGANIZATION
QUANTITATIVELY
 Understand process performance;  Organizational
quantitatively manage Process Performance
the organization’s projects (OPP)
Level 5 – Optimizing

 Work is based upon continuous Improvement

The key characteristic of this level is focusing on continuously
improving process performance.
Key Feature are:
 Process Change management

 Technology Change Management

 Defect Prevention
 CMMI Level 5: “Optimizing”
2 Process Areas
OPTIMIZE PERFORMANCE
 Identify and eliminate  Causal Analysis
and Resolution
the cause of defects early
(CAR)
ADOPT IMPROVEMENTS
 Identify and deploy new tools and  Organizational Innovation
process improvements to meet needs and Deployment
and business objectives (OID)
Proving Maturity Levels
 Five characteristics must be demonstrated in each practice to be assessed in
that maturity level practice areas:
 Commitment to Perform – Policies, procedures, and resources to perform the work
 Ability to Perform – Personnel, tools, and templates in place
 Activities Performed – Documentation and interviews demonstrating that policies are
implemented
 Measurement and Analysis – Metrics and other tools used to evaluate effectiveness of
processes
 Verifying Implementation – Independent review and evaluation of the processes
 Maturity levels are proven through documentation (policies, procedures,
templates) and interviews of staff (to prove institutionalization).
Stages of Process Maturity Quality
Productivity
Level Focus Process Areas
Continuous Organizational Innovation and Deployment
5 Optimizing Process Causal Analysis and Resolution
Improvement
4 Quantitatively Quantitative Organizational Process Performance
Managed Management Quantitative Project Management

Requirements Development
Technical Solution
Product Integration
Verification
Validation
3 Defined Process Organizational Process Focus
Standardization Organizational Process Definition
Organizational Training
Integrated Project Mgmt (with IPPD extras)
Risk Management
Decision Analysis and Resolution
Integrated Teaming (IPPD only)
Org. Environment for Integration (IPPD only)
Integrated Supplier Management (SS only)
Requirements Management
Basic Project Planning
Project Monitoring and Control
2 Repeatable Project
Supplier Agreement Management
Management Measurement and Analysis Risk
Process and Product Quality Assurance Rework
Configuration Management
1 Initial
The CMM Maturity Levels

Maturity Level 1

Maturity Level 2
~
Maturity Level 3
~ ~ ~
Maturity Level 4
~ ~ ~ ~ ~ ~

Maturity Level 5
~ ~ ~ ~ ~ ~
CMM Process Maturity Profile
of Software Organizations

Maturity Level 1987-91 1997 1999 2001 December

2002
1- Initial 80% 61% 48% 38% 32%
2- Repeatable 12% 23% 30% 34% 37%

3- Defined 7% 14% 16% 20% 21%

4- Managed 0% 2% 4% 5% 5%
5- Optimizing 1% 1% 2% 4% 5%

Organizations 130 795 1179 1641 1998

reporting to SEI

Source: http://www.sei.cmu.edu/sema/profile.html
Pitfalls of Implementation

How Long Does it Take?

Is it Perfect?
Overall Beneficial?
How Long Does it Take?
 Implementing CMM does not occur overnight.
 Typical times for implementation:
 3-6 months of preparation
 6-12 months of implementation
 3 months of assessment preparation
 12 months for each new level
Is it Perfect?

 No! Some implementations do more harm

than good.
 Complete re-vamp of processes to “get
certified” instead of smartly adapting
processes.
 Process focus used more as a stick than as a
carrot.
 Focusing on compliance instead of
improvement.
Overall Benefits

 Defect rates have dropped

 Defect detection occurs earlier
 User requirements are documented, controlled, and managed
 Especially important when users change their minds!
 Estimating improves and becomes more precise
 Risk management is a practice
 Development processes remain agile!
Benefit-Cost Ratio (BCR)
 A benefit-cost ratio (BCR) is a ratio used in a
cost-benefit analysis to summarize the overall
relationship between the relative costs and
benefits of a proposed project.
 BCR can be expressed in monetary or qualitative
terms. If a project has a BCR greater than 1.0,
the project is expected to deliver a positive net
present value to a firm and its investors.

27
Benefit-Cost Analysis..

28
Data Acquisition Methods
 A data acquisition system (DAQ) is an information
system that collects, stores and distributes information.
 There are four methods of acquiring data: collecting new
data; converting/transforming legacy data;
sharing/exchanging data; and purchasing data. This
includes automated collection (e.g., of sensor-derived
data), the manual recording of empirical observations,
and obtaining existing data from other sources.

29
Data Acquisition Methods

30
Common Data Acquisition Considerations 
 Business Needs: why are these data required? What will be done with them?
Business Rules: A business rule identifies the constraints under which the business operates.
 Data Standards: Any Government or industry standards that apply will need consideration.
 Accuracy: How much accurate and reliable data you have?
 Cost: Cost is always a consideration. Expensive to collect new data as compared to legacy
system.
 Data Currency: To identify the current value of the data
 Time Constraints: You should determine how soon you need the data.
 Format: Do you need the data in form of flat files, Excel files, XML files? This may not apply, but
you need to determine that for each project.

 
Purchased Data Considerations 
 Purchase Agreements: Data purchases require a Purchasing
Agreement. By purchasing data, you are endorsing the data.
E.g. Facebook sell the data for marketing.
 Data Certification: Metadata are required for purchased data.
The specifics of this requirement should be specified in the
Purchasing Agreement.
 Licensing Issues: What restrictions are placed upon the use
of the data? Any privacy policy.
Shared/Exchanged Data Considerations 
 Creating Data Sharing Agreements: Data sharing
agreement where privacy information may be disclosed.
 Data Organization: Is the data organized in a usable
form? Will it require conversion/transformation to make it
usable? Who will perform this? At what cost?
 Records Requirements: Data must have corresponding
metadata and other documentation.
 Completeness of Data: Is the dataset complete? If not,
who will address the gaps in the data? At what cost?
Converted/Transformed Legacy Data
Considerations 
 Legacy Quality: Is the data of sufficient quality to meet the
business needs? 
 Technical Issues: Can the data be converted into a usable
format? readable?
Newly Collected Data Considerations 
 Contractor/Volunteer : The decision of who will perform
new data collection:
 Skills: Skills required for data collection(What kind of
data we need).
 Frequency: Is this dataset will only be collected once?
Timeliness: When will the data be needed? Is it time-
critical?