Software Reliability and Its Evolving Significance in the Overall Growth and Development of Software Engineering Tools and Methodologies

(1)

International Journal of Emerging Technology and Advanced Engineering

Website: www.ijetae.com (ISSN 2250-2459, ISO 9001:2008 Certified Journal, Volume 9, Issue 4, April 2019)

41 Software Reliability and Its Evolving Significance in the

Overall Growth and Development of Software Engineering

Tools and Methodologies

Dr. Abhaya Nand

Department of Computer Application, JSS Academy of Technical Education, Noida, India

Abstract— We are living in the age of digital world which is

distinctly characterized by high end sophisticated Software systems, Mobile applications, Artificial Intelligence, Cloud computing, Cognitive computing, Knowledge Engineering, Natural language processing etc. With the rapid advancement in the field of Information Technology Software organizations are trying to use the strength of these emerging and powerful technologies to develop/produce software systems/products at minimum cost with maximum quality in terms of reliability, portability, accessibility, maintainability etc. Software Organizations today are looking for efficient technologies that should be able to enhance the quality of Software systems. Despite the gloom in the global economy that has not spread any sector one thing that certainly seems to have stayed put on the agenda of most organization are the strategy sessions on how to increase reliability, productivity, maintainability while bringing the cost down. At present, Software development organizations are under continuous pressure to improve productivity as well as quality of software systems. In order to face global competition and retain the potential buyers Software organizations are compelled to develop reliable software and thereby enhancing the quality of developed product. Software Reliability is one of the most relevant terminologies which has been in widespread use by the Software Organizations for years. From its modest beginning in 1816-the word reliability was first coined and grew into an omnipresent attribute with qualitative and quantitative connotation that pervades every aspect of our present day technologically intensive world. Software failures of any kind must be avoided. In this paper, the emerging and evolving nature of Software reliability has been highlighted which will be certainly highly beneficial to develop a Unified framework for Software Engineering.

Keywords— Software Reliability, Quality, Productivity, Software Organizations, Software Failure, Software Engineering, Software system.

I. INTRODUCTION

Software reliability is one of the important attributes of the Software system which enables it to perform its intended tasks, functions and operations in a particular environment without experiencing any kind of failure or system crash.

Reliability is a relative attribute of the quality of the Software system and means continuity of service from the software. It depends on the consequence of any deviation from correct results at any instant. The word Reliability was coined by Samuel T. Coleridge in the year 1816. It was the modest beginning of Reliability, and grew into an omnipresent attribute with qualitative and quantitative connotation that pervades every aspect of present day technologically intensive world. Statistics and mass production were the enablers in the rise of this new discipline, and the catalyst that accelerated the coming of this new discipline was the unreliability of the vacuum tube. The foundational role of AGREE report in 1957 in the birth of reliability engineering, and discuss the consolidation of numerous efforts in the 1950s into a coherent new technical discipline [Saleh and Marais(2006)]. The Oxford English Dictionary defines it as „the quality of being reliable, that may be relied upon; in which reliance or confidence may be put; trustworthy, safe, sure‟. IEEE defines it as: Reliability is the ability of a system or component to perform its required functions under stated conditions for a specified period of time.

(2)

International Journal of Emerging Technology and Advanced Engineering

42

The computer revolution is fueled by an ever more rapid technological advancement. Today, computer hardware and software permeates our modern society. Computers are embedded in aircraft, automobiles, telecommunications appliances, home appliances, defense system etc. These demand high performance hardware and high quality software for making improvements and breakthroughs. We can look at virtually any industry- automotive, oil, avionics, telecommunications, banking, semiconductors, pharmaceuticals- all these industries highly dependent on computers for their basic functions. When the requirements for and dependencies on computers increase, the possibility of crises from computer failures also increases. The impact of these failures ranges from inconvenience (e.g., malfunctions of home appliances) to loss of life. Needless to say, the reliability of computer systems has become a major concern for our society.

Systems of the real world are generally nonlinear. Linearity has to be regarded either as a very special case, or as an approximation of physical reality. Then methods of nonlinear analysis need to be developed to deal with the application of models. Computational methods are necessary to solve mathematical problems generated by the application of models to the analysis and interpretation of systems of real world. Computational methods can be developed only after a deep analysis of the qualitative properties of a model and of the related mathematical problems.

