KR20010109629A - Quality Management System using Hierarchical Software Quality Model - Google Patents

Abstract

The present invention relates to a software quality control method using a hierarchical software quality model. When measuring quality, the quality of the corresponding software is measured when the defined product characteristic is measured to be mapped to one quality attribute. Make sure you know the level immediately. For this purpose, a precondition condition relationship should be created between quality attributes, and the following relationship among quality attributes is extracted.

1. Reliability can be satisfied when functionality is satisfied.

2. Usability can be satisfied when reliability is satisfied.

3. Usability can be satisfied when efficiency is satisfied.

4. Modularity is a prerequisite for reusability.

5. Modularity improves maintainability.

6. Portability is improved when reusability is satisfied.

By defining the relationship between the above quality attributes, the overlapped product characteristics among the quality attributes are attributed to one quality attribute, and the quality can be measured in the process based on the product characteristics for each quality attribute.

Description

Quality Management System Using Hierarchical Software Quality Model

The present invention relates to a software quality management method using a hierarchical software quality model. More specifically, the present invention is based on an ISO / IEC 9126 quality model, which is a use point of view, and is a hierarchical model in which a lower quality factor is not duplicated, and in a development process. A software quality management method that defines software quality models based on controllable product characteristics to measure and control product characteristics within a process. Generally, software is a generic term for various software used in computer systems. It is already well known that the descriptions and documents are generic to the processing procedures of computer systems, including (OS), compilers, assemblers, generators, subroutines, libraries, application software, and the like.

And even if a computer system having the same hardware is different software, as can be seen in performing a completely new operation, software is a very important technology for the operation of the computer system is a situation that requires the development of good software.

In order to develop such high quality software, measures for measuring the quality of software have been proposed, and software quality models for producing high quality software using these measures have been developed.

The Software Quality Model (SQM) is developed for two purposes, one for measuring software quality and the other for controlling software quality in the development process.

International standard ISO / IEC 9126 provides a software quality model for software measurement.

The ISO / IEC 9126 model defines software quality from the point of view of use and defines the scale based on the product's external behavior.

In this case, the external behavior of the product cannot be directly assessed within the development process and therefore cannot be used as a quality control criteria within the process.

Therefore, ISO / IEC 9126 is a model that can measure the quality characteristics of software after completing the software. However, in terms of quality control in the development processor, it is another model because it is impossible to see how the quality of software is made in the processor. Software quality models are needed from a development standpoint. Boehm's and McCall's quality models interpret quality attributes as product characteristics.

The above quality model has the advantage of being able to establish an objective and universal quality model by evaluating the quality based on the general characteristics of the software. It is difficult to respond directly to product characteristics, which makes it difficult to directly evaluate quality.

Therefore, it was difficult to use the results measured by the measures as verification values for software quality.

The present invention for solving the above-mentioned disadvantages is to establish a post-condition relationship between the quality attributes when constructing the software quality model, and then to provide a basis for mapping the overlapped product characteristics between the quality attributes to one quality attribute, Based on the ISO / IEC 9126 quality model, we define a software quality model that measures controllable product characteristics within the development process but does not overlap product characteristics for each quality attribute. Its purpose is to provide a software quality control method that enables measurement.

The software quality management method using the hierarchical software quality model of the present invention for achieving the above object is to redefine the software quality based on the product characteristics, and to make the hierarchical model with no sub-quality factors, so that the post-condition relationship between the quality attributes Should be presented.

There are six post-conditional relationships as follows.

Relationship between quality attribute and preconditions 1: Reliability can be satisfied when functionality is satisfied.

Functionality is the ability of the software to provide the stated or implied function. Reliability is the ability of the software to meet the performance level of the system. The reliability that defines this performance level is defined as the level of operation for a long time without functional impairments in a given environment. Therefore, the accuracy is high when the function is accurate, but the reliability is not satisfied when the function is satisfied. For example, even if the function is correct, a functional failure may be caused by an external error such as an incorrect input. In this case, the functionality is satisfied, but the reliability is not satisfied. Reliability includes functionality and the ability to maintain the system's performance level against external errors.

Quality attribute after condition Relationship 2: Usability can be satisfied when reliability is satisfied.

Usability is the ability of a user to understand, use and like when using, and refers to the quality of using. The premise is that the system must maintain a certain level of performance for this.

The reliability of the system is so low that if the system goes down or produces different results, the user's satisfaction can be intuitive.

Quality attribute after condition Relationship 3: Usability can be satisfied when efficiency is satisfied.

