The CMMI project integrated the SW-CMM® Version 2C, [1] EIA/IS-731 Systems Engineering Capability Model Version 1.0 [2], and the IPD-CMM Version 0.98a [3] into a single framework that can be used by any organization whose processes involve developing a product or service for process development and improvement. In developing the CMMI, authors are constrained by size and complexity considerations relative to the activities/practices that can be included from source models. Mapping files can be used to help the user community evaluate whether a reasonable suite of practices was included from the source models, and to aid in transition from the source models to CMMI. The differences between CMMI Version 0.2 and EIA/IS-731 are described in this article. The impacts described may change when EIA/IS-731 is compared to CMMI Version 1.0.

EIA/IS-731 is organized by Categories, Focus Areas, Themes, and Specific Practices. These, along with Generic Practices and Generic Attributes, provide the model used for assessments (See Figure 1). The only informative material in EIA/IS-731 is in the Descriptions and Notes found in Generic Practices, Generic Attributes, Focus Areas, and Themes. Specific Practices do not provide any informative material.


Figure 1: EIA/IS-731 architecture

The CMMI is similar to EIA/IS-731. The primary difference between the models is the amount of informative material included. Compare Figure 2, CMMI Architecture, with Figure 1, EIA/IS-731 Architecture. CMMI has fewer normative and expected elements than EIA/IS-731. EIA/IS-731 has 19 Focus Areas, 77 Themes and 381 Specific Practices. CMMI has 28 Process Areas, 92 goals and 221 Specific Practices. CMMI has 22 Generic Practices while EIA/IS-731 has 12.


Figure 2: CMMI architecture

Capability Levels, and Categories of Process Areas organize CMMI. Generic Attributes are under study and may be added to the model. The model's Specific Practices are organized by Categories, Process Areas and Specific Goals. Generic Practices are organized by Capability Levels and Generic Goals.

The CMMI provides informative material in several formats.

• References provide links to other process areas. There are two kinds of references in CMMI, Refer to and Use. "Refer to" means go to the referenced Process Area (PA) for more information on the topic. "Use" means use the practices in the referenced PA to perform the practice. Both references are informative only, no required or expected inference is intended.
• Notes are allowed for every level of the architecture to explain the intent and provide examples of the model component.
• Specific and Generic Practices may have Subpractices to provide more detailed level of informative material for the practices.
• Each Specific Practice and Subpractice may have amplifications to provide information specific to a discipline.
• CMMI contains example Work Products to help interpret the practice.
• Generic Practice Elaborations provide informative material. They are organized by PAs because each Generic Practice is used for all Process Areas.

