NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/software/2924

Internet Message Format | 1992-07-22 | 3.4 KB

Path: sparky!uunet!icd.ab.com!iccgcc.decnet.ab.com!kambic
From: [e-mail] (Bonus, Iniquus, Celer - Delegitus Duo)
Newsgroups: comp.software-eng
Subject: Re: SEI Process Maturity Model
Message-ID: <[e-mail]>
Date: 20 Jul 92 14:45:46 EST
References: <[e-mail]>  <[e-mail]>
Lines: 53

In article <[e-mail]>, [e-mail] (David Wahl) writes:
> In article <[e-mail]>, [e-mail]
> (Terry Bollinger) writes:
[...]
>
> Terry, I enjoyed your thoughtful article.  I have had the same concern about
> the whole assumption that statistical quality control is applicable to
> software development.  I do think, though, that you failed to address a key
> issue regarding the CMM: the issue of whether metrics -- ANY metrics -- are
> useful in determining how to improve the quality of software.  I think it's
> really there that your arguments succeed or fail; the choice of manufacturing
> analogies to software is, I think, simply because most of what we know about
> measurable quality comes from manufacturing process improvement.
I hate to say this, but we had better start working with nomenclature before
continuing this discussion.  Words that we need to deal with are ones like:
quality, and production.  What does quality mean when applied to sw?  Is it
exactly the same as a classically manufactured product? If so, then we need to
determine if the word production applies in any sense? BTW, if it does not,
Dave, could you or Terry propose a definition?  Quality as defect-free,
on-time, meeting requirements attributes for a product should be sufficient for
any product in the world.  And Dave, to follow on with what you said, there are
some practices in sw that have used the manufacturing process improvement model
to do exactly that: improve the process.  The data exist, and some are in the
public literature.  If we need to take it one step at a time, there is at least
one metric, defects/unit of opportunity that is a proven metric for improving
sw.

>
> While I agree that there are some fundamental differences between replicative
> processes and design-intensive processes, I think you have to step back a
> second and ask what management can do to impose change from above to improve
> the design-intensive process.  If it's an organization large enough to produce
> and maintain really complex software with replaceable people, the only
> objective tool management has to get a handle on the problem is to measure
> things about how the process is working and compare them against some baseline.
> I think you can argue about which metrics and where the baseline comes from,
> but I think the notion of trying to measure the process is sound.
>
Yep.

> I think metrics are often portrayed in the hearts of programmers as something
> which will remove all creativity from the process and make us all 1984 drones
> victimized by Big Brother management, but the truth is that projects get large
> enough that even the most experienced technical leaders can't get a handle on
> where the quality problems are.  In my experience, even teams with lots of
> experience, supportive management and the best of intentions have blind spots
> and a bit of self-deception regarding quality.
Yep.
[...]

George Kambic
standard disclaimer