Capability Maturity Model Integration

from Wikipedia, the free encyclopedia

The Capability Maturity Model Integration ( CMMI ) is a family of reference models for different areas of application - currently for product development, product purchasing and service provision. A CMMI model is a systematic preparation of best practices to support the improvement of an organization. A CMMI model can be used to

  • get an overview of best practices (e.g. in project planning ),
  • to objectively analyze the strengths and weaknesses of an organization or
  • Determine improvement measures and put them in a meaningful order.

The CMMI models are primarily a means to improve the work of an organization. Secondly, official reviews of a maturity level (see appraisal ) are a de facto recognized award in the industry. CMMI is therefore often referred to as the maturity level model, although the maturity levels are only one aspect among many of CMMI.

All CMMI models (called "Constellation") have the same structure and a common core content. There are currently three published CMMI models:

  • The "CMMI for Development" (CMMI-DEV) supports the improvement of organizations that develop software, systems or hardware.
  • The "CMMI for Supplier Management" (CMMI-SPM) supports the improvement of organizations that purchase software, systems or hardware from suppliers but do not develop them themselves (up to version 1.3 Acquisition (CMMI-ACQ)).
  • The "CMMI for Services" (CMMI-SVC) supports the improvement of organizations that provide services.

historical development

  • In 1979 Philip B. Crosby published the Quality Management Maturity Grid , which is considered the forerunner of the CMMI.
  • In 1986, on the initiative of the US Department of Defense, the Software Engineering Institute (SEI) at Carnegie Mellon University / Pittsburgh , which is subordinate to the US Department of Defense, began developing a system for evaluating the maturity of software processes.
  • In 1991 the model was released as Capability Maturity Model 1.0.
  • In 1993, CMM was revised and made available in version 1.1.
  • In 1997, shortly before adoption by the US Department of Defense , CMM 2.0 was withdrawn and the CMMI project started.
  • In 2000, CMMI - at that time still under the name Capability Maturity Model Integrated - was published as a pilot version 1.0.
  • In 2002, CMMI was released under the new name Capability Maturity Model Integration (CMMI for short).
  • In 2003 the SEI's support for the old version CMM expired, and
  • Since 2005 the licenses of the assessment manager for CMM have expired. In other words, there are no longer any official CMM assessments.
  • In 2006 the new version 1.2 of the CMMI was published. With this came some fundamental changes. So was u. a. renamed the new version to CMMI-DEV (CMMI for Development).
  • In 2007 version 1.2 of the CMMI for Acquisition was released.
  • Version 1.2 of the CMMI for Services was released in 2009.
  • In 2010 a version 1.3 of all CMMI models (CMMI-DEV, CMMI-ACQ, CMMI-SVC) was released.
  • Version 2.0 of CMMI-DEV, CMMI-SVC and CMMI Supplier Management (SPM) appeared in 2018. The latter is the new name of the previous CMMI-ACQ.

Classification of the CMMI models

The CMMI models are reference models that summarize best practices. In contrast to a concrete process model , a CMMI model defines basic practices, e.g. B. good product development (the “what”), but no concrete steps (the “how”). The primary goal of the CMMI models is to support continuous process improvement by defining practices or criteria by a professional organization. The specific and adequate design of the work or working method is the responsibility of the organization and is an important part of the process improvement task. Since CMMI does not define a specific procedure, CMMI can be applied to very different organizations and sizes of organization. So z. For example, the requirement of CMMI that the project participants ( stakeholders ) consent to the project plan must be obtained during project planning can be implemented in very different ways in an organization. There is therefore no “one” correct CMMI implementation.

A special feature of the CMMI models is that they not only deal with the technical practices, but also with the supporting tasks of the organization, such as B. Provision of resources or implementation of training measures. Another special feature is that CMMI attaches great importance to the actual process and thus stands in contrast to processes - often referred to as "cabinet goods" - that are documented but not lived.

Building a CMMI model

