iso9000-3-digest        Monday, April 20 1998        Volume 02 : Number 005




----------------------------------------------------------------------

Date: Mon, 19 Jan 1998 13:20:54 -0500 (EST)
From: "Bill Casti, CQA (System Administrator)" 
Subject: Software failure (fwd)

NOTE: If you have any feedback for him, please direct it to his personal
email address (below). Do NOT send it to me.

Thanks.
Bill

- ---------- Forwarded message ----------
Date: Mon, 19 Jan 1998 11:41:20 +0100
From: Steve Hignett <65143418@mmu.ac.uk>
Subject: Software failure

Is there any evidence that compliance with standards like ISO9001, etc
has actually cut the number of software projects failing or being
abandoned?

If so, where is it?
Steve Hignett

------------------------------

Date: 26 Jan 1998 09:14:14 +0100
From: Thierry.BERGIER@email.afnor.fr
Subject: RE: Update to ISO 9000-3

I am sorry to interrupt, but I don't understand the discussion below.

The new revision of ISO 9000-3 is about to be published by ISO (in both languages English and French).
The text is final ; it is only a matter of publication procedure.

I believe it will be referenced as ISO 9000-3:1997.

- -----------------------------------------------------
Thierry Bergier - AFNOR - French ISO National Body
Tel. : (+33) 1 42 91 58 42, fax : (+33) 1 42 91 56 56
mailto:thierry.bergier@email.afnor.fr
http://www.afnor.fr
Tour Europe - 92049 Paris La Defense Cedex - France
- -----------------------------------------------------


- -----Message d'origine-----
De:   owner-iso9000-3@quality.org [SMTP:owner-iso9000-3@quality.org]
Date:   mardi 6 janvier 1998 18:15
À:   peter.teng@ot-link.ot.com.au
Cc:   iso9000-3@quality.org
Objet:   RE: Update to ISO 9000-3

Nope, it is the conflict we all have to live with until they issue an
updated joint set, presumably in the 1999 time frame. See
www.software.org/quagmire for more.
Sarah Sheard

Sarah Sheard                                   Senior Systems Engineer
Software Productivity Consortium       sheard@software.org    
2214 Rock Hill Rd, Herndon VA 20170            (703) 742-7106


