Capability Maturity Model Integration
Capability Maturity Model Integration (CMMI) is a process improvement approach that provides organizations with the essential elements of effective processes.[1] 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 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: [1]. CMMI should be adapted to each individual company, therefore companies are not "certified." A company is appraised (e.g. with an appraisal method like SCAMPI) at a certain level of CMMI. The results of such an appraisal can be published if released by the appraised organization (see SCAMPI Appraisal Results).
Process Areas
The CMMI contains 22 process areas:
History
The CMMI is the successor of CMM, CMM was developed from 1987 until 1997. In 2002 version 1.1 of the CMMI was released: v1.2 followed in August 2006. The goal of the CMMI project is to improve usability of maturity models for software engineering and other disciplines, by integrating many different models into one framework. It was created by members of industry, government and the SEI. The main sponsors included the Office of the Secretary of Defense (OSD) and the National Defense Industrial Association (NDIA) Systems Engineering Committee.[2]
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 ([2]). 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 ([3]). 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: Published SCAMPI Appraisal Results. SCAMPI also supports the conduct of ISO/IEC 15504, also known as SPICE (Software Process Improvement and Capability dEtermination), assessments.
Evaluation
The SEI states that 25 organizations measured increases of performances in the categories cost, schedule, productivity, quality and customer satisfaction.[3] 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 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).
Interestingly, Turner & Jain (2002) argue that although it is obvious there are large differences between CMMI and 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 (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.
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 describes CMMI terminology in more detail. The page numbers refer to the Staged Representation. Common Features are historical artifacts from the software CMM; they do not appear in the CMMI v1.2.
CAPABILITY LEVEL | 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) |
CMMI MODEL | 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) |
CONTINUOUS REPRESENTATION | The CONTINUOUS REPRESENTATION uses capability levels to measure process improvement. (page 20) |
DISCIPLINE AMPLIFICATION | 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) |
GENERIC GOAL | 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) |
GENERIC PRACTICE | 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) |
GENERIC PRACTICE ELABORATIONS | 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) |
GOAL | 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) |
MATURITY LEVEL | 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) |
PROCESS AREA | 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) |
REFERENCE | 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) |
SPECIFIC GOAL | 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) |
SPECIFIC PRACTICES | 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) |
STAGED REPRESENTATION | The STAGED REPRESENTATION uses maturity levels to measure process improvement. (page 20) |
STATEMENT | A STATEMENT is designed to be used for process-improvement and appraisal purposes. (page 7) |
SUBPRACTICE | 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) |
WORK PRODUCT | 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) |
References
- ^ "What is CMMI®?". Retrieved 2006-09-23.
- ^ "History of CMMI". Retrieved 2006-09-23.
- ^ "CMMI® Performance Results, 2005". Retrieved 2006-09-23.
- Members of the Assessment Method Integrated Team. (2001). "Standard CMMI Appraisal Method for Process Improvement (SCAMPISM)" (PDF). Carnegie Mellon University Software Engineering Institute. Retrieved 2006-03-05.
{{cite web}}
: Cite has empty unknown parameters:|accessyear=
and|coauthors=
(help) - Nawrocki, J.R., Jasinski, M., Walter, B., Wojciechowski, A. (2002). "Extreme Programming Modified: Embrace Requirements Engineering Practices". Proceedings of the IEEE Joint International Conference on Requirements Engineering: 3.
{{cite journal}}
: CS1 maint: multiple names: authors list (link) - SEI CMMI Appraisal Program. (2005). "Process Maturity Profile" (PDF). CMMI® v1.1 SCAMPI v1.1 Class A Appraisal Results 2005 Mid-Year Update. Carnegie Mellon University Software Engineering Institute. Retrieved 2006-03-10.
{{cite web}}
: Cite has empty unknown parameters:|accessyear=
and|coauthors=
(help) - SEI CMMI Product Team. (2001). "Appraisal Requirements for CMMISM (ARC)" (PDF). Carnegie Mellon University Software Engineering Institute. Retrieved 2006-03-05.
{{cite web}}
: Cite has empty unknown parameters:|accessyear=
and|coauthors=
(help) - SEI CMMI Product Team. (2002). "CMMI Staged Representation" (DOC). CMMI-SE/SW/IPPD/SS (Version 1.1, March 1, 2002). Carnegie Mellon University Software Engineering Institute. Retrieved 2006-03-10.
{{cite web}}
: Cite has empty unknown parameters:|accessyear=
and|coauthors=
(help) - Software Engineering Institute. (2005). "CMMI® Performance Results". Carnegie Mellon University Software Engineering Institute. Retrieved 2006-03-05.
{{cite web}}
: Cite has empty unknown parameters:|accessyear=
and|coauthors=
(help) - Software Engineering Institute. (2006). "History of CMMI". Carnegie Mellon University Software Engineering Institute. Retrieved 2006-03-05.
{{cite web}}
: Cite has empty unknown parameters:|accessyear=
and|coauthors=
(help) - Solomon, P. (2002). "Using CMMI to Improve Earned Value Management" (PDF). CMU/SEI2002TN016, October. Carnegie Mellon University Software Engineering Institute. Retrieved 2006-03-05.
{{cite web}}
: Cite has empty unknown parameters:|accessyear=
and|coauthors=
(help); soft hyphen character in|work=
at position 8 (help) - Turner, R. & Jain. A. (2002). "Agile Meets CMMI: Culture Clash or Common Cause?". Extreme Programming and Agile Methods – XP/Agile Universe 2002: 153–165. ISBN 3540440240.
See also
- Capability Maturity Model
- Process area (CMMI)
- The SPICE project
- Process improvement
- Software Engineering Institute
- CyberQ Consulting
External links
Examples
Some recent examples of published SCAMPI appraisal results are listed below. The complete list of published SCAMPI appraisal results can be viewed here: SCAMPI Appraisal Results.
- HermeSoftware Technology Inc. Staged Maturity Level 2, in the discipline SE/SW (12/14/2005)
- Zhejiang Hongcheng Computer System Co., Ltd. Staged Maturity Level 2, in the discipline SE/SW (12/10/2005)
- LG Electronics Staged Maturity Level 3, in the discipline SE/SW (12/2/2005)
- Toshiba Solutions Corporation Staged Maturity Level 3, in the discipline SE/SW (12/1/2005)
- Thomas and Herbert Consulting, LLC Staged Maturity Level 3, in the discipline SE/SW (12/1/2005)
Below an example is shown of how one should interpret the CMMI for a specific type of organization.
- Herndon, M.A., Moore, R., Phillips, M., Walker, J., West, L. (2003). "Interpreting Capability Maturity Model® Integration (CMMI®) for Service Organizations - a Systems Engineering and Integration Services Example" (PDF). (CMU/SEI-2003-TN-005) Pittsburgh, PA: Software Engineering Institute. Carnegie Mellon University. Retrieved 2006-03-10.
{{cite web}}
: Cite has empty unknown parameters:|accessyear=
and|coauthors=
(help)CS1 maint: multiple names: authors list (link)
Organizations