A CMMI model defines a number of process areas (e.g. project planning , requirements development , organization- wide process definition ). A process area specifies goals and best practices of professional work. For example, in the project planning process area, the goals are "make estimates", "develop a project plan", and "bring about commitment to the plan". The practices for the goal of “making estimates” are “estimate the scope of the project”, “estimate attributes of work products and tasks”, “define the project lifecycle” and “make estimates of effort and costs”. For the process areas, goals and practices, CMMI provides additional explanatory information. So z. B. Each process area is explained first and other related process areas are listed. Then the goals and practices are listed. Each practice is further explained with an explanatory text, typical work results and typical work steps. These notes are intended to help with implementation, but are not the basis for an assessment ( appraisal ).

The process areas are divided into categories. For all three CMMI models these are:

  • Project Management ( Project Management ) or in the CMMI for Services Work Management ( Work Management )
  • Support ( support )
  • Process Management ( Process Management ).

The process areas in these categories are fundamentally similar in the three CMMI models, although the process areas differ in some cases. So speaks z. B. CMMI for Services from work management and CMMI for Development from project management, since services are often implemented through teams and developments are typically implemented through projects.

Process management and process improvement are above all an organization-wide task. The process areas in the support category are implemented project-specific or team-specific in some organizations, and across the organization in some organizations.

Each of the three CMMI models has a further category in which the process areas specific to the respective application area are included:

  • At CMMI for Development: Development ( Engineering )
  • At CMMI for Acquisition: Acquisition ( Acquisition )
  • At CMMI for Services: establishment and supply of services ( Service Establishment and Delivery )

This structure in the CMMI models of common categories and specific categories is one of the great advantages of CMMI. On the one hand, the specific topics are addressed (such as services), on the other hand, the CMMI models can be seamlessly combined with one another thanks to the common core and structure. The latter is particularly interesting for organizations that z. B. offer both development and services (e.g. IT development and IT services, or development of cars and maintenance of cars). Such organizations find a coordinated set of models in the CMMI family, so that improvements can be "thought" across the board.

Process areas of the CMMI for Development Version 1.3

The following table lists the process areas of the CMMI for Development Version 1.3 - and the assignment of the process areas to the categories and degrees of maturity.

Process Areas ( Process Areas ), categories ( Categories ) and levels of maturity ( Maturity Levels ) at CMMI for Development Version 1.3
Process area Process area (German) category Maturity level
Causal Analysis and Resolution (CAR) Root cause analysis and problem solving Support 5
Configuration Management (CM / SCM ) Configuration management Support 2
Decision Analysis and Resolution (DAR) Decision analysis and discovery Support 3
Integrated Project Management (IPM) Integrated project management Project management 3
Measurement and Analysis (MA) Measurement and analysis Support 2
Organizational Performance Management (OPM) Organization-wide process capability management Process management 5
Organizational Process Definition (OPD) Organization-wide process definition Process management 3
Organizational Process Focus (OPF) Organization-wide process focus Process management 3
Organizational Process Performance (OPP) Organization-wide process capability Process management 4th
Organizational Training (OT) Organization-wide training Process management 3
Product Integration (PI) Product integration Engineering 3
Project Monitoring and Control (PMC) Project tracking and control Project management 2
Project Planning (PP) Project planning Project management 2
Process and Product Quality Assurance (PPQA) Quality assurance of processes and products Support 2
Quantitative Project Management (QPM) Quantitative project management Project management 4th
Requirements Development (RD) Requirements development Engineering 3
Requirements Management (REQM) Requirements management Project management 2
Risk Management (RSKM) Risk management Project management 3
Supplier Agreement Management (SAM) Management of supplier agreements Project management 2
Technical Solution (TS) Technical implementation Engineering 3
Validation (VAL) Validation Engineering 3
Verification (VER) verification Engineering 3

Institutionalization and skill levels