>-----Original Message-----
>From:   Peter Teng [SMTP:peter.teng@ot-link.ot.com.au]
>Sent:   Monday, January 05, 1998 11:44 PM
>To:   iso9000-3@quality.org
>Subject:   Update to ISO 9000-3
>
>
>Anyone know about any update to ISO 9000-3:1991? 
>
>Since ISO 9001 has been revised in 1994, I thought as guidelines, ISO
>9000-3:1991 would be outdated.
>
>Standards Australia (http://www.standards.com.au) has published guidelines
>for software industry as AS/NZS 3905.8:1996 Is this guidelines accepted by
>international communities. Will it be adopted by ISO?
>
>
>Peter Teng   
>email: peter.teng@ot.com.au
>      OPEN TECHNOLOGY
>  _--_|\     Intelligent Networks Group
>/       \       Level 2, 53 Walker Street,
>\_.--. _*       North Sydney, Australia, 2060
>       v        Phone:(612)9964 9633 Fax:(612)9929 8477
>_________________________________________________________

------------------------------

Date: Mon, 26 Jan 1998 19:55:10 +0200
From: paula parash 
Subject: Re: ANNOUNCEMENT: New FOOD-QUAL Email Discussion List

This is a multi-part message in MIME format.
- --------------86BFA7D9824A122C28E08861
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Opening new mailing lists for specific fields in software quality is a
great idea.
I am the software QA manager in a biomedical company. I deal with
general SQA issues but also with SQA issues that involve medical
equipment and FDA standards.
I was wondering if there are enough folks out there from the same field
who would be interested in opening another email list, for software
quality in medical devices.

Regards,
Paula






Bill Casti, CQA (System Administrator) wrote:
> 
> NOTE: This is an announcement of a new list at QUALITY.ORG. It is
> being
> delivered to all subscribers of other QUALITY.ORG lists. You will get
> duplicate messages if you are subscribed to more than one QUALITY.ORG
> list. My apology for the unavoidable duplications.
> 
> ------
> 
> At the request of many people, including some of you being cc:'d on
> this
> announcement, QUALITY.ORG is pleased to announce that we have created
> another topic-specific quality-related email discussion list on
> Quality
> Issues in the Food Processing Industry.
> 
> At this time, the list is NOT moderated. If the volume becomes great
> enough--and a suitably-qualified volunteer emerges--turning it into a
> moderated list is possible.
> 
> This list also has a Digest version, which you can subscribe to in
> addition to or instead of the "single-message-at-a-time" list. A new
> Digest will be generated and emailed to the Digest subscribers
> whenever
> over 25,000 characters have been posted to the list. Digests are not
> generated on the basis of date or time-elapsed since the previous
> Digest.
> Digests will also be archived at the QUALITY.ORG website.
> 
> As with all lists at QUALITY.ORG, you must be a subscriber to the list
> in
> order to post a message to the list. This also means that the address
> from
> which you, as a subscriber, are trying to post a message must be
> EXACTLY
> the same as the address at which you are subscribed to the list. We
> use
> very good list management software--called Majordomo--to manage the
> automated subscription/unsubscription processes. But, it is not
> artificial
> intelligence or intuitive; it has no way of telling that
> "john.brown@aol.com" is the same person as "john_brown@cisco.com". All
> it
> does is compare the "from:" line of your attempted post to the lines
> in
> the subscriber file. If it doesn't find one EXACTLY the same, it won't
> post the message. So, it's very important for you to subscribe
> yourself to
> the list from the address (if you have more than one) that you expect
> to
> be using most of the time.
> 
> To Subscribe to the FOOD-QUAL List:
> 
> 1. Address your message ONLY to:        Majordomo@quality.org
> 2. In the BODY of your message, place ONLY these two words:
>         subscribe food-qual
> 
> and/or  subscribe food-qual-digest  (if you want to subscribe to the
>                                      Digest version; you can subscribe
> to
>                                      both list versions, BUT each
> command
>                                      line must be on a separate line)
> 
> ** (DON'T put any other text in the BODY of your message or Majordomo
> will
> try to interpret it against the commands it knows. It won't be able to
> and
> will bounce it back to you.) **
> 
> 3. Majordomo will respond by sending an authentication message back to
> you. You will need to return the authentication code and command line
> back
> to Majordomo@quality.org in order for your subscription request to be
> completed. The authentication message will be sent to the address
> being subscribed, not the address from which the message originated.
> We do
> this so you can verify that YOU are the person requesting your address
> to
> be added to the list. A common malicious act is to subscribe people to
> thousands of lists; so, we request Majordomo to verify the wish to
> join
> the list with the address being subscribed.
> 
> 4. When your subscription request has been authenticated and
> completed,
> Majordomo will also send you an "informational" file about the list.
> Please SAVE that message, as it will also contain instructions telling
> you how to remove yourself from the list. It is "bad form" to send
> your
> "remove me from this list" messages to the list itself, so KEEP THE
> MESSAGE.
> 
> To Post a Message to Everyone Else on the List:
> 
> 1. Address your posting to:     food-qual@quality.org
> 
> 2. I recommend that all new subscribers to the list start off by
> posting an
> introduction to the other members of the list, to get the
> conversational
> ball rolling. Since it is not a moderated list, the only way any
> discussion will occur is when the subscribers themselves initiate it.
> If
> everyone waits around for someone else to post, it will be a very
> boring
> list.
> 
> 3. Please don't send large attachments with your messages. It's better
> to
> just let people know that you are willing to send them "this file",
> whatever it may be, and let those who are genuinely interested request
> it
> from you, rather than forcing everyone to deal with, whether they want
> to
> or not. This way is also much more courteous to your fellow
> subscribers.
> Remember that not everyone may have a similar connection to yours, so
> large attachments may crash their system or may be restricted from
> receipt. Take the "world view".
> 
> 4. Please be professional and deal with the issues, not with the
> personalities behind the opinions. While the posting may strike you as
> "juvenile", there is nothing to be gained from "flaming" or insulting
> the
> poster because you have differing opinions. If I am repeatedly
> notified of
> an obnoxious poster, that person may have his/her subscription
> removed,
> possibly being banned from the QUALITY.ORG system entirely. Remember
> that
> this site is not a democracy; it is privately-owned and -operated.
> Even as
> a subscriber, you are just a guest here. So, behave yourself.
> 
> Enjoy the discussions!
> 
> Regards.
> Bill
> 
> =============================================================================
>  Bill Casti, CQA                                     Email:
> help@quality.org
>  Domain Owner, QUALITY.ORG                           Pager: +1 800 604
> 6149
>  President, Associated Quality Consultants, Inc.       Fax: +1 703 834
> 8209
> 
> -----------------------------------------------------------------------------
>         Visit our Online Quality Resources Website and Bookstore at
>                           http://www.quality.org
> 
> =============================================================================
> 
>
- --------------86BFA7D9824A122C28E08861
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Paula Parash
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Paula Parash
n:              Parash;Paula
org:            Biosense
email;internet: paula@biosense.co.il
title:          SW QA Manager
note:           Tel     8576057, ext 156
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
end:            vcard


- --------------86BFA7D9824A122C28E08861--

------------------------------

Date: Tue, 27 Jan 1998 10:49:45 +0200
From: paula parash 
Subject: New Medical-Quality Email Discussion List

This is a multi-part message in MIME format.
- --------------EFF036B32C8F8ACB1957CA8D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Danny,

I've received many positive responses from software qa people in the
biomedical arena who are very interested in participating in an email
list that deals with biomedical devices issues, especially FDA
regulations of software in medical devices and so on.
I know you are the owner of at least one mailing list I'm participating
in (and doing a great job too!) and I assumed you would be able to guide
me on what is necessary to be done in order to open such a new alias
discussion team.

Thx in advance,
Paula.



Michael Emeigh wrote:
> 
> Yes, I'd *definitely* be interested in this myself.
> 
> >----------
> >From:  paula parash[SMTP:paula@biosense.co.il]
> >Sent:  Monday, January 26, 1998 12:55 PM
> >To:    Bill Casti, CQA (System Administrator); Quality Distribution
> List;
> >swtest-discuss@mailhost.rsn.hp.com; iso9000-3@quality.org;
> >ISO9000@LISTSERV.NODAK.EDU
> >Subject:       Re: ANNOUNCEMENT: New FOOD-QUAL Email Discussion List
> >
> (snip)
> >I was wondering if there are enough folks out there from the same
> field
> >who would be interested in opening another email list, for software
> >quality in medical devices.
> >
> Mike Emeigh
> NOMOS Corporation
> mwe@nomos.com
> http://www.geocities.com/Colosseum/Stadium/8957/
- --------------EFF036B32C8F8ACB1957CA8D
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Paula Parash
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Paula Parash
n:              Parash;Paula
org:            Biosense
email;internet: paula@biosense.co.il
title:          SW QA Manager
note:           Tel     8576057, ext 156
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
end:            vcard


- --------------EFF036B32C8F8ACB1957CA8D--

------------------------------

Date: Tue, 27 Jan 1998 06:05:08 -0500
From: David Walker 
Subject: Re: New Medical-Quality Email Discussion List

I would be interested in such a discussion group if it encompassed all regulated
software including clinical trials (pharmaceutical).

Dave

David W. Walker  MS, CSQE
Trilogy Consulting Corporation
Kalamazoo, Michigan
dwwalker@trilogyusa.com

>>> paula parash  01/27 3:49 AM >>>
Hi Danny,

I've received many positive responses from software qa people in the
biomedical arena who are very interested in participating in an email
list that deals with biomedical devices issues, especially FDA
regulations of software in medical devices and so on.
I know you are the owner of at least one mailing list I'm participating
in (and doing a great job too!) and I assumed you would be able to guide
me on what is necessary to be done in order to open such a new alias
discussion team.

Thx in advance,
Paula.



Michael Emeigh wrote:
> 
> Yes, I'd *definitely* be interested in this myself.
> 
> >----------
> >From:  paula parash[SMTP:paula@biosense.co.il] 
> >Sent:  Monday, January 26, 1998 12:55 PM
> >To:    Bill Casti, CQA (System Administrator); Quality Distribution
> List;
> >swtest-discuss@mailhost.rsn.hp.com; iso9000-3@quality.org;
> >ISO9000@LISTSERV.NODAK.EDU 
> >Subject:       Re: ANNOUNCEMENT: New FOOD-QUAL Email Discussion List
> >
> (snip)
> >I was wondering if there are enough folks out there from the same
> field
> >who would be interested in opening another email list, for software
> >quality in medical devices.
> >
> Mike Emeigh
> NOMOS Corporation
> mwe@nomos.com 
> http://www.geocities.com/Colosseum/Stadium/8957/
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                    

------------------------------

Date: Thu, 29 Jan 1998 12:17:31 -0500 (EST)
From: "Bill Casti, CQA (System Administrator)" 
Subject: Non-member submission from [Melanie Hopwood ]    (fwd)

NOTE: Respond *both* to the poster's address (see BELOW line reading
"Forwarded Message") and to the list's posting address, OR as directed in
the posting, but definitely NOT to me.


