Capability Maturity Model Integration

Last updated

Capability Maturity Model Integration (CMMI) is a process level improvement training and appraisal program. Administered by the CMMI Institute, a subsidiary of ISACA, it was developed at Carnegie Mellon University (CMU). It is required by many U.S. Government contracts, especially in software development. CMU claims CMMI can be used to guide process improvement across a project, division, or an entire organization.

Contents

CMMI defines the following five maturity levels (1 to 5) for processes: Initial, Managed, Defined, Quantitatively Managed, and Optimizing. CMMI Version 3.0 was published in 2023; [1] Version 2.0 was published in 2018; Version 1.3 was published in 2010, and is the reference model for the rest of the information in this article. CMMI is registered in the U.S. Patent and Trademark Office by CMU. [2]

Overview

Characteristics of the maturity levels. Characteristics of Capability Maturity Model.svg
Characteristics of the maturity levels.

Originally CMMI addresses three areas of interest:

  1. Product and service development – CMMI for Development (CMMI-DEV),
  2. Service establishment, management, – CMMI for Services (CMMI-SVC), and
  3. Product and service acquisition – CMMI for Acquisition (CMMI-ACQ).

In version 2.0 these three areas (that previously had a separate model each) were merged into a single model.

CMMI was developed by a group from industry, government, and the Software Engineering Institute (SEI) at CMU. CMMI models provide guidance for developing or improving processes that meet the business goals of an organization. A CMMI model may also be used as a framework for appraising the process maturity of the organization. [3] By January 2013, the entire CMMI product suite was transferred from the SEI to the CMMI Institute, a newly created organization at Carnegie Mellon. [4]

History

CMMI was developed by the CMMI project, which aimed to improve the usability of maturity models by integrating many different models into one framework. The project consisted of members of industry, government and the Carnegie Mellon Software Engineering Institute (SEI). The main sponsors included the Office of the Secretary of Defense (OSD) and the National Defense Industrial Association.

CMMI is the successor of the capability maturity model (CMM) or Software CMM. The CMM was developed from 1987 until 1997. In 2002, version 1.1 was released, version 1.2 followed in August 2006, and version 1.3 in November 2010. Some major changes in CMMI V1.3 [5] are the support of agile software development, [6] improvements to high maturity practices [7] and alignment of the representation (staged and continuous). [8]

According to the Software Engineering Institute (SEI, 2008), CMMI helps "integrate traditionally separate organizational functions, set process improvement goals and priorities, provide guidance for quality processes, and provide a point of reference for appraising current processes." [9]

Mary Beth Chrissis, Mike Konrad, and Sandy Shrum Rawdon were the authorship team for the hard copy publication of CMMI for Development Version 1.2 and 1.3. The Addison-Wesley publication of Version 1.3 was dedicated to the memory of Watts Humphry. Eileen C. Forrester, Brandon L. Buteau, and Sandy Shrum were the authorship team for the hard copy publication of CMMI for Services Version 1.3. Rawdon "Rusty" Young was the chief architect for the development of CMMI version 2.0. He was previously the CMMI Product Owner and the SCAMPI Quality Lead for the Software Engineering Institute.

In March 2016, the CMMI Institute was acquired by ISACA.

In April 2023, the CMMI V3.0 was released.

Topics

Representation

In version 1.3 CMMI existed in two representations: continuous and staged. [3] The continuous representation is designed to allow the user to focus on the specific processes that are considered important for the organization's immediate business objectives, or those to which the organization assigns a high degree of risks. The staged representation is designed to provide a standard sequence of improvements, and can serve as a basis for comparing the maturity of different projects and organizations. The staged representation also provides for an easy migration from the SW-CMM to CMMI. [3]

In version 2.0 the above representation separation was cancelled and there is now only one cohesive model. [10]

Model framework (v1.3)

Depending on the areas of interest (acquisition, services, development) used, the process areas it contains will vary. [11] Process areas are the areas that will be covered by the organization's processes. The table below lists the seventeen CMMI core process areas that are present for all CMMI areas of interest in version 1.3.

