ArticlePDF Available

The Definition of ‘Software Quality-: A Practical Approach

Authors:
  • Berliner Hochschule für Technik Berlin

Abstract

Probably everyone has an idea about the meaning of quality. However, when it comes to quality in the real world, i.e. in conjunction with a software development project, disagreements between the persons involved often lead to further problems. Especially in the case of customer complaints about faults in a software product, it seems to be unclear not only what the requirements are, but also if the software has the „right“ characteristics with regard to these require­ments. This article aims to reduce the confusion arisen about quality, requirement and characteristic.
requirement
Q
software_product
Q
characteristic
ist related to
(contributes to
the fulfillmenti)
has
should
fulfill
Fig. 1. Relationship between requirements and
characteristics in conjunction with quality [10]
The Definition of ‚Software Quality’: A Practical Approach
Dr. Roland Petrasch
petrasch@computer.org
Motivation
Probably everyone has an idea about the meaning
of quality. However, when it comes to quality in the
real world, i.e. in conjunction with a software
development project, disagreements between the
persons involved often lead to further problems.
Especially in the case of customer complaints about
faults in a software product, it seems to be unclear
not only what the requirements are, but also if the
software has the „right“ characteristics with regard
to these requirements. This article aims to reduce
the confusion arisen about quality, requirement and
characteristic.
Introduction
Only when the requirements are defined in
conjunction with the characteristics that are relevant
for quality, it is possible to measure software
quality. We have learned from experience that it is
neither possible to give a standard recipe to
overcome “software’s chronic crisis” [2], nor the
deadlock can be broken easily that evolves in many
projects because of short-term and hectic activities
of error correction to solve acute quality problems
to the debit of long-term and well-panned methods
to “produce” quality. Nevertheless, one main
concept for quality can be presented here.
To explain quality the definition of the
International Standardization Organization (ISO)
is a basis but over and above that, software
engineering techniques are used later to provide an
object oriented model for the context in which
quality, requirements and characteristics occur. It
can be shown that even in scientific literature and
standards the understanding of quality is neither
uniformed nor consistent, so that the given
definition can help especially when standards are
interpreted and applied.
Definition of quality
Standards shall and can help to define terms like
quality [9]. Nevertheless, the means of expression
used in standards are often not appropriate for the
practice. This is also true for the definition of the
ISO 8204 for quality: „Totality of characteristics of
an entity that bears on its ability to satisfy stated
and implied needs.“ [3]. That means: We require a
quality software product to have certain
characteristics that are related to requirements (of
the user) and satisfies them.
It is clear that the pair requirement and
characteristic plays a central role in the definition
of quality. Therefore, an object oriented model1 con-
tributes to a better understanding for these notions.
Figure 1 shows a software product, which is to fulfill
requirements in having appropriate characteristics [10].
The existence of relationships between requirements and
characteristics makes statements about the quality of a
product possible.
Problem of the term Quality
Despite the standardized ISO definition of quality, it can
be shown that scientific literature lacks consistency and
unity regarding the usage of the terms requirement and
characteristic. Examples of this heterogeneity are terms
like feature, attribute and characteristic [11] [12].
Unfortunately, standards like ISO 9001 [4], ISO 15504
[7] and the German V-Modell 97 [1] (similar to DoD
MIL-STD-498) give reason for further criticism.
Let’s take the ISO 9001 as an example: Because of
the reference to the ISO 8204, it can be assumed that the
terms requirement und characteristic are often used. This
is the case when it comes to requirements, but the stan-
dard does not give any information about characteristics,
e.g. chapter 4.10 (Inspection and testing), which is quite
astonishing in the face of the definition of quality.
The following example will show that it is possible to
describe the management of requirements and
characteristics in the software development process to
determine the quality of a software product.
Example: Quality Inspection
This example shows an important process that is a part of
quality management: The static analytical quality
measure “inspection of the user interface”. It takes up the
central concept that certain characteristics of the user
interface (e.g. list box, push button) are to be checked
against the requirements that can be ergonomic
requirements of the ISO 9241-10 [6]. According to the
quality definition, the precondition for any inspection is
the assignment: The characteristics have to be assigned
1 It is left open, if the model uses classes in means of the object-
oriented paradigm. Important is here that a technical term is brought
into a context. This terminus oriented notation is used in [6].
Figure 3. Window „Language“
Figure 4. Window „Columns“
conformity with
expectations
Q
dialog window
Q
position of
pushbuttons
is related
has
shall
fulfill
access
control
Fig. 2: Example for a requirement
and characteristics
to the requirements they are able to fulfill.
At first, a presentation of some requirements and
the assigned characteristics prepare for the in-
spection. Figure 2 demonstrates the existence of the
requirement “Conformity with user expectations”
[6]. The consistency of the dialog layout is
necessary. The characteristic “position of push
buttons for dialog navigation” can help to fulfill this
requirement and therefore it is assigned.
The inspection is to check the characteristic
“position of push buttons” of different windows
against the requirement “Conformity with user
expectations”, i.e. in all windows we expect push
buttons with the same or analogous functionality of
interaction at the same position. The “OK” button
(i.e. “save & exit”) is such an interaction element
and occurs in many dialog windows.
The windows belong to the product Microsoft®
Word for Windows 2000® 2 (see Fig. 3 and 4). Push
button positions are the values of the characteristic.
They indicate a difference: Window „Language“
places the „OK” button on the left side of the
„Cancel” button, while window „Columns“
contains the button on top of the other, i.e. the
inspection has found an error, because the assessed
characteristic is not able to fulfill the requirement
“Conformity with user expectations” which results
in the statement: The quality of the dialogs is
deficient with regard to the requirement.
This example has shown how to use requirement
and characteristic in conjunction with an inspection
and how a quality statement is based on the results.
Conclusion
Software quality is the existence of characteristics of a
product which can be assigned to requirements. In
addition to this, we have to look at the characteristics that
are not related to requirements: Characteristics, which
reduce the software quality (contra-productive) and
„neutral“ characteristics, which are not relevant for
quality. It is clear that not only the presence of
characteristics is important, but also the absence of these
contra-productive characteristics.
Hopefully in the literature and standards a more uni-
fied and consistent usage of the term quality can be found
in the future. Experiences with the quality concept pre-
sented here are positive, because the personnel involved
in a development project relies on a common
terminological fundament.
References
[1] Entwicklungsstandard für IT-Systeme des Bundes:
Vorgehensmodell, Teil 1: Regelungsteil. Juni 1997
[2] Gibbs, W.: Software’s chronic crisis. Scientific
American. 1994
[3] DIN EN ISO 8402: 1995: Qualitätsmanagement Begriffe.
1995
[4] DIN EN ISO 9001: 1994: Qualitätsmanagementsysteme.
1994
[5] Horn, E.; Schubert, W.: Objektorientierte Software-
Konstruktion. 1993
[6] ISO 9241-10:1996: Ergonomic Requirements for Office
Work with Visual Display Terminals - Part 10. ISO, 1996
[7] ISO/IEC TR 15504-2:1998(E) Information Technology
- Software Process Assessment: Part 2: A reference
model for processes and process capability. Template
Vers. 3.3, ISO/IEC 1998
[8] Myers, G.J.: Methodisches Testen von Programmen. 1995
[9] Petrasch, R.: Einführung in das
Software-Qualitätsmanagement. 1998
[10] Petrasch, R.: Entwicklung von Modelltypen für das
Qualitätsmanagement in der Software-Entwicklung am
Beispiel von ausgewählten
Qualitätssicherungsmaßnahmen. Dissertation.
Universität Potsdam, 1999
[11] Thaller, G. E.: Software-Qualität: Entwicklung, Test,
Sicherung. 1990
[12] Wallmüller, E.: Software-Qualitätssicherung in der
Praxis. 1990
FastAbstract ISSRE Copyright 1999
2
Microsoft and Word for Windows 2000
are reg.Trademarks of Microsoft Corp.
... Similarly, the metric structure for the evaluation of quality varies and therefore cannot be a single acceptable measure of product quality. Essentially, there are two main concepts as to how to approach quality improvement: the "product base" approach and the "process base" approach [9]. In the "product base" approach, as it is commonly perceived, "quality software" is software where all the characteristics comply with the requirements. ...
... In practice, the characteristics that are not related to the requirements are also important. Therefore, not only the presence of certain characteristics is important; a lack of features will also affect the quality of the product [9]. On the other hand, software quality is highly influenced by the development process, as is argued by the proponents of the "process base" approach. ...
... The second emphasis is the fulfillment of the direct (stated) or indirect (implied) requirements as the goal of features or characteristics inclusion. In other words, as Petrasch describes, quality is not only related to the presence of characteristics that are bound to positive requirements, but also to the absence of characteristics related to non-requirements or neutral requirements (Petrasch, 1999). ...
... Furthermore, we agree that, as Petrasch (1999) suggests, requirements specifications in general should not only list the elements and characteristics of quality design to be included, but also emphasize the characteristics of non-requirements, whose absence is vital for quality to happen. Although our framework was open to both positive and negative suggestions, our selection of the sources for normative needs was biased toward sources of quality design -the exemplar Web sites. ...
Thesis
Full-text available
Quality online health information/knowledge is globally in high demand. Achieving such quality necessitates a multi-disciplinary requirements engineering approach that enables elicitation, analysis and representation of the viewpoints from a broad variety of related sources. These sources include health and health education/promotion professionals, health informaticians and application design experts, and health consumers, the primary users of such knowledge. In addition, maintaining and improving quality over time requires such a large set of viewpoints to be updated regularly. This dissertation endeavors to provide an enabling methodology to address the above needs specifically in the field of eHealth. This research was conducted in two steps. In the first step, the existing methods of requirements engineering applicable into our particular scope of eHealth applications, aimed at health promotion/education, were reviewed to develop a framework for knowledge requirements engineering. In the second step, the usability and usefulness of the proposed framework were evaluated throughout a four-phase study (0-III). During this study, knowledge requirements engineering was used to specify the pieces of information that should be included in a quality health Web site targeting university students. Within the established framework, requirements data was gathered from various sources, including literature, existing Web sites, and interviews with local health professionals and university students. The evaluation results showed that the pieces of information and health topics specified using the framework consistently matched those the subjects preferred. In addition, the findings provided evidence that such information, when used by health search engines to index and retrieve online health resources, helped the subjects choose the resources that actually matched their interest. Finally, the data showed a higher satisfaction of the subjects with the health Web site that was built based on the knowledge requirements specified, as compared to the other selected health Web sites. This dissertation makes significant contributions to the fields of health informatics, health promotion, and requirements engineering. It contributes to the field of health informatics by expanding the scope of requirements engineering to include the field of eHealth and knowledge provision. The approach presented illustrates how various viewpoints related to requirements knowledge should be elicited, analyzed, and reasoned to build valid knowledge requirements specifications representing viewpoints of all sources consulted. It also illustrates how such specifications can be used as a basis to build quality eHealth applications. In the field of health promotion, this dissertation demonstrates a knowledge provision methodology that is grounded in the models of health behaviour change. This methodology allows health educators to rationally and accurately specify not only the health topics of high interests to health consumers, but also the type of knowledge they would prefer to be provided in the related knowledge artifacts. More particularly, this research has specified the health knowledge content of preference to adolescent consumers. These specifications highlight the particular knowledge needs of this age group, which can be used as a basis for local to national health promotion activities targeting these consumers. Finally, the research contributes to the field of requirements engineering by illustrating an integrated requirements engineering approach that accommodates multiple viewpoints and allows transparent reasoning and representation of requirements. It is anticipated that the concept of knowledge requirements engineering introduced and discussed in this dissertation will open a new area of research and practice for health informaticians. Subsequently, the methodology demonstrated can be improved and further advanced to address the needs of other domains of health and health-related knowledge.
Chapter
Pervasive systems and increased reliance on embedded systems require that the underlying software is properly tested and has in-built high quality. The approaches often adopted to realize software systems have inherent weaknesses that have resulted in less robust software applications. The requirement of reliable software suggests that quality needs to be instilled at all stages of a software development paradigms, especially at the testing stages of the development cycle ensuring that quality attributes and parameters are taken into account when designing and developing software. In this respect, numerous tools, techniques, and methodologies have also been proposed. In this chapter, the authors present and review different methodologies employed to improve the software quality during the software development lifecycle.
Article
With the increase in the number of smartphones, the use of mobile applications is growing dramatically in today's high-tech environment. With this high user demand, the quality of mobile applications is becoming a serious issue. With the perspective of quality enhancement, these applications must be smart enough so that they can handle any kind of issue automatically. Also, with the increasing complexity of these applications, they need to be more self-managed for better operability and interoperability. The self-management features allow handling issues such as error handling, optimization, resource utilization, configuration management etc. by its own. This will lead to the better functionality of mobile applications. The present research work proposes to incorporate autonomic capability as an attribute for assessing mobile applications. A multi-criteria decision-making approach named ELECTRE-TRI outranking method is used to evaluate the self-management aspect i.e. the autonomic capability of mobile applications to provide the quality estimation of mobile applications a better way.
Article
Full-text available
Chapter
Pervasive systems and increased reliance on embedded systems require that the underlying software is properly tested and has in-built high quality. The approaches often adopted to realize software systems have inherent weaknesses that have resulted in less robust software applications. The requirement of reliable software suggests that quality needs to be instilled at all stages of a software development paradigms, especially at the testing stages of the development cycle ensuring that quality attributes and parameters are taken into account when designing and developing software. In this respect, numerous tools, techniques, and methodologies have also been proposed. In this chapter, the authors present and review different methodologies employed to improve the software quality during the software development lifecycle.
Article
Full-text available
The quality of software products rarely achieves the level expected by managers purchasing the software. Only one of five implemented software projects successfully fulfills the required quality criteria. As with other products, customer satisfaction is the basic quality criterion for software products. Because each software product must be designed for an individual user, neither the customer nor the software producer has an exact image of the final product or its quality. Even when the customer and producer have similar images, the product is subject to change during the software development lifecycle. Customers often modify software requirements as the underlying needs of the customer change. It is not possible to generalize the relative importance of software quality characteristics because they are unequal for different products as well as for different customers. The aim of this research is to explore the possibilities of knowledgebased systems to support and automate the process of identifying important software quality characteristics at a specific moment in time. Identifying quality characteristics will facilitate software quality management. We applied a modified C4.5 algorithm and induced the most informative attributes with rules describing a variety of perceptions of software quality characteristics from customer and producer perspectives. The findings provide managers with useful insights that will signal needs for software quality improvements, which will enhance and refine their business performance.
Conference Paper
Software test quality measurement is the key for software release decision. It is hard to evaluate software test quality because full coverage test is impossible in practice. In this paper, we compare the existing methods for the software test quality measurement and discuss their drawbacks. Then we propose TBPP - a weighted tree based partition and proration method to evaluate software test quality. Furthermore, we evolve this method to TBPP-R by introducing a risk distribution function, which can reveal software test quality more accurately. In our experiments, we compare TBPP-R and TBPP with existing methods in our test projects. The results show that TPBB-R can measure software test quality much more accurately.
Article
Full-text available
Dieser Beitrag führt die Diskussion um den Begriff Software-Qualitätfort [Petr99b]. Ausgangspunkt war die Feststellung, dass es nicht genügt, den Qualitätsbegriff zu definieren, um ein einheitliches Verständnis für Qualität bei den Beteiligten zu erreichen. Vielmehr sind qualitätsbestimmende Begriffe wie Forderungund Merkmalzu klären. Auch stellt sich die Frage nach der Verwendung dieser Begriffe im Rahmen von Entwicklungsprozessen und Vorgehensmodellen (vgl. [Petr99a]). In die Kritik geraten dabei Normen und Standards wie beispielsweise die ISO 9001 oder das V-Modell 97, die kaum zur Klärung beitragen. Die Problematik des Qualitätsbegriffes auch in Verbindung mit Prozessstandards sei daher nochmals kurz erläutert. Weiterhin seien einige kontroverse Argumente vorgestellt, und um das Problem mit der Software-Qualität zu veranschaulichen, ist ein Beispiel aus dem Bereich Software-Ergonomiegegeben. Allerdings kann und will dieser Beitrag keine „Küchenrezepte“ liefern, sondern hauptsächlich auf die Schwierigkeiten beim Umgang mit Qualität hinweisen und die Diskussion beleben.
Book
Full-text available
Dieses Buch richtet sich an Software-Entwickler und Projektleiter in der Praxis, die einen Einstieg in das Thema Software-Qualitätsmanagement suchen und an Studierende, die das Lehrgebiet Software-Engineering in Richtung Qualitätsmanagement vertiefen wollen. Vor­aus­setzungen für das Lesen sind prinzipiell nicht vorhanden, allerdings erleichtern Grund­kenntnisse des Software-Engineering und speziell im Bereich der Entwicklung von Soft­ware-Systemen mit einer Hochsprache das Verstehen der Thematik. Die Einführung in das Software-Qualitätsmanagement will in erster Linie die Software-Ent­wick­lung mit dem Begriff Qualität derart verbinden, dass die Leserin oder der Leser eine Vorstellung von der mittlerweile recht eigenständigen und umfangreichen Disziplin des Quali­täts­manage­ments und den damit verbundenen Tätigkeiten, Dokumente und Rollen er­hält, wo­bei der Schwer­punkt auf dem eigentlichen Software-Entwicklungsprozess liegt und die sicher­lich eben­falls wichtigen Bereiche wie das Projekt- und Konfigurations­manage­ment nicht näher betrachtet werden. Eine weitere Intention ist die Darstellung verschiedener Aspekte des Qualitätsmanage­ments: Es existiert eine Vielzahl von Normen, Standards und Methoden bzw. Techniken, so dass zumindest einige davon eine einführende und beispielhafte Erläuterung verdienen, z. B. die ISO 9000, das Capability Maturity Model, der Rational Unified Process, das V-Modell 97, das W-Modell und das Test Process Improvement (TPI®). die eine große prakti­sche Bedeutung besitzen. Einige dieser Themen werden durch Gast­beiträge be­han­delt. Die Au­­toren der Beiträge, Thomas Blum, Ralf Kneuper, Tim Koomen, Martin Pol, und Andreas Spillner, sind Spezialisten im Bereich Qualitätsmanagement mit fun­dier­ten theo­retischen Kenntnissen und langjährigen praktischen Erfahrungen (s. Autorenver­zeichnis, S. 268f.). Weiterhin sollen Verfahrensanweisungen, die bei einem Qualitätsmanagementsystem eine zentrale Rolle einnehmen, in leicht verständlicher Form und konkreten Ablauf­be­schrei­bun­gen ver­mittelt werden, so dass eine Vorstellung von der Anwendung des Qualitäts­manage­ments ent­stehen kann. Auch auf die Problembereiche im QM-Umfeld sei hingewiesen, z. B. die Gefahr der Unflexibilität bei der Festschreibung der Prozesse in der Software-Ent­wicklung. Analytische Qualitätssicherungsmaßnahmen, die „nah“ am Code zur Anwendung kom­men, z. B. der objektorientierte Modultest, und die Verifikation seien nur im Überblick be­schrie­ben – zu groß wäre der Umfang durch die Vielzahl der Qualitätstechniken und Pro­gram­mier­sprachen.
Article
Full-text available
Denver's new international air port was to be the pride of the Rockies, a wonder of modern engineering. Twice the size of Manhattan, 10 times the breadth of Heathrow, the airport is big enough to land three jets simultaneously-in bad weather. Even more impressive than its girth is the airport's subterranean baggage-handling system. Tearing like intelligent coal-mine cars along 21 miles of steel track, 4,000 independent "telecars" route and deliver luggage between the counters, gates and claim areas of 20 different airlines. A central nervous system of some 100 computers networked to one another and to 5,000 electric eyes, 400 radio receivers and 56 bar-code scanners orchestrates the safe and timely arrival of every valise and ski bag. At least that is the plan. For nine months, this Gulliver has been held captive by Lilliputians-errors in the software that controls its automated baggage system. Scheduled for takeoff by last Halloween, the airport's grand opening was postponed until December to allow BAE Automated Systems time to flush the gremlins out of its 193millionsystem.DecemberyieldedtoMarch.MarchslippedtoMay.InJunetheairportsplanners,theirbondratingdemotedtojunkandtheirbudgethemorrhagingredinkattherateof193-million system. December yielded to March. March slipped to May. In June the airport's planners, their bond rating demoted to junk and their budget hemorrhaging red ink at the rate of 1.1 million a day in interest and operating costs, conceded that they could not predict when the baggage system would stabilize enough for the airport to open. To veteran software developers, the Denver debacle is notable only for its visibility. Studies have shown that for every six new large-scale software systems that are put into operation, two others are canceled. The average software development project overshoots its schedule by half; larger projects generally do worse. And some three quarters of all large systems are "operating failures" that either do not function as intended or are not used at all. Photo of Dallas International Baggage Handling System: SOFTWARE GLITCHES in an automated baggage-handling system force Denver International Airport to sit empty nine months after airplanes were to fill these gates and runways (top). The system that is supposed to shunt luggage in 4,000 independent "telecars" along 21 miles of track still opened, damaged and misrouted cargo as testing continued in July (bottom). The art of programming has taken 50 years of continual refinement to reach this stage. By the time it reached 25, the difficulties of building big software loomed so large that in the autumn of 1968 the NATO Science Committee convened some 50 top programmers, computer scientists and captains of industry to plot a course out of what had come to be known as the software crisis. Although the experts could not contrive a road map to guide the industry toward firmer ground, they did coin a name for that distant goal: software engineering, now defined formally as "the
ISO 9241-10:1996: Ergonomic Requirements for Office Work with Visual Display Terminals -Part 10
ISO 9241-10:1996: Ergonomic Requirements for Office Work with Visual Display Terminals -Part 10. ISO, 1996
(E) – Information Technology -Software Process Assessment: Part 2: A reference model for processes and process capability
  • Iec Tr
ISO/IEC TR 15504-2:1998(E) – Information Technology -Software Process Assessment: Part 2: A reference model for processes and process capability. Template Vers. 3.3, ISO/IEC 1998