Thank you for your cooperation.
Bill

=============================================================================
 Bill Casti, CQA                                     Email: help@quality.org
 Domain Owner, QUALITY.ORG                           Pager: +1 800 604 6149
=============================================================================


- ---------- Forwarded message ----------
Date: Mon, 26 Jan 1998 10:37:54 -0500 (EST)
From: Melanie Hopwood 
To: "iso9000-3@quality.org" 
Subject: Validating Software

Hi

We are switching our product from a Unix to a PC platform.  I have some
questions regarding validating on a PC.  Could someone please respond
and tell me how they validate their software on a PC or give me some
points of reference.  Do you specify a minimum set of hardware
requirements and then just validate on that set.  Do you specify a cpu
processor vendor?

Also I would like to get some response from someone who has done
validation on a system written in Java.

Any help would be greatly appreciated.

Melanie Hopwood
Software Quality Assurance Engineer

Computerized Medical Systems, Inc.
St. Louis, MO  63132

phone: 314/993-0003
fax: 314/993-0075
email: hopwoodm@cms-stl.com

------------------------------

Date: Sun, 8 Feb 1998 16:19:15 +0200
From: jklein@ndc.co.il
Subject: Is It Somebody Coding Around 

     Would you help me remember the right acronym?
     
     Thanks

