Software-Quality Discussion List
Digest # 009

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.     
March 12, 1998                       Digest # 009





    ==== CONTINUING ====

    Re: HTML Example
       Robin Rosenberg 

    Re: Formatting
       Jerry Weinberg 

    RE: HTML Experiment Result
       Rick Pelleg 

    RE: HTML
       Richard Hendershot 

    Re: Understandability
       Jerry Weinberg 

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

    Information about International Software QA Standards Wanted
       Val Stone 

    In order to form a more perfect union
       "Phillip Senn" 

    ==== BOOK REVIEW ====

    "Introduction to the Personal Software Process"
       by Watts S. Humphrey



  First, I'd like to apologize.  The subject of the last digest
  was wrong -- it mentioned 007 and it should have said 008.
  I am trying to find some tool to blame this on... ;-)

  I'm trying to get this out more frequently, so here is a
  shorter version.  My next projects are to do some promotion
  of this list, so we can have more people in our discussions.


  The final (for now) decision on formatting:  fixed length
  lines, 63 character, hard carriage returns, no HTML.  The
  was almost no support for full HTML.  This format presents
  okay on all environments, even though it's possible to have
  nicer formatting and live links in some environments.  We
  will revisit this in 1999.

==== CONTINUING ====

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

From: Robin Rosenberg 
Subject: Re: HTML Example

I say HTML codes (not pretty at all) and as HTML in mail is
far far from being standard, I'd would hope that the
formatting experiment goes somewhere else than the Software
Quality list.

As I understand the term Software Quality it is about
building quality into the core of software, not just make it
look good at first glance. ;-)

-- robin

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

From: Jerry Weinberg 
Subject: Re: Formatting

>  The above is an experiment.  Please tell me what you
>  saw in your mail reader.  (I got semi-formatted text,
>  but the links worked -- much to my surprise!  (Eudora
>  Pro 3.0.)

My mail reader, Claris E-Mailer 2.0, just reads it as asci
text.  It's rather readable in that format, just by ignoring
the html syntax.

I pasted into Claris Home page and viewed it as formatted.
It seems to work okay, and looks somewhat easier to read.
The links work.  But, what's the point?  What problem is html

>  Other than counting responses from this experiment,
>  I call an end to discussions of formatting -- until next
>  time!  ;-)


website =
email =

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

From: Rick Pelleg 
Subject: RE: HTML Experiment Result

Let me reword it: the HTML section showed as plain text
without any formatting or "activation" of HTML features. This
is, as far as I understand, because the Outlook editor uses
RTF internally.

Text that is in full URL syntax, such as those at the end of
your reply to me, are changed by Outlook to color blue and
underlined and are "activated" so that if  you mouse click on
them they open the associated application (browser, new mail
window, usenet, etc.).

Let me add that I am NOT using MS Word as my email editor (a
user-selectable option in Outlook), but Word 97 gives the
same behavior: it "activates" URLs but does not do anything
with HTML.

--- Rick

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

From: Richard Hendershot 
Subject: RE: HTML

Thanks for an important resource!

re: html experimental digest issue. It displayed as straight
    text in Shark!mail (an Outlook/Exchange replacement)
    which is to be expected.  Same with Outlook (from
    office97).  For me encoding using HTML will not work and
    it's impossible to read.  A text only attachment to an
    HTML digest might work, especially if RTF is used. If the
    question concerns html-only digest, I'm a hearty NO....


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

From: Jerry Weinberg 
Subject: Re: Understandability

>  I worry a bit about defects that are hard to identify
>  and/or measure, since one of my goals is to push
>  defect-free software development.
>  I agree that standards can't insure understandability, but
>  I can measure the standards I mentioned, while I don't have
>  measurements for "understandability."

Our of all the things you need to measure in software,
"understandability" is probably the *easiest*.  You take a
sample of several people from the population of people whose
job it is to understand the product.  You have them try to
understand it well enough, say, to make a few typical
modifications.  The less time it takes and the fewer mistakes
they make, the more understandable it is.

This test has the curious, and welcome, property that the
test time is clearly bounded.  If it takes more than X
minutes to perform the test, the module is simply not
sufficiently understandable enough to pass.  And how do you
determine X?  Just consider how often this module might need
to be read in its lifetime (which is many times more than it
will have to be modified).  Call that n.  Then consider how
much time you are willing to spend on it during its lifetime,
call that M, for Maximum.  Then M/n is a good upper limit for
lack of understandability.

