This webpage was compiled to serve those of you adopting CMMI-SVC who are familiar with CMMI-DEV to help you quickly understand the differences between CMMI-SVC, V1.2 and CMMI-DEV, V1.2.
Below you will find the following:
CMMI-DEV, V1.2 was released in August 2006 and has a large number of users. CMMI-DEV focuses on product and service development. CMMI-SVC, V1.2 was released in February 2009 and focuses on service establishment, management, and delivery. A comparison of these two models is summarized in this table:
CMMI-SVC, V1.2 |
CMMI-DEV, V1.2 |
Chapter 4 covers only the Services-related process areas. |
Chapter 4 covers all of the process areas in the model. |
No Engineering process areas appear in the model. |
No Service Establishment and Delivery process areas appear in the model. |
The model has 24 process areas. |
The model has 22 process areas. |
Generic practices are listed only in the Generic Goals and Generic Practices section. GP elaborations also are located in this section of the model. |
Generic practices are listed both in the Generic Goals and Generic Practices section and at the end of each process area. GP elaborations also are located at the end of each process area. |
No IPPD additions appear in the model. |
IPPD additions appear in the model. |
Integrated teaming is covered in the specific practices of IPM and OPD, not as IPPD additions, but rather as specific practices inherent in these process areas (IPM SP 1.6 and OPD SP 1.7). |
Integrated teaming is covered in the specific practices of IPM and OPD as part of the IPPD group of additions. |
SSD additions covering service system development appear in the model. |
No SSD additions appear in the model. |
Many examples are included specifically for service organizations. |
Few examples are included specifically for service organizations. |
No amplifications appear in the model. |
Amplifications for software engineering, systems engineering, and hardware appear in the model. |
The preface of each model serves to introduce readers to the model. Each is structured the same as the other, but addresses a different audience.
This chapter in CMMI-SVC is a little less detailed and, of course, approaches the introduction to the model from a service provider’s perspective. This chapter in CMM-DEV approaches the material from a developer’s perspective.
This chapter is essentially the same in both models. The material about additions was moved. Discussion about amplifications and representation-specific content is absent in the CMMI-SVC model. In addition, the examples used in this chapter vary depending on the model.
This chapter is largely the same in both models. CMMI-SVC approaches this chapter from a service provider’s perspective. This chapter in CMM-DEV approaches the material from a developer’s perspective. An additional section, Understanding Key Concepts in the Use of CMMI for Services, is present in CMMI-SVC, but has no corresponding section in CMMI-DEV.
This chapter is about the same general subject in both models, but the two models have completely different content in Chapter 4. In CMMI-SVC, this chapter uses two figures and some discussion to illustrate the interrelationships of a group of process areas. This group of process areas consists of mostly services-specific process areas. In CMMI-DEV, this chapter uses three figures and discussion to illustrate the interrelationships among all of the model’s process areas. (No compare redline is provided because it would add no value.)
This chapter is largely the same in both models. CMMI-SVC approaches this chapter from a service provider’s perspective. This chapter in CMM-DEV approaches the material from a developer’s perspective.
Generic Goals and Generic Practices
The Generic Goals and Generic Practices section of Part 2 is similar in both models. CMMI-SVC has generic practice elaborations added for GPs under GG2 and GG3 and a few references were updated. The rest of the material is nearly identical.
The following seven CMMI-SVC, V1.2 process areas are unique to the CMMI-SVC model. They do not appear in the CMMI-DEV model. Each entry below includes the process area name and its purpose.
Capacity and Availability Management (CAM)
The purpose of Capacity and Availability Management (CAM) is to ensure effective service system performance and ensure that resources are provided and used effectively to support service requirements.
Incident Resolution and Prevention (IRP)
The purpose of Incident Resolution and Prevention (IRP) is to ensure timely and effective resolution of service incidents and prevention of service incidents as appropriate.
Service Continuity (SCON)
The purpose of Service Continuity (SCON) is to establish and maintain plans to ensure continuity of services during and following any significant disruption of normal operations.
Service Delivery (SD)
The purpose of Service Delivery (SD) is to deliver services in accordance with service agreements.
Service System Development (SSD)
The purpose of Service System Development (SSD) is to analyze, design, develop, integrate, verify, and validate service systems, including service system components, to satisfy existing or anticipated service agreements.
Service System Transition (SST)
The purpose of Service System Transition (SST) is to deploy new or significantly changed service system components while managing their effect on ongoing service delivery.
Strategic Service Management (STSM)
The purpose of Strategic Service Management (STSM) is to establish and maintain standard services in concert with strategic needs and plans.
The following CMMI-SVC, V1.2 process areas are in common or shared with other CMMI models. All but one of them are common to all CMMI models. (SAM is shared with CMM-DEV but not CMMI-ACQ.) Each entry below summarizes the changes made to the CMMI-DEV material when developing CMMI-SVC, V1.2. Click on the process area name to see the CMMI-SVC to CMMI-DEV redline comparison of the process area contents.
Causal Analysis and Resolution (CAR)
The discussion in this process area was revised to consistently refer to “defects and problems.” This change affected the wording of goals and practices as well as informative material.
The revisions to this process area were either editorial or were in the informative material. There were no major changes.
Decision Analysis and Resolution (DAR)
The revisions to this process area were either editorial or were in the informative material. There were no major changes.
Integrated Project Management (IPM)
A discussion of what “project” means for a service provider organization was added to the introductory notes. The specific practice, Establish Integrated Teams, was added and the IPPD additions were removed. Notes were also added that emphasize the importance of the service agreement in managing stakeholder involvement.
The revisions to this process area were either editorial or were in the informative material. There were no major changes.
Organizational Innovation and Deployment (OID)
The revisions to this process area were either editorial or were in the informative material. There were no major changes.
Organizational Process Definition (OPD)
The specific practice, Establish Rules and Guidelines for Integrated Teams, was added and the IPPD additions were removed. Other revisions to this process area were either editorial or were in the informative material.
Organizational Process Focus (OPF)
In SG2, “process improvements” was replaced with “process actions.” In SG3, “lessons learned” was replaced with “experiences.” Other revisions to this process area were either editorial or were in the informative material.
Organizational Process Performance (OPP)
The revisions to this process area were either editorial or were in the informative material. There were no major changes.
The revisions to this process area were either editorial or were in the informative material. There were no major changes.
Project Monitoring and Control (PMC)
Informative material was added to interpret many of the concepts in PMC for a service provider organization. Other revisions to this process area were either editorial or were in the informative material. There were no major changes.
Informative material was added to interpret many of the concepts in PP for a service provider organization. A substantial discussion of what “project” and “organization” mean for a service provider organization was added to the introductory notes. The specific practice, Establish the Project Strategy, was added to meet the strategic needs of planning.
Process and Product Quality Assurance (PPQA)
In this process area, the phrase “work products and services” was restated to be only “work products” because the meaning was confusing for service providers. This change affected the wording of goals and practices as well as informative material.
Quantitative Project Management (QPM)
The revisions to this process area were either editorial or were in the informative material. There were no major changes.
Requirements Management (REQM)
Notes about the importance of the service agreement with relation to requirements were added to the introductory notes. Notes to interpret the concept of bidirectional traceability for service provider organizations were also added. Other revisions to this process area were either editorial or were in the informative material.
The revisions to this process area were either editorial or were in the informative material. There were no major changes.
Supplier Agreement Management (SAM)
Notes were added to interpret SAM for service provider organizations. In this process area, the SP 1.3 statement was changed to no longer refer to “formal agreements with the supplier” but instead to refer to “supplier agreements.” The SP 2.3 statement was revised to remove the phrase “of custom-made products” since suppliers of services are not clearly covered by the practice with this phrase, and because standard and custom-made service products may both be critical and relevant. The phrase “as appropriate” was added to the SP 2.5 statement about ensuring transition of products because services cannot be stored and therefore this practice would not apply to services.
The references listed in each of the models are relevant to the area of interest addressed by the model in which they are listed.
This appendix is quite similar in both models. The process area abbreviations of each model are listed in the acronym list of each. Only those abbreviations used in a model are included in its list of acronyms.
Appendix C: Project Participants
Each time a model is published, those who participated during the time of its development are listed in this appendix. Differences are based on who was involved. No redline is provided for this appendix.
This appendix defines all important terms used in a CMMI model. Some changes occur when a model is developed; however, these changes are typically made ensuring that the definitions are relevant to all CMMI models. Some new or updated sources of glossary terms were added to the glossary introduction. There are many differences between the CMMI-DEV glossary and CMMI-SVC glossary. A significant portion of these changes were made during the development of CMMI-ACQ and were carried over into the CMMI-SVC baseline.
The following terms were added to the glossary: acquirer, appraisal team leader, commercial off-the-shelf, contractual requirements, deliverable, delivery environment, end user, measure, measurement, process context, service agreement, service catalog, service incident, service level, service level agreement, service level measure, service line, service request, service requirements, service system, service system component, service system consumable, solicitation package, supplier agreement, system of systems, technical performance, and technical performance measure.
The following terms were removed from the glossary: addition, capability evaluation, contractor, COTS, integrated product and process development, performance parameters, product baseline, quality control, and technical data package.
Changes were made to the following terms in the glossary: acceptance criteria, acquisition, adequate, alternative practice, appropriate, as needed, CMMI model, CMMI Product Suite, configuration status accounting, derived measure, derived requirements, design review, development, development plan, document, enterprise, establish and maintain, functional analysis, generic practice elaboration, lifecycle model, nontechnical requirements, observation, organizational unit, planned process, process area, process measurement, process performance, process-performance model, product lifecycle, product-related lifecycle processes, project, prototype, quality, reference model, requirement, risk management strategy, senior manager, service, standard, statement of work, statistical process control, subpractice, sustainment, systems engineering, tailoring, and validation.