ISO 9000-3 Digest Wednesday, 1 May 1996 Volume 01 : Number 014
In this issue:
FW: Design Validation
Re: Design Validation
an input on 'design validation'
ISO 9000 Contract Jobs in Chicago (fwd)
Re: Design Validation
workshop on software process automation (fwd)
Re: Design Validation
Require info on managing software quality. (fwd)
FW: ISO 9001 book review
Re: Design Validation/One mo' time
Re[2]: Design Validation/One mo' time
----------------------------------------------------------------------
From: "Gomes, A Ferdinand PL"
Date: Tue, 16 Apr 96 10:11:00 GMT
Subject: FW: Design Validation
To Dhruba P Sen,
Your enquiry: > In the context of ISO 9001 registration for SW houses, how
does one
accomplish DESIGN VALIDATION ? (Pl also refer to the Draft ISO 9000-3
:9001-94).<
Here is a brief explanation as I understand it.--
I'll begin with Design Verification to put it in perspective.... Tests are
planned, developed and carried out to verify that the software product meets
the Design Spec (i.e. what it was designed to do)
Design Validation, on the other hand, validates that the software meets the
clients'/users' intended product functional requirements and needs.
To accomplish this, one approach may be to test the FINAL (controlled
release) software against the product requirements spec (not against the
design spec). Functional tests are also included at this stage. It's very
much akin to a beta test (or Field Test). (In a later email you enquired
about use of prototyping... if the prototype is your final product then it
may apply. I imagine that the prototype would evolve to meet client needs
etc... )
Hope this helps some.
Cheers,
Ferdi Gomes, ISO 9000 Coordinator/Manager,
Imaging Systems & Manufacturing,
Unisys, Plymouth, Michigan, USA.
gomesaf@po4.pl.unisys.com
Tel. 313 451 4241 ( Unisys net 262-4241)
------------------------------
From: "OTTER"
Date: Wed, 17 Apr 1996 10:47:09 +0000
Subject: Re: Design Validation
> In the context of ISO 9001 registration for SW houses, how does one
> accomplish DESIGN VALIDATION ? (Pl also refer to the Draft ISO 9000-3
> :9001-94).
> --
In industry, design covers the product specifications and the initial
prototype construction. Production then covers mass production.
For software development, we interpret the design concept as all the
life cycle until the end of contractual obligations.
So, software design, in the ISO 9001 sense of the word, is only
completed when the software is finished and covers all stages, from
design, in the computing sense of the word, to acceptance by the
customer. It includes specification, coding and tests.
This choice is justified by the growing use of prototyping cycles
during which software specifications gradually emerge and only
stabilize during the final validation stage.
For design verification , we must develop test procedures and
procedures for checking documents and intermediate products or
associated services. All products delivered must be checked before
delivery. Records must kept of checks performed.
This is the point of view of ADELI (Association de genie logiciel,
http://lgl.www.epfl.ch/Team/NG/ADELI/ADELI.html).
Other points of view could be considered, such as limiting design to
"analysis" activities, or presenting development work as a service
production activity.
Martine Otter, Quality Director
SG2, France
e-mail: otter@micronet.fr
http://www.sg2.fr
------------------------------
From: "Jon Prescott [70743,3250]" <70743.3250@CompuServe.COM>
Date: 17 Apr 96 11:50:18 EDT
Subject: an input on 'design validation'
Re: "design validation" I have been reading different views on
this with a coworker and neither of us has yet seen much that
we could in fact validate.
How about reviewing/evaluating the perceived requirements, checking
of course for testability, then driving these reqmts into a (high level)
design, while checking for and verifying as best as possible what
knowledge of interfaces, and did I neglect to mention update the docu-
mentation on reqmts and the design ?
Next drive this design down into a detailed design by clearly and
concisely specifying the English narrative of all pertinent details
of the required processing involved in, e.g., a reqmt to delete a
data item from a data structure kind of s/w reqmt ? Again, there is
work to be done in doing the interfaces as well as any algorithm ....?
Hope the above helps and is not too confusing !
------------------------------
From: "Bill Casti, CQA (Moderator)"
Date: Wed, 17 Apr 1996 21:11:38 -0400 (EDT)
Subject: ISO 9000 Contract Jobs in Chicago (fwd)
NOTE:
This message is being distributed widely to a number of ISO related
lists, so you may get duplicates. Sorry.
- ---------- Forwarded message ----------
Date: Wed, 17 Apr 1996 04:29:08 -0700
From: Bret Lokken
Subject: ISO9000 Writers Needed (Contract)
Location: Chicago Metro Area
Duration: 3-6 months (may be much longer)
My name is Bret Lokken and I work for Aerotek Contract Engineering.
One of my clients needs three writers to assist with their ISO9000
documentation. I am running into all sorts of problems finding
qualified individuals. Can you help?
Thank you for your time.
Sincerely,
Bret Lokken
Technical Recruiter
Phone 1-800-676-7955.
- -----------------------------------------------------------------------------
This message is being distributed widely to a number of related lists, so
you may get duplicates. Sorry.
- -----------------------------------------------------------------------------
------------------------------
From: "William J. Deibler II"
Date: Thu, 25 Apr 1996 01:02:18 -0700 (PDT)
Subject: Re: Design Validation
On Tue, 16 Apr 1996, Dhruba P. Sen wrote:
> In the context of ISO 9001 registration for SW houses, how does one
> accomplish DESIGN VALIDATION ? (Pl also refer to the Draft ISO 9000-3
> :9001-94).
> --
> Dhruba P Sen,Senior Manager(QMG)
> Tata Unisys Ltd, Nepz, India
> E-mail: dpsen@tulnepz.unisys.com
> Voice : (011-8) 562356, 562376, 562583, 562585, 562588-92
> Fax : (011-8) 562584
Dhruba,
Design validation can be accomplished by a variety of means.
Typically companies validate by performing testing at a system level
against a functional description of the product. The functional
description of the product might be a specification, a user guide,
or some other document that outlines the functional behavior of the
product.
Validation testing is often used to simulate how the product will be
used in the customer environment. Integration, Product Assurance,
and Beta Tests are mechanisms that are often used to validate a
product.
Essentially, when we validate, we check out the "whole enchilada",
if you'll excuse the expression.
Remember, when ISO 9000 refers to design, as in design control, they
are referring to the entire software development process.
Sincerely,
Bill
- --------------------------------------------------------------------
Bill Deibler SSQC
SSQC Webinfo-> http://www.cris.com/~ssqc 2269 Sunny Vista Drive
Phone/Fax (408) 985-4476 San Jose, CA 95128
------------------------------
From: "Bill Casti, CQA (Moderator)"
Date: Thu, 25 Apr 1996 17:13:59 -0400 (EDT)
Subject: workshop on software process automation (fwd)
FYI....
- ---------- Forwarded message ----------
Date: Thu, 25 Apr 96 14:36:16 EDT
From: Alan Christie
To: quality@PUCC.PRINCETON.EDU
Subject: workshop on software process automation
Request for Participation in a Workshop on
------------------------------------------
Identifying Succcess Strategies for Software Process Automation
---------------------------------------------------------------
As a recent SEI study indicates, software process automation has yet to make
noticable impact in practical application. The evidence gathered also suggests
that there is still a significant gap between what technology currently
provides and what end-users need. The objective of this one-day workshop is to
explore why this gap is as large as it is, and to identify strategies to
reduce it. The workshop also aims to foster communication between the diverse
elements of the software process automation community.
The workshop is intended for individuals who have experience in one of the
disciplines needed to address the above issues. Thus we encourage those with
appropriate research, development, adoption and end-user perspectives to
attend this event, and to contribute their views.
The first part of the workshop will be devoted to a number of presentations on
process automation technology, and on what elements should be put in place for
its successful adoption. We are soliciting a 10-15 minute presentations that
deal, for example, with limitations in the underlying technology, in what
makes for good or poor process-centered environment design, or in what makes
adoption strategies effective or ineffective. The latter part of the workshop
will actively involve the participants in addressing technology or adoption
inhibitors to the use of process automation, and exploring strategies to
mitigate these inhibitors.
The workshop will be held on September 9, 1996 in conjunction with the Software
Engineering Institute Symposium. Further details can be found at:
http://www.sei.cmu.edu/technology/ASPAworkshop/
or by contacting Alan Christie
e-mail: amc@sei.cmu.edu
phone: 412-268-6324
------------------------------
From: doug@mincom.com (Doug Thiele)
Date: Fri, 26 Apr 1996 10:48:21 +1000
Subject: Re: Design Validation
>Remember, when ISO 9000 refers to design, as in design control, they
>are referring to the entire software development process.
>Bill Deibler SSQC
This is one view. The words "Design and development" in section 4.4 of ISO
9001 derive from the manufacturing world where the design may need to be
developed e.g. through modelling etc. Some areas of the software industry
have taken the presence of the word development in section 4.4 in a purely
software context. In a prototyping situation this may make sense, but in a
full life cycle software project it may make sense to use section 4.9. Note
that items in 4.9 such as "monitoring and control of suitable process
parameters and product characteristics" and "suitable working environment"
are not covered in 4.4.
In a similar vein, the words "test software" in 4.11 were not originally
referring to computer software explicitly. Specific data which is used to
calibrate a piece of equipment can be included under this banner.
In the end it doesn't really matter how you map your system into ISO 9001 as
long as all the necessary parts are covered.
- --
Doug Thiele
Mincom Pty Ltd, Brisbane, Australia tel +61 7 3303-3139
doug@mincom.com fax +61 7 3303-3232
------------------------------
From: "Bill Casti, CQA (Moderator)"
Date: Mon, 29 Apr 1996 08:49:57 -0400 (EDT)
Subject: Require info on managing software quality. (fwd)
NOTE: Respond only to the poster's address (see below) and/or to the
list, not to me. (He is not a subscriber to the ISO9000-3 list, but you
should encourage him to be one.)
Thanks.
Bill
- ---------- Forwarded message ----------
Date: 29 Apr 1996 09:14:38 GMT
From: David Craft
Subject: Require info on managing software quality.
I am a final year Information Technology at the University of Queensland,
Australia, and I have been assigned the task of writing a paper onmanaging
software quality. In particular, I am to critically assess the options
for managing quality within a software development team.
Initially I am required to submit a list of sources of info as well as an
outline of what the paper will cover.
If anyone is able to supply any info,viewpoints, sources etc it would be
greatly appreciated. I can be emailed at: s331256@cello.cs.uq.edu.au.
Thanks for any help that you can give.
David Craft
B.InfTech University Of Queensland
------------------------------
From: Arnold Miller
Date: Mon, 29 Apr 1996 16:16:22 -0600
Subject: FW: ISO 9001 book review
- ----------
From: David Askey[SMTP:askey@sweng.stortek.com]
Sent: Friday, April 26, 1996 4:51 PM
To: miller@xytp.com; askey@sweng.stortek.com
Subject: ISO 9001 book review
Hi Arnold,
Thought you might be interested in this. You might want to forward
it to your local mailing list, or post this on a web site.
- --David Askey
========================================================================
ISO 9001: Interpreted for Software Organizations
by
Ronald A. Radice
A NEW BOOK BASED ON THE NEW
JULY 1994 VERSION OF THE ISO 9001 STANDARD
Contains the Full Text of the ISO 9001 Clauses
FOREWORD by Watts Humphrey
Editors Notes: We received this in incoming Email and have reprinted it
with credit to Mr. Ron Radice, Software Technology Transition
ABOUT THE BOOK:
You'll want to read this book
- If you are interested in software process improvement (SPI)
- Are pursuing ISO 9001 registration
- Even if you already have ISO 9001 registration
- You are not a software organization, but are interested in ISO 9001
The book has completed a worldwide technical review in six countries
with over 20 ISO 9001 experts.
As one reviewer said, "This book was needed five years ago when the
standard was in its beginning use. It is still very much needed. It
makes a dense subject easy to understand, especially because it takes a
business perspective."
One user recently said, "I have been using your book along with a tem-
plate for a Quality System Manual provided in another book on ISO 9000,
to help me create a Quality System Manual. I have found your applica-
tion of the standard to software development extremely helpful. I think
I would have been feeling my way in the dark without it."
"In short, this book is designed to be used. If you are interested in
ISO 9001 you should use it." -Watts Humphrey
Topics covered include:
Quality Management Systems (QMS):
-Contents
-Objectives
-Best approach
-What to be sensitive to when developing a QMS
-How to establish a QMS that meets your business needs
Audits:
-What are the different types
-Auditee's responsibilities
-Auditor's responsibilities
-How do auditors work
Getting Registered:
-The steps that you should follow
-Business reasons to consider
-Avoiding overkill
-Taking a pragmatic approach
For each of the 20 Clauses in ISO 9001:
-Fully stated clause from the standard
-Encapsulated, easy to read, requirements restatement
-Explanation of each requirement
-Interpretation for software
-Risks associated with each requirement
-What auditors will look for
ABOUT THE AUTHOR:
Ronald A. Radice is a principal partner in Software Technology Transi-
tion, a company that provides training, consulting services, diagnostic
services, and software engineering methods and tools. He is a past
Director of the Software Process Program at the Software Engineering
Institute (SEI) at Carnegie Mellon University. Previously he was the
Director of Software Resources at Groupe Bull. He worked at IBM for 23
years in technical and managerial positions across all aspects of the
software life cycle. Ron has co-authored Software Engineering: An
Industrial Approach. From 1984 to 1988 Ron taught software engineering
on the graduate level at Rensselear Polytechnic Institute.
Contact: PARADOXICON PUBLISHING, PO Box 1095, Andover, MA 01810.
========================================================================
- - Arnold Miller (miller@xytp.com) 303-443-7006x19
- - ASQC Section 1313 ISO 9000 Chair
------------------------------
From: "William J. Deibler II"
Date: Tue, 30 Apr 1996 09:51:18 -0700 (PDT)
Subject: Re: Design Validation/One mo' time
On Fri, 26 Apr 1996, Doug Thiele wrote:
> >Remember, when ISO 9000 refers to design, as in design control, they
> >are referring to the entire software development process.
> >Bill Deibler SSQC
>
> This is one view. The words "Design and development" in section 4.4 of ISO
> 9001 derive from the manufacturing world where the design may need to be
> developed e.g. through modelling etc.
Doug,
I would add that the language "design" is used in other development
environments as well. Again, in the hardware development arena, the
term "hardware design" encompasses the entire development process.
> Some areas of the software industry
> have taken the presence of the word development in section 4.4 in a purely
> software context.
Not sure what you mean. The definitive interpretation from ISO is
outlined in 9000-3. Anyway, the heart of the development process is
encompassed within design control.
> In a prototyping situation this may make sense, but in a
> full life cycle software project it may make sense to use section 4.9. Note
> that items in 4.9 such as "monitoring and control of suitable process
> parameters and product characteristics" and "suitable working environment"
> are not covered in 4.4.
Let me clarify something. This discussion did not branch into 4.9
or any other clause other than 4.4. The interpretation outlined in
the 1991 version 9000-3 recognizes that process control in software
relates to project management and other key issues.
The sad thing is that the current proposed committee draft of 9000-3
is not applying the same interpretation. They are proposing that is
apply to only software replication.
Part of the problem with 9001 is that some key words are not defined
in any of the ISO vocabulary. Two key words are design and
production.
I would argue that clauses like 4.8, 4.9, 4.10, 4.12, and 4.13 have
significant impact when interpreted for software.
For example, design validation and final inspection and testing
could be tightly coupled. The testing reqts. are better defined in
the 4.10 clause.
> In the end it doesn't really matter how you map your system into ISO 9001 as
> long as all the necessary parts are covered.
Not sure what the statement implies. Here are my thoughts. It's
important to understand the implications of the clauses to the way
you develop software.
There is nothing contained within 9001 that isn't fundamental good
software engineering. The standard does not prescribe any
particular method. It's what's not how's.
It's essentially a functional specification, not a design specification
for quality. ;}
bill
- --------------------------------------------------------------------
Bill Deibler SSQC
SSQC Webinfo-> http://www.cris.com/~ssqc 2269 Sunny Vista Drive
Phone/Fax (408) 985-4476 San Jose, CA 95128
------------------------------
From:
Date: Wed, 01 May 1996 15:03 -0500 (EST)
Subject: Re[2]: Design Validation/One mo' time
Bill Deibler,
You are so correct - the Non-software QA & CM folks have divergent
priorities from software engineering. The assumption that a general
standard on QA & CM can be interpreted/focused by a guideline ignores
the unique requirements for software, especially in our modern
prototyping, reuse-driven and components-first paradigms.
The general-purpose standards do not even define fundamentals like
templates, components and frameworks, let alone indicate proper controls,
review agents, and inspection criteria for advanced software artifacts
such as object class/inheritance relationships, testbed/scaffolding and
user hypertext.
Keep pitching and keep the strike-zone open,
-- Mike Berens, Lockheed Martin DEIS
------------------------------
End of ISO 9000-3 Digest V1 #14
*******************************