BKASWQTT.RVW   20040622

"Achieving Software Quality Through Teamwork", Isabel Evans, 2004,
1-58053-662-X, U$79.00/C$114.95
%A   Isabel Evans
%C   685 Canton St., Norwood, MA   02062
%D   2004
%G   1-58053-662-X
%I   Artech House/Horizon
%O   U$79.00 617-769-9750 fax: 617-769-6334 artech@artech-house.com
%O  http://www.amazon.com/exec/obidos/ASIN/158053662X/robsladesinterne
  http://www.amazon.co.uk/exec/obidos/ASIN/158053662X/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/158053662X/robsladesin03-20
%P   294 p.
%T   "Achieving Software Quality Through Teamwork"

The preface notes that software is produced by people, and usually
teams of people.  The author proposes that understanding people, and
teams, should help make better software.

Chapter one attempts to point out that quality depends upon
perception, but doesn't do a really clear job of it.  Four definitions
of quality are presented: product (specifications), manufacturing
(development process), user (fitness for use: the most subjective),
and value (related to return on investment).  The European Foundation
for Quality Management (EFQM) model is introduced as the basis for the
book (which appears to concentrate on the user and value definitions). 
Different groups of people, and the different ways of viewing quality,
are outlined in chapter two, but the interactions and implications are
not apparent.  One set of divisions; between customers, managers,
builders, measurers, and supporters; is used to structure the next
five chapters.

Chapter three looks at various types, factors, and needs of customers,
but gives little that would be of help in the development process. 
Managers fare slightly better in chapter four: one specific
communications tool or exercise is listed.  Builders are defined, in
chapter five, by a litany of complaints that programmers have about
others.  Oddly, responsibility for communications is laid at the feet
of the coders, but no means of improvement is provided for them.  The
role of measurers, in chapter six, is again described primarily in
terms of problems, with few solutions discussed.  Chapter seven uses
lots of words in dealing with supporters, but says little of
substance.

Chapter eight describes the life cycle of systems, collapsing
requirements, design, and implementation into a small development
block, and emphasizing delivery and post-delivery.  Start-up has some
brief ideas on concepts and initiation, and then gets into contracts. 
The software development life cycle (which, since it is only referred
to as SDLC, is hard to keep separate from the "system" cycle) provides
a terse outline of some project management methods.  A few aspects of
delivery and acceptance are reviewed in chapter eleven.  The post-
delivery material, in chapter twelve, is confused and confusing, but
eventually talks about maintenance.

Overall, the book has numerous points worth considering in the
development process.  Some may help when dealing with requirements and
design, which may assist with the user and value definitions of
quality.  Very little of the content is applicable to the product or
manufacturing aspects noted at the beginning.  In addition, the
particulars are buried in a great deal of superfluous verbiage, and
little is of direct and practical use.  For example, communications is
frequently noted as a problem, and appendix A lists a variety of
communications techniques, but there is very little discussion as to
how to use these methods.

It is very difficult to identify an audience that would benefit from
this work.

copyright Robert M. Slade, 2004   BKASWQTT.RVW   20040622