Digital Intelligence & Forensics
Measurement & Analysis
Performance & Dependability
Process & Performance Improvement
Security & Survivability
NEWS AT SEI
This article was originally published in News at SEI on: March 1, 2005
My last column focused on appraisals, and now is a good time to update you on where we see ourselves going with the CMMI Product Suite. This is the first in a series of columns to provide you a broad understanding of what will be included-and what will not be included-in V1.2.
In this first segment, let me first review our process. In our preparation for V1.2, we used the change request (CR) process to identify the potential areas for improvement. For major decisions, we provided decision papers to the CMMI Steering Group to get strategic direction. We then created change packages with more detailed proposed conceptual solutions, always tied to CRs we received, that required review and approval by our multi-organizational Configuration Control Board (CCB). All of the proposed changes have now been approved, and we have begun the task of making changes to the CMMI Product Suite documents. Once these changes are redlined, we will return implementation packages containing these changes to the CCB to get its approval for each of the process areas.
As we began our investigation of improvement possibilities, we determined that we needed to be able to accommodate expanded enterprise coverage without continually increasing the size of the models that organizations need to guide their part of the work. While we could easily imagine gathering best-practice inputs to guide process improvement across more of the life cycle and into new domains, we needed to examine our architectural approach. One element of this review will be seen in V1.2, as it helps to clarify the current material.
In the existing models, we describe the total collection of best practices for product development as "CMMI-SE/SW/IPPD/SS." We described each of the bodies of knowledge comprising existing models as "disciplines." While systems engineering (SE) and software engineering (SW) are bodies of knowledge that can stand alone or with other bodies of knowledge, integrated process and product development (IPPD) and supplier sourcing (SS) are somewhat different and must be combined with SE, SW, or both. So with V1.2, the full development collection will be described as "CMMI-SE/SW+IPPD+SS." We believe this new way of naming CMMI models will also make the differences between models within the development collection easier to recognize. Organizations choosing to address the engineering disciplines all use the same set of practices. Those who wish to add IPPD or SS coverage add practices and goals to cover these environments.
This architectural change is a small one for V1.2, but it has larger implications because it helps position the CMMI model framework for future expansion. We are calling these future collections of models "constellations." The current collection of CMMI models comprises the development constellation. As the product suite expands to new constellations, we will seek to maximize the commonality among all future and current constellations to allow the generation of multiple model variations.
The first expansion beyond the development constellation was already approved by the CMMI Steering Group. This new constellation will address services. The release of the service constellation will occur after the release of V1.2, so I will not discuss the details here. Suffice it to say that this is the first approved expansion, and its release will occur a few months after the release of V1.2. At that point, we will have a "CMMI-Development" family of models and a "CMMI-Services" set. We envision that most of the process areas will be identical for both collections, but some process areas will be unique to Development and others to Services. The initial investigation suggests that the Process Management, Project Management, and Support process areas might be common across both collections, with only the current Engineering group being the place for selected process area replacements for CMMI-Services.
One expansion that the Steering Group has approved is actually a clarification-coverage of the hardware discipline. In some organizations, hardware development centers are not being included within the scope of CMMI-based process improvement because of perceptions that the models are "just for systems engineering and software engineering." We are planning to add informative material in amplifications, typical work products, and examples that apply specifically to those engineers producing the hardware elements of software-intensive systems. We found that these additions better covered product development as a whole and improved the recognition that development efforts must plan appropriately for production.
Another expansion we will include in V1.2 is a broadening of CMMI coverage of the development environment. Currently, the Organizational Environment for Integration (OEI) process area provides some coverage of these processes, and other process areas provide some additional information. However, one of the source models for CMMI, EIA 731, contains additional practices covering the engineering environment [EIA 98]. Furthermore, CRs have indicated that coverage of the work environment is desirable to address safety and security. A few provocative CRs have suggested that we need to include some of the best practices associated with "business continuity," particularly after experiences or organizational shocks such as the September 11 disaster. We determined that the kind of expanded coverage we provide for IPPD in the Integrated Project Management (IPM) process area was a good model for the approach. A potential new process area, "Work Environment," (WE) has been proposed to include the OEI practices and goals as IPPD additions. I'll discuss more about the final approach we take in my column in the next issue.
First, we think that presenting both the staged and continuous representations in one document reduces one aspect of model complexity. The dual-representation book version of CMMI [Chrissis 03] contains the same total number of pages as a previous model that includes only one representation. We are pleased with this outcome.
We are removing two components from CMMI models: advanced practices and common features. These are legacy artifacts from two CMMI source models that complicate the depiction of the material and no longer serve the purpose they once did in their sources. Advanced practices are artifacts inherited from the EIA 731 source model, and common features are artifacts inherited from the SW-CMM source model [SEI 95]. While each of these components has had value in V1.0 and V1.1, the need to use them in the continuing depiction of the CMMI model (2006 and beyond) appears marginal and outweighed by the potential for simplification. Generic practices will continue as the main measure of capability levels but will not be characterized by their common-feature identifier.
In addition to simplifying the numbering scheme, several practices that were base practices in the continuous representation will no longer be in the document. Instead, the base and advanced pairing of practices will be replaced by the advanced practice only. For example, we will describe only "eliciting" requirements, rather than seeking to differentiate (particularly in appraisals) whether requirements have been "gathered" or "elicited."
We investigated combining the two process areas that deal with suppliers-Supplier Agreement Management (SAM) and Integrated Supplier Management (ISM)-but concluded that ISM needed to be addressed in a distinct, proactive manner that deserved separate level-three coverage.
A related clarification is to move the commercial off-the-shelf (COTS) choices from their current location within SAM to a related section within Technical Solution (TS). Many CRs noted that the effort to "select product-component solutions" was a better place to frame the discussion about COTS than its current location in SAM.
With increasing numbers of organizations exploring high-maturity practices, we have been encouraged by CRs to give clearer guidance on what it means to apply the practices summarized in the level four and five generic practices to the various process areas. So we will provide more elaborations in these areas for V1.2.
As you can see, the major purpose of our work for V1.2 is to clarify and simplify, with only limited expansion of coverage. We do not envision the need for anyone who has taken CMMI courses to return for revised training. We do recognize that the changes will require some familiarization and perhaps some minor adjustment to mappings or practice implementation indicator documents (PIIDs). Therefore we will establish a period of continued support for V1.1 appraisals to minimize any disruption with the change.
In the next quarterly column, I'll be able to provide more detail on the changes for V1.2, as we prepare to pilot the proposed update.
Chrissis, Mary Beth; Konrad, Mike; and Shrum, Sandy. CMMI: Guidelines for Process Integration and Product Improvement. Boston, MA: Addison-Wesley, 2003.
Mike Phillips is the Director of Special Projects at the SEI, a position created to lead 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, OH. In addition to his bachelor's degree in astronautical engineering from the Air Force Academy, Phillips has masters 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.