Introduction to CMMI

Yelda Gurbuz Erdogan
www.hapcozum.com
1/23/2017
INTRODUCTION TO CMMI

Introduction to CMMI V1.0 23. Jan.2017
Introduction to CMMI www.hapcozum.com Page 1 of 34
Contents
1. WHAT IS CMMI ............................................................................................ 3
2. CASE STUDY................................................................................................ 5
3. CMMI HISTORY ............................................................................................ 7
4. BENEFITS of CMMI ....................................................................................... 8
Division 1 .......................................................................................................... 9
Division 2 .......................................................................................................... 9
Overall Results ................................................................................................... 9
5. CASE STUDY: Warner Robins Air Logistics Center ............................................10
6. CASE STUDY: Cost of Poor Quality.................................................................12
7. CASE STUDY: Motorola GSG China Center ......................................................12
8. CMMI MODELS ............................................................................................13
CMMI-DEV ........................................................................................................13
CMMI-SVC ........................................................................................................13
CMMI-ACQ ........................................................................................................14
ABC SW Company..............................................................................................14
9. CMMI FRAMEWORK......................................................................................14
10. PROJECT DEFINITION CHALLENGE for CMMI MODELS ......................................15
11. CMMI CORE PROCESS AREAS .......................................................................15
12. MODEL STRUCTURE.....................................................................................15
13. MODEL COMPONENTS ..................................................................................16
14. PROCESS AREA COMPONENTS ......................................................................16
15. GENERIC GOALS COMPONENTS ....................................................................17
16. CMMI PRESENTATIONS ................................................................................17
Staged Representation .......................................................................................18
Continuous Representation .................................................................................20
17. UNDERSTANDING MATURITY LEVELS.............................................................22
Maturity Level 1: Initial ......................................................................................23
Maturity Level 2: Managed..................................................................................23
Moving from Maturity Level 1 to Level 2.............................................................25
Software Engineering Process Group .................................................................25
Maturity Level 3: Defined....................................................................................26
Maturity Level 4: Quantitatively Managed .............................................................27
Maturity Level 5: Optimizing ...............................................................................28
18. UNDERSTANDING CAPABILITY LEVELS...........................................................29
Capability Level 0: Incomplete ............................................................................30
Capability Level 1: Performed..............................................................................30
Capability Level 2: Managed................................................................................30

Capability Level 3: Defined .................................................................................30
Advancing Through Capability Levels....................................................................31
19. RELATIONSHIP BETWEEN PROCESS AREAS ....................................................32
Process Area Categories .....................................................................................32
Process Management Category .........................................................................33
Project Management........................................................................................34
Engineering....................................................................................................34
Support .........................................................................................................34

1. WHAT IS CMMI
CMMI is acronym for Capability Maturity Model Integration.
The Capability Maturity Model Integration is a capability maturity model developed by the
Software Engineering Institute, part of Carnegie Mellon University in Pittsburgh, USA .
There are 3 CMMI models:
- CMMI for Development,
- CMMI for Services,
- CMMI for Acquisition,
CMMI models are collection of best practices that help organizations to improve their key
capabilities which are performance, quality, and profitability.
CMMI models can be used to guide process improvement across a project, a division, or
an entire organization to make processes applicable, visible, and measurable.
Process improvement is based on three critical dimensions that organizations typically
focus on: people, procedures and methods, and tools and equipment
CMMI provides
 Guidelines for processes improvement
 An integrated approach to process improvement
 Embedding process improvements into a state of business as usual
 A phased approach to introducing improvements
Performance Quality Profitability

In the beginning of the 1980’s, software has becoming important portion of the systems
especially in military related systems.
Computer systems were not sophisticated as today.Hence, systems have becoming more
complex. These systems had critical importance and were purchased from external
contractors.
The Department of Defense substantially needed a way to determine whether contractors
could provide software on time, within budget and to specifications.
Not only development process, maintenance process also has critical importance for
acquirer.
United States Department of Defense funded Carnegie Mellon University to provide an
approach for determine their contractor’s capability and maturity. Software Engineering
Institute is established
Software Engineering Institute has become CMMI Institute.
ISACA has acquired CMMI Institute on 1st
of March 2016.
ISACA is a global association that helps professionals worldwide keep pace with the
dynamic tech landscape and had better understand and apply technology to transform
their organizations.
Through its comprehensive knowledge, standards, credentials, and education, ISACA
defines and advances the roles of information systems assurance, governance and
cybersecurity professionals worldwide.
The association developed and administers industry-leading certifications, including:
‒ Certified Information Systems Auditor (CISA)
‒ Certified Information Security Manager (CISM)
‒ Certified in the Governance of Enterprise IT (CGEIT)
‒ Certified in Risk and Information Systems Control™ (CRISC)
ISACA also established Cybersecurity Nexus a holistic resource of cybersecurity research,
guidance, education and credentialing, including the first vendor-neutral, performance-
based cybersecurity certification.
Additionally, ISACA is the creator of COBIT, a business framework for managing and
governing enterprise information and technology.
ISACA and CMMI Institute share a vision for advancing organizational performance that
centers on supporting excellence in the IT, information systems governance, data
management governance, software, and systems engineering functions in organizations
across a spectrum of industries.
Joining forces will allow both entities to raise the level of enterprise-wide performance of
existing and prospective members and clients.
Together, they can offer holistic solutions for current and future customers. CMMI has
strong brand recognition and a record of success in the government and enterprise
segments, while ISACA excels in helping practitioners, enterprises, and governments.

The portfolio synergies will help ISACA and CMMI Institute improve value and delivery by
leveraging the strengths of each organization.
For over three decades, CMMI Institute has been helping government and industry
organizations to acquire, develop, operate, and sustain software systems that are
innovative, affordable, enduring, and trustworthy.
CMMI Institute will continue to operate independently as a stand-alone subsidiary of
ISACA.
CMMI Institute will continue to operate as always to support the appraisal review and
quality assessment process for assigning maturity level ratings for organizations that
earn them.
CMMI Institute provides training and certifications to individuals. Trainings can be divide
in five areas:
1. CMMI Practitioner Certifications
2. CMMI Instructor Certifications
3. CMMI Appraiser Certifications
4. People CMMI Certifications
5. Data Management Expert Certifications
CMMI Institute helps organizations discover the true value they can deliver by building
capability in their people and processes.
CMMI has been using at
- 101 Countries,
- 11 governments invest in CMMI to support economic development in their
countries,
- CMMI models have been translated into 10 languages.
CMMI in 60 WORDS
Capability Maturity Model Integration is a process improvement training and certification
program and service administered and marketed by Carnegie Mellon University.
Capability Maturity Model Integration required by many Department of Defense and
Government programs for government contracts, especially software development.
Carnegie Mellon University claims CMMI can be used to guide process improvement
across a project, division, or an entire organization.
2. CASE STUDY
We will go over CMMI by concerning hypothetical company.
Let’s consider a company named ABC Software Company.
ABC Software Company was established on 2012 and the headquarter is placed in
İstanbul.
ABC Software Company have 150 employees.
Organization have 4 different product lines:
- Communication Systems Solutions
- Customer Relationship Management Solutions
- Simulation Solutions

