DEVELOPER’S VIEW ON THE SOFTWARE QUALITY MODEL BASED ON THE ISO/IEC 9126 ** Seon-ah Lee, Samsung Electronics Co., Ltd. Sookyung Kim, Byoungju Choi, Ewha Womans University, Korea Summary: Several Software Quality Models (SQMs) have been developed to define a software quality. These models have two goals: to measure a software quality and to control a software quality. The SQM of ISO/IEC 9126 is defined from the user's viewpoint and is an incomplete model for controlling a software quality in the development process. Since this model cannot show how to build a high quality software, the SQM of the developer's view is needed. Here, we suggest the Hierarchical Software Quality Model (H-SQM). This model is a completely hierarchical model and based on product properties. And we propose the method of applying metrics to the development process using the H-SQM. Thus we could utilize the software quality metrics efficiently in order to improve the quality of software in the software development process. Seon-ah Lee, Ms., Sookyung Kim, Ms., Byoungju Choi, Prof., Deft. of CS and Engg., Ewha W. Univ., Seoul <120-750>, Korea, tel.:+82-2-3277-2593, fax.: +82-2-3277**This 3508, email : [email protected], [email protected]. research was supported by the Brain Korea 21 project.

1. Introduction In order to develop high quality software, software metrics have been developed to assess software quality. Several Software Quality Models (SQMs) have been suggested for using software metrics. An SQM defines the quality of software and analyzes the metrics' measurements based on its definition. For that, the quality is divided into quality attributes, and accordingly quality attributes are sub-divided into sub-quality attributes. Metrics are constructed to assess the aspect of a sub-quality attribute. ISO/IEC 9126, international standards, suggested the SQM defined from the user's viewpoint [ISO/IEC 9126, 1996]. This SQM defines quality attributes and sub-quality attributes on the basis of external product behavior. Because external product behavior cannot be assessed directly in the development process, this model cannot be utilized as a criterion of quality control. Thus it is an incomplete model to control software quality in the development process. Boehm, McCall and Dromey suggested their SQMs to analyze the meaning of measurement of metrics in the development process from the developer’s viewpoint. Since these models redefine quality attributes as product properties, they have the merit of establishing an objective and universal quality model by assessing quality based on the general properties of software. In these models, however, there cannot be 1:m relations of quality attributes and product properties. Thus it is not easy to evaluate quality by the product properties. We suggest the Hierarchical Software Quality Model (H-SQMs). For this model, we define implicative relations among quality attributes in order to solve the problem of quality attributes overlapping each other.

Under these relationships among quality attributes, this SQM is a quality model based on product properties and a hierarchical quality model which does not overlap the quality attributes. Also, we propose a method for applying metrics to a development process using the H-SQM. The method represents the H-SQM as the cause-and-effect diagram and changes this diagram to the process-analysis diagram. Then, the method applies software quality metrics to each development phase by the processanalysis diagram. In this way, we could utilize the software quality metrics efficiently in order to improve the quality of software in the software development process.

2. A Software Quality Model of Developer's View: H-SQM The H-SQM proposed in this paper is a quality model from the product's view, which does not have any overlapped sub-quality element. It is made from applying the implicative relationships between quality attributes proposed in Section 2.1 and product properties and metrics identified by the step in Section 2.2. The H-SQM may be illustrated using a cause-and-effect diagram as in Figure 1 in Section 2.3.

2.1 Implicative Relationship Between Quality Attributes. The implicative relationship between quality attributes is the one between pre-condition and post-condition of a quality attribute. The former should be satisfied in advance. The definitions of quality attributes are based on ISO/IEC 9126. The quality attributes in ISO/IEC 9126 are functionality, reliability, efficiency, usability, portability and maintainability. Among these, portability is defined as the capability of software to be transferred from one environment to another in a wider sense than the general meaning of portability. Therefore, we modify the definition of portability as the capability of software to be ported from one environment to another. Reusability is not defined in ISO/IEC 9126, but it is the most important one among attributes when we evaluate a software quality from re-developer's point of view. Therefore, this paper adds reusability to the quality attribute group and defines it as the capability of software component to be reused when it is used for the same, or different system in a new context. This section defines 6 implicative relationships between quality attributes based on definitions and ranges of quality attributes as follow and illustrate them in a diagram in Figure 1(b). Functionality prior to reliability: Functionality is the capability of the software to provide functions which meet stated and implied needs under specified conditions. Reliability is defined as an ability to satisfy the software's performance level high enough to operate a long period of time without any failure in a given environment. A correct function makes high reliability. But it doesn't always mean that correct function guarantees high reliability. Wrong input could result in malfunction even though functions are correct. In this case, functionality is satisfied, but reliability isn't. Reliability prior to usability: Usability is the capability of the software to be understood, learned, used and liked by the user. For usability, the system should maintain a certain level of performance as first priority. If the system is low in reliability and fails when in use, user satisfaction will be lowered. Efficiency prior to usability: Efficiency is an ability that provides the required performance related to the amount of resources used, under stated conditions. Usability is evaluated partly by his/her efforts using the software. The efforts can be defined as efficient work per operating time. When efficiency is satisfied in advance, response is made within required time. Then the efforts made to use the software can be reduced. Therefore, efficiency should be satisfied to guarantee usability.