The following sections describe how EIA/IS-731 ('731) maps to and from CMMI Version 0.2. Please note that several changes are under investigation that may result in changes to the CMMI Version 1.0. The detailed mapping will be updated after its release. The detailed mapping can be accessed at www.sei.cmu.edu/cmm/cmmi/comm/map731.html

In developing the CMMI, there were a number of opposing forces that had to be overcome in integrating the systems and software models. '731 has six Focus Areas (process areas) that address engineering, while the SW-CMM has one Process Area (Software Product Engineering) to cover the same material. '731 has a large number of practices per process area, while the SW-CMM is relatively sparse in the number of practices (activities) per process area. The integration compromise resulted in five process areas for engineering, similar to '731. However, the number of practices was reduced by about half, relative to '731. As CMMI is released for comment and public use, several questions, important to the ultimate success of CMMI, will need answers from the systems and software community. Will the software community find the increase in the number of engineering process areas and practices helpful or burdensome? Will the systems engineering community find the elimination of the Define Technical Problem Focus Area and the reduction in the number of practices acceptable? Are '731 practices in CMMI the appropriate ones?

The representation of each of the '731 Technical Category Focus Areas in CMMI, and some effects of transitioning, are briefly discussed below. Recommendations, related to model transition, represent the authors' judgement.

The CMMI Customer and Product Requirements (CPR) PA includes the two themes from EIA/IS-731, Define Stake-holder and System Level Requirements, under Goal 1. Goal 2 of the CMMI CPR PA includes selected practices from Problem Refinement Theme of the '731 Define Technical Problem Focus Area. (The Define Technical Problem Focus Area does not exist as a PA in CMMI. Several of its practices are distributed to other CMMI PAs.)

The CMMI CPR PA addresses, in less detail, the following '731 concepts:

• Collecting stakeholder needs and the related advanced concept of eliciting stakeholder needs.
• Converting needs to requirements.
• Obtaining agreements on the requirements with customers.
• Validating requirements.
• Refinement of requirements.

Some Define Technical Problem (DTP) Focus Area practices were included in the CMMI Customer and Product Requirements PA; some were included in the Technical Solution PA. DTP addresses logical or functional problem analysis (solution independent) and requirements document maintenance. Fifteen DTP practices were not included in the CMMI. Excluded practices that deserve a close look (for transition considerations) include practices that address identifying key stakeholder requirements, capturing relationships between requirements, and capturing rationale for requirements traceability, derivations, and allocations. '731 practices that deal with reviewing requirements against quality attributes and maintaining the status of requirements are represented in the CMMI Requirements Management PA as (informative) subpractices. The entire '731 Feedback and Verification Theme, relating to involvement of stake-holders in requirements development, is not included in CMMI. Several '731 practices that are not specific practices in CMMI are covered by the CMMI generic practices (Common Features).

The CMMI Technical Solution process area includes most of the '731 Define Solution practices. It also includes the functional architecture practices from Define Technical Problem and the product construction and supporting documentation activities from the SW-CMM Software Product Engineering process area. A significant '731 practice, not included in the CMMI, is one that addresses review of derived and allocated requirements in the context of operational concept threads and scenarios. As this practice is valuable for evaluating the adequacy of requirements, organizations should consider retaining it as a key process element. Three of the CMMI practices include several of the '731 concepts in bulleted lists. The CMMI practice on development of design alternatives and selection criteria invokes considerations of life cycle cost, performance, complexity, robustness, expansion and growth, cost drivers, technology limitations, sensitivity to construction methods and materials, risk, and evolution of requirement drivers and technology. The CMMI activity on maintaining complete design descriptions calls for including functionality, requirement allocations to design components, operational concepts and scenarios, architectural features, and design decision rationale. The CMMI activity on developing component specifications calls for specifying each design component in terms of allocation of product performance, design constraints, fit, form, and function to meet requirements and facilitate production and derived requirements that address the cost and performance of other life-cycle phases.

These practices embody a lot of material, and although they may prove awkward in assessments, the material should be valuable for process definition and improvement guidance.

All of the '731 Assess and Select practices are included in the CMMI Decision Analysis and Resolution process area. The CMMI Decision Analysis and Resolution process improves on the '731 Assess and Select focus area by adding a practice on establishing and using criteria to determine which issues to subject to a formal decision analysis and resolution process.

Without this, the question nearly always came up in assessments as to whether all decisions, or some select set, were to be subjected to a formal decision process. The new practice solves this problem by requiring organizations to establish criteria for selecting those decisions important enough to need a formal resolution process.

About half of the '731 Integrate System Focus Area practices are included in the CMMI Product Integration Strategy Process Area. Only two relatively high-value practices are not included in CMMI. One of these is the '731 advanced practice, "develop the integration strategy early in the program."

Organizations should continue to make early integration planning part of their standard process. The other is a practice that addresses formal procedures for coordination of multiteam integration efforts. Of the remaining '731 practices not included in CMMI, some are handled by generic practices and other process areas and the remainder are of relatively low value. The CMMI Product Integration process area includes a new practice, "select the optimum integration strategy." It would be reasonable to expect that the word optimum will be eliminated in a future release. The CMMI Product Integration process area adds (relative to '731) a practice on acceptance tests performance and a practice on product packaging and delivery. The presence of the acceptance test practice in the integration process area is puzzling and seems to overlap with material in the Product Verification process area.

