Software-Quality Discussion List
Digest # 004


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

      "Cost-Effective Quality Techniques that Work"
============================================================
List Moderator:                      Supported by:
Terry Colligan                       Tenberry Software, Inc.
moderator@tenberry.com               http://www.tenberry.com
============================================================
February 7, 1998                     Digest # 004
============================================================

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

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

      Changed tag line

      New feature -- book review

      Moderator's bio


    ==== CONTINUING ====

      ?handling CEOs?
        George B. Durham 

      RE: Quality or customers?
        Subramaniam S 


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

      ISO 9000-3
        Luis T. Gutierrez 

      The long term prospects of testing jobs
        Phil Reeves 


    ==== BOOK REVIEW ====

      "SOFTWARE Rx Secrets of Engineering Quality Software"
         by Rodney C. Wilson




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

The messages in this digest are as submitted,
except that my mailer is very cranky about
spelling, and I reformatted a bunch of the
text to create smaller lines.  I would
appreciate contributions to be limited
to 60-character lines, since that's what I am
trying for.

I changed the tag-line for the list slightly
with this issue.  The new featured point is
to concentrate on cost-effective quality
measures.  As I give speeches to local groups
about various quality groups, I am always
surprised by the wide-spread assumption that
true quality is too expensive, so we have
to settle for something less.  This attitude
is almost universal, *even in professional
quality groups*!  Obviously, I disagree.
More on this in future issues.

I have added a new feature with this issue --
a book review.  Every so often, I will review
a book that ought to be of interest to the
members of our Software-Quality list.  If any
one else would like to write a review of a
book that might help produce better software,
I'll be glad to include it.