- Outsourcing Solutions
Current ABC Software Company Organization is given below figure.
- Chief Executive Officer
- Board of Directors
- Software Development Department
- Human Resources Department
- Outsourcing Solutions Department
- Business Development Department
- Marketing Department
- Purchase and Contracts Department
- Software Development Department includes
o Communication Systems Solutions Department
o Customer Relationship Management Solutions Department
o Simulation Solutions Department
- Human Resources Department includes
o Outsourcing Solutions Department
ABC software Company aimed to bid on one of major defense project by Turkish
Government on second half of 2018.
The Request for Proposal for the major project requires a CMMI Maturity Level 3.
Therefore, the ABC Software Company have a goal on to being appraised on CMMI
Maturity Level 3 on 2017
ABC Software Company needs to create formal processes and a clear strategy to enhance
their customer towards to government defense projects.
ABC software company will consider following items while their CMMI Journey:
1. Benefits of CMMI
2. Which CMMI Model is appropriate for the company
3. Which CMMI presentations useful for the company
CEO
Software
Development
Communication
Systems Solutions
Department
Customer
Relationship
Management
Solutions Department
Simulation Solutions
Department
Human Resources
Department
Outsourcing Solutions
Department
Business
Development
Department
Marketing
Department
Purchase and
Contracts
Department
Board of Directors

4. Which CMMI Level to be aimed
5. Consultancy needs
6. Changes in organizational structure
7. Roles and responsibilities identification
8. Establishment of process improvement organization
9. Determination of documentation needs
10. Process Asset Library Establishment
11. Training needs
12. Project Selection
13. CMMI Appraisals
3. CMMI HISTORY
Software Engineering Institute (SEI) was founded on 1984 in Carnegie Mellon University.
U.S. Department of Defense was sponsor for SEI.
Watts Humphrey started to work at SEI on 1986. He is also known as ‘Father of Software
Quality’.
Watts Humphrey wrote ‘Characterizing the Software Process A Maturity Framework’
report on 1987. It was the first time that process maturity levels were defined in the
report.
He wrote ‘Managing the Software Process’ book on 1989.The book introduces improving
software development and maintenance processes methods which are commonly
practiced in industry now.
‘A Method for Assessing Software Measurement Technology’ article was published and
commercialized on 1990 by SEI.Article describes a method for assessing an
organization’s software measurement technology in consistent with SEI software process
methodology.
‘Key Practices of the Capability Maturity Model’ was published by SEI on 1991. Capability
Maturity Model was comprehensively described in the document which is also known as
first version of the CMM Model.
‘The Capability Maturity Model for Software’ was published by SEI on 1993. The initial
release of the CMM, v1.0, was reviewed and used by the software community during
1991 and 1992. The SW-CMM version 1.1 is the result of the feedback from the software
community.
‘Software Capability Evaluation Implementation Guide’ was published by SEI on
1993.Software Capability Evaluation offers a means to evaluate an organization's
software process capability—that is, how well an organization manages the process it
used to create software.

‘A Systems Engineering Capability Maturity Model’ was published by SEI on 1994. The
SE-CMM describes the essential elements of an organization's systems engineering
process that must exist to ensure good systems engineering.
‘CMM Appraisal Framework’ was published by SEI on 1995. This report describes the
common requirements used by the CMM-Based Appraisal (CBA) project in developing
appraisal methods based on the Capability Maturity Model (CMM) for Software, Version
1.1.
‘Software Acquisition Capability Maturity Model’ was published by SEI on 1996. Software
Acquisition Capability Maturity Model is a model for benchmarking and improving the
software acquisition process.
CMMI first version published by SEI on 2000.
CMMI version 1.1 published by SEI on 2002.
4. BENEFITS of CMMI
Capability Maturity Model Integration models has many benefits in scope of following
criteria:
- Cost
- Schedule
- Quality
- Customer Satisfaction
- Return on Investment
U.S. Government Agency claims that Using CMMI Increases Software Productivity by
34%.1
Previously, the agency had implemented an ISO 9000 process for project management
and quality control.
While this demonstrated that its divisions had appropriate documentation, it did not
prove they had the capability to deliver consistent, defect-free performance.
In an effort to prove its capabilities, the agency required all of its divisions, as well as its
contract partners and suppliers, to earn a CMMI maturity level 2 or 3 rating.
Implementing CMMI would move its divisions toward a standard set of processes that
everyone could follow.
The use of the CMMI model was included to make sure agency projects are supported by
software development organizations having the necessary skills and processes in place to
produce reliable products within cost and schedule estimates.
The CMMI requirement provides the agency with a methodology to determine these
factors:
- Measure software development organizations against an industry-wide set of best
practices that address software development and maintenance activities applied to
products and services.
1
http://cmmiinstitute.com/sites/default/files/Government%20Agency%20Case%20Study_061616.pdf

- Evaluate and compare the maturity of an organization’s product development and
acquisition processes with industry state of the practice.
- Measure and ensure compliance with the intent of the agency’s process-related
requirements document, using an industry-standard approach.
- Assess internal and external organizations’ software development processes.
- Identify potential risk areas within a given organization’s software development
processes.
Division 1
One division of this government agency is the “go to” organization for process expertise;
and it frequently provides training and mentoring to other software projects.
To earn maturity level 3 rating, it implemented CMMI for Development, version 1.3, to
achieve the following goals:
- Created a vast suite of process assets such as templates, checklists, forms, and
methods to facilitate product development
- Developed lean operating procedures
- Produced tools to ensure comprehensive life-cycle traceability and relationship
identification
- Institutionalized work instructions at the project and organizational levels
- Introduced peer-review methods and tools that support complete, consistent, and
accurate results
- Provided role-based process training through the agency’s online training tool ,
This division was the first to earn a CMMI maturity level 3 rating. For 10 years, it has
consistently applied process improvements to its software in support of its objectives.
As a result, it has achieved many efficiencies and has become a trusted adviser
throughout the organization for all things process related. It has reported an increase in
productivity and a reduction in defects.
Division 2
Another division of this agency is responsible for research, design, development, and
testing innovative technology. To earn a maturity level 2 rating, it deployed
CMMI for Development version 1.3, to achieve these objectives:
- Updated all operating processes and templates
- Implemented goals to ensure processes were defined, communicated, repeatable,
and consistent across the division to help stay on budget and on schedule
- Worked to better organize and document the training needs of all employees
Through its process improvements, this division has been able to estimate costs
consistently and more accurately so that projects can meet budgetary requirements.
It is also able to predict project timelines more consistently to prevent deadline
extensions.
Overall Results
Eight of the 10 divisions of this government agency have adopted CMMI and earned
maturity level 2 or 3 ratings or higher.
This has become the model against which the organization measures the capabilities of
the contractors it hires and has been a key factor in maintaining quality and increasing
productivity.