Scientists/researcher use mathematics to describe real phenomena, and in fact much of this activity constitutes mathematical modeling. As computers become cheaper and powerful and their use becomes more widespread, mathematical models play an increasingly important role in science. Unfortunately, there is no definite algorithm to construct a mathematical model that will work in all situations. Modeling is sometimes viewed as an art. It involves taking whatever knowledge you may have of mathematics and of the system of interest and using that knowledge to create something. Since everyone has a different knowledge base, a preferred bag of tricks, and a unique way of looking at problems, different people may come up with different models for the same system. There is usually plenty of room for argument about which model is best. It is very important to understand at the outset that for any real system, there is no perfect model. A model may consist of algebraic, differential, or integral equations, stochastic processes, geometrical structures, etc. Once a model is constructed, one generally needs to do some analysis or computation to make it produce results.

The results are often approximate solutions to the equations of interest. Since the model is supposed to somehow represent the real system, it should be possible to interpret results from the model in terms of observable properties of the system. This is not always a trivial step, but it must be done if the results are to be of any use. Interpretation of the results should lead to predictions or explanations about the real system, which can then be tested against real observations to determine the effectiveness of the model.

II. SOFTWARE ENGINEERING FRAMEWORK

(3)

International Journal of Emerging Technology and Advanced Engineering

43

III. PROCESS MODELS

Software Process model is the backbone of Software Engineering framework which requires the various tasks/activities to be accomplished in a well defined manner. A software process is a set of activities that leads to the production of a software product. The objective of

Software Process is to facilitate improvement in the quality, productivity, performance and assessment of the software development process. A software process model is an abstract representation of a software process. The terms "software process model" and "software engineering paradigm" are used interchangeably in the literature. Each process model represents a process from a particular perspective, and thus provides only partial information about that process. Some of the software process models based on different paradigms like: the Waterfall Model, the Boehm‟s Spiral Model, Incremental model, Concurrent Development Model, etc. However, all these models are based on a set of related software engineering activities that form the generic process framework. A software developer needs to achieve the desired result by following this particular process framework. The various activities of process framework are described as below:

Feasibility Study/Analysis: In this phase, the development team visits the customer and studies their system. They investigate the need for possible software automation in the given system. This process is also known as feasibility study. By the end of the feasibility study, the team furnishes a document that holds the different specific recommendations for the candidate system. It also includes the personnel assignments, costs, project schedule, target dates etc...

Software Requirement Specification: All possible requirements of the system to be developed are captured in this phase. Requirements are set of functionalities and constraints that the end-user (who will be using the system) expects from the system. The requirements are gathered from the end-user by consultation, these requirements are analyzed for their validity and the possibility of incorporating the requirements in the system to be development is also studied. Finally, a Requirement Specification document is created which serves the purpose of guideline for the next phase of the model.

System Design: Before a starting for actual coding, it is highly important to understand what we are going to create and what it should look like? The requirement specifications from first phase are studied in this phase and system design is prepared.

System Design helps in specifying hardware and system requirements and also helps in defining overall system architecture. The system design specifications serve as input for the next phase of the model.

Coding & Implementation: On receiving system design documents, the work is divided in modules/units and actual coding is started. The system is first developed in small programs called units, which are integrated in the next phase. The design must be translated into a machine-readable form. The code generation step performs this task. If the design is performed in a detailed manner, code generation can be accomplished without much complication. Programming tools like compilers, interpreters, debuggers etc... are used to generate the code. Different high level programming languages like C, C++, Pascal, Javaare used for coding. With respect to the type of application, the right programming language is chosen.

Testing and Integration: As specified above, the system is first divided in units which are developed and tested for their functionalities. These units are integrated into a complete system during Integration phase and tested to check if all modules/units coordinate between each other and the system as a whole behaves as per the specifications. After successfully testing the software, it is delivered to the customer.

Operation & Maintenance: This phase is virtually never ending phase (Very long). Generally, problems with the system developed (which are not found during the development life cycle) come up after its practical use starts, so the issues related to the system are solved after deployment of the system. Not all the problems come in picture directly but they arise time to time and needs to be solved; hence this process is referred as Maintenance.