Just so that you have some idea of who is
writing all this stuff, I include a mini-bio:
I have been programming professionally for 31
years, and managing programmers for 23 years.
I learned to program at MIT, and have mostly
worked on systems programs (compilers, real-
time, OS's, etc.), and middleware and packaged
software products.  I have managed small to
mid-sized groups (up to about 50 people), and
I've been president of my own company for the
last 14 years.  I am the co-creator of the
first DOS extender, and the creator of the
only commercial incremental C compiler, Instant-C.
I was a signing member of the ANSI C committee.
I have been interested in software process
improvement and software quality for about
30 years.

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



==== CONTINUING ====

++++ New Post ++++

Subject: ?handling CEOs?
From: "george b. durham" 

julio di egidio
julio@webzone.it wrote:




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.


although i don't necessarily agree with everything he
has to say, steve mcconnell says in his "software project
survival guide", microsoft press, 1998, that we should
produce a gui interface quickly in the project to show
users (ceo's) what it will look like.  everything under
the gui should be stubs, at the beginning, and as the
project advances, more functionality is built in (as
requirements become better defined.)  i have to agree that
this approach gives the users a more warm fuzzy feeling,
and can also aid you, the developer, because it can help
define the project.  ((read the book for a more detailed
description))

at first glance, i admit, the idea is not appealing, but
the more you think about it, i think you will agree that
it has merit.  just be cautious not to try to build too
much functionality into it too early, nor should you try
to build to many bells and whistles into it which clutter
the project, as well as making it more complex.

g.durham, gdurha1@erols.com


++++ New Post, same topic ++++

Subject: RE: Quality or customers?
From: Subramaniam S 

> 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?

IMO,  you must give priority to Software Development process 
first than to customer requests.  Without a development 
process, it is almost impossible to measure or predict the 
quality of a software product.  If the customer insists on 
quicker delivery, he/she should be explained about the 
necessity of waiting to receive a good quality product. 
There is no quick-fix to get your problem.  If you skip any 
steps in the software development process, it will show-up in 
poor quality of the final product.

I have seen multiple examples how a code or design inspection 
has helped reduce the number of defects.  Whatever products I 
will develop, I will never bypass inspection stages.

> 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 tools!

I am working for a SEI 4 level company.  Believe me, I am not 
aware of anyone using CASE tools in my organization.

Subra




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

++++ New Topic ++++

Subject: ISO 9000-3
From: "Luis T. Gutierrez" 

Hello everyone,

Any experience out there with ISO 9000-3?  
Does the process of getting certified actually 
induce higher SQ?  Does anyone know about 
other SQ standards that really help improve SQ?  

Luis

++++ Moderator Comment ++++

  I just finished Watts Humphrey's "Introduction
  to the Personal Software Process".  I think it
  might help a lot of people -- I'm going to be
  trying parts of it myself.  I presume that it
  is or will be a SEI 'standard'.


++++ New Topic ++++

Subject: The long term prospects of testing jobs
From: Phil Reeves 

I've seen many discussions about 'how', 'why', 
'where' and 'who' for software testing, but 
there is one, important aspect I suddenly realized
that I'd _never_ seen people discuss:

Is software testing a "Job for life"?

I get the impression that in the vast majority of 
cases, QA and testing are treated as stepping-
stones to other posts that inevitable are perceived
as being more interesting and 'glamorous.' 

I have been working in a software testing role 
for nearly 3 years, and in that time I have 
proven that I have the skills (No point in being 
falsely modest) to venture into just about any 
avenue of the IT world.

I am not talking about a job that requires me to run
(by hand) through a list of pre-written checks to 
perform on the software. Although to some unfortunate
souls, this is all testing involves, I am lucky in 
that my current post requires a fairly high level 
of technical knowledge and programming ability. 
Writing code to automatically reproduce events and
report on Windows applications can in some cases be
as complex as writing the applications themselves. 
(In fact, occasionally more so.)

And yet, it is still my perception that I would 
get more satisfaction, more recognition, a better
working environment, (Not to mention more money...)
if I used my skills on the 'other side' of the 
software cycle and got programming 'real' applications.

My questions, then, are:

- What do other people perceive the 'status' of 
   a QA job to be, compared to a development role
   of the same experience?
- Is the perception that QA is a 'worse' job than
   development justified?
   How? (/How not?)   
- (As someone responsible not only for my own career,
   but also for keeping current QA personnel happy
   in their jobs) How can we improve the situation
   and prevent people with testing experience drifting
   off to other posts?

  Phil

 -------------
|  Phil Reeves, GUI QA Team Leader, 
|  Cyberscience Corporation
|  par@cyberscience.com

|  The views expressed herein are not necessarily
|  those of my employer. Or mine, either, for that
|  matter; I might just have been typing in my sleep.


++++ New Topic ++++

Subject: Problems in Q. S/W development
From: BIKER ON THE ROAD 

Hello SQ,
I am working with legacy software system that 
was developed in 1966 and is continuing to develop.
We face many problems during development in such 
a system.

I will use my experience in that system to 
describe what type of problems we might face when 
we want to extend such systems:
1. Uncomplete documentation.
2. Non-standard way of documenting various
   developments.
3. Purchased extensions come with different kind
   of documentations.
4. Difficulty to develop standards for assembly coding.
5. Difficulty to enforce standards for assembly 
   programmers - desktop checking?

Any help will be appreciated to solve these problems
I'll post my solutions in a later post
thanks ... Biker

++++ Moderator Comment ++++

  We've found that informal peer code reviews have
  had a big positive influence on assembly programming
  quality -- sort of an informal standard which grows
  stronger and tougher over time.



==== BOOK REVIEW ====

Review of:
"SOFTWARE Rx Secrets of Engineering Quality Software"
by Rodney C. Wilson
Prentice Hall PTR 1997
138 pages (plus 46 pages of appendices)
ISBN: 0-13-472663-4

I had high hopes when I started reading this book.  Many
books on software quality tend to be abstract, and I was
hoping for practical prescriptions on how to achieve
quality software.

Mr. Wilson's stated objective is to provide a book 
identifying "Software Engineering Best Practices" for 
software engineering courses and "seasoned computer 
professionals".

He has some success -- there are lots of ideas here, many
of them good ones.  His writing uses an easy-to-read style.
He has obvious experience at producing high-quality 
software.  Many of his suggestions and recommendations
match my own experiences, and, I believe, would help most
organizations.

The Chapters are:

  1. Software Engineering Best Practices -- 18 pages

  2. Teamwork -- 9 pages

  3. Project Teams and Quality -- 13 pages

  4. The Phased Approach -- 10 pages

  5. Design Specifications -- 10 pages

  6. Design Reviews -- 10 pages

  7. Code Reviews -- 30 pages

  8. Object-Oriented Programming (Software Standards)
      -- 10 pages

  9. Assertions (Making Your Source Code Robust)
      -- 10 pages

 10. Best Practices for Software Testing -- 14 pages

 11. Problem Reporting and Tracking -- 6 pages

 There are also seven appendices with checklists for
 various parts of the software process -- 46 pages

The detailed discussion and checklists for design reviews
and particularly code reviews are specific enough to put 
into immediate practice.

Unfortunately, there are a number of problems:

1. His writing is sometimes unclear, due mostly to the 
   brevity of the text, I think. 

2. Although not explicitly stated in the preface or text, 
   this book is apparently targeted at medium to large
   developers of packaged software goods.   There is no
   allowances for small development organizations (under
   10 people) or for developers of internal-use
   applications.  He assumes that your company develops 
   mass market applications for sale to other 
   organizations.  He also assumes a particular structure 
   of the development company, which may not match your 
   organization.

3. He provides lots of advice and suggestions, but not much
   information about how to accomplish the suggestions. 

4. His opinions, while they often seem to be valid, are not
   supported by facts, numbers, relevant experience, or 
   even anecdotal stories, so you won't be able to use this
   book for justification or persuasion to your management.

5. Mr. Wilson doesn't distinguish between what has worked 
   for Mr. Wilson versus what might work for you.  For 
   example, in the chapter on Problem Reporting and 
   Tracking, he suggests that voice mail should be 
   preferred to e-mail for accepting customer problem 
   reports.  I have two problems with this idea: First of 
   all, not all developers have voice mail.  Secondly, my 
   experience is that e-mail is much more likely to provide
   the kind of precise details needed to debug a problem.

6. Although this book is not as detailed as Steve 
   McConnell's books, it still tries to cover as much 
   ground.  As a result, most topics are treated very 
   superficially.

I'm not sure who would benefit from this book, which is 
heavily weighted towards commercial, repeated release 
packaged software.  Translation of many of the ideas may 
be required for in-house development and for contract 
programming.  It also covers subjects other than design 
and code reviews too briefly to be much help for the 
neophyte.

For the experienced software quality engineer, this book 
should prove useful as a checklist of quality ideas that 
can be adjusted for local conditions and as a reminder of 
a lot of ways to improve software quality.

My advice:  "SOFTWARE Rx Secrets of Engineering Quality 
Software" would not be good as your starting book on 
software quality -- there just isn't enough explanation.  
If, however, you are building a library of ten or more 
books on software quality, this book has some valuable
ideas.  The checklists should prove useful starting points
for your own quality organization, and are easily worth 
the price.


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