Capability Maturity Model Integration: Difference between revisions
m →References: added Guidelines for Process Integration and Product Improvement |
|||
(934 intermediate revisions by more than 100 users not shown) | |||
Line 1: | Line 1: | ||
{{Short description|Process level improvement training and appraisal program}} |
|||
<!--==Description==--> |
|||
{{Redirect|CMMI|the US government organization|Center for Medicare and Medicaid Innovation}} |
|||
'''Capability Maturity Model Integration''' ('''CMMI''') is a [[process improvement]] approach that provides organizations with the essential elements of effective processes.<ref>{{cite web |
|||
{{Use dmy dates|date=December 2019}} |
|||
| title = What is CMMI®? |
|||
{{Software development process}} |
|||
| url = http://www.sei.cmu.edu/cmmi/general/general.html |
|||
'''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. |
|||
| accessdate = 2006-09-23 }} |
|||
</ref> The latest version of CMMI ver 1.2 was released in August 2006. There are 3 constellations of CMMI in the new version, namely:- CMMI Development, CMMI Services and CMMI Acquisition. |
|||
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;<ref>{{cite web |title=CMMI Content Changes. Release: V3.0, 6 April 2023. |url=https://cmmiinstitute.com/getattachment/47a7c84e-472c-4f7f-a473-ddc21c6ae045/attachment.aspx |publisher=CMMI Institute}}</ref> 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.<ref>{{Cite web|url=http://tmsearch.uspto.gov/bin/showfield?f=doc&state=4803:4i4pt6.2.7|title=Trademark Electronic Search System (TESS)|website=tmsearch.uspto.gov|access-date=21 December 2016}}</ref> |
|||
CMMI for Development Ver 1.2 consists of 22 process areas with Capability or Maturity levels. CMMI is created by the [[Software Engineering Institute]] and is available on: [http://www.sei.cmu.edu/cmmi/models/]. CMMI should be adapted to each individual company, therefore companies are not "certified." A company is appraised (e.g. with an appraisal method like [[Standard CMMI Appraisal Method for Process Improvement|SCAMPI]]) at a certain level of CMMI. The results of such an appraisal can be published if released by the appraised organization (see [http://seir.sei.cmu.edu/pars/pars_list_iframe.asp SCAMPI Appraisal Results]). |
|||
[[Image:Cmmi_logo_small.png|frame|Figure 1: CMMI Logo]] |
|||
== |
==Overview== |
||
[[Image:Characteristics of Capability Maturity Model.svg|thumb|500px|Characteristics of the maturity levels.<ref name="Go08">Sally Godfrey (2008) [software.gsfc.nasa.gov/docs/What%20is%20CMMI.ppt What is CMMI ?]. NASA presentation. Accessed 8 December 2008.</ref>]] |
|||
The CMMI contains 22 [[Process area (CMMI)|process areas]]: |
|||
Originally CMMI addresses three areas of interest: |
|||
<table style="valign:top;"> |
|||
<tr> |
|||
#Product and service development – CMMI for Development (CMMI-DEV), |
|||
<td> |
|||
#Service establishment, management, – CMMI for Services (CMMI-SVC), and |
|||
*[[CMMI Causal Analysis and Resolution]] |
|||
#Product and service acquisition – CMMI for Acquisition (CMMI-ACQ). |
|||
*[[CMMI Configuration Management]] |
|||
*[[CMMI Decision Analysis and Resolution]] |
|||
In version 2.0 these three areas (that previously had a separate model each) were merged into a single model. |
|||
*[[CMMI Integrated Project Management]] |
|||
*[[CMMI Measurement and Analysis]] |
|||
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.<ref name="Go08" /> By January 2013, the entire CMMI product suite was transferred from the SEI to the CMMI Institute, a newly created organization at Carnegie Mellon.<ref>{{Cite web|url=http://www.sei.cmu.edu/cmmi/|title=CMMI Institute - Home}}</ref> |
|||
*[[CMMI Organizational Innovation and Deployment]] |
|||
*[[CMMI Organizational Process Definition]] |
|||
*[[CMMI Organizational Process Focus]] |
|||
*[[CMMI Organizational Process Performance]] |
|||
*[[CMMI Organizational Training]] |
|||
</td> |
|||
<td> |
|||
*[[CMMI Product Integration]] |
|||
*[[CMMI Project Monitoring and Control]] |
|||
*[[CMMI Project Planning]] |
|||
*[[CMMI Process and Product Quality Assurance]] |
|||
*[[CMMI Quantitative Project Management]] |
|||
*[[CMMI Requirements Development]] |
|||
*[[CMMI Requirements Management]] |
|||
*[[CMMI Risk Management]] |
|||
*[[CMMI Supplier Agreement Management]] |
|||
*[[CMMI Technical Solution]] |
|||
*[[CMMI Validation]] |
|||
*[[CMMI Verification]] |
|||
</td> |
|||
</tr> |
|||
</table> |
|||
==History== |
==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 ([[Office of the Secretary of Defense|OSD]]) and the [[National Defense Industrial Association]]. |
|||
| title = History of CMMI |
|||
| url = http://www.sei.cmu.edu/cmmi/faq/his-faq.html |
|||
| accessdate = 2006-09-23 }} |
|||
</ref> |
|||
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 <ref>{{Cite web|url=https://www.benlinders.com/2011/cmmi-v1-3-summing-up/|title=CMMI V1.3: Summing up|date=10 January 2011|website=Ben Linders}}</ref> are the support of [[agile software development]],<ref>{{Cite web|url=https://www.benlinders.com/2010/cmmi-v1-3-agile/|title=CMMI V1.3: Agile|date=20 November 2010|website=Ben Linders}}</ref> improvements to high maturity practices<ref>{{Cite web|url=https://www.benlinders.com/2010/cmmi-v1-3-released-high-maturity-clarified/|title=CMMI V1.3 Released: High Maturity Clarified|date=2 November 2010|website=Ben Linders}}</ref> and alignment of the representation (staged and continuous).<ref>{{Cite web|url=https://www.benlinders.com/2010/cmmi-v1-3-deploying-the-cmmi/|title=CMMI V1.3: Deploying the CMMI|date=16 November 2010|website=Ben Linders}}</ref> |
|||
==Appraisal== |
|||
There are three different types of appraisals, type A, B and C. In Appraisal Requirements for CMMI (ARC) the requirements for CMMI appraisal methods are described ([http://www.sei.cmu.edu/publications/documents/06.reports/06tr011.html]). The [[Standard CMMI Appraisal Method for Process Improvement]] (SCAMPI) is the only appraisal method which meets all of the ARC requirements for a Class A appraisal method ([http://www.sei.cmu.edu/publications/documents/06.reports/06hb002.html]). An appraisal team and questionnaire are obligatory when conducting a class A appraisal (in class B and C these are optional). Class A appraisals are more formal and can therefore also be used for marketing purposes. The results of the appraisal are published (if the concerning company approves) on the website of the SEI: [http://seir.sei.cmu.edu/pars/pars_list_iframe.asp Published SCAMPI Appraisal Results]. SCAMPI also supports the conduct of [[ISO 15504|ISO/IEC 15504]], also known as SPICE (Software Process Improvement and Capability dEtermination), assessments. |
|||
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."<ref name=SEI08>[http://www.sei.cmu.edu/cmmi/ CMMI Overview]. Software Engineering Institute. Accessed 16 February 2011.</ref> |
|||
==Evaluation== |
|||
The SEI states that 25 organizations measured increases of performances in the categories cost, schedule, productivity, quality and customer satisfaction.<ref>{{cite web |
|||
| title = CMMI® Performance Results, 2005 |
|||
| url = http://www.sei.cmu.edu/cmmi/results.html |
|||
| accessdate = 2006-09-23 }} |
|||
</ref> 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. SEI thus also mentions that 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 [http://www.sei.cmu.edu/appraisal-program/profile/pdf/CMMI/2005sepCMMI.pdf Process Maturity Profile] (page 10). Of the small organizations (<25 employees) 70.5% is assessed at level 2: Managed, while 52.8% of the organizations with 1001–2000 employees are rated at the highest level (5: Optimizing). |
|||
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. |
|||
Interestingly, Turner & Jain (2002) argue that although it is obvious there are large differences between CMMI and [[Agile software development|agile methods]], 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. The combination of the project management technique [[Earned value management]] (EVM) with CMMI has been described (Solomon, 2002). To conclude with a similar use of CMMI, Extreme Programming ([[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. |
|||
In March 2016, the CMMI Institute was acquired by [[ISACA]]. |
|||
==Structure== |
|||
The CMMI comes with two different representations - staged and continuous. The staged model, which groups process areas into 5 ''maturity'' levels, was also used in the ancestor software development CMM, and is the representation used to achieve a "CMMI Level Rating" from a SCAMPI appraisal. The continuous representation, which was used in the ancestor systems engineering CMM, defines ''capability'' levels within each profile. The differences in the representations are solely organizational; the content is equivalent. |
|||
The CMMI uses a common structure to describe each of the 25 process areas (PAs). A process area has 1 to 4 ''goals'', and each goal is comprised of ''practices''. Within the 22 PAs these are called ''specific'' goals and practices, as they describe activities that are specific to a single PA. There is one additional set of goals and practies that apply in common across all of the PAs; these are called ''generic'' goals and practices. [[#table 1|Table 1]] describes CMMI terminology in more detail. The page numbers refer to the [http://www.sei.cmu.edu/cmmi/models/ss-staged-v1.1.doc Staged Representation]. ''Common Features'' are historical artifacts from the software CMM; they do not appear in the CMMI v1.2. |
|||
In April 2023, the CMMI V3.0 was released. |
|||
<table style="float:left; width:100%;" class="wikitable" id="table_1"><caption> |
|||
Table 1: CMMI concept definition list |
|||
</caption> |
|||
<tr> |
|||
<td bgcolor="#e6e6e6"><center>'''Concept''' </center></td> |
|||
<td bgcolor="#e6e6e6"><center>'''Definition (source)''' </center></td> |
|||
</tr> |
|||
<tr> |
|||
<td>CAPABILITY LEVEL</td> |
|||
<td>CAPABILITY LEVELS, which belong to the continuous representation, apply to an organization’s process-improvement achievement for each process area. There are six capability levels, numbered 0 through 5. Each capability level corresponds to a generic goal and a set of generic and specific practices. (page 20)</td> |
|||
</tr> |
|||
<tr> |
|||
<td>CMMI MODEL</td> |
|||
<td>Since the CMMI Framework can generate different models based on the needs of the organization using it, there are multiple CMMI models. Consequently, the phrase “CMMI MODEL” could be any one of many collections of information. The phrase “CMMI models” refers to one, some, or the entire collection of possible models that can be generated from the CMMI Framework. (page 29)</td> |
|||
</tr> |
|||
<tr> |
|||
<td>CONTINUOUS REPRESENTATION</td> |
|||
<td>The CONTINUOUS REPRESENTATION uses capability levels to measure process improvement. (page 20)</td> |
|||
</tr> |
|||
<tr> |
|||
<td>DISCIPLINE AMPLIFICATION</td> |
|||
<td>Model components that provide guidance for interpreting model information for specific disciplines (e.g., systems engineering, or software engineering) are called “DISCIPLINE AMPLIFICATIONS.” Discipline amplifications are added to other model components where necessary. These are easy to locate because they appear on the right side of the page and have a title indicating the discipline that they address (for example, “For Software Engineering”). (page 8)</td> |
|||
</tr> |
|||
<tr> |
|||
<td>GENERIC GOAL</td> |
|||
<td>GENERIC GOALS are called “generic” because the same goal statement appears in multiple process areas. In the staged representation, each process area has only one generic goal. Achievement of a generic goal in a process area signifies improved control in planning and implementing the processes associated with that process area, thus indicating whether these processes are likely to be effective, repeatable, and lasting. Generic goals are required model components and are used in appraisals to determine whether a process area is satisfied. (page 19) </td> |
|||
</tr> |
|||
<tr> |
|||
<td>GENERIC PRACTICE</td> |
|||
<td>GENERIC PRACTICES provide institutionalization to ensure that the processes associated with the process area will be effective, repeatable, and lasting. Generic practices are categorized by generic goals and common features and are expected components in CMMI models. (Only the generic practice title, statement, and elaborations appear in the process areas.) (page 19) </td> |
|||
</tr> |
|||
<tr> |
|||
<td>GENERIC PRACTICE ELABORATIONS</td> |
|||
<td>After the specific practices, the generic practice titles and statements appear that apply to the process area. After each generic practice statement, an elaboration may appear in plain text with the heading “Elaboration.” The GENERIC PRACTICE ELABORATION provides information about how the generic practice should be interpreted for the process area. If there is no elaboration present, the application of the generic practice is obvious without an elaboration. (page 7)</td> |
|||
</tr> |
|||
<tr> |
|||
<td>GOAL</td> |
|||
<td>A “GOAL” is a required CMMI component that can be either a generic goal or a specific goal. When you see the word “goal” in a CMMI model, it always refers to model components (for example, generic goal, specific goal). (page 27)</td> |
|||
</tr> |
|||
<tr> |
|||
<td>MATURITY LEVEL</td> |
|||
<td>A MATURITY LEVEL is a defined evolutionary plateau of process improvement. Each maturity level stabilizes an important part of the organization’s processes. Maturity levels, which belong to the staged representation, apply to an organization’s overall maturity. There are five maturity levels, numbered 1 through 5. Each maturity level comprises a predefined set of process areas. (page 21)</td> |
|||
</tr> |
|||
<tr> |
|||
<td>PROCESS AREA </td> |
|||
<td>A PROCESS AREA is a cluster of related practices in an area that, when performed collectively, satisfy a set of goals considered important for making significant improvement in that area. All CMMI process areas are common to both continuous and staged representations. In the staged representation, process areas are organized by maturity levels. (page 17)</td> |
|||
</tr> |
|||
<tr> |
|||
<td>REFERENCE</td> |
|||
<td>REFERENCES are informative model components that direct the user to additional or more detailed information in related process areas. Typical phrases expressing these pointers are “Refer to the Organizational Training process area for more information about identifying training needs and providing the necessary training” or “Refer to the Decision Analysis and Resolution process area for more information about evaluating and selecting among alternatives.” All references are clearly marked in italics. (page 19) </td> |
|||
</tr> |
|||
<tr> |
|||
<td>SPECIFIC GOAL </td> |
|||
<td>SPECIFIC GOALS apply to a process area and address the unique characteristics that describe what must be implemented to satisfy the process area. Specific goals are required model components and are used in appraisals to help determine whether a process area is satisfied. (page 17) </td> |
|||
</tr> |
|||
<tr> |
|||
<td>SPECIFIC PRACTICES </td> |
|||
<td>A SPECIFIC PRACTICE is an activity that is considered important in achieving the associated specific goal. The specific practices describe the activities expected to result in achievement of the specific goals of a process area. Specific practices are expected model components. (page 17) </td> |
|||
</tr> |
|||
<tr> |
|||
<td>STAGED REPRESENTATION</td> |
|||
<td>The STAGED REPRESENTATION uses maturity levels to measure process improvement. (page 20)</td> |
|||
</tr> |
|||
<tr> |
|||
<td>STATEMENT</td> |
|||
<td>A STATEMENT is designed to be used for process-improvement and appraisal purposes. (page 7) </td> |
|||
</tr> |
|||
<tr> |
|||
<td>SUBPRACTICE</td> |
|||
<td>SUBPRACTICES are detailed descriptions that provide guidance for interpreting specific or generic practices. Subpractices may be worded as if prescriptive, but are actually an informative component in CMMI models meant only to provide ideas that may be useful for process improvement. (page 18) </td> |
|||
</tr> |
|||
<tr> |
|||
<td>WORK PRODUCT</td> |
|||
<td>The term WORK PRODUCT is used throughout the CMMI Product Suite to mean any artifact produced by a process. These artifacts can include files, documents, parts of the product, services, processes, specifications, and invoices. Examples of processes to be considered as work products include a manufacturing process, a training process, and a disposal process for the product. A key distinction between a WORK PRODUCT and a product component is that a work product need not be engineered or part of the end product. (page 25)</td> |
|||
</tr> |
|||
</table> |
|||
==Topics== |
|||
<div style="float:left; width:100%"> |
|||
==References== |
|||
<references/> |
|||
===Representation=== |
|||
*{{cite book |
|||
In version 1.3 CMMI existed in two representations: continuous and staged.<ref name=Go08/> 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.<ref name=Go08 /> |
|||
| last = Chrissis |
|||
| first = Mary Beth |
|||
| authorlink = |
|||
| coauthors = Konrad, Mike, Shrum, Sandy |
|||
| title = CMMI : Guidelines for Process Integration and Product Improvement |
|||
| publisher = Addison-Wesley Professional |
|||
| date = 2003 |
|||
| location = |
|||
| pages = |
|||
| url = |
|||
| doi = |
|||
| id = ISBN 0321154967 }} |
|||
In version 2.0 the above representation separation was cancelled and there is now only one cohesive model.<ref>{{Cite web |url=https://www.cmmiinstitute.com/cmmi/model-viewer/appendices/a |title=CMMI Institute - Core Practice Areas, Categories, and Capability Areas |access-date=15 December 2018 |archive-date=16 December 2018 |archive-url=https://web.archive.org/web/20181216031208/https://www.cmmiinstitute.com/cmmi/model-viewer/appendices/a |url-status=dead }}</ref> |
|||
*{{cite web |
|||
| last = Members of the Assessment Method Integrated Team. |
|||
| first = |
|||
| authorlink = |
|||
| coauthors = |
|||
| year = 2001 |
|||
| url =http://www.sei.cmu.edu/publications/documents/01.reports/01hb001.html |
|||
| title =Standard CMMI Appraisal Method for Process Improvement (SCAMPISM) |
|||
| format = PDF |
|||
| work = |
|||
| publisher =Carnegie Mellon University Software Engineering Institute |
|||
| accessdate = 2006-03-05 |
|||
| accessyear = |
|||
}} |
|||
*{{cite journal |
|||
| author=Nawrocki, J.R., Jasinski, M., Walter, B., Wojciechowski, A. |
|||
| title=Extreme Programming Modified: Embrace Requirements Engineering Practices |
|||
| journal=Proceedings of the IEEE Joint International Conference on Requirements Engineering |
|||
| year=2002 |
|||
| volume= |
|||
| issue= |
|||
| pages=3 |
|||
| url= |
|||
}} |
|||
*{{cite web |
|||
| last = SEI CMMI Appraisal Program. |
|||
| first = |
|||
| authorlink = |
|||
| coauthors = |
|||
| year = 2005 |
|||
| url = http://www.sei.cmu.edu/appraisal-program/profile/pdf/CMMI/2005sepCMMI.pdf |
|||
| title = Process Maturity Profile |
|||
| format = PDF |
|||
| work = CMMI® v1.1 SCAMPI v1.1 Class A Appraisal Results 2005 Mid-Year Update |
|||
| publisher = Carnegie Mellon University Software Engineering Institute |
|||
| accessdate = 2006-03-10 |
|||
| accessyear = |
|||
}} |
|||
*{{cite web |
|||
| last = SEI CMMI Product Team. |
|||
| first = |
|||
| authorlink = |
|||
| coauthors = |
|||
| year = 2001 |
|||
| url =http://www.sei.cmu.edu/publications/documents/01.reports/01tr034.html |
|||
| title =Appraisal Requirements for CMMISM (ARC) |
|||
| format = PDF |
|||
| work = |
|||
| publisher =Carnegie Mellon University Software Engineering Institute |
|||
| accessdate = 2006-03-05 |
|||
| accessyear = |
|||
}} |
|||
*{{cite web |
|||
| last = SEI CMMI Product Team. |
|||
| first = |
|||
| authorlink = |
|||
| coauthors = |
|||
| year = 2002 |
|||
| url = http://www.sei.cmu.edu/cmmi/models/ss-staged-v1.1.doc |
|||
| title = CMMI Staged Representation |
|||
| format = DOC |
|||
| work = CMMI-SE/SW/IPPD/SS (Version 1.1, March 1, 2002) |
|||
| publisher = Carnegie Mellon University Software Engineering Institute |
|||
| accessdate = 2006-03-10 |
|||
| accessyear = |
|||
}} |
|||
*{{cite web |
|||
| last =Software Engineering Institute. |
|||
| first = |
|||
| authorlink = |
|||
| coauthors = |
|||
| year = 2005 |
|||
| url = http://www.sei.cmu.edu/cmmi/results.html |
|||
| title = CMMI® Performance Results |
|||
| format = |
|||
| work = |
|||
| publisher =Carnegie Mellon University Software Engineering Institute |
|||
| accessdate = 2006-03-05 |
|||
| accessyear = |
|||
}} |
|||
*{{cite web |
|||
| last =Software Engineering Institute. |
|||
| first = |
|||
| authorlink = |
|||
| coauthors = |
|||
| year = 2006 |
|||
| url = http://www.sei.cmu.edu/cmmi/faq/his-faq.html |
|||
| title = History of CMMI |
|||
| format = |
|||
| work = |
|||
| publisher =Carnegie Mellon University Software Engineering Institute |
|||
| accessdate = 2006-03-05 |
|||
| accessyear = |
|||
}} |
|||
*{{cite web |
|||
| last = Solomon |
|||
| first = P. |
|||
| authorlink = |
|||
| coauthors = |
|||
| year = 2002 |
|||
| url = http://www.sei.cmu.edu/pub/documents/02.reports/pdf/02tn016.pdf |
|||
| title = Using CMMI to Improve Earned Value Management |
|||
| format = PDF |
|||
| work = CMU/SEI2002TN016, October |
|||
| publisher = Carnegie Mellon University Software Engineering Institute |
|||
| accessdate = 2006-03-05 |
|||
| accessyear = |
|||
}} |
|||
*{{cite journal |
|||
| author=Turner, R. & Jain. A. |
|||
| title=Agile Meets CMMI: Culture Clash or Common Cause? |
|||
| journal=Extreme Programming and Agile Methods – XP/Agile Universe 2002 |
|||
| year=2002 |
|||
| volume= |
|||
| issue= |
|||
| pages=153–165 |
|||
| url= |
|||
| id=ISBN 3540440240 |
|||
}} |
|||
===Model framework (v1.3)=== |
|||
==See also== |
|||
<!-- (NB: this section moved from CMM, where it was irrelevant. It requires checking for relevance here in CMMI.) --> |
|||
*[[Capability Maturity Model]] |
|||
{{further|Process area (CMMI)}} |
|||
*[[The SPICE project]] |
|||
*[[Process improvement]] |
|||
*[[Software Engineering Institute]] |
|||
*[[CyberQ Consulting]] |
|||
Depending on the areas of interest (acquisition, services, development) used, the [[process area]]s it contains will vary.<ref>{{Cite web|url=https://www.benlinders.com/tools/cmmi-v1-3-process-areas/|title=CMMI V1.3 Process Areas|website=Ben Linders|date=18 September 2023 }}</ref> [[Process area (CMMI)|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. |
|||
==External links== |
|||
'''Examples'''<br /> |
|||
Some recent examples of published SCAMPI appraisal results are listed below. The complete list of published SCAMPI appraisal results can be viewed here: [http://seir.sei.cmu.edu/pars/pars_list_iframe.asp SCAMPI Appraisal Results]. |
|||
{| class="wikitable sortable" |
|||
*[http://seir.sei.cmu.edu/pars/pars_display.asp?i=1053 HermeSoftware Technology Inc.] Staged Maturity Level 2, in the discipline SE/SW (12/14/2005) |
|||
|+ Capability Maturity Model Integration (CMMI) core process areas |
|||
*[http://seir.sei.cmu.edu/pars/pars_display.asp?i=1052 Zhejiang Hongcheng Computer System Co., Ltd.] Staged Maturity Level 2, in the discipline SE/SW (12/10/2005) |
|||
*[http://seir.sei.cmu.edu/pars/pars_display.asp?i=1051 LG Electronics] Staged Maturity Level 3, in the discipline SE/SW (12/2/2005) |
|||
*[http://seir.sei.cmu.edu/pars/pars_display.asp?i=1054 Toshiba Solutions Corporation] Staged Maturity Level 3, in the discipline SE/SW (12/1/2005) |
|||
*[http://seir.sei.cmu.edu/pars/pars_display.asp?i=1018 Thomas and Herbert Consulting, LLC] Staged Maturity Level 3, in the discipline SE/SW (12/1/2005) |
|||
! Abbreviation !! Process Area !! Category !! Maturity level |
|||
Below an example is shown of how one should interpret the CMMI for a specific type of organization. |
|||
|- |
|||
*{{cite web |
|||
| CAR || Causal Analysis and Resolution || Support || style="text-align:center;"| 5 |
|||
| last = Herndon, M.A., Moore, R., Phillips, M., Walker, J., West, L. |
|||
|- |
|||
| first = |
|||
| CM || Configuration Management || Support || style="text-align:center;"| 2 |
|||
| authorlink = |
|||
|- |
|||
| coauthors = |
|||
| DAR || Decision Analysis and Resolution || Support || style="text-align:center;"| 3 |
|||
| year = 2003 |
|||
|- |
|||
| url = http://www.sei.cmu.edu/pub/documents/03.reports/pdf/03tn005.pdf |
|||
| IPM || Integrated Project Management || Project Management || style="text-align:center;"| 3 |
|||
| title = Interpreting Capability Maturity Model® Integration (CMMI®) for Service Organizations - a Systems Engineering and Integration Services Example |
|||
|- |
|||
| format = PDF |
|||
| MA || Measurement and Analysis || Support || style="text-align:center;"| 2 |
|||
| work = (CMU/SEI-2003-TN-005) Pittsburgh, PA: Software Engineering Institute |
|||
|- |
|||
| publisher = Carnegie Mellon University |
|||
| OPD || Organizational Process Definition || Process Management || style="text-align:center;"| 3 |
|||
| accessdate = 2006-03-10 |
|||
|- |
|||
| accessyear = |
|||
| OPF || Organizational Process Focus || Process Management || style="text-align:center;"| 3 |
|||
}} |
|||
|- |
|||
| OPM || Organizational Performance Management || Process Management || style="text-align:center;"| 5 |
|||
|- |
|||
| OPP || Organizational Process Performance || Process Management || style="text-align:center;"| 4 |
|||
|- |
|||
| OT || Organizational Training || Process Management || style="text-align:center;"| 3 |
|||
|- |
|||
| PMC || Project Monitoring and Control || Project Management || style="text-align:center;"| 2 |
|||
|- |
|||
| PP || Project Planning || Project Management || style="text-align:center;"| 2 |
|||
|- |
|||
| PPQA || Process and Product Quality Assurance || Support || style="text-align:center;"| 2 |
|||
|- |
|||
| QPM || Quantitative Project Management || Project Management || style="text-align:center;"| 4 |
|||
|- |
|||
| REQM || Requirements Management || Project Management || style="text-align:center;"| 2 |
|||
|- |
|||
| RSKM || Risk Management || Project Management || style="text-align:center;"| 3 |
|||
|- |
|||
| SAM || Supplier Agreement Management || Support || style="text-align:center;"| 2 |
|||
|} |
|||
=== Maturity levels for services === |
|||
'''Organizations'''<br /> |
|||
The process areas below and their maturity levels are listed for the CMMI for services model: |
|||
*[http://www.ndia.org/ NDIA] National Defense Industrial Association |
|||
*[http://www.sei.cmu.edu/ SEI] Software Engineering Institute |
|||
'''Maturity Level 2 – Managed''' |
|||
*[http://www.espi.org/ ESPI Foundation] European SEPG |
|||
* CM – Configuration Management |
|||
</div> |
|||
* MA – Measurement and Analysis |
|||
* PPQA – Process and Quality Assurance |
|||
* REQM – Requirements Management |
|||
* SAM – Supplier Agreement Management |
|||
* SD – Service Delivery |
|||
* WMC – Work Monitoring and Control |
|||
* WP – Work Planning |
|||
'''Maturity Level 3 – Defined''' |
|||
* CAM – Capacity and Availability Management |
|||
* DAR – Decision Analysis and Resolution |
|||
* IRP – Incident Resolution and Prevention |
|||
* IWM – Integrated Work Managements |
|||
* OPD – Organizational Process Definition |
|||
* OPF – Organizational Process Focus... |
|||
* OT – Organizational Training |
|||
* RSKM – Risk Management |
|||
* SCON – Service Continuity |
|||
* SSD – Service System Development |
|||
* SST – Service System Transition |
|||
* STSM – Strategic Service Management |
|||
'''Maturity Level 4 – Quantitatively Managed''' |
|||
* OPP – Organizational Process Performance |
|||
* QWM – Quantitative Work Management |
|||
'''Maturity Level 5 – Optimizing''' |
|||
* CAR – Causal Analysis and Resolution. |
|||
* OPM – Organizational Performance Management. |
|||
===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. |
|||
* CMMI for Development (CMMI-DEV), v1.3 was released in November 2010. It addresses product and service development processes. |
|||
* CMMI for Acquisition (CMMI-ACQ), v1.3 was released in November 2010. It addresses supply chain management, acquisition, and outsourcing processes in government and industry. |
|||
* CMMI for Services (CMMI-SVC), v1.3 was released in November 2010. It addresses guidance for delivering services within an organization and to external customers. |
|||
=== 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: |
|||
# "Process Areas" have been replaced with "Practice Areas (PA's)". The latter is arranged by levels, not "Specific Goals". |
|||
# 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. |
|||
# Since all practices are now compulsory to comply, "Expected" section has been removed. |
|||
# "Generic Practices" have been put under a new area called "Governance and Implementation Infrastructure", while "Specific practices" have been omitted. |
|||
# Emphasis on ensuring implementation of PA's and that these are practised continuously until they become a "habit". |
|||
# All maturity levels focus on the keyword "performance". |
|||
# Two and five optional PA's from "Safety" and "Security" purview have been included. |
|||
# 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: |
|||
# To determine how well the organization's processes compare to CMMI best practices, and to identify areas where improvement can be made |
|||
# To inform external customers and suppliers of how well the organization's processes compare to CMMI best practices |
|||
# To meet the contractual requirements of one or more customers |
|||
Appraisals of organizations using a CMMI model<ref>For the latest published CMMI appraisal results see the [http://sas.sei.cmu.edu/pars/ SEI Web site] {{webarchive|url=https://web.archive.org/web/20070206030049/http://sas.sei.cmu.edu/pars/ |date=6 February 2007 }}.</ref> 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.<ref>{{cite web |
|||
|year=2006 |
|||
|work=CMU/SEI-2006-HB-002 |
|||
|publisher=Software Engineering Institute |
|||
|title=Standard CMMI Appraisal Method for Process Improvement (SCAMPISM) A, Version 1.2: Method Definition Document |
|||
|url=http://www.sei.cmu.edu/library/abstracts/reports/06hb002.cfm |
|||
|access-date=23 September 2006}} |
|||
</ref> 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 15504|ISO/IEC 15504]], also known as [[The SPICE project|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.<ref>{{cite web |
|||
|title=Process Maturity Profile |
|||
|url=http://www.sei.cmu.edu/cmmi/casestudies/profiles/cmmi.cfm |
|||
|access-date=16 February 2011}} |
|||
</ref> 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|date=November 2013}} |
|||
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<ref>{{Cite web|url=https://resources.sei.cmu.edu/library/|title=SEI Digital Library|website=resources.sei.cmu.edu|date=9 February 2024 }}</ref> (AIM) combines the use of CMMI and the TSP.<ref>{{Cite web|url=https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=72816|title=TSP Overview|website=resources.sei.cmu.edu|date=13 September 2010 }}</ref> |
|||
=== 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.<ref>Eileer Forrester and Kieran Doyle. Considering the Case for Security Content in CMMI for Services (October 2010)</ref> ''Security by Design with CMMI for Development, Version 1.3'' has the following process areas: |
|||
* OPSD – Organizational Preparedness for Secure Development |
|||
* SMP – Secure Management in Projects |
|||
* SRTS – Security Requirements and Technical Solution |
|||
* SVV – Security Verification and Validation |
|||
While they do not affect maturity or capability levels, these process areas can be reported in appraisal results.<ref>Siemens AG Corporate Technology. ''Security by Design with CMMI for Development, Version 1.3'', (May 2013)</ref> |
|||
==Applications== |
|||
The SEI published a study saying 60 organizations measured increases of performance in the categories of cost, schedule, productivity, quality and customer satisfaction.<ref>{{cite web |
|||
|title=CMMI Performance Results of CMMI |
|||
|url=http://www.sei.cmu.edu/cmmi/research/results/ |
|||
|access-date=23 September 2006}} |
|||
</ref> 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 (software development)|Scrum]] and CMMI brings more adaptability and predictability than either one alone.<ref>{{Cite web |last1=Sutherland |first1=Jeff |last2=Ruseng Jakobsen |first2=Carsten |last3=Johnson |first3=Kent |title=Scrum and CMMI Level 5: The Magic Potion for Code Warriors |url=http://jeffsutherland.com/scrum/SutherlandScrumCMMIHICSSPID498889.pdf |website=Object Technology Jeff Sutherland}}</ref> David J. Anderson (2005) gives hints on how to interpret CMMI in an agile manner.<ref>{{Cite book|chapter=Stretching agile to fit CMMI level 3 - the story of creating MSF for CMMI/spl reg/ process improvement at Microsoft corporation|first=D. J.|last=Anderson|date=20 July 2005|pages=193–201|via=IEEE Xplore|doi=10.1109/ADC.2005.42|title=Agile Development Conference (ADC'05)|isbn=0-7695-2487-7|s2cid=5675994}}</ref> |
|||
CMMI Roadmaps,<ref>{{Cite web|url=https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=8581|title=CMMI Roadmaps|website=resources.sei.cmu.edu|date=31 October 2008 }}</ref> 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,<ref>{{Cite web|url=https://www.benlinders.com/2010/cmmi-v1-3-the-cmmi-project-roadmap/|title=CMMI V1.3: The CMMI Project roadmap|date=7 December 2010|website=Ben Linders}}</ref> CMMI Product and Product Integration Roadmaps<ref>{{Cite web|url=https://www.benlinders.com/2010/cmmi-v1-3-the-cmmi-product-and-product-integration-roadmaps/|title=CMMI V1.3: The CMMI Product and Product Integration roadmaps|date=14 December 2010|website=Ben Linders}}</ref> and the CMMI Process and Measurements Roadmaps.<ref>{{Cite web|url=https://www.benlinders.com/2010/cmmi-v1-3-the-cmmi-process-and-measurement-roadmaps/|title=CMMI V1.3: The CMMI Process and Measurement roadmaps|date=28 December 2010|website=Ben Linders}}</ref> 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.<ref>{{Cite web |title=Using CMMI to Improve Earned Value Management |url=https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=5957 |access-date=2022-06-30 |website=resources.sei.cmu.edu | date=30 September 2002 |language=en}}</ref> To conclude with a similar use of CMMI, Extreme Programming ([[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== |
|||
* [[Capability Immaturity Model]] |
|||
* [[Capability Maturity Model]] |
|||
* [[Enterprise Architecture Assessment Framework]] |
|||
* [[LeanCMMI]] |
|||
* [[People Capability Maturity Model]] |
|||
* [[Software Engineering Process Group]] |
|||
== References == |
|||
{{Reflist}} |
|||
==External links== |
|||
{{Commons category|Capability Maturity Model Integration}} |
|||
* {{official website|http://cmmiinstitute.com/}} |
|||
{{Carnegie Mellon}} |
|||
[[Category:Software engineering]] |
|||
{{Software engineering}} |
|||
{{Authority control}} |
|||
[[Category:Maturity models]] |
|||
[[es:CMMI]] |
|||
[[Category:Software development process]] |
|||
[[sk:CMMI]] |
|||
[[Category:Standards]] |
|||
[[Category:Systems engineering]] |
|||
[[Category:Carnegie Mellon University software]] |
Latest revision as of 04:11, 19 October 2024
Part of a series on |
Software development |
---|
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.
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
[edit]Originally CMMI addresses three areas of interest:
- Product and service development – CMMI for Development (CMMI-DEV),
- Service establishment, management, – CMMI for Services (CMMI-SVC), and
- 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
[edit]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
[edit]Representation
[edit]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)
[edit]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.
Abbreviation | Process Area | Category | Maturity level |
---|---|---|---|
CAR | Causal Analysis and Resolution | Support | 5 |
CM | Configuration Management | Support | 2 |
DAR | Decision Analysis and Resolution | Support | 3 |
IPM | Integrated Project Management | Project Management | 3 |
MA | Measurement and Analysis | Support | 2 |
OPD | Organizational Process Definition | Process Management | 3 |
OPF | Organizational Process Focus | Process Management | 3 |
OPM | Organizational Performance Management | Process Management | 5 |
OPP | Organizational Process Performance | Process Management | 4 |
OT | Organizational Training | Process Management | 3 |
PMC | Project Monitoring and Control | Project Management | 2 |
PP | Project Planning | Project Management | 2 |
PPQA | Process and Product Quality Assurance | Support | 2 |
QPM | Quantitative Project Management | Project Management | 4 |
REQM | Requirements Management | Project Management | 2 |
RSKM | Risk Management | Project Management | 3 |
SAM | Supplier Agreement Management | Support | 2 |
Maturity levels for services
[edit]The process areas below and their maturity levels are listed for the CMMI for services model:
Maturity Level 2 – Managed
- CM – Configuration Management
- MA – Measurement and Analysis
- PPQA – Process and Quality Assurance
- REQM – Requirements Management
- SAM – Supplier Agreement Management
- SD – Service Delivery
- WMC – Work Monitoring and Control
- WP – Work Planning
Maturity Level 3 – Defined
- CAM – Capacity and Availability Management
- DAR – Decision Analysis and Resolution
- IRP – Incident Resolution and Prevention
- IWM – Integrated Work Managements
- OPD – Organizational Process Definition
- OPF – Organizational Process Focus...
- OT – Organizational Training
- RSKM – Risk Management
- SCON – Service Continuity
- SSD – Service System Development
- SST – Service System Transition
- STSM – Strategic Service Management
Maturity Level 4 – Quantitatively Managed
- OPP – Organizational Process Performance
- QWM – Quantitative Work Management
Maturity Level 5 – Optimizing
- CAR – Causal Analysis and Resolution.
- OPM – Organizational Performance Management.
Models (v1.3)
[edit]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.
- CMMI for Development (CMMI-DEV), v1.3 was released in November 2010. It addresses product and service development processes.
- CMMI for Acquisition (CMMI-ACQ), v1.3 was released in November 2010. It addresses supply chain management, acquisition, and outsourcing processes in government and industry.
- CMMI for Services (CMMI-SVC), v1.3 was released in November 2010. It addresses guidance for delivering services within an organization and to external customers.
Model (v2.0)
[edit]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:
- "Process Areas" have been replaced with "Practice Areas (PA's)". The latter is arranged by levels, not "Specific Goals".
- 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.
- Since all practices are now compulsory to comply, "Expected" section has been removed.
- "Generic Practices" have been put under a new area called "Governance and Implementation Infrastructure", while "Specific practices" have been omitted.
- Emphasis on ensuring implementation of PA's and that these are practised continuously until they become a "habit".
- All maturity levels focus on the keyword "performance".
- Two and five optional PA's from "Safety" and "Security" purview have been included.
- PCMM process areas have been merged.
Appraisal
[edit]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:
- To determine how well the organization's processes compare to CMMI best practices, and to identify areas where improvement can be made
- To inform external customers and suppliers of how well the organization's processes compare to CMMI best practices
- 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
[edit]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:
- OPSD – Organizational Preparedness for Secure Development
- SMP – Secure Management in Projects
- SRTS – Security Requirements and Technical Solution
- SVV – Security Verification and Validation
While they do not affect maturity or capability levels, these process areas can be reported in appraisal results.[18]
Applications
[edit]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
[edit]- Capability Immaturity Model
- Capability Maturity Model
- Enterprise Architecture Assessment Framework
- LeanCMMI
- People Capability Maturity Model
- Software Engineering Process Group
References
[edit]- ^ "CMMI Content Changes. Release: V3.0, 6 April 2023". CMMI Institute.
- ^ "Trademark Electronic Search System (TESS)". tmsearch.uspto.gov. Retrieved 21 December 2016.
- ^ a b c d Sally Godfrey (2008) [software.gsfc.nasa.gov/docs/What%20is%20CMMI.ppt What is CMMI ?]. NASA presentation. Accessed 8 December 2008.
- ^ "CMMI Institute - Home".
- ^ "CMMI V1.3: Summing up". Ben Linders. 10 January 2011.
- ^ "CMMI V1.3: Agile". Ben Linders. 20 November 2010.
- ^ "CMMI V1.3 Released: High Maturity Clarified". Ben Linders. 2 November 2010.
- ^ "CMMI V1.3: Deploying the CMMI". Ben Linders. 16 November 2010.
- ^ CMMI Overview. Software Engineering Institute. Accessed 16 February 2011.
- ^ "CMMI Institute - Core Practice Areas, Categories, and Capability Areas". Archived from the original on 16 December 2018. Retrieved 15 December 2018.
- ^ "CMMI V1.3 Process Areas". Ben Linders. 18 September 2023.
- ^ For the latest published CMMI appraisal results see the SEI Web site Archived 6 February 2007 at the Wayback Machine.
- ^ "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.
- ^ "Process Maturity Profile". Retrieved 16 February 2011.
- ^ "SEI Digital Library". resources.sei.cmu.edu. 9 February 2024.
- ^ "TSP Overview". resources.sei.cmu.edu. 13 September 2010.
- ^ Eileer Forrester and Kieran Doyle. Considering the Case for Security Content in CMMI for Services (October 2010)
- ^ Siemens AG Corporate Technology. Security by Design with CMMI for Development, Version 1.3, (May 2013)
- ^ "CMMI Performance Results of CMMI". Retrieved 23 September 2006.
- ^ Sutherland, Jeff; Ruseng Jakobsen, Carsten; Johnson, Kent. "Scrum and CMMI Level 5: The Magic Potion for Code Warriors" (PDF). Object Technology Jeff Sutherland.
- ^ 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.
- ^ "CMMI Roadmaps". resources.sei.cmu.edu. 31 October 2008.
- ^ "CMMI V1.3: The CMMI Project roadmap". Ben Linders. 7 December 2010.
- ^ "CMMI V1.3: The CMMI Product and Product Integration roadmaps". Ben Linders. 14 December 2010.
- ^ "CMMI V1.3: The CMMI Process and Measurement roadmaps". Ben Linders. 28 December 2010.
- ^ "Using CMMI to Improve Earned Value Management". resources.sei.cmu.edu. 30 September 2002. Retrieved 30 June 2022.