(You might derive M from the time it takes to develop the
module in the first place.  How much of your developer time
is saved by doing things that displace the costs into
maintenance mode?)

website =
email =

++++ Moderator Comment ++++

  While I think that Jerry has made a clever and correct
  discussion of measuring understandability, I feel that this
  is too "academic" for use in most environments.

  First, I doubt that most people have any confidence in
  values for "M" or "n".  Second, in my experience the values
  of "X", "M" and "n" would be quite different for different
  modules in a system.

  But most importantly, your proposed measurement, although
  bounded, is still too long for the purpose I want to put it
  to -- to use during a code review.  Since we do code
  reviews every day, I need measurements that can be in five
  minutes, or even ideally one minute.  I think that the
  desire for measurements that can be quickly taken is the
  main reason that LOC is so popular, in spite of the various
  objections people have raised.

  I will try your test as a way to calibrate the more mundane
  measurements that I can afford to take.

  This whole discussion brings up the issue of the economics
  of software quality, which I will write up for next issue.

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

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

From: Val Stone 
Subject: Information about International Software QA Standards Wanted

Hello all,

Can anybody tell me where can I receive information about the
International software QA standards.

Any input is highly appreciated.

Val Stone 
ICN Ltd - contract software programming services at reasonable price
9/12 Baumana street, 252190, Kiev, Ukraine
Phone: 044.442.6077 / Fax: 044.443.7925 / Email:
Temporary site:

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

From: "Phillip Senn" 
Subject: In order to form a more perfect union

Flame off.
I admire having a digest devoted to software quality (SQ).
There are a number of things I'd like to talk about. But
before launching into a topic, perhaps discussing the way we
discuss things would be appropriate. It's hard to have a
meaningful talk about a subject and not divulge your exact
details.  I think that most people don't want to be
considered 'self-centered' and yet want to bring their
life-experiences to the table.  So, in response to this,
perhaps we can agree to use a fictitious project to layout,
draw upon, scribble upon, tear to pieces and otherwise spin,
fold and mutilate. I'm thinking of a simple inventory package
(with apologies to those out there who write firmware)
because that's what I've been working in most of my life (see
below for the grizzly details). An inventory system could
include any number of scenarios that we want to introduce for
problem solving.  And to make things snazzier, we could say
that it is a web page that keeps track of the inventory (I'm
making this up as I go along). Immediately you're going to
say that this is a bad idea because we'll begin talking about
the specifics of what languages can be used, or what the
latest canned package is available, etc, etc. Well, I think
we've got to talk about something 'real', or otherwise a lot
of meaning will get lost in the hyperbole of pat phrases,
such as "If the foundation is shaky, continuing to build the
house is risky and expensive".

If the idea of 'a simple inventory package' makes you want to
vomit in your hat, then maybe we can discuss a better quality
way of disseminating information through listservs.  The
amount of data that has passed through this listserv is
relatively small, I think you'd agree.  But IMHO, all the
methods developed so far have made it extremely clumsy. I'm
not talking about you Terry - I'm talking about the tools
that are available to you.  I'd like to see something in the
order of a Usenet, actually. Have the topics collapsible,
which you can point and click to follow the threads.  I'd
also transmit the original message with every digest (and all
its replies), until a message becomes a dead-end.  (A dead
end meaning that no one replied to the message).  I can hear
what you're thinking, "But that would be a lot of wasted
bandwidth".  Please folks.  When people are downloading AVI
files nightly, we shouldn't worry about our little text
entries. What am I rambling about?  There could be a lot of
discussion about a better quality listserv.  Are we up to the
task? BTW, while I've been writing all this down, MS Word97
has been helping me with my spelling and grammar.  NOW THAT'S
SQ! [Grizzly details: Programming since 1977 in languages
such as BASICA, QBASIC, BBx, VB and UniVerse Basic.  BS Comp
Sci, 1982]
Flame on.

