NEWS AT SEI
This article was originally published in News at SEI on: December 1, 2002
Because we get a lot of email, visit a lot of conferences, and teach CMMI1 courses, we get a lot of “messages from the field.” In this quarter’s column, we summarize and comment on some of the messages we have received.
It Is “Process Improvement,” Not CMM vs. CMMI
Increasingly we are seeing both the legacy SW-CMM2 and the CMMI upgrade being mentioned together in documents such as abstracts for SEPG. This mention of both CMM-based products together makes sense. The motivation behind upgrading SW-CMM Version 2, draft C to CMMI was not that there were major flaws in the trusted SW-CMM, but that more had been learned about software engineering best practices during its use. Continuous improvement has been the goal for using the CMMs, and they in turn have needed updating as our knowledge grew. One might view this element of change to be “vertical,” as it strengthens the understanding of key concepts such as measurement and analysis and risk management. So in this dimension,, CMMI offers modernization and greater clarity. But there was also the growing recognition that the power of process discipline was enhanced by involving more of the organization. This led to attention in the “horizontal” direction. Here, CMMI offers expanded breadth of coverage, since the rest of the organization can no longer say, “Oh, that’s just for the software group.” For those who need better coverage across the organization, the “I” in CMMI stands for “Integration,” but for those who have brought the organization into healthy examination of its process capability and maturity with the SW-CMM, the “I” may also be defined as “Improved.”
Our initial thought was that CMMI would be used in the same fashion as the SW-CMM. But some innovative uses of CMMI have come to our attention. For example, a large, global, multiproduct development organization has used CMMI to examine its approach to life-cycle management. This use of CMMI was not done to establish a benchmark, but as a checklist to ensure adequate coverage of life-cycle processes at the corporate level. Best practices critical to achieving corporate objectives for communication and product development could be identified and institutionalized across all corporate units using CMMI. Another example involved an organization that chose to appraise its developmental risks. A risk taxonomy based on CMMI was used to probe the areas that posed particular difficulties for the project investigated.
A joint government and industry team examined ways to reduce the impact of repeated government evaluations supporting source selections. A recent SCAMPI3 appraisal provided an opportunity to test an idea that the team had considered: having government participation on an industry appraisal, rather than performing an additional independent evaluation. Two government evaluators, trained in both CMMI and SCAMPI, joined an industry appraisal team for the industry site SCAMPI. At the end of the SCAMPI, the government appraisers provided a letter to the SEI indicating that they had participated in the SCAMPI and agreed with the findings. Government participation in scheduled improvement appraisals offers a way to address the need for ensuring a level playing field of contractors for government procurement of software-intensive systems, while giving the confidence associated with government involvement. If this practice is encouraged within the DoD, a proposing contractor will be able to provide evidence that the government had participated in a recent appraisal. This could be considered sufficient to avoid the need for Software Capability Evaluations (SCEs) or Software Development Capability Evaluations (SDCEs) for those contractors.
We frequently hear requests for coverage of “hardware engineering.” Most often that request refers to the hardware directly associated with software-intensive systems. At various presentations, attendees have noted the emphasis on systems engineering and software engineering. Some have asked about “the rest of the system.” Many specify that they mean “hardware engineering.” These questions usually come from computer-systems companies. The engineering discipline most often described is electrical engineering for the hardware associated most closely with the software. Pending a further update to CMMI models, likely a few years away, organizations are encouraged to use the flexibility of the Microsoft® Word versions of CMMI models to insert typical work products or sub-practices that cover elements in the organization that have not seen their material included in the informative components of CMMI models. At the SEI, we also encourage the production of supplemental reports that can help organizations pursue process improvement in new areas without increasing the size of the model documents. If your organization has best practices that can aid us in expanding our coverage, we would welcome your submissions.
Some readers have pointed out errors in the text of the CMMI documents. We regularly update an errata sheet and post it on the CMMI Web site. This practice allows us to avoid republication, while enabling us to catch errors that eluded us before publication of V1.1. In addition, readers have noted that some concepts may have been captured in one Process Area (PA), but are less clearly covered in another related PA. An example of this is coverage of technical performance measures. These measures are specifically mentioned in the Requirements Development PA, but not in the closely related Technical Solution PA. The CMMI model authors were often torn between the desire for absolute consistency across the PAs and the desire to avoid repetition. Care was taken to ensure that key concepts were addressed at each level of increased capability or maturity, but repetition across closely related PAs was not enforced. Another reader noted that test plans, explicitly discussed in the SW-CMM, were not emphasized across CMMI PAs They are mentioned in the Requirements Management and Configuration Management PAs, but not, ironically, in the Verification PA. This was another example of an idea fully endorsed by CMMI authors, but not called out with the frequency desired by experts in the test discipline. Cases like this are sometimes better addressed with updates to the Frequently Asked Questions (FAQs), but change requests will be held for the next CMMI model update, which will happen no earlier than 2005.
“Technical Notes du Jour”
One of our commitments at the SEI has been to add informative elements around the basic building blocks of the product suite—the models, appraisal method, and training program. Three new technical notes are now available from the CMMI Web site. A technical note by Brian Gallagher describes how CMMI might be interpreted for use in operational organizations; one by Larry Jones describes how CMMI supports organizations that have recognized the power of product line strategies for their development efforts; and a third technical note by Paul Solomon describes the synergy between CMMI and earned value management. Other technical notes currently being prepared cover how CMMI applies in service and sustainment organizations, how modern knowledge management practices can assist the employment of CMMI, and how areas such as security and safety engineering can be addressed using CMMI.
Ease of Upgrade
At the recent annual CMMI Technology Conference, several companies and lead appraisers described their move to CMMI. One described the long-term value of having gathered the Process Improvement Indicators, as those will help to guide future improvement. Another noted the relatively small additional effort (about 22 staff-days) to provide this enhanced picture of the process improvement effort. Another noted the enhanced business case analysis for CMMI over the SW-CMM, because applying process discipline across the rest of the development organization multiplied the favorable impacts on test time and defect-reduction activities.
As time goes on, the character of the CMMI Product Suite will build and develop based on what you, the community, find useful about it. The messages you send us will shape how CMMI can meet organizations’ needs and influence the practice of software engineering throughout the world.
About the Author
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.
1 Capability Maturity Model Integration
2 Capability Maturity Model for Software
3 Standard CMMI Appraisal Method for Process Improvement
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.