Relatively high-value practices not included in CMMI are the practices that address validation of verification procedures and support facilities, incremental verification, and review and coordination results with stakeholders. Practices that address these topics are recommended as valuable elements of organizational processes for product verification. A number of other '731 System Verification practices are not included in CMMI: these are moderate to low value, mostly due to CMMI generic practices and some redundancy in '731. Readers should be alert to the use of the term work products in the CMMI Product Verification process area. The term appears to include the product(s) delivered to the customer, hence, the overlap mentioned above with the acceptance test practice of Product Integration.

The CMMI Validation process area has improved on the '731 practice of performing validation, by separating out training, maintenance, and support validation as a separate practice. CMMI does not include the '731 practices on early requirements validation. These '731 practices should be considered for any organization's standard process on validation.

The application of advanced practices is the primary difference between '731 and CMMI. '731 defines specific practices by capability level. The SW-CMM uses only base practices called activities. The CMMI Engineering process areas use advanced practices, but the Management and Support process areas do not. Many of the advanced practices, those that are at Level 2 or higher, now map to CMMI base practices. This, in effect, raises the bar for the continuous assessments with respect to '731.

The CMMI does this by including many of the '731 practices as subpractices. As shown in the introduction, subpractices are informative only. However, informative material should be used for guidance on process improvement programs. CMMI improves on '731 by providing informative material for this purpose while reducing the number of specific practices assessed.

Each '731 Focus Area in the Management Category is discussed in this section. Unless noted, there is no significant impact in CMMI transition, other than lack of advanced practices. There are practices included in CMMI that are new to '731 users. Table 1 shows the number of these practices by process area.


Table 1: CMMI practices new to EIA/IS-731 users
(Click on image above to show full-size version in pop-up window.)

As the table shows, organizations transitioning to CMMI should consider Quantitative Management of Quality and Process (QMQP), Measurement and Analysis, (M&A) Causal Analysis and Resolution (CAR) and the new practices in risk management. The new QMQP practices deal with statistically managing the sub-processes. M&A defines the process that should be used to establish a measurement system. This process is not covered in '731. CAR practices deal with determining and addressing root causes of defects.

Plan and Organize practices are included primarily in CMMI Project Planning. Some practices are included in Integrated Project Management and two are in Measurement and Analysis. Six '731 practices are not included in CMMI and two are covered by CMMI generic practices. One practice not included addresses designating a systems engineering first-line manager for negotiating technical commitments. This is an important systems engineering role and should be considered when assigning responsibilities. Three practices address the statement of work (SOW) and the work breakdown structure (WBS). The WBS is addressed in CMMI Project Planning in a more general manner. '731 has three levels of capability addressing the SOW and WBS. Another practice not addressed directly is developing top-level schedules for the remaining life cycle phases of the program. CMMI addresses defining the project life cycle in Project Planning. This, along with the planning generic practice and the Establish and Maintain Schedules Practice adequately covers this practice. The last practice not addressed in CMMI addresses clear lines of responsibility and authority between systems engineering and program management. The Assign Responsibility and Planning generic practices and the overall Project Planning PA imply this practice.

Monitor and Control practices are included in CMMI Project Monitoring and Control, Integrated Project Management and Measurement and Analysis. Two practices in Theme 2-2.1, Degree of Formality, are not included in CMMI that address the degree of oversight needed, and establishing criteria for program evaluation. Establishing the criteria is important and should be a part of a measurement or monitoring and controlling process. CMMI addresses determining objectives but not specific criteria. One practice is covered by a CMMI generic practice.

Integrate Disciplines' Practices are included in CMMI Integrated Project Management. Three '731 practices are not included in CMMI. One addresses training that the CMMI Organizational Training PA can address if there is a need for interdisciplinary cooperation. Another practice not included is a Level 4 practice that addresses modeling communication skills and interdepartmental cooperation of upper management. This is an advanced practice and could not be placed in CMMI with the current architecture. Another Level 3 advanced practice addresses establishing a mechanism to ensure compliance with commitments. Both of these should be considered when defining integrated disciplines processes. One practice is covered by a CMMI generic practice. One of the practices is covered by a practice in an IPPD process area, Integrated Team. Only four Integrate Disciplines specific practices (SPs) are included in CMMI as SPs. The remaining '731 practices map to CMMI informational components.

