Author: Gautam Brahma
 'Software
quality' is often the butt of jokes. Many people think of
the phrase as an oxymoron, much like 'military intelligence'
and 'obedient teenager'. Flawed software is widely believed
to be the reason for several spectacular mission failures.
The most recent of these being NASA's Mars Observer which
became silent last month, just three days before it was scheduled
to enter its orbit around that planet. This widely held belief
is both sad and amusing, depending on the example being quoted,
but it is certainly not true.
Reliable software is at the heart of a number of conveniences
that we take for granted everyday. Two examples are the carburetor-less
multi-point fuel injection engine and the ubiquitous cellphone.
Software quality is real. The challenge lies in measuring
this intangible feature, so that it can be controlled and
improved. And the smart thing to do when measuring intangibles
is to take more than one approach and see if they converge.
One approach to measuring software quality is to count the
number of defects at each stage of testing and divide by some
measure of size, like thousand lines of code, to arrive at
the defect density. This tells us how well the software is
meeting the precise specifications against which it was designed.
Several measures analogous to defect density, can be conceived
and used. Unfortunately this cannot be the only approach,
as it depends a lot on the thoroughness of our testing and
the completeness of the specifications themselves.
A simpler approach is to poll customer satisfaction and find
out whether the software meets the general requirements of
the user it was designed for. A customer can often label a
bug-free code with poor quality, if it is difficult to install
and use and does not do what the customer thinks it rightly
should. Maybe the requirements were not gathered accurately
by the designers but, tough luck, it is still poor software
quality as perceived by the one who calls the shots!
Both these approaches assess quality after the event, and
can at best lead to improvements when the next piece of software
is designed. The third approach focuses on measuring quality
as it is created, by measuring compliance with a good process
for doing every task in the chain that ultimately results
in the finished software. High compliance creates a confidence
in the finished artifact. Also, this way, any deviations can
be trapped and corrected early, more effectively, often at
lower cost.
The best way is to use all three approaches to measure software
quality. There can be no disagreements about the quality of
software that is built in compliance with a good process,
yields few defects on testing and gets the thumbs up from
customers. Once we get all three measures in line we know
exactly what we need to do each time we have to create quality
software. This has been the guiding principle behind HSS's
approach to quality. It is straightforward and pragmatic,
and has worked well for us.
- BACK -
Last updated : February 2, 2004
|