The above mentioned set of activities are applicable throughout the software process for every project and hence is termed as umbrella activities. These activities are useful for software engineer for developing software.

(4)

International Journal of Emerging Technology and Advanced Engineering

44

The fixing/removal of fault during the software testing may be identified as a fault removal process. The reliability of the software will be increased during the testing phase as more and more faults are removed. The reliability improvement phenomenon is also called Reliability Growth. However, the assessment of the software reliability is not easy. The level of reliability is usually estimated by using some appropriate models applied to the empirical data from the software failure/removal history[M. Xie(1991)]. Thus, Software Reliability Growth models measures and predicts the improvement of software reliability through the testing process. The growth model represents the reliability or failure rate of a system as a function of time or the number of test cases. A proliferation of software reliability models has emerged since the early 1970s and over hundreds of models have been developed for estimating and predicting reliability of software. There are two types of software reliability models - those that attempt to predict software reliability from

design parameters and those that attempt to predict software reliability from test data. The first type of models are usually called "Defect Density Models" and use code characteristics such as lines of code, nesting of loops, external references, input/outputs, and so forth to estimate the number of faults in the software. The second types of models are usually called "Software Reliability Growth Models" since the number of faults (as well as the failure rate) of the software system reduces when the testing progresses, resulting in growth of reliability[Wood(1996)].

4.1 Literature Survey of continuous SRGMs

Increasing dependence of mankind on computers and computer-based systems attracted the attention of the software engineers and reliability researchers in early 1970s to study the reliability aspect of software systems. One of the earliest models was due to Musa (1975) assuming that the time between failures is exponential and the debugging is perfect. The author also proposed another well-known model known as Logarithmic Poisson Model. These models assumed that the failure is independent of the previous failure and time. Goel and Okumoto [1979] proposed time dependent NHPP based SRGM assuming that the failure intensity is proportional to the number of faults remaining in the software. The model simply described exponential failure curves. Ohba [1984] refined the Goel and Okumoto model (1979) by assuming that the fault detection / removal rate increases with time and that there are two types of faults in the software. SRGM proposed by Bittanti et al. [1988] and Kapur and Garg [1992] have similar forms as that of Ohba [1984] but were developed under different set of assumptions.

Yamada et. al. [1983] proposed an SRGM defining the failure observation and fault removal as a two-phase process consisting of failure detection and then its eventual removal on isolation. Whereas, Kapur and Garg [1992] describe a fault removal phenomenon, where they assume that during a removal process of a fault some of the additional faults might be removed without these faults causing any failure. These models can describe both exponential and S-shaped growth curves and therefore are termed as flexible models.

In this section we describe some of the existing SRGMs in the literature. Some of the general assumptions (apart from the some special ones for specific models discussed) for the models discussed below are as follows:

Models Assumptions

1. Software system is subject to failure during execution caused by faults remaining in the system.

2. The number of faults detected at any time instant is proportional to the remaining number of faults in the software.

3. The fault detection/ removal phenomenon is modeled by NHPP.

4. All faults are mutually independent from failure detection point of view.

Models Notations

a : expected total number of fault existing in the software before testing.

b : constant fault detection/removal rate per remaining fault per unit time.

m(t) : expected mean number of failures/removal by time t,

m

(0)



0

.

mf (t) : expected mean number of failures observed by time t,

m

_f

(0)



0

.

mi (t) : expected mean number of faults isolated by time t,

m

_i

(0)



0

.

mr(t) : expected mean number of faults removed by time t,

m

_r

(0)



0

.



₀ : initial fault intensity.



: failure intensity decay parameter.

(5)

International Journal of Emerging Technology and Advanced Engineering

45 

: constant rate of error generation,

0  



1

.

W(t) : Cumulative testing effort in the time interval (0,t],

d

_{W t}

_{( )}

_{w t}

_{( )}

dt



W*(t) : W(t)-W(0)

 : Constant parameter in logistic function.

N : Total amount of testing effort consumed.

4.1.1. SRGMs under Perfect Debugging Environment

SRGMs under perfect debugging environment assume that a fault is removed after a fault is detected during testing with no new faults are introduced in the software. Some of the models proposed under this category are discussed below. One of the earliest SRGM was proposed by Musa(1975) and Goel & Okumoto(1979).

Basic Execution Time Model [Musa (1975)]

