See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/260843577

Mapping Between ISO 9126 on Software Product Quality Metrics and ISO 12207
on Software Life Cycle Processes

Conference Paper · June 2006

CITATION READS

1 2,266

2 authors:

Rafa E. Al-Qutaish Hamed Fawareh

Zarqa University
66 PUBLICATIONS 895 CITATIONS
35 PUBLICATIONS 369 CITATIONS
SEE PROFILE
SEE PROFILE

All content following this page was uploaded by Rafa E. Al-Qutaish on 18 March 2014.

The user has requested enhancement of the downloaded file.

 MAPPING BETWEEN ISO 9126 ON SOFTWARE PRODUCT QUALITY
METRICS AND ISO 12207 ON SOFTWARE LIFE CYCLE PROCESSES

RAFA E. AL-QUTAISH HAMED J. AL-FAWAREH

École de Technologie Supérieure (ÉTS) Dept. of Computer Science
University of Québec Zarqa Private University
1100 Notre-Dame St., Montréal, QC, H3C 1K3, P. O. Box 2000, Zarqa 13110,
Canada Jordan
rafa.al-qutaish.1@ens.etsmtl.ca fawareh@zpu.edu.jo

ABSTRACT
Nowadays, the International Organization for Standardization (ISO) is working on the next generation of the software
product quality standards which will be referred to as Software Product Quality Requirements and Evaluation (SQuaRE
– ISO 25000 series). However, this series of standards will replace the current version of ISO 9126 International
Standard which consists of inventories of proposed metrics to measure the quality of the internal, external, and in-use
software product. For each of these metrics there is a cross-reference on where they could be applied (measured) during
the ISO 12207 Software Life Cycle Processes and activities (SLCP). This paper provides a mapping between those two
standards to highlights the weaknesses of these cross-references and proposes a number of suggestions to address them.

Keywords: Software Measurement, Software Quality Metrics, Software Life Cycle Processes (SLCP), ISO 9126, ISO
12207.

1. INTRODUCTION The definition of a “measure” is an empirical

