"Abstract" This paper analyzes the CMM to CMMI mapping at all levels, points out the differences between CMM and CMMI, and discusses the work and transition methods needed to upgrade CMM to CMMI. It can be used as a reference for the software organization of CMM to upgrade smoothly to CMMI.
"Key Words" KAP, CMM, CMMI, SCAMPI, KP
1 Introduction
Since 1990, the Software Engineering Institute of Carnegie Mellon University (SW-CMM) has released the v1.0, the SEI has improved the SW-CMM in different fields, and derived a series of maturity models. Among the more important include: Systems engineering Capability Maturity Model (SE-CMM), software procurement Capability Maturity Model (SA-CMM), integrated product development Capability Maturity Model (IPD-CMM), etc. But these targeted models have brought some new problems. The software company's business is generally not a single, some companies may be engaged in software development, hardware development, but also to the software procurement. Taking more than one model at this point can make many key process domains overlap and increase development costs.
November 2001 SIE introduced CMMI V1.1, integrated the above model to solve the overlapping problem between multiple models. At the same time SEI published a set of evaluation systems for CMMI SCAMPI SM V1.1, replacing the CBA IPI and SCE SM and intended to replace the CMM with CMMI. Many organizations have already begun to transition to CMMI.
The CMMI's underlying source model includes: Software CMM version 2.0 (draft C), EIA-731 Systems Engineering, and IPD CMM (IPD) 0.98a, which covers systems engineering, software engineering, integrated product and process development (IPPD) and supplier sourcing from four areas of knowledge. It has two representations of stage (staged) and continuous (continuous). In order to facilitate the comparison with CMM, the CMM and CMMI are used in phase representation.
About CMM and CMMI This article does not do detailed introduction, the related data is more, to the CMM and CMMI not quite understand reader to be visible reference book [1], [2].
2 mapping from CMM to CMMI
The mapping of CMM to CMMI is a complex system, which involves KPA reconfiguration and KP's re organization. Figure 1 only describes the mapping relationship of CMM to CMMI in general.
Figure 1 CMM to CMMI mapping at all levels
For a detailed description of the mapping relationship between CMM and CMM, see ref. 3.
3 Mapping Analysis
Although the CMMI is based on the CMM, the two are mostly similar, but there are still great differences. In general, CMMI is a clearer illustration of how the process domains and generic practices (generic practice) are applied, and how to incorporate work products into the appropriate levels of configuration and data management baselines, risk management policies, validation strategies, and more. The CMMI contains more engineering activities, such as requirements development, product integration, validation, and other process areas; The process content is defined more clearly, with less emphasis on documented procedures.
As shown in Fig. 1, the measurement and analysis of KPA (measurement) was added to the CMMI2 level, and the Measurement Analysis Practice (KP) was summed up as a formal key process area, while the measurement and analysis practices in CMM were scattered in various grades. As a result, more emphasis has been placed on quantitative management in the CMMI, transparency in management and transparency in software development have been upgraded.
Requirements Development (Requirements Development), Technology Solutions (technical Solution), product integration (products Integration), verification (verification), validation (CMMI3) are added at the level (Validation), risk management (Risk Management), decision analysis and decision (Decision analyses and resolution) KPAs. Software PRODUCT engineering in CMM it has been replaced by demand development, technical solutions, product integration, verification, validation and KPAs. Peer review KPA was incorporated into the validation kpa; Integrated software management in CMM the risk management articulated by KPA formed an independent risk management in CMMI3. kpa 。 At the same time integrated software management and coordination between groups KPAs integrated project Management KPA. Synthetic teams, decision analysis and solutions, and an integrated environment for the organization KPAs are new, and the process content is not mentioned in the CMM.
There is no new process domain in CMMI4, only the original quantitative process management, software Quality Management KPAs rebuilt for quantitative project management and organizational process performance KPAs.
Technology change management and process change management in CMMI5 KPAs merger for organizational innovation and technology popularization kpa, defect prevention kpa rebuilt for reason analysis and solution kpa.