Efficiency is the ability to provide the required performance in terms of resource usage when using the software under specified conditions. Usability is the effort taken when used in conjunction with a user's personal assessment of the use, which can be defined as working time versus effective work.

In order to reduce the effort in use, the efficiency can be reduced before the efficiency is satisfied and the required timely response is obtained.

Therefore, efficiency must be satisfied first to ensure usability.

Quality attribute preconditions Relationship 4: Modularity is a precondition for reusability.

Reusability is the ability of software components to be reused. In order for part of the system to be reusable, the system must be basically modular.

It's only modular that it can be separated from the system.

Thus, modularity is a prerequisite for reusability.

Quality attribute Precondition Condition 5: Modularity improves maintainability.

Maintainability is the ability of the software to correct.

Substituting part of a system improves maintainability when there is little impact on the rest.

Therefore, maintainability is increased when the modular method, which is a prerequisite for reusability, is satisfied.

Quality attribute preconditions Relationship 6: Portability improves when reusability is satisfied.

The more modules available for porting to other environments among the reusable modules, the more portable they become.

1 is a schematic diagram showing the configuration of a software quality measure for evaluating quality with a general software measure.

2 is a schematic diagram showing the relationship between quality attributes for constructing a software quality model in accordance with an embodiment of the invention.

3 is a schematic diagram illustrating various software quality models for measuring software quality according to an embodiment of the present invention.

Figure 4 is a schematic diagram showing a procedure for applying the scale in the development process of the present invention.

Hereinafter, the present invention will be described in detail with reference to Examples.

FIG. 1 schematically illustrates the framework of a software quality model presented in IEEE 1061 for assessing quality on a software quality scale.

The software quality model is presented in the same manner as in FIG. 1, but each layer is expressed in different terms.

The terms are indicated next to the hierarchy of FIG. 1 and the same meanings are expressed in different terms, so a definition of the term is needed to unify them.

As shown in FIG. 1, software quality is defined as functionality, reliability, efficiency, usability, maintainability, portability, etc., which are characteristics of external behavior of the system. This is called a quality factor, a quality characteristic, and a quality attribute. In this embodiment, this is defined as a quality attribute, which is recognized by the user as a criterion when evaluating a product from the user's point of view. It is intended to represent the characteristics of the system behaviour.

On the other hand, the lower quality factor is a quality factor that is broken down into attributes of measurable software and is the basis for quantitatively measurable measures as factors related to production and design of quality. This is called criterion, primitive characteristics, internal properties, and sub-characteristics. In this embodiment, the sub-quality factor is expressed as a product property, which is a product. It can be measured directly or indirectly by itself and is defined as a factor that affects the behavior of the system.

Metrics are also used to measure software during development, and in this embodiment, metrics are defined as quantitative measures of what quality attributes a product can possess and show.

The quality attributes of the software product can be defined as the following seven.

The first is functionality, the ability of the software to provide the stated or implied functionality when using the software under specified conditions, the second is the reliability, the ability of the software to meet the performance levels of the system when using the software under specified conditions,

Third is efficiency, the ability of the software to provide the necessary performance with respect to the amount of support used when using the software under specified conditions,

Fourth, reliability is the ability of the software to enable users to understand, use and like when using the software under specified conditions.

Fifth is the maintainability, the ability of the software to modify,

Sixth is portability, the ability of software to port from one environment to another,

The seventh can be defined as seven of reusability, the ability of a component to be reused when using a software component in a new context of the system.

In order to satisfy these intimate relations with each other, we propose a postcondition relationship between the software quality attributes shown in FIG.

In order to create a hierarchical model in which software quality is redefined based on product characteristics and no sub-quality factors overlap, post-condition relations between quality attributes must be presented.

Relationship between quality attribute and preconditions 1: Reliability can be satisfied when functionality is satisfied.

Functionality is the ability of the software to provide the stated or implied function. Reliability is the ability of the software to meet the performance level of the system. The reliability that defines this performance level is defined as the level of operation for a long time without any functional impairment in a given environment. Therefore, accuracy is high when the function is correct.

However, if the functionality is satisfied, the reliability is not satisfied. For example, even if the function is correct, a functional failure may be caused by an external error such as an incorrect input. In this case, the functionality is satisfied, but the reliability is not satisfied. Reliability includes functionality and the ability to maintain the system's performance level against external errors.

Quality attribute after condition Relationship 2: Usability can be satisfied when reliability is satisfied.

