|
|
The readers of the Computer Journal must include many that,
like your reviewer, have devoted most of their working life to the writing of high quality software.
And yet, presented with any book titled software quality, our hearts sink.
This book does not disappoint our expectations.
It comprises a managers guide to implementing a quality system,
a software engineers guide to best practice
(in quality,
not best practice in software development),
and six appendices, including overviews of the ISO 9000 standards and the Capability Maturity Model,
ISO/IEC 9126 definitions of abstract nouns that mostly end in ility,
and a summary of no less than 141 essential practices.
The managers are given the usual motivational stuff.
What we used to call the cost of quality
is now called the cost of low quality,
although it is the cost of doing things later classified as essential.
We are reminded that ISO 9000 certified companies demand similar certification of their suppliers,
so you had better get certified and make the same demands on your suppliers.
Empowering employees is there but only in the non-threatening sense of delegation of
authority and decision making ... to the appropriate level.
Quality must be accepted by everyone;
but not to worry: this can be achieved by a lively and appealing education programme.
Then you can implement your quality system,
get your ISO 9000 certificate, and be in on the racket.
Quality means points; and you know what points mean:
the Baldridge Award, the Deming Award, the European Quality Award.
For the software engineers, or rather,
their project managers, there are some really sensible remarks:
software needs to be designed for change;
support is needed as well as development; the causes of problems need to be identified and eliminated.
And then we have three chapters that are, in substance, a process checklist,
each item being boldly labelled ESSENTIAL,
IMPORTANT,
or USEFUL;
the rationale for the classification is opaque.
The checklist is written, largely, as continuous prose.
Here is a specimen: "It is IMPORTANT to identify in the acceptance test plans the
acceptance tests necessary for the provisional acceptance of the software." Get the flavour?
It is clear,
say the authors (not descending to argument),
that the quality of software is largely determined by the quality of the process used to develop ... it.
It is indeed clear, because it is trivial,
if by process
one means policies, procedures, tools and resources,
both human and technological.
But if one means process the sort of procedures that have to be recorded and measured for,
say, ISO 9000 certification then it is not clear at all.
Much quality depends not on process but on the professional exercise of skill and care:
do you choose your hairdresser, car mechanic, or dentist for their process quality?
And is it, do you suspect, just possible that even in these latter days
the most important thing to do if you want high quality software is to employ
some really clever professional software writers?
|
|
|
But the authors have anticipated your reviewer:
It is common for software developers to resist written standards and procedures ...
They are too bureaucratic, or unduly constrain creativity or are too much of an overhead.
These arguments must not be rejected out of hand if they are made by capable staff ...
Then they reject them out of hand.
That is software quality for you:
those that understand high quality software, and have long been committed to it,
are to be educated in a lively and appealing way, given a fair hearing, and humoured.
(Readers disagreeing with, or even offended by,
this review should address their comments to The ISO 9000 Process Quality Manager,
The Computer Journal. Only joking.)
|