ISO 9000-3 Digest Wednesday, 4 September 1996 Volume 01 : Number 022
In this issue:
Need quality software for nonconformance reporting and more (fwd)
RE: Guidelines to improve the quality of software / ISO9000
Re: Guidelines to improve the quality of software / ISO9000
Re: Re[2]: Guidelines to improve the quality of software /
Re[4]: Guidelines ... protocol
Re: Re[4]: Guidelines ... proto
Re: Re[4]: Guidelines ... protocol
Re: Re[2]: Guidelines to improve the quality of software /
----------------------------------------------------------------------
From: "Bill Casti, CQA (Moderator)"
Date: Sun, 1 Sep 1996 21:16:39 -0400 (EDT)
Subject: Need quality software for nonconformance reporting and more (fwd)
NOTE: This request for assistance is being distributed to multiple email
lists. If you're on more than one list, you may receive duplicates. My
apology for that. Please respond DIRECTLY to the inquirer's address (see
below), NOT to your list--as the inquirer doesn't subscribe to it--and
definitely NOT to me.
Thanks.
Bill
- ---------- Forwarded message ----------
> Date: Sat, 31 Aug 96 11:59:07 EDT
> From: tkalal@aol.com
> Subject: Need quality software for nonconformance reporting and more
>
> I am starting at a small company han would like help in
> finding a software package that allows me to create my own
> nonconformance recording, tracking, charting, etc.
>
> I see that there is a 1995 issue of Quality magazine that
> lists 400+ packages but this list is vauge and overwhelming.
> I have a Win 95 on a Msft NT network.
>
> All the help I get here would be greatly appreciated.
>
> Thank You,
>
> Ted Kalal
>
> (414)-774-6824
>
Message originally posted through the Clemson CQI Web Server.
------------------------------
From: calafut@epix.net (George J. Calafut)
Date: Mon, 2 Sep 96 08:47:57 PDT
Subject: RE: Guidelines to improve the quality of software / ISO9000
Dan,
Re: Your request for guidelines to improve software quality as IT Quality
Assurance Analyst for Michigan
In addition to the items already mentioned, have a look at the UK TickIT
guide. TickIT is a certification scheme that applies ISO 9000 to software
development.
The full name of the Guide is 'Guide to Software Quality Management
System Construction and Certification using EN 29001'. The document
includes a Purchaser's Guide, Supplier's Guide, Auditor's Guide, and a
European IT Quality System Auditor Guide. These Guides should help
you develop your own guidelines.
The TickIT Guide is available from
DISC TickIT Office
BSI-DISC
389 Cheswick High Road
London, W4 4AL
tel: +44 171 602 8536
fax: +44 171 602 8912
Another interesting website for software quality is Tesseract Publishing at
www.avenet.co.uk. Check it out.
Regards,
George Calafut
Registered TickIT Auditor
------------------------------
From: Eduardo Cadena
Date: Tue, 03 Sep 1996 07:49:42 -0600
Subject: Re: Guidelines to improve the quality of software / ISO9000
There is a whole ISO technical report being developed. It=B4s called the =
SPICE proyect (Software Process Improvement and Capability =
dEtermination).
You cand find information at: http://www.serinf.com/Symposium.html
=
****************************************************************
* Eduardo Cadena e-mail: ecadena@serinf.com
* Servicios en Informatica fax: (525) 536 8112
* SPICE Symposium: http://www.serinf.com/Symposium.html
****************************************************************
------------------------------
From: Glen Ford
Date: Tue, 3 Sep 1996 22:53:11 -0400
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 ...."
__________________________________________________________________
------------------------------
From:
Date: Wed, 04 Sep 1996 12:10 -0500 (EST)
Subject: Re[4]: Guidelines ... protocol
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
------------------------------
From: "Paquin, Sherolyn A."
Date: Wed, 4 Sep 96 16:21:34 -0400
Subject: Re: Re[4]: Guidelines ... proto
I say YES. This is a discussion group, isn't it?
Sherry
WHEN QUALITY IS INVISIBLE, WE WILL HAVE WON!
**********************************************************************
Sherry Paquin SAP01@MHS.Sperry-Marine.COM
Sperry Marine Inc. w: 804-974-2078
1070 Seminole Trail fax: 804-974-2480
Charlottesville, VA 22901-2891
**********************************************************************
------------------------------
From: Glen Ford
Date: Wed, 4 Sep 1996 22:16:38 -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
>
1. I admit that I PRESUMED that the response was sent personally to me by
mistake. Mostly 'cause I've been having a problem with making that mistake
myself.
2. I did, additionally however, respond publicly because I felt that the
message belonged in this forum.
3. If the messages remain in the private circuit rather than the public then
the discussion will degrade into a private argument in which no one will
learn nuttin. No one owns the truth and by increasing the participation in
any discussion we can perhaps build on each others comments to create
learning. (Open minds being presumed.)
4. There is another message that has been sent to me (not necessarily in
this list) part of which I will respond to publicly and part of which I will
respond privately. Why? Because, part of it says things that belong in the
list and part of which belongs off-line.
So my feeling is that some thought should be used. If nothing untoward or
sensitive is being said put it through the list. If there is any reason to
doubt that then don't.
__________________________________________________________________
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:20:59 -0400
Subject: Re: Re[2]: Guidelines to improve the quality of software /
At 09:14 1996-09-04 -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).
>
>On this point, I think that it is necessary to talk about the
>practice rather than the theory. Testing is a critical discipline
>and must be used throughout the life cycle. Whether it is located in
>QC or QA is of less importance to me than the practice of testing.
This is why I have harped on the concept of QC and QA. Quality Control is
defined as the philosophy of testing at the end. If you test before it goes
out the door then the product will be perfect. Quality Assurance is defined
as the philosophy of building in quality throughout the process. Testing is
still required but under QA it is carried out throughout the process.
In practice QA groups usually practice QC. Sad, very sad, very, very sad -
but unfortunately true.
For an industry that created and embraced theories that embodied QA while QA
was abornin', we sure have been reluctant to let QC go and embrace QA when
it comes to the quality department.
>QC has valid practices that assist in software development, and we
>must not hide the word *control* under a bushel basket because
>programmers are turned off by it. If QC is defined as only test in
>the end, then I agree it will fail. But if it is recognized that QC
We agree, that was my point.
>principles, sampling, testing, classification of defects, etc., are
>useful and can be applied to the development, then it will be of
>benefit.
The QA (and subsequent philosophies) donot discount the need for testing and
statistics. Some believe more heavily in them than others - some believe
they should not be needed (but accept that they are). The difference is in
where the quality control points are. QC says at the end, QA says during,
TQM says before and during, and Kaizen says before, during and anytime at all.
>
>> 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 agree with this. I may not have made this point clear.
>
>> >
>> >> 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?
>
>I will have to. I was asking for a specific definition of the work
>*organic* though to assist in the discussion. One definition might
>be that it takes a lot of b***s*** ( or manure if you like) to create
>it.
>(JOKE WARNING - THE LAST STATEMENT WAS A LAME
>ATTEMPT AT A JOKE.
>>
No that's to get it past the QA/QC department. (I did you one better).
What I meant was that it grows and changes as it grows. Where manufacturing
designs using reasonably static precepts and then creates many versions of
the same product with little (official) change during the production
process, IT begins with (hopefully) one idea but the design changes as it is
realized. That's the reason for RAD/RPE and bullpens popping up to replace
Structured Analysis and Design.
>> Read his work!
>
>Will.
>
Good - and yes he's still alive.
>>
>> >> 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.
>
>I must admit I am lost here. The Edsel was a failure, wasn't it?
>But a building is built up from parts! I must admit that I am
>confused by the analogy that you are trying to build here.
>Was Microsoft a failure because its products were late, and did not
>have the functionality that other products did?
>
Microsoft's the classic example of "good enough programming". Buggy, low
functionality, but it met the need at the time. Good Quality? Yes! Why -
because it met the PERCEIVED definition of quality! Which was timing (and
marketing) based. Technically? I respectfully refuse to answer on the
grounds that this note is long enough ... and I don't want Billy to sue me!
>> >>
>> >> 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.
>
>OK
>
>> >
>> >> 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.
>
>Finally! Someone who has been in sw testing longer than me! Were the
>test groups bottlenecks because of the way the process was structured
>or because of the way they chose (or were ordered) to operate?
>
Personal experience - usually because they were initially staffed without
the theoretical skills needed and then were isolated from the growth in
theory. (In other words they were behind when they started and moved further
behind as they stayed). The result was a perceived high resistance to change
in an industry that changes continually.
>> >
>> >> 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.
>
>I guess that I say this because in my practice, in other places I
>have worked, in *some*, not all, of conversations that I have had
>over the years, this has not been the case. I think that it is a
>generalization.
In my experience, it's true - not only with QC but with the entire team.
Communications is both the most difficult and most important task there is
for a project manager (not to mention the team). And if you think convincing
a QC group to accept an agreement with a client is hard try convinving a
programmer to deliver lower quality in order to deliver on the date
(assuming that it is necessary to lower quality).
>>
>> 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.
>
>Couple of points. 1. Even the best minds can be wrong. That is why
Yes but ... (next paragraph).
>I disagree, based on practical experience. It is apparently one of
>those things that is true in some places, and not true in others. I
>agree completely with understanding the customer's mind.
In this particular case, his opinion agrees with most theories (from several
different disciplines) today. In essence, all of these independently
developing disciplines have arrived at what a sales manager told me back in
the '60s - " It don't matter shit what the truth is ... it only matters what
the customer thinks is the truth."
As for it being true in some places - some people are lucky - some aren't.
(I was actually moderately lucky for seven years).
>
>> >> 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.
>
>Yep. I agree that it is easy to become obsolete. I also surmise
>that we are operating from different experience bases. In my
Could be...
>experience, the testing and SQA/SQC people have led the changes in
>attempting to be involved in the process. The resistance to change
>typically came from others.
In my experience, the pressure for involvement has come from many sources.
Sometimes QA, sometimes the Project Manager, sometimes department
management. For some reason I've never experienced it from the user/client.
Often, the (valid) resistance I've received to my rule of involvement is -
"What will they contribute?".
To a certain extent, we're talking about baseline skill levels. I know there
actually are some Quality Analysts deserving of the title (please don't
anyone burst my bubble - let me keep my naivete a little longer), however, I
can't say that I've met very many of them.
However, the key point is growth. Presentation theory for example has grown
immensly in the last fifteen years. You don't need to be involved in the
project to lead the department in enhancing presentation. How many QA
departments have you found which have led the department into new styles of
presentation?
>>
>> >> > 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.
>
>I think that it is necessary that we define an obsolete process.
>What data indicate that a process is obsolete? Possibly response
>time to customers. Possibly lack of automation. Without data it is
>hard to surmise what might be the right answer. I also agree that
In this particular case I meant that the process is no longer used ie
obsolete (as opposed to outdated/outmoded/due for review).
>change is most difficult in people rather than systems. However,
>people run the systems. If they are not on course, any system in the
>world will fail.
One of the basic tenets of IT/IS theory - along with the 7+/-2 rule.
__________________________________________________________________
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 ...."
__________________________________________________________________
------------------------------
End of ISO 9000-3 Digest V1 #22
*******************************