Usability is the ability of a user to understand, use and like when using, and refers to the quality of using. The premise is that the system must maintain a certain level of performance for this.

The reliability of the system is so low that if the system goes down or produces different results, the user's satisfaction can be intuitive.

Quality attribute after condition Relationship 3: Usability can be satisfied when efficiency is satisfied.

Efficiency is the ability to provide the required performance in terms of resource usage when using the software under specified conditions. Usability is the effort taken when used in conjunction with a user's personal assessment of the use, which can be defined as working time versus effective work.

In order to reduce the effort in use, the efficiency can be reduced before the efficiency is satisfied and the required timely response is obtained.

Therefore, efficiency must be satisfied first to ensure usability.

Quality attribute preconditions Relationship 4: Modularity is a precondition for reusability.

Reusability is the ability of software components to be reused. In order for part of the system to be reusable, the system must be basically modular.

It's only modular that it can be separated from the system.

Thus, modularity is a prerequisite for reusability.

Quality attribute Precondition Condition 5: Modularity improves maintainability.

Maintainability is the ability of the software to correct.

Substituting part of a system improves maintainability when there is little impact on the rest.

Therefore, maintainability is increased when the modular method, which is a prerequisite for reusability, is satisfied.

Quality attribute preconditions Relationship 6: Portability improves when reusability is satisfied.

The more modules available for porting to other environments among the reusable modules, the more portable they become.

Due to the post-condition relationship between the quality attributes, the many-to-many relationship between the quality attributes and the product characteristics is changed into a one-to-many relationship so that the influence of the product characteristics on the quality attributes can be easily identified. For example, after applying the post-condition relationship of two quality attributes that accuracy was previously linked to both functionality and reliability, but only if the functionality is satisfied, the effect on reliability can be analyzed automatically. It becomes possible.

Therefore, the relationship between the overall product characteristics and quality becomes clear, so that the overall view of how to improve the quality by controlling the product characteristics can be integrated.

As shown in FIG. 3, the product characteristics included in the quality attribute do not overlap between the quality attributes due to the post-condition relationship between the quality attributes.

In addition, the method of applying the scale in the development process of the present invention comprises the steps of reinterpreting the quality attribute as the characteristics of the product, as shown in Figure 4,

Subdividing the product characteristics into characteristics of components;

Setting a scale based on the characteristics of the subdivided components;

Changing the general software property to the object-oriented property for the above-mentioned scale, replacing the existing scale with a more appropriate object-oriented measure,

By arranging components on the scale of the software to improve the quality, and by placing the software quality scale on the scale on which the components are arranged to complete the high-quality software can be developed.

The hierarchical software quality model does not overlap the product characteristics included in the quality attribute, so it is possible to verify the effect of the product characteristics on the quality. In this way, hierarchical software quality models provide a basis for analyzing the relationship between quality attributes and product characteristics.

The scale can be set based on the relationship between the product characteristics and the quality attributes, so that you know what aspects of quality improve when the scale is satisfied, making the scale clearer and easier to control software quality in the development process.

The hierarchical software quality model is a quality model that has the requirements as a quality model in the existing quality model and is easy to verify quality, and is suitable as a quality control model in the development process that satisfies the quality of the conventional ISO / IEC 9126.

In order to compare and analyze the hierarchical software quality model according to the present invention with the existing quality models of Boehm, McCall, ISO / IEC 9126, Dromey, quality analysis standards are established, and these quality models are analyzed as follows. .

In order to analyze the quality model, the analysis criteria are first determined based on the requirements of the quality model. In the present invention, as shown in Table 1, the analysis criteria of understanding, applicability, completeness, compatibility, non-redundancy, and measurement reflection are defined.

The above quality model must be understandable (understandable) by the quality defined and be applicable (applicable) to the quality model.

And in order to make quality understandable, the quality attributes of the software quality model must be complete (complete), compatible (compatible), and not redundant (non-redundant).

Integrity means that quality attributes must be gathered to make software quality complete, and compatibility means that there should be no conflicting quality attributes or product characteristics within the quality model. Non-redundancy means that product characteristics in the quality attributes should not overlap. It is necessary for quality quality to be directly mapped to product characteristics so that quality can be measured. Also, reflecting the results of the scale properly in the quality model (measurement of reflection) is a requirement for accurate quality model.

The hierarchical software quality model is compared with McCall, Boehm, ISO / IEC 9126, Dromey's quality model according to the analysis criteria of the above quality model.