Benefits of CMMI regarding ABC Software company as follows:
- Enhance customer portfolio
- Establish common language
- Processes Standardization
- Measurement Standardization
- Better coordination in identifying, communicating, and understanding priorities
- Proven best practices
- Increase productivity
5. CASE STUDY: Warner Robins Air Logistics Center2
In October 1997, Warner Robins Air Logistics Center consolidated its four previously
separate software organizations into a single division called the Software Engineering
Division
These four organizations previously had some experience Software CMM maturity level 3,
but these activities had been performed separately in each of them
The Software Engineering Division immediately established an integrated Software
Engineering Process Group and a Quality Metrics Group
Software Engineering Process Group and a Quality Metrics Group established a process
architecture to adopt the best practices identified in the existing best practices from the
four original organizations and map those practices to the SW-CMM.
The Software Engineering Process Group Division achieved Software Engineering
Capability Maturity Model maturity level 3 in an Software Engineering Institute-led, CMM-
Based Appraisal for Internal Process Improvement in April of 2000.
During the same timeframe, CMMI pilot appraisal was conducted that brought together
projects involved in systems engineering, software engineering, and software acquisition.
In July 2001, the Software Engineering Group Division decided to transition from the
Software CMM to CMMI. Next 12 months, the Software Engineering Process Group
performed a gap analysis to determine which areas of the organization’s process
architecture would need to change.
In December 2002, the Software Engineering Group division rolled out a revised software
engineering process to the organization.
From September through December 2003, four Standard CMMI Appraisal Method for
Process Improvement (SCAMPI) Class B appraisals were performed to assess the
organization’s readiness for a SCAMPI Class A appraisal.
During the Class B appraisals, team members from company and the SEI reviewed more
than 980 artifacts across seven projects and identified areas of risk in how the
organization was implementing the practices identified in CMMI.
These appraisals led to action plans for addressing the risk areas and verification
meetings between each of the projects. Software Engineering Process Group determined
whether the organization was adequately addressing the findings.
An appraisal in October 2004 confirmed that the Software Engineering Division had
achieved CMMI maturity level 5.
2
http://seir.sei.cmu.edu/cmmiresearch/results/pdfs/DACS-Software-Tech-News-Mar-07-
cost-schedule-quality.pdf

This process standardization effort within the Software Engineering Division eliminated
late deliveries of software releases from August 2004 to January 2005. This marked
improvement prompted the division to embrace a goal of 100 percent on-time delivery
for fiscal year 2005.
Similar dramatic results were also achieved in delivered defect reduction after
implementing the CMMI maturity level 5 process improvement practices with no defects
reported in fielded software during the same six-month period.
Very little variance between estimated and actual cost, and proportionally, more of the
projects were completed under their cost estimates.
Variation in schedule adherence was significantly reduced and negative occurrences were
almost completely eliminated.
Figure summarizes the differences in cost variance. X axis indicates cost variance. Y axis
indicates number of projects
Before CMMI Level 5 implementation, there was substantially more variation among the
projects cost performance, and more of the projects came in over budget. After CMMI L5,
there was much less variation among the projects. There was very little variance
between estimated and actual cost, and proportionally, more of the projects were
completed under their cost estimates.
Figure summarizes the differences in schedule variance. X axis indicates schedule
variance. Y axis indicates number of projects.
Before CMMI Level 5 implementation, several products were delivered late, with
considerable schedule variance. After achieving maturity level 5, variation in schedule
adherence was significantly reduced and negative occurrences were almost completely
eliminated.

6. CASE STUDY: Cost of Poor Quality
Another case study shows that cost of poor quality reduced by implementing CMMI Level
2.
Figure shows a comparison of the cost of poor quality in 2002 and 2003 on a cumulative
basis as well as month-by-month. The absolute values have been sanitized in the figure;
however, the cumulative cost of poor quality was 30 percent lower in 2003 in the unit’s
second year of CMMI-based improvement.
7. CASE STUDY: Motorola GSG China Center3
Another case study shows improved verification process reduce cost of quality. By
implementing CMMI Level 5.
3
http://seir.sei.cmu.edu/cmmiresearch/results/pdfs/DACS-Software-Tech-News-Mar-07-
motorola.pdf

As result of improved verification processes, particularly product peer review and
software test processes, Company could reduce its overall cost of quality by over one
third, 36.5 percent, from its pre-CMMI baseline. The cost of poor quality remained under
control at less than 5 percent during the same period.
8. CMMI MODELS
CMMI suite have 3 models:
- CMMI for Development
- CMMI for Services
- CMMI for Acquisition
CMMI-DEV
CMMI for Development model is collection of best practices meant for Software
Development Companies to improve their products and thus to improve customer
satisfaction by meeting needs of customers and end users.
The companies which develops complex systems on banking services, IT services,
telecom products, defense systems, oil refineries, simulation solutions, solar systems,
constructions prefer to get certified on CMMI for Development.
When a company has certification on CMMI for development, it shows their customer that
capability and maturity of their process on their product development.
When we checked CMMI published appraised result database, we will face following
result:
Total Number of company which has CMMI for Development version 1.3 is 4939.
CMMI-SVC
CMMI for Services model is a collection of best practices meant for Provider Organizations
to minimize cost, improve quality, and improve the predictability of their service
deliveries, and thus achieving a larger share of profit.

