============================================================
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.
moderator@tenberry.com http://www.tenberry.com
============================================================
March 12, 1998 Digest # 009
============================================================
====IN THIS DIGEST=====
==== MODERATOR'S MESSAGE ====
Housekeeping
Formatting
==== 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
==== MODERATOR'S MESSAGE ====
Housekeeping
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.
Formatting
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
solving?
>
> Other than counting responses from this experiment,
> I call an end to discussions of formatting -- until next
> time! ;-)
Amen!
Jerry
website = http://www.geraldmweinberg.com
email = hardpretzel@earthlink.net
++++ 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.
Regards,
--- 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....
-rsh
++++ 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?)
Jerry
website = http://www.geraldmweinberg.com
email = hardpretzel@earthlink.net
++++ 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.
Thanks,
--
Val Stone
President
----------------------------------------------------------------------
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: icn_info@icn.kiev.ua
Temporary site: http://www.geocities.com/SiliconValley/Way/2293
----------------------------------------------------------------------
++++ New Post, New Topic ++++
From: "Phillip Senn"
Subject: In order to form a more perfect union
123456789012345678901234567890123456789012345678901234567890
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
environment.
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
programmer.
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
programming.
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. 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.3.26.
Your questions,
comments, and feedback
are welcome.
Tenberry Home