Measurements have a long tradition in natural sciences. objective assignment of a number or a symbol to an
At the end of the 19th century the physicist, Lord entity to characterize a specific attribute [6]. Moreover,
Kelvin, formulated the following about measurement: Ince et al. [11] have defined the software “metrics” as
“When you can measure what you are speaking about, numerical values of quality which can be used to
and express it into numbers, you know some thing about characterized how good or bad that the product is in
it. But when you can not measure it, when you can not terms of properties such as its proneness to error. In
express it in numbers, your knowledge is of a meager Addition, “metrics” defined in [10] as quantitative
and unsatisfactory kind: It may be the beginning of measures of the degree to which a system, component,
knowledge, but you have scarcely in your thoughts or process possesses a given attribute, while within the
advanced to stage of science” [20]. ISO 15939, it was defined as a variable to which a value
is assigned as a result of measurements [15].
Moreover, Roberts [21] points out in his book about
measurement theory that: “A major difference between In order to standardize the software product quality
well-developed sciences such as physics and some of the measurement process, in 1991, the ISO published its
less well-developed sciences such as psychology or first international consensus on the terminology for the
sociology is the degree to which things are measured”. quality characteristics for software product evaluation;
this standard was called as Software Product Evaluation
In the area of software engineering, the concept of - Quality Characteristics and Guidelines for Their Use
software measurement (or what is commonly called (ISO 9126: 1991) [14].
software “metrics”) is not new. Since 1972, a number of
so-called software “metrics1”, or “measures”, have been From 2001 to 2004, the ISO published an expanded
developed. From the wide range of software measures, version, containing both the ISO quality models and
four basic theories have been the source of the majority inventories of proposed measures for these models (ISO
of the research conducted on software measurement. 9126 parts 1, 2, 3, and 4) [12, 16-18].
Some of these measures have been defined by Halstead
[7, 8], Albrecht [3], DeMarco [5], and McCabe [19]. Recently, the ISO has recognized a need for further
enhancement of ISO 9126 International Standard,
primarily as a result of advances in the fields of
1
While the term “metrics” is used in ISO 9126, the use information technologies and changes in environment
of this term will be abandoned and replaced by [4]. Therefore, the ISO is now working on the next
“measures” in the upcoming new ISO 25000 as an generation of software product quality standards [22],
initial step towards harmonizing the software which will be referred to as Software Product Quality
engineering measurement terminology with the ISO Requirements and Evaluation (SQuaRE – ISO 25000
15939. [11] series). This series of standards will replace the current
ISO 9126 International Standard. However, many 2. RELATED SOFTWARE
researches have focused on some weaknesses on the
current ISO 9126 and even on the draft versions of the
ENGINEERING ISO STANDARDS
upcoming new ISO 25000 series of standards (SQuaRE) 2.1 ISO 9126
[1, 2]. The ISO 9126 series of standards now consists of one
International Standard [12] and three Technical Reports
The current version of the ISO 9126 consists of [16-18]:
inventories of proposed metrics to measure the quality 1. ISO 9126-1: Quality Model [12].
of the internal, external, and in-use software product. 2. ISO TR 9126-2: External Metrics [16].
However, for each of these metrics there is a cross- 3. ISO TR 9126-3: Internal Metrics [17].
reference on where they could be applied (measured) 4. ISO TR 9126-4: Quality in Use Metrics [18].
during the ISO 12207 Software Life Cycle Processes
and activities (SLCP). This paper provides a mapping The first document of the ISO 9126 series – Quality
between these two standards to highlights the Model – contains two-parts quality model for software
weaknesses of these cross-references and proposes a product quality [12]:
way to address them. 1. Internal and external quality model.
2. Quality in use model.
This paper is organized as follows: section 2 presents
an overview of the related software engineering The first part of the two-parts quality model
standards, that is, ISO 9126 and ISO 12207. Section 3 determines six characteristics in which they are
shows a detailed mapping of the ISO 9126 metrics to subdivided into twenty-seven subcharacteristics for
where they could be measured during the Software Life internal and external quality, as in Figure 1 [12]. These
Cycle Processes (SLCP) provided by ISO 12207. subcharacteristics are a result of internal software
Section 4 discusses the results of this mapping. Finally, attributes and are noticeable externally when the
Section 5 concludes the paper with some comments and software is used as a part of a computer system. The
suggestions. second part of the two-part model indicates four quality
in use characteristics, as in Figure 2 [12].

External and Internal Quality

1. Functionality 2. Reliability 3. Usability 4. Efficiency 5. Maintainability 6. Portability

1.1 Suitability 2.1 Maturity 3.1 Understandability 4.1 Time 5.1 Analyzability 6.1 Adaptability
1.2 Accuracy 2.2 Fault 3.2 Learnability Behavior 5.2 Changeability 6.2 Installability
1.3 Interoperability Tolerance 3.3 Operability 4.2 Resource 5.3 Stability 6.3 Co-existence
1.4 Security 2.3 Recoverabilit 3.4 Attractiveness Utilization 5.4 Testability 6.4 Replaceability
1.5 Functionality 2.4 Reliability 3.5 Usability 4.3 Efficiency 5.5 Maintainability 6.5 Portability
Compliance Compliance Compliance Compliance Compliance Compliance

Figure 1: ISO 9126 Quality Model for External and Internal Quality (Characteristics and Subcharacteristics) [12].

Quality in use

1. Effectiveness 2. Productivity 3. Safety 4. Satisfaction

Figure 2: ISO 9126 Quality Model for Quality in Use (characteristics) [12].

The second, third, and fourth documents of the ISO 2.2 ISO 12207
9126 series provide the following information [16]: It consists of processes, activities for each process, and
1. Sets of metrics for each external quality sub- tasks for each activity [9, 13]. Figure 3 shows the
characteristic, internal quality sub- software life cycle processes, the number of activities in
characteristic, and quality in use each process, and the number of tasks in each process.
characteristic. The full list of the process, activities, and tasks can be
2. Explanations of how to apply and use these seen in ISO 12207 and IEEE/EIA 12207 (the IEEE/EIA
sets of metrics. 12207 is the IEEE version of the ISO 12207).
3. Examples of how to apply these metrics
during the software product lifecycle.
 The ISO 12207 software life cycle processes are verification, validation, and problem resolution. A
