Software Quality: Attributes and Modalities

Software quality: attributes and modalities

M.L. Hines, A.A. Goerner

Computer Science Telecommunications Program, University of Missouri - Kansas City, 5100 Rockhill Road, Kansas

City, Missouri 64110, USA

Abstract

Taxonomies of software qualities have attempted to differentiate the roles of the various software qualities (Boehm[lj). As such they have not achieved a delineation useful for software quality assessment, either quantifiably or

relatively. Typically software quality roles have been either as-built utility or evolvability. As-built utility centers around issues of reliability, measurability, and human/social factors. Evolvability centers around issues of understandability, testability, and modifiability. None of the issues associated with either as-built utility or evolvability are easy to differentiate in a manner that allows discussion of software quality in even a relative manner. We propose a software quality taxonomy which delineates software quality roles as attributes or modalities. Attributes are descriptive of code and relate to how code is written. They predicate on functionality and do NOT correspond to a support subsystem but are integrally part of the system. Modalities are descriptive of software architecture and relate to what code is written. They are a relation over functionality and often correspond to a support subsystem. The interaction and interdependencies between the quality issues associated with both the attribute and modality roles are explored with respect to the necessary tradeoffs which influence software quality and its management within a system. A brief example relating in particular to some of the modalities is included.

1 Introduction

A fundamental goal of software engineering is the development of high quality software at low cost (Jalote[2]). Attention to software quality is important in software development not only because of its influence on long-term corporate profitability, but primarily because of the increasing pervasiveness of software

138 Software Quality Management

in everyday life. Software quality has remained, however, a somewhat elusive goal, primarily because of the lack of measurability of "quality". Increasing complexity and evolvability of software requires continuous attention to, and assessment of the quality of the software under development. In particular, evolution of software poses a special threat for software quality that requires an examination of the interrelationships among different facets of software quality. To be able to examine these interrelationships, the roles of software quality need to be differentiated such that either a quantifiable or a relative assessment of software quality can be achieved. Taxonomies of software quality have attempted to differentiate the roles of the various software qualities but have not achieved a delineation useful for software quality assessment, either quantifiably or relatively (Boehm[l], McCall[3]. Cavano[4] Kaposi[5]). Quantifiable measurement of software quality is difficult to achieve as most of the facets of software quality cannot be measured directly; rather they must be measured indirectly, and generally, subjectively (van Vliet[6]). Another problem with quantifiable measurement of software quality, albeit an overlooked problem, is that measurements do not tell you how to do a better job of achieving software quality. A relative assessment of software quality allows tradeoff considerations to be made (Kitchenham[7]). To achieve a relative assessment of software quality, the roles of the different software qualities need to be clearly delineated. This allows each quality to remain in context of other qualities and in the context of the application domain. The software quality taxonomies to date have attempted to categorize software qualities in a manner that will allow objective, quantifiable measurement (Boehm[l], McCall[3], Cavano[4] Keller[8]). In some cases, researchers have attempted to decompose software qualities into consumer- oriented qualities and technically oriented qualities (Keller[8J). The research presented in this paper proposes a software quality taxonomy which delineates the roles of software qualities such that relative assessment is possible especially with respect to assessment of tradeoffs between software qualities. More importantly, the role delineation highlights the separation between which software can be built and reused, and which software must be included in the system itself. Software qualities are differentiated as either attributes or modalities. Attributes are descriptive of code and relate to how code is written. They do NOT correspond to a support subsystem but are integrally part of the system.

Modalities are descriptive of software architecture and relate to what code is written. They generally correspond to a support subsystem, or code which potentially can be reused. The interactions and interdependencies between the attributes and modalities allow a relative assessment of software quality especially with respect to the tradeoffs necessary during system development and evolution.

Section 2 reviews the historical foundations of software quality, in particular highlighting the taxonomy work of Boehm and McCall. Section 3 introduces the general notions and concepts behind the attribute/modality approach to software quality and sets it within the historical framework of Boehm and McCall. Section 4 provides the details of the attribute/modality approach and highlights the interactions between attributes and modalities with respect to system development and analysis. Section 5 presents a brief example relating to some of the modalities. Section 6 concludes the paper.

Software Quality Management 139

2 Background information

Software quality assessment has two basic approaches: definition and taxonomy. Agreement as to the definitions of the different facets of software quality has not been reached, leaving the definition of software quality itself open to multiple perspectives. ISO 9001 states general requirements for a quality system but has to be augmented by more specific procedures and definitions (ISO[9]). IEEE provides definitions for some of the different facets of software quality but is not complete (IEEE[10J). The initial starting point for this work was to re-examine those definitions and provide a set of software qualities with definitions that would serve as the foundation for the software taxonomy. There are several different software quality taxonomies which have been proposed; included are Boehm's and McCall's taxonomies. Each taxonomy attempts to group software qualities in some fashion that will allow quantitative assessment of quality (Boehm[l], McCall[3]). Boehm initially categorizes software qualities (called quality attributes) as maintainability (or evolvability), portability, and as-is utility (Boehm[l]). Each of these is then decomposed into second-level quality attributes and finally into source-code characteristics. Boehm's software quality characteristic tree, with updates and extensions to correspond to the set of software quality definitions provided in this work, is shown in figure 1. Boehm's quality characteristics are placed strictly within the source code of the system.

Reliability

Human Factors

Measur-

ability Software Qualities Understand- ability

Testability

Modifi- ability

Figure 1. Software qualities

McCall distinguishes between two levels of quality attributes. The higher-level quality attributes are termed quality factors, and cannot be measured directly. The second level of quality attributes are termed quality criteria, and are measured generally subjectively. By combining ratings for the individual quality criteria affecting a given quality factor, a measure for the extent to which that quality factor is being satisfied can be indirectly obtained (McCall[3]). Fenton uses McCall's taxonomy to distinguish between internal and external quality attributes, with internal attributes corresponding to quality criteria and external attributes corresponding to quality factors (Fenton[10J). Fenton's work begins a foundation for differentiating the roles of software qualities but does not carry it out to provide a reuse and relative assessment foundation. The current software quality taxonomies do not provide a delineation of software roles such that a foundation is provided for discussion of reuse or of relative assessment.

3 Introduction to attributes and modalities

To provide a foundation for the delineation of software quality roles, it was initially necessary to define a set of software qualities (Table 1).

Table 1. Software qualities accuracy - freedom from error cohesiveness - degree to which tasks performed by a single program module are functionally related completeness - degree to which full implementation of required function has been achieved complexity - degree to which a program can be understood w/out difficulty conciseness - compactness of program code consistency - absence of conflicts or contradictions correctness - degree to which a program satisfies its specification, fulfills the customer's mission objectives, and is free from defects device performance - degree to which software performs its intended function with a minimum of consumption of computing resources device independence - degree to which software is decoupled from the hardware on which it operates genericity - ease with which software allows differing system constraints and user needs to be satisfied legibility - effort required to learn, operate, prepare input and interpret output of a program orthogonality - functional independence of program components portability - ease of transferring a software system to a different computer and/or operating system representativeness - degree to which the program models real-world functionality reusability - degree to which program can be reused in other applications self-containedness - degree to which software is composed of discrete components such that a change in one component has minimal impact on other components stability - ability of a system to provide continuity of operation under various abnormal conditions

Software Quality Management 141

Table 1. Software qualities (continued) time-dependent - ability of a computer system to perform its functions with respect to time and performance constraints, e.g., response time, etc. verifiability - ability to trace a design representation or actual program component back to requirements well-documented - degree to which the software assists in enabling new users to apply the system augmentability - degree to which design can be extended distributability - degree to which the software is amenable to distribution

geographically and temporally instrumentability - degree to which the program monitors its own operation and identifies errors that occur integrated - related specifically to interfaces to other systems, users, or self integrity - prevention of unauthorized alteration, use, destruction, or release of data during authorized use interoperability - ability of two or more systems to exchange information and to mutually use the exchanged information robustness - degree to which software can continue to operate correctly despite the introduction of invalid inputs safety - degree to which the software system ensures that no matter what errors occur, the system defaults to that state which does no harm security - availability of mechanisms that control or protect programs and data

user-adaptability - degree to which the software can be adapted to a user or by self, to meet individual user needs

These software qualities were then re-examined with respect to the software quality roles they affected or to which they made contributions. Two primary roles were identified which emphasized relative assessment and reuse potential: attributes and modalities (figure 2).

Software Qualities

Figure 2. Attributes and modalities

A software attribute is descriptive of code in that it focuses on how code is written rather than what code is written (with respect to functionality). Software attributes do not correspond to a support subsystem and as such are not good candidates for software reuse since variance in the domain generally disallows genericity of the software quality code. Software attributes are generally easier to build than software modalities because we better understand software from a code integration viewpoint rather than an architectural integration viewpoint. Attributes are first order software qualities that relate directly to the functionality of the software system.

A software modality is descriptive of the software architecture of a system rather than the code of the system. Often a software modality corresponds to a support subsystem and becomes a viable candidate for software reuse, either as an operating system extension or as a framework for code inclusion. Software modalities traditionally have been hard to build because they are often reflective of nonfunctional requirements. Modalities are second order software qualities that relate to the functionality of the software architecture. Once the two primary software roles were defined, the software qualities were then evaluated as to the roles they fit. Figure 3 shows the results of that evaluation with a cross-referencing to Boehm's taxonomy.

4 Attribute/modality tradeoffs

Attributes and modalities do not exist in a vacuum: each attribute or modality affects and is affected by other attributes and/or modalities. The degree and extent to which an attribute or modality is affected by another, helps determine the tradeoffs which may be necessary when deciding which attributes/modalities are required by a system. Although an in-depth examination of all of the tradeoffs is beyond the scope of this paper, an overview of some of the interactions and interdependencies between attributes and modalities is included to highlight tradeoffs which may have to be made. The interactions and interdependencies occur as attribute-attribute, attribute- modality, and modality-modality (figure 4).

Many attributes clearly aid (+) or detract (-) from other attributes; some can either help or hinder depending on the domain and situation (+/-). In a large number of cases, there is little or no effect. In general, attributes affect modalities more than modalities affect attributes. The attribute-modality review focuses one-way from attribute to modality but not the reverse of modality to attribute. Most of the modalities decrease the conciseness of a system, and strongly enhance portability and reusability. As in the case of the attribute-attribute interactions and interdependencies, the modality-modality interactions and interdependencies have some very clear effects and some effects which are dependent on domain and situation. Again, in some cases, there is little or no effect. Since it is not possible to positively maximize all software qualities, it is necessary to make decisions regarding tradeoffs. An examination of the interactions and interdependencies aids in relative assessment of software qualities by providing a mechanism for tradeoff evaluation.

5 Brief example

The attribute role of software qualities is relatively well-understood; it is in general how the inclusion of software qualities has been traditionally accomplished. The modality role of software qualities is not well-understood; the example presented here emphasizes one of the modalities - instrumentability - to illustrate the concept of modalities. Instrumenting complex production software systems is one of the most problematic aspects of software system architecture. The instrumentation problem, in particular for large-scale, multimodal production software systems and computing environments, is to provide a means for one software system to

Software Quality Management 143

Accuracy

Cohesiveness

Completeness j Complexity |

Conciseness

Consistency |

Correctness

Device-Independence]

] Legibility ]

