NEWS AT SEI
This library item is related to the following area(s) of work:CMMI
This article was originally published in News at SEI on: July 31, 2009
The CMMI Steering Group has approved criteria for the next release of the CMMI Product Suite. This column will describe the key ingredients and the plans for release of CMMI Version 1.3.
In the last column, I described the need to clarify the coverage of high maturity practices in CMMI models. Initially we created and reviewed model updates that we felt could be released as CMMI Version 1.2A. This version, considered a minor update, would include updates made only to informative material.1
These model updates were reviewed by CMMI High Maturity Lead Appraisers and the CMMI Steering Group at a workshop in late September 2008. As a result of the review, the Steering Group determined that modernizing the practices for maturity levels 4 and 5 was a better choice than a more limited attempt to clarify practices by updating only informative material. So rather than releasing a CMMI for Development V1.2A, we instead are including these and other updates to address the coverage of high maturity practices in the planned release of CMMI V1.3 for all three constellations—Development, Services, and Acquisition
Over the last few months, the CMMI Product Team has reviewed more than 1,150 change requests for the models and 850 for the appraisal method. Teams were formed to initiate the development of CMMI Version 1.3, and the Steering Group has provided criteria to guide the range of acceptable product suite updates. The criteria are in Figure 1 below.
As mentioned in the previous column, a clear focus of current model development is on clarifying the practices associated with high maturity for organizations using the staged approach—and high capability in process areas for organizations using the continuous approach. The CMMI Product Development Team has formed a High Maturity Team. This team’s members are focusing on making these changes. A team lead was chosen from industry participants to ensure that the improvements made are representative of current best practices in the community.
The redlines produced in the effort I mentioned earlier are only a part of the full array of change requests now available to assist this team in its improvement effort. This team’s work focuses on the four high maturity process areas: Organizational Process Performance (OPP), Quantitative Project Management (QPM), Causal Analysis and Resolution (CAR), and Organizational Innovation and Deployment (OID).
As we leveraged the content of the CMMI-DEV V1.2 model to create two new constellations (Services and Acquisition), we modernized some of the material in the 16 core process areas that are common to all three constellations. This modernization meant that we knew we had to eventually revisit CMMI-DEV and modernize it as well. Even though we allowed some differences between the constellations, some of the differences can be harmonized to make the three constellations more consistent and able to be used together.
For example, we have two different approaches to integrated teaming in CMMI models: in CMMI-DEV, teaming is covered in two goals that are treated as optional, or additions; in CMMI-ACQ and CMMI-SVC, teaming is covered in two specific practices in two process areas (OPD and IPM). These practices are expected model components and therefore not optional. In CMMI V1.3, we will determine how best to provide teaming information in a single approach in all three CMMI constellations. This work to ensure commonality of the approach to teaming has gained importance since the Team Software Process has demonstrated the performance potential of high-performing teams.
CMMI models are now available in several different languages. The teams that created these translations have requested that we improve the models’ ease of translation. A simple example of changes we can make to the model to ease its translation is eliminating the use of words such as “stovepipe,” which is difficult to interpret into different languages appropriately because its literal meaning is different from how we use it in CMMI models.
A number of change requests have suggested further expansion of CMMI models in new directions. We do not see this release as being suitable for major expansions like the ones we had with the two recent constellations, but we will likely add some of the current information on architecture, software assurance, Agile, and Lean Six Sigma. We’ve also been encouraged to add more emphasis on activities to assure customer satisfaction. These types of expansions assist in the modernization of model coverage without adding new process areas.
Many students taking either of the one-day Supplement courses that cover acquisition or service delivery have commented that many organizations span more than one area of interest. One theme for the V1.3 release is to enable as much sharing of best practices across the constellations as possible. An earlier CMMI in Focus column described our current thinking about joint appraisals. Given some effective pilots, we plan to improve the SCAMPI Method Definition Document to facilitate appraisals that use process areas from multiple constellations.
When we modified the appraisal method associated with the SW-CMM from its discovery focus to a verification focus, it was intended to save appraisal time. The Practice Implementation Indicator Documents (PIIDs) were introduced to reduce on-site appraisal time. However, if organizations are spending excessive time preparing PIIDs, we need to examine ways of upholding appraisal confidence without driving up preparation expenses. The SCAMPI Upgrade Team is looking for innovative ways to achieve this goal.
To meet the fourth criterion that limits the overall size of CMMI models, we are looking for ways to balance model additions with deletions. We received change requests resulting from an effort collecting input from multiple lead appraisers that many of you know as ATLAS, which was sponsored by Pat O’Toole. This group submitted change requests that identified some lower-value practices that might be removed to add others now viewed as more important. As mentioned above, additional process areas will not be encouraged for V1.3.
Given the number of change requests and the span of contentious issues to be resolved by the teams, we have not yet decided on a release schedule for the various elements of CMMI Version 1.3. The Steering Group has approved our proposal to assure a significant period of overlap between the release of CMMI Version 1.3 and the sunset of CMMI Version 1.2. We are also investigating innovative ways of providing information about CMMI improvements to you in draft form. However, we do not encourage you to delay process improvement by waiting for the release of the next version.
Some of you reading this column may be in organizations who can use Version 1.3 development drafts (published monthly during the piloting period) and give us feedback on proposed changes as we move through the upgrade to Version 1.3. These monthly drafts will be available for your review and use from October 2009 through March 2010. If your organization is interested in reporting on its use of draft versions of a CMMI Version 1.3 draft model (CMMI-DEV, CMMI-ACQ, CMMI-SVC) during this period, contact SEI Customer Relations (email@example.com). We will send you details of how you can receive the drafts and how we will be collecting structured feedback from you.
After the release of CMMI V1.1, we began to consider future release strategies. The Steering Group agreed that CMMI versions should be released approximately three to five years apart to allow sufficient time for organizations to understand and deploy healthy approaches in reasonable improvement cycles. Version 1.2 was at the higher end of that range. Version 1.3 may be closer to the lower end. The concerns about the clarification of high maturity practices and for commonality across the three constellations suggest that the timing of a late 2010 release is sensible.
1 All CMMI model components are grouped into three categories: required, expected, and informative. Unlike the required and expected model components, the informative model material is not considered normative.
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.
The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.
For more information
Please tell us what you
think with this short
(< 5 minute) survey.