Modularity is a precondition to reusability: Reusability is the capability of a software component to be reused. To reuse the part of the system, the system should be constructed based on modularity. Only by modularity, a component can be separated from a system. Therefore, Modularity is a precondition of reusability. Modularity improves maintainability: Maintainability gets higher when a replacement of a component affects less the rest part of a system. Therefore, when modularity is satisfied, maintainability improves. Reusability improves portability: The more modules of the software are reusable when they carry to another environment, the more portable the software is.

2.2 Metrics of each of Quality Attributes. A lot of studies have been made on product properties and metrics of each of quality attributes. In this section, we describe how to identify the metrics of each quality attributes. First of all, we identify and classify the product properties for each quality attributes based on the results of those studies. If a product property is overlapped in two quality attributes, it was put into the quality attribute that should be first satisfied according to implicative relationships defined in section 2.1. In this way, the quality attribute that should be later satisfied can also contain the product properties. Therefore, quality attributes are nonoverlapping. For example, reusability should be satisfied prior to maintainability and portability. Therefore, when reusability includes modularity, maintainability and portability will also include modularity. Based on these properties, we can formulate the metrics of each quality attributes. The product properties were illustrated in a diagram in Figure 1. (a)

Completeness Specification completeness Consistency Specification suitability Traceability

Correctness Specification correctness Function implementation adequacy Module Correctness Interoperability System Functionality

Fault tolerance

Memory utilization

Task Efficiency

Task Time

Functionality

Functionality

Module reliability System reliability Data consistency

Time Needless re-computation Design for performance engineering Useless computation Bottlenecks Waiting for services Response time Requests for services

Reliability

Reliability

Efficiency

Efficiency

User Satisfaction

Help & documentation Visibility of system status Match between system and the real world Flexibility and efficiency of use Recognition rather than recall User control and freedom Error prevention Consistency and standards Help users recover from error Aesthetic & minimalist design

Module Reliability Module Complexity Module Documentation Module external dependency Lines of Module document Number of parameters Testability Currency

A prior to B A improves B

Reliability Fail-safety Fail-operation No single point of failure

Resource

(b)

Description

Controllability Loss of information Capability to observe Sensibility of failure

Usability

Reusability

Usability

Reusability

Complexity External documentation Lines of comments

Complexity Lines of code Maintainability

Isolating O.S environment Hardware Independent Environment independent module Data type compatibility GUI division Compiler result consistency Execution engine independence File module documentation Isolating OS-spec. code Data continuation Data Adequacy Portability

Maintainability

GUI division

Software Quality

Figure 1. The cause-and-effect diagram of H-SQM

2.3 H-SQM

Portability Implicative Relationships among Quality Attributes

In this Section, the H-SQM is shown using a cause-and-effect diagram (Kan,1995) as in Figure 1(a and b). This diagram illustrates in a clear way the possible relationships between identified quality attributes and product properties that may have influence on them. Each of product properties can be treated as an individual branch. Thus various causes are closely examined to improve the quality. This shows easily how to control product properties to improve quality.

3. Method to Apply the H-SQM to Development Process This section shows how to apply the H-SQM to the development process as shown in Figure 2. Phase 0 prepares the basis of the H-SQM. Phase 1, 2 and 3 in Figure 2 present how to make the H-SQM. Phase 3', 4 and 5 show how to apply the H-SQM to the pertinent development process. This section describes how to apply the H-SQM to an object-oriented development process, following the phase 3', 4, and 5. Product 0. Define the implicative relations among quality attributes. Identify the product components. 1. Identify the product properties for each quality attributes. 1

