For software organizations often performing measurement, evaluation (ME), and even change/improvement (MEC) projects, a wellestablished quality evaluation approach can be useful. In this direction, we have developed a holistic quality evaluation approach whose architecture is based on two pillars, namely: a quality multi-view modeling framework, and ME/MEC integrated strategies. In this paper, we specify the conceptual base for the former pillar. Specifically, we specify an ontology of quality views documenting its main terms, properties and relationships. Quality views are paramount for selecting evaluation strategies and strategy patterns to be assigned as resources to ME/MEC projects. Also, we show how this ontology is semantically linked with the previously built ME domain ontology.
For those software organizations that frequently perform quality assurance activities devoted to measurement, evaluation, and change/improvement projects, a wellfounded quality evaluation approach can be useful. In this direction, we consider that counting with a holistic quality evaluation approach can help software organizations to reach the planning and performing of measurement, evaluation and change project goals in a systematic and disciplined way. So, clear ME/MEC project goals should be established, e.g. ‘understand the usability of the XYZ mobile application’. In order to achieve this goal, a strategy with well-established activities and methods for performing ME actions should be selected. For choosing the suitable strategy from a set of strategies, the target quality view must be taken into account. A quality view relates accordingly an entity super-category, e.g., product, system, system in use, with a quality focus such as internal quality (IQ), external quality (EQ), and quality in use (QinU). To fulfill the project goal for the given example, the underlying quality view is the System Quality View, where System is the entity super-category to be evaluated regarding the EQ focus and the Usability characteristic.
In the last years, we have developed a holistic quality evaluation approach [
Thus, the major contributions of this work are: (i) Specify an ontology of quality views; (ii) Relate the quality view terms with the ME ontology terms; and (iii) Discuss its applicability for selecting strategy patterns in ME/MEC projects.
The remainder of this paper is organized as follows. Section 2 specifies the ontology of quality views, which extends the conceptual base of our holistic quality evaluation approach. Section 3 stresses the practical impact of the quality multi-view framework when selecting strategy patterns for specific project goals. Section 4 describes related work and, finally, Section 5 outlines conclusions and future work. 2
As commented previously, the architecture of our holistic quality evaluation approach is built on two pillars: a quality multi-view modeling framework and ME/MEC integrated strategies. Next, we describe the quality multi-view modeling framework pillar considering the proposed ontology for the domain of quality views.
The ISO 25010 standard [
It is worthy to remark that an ontology is a way for structuring a conceptual base
by specifying its terms, properties, relationships, and axioms or constraints. A
wellknown definition of ontology says that “an ontology is an explicit specification of a
conceptualization” [
Regarding the above classification, our proposed ontology can be considered
rather a domain ontology since its terms, properties and relationships are specific to
the quality area. However, some terms like entity super-category can be considered
generics. Fig. 1 depicts the quality views ontology using the UML class diagram [
One core term in this ontology is Calculable-Concept View. This term relates the
Entity Super-Category term with the Calculable-Concept Focus term. An Entity
Super-Category is the highest abstraction level of an Entity Category to be
characterized for measurement and evaluation purposes. On the other hand, a
Calculable-Concept Focus is a Calculable Concept that represents the root of a
Calculable-Concept Model, e.g., a quality model such as the EQ or QinU models
prescribed in [
Fig. 1 shows that instances of Entity Super-Category are Software Product, System, Process, amongst others. On the other hand, a Calculable-Concept Focus for the quality domain is named Quality Focus. Considering other domains like the cost area, Cost Focus is other type of Calculable-Concept Focus. Some instances of Quality Focus are for example Internal Quality, External Quality and Quality in Use. In Table 1 we define Internal Quality as “the quality focus associated to the software product entity super-category to be evaluated”, External Quality is defined as “the quality focus associated to the system entity super-category to be evaluated”, and Quality in Use as “the quality focus associated to the system-in-use entity supercategory to be evaluated”.
The relation between an instance of a Quality Focus and its associated instance of an Entity Super-Category derives in a key concept of the ontology, viz.: Quality View. A Quality View is a Calculable-Concept View for quality. Instances of the Quality View term are Software Product Quality View, System Quality View, Systemin-Use Quality View, Resource Quality View and Process Quality View, being all of them represented in Fig. 1. (Note that another instance is for example the Service Quality View which is not shown in Fig. 1).
Fig. 2 shows the influences and depends on relationships between instances of quality views which are commonly present in development, evaluation and maintenance projects. E.g., the Resource Quality View influences the Process Quality View. That is, if a development team uses a new tool or method – both considered as entities of the Resource Entity Super-Category- this fact impacts directly in the quality of the development process they are carrying out. In turn, the Process Quality View influences the Software Product Quality View. The Product Quality View influences the System Quality, and in turn this influences the System-in-Use Quality View. The depends on relationship has the opposite semantic. Note that more quality views than those depicted in Fig. 2 can be derived from Fig. 1. E.g., the Process Quality View that influences the Service Quality View could be represented. In Section 3, we discuss the utility of having well-defined quality views and relationships.
Definition Abstract relationship between attributes of entity categories and information needs. Note 1: A Calculable Concept, usually called characteristic, represents a combination of measurable attributes.
Therefore a characteristic can be evaluated but cannot be measured as an attribute. Note 2: A characteristic can have subcharacteristics.
Highest abstraction level of a root calculable concept associated to one entity super-category to be evaluated.
The set of calculable concepts and the relationships between them, which provide the basis for specifying the root calculable-concept requirements and their further evaluation. Note 1: A possible instance of a Calculable-Concept Model is the ISO 25010 Qualityin-use Model.
Relationship of highest abstraction level between one calculableconcept focus and one entity super-category. Note 1: Names of calculable-concept views are Quality View, Cost View, among others.
Object category that is to be characterized by measuring its attributes.
Highest abstraction level of an entity category of value to be characterized and assessed in Software Engineering organizations.
Note 1: Names of entity super-categories are Resource, Process, Software Product, System, System in use, among others.
It is the quality focus associated to the system entity super-category to be evaluated.
It is the quality focus associated to the software product entity super-category to be evaluated.
It is the entity super-category which embraces work definitions.
It is the quality focus associated to the process entity supercategory to be evaluated.
It is the quality view that relates the process quality focus with the process entity super-category.
It is a calculable-concept focus for quality.
It is the quality focus associated to the system-in-use entity supercategory to be evaluated.
It is a calculable-concept view for quality.
It is the entity super-category which embraces assets that can be assigned to processes, activities and tasks. Note 1: Examples of assets are Tool, Strategy, Software team, etc.
It is the quality focus associated to the resource entity superResource Quality View Software Product Software Product Quality View System System in Use System-in-Use Quality View System Quality View category to be evaluated.
It is the quality view that relates the resource quality focus with the resource entity super-category.
It is the entity super-category which embraces software programs (i.e., source codes), specifications (i.e., requirements specifications, architectural specifications, data specifications, testing specifications, etc.), and other associated documentation.
It is the quality view that relates the internal quality focus with the software product entity super-category.
It is the entity super-category which embraces software programs (i.e., applications) running in a computer environment, but not necessarily in the final environment of execution and usage.
It is the entity super-category which embraces operative software applications used by real users in real contexts of use.
It is the quality view that relates the quality in use focus with the system-in-use entity super-category.
It is the quality view that relates the external quality focus with the system entity super-category.
Definition A calculable-concept view depends on other calculable-concept view.
A calculable-concept view influences other calculable-concept view.
An entity category can be classified into an entity super-category.
A calculable-concept view can be represented by one or several calculable concept models.
The quality views ontology shares some terms with the previously developed ME
ontology [
Ultimately, Fig. 3 shows the added component –which includes those yellow-colored key terms in Fig. 1- and its linking with the non-functional component, which is one component of the C-INCAMI conceptual framework. Note also that in Fig. 1 the terms belonging to the component are green colored as in Fig. 3. 3
It is well-known that ontologies are widely used for different purposes [
A strategy pattern can be seen as a general reusable solution to recurrent problems within given measurement, evaluation and change/improvement situations for specific projects' goals. So, in the following paragraphs, we analyze some strategy patterns that can be defined considering the type of ME/MEC project goal (e.g. understand, change/improve) and the type and amount of quality views that can intervene (recall Fig. 2), which can be one or more. It is worthy to remark that the quality views ontology plays a central role in defining strategy patterns. That is, without a clear specification of the terms and relationships for quality views, the ulterior specification of strategy patterns could not be done appropriately. Specifically, the quality views ontology fosters the specification and selection of appropriate strategy patterns and their instantiation regarding different ME/MEC project goals.
Usually, strategy patterns are documented by templates. In a previous work [
As above mentioned, a strategy pattern must be selected according to the type of
ME/MEC project goal and the amount of involved quality views. In this sense, we
distinguish at least a set of six strategy patterns. Reassuming the example commented
in the Introduction, viz. ‘understand the usability of the current state of the XYZ
mobile application’, the ME project goal has an "understand" purpose embracing the
System Quality View (i.e., the Entity Super-Category is System and the Quality Focus
is EQ, where the concrete Entity is the "XYZ mobile application"). Therefore, a
strategy pattern that considers just one quality view for ME should be selected. In
[
On the other hand, if the project involves MEC goals but for two quality views
then the GOCAMEC_2V strategy pattern should be chosen. This strategy pattern
addresses the fact that improving one quality view from other quality view is
supported thanks to the influences and depends on relationships between quality
views. As can be seen in Fig. 2, the System Quality View influences the
System-inUse Quality View, hence by evaluating and improving the EQ Focus of a System is
one means for improving the QinU Focus of a System in Use. Conversely, evaluating
the QinU can provide feedback to improve the EQ by exploring the depends on
relationship. A concrete strategy derived from this pattern is the so-called SIQinU
(Strategy for Improving Quality in Use). This strategy allows improving QinU from
the EQ standpoint, as documented in the industrial case presented in [
The GOCAMEC_2V strategy pattern can also be instantiated for other two related quality views. For example, looking at Fig. 2 in which the resource quality (e.g., a new integrated tool) influences the process quality (e.g., a development process) and the process quality depends on the resource quality, GOCAMEC_2V should be instantiated respectively for Resource and Process Quality Views.
Furthermore, regarding the mentioned relationships between views, strategy patterns where three quality views intervene can be instantiated. For instance, we can mention the GOCAMEC_3V strategy pattern where the Software Product, System and System-in-Use Quality Views can be considered.
In summary, the modeling of many quality views and their relationships foster developing a family of patterns. Patterns are essentially ‘experience in a can’, to our case, ready to be opened and used by evaluators in quality assurance processes. 4
In the literature review made about the few works that deal with the domain of
quality views, we have observed there is no research defining a quality views
ontology, nor an explicit glossary of terms. One of the most relevant works
previously mentioned is the ISO 25010 standard [
Other initiative related to quality views is [
Lastly, we can mention the 2Q2U (Internal/External Quality, Quality in Use,
Actual Usability, and User experience) quality framework [
In summary, there are no related works for the definition and specification of an
ontology of quality views. Moreover, there is no research that relates quality views'
terms with non-functional requirements' terms as we documented in Section 2.
However, there exists research about ontologies in software measurement, e.g., the
Software Measurement Ontology (SMO) [
Finally, having well-defined quality views and their relationships provides the basis for a more robust selection of strategy patterns for ME/MEC project goals (as commented in Section 3) and also contributes to enhance our quality evaluation approach. 5
As commented in the Introduction Section, the architecture of our holistic quality evaluation approach is built on two columns: (1) a quality multi-view modeling framework, and (2) ME/MEC integrated strategies. One discussed contribution in this work is the specification of the ontology of quality views, aimed at adding robustness to our approach. To build this ontology we have reviewed the related literature to the quality views domain. Specifically, we have observed that there is no such an ontology, taxonomy or glossary for this domain.
Note that in this paper, we have addressed the ontology representation and a
possible instantiation of it rather than the ontology construction process itself.
Nevertheless, the stages proposed in the METHONTOLOGY [
Regarding the third stated contribution, we have analyzed in Section 3 the importance of having well-defined quality views and their relationships with the aim of defining and selecting strategy patterns for different ME/MEC project goals.
As future work, we envision the development of a strategy pattern recommender system as a practical use of the quality views ontology in the context of the holistic quality evaluation approach. This system can be useful when an organization establishes a ME/MEC project goal. So, taking into account the type of project goal and the amount of involved quality views, the strategy pattern recommender system will suggest the suitable strategy pattern that fits that goal.