The companies which provides service solutions on consulting, outsourcing, healthcare,
banking and financial services, payments, retail, human resource, hospitality prefers to
get certified on CMMI for Services.
When a company has certification on CMMI for Services, it shows their customer that
capability and maturity of their process on their service solutions development.
result:
Total Number of company which has CMMI for Services version 1.3 is 513.
CMMI-ACQ
CMMI for Acquisition model is a collection of purchase best practices meant for
Acquisition Companies to focus on activities for initiating and managing the acquisition of
products and services which meet the needs of the customers.
The companies which provides services on acquiring prefers to get certified on CMMI for
Acquisition.
When a company has certification on CMMI for Acquisition, it shows their customer that
capability and maturity of their process on their acquisition solutions.
result:
Total Number of company which has CMMI for Acquisition version 1.3 is 10.
ABC SW Company
Since ABC Software Company develops software product, the company would select
CMMI for Development model.
CMMI for Development model is the most suitable for the company.
While preparation and assessment of CMMI for Development, some departments will be
excluded from appraisal.
These departments have not influence on product development directly. Excluded
departments may be specified in the certification document.
Excluded departments for ABC company would be as follows:
- Outsourcing Solutions Department
- Business Development Department
- Purchase and Contracts Department
- Marketing Department
9. CMMI FRAMEWORK
All CMMI models are produced from the CMMI Framework. The CMMI Framework
provides the structure needed to produce CMMI models, training, and appraisal
components.
 The model components include process areas, goals, practices, and informative
material about the use of the model and its components.
 The training components include guidebooks on implementing the model and
audio-visuals to support teaching how to use the model.

 The appraisal components describe the process of appraising the organization’s
processes against the goals and practices described in the model. They also
include training for performing the appraisal process.
In the framework, there are constellations of components that are used to construct
models, training, and appraisal materials in an area of interest for example acquisition,
development, or services:
 The Acquisition constellation supports an organization (or project) in procuring
products or services from suppliers outside of the organization (or project).
 The Development constellation supports an organization (or project) that develops
products or services.
 The Services constellation supports an organization (or project) that delivers
services.
10.PROJECT DEFINITION CHALLENGE for CMMI MODELS
“Project” commonly refers to an endeavor whose purpose and end are marked by the
delivery of something tangible for example a product. This project definition is good for
CMMI for Development and CMMI for Acquisition.
“Work” “Work Activities” “Services” terms are used for CMMI for Services instead of
project term.
11.CMMI CORE PROCESS AREAS
A process area is a cluster of related practices in an area that, when implemented
collectively, satisfies a set of goals considered important for making improvement in that
area.
“Core Process Areas” means that these process areas are common in the CMMI for
Development, CMMI for Services, and CMMI for Acquisition models.
There are 16 (sixteen) core process areas are given as alphabetical order:
 Causal Analysis and Resolution (CAR)
 Configuration Management (CM)
 Decision Analysis and Resolution (DAR)
 Integrated Project Management (IPM)
 Measurement and Analysis (MA)
 Organizational Innovation and Deployment (OID)
 Organizational Process Definition (OPD)
 Organizational Process Focus (OPF)
 Organizational Process Performance (OPP)
 Organizational Training (OT)
 Project (Work) Monitoring and Control (PMC)
 Project (Work) Planning (PP)
 Process and Product Quality Assurance (PPQA)
 Quantitative Project Management (QPM)
 Requirements Management (REQM)
 Risk Management (RSKM)
12.MODEL STRUCTURE
CMMI models have a defined structure.When you look at the structure of a process area,
there are components. Model components are grouped into three categories:

 Required Components: These are essential to achieving process improvement in
each process area
 Expected Components: These describe activities which are important in achieving
a required component.
 Informative Components: These help model users understand required and
example components.
13.MODEL COMPONENTS
 Process Area
 Introductory Notes
 Related Process Areas
 Specific Goals
 Specific Practices
 Typical Work Products
 Sub-practices
 Generic Goals
 Generic Practices
 Generic Practices Elaborations
In thıs figure:
 Rectangular shows required components.
 Dimond shows expected components
 Oval shows informative components.
14.PROCESS AREA COMPONENTS
CMMI models explain process area comprehensively.

Process Area Name is given in the beginning of the related process area chapter and is
an informative component.
Process Area Category indicates category of the process area and is an informative
component.
Maturity Level indicates maturity level of process area. and is an informative component.
Purpose Statement describes the purpose of the process area and is an informative
component.
Introductory Notes describes the major concepts covered in the process area and is an
informative component.
Specific Goal describes the unique characteristics that must be present to satisfy the
process area and is a required model component. It is used in appraisals to help
determine whether a process area is satisfied.
Specific Practice is the description of an activity that is considered important in achieving
the associated specific goal and is an expected model component.
Example Work Product lists sample outputs from a specific practice and is an informative
component.
Example Box is a component comprising text and often a list of items, usually in a box,
that can accompany nearly any other component and is an informative component.
Subpractice is a detailed description that provides guidance for interpreting and
implementing a specific or generic practice and is an informative component.
Reference is a pointer to additional or more detailed information in related process areas
and can accompany nearly any other model component. It is an informative model
component.
15.GENERIC GOALS COMPONENTS
Generic Goal describes the characteristics that must be present to institutionalize
processes that implement a process area. A Generic Goal is a required model component
and is used in appraisals to determine whether a process area is satisfied.is a required
model component.
Generic Practice associated with a generic goal describe the activities that are considered
important in achieving the generic goal and contribute to the institutionalization of the
processes associated with a process area. A generic practice is an expected model
component.
Generic Practice Elaboration appear after generic practices to provide guidance on how the generic
practices can be applied uniquely to process areas. A generic practice elaboration is an informative
model component.
16. CMMI PRESENTATIONS
CMMI models have two different presentations:
- Staged
- Continuous

In terms of process areas and generic goals, the meeting requirements is the same either
Staged or Continuous Representation for CMMI.
The difference between staged and continuous representation is approach for
implementation and appraisal for CMMI.
Staged Representation
Staged Representation uses Maturity Levels to measure Process Improvements.
Maturity levels apply to the organization’s overall maturity.
The maturity level of an organization provides a way to characterize its performance.
Experience has shown that organizations do their best when they focus their process
improvement efforts on a manageable number of process areas at a time and that those
areas require increasing sophistication as the organization improves.
There are five Maturity Levels:
- Maturity Level 1: Initial
- Maturity Level 2: Managed
- Maturity Level 3: Defined
- Maturity Level 4: Quantitatively Managed
- Maturity Level 5: Optimizing
At Maturity Level 1, Processes are unpredictable, poorly controlled, reactive.
At Maturity Level 2, Processes are planned, documented, performed, monitored, and
controlled at the project level.Often reactive.
At Maturity Level 3, Processes are well characterized and understood.Processes,
standards, procedures, tools, etc. are defined at the organizational level.Proactive.
At Maturity Level 4, Processes are controlled using statistical and other quantitative
techniques.
At Maturity Level 5, Process performance continually improved through incremental
and innovative technological improvements.