------------------------------

Date: Wed, 18 Mar 1998 23:41:07 -0500 (EST)
From: "Bill Casti, CQA (System Administrator)" 
Subject: re: Bogus "warnings"!

NOTE: There is NO SUCH THING as the "win a holiday virus". It's a HOAX. If
you receive such a warning, throw it away! Do NOT forward it to anyone!
Toss it. Do not pass go, do not collect anything, do not send it to anyone
else.

Authoritative sites to which you should refer, BEFORE passing anything
like that on, are:

- - The US Department of Energy's Computer Incident Advisory Capability
(CIAC) at http://ciac.llnl.gov/ciac/CIACHoaxes.html

- - Network Associates' (McAfee) Anti-Virus Information Site
at http://www.nai.com/vinfo/

- - TrendMicro's Anti-Virus Website
at http://www.antivirus.com/


And, there are many, many other sites. The point here is that you
shouldn't accept "warnings" just on the face of them. They are intended to
suck you into the hoax--and when you blindly send them on, they do. Don't
be taken in.

Real virus warnings are NOT distributed by the FBI, the FCC or anonymous
people on the Internet. They come from reputable and traceable sources and
will be accompanied by a digital signature certificate, usually issued by
FEDCIRC or DOE/CIAC. 

Basically, if in doubt, throw it away!

Regards.
Bill

=============================================================================
 Bill Casti, CQA                                     Email: help@quality.org
 Domain Owner, QUALITY.ORG                           Pager: +1 800 604 6149
 President, Associated Quality Consultants, Inc.       Fax: +1 703 834 8209
=============================================================================

------------------------------

Date: Mon, 23 Mar 1998 18:15:07 MET-1MEST
From: "Dirk Stelzer" 
Subject: Historical roots of ISO 9000

I am looking for a bibliographic reference that describes the 
historical roots of the ISO 9000 standards family.

Any information on such references (journal articles, books, 
conference papers etc.) would be greatly appreciated.

Please send your replies to stelzer@informatik.uni-koeln.de

I shall post a summary of replies to the list in due course.

Thanks in advance.
Regards,
Dirk Stelzer



Dr. Dirk Stelzer
Universitaet zu Koeln, LS fuer Wirtschaftsinformatik
Albertus-Magnus-Platz, D-50923 Koeln, Germany
Fon:  +49(0)221-470-5373
Fax:  +49(0)221-470-5386
mailto:stelzer@informatik.uni-koeln.de
http://www.informatik.uni-koeln.de/winfo/prof.mellis/stelzer.htm

------------------------------

Date: Fri, 27 Mar 1998 12:17:43 +0200
From: "Chris on Code" 
Subject: Introduction to myself -new member in the list

Hi !

My name is Christian Petrov, I am from Bulgaria (country known with its
Viruses, pirated software  and cheap developers) .
I am working for an USA company as a QA since March 1997.
Most of the time I write automated GUI tests using VT. My other activities
include
component non-GUI testing, implementing ISO 9000-3 standards, and sometimes
manual testing .  I adore to test manually but my opinion is that automated
testing is better.
The product I'm responsible to is about 500KLOC and runs under Win 95/NT.
That's all, I think.

Christian Petrov
Senior QA Engineer
Code Assistance Ltd.
cpetrov@code.bg

------------------------------

Date: Thu, 2 Apr 1998 16:50:13 MET-1MEST
From: "Dirk Stelzer" 
Subject: Summary: Historical roots of ISO 9000

Some days ago I posted a query about the historical roots of ISO 9000.
The original question was as follows:

>I am looking for a bibliographic reference that describes the 
>historical roots of the ISO 9000 standards family.

>Any information on such references (journal articles, books, 
>conference papers etc.) would be greatly appreciated.

Here is a summary of the reponses I received (most of them are in
German). Thanks to Andreas Frick, Georg Herzwurm, Kay Krämer, Tilo
Linz, and Malcolm McLean for their valuable input.

Best regards,
Dirk Stelzer

________________________________

In the foreword to "PLUS 9001 - The ISO 9000 Essentials", Dwayne D
Mathers, Administrator of CAC/ISO/TC176 gives some background on
quality system standards, including the role that Canada played in the
development of ISO9000.

Dwayne D. Mathers, Robert T. Marshall, Pierre F. Callibot, Malcolm J.
Phipps (Eds.): Plus 9001 - The ISO 9000 Essentials. Missisauga,
Ontario, Canada 1994 [0-921347-40-5] pp. 7-8

________________________________


Walter Geiger: Die Entstehung, Erstellung und Weiterentwicklung der
DIN ISO 9000-Familie. In: Bernd Stauss (Hrsg.): Qualitätsmanagement
und Zertifizierung. Von DIN ISO 9000 zum Total Quality Management.
Wiesbaden 1994, S. 27-62

________________________________


> In /Glaap 93, S.28/ findet sich folgender Text: "Schon 1979 hat das
> British Standards Institute (BSI) seine Norm BS 5750 für QS-Systeme
> herausgegeben. Ursprünglich war sie für die Rüstungsindustrie
> gedacht. Die britische Regierung unterstützte jedoch aus Sorge um
> die internationale Wettbewerbsfähigkeit ihrer Produkte eine
> Weiterentwicklung für nahezu alle Industriezweige. 1987 übernahm
> dann das International Office of Standardisation (ISO) in Genf die
> Richtlinie nahezu vollständig und gab sie als ISO 9000-Serie
> heraus." /Winfried Glaap, ISO 9000 leicht gemacht, Hanser 1993/ Der
> Autor dieses kleinen Absatzes stammt aus der Praxis des
> Qualitätsmanagements (ISO 9000-Einführung, TQM etc.). In seinem Buch
> gibt er in Kapitel 1 (W.E.Deming und J.M. Juran) und 2 (Von Japan
> über Amerika nach Europa) einen Überblick zur Geschichte von
> Qualitätssicherung und -management und der Normenreihe ISO 9000.

________________________________


z. B. Modul 1 "Bedeutung" der Unterlagen zum Lehrgang "QMF 
Qualitätsmanagement-Fachkraft" der TÜV Akademie des TÜV Bayern Sachsen


Dr. Dirk Stelzer
Universitaet zu Koeln, LS fuer Wirtschaftsinformatik
Albertus-Magnus-Platz, D-50923 Koeln, Germany
Fon:  +49(0)221-470-5373
Fax:  +49(0)221-470-5386
mailto:stelzer@informatik.uni-koeln.de
http://www.informatik.uni-koeln.de/winfo/prof.mellis/stelzer.htm

------------------------------

Date: Thu, 2 Apr 1998 14:26:44 -0500 (EST)
From: "Bill Casti, CQA (System Administrator)" 
Subject: Submission from [Franco Martinig ]    (fwd)

NOTE: Respond *both* to the poster's address (see BELOW line reading
"Forwarded Message") and to the list's posting address, NOT to me.

=============================================================================
 Bill Casti, CQA                                     Email: help@quality.org
 Domain Owner, QUALITY.ORG                           Pager: +1 800 604 6149
=============================================================================


- ---------- Forwarded message ----------
Date: Wed, 1 Apr 1998 15:20:55 -0500 (EST)
To: iso9000-3@quality.org
From: Franco Martinig 
Subject: ISO 9000 and CMM status in the banking industry

Martinig & Associates recently completed a detailed survey about software
development quality in 27 banks in North America and Europe.
We asked these banks what where their status regarding the ISO 9000
standards and the Capability Maturity Model of the Software Engineering
Institute.
Here are the results:

Model/				ISO 9000			CMM
Status

Never heard about			11%				37%

Heard about				44%				48%

Usage planned			11%				11%

Implementing			0%				4%

Certified				15%				0%

Rejected after analysis		19%				0%

A third question asked if the company has its own quality model. Only two
participants answered positively.
I would like to "hear" your comments about this numbers. More specifically:
Does this what you see in your or other organisations?
Why is ISO 9000 rejected so often? (Please note that there are also some
"good quality" organisations, measured with a CMM-based evaluation, that
have rejected ISO 9000)
Why is the CMM ignored by "the masses"? (There are no significant
differences between European and North American answers to this question)