grouped into three broad classes: primary; supporting; supporting process supports another process in
and organizational. Primary processes are the prime performing a specialized function. Organizational
movers in the life cycle; they are acquisition, supply, processes are management, infrastructure,
development, operation, and maintenance. Supporting improvement, and training. An organization may
processes are documentation, configuration employ an organizational process to establish, control,
management, quality assurance, joint review, audit, and improve a life cycle process.

Groups Processes Number of Number of

Activities Tasks

5. 5.1 Acquisition 5 23
Primary 5.2 Supply 7 24
Processes
5.3 Development 13 55
5.4 Operation 4 9
5.5 Maintenance 6 24

6. 6.1 Documentation 4 7
Supporting 6.2 Configuration Management 6 6
Processes
6.3 Quality Assurance 4 16
6.4 Verification 2 13
6.5 Validation 2 10
6.6 Joint Review 3 8
6.7 Audit 2 8
6.8 Problem Resolution 2 2

7. 7.1 Management 5 12
Organizational 7.2 Infrastructure 3 5
Processes
7.3 Improvement 3 6
7.4 Training 3 4

Figure 3: ISO 12207 Software Life Cycle Processes, Activities, and Tasks.

3. MAPPING BETWEEN ISO 9126 be provided. In more details, this mapping will focus on
an investigation of the “ISO 12207 Software Life Cycle
AND ISO 12207 Processes (SLCP) References” provided by ISO 9126
For each metric of the internal, external, and in-use for each of its metrics.
metrics, the ISO 9126 parts 2, 3, and 4 provides the
following information:
ƒ Metric name. 3.1 INTERNAL QUALITY METRICS
ƒ Purpose of the metric. Within the ISO 9126-3 on software product internal
ƒ Method of application. quality metrics, there is 70 metrics. These metrics can
ƒ Measurement formula. be applied during the software life cycle. Internal
ƒ Interpretation of Measured value. quality defined in ISO 9126-1 as the totality of
ƒ Metric scale type. characteristics of the software product from an internal
ƒ Measure type. view. Internal quality is measured and evaluated against
ƒ Input to measurement. the internal quality requirements. Details of software
ƒ ISO 12207 SLCP Reference. product quality can be improved during code
ƒ Target audience. implementation, reviewing and testing, but the
fundamental nature of the software product quality
Within the following subsections, detailed mappings represented by internal quality remains unchanged
between the ISO 9126 quality metrics of the Internal, unless redesigned [12].
external, and in-use software product and the ISO
12207 software life cycle processes and activities will Figure 4 shows the number of internal quality
metrics which can be applied (measured) during each of
the ISO 12207 software life cycle processes. For However, from Figure 4 we can note that there is no
example, within the “verification process” (of the metrics which could be measured during 4 out of 5
“supporting processes”) 59 metrics can be applied primary life cycle processes. This means that there is no
(measured). As an example, Appendix A shows a any metric from ISO 9126 external quality metrics
detailed structure of the software product internal could be useful during the acquisition, supply,
quality metrics’ names and where they can be measured operation, and maintenance primary life cycle
during the software life cycle processes or activities processes. Moreover, there is no metrics which could be
along with the corresponding characteristic and measured during 3 out of 8 of the supporting life cycle
subcharacteristic for each of those metrics. In this processes; that is, documentation, configuration
appendix, only the software life processes/activities management, and audit processes.
which have internal quality metrics are mentioned.

5. Primary Life Cycle Processes 6. Supporting Life Cycle Processes

5.1 Acquisition (0 Metric) 6.1 Documentation (0 Metric)
5.2 Supply (0 Metric) 6.2 Configuration Management (0 Metric)
5.3 Development 6.3 Quality Assurance (2 Metrics)
(1 Metric in Software Qualification 6.4 Verification (59 Metrics)
Testing activity)
6.5 Validation (13 Metrics)
5.4 Operation (0 Metric)
6.6 Joint review (59 Metrics)
5.5 Maintenance (0 Metric)
6.7 Audit (0 Metric)

6.8 Problem Resolution (4 Metrics)

Figure 4: The ISO 9126-3 Internal Quality Metrics and where they could be measured in the SLCP.