Capability Maturity Model Integration (CMMI) core process areas
AbbreviationProcess AreaCategoryMaturity level
CARCausal Analysis and ResolutionSupport5
CMConfiguration ManagementSupport2
DARDecision Analysis and ResolutionSupport3
IPMIntegrated Project ManagementProject Management3
MAMeasurement and AnalysisSupport2
OPDOrganizational Process DefinitionProcess Management3
OPFOrganizational Process FocusProcess Management3
OPMOrganizational Performance ManagementProcess Management5
OPPOrganizational Process PerformanceProcess Management4
OTOrganizational TrainingProcess Management3
PMCProject Monitoring and ControlProject Management2
PPProject PlanningProject Management2
PPQAProcess and Product Quality AssuranceSupport2
QPMQuantitative Project ManagementProject Management4
REQMRequirements ManagementProject Management2
RSKMRisk ManagementProject Management3
SAMSupplier Agreement ManagementSupport2

Maturity levels for services

The process areas below and their maturity levels are listed for the CMMI for services model:

Maturity Level 2 – Managed

Maturity Level 3 – Defined

Maturity Level 4 – Quantitatively Managed

Maturity Level 5 – Optimizing

Models (v1.3)

CMMI best practices are published in documents called models, each of which addresses a different area of interest. Version 1.3 provides models for three areas of interest: development, acquisition, and services.

Model (v2.0)

In version 2.0 DEV, ACQ and SVC were merged into a single model where each process area potentially has a specific reference to one or more of these three aspects. Trying to keep up with the industry the model also has explicit reference to agile aspects in some process areas.

Some key differences between v1.3 and v2.0 models are given below:

  1. "Process Areas" have been replaced with "Practice Areas (PA's)". The latter is arranged by levels, not "Specific Goals".
  2. Each PA is composed of a "core" [i.e. a generic and terminology-free description] and "context-specific" [ i.e. description from the perspective of Agile/ Scrum, development, services, etc.] section.
  3. Since all practices are now compulsory to comply, "Expected" section has been removed.
  4. "Generic Practices" have been put under a new area called "Governance and Implementation Infrastructure", while "Specific practices" have been omitted.
  5. Emphasis on ensuring implementation of PA's and that these are practised continuously until they become a "habit".
  6. All maturity levels focus on the keyword "performance".
  7. Two and five optional PA's from "Safety" and "Security" purview have been included.
  8. PCMM process areas have been merged.

Appraisal

An organization cannot be certified in CMMI; instead, an organization is appraised. Depending on the type of appraisal, the organization can be awarded a maturity level rating (1–5) or a capability level achievement profile.

Many organizations find value in measuring their progress by conducting an appraisal. Appraisals are typically conducted for one or more of the following reasons:

  1. To determine how well the organization's processes compare to CMMI best practices, and to identify areas where improvement can be made
  2. To inform external customers and suppliers of how well the organization's processes compare to CMMI best practices
  3. To meet the contractual requirements of one or more customers

Appraisals of organizations using a CMMI model [12] must conform to the requirements defined in the Appraisal Requirements for CMMI (ARC) document. There are three classes of appraisals, A, B and C, which focus on identifying improvement opportunities and comparing the organization's processes to CMMI best practices. Of these, class A appraisal is the most formal and is the only one that can result in a level rating. Appraisal teams use a CMMI model and ARC-conformant appraisal method to guide their evaluation of the organization and their reporting of conclusions. The appraisal results can then be used (e.g., by a process group) to plan improvements for the organization.

The Standard CMMI Appraisal Method for Process Improvement (SCAMPI) is an appraisal method that meets all of the ARC requirements. [13] Results of a SCAMPI appraisal may be published (if the appraised organization approves) on the CMMI Web site of the SEI: Published SCAMPI Appraisal Results. SCAMPI also supports the conduct of ISO/IEC 15504, also known as SPICE (Software Process Improvement and Capability Determination), assessments etc.

This approach promotes that members of the EPG and PATs be trained in the CMMI, that an informal (SCAMPI C) appraisal be performed, and that process areas be prioritized for improvement. More modern approaches, that involve the deployment of commercially available, CMMI-compliant processes, can significantly reduce the time to achieve compliance. SEI has maintained statistics on the "time to move up" for organizations adopting the earlier Software CMM as well as CMMI. [14] These statistics indicate that, since 1987, the median times to move from Level 1 to Level 2 is 23 months, and from Level 2 to Level 3 is an additional 20 months. Since the release of the CMMI, the median times to move from Level 1 to Level 2 is 5 months, with median movement to Level 3 another 21 months. These statistics are updated and published every six months in a maturity profile.[ citation needed ]

The Software Engineering Institute's (SEI) team software process methodology and the use of CMMI models can be used to raise the maturity level. A new product called Accelerated Improvement Method [15] (AIM) combines the use of CMMI and the TSP. [16]

Security