For those interested in more detailed results a PDF summary report can be
downloaded from our web site: www.martinig.ch

Thank you and best regards,

Franco Martinig


Martinig & Associates                 Tel: +41-21-922-1300
Avenue Nestle 28                      Fax: +41-21-921-2353
CH-1800 Vevey / Switzerland           Mail: franco@martinig.ch
                 http://www.martinig.ch

------------------------------

Date: Wed, 8 Apr 1998 06:42:29 -0400
From: SHASHISHEKARA Anantharamaiah 
Subject: FW: Q: Contracts and Contract Reviews as per ISO 9000-3 guideline s

Ladies/Gentlemen,

I have the following questions on contracts/ contract reviews for
software projects, with regard to guidelines given in ISO 9000-3:1997.
The clause suggests that contract is reviewed for various 'concerns' by
the supplier. The concerns are customer related, legal, technical or
management related as listed in the guidelines.

What should be the contents of the contract vis-a-vis concerns in review
of contract/ review items? Is it necessary that all the concerns ( e.g.
risks and contingencies which are management related) be documented in
the contract under review? OR is it sufficient if we identify and
document such concerns during contract reviews by means such as reports,
filled-in checklists and/or any other review policies?

Assume that certain initially identified risks known to the purchaser
are documented as a part of the contract under review. During project
planning and execution, certain other risks may come up and be managed
by the supplier. Is it necessary to amend the contract to include these
risks as well? 

I would appreciate opinions from qualified experts in the field in this
regard. Thanks in advance.

Shashishekara A

------------------------------

Date: Mon, 20 Apr 1998 09:11:47 -0400 (EDT)
From: "Bill Casti (System Admin)" 
Subject: Submission from [Mohamed Fayad ]    (fwd)

NOTE: Respond *both* to the poster's address (see BELOW line reading
"Forwarded Message") and to the list's posting address, NOT to me.

=============================================================================
 Bill Casti, CQA                                     Email: help@quality.org
 Domain Owner, QUALITY.ORG                           Pager: +1 800 604 6149
=============================================================================

- ---------- Forwarded message ----------
Date: Mon, 20 Apr 1998 04:38:05 -0400 (EDT)
From: Mohamed Fayad 
To: Undisclosed.recipients.;@cs.unr.edu;
Subject: Responses to our Nov. 1997 column


Hello All,

Below is the letters in the order in which they appeared in April 1998   
in the Communications of the ACM's Forum.  These letters are in response 
to our Communications of the ACM's columns on "thinking objectively" that 
titled "Process Assessment Considered Wasteful". If you are interested in
the columns please e-mail me.

Our response to these letters will follow this message.

You can find these letters and the response in:
1. The Communications of the ACM, Vol. 41, No. 4, April 1998
2. My web site  visit SPI.

Cheers,

Mohamed Fayad
fayad@cs.unr.edu

*******************************************************************

Readers  "Thinking Objectively"


The following letters are in response to Mauri Laitinen and Mohamed   
Fayad's "Thinking Objectively" column (Nov. 1997, p. 125)

1.
While Fayad and Laitinen have many valid points, I believe the essence of   
their arguments revolves around the application of the CMM rather than   
the model itself and its attendant assessment process as originally   
conceived. We must remember, however, that there was a dual purpose: the   
U.S. Department of Defense wanted a way to evaluate the relative risk of   
choosing Contractor A vs. Contractor B. (Watts Humphrey came up with a   
way to do this and also provide guidance on process improvement.) The   
objective was to provide guidance to the military services in selecting   
capable software contractors. The resulting method for evaluating their   
strengths and weaknesses has proved valuable for assessing other software   
organizations. Humphrey's book, Managing the Software Process, describes   
the technical and managerial topics these assessments have found most   
critical for improvement. The techniques outlined in these pages are   
grounded in the durable principles that have fueled several centuries of   
scientific and engineering advancement. These principles provide a   
powerful conceptual framework for learning about and improving the   
software engineering process.

Many organizations have focussed on "achieving Level x" rather than on   
using the principles of the CMM to guide their process improvement   
activities and help them decide where to best spend their next   
improvement dollar. That is a danger we must fight in the context of   
powerful customer pressures to treat the CMM as a goal. On the other   
hand, if we're smart, we can use that pressure as an incentive to achieve   
valuable process improvements which are beneficial from a business   
perspective.

Dick Wiana
Plano, TX

