From: kirby@xerox.com (Mike Kirby)
Newsgroups: comp.software-eng
Subject: Re: Is SEI's CMM being used in Anger or ju
Date: 13 Dec 92 17:48:50 GMT
Reply-To: kirby@xerox.com
Organization: Xerox Corporation, Webster NY

In article 24010@asl.dl.nec.com, terry@asl.dl.nec.com writes:
> Hi folks,
> 
> In article <1992Dec11.103044.9471@iccgcc.decnet.ab.com>
> kambic@iccgcc.decnet.ab.com (Bonus, Iniquus, Celer - Delegitus Duo) writes:
> 
> > In article <18108@autodesk.COM>, drake@Autodesk.COM (Dan Drake) writes:
> >
> > | The reference may be to a recent message of mine contrasting my
> > | perceptions of Deming's and SEI's outlooks.  Having read Out of the
> > | Crisis doesn't make me any kind of expert on Deming, much less Juran,
> > | but consider this: Deming's consistent message is that hundreds of
> > | companies have got into Continuous Improvement, outside of Japan as well
> > | as inside, and he loads his writing with success stories.  *Obviously*
> > | he doesn't think that a super-elite Level 5 status that virtually nobody
> > | has achieved is a prerequisite.
> >
> > Dan's point is fundamentally correct.  The ISO certification process requires
> > continuous improvement from the get-go.
> 
> 
> The point?  While the CMM does, as George rightly points out, give a lot
> of good ideas about what how to get good management and software engineering
> practices into place (the "rules of the road" again, if you will), I have
> a *lot* of problems with the way it tries to order things.  Our experience
> in bottom-line results both hear and at Contel is that the FIRST thing you
> should look for are the process problems with the biggest payoffs.  Waiting
> until you have umpteen different "metric programs" in place before you
> begin to apply good old-fashioned common sense to whatever is going on
> NOW is just a recipe for disaster -- plus you run a very real risk of
> actually "fossilizing" highly detrimental process features by decorating
> them with all sorts of data collection and management techniques.  In short,
> you should get the really ugly limbs sawed off your Christmas tree *before*
> you start sticking all sorts of expensive goodies on it.

NO NO NO NO...

Okay.. Let me try this one more time.

The whole idea of the metrics program is so we can take specific measurements
of the process and product and make specific recomendations based on those metrics.
The idea is that at the later stages of the SEI model we have already removed all the
"easy" fixes.  Now we are at a point where continous improvement will be the
only way to improve our process. (note...this is mainly process improvement, not 
product improvement).   Up until this point ALL we have been doing is gut feel, common
sense type of improvements.   Infact that is what the first 2 levels of the
CMM talk about.  The SEI has tried to write down what all these common sense type
of things are.  If you follow the first 2 levels of the SEI, you are doing the
common sense improvements you are talking about. 

Most organizations will have product measures in place long before they start
on level 4.

From CMU/SEI-91-TR-24 (August 91) (does anyone know if there is a newer version out??)
2.1.4 (pg 12)

	At the Managed level, the organization sets quantitative quality goals for
	software products.. Productivity and quality are measured for important
	software process activities across all projects in the proganization.  An
	organization-wise process database is used to collect and analyze the data
	available from a carefully defined process.  Software processes have been
	instrumented with well-defined and consistent measures at Level 4.  These
	measures establish the quantitative foundation for evaluating project
	processes and products.

	Projects achieve control over their products and processes by narrowing the
	variation in their performance to within acceptable quantitative boundaries.
	Meaningful variations in perfromance can be distinguished from random
	variation (noise), particularly within established product lines.  In order to
	reduce the process variation due to constant shifts among new application
	domains, there is a strategic business plan describing which product lines to
	pursue.  The risks involved in moving up the learning curve of a new
	application domain are known and carefully managed.

	The process capability of Level 4 organizations can be summarized as
	measured and operating within measurable limits.  This level of process
	capability allows an organization to predict process and product quality
	trends within the quantitative bounds of these limits.  When these limits 
	are violated, action is taken to correct the situation.  Software
	products are of predictably high quality.

What they are saying is that we are measuring the PROCESS as well as the product
and predicting the quality in any given project within a particular application
domain.  Of course a level 4 organization can detect when something goes wrong
with their process, but doesn't have the capability to do anything about it.  That
is what a level 5 organization does.


	 
> 
> 
> +--------------------------------------------+-------------------------------+
> | Terry Bollinger                            | Phone: 214-518-3538           |
> | Advanced Switching Laboratory, NEC America |   Fax: 214-518-3499           |
> | 1525 Walnut Hill Lane, Irving, Texas 75038 | Email: terry@asl.dl.nec.com   |
> +--------------------------------------------+-------------------------------+



Mike Kirby
Xerox Corp
E-mail: kirby.roch803@xerox.com
Newsgroups: comp.software-eng