Software-Quality Discussion List
Digest # 003

Tenberry Home
Software-Quality Home
Reducing Defects
Automated QA
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.     
February 4, 1998                     Digest # 003



       Still Growing!


    ==== CONTINUING ====

       errors and defects
       Tim Holliefield 

       some answers
       Tim Holliefield 

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

       Quality or customers?
       julio di egidio 

       Miller, Marion 


        How separated are your QA and Development?


  Still Growing!

  We continue to grow strongly -- we now have over 200 members,
  and we haven't done any publicity yet.


  There were a number of people who had trouble retrieving files, although
  there aren't many files to retrieve as yet.  The most common problem was
  trying to retrieve files before joining the list.  I have modified the
  parameters of Software-Quality, so that this now works.

  The second most common problem was not being able to get the listed files,
  once they had gotten a directory listing.  The help text sent back was
  generic help for our mail system, not for the Software-Quality list,
  which confused several folks.  I have installed correct help text for
  the request manager, so at least you'll be told what is possible.

  Just for your information, we are running this list on a package called
  NTMail from Computer Shopper in the UK.  While the software seems to
  be fine, the operator (me) is still learning.  Also, although the
  commands are similar to majordomo or LISTSERV, NTMail is something
  different, with slightly different features/actions/commands.  I
  have tried to configure NTMail so that most forms of most commands
  will work.

  Let me know if you have any more problems.

==== CONTINUING ====

++++ New Post ++++

Subject: errors and defects
From: "Tim Holliefield" 

I think you will see little discussion of your terminology because 
anyone who cares about software quality can accept it. Good terms, I 
will try to use them in the future.

Another reason for avoiding the term bug: users also realize that
"bug" makes reference to some third party rather than the programmer.
Your relationship with the user community isn't helped when they come
to you with a problem and you blame it on something outside your
control. You wrote the software in the first place, how can it not be
your responsibility? 

Tim Holliefield             "It's in the queue"
Information System and Administrative Computing
University of Maryland, European Division

++++ New Post ++++

Subject: some answers
From: "Tim Holliefield" 

I wonder how many top quality software producers are lurking on this 
list? Would they benefit as much as someone who has, shall we say, a 
lot more room for improvement? Just to break the ice, I will admit to 
having a long way to go to producing better quality software. So 
contribute folks, you can't be doing much worse than me and my 
organization:) Just to prove it, I'll answer the moderators 


1.  How do YOU measure quality?

I don't have many formal measurements. Mostly, I estimate quality 
based on a subjective impression of number and severity of defect 

2.  How can you tell that you and your organization is doing
  a good job on quality?

Mostly I can't, except by the method described in #1 above. Sometimes 
existing software is already flexible enough to handle new 
requirements, which would indicate someone did a good job in the 

2.  How can you tell that you are doing better this year than

We count program maintenance requests. The number doesn't vary much 
from year to year.

3.  Do you count the number of times the CEO threatens you?
    (fewer is better!)

Doesn't happen.

4.  Do you count customer defect reports?

Not as explicit defect reports. As mentioned we count requests for 
service. These requests include defect correction, new work, and 
maintenance due to changes in external requirements (for example, 
Federal requirements change).

5.  Just how do you persuade some other party (like your boss
  or your customers) that you are doing well/better?

Expectations from some other party are much lower than that. The 
question is usually "can you do it or not?"


See? You are much better off than you thought (I hope). Maybe someone 
on this list has suggestions for me?

Tim Holliefield             "It's in the queue"
Information System and Administrative Computing
University of Maryland, European Division

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

++++ New Topic ++++

Subject: Quality or customers?
From: julio di egidio 

Hello SQ,

i'd like to apologize in advance for my poor English; i'll try to make
myself clear anyway.

  I've been working in Italy as a developer for about 10 years, and have
always tried to give my customers (or CEOs) high quality products by
enforcing some Software Engineering steps to my development cycle;
something like: never write any lines of code before the problem
analisys and project have been fully worked out.

  Anyway, Italy still has very poor "information technology" culture
(and CEOs are not an exception here); so i've usually to face customers
who cannot understand why i'm not happy to give them "something to see"
as soon as possible. Each time i _have_ to give them what they are
asking for, i find in troubles in a later development phase - of course!
you may say.

  Now, the question seems to be: are there any acquired practices to
face such a problem? or, is it all just due to my lack of experience
regarding developer-customer communication?

BTW, i'm posting this question because believe that, actually, most
software quality can come out from a mature software process; but we
should all know, more or less, what such a process is, while sometimes
cannot apply it because we couldn't convice our customers that that was
the way to go - or could not convince our management to buy some CASE

Kind regards,

julio di egidio

++++ New Topic ++++

From: "Miller, Marion" 

Cut your project into tiny, tiny pieces.

Each piece will be easy to understand and program.

A unit of code longer than one page/screen is too long.

Progress is rapid since each unit is error free.

Problems increase geometrically with the complexity of the coding.

++++ Moderator's comment: ++++

  These seem like good ideas -- except when you can't!

  How do you get the right pieces?

  If you construct a million-line program into pieces of
  20 lines each, you have 50,000 pieces to deal with!


  How separated are your development and QA people:

    On the same project team?

    In different departments, reporting to one manager?

    In different departments, reporting to one VP?

    In different departments, reporting to different VPs?

    Or something else?

  Does this organization help or hurt quality?

The Software-Quality Digest is edited by:
Terry Colligan, Moderator.

And published by:
Tenberry Software, Inc.     

Information about this list is at our web site,
maintained by Tenberry Software:

To post a message ==>

To subscribe ==>

To unsubscribe ==>

Suggestions and comments ==>

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

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