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

Internet Message Format | 1992-07-22 | 8.3 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:34:19 EST
References: <[e-mail]>  <[e-mail]>
Lines: 137

In article <[e-mail]>, [e-mail] (Terry Bollinger) writes:
> Hi folks,
> Interesting and in some cases amusing discussion.  Allow me to address a
> few specific points and questions:
> ---------------------------------------------------------------------------
>  1. Is the SEI Maturity Model REALLY based on the assumption that building
>     new software is "just like" mass production of, say, copper sheeting?
> ---------------------------------------------------------------------------
>     [Ref: George Kambic in <[e-mail]>]
>
>     Yes.  In fact, I may well have understated the case in terms of how
>     firmly Watts Humphrey, the originator and primary promulgator of the
>     model, views software development.  He came and gave a talk when I
>     took SEI Process Assessment training (at SEI), and the talk consisted
>     almost entirely of telling us how detection of holes in copper sheets
>     shows us how we should strive to build rock-solid software processes
>     that will chug out "hole-less" (defect free) software.
This has _not_ come through in subsequent lectures or information from SEI such
as presented at the Affiliates symposium (1991), so is the SEI implementing
Humphrey's belief in the model.  In my mind there is the very real possibility
of improving sw by using process improvement methods, re: Fagan inspections.
So Humphrey may believe sw=Cu, but that does not obviate the value of a process
improvement paradigm, nor necessarily the SEI maturity model.  IMHO,
independent of whether or move around on the scale, the process still asks good
questions about what you are doing.

>
>     Scan through his book and you will find that it makes frequent and very
>     definite analogies of software production to such items as watches and
>     cars.  He does NOT make any comparisons of note to design-intensive
>     activities such as chip design (vs. replication), only to assembly-line
>     (replication) processes.  Don't take my word for it -- get out your
>     copy of Humphrey's book and LOOK.
>
The methods of thinking in the general sense about how defects leak into a
product are independent of whether you are doing design or production.  When
you get to what specific questions you need to ask, it does require application
knowledge.  We do replicate the design process.  Processes can fail the
processor.  Methods of analysis of process problems are similar no matter what
process  you are attacking.

>     One thing that continually astonishes me about the whole SEI Process
>     Program is how often this point seems to slip by -- that is, that the
>     concept of maturity that it promulgates is strongly and fundamentally
>     based on the premise that software can be treated as a substance or
>     medium that can be processed very, very much like some sort of metal
>     or ceramic on an assembly line.  You might want to keep it in mind
>     the next time you or someone else quotes "Level 4" or "Level 5" as
>     if they were PROVEN ideas for how to build high-quality software.
>
I will go back and check out WH's book again.  However, I think what the model
is used as is something different.  I think that it is now seen as a tool to
ask sensible questions that have to be asked about how you do what you do
anyway.  See above.  I think that there is a different point that you are
missing.  Process improvement is proven.  The particular maturity model is not,
but hey, gotta start somewhere.

[...]
> ---------------------------------------------------------------------------
>  2. IS the production of defect-free software different in any really
>     significant way from the production of defect-free copper sheets?
> ---------------------------------------------------------------------------
>     [Ref: George Kambic in <[e-mail]>]
>     Yes, emphatically.  The former is a design process, the latter is a
>     replication process.  These two process types have markedly different
>     resource and management needs, risk types and factors, measurement
>     needs, and potential for automation.  Slurring them together not only
>     is inaccurate, it can be disastrous for your ability to produce high
>     quality software, because it will lead management to look at the WRONG
>     process control indicators.
Exactly.  I am not in disagreement with this statement.  But then I apparently
did not make myself clear at some point.  The fact that both are processes lend
both activities subject to process improvement.  And for lack of a place to
start, why not start with the maturity model?  BTW, although WH drove the
creation of CMM, I think that it has turned into something quite different from
what was intended.
>
>     Says who?  Well, let's try a simple comparison:  How does a bakery
>     with many separate locations ensure that the quality, flavor, and
>     texture of their products will all be consistent?
>
>     Simple answer:  By setting up a management process and measurement
>     program that will ensure that all products will be IDENTICAL to within
>     some well-defined set of tolerances.  Initial risks come more from poor
>     adherence to the defined management practices than from practices
>     themselves.  Poor products result from deviations from a predefined
>     recipe, and can be traced back to whatever part of the process is
>     failing to EXACTLY match the predefined standard for a good product.
I think that the data are in place in support the contention that poor sw
products can result from deviations from a predefined (process) recipe.

>     In short, it's a replication process -- a process in which innovation
>     *of the product itself* is (by definition) forbidden.  You may be
>     allowed to make innovations in the PROCESS for making that product
>     -- e.g., going from a batch style to a more assembly-line style --
>     but changing the product itself counts as a violation of the way
>     all the different bakery locations have agreed to make their products.
>
Me thinks that I thought it was clear that the word "production" of software
must be applied to the analysis/design/implementation stages.  The "production"
of software by copying disks, etc., is almost irrelevant to the most
interesting  questions in sw.

[...]
>  3. Does following the SEI maturity model *necessarily* ensure that you
>     will "deliver top quality software products at a profit that meet
>     customer needs and expectations?"
> ---------------------------------------------------------------------------
>     [Ref: John C. Howland in <[e-mail]>]
>     Well if it does I'd SURE like to see the data -- wouldn't you?
>     One of the really nice features of defining a maturity model in which
>     NO ONE is "mature" is that you can play some very interesting games
>     in how you describe the higher levels of the model.
Or maybe you are trying to learn if the model has any value.  Gotta start
somewhere.
>
[...]
>     Now ain't all that great?  I mean absolutely GREAT?  How can ANYONE
>     be against such an absolutely outstanding program if it will result
>     in such UNBELIEVABLE results?
>
>     Well... that's sort of the problem, isn't it?  "Unbelievable?"  As in:
>     If I claim to you that your Fairy Godmother will come down and shower
>     you with kisses when you reach Level 5, WHO is to say that I'm WRONG?
>
>     How are you going to judge the believability of a set of claims when
>     they are based on descriptions of a hypothetical organization that
>     NEVER EXISTED at the time the maturity model was devised?  There WAS
>     no data, good or bad, for such an organization at that time, so how
>     do I judge ANY kind of assertion about it?  (I'll discuss the Space
>     Shuttle case a bit later...)

Hmm....sounds like what Deming probably said to the Japanese after WWII.

George Kambic
standard disclaimer