Basic execution time model is proposed by Musa(1975). This model assumed that failure intensity to decay exponentially with execution time of the software

( )

exp(

)

o

dm t

bt

dt







…(1.1)

where



₀ is the initial fault intensity and is the rate of decrease of failure intensity per unit execution time. Solving the differential equation (1.1), the mean value function is given by

( )

o

(1 exp(

))

m t

bt

b







…(1.2)

The initial failure intensity



_o

= a.b, where a is the expected number of failures at infinite execution time. The parameter b may be viewed as the constant hazard rate that characterizes any failure.

A. Exponential SRGM [Goel and Okumoto(1979)]

This model is proposed by Goel and Okumoto(1979). It is also called as exponential model. They assumes that each time a software failure occurs, the fault causing the failure is immediately removed, and no new fault is generated during testing along with the above mentioned assumptions. The differential equation based on the assumptions is given by:

( )

[

( )]

dm t

b a m t

dt





…(1.3) Solving differential equation (1.3) under the initial condition

m

(0)



0

gives the following mean value function for NHPP

( )

(1

bt

)

m t



a



e



…(1.4)

It is very popular due to its simplicity. In this model, the efficiency of the testing team is uniformly increasing.

Two stage Yamada S-shaped model (1983)

Yamada et al (1983) in their model assumed that a time delay exists between fault failure/detection and fault removal/correction processes. In the first stage the rate of change of fault failure/detection is proportional to the mean number of undetected faults remaining in the software and it can be expressed by following differential equation:

f

f dm ( t )

b( a m ( t ))

dt   …(1.5) Solving equation (1.5) with the initial condition mf(0) =

0 the mean number of fault failure/detection is given by



bt



f

m ( t ) a 1 e





 …(1.6)

In the second stage the fault removal/correction rate at any time is proportional to the mean number of fault failure/detected but not yet removed/corrected faults remaining in the software and it can be expressed by following differential equation:





r

f f

dm ( t )

b m ( t ) m ( t )

dt   …(1.7) Solving equation (1.7) with the initial condition mr(0) =

0 the mean number of fault removed/corrected till time t is given by:



bt



r

m ( t )a 1 ( 1 bt )e   …(1.8)

The model can be formulated alternatively as a single stage process by assuming the fault detection rate as

2

(6)

International Journal of Emerging Technology and Advanced Engineering

46

2

( )

(

( ))

1

r

dm t

b t

a m t

dt

bt









_



_









…(1.9)

It is observed that 2

1 b t

b

bt





as

b





. After

solving equation (1.9) with the initial condition mr(0) = 0, the mean number of fault removed/corrected is same as equation (1.8).

Inflection S-shaped Model [Obha(1984)]

This model is best suited when the software contains fairly large number of errors and the effort increases with testing period. This is proposed by Obha(1984). In this model it is assumed that there are two types of errors in the software, mutually independent and mutually independent. The mutually independent faults lie on different execution paths and mutually dependent faults lie on the same execution path. The dependent faults are not detected until independent faults are removed. The differential equation describing the failure phenomenon for the model is:

( )

( )[

( )]

dm t

b t a m t

dt





…(1.10)

where the fault removal rate

b

(t

)

is defined as:

)

(

)

(

t

b

t

b





,

a

t

m

r

t

)

(

1 )

(

)

(









,



₍

₀

₎



₀

and



₍



₎



₁

…(1.11)

and



(

t

)

is the inflection factor and b is the fault removal rate in the steady state.

Solving equation(1.10) under the initial condition

0 )

