Software-Quality Discussion List
Digest # 005

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

      "Cost-Effective Quality Techniques that Work"
List Moderator:                      Supported by:
Terry Colligan                       Tenberry Software, Inc.     
February 17, 1998                     Digest # 005



    Tell your friends

    An apology

    ==== CONTINUING ====

     RE: Software-Quality Digest # 004 personals ad
       "Miller, Marlene" 

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

      Research vs design, coding vs engineering,
      validation vs testing, shrink-wrap vs bespoke
         David Bennett 

      Books you should review
         Mats Henricson 

      QA for real-time embedded firmware
         Puzzled in Cyberland

     ==== ANNOUNCEMENTS ====

      Nicholas Zvegintzov 
         Software Maintenance Conference Call - ICSM'98


  Tell your friends

  In order to have a useful discussion, we need to have a larger
  group.  I will be doing various promotional postings, but you
  can help by sending a sample copy to your friends or aquaintances
  who are (or should be) interested in software quality.

  The book review section will resume with the next issue.  (I've
  got several books finished, but didn't have time to write up the
  review yet.)

  An apology

  In SQ#003, Marion Miller wrote a bit of very good advice, which
  with I agree.  In an attempt to generate some discussion and maybe
  raise a controversy or two, my response didn't come out the way
  I intended.  Several people criticized me for "dumping" on Ms.
  Miller.  After re-reading my comments, I can see that I was
  too negative.  So, Ms. Miller:

    I'm sorry! :(

  Here is your posting again:

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 Revised comment: ++++

  These are like good ideas!  We use them in our own development.

  Do you have any specific rules of thumb to help
  get the right pieces?

==== CONTINUING ====

++++ New Post, New Topic ++++

From: "Miller, Marlene" 
Subject: RE: Software-Quality Digest # 004

>In other words, I'm old, grizzled, cranky
and opinionated. ;-)<

But are you married. . .?

Couldn't resist - it was starting to sound like a personals ad! Thanks
for moderating this list. Software quality is a big concern at our
company because we produce too much that isn't.

++++ Moderator Comment ++++

  Sorry for the personals.  Thanks for the feedback.

  Moderating is kind of fun, except that I'm not getting much material
  or comments yet -- HINT! HINT!

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

++++ New Post, New Topic ++++

From: David Bennett 
Subject: Research vs design, coding vs engineering, validation vs
  testing, shrink-wrap vs bespoke

Hi Terry and all

My reading of this group so far shows up a serious split (which is what I would have expected).

Super-mini-bio: I'm Managing Director (sort of President) of POWERflex Corporation, with 32 
years of software development.  We've been using DOS4GW via Watcom C for 4-5  years.  
PFXplus is a database application development language.  We take quality VERY seriously.  
I'm the only author of a commercial 4GL OOPS compiler I know (there are others - I just 
don't know them!)

In other words, I'm old(er), cranky (sometimes), opinionated (usually).  
Grizzled?  Working on it.

To the point.  Most of the group does (more or less) bespoke/end-user/vertical/low-
volume/application development (to over-generalise somewhat!)

Terry and I (and hopefully one or two others) do shrink-wrap/horizontal/high 
volume/systems/middle-ware development.

Speaking for our company...
1. We do lots and lots of research.  When we understand the problem and how to solve it 
we spend relatively little time on design - there are usually few choices, the code 
is small and (usually) easy to understand by one person
2. We rarely start with good specifications.  We create them as we understand what 
is possible, as compared to what is useful, what can be documented and what can be sold. 
3. We don't use CASE tools.  The ones we have looked at are simply not going our way.
4. Writing code is easy - it's knowing what to write that's hard!
5. Inspection is important.  We use a lot of ASSERTs and tracing, and subtle 
computer-science-type algorithms.  We don't have much formalised in this area.
6. We don't do a lot of testing, but we do a helluva lot of validation.  
Every engineer who designs the solution to a problem must design a validation 
test as well.  If we can't validate it, we can't write it (there are exceptions).
7. Up to the point where we release a piece of software we can change it to do 
almost anything we want.  Once it is released it is cast in concrete.  Programmers 
start using it, and we can no longer change anything.  That can be painful!

Testing: semi-random probes into software functionality in the hope of uncovering bugs.
Validation: exercising of software against a set of formal requirements resulting 
in a statement of compliance.

Testing: we didn't find any bugs.
Validation: the software complies.

In our experience the customers are relatively tolerant of newly-released features 
which don't work quite right in the first released.  They quite like the opportunity 
to provide feedback and influence the next release.  

We often strengthen validation testing based on feedback.  Customers may come to 
depend on "features" which were not part of the original specification.

Those same customers are totally intolerant of existing features which stop working 
or change in the most minor respect.  They will refuse to use (or even pay for) 
an upgrade on the basis of a single minor incompatibility, even where (in our 
opinion) we were fixing a bug from the previous version.

We always strengthen validation if a defect is missed and reaches a customer.

