SOFTWARE QUALITY MODELS AND RELIABILITY MEASUREMENT METRICS

— " Software reliability is the probability that the software will run without failures for an unlimited time until and unless changed intentionally". It is a crucial characteristics of quality with other essential characteristics. Software reliability measurement is an important concern for any organization to master its software before reaching to end users. A literature review shows that much wok has not been done in this direction. Although achieving software reliability is hard due to software's complex nature but different techniques can be applied to enhance its reliability. Every organization has its own metrics for reliability measurement. There is a need to define metrics according to international standards. In this paper we will analyze software quality and reliability metrics thoroughly.


I. INTRODUCTION
"Reliability is an external software quality attribute defined by the ISO/IEC 25010:2011" [1]. "Software reliability is the probability that the software system will function properly without failure over a certain time period" [2]. "It is an external quality attribute, which relates internally to the notion of program faults or defects". "Software Reliability is also an important factor that affect system reliability" [1]. It is different from hardware reliability in such a way that it shows software design precision, while hardware reliability covers manufacturing perfection. Hardware reliability have a tendency to be steady or fixed while passes time while software reliability has trend to alter in the testing life cycle.
The failing causes are totally diverse for both hardware and software reliabilities. "Hardware faults arise mostly from wear and physical deterioration, while software faults come mostly from design issues" [10]. They may be incorrect requirements, deviation of code from requirements, sudden modifications in operational control or incorrect changes in the code.
Researchers have developed different models to correlate software reliability and time. But it is obvious that software reliability is not related to time. The modeling techniques for software reliability are now very much matured. However, we should select the technique very carefully before using in any case. "Measurement in software is still in its infancy. No good quantitative methods have been developed to represent software reliability without excessive limitations" [11]. We can use different approaches to enhance the reliability of software.
However, it is a difficult task to get software reliability with a balanced cost against the software development time.
The remaining paper is outlined as following. Section II describes software and system quality models. Section III discuss about the software reliability measurement and reliability matrices. Conclusion is mentioned in the final Section IV.

II. SOFTWARE QUALITY MODELS
There are different quality models available in industry.
"Software quality models and their metrics may be used in many contexts, i.e. during the development of a new application [3,4] or when selecting commercial components" [5]. "Software quality is described by a number of attributes which are further classified into two categories, internal and external". Reliability is one of the vital and fundamental quality factor, criteria or characteristic between the others.
Farooq et al. [6] shows that "it is the only common factor of different quality models i.e., Bohem's, FURPS, McCall's, ISO 9126 and ISO 25010:2011". Currently, ISO/IEC 9126 [7] is one of the prevailing quality standards used in the world. There are two software quality models according to ISO/IEC 25010 standard.

Quality in use model
2. Product quality model The quality in use model consists of five characteristics, a few of these are further classified into sub-characteristics. "These characteristics relate to the outcome of interaction when a product is used in a particular context of use". This quality model covers the whole computer system that includes in use computer system and software products. Table 1 Table 2 shows characteristics and sub-characteristics of the product quality model.

III. SOFTWARE RELIABILITY MEASUREMENT
Software is considered an essential part of everyday usage products. Therefore, a lower degree of software reliability can be profoundly costly for the supplier in the form of displeased customers, loss in market share, extra work and effort to make the necessary changes and corrections in the faulty system. [8].

External Metrics
Following metrics have been defined in this category.

Maturity Metrics
These metrics evaluate the existence of attributes like software failures that are triggered by flaws in the existing software.
Following are sub-matrices in this category.

• Failure Density against Test Cases:
This matrix calculates the number of failures detected during a specified trial session. Failure intensity is very important for reliability.

• Failure Resolution:
This matrix confirms how many failure conditions are resolved.

• Fault Density:
Fault density matrix finds out the number of faults that were detected during a specified trial session. One must know difference between fault and failure clearly.

• Fault Removal:
This matrix counts the number of faults eliminated whilst testing and compares the sum of faults with the sum of those predicted.

• Mean Time between Failures (MTBF)
It calculates the frequency of failures that eventuated during a specified period of operation and sums up the average duration between the failures.
• Test Coverage: What number of essential test scenarios have been concluded whilst testing? This confirms test case coverage. We can set threshold according to our own requirement.
• Test Maturity: Purpose of this matrix is to check whether the product has been well tested.
Similarly, Fault Tolerance matrices pertain to the software's potential of sustaining a specific degree of performance in case of functional flaws.

Fault Tolerance Matrices
There are two selected matrix in this category.

• Software Breakdown & Avoidance:
How frequently the software trigger disruption in the production environment.
• Mean Down Time: The average time of system unavailability when a malfunction ensues prior to its start.

Recoverability Metrics
These metrics evaluate attributes such as whether the software system is able to re-establish its appropriate degree of efficiency and retrieve the data that was directly influenced, for instance during a failure.

• Mean Recovery Time:
This metric shows the typical average time that the system takes to recover completely.
• Restartability: Restartability matrix assesses how many times the process can restart offering services to the customers inside a required time.

Reliability Compliance Metrics
These metrics measure attributes such as the amount of functions that are unable to meet the standard as per the guidelines set for the required compliance.

• Reliability Compliance:
It is the capability of the software that shows how it observes regulations, conventions and standards of reliability.
This is an important issue. Developers should follow standards strictly to obtain good reliability results.
All the matrices mentioned above to measure software reliability have been taken from ISO/IEC 9126 standard. Any organization may define their own matrix or they can exactly follow above matrices to measure software reliability. One sample matrix, Fault Removal, is shown in Table 3

IV. CONCLUSION
This paper focuses primarily on software reliability measurement and matrices. Achieving software reliability is considered an important task of any organization.
Measurement of software reliability is difficult resulting from the complexity of the software. Quality of the software might be improved by applying metrics at each and every phase of software development life cycle (SDLC). We recommend to follow reliability matrices defined by ISO/IEC.

V. DISCUSSION
Supporting or contradicting them. Students should also justify their results with evidence-based reasoning and not merely stating the supporting and contradicting studies.
Discussion should end with implications or suggestions for future research or