Coordinate with Suppliers practices are included in CMMI Suppler Agreement Management. Six practices are not included in CMMI. The first addresses selecting suppliers based on inputs from the systems engineering team leader. The integrated model addresses this by the Assign Responsibility and Planning generic practices. A Level 4 '731 specific practice builds on this concept by having systems engineering participate in the plans, process, and product standards the suppliers use. Another practice is a Level 4 specific practice in '731 and addresses involving the supplier early in the program to assist in requirements development. This is not addressed in CMMI but should be considered when appropriate. The other practices address providing feedback to the suppliers and having a mechanism for assuring that they follow their processes. These are important practices for both the project and the suppliers and should be included in an organization's processes.

Manage Risk Practices are included primarily in CMMI risk management. One practice is included in Project Monitoring and Control and four are covered by CMMI generic practices. Eleven practices are not included in CMMI. Theme 2-5.5 contains three practices that should be included in a risk management strategy. Theme 2.5-8 addresses communication and coordination of risk status. These practices are not addressed in CMMI but should be considered as an important part of an organization's process. A Level 3 specific practice not included in CMMI addresses implementing risk management for key processes within the program. CMMI addresses several other aspects of risk but not processes for design, test, manufacturing, etc. CMMI provides adequate coverage of this practice although it is not explicitly stated. Another specific practice addresses assessing risks qualitatively. CMMI has a practice that assesses the likelihood and consequences for each risk that probably covers qualitative assessment of risks. One specific practice addresses reviewing risk analysis. In general, specific reviews are not listed in CMMI. There is also a Level 4 specific practice that addresses using metrics regarding risks to initiate corrective action. There is a subpractice under the CMMI Implement Mitigation Plans specific practice that collects performance metrics on the risk-handling activities. This only partially covers the '731 specific practice. The other specific practice not included in CMMI is a document practice. CMMI does not include document at the specific practice level but it is implied. This construct may be improved in future releases.

Manage Data practices are included in CMMI Data Management. Two practices are not included in CMMI. One provides a common data management archival and retrieval capability throughout the organization. CMMI is not specific on providing data management capability throughout the organization. The CMMI practices can be applied at any level in the organization. The other specific practice that addresses archiving data efficiently was not included in CMMI because the term efficiency is difficult to assess. CMMI tried to avoid subjective words. CMMI generic practices cover three practices. An improvement provided by CMMI is a practice on establishing data privacy and security.

Manage Configurations practices are included in CMMI Configuration Management. One '731 advanced practice (2.7- 2-3) relating to evaluation of change impact beyond the immediate program is not included in CMMI. This practice should be considered for inclusion in organizational processes.

Ensure Quality practices are included primarily in CMMI Process and Project Quality Assurance. One practice is covered by Quantitative Management of Quality and Process. One is covered by Causal Analysis and Resolution and two are covered by CMMI generic practices.

Each '731 Focus Area in the Environment Category is dis-cussed in this section. Unless otherwise noted, there is not any significant impact in transitioning to CMMI, other than the lack of advanced practices.

Define and Improve the Systems Engineering Process practices are included primarily in CMMI Organizational Process Definition and Organizational Process Focus. Some practices map to CMMI Qualitative Management of Quality and Process, Integrated Project Management, and Organizational Process Technology Innovation. Two practices map to a CMMI generic practice and two are not included in CMMI. One of these practices clearly defines the inputs and outputs of the systems engineering subprocesses. The word clearly is subjective and is not included in CMMI. The practices included in CMMI are defined to a level of detail that improves on the '731 specific practice. The other specific practice performs improvement of systems engineering processes in use on programs in at least an informal manner. CMMI Organizational Process Technology Innovation provides several specific practices that address process improvement. This is probably an improvement provided by CMMI.

