Measuring software reliability: a fuzzy model - Semantic Scholar
ACM SIGSOFT Software Engineering Notes
Page 1
November 2011 Volume 36 Number 6
Measuring Software Reliability : A Fuzzy Model Ravinder Kumar
Kiran Khatter
Arvind Kalia
Associate Professor Ansal Institute of Technology Sector – 55, Gurgaon, INDIA +91-1244750422
Assistant Professor Ansal Institute of Technology Sector – 55, Gurgaon, INDIA +91-1244750485
Associate Professor Deptt. of Computer Application H P University, Shimla, INDIA +919418001760
[email protected]
[email protected]
[email protected]
ABSTRACT Software reliability is an essential part of software engineering to ensure the quality of a system. There are various techniques, which can be used in building models for predicting quality attributes. This paper presents a Fuzzy model for software reliability prediction. We have proposed three parameters Availability, Failure Probability and Recoverability as an integrated measure of software reliability. Fuzzy Model provides a way to arrive at a discrete Reliability Non-functional requirement (NFR) in contrast to imprecise, vague and ambiguous. This model will help us to evolve intermediate stages between reliable state and unreliable state of a system. Results obtained by proposed model show that this is suitable for predicting software reliability of the software.
Categories and Subject Descriptors D.2.8 [Software Engineering]: Metrics – performance measure
General Terms Measurement, Performance and Reliability
2. FACTORS AFFECTING RELIABILITY
Keywords Non-functional Requirement, Reliability, Probability, Recoverability, Fuzzy Model
Availability,
Failure
1. INTRODUCTION Quantification of desirable properties of a system is an integral part of the software engineering. Since most of requirement analysis methods do not consider non-functional requirements, which leads to serious software development problems [1][2][3][4][6]. The problems faced because of negating non-functional requirements are more severe than the problems of functional requirements omissions [4][5]. Software reliability is major concern for quality system. It is the probability to perform failure free operation and produce correct output for a specified time under specified conditions. Once the system is installed, it is not possible to test system reliability in an operational environment because failure data collected in an uncontrolled tested environment may be limited. In this case, faults may not be necessarily removed as failures are identified. Therefore failures are considered as one of the factors affecting the software reliability [7]. Failure data need to be properly collected and measured during software development process for the assessment of reliability of software systems. There are various reliability growth models for assessing the reliability of a system. These models aim at predicting reliability of the software system during failure and removal process. Software reliability is measured by collecting the historical data and a distribution curve. As failures are identified, faults are removed from the system to increase reliability [8]. The fault tree uses fuzzy set theory for the quantification of uncertainty in order to make the system reliable. In a software development process, software is designed as an integration of sub-systems instead of a large system. The uncertainty of the overall system is found on the basis of uncertainties in the failure probability of sub-systems. Thus reliability requirements apply to the individual subsystems rather than the whole system. Software reliability is one of the most desirable quality attributes of the system. Thus its quantitative measurement is an
DOI: 10.1145/2047414.2047425
essential part of the development of a quality system. Estimation of software reliability becomes more important for those applications where safety is major consideration. Though available literature emphasizes the importance of non-functional requirements but implementation of non-functional requirements in the available literature is less. It is not possible to verify non-functional requirements at any point as we verify functional requirements. In this paper, we are bridging this gap between non-measurable/vague and precise/exact. To make reliability non-functional requirement measurable, we have used fuzzy model. In [9] also a fuzzy model is proposed to measure the reliability of the software. This model considers frequency of failure and recoverability as two metrics to assess reliability. After reviewing available literature, it is observed that reliability also depends upon availability non-functional requirement of the system. At present, there is no model that considers all these non-functional requirements to estimate the reliability of the system. Therefore, we propose a model, which integrates availability (AVAIL), failure probability (FPROB) and recoverability (RECOV) non-functional requirements and provides an assessment of reliability. Reliability is a key non-functional requirement, which can be divided into three Sub-NFRs (Availability, Failure Probability and Recoverability). Availability is one of the important metric used to assess the performance of a system, accounting for reliability of a system. It is defined as the ability to perform a required function under specified conditions at a given point of time or over a given time interval. It is related to the time that the system is expected to be available to the users. System must be alive for service when it is requested by endusers. Availability indicates how reliable system is during operational hours. It is defined as the probability that a system is in its expected functional condition and capable of being used in a specified environment. It deals with up-time hours and measures how often the system is alive. It is often expressed as up-time and downtime. Uptime refers to the capability to perform the intended task in a stated environment and downtime refers to not being able to perform the intended task in a stated environment [10]. Average Uptime Availability (A (t)) is the proportion of time that the system is operational and available for use. It represented by the mean value of the instantaneous availability, which is used to estimate the availability of the system at a specific time. t
1 A(t ) = ∫ A(u )du t0 Inherent Availability (AI) considers corrective maintenance downtime of the system and is represented as follows:
AI =
MTTF MTBF + MTTR
http://doi.acm.org/10.1145/2047414.2047425
ACM SIGSOFT Software Engineering Notes
Page 2
November 2011 Volume 36 Number 6
MTBF = Uptime / Number of System Failures MTTR = Corrective Maintenance Downtime / Number of System Failures Failure Probability is another important metric used to assess the reliability of a system. It is very important to know how often system fail to deliver expected level of service. Reliability is concerned with the occurrences and frequency of different types of failures. Reliability growth analysis uses times-to-failure data obtained during the testing phase of development process. Failure probability of the overall system is calculated by considering failure probabilities of all sub-systems. If operation of the system depends upon sub systems then failure probability is given by
P ( S ) = P( A) + P ( B) + ......... + P(n) If all subsystems are replicated means all subsystem fail at once then probability of failure is
P( S ) = P( A) n The Crow-AMSAA model can be used in the analysis of times-tofailure data [11]. Suppose a reliability growth program is represented by i sessions.
RULE BASE
Input 1 . . .
FUZZIFICATION MODULE
INFERENCE ENGINE
Input n Output
DEFUZZIFICATION MODULE
Figure 1. Block Diagram of Fuzzy Model
Working of Fuzzy Model A fuzzy model performs its operations in the following steps:
Fuzzification of Inputs: Fuzzification is the process of transformation of crisp inputs to the corresponding values in fuzzy domain. Fuzzifier takes the inputs and uses membership functions to determine the degree to which they belong to each of the appropriate fuzzy sets. The input is always a crisp numerical value.
Apply Fuzzy Operators:
Ki = the cumulative number of failures through session i.
Fuzzy operators are applied to compute the degree of support for each rule for the generation of a single crisp value. This value will then be applied to the output functions. The input to a fuzzy operator is two or more membership values from fuzzified input variables. The output is the single truth-value. Two commonly used fuzzy operators are MINMAX operators
The expected number of failures by the end of session i is:
Apply implication methods:
Ni = the number of trials during session i. Ti = the cumulative number of trials through session i. Mi = the number of failures during session i.
E [K i ] = λTi
β
The failure probability on a configuration basis, fi, is:
fi =
λTi β − Ti −β1 Ni
Recoverability is also another important metric used to assess the reliability of a system. There may be many ways to recover from a failure. Therefore, it is important to determine which failures may occur when system is available during specific time in stated environment and how to recover from these failures. Good architecture provides recoverability in the time specified in a service-level agreement.
3. FUZZY MODEL Fuzzy model is the best choice for managing vague, imprecise, doubtful, contradicting and diverging opinions. There are four modules (Rule Base, Fuzzification, Inference Engine, Defuzzification), which transform the crisp inputs into fuzzy values. Then these values are processed by inference engine in the fuzzy domain using the rule base created by domain expert. Finally the processed output is transformed from fuzzy domain to crisp domain by defuzzification module [12].
The shaping of the consequent based on the antecedent is termed as implications. The input for the implications processes is a single number given by the antecedent, and the output is a fuzzy set. Implication is applied for each rule. Two commonly used implication methods for AND are MIN (i.e. truncation) and PRODUCT (i.e. scaling the height of a fuzzy set). Two commonly used implication methods for OR are MAX (maximum) and probabilistic OR (algebraic sum).
Aggregate all outputs: Aggregation is a process by which fuzzy sets are combined in desirable way to produce a single fuzzy set. It is obtained by combining all the fuzzy sets that represents the output of each rule into a single fuzzy set. Aggregation occurs only once for each output variable. For our model the input of the aggregation processes is the list of truncated output functions returned by the implication process for each rule. The output of the aggregation process is one fuzzy set for each output variable.
Defuzzify: Defuzzification transforms the fuzzy values to crisp values. The input of the defuzzification process is a fuzzy set and the output is a single fuzzy number. Given a fuzzy set that encompasses a range of output values, one number needs to be returned thereby moving from a fuzzy set to crisp output.
It is represented as follows:
Figure 2. Fuzzy Reference System: Reliability Model
DOI: 10.1145/2047414.2047425
http://doi.acm.org/10.1145/2047414.2047425
ACM SIGSOFT Software Engineering Notes
Page 3
November 2011 Volume 36 Number 6
4. FUZZIFICATION The first step in the fuzzy inference system is to fuzzify inputs. The input parameters to the fuzzy system are represented as fuzzy sets. Fuzzy sets allow its elements to have degrees of membership. Thus element of a fuzzy set is represented as a pair (member, degree). A linguistic variable is used to represent degrees of “support” and “confidence” for members [13]. The inputs to the reliable system are the assumed values for Availability (AVAIL), Failure Probability (FPROB) and Recoverability (RECOV) and are taken on the higher side so that the resultant system remains reliable. The input parameters are considered to be of the same weight. All the input values for abovementioned parameters are defined as a fuzzy number by using suitable fuzzy sets. Levels of three input variables i.e. Availability, Failure Probability and Recoverability as fuzzy sets are given below: Availability = {VGOOD, GOOD, MODERATE, BAD, VBAD} Failure Probability = {VLOW, LOW, MED, HIGH, VHIGH} Recoverability = {HIGH, AVG, LOW} Then these fuzzy sets are represented by a membership function. This can be best achieved by deciding numerical range for the fuzzy input/output variables.
Figure 4. Fuzzification of input variable: Failure Probability Table 3. Fuzzy Variable Range for Recoverability Recoverability (RECOV) Numerical Range
Linguistic Variables
0-4
HIGH
1-9
AVG
6-10
LOW
Table 1. Fuzzy Variable Range for Availability Availability (AVAIL) Numerical Range
Linguistic Variables
0-3
VGOOD
2-5
GOOD
4-7
MODERATE
6-9
BAD
8-10
VBAD Figure 5. Fuzzification of input variable: Recoverability Similarly the output variable Reliability is represented by fuzzy variables as shown below: TABLE 4. Fuzzy Variable Range for Reliability Reliability
Figure 3. Fuzzification of input variable: availability
Numerical Range
Linguistic Variables
8-10
VHIGH
6-9
HIGH
4-7
MED
2-5
LOW
0-3
VLOW
Table 2. Fuzzy Variable Range for Failure Probability Failure Probability (FPROB) Range
Fuzzy Variables
0-3
VLOW
2-6
LOW
5-9
MED
8-12
HIGH
11-13
VHIGH Figure 6. Fuzzification of output variable: Reliability
DOI: 10.1145/2047414.2047425
http://doi.acm.org/10.1145/2047414.2047425
ACM SIGSOFT Software Engineering Notes
Page 4
5. RULE BASE FOR THE PROPOSED SYSTEM After the fuzzification of inputs, fuzzy operations are carried out in fuzzy domain. The proposed model integrates the effect of AVAIL, FPROB, and RECOV into a single measurable parameter, termed as software reliability, based on the following rule base. All possible combinations of inputs were considered which leads to 75 sets. The Reliability in case of all 75 combinations is classified as Very High, High, Medium, Low and Very Low by expert opinion. These lead to formation of 75 rules for the fuzzy model and rules are shown as below: 1. If (AVAIL is VGOOD) and (FPROB is VLOW) and (RECOV is HIGH) Then (Reliability is VHIGH). 2. If (AVAIL is VGOOD) and (FPROB is VLOW) and (RECOV is AVG) Then (Reliability is VHIGH). 3. If (AVAIL is VGOOD) and (FPROB is VLOW) and (RECOV is LOW) Then (Reliability is HIGH). 4. If (AVAIL is VGOOD) and (FPROB is LOW) and (RECOV is HIGH) Then (Reliability is VHIGH). 5. If (AVAIL is VGOOD) and (FPROB is LOW) and (RECOV is AVG) Then (Reliability is HIGH). 6. If (AVAIL is VGOOD) and (FPROB is LOW) and (RECOV is LOW) Then (Reliability is HIGH). 7. If (AVAIL is VGOOD) and (FPROB is MED) and (RECOV is HIGH) Then (Reliability is HIGH). 8. If (AVAIL is VGOOD) and (FPROB is MED) and (RECOV is AVG) Then (Reliability is MED). 9. If (AVAIL is VGOOD) and (FPROB is MED) and (RECOV is LOW) Then (Reliability is LOW). 10. If (AVAIL is VGOOD) and (FPROB is HIGH) and (RECOV is HIGH) Then (Reliability is MED). 11. If (AVAIL is VGOOD) and (FPROB is HIGH) and (RECOV is AVG) Then (Reliability is MED). 12. If (AVAIL is VGOOD) and (FPROB is HIGH) and (RECOV is LOW) Then (Reliability is LOW). 13. If (AVAIL is VGOOD) and (FPROB is VHIGH) and (RECOV is HIGH) Then (Reliability is MED). 14. If (AVAIL is VGOOD) and (FPROB is VHIGH) and (RECOV is AVG) Then (Reliability is LOW). 15. If (AVAIL is VGOOD) and (FPROB is VHIGH) and (RECOV is LOW) Then (Reliability is LOW). 16. If (AVAIL is GOOD) and (FPROB is VLOW) and (RECOV is HIGH) Then (Reliability is VHIGH). 17. If (AVAIL is GOOD) and (FPROB is VLOW) and (RECOV is AVG) Then (Reliability is HIGH). 18. If (AVAIL is GOOD) and (FPROB is VLOW) and (RECOV is LOW) Then (Reliability is HIGH). 19. If (AVAIL is GOOD) and (FPROB is LOW) and (RECOV is HIGH) Then (Reliability is HIGH). 20. If (AVAIL is GOOD) and (FPROB is LOW) and (RECOV is AVG) Then (Reliability is MED). 21. If (AVAIL is GOOD) and (FPROB is LOW) and (RECOV is LOW) Then (Reliability is MED). 22. If (AVAIL is GOOD) and (FPROB is MED) and (RECOV is HIGH) Then (Reliability is HIGH).
DOI: 10.1145/2047414.2047425
November 2011 Volume 36 Number 6
23. If (AVAIL is GOOD) and (FPROB is MED) and (RECOV is AVG) Then (Reliability is HIGH). 24. If (AVAIL is GOOD) and (FPROB is MED) and (RECOV is LOW) Then (Reliability is MED). 25. If (AVAIL is GOOD) and (FPROB is HIGH) and (RECOV is HIGH) Then (Reliability is MED). 26. If (AVAIL is GOOD) and (FPROB is HIGH) and (RECOV is AVG) Then (Reliability is LOW). 27. If (AVAIL is GOOD) and (FPROB is HIGH) and (RECOV is LOW) Then (Reliability is LOW). 28. If (AVAIL is GOOD) and (FPROB is VHIGH) and (RECOV is HIGH) Then (Reliability is MED). 29. If (AVAIL is GOOD) and (FPROB is VHIGH) and (RECOV is AVG) Then (Reliability is LOW). 30. If (AVAIL is GOOD) and (FPROB is VHIGH) and (RECOV is LOW) Then (Reliability is LOW). 31. If (AVAIL is MODERATE) and (FPROB is VLOW) and (RECOV is HIGH) Then (Reliability is HIGH). 32. If (AVAIL is MODERATE) and (FPROB is VLOW) and (RECOV is AVG) Then (Reliability is MED). 33. If (AVAIL is MODERATE) and (FPROB is VLOW) and (RECOV is LOW) Then (Reliability is MED). 34. If (AVAIL is MODERATE) and (FPROB is LOW) and (RECOV is HIGH) Then (Reliability is HIGH). 35. If (AVAIL is MODERATE) and (FPROB is LOW) and (RECOV is AVG) Then (Reliability is MED). 36. If (AVAIL is MODERATE) and (FPROB is LOW) and (RECOV is LOW) Then (Reliability is MED). 37. If (AVAIL is MODERATE) and (FPROB is MED) and (RECOV is HIGH) Then (Reliability is MED). 38. If (AVAIL is MODERATE) and (FPROB is MED) and (RECOV is AVG) Then (Reliability is LOW). 39. If (AVAIL is MODERATE) and (FPROB is MED) and (RECOV is LOW) Then (Reliability is LOW). 40. If (AVAIL is MODERATE) and (FPROB is HIGH) and (RECOV is HIGH) Then (Reliability is MED). 41. If (AVAIL is MODERATE) and (FPROB is HIGH) and (RECOV is AVG) Then (Reliability is LOW). 42. If (AVAIL is MODERATE) and (FPROB is HIGH) and (RECOV is LOW) Then (Reliability is LOW). 43. If (AVAIL is MODERATE) and (FPROB is VHIGH) and (RECOV is HIGH) Then (Reliability is MED). 44. If (AVAIL is MODERATE) and (FPROB is VHIGH) and (RECOV is AVG) Then (Reliability is LOW). 45. If (AVAIL is MODERATE) and (FPROB is VHIGH) and (RECOV is LOW) Then (Reliability is LOW). 46. If (AVAIL is BAD) and (FPROB is VLOW) and (RECOV is HIGH) Then (Reliability is MED). 47. If (AVAIL is BAD) and (FPROB is VLOW) and (RECOV is AVG) Then (Reliability is LOW). 48. If (AVAIL is BAD) and (FPROB is VLOW) and (RECOV is LOW) Then (Reliability is LOW).
http://doi.acm.org/10.1145/2047414.2047425
ACM SIGSOFT Software Engineering Notes
Page 5
November 2011 Volume 36 Number 6
49. If (AVAIL is BAD) and (FPROB is LOW) and (RECOV is HIGH) Then (Reliability is MED).
75. If (AVAIL is BAD) and (FPROB is VHIGH) and (RECOV is LOW) Then (Reliability is VLOW).
50. If (AVAIL is BAD) and (FPROB is LOW) and (RECOV is AVG) Then (Reliability is MED).
All 75 rules are inserted and a rule base is created. Depending on a particular set of inputs, a rule will be fired. In this model, Mamdani style inference mechanism has been used. Output variable Reliability is observed using MATLAB fuzzy tool Box for a particular sets of inputs. For a given set of input parameters [AVAIL, FPROB, RECOV] say [5, 6.5, 5], Rule Viewer helps to see the output reliability level generated i.e 3.5 corresponding to this assumed set of input variables which is shown below:
51. If (AVAIL is BAD) and (FPROB is LOW) and (RECOV is LOW) Then (Reliability is LOW). 52. If (AVAIL is BAD) and (FPROB is MED) and (RECOV is HIGH) Then (Reliability is MED). 53. If (AVAIL is BAD) and (FPROB is MED) and (RECOV is AVG) Then (Reliability is LOW). 54. If (AVAIL is BAD) and (FPROB is MED) and (RECOV is LOW) Then (Reliability is LOW). 55. If (AVAIL is BAD) and (FPROB is HIGH) and (RECOV is HIGH) Then (Reliability is LOW). 56. If (AVAIL is BAD) and (FPROB is HIGH) and (RECOV is AVG) Then (Reliability is LOW). 57. If (AVAIL is BAD) and (FPROB is HIGH) and (RECOV is LOW) Then (Reliability is VLOW). 58. If (AVAIL is BAD) and (FPROB is VHIGH) and (RECOV is HIGH) Then (Reliability is LOW). 59. If (AVAIL is BAD) and (FPROB is VHIGH) and (RECOV is AVG) Then (Reliability is VLOW). 60. If (AVAIL is BAD) and (FPROB is VHIGH) and (RECOV is LOW) Then (Reliability is VLOW). 61. If (AVAIL is VBAD) and (FPROB is VLOW) and (RECOV is HIGH) Then (Reliability is MED). 62. If (AVAIL is VBAD) and (FPROB is VLOW) and (RECOV is AVG) Then (Reliability is MED). 63. If (AVAIL is VBAD) and (FPROB is VLOW) and (RECOV is LOW) Then (Reliability is LOW).
Figure 7. Rule Viewer for the Reliability Model
6. Defuzzification Defuzzification is the process of transformation of the output from fuzzy domain to crisp domain. We defuzzify the fuzzified output to get crisp value of the output variable reliability. In our model, we are using Center of Gravity method. This method finds the centre of the area, which is determined by the joint membership function of the fuzzy action [14]. The overlapping area is taken only once. This requires the integration over 2-D surface, which results into reference cycle.
64. If (AVAIL is VBAD) and (FPROB is LOW) and (RECOV is HIGH) Then (Reliability is MED). 65. If (AVAIL is VBAD) and (FPROB is LOW) and (RECOV is AVG) Then (Reliability is LOW). 66. If (AVAIL is VBAD) and (FPROB is LOW) and (RECOV is LOW) Then (Reliability is VLOW). 67. If (AVAIL is VBAD) and (FPROB is MED) and (RECOV is HIGH) Then (Reliability is LOW). 68. If (AVAIL is VBAD) and (FPROB is MED) and (RECOV is AVG) Then (Reliability is LOW).
Figure 8. Surface view with AVAIL input as x axis and FPROB on Y axis and Reliability on Z axis
69. If (AVAIL is VBAD) and (FPROB is MED) and (RECOV is LOW) Then (Reliability is VLOW). 70. If (AVAIL is VBAD) and (FPROB is HIGH) and (RECOV is HIGH) Then (Reliability is LOW). 71. If (AVAIL is BAD) and (FPROB is HIGH) and (RECOV is AVG) Then (Reliability is LOW). 72. If (AVAIL is BAD) and (FPROB is HIGH) and (RECOV is LOW) Then (Reliability is VLOW). 73. If (AVAIL is BAD) and (FPROB is VHIGH) and (RECOV is HIGH) Then (Reliability is LOW).
Figure 9. Surface view with AVAIL input as x axis and RECOV on Y axis and Reliability on Z axis
74. If (AVAIL is BAD) and (FPROB is VHIGH) and (RECOV is AVG) Then (Reliability is VLOW).
DOI: 10.1145/2047414.2047425
http://doi.acm.org/10.1145/2047414.2047425
ACM SIGSOFT Software Engineering Notes
Page 6
November 2011 Volume 36 Number 6
[4] Ebert, C. Dealing with Nonfunctional in Large Software Systems. Annals of Software Engineering, 3, 1997, pp. 367-395. [5] Mylopoulos, J., Chung, L., and Nixon, B., “Representing and Using Non-functional Requirements: A Process-Oriented Approach”, IEEE Trans. on Software Eng, 18(6), pp:483-497, June 1992. [6] Kotonya, G. and Sommerville, I. Requirements Engineering: Processes and Techniques. John Willey & Sons, 1998. [7] Jalote Pankaj, Murphy Brendan, Garzia Mario and Errez Ben, “Measuring Reliability of Software Products”, Industrial track in Int. Symp. on Sw Reliability (ISSRE-2004), Saint Melo, France, Oct 2004 Figure 10. Surface view with FPROB input as x axis and RECOV on Y axis and Reliability on Z axis
7. Results and discussions Suppose we have the following crisp value inputs to the model: AVAIL = 2.7, FPROB= 2.5, and RECOV=3.5. These inputs are fed to the fuzzification module and after fuzzification of the given values we find that AVAIL = 2.7 belongs to fuzzy set VGOOD with membership grade 0.20 and to the fuzzy set GOOD with membership grade 0.47, FPROB=2.5 belongs to the fuzzy set VLOW with membership grade 0.33 and to the fuzzy set LOW with membership grade 0.25, RECOV = 3.5 belongs to fuzzy set HIGH with membership grade 0.25. With these inputs values, we find that following rules were fired as given in table 5: Table 5. Software Reliability calculation for a given input set
[8] Lyu M. R., " Software Reliability Engineering: A Roadmap”, Future of Software Engineering, 2007. FOSE '07 [9] Malik N. M., Mushtaq A., Khalid S., Khalil T., Malik F. M., ”Measurable & Scalable NFRs using Fuzzy Logic and Likert Scale”, Computing Research Repository - CORR, 2009 [10] http://www.weibull.com/SystemRelWeb/availability.htm [11] Paul Barringer, P.E.,”Predict Failures: Crow-AMSAA 101 and Weibull 101”, Proceedings of IMEC 2004 International Mechanical Engineering Conference, 2004 [12] Singh Y., Bhatia, P. K., Sangwan O., ”Predicting Software Maintenance Using Fuzzy Model”, ACM SIGSOFT Software Engineering Notes (2009), Volume 34 Issue 4, July 2009 [13] Aggarwal K.K, Singh Y., Chandra P. and Puri M., Measurement of Software Maintainability Using a Fuzzy Model, Journal of Computer Sciences 1 (4): 538-542, 2005
AVAIL
FPROB
RECOV
(2.7)
(2.5)
(3.5)
Reliability Level
Membership Grade of Reliability
VGOOD
VLOW
HIGH
VHIGH
Min (0.20,0.33, 0.25)=0.20
[15] Gandotra V., Singhal A., Bedi P., “A Step Towards Secure Software System Using Fuzzy Logic”, 2nd International Conference on Computer Engineering and Technology (ICCET), 2010
GOOD
LOW
HIGH
HIGH
Min (0.47,0.25, 0.25)=0.25
[16] L. M. Cysneiros and J. C. S. do Prado Leite., “Non-functional requirements: From elicitation to conceptual models”, IEEE Trans., Software. Eng., 30(5): 328–350, 2007.
Rule No.1 gives software reliability VHIGH to an extent of 0.20 and rule no. 19 gives reliability HIGH to an extent of 0.25.
8. Conclusion Many systems failed due to cost and schedule overrun because of negligence of non-functional requirements, as stakeholders demand high quality software, non-functional requirements are considered to be primary importance. So in this paper, we have incorporated fuzzy logic to measure the reliability of software. The proposed model has demonstrated integrated measure of software reliability based on the following three factors: Availability (AVAIL), Failure probability (FPROB) and Recoverability (RECOV).
9. REFERENCES [1] Yeh, R. et. al. Software Requirements: New Directions and Perspectives. Handbook of Software Engineering, 1984, pp. 519543. [2] Roman, G. C. Taxonomy of Current Issues in Requirements Engineering. IEEE Computer, 18(4), 1985, pp.14-22. [3] Landes, D. and Studer, R.. The Treatment of Non-Functional Requirements in MIKE. LNCS 989 (Software Engineering: ESEC’95), Springer-Verlag, 1995, pp. 294-306
DOI: 10.1145/2047414.2047425
[14] Fuzzy Logic Toolbox, User’s Guide version 2, The Math Works Inc., SA, July 2002.
[17] Prasad L., Gupta A. Badoria S., “Measurement of Software Reliability Using Sequential Bayesian Technique” Proceedings of the World Congress on Engineering and Computer Science 2009 Vol I WCECS 2009 [18] Yen J., Liu X., Teh and S.H Xiaoqing, “A Fuzzy Logic-based Methodology for the Acquisition and Analysis of Imprecise Requirements”, [19] Komeili M., Valizadeh M., Armanfard N. and Kabir E. “An optimal fuzzy system for feature reliability measuring in particle filter-based object tracking”, Computer Conference, 2009. CSICC 2009. 14th International CSI [20] Kirner T.G. , Davis A .M. , “Nonfunctional Requirements of RealTime Systems”, Advances in Computers, Vol 42 pp 1-37 1996. [21] Wiegers, K. (2003). Software Requirements, 2nd edition. Microsoft Press. [22] Cysneiros, L.M. and Leite, J.C.S.P. “Integrating Non-Functional Requirements into data model” 4th International Symposium on Requirements Engineering – Ireland June 1999. [23] Roman, G.-C. A Taxonomy of Current Issues in Requirements Engineering. IEEE Computer, 18(4), 1985, pp.14-22.
http://doi.acm.org/10.1145/2047414.2047425
Page 1
November 2011 Volume 36 Number 6
Measuring Software Reliability : A Fuzzy Model Ravinder Kumar
Kiran Khatter
Arvind Kalia
Associate Professor Ansal Institute of Technology Sector – 55, Gurgaon, INDIA +91-1244750422
Assistant Professor Ansal Institute of Technology Sector – 55, Gurgaon, INDIA +91-1244750485
Associate Professor Deptt. of Computer Application H P University, Shimla, INDIA +919418001760
[email protected]
[email protected]
[email protected]
ABSTRACT Software reliability is an essential part of software engineering to ensure the quality of a system. There are various techniques, which can be used in building models for predicting quality attributes. This paper presents a Fuzzy model for software reliability prediction. We have proposed three parameters Availability, Failure Probability and Recoverability as an integrated measure of software reliability. Fuzzy Model provides a way to arrive at a discrete Reliability Non-functional requirement (NFR) in contrast to imprecise, vague and ambiguous. This model will help us to evolve intermediate stages between reliable state and unreliable state of a system. Results obtained by proposed model show that this is suitable for predicting software reliability of the software.
Categories and Subject Descriptors D.2.8 [Software Engineering]: Metrics – performance measure
General Terms Measurement, Performance and Reliability
2. FACTORS AFFECTING RELIABILITY
Keywords Non-functional Requirement, Reliability, Probability, Recoverability, Fuzzy Model
Availability,
Failure
1. INTRODUCTION Quantification of desirable properties of a system is an integral part of the software engineering. Since most of requirement analysis methods do not consider non-functional requirements, which leads to serious software development problems [1][2][3][4][6]. The problems faced because of negating non-functional requirements are more severe than the problems of functional requirements omissions [4][5]. Software reliability is major concern for quality system. It is the probability to perform failure free operation and produce correct output for a specified time under specified conditions. Once the system is installed, it is not possible to test system reliability in an operational environment because failure data collected in an uncontrolled tested environment may be limited. In this case, faults may not be necessarily removed as failures are identified. Therefore failures are considered as one of the factors affecting the software reliability [7]. Failure data need to be properly collected and measured during software development process for the assessment of reliability of software systems. There are various reliability growth models for assessing the reliability of a system. These models aim at predicting reliability of the software system during failure and removal process. Software reliability is measured by collecting the historical data and a distribution curve. As failures are identified, faults are removed from the system to increase reliability [8]. The fault tree uses fuzzy set theory for the quantification of uncertainty in order to make the system reliable. In a software development process, software is designed as an integration of sub-systems instead of a large system. The uncertainty of the overall system is found on the basis of uncertainties in the failure probability of sub-systems. Thus reliability requirements apply to the individual subsystems rather than the whole system. Software reliability is one of the most desirable quality attributes of the system. Thus its quantitative measurement is an
DOI: 10.1145/2047414.2047425
essential part of the development of a quality system. Estimation of software reliability becomes more important for those applications where safety is major consideration. Though available literature emphasizes the importance of non-functional requirements but implementation of non-functional requirements in the available literature is less. It is not possible to verify non-functional requirements at any point as we verify functional requirements. In this paper, we are bridging this gap between non-measurable/vague and precise/exact. To make reliability non-functional requirement measurable, we have used fuzzy model. In [9] also a fuzzy model is proposed to measure the reliability of the software. This model considers frequency of failure and recoverability as two metrics to assess reliability. After reviewing available literature, it is observed that reliability also depends upon availability non-functional requirement of the system. At present, there is no model that considers all these non-functional requirements to estimate the reliability of the system. Therefore, we propose a model, which integrates availability (AVAIL), failure probability (FPROB) and recoverability (RECOV) non-functional requirements and provides an assessment of reliability. Reliability is a key non-functional requirement, which can be divided into three Sub-NFRs (Availability, Failure Probability and Recoverability). Availability is one of the important metric used to assess the performance of a system, accounting for reliability of a system. It is defined as the ability to perform a required function under specified conditions at a given point of time or over a given time interval. It is related to the time that the system is expected to be available to the users. System must be alive for service when it is requested by endusers. Availability indicates how reliable system is during operational hours. It is defined as the probability that a system is in its expected functional condition and capable of being used in a specified environment. It deals with up-time hours and measures how often the system is alive. It is often expressed as up-time and downtime. Uptime refers to the capability to perform the intended task in a stated environment and downtime refers to not being able to perform the intended task in a stated environment [10]. Average Uptime Availability (A (t)) is the proportion of time that the system is operational and available for use. It represented by the mean value of the instantaneous availability, which is used to estimate the availability of the system at a specific time. t
1 A(t ) = ∫ A(u )du t0 Inherent Availability (AI) considers corrective maintenance downtime of the system and is represented as follows:
AI =
MTTF MTBF + MTTR
http://doi.acm.org/10.1145/2047414.2047425
ACM SIGSOFT Software Engineering Notes
Page 2
November 2011 Volume 36 Number 6
MTBF = Uptime / Number of System Failures MTTR = Corrective Maintenance Downtime / Number of System Failures Failure Probability is another important metric used to assess the reliability of a system. It is very important to know how often system fail to deliver expected level of service. Reliability is concerned with the occurrences and frequency of different types of failures. Reliability growth analysis uses times-to-failure data obtained during the testing phase of development process. Failure probability of the overall system is calculated by considering failure probabilities of all sub-systems. If operation of the system depends upon sub systems then failure probability is given by
P ( S ) = P( A) + P ( B) + ......... + P(n) If all subsystems are replicated means all subsystem fail at once then probability of failure is
P( S ) = P( A) n The Crow-AMSAA model can be used in the analysis of times-tofailure data [11]. Suppose a reliability growth program is represented by i sessions.
RULE BASE
Input 1 . . .
FUZZIFICATION MODULE
INFERENCE ENGINE
Input n Output
DEFUZZIFICATION MODULE
Figure 1. Block Diagram of Fuzzy Model
Working of Fuzzy Model A fuzzy model performs its operations in the following steps:
Fuzzification of Inputs: Fuzzification is the process of transformation of crisp inputs to the corresponding values in fuzzy domain. Fuzzifier takes the inputs and uses membership functions to determine the degree to which they belong to each of the appropriate fuzzy sets. The input is always a crisp numerical value.
Apply Fuzzy Operators:
Ki = the cumulative number of failures through session i.
Fuzzy operators are applied to compute the degree of support for each rule for the generation of a single crisp value. This value will then be applied to the output functions. The input to a fuzzy operator is two or more membership values from fuzzified input variables. The output is the single truth-value. Two commonly used fuzzy operators are MINMAX operators
The expected number of failures by the end of session i is:
Apply implication methods:
Ni = the number of trials during session i. Ti = the cumulative number of trials through session i. Mi = the number of failures during session i.
E [K i ] = λTi
β
The failure probability on a configuration basis, fi, is:
fi =
λTi β − Ti −β1 Ni
Recoverability is also another important metric used to assess the reliability of a system. There may be many ways to recover from a failure. Therefore, it is important to determine which failures may occur when system is available during specific time in stated environment and how to recover from these failures. Good architecture provides recoverability in the time specified in a service-level agreement.
3. FUZZY MODEL Fuzzy model is the best choice for managing vague, imprecise, doubtful, contradicting and diverging opinions. There are four modules (Rule Base, Fuzzification, Inference Engine, Defuzzification), which transform the crisp inputs into fuzzy values. Then these values are processed by inference engine in the fuzzy domain using the rule base created by domain expert. Finally the processed output is transformed from fuzzy domain to crisp domain by defuzzification module [12].
The shaping of the consequent based on the antecedent is termed as implications. The input for the implications processes is a single number given by the antecedent, and the output is a fuzzy set. Implication is applied for each rule. Two commonly used implication methods for AND are MIN (i.e. truncation) and PRODUCT (i.e. scaling the height of a fuzzy set). Two commonly used implication methods for OR are MAX (maximum) and probabilistic OR (algebraic sum).
Aggregate all outputs: Aggregation is a process by which fuzzy sets are combined in desirable way to produce a single fuzzy set. It is obtained by combining all the fuzzy sets that represents the output of each rule into a single fuzzy set. Aggregation occurs only once for each output variable. For our model the input of the aggregation processes is the list of truncated output functions returned by the implication process for each rule. The output of the aggregation process is one fuzzy set for each output variable.
Defuzzify: Defuzzification transforms the fuzzy values to crisp values. The input of the defuzzification process is a fuzzy set and the output is a single fuzzy number. Given a fuzzy set that encompasses a range of output values, one number needs to be returned thereby moving from a fuzzy set to crisp output.
It is represented as follows:
Figure 2. Fuzzy Reference System: Reliability Model
DOI: 10.1145/2047414.2047425
http://doi.acm.org/10.1145/2047414.2047425
ACM SIGSOFT Software Engineering Notes
Page 3
November 2011 Volume 36 Number 6
4. FUZZIFICATION The first step in the fuzzy inference system is to fuzzify inputs. The input parameters to the fuzzy system are represented as fuzzy sets. Fuzzy sets allow its elements to have degrees of membership. Thus element of a fuzzy set is represented as a pair (member, degree). A linguistic variable is used to represent degrees of “support” and “confidence” for members [13]. The inputs to the reliable system are the assumed values for Availability (AVAIL), Failure Probability (FPROB) and Recoverability (RECOV) and are taken on the higher side so that the resultant system remains reliable. The input parameters are considered to be of the same weight. All the input values for abovementioned parameters are defined as a fuzzy number by using suitable fuzzy sets. Levels of three input variables i.e. Availability, Failure Probability and Recoverability as fuzzy sets are given below: Availability = {VGOOD, GOOD, MODERATE, BAD, VBAD} Failure Probability = {VLOW, LOW, MED, HIGH, VHIGH} Recoverability = {HIGH, AVG, LOW} Then these fuzzy sets are represented by a membership function. This can be best achieved by deciding numerical range for the fuzzy input/output variables.
Figure 4. Fuzzification of input variable: Failure Probability Table 3. Fuzzy Variable Range for Recoverability Recoverability (RECOV) Numerical Range
Linguistic Variables
0-4
HIGH
1-9
AVG
6-10
LOW
Table 1. Fuzzy Variable Range for Availability Availability (AVAIL) Numerical Range
Linguistic Variables
0-3
VGOOD
2-5
GOOD
4-7
MODERATE
6-9
BAD
8-10
VBAD Figure 5. Fuzzification of input variable: Recoverability Similarly the output variable Reliability is represented by fuzzy variables as shown below: TABLE 4. Fuzzy Variable Range for Reliability Reliability
Figure 3. Fuzzification of input variable: availability
Numerical Range
Linguistic Variables
8-10
VHIGH
6-9
HIGH
4-7
MED
2-5
LOW
0-3
VLOW
Table 2. Fuzzy Variable Range for Failure Probability Failure Probability (FPROB) Range
Fuzzy Variables
0-3
VLOW
2-6
LOW
5-9
MED
8-12
HIGH
11-13
VHIGH Figure 6. Fuzzification of output variable: Reliability
DOI: 10.1145/2047414.2047425
http://doi.acm.org/10.1145/2047414.2047425
ACM SIGSOFT Software Engineering Notes
Page 4
5. RULE BASE FOR THE PROPOSED SYSTEM After the fuzzification of inputs, fuzzy operations are carried out in fuzzy domain. The proposed model integrates the effect of AVAIL, FPROB, and RECOV into a single measurable parameter, termed as software reliability, based on the following rule base. All possible combinations of inputs were considered which leads to 75 sets. The Reliability in case of all 75 combinations is classified as Very High, High, Medium, Low and Very Low by expert opinion. These lead to formation of 75 rules for the fuzzy model and rules are shown as below: 1. If (AVAIL is VGOOD) and (FPROB is VLOW) and (RECOV is HIGH) Then (Reliability is VHIGH). 2. If (AVAIL is VGOOD) and (FPROB is VLOW) and (RECOV is AVG) Then (Reliability is VHIGH). 3. If (AVAIL is VGOOD) and (FPROB is VLOW) and (RECOV is LOW) Then (Reliability is HIGH). 4. If (AVAIL is VGOOD) and (FPROB is LOW) and (RECOV is HIGH) Then (Reliability is VHIGH). 5. If (AVAIL is VGOOD) and (FPROB is LOW) and (RECOV is AVG) Then (Reliability is HIGH). 6. If (AVAIL is VGOOD) and (FPROB is LOW) and (RECOV is LOW) Then (Reliability is HIGH). 7. If (AVAIL is VGOOD) and (FPROB is MED) and (RECOV is HIGH) Then (Reliability is HIGH). 8. If (AVAIL is VGOOD) and (FPROB is MED) and (RECOV is AVG) Then (Reliability is MED). 9. If (AVAIL is VGOOD) and (FPROB is MED) and (RECOV is LOW) Then (Reliability is LOW). 10. If (AVAIL is VGOOD) and (FPROB is HIGH) and (RECOV is HIGH) Then (Reliability is MED). 11. If (AVAIL is VGOOD) and (FPROB is HIGH) and (RECOV is AVG) Then (Reliability is MED). 12. If (AVAIL is VGOOD) and (FPROB is HIGH) and (RECOV is LOW) Then (Reliability is LOW). 13. If (AVAIL is VGOOD) and (FPROB is VHIGH) and (RECOV is HIGH) Then (Reliability is MED). 14. If (AVAIL is VGOOD) and (FPROB is VHIGH) and (RECOV is AVG) Then (Reliability is LOW). 15. If (AVAIL is VGOOD) and (FPROB is VHIGH) and (RECOV is LOW) Then (Reliability is LOW). 16. If (AVAIL is GOOD) and (FPROB is VLOW) and (RECOV is HIGH) Then (Reliability is VHIGH). 17. If (AVAIL is GOOD) and (FPROB is VLOW) and (RECOV is AVG) Then (Reliability is HIGH). 18. If (AVAIL is GOOD) and (FPROB is VLOW) and (RECOV is LOW) Then (Reliability is HIGH). 19. If (AVAIL is GOOD) and (FPROB is LOW) and (RECOV is HIGH) Then (Reliability is HIGH). 20. If (AVAIL is GOOD) and (FPROB is LOW) and (RECOV is AVG) Then (Reliability is MED). 21. If (AVAIL is GOOD) and (FPROB is LOW) and (RECOV is LOW) Then (Reliability is MED). 22. If (AVAIL is GOOD) and (FPROB is MED) and (RECOV is HIGH) Then (Reliability is HIGH).
DOI: 10.1145/2047414.2047425
November 2011 Volume 36 Number 6
23. If (AVAIL is GOOD) and (FPROB is MED) and (RECOV is AVG) Then (Reliability is HIGH). 24. If (AVAIL is GOOD) and (FPROB is MED) and (RECOV is LOW) Then (Reliability is MED). 25. If (AVAIL is GOOD) and (FPROB is HIGH) and (RECOV is HIGH) Then (Reliability is MED). 26. If (AVAIL is GOOD) and (FPROB is HIGH) and (RECOV is AVG) Then (Reliability is LOW). 27. If (AVAIL is GOOD) and (FPROB is HIGH) and (RECOV is LOW) Then (Reliability is LOW). 28. If (AVAIL is GOOD) and (FPROB is VHIGH) and (RECOV is HIGH) Then (Reliability is MED). 29. If (AVAIL is GOOD) and (FPROB is VHIGH) and (RECOV is AVG) Then (Reliability is LOW). 30. If (AVAIL is GOOD) and (FPROB is VHIGH) and (RECOV is LOW) Then (Reliability is LOW). 31. If (AVAIL is MODERATE) and (FPROB is VLOW) and (RECOV is HIGH) Then (Reliability is HIGH). 32. If (AVAIL is MODERATE) and (FPROB is VLOW) and (RECOV is AVG) Then (Reliability is MED). 33. If (AVAIL is MODERATE) and (FPROB is VLOW) and (RECOV is LOW) Then (Reliability is MED). 34. If (AVAIL is MODERATE) and (FPROB is LOW) and (RECOV is HIGH) Then (Reliability is HIGH). 35. If (AVAIL is MODERATE) and (FPROB is LOW) and (RECOV is AVG) Then (Reliability is MED). 36. If (AVAIL is MODERATE) and (FPROB is LOW) and (RECOV is LOW) Then (Reliability is MED). 37. If (AVAIL is MODERATE) and (FPROB is MED) and (RECOV is HIGH) Then (Reliability is MED). 38. If (AVAIL is MODERATE) and (FPROB is MED) and (RECOV is AVG) Then (Reliability is LOW). 39. If (AVAIL is MODERATE) and (FPROB is MED) and (RECOV is LOW) Then (Reliability is LOW). 40. If (AVAIL is MODERATE) and (FPROB is HIGH) and (RECOV is HIGH) Then (Reliability is MED). 41. If (AVAIL is MODERATE) and (FPROB is HIGH) and (RECOV is AVG) Then (Reliability is LOW). 42. If (AVAIL is MODERATE) and (FPROB is HIGH) and (RECOV is LOW) Then (Reliability is LOW). 43. If (AVAIL is MODERATE) and (FPROB is VHIGH) and (RECOV is HIGH) Then (Reliability is MED). 44. If (AVAIL is MODERATE) and (FPROB is VHIGH) and (RECOV is AVG) Then (Reliability is LOW). 45. If (AVAIL is MODERATE) and (FPROB is VHIGH) and (RECOV is LOW) Then (Reliability is LOW). 46. If (AVAIL is BAD) and (FPROB is VLOW) and (RECOV is HIGH) Then (Reliability is MED). 47. If (AVAIL is BAD) and (FPROB is VLOW) and (RECOV is AVG) Then (Reliability is LOW). 48. If (AVAIL is BAD) and (FPROB is VLOW) and (RECOV is LOW) Then (Reliability is LOW).
http://doi.acm.org/10.1145/2047414.2047425
ACM SIGSOFT Software Engineering Notes
Page 5
November 2011 Volume 36 Number 6
49. If (AVAIL is BAD) and (FPROB is LOW) and (RECOV is HIGH) Then (Reliability is MED).
75. If (AVAIL is BAD) and (FPROB is VHIGH) and (RECOV is LOW) Then (Reliability is VLOW).
50. If (AVAIL is BAD) and (FPROB is LOW) and (RECOV is AVG) Then (Reliability is MED).
All 75 rules are inserted and a rule base is created. Depending on a particular set of inputs, a rule will be fired. In this model, Mamdani style inference mechanism has been used. Output variable Reliability is observed using MATLAB fuzzy tool Box for a particular sets of inputs. For a given set of input parameters [AVAIL, FPROB, RECOV] say [5, 6.5, 5], Rule Viewer helps to see the output reliability level generated i.e 3.5 corresponding to this assumed set of input variables which is shown below:
51. If (AVAIL is BAD) and (FPROB is LOW) and (RECOV is LOW) Then (Reliability is LOW). 52. If (AVAIL is BAD) and (FPROB is MED) and (RECOV is HIGH) Then (Reliability is MED). 53. If (AVAIL is BAD) and (FPROB is MED) and (RECOV is AVG) Then (Reliability is LOW). 54. If (AVAIL is BAD) and (FPROB is MED) and (RECOV is LOW) Then (Reliability is LOW). 55. If (AVAIL is BAD) and (FPROB is HIGH) and (RECOV is HIGH) Then (Reliability is LOW). 56. If (AVAIL is BAD) and (FPROB is HIGH) and (RECOV is AVG) Then (Reliability is LOW). 57. If (AVAIL is BAD) and (FPROB is HIGH) and (RECOV is LOW) Then (Reliability is VLOW). 58. If (AVAIL is BAD) and (FPROB is VHIGH) and (RECOV is HIGH) Then (Reliability is LOW). 59. If (AVAIL is BAD) and (FPROB is VHIGH) and (RECOV is AVG) Then (Reliability is VLOW). 60. If (AVAIL is BAD) and (FPROB is VHIGH) and (RECOV is LOW) Then (Reliability is VLOW). 61. If (AVAIL is VBAD) and (FPROB is VLOW) and (RECOV is HIGH) Then (Reliability is MED). 62. If (AVAIL is VBAD) and (FPROB is VLOW) and (RECOV is AVG) Then (Reliability is MED). 63. If (AVAIL is VBAD) and (FPROB is VLOW) and (RECOV is LOW) Then (Reliability is LOW).
Figure 7. Rule Viewer for the Reliability Model
6. Defuzzification Defuzzification is the process of transformation of the output from fuzzy domain to crisp domain. We defuzzify the fuzzified output to get crisp value of the output variable reliability. In our model, we are using Center of Gravity method. This method finds the centre of the area, which is determined by the joint membership function of the fuzzy action [14]. The overlapping area is taken only once. This requires the integration over 2-D surface, which results into reference cycle.
64. If (AVAIL is VBAD) and (FPROB is LOW) and (RECOV is HIGH) Then (Reliability is MED). 65. If (AVAIL is VBAD) and (FPROB is LOW) and (RECOV is AVG) Then (Reliability is LOW). 66. If (AVAIL is VBAD) and (FPROB is LOW) and (RECOV is LOW) Then (Reliability is VLOW). 67. If (AVAIL is VBAD) and (FPROB is MED) and (RECOV is HIGH) Then (Reliability is LOW). 68. If (AVAIL is VBAD) and (FPROB is MED) and (RECOV is AVG) Then (Reliability is LOW).
Figure 8. Surface view with AVAIL input as x axis and FPROB on Y axis and Reliability on Z axis
69. If (AVAIL is VBAD) and (FPROB is MED) and (RECOV is LOW) Then (Reliability is VLOW). 70. If (AVAIL is VBAD) and (FPROB is HIGH) and (RECOV is HIGH) Then (Reliability is LOW). 71. If (AVAIL is BAD) and (FPROB is HIGH) and (RECOV is AVG) Then (Reliability is LOW). 72. If (AVAIL is BAD) and (FPROB is HIGH) and (RECOV is LOW) Then (Reliability is VLOW). 73. If (AVAIL is BAD) and (FPROB is VHIGH) and (RECOV is HIGH) Then (Reliability is LOW).
Figure 9. Surface view with AVAIL input as x axis and RECOV on Y axis and Reliability on Z axis
74. If (AVAIL is BAD) and (FPROB is VHIGH) and (RECOV is AVG) Then (Reliability is VLOW).
DOI: 10.1145/2047414.2047425
http://doi.acm.org/10.1145/2047414.2047425
ACM SIGSOFT Software Engineering Notes
Page 6
November 2011 Volume 36 Number 6
[4] Ebert, C. Dealing with Nonfunctional in Large Software Systems. Annals of Software Engineering, 3, 1997, pp. 367-395. [5] Mylopoulos, J., Chung, L., and Nixon, B., “Representing and Using Non-functional Requirements: A Process-Oriented Approach”, IEEE Trans. on Software Eng, 18(6), pp:483-497, June 1992. [6] Kotonya, G. and Sommerville, I. Requirements Engineering: Processes and Techniques. John Willey & Sons, 1998. [7] Jalote Pankaj, Murphy Brendan, Garzia Mario and Errez Ben, “Measuring Reliability of Software Products”, Industrial track in Int. Symp. on Sw Reliability (ISSRE-2004), Saint Melo, France, Oct 2004 Figure 10. Surface view with FPROB input as x axis and RECOV on Y axis and Reliability on Z axis
7. Results and discussions Suppose we have the following crisp value inputs to the model: AVAIL = 2.7, FPROB= 2.5, and RECOV=3.5. These inputs are fed to the fuzzification module and after fuzzification of the given values we find that AVAIL = 2.7 belongs to fuzzy set VGOOD with membership grade 0.20 and to the fuzzy set GOOD with membership grade 0.47, FPROB=2.5 belongs to the fuzzy set VLOW with membership grade 0.33 and to the fuzzy set LOW with membership grade 0.25, RECOV = 3.5 belongs to fuzzy set HIGH with membership grade 0.25. With these inputs values, we find that following rules were fired as given in table 5: Table 5. Software Reliability calculation for a given input set
[8] Lyu M. R., " Software Reliability Engineering: A Roadmap”, Future of Software Engineering, 2007. FOSE '07 [9] Malik N. M., Mushtaq A., Khalid S., Khalil T., Malik F. M., ”Measurable & Scalable NFRs using Fuzzy Logic and Likert Scale”, Computing Research Repository - CORR, 2009 [10] http://www.weibull.com/SystemRelWeb/availability.htm [11] Paul Barringer, P.E.,”Predict Failures: Crow-AMSAA 101 and Weibull 101”, Proceedings of IMEC 2004 International Mechanical Engineering Conference, 2004 [12] Singh Y., Bhatia, P. K., Sangwan O., ”Predicting Software Maintenance Using Fuzzy Model”, ACM SIGSOFT Software Engineering Notes (2009), Volume 34 Issue 4, July 2009 [13] Aggarwal K.K, Singh Y., Chandra P. and Puri M., Measurement of Software Maintainability Using a Fuzzy Model, Journal of Computer Sciences 1 (4): 538-542, 2005
AVAIL
FPROB
RECOV
(2.7)
(2.5)
(3.5)
Reliability Level
Membership Grade of Reliability
VGOOD
VLOW
HIGH
VHIGH
Min (0.20,0.33, 0.25)=0.20
[15] Gandotra V., Singhal A., Bedi P., “A Step Towards Secure Software System Using Fuzzy Logic”, 2nd International Conference on Computer Engineering and Technology (ICCET), 2010
GOOD
LOW
HIGH
HIGH
Min (0.47,0.25, 0.25)=0.25
[16] L. M. Cysneiros and J. C. S. do Prado Leite., “Non-functional requirements: From elicitation to conceptual models”, IEEE Trans., Software. Eng., 30(5): 328–350, 2007.
Rule No.1 gives software reliability VHIGH to an extent of 0.20 and rule no. 19 gives reliability HIGH to an extent of 0.25.
8. Conclusion Many systems failed due to cost and schedule overrun because of negligence of non-functional requirements, as stakeholders demand high quality software, non-functional requirements are considered to be primary importance. So in this paper, we have incorporated fuzzy logic to measure the reliability of software. The proposed model has demonstrated integrated measure of software reliability based on the following three factors: Availability (AVAIL), Failure probability (FPROB) and Recoverability (RECOV).
9. REFERENCES [1] Yeh, R. et. al. Software Requirements: New Directions and Perspectives. Handbook of Software Engineering, 1984, pp. 519543. [2] Roman, G. C. Taxonomy of Current Issues in Requirements Engineering. IEEE Computer, 18(4), 1985, pp.14-22. [3] Landes, D. and Studer, R.. The Treatment of Non-Functional Requirements in MIKE. LNCS 989 (Software Engineering: ESEC’95), Springer-Verlag, 1995, pp. 294-306
DOI: 10.1145/2047414.2047425
[14] Fuzzy Logic Toolbox, User’s Guide version 2, The Math Works Inc., SA, July 2002.
[17] Prasad L., Gupta A. Badoria S., “Measurement of Software Reliability Using Sequential Bayesian Technique” Proceedings of the World Congress on Engineering and Computer Science 2009 Vol I WCECS 2009 [18] Yen J., Liu X., Teh and S.H Xiaoqing, “A Fuzzy Logic-based Methodology for the Acquisition and Analysis of Imprecise Requirements”, [19] Komeili M., Valizadeh M., Armanfard N. and Kabir E. “An optimal fuzzy system for feature reliability measuring in particle filter-based object tracking”, Computer Conference, 2009. CSICC 2009. 14th International CSI [20] Kirner T.G. , Davis A .M. , “Nonfunctional Requirements of RealTime Systems”, Advances in Computers, Vol 42 pp 1-37 1996. [21] Wiegers, K. (2003). Software Requirements, 2nd edition. Microsoft Press. [22] Cysneiros, L.M. and Leite, J.C.S.P. “Integrating Non-Functional Requirements into data model” 4th International Symposium on Requirements Engineering – Ireland June 1999. [23] Roman, G.-C. A Taxonomy of Current Issues in Requirements Engineering. IEEE Computer, 18(4), 1985, pp.14-22.
http://doi.acm.org/10.1145/2047414.2047425
