ISO 9000-3 Digest Wednesday, 11 September 1996 Volume 01 : Number 024
In this issue:
RE: Re[2]: Guidelines to improve the quality of software /
RE: Re[2]: Guidelines to improve the quality of software /
Guidelines, Protocols & Quality
Re: RE: Re[2]: Guidelines to improve the quality of software etc.
Quality-Handbook
Re[4]: Guidelines ... [ref. QA/QC/SPI etc. definitions]
Re[4]: Guidelines ... [ref.Fagan inspections]
Re[4]: Guidelines ... [ref. SQA/SCM/IT deployment]
----------------------------------------------------------------------
From: Glen Ford
Date: Thu, 5 Sep 1996 23:37:59 -0400
Subject: RE: Re[2]: Guidelines to improve the quality of software /
>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.
>
So? I've worked in one firm where the head of finance/accounting was an
engineer. And another where a (real) Quality Analyst (ex-manager in fact)
was working as a programmer and the QA Manager was a keypunch operator who
had jumped to programmer and then to QA as she ran out of ability to keep
up. Of course they never talk and the QA Manager has never asked advice
about QA.
Sorry, but companies don't always choose people based on capability to do
the job.
Having said that, there are many skills a project manager needs. Ability to
program isn't one of them. One Documentation specialist I know of is now a
project leader - the closest she's ever gotten to the technical aspects is
watching me work. Is she a good project leader - yes. She just assigns other
people to perform the technical work.
__________________________________________________________________
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: "George X. Kambic"
Date: Fri, 6 Sep 1996 09:09:29 -0500
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.
Possibly.
...
> 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.
Do you have data on this, or is this an invented example?
Is the accuracy intended to represent the difference between the
desired requirements and the actuals, or something else? Is this 90%
per team or total at the end of the life cycle? What I am assuming
that you mean is that at the end of each stage (however defined) you
have achieved 90% of the expect results, with the other 10% being
defective in some manner - missing, wrong, or extra for example.
> 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.
What data supports the accuracy statement that you make here?
>
> 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."
Fagan's original papers, some of the follow on ones, and my personal
introduction of inspections in a development organization support the
defect detection and removal process. However, I think that the
selling of inspections is a bit more complex than that. If it is
usually a little easier to introduce inspections in this manner, I
would argue it is a lot easier if you find a small group that is
willing to read the original papers because they are interested in
process, and are then willing to apply the principles. The selling
of inspections will have to take many paths. Yours is one. However,
the techniques of selling usually have to deal with satisfying the
needs of the customer. If the inspection process doesn't do this,
then it ain't gonna get sold.
George X. Kambic
kambic@ct.picker.com
Voice: 216.473.2557
Fax: 216.473.7098
------------------------------
From: "THOMAS GARVEN"
Date: Fri, 06 Sep 96 12:10:33 PST
Subject: Guidelines, Protocols & Quality
Mike Berens posts [in part]
Quality Folks -- I agree with Glen's comment on protocol - we should
try to keep our remarks public... 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 ...
George X. Kambic posts [in part]
Interesting. I worked in one organization where the engineering team
asked the QA rep to be head of the project team...
---------------1st post by Tom Garven -------------------
San Onofre Nuclear Generating Stations
San Clemente, CA
garventd@songs.sce.com OR TomGarven@aol.com
Thank you Mike, George and other list members for openly sharing
your beliefs, knowledge's and experiences with us. A brief
introduction of myself is appropriate since this is my first post. My
full name is Thomas D. Garven [friends call me Tom]. Have a PE in
quality, CQE and CQT.
Background
* 30 years in quality field
* 4 years supervising computer programming group
* 5 years training personnel in quality principles
* Internal and external consultant in the field of quality & teams
* Generally a nice guy who will be retiring in December under a
Voluntary Early Retirement program at 56 :-)
* Employed by Edison International, 16,500 employees, 2nd largest
public utility in U.S., 50,000 square mile service area, about
6,000,000 satisfied customers.
* Computer user; not a programmer :-)
So what is a San Onofre? San Onofre is the name of a nuclear power
plant located about 60 miles north of San Diego California producing
2,250 megawatts of electric power. My current assignment is the
Training Division training and qualifying engineering support personnel
and reengineering the division training processes. Typical software
we use include: *Novel *Microsoft *Wordperfect *Fortran *APL
*Powerbuilder and *Oracle.
About Posting - When I write to an individual or when I write something
for posting on a list, I try to keep in mind that whatever I write may
end up as a reference in someone's paper, book or a list as a quoted
statement. Therefore I tend to keep what I write at the professional
level as much as possible and look for the positive elements in what I
read. Enough said.
Now about Software Quality, QA, QC, BPR, Reengineering, Downsizing,
Rightsizing, IEEE, ISO, people and achieving quality. In the
highly regulated nuclear power industry we use the following
definitions for Quality Assurance (QA) and Quality Control (QC)
QA = All those planned and systematic actions necessary to provide
assurance that a ... will perform satisfactorily in service.
QC = Those quality assurance actions and organizational functions which
provide a means to control and measure ... to established requirements.
Lucky aren't we to have such clearly defined terms - or are we?
About 4/5 years ago we did a survey of our workforce and determined
what I believe every quality professional knows and understands. 73% OF
OUR WORKFORCE DID NOT KNOW THE DIFFERENCE BETWEEN THESE TWO QUALITY
FUNCTIONS. We fixed that misunderstanding in a hurry and one year
later 80% or our workforce DID know the difference and could define the
differences in detail citing specific examples.
So I believe and support George's position that "the engineering team
asked the QA rep to be head of the project...". I believe that because
that individual had probably learned to integrate the principles,
practices and processes of quality with effective project planning
based on sound business principles. In short; that individual was the
best choice for that specific project/team effort.
I also believe and support Mike's position that "a fair degree of
parochialism and skepticism about our fellow quality support services
colleagues ...". I believe this is also true because in many cases we;
the quality practitioners; set ourselves up for failure by separating
ourselves from the very partnerships we must maintain to achieve
continuously improving or specified quality levels. We should never
forget that we can reengineer a process but not quality. For so many
of the people I know; quality is a personal belief.
So how do I end this rambling on about quality? Maybe with a few
recommendations that could be of value when tempered with the wisdom
and culture of the people in your companies or divisions.
1. Insist that a Quality Engineer [or some type of quality element] be
assigned to each software development team if you are using the team
approach. Assign them to the team with the understanding that they are
responsible for the acceptable quality level of the product. A good
Quality Engineer will find ways to train, integrate the necessary
quality tools into the processes and facilitate team success.
2. Begin early; at the first sales meeting if possible but in any
case, before the project is launched; and give your internal customers
a choice. A choice like; the following Quality Engineers are available
for this project - who do you want on your team?
3. Be specific in your planning. Stay away from subjective terms such
as: fit for use, defect free, no faults. State specific achievable
quality objectives like; the following four algorithms ... shall be
independently verify by manual calculation and certified by ... you get
the idea.
4. Develop a strategic plan this week to ELIMINATE the Quality
Assurance/Quality Control Department/Division. No don't eliminate the
people - just the titles. You do believe that quality is everyone's
business right? Strive to get your quality people out of their
offices and into the processes and teams where they belong.
5. Treat your quality staff like a RESOURCE not a POSITION. At Edison
International we do not have a Director of Quality, V.P. of Quality,
Senior Vice President of Quality or any other title which would be
representative of a quality champion. Oh sure we have CQE's, CQA's,
CQT's, Quality Control Engineers and Inspectors but NONE are assigned
to a department or division entitle quality something. They are
integrated into each business unit needing their specific talents.
Well o.k. that's enough for my first post and maybe for the rest of
this year :-). Questions and comments are welcomed and will be
answered as quickly as possible.
Now if someone could just tell me which Mutual Funds will be the best
performers in '97; I could get ready to roll-over my 401k and life
would be sweet :-)
Tom Garven
------------------------------
From: dbarnes@cix.compulink.co.uk (Dave Barnes)
Date: Sun, 8 Sep 96 16:09 BST-1
Subject: Re: RE: Re[2]: Guidelines to improve the quality of software etc.
In-Reply-To: <271C5B4AB2@ct1.ct.picker.com>
> > 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.
>
> Do you have data on this, or is this an invented example?
> Is the accuracy intended to represent the difference between
> the desired requirements and the actuals, or something else?
> Is this 90% per team or total at the end of the life cycle?
> What I am assuming that you mean is that at the end of each
> stage (however defined) you have achieved 90% of the expect
> results, with the other 10% being defective in some manner -
> missing, wrong, or extra for example.
>
Invented example - and yes to 90% accurate per stage.
> > 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.
>
> What data supports the accuracy statement that you make here?
> >
Should have gone back to my notes rather than trying to
remember. 0.9 to the power 4 is about .65 - so 65% correct (not
63% as stated above). 0.9 to the power 5 is about .59 so 59%
correct (not 55% as above).
As for accuracy - personal experience of teams I have worked
with - most have an error rate of about 1 in 12 to 1 in 20 for
enhancements/corrections to existing code (ie, in the first
case, for every twelve Change Requests incorporated, one is
likely to be wrong in some respect) when I first start working
with them.
As for new code, error rates vary widely, depending on the
language used, the experience of the people, whether CASE tools
are available (and used properly), even how well the
requirements were specified, etc.. but, for coding in a 3GL,
about 20 faults per kloc is a good approximation *if* you count
all the faults found from Integration Test up to the end of the
first 6 months usage. Whether this is an error rate of 2% or
100% (if all procedures have more than 1000 lines) depends on
how faults are gathered and categorised.
However, I always emphasise that the data are invented and
indicate that *reduction* in the numbers of faults produced is
the aim - not simply to get a fault-rate which is less than
some mythical industry average.
> > 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."
>
> Fagan's original papers, some of the follow on ones, and my
> personal introduction of inspections in a development
> organization support the defect detection and removal
> process. However, I think that the selling of inspections is
> a bit more complex than that.
Agreed - but the above is used when I hit "QA = test and that's
all we need do" mentality and is to get through to the
managers. The people actually doing the work usually don't need
to be convinced.
> If it is usually a little
> easier to introduce inspections in this manner, I would argue
> it is a lot easier if you find a small group that is willing
> to read the original papers because they are interested in
> process, and are then willing to apply the principles. The
> selling of inspections will have to take many paths. Yours
> is one. However, the techniques of selling usually have to
> deal with satisfying the needs of the customer. If the
> inspection process doesn't do this, then it ain't gonna get
> sold.
Agreed again - but I have usually found that the team aren't
willing to do this work without their manager's knowledge.
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."
------------------------------
From: noltet.mt-consult.da@t-online.de (Thomas Nolte)
Date: Wed, 11 Sep 96 18:20 +0100
Subject: Quality-Handbook
Dear subscribers,
does anybody of you have experience in writing a quality handbook which ist
oriented on iso 9000-3 and does anybody knows a good guidance for implementing
a quality system?
The most quality handbooks are oriented on iso 9001 (20 quality system
elements).
Regards
Thomas Nolte
noltet.mt-consult.da@t-online.de
------------------------------
From:
Date: Wed, 11 Sep 1996 13:07 -0500 (EST)
Subject: Re[4]: Guidelines ... [ref. QA/QC/SPI etc. definitions]
Date: Wed, 11 Sep 1996 13:00 -0500 (EST)
From: Michael_S_Berens%bal-skyline-cc-p@ccmail.orl.mmc.com
Subject: Re[4]: Guidelines ... [ref.Fagan inspections]
To: Locklin@OIEng.MKE.AB.Com, Lawrence@ACM.Org
Cc: "ISO9000-3"@quality.Org
MIME-version: 1.0
Content-type: TEXT/PLAIN
Software Industry Quality Forum (SWIQF)
SWIQF Folks,
A recent palaver here in the ISO9000-3 (Sfw) Email list ranged into
basic terms and concepts, some of which have differing acceptances.
George Kambic, Glen Ford and others from ISO9000-3@quality.org may be
interested in recent and planned events at the SWIQF.
Please send us a brief EMail synopsis of recent and planned SWIQF
events.
Thanks
Mike Berens, CSQE
ASQC-SD Liaisons Committee
Lockheed Martin DEIS
Two Skyline Place S#1500
Baileys X-Rds, VA 22041-3401
703/671-2967;-3400/ext.304; Fax:-2974
------------------------------
From:
Date: Wed, 11 Sep 1996 13:00 -0500 (EST)
Subject: Re[4]: Guidelines ... [ref.Fagan inspections]
Software Inspections Research Organization (SIRO)
SIRO Folks,
A recent palaver here in the ISO9000-3 (Sfw) Email list ranged into
Fagan and recent methods.
George Kambic and others from ISO9000-3@quality.org may be interested
in current event at the Software Inspection Research Organization
(SIRO).
Please send us a brief EMail synopsis of recent and planned SIRO
events.
Thanks
Mike Berens, CSQE
ASQC-SD Liaisons Committee
Lockheed Martin DEIS
Two Skyline Place S#1500
Baileys X-Rds, VA 22041-3401
703/671-2967;-3400/ext.304; Fax:-2974
------------------------------
From:
Date: Wed, 11 Sep 1996 13:18 -0500 (EST)
Subject: Re[4]: Guidelines ... [ref. SQA/SCM/IT deployment]
Date: Wed, 11 Sep 1996 13:07 -0500 (EST)
From: Michael_S_Berens%bal-skyline-cc-p@ccmail.orl.mmc.com
Subject: Re[4]: Guidelines ... [ref. QA/QC/SPI etc. definitions]
To: naselby@CCGATE.HAC.COM, Henry@dynacomm.fse.comm
Cc: "ISO9000-3"@Quality.Org
MIME-version: 1.0
Content-type: MESSAGE/RFC822
Date: Wed, 11 Sep 1996 13:00 -0500 (EST)
From: Michael_S_Berens%bal-skyline-cc-p@ccmail.orl.mmc.com
Subject: Re[4]: Guidelines ... [ref.Fagan inspections]
To: Locklin@OIEng.MKE.AB.Com, Lawrence@ACM.Org
Cc: "ISO9000-3"@quality.Org
MIME-version: 1.0
Content-type: TEXT/PLAIN
Society for Software Quality (SSQ)
Chris & other SSQ Folks,
I apolohgize for missing your recent meeting in Herndon. Please fill me in
with your speaker's reasons for pessimism about CMM ratings.
A recent palaver here in the ISO9000-3 (Sfw) Email list ranged into
a discussion about disbursed vs. concentrated software quality
roles. Though the CMM does not proscribe a specific organizational
approach, I believe it tends to favor the concentrated mode by its
need to verify independent reporting. Does SSQ have any guidance
on this issue?
George Kambic, Glen Ford and others from ISO9000-3@quality.org may be
interested in recent and planned events at the SSQ.
Please send us a brief EMail synopsis of recent and planned SSQ
events when convenient.
Thanks
Mike Berens, CSQE
ASQC-SD Liaisons Committee
Lockheed Martin DEIS
Two Skyline Place S#1500
Baileys X-Rds, VA 22041-3401
703/671-2967;-3400/ext.304; Fax:-2974
------------------------------
End of ISO 9000-3 Digest V1 #24
*******************************