3.2 EXTERNAL QUALITY METRICS still remain after testing. As it is difficult to correct the
Within the ISO 9126-2 on software product external software architecture or other fundamental design
quality metrics, there is 110 metrics. These metrics can aspects of the software, the fundamental design usually
be applied during the software life cycle. External remains unchanged throughout testing [12].
quality defined in ISO 9126-1 as the totality of
characteristics of the software product from an external Figure 5 shows the number of external quality
view. It is the quality when the software is executed, metrics which can be applied (measured) during each of
which is typically measured and evaluated while testing the ISO 12207 software life cycle processes. For
in a simulated environment with simulated data using example, within the “operation process” of the “primary
external metrics. During testing, most faults should be processes”, 93 metrics can be applied (measured).
discovered and eliminated. However, some faults may

5. Primary Life Cycle Processes 6. Supporting Life Cycle Processes

5.1 Acquisition (0 Metric) 6.1 Documentation (0 Metric)
5.2 Supply (0 Metric) 6.2 Configuration Management
5.3 Development (0 Metric)
(7 Metrics in Software Integration activity) 6.3 Quality Assurance (14 Metrics)
(100 Metric in Software Qualification Testing activity) 6.4 Verification (0 Metrics)
(7 Metrics in System Integration activity)
6.5 Validation (47 Metrics)
5.4 Operation (93 Metric)
6.6 Joint review (0 Metric)
5.5 Maintenance (48 Metric)
6.7 Audit (0 Metric)
6.8 Problem Resolution (1 Metric)

Figure 5: The ISO 9126-2 External Quality Metrics and where they could be measured in the SLCP.

3.3 QUALITY IN USE METRICS quality of the software product when it is used in a
Within the ISO 9126-2 on software product quality in specific environment and a specific context of use. It
use metrics, there is 15 metrics. These the 15 metrics measures the extent to which users can achieve their
can be applied during the software life cycle. Quality in goals in a particular environment, rather than measuring
Use defined in ISO 9126-1 as the user’s view of the the properties of the software itself. The term ‘user’
refers to any type of intended users, including both 12207 software life cycle processes. For example,
operators and maintainers, and their requirements can during the “software qualification testing” activity of
be different. [12]. the “development process” of the “primary processes”,
12 metrics can be applied (measured).
Figure 6 shows the number of quality in use metrics
which can be applied (measured) during each of the ISO

5. Primary Life Cycle Processes 6. Supporting Life Cycle Processes

5.1 Acquisition (0 Metric) 6.1 Documentation (0 Metric)
5.2 Supply (0 Metric) 6.2 Configuration Management
(0 Metric)
5.3 Development
(12 Metric in Software Qualification Testing activity) 6.3 Quality Assurance (0 Metrics)
5.4 Operation (15 Metric) 6.4 Verification (0 Metrics)
5.5 Maintenance (0 Metric) 6.5 Validation (11 Metrics)
6.6 Joint review (0 Metrics)
6.8 Problem Resolution (0 Metrics) 6.7 Audit (0 Metric)

Figure 6: The ISO 9126-4 Quality in Use Metrics and where they could be measured in the SLCP.