2.
As a practicing software quality manager in a commercial world, I would   
like to offer a comment on Laitinen's and Fayad's "Thinking Objectively"   
column. I believe that the reason---not excuse---why it is so difficult   
to introduce documented processes is simply that the people whom we want   
to follow them don't enjoy working that way.

You can reason and rationalize all you want, but the fact is that people   
resist what they don't like, and many of the people whom we employ to   
develop software simply don't like structure or organization or anything   
they see as a restriction.

They won't tell you that they come to work to do what they like. They   
won't argue with your unassailable reasoning---because they can't. They   
just don't want to do what you are asking for. So they don't. They'll   
offer excuses. And if you overcome the excuses they will just find more   
because you have not tackled the problem. They don't want to do it that   
way.

I don't have any answers, except maybe hire only people who like working   
in a structured environment. But will they be the people who have the   
best skills and insights? Or  a few could be fired to encourage the rest,   
probably all the good ones would then leave. Me, I'll go on working with   
the willing, struggling to persuade the unwilling and not expecting great   
success.

Josh Jones
Magill, SA, Australia

3.
Laitinen and Fayad's  points about the use of assessments in immature   
organizations are quite apt. We find that an audit-like CBA-IPI, checking   
each of the activities of level 2, doesn't really serve the organization.   
Participants are only too likely to perceive the results as indicating   
that they do nothing right. With any assessment, there are two data   
collection goals: checking compliance with a given level and identifying   
where to go from here. For immature organizations, they don't usually   
comply with many activities, so the focus is better placed on what the   
most important problems are to be tackled. This was the focus of the   
original SEI assessment technology (SPA: Software Process Assessments),   
and we find that the newer CBA-IPI doesn't serve Level 1 organizations as   
well. We generally tailor CBA-IPI's for such clients to make them look   
more like SPA's.

The general point about the applicability of the CMM to small   
organizations keeps coming up. The CMM was meant to be tailored. The key   
misunderstanding is that the CMM is NOT a list of activities that must be   
in place. It is a set of goals that a process should achieve, by whatever   
mechanism works! The goals are intended to prevent certain sets of   
problems from occurring. If an organization has other ways of preventing   
such problems from occurring, that differ from the CMM, an assessor will   
still consider the goal to have been met and the process requirements to   
have been satisfied. These are referred to as "alternative practices" in   
the CBA-IPI method. The point here is that organizations can look at the   
problems they are facing and look to the CMM for ideas of practices that   
might prevent them from occurring. They don't have to put elaborate   
systems in place, just to meet a "CMM checklist". The checklist mentality   
is something that we have to work hard to change. It is worth reiterating   
that everything in the CMM is designed to either prevent a problem or   
provide mechanisms for process improvement.

Regarding the order of adoption of KPA's and practices, this of course is   
a very contentious point and one of the differences between the CMM and   
other models. Certainly there are special organizational conditions that   
may make a higher-level practice or process area needed earlier. However,   
in general, the principle of focusing on level X issues before level X+1   
involves the following points. First, the CMM is addressing "key" process   
areas and "key" practices. This does not mean that other areas are not   
also being performed (e.g., software development itself does not appear   
until level 3!). It simply means that focusing scarce resources and even   
scarcer organizational attention on higher level practices won't yield as   
much benefit as it would if lower level practices were already in place.

For example quantitative root cause analysis (Level 5) doesn't yield big   
benefits unless done in a quantitatively managed environment (Level 4).   
 Quantitative management can't be done unless data is consistent (Level   
3). Data won't be very meaningful if you don't have the discipline to   
carry out a repeatable process (Level 2). Again, this is not to say that   
you aren't doing some measurement, analysis and defect prevention at   
lower levels. It just means that this is not a big bang-for-buck area   
compared to putting in place basic project management discipline. You'll   
get much more benefit out of tackling the level 2 issues before the level   
3 ones, level 3 before level 4 and so on.

I don't have systematic academic studies to back this up. However, many   
clients have come to us and, through CMM training and coaching, realized   
that they were trying to juggle too many processes at different levels   
and that that was why they couldn't seem to make any progress with any   
one process. Also, when we do assessments, we don't find level 1   
organizations mentioning problems that relate to level 3 or higher.   
Similarly, level 2 organizations don't mention problems relating to level   
4 or higher. Again, assessment (and improvement) is related to   
solving/preventing problems, and the order implied in the CMM is based on   
what was seen during assessments when the CMM was being developed.

