NEWS AT SEI
This article was originally published in News at SEI on: April 1, 2005
Before Version 1.0, the CMMI Product Team used a large stakeholder group to provide feedback on early draft versions of the model. These early versions were not yet ready for release, and comments from the stakeholder group were often wide-ranging in seeking to set the broad course for combining the best parts of three distinct source models:
- Software CMM Version 2, draft C (this version was never publicly released, but it improved on the widely used SW-CMM Version 1.1)
- EIA Interim (at the time) Standard 731 (this standard brought together two concurrently developed systems engineering models)
- Integrated Product Development CMM (this CMM reached a draft Version 0.98 but was never publicly released)
These were lively days. We wrestled with whether to continue a process area for peer reviews that was strongly desired by the software community and whether to add a process area for data management that was strongly desired by the systems engineering community.
With the baseline release of CMMI Version 1.0, we instituted a more formal mechanism for change. The CMMI Steering Group created a Configuration Control Board (CCB) with a majority of the membership from outside the SEI to help us judge the community's tolerance for-and interest in-change. We formalized the change-request system with automated support to help us keep track of the requests for change to CMMI models, the SCAMPI appraisal method, and the CMMI training courses. When we developed the current Version 1.1, we used change requests from all sources and also announced a formal review period to stimulate reviews by various organizations that used such review mechanisms in their standards work.
The criteria that our steering group provided for the development of Version 1.1 meant that many of the aggressive changes recommended by some reviewers would not be allowed for that version. But rather than rejecting those change requests, we kept them in the change-request system and marked them "deferred." These change requests would be reviewed and analyzed again for future product-suite updates.
The CR Process for V1.2
While the release plan for Version 1.1 was to provide a mature, fully operational version that we knew deserved a rather quick release (one year after V1.0), the intent was to then stabilize use of V1.1 for an extended period-three to five years. Our collection of change requests was maintained and began to grow. We allowed for modest change by maintaining a collection of errata. This collection largely consisted of typographical errors, but sometimes included changes to text that we realized was particularly misleading. The publication of CMMI: Guidelines for Process Integration and Product Improvement by Addison-Wesley also allowed the discovery of a few more corrections that we captured in errata and made available on the SEI Web site.
We spent about a year seeking feedback from a wide range of users through the CMMI Interpretive Guidance Project to see which concepts were being easily understood and which were more difficult for adopters. Sometimes the difficult concepts actually involved understanding the differences between concepts in a source model (e.g., Software CMM) and the concepts in the CMMI model; other difficult concepts involved understanding the greater breadth of coverage of the enterprise development effort offered by CMMI.
When we began analyzing the change requests for the model, we had a varied collection of requests. Some were several years old-requests deferred from the V1.1 update; some were notes or issues elicited as part of the CMMI Interpretative Guidance Project; some were received as part of the formal review period; and others were change requests that were submitted by individuals and groups at various times after the release of Version 1.1 as they used the product suite and saw opportunities to improve the material.
The model team examined all of these change requests and addressed as many of them as possible. At the same time, the team also needed to abide by the criteria for Version 1.2 provided by the CMMI Steering Group. These criteria were to assure that the upgrade from existing material does not constitute a radical change in the product suite that might require major revision in existing improvement efforts or additional training for users.
One lesson that we've learned from this analysis of change requests is that maintaining deferred change requests can be problematic. Some change requests were deferred from the development of Version 1.02. Could we be sure that someone who expressed the wish for a change in 2002 while using CMMI Version 1.02 would want the same change in 2005 using CMMI Version 1.1 and with more experience and familiarity with the concepts?
Administration of the change-request management system has also had its challenges. We have been successful in assuring that every change package we prepare for CCB consideration is based on submitted change requests, not just a desire of model team members. But often change requests in a given area recommended remedies different from those proposed by the model team in the change package. In some cases, this has meant that a requested change has been approved while the proposed remedy was rejected. Further, it was not uncommon for change requests to have multiple ideas submitted on one form, so that a portion of the change request could be addressed in the current development cycle, while another portion was rejected or deferred. This situation made the dialogues between the model team and the CCB challenging at times, even though the change-request system allowed for change requests to be subdivided if needed.
To date, we have not been able to determine an efficient method to advise the many change-request submitters about the status of their recommendations. We have, however, been able to send an automated response to each submitter that his or her change request has been received into the system.
A query of our change-request database shows that of 1001 change requests considered for V1.2, 360 were approved to provide inputs to the change packages; 590 were rejected, and 51 were beyond our ability to include in V1.2. The various ways that all, some, or none of the proposed content will be seen in the upcoming version makes describing a specific change request as approved, rejected, or deferred beyond V1.2 difficult to characterize. Often proposed change requests that were "rejected" influenced the wording chosen for "approved" changes.
We would love to conclude this column with a statement that each of you who devoted time and effort to send us your thoughts for improvement would be able to know precisely where and how your recommendation was accommodated in the update. But as you have read above, we have not created the mechanisms for that level of confirmation. We can assure you that we read, analyzed, considered, and debated all of your submissions and that they influenced the model team in its deliberations. Just as we found many opportunities to improve from V1.1, we know that the future will include further opportunities to enhance the approach to CMMI-based process improvement and enhance the quality of our future and existing software-intensive systems.
In the next column, we'll be able to provide more detail on the changes for V1.2 as we prepare to pilot the proposed update.
Electronic Industries Alliance. Systems Engineering Capability Model (EIA/IS- 731). Washington, DC, 1998.
Software Engineering Institute. The Capability Maturity Model: Guidelines for Improving the Software Process. Reading, MA: Addison-Wesley, 1995.
About the Authors
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.
Sandy Shrum is a senior writer/editor at the Software Engineering Institute. Since 1998, she has served on the CMMI Product Team in roles such as author, reviewer, editor, and quality assurance process owner. Sandy also serves on the CMMI configuration control board and is the CMMI communications coordinator. She has over sixteen years experience as a technical communicator in the software industry. Sandy earned her MS in professional writing from Carnegie Mellon in 1988.