Software Project Quality


A debate about software project quality would have to begin with attempting to define what software project quality is . There are many such definitions, each reflecting a particular quality philosophy and approach. For example, "quality is conformance to requirements," and "quality is achieved when the software is 'good enough.'" Perhaps Bach [1997] said it best when he noted that "quality is ultimately situational and objective." However, while all these definitions give us context for a quality debate, none of them give us a more objective approach we can readily apply to our context. So, we'll simply defer to a definition used in one significant segment of the software development community, one that also meets the requirements of this book. The Rational Unified Process [Rational Software Corporation 2002] defines software quality as:

the characteristic of having demonstrated the achievement of producing a product that meets or exceeds agreed-on requirements ”as measured by agreed-on measures and criteria ”and that is produced by an agreed-on process.

According to this definition, quality is not simply "meeting requirements" or even producing a product or system that meets user needs and expectations. Rather, quality also includes identifying the measures and criteria to demonstrate the achievement of quality, and the implementation of a process and execution of a project to ensure the product created by the process has achieved the desired result. These additional aspects of quality include process and project measures such as time to market; overall budget adherence; and scope of team, project, and company investment. Quality is a multidimensional concept, and these two primary dimensions ”the end result of the application itself and the business impact on the producer and consumer ”must each get primary consideration.

Fortunately, the intent of this book addresses both. The techniques and methods we've been describing for effective requirements management are designed for the primary quality purpose: to help the team assure that the product or system developed meets or exceeds agreed-on requirements. And in so doing, we also provide a prescription for an agreed-on process that the team can use to help assure those results are achieved.


Managing Software Requirements[c] A Use Case Approach
Managing Software Requirements[c] A Use Case Approach
ISBN: 032112247X
Year: 2003
Pages: 257 © 2008-2017.
If you may any questions please contact us: