NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/software/4927

Text File | 1992-12-13 | 5.7 KB | 115 lines

Path: sparky!uunet!olivea!spool.mu.edu!wupost!udel!rochester!rocksanne!news
From: [e-mail] (Mike Kirby)
Newsgroups: comp.software-eng
Subject: Re: Is SEI's CMM being used in Anger or ju
Message-ID: <[e-mail]>
Date: 13 Dec 92 17:48:50 GMT
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Xerox Corporation, Webster NY
Lines: 102

In article [e-mail], [e-mail] writes:
> Hi folks,
>
> In article <[e-mail]>
> [e-mail] (Bonus, Iniquus, Celer - Delegitus Duo) writes:
>
> > In article <[e-mail]>, [e-mail] (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: [phone]           |
> | Advanced Switching Laboratory, NEC America |   Fax: [phone]           |
> | 1525 Walnut Hill Lane, Irving, Texas 75038 | Email: [e-mail]   |
> +--------------------------------------------+-------------------------------+



Mike Kirby
Xerox Corp
E-mail: [e-mail]