Over the last decade, the general focus of the software industry has shifted from providing ever more functionalities to improving what has been coined the user experience. The user experience refers to characteristics such as ease of use, security, stability, etc. lmprovements in such areas lead to an improved qua!ity as perœived by the end users. Sorne software products, most notably Microsoft’s next iteration of their Windows operating system, have been delayed by as much as two years in arder to improve their quality. There is no doubt that software quality is beooming an increasingly important subject in software engineering.

Traditionally, software requirements have been classified either as functional or nonfunctional with eventual notions of quality hidden in the latter. As the industry focus is shifting from functionality to improving quality, a new category of requirements are emerging.

ln arder to define these new quality requirements, quality itself must be defined. The role of the definition of quality is filied by what is ca lied a quality madel. Unfortunateiy, the push towards software quality that can be observed in the industry today is lacking a soiid foundation in the form of an agreed upon quality model that can be used not only to evalua te software quality, but also to specify it.

The primary objective of this research is to identify a quality model that can serve as a basis for the improvement of software quality in a ccmtinuous, systematic, disciplined and quantifiable wa.y (Suryn, 2003). in orcier to attain this objective, the following process will be followed:

• A review of the literature will allow for the observation of the state of the art in the industry and the research community with respect to software quality. This part of the thesis will identify possible causes for lacking software quality in the industry and further stress the need for a solid foundation to the engineering of quality.
• Using the premises estabiished in the review of the literature, four quality models recognized today will be described and evaluated with respect to their suitability for the improvement of software quality. One mode! will be selected for further analysis.
• An in-depth analysis and evaluation of the mode! that seems the most suited for the improvement of quality will be conducted.
• The result of the analysis will be presented in form of a discussion and recommandations.

The software engineering industry has long been diagnosed with a « quality problem » (Glass, 1997; NIST, 2002; SEl, 2002). This quaiity problem can take different incarnations: from monumental disasters related to software (Glass, 1997) to disastrous economie !osses. For example, a NIST report clearly blames lacking software quality for !osses of up to 60 billion US dollars in 2002 in the United States alone (NIST, 2002). Discussion on how to resolve the quality problem in software engineering leads to heated and interesting debates because what exactly constitutes the quality of a product is often the subject of hot debate. The reason the word quality is so controversial is that people fail to agree on what it means. For sorne it is « [the] degree to which a set of inherent characteristics fulfills requirements » (ISO/IEC 1999b) while for ethers it can be synonymous with « customer value » (Highsmith, 2002), or even « defect levels » (Highsmith, 2002). A possible explanation asto why any of these definitions fail to garner a consensus is that they generally fail to recognize the different perspectives of quality. Kitchenham and Pfleeger (1996), by reporting the teachings of David Garvin, report on the 5 different perspectives of quality:
◆ The transcendental perspective deals with the metaphysical aspect of quality. in this view of quality, it is « something toward which we strive as an ideal, but may ne ver implement completely. » (Kitchenham & Pfleeger, 1996);
◆ The user perspective is concemed with the appropriateness of the product for a given context of use. Kitchenham and Pfleeger further note that « whereas the transcendental view is ethereal, the user view is more concrete, grounded in the product characteristics that meet user’s needs. »;
◆ The manufacturing perspective represents quality as conformance to requirements. This aspect of quality is stressed by standards such as ISO 9001, which defines quality as « [the] degree to which a set of inherent characteristics fuifills requirements » (ISO/IEC 1999b). Other models, like the Capability Maturity Mode! (CMM) state that the quality of a product is directly  related to the quality of the engineering process, thus emphasizing the need for a manufacturing-like proœss;
◆ The product perspective implies that quality can be appredated by measuring the inherent characteristics of the product. Such an approach oft:en leads to a bottom-up approach to software quality: by measuring sorne attributes of the different components composing a software product, a conclusion can be drawn as to the quality of the end product;
◆ The final perspective of quality is vaiue-based. This perspective recognizes that the different perspectives of quality may have a different importance, or value, to various stakeholders.

One couid argue that in a world where conformance to ISO and IEEE standards is increasingly present in contractual agreements and used as a marketing tool (Adey & Hill, 2000), ali the perspectives of quality are subordinate to the manufacturing view. This importance of the manufacturing perspective has increased throughout the years through works like Quality is Free (Crosby, 1979) and the popularity of movements like Six-Sigma (Biehl, 2001 ). The predominance of the manufacturing view in Software Engineering can be traced back to the 1960s, when the US Department of Defense and IBM gave birth to Software Quality Assurance (Voas, 2003). This has led to the belief that adherence to a development process, as in manufacturing, will lead to a quality product. The corollary to this belief is that process improvement will lead to improved product quality. According to many renowned researchers, this belief is false, or at !east flawed. Geoff Dromey states:  »The flaw in this approach [that you need a quality process to produce a quality product] is that the emphasis on process usually cornes at the expense of constructing, refining, and using adequate product quality mode/s. » (Drome y, 1996) .

Kitchenham and Pfleeger reinforce this opinion by stating:  « There is little evidence that conformance to process standards guarantees good products. ln fact, the critics of this view suggest that process  standards guarantee on/y uniformity of output [. .. ] » (Kitchenham & Pfleeger, 1996)  .

Furthermore, data available from so-called Agile (Highsmith, 2002) projects show that high quality is attainable without following a manufacturing-like approach. However, recent studies conducted at Motorola (Eickelman, 2003; Diaz & Sligo, 1997) and Raytheon (Haley, 1996) show that there is indeed a correlation between the maturity level of an organization as measured by the Capability Maturity Model and the quality of the resulting product. These studies provide data on how a higher maturity level (as measured by the CMM) can lead to:
• lmproved error/defect density (i.e. the error/defect density lowers as maturity improves)
• Lower error rate
• Lower cycle time (time to complete parts of the lifecycle)
• Setter estimation capability .

From these results, one could conclude that the « quality problem » is non-existent, that it can easily be solved by following a mature process. However, these measured improvements are directly related to the manufacturing perspective of quality. Therefore, such quality improvement efforts fail to address the other perspectives of quality. This might be one of the reasons that sorne observers of the software development scene perceive the « quality problem » as one of the main failings of the software engineering industry. Furthermore, studies show that improvement efforts grounded in the manufacturing perspective of quality are difficult to scale down to smaller projects and/or smalier teams (Laitinen, 2000; Boddie, 2000). lndeed, rather than being scaled down in smaller projects, these practices are simply not performed.

Over the recent years, researchers have proposed new models that try to encompass more perspectives of quality them just the manufacturing view. One such model was proposed by Geoff Dromey (1995; 1996). Dromey’s view of the quality of the end product is that it is directly related to the quality of the artifacts that are a by-product of the process being followed. Therefore, he developed different modeis that can be used to evaluate the quality of the requirements model, the design mode! and the resulting software. The reasoning is that if quality artifacts are conceived and produced throughout the lifecycle, then the end product will manifest attributes of quality. This approach can clearly be linked to the product perspective of quality with elements from the manufacturing view. This is certainly a step forward from the manufacturing-only approach described above, but it fails to view the engineering of quality as a process that co vers ali the perspectives of quality. Pfleeger (2001) wams against approaches that focus only on the product perspective of quality: « This view [the product view] is the one often advocated by software metrics experts; they assume that good Internai Quality indicators will lead to good extemal ones, such as reliability and maintainability. However, more research is needed to verity these assumptions and to determine which aspects of quality affect the actual product’s use. »