To address user security concerns, two unofficial security guides are available. Considering the Case for Security Content in CMMI for Services has one process area, Security Management. [17] Security by Design with CMMI for Development, Version 1.3 has the following process areas:

While they do not affect maturity or capability levels, these process areas can be reported in appraisal results. [18]

Applications

The SEI published a study saying 60 organizations measured increases of performance in the categories of cost, schedule, productivity, quality and customer satisfaction. [19] The median increase in performance varied between 14% (customer satisfaction) and 62% (productivity). However, the CMMI model mostly deals with what processes should be implemented, and not so much with how they can be implemented. These results do not guarantee that applying CMMI will increase performance in every organization. A small company with few resources may be less likely to benefit from CMMI; this view is supported by the process maturity profile (page 10). Of the small organizations (<25 employees), 70.5% are assessed at level 2: Managed, while 52.8% of the organizations with 1,001–2,000 employees are rated at the highest level (5: Optimizing).

Turner & Jain (2002) argue that although it is obvious there are large differences between CMMI and agile software development, both approaches have much in common. They believe neither way is the 'right' way to develop software, but that there are phases in a project where one of the two is better suited. They suggest one should combine the different fragments of the methods into a new hybrid method. Sutherland et al. (2007) assert that a combination of Scrum and CMMI brings more adaptability and predictability than either one alone. [20] David J. Anderson (2005) gives hints on how to interpret CMMI in an agile manner. [21]

CMMI Roadmaps, [22] which are a goal-driven approach to selecting and deploying relevant process areas from the CMMI-DEV model, can provide guidance and focus for effective CMMI adoption. There are several CMMI roadmaps for the continuous representation, each with a specific set of improvement goals. Examples are the CMMI Project Roadmap, [23] CMMI Product and Product Integration Roadmaps [24] and the CMMI Process and Measurements Roadmaps. [25] These roadmaps combine the strengths of both the staged and the continuous representations.

The combination of the project management technique earned value management (EVM) with CMMI has been described. [26] To conclude with a similar use of CMMI, Extreme Programming (XP), a software engineering method, has been evaluated with CMM/CMMI (Nawrocki et al., 2002). For example, the XP requirements management approach, which relies on oral communication, was evaluated as not compliant with CMMI.

CMMI can be appraised using two different approaches: staged and continuous. The staged approach yields appraisal results as one of five maturity levels. The continuous approach yields one of four capability levels. The differences in these approaches are felt only in the appraisal; the best practices are equivalent resulting in equivalent process improvement results.

See also

Related Research Articles

The Capability Maturity Model (CMM) is a development model created in 1986 after a study of data collected from organizations that contracted with the U.S. Department of Defense, who funded the research. The term "maturity" relates to the degree of formality and optimization of processes, from ad hoc practices, to formally defined steps, to managed result metrics, to active optimization of the processes.

<span class="mw-page-title-main">Software Engineering Institute</span> Federally funded research center in Pittsburgh, Pennsylvania, United States

Software Engineering Institute (SEI) is a federally funded research and development center in Pittsburgh, Pennsylvania, United States. Founded in 1984, the institute is now sponsored by the United States Department of Defense and the Office of the Under Secretary of Defense for Research and Engineering, and administrated by Carnegie Mellon University. The activities of the institute cover cybersecurity, software assurance, software engineering and acquisition, and component capabilities critical to the United States Department of Defense.

Watts S. Humphrey was an American pioneer in software engineering who was called the "father of software quality."

ISO/IEC 15504Information technology – Process assessment, also termed Software Process Improvement and Capability dEtermination (SPICE), is a set of technical standards documents for the computer software development process and related business management functions. It is one of the joint International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC) standards, which was developed by the ISO and IEC joint subcommittee, ISO/IEC JTC 1/SC 7.

The Personal Software Process (PSP) is a structured software development process that is designed to help software engineers better understand and improve their performance by bringing discipline to the way they develop software and tracking their predicted and actual development of the code. It clearly shows developers how to manage the quality of their products, how to make a sound plan, and how to make commitments. It also offers them the data to justify their plans. They can evaluate their work and suggest improvement direction by analyzing and reviewing development time, defects, and size data. The PSP was created by Watts Humphrey to apply the underlying principles of the Software Engineering Institute's (SEI) Capability Maturity Model (CMM) to the software development practices of a single developer. It claims to give software engineers the process skills necessary to work on a team software process (TSP) team.

