An Activity-Centric Quality Model of Software

Abstract

In this paper, software activity, software activity instance, and the quality of the activity instance are defined as the 'activity which is performed on the software product by a person or a group of persons,' the 'distinctive and individual performance of software activity,' and the 'performer's evaluation on how good or bad his/her own activity instance is,' respectively. The representative values of the instance quality population associated with a product and its sub-population are defined as the (software) activity quality and activity quality characteristic of the product, respectively. The activity quality model in this paper classifies activity quality characteristics according to the classification hierarchy of software activity by the goal. In the model, a quality characteristic can have two types of sub-characteristics : Special sub-characteristic and component sub-characteristic, where the former is its super-characteristic too simultaneously and the latter is not its super-characteristic but a part of its super-characteristic. The activity quality model is parsimonious, coherent, and easy to understand and use. The activity quality model can serve as a corner stone on which a software quality body of knowledge, which constituted with a set of models parsimonious, coherent, and easy to understand and use and the theories explaining the cause-and-relationships among the models, can be built. The body of knowledge can be called the (grand) activity-centric quality model of software.

1. Introduction

This paper presents an activity quality model which is a direct extension of Koh and Koh’s [2018] activity-oriented usability model for software. Koh and his colleagues [Koh 2016, 2017a, 2017b; Koh and Jiang, 2017] define software activity as the activity which is performed on the software product by a person or a group of persons. Using, changing, and installing software products, for example, are important types of software activity. A software product should be good for various software activity types.

In this paper, the activity type and the activity instance are distinguished. Using, changing, developing, and installing, for example, will be used to denote types of software activity. Using instance, changing instance, developing instance, and installing instance, for example, will be used to denote the distinctive and individual performance of corresponding type of software activity. Rigorously expressing, whenever a person or a group of persons performs an activity on a software product to achieve distinctive and specific objectives, an activity instance is generated. For example, a specific individual’s playing a specific software game product or shopping on a specific internet shopping mall at some specific moment is a using instance.

The quality of something is can be defined as, according to Collins Cobuild Advanced Learner’s English Dictionary, ‘how good or bad it is.’1) Koh and Koh [2018] define the quality of a software product as ‘how product good or bad is the product?’ In this paper, the activity quality of a software product is defined as ‘‘how good or bad is the product for software activity?’

The goodness of a software product may vary by software activity type. Specifically, Koh and Koh [2018] define the usability of a software product as ‘how good a product is for being used’ or ‘goodness for using.’ This definition of usability is very simple and precise in sharp contrast with many existing definitions of other authors, for example, ISO/IEC SQuaRE (ISO/IEC 25000 Series, Systems and Software Quality Requirements and Evaluation).

Software quality is a very confusing concept. For example, some authors regard usability concerning user’s experiences [Gonzalez Sanchez et al., 2009b; Microsoft Corporation 2000; U.S. Department of Health and Humanity Services, 2017] while other authors regard it concerning the product itself [Herrera et al., 2010; ISO 9126-1, 9241-11, 25000 Series; Nielsen, 2016]. Koh and his colleagues [Koh, 2016, 2017a, 2017b; Koh and Jiang, 2017; Koh and Koh, 2018] combine these two approaches to define two types of usability : the usability instance as the goodness evaluated by the user him/herself of an individual using instance, and the product usability as the goodness of the product for using as a type of software activity. The product usability is get by aggregating all usability instances associated with a product.

In section 2, a classification model of software activity types is presented. In section 3, an activity software quality model is presented. The parts regarding using and usability in sections 2 and 3 correspond to those in Koh and Koh’s [2018] activity-oriented usability model of software. In section 4, the discussions for a more comprehensive software quality body of knowledge are presented. In section 5, the conclusions and suggestions for further research are presented.

2. Software Activity Model

In this paper, the sub-types of a software activity type (the super-type activity) are classified into two categories :

∙Special Sub-type : An activity instance of a special sub-type is an activity instance of the super type too.

∙Component Sub-type : An activity instance of a component sub-type is not a super-type activity instance, but a part of a supertype activity instance.

[Figure 1] shows an example of the classification of special sub-types of software activity. The criterion of the classification is the goal of the activity. The classification is not mutually exclusive. That is, it is possible to classify an activity instance to more than two types simultaneously. However, the level 1 classification is designed to be exhaustive. That is, it is possible to classify every activity instance into at least one type of level 1 properly.