++++ Moderator Comment ++++

  I suspect discussions about a fictitious software system,
  even a 'simple inventory package', would be even less
  effective than our current discussions -- we would get to
  argue about what the system was or was not, as well as
  everything we discuss now.

  While I don't disagree with what you are trying to
  accomplish with regard, I haven't seen the tools to make it
  happen.  All of the automated thread-making system that I
  have used so far are very sensitive to the headers that
  people choose.  As we've seen in Software-Quality, people
  aren't very consistent.  As a result, the automatic
  threading systems create 3 to 30 threads where there is
  really only one.  Even worse, many of those threads cover
  widely disparate topics, because the posters didn't change
  the Subject field when they changed topics.

  If you know of some software that works, I'd love to try
  it. In the meantime, I'll look at creating a web page with
  your ideas -- it might be doable.

==== BOOK REVIEW ====

Review of: "Introduction to the Personal Software Process"
by Watts S. Humphrey
Addison-Wesley 1997
278 pages
ISBN: 0-201-54809-7

Watts Humphrey is the creator of SEI's Capability Maturity
Model (CMM), and as such has been one of the most influential
people in the software industry quality improvement.

One of the criticisms of the CMM process is that it's very
large-organization oriented.  In response, Mr. Humphrey has
created the Personal Software Process (PSP).  This book is
an introductory text designed to teach programmers how to
use PSP to become effective software engineers.

The PSP uses systematic recording of daily data in several
different forms (sample forms provided), together with simple
models of how to interpret that data to create various
reality-based metrics, and how to use those metrics for
estimating and process improvement.

The book is designed for use in a college class, and contains
exercises for each chapter.  (There are instructor materials
separately available.)  Although the book is written towards
a classroom environment, everything except a few phrases and
examples translate well to the professional programmer's

The Chapters are:

  1. The Software Engineer's Job -- 8 pages

  2. Time Management -- 10 pages

  3. Tracking Time -- 12 pages

  4. Period and Product Planning -- 14 pages

  5. Product Planning -- 12 pages

  6. Product Size -- 16 pages

  7. Managing Your Time -- 14 pages

  8. Managing Commitments -- 10 pages

  9. Managing Schedules -- 14 pages

 10. The Project Plan -- 12 pages

 11. The Software Development Process -- 14 pages

 12. Defects -- 20 pages

 13. Finding Defects -- 18 pages

 14. The Code Review Checklist -- 18 pages

 15. Projecting Defects -- 16 pages

 16. The Economics of Defect Removal -- 16 pages

 17. Design Defects -- 14 pages

 18. Product Quality -- 14 pages

 19. Process Quality -- 16 pages

 20. A Personal Commitment to Quality -- 4 pages

 There is also a five-page index.

The first ten chapters are cover how to be an organized
software engineer, while the second ten chapters focus on how
to use the first part to improve the quality of any software
you produce.

Even though "Introduction to the PSP" is written towards the
computer science undergraduate in college, and even though I
am a grizzled veteran of more than 30 years experience, I
learned a number of useful and practical techniques that I am
adding to my programming process toolbox.

I wish that this book existed when I was learning to program.
In particular, the techniques on estimating and scheduling
show how to base your estimates on historical reality, rather
than the two most common techniques used today -- "Wild-Assed
Guess" and "Wishful Thinking".  These are the first
estimating techniques I've seen that can be taught to any

In the past, I have found Mr. Humphrey's other books to be
full of good ideas, but extremely dense and much harder than
average to read -- sort of like reading the dictionary.  This
book is still full of good ideas, but the material is
presented simply, clearly and effectively.

Mr. Humphrey's PSP approach to programming is record-oriented
and quite disciplined -- no surprise to those familiar to
those familiar with CMM.  PSP has you using forms to record
the basic data of your programming -- how long it took to
code a module, how many lines of code there were, and how
many defects there were.  Although I have never been fond of
forms or micro-management, I am trying these forms in my own

There's not a lot of theory here -- this book is more like a
user's manual for the PSP, and tells you how to use the forms
to collect data, and how to use that data for scheduling,
estimating and process improvement.  Mr. Humphrey has written
another (larger and denser) book that covers the theory and
definitions of PSP.

My advice:  Buy "Introduction to the Personal Software
Process" -- it's well written and full of practical, useful
techniques that will help almost every software engineer do a
better job.  In fact, at $24.95, buy a copy for every member
of your programming staff!  "Introduction to the PSP" is
definitely a reference that you should refer to repeatedly
and should be on your software quality reference shelf.

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