2

3’

2. Identify the component properties for each product property.

3 3. Get the metrics for measuring each component property. 4

0 Quality

3’. Replace general component properties and metrics with specific component properties and metrics to the product. 4. Find the point of time when each component is created in the process.

5 Process

5. Establish metrics in the point of time when a component is created in the process.

Figure 2. Steps to apply the H-SQM to development process Phase 3’: Phase of replacing general metrics with object-oriented metrics Metrics of the H-SQM are replaced with object-oriented metrics. In the object-oriented development, the modules are refined into method, class and component. Consequently, module-related metrics should be modified to metrics relative to the object-oriented properties. For example, we can replace McCabe's complexity metrics as metrics for module complexity with WMC, RFC and LCOM [Chidamber, 1994]. Phase 4, 5: Phase of establishing metrics specific to development steps In this phase, we apply the H-SQM to the development process by using a process-analysis diagram. The H-SQM can be rebuilt as a process-analysis diagram according to the flow of development process. we produce such a process-analysis diagram as in Figure 3 by identifying the point of time when a component is created in the process, arranging metrics according to the arrangement of components. The metrics, which are proposed for each of quality attributes, are grouped in each development phase. The metrics of each phase are shown in Figure 3. As the aspects to be measured for every quality attribute are different, quality attributes emphasized in each phase are also different. For example, since correctness and completeness are important in analysis and design phases, quality attribute which is mainly measured in these phases is functionality. In implementation, since actually implemented modules and codes are produced, reusability, maintainability and portability are mainly measured. In test phase, functionality, reliability, efficiency and usability, which are the external user's point of views, are measured.

•Interoperability •Module correctness •Specification •Function implementation •Interoperability completeness adequacy •Consistency •Specification •Consistency •Traceability correctness •Traceability

•Component •Functional correctness •Consistency •Traceability

•System test •Density of failure •Consistency •Traceability

Functionality

•Fail-safety

•Component reliability

•System reliability •Data consistency •No single point of failure

Reliability

•Memory utilization •Response time

Efficiency

•Fail-operation

•Module reliability

•Bottlenecks •Design for performance •Memory utilization engineering •Useless computation •Requests for services •Needless re-computation •Waiting for services

•Data structure •UI satisfaction

•Data structure •UI satisfaction Analysis

Design

Implementation of class

• Module complexity • Module external dependency

•Module reliability •Module documentation

•Complexity •Currency

•Lines of code •Lines of comments •Controllability •Capability to observe

•GUI division •Execution engine independency •Environment independent module •File module documentation

Implementation of component

Implementation of system

Usability

User test Reusability

•Module documentation

•Halstead’s complexity •McCabe’s complexity •LOC: Lines of code •CMT: Lines of Comments

•External document

•Data type compatibility •Compiler result consistency •Data adaptability •Data continuation •Isolating OS-spec. code

Maintainability

Portability

Figure 3. The metrics set in each development phase

4. Analysis First, we have analyzed to what degree the H-SQM is qualified compared with the existing quality models. Secondly, we have compared and analyzed application methods of SQM. (1) Comparison between the H-SQM and Other SQMs To compare the H-SQM with the existing quality models of Boehm, McCall, ISO/IEC 9126 and Dromey, the criteria for quality model analysis were established. Analysis criteria are established, based on the requirements of quality model; SQM should be comprehensive (comprehensiveness) and applicable to the process (applicability). To make quality understandable, quality attributes of software quality model should be gathered to complete the software quality (completeness) and a quality attribute should not deteriorate while another improves (compatibility). Quality attributes should not be overlapped (non-overlapping). The metrics results should be variously reflected to quality model (reflection of results). Table 1 shows the results of comparing the above 6 requirements for quality model analysis. It can be noticed as shown in Table 1 that the H-SQM solved the problem of overlapping while meeting other requirements. (2) Comparison of Methods applying SQM to development process The method suggested in this paper was compared and analyzed with ISO/IEC 14598[ISO/IEC 14598, 1996]. For this, 6 attributes, which effective software metrics should include, were used as criteria[Ejiogu, 1991]. The cause of using the attributes as criteria for comparison of methods is that application method is the overall point of view for measuring the quality using metrics. Therefore what the attribute is extended to the overall point of view is requirements for method. The results of comparing between this paper's method and ISO/IEC 14598 are shown in Table 2. They are summarized as in the followings. First, this paper's method can be applied to individual processes more efficiently than ISO/IEC 14598. Secondly, the method enables applied metrics to be easily analyzed from a quality's point of view. Thirdly, when the results of metrics measurement are not sufficient, it is easy to show in what aspect quality improvement should be made. Therefore, quality can be reviewed more efficiently in this method than the existing methods.