The staged representation is concerned with selecting multiple process areas to
improve within a maturity level; whether individual processes are performed or
incomplete is not the primary focus.
Therefore, the name “Initial” is given to the staged representation starting point.
When a company selects staged representation, the company achieve all process areas
regarding aimed maturity level.
The staged representation provides a path of improvement from maturity level 1 to
maturity level 5 that involves achieving the goals of the process areas at each maturity
level.
Maturity levels apply to an organization’s process improvement achievement across
multiple process areas.
There may be some exceptions. Supplier Agreement Management process area is
commonly excluded while appraisals.
For example, if company produce all products by itself, then Supplier Agreement
Management would be excluded.
You may think that company purchase computers, tools, consulting service and so on.
How supplier agreement management process area would be excluded.
Since these purchase items are not directly related with product development, service
development or acquisition.
If main activity of the company on acquisition, then the company will get CMMI for
Acquisition.
The Maturity Level 2 has 7 process areas. The company should cover for all these 7
process areas.
The Maturity Level 3 includes 11 process areas. In the CMMI appraisal, will be performed
for 18 process areas including Level 2 process areas.
for 20 process areas including Level 2 and Level 3 process areas.
for 22 process areas including Level 2, Level 3 and Level 4 process areas.
The staged representation is most popular CMMI representation. When we check
published appraisal result site of CMMI, there are 5152 staged appraisals which is 93% of
total appraisal.
Let’s assume that ABC Software company would select Staged Representation and
Maturity Level 2.
The appraisal will cover all over organization departments which are subjected to
appraisal for Maturity Level 2.
Maturity Level 2 includes following process areas:
- Configuration Management
- Measurement and Analysis
- Project Monitoring and Control
- Project Planning
- Process and Product Quality Assurance

- Requirements Management
- Supplier Agreement Management
Supplier Agreement Management will not be included appraisal. This is indicated on
published appraisal result and result will be shown as:
CMMI-DEV v1.3(Staged): Maturity Level 2.
Continuous Representation
Continuous Representation uses Capability Levels to measure Process Improvements.
Capability levels apply to an organization’s process improvement achievement in
individual process areas.
There are 4 Capability Levels:
- Capability Level 0: Incomplete
- Capability Level 1: Performed
- Capability Level 2: Managed
- Capability Level 3: Defined
The continuous representation is concerned with selecting both a process area to improve
and the desired capability level for that process area.
In this context, whether a process is performed or incomplete is important.
Therefore, the name “Incomplete” is given to the continuous representation starting
point.
When a company selects continuous representation, the company selects process areas
then aimed Level.
Capability Level 0 is INCOMPLETE: Not comply fully with Specific Goals of Process Area
Capability Level 1 is PERFOMED: Process fully comply with CMMI Specific Goals of
Process Area but through individual’s expertise. ‘All in his Head’
Capability Level 2 is MANAGED: Fully comply through sub-units having own planned
process but no organization standards to tailor from. Informally copy paste only.

Capability Level 3 is DEFINED: Fully comply and have organizational standards. Formally
inherit, modify, paste ,
Continuous representation is rarely chosen. When we check published appraisal result
site of CMMI, there are 411 continuous appraisals which is 7 % of total appraisal ,
When we check published appraisal result site of CMMI, there are 297 Continuous
appraisals has been done in total of 4939 CMMI appraisals.
If ABC Software company, select continuous would select continuous representation, the
company first selects the process areas then selects the level.For example, ABC Company
selects following process areas for Capability Level 2:
- Project Planning
- Requirement Management
- Measurement Analysis
It will be shown on published appraisal result as:
CMMI-DEV v1.3(Continuous): Maturity Level 2
Each representation has advantages over the other, some organizations use both
representations to address needs at various times in their improvement programs.We
provide the advantages and disadvantages of each representation to help you decide
which representation is best for your organization.
Continuous Representation Staged Representation
Grants explicit freedom to select the order
of improvement that best meets the
organization’s business objectives and
mitigates the organization's areas of risk
Enables organizations to have a
predefined and proved improvement path

Continuous Representation Staged Representation
Enables increased visibility of the
capability achieved in each individual
process area
Focuses on a set of processes that provide
an organization with a specific capability
that is characterized by each maturity
level
Provides a capability-level rating that is
used primarily for improvement in an
organization and is rarely communicated
externally
Provides a maturity-level rating that is
often used in internal management
communication, statements external to
the organization, and during acquisitions
to qualify bidders
Allows improvements of different
processes to be performed at different
rates
Summarizes process-improvement results
in a simple form—a single maturity-level
number
Reflects a newer approach that does not
yet have the data to demonstrate its ties
to return on investment
Builds on a relatively long history of use
that includes case studies and data that
demon strait proved return on investment
CMMI representations is chosen regarding following items:
- Company Business Objectives
- Company Culture
- Company Legacy
17. UNDERSTANDING MATURITY LEVELS
Maturity Levels are used in CMMI models to describe an evolutionary path recommended
for an organization that wants to improve the processes it uses to develop products or
services.
Maturity Levels can also be the outcome of the rating activity in appraisals. Appraisals
can apply to entire organizations or to smaller groups such as a group of projects or a
division.
Maturity Levels enable organizations to improve a set of related processes by
incrementally addressing successive sets of process areas.

The five maturity levels, each a layer in the foundation for ongoing process improvement,
are designated by the numbers 1 through 5:
1. Initial
2. Managed
3. Defined
4. Quantitatively Managed
5. Optimizing
Maturity Level 1: Initial
At maturity level 1, processes are usually ad hoc and chaotic.
The organization usually does not provide a stable environment to support processes.
Success in these organizations depends on the competence and heroics of the people in
the organization and not on the use of proven processes.
Despite this chaos, maturity level 1 organizations often produce products and services
that work, but they frequently exceed the budget and schedule documented in their
plans.
Maturity Level 1 organizations are characterized by a tendency to overcommit, abandon
their processes in a time of crisis, and be unable to repeat their successes.
Maturity Level 2: Managed
At maturity level 2, the projects have ensured that processes are planned and executed
in accordance with policy; the projects employ skilled people who have adequate
resources to produce controlled outputs; involve relevant stakeholders; are monitored,
controlled, and reviewed; and are evaluated for adherence to their process descriptions.
The process discipline reflected by maturity level 2 helps to ensure that existing practices
are retained during times of stress.
When these practices are in place, projects are performed and managed per their
documented plans.
Maturity Level 2 includes 7 process areas which are