[Figure 1] Level 1 and Level 2 Special Sub-Types of Software Activity

* (the type of stakeholder who performs the corresponding activity type).

** This part is the same as the corresponding part of Koh and Koh [2018].

It is noticeable that accessing is separated from using since accessing can occur independently with using : For example, A person may access a software product, for example, to test or study it, or customize its interface [Koh and Jiang, 2017].

It is also noticeable that learning, recognizing appropriateness and testing are absent in [Figure 1]. Testing is classified as a component sub-type of changing (refer [Figure 2]).

[Figure 2] Examples of Component Sub-Type of Using and Changing

* (the type of stakeholder who performs the corresponding activity type).

** This part is the same as the corresponding part of Koh and Koh [2018].

Learning and recognizing is not regarded as a type of software activity since they are generally used to denote mental phenomena which occur inside a person [Koh, 2017a]. For example, Oxford Learner’s Dictionary defines learning as ‘gaining knowledge or skill by studying, from experience, from being taught. On the other hand, studying or examining are usually used to denote a activity type that take time and efforts. Examining and studying are distinguished by their goals : learning about the product itself or some other things.

The classification in [Figure 1] is not mutually exclusive. For example, a person can interface with a software product both for using and examining the product.

Maintaining is one of the most confusing software terminologies. For a hardware product, maintaining is typically used to mean preserving and restoring its original state [Koh and Han, 2015; NF EN 13306 : 2001]. For a software product, however, maintaining is typically used to refer changing or modifying it [ANSI/IEEE Std. 729 : 1983; Boehm, 1981; IEEE Std. 1219 : 1998; ISO/IEC 14764 : 2006; Martin and Osborne, 1983]. GAO (The American General Accounting Office) and ANSI/ IEEE Std. 729 : 1983 define software maintenance to include virtually all changes made on a software product after its delivery. Although the definitions of these organizations are generally accepted as the standard definitions of software maintenance, some literatures define software maintenance as a special type of software modification or change [Abran and Nguyenkim, 1993; Chaptin et al., 2001; Hatton, 2007; Hunt et al., 2008; ISO/ IEC 14764 : 2006; Koh and Han, 2015; Martin and Osborne, 1983; Sneed, 2004]. It is one of the most important causes of the chaos in the literature and practice regarding software maintenance to use the term ‘software maintenance’ without mentioning its scope explicitly [Chaptin et al., 2001; Koh and Han, 2015; Seed, 2004]. Here, maintaining is used to mean preserving the initial installed state of the product and do not involve changing the source code of the product.

Changing in this paper denotes changing a software product after its delivery. Changing during the development phase is not included in the ‘changing.’ Changing userinterface, data-interface, data processing, and architecture are special types of changing. Special sub-types of changing may be classified otherwise. For example, Koh and Han [2015] classify the post life cycle changes of software classify into modification, enlargement, replacement, and retirement. It is beyond the scope of this paper, however, to classify the special sub-types of changing rigorously. The goal of this section is to present a satisfactory practical example of the classification of software activity.

[Figure 2] shows examples of component sub-type of using and changing. Especially, the component sub-types of using are intended to be exhaustive and mutually exclusive. That is, every atomic activity of a using instance can and should be classify into one and only one of them. Those of changing are not intended to be so rigorous. Especially, testing is generally not performed against the current product, but generally performed against the altered product. So, it may improper to define testing as the software activity that is performed to the (current) software product.

3. Goodness of a Software Product

In this paper, the representative values of the instance quality population associated with a product and its sub-population are defined as the (software) activity quality and activity quality characteristic of the product, respectively. Koh and Koh’s [2018] usability corresponds to the population of usability instances associated with a software product.

According to Oxford online dictionary, the suffix ‘-ability’ means ‘the quality of being able to be or having to be’ or ‘the fact of having the quality mentioned.’ According to this principle, for example, usability can be used to mean ‘the quality of being able to be used,’ ‘how good it is to be used,’ or ‘goodness for using.’ [Koh and Whang, 2016; Koh and Jiang, 2017; Koh and Koh, 2018]. Applying this naming scheme, the activity quality characteristics associated with software activity types on [Figure 1] can be defined as in [Figure 3] Koh and Whang’s [2016] ‘-ability’ principle can be rephrased as the following.