4. DISCUSSION OF THE MAPPING activity is a part of the “development process” Thus, it’s
In ISO 9126-3, there are some external quality metrics – strange and make no sense to measure the 12 metrics
as in Table 1 - which have been referred to be applied
during the “integration” activity of the “development The “joint review process” of the “supporting
process” of the “primary processes”. But, within the processes” consists of three activities; one of these
“development” process, there are two activities related activities is the “technical reviews” activity. The
to the “integration”, that is, “system integration” and “technical reviews” activity contains one task that is,
“software integration”. However, this document (ISO “Technical reviews shall be held to evaluate the
9126-3) did not specify during which “integration” software products or services under consideration and
activity those metrics can be applied (measured). provide evidence that: a) they are complete . . . ” [9].
Now, if we go back to Figure 4, we will find that there
is 59 internal quality metrics that could be measured
Table 1: Some External Quality Metrics.
during the “joint review” process. Whereas, from
1- Estimated latent fault 2- Incorrect operation Figures 5 and 6, it is seen that there is no any external
density avoidance quality or quality in use metrics that can be applied
3- Failure density 4- Availability during “joint review” process.
against test cases
5- Failure resolution 6- Mean down time
7- Fault density 8- Mean recovery time 5. CONCLUSION
9- Fault removal 10- Restartability The current edition of the ISO 9126 consists of
11- Mean time between 12- User support inventories of proposed metrics to measure the quality
failures (MTBF) functional consistency of the internal, external, and in-use software product.
13- Breakdown 14- Restore effectiveness However, for each of these metrics there is a cross-
15- Failure avoidance 16- Restorability reference on where it could be applied (measured)
during the ISO 12207 software life cycle processes and
activities. This paper provided a mapping between those
It is clearly noted that through the ISO 12207 two standards to investigate the cross-references
“organizational processes” none of the 195 quality between them. Based on this mapping, the following
metrics - found in ISO 9126 series of international comments and suggestions for the upcoming new ISO
standards - can be applied (measured). 25000 series of standards (SQuaRE) can be concluded:
- There is no any metric can be measured during
As mentioned in ISO 9126-1, the quality in use the “organizational processes”.
metrics should be measured during the execution of the - A number of external quality metrics where
software product in an actual working environment. mentioned in ISO 9126-2 to be measured during
However, in Figure 6 we can see that there is 12 metrics the “integration” activity. However, within the
which could be measured through the “software ISO 12207 there are two activities labeled
qualification testing” activity. But since ISO 12207 “system integration” and “software integration”.
mentioned that the “software qualification testing” This will make the user of the ISO 9126
confused.
 - Many of the ISO 9126 quality metrics referred to Electrical and Electronics Engineers, New York,