In addition to the technical practices that are specific to a process area, CMMI also explicitly addresses the issue of institutionalization. “Institutionalization” means that the working methods in the organization are lived as a matter of course and as part of daily work. In times of stress, in particular, institutionalized working methods endure. In addition to the professional practices, CMMI defines practices that implement the institutionalization. These practices are institutionalized as generic practices ( generic practice ) because they are the same for all process areas. Implementing many generic practices is an organizational responsibility.

CMMI describes the degree of maturity of an individual process area through so-called " capability levels ". The degree of institutionalization is defined as follows from version 1.3:

0 - Incomplete
The work is carried out in such a way that the technical goals ( called " Specific Goals " in CMMI , e.g. a project plan in project planning) are not achieved.
1 - Performed
The work is carried out in such a way that the technical goals are achieved.
2 - managed
The work is directed.
3 - Defined
The work is carried out using an adapted standard process and the way of working is improved.

The generic practices and skill levels are at the core of CMMI and are identical in all CMMI models.

Maturity levels

Characteristics of the different degrees of maturity (English original).

In addition to the skill levels of an individual process area, CMMI defines “maturity levels” . A maturity level comprises a number of process areas that must be established with the skill level corresponding to the maturity level. Each degree of maturity is a development plateau in the process improvement of the organization. CMMI thus offers help for improvement by prioritizing the process areas with regard to improvement. The maturity levels are:

1 - initial
No requirements. Every organization automatically has this level of maturity.
2 - managed
The projects are managed. A similar project can be repeated successfully.
3 - Defined
The projects are carried out according to an adapted standard process and there is an organization-wide continuous process improvement.
4 - Quantitatively managed
A statistical process control is carried out.
5 - Optimizing
The work and working methods are improved with the help of a statistical process control.

The maturity levels are basically identical in all CMMI models, but the assignment of the process areas to the five maturity levels is specific for each CMMI model (since each CMMI model contains different process areas).

The assessment of the degree of maturity or the degree of ability of an organization is carried out by means of a SCAMPI examination (SCAMPI appraisal ), which can only be conducted by persons authorized by the SEI. The list of all lead appraisers authorized by the SEI, i.e. those persons who are allowed to lead such a SCAMPI, can be found on the website of the Software Engineering Institute (see web links below). The German-speaking authorized lead appraisers have joined forces in the German CMMI Lead Appraiser and Instructor Board (CLIB).

Published results of CMMI appraisals (status 01/2009)
Level Companies
1 ( initial ) 80
2 ( managed ) 726
3 ( Defined ) 1306
4 ( Quantitatively Managed ) 51
5 ( Optimizing ) 184

CMMI and CMM

CMMI has replaced the Software Capability Maturity Model (SW- CMM for short or just CMM for short ). CMM has been discontinued by the SEI and is no longer supported. CMMI not only replaces different quality models for different development disciplines (e.g. for software or system development), but also integrates them in a new, modular model. This modular concept enables, on the one hand, the integration of further development disciplines (e.g. hardware development) and, on the other hand, the application of the quality model in overarching disciplines (e.g. development of chips with software).

Goal orientation and incorrect use of CMMI

For a successful use of CMMI, a specific improvement goal is absolutely necessary.

With a specific improvement goal, CMMI is a very useful support for improvement. CMMI helps to go through the relevant practices in a targeted manner, in which the question is in the foreground whether these practices are under control in terms of the improvement goal or whether an optimization makes sense. An example of an implementation of CMMI with leanness and efficiency as improvement goals is z. B. Scrum , which offers project and requirements management methods.

Without an improvement target, an organization can only make improvements by chance - with or without CMMI. On the contrary: Improvements without a goal can quickly create bureaucraticism if practices are implemented aimlessly (and then over-fulfilled to be on the safe side).

Differentiation from other standards

In contrast to DIN EN ISO 9001 , the CMMI models specifically address the practices in a certain area of ​​application.

While DIN EN ISO 9001 covers the entire organization and thus more broadly, CMMI goes far more in-depth with the specific activities and offers specific process areas and practices. However, the CMMI models and DIN EN ISO 9001 have the same basic idea. The requirements of the CMMI models can be mapped to the requirements of DIN EN ISO 9001 (this table is available on the SEI website).

