I had previous ranted about a website that rubbed me the wrong way when it discussed software quality (Towards and Improved Definition of Software Quality). I apologize for being hot-headed about the topic and I will try to take a more measured approach to the subject and begin to lay the foundation for a deeper study of the topic.

Historical Perspective
I found a paper by Boehm from 1976 that addressed the topic. [1] It is very typical of the way people talked about software quality historically.

Kitchenham & Pfleeger offers that quality views are [2]:

• transcendental
• user
• manufacturing
• product
• value-based

To paraphrase her definitions, the transcendental view is "I know it when I see it" type of definition which is not helpful for detailed analysis. The user sees software as fitness for purpose. The manufacturing view of quality is its conformance to specification. The product view of quality ties it to the intrinsic qualities of the product. The value-based view should really be called the market view of quality; high quality products command a premium in the marketplace.

They observe that people who focus on metric tend toward the product view of software quality. Their orientation is to measure the intrinsic qualities so as to predict something about the quality-in-use that will be observed.

An important opinion expressed in this article is that "there is little evidence that conformance to process standards is a guarantee of quality software." The components of quality in the user view are the proper mix of functionality, the non-functional behavior of the software and external factors that affect the use of the software. They quote the ISO definition of quality as “the totality of characteristics of an entity
that bear on its ability to satisfy stated and implied needs." They go on to say that Tom Glib proposes a method for measuring the non-functional characteristics that will affect the composite perception of quality in the user. The ultimate goal is to have a metric for each characteristic.

In the Kitchenham & Pfleeger article, I note that they implicitly define quality as a stakeholder perception and not some absolute measure of anything fixed and unchangable. But this impression is corrected in the article call out where an article by David Garvin called "What Does Product Quality Really Mean?" (Sloan Management Review, 1984) where it is explicitly acknowledge that there are as many measures of quality as their are stakeholders. This article then goes on to introduce the various papers in this publication. What is safely understood from this paper is that the balancing of these qualities is a shared responsibility between technical project management, product management and senior management.

Herbsleb et al [4] published an article called "Software quality and the Capability Maturity Model." [4] Their article is a straightforward presentation of the CMMI from SEI and their justification for it as a basis for a metrics program. The take on and address the criticisms of CMMI. What is probably the most difficult challenge is the charge that a CMMI organization will become rigid and bureaucratic. After all, the organization will focus on the measures that are chosen and those that are not measured may change, often for the worse. To measure everything creates a very data driven organization. Without the proper tool support, an excessive amount of time and energy is spent on on the gathering, analysis, and challenges to the data to the exclusion of the ultimate product quality. Yet their data support their belief that this charge is not supported by the customers who adopt their process model.

(to be continued)

REFERENCES
[1] B. W. Boehm, J. R. Brown, and M. Lipow. 1976. Quantitative evaluation of software quality. InProceedings of the 2nd international conference on Software engineering (ICSE '76). IEEE Computer Society Press, Los Alamitos, CA, USA, 592-605.


[2] Kitchenham, B.; Pfleeger, S.L.; , "Software quality: the elusive target [special issues section]," Software, IEEE , vol.13, no.1, pp.12-21, Jan 1996
doi: 10.1109/52.476281
URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=476281&isnumber=10198

[3] T. Gilb, Phczpals of Software Engineering Management, Addison-Wesley, Reading, Mass., 1987

[4] James Herbsleb, David Zubrow, Dennis Goldenson, Will Hayes, and Mark Paulk. 1997. Software quality and the Capability Maturity Model. Commun. ACM 40, 6 (June 1997), 30-40. DOI=10.1145/255656.255692 http://doi.acm.org.proxy.lib.csus.edu/10.1145/255656.255692