processes. However, as known, each process in USA, 1996.
ISO 12207 contains a number of different [10] IEEE, Std. 610.12-1990: Standard Glossary of
activities. Thus, it is more usable for the ISO Software Engineering Terminology, the Institute
9126 users to refer to the activities of the ISO of Electrical and Electronics Engineers, New
12207. This can be done using cross-reference York, USA, 1990.
numbers from ISO 12207. For example, the [11] Ince, D. S., Sharp, H., and Woodman, M.,
cross-reference number 5.3.9 is referring to Introduction to Software Project Management and
“primary processes”, “development process”, and Quality Assurance, McGraw-Hill, New York,
“software qualification testing” activity, USA, 1993.
respectively. [12] ISO/IEC, ISO/IEC 9126-1: Software Engineering
- Product Quality - Part 1: Quality Model,
In addition to the mapping in this paper, it is a good International Organization for Standardization,
idea to investigate where to collect the data for each of Geneva, Switzerland, 2001.
the ISO 9126 quality metrics in the ISO 12207 software [13] ISO/IEC, ISO/IEC 12207: Information
life cycle processes and activities. This will save time Technology - Software life cycle processes,
and assure that the data have been completely collected International Organization for Standardization,
before the measurement of the metrics is performed. Geneva, Switzerland, 1995.
[14] ISO/IEC, ISO/IEC IS 9126, Software Product
Evaluation - Quality Characteristics and
REFERENCES Guidelines for Their Use, International
[1] Abran, A., Al-Qutaish, R. E., and Desharnais, J.
Organization for Standardization, Geneva,
M., "Harmonization Issues in the Updating of the
Switzerland, 1991.
ISO Standards on Software Product Quality,"
[15] ISO/IEC, ISO/IEC IS 15939: Software
Metrics News Journal, Vol. 10, No. 2, pp. 35-44,
Engineering - Software Measurement Process,
2005.
International Organization for Standardization,
[2] Abran, A., Al-Qutaish, R. E., Desharnais, J. M.,
Geneva, Switzerland, 2002.
and Habra, N., "An Information Model for
[16] ISO/IEC, ISO/IEC TR 9126-2: Software
Software Quality Measurement with ISO
Engineering - Product Quality - Part 2: External
Standards," in Proceedings of the International
Metrics, International Organization for
Conference on Software Development (SWDC-
Standardization, Geneva, Switzerland, 2003.
REK'05), Reykjavik, Iceland, pp. 104-116, 2005.
[17] ISO/IEC, ISO/IEC TR 9126-3: Software
[3] Albrecht, A. J., "Measuring Application
Engineering - Product Quality - Part 3: Internal
Development Productivity," in Proceedings of the
Metrics, International Organization for
IBM Application Development Joint
Standardization, Geneva, Switzerland, 2003.
SHARE/GUIDE Symposium, Monetary,
[18] ISO/IEC, ISO/IEC TR 9126-4: Software
California, pp. 83-92, 1979.
Engineering - Product Quality - Part 4: Quality in
[4] Azuma, M., "SQuaRE: The next Generation of
Use Metrics, International Organization for
ISO/IEC 9126 and 14598 International Standards
Standardization, Geneva, Switzerland, 2004.
Series on Software Product Quality," in
[19] McCabe, T. J., "A Complexity Measure," IEEE
Proceedings of the European Software Control
Transaction on Software Engineering, vol. 2, No.
and Metrics Conference (ESCOM), London, UK,
4, pp. 308-320, 1976.
pp. 337-346, 2001.
[20] Pressman, R. S., Software Engineering: A
[5] DeMarco, T., Controlling System Projects,
Practitioner's Approach, 3rd ed., McGraw-Hill,
McGraw-Hill, New York, USA, 1982.
New York, USA, 1992.
[6] Fenton, N. E. and Pfleeger, S. L., Software
[21] Roberts, F. S., Measurement Theory, with
Metrics: A Rigorous and Practical Approach, 2nd
Applications to Decision Making, Utility, and the
ed., PWS Publishing Company, Boston, USA,
Social Sciences, Addison Wesley, New York,
1997.
USA, 1979.
[7] Halstead, M. H., Elements of Software Science,
[22] Suryn, W., Abran, A., and April, A., "ISO/IEC
Elsevier North-Holland, New York, 1977.
SQuaRE: The Second Generation of Standards for
[8] Halstead, M. H., "Natural Laws Controlling
Software Product Quality," in Proceedings of the
Algorithm Structure," ACM SIGPLAN Notices,
7th IASTED International Conference on Software
Vol. 7, No. 2, pp. 19-26, 1972.
Engineering and Applications, California, USA,
[9] IEEE, IIEEE/EIA-12207: Information Technology
2003.
– Software Life Cycle Processes, the Institute of
 APPENDIX A
ISO 9126-3 INTERNAL QUALITY METRICS AND WHERE THEY COULD BE APPLIED
(MEASURED) IN ISO 12207 PROCESSES AND ACTIVITIES

5-Primary Processes:
5.3 Development:
9) Software qualification testing:
1. Functional specification stability (1.12)
5.4 Operation:
1. Functional specification stability (1.1)
6-Supporting Processes:
6.3 Quality Assurance:
1. Functional specification stability (1.1)
2. Test adequacy (2.1)
6.4 Verification:
1. Computational accuracy (1.2) 31. User Interface appearance customizability (3.4)
2. Precision (1.2) 32. Usability Compliance (3.5)
3. Data exchangeability (data format based) (1.3) 33. Response time (4.1)
4. Interface consistency (protocol) (1.3) 34. Throughput time (4.1)
5. Functional Compliance (1.5) 35. Turnaround time (4.1)
6. Intersystem standard compliance (1.4) 36. I/O Utilization (4.2)
7. Fault detection (2.1) 37. I/O Utilization Message Density (4.2)
8. Fault removal (2.1) 38. Memory utilization (4.2)
9. Test adequacy (2.1) 39. Memory utilization message density (4.2)
10. Failure avoidance (2.2) 40. Transmission Utilization (4.2)
11. Incorrect operation avoidance (2.2) 41. Efficiency Compliance (4.3)
12. Restorability (2.3) 42. Activity recording (5.1)
13. Restoration Effectiveness (2.3) 43. Readiness of diagnostic function (5.1)
14. Reliability Compliance (2.4) 44. Change recordability (5.2)
15. Completeness of description (3.1) 45. Change impact (5.3)
16. Demonstration capability (3.1) 46. Modification impact localization (5.3)
17. Evident functions (3.1) 47. Completeness of built-in test (5.4)
18. Function understandability (4.1) 48. Autonomy of testability (5.4)
19. Completeness of user documentation and/or 49. Test progress observability (5.4)
help facility (3.2) 50. Maintainability Compliance (5.5)
20. Input validity checking (3.3) 51. Adaptability of data structures (6.1)
21. User operation cancellability (3.3) 52. Organizational Environment adaptability (6.1)
22. User operation Undoability (3.3) 53. Hardware Environmental Adaptability (H/W,
23. Customizability (3.3) network) (6.1)
24. Physical accessibility (3.3) 54. System software Environmental adaptability (OS,
25. Operation status monitoring capability (3.3) concurrent application) (6.1)
26. Operational consistency (3.3) 55. Porting User Friendliness (6.1)
27. Message Clarity (3.3) 56. Continued use of Data (6.3)
28. Interface element clarity (3.3) 57. Functional inclusiveness (6.3)
29. Operational error recoverability (3.3) 58. Available co-existence (6.4)
30. Attractive interaction (3.4) 59. Portability Compliance (6.5)
6.5 Validation:
1. Functional adequacy (1.1) 8. Data encryption (1.4)
2. Functional implementation completeness (1.1) 9. Failure avoidance (2.2)
3. Functional implementation coverage (1.1) 10. Incorrect operation avoidance (2.2)
4. Functional specification stability (1.1) 11. Ease of setup retry (6.2)
5. Access auditability (1.4) 12. Installation effort (6.2)
6. Access controllability (1.4) 13. Installation flexibility (6.2)
7. Data corruption prevention (1.4)

