Software Quality, Change Management and Testing: A Research Report

This research report reviews the paper titled “In search for a widely applicable and accepted software quality model for software quality engineering” by Côté, Witold, & Elli, 2007. It covers definitions of software quality, its specifications and quality models as proposed by other researchers.

Running head: Quality Measurement 1
Software Quality, Change Management and Testing: A Research Report
Name of the Student
Name of the Institution

Quality Measurement 2
Introduction
Software quality engineering has grown to become a major discipline and a critical
consideration for software developers. The discipline is concerned with software quality
management and is rooted in quality models designed to not only deliver products that meets
customer requests but also satisfy standard software quality demands (Côté, Witold, & Elli,
2007). The needs of improved performance, security, user experience, scalability, reliability and
stability propel the development of software quality engineering.
In order to define quality engineering, three authors Marc-Alexis, Witold Suryn and Elli
Georgiadou, in 2007 authored a paper titled “In search for a widely applicable and accepted
software quality model for software quality engineering” in which they reviewed literature on
software quality development and measures. They recommended the development of software
quality management model for use in all development lifecycles.
The purpose of this research report is to review this paper, the research and the findings
that were made. The paper in structured into three sections- the introduction, body and
conclusion. The body section will review definitions of software quality management, its
specifications and quality models as proposed by other researchers. The conclusion summarizes
these findings and relates their importance to the course Software quality, change management
and testing.
Definition of Software Quality
In this paper, the three conducted a literature review of content related to the subjected,
and proposed features describing suitable quality model by way of comparatively evaluating
previously designed/developed quality models alongside their support for quality engineering.

Quality Measurement 3
They started by evaluating several definitions for software quality as proposed by other
researchers, reviewing te specifications and evaluation of quality as far as software quality
engineering is concerned, evaluated quality models and concluded by making recommendations
based on their research findings.
The Importance of Quality in Software Engineering
Traditional software development lifecycle and system analysis segmented user
requirements as either being functional or non-functional (Owlia & Elaine, 1996). The need for
improved user experience, robustness, performance, scalability, reliability and security gradually
shifted software development activities from being functionality-centered to quality-
requirements centered. To meet these requirements, a quality model must be used as a reference
framework towards the definition of quality. Additionally, quality assurance and quality checks
must be integrated with all other software development activities. Such efforts should be
formally managed and their implementation initiated during the definition and analysis of user
requirements and continued throughout the software development lifecycle. As such, software
quality development or quality engineering is seen as the “application of a continuos, systematic
disciplined, quantifiable approach to the development and maintenance of quality of software
products and systems; that is, the application of quality engineering to software (Suryn, 2003)”.
Most unfortunately for many software developers and users alike, the debate about what
constitute software quality is so controversial and its definition remains large vague in the eyes
many. The authors of this article suggested that these differences emanate from the fact that the
fact that many of the definitions do not recognize the different aspects of quality. They then
settled on the views of David Garvin about the five aspects of quality management. These
perspectives are outlined as follows:

Quality Measurement 4
a) The manufacturing perspective- this is a representation of conformance to predefined
requirements. The ISO 9001 standard stresses manufacturing quality perspective by
defining “quality as the degree to which a product satisfies requirements (ISO/IEC,
1999b).”
b) The user perspective- focusses on the appropriateness of a product. This is a more
concrete definition that is grounded on features that meet user requirements.
c) The transcendental perspective- an ethereal view of quality as something physical and
ideal ‘quantity’ that cannot be implemented in entirety (Kitchenham and Pfleeger, 1996).
d) The product perspective- a software products quality is measured in accordance to its
features. The measurement is bottom-up approach that reviews all of the system’s
components features.
e) Value-based perspective- a quality measure that recognizes that the different quality
perspectives have different value and importance among different stakeholders.
While some researches, aligned to the ISO and IEEE standards suggested that the
manufacturing perspective is the main approach to attaining quality, some argue that
conformance to such have little help and have suggested for the development of models that have
broder quality perspectives. The Capability Maturity Model in particular, show a correlation
between maturity levels of software products and resulting products quality. Data from CCM
indicated that higher maturity levels lead to enhanced error/fault density, lesser fault rates,
subordinate sequence times and improved approximation capabilities (Diaz & Sligo, 1997).
The trio observed that there are major disagreements between research and the
community as far as software quality is concerned. They defined the goal of quality model as the
provision of operational quality definition.

