NEWS AT SEI
This article was originally published in News at SEI on: May 1, 2006
As planning began for CMMI Version 1.2, the CMMI Product Team recognized that future expansion of CMMI coverage needed in domains closely related to development, such as services and acquisition, might require adjustments to the architectural approach used for CMMI V1.0 and V1.1. Following is the information you’ll need to understand these changes.
Because of the creation of CMMI models for services and acquisition, what I have been calling CMMI Version 1.2 in my recent columns has been renamed CMMI for Development (CMMI-DEV). Besides this name change, the modifications made to this model are quite small. A single model for development, scheduled for publication this year, provides amplifications for the systems engineering, software engineering, and hardware engineering disciplines. IPPD coverage will be included in the model as an addition. (In V1.1, IPPD was a discipline.) The CMMI Development Team also simplified and consolidated the coverage of both IPPD and Supplier Sourcing in a way that eliminates the need for three process areas:
With the first two releases of CMMI, it was important to recognize the distinctions of the specific disciplines and to recognize the heritage of the improvement models for each of the disciplines. However, these distinctions have now become less important, and the unifying engineering-development processes have demonstrated synergies that go beyond the original source models. The team also received requests from users and the CMMI Steering Group to simplify the material. The increasing number of possible variations (and therefore printed models) to address the various combinations of existing engineering disciplines made movement in that direction undesirable. Consequently, we added amplifications for hardware-engineering examples but chose not to call out another model variation in the model name. Nor are multiple models available for users to choose from. Instead there is one integrated model containing the best development practices.
As we began to consider future coverage of organizational process improvement, we sought to maintain the greatest possible commonality among all the models created from the CMMI common framework of best practices. The figure below depicts this commonality along with needed specificity. This provides a way to avoid having any CMMI model grow too large for effective use.
Based on the initial efforts to maximize commonality among CMMI models, 16 of the 22 process areas of CMMI-DEV comprise the process improvement core for the three areas of interest currently being pursued: development, acquisition, and services. These 16 process areas (in alphabetical order) are
We use the word constellation to refer to a set of model components, training materials, and appraisal documents in the CMMI Framework that covers an area of interest, such as development, services, or acquisition. Each constellation includes the 16 common process areas above, with additions unique to the area of interest, or shared across some, but not all, of the constellations.
We recognized that even with common process areas, we needed to allow some flexibility. None is allowed, however, for the “required” (goals) or “expected” (practices) levels of the 16 core process areas. Additions to these process areas will be allowed, just as the IPPD addition is allowed and encouraged in the Development constellation. In the informative material, we allow a little more flexibility so that typical work products can be added or substituted to fit a process area in each constellation. The only other substitutions or deletions allowed within the 16 core process areas will be at the level of the informative material judged specific to development. This occurs in the current model in subpractices, where development-specific explanations are often found. These statements may be tailored to the needs of the new constellation and include informative paragraphs below sub-practices and generic practice elaborations.
More tailoring is permitted to describe activities captured primarily in the Engineering process areas of CMMI-DEV. While some of the constellations may share components with the Engineering process areas in CMMI-DEV, the shared material may be arranged and grouped differently to meet the needs of the constellation’s user base. If these adjustments change the process area in any significant way, the process area will be given a different name to avoid confusion in use, training, or appraisals. If a particular PA can be shared by two constellations, these PAs will be designed to capture that commonality as well. (For example, the existing VER or VAL might be usable in one of the future models but not in others, so it would be shared across two constellations.)
Teams that are setting out to develop their own internal expansions of the CMMI Framework can request a more detailed version of the CMMI architecture to assist in their development efforts—but all users should understand the broad approach we have put in place to create an architecture that allows flexibility of coverage while preserving the key ingredients of commonality to assure adequate stability across the set of emerging constellations.
As the director of special projects at the Software Engineering Institute, Mike Phillips leads the Capability Maturity Model Integration (CMMI) project for the SEI. He was previously responsible for transition-enabling activities at the SEI. Prior to his retirement as a colonel from the Air Force, he managed the $36B development program for the B-2 in the B-2 SPO and commanded the 4950th Test Wing at Wright-Patterson AFB, Ohio. In addition to his bachelor’s degree in astronautical engineering from the U.S. Air Force Academy, Phillips has master’s degrees in nuclear engineering from Georgia Tech, in systems management from the University of Southern California, and in international affairs from Salve Regina College and the Naval War College.
For more information
Please tell us what you
think with this short
(< 5 minute) survey.