2
This number refers to the characteristic-number.subcharacteristic-number which can be taken from Figure 1. For
example, the number 1.1 refers to the “Functionality” characteristic and “Suitability” subcharacteristic which means
that this metric (Functional specification stability) is used to measure the “Suitability” subcharacteristic in which it is a
part of the “Functionality” of any software product, this metrics could be measured during the “Software qualification
testing” activity of the “development” process. Throughout these Appendices, the Software Quality Metrics names
have been written in italic fonts.
 6.6 Joint Review:
1. Functional adequacy (1.1) 31. Operational consistency (3.3)
2. Functional implementation completeness (1.1) 32. Message Clarity (3.3)
3. Functional implementation coverage (1.1) 33. Interface element clarity (3.3)
4. Computational accuracy (1.2) 34. Operational error recoverability (3.3)
5. Precision (1.2) 35. Attractive interaction (3.4)
6. Data exchangeability (data format based) (1.3) 36. User Interface appearance customizability (3.4)
7. Interface consistency (protocol) (1.3) 37. Usability Compliance (3.5)
8. Access auditability (1.4) 38. Response time (4.1)
9. Access controllability (1.4) 39. Throughput time (4.1)
10. Data corruption prevention (1.4) 40. Turnaround time (4.1)
11. Functional Compliance (1.4) 41. Efficiency Compliance (4.3)
12. Intersystem standard compliance (1.4) 42. Activity recording (5.1)
13. Fault detection (2.1) 43. Readiness of diagnostic function (5.1)
14. Fault removal (2.1) 44. Change recordability (5.2)
15. Failure avoidance (2.2) 45. Change impact (5.3)
16. Incorrect operation avoidance (2.2) 46. Modification impact localization (5.3)
17. Restorability (2.3) 47. Completeness of built-in test (5.4)
18. Restoration Effectiveness (2.3) 48. Autonomy of testability (5.4)
19. Reliability Compliance (2.4) 49. Test progress observability (5.4)
20. Completeness of description (3.1) 50. Maintainability Compliance (5.5)
21. Demonstration capability (3.1) 51. Adaptability of data structures (6.1)
22. Evident functions (3.1) 52. Organizational Environment adaptability (6.1)
23. Function understandability (3.1) 53. Hardware Environmental Adaptability (H/W,
24. Completeness of user documentation and/or network) (6.1)
help facility (3.2) 54. System software Environmental adaptability (OS,
25. Input validity checking (3.3) concurrent application) (6.1)
26. User operation cancellability (3.3) 55. Porting User Friendliness (6.1)
27. User operation Undoability (3.3) 56. Continued use of Data (6.3)
28. Customizability (3.3) 57. Functional inclusiveness (6.3)
29. Physical accessibility (3.3) 58. Available co-existence (6.4)
30. Operation status monitoring capability (3.3) 59. Portability Compliance (6.5)
6.8 Problem Resolution:
1. Functional specification stability (1.1) 3. Failure avoidance (2.2)
2. Test adequacy (2.1) 4. Incorrect operation avoidance (2.2)

View publication stats