Orthogonality { Portability ] Representativeness

Reusability J

Self-Containedness |

Verifiability

Well-Documented J -

Augmentability |

Instrumentabillty |

n Integrity J

Interoperability |

Robustness { Safety |

Security ] User-Adq)tability (-*

Figure 3. Software quality roles

144 Software Quality Management

Figure 4. Interactions and interdependencies

Software Quality Management 145

orthogonally monitor, and possibly modify another. Object-orientation addresses the problems of large-scale software not only by providing facilities for modularization, data encapsulation, and source code reuse, but also by providing fundamental support for general system modeling and orthogonal design via inheritance, message passing, and dynamic binding. Using an

object-oriented foundation, a standard, transparent mechanism for message interception and event propagation, called a probe, is defined to address the instrumentation problem (Goernerfl 1]). A probe is a transparent filter which may be placed in the messaging stream. Each probe is created to recognize specific messages, and is a guarded command which, when enabled and triggered by the receipt of a message type it monitors, emits another, derivative message to a designated probe handler. Probes may handle a triggering message in one of two ways: the probe may operate in surveillance mode such that it passes the triggering message through to its intended destination immediately after noting its arguments and then sends its message to the probe handler or it may operate in an interception mode, where it holds the triggering message until it receives an acknowledgment from its probe handler. In general, unidirectional event synchronization and data flow between

