| P.Kubat, "Assessing Reliability of Modular Software", Operations Research Letters, Vol.8, 1989, pp. 35-41. |
....matrix of the composite model. Basically, it is equivalent to the sum of the reliabilities of all paths that start at the entry node and end at the exit node S, including the possibility of infinite number of paths due to the loops that might exist between two or more components. Kubat model [2] characterizes software architecture by an SMP defined as follows. Transitions between components follow a DTMC with transition probability matrix P and the sojourn time in state i has pdf g i (t) Assuming constant failure intensity i , the reliability of component i is estimated as R i = R 1 ....
.... of component i is estimated as R i = e Gamma R V i t i 0 i (t) dt : Thus, the reliability of the overall application becomes R = Q n i=1 R i : Note that, the special case of this model that assumes constant failure intensities i is equivalent to the special case of Kubat model [2] that assumes deterministic execution times g i (t) t i . Now, consider the models of continuously operating software applications that describe software architecture with an irreducible CTMC [4] 5] For the sake of comparison we discuss Laprie model [5] since it considers only component ....
P.Kubat, "Assessing Reliability of Modular Software", Operations Research Letters, Vol.8, 1989, pp. 35-41.
....out of components they propose a variation of the above model such that the states of the CTMC are defined by more than one component under execution at a time. The system makes a transition between the states when there is a start or end of the execution of one or several components. Kubat model [27] This model considers the case of a terminating software application composed of n modules designed for K different tasks. Each task may require several modules and the same module can be used for different tasks. Architecture. Transitions between modules follow a discrete time Markov chain such ....
....Poisson process model using a time dependent failure intensity i (t) determined by block coverage measurements during the testing of the application together with the fault density approach. Solution method. The expected number of visits to module i, denoted by V i , is computed as in [27] by solving the following system of linear equations V i = q i n X j=1 V j p ji where q denotes the initial state probability vector. The reliability of module i, given time dependent failure intensity i (t) and the total expected time V i t i spent in the module per execution of the ....
[Article contains additional citation context not shown here]
P.Kubat, Assessing reliability of modular software, Operations Research Letters, 8 (1989) 35-41.
....the system failure rate becomes eq P n i=1 i i ; where the steady state probability vector = i ] is the solution of B 0 = 0. This result has a simple physical interpretation having in mind that i is the proportion of time spent in state i when no failure occurs. Kubat model [9] This model considers the case of a software composed of M modules designed for K different tasks. Each task may require several modules and the same module can be used for different tasks. Architecture. Transition between modules follow a DTMC such that with probability q i (k) task k will ....
P.Kubat, Assessing reliability of modular software, Oper. Research Letters, 8, 35-41 (1989).
....rate ij s Sojourn time of a call in module i with product j = ij x otherwise. 0 selected; is module of product if 1 i j The failure rate and the sojourn time given by COTS s developers would be estimated during the system prototyping, module testing, and the early stage of integration testing [8]. The call arrival rate, maximumallowable system failure rate and delay will be estimated and then described in a specification. In the underlying model, the initial cost for the modular system development includes the procurement cost of COTS products, where each module should be configured by a ....
P. Kubat, "Assessing reliability of modular software", Operations Research Letters, vol. 8, 1989, pp. 35--41.
....its internal structure. The counterpart of this is, of course, the fact that more sophisticated data is needed to use it. With respect to the black box approach, just a few papers have been published on structural software reliability models. A representative sample is [12] 13] 2] 9] 10] 15] [7], 1] This paper adopts this point of view and propose a general model as an attempt to answer some objections that have been made to this approach, namely (i) the fact that previous published models may need unrealistic assumptions to be applied and (ii) the analytic and algorithmic difficulties ....
....Component definition is a user level task, depending on the system being analyzed, on the possibility of getting the required data, etc. The first idea is to identify the components with the standard software engineering concept of module, as it is done for instance in [12] 13] 2] 1] [7] (in other papers, some slightly different choices are done, but the idea is basically the same. The system structure is then represented by the call graph of the set of modules. The main problem with this approach is that the Markovian (or semi Markovian) assumption may be too much unrealistic. ....
P. Kubat. Assessing reliability of modular software. Opns Res. Letters, 8:35--41, 1989.
....methods can be used to describe how software is physically decomposed. The two most popular categories of software design methods are Structured Design (SD) and Object Oriented Design (OOD) Previous work on structural reliability models assumes that software is designed according to SD principles [2, 5, 6, 7, 12, 13]. The proposed model assumes that software is designed according to OOD principles. 2.1 Model Components In this first attempt at using OOD to define the components and relationships of the structural model, it is found that OOD methods such as Booch s [1] or Rumbaugh et al. 11] are too ....
....Such relationships are the basis of methods for calculating a total software system reliability figure from the reliability of the components. The relationships at the base of the current structural model follow one of two trends: execution path based [12, 13] or module transition based [2, 5, 6, 7]. Note that the word module here is loosely employed to include any definition of module. Although the practicality of the execution path approach is questionable, execution paths are preferred to the transition probability models because the Markov process basis of the latter does not reflect ....
P. Kubat, "Assessing Reliability of Modular Software", Operations Research Letters, Vol 8 No. 1, February 1989, pp. 35-41.
Online articles have much greater impact More about CiteSeer.IST Add search form to your site Submit documents Feedback
CiteSeer.IST - Copyright Penn State and NEC