0 (



m

we get:

1 (1

)

( )

where

;0

1

bt bt

e

r

m t

a

r

e



 



_



_







 



_







(1.12)

Here r is called the inflection parameter



₀



_r



₁



and represents the proportion of independent faults present in the software. Depending upon the value of r, the SRGM (1.12) can describe both exponential and S-shaped growth curves and hence is called a flexible SRGM.

SRGM for Error Removal Phenomenon [Kapur and Garg(1992)]

This model is due to Kapur and Garg model(1992). It is based on assumption that on a failure the detection of the error causing failure also results in the detection of some additional errors without these errors causing any failure. Hence the rate of the number of errors detected per unit time(fault removal rate) for the model can be written as:





( )

(

( ))

( )

r

dm t

m t

p a m t

q

a m t

dt







a



(1.13)

Solving above equation with initial condition _mr(0) = 0 we get the solution as:





(

)

(

)

1 ( )

1 p q t

r

_{p q t}

e

m t

a

q p e

 



_











_







…(1.14)

If q = 0 the model reduces to G-O model. The number of failures by time t is given by:





0 (

)

( )

t

( )

ln

f

r

_{p q t}

ap

p q

m t

p a m x dx

q

_{p qe}

 



_















_









(1.15)

The model can be derived alternatively if we assume logistic learning fault detection rate given by

_{( )}

1

bt

b

b t

e









with b = (p+q) and β = (q/p), where

p, q are proportionality constants.

Three-Stage Correction Process

Software testing phase can actually be considered as a three-stage process namely fault failure/detection, fault isolation and fault removal correction. When software fault is detected it takes time and effort to isolate the fault, which has caused software failure. Hence fault isolation can be considered as the second stage of testing phase. The software team takes time to remove/correct the detected faults, which depends on many factors varying from complexity of fault to the skills of testing team.

(7)

International Journal of Emerging Technology and Advanced Engineering

47

K-3 Stage Erlang -Model with constant fault correction rate (Kapur et. al. (1995a))

This model is due to Kapur et. al.(1995a). Software testing phase can actually be considered as a three-stage process namely fault failure/detection, fault isolation and fault removal/correction. The first stage illustrates fault failure/detection process in which the software fails i.e. it does not produce the desired output when tested on several test-cases. In the first stage the rate of change of fault failure/detection is proportional to the mean number of undetected faults remaining in the software and it can be expressed by following differential equation:





f f

m ( t )





b a



m ( t )

…(1.16)

Solving equation (1.16) with initial condition mf(0) = 0 we get:



bt



f

m ( t )a 1 e  …(1.17) Then the fault is isolated by the software team in the second stage of the software-testing phase. The time required to isolate the fault is delay between the fault failure/detection and fault isolation. The mean number of fault isolated is proportional to the mean number of fault failure/detected but not yet isolated faults remaining in the software and it can be expressed by following differential equation:





i f i

m ( t )





b m ( t ) m ( t )



…(1.18)

Solving equation (1.18) with initial condition mi(0) = 0 we get the mean number of fault isolated as:



bt



i

m ( t )a 1 ( 1 bt )e   …(1.19) In the third stage of testing phase, isolated fault is then corrected. The fault removal/correction rate is proportional to the number of faults isolated but yet not removed/corrected faults remaining in the software and it can be expressed by following differential equation:





r i r

m ( t )





b m ( t ) m ( t )



…(1.20)

Solving equation (1.20) with initial condition mr(0) = 0 we get the mean number of fault removal/correction as:

2 2 bt r

b t m ( t ) a 1 1 bt e

2



   

 

 _ _   _ _

 

…(1.21)

Generalized Erlang SRGM[Kapur et al(1995a)]

The time delay between the failure observation and subsequent removal is assumed to represent the severity of the fault. The more severe the fault, more the time delay. Faults are classified as a simple fault if the time delay between failure observation, isolation and removal is negligible, whereas if there is a time delay between failure observation and fault isolation, the fault is identified as a

hard fault. Furthermore if there exist a time delay between failure observation and isolation of a fault and a time delay between fault isolation and its removal, then the fault is classified as a complex fault. The total removal phenomenon is the superposition of these three processes.

Assuming a to be the expected number of total faults in the software and pi , i =1,2,3 be the proportion of simple, hard and complex faults in a software system (ap1 + ap2 +

ap3 = a) and b1, b2, b3 to be the fault detection rates for simple, hard and complex faults.

The simple fault removal process is modeled as:





1

1 1 1

( )

dm t

b ap

m t

dt





…(1.22)



1



1

( )

₁

1

b t

m t



ap



e

 …(1.23)

The hard fault detection and removal is modeled as a two-stage process





2

2 2 2

( )

f

dm

t

b ap

m

t

dt





(1.24)





( )

2 _{( )} _{( )}

2 2 2

dm t

r _b _m _t _m _t

f r

dt   …(1.25)



2



2

( )

2

( )

2

1 (1

2

)

b t r

m t



m t



ap

 

b t e

 (1.26)

The complex fault removal process is modeled as a three-stage process





3

3 3 3

( )

f

dm

t

b ap

m

t

dt





…(1.27)





3

3 3 3

( )

i

f i

dm

t

b m

t

m

t

dt





…(1.28)





3

3 3 3

( )

r

i r

dm

t

b m t

m

t

(8)

International Journal of Emerging Technology and Advanced Engineering

48

2 2 3

3 3 3 3

3 ( )

( )

1 1

2

b t

r

b t

m t



m t



a p



_



  





b t





e







_









(1.30)

The mean value function of the SRGM is:

)

