Aspects of CMM

Roy Thelin

Mark Paxton, FAC

CMGT/555 - Systems Analysis and Development

13 October 2004

University of Phoenix Online
Introduction

The Capability Maturity Model (CMM) is more than a theoretical outline of how to improve development processes. “According to the Carnegie Mellon University Software Engineering Institute, software CMM is a common-sense application of software or business process management and quality improvement concepts to software development and maintenance. It’s a community-developed guide for evolving towards a culture of engineering excellence, model for organizational improvement. The underlying structure for reliable and consistent software process assessments and software capability evaluations” (“Capability Maturity Model”, 2004).

SW-CMM provides a way to gauge the maturity level of an organization’s software development efforts. Some aspects of CMM that are particularly interesting are its level of acceptance, hierarchal design and target improvement area.

Acceptance

CMM was first developed for the military. “It has been used extensively for avionics software and for government projects since it was created in the mid-1980s” (Wikipedia, 2004). The government in-turn wanted contractors to develop software at a known and measurable level. This led to implementation of SW-CMM across a broad range of businesses that wanted to show, in a meaningful way, the quality of their development efforts. Foreign companies that wanted to compete for outsourcing contracts also implemented CMM as a way to prove the quality of their development process.

This is interesting because of the contradiction in company objectives it imposes. A software development company wants to develop high quality software at a reasonable price and in a short amount of time. The CMM requires a tremendous amount of documentation, testing and evaluations that slow down the actual production of software. “Another issue is that most implementations of the CMM drive organizations to produce more documents, more checkpoints, more artifacts, more traceability, more reviews and more plans. Furthermore, thicker documents, more detailed information and longer meetings are considered better” (Royce, 2002).

Design

CMM defines five levels of software process or development maturity. Each level has certain key process areas (KPAs). An organization’s support of these KPAs defines which level of CMM the organization is at. While an organization may support KPAs of a higher level, it is considered to be at the level in which it supports all of the associated KPAs. This is analogous to normalization in database design, where the database is considered normalized to the level at which it implements all of the requirements, even if it includes a subset of a higher level.

Figure 1 : SW-CMM (Key Process Area, 2004)

One of the criticisms of CMM is “that it ignores the possibility that a single group may exhibit all of the behaviors and may change from behavior to behavior over time” (Wikipedia, 2004). This means that a company could be evaluated at CMM Level 3 but produce anywhere from Level 1 to Level 5.

There is also the requirement for a group to mature or work through each level, a very time consuming process. At the average of 18 months per level, it would take a group 5 years to reach Level 5. Given today’s constant turnover in employees, it would be extremely difficult to ever reach above a certain level. Companies that subscribe to CMM consider Level 3 to be the obtainable or sustainable goal.

What makes the design of CMM so interesting is that the companies that have implemented it have been able to achieve dramatic improvements in their development processes. This means that coding errors were reduced and project timeframes were much more accurate.

Improvement Area

“The Capability Maturity Model for Software (CMM), developed by the Software Engineering Institute, and the ISO 9000 series of standards, developed by the International Standards Organization, share a common concern with quality and process management. The two are driven by similar concerns and intuitively correlated” (Paulk, 2004). The key words here are process and quality.

Neither the ISO 9000 nor CMM adequately addresses the issues surrounding the quality of the product produced or organization. They both address process, doing the job right in a measurable and repeatable way. It is still possible to develop software that does not sell.

At the same time, CMM does not define how a company or group should be organized to produce quality software. As long as the KPAs are satisfied, management is left to work on their own organizational issues.

So, the issue of quality software is not demonstrated by the product produced or the producers of the product. The whole concentration is on development of a quality production process. This is a particularly interesting point that probably contributed significantly to the replacement of SW-CMM with the newer Capability Maturity Model Integrated (CMMI).

Conclusion

CMM was introduced at a time when quality improvement was a very strong initiative in the United States. The thinking being that a high quality process would produce a high quality product. Unfortunately, while the quality standards rose, the need to produce products in ever shorter amounts of time provided competing priorities. Furthermore, organizations like the military could emphasize quality in its processes since it is not a profit producing organization.

The lack of support for the actual product produced and the burden of oversight requirements led to a rethinking of the CMM. That, in-turn, has led to the retirement of CMM support by the SEI, in favor of CMMI, the latest way to do things right.

In an era of unemployment, under-employment and a nomadic workforce, the cost of the delivered product has to be kept at a level that will make it marketable. In order to stay ahead or even with the competition, software developers have to be able to deliver products in ever shorter development cycles. Cheap and fast are not the earmarks of high level CMM produced products.

References

Capability Maturity Model (CMM) Key Process Area (KPA). (2004). Six Sigma Tutorial. Retrieved from http://sixsigmatutorial.com/CMM/CMM-Key-Process-Area.aspx on October 13, 2004.

Paulk, M. (2004). A comparison of ISO 9001 and the Capability Maturity Model for Software. Carnegie Mellon Software Engineering Institute, (2004). Retrieved from http://www.sei.cmu.edu/publications/documents/94.reports/94.tr.012.html on ,October 13, 2004.

Royce, W. (2002). CMM versus CMMI: from conventional to modern software management.

The Rational Edge (February, 2002). Retrieved from http://www-106.ibm.com/developerworks/rational/library/content/RationalEdge/feb02/ConventionalToModernFeb02.pdf on October 13, 2004.

What is SEI Capability Maturity Model (CMM). (2004). Six Sigma Tutorial. Retrieved from http://sixsigmatutorial.com/CMM/CMM-Intoduction.aspx on October 13, 2004.

Wikipedia, (2004). Capability Maturity Model. Wikipedia. Retrieved from http://en.wikipedia.org/wiki/CMM on October 13, 2004