Software-Quality Discussion List
Digest #001


Tenberry Home
Software-Quality Home
Reducing Defects
Automated QA
Consulting
Site Index

================================================================
           Software-Quality Discussion List

      S O F T W A R E - Q U A L I T Y    D I G E S T

         "Quality Techniques that Work for Us"
================================================================
List Moderator:                      Supported by:
Terry Colligan                       Tenberry Software, Inc.
moderator@tenberry.com               http://www.tenberry.com
================================================================
January 23, 1998                        Digest # 1
================================================================

====IN THIS DIGEST=====

    ==== MODERATOR'S MESSAGE ====

      Welcome to Software-Quality!

    ===== NEW POST(S) =====

      "Quality in a Complex Environment"
       Phil Helms


==== MODERATOR'S MESSAGE ====

  Welcome to the first issue of the Software-Quality discussion
  list digest!  I'm Terry Colligan, your moderator.  I have been
  developing software (primarily systems software) for over 30
  years.  I started this list to provide an environment where
  developers, QA engineers and software managers could exchange
  ideas about how to deploy very high quality software.

  I am hoping for a practical, results-oriented discussion,
  rather than theoretical arguments about whether or not you
  can prove that the last defect has been found.  On the masthead,
  I wrote, "Quality Techniques that Work for Us" -- that's what
  I hope we can find.

  This is my first attempt at moderating a discussion list.  I have
  modeled this list on John Audette's Internet Sales Discussion List,
  which has been the most effective discussion list I belong to.  I
  welcome comments and suggestions on the format, goals, policies
  or any other part of the Software-Quality discussion list.

  I will distribute the list as content is available, so you will
  gain as much as you put in.  I am moderating to eliminate the
  job postings and the "my language/system/etc is better than
  yours" flame wars.  We will work out more detailed guidelines
  as time goes by.  To start with, if

    1) the poster has personal knowledge of the post; and

    2) the post may help improve software quality,


  then we'll use it.

  I hope to see book reviews, programming techniqes, testing
  strategies, design techniques, horror stories, etc. -- anything
  that might help us deliver better-quality software.

  Welcome!



===== STARTING QUESTION ======

  Is it possible to economically produce software with such a low
  defect rate (< 1 defect per 100K or 1000K lines of code) that
  the users see it as defect-free?   If not, why not?



===== NEW POST(S) =====

From: Phil Helms 
Subject: Quality in a Complex Environment

Software quality in a diverse and complex environment is much harder to
achieve than in a simpler one.

A shop with 3GL and 4GL languages and a RAD tool, and with legacy,
client-server, and Web systems, and looking at data warehousing,
will have its work cut out for it trying to get everything to work
properly and together.  Add to this mix the use of both character cell
terminals and Windows PC's, with both traditional host (DEC VMS) architecture
and server (NT) architecture, plus network communications, geographically
dispersed operational units, and geographically dispersed personnel, and you
have a complicated picture.

Some quality assurance can be achieved by holding certain of the variables
of this mix constant while testing others, and in fact this is what often
happens just by default.  This suffices where an application doesn't touch
too many of the components of the total system, but trying to test out
(or just bring to a state of minimal functionality) something that depends
on more than just a few components can become nothing more than a guessing
game, and not a very efficient one at that.

Suggestions...

Minimally, identify all the components of the total system, so that you know
all your potential variables.  I believe that we often don't give this first
step very much thought.

Additionally, identify which components are significant to a particular
application, so that you know which variables you need to pay attention
to for developing and/or testing the application.

Also, identify any of the application-significant components over which you
have no control, so that you know the potential limitations of your quality
assurance efforts for the application.  Depending on what these maverick
variables are, you may be able to obtain control over them, you may be
able to anticipate their behavior, or they may be a total wildcard in the
functioning of your application.

Another thing that would be nice would be to have hardware and software
components that are, down to the level of detail at which you'll be testing
your application, sufficiently granular and non-monolithic, but which can
also be seen as black boxes below your needed level of detail.

Just some thoughts.  Any responses?

 --
 Phil Helms
 Community College Computer Services
 phil@cccs.cccoes.edu

=============================================================
The Software-Quality Digest is edited by:
Terry Colligan, Moderator.      mailto:moderator@tenberry.com

And published by:
Tenberry Software, Inc.               http://www.tenberry.com

Information about this list is at our web site,
maintained by Tenberry Software:
    http://www.tenberry.com/softqual

To post a message ==> mailto:software-quality@tenberry.com

To subscribe ==> mailto:software-quality-join@tenberry.com

To unsubscribe ==> mailto:software-quality-leave@tenberry.com

Suggestions and comments ==> mailto:moderator@tenberry.com

=============  End of Software-Quality Digest ===============

[Tenberry] * [Software-Quality] * [Zero Defects] * [Automated QA] * [Consulting] * [Site Map]
Last modified 1998.1.29. Your questions, comments, and feedback are welcome.