Nov 20, 2008

CMMI - Misunderstandings and Abuses

I was reading White paper, CMM & CMMI - Show me the value! by Mr.Alan Koch, Global Knowledge Instructor, PMP. found very intresting and Thought of sharing some of the very known CMMI Misunderstandings and Abuses.

Misunderstandings

Many people who open the CMMI book are immediately overwhelmed by the volume of information: five Maturity Levels, two Generic Goals, 12 Generic Practices, 25 Process Areas, 55
Specific Goals, 185 Specific Practices, hundreds of Sub-Practices—nearly a thousand pages
in all! It is hard to blame them for feeling that this model must be way too restrictive to be
applicable to a real-life organization.

Yes, the CMMI contains a lot of information. But the majority of it is just that, only information.
For organizations that must achieve a CMMI rating, the Goals are most important. In order to
receive a Maturity Level 2 rating, the organization must achieve only the 16 Goals for the
seven Maturity Level 2 Process Areas.

The Practices (which are much more numerous) are "expected" elements of the model. That
means that the SEI expects that an organization will have to perform all of those Practices in
order to achieve the Goals. But the Practices are not required. Organizations occasionally
employ "alternative practices" to achieve the Goals, and when they do, that is OK. As long as
each Goal is achieved, the actual Practices that are employed are not an issue.
The Sub-Practices and other information in the CMMI are merely "informative" elements of the
model. That is, they are there to provide additional information to help the reader to understand
the intent of the Goals and Practices. There is no requirement (or even expectation) that
an organization will perform all of the Sub-Practices.
Naturally, if your organization is not under a mandate to achieve a Maturity Level rating, then
the Practices, and even the Goals in the CMMI take on more of a suggestive flavor. Of course,
any organization would do well to take them as exceedingly strong suggestions, given the
CMMI’s solid research basis!

Abuses

The SEI designed the CMMI to be a roadmap for process improvement. But what we have seen in practice is organizations requiring their suppliers to achieve specific Maturity Level ratings. This in turn causes those suppliers to turn to the CMMI simply to achieve a rating, even if they have little or no interest in process improvement.

When the CMMI is used by an organization that has no interest in process improvement, its
use can (and often does) become abuse. Processes are written solely to satisfy a CMMI
Appraiser, but with little or no thought for how they will affect the organization's work. Paperwork grows seemingly without bounds, and people feel that they are drowning in "process for process' sake".

In these organizations, the CMMI's primary purpose (a roadmap to improvement) is lost, and it
becomes a straightjacket for the organization and its people. It becomes abusive as it is
abused by those whose primary objective is a Maturity Level rating. And many of these organizations end up with no more than they sought: a Maturity Level rating and process binders sitting on shelves gathering dust while business goes on little improved from its starting point.

For those of us who see the CMMI's potential to benefit those who use it, this is the saddest
and most frustrating thing: to see an organization that goes through the motions of process
improvement, but ends up with only a plaque on the wall and a bevy of disgruntled employees.

It is sad because the benefits are so great when the CMMI is used as a guide to process
improvement, as it was intended! Maturity Level 1 organizations can be frustrating and
exhausting to work in because even when "Heroic Effort" is put forth, project success is often
elusive. This contrasts sharply with moving up the maturity scale by truly improving processes,
which provides significant benefits to the organization.

Nov 12, 2008

ODC: Orthogonal Defect Classification

Ram Chillarege proposed a technique in the early ’90s called Orthogonal Defect
Classification (ODC), as a way of categorizing defects found both during the
development process and after customers receive and begin using the product.


In ODC, defects are classified according to key attributes and then data are
analyzed to form the basis for action plans and process improvement activities.
ODC is a technique mid-way between the traditional RCA (more qualitative and timeconsuming)
and Statistical Defect Models (more quantitative, but not easily translatable into corrective action).
Through the orthogonal classification of defects found (defect type) and their association with their trigger, it is possible to create consistent and meaningful characterizations of the problems that are found across all software development life cycle stages.

A list of strengths and possible limitations in applying ODC has been compiled from the
literature:

Strengths:
o It is an evolution of RCA from a qualitative to a quantitative approach.
o It has adopted a standard taxonomy (types; triggers), which allows
comparability across time and organizations.
o It helps in gathering defect data over time, enabling an organization to run
statistical analysis and – more generally – to look at defect data in a more
objective way.

Limitations:

o It is challenging to use Software Defect Removal, since a large part of the SPI
activity is focused on the code. Furthermore, the later a generic defect (not only
code) is detected, the more difficult and costly it is to remove [12].
o It is typically applied by organizations having a robust measurement system: ODC
needs the capability to consistently gather and analyze data over time; a number of
organizations are at lower maturity levels and do not have this capability, or the
payback period is too remote for its application to be economical.
o The updating of defect types and related defect triggers makes it difficult to
maintain a backward comparability of source defect data over a long period of
time.

Reference: Introducing Root-Cause Analysis and Orthogonal Defect Classification at Lower CMMI Maturity Levels by Luigi Buglione and Alain abran.