- Project Planning
- Requirement Management
- Measurement Analysis
- Supplier Agreement Management
Maturity Level 2:
- The status of the work products is visible to management at defined points.
- Commitments are established among relevant stakeholders and are revised as
needed.
- Work products are appropriately controlled.
- The work products and services satisfy their specified process descriptions,
standards, and procedures.
Let’s discuss Project Planning Process Area which is one of Maturity Level 2 process
areas.
Project Planning process area has 3 specific goals which are:
1. Establish Estimates
2. Develop a Project Plan
3. Obtain Commitment to the Plan
In order to meet first specific goal which is Establish Estimates, following specific
practices are required to complete in scope of appraisal:
1. Estimate the Scope of the Project
2. Establish Estimates of Work Product and Task Attributes
3. Define Project Lifecycle Phases
4. Estimate Effort and Cost
Let’s look at the first specific practice ‘Estimate the Scope’ in detail.
‘Estimate the Scope’ specific practice requires a top-level work breakdown structure must
be established to estimate the scope of the project.
The work breakdown structure evolves with the project. A top-level work breakdown
structure can serve to structure initial estimating.
The development of a work breakdown structure divides the overall project into an
interconnected set of manageable components.
In order to meet ‘Estimate the Scope’ specific practice requirement following activities
should be performed:
Firstly, Work Breakdown Structure should be developed. The Work Breakdown Structure
provides a scheme for organizing the project’s work.
Secondly, the work packages are defined in sufficient detail so that estimates of project
tasks, responsibilities, and schedule can be specified.
Thirdly, products and product components are identified to be externally acquired.
Lastly, work products are identified to be reused.

Moving from Maturity Level 1 to Level 2
The biggest issue that most organizations face when embarking on the journey from an
immature organization to a more mature one is the jump from Maturity Level 1 to
Maturity Level 2.
Maturity Level 1 is characterized as ad hoc processes which means that processes that
the people doing the work have created themselves in order to accomplish their tasks.
The problem with this method is that redundant work is often done, people do not share
their methods across the organization, and some approaches are in opposition to make
the organization run more effectively.
While some individual approaches may work for that individual, that person's approach
may conflict with work being done downstream.
The results are more rework, delays, and frustration.
The organization functions due to the heroics of its people. When these people move on,
the organization suffers.
If ABC Software Company wants to go more mature organization, firstly they should
establish the software engineering process group.
Software Engineering Process Group
The software engineering process group is the focal point for process improvement.
Composed of line practitioners who have varied skills, the group is at the center of the
collaborative effort of everyone in the organization who is involved with software
engineering process improvement.
Group size is usually equal to 1-3% of the development staff. Because the process group
is small, it relies upon outside support the support of a steering committee and technical
working groups.
The software engineering process group is a central force for process improvement.
The group maintains the overall view of current efforts and facilitates these efforts on a
continuing basis.
Its members foster collaboration among everyone in the organization who is involved
with software process improvement.
Following are ongoing activities of the software process engineering group:
- Obtains and maintains the support of all levels of management.
- Facilitates software process assessments.
- Works with line managers whose projects are affected by changes in software
engineering practice, providing a broad perspective of the improvement effort and
helping them set expectations.
- Maintains collaborative working relationships with software engineers, especially
to obtain, plan for, and install new practices and technologies.
- Arranges for any training or continuing education related to process
improvements.
- Tracks, monitors, and reports on the status of particular improvement efforts.
- Facilitates the creation and maintenance of process definitions, in collaboration
with managers and engineering staff.
- Maintains a process database.
- Provides process consultation to development projects and management

Maturity Level 3: Defined
At maturity level 3, processes are well characterized and understood, and are described
in standards, procedures, tools, and methods.
The organization’s set of standard processes, which is the basis for maturity level 3, is
established and improved over time.
These standard processes are used to establish consistency across the organization.
Projects establish their defined processes by tailoring the organization’s set of standard
processes per tailoring guidelines.
The standards, process descriptions, and procedures for a project are tailored from the
organization’s set of standard processes to suit a particular project or organizational unit
and therefore are more consistent except for the differences allowed by the tailoring
guidelines.
At maturity level 3, processes are typically described more rigorously than at maturity
level 2.
A defined process clearly states the purpose, inputs, entry criteria, activities, roles,
measures, verification steps, outputs, and exit criteria.
At maturity level 3, processes are managed more proactively using an understanding of
the interrelationships of process activities and detailed measures of the process, its work
products, and its services.
1. Decision Analysis and Resolution
2. Integrated Project Management
3. Organizational Process Definition
4. Organizational Process Focus
5. Organizational Training
6. Product Integration
7. Requirements Development
8. Risk Management
9. Technical Solution
10. Validation
11. Verification
At maturity level 3, the organization further improves its processes that are related to
the maturity level 2 process areas.
Generic practices associated with generic goal 3 that were not addressed at maturity
level 2 are applied to achieve maturity level 3.
Let’s discuss Risk Management which is one of Maturity Level 3 process areas.
Risk Management process area has 3 specific goals which are:
1. Prepare for Risk Management
2. Identify and Analyze Risks
3. Mitigate Risks
In order to meet first specific goal which is Prepare for Risk Management, following
specific practices are required to complete in scope of appraisal:
1. Determine Risk Sources and Categories

2. Define Risk Parameters
3. Establish a Risk Management Strategy
Let’s look at first specific practice ‘Determine Risk Sources and Categories’ in detail.
‘Determine Risk Sources and Categories’ specific practice requires identifying risk sources
provides a basis for systematically examining changing situations over time to uncover
circumstances that affect the ability of the project to meet its objectives.
Firstly, risk sources are determined. Risk sources are fundamental drivers that cause
risks in a project or organization. There are many sources of risks, both internal and
external to a project. Risk sources identify where risks can originate.
Lastly, risk categories are determined. Risk categories are ‘bins’ used for collecting and
organizing risks. Identifying risk categories aids the future consolidation of activities in
risk mitigation plans.
Maturity Level 4: Quantitatively Managed
At maturity level 4, the organization and projects establish quantitative objectives for
quality and process performance and use them as criteria in managing projects.
Quantitative objectives are based on the needs of the customer, end users, organization,
and process implementers.
Quality and process performance is understood in statistical terms and is managed
throughout the life of projects.
1. Organizational Process Performance
2. Quantitative Project Management
For selected sub-processes, specific measures of process performance are collected and
statistically analyzed.
When selecting sub processes for analyses, it is critical to understand the relationships
between different sub-processes and their impact on achieving the objectives for quality
and process performance.
Such an approach helps to ensure that sub-process monitoring using statistical and other
quantitative techniques is applied to where it has the most overall value to the business.
Process performance baselines and models can be used to help set quality and process
performance objectives that help achieve business objectives.
Let’s discuss Quantitative Project Management process area which is one of Maturity
Level 4 process areas.
Quantitative Project Management process area has 2 specific goals which are:
1. Prepare for Quantitative Management
2. Quantitatively Manage the Project
In order to meet first specific goal which is Prepare for Quantitative Management,
following specific practices are required to complete in scope of appraisal:
1. Establish the Project’s Objectives
2. Compose the Defined Process
3. Select Sub-processes and Attributes
4. Select Measures and Analytic Techniques

