Software Quality Professional From the Editor - June 2000 - ASQ

Software Quality Professional From the Editor - June 2000


Software quality isn’t what it used to be.

No, I don’t mean that the measures of quality factors have worsened over time. Those who track product characteristics can assure us that industry-average counts of defects per function point continue to decline. And those who focus on process improvement can point to a lengthening list of organizations attaining ever more “mature” ratings.

Instead I am thinking about the range of concerns that quality professionals must now address. These concerns are both objective (in software) and subjective (among humans). We might find these changes stimulating as well as disconcerting, but they are clearly unavoidable.

It certainly seemed much simpler when computers were kept in glass houses and provided rigid procedural instructions. Quality assurance consisted of questioning whether things were done right...and only occasionally whether the right things were done.

Functionality was, if not the only, at least the greatest factor to be evaluated. Of course, once humans got into the interactive loop we also had to be concerned about usability in all its manifestations. And as computers emerged from splendid isolation, and especially as they began to be connected with one another, security in its many different dimensions arose as another major issue.

But quality has always been quality, right?

The classic definition of quality about which I have often expressed a preference is also the simplest: fitness for use. My own jest has been that there were only two words that created difficulty in the definition: “fitness” and “use.” So the two significant questions were “How will the system be used?” and “How are we to determine its fitness for that use?”

More elaborate formulations have framed quality as “the degree to which the requirements of the user are satisfied.” And that led to the further elaboration that the requirements might be both explicit (specifications) and implicit (expectations). Note, too, that speaking of a “degree” of satisfaction meant we might consider tradeoffs and shades of gray between wholly acceptable and wholly unacceptable.

Then there was the additional complication that it might not be only the end user who would need to be satisfied. The sponsor who funded the project might be distinct from the user who would actually operate the system. Acceptance criteria had to be documented so their satisfaction resulted not only in a happy users but also a willing payer.

As software ranged farther into uses with possible impact on public health and safety, its quality became the concern of regulatory agencies. I myself have worked in regulated environments where constraints were imposed by the Nuclear Regulatory Commission or the Food and Drug Administration. There a sanity check was to be sure the system “violated neither the laws of physics nor of Congress.” The circle of concern grew even wider.

Now I have a new set of stakeholders to whom I must communicate the quality message: the investors who must choose to finance our efforts.

The interests of potential investors and potential customers could be quite different. Correspondingly, development and quality activities are often addressed to these different audiences in different ways. Investors are keen to understand commercial opportunity, potential competitors, and the likelihood that a firm has the technical, marketing, and organizational capabilities to do what it says.

I might draw analogies between the needs of potential investors today and those of military procurement offices two decades ago, as far as wishing to assess the likelihood of “backing a winner.” At the risk of being taken too seriously, I might even suggest a contemporary corollary could be a Vaporware Maturity Model, to gauge the probability of turning marketing demos and prototypes into commercially viable products.

I am becoming increasingly convinced that software development and software quality are in the midst of fundamental changes, not just in the pace of so-called “Internet time” but also in the very nature of the disciplines. Quality practitioners cannot afford to neglect broader business issues, nor can management ignore the leverage afforded by quality initiatives.

No, software quality isn’t what it used to be. Nor will software quality professionals be able to function effectively according to the old rules and career paths.

Twenty years ago my development organization recruited from the ranks of engineering students, graduates in the physical sciences, and mathematicians. Quality functions such as testing (or, more comprehensively, verification and validation) were performed by workers drawn from the same pool, often rotating between development and assurance tasks.

The joke was that the quality professionals of the day would insist on software calibration (“Are all the diskettes of the proper dimension?”) or otherwise be unable to transition from the manufacturing environment. Quality principles had seldom been properly translated from the assembly line to the programmer’s cubicle.

Today there is little doubt that concepts originated in other application areas have contributed greatly to the pursuit of quality in the development and use of software-based systems. Costs of quality, quality function deployment, process definition and improvement–all have enriched our efforts.

I, for one, am not prepared to go back to any imagined “good old days.” Software and software quality concerns have emerged into broader, more human realms. It’s a great time to be a software quality professional.


I can be contacted at

Featured advertisers

ASQ is a global community of people passionate about quality, who use the tools, their ideas and expertise to make our world work better. ASQ: The Global Voice of Quality.