[Figure 3] Level 1 and Level 2 Special Characteristics of Software-Activity Quality Model

* (The type of stakeholder who performs and evaluate the corresponding activity instance; Object of evaluation).

** This part is the same as the corresponding part of Koh and Koh [2018].

∙Activity quality naming principle : The suffix ‘-ability’ can be attached to and only to software activity type to denote the corresponding activity quality characteristics.

As activity types, an activity quality characteristic can have two types of sub-characteristics :

∙Special sub-characteristic : The sub-characteristic of this type is its super-characteristic simultaneously.

∙Component sub-characteristic : The subcharacteristic of this type is not its supercharacteristic simultaneously. The aggregation of sub-characteristic of this type can be used as the super characteristic.

[Figure 4] shows the component sub-characteristics of usability and change-ability corresponding to their component sub-types. It will provide much richer and more reliable data to measure the component sub-characteristics and to aggregate them than to measure the usability or change-ability directly [Koh and Koh, 2018].

[Figure 4] Component Sub-Characteristics of Usability and Change-Ability

* This part is the same as the corresponding part of Koh and Koh [2018].

Significant special sub-characteristics of an activity quality characteristic can be measured and aggregated to be the activity quality characteristic. It also will provide much richer and more reliable information than to measure the activity quality characteristic directly. For example, study-ability and play-ability can be measured respectively and aggregated to usability for an educational game product [Koh and Koh, 2018]. If play-ability is turned out to be low relatively to study-ability, then effort can be devoted chiefly into enhancing entertainingness.

4. Discussions

Koh and his colleagues [Koh, 2017a, 2017b; Koh and Jiang, 2017; Koh and Koh, 2018] have proposed a model of the view (refer [Figure 5]) and quality view and principles regarding software quality :

∙Principle of one view : A software quality model should correspond to one and only one software quality view.

∙Principle of Parsimony : The quality characteristic should be defined as brief and precise as possible.

∙Principle of Cohesiveness : The quality characteristic should consist of elements that fit together well and form a united whole.

∙Principle of Inheritance : Every aspect of usability should be able to be inherited by its special sub-characteristics, possibly, with proper specializations.

[Figure 5] Koh and Jiang's [2017] Model of Software Quality View

The activity software quality model in section 3 abides by all the four principles. Specifically, it corresponds to the ‘performer’s view on software activity’ in [Figure 5]. As the result, the activity quality model is parsimonious, coherent, and easy to understand and use.

Most of existing software quality model violate the principle of one view. For example, SQuaRE suffers from ambiguity, inconsistency, and contradictions in the definitions of quality characteristics and sub-characteristics, making it un-suitable to measure the design quality of software product [Al-Kilidar, 2005; Haboush et al., 2014; Kitchenham and Pfleeger, 1996; Koh, 2017a; 2017b; Koh and Jiang, 2017; Koh and Whang, 2016].

Koh [2017] reclassifies 86 measures which belong to 8 characteristics (31 sub-characteristics) into 7 categories (15 sub-categories) : Data processing (valid; correct; efficient), data interface, user interface (information providing, data inputting; process controlling; presentation, appearance & composite), composite, software engineering (diagnosis and testing; architecture; coding), system (capacity; runtime behavior; operation management), activity view (developing & maintaining; installing) (refer [Table 1]). The result shows the fundamental reason of SQuaRE’s problems : The items related with end and means exist mixed unsystematically in a model (refer [Table 1] and [Table 2]). For example, usability of a product is influenced by data processing of the product and the system on which the product is operated as well as by user interface of the product. Usability is indirectly influenced by data interface of the product too. In SQuaRE, only the items related to user interface are classified into usability, implying implicitly that usability is influence only by user-interface.

[Table 1] Koh’s [2017a] Classification of the Measures of SQuaRE’s Product Quality Model

The sub-characteristic to which the measures in the parenthesis belong. For the abbreviation, refer [Table 2]​​​​​​​

[Table 2] Correspondence between the Activity Quality Model and the Product Quality Model of SQuaRE

* Abbreviation of characteristics (sub-characteristics) : For example, CCo means ‘Co-existence of Compatibility.

C (Co, In) = Compatibility (Co-existence, Interoperability),