Let’s look at first specific practice ‘Establish the Project’s Objectives’ in detail.
‘Establish the Project’s Objectives’ specific practice requires establishment and
maintenance of the project’s quality and process performance objectives.
Firstly, the organization's objectives are reviewed for quality and process performance.
This review ensures that project members understand the broader business context in
which the project operates. The project’s objectives for quality and process performance
are developed in the context of these overarching organizational objectives.
Secondly, the quality and process performance needs and priorities of the customer,
suppliers, end users, and other relevant stakeholders are identified.
Thirdly, measurable quality and process performance objectives are defined and
documented for the project.
Fourthly, interim objectives are derived to monitor progress toward achieving the
project’s objectives. Interim objectives can be established for attributes of selected
lifecycle phases, milestones, work products, and sub-processes.
Fifthly, the risk of not achieving the project’s quality and process performance objectives
are determined. The risk is a function of the established objectives, the product
architecture, the project’s defined process, availability of needed knowledge and skills,
and so on.
Sixthly, conflicts are resolved among the project’s quality and process performance
objectives. Process performance models can help to identify conflicts and help to ensure
that the resolution of conflicts does not introduce new conflicts or risks.
Seventhly, traceability to the project’s quality and process performance objectives are
established from their sources.
Eighthly, quality and process performance objectives are defined and negotiated for
suppliers.
Lastly, the project’s quality and process performance objectives are revised as necessary.
Maturity Level 5: Optimizing
At maturity level 5, an organization continually improves its processes based on a
quantitative understanding of its business objectives and performance needs. The
organization uses a quantitative approach to understand the variation inherent in the
process and the causes of process outcomes.
Maturity level 5 focuses on continually improving process performance through
incremental and innovative process and technological improvements.
The organization’s quality and process performance objectives are established,
continually revised to reflect changing business objectives and organizational
performance, and used as criteria in managing process improvement.
The effects of deployed process improvements are measured using statistical and other
quantitative techniques and compared to quality and process performance objectives.
The project’s defined processes, the organization’s set of standard processes, and
supporting technology are targets of measurable improvement activities.
Maturity Level 5 includes 2 process areas which are:
1. Causal Analysis and Resolution

2. Organizational Performance Management
At maturity level 5, the organization is concerned with overall organizational performance
using data collected from multiple projects.
Analysis of the data identifies shortfalls or gaps in performance.
These gaps are used to drive organizational process improvement that generates
measurable improvement in performance.
Let’s discuss Causal Analysis and Resolution process area which is one of Maturity Level 5
process areas.
Causal Analysis and Resolution process area has 2 specific goals which are:
1. Determine Causes of Selected Outcomes
2. Address Causes of Selected Outcomes
In order to meet first specific goal which is ‘Determine Causes of Selected Outcomes’,
following specific practices are required to complete in scope of appraisal:
1. Select Outcomes for Analysis
2. Analyze Causes ,
Let’s look at first specific practice ‘Select Outcomes for Analysis’ in detail.
‘Select Outcomes for Analysis’ specific practice requires selecting outcomes for analysis.
This activity could be triggered by an event which is reactive approach or could be
planned periodically, such as at the beginning of a new phase or task which is proactive
approach.
Firstly, relevant data are gathered.
Secondly, which outcomes to analyze further is determined.
Lastly, the scope of the analysis is formally defined, including a clear definition of the
improvement needed or expected, stakeholders affected, target affected, and so on.
18. UNDERSTANDING CAPABILITY LEVELS

Capability Levels are used in CMMI models to describe an evolutionary path
recommended for an organization that wants to improve the processes it uses to develop
products or services.
Capability Levels can also be the outcome of the rating activity in appraisals. Appraisals
can apply to entire organizations or to smaller groups such as a group of projects or a
division.
Capability Levels enable organizations to incrementally improve processes corresponding
to an individual process area or group of process areas selected by the organization.
Capability Level 0: Incomplete
An incomplete process is a process that either is not performed or is partially performed.
One or more of the specific goals of the process area are not satisfied and no generic
goals exist for this level since there is no reason to institutionalize a partially performed
process.
Capability Level 1: Performed
A capability level 1 process is characterized as a performed process.
A performed process is a process that accomplishes the needed work to produce work
products; the specific goals of the process area are satisfied.
Although capability level 1 results in important improvements, those improvements can
be lost over time if they are not institutionalized.
The application of institutionalization helps to ensure that improvements are maintained.
Capability Level 2: Managed
A capability level 2 process is characterized as a managed process.
A managed process is a performed process that is planned and executed in accordance
with policy; employs skilled people having adequate resources to produce controlled
outputs; involves relevant stakeholders; is monitored, controlled, and reviewed; and is
evaluated for adherence to its process description.
The process discipline reflected by capability level 2 helps to ensure that existing
practices are retained during times of stress.
Capability Level 3: Defined
A capability level 3 process is characterized as a defined process.
A defined process is a managed process that is tailored from the organization’s set of
standard processes according to the organization’s tailoring guidelines; has a maintained
process description; and contributes process related experiences to the organizational
process assets.
A critical distinction between capability levels 2 and 3 is the scope of standards, process
descriptions, and procedures.
At capability level 2, the standards, process descriptions, and procedures can be quite
different in each specific instance of the process for example on a particular project.
At capability level 3, the standards, process descriptions, and procedures for a project
are tailored from the organization’s set of standard processes to suit a particular project
or organizational unit and therefore are more consistent, except for the differences
allowed by the tailoring guidelines.

