============================================================
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.
Tenberry Home