The '731 Manage Competency Focus Area is represented in CMMI by the Organizational Training process area. Many of the '731's 30 practices are included as subpractices of the six CMMI practices. The Learning Environment Theme of '731, which addresses methods for creating a learning environment, is not included in CMMI. Inclusion of this important theme in an organization's process is highly recommended. The '731 practice (3.2-4-4) on evaluating alumni capability is not included in CMMI; organizations should consider this practice at higher capability levels. The '731 practice relating to provision of skill and knowledge from outside sources was moved to the Project Planning process area in CMMI.

Manage Technology Theme 3.3-1 is not included in CMMI. One practice from Theme 3.3-2 is included in CMMI Suppler Agreement Management. Theme 3.3-3 is included in CMMI Process Innovation Deployment, Organizational Process Technology Innovation, and Integrated Project Management. Systems engineers consider this a weakness in CMMI. Future versions of the CMMI may include these practices.

Manage Systems Engineering Support Environment practices are included in CMMI Organizational Process Definition and four CMMI generic practices. Four practices are not included in CMMI. Piloting new tools is one specific practice that is not included in CMMI. If tools were considered a part of new processes, then this would be addressed by Organizational Process Technology Innovation (OPTI), where piloting is addressed in the "pilot-selected process improvements" practice. Perform cost-benefit analysis for commercial off-the-shelf vs. in-house developed environments is another specific practice not addressed in CMMI. OPTI addresses cost-benefit analysis but does not specifically address this trade-off. The new processes addressed in OPTI could include off-the-shelf systems engineering environment improvements, however. Another practice not included uses the word maximize. This is difficult to assess and will not be used in CMMI. The fourth practice not included addresses planning and tracking maintenance of the support environment. The key words in this practice relate to monitor and control maintenance that is not addressed in CMMI. However, a combination of several practices indirectly addresses the concept.

The CMMI generic practices are similar to those found in '731. It has 12 generic practices while CMMI has 22. In general, the CMMI is more detailed than '731. The SW-CMM common features are the source for several of the generic practices. The CMMI generic practices are grouped under Generic Goals. There is one generic goal for each capability level. The goals are general in nature: "The process is institutionalized as an xxx process." XXX represents the five levels, (i.e., Performed, Managed, Defined, Quantitatively Measured, and Optimizing).

The CMMI generic practices may be grouped within categories in CMMI Version 1.0. The following categories are in use in the CMMI Staged Representation and may be used in the Version 1.0 Continuous Representation:

• Commitment to perform.
• Ability to perform.
• Directing implementation.
• Verifying implementation.

Due to significant differences between EIA/IS-731 and CMMI, a well-planned transition is recommended. Organizations are encouraged to avail themselves of appropriate training and reference resources in planning and effecting the transition. The Software Engineering Institute, the International Council on System Engineering, and the Government Electronics and Information Technology Association are expected to provide transition resources. Organizations should also carefully evaluate the business value of existing practices in their standard processes before making model evolution/transition changes. Organizations are encouraged to participate in the CMMI comment and improvement process.

1. See Sandy Shrum's article on page 6 for more on staged vs. continuous representations of the CMMI.

1. SW-CMM v2 draft C Software Engineering Institute. Software CMM, Version 2c, Oct. 22, 1997.
2. EIA/IS-731, Systems Engineering Capability Model. Represents a merger of legacy systems engineering models under the auspices of the INCOSE and Electronic Industries Association. Available at www.incose.org
3. IPD CMM Version 0.98. Not publicly available.

Aaron Clouse is a senior Principal Systems Engineer at Raytheon Systems Co. He has worked on several programs involving radar, sonar, global positioning systems, and cellular telephones. He is assigned to work engineering metrics and process improvement programs and is an author of CMMI.

P.O. Box 801, MS 8078
McKinney, Texas 75070
Phone: 972-952-2110
Fax: 972-952-2532
E-mail: Eajc@raytheon.com

Curt Wells consults on process improvement and assessment and teaches Process Oriented Systems Engineering for the University of Texas. He co-authored EIA/IS-731 and the Systems Engineering Capability Maturity Model, and is an author of the CMMI.

i-metrics
90 S. Camino Real
Uhland, Texas 78640
Phone: 512-76-9688
Fax: 773-913-0473
E-mail: cwells@i-metrics.net