I have several other comments, which I'll condense down into the   
following points.
1) Level 2 is not a "negative designation." We still don't see many Level   
2's around. It *is* a big cultural jump that takes time and effort and   
can't reasonably be divided into smaller chunks.
2)  A key contribution of the CMM is to show that there *are* several   
levels. Although each process area in any given level is "simple", it is   
not "easy" and expectations should be set accordingly.
3) Yes, assessment findings can be difficult to address, and yes,   
improvement can take time and money. Neither of these is an argument that   
they are not worth doing. Nor do they indicate a failure of either the   
model or the organization.
4) The scarcity of data is not an indication that the existing data are   
false or misleading. In the absence of data contradicting the SEI, use   
what we have so far and collect more.

The authors point out that "smaller organizations cannot afford the two   
or three year duration it normally takes to reach CMM level 3". It is not   
a matter of affording it. It is simply how long it takes to get there, if   
that is where you want to go.

Conclusions
Laitinen and Fayad suggest that organizations use assessment to evaluate   
how projects are done. Please keep in mind that this is the data   
collection role of assessment, and misses the critical consensus-building   
role.  Without organizational consensus as to which problems to address   
first, improvement is much, much harder. I heartily agree with their   
final points:

* Process improvement must be tailored
* Models must be used intelligently, not slavishly
* Focus should be on solutions, not processes for their own sake

David Constant
Pittsburgh, PA 

4.
Laitinen and Fayad say: "Assessments are very expensive, and in an   
immature organization the results are likely to be meaningless."  This is   
not true. Assessments are not expensive, either in terms of money or in   
terms of the amount of time required of the assessed organization. I   
don't know what data was used as a basis for this, but the data from the   
35 assessments that I have led doesn't jive with this statement.

Someone has seriously misled Laitinen and Fayad about the application of   
the CMM to different organizational situations. Expert assessors know how   
to tailor the model to the situation. The suggested practices are not a   
check list or an idealized set to measure against. The spirit of the CMM   
lives in the KPA purposes and goal statements. Alternate practices to   
those listed in the CMM are legitimate ways to accomplish the goals. The   
organization has broad freedom in deciding how to accomplish the goals.

The authors say: "In the decade since the CMM was first published, most   
development organizations are still at level 1 . . . most of the world's   
best known commercial software is produced by organizations at or below   
level 3."
   

Although I agree that better differentiation of organizations at Level 1   
is needed (Levels 0 and -1 have been described and proposed before), I am   
curious as to how the authors know that most development organizations   
are still at level 1---perhaps those in the SEI's database are---but is   
that representative of all organizations? And if it is true that the best   
known software is produced by level 3 and below organizations, then maybe   
that explains why we have so much subpar software in the world today.   
Most of the world's commercial software organizations struggle to get   
their software products out on time and would love to reduce their cost   
of software quality. They and we would benefit from them having more   
mature practices.

The authors go on to say: "What is the value of attaining CMM Level 5?   
... getting there is so difficult and rare, does it have meaning for most   
development organizations?" How do the authors know how difficult it is   
to get to level 5? Have they worked in or helped grow a level 5   
capability in an organization? Do they have the data to support this   
claim of difficulty? Also, the incentive for reaching higher levels of   
maturity is not getting contracts, although that may be a direct result   
of consistently producing higher quality software, on time and under   
budget. The evidence is that high maturity organizations come closer to   
assuring that life-critical or business-critical software works under   
almost any conditions.

As for the value of moving beyond level 3, it is true that levels 4 and 5   
are undergoing significant redefinition in CMM V2.0 based on what the SEI   
has learned since V1.1. Nonetheless, those who are now at those levels   
have no doubt of the added value of getting there. Reported benefits of   
moving beyond level 3 include:

*Better predictability
*Higher product quality
*Much higher process quality
*Increased customer satisfaction
*Increased job satisfaction
*Reduced cycle time
*Increased levels of reuse

Have the authors looked at the measured results of these leaders lately?   
If not then they should check out my latest article, "Accumulating the   
Body of Evidence for the Payoff of SPI," which can be found at   
www.utexas.edu/coe/sqi/archive.

On Laitinen's and Fayad's conclusions: A famous friend of mine once said:   
 "a fool with tool is still a fool." It appears that we still have lots   
of CMM and SPI fools out there.

Herb Krasner
Austin, TX


Response

See the Response Message that will follow this message.

=========================
Mohamed E. Fayad
Associate Professor
Computer Science Dept. / 171
College of Engineering
University of Nevada
Reno, Nevada 89557

Ph: (702) 784-4356
Fax: (702) 784-1877

E-mail: fayad@cs.unr.edu
	m.fayad@computer.org
Web: www.cs.unr.edu/~fayad

------------------------------

End of iso9000-3-digest V2 #5
*****************************