And finally, we are committed to quality.  To us quality simply means if you do it 
right the first time you only have to do it once.  We're too small a company to be 
able to afford to do things twice.

I don't know whether our methods would be of much use to developers of application 
software.  I do think we could learn from and possibly even give some hints to 
companies like Tenberry who (I expect) are faced with a similar situation.

PS - I think I'll get the book.

David Bennett
[ POWERflex Corporation   Developers of PFXplus ]
[ Tel:  +61-3-9888-5833   Fax:  +61-3-9888-5451 ]
[ E-mail: ]
[ Visit our Web Site:  ]

++++ Moderator Comment ++++

  I'm not so sure that there needs be as much difference as David thinks
  between the kinds of organizations.  We have done both custom, small 
  distribution, and packaged, large distribution software over time.  We
  developed our techniques on our packaged, large distribution software,
  but find that they apply equally well to custom development projects.
  What is others' experience?

  We use a number of techniques similar to David's, although we use
  different names.  I particularly agree with not being able to afford
  to do things twice!

++++ New Post, New Topic ++++

From: Mats Henricson 
Subject: Books you should review

At my company we have gone wild lately over two books:

- Rapid Development by Steve McConnell
- Software Metrics, A Rigorous and Practical Approach,
  2nd edition, by N E Fenton and Shari Lawrence Pfleeger

Very very very good books!


++++ Moderator Comment ++++

  Thanks for the suggestions.  I had Steve McConnell's book on
  my to-do list already.

  In the meantime, this seems like a pretty good endorsement for
  these books.

  If anyone else would like to write reviews from a software-quality
  slant, I'm sure people would appreciate them.

++++ New Post, New Topic ++++

From: Puzzled in Cyberland
Subject: QA for real-time embedded firmware

Dear Terry - 

I considered sending something on this to the Software Quality list, but I 
certainly don't want to make anyone look bad (especially while they're paying me
money!), but I think it's a good question. How about something like the 

One of our correspondents recently reported an interesting QA problem. He says: 
I am working on real-time embedded firmware used to control a peripheral device.
The firmware has no - repeat no - QA tests. The only acceptance test for the 
latest version of firmware is to fire up the device, run it once, and if the 
output seems normal, to declare victory and move on. The firmware has known 
bugs, some of which have been fixed, but both new bugs and regressions are 
field-reported (i.e., customers call then in!). 

Does the company allow this situation because of the daunting technical problems 
of doing QA testing in this scenario? 

Does anyone have experience in Quality Assurance for real-time embedded firmware? 

Does testing depend upon developing some sort of emulator? 

Is automated QA testing even possible? 

Would the nature of the testing depend on the nature of the device, i.e., 
would you develop different kinds of tests for, let's say, a printer as opposed 
to a modem? 

Any light would be appreciated. 
Signed, Puzzled in Cyberland.

Terry - please, withhold name and address to protect the innocent - no 
wisecracks, please. ;)


From: Nicholas Zvegintzov 
Subject: Software Maintenance Conference Call - ICSM'98

1998 International Conference on Software Maintenance - ICSM'98
in Metropolitan Washington, D.C. USA     November 16th-20th, 1998

Call for Papers
Research Papers and Experience Reports are invited.

Suggested Topics    
*    Software change verification and validation
*    Software maintenance testing
*    Software system migration and conversion
*    COTS application maintenance
*    Component-based software maintenance
*    Y2K conversion and testing
*    Software modernization
*    Software reengineering and restructuring
*    Software maintenance measurement
*    Empirical studies of maintenance activities
*    Software documentation and standards
*    Process modeling and assessment
*    Software change and impact analysis
*    Formal methods in maintenance
*    Program comprehension
*    Designing for ease of software evolution

Software system maintenance extends from correction of code to adaptation,
and enhancement of systems, designs, and architectures. ICSM'98 will
provide a forum for discussing the latest techniques, tools, and
methodologies that support software maintenance and its ramifications.
ICSM'98 will provide an international forum for researchers, developers and
users interested in software maintenance issues. Participants will include
practitioners and researchers from industry, academia, and government.

Submit five (5) copies of papers and proposals to the appropriate chair by
March 27, 1998. Paper copies are required. Electronic submissions will not
be accepted.

Web Site
Information and the full Call For Papers for ICSM'98 can be obtained at or from the Program Co-Chairs below.

IEEE Computer Society, Technical Council on Software Engineering (TCSE)

Program Co-Chairs
Taghi M. Khoshgoftaar
Empirical Software Engineering Laboratory
Dept. of Computer Science and Engineering
Florida Atlantic University
777 West Glades Road
Boca Raton, FL 33431 USA
+1 561 297 3994 Voice
+1 561 297 2800 FAX

Keith Bennett
Department of Computer Science
Centre for Software Maintenance
University of Durham
South Road
Durham DH1 3LE,  UK
+44 91 374 2632 Voice
+44 91 374 2560 FAX

++++ Moderator Question ++++

  Are these kind of announcement postings useful enough to include them?

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.17. Your questions, comments, and feedback are welcome.