In terms of understanding the quality model, the ideal quality model should be quality = quality factor = sub-quality factor = scale.

McCall, Boehm, ISO / IEC 9126, the hierarchical software quality model subdivides quality into quality factors and subdivides the quality elements into a set of scales, where each layer represents one aspect of quality, while Dromey represents product characteristics and quality attributes. Product characteristic classification, which is a link between, makes it difficult to interpret quality as product characteristics. From the standpoint of applicability of the quality model, it is necessary to be able to interpret the quality as product characteristics so that the quality model can be applied within the development process. Quality attributes are assessed based on the behavior of the finished system, but product characteristics are measurable within the development process.

McCall, Boehm, Dromey, and hierarchical software quality models all have product characteristics as the basis of the quality model, while the ISO / IEC 9126 quality model is user-specified in terms of quality. From the standpoint of quality model integrity, quality is defined as suitability for use, so a quality attribute defining quality should be able to represent all uses, but software is developed for a variety of uses, so quality Is defined differently.

All five quality models under discussion are quality models with quality subdivided into general quality attributes, so that the completeness cannot be guaranteed unless the characteristics of the system to be developed are reflected. When the quality attribute of R is improved, other quality attributes should not be degraded.

All five quality models discussed use almost similar quality attributes, and since these quality attributes do not show collisions with each other, all five quality models are compatible.

When quality attributes do not overlap with each other, quality can be defined directly by defining product attributes as product characteristics, which facilitates quality verification by measuring product characteristics. Existing models of McCall, Boehm and Dromey And quality attributes are overlapped, so if we set this as a subscale again, the relationship between scale and quality becomes more ambiguous. Therefore, it does not explain how the selected measure affects quality.

In the present invention, the hierarchical software quality model connects the relationship between the quality attributes and the product characteristics in a one-to-many relationship, and defines the scale as a detail in producing the product characteristics. Make it easy to see if it affects you.

Measurement reflection in the quality model evaluates the attributes of the software scale for accurate quality measurements.

ISO / IEC 9126 and the present invention vary the application of measurement techniques to quality attributes and measures, while McCall and Boehm measure that measurements are subjective and do not reflect the diversity of measurements.

For example, does a module, one of McCall's measures, have a single entry / exit? The question is different. A measure of this would reflect a more correct result of the proportion of modules with entry / exit of one of the modules rather than a yes / no answer.

Table 2 shows the results of comparing Boehm, McCall, ISO / IEC 9126, Dromey, and the hierarchical software quality model proposed in the present invention according to the analysis criteria of the software quality model.

Table 2 shows that the hierarchical software quality model can be applied in-process and solves the redundancy problem between quality attributes while having other requirements.

Therefore, according to the software quality management method using the hierarchical software quality model of the present invention, "1. Functionality can be satisfied to be reliable. 2. Reliability must be satisfied to be usable." 4. Usability is a prerequisite for reusability. 5. Modularity improves maintainability. 6. Portability improves when reusability is satisfied. " First, the concrete post-condition relations between the quality attributes defined in this section are established first, and then, the product characteristics overlapped between the quality attributes are attributed to one quality attribute, and the product characteristics are measured in the process, so that quality can be managed in the software development process. will be.

Claims (3)

In developing a software, the software quality management method for constructing a software quality model to measure quality, Software quality management method using hierarchical software quality model that introduces the postcondition relationship of propositional concept to define the relationship between quality attributes. The method of claim 1, wherein the overlapping product characteristics between the quality attributes are attributed to one quality attribute, and a hierarchical software quality model is provided for measuring the product characteristics in the process based on the product characteristics for each quality attribute. "Only when the functionality is satisfied can the reliability be satisfied, To be satisfied, reliability can be satisfied. The efficiency must be satisfied to ensure the usability, Modularity is a prerequisite for reusability, Modularity increases maintenance Software quality management method using hierarchical software quality model that introduces specific after-condition relationship between quality attributes defined by "and improves portability when reusability is satisfied." The method of claim 1, further comprising: reinterpreting the quality attribute as a product characteristic in the process of applying the scale in the development process to develop the software with high quality using the hierarchical software quality model, Subdividing the product characteristics into characteristics of components; Setting a scale based on the characteristics of the subdivided components; Changing the general software property to the object-oriented property for the above-mentioned scale, replacing the existing scale with a more appropriate object-oriented measure, Placing components on a scale of the software; Software quality management method using a hierarchical software quality model to proceed by the procedure consisting of placing a software quality measure on the scale on which the component is arranged.