E (Ca, Ru, Tb) = Performance Efficiency (Capacity, Resource utilization, Time behavior)

F (Ap, Cp, Cr) = Functional suitability (Functional appropriateness, Functional completeness, Functional correctness),

M (An, Md, Mo, Re, Te) = Maintainability (Analyzability, Modifiability, Modularity, Reusability, Testability),

P (Ad, In, Re) = Portability (Adaptability, Install-ability, Replaceability),

R (Av, Ft, Ma, Re) = Reliability (Availability, Fault tolerance, Maturity, Recoverability)

S (Ac, Au, Co, In, No) = Security (Accountability, Authenticity, Confidentiality, Integrity, Non-repudiation),

U (Ac, Ap, Ep, In, Le, Op) = Usability (Accessibility, Appropriateness recognizability, User error protection, User interface aesthetics, Learnability, Operability)

i. All the items belong to Developing & maintaining in [Table 5]. It is noticeable these items are related to change-ability too.

ii. Installing

iii. Operation management (including ease of installation only; It belongs to PIn in SQuaRE)

iv. Excluding product quality equivalence, usage similarity.

v. Operation management (excluding ease of installation).

vi. Including usage similarity only; It belongs to PRe in SQuaRE.

vii. Information providing (excluding monitoring capability), presentation, appearance, & composite (including appearance consistency only; It belongs to UOp in SQuaRE)

viii. Capacity (including redundancy of component, user access capacity, user access increase adequacy only; They belong to RFt, ECa, ECa in SQuaRE, respectively), runtime behavior (excluding system log completeness, mean fault notification time).

ix. Capacity (Excluding redundancy of component, user access capacity, user access increase adequacy), time behavior (including system log completeness, mean fault notification time only; They belong to MAn, RFt in SQuaRE, respectively).

x. Excluding the measures that is related to examinability.

xi. Including product quality equivalence only which belongs to PRe in SQuaRE

Moreover, among 86 measures of the product quality model, only 21 measures are intrinsic [Koh, 2017b]. This means that the product quality model does not provide sufficient information for software engineers to improve the activity quality. It is the intrinsic quality attributes that software engineers can control to improve the activity quality. The contingency quality attributes are influenced many factors other than the product, which software engineers cannot control. More intrinsic quality attributes should be identified to complete a separate intrinsic quality model of software. The model should conform to the principles suggested above.

The quality model subjects to contingency view, third party’s view, and long-term view respectively should be developed too. They should confirm to the principles suggested above. The theories to explain the cause-andeffect relationships among the models should be developed too. The theories and the models will constitute a software quality body of knowledge which will guide development, use, and post life cycle changes of software.

5. Conclusions

The activity quality model in this paper is a direct extension of Koh and Koh’s [2018] activity-oriented usability model for software. It has 7 characteristics, developability, operateability, examinability, access-ability, usability, changeability, and retire-ability, which correspond to developing, operating, examining, accessing, using, changing, and retiring, respectively. They are designed to be exhaustive and mutually exclusive.

A quality characteristic can have two types of sub-characteristics : Special sub-characteristic and component sub-characteristic, where the former is its super-characteristic too simultaneously and the latter is not its super-characteristic but a part of its supercharacteristic. For example, usability has workability, study-ability, and play-ability as its special sub-characteristics. This classification of special sub-characteristics of usability is really an example and is meant to be neither exhaustive nor mutually exclusive. Usability has navigate-ability, data-prepare-ability, datainput-ability, response-wait-ability, outputexamine-ability, and output-utilize-ability as its component sub-characteristics. They are meant to be exhaustive and mutually exclusive. The activity quality (sub-)characteristic is defined as ‘‘how good or bad is the product for the corresponding software activity?’ or, shortly, ‘goodness for the corresponding software activity.’

The activity quality model is parsimonious, coherent, and easy to understand and use. The activity quality model can serve as a corner stone on which a software quality body of knowledge, which constituted with a set of models parsimonious, coherent, and easy to understand and use and the theories explaining the cause-and-relationships among the models, can be built. The body of knowledge can be called the (grand) activity-centric quality model of software. To be so, the quality models which are subjects to contingency view, third party’s view, and long-term view respectively should be developed. They should confirm to the principles of one view, parsimony, cohesiveness, and inheritance. The theories to explain the cause-and-effect relationships among the models should be developed thereafter.