(

)

(

)

(

)

(

t

m

₁

t

m

₂

t

m

₃

t

m





,

ap

₁



ap

₂



ap

₃



a

…(1.31) The mean value function of SRGM can be generalized to include n different types of faults depending upon their severity:







 





























n

i

j

j i t

i b i

j

t

b

e

a

t

m

1

0

!

)

(

1 )

(

_…(1.32)

V. CONCLUSION

In view of above facts and figures it can be concluded that the emerging and evolving nature of Software reliability has contributed a lot in enhancing the quality of Software development process which has been the greatest challenge to software organizations. Every technology seems to inhabit its own time scale and Software reliability is not an exception to this. So in order to place Software reliability in its right perspective, Software Engineers need to understand each and every important points involved and also the important relationship between Software reliability and Software Engineering. This paper explained the term Software reliability in the context of its evolution and emergence as an important software attribute, placed the field within its historical context, and finally described its significant contributions in developing a Unified framework for Software Engineering.

REFERENCES

[1] Bittanti S, Bolzern P, Pedrotti E, Scattolini R. “A flexible modelling approach for Software reliability growth” Software Reliability Modelling and Identification (Ed.) G. Goos and J. Harmanis, Springer Verlag, Berlin, 1988, 101-140.

[2] Brooks WD, Motley RW. “Analysis of discrete software reliability models - Technical Report (RADC-TR-80-84)” 1980; New York: Rome Air Development Center.

[3] Goel AL, Okumoto K. “Time dependent error detection rate model for software reliability and other performance measures” IEEE Transactions on Reliability 1979; R-28 (3).

[4] Kapur PK, Garg RB. “A software reliability growth model for an error removal phenomenon” Software Engineering Journal 1992; 7: 291-294.

[5] Kapur PK, Garg RB, Kumar S. “Contributions to hardware and software reliability” 1999; Singapore: World Scientific Publishing Co. Ltd.

[6] Kapur P.K., Jha P.C. and Gupta Amit. “Optimal Release Policy of a Software Fuzzy Environment” Published in the Proceeding Mathematical Modeling, Application Issue and Analysis, held BITS Pilani,8-9 th oct.-2004,pp125-134

[7] Kapur,P.K.Goswami, D.N.Gupta Amit “A Software Reliability Growth Model for Distributed Development Environment with Learning Function and Errors of DiffferentSeverity” Published in the Proceeding Mathematical Modeling ,Application Issue and Analysis,BITS Pilani,8-9 th oct.-2004,pp 99-110

[8] Kapur P.K., Goswami D.N., Bardhan A.K. “A Flexible Delayed s-Shaped Software Reliability Growth Model”, CSI

[9] Kapur, P. K., Bardhan AK and O. Shatnawi “Software Reliability Growth Model with fault dependency using lag function” A. K. Verma edited Proceedings of ICQRC-2001 during December 27-28, 2001, Hotel Le Royal Meridian, Mumbai, R53: 1-7, 2001.

[10] Kapur P.K.,Gupta Anu,Yadavalli V.S.S.“Software Reliability Growth Modeling Using Power Function of Testing Time” International Journal of Operations and Quantitative Management, Vol.12, No.2, June 2006,pp.127-140

[11] Kumar Deepak (2009) ,” Modelling and Optimization Problems in Software Reliability” Ph. D. thesis, University of Delhi, Delhi. [12] Musa JD, Iannino A, Okumoto K. “Software reliability:

Measurement, Prediction, Applications” 1987; New York: Mc Graw Hill

[13] Pham H. “System Software Reliability” 2006; Springer -Verlag Singapore Pte. Ltd