Table 2. Comparison of metrics in each method

Table 1. Comparison of SQMs SQM

O

O

ISO/IE C 9126 O

Applicability

O

O

X

O

O

An effective mechanism for quality feedback

△

O

Completeness

△

△

△

△

△

Simple and computable

×

O

Compatibility

O

O

O

O

O

Consistent in its use of units and dimensions

O

O

Non-overlapping

X

X

O

X

O

Programming language independent

O

O

Reflection of Results

X

X

△

X

△

Consistent and object

O

O

Requirement Understadability

McCall

Boehm

Drome y △

H-SQM O

(○:Satisfy, △:A little satisfied, ×:Not satisfied)

Method Measurement Empirically and intuitively

ISO/IEC 14598 △

Our Method O

(○:Satisfy, △:A little satisfied, ×:Not satisfied)

5. Conclusion This paper proposed the H-SQM, an SQM for controlling software quality in the development phase. By using the H-SQM, the influences that product properties have on quality can be verified, as product properties among quality attributes are not duplicated. The H-SQM let us know what aspects of quality improve when metrics are satisfied. Therefore, establishment of metrics gets clear and the control of software quality in the development phase turns easy. The H-SQM, as has been analyzed, satisfies requirements for the quality model and is easy to verify, suitable for a quality control model in the development phase to satisfy the quality described in ISO/IEC 9126. Methods to analyze the results of metrics assessment are needed for further complement in the future. The H-SQM is for quality control in the process. Therefore, an example of actual application should be showed. The method of collecting and analyzing the results of metrics assessment should be presented to evaluate products at the point of verification in the development process. To do this, weights for importance should be put on every quality element and a measurement process using it should be produced. H-SQM has not been completed yet. More product properties that affect its quality will be added to complete H-SQM. If factors to satisfy quality are found out and complimented, H-SQM could came to satisfy perfectly the quality assessment for measuring with quality model of ISO/IEC 9126.

References (Bevan, 1995) Bevan, Nigel: Measuring usability as quality of use. J, of Software Quality, Issue 4, 1995. (Blackham, 1988) G. Blackham: Building Software for Portability, Dr. Dobb's J., Dec. 1988. (Chidamber,1994) S. Chidamber, C. Kemerer:A Metrics suite for object oriented design, IEEE TSE, June, 1994. (Dromey, 1996) R. Dromey: Cornering the Chimera, IEEE Software, Jan. 1996. (Ejiogu, 1991) L. Ejiogu: Software Engineering with Formal Metrics, QED, ISDN 0-13-099755-2, 1991. (IEEE 1061, 1989) IEEE 1061: Standard for a Software Quality Metrics Methodology(Draft), 1989. (ISO/IEC 9126, 1996) ISO/IEC 9126: Software Quality Characteristics and Metrics(Draft), 1996. (ISO/IEC 14598, 1996) ISO/IEC 14598: Software Product Evaluation, 1996. (Jeffrey, 1994) P. Jeffrey: Measuring Software Reusability. Proc. of the 3rd ICSR, Nov. 1994. (Kan, 1995) S. Kan: Metrics and Models in SW Quality Engg., Addson Wesley, ISDN 0-201-63339-5, 1995. (Kitchenham, 1996) B. Kitchenham, S. Pfleeger: Software Quality:The Elusive Target, IEEE Software, Jan. 1996. (Linger, 1993) R. Linger: Cleanroom Software Engineering for Zero-Defect Software, Proc. of ICSE, May 1993. (Oman, 1994) P.Oman, J.Hagemeister: Constructing and Testing of Polynomials for Predicting Software Maintainability, J. of System & Software, Mar. 1994. (Poore, 1993) J. Poore, et.al.: Planning and Certifying Software System Reliability, IEEE Software, Jan. 1993. (Tervonen, 1996) I. Tervonen: Support for Quality-Based Design and Inspection, IEEE Software, Jan. 1996.