The CMMI models implement the requirements of the ISO / IEC 15504 (SPICE) standard for a process model. The SCAMPI appraisal process partially implements the requirements of the ISO / IEC 15504 standard for an assessment process.

In addition to the CMMI models, there are also the process model standards ISO / IEC 12207 for software and ISO 15288 for system development . In contrast to CMMI, these two standards do not go beyond the definition of the titles of the practices of CMMI (no extensive explanations as in CMMI). There is also no integration of the two norms. In terms of content, ISO / IEC 12207 and ISO 15288 essentially require the same as CMMI for development (CMMI-DEV). For the ISO 12207 standard there is a CMMI-independent evaluation procedure ("process assessment model") defined as an example in ISO / IEC 15504 (SPICE) Part 5.

CMMI for Development (CMMI-DEV) is used for the development of products or for maintenance projects on existing products. The CMMI for Services (CMMI-SVC) is used for organizations that offer services. CMMI-SVC addresses all types of service organizations. For IT operating organizations, CMMI for Services is an alternative to ITIL . Compared to ITIL, CMMI for Services is more highly aggregated. CMMI for Services and CMMI for Development can be integrated with one another so that together they cover the entire product lifecycle.

literature

  • Mary B. Chrissis, Mike Konrad, Sandy Shrum: CMMI. Process integration and product improvement guidelines . 1st edition. Addison-Wesley Verlag, Munich 2009, ISBN 978-3-8273-2784-0 .
  • Brian P. Gallagher, Mike Phillips, Karen J. Richter, Sandy Shrum: CMMI-ACQ. Guidelines for Improving the Acquisition of Products and Services . Addison-Wesley, 2009, ISBN 978-0-321-58035-1 .
  • Eileen C. Forrester, Brandon L. Buteau, Sandy Shrum: CMMI for Services. Guidelines for Superior Service . Addison-Wesley, 2009, ISBN 978-0-321-63589-1 .
  • Malte Foegen, Mareike Solbach, Claudia Raak: The way to professional IT . Springer, Berlin 2007, ISBN 3-540-72471-0 .
  • Christian Hertneck, Ralf Kneuper: Improve processes with CMMI® for Services: A practical guide with case studies . dpunkt.verlag, Heidelberg 2011, ISBN 978-3-89864-657-4 .
  • Hubert Hofmann, Yedlin, Debbie; Mishler, John; Kushner, Susan: CMMI for Outsourcing: Guidelines for Software, Systems, and IT Acquisition . Addison-Wesley Professional, 2007, ISBN 0-321-47717-0 .
  • Ralf Kneuper: CMMI. Improvement of software processes with Capability Maturity Model Integration . 3. Edition. dpunkt.verlag, Heidelberg 2007, ISBN 978-3-89864-464-8 .
  • Ralf Kneuper, Ernest Wallmüller: CMMI in practice. Case studies to improve development processes with CMMI . dpunkt.verlag, Heidelberg 2009, ISBN 978-3-89864-571-3 .
  • Jürgen Schmied, Paul-Roux Wentzel, Michael Gerdom, Uwe Hehn: Improve processes with CMMI! dpunkt.verlag, 2008, ISBN 978-3-89864-538-6 .
  • Ernest Wallmüller: SPI - Software Process Improvement with CMMI and ISO 15504 . Hanser, Munich 2006, ISBN 3-446-40492-9 .

Web links

Individual evidence

  1. CMMI Version 1.3 Information Center. Retrieved January 6, 2011 .
  2. ^ History Of CMMI. Retrieved June 16, 2020 .
  3. ^ Sally Godfrey (2008) What is CMMI? ( Memento of the original from April 4, 2009 in the Internet Archive ) Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice. . NASA presentation. Accessed 8 dec 2008. @1@ 2Template: Webachiv / IABot / software.gsfc.nasa.gov
  4. Published Appraisal Results. Retrieved January 22, 2009 .