Quality Measurement 5
Specification and Evaluation of Quality
According to IEEE standards 1061- 1998, quality can be evaluated using top-to-down
and bottom-to-up approaches. The top to bottom perspective framework is useful in the
establishment and communication of quality wants factors, and in the identification of quality
measurement metrics that are related to the pre-established or defined quality factors and sub-
factors. The bottom-up approach on the other hand, is a quality framework that enhances the
administrative and technical to get response by assessing and analyzing software products
processes and metrics value in the estimation and assessment of quality factors. Following these
standards and approaches, the trio recommends for a quality testing framework applicable as the
basis for the elicitation and analysis of quality requirements. Further, the model must be effective
in the definition of specifications, quality requirements plus software quality evaluation. This
implies that the model ought to be usable in both top-down as well as bottom-up quality
evaluation approaches.
Evaluation of Quality Models
In this section, the researchers defined measurement for a quality framework for use in
the measurement of software quality engineering and suggested that any model should: backing
the diverse quality viewpoints as describe in the previous section, must be usable in both top-
down and bottom-up lifecycle as defined by the IEEE standards. In this regard, four quality
models were evaluated: McCalls’, Boehm’s, Dromey’s and the ISO/IEC 9126 quality models.
Defined in 1991, the ISO/IEC quality framework contained a set of characteristics and
guidelines to ensure quality development. The model gained popularity in Europe and was

Quality Measurement 6
viewed as the finest way of defining, measuring besides interpreting quality. Nevertheless,
Pfleeger (2001) reported about weakness inherent to the model. He reported that the model did
not provide sufficient guidelines on how to sufficiently access quality, lacked indications on how
to perform quality, measurements and only focused on developers’ view of a product rather than
that of the user (IEEE, 1998).
The Dromey model measures quality in terms of ‘tangible’ properties. Each artefact
delivered in every lifecycle is associated with an evaluation model (Dromey, 1995). The model
as proposed is focused on product quality perspective. The tangibles were described as
correctness, internal contextual and descriptive features of a system. However, the fact that this
model is product-focused implies that it does not meet the previously defined quality model’s
features and, therefore, need improvement.
A close examination of the McCall model revealed that quality metrics under this model
can only be measured subjectively (Pressman, 2005). This makes it difficult to define precise and
specific requirements. Additionally, some of its proposed quality factors such as self-
documentation and traceability cannot be adequately defined and meaningless for non-technical
stakeholders.
The Boehm’s approach was an advanced version of McCall’s work. The model defined
general utility system features as ease of use, portability and maintainability. These utilities as
defined, were too broad and indefinite to be valuable in software quality measurement (Boehm,
John, & Mlity, 1976). The support offered by the model for the top-down software quality
measurement approach, the sustenance is way too much “short-lived to be trusted as a concrete
reference for software quality development.

Quality Measurement 7
Conclusion
The extensive literature review on software quality measurement revealed some
confusing and conflicting definitions of software quality. Additionally, it is established that such
definitions must encompass both the manufacturing, product, user, transcendental and value-
based quality perspective. Further, looking at the quality models that have been defined or
otherwise developed in the past, it is clear that each model focusses on one aspect of quality, just
like the many definitions used to describe quality, and forget the other. As such, when evaluated
against quality model specifications, all the models ecxept the ISO/IEC 9126 model and product
perspective. The later support all the perspectives and is highly predicative framework that offers
support for both top-down and bottom-up approaches. Quality measurement and engineering are
to be initiated at the beginning of software development lifecycle.
These findings will help me to understand what quality engineering is, its importance and
aspects. It is also an eye opener to the application of quality models as reference frameworks that
define and guide software quality engineering processes.

Quality Measurement 8
References
Boehm, B. W., John, R. B., & Mlity, L. (1976). Quantitative evaluation of software quality.
Proceedings of the 2nd international conference on Software engineering (pp. 592-605).
IEEE Computer Society Press.
Côté, M.-A., Witold, S., & Elli, G. (2007). In search for a widely applicable and accepted
software quality model for software quality engineering. Software Quality Journal, 15(4),
401-416.
Diaz, M., & Sligo, J. (1997). How software process improvement helped Motorola. IEEE
Software, 17(5), 75–81.
Dromey, R. G. (1995). A model for software product quality. IEEE Transactions on software
engineering, 21(2), 146-162.
IEEE (1998). Std. 1061–1998 IEEE standard for a software quality metrics methodology.
ISO/IEC (1999b). ISO/IEC 9000:2000 Quality management systems – Fundamentals and
vocabulary.
Geneva, Switzerland: International Organization for Standardization.
Kitchenham, B., Pfleeger, S. L. (1996). Software quality: The elusive target. IEEE Software,
13(1), 12–21
Owlia, M. S., & Elaine, M. A. (1996). A framework for the dimensions of quality in higher
education. Quality Assurance in Education, 4(2), 12-20.

Quality Measurement 9
Pfleeger, S. L. (2001). Software Engineering: Theory and practice (2nd edn.). Upper Saddle
River, N.J.: Prentice Hall
Pressman, R. S. (2005). Software engineering: a practitioner's approach. Palgrave Macmillan.
Suryn, W. (2003). Course notes SYS861. In École de Technologie Supérieure, Montréal.