Another critical distinction is that at capability level 3 processes are typically described
more rigorously than at capability level 2.
A defined process clearly states the purpose, inputs, entry criteria, activities, roles,
measures, verification steps, outputs, and exit criteria.
At capability level 3, processes are managed more proactively using an understanding of
the interrelationships of the process activities and detailed measures of the process and
its work products.
Advancing Through Capability Levels
The capability levels of a process area are achieved through the application of generic
practices or suitable alternatives to the processes associated with that process area.
Reaching capability level 1 for a process area is equivalent to saying that the processes
associated with that process area are performed processes.
Reaching capability level 2 for a process area is equivalent to saying that there is a policy
that indicates you will perform the process.
There is a plan for performing it, resources are provided, responsibilities are assigned,
training to perform it is provided, selected work products related to performing the
process are controlled, and so on.
In other words, a capability level 2 process can be planned and monitored just like any
project or support activity.
Reaching capability level 3 for a process area is equivalent to saying that an
organizational standard process exists associated with that process area, which can be
tailored to the needs of the project.
The processes in the organization are now more consistently defined and applied because
they are based on organizational standard processes.
After an organization has reached capability level 3 in the process areas it has selected
for improvement, it can continue its improvement journey by addressing high maturity
process areas which are Organizational Process Performance, Quantitative Project
Management, Causal Analysis and Resolution, and Organizational Performance
Management.
The high maturity process areas focus on improving the performance of those processes
already implemented.
The high maturity process areas describe the use of statistical and other quantitative
techniques to improve organizational and project processes to better achieve business
objectives.
When continuing its improvement journey in this way, an organization can derive the
most benefit by first selecting the Organizational Process Performance and Quantitative
Project Management process areas, and bringing those process areas to capability levels
1, 2, and 3. In doing so, projects and organizations align the selection and analyses of
processes more closely with their business objectives.
After the organization attains capability level 3 in the Organizational Process Performance
and Quantitative Project Management process areas, the organization can continue its
improvement path by selecting the Causal Analysis and Resolution and Organizational
Performance Management process areas.

In doing so, the organization analyzes the business performance using statistical and
other quantitative techniques to determine performance shortfalls, and identifies and
deploys process and technology improvements that contribute to meeting quality and
process performance objectives.
Projects and the organization use causal analysis to identify and resolve issues affecting
performance and promote the dissemination of best practices.
19. RELATIONSHIP BETWEEN PROCESS AREAS
Relationship between process areas is very important topic for appraisal preparation
phase of the company.
When company starts to their CMMI journey, CMMI team should relationship between
process areas because it gives systematic approach to meet CMMI requirements.
In other words, relationships among process areas to help you see the organization’s
view of process improvement and how process areas depend on the implementation of
other process areas.
The relationships among multiple process areas, including the information and artifacts
that flow from one process area to another help you to see a larger view of process
implementation and improvement.
Successful process improvement initiatives must be driven by the business objectives of
the organization.
For example, a common business objective is to reduce the time it takes to get a product
to market.
The process improvement objective derived from that might be to improve the project
management processes to ensure on-time delivery; those improvements rely on best
practices in the Project Planning and Project Monitoring and Control process areas.
Although we group process areas in this chapter to simplify the discussion of their
relationships, process areas often interact and have an effect on one another regardless
of their group, category, or level.
For example, the Decision Analysis and Resolution process area, it’s category Support,
and it is one of the process area at Maturity Level 3.
It contains specific practices that address the formal evaluation process used in the
Technical Solution process area for selecting a technical solution from alternative
solutions.
Being aware of the key relationships that exist among CMMI process areas will help you
apply CMMI in a useful and productive way.
Relationships among process areas are described in more detail in the references of each
process area and specifically in the Related Process Areas section of each process area in
this part.
Process Area Categories
CMMI models have 22 process areas which are grouped into four categories to
understand their interactions and links with one another regardless of their defined level:
- Process Management
- Project Management

- Engineering
- Support
Let’s consider CMMI for Development model.
Process Management Category
Process Management category have 5 process areas:
1. Organizational Process Definition
2. Organizational Process Focus
3. Organizational Performance Management
4. Organizational Process Performance
5. Organizational Training
There are two levels relationship in between Process Areas of Process Area Category
- The Basic Process Management Process Areas
- The Advance Process Management Process Areas
Basic Process Management Process Areas
The Basic Process Management process areas provide the organization with a capability
to document and share best practices, organizational process assets, and learning across
the organization.
Figure provides a bird’s-eye view of the interactions among the Basic Process
Management process areas and with other process area categories.
The Organizational Process Focus process area helps the organization to plan, implement,
and deploy organizational process improvements based on an understanding of the
current strengths and weaknesses of the organization’s processes and process assets.
Senior Management provides Organization’s business objectives
Process improvement proposals are gathered from Project Management, Support, and
Engineering process areas by participation in defining, assessing, and deploying
processes.
The Organizational Process Focus process area provides these items to the organization
wide:
- Organization’s process needs and objectives
- Resources and coordination
The Organizational Process Definition process area establishes and maintains the
organization’s set of standard processes, work environment standards, and other assets
based on the process needs and objectives of the organization. These other assets
include descriptions of lifecycle models, process tailoring guidelines, and process related
documentation and data.
Projects tailor the organization’s set of standard processes to create their defined
processes. The other assets support tailoring as well as implementation of the defined
processes.
Experiences and work products from performing these defined processes, including
measurement data, process descriptions, process artifacts, and lessons learned, are
incorporated as appropriate into the organization’s set of standard processes and other
assets.

The Organizational Training process area identifies the strategic training needs of the
organization as well as the tactical training needs that are common across projects and
support groups.
Training includes Training for projects and support groups in standard process and
assets
Project Management
Project Management category have 7 process areas:
1. Integrated Project Management (IPM)
2. Project Monitoring and Control (PMC)
3. Project Planning (PP)
4. Quantitative Project Management (QPM)
5. Requirements Management (REQM)
6. Risk Management (RSKM)
7. Supplier Agreement Management (SAM)
Engineering
Engineering category have 5 process areas:
1. Product Integration (PI)
2. Requirements Development (RD)
3. Technical Solution (TS)
4. Validation (VAL)
5. Verification (VER)
Support
Support category have 5 process areas:
1. Causal Analysis and Resolution (CAR)
2. Configuration Management (CM)
3. Decision Analysis and Resolution (DAR)
4. Measurement and Analysis (MA)
5. Process and Product Quality Assurance (PPQA)

Introduction to CMMI

Recomendados

Recomendados

Más contenido relacionado

Similar a Introduction to CMMI

Similar a Introduction to CMMI (20)

Último

Último (20)

Introduction to CMMI