Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Practical CMM

, March 01, 2001


March 2001: Practical CMM

The capability maturity model (CMM), developed by the Software Engineering Institute (SEI), is a model to help software organizations improve their development capability. Acceptance and use of the CMM for process improvement varies greatly in the industry—some use it as an optional guideline, while others revere it as gospel. When used appropriately, CMM can help organizations develop software with predictable cost, schedule and quality. When used inappropriately, it can waste an entire organization's time.

Many organizations approach process improvement by simply documenting each and every process. This process-centric approach may be amplified when an organization attempts to adopt a more sweeping and systematic technique for improvement such as ISO9001 or the CMM. In light of a process-centric goal stating, "Be SEI CMM Level 3 by December," the approach of documenting all processes is reinforced and might even appear natural. A process-centric approach can work, but it has a high risk of failure because most people mistake documentation for progress. The improvement effort isn't integrated with the organization's product development goals, and this usually results in a large stack of unused process documents.

The capability maturity model (version 1.1) consists of five levels of engineering and management process maturity, each level building on the next. CMM Level 1 has no criteria and represents projects that typically have large amounts of rework, numerous technical surprises, frustrated customers, and significant cost and schedule overruns. Good software can come from a CMM Level 1 organization; however, this result isn't easy to achieve or sustain. CMM Level 2 comprises sound project management, negotiations with the customer, version control, vendor management, and simple process and product assurance. Organizations at CMM Level 2 can focus on product development rather than day-to-day crises. CMM Level 3 focuses on organization-wide engineering skills, basic systems engineering, advanced project management, and an infrastructure to support sustained improvement. Organizations at CMM Level 3 consistently produce reliable software on time. A complete copy of the CMM can be found at www.sei.cmu.edu/pub/documents/93.reports/pdf/tr24.93.pdf.

Goal-Problem Approach
An alternative to the process-centric approach of improvement is to scope your improvement program based on the problems and goals of your organization. Adopting this approach enables you to make significant progress on real issues and make headway using the CMM.

Examples of an organization's business goals include the delivery of a product, the completion of a software installation or the upgrade of a database. The goal could also be the desired outcome when a critical problem has been solved. For example, an organization may be unable to hit delivery deadlines, or it might spend 75 percent of its resources on rework. The related goals to these problems would be meeting deadlines 100 percent of the time or reducing rework to 25 percent.

To use the goal-problem approach, first determine your organization's business goals and problem areas, and then compare these to the elements of the SEI CMM. Select the appropriate elements of the CMM that address these problems and help you move towards your goals.

During one session to help a company plan an improvement program, we learned that the organization was about to form six teams to work on the six key process areas (KPA) of CMM Level 2, which are requirements management (RM), software project planning (SPP), software project tracking and oversight (SPTO), software configuration management (SCM) and software quality assurance (SQA). The key process areas of CMM Level 3 are training programs (TP), software product engineering (SPE), peer reviews (PR), intergroup coordination (IC) and integrated software management (ISM). We suggested that the developers and managers temporarily forget about reaching CMM Level 2 and instead state all the major product development problems they currently faced. Then we asked them to list the business goals they were trying to achieve over the next six to 18 months. These two independent lists are shown in Table 1.

We then compared their problems and goals with the practices in SEI CMM Levels 2 and 3 and placed the related KPA names and activities in parentheses after each item (Table 1). These activities are small solutions that address the problems and support the goals. (If the company had been using ISO9001 or the Malcolm Baldrige Award, we would have mapped the problems and goals to those criteria.)

What was the scope of the improvement program? To address the problems and the goals of the organization. As you can see, 21 out of the 23 items (91 percent) map to CMM Level 2. When all the problems and goals have been addressed, 46 percent of the CMM Level 2 activities will have been addressed.

The essential difference between this approach and addressing the six KPAs in parallel is that the problems and goals indicate which pieces of each KPA you should address first. Regardless of whether your organization is using SEI CMM ISO9001 or another model or standard, the problem-goal approach will help scope and sequence your improvement program.

Items that Don't Quite Fit
Not every problem in Table 1 exactly matches the key process areas of CMM Level 2. For example, there isn't much in the CMM to help this organization specifically address the fifth goal, improve performance of core software product. In this situation, you must determine which areas are the most important for the organization to fix now. Serious problems should be worked on first,


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.