ISO 9000-3 Digest Thursday, 5 September 1996 Volume 01 : Number 023
In this issue:
RE: Re[2]: Guidelines to improve the quality of software /
Re: BPR
Re: Re[4]: Guidelines ... protocol
Re[6]: Guidelines ... protocol & context
RE: Re[2]: Guidelines to improve the quality of software /
RE: Re[2]: Guidelines to improve the quality of software /
RE: Re[2]: Guidelines to improve the quality of software /
----------------------------------------------------------------------
From: Glen Ford
Date: Wed, 4 Sep 1996 23:40:08 -0400
Subject: RE: Re[2]: Guidelines to improve the quality of software /
At 14:45 1996-09-04 -0500, you wrote:
>Hi Glen,
>
>I've read your recent postings with a lot of interest and I support
>everything that you've asserted. However, I can't tell from your most
>recent response (see below) who you are rebutting. This person seems out
>of touch with the whole QA vs. QC subject.
>
>In addition to my job as Manager of Systems & Procedures (read ISO Mgmt
>Rep/Quality Director) at FutureSoft, I also teach a 2-day seminar on
>Quality Assurance and Software Testing. From teaching the seminar it is
>obvious to me that there is a software industry-wide misuse of the term QA.
Boy, do I agree with that comment!
> We at FutureSoft are just as guilty as the rest. We cavalierly call our
>testing group QA without any of the QA jobs being done yet. Every time I
>bring up the point that true QA needs to be involved in all inspections,
>walkthroughs, reviews, etc. I get resistance because my developers think
>that "QA" is trying to do the developer's job. I am currently developing a
>presentation to describe the QA job without using that term until the very
>end. I think much of this resistance comes from semantics and not that
>those activities don't need to occur.
Also possibly from respect. How skilled are your QAs? Are they QAs or just
datapunch people that had nowhere else to go? Also "developers"
(programmers) tend to be very provincial. If you're not a programmer you're
nothing (I haven't been one for 10 years although I probably know more about
the theory than anyone I work with - and no I don't get any respect
especially from those who are pure coders). I have an organizational model
on respect which may help you to build up acceptance(at
www.io.org/~gford/bwca/models.html). At least it may get you thinking on how
to influence the situation.
Assuming your company does walkthoughs etc. now - why not pick up some of
the original works on walkthroughs. You may find some amunition there (ie a
role for your people).
>
>>From reading your rebuttal I think that is also true of the person you
>responded to below.
>
>Just a couple of questions for you. How do you apply SPC to software
>development? Since it is not a manufacturing discipline, does SPC even
Most organizations seem not to believe so. They tend to deal with each
project on its own merits. Personnally, I tend to use pretty simple forms to
identify where a project has gone wrong. In reality, I use the figures to
back up my arguments - since I usually know how I screwed up.
>make sense? What is BPI/BPR? You used those terms but never defined them?
Business Process Improvement/Business Process Re-engineering. Constant
review and modification for the former and scrap it and start over for the
second. Usually they're lumped together as Re-engineering. And usually are
just another way of cutting the personnel rolls. (Duck! :) )
> I've never seen them before. Do they have something to do with best
>practices?
Yes. That's the target.
>
>Henry Schneider
>
>----------
>From: Glen Ford[SMTP:gford@io.org]
>Sent: Tuesday, September 03, 1996 10:53 PM
>To: iso9000-3
>Subject: Re: Re[2]: Guidelines to improve the quality of software /
>
>----------------------------------------------------
>At 06:58 1996-08-31 -0500, you wrote:
>>> In software I would contend that Quality Control as a concept is
>unworkable.
>>> Unless Quality is built into the process (ie the defining conceptual
>>> difference between QC and QA) the quality process will fail.
>>
>>Like any other process, QC is as necessary as QA. Without
>>measurements to support where you have been, and SPC to help get a
>>handle on the variations in your process, QA has no feedback.
>
>Remember that I was talking about the concepts of Quality Control (ie test
>a
>t the end) vs Quality Assurance (ie build quality in and test throughout).
>
>I agree that a QC STEP is needed to provide a final check and to help
>provide info for process analysis. However, a QC step without QA is not
>sufficient to create quality. I'm sorry but it don't. That idea died out
>during the 60s and early 70s.
>
>
>>
>>> I suggest to
>>> you the work by Yourdon on "Good Enough Programming" as an important
>piece
>>> of thought on this subject. Software is an organic creation.
>>
>>What the heck does *that* mean?
>>
>
>Read his work!
>
>
>>> Unlike
>>> manufacturing in which each stage is an assembly of either components or
>>> sub-assemblies, software is a cumulative process with each stage
>building
>on
>>> (or completing if you prefer) the outputs of its predecessors.
>>
>>I think that this is a mistaken view. Software follows very much a
>>classic development process, except that the design and
>>implementation involve much more effort in comparison to the
>>manufacturing process. I guess I do not under stand how code
>>completes the output of design. Code is totally different. It will
>>run. The design will not. Code is compilable. A design is not. A
>>design ends up on paper or in diagrams. Code ends in stated in a
>>specific grammar according to certain rules. Both are a different
>>representation of a view of the problem solution and they complement
>>one another. How is this different from the design of a car and the
>>implementation of a car? I fear that I hear the theme "Software is
>>different." It ain't.
>
>
>Obviously, I disagree. Unlike a car which has assembly built upon assembly,
>programming is a build up of the previous thoughts. Like writing or
>architecture, the design and the result are inseperable. A car may be
>functionally perfect (the Edsel) while being functionally imperfect (the
>Edsel). (It works fine but doesn't meet the need). Software can
>theoretically be that way but invariably a functionally perfect piece of
>software is considered a complete failure if it doesn't meet the need.
>
>>>
>>> Over the last 20 years one of the key lessons learned by Software
>>> professionals is the need to involve all stakeholders in the process -
>>> client, user, developer, designer, implementer and tester. Only through
>this
>>> wide involvement can buy-in and quality be achieved. In other words the
>>> Quality Assurance concept.
>>
>>No different from anyone else.
>
>On this we agree.
>
>>
>>> Quality Control (ie test at the end) groups - whatever their
>organizational
>>> name - invariably become bottlenecks and fail to perform.
>>
>>Having been involved in software testing for about 20 years, I cannot
>>tell you how wrong this statement is.
>
>Let's not bring in length of experience - you'll lose. The concept of QC
>was
>strong in the 60s and was replaced by the late 60s and 70s by Structured
>Techniques. The concept of QC was replaced more generally by QA in the 70s.
>
>>
>>> Project Management
>>> especially in Software, is a balancing act between the different
>definitions
>>> of quality - bugs, dates, functionality etc. Since QC groups are not
>>> involved in the process they are not aware of the trade-offs (agreed to
>or
>>> otherwise) required to create this balance.
>>
>>To put it mildy - nonsense.
>>
>
>We disagree. Unfortunately that is a (paraphrased) quote from one of the
>best minds in Software theory today. I also agree with him. That's why it's
>so important to keep clued to the user/client's definition of quality.
>
>>> To make matters worse, often QC
>>> groups are not involved in the process enough that they will continue to
>>> grow. As a result, they become targets as a result of their own
>resistance
>>> to change ("But it doesn't look like the old one").
>>
>>With all due respect, more nonsense.
>>[....]
>>
>
>That is not an arguement. My experience proves otherwise. If you are one of
>these QC people who have failed to grow then I can only pity you. The IS/IT
>has grown and changed at a phenominal rate. It is easy to become obsolete.
>
>
>>> > Most frequently when TQM does not succeed
>>> > it is because QA is either bypassed or sold off. Most frequently
>>>
>>[....]
>>> > where BPI/BPR fails it is beacause TQM is either only front-end
>lip
>>> > service or an excuse for ZQM (zero). For more on getting quality
>>>
>>> Again I disagree. If this were true BPR would succeed more often and (in
>my
>>> experience) succeed where it fails and fail where it succeeds. Radical
>>> change is seldom easy or successful. Successful BPR must be performed on
>a
>>> regular and routine basis. In essence, the sloughing off of old habits
>must
>>> be done regularly. Otherwise it becomes radical surgery instead of
>precise.
>>> And like surgery, any radical procedure has a large risk factor.
>>
>>What data are used to indicate that BPR is necessary?
>
>Current stats are 75% of BPR project fail. In my experience, organizations
>engaging in BPR often have processes which are obsolete. The systems
>changed
>but the people didn't. Unless the people become comfortable with changing
>systems this problem will continue.
>__________________________________________________________________
>Glen D. Ford
>Mississauga, Ontario, Canada
>Bwca Management Consulting/CanDa Software
>visit our Websites at: www.io.org/~gford/bwca.html
> and www.io.org/~gford/canda.html
>Pick up free software at www.io.org/~gford/canda.html
>Read our Organizational Development Models at
>www.io.org/~gford/bwca/models.html
>Comments are encouraged.
>------------------------------------------------------------------
>"Hey, ya gotta laugh ...."
>__________________________________________________________________
>
>
>
>
>
__________________________________________________________________
Glen D. Ford
Mississauga, Ontario, Canada
Bwca Management Consulting/CanDa Software
visit our Websites at: www.io.org/~gford/bwca.html
and www.io.org/~gford/canda.html
Pick up free software at www.io.org/~gford/canda.html
Read our Organizational Development Models at www.io.org/~gford/bwca/models.html
Comments are encouraged.
- ------------------------------------------------------------------
"Hey, ya gotta laugh ...."
__________________________________________________________________
------------------------------
From: Glen Ford
Date: Wed, 4 Sep 1996 23:47:26 -0400
Subject: Re: BPR
At 10:17 1996-09-05 +-800, you wrote:
>Glen
>>Current stats are 75% of BPR project fail. In my experience, organizations
>>engaging in BPR often have processes which are obsolete. The systems >changed
>>but the people didn't. Unless the people become comfortable with changing
>>systems this problem will continue.
>
>My experience with QA/QC is short, my experience with people is long.
>I would like to add the folowing:
>
>CLIENTS, particularly established once, will require many changes, upgrades
and even new systems, even stomp thier feet and accuse of incompetence.
>
>But, we must never change what they or thier clients are used to.
>
>So, there we are, new systems architecture, new development software, new
methods, etc, etc, but, but, but ....... incompatable clients.
>
>Cheers Pieter
>
I don't know whether to applaude, cry in my beer or respond intellegently!
I read an article a few years ago which discussed the RC factor in IS/IT.
The author(s) contention was that we have as great or a greater RC factor
than our clients. In essence, we are the authors of our own failure.
A few years ago I began applying the principle of "quality is in the eyes of
the beholder". Which means I have to both know what the client defines as
quality and also manage that definition. The improvement was amazing! But
every once in a while ....
__________________________________________________________________
Glen D. Ford
Mississauga, Ontario, Canada
Bwca Management Consulting/CanDa Software
visit our Websites at: www.io.org/~gford/bwca.html
and www.io.org/~gford/canda.html
Pick up free software at www.io.org/~gford/canda.html
Read our Organizational Development Models at www.io.org/~gford/bwca/models.html
Comments are encouraged.
- ------------------------------------------------------------------
"Hey, ya gotta laugh ...."
__________________________________________________________________
------------------------------
From: Glen Ford
Date: Wed, 4 Sep 1996 23:56:43 -0400
Subject: Re: Re[4]: Guidelines ... protocol
At 12:10 1996-09-04 -0500, you wrote:
> Glen & folks,
>
> Apparently I started a debate with my short QC-QA-QM-PR-PI comment to
> Glen Ford, to which he went public including my original (so that
> folks could read it). I will extrapolate on this substance in a
> following message.
>
> However, I see Glen now has a second response to someone else's
> intervening comment, which mean's that the intervener replied
> off-circuit to Glenn, which leads me to a protocol issue: should we
> broadcast a message or reply which was private (even if inadvertently
> sent privately)?
>
> -- Mike Berens
> Lockheed martin DEIS QA
Just as a side issue most of the responses to the discussion have been sent
privately. Which forces me to spout off a lot more than I would like.
Please reply to the list - which means you can't just hit the reply key.
It's a pain I know but give everyone a chance to reply ... and save me
having to decide if you'd prefer privacy. Besides, you're more likely to
actually get a correct response (if there is one).
__________________________________________________________________
Glen D. Ford
Mississauga, Ontario, Canada
Bwca Management Consulting/CanDa Software
visit our Websites at: www.io.org/~gford/bwca.html
and www.io.org/~gford/canda.html
Pick up free software at www.io.org/~gford/canda.html
Read our Organizational Development Models at www.io.org/~gford/bwca/models.html
Comments are encouraged.
- ------------------------------------------------------------------
"Hey, ya gotta laugh ...."
__________________________________________________________________
------------------------------
From:
Date: Thu, 05 Sep 1996 08:15 -0500 (EST)
Subject: Re[6]: Guidelines ... protocol & context
Quality Folks --
I agree with Glen's comment on protocol - we should try to keep our
remarks public. I disagree with Sherry Paquin - if a remark is
private it should be up to the originator to redirect (including
broadcast).
Based my reading various responses to the buzzwords QC-QA-TQM-BPR-SPI,
with further buzzwords such as the "punch-card checker" epithet thrown
in - it appears that we each bring a fair degree of parochialism and
skepticism about our fellow quality support services colleagues to the
floor. This will necessitate that our discourse become more
constrained if we hope it to be positive and semi-enlightening.
As many of have heard one of the software industry dons has declared
the defect identification process part of the problem with low quality
software. Watts Humphrey (CMU-SEI) recently stated that product
development resources spent building in assurance by careful attention
to incremental reviews and intelligent testing would be better spent
by more user feature research (my paraphrase - sorry, don't have the
cite-ref. handy). My experience says differently.
Perhaps my original intent with the QC-QA-TQM-BPR-PI comment would be
better expressed with a Venn Diagram. I'll consider that, since it
appears that my attempt at linear rhetoric led to more
finger-pointing.
-- more later --
-- Mike Berens, CQA(QAI), CSQE(ASQC)
Lockheed Martin DEIS
------------------------------
From: "George X. Kambic"
Date: Thu, 5 Sep 1996 11:34:56 -0500
Subject: RE: Re[2]: Guidelines to improve the quality of software /
> >I've read your recent postings with a lot of interest and I support
> >everything that you've asserted. However, I can't tell from your most
> >recent response (see below) who you are rebutting. This person seems out
> >of touch with the whole QA vs. QC subject.
Whoops. I finally been found out. Darn. I thought I could hide and
fake my through this whole argument. I guess that I don't know
anything about software development and QA/QC (sniff!). Thanks for
clearing up my situation for me.
George X. Kambic
kambic@ct.picker.com
Voice: 216.473.2557
Fax: 216.473.7098
------------------------------
From: "George X. Kambic"
Date: Thu, 5 Sep 1996 12:54:26 -0500
Subject: RE: Re[2]: Guidelines to improve the quality of software /
> > We at FutureSoft are just as guilty as the rest. We cavalierly call our
> >testing group QA without any of the QA jobs being done yet. Every time I
> >bring up the point that true QA needs to be involved in all inspections,
> >walkthroughs, reviews, etc. I get resistance because my developers think
> >that "QA" is trying to do the developer's job. I am currently developing a
> >presentation to describe the QA job without using that term until the very
> >end. I think much of this resistance comes from semantics and not that
> >those activities don't need to occur.
Interesting. I worked in one organization where the engineering team
asked the QA rep to be head of the project team, because the team
viewed him as the person most likely to be able to bring the project
to a successful, high quality conclusion. They worried less about
the classical definitions of QA/QC than about what they actually had
to do to achieve a high quality product.
Whoops. Sorry, I forgot. I am out of touch.
George X. Kambic
kambic@ct.picker.com
Voice: 216.473.2557
Fax: 216.473.7098
------------------------------
From: dbarnes@cix.compulink.co.uk (Dave Barnes)
Date: Thu, 5 Sep 96 23:17 BST-1
Subject: RE: Re[2]: Guidelines to improve the quality of software /
In-Reply-To: <12DB9A6EEA@ct1.ct.picker.com>
I think that the IEEE (in 610-12??) is partly to blame here
since it says that QA and QC are the same thing although it
could be just reflecting current usage.
It doesn't help either with software testing tools called, eg
"QA Automator" (not the only one before anyone takes offence).
I use the following example sometimes when I am told that the
QA (ie the test group) "assure the quality of the delivered SW".
Four teams (req capture, analysis design and code) each do
their job to the best of their ability but manage only 90%
accuracy.
No inspection until the test group (ie QA) who are 100%
perfect. How good is the finished product? About 63% correct.
Allow the QA group to make mistakes too and it comes down to
55% correct. I accept that most people are more accurate than
this but it illustrates the point better.
After this it is usually a little easier to introduce
inspections at each stage of the lifecycle (eg Fagan reviews,
Code walkthroughs), with prevention techniques like "No program
longer than x lines" or "Maximum Cyclomatic Complexity of n."
Dave
dbarnes@cix.compulink.co.uk
"My views, not my employers - and I reserve the right to change
my mind with little or no notice - just more experience."
- -------- Original Message --------
>From iso9000-3-owner@vector.casti.com Thu Sep 5 18:36:59 1996
Received: from matrix.casti.com (matrix.casti.com
[199.181.80.101]) by tom.compulink.co.uk (8.6.9/8.6.9) with
ESMTP id SAA17107 for ; Thu, 5 Sep
1996 18:36:59 +0100
Received: from casti.com (vector.casti.com [199.181.80.100]) by
matrix.casti.com (8.6.12/8.6.12) with ESMTP id NAA02177 for
; Thu, 5 Sep 1996 13:09:35 -0400
Received: by casti.com (8.6.9/NX3.0M)
id NAA23513; Thu, 5 Sep 1996 13:09:45 -0400
Received: from central.picker.com by casti.com (8.6.9/NX3.0M)
id NAA23506; Thu, 5 Sep 1996 13:09:38 -0400
Received: from ct.picker.com by central.picker.com with smtp
(Smail3.1.28.1 #3) id m0uyhjH-0004rjC; Thu, 5 Sep 96
12:56 EDT
Received: from ct1.ct.picker.com ([144.54.62.2]) by
ct.picker.com (4.1/SMI-4.1)
id AA15573; Thu, 5 Sep 96 12:54:52 EDT
Received: from CT1/SpoolDir by ct1.ct.picker.com (Mercury 1.21);
5 Sep 96 12:54:50 +0500
Received: from SpoolDir by CT1 (Mercury 1.21); 5 Sep 96
12:54:29 +0500
From: "George X. Kambic"
Organization: Picker Int.
To: iso9000-3@quality.org
Date: Thu, 5 Sep 1996 12:54:26 -0500
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: RE: Re[2]: Guidelines to improve the quality of
software /
Reply-To: kambic@ct.picker.com
Priority: normal
X-Mailer: Pegasus Mail for Windows (v2.42a)
Message-Id: <12DB9A6EEA@ct1.ct.picker.com>
Sender: owner-iso9000-3@quality.org
Precedence: bulk
Apparently-To: dbarnes@cix.compulink.co.uk
> > We at FutureSoft are just as guilty as the rest. We
cavalierly call our
> >testing group QA without any of the QA jobs being done yet.
Every time I
> >bring up the point that true QA needs to be involved in all
inspections,
> >walkthroughs, reviews, etc. I get resistance because my
developers think
> >that "QA" is trying to do the developer's job. I am
currently developing a
> >presentation to describe the QA job without using that term
until the very
> >end. I think much of this resistance comes from semantics
and not that
> >those activities don't need to occur.
Interesting. I worked in one organization where the
engineering team
asked the QA rep to be head of the project team, because the
team
viewed him as the person most likely to be able to bring the
project
to a successful, high quality conclusion. They worried less
about
the classical definitions of QA/QC than about what they
actually had
to do to achieve a high quality product.
Whoops. Sorry, I forgot. I am out of touch.
George X. Kambic
kambic@ct.picker.com
Voice: 216.473.2557
Fax: 216.473.7098
------------------------------
End of ISO 9000-3 Digest V1 #23
*******************************