software systems is as easy as creating a probe on the triggering event and a probe handler which takes appropriate action. This use of probes could be valuable in designing sophisticated shared resource managers such as printer pool managers. Probes provide such managers the means to react to a request before it is actually submitted so that resource initialization or reservation may be done. Probes also allow monitoring of system usage patterns which otherwise might not be captured but which are important to load balancing strategies. Instrumentation via probes is an example of the role of software modalities. While instrumentation is not part of the functionality of the software (predicate on functionality) it is an integral part of the functionality of the software architecture within which the software resides (relation over functionality).

6 Conclusion

This paper has presented a software quality taxonomy which differentiates the roles of software qualities. The differentiation of software qualities as attributes and modalities provides a means for relative assessment of software qualities particularly with respect to tradeoffs between software qualities, and to their place within a software system. It also provides a foundation for future work with respect to software modalities, software architectures, and the ability to reuse software. This future work centers around, in particular, whether software modalities, built for reuse, are extensions to an operating system or are a framework for specialization and adaptation. There is also more work to be done in the examination of the interactions and interdependencies of the attributes and modalities, and the extent of those issues.

146 Software Quality Management

References

1. Boehm, B. W., Brown, J. R., Kaspar, H., Lipow, M., MacLeod, G., J. & Merit, M. J., Characteristics of Software Quality, TRW Series of Software Technology 1, North-Holland, 1978. 2. Jalote, P., An Integrated Approach to Software Engineering, Springer- Verlag, 1994. 3. McCall, J. A., Richards, P. K. & Walters, G. F., Factors in Software Quality, RADC-TR-77-369, US Department of Commerce, 1977. 4. Cavano, J. P. & McCall, J. A., A framework for the measurement of software quality, pp. 133-139, Proc., ACM Software Quality Assurance

Workshop, Nov. 1978. 5. Kaposi, A. & Kitchenham, B., The architecture of system quality, Software Engineering Journal, 1987, 2-8. 6. van Vliet, H., Software Engineering: Principles and Practice, Wiley, 1993. 7. Kitchenham, B., Towards a constructive quality model, Part I: software quality modelling, measurement and prediction, Software Engineering Journal, 1987, 105-113. 8. Keller, S. E., Kahn, L. G. & Panara, R. B., Specifying Software Quality Requirements with Metrics, System and Software Requirements Engineering, ed. R. Thayer & M. Dorfman, pp. 145-163, IEEE Computer Society Press, 1990. 9. ISO 9001: Quality systems - Model for quality assurance in design/development, production, installation and servicing, ISO, 1987.

10. IEEE Standard for Quality Assurance Plans, IEEE Std. 730, 1984. 11. Goerner, A. A. & Hines, M. L., Instrumenting Intelligent Manufacturing Applications, Proceedings The Fourth International Conference on Industrial & Engineering Applications of Artificial Intelligence and Expert Systems, Kauai, Hawaii, June 2-5, 1991.