Quality management ensures that an organization, product or service consistently functions well. It has four main components: quality planning, quality assurance, quality control and quality improvement. Quality management is focused not only on product and service quality, but also on the means to achieve it. Quality management, therefore, uses quality assurance and control of processes as well as products to achieve more consistent quality. Quality control is also part of quality management. What a customer wants and is willing to pay for it, determines quality. It is a written or unwritten commitment to a known or unknown consumer in the market. Quality can be defined as how well the product performs its intended function.

Microsoft Solutions Framework (MSF) is a set of principles, models, disciplines, concepts, and guidelines for delivering information technology services from Microsoft. MSF is not limited to developing applications only; it is also applicable to other IT projects like deployment, networking or infrastructure projects. MSF does not force the developer to use a specific methodology.

The Capability Maturity Model Integration (CMMI) defines a process area as, "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." Both CMMI for Development v1.3 and CMMI for Acquisition v1.3 identify 22 process areas, whereas CMMI for Services v1.3 identifies 24 process areas. Many of the process areas are the same in these three models.

Capability Immaturity Model (CIMM) in software engineering is a parody acronym, a semi-serious effort to provide a contrast to the Capability Maturity Model (CMM). The Capability Maturity Model is a five point scale of capability in an organization, ranging from random processes at level 1 to fully defined, managed and optimized processes at level 5. The ability of an organization to carry out its mission on time and within budget is claimed to improve as the CMM level increases.

People Capability Maturity Model is a maturity framework that focuses on continuously improving the management and development of the human assets of an organization. It describes an evolutionary improvement path from ad hoc, inconsistently performed practices, to a mature, disciplined, and continuously improving development of the knowledge, skills, and motivation of the workforce that enhances strategic business performance.

A Software Engineering Process Group (SEPG) is an organization's focal point for software process improvement activities. These individuals perform assessments of organizational capability, develop plans to implement needed improvements, coordinate the implementation of those plans, and measure the effectiveness of these efforts. Successful SEPGs require specialized skills and knowledge of many areas outside traditional software engineering.

The Standard CMMI Appraisal Method for Process Improvement (SCAMPI) is the official Software Engineering Institute (SEI) method to provide benchmark-quality ratings relative to Capability Maturity Model Integration (CMMI) models. SCAMPI appraisals are used to identify strengths and weaknesses of current processes, reveal development/acquisition risks, and determine capability and maturity level ratings. They are mostly used either as part of a process improvement program or for rating prospective suppliers. The method defines the appraisal process as consisting of preparation; on-site activities; preliminary observations, findings, and ratings; final reporting; and follow-on activities.

The Trillium Model, created by a collaborative team from Bell Canada, Northern Telecom and Bell Northern Research combines requirements from the ISO 9000 series, the Capability Maturity Model (CMM) for software, and the Baldrige Criteria for Performance Excellence, with software quality standards from the IEEE. Trillium has a telecommunications orientation and provides customer focus. The practices in the Trillium Model are derived from a benchmarking exercise which focused on all practices that would contribute to an organization's product development and support capability. The Trillium Model covers all aspects of the software development life-cycle, most system and product development and support activities, and a significant number of related marketing activities. Many of the practices described in the model can be applied directly to hardware development.

LeanCMMI is an approach to software engineering process improvement that integrates agile computing methods with process design and deployment for organization's wishing to improve software engineering capability and achieve a maturity level two or three rating based upon the Software Engineering Institute's Capability Maturity Model Integration (CMMI).

In combination with the personal software process (PSP), the team software process (TSP) provides a defined operational process framework that is designed to help teams of managers and engineers organize projects and produce software for products that range in size from small projects of several thousand lines of code (KLOC) to very large projects greater than half a million lines of code. The TSP is intended to improve the levels of quality and productivity of a team's software development project, in order to help them better meet the cost and schedule commitments of developing a software system.

A maturity model is a framework for measuring an organization's maturity, or that of a business function within an organization, with maturity being defined as a measurement of the ability of an organization for continuous improvement in a particular discipline. The higher the maturity, the higher will be the chances that incidents or errors will lead to improvements either in the quality or in the use of the resources of the discipline as implemented by the organization.

<span class="mw-page-title-main">Roger R. Bate</span> American academic and United States Air Force general

Roger Redmond Bate was a brigadier general, Rhodes Scholar, professor, and scientist who had held a variety of positions with the Air Force, Texas Instruments, and the Software Engineering Institute at Carnegie Mellon University.

In software engineering, a software development process or software development life cycle (SDLC) is a process of planning and managing software development. It typically involves dividing software development work into smaller, parallel, or sequential steps or sub-processes to improve design and/or product management. The methodology may include the pre-definition of specific deliverables and artifacts that are created and completed by a project team to develop or maintain an application.

