Measuring Software Quality


Historically software quality metrics have been the measurement of exactly their oppositethat is, the frequency of software defects or bugs. The inference was, of course, that quality in software was the absence of bugs. So, for example, measures of error density per thousand lines of code discovered per year or per release were used. Lower values of these measures implied higher build or release quality. For example, a density of two bugs per 1,000 lines of code (LOC) discovered per year was considered pretty good, but this is a very long way from today's Six Sigma goals. We will start this chapter by reviewing some of the leading historical quality models and metrics to establish the state of the art in software metrics today and to develop a baseline on which we can build a true set of upstream quality metrics for robust software architecture. Perhaps at this point we should attempt to settle on a definition of software architecture as well. Most of the leading writers on this topic do not define their subject term, assuming that the reader will construct an intuitive working definition on the metaphor of computer architecture or even its earlier archetype, building architecture. And, of course, almost everyone does! There is no universally accepted definition of software architecture, but one that seems very promising has been proposed by Shaw and Garlan:

Abstractly, software architecture involves the description of elements from which systems are built, interactions among those elements, patterns that guide their composition, and constraints on those patterns. In general, a particular system is defined in terms of a collection of components, and interactions among those components.[1]

This definition follows a straightforward inductive path from that of building architecture, through system architecture, through computer architecture, to software architecture. As you will see, the key word in this definitionfor software, at leastis patterns. Having chosen a definition for software architecture, we are free to talk about measuring the quality of that architecture and ultimately its implementations in the form of running computer programs. But first, we will review some classical software quality metrics to see what we must surrender to establish a new metric order for software.




Design for Trustworthy Software. Tools, Techniques, and Methodology of Developing Robust Software
Design for Trustworthy Software: Tools, Techniques, and Methodology of Developing Robust Software
ISBN: 0131872508
EAN: 2147483647
Year: 2006
Pages: 394

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net