Bill Curtis is a software engineer best known for leading the development of the Capability Maturity Model and the People CMM in the Software Engineering Institute at Carnegie Mellon University, and for championing the spread of software process improvement and software measurement globally. In 2007 he was elected a Fellow of the Institute of Electrical and Electronics Engineers (IEEE) for his contributions to software process improvement and measurement. He was named to the 2022 class of ACM Fellows, "for contributions to software process, software measurement, and human factors in software engineering".

<span class="mw-page-title-main">Tudor IT Process Assessment</span> Process assessment framework

Tudor IT Process Assessment (TIPA) is a methodological framework for process assessment. Its first version was published in 2003 by the Public Research Centre Henri Tudor based in Luxembourg. TIPA is now a registered trademark of the Luxembourg Institute of Science and Technology (LIST). TIPA offers a structured approach to determine process capability compared to recognized best practices. TIPA also supports process improvement by providing a gap analysis and proposing improvement recommendations.

References

  1. ↑ "CMMI Content Changes. Release: V3.0, 6 April 2023". CMMI Institute.
  2. ↑ "Trademark Electronic Search System (TESS)". tmsearch.uspto.gov. Retrieved 21 December 2016.
  3. 1 2 3 4 Sally Godfrey (2008) [software.gsfc.nasa.gov/docs/What%20is%20CMMI.ppt What is CMMI ?]. NASA presentation. Accessed 8 December 2008.
  4. ↑ "CMMI Institute - Home".
  5. ↑ "CMMI V1.3: Summing up". Ben Linders. 10 January 2011.
  6. ↑ "CMMI V1.3: Agile". Ben Linders. 20 November 2010.
  7. ↑ "CMMI V1.3 Released: High Maturity Clarified". Ben Linders. 2 November 2010.
  8. ↑ "CMMI V1.3: Deploying the CMMI". Ben Linders. 16 November 2010.
  9. ↑ CMMI Overview. Software Engineering Institute. Accessed 16 February 2011.
  10. ↑ "CMMI Institute - Core Practice Areas, Categories, and Capability Areas". Archived from the original on 16 December 2018. Retrieved 15 December 2018.
  11. ↑ "CMMI V1.3 Process Areas". Ben Linders. 18 September 2023.
  12. ↑ For the latest published CMMI appraisal results see the SEI Web site Archived 6 February 2007 at the Wayback Machine .
  13. ↑ "Standard CMMI Appraisal Method for Process Improvement (SCAMPISM) A, Version 1.2: Method Definition Document". CMU/SEI-2006-HB-002. Software Engineering Institute. 2006. Retrieved 23 September 2006.
  14. ↑ "Process Maturity Profile" . Retrieved 16 February 2011.
  15. ↑ "SEI Digital Library". resources.sei.cmu.edu.
  16. ↑ "TSP Overview". resources.sei.cmu.edu.
  17. ↑ Eileer Forrester and Kieran Doyle. Considering the Case for Security Content in CMMI for Services (October 2010)
  18. ↑ Siemens AG Corporate Technology. Security by Design with CMMI for Development, Version 1.3, (May 2013)
  19. ↑ "CMMI Performance Results of CMMI" . Retrieved 23 September 2006.
  20. ↑ Sutherland, Jeff; Ruseng Jakobsen, Carsten; Johnson, Kent. "Scrum and CMMI Level 5: The Magic Potion for Code Warriors" (PDF). Object Technology Jeff Sutherland.
  21. ↑ Anderson, D. J. (20 July 2005). "Stretching agile to fit CMMI level 3 - the story of creating MSF for CMMI/spl reg/ process improvement at Microsoft corporation". Agile Development Conference (ADC'05). pp. 193–201. doi:10.1109/ADC.2005.42. ISBN   0-7695-2487-7. S2CID   5675994 – via IEEE Xplore.
  22. ↑ "CMMI Roadmaps". resources.sei.cmu.edu.
  23. ↑ "CMMI V1.3: The CMMI Project roadmap". Ben Linders. 7 December 2010.
  24. ↑ "CMMI V1.3: The CMMI Product and Product Integration roadmaps". Ben Linders. 14 December 2010.
  25. ↑ "CMMI V1.3: The CMMI Process and Measurement roadmaps". Ben Linders. 28 December 2010.
  26. ↑ "Using CMMI to Improve Earned Value Management". resources.sei.cmu.edu. Retrieved 30 June 2022.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.