5.3 Design Guidelines for Software Quality
5.3.4 Software Quality Growth Models
Since the beginning of the seventies, a large number of models have been proposed to describe the occurrence of software defects during operation of complex equip- ment and systems. Such an occurrence can generate a failure at system level and appears often randomly distributed in time. For this reason, modeling has been done in a similar way as for hardware failures, i.e., by introducing the concept of software failure rate. Such an approach may be valid to investigate software quality
P0(t )=e−nλt; P1(t )=ne−nλt( eλt−1) P2(t )=n(n−1)e−( n−1)λt(eλt/ 2+e−λt/ 2−1)
P3( t)=n (n−1) (n−2) e−( n−2)λt( eλt/ 6+e− λt/ 2−e−2λt/6−1 /2) 1.0
0.5
0 t P (t) i
P (t) 0
P (t) 1
P (t)
2 P (t) 3
2 / n λ
1 / n λ 3 / n λ
Figure 5.3 P ( )i t =Pr{i defects have been removed up to the time t |n defects were present at t =0} for i=0 -3 and n=10 (the time interval between consecutive occurrence points of a defect is exponentially distributed with parameter λi=(n−i) )λ
growth during software validation and installation, as for the reliability growth models developed in the sixties for hardware (Section 7.7). However,
from the considerations in Sections 5.3.1-5.3.3, the main target should be the development of software free from defects, and thus to focus effort on defect prevention rather than on defect modeling, see e.g. [5.78].
Because of their use in investigating software quality growth, this section introduces briefly some basic models known for software defect modeling (see Section 7.7 for further possible models, and p. 168 for some critical remarks):
1. Between consecutive occurrence points of a software defect, the "failure rate"
is a function of the number of defects present in the software. This model leads to a death process and is known as Jelinski-Moranda model. If at t=0 the software contains n defects, the probability P ( )i t =Pr{i defects have been removed up to the time t n defects were presentat t=0} can be calculated recursively from (Problem A7.4 in Appendix A11)
P ( )0 , P ( ) ( ) ( ) 1( ) , , ,
0
1 1
t e n t i t n i e n i xPi t x dx i n t
= − λ =∫ − + λ − − λ − − = … , (5.3)
or directly as
P ( )i t n ( e t i)e (n i) t, i , ,n
=( )i 1− −λ − − λ = …1 . (5.4)
Figure 5.3 shows P ( )0 t to P ( )3 t for n=10. This model can be easily extended to cover the case in which the parameter λ also depends on the number of defects still present in the software.
2. Between consecutive occurrence points of a software defect, the "failure rate"
is a function of the number of defects still present in the software and of the time elapsed since the last occurrence point of a defect. This model generalizes Model 1 above and can be investigated using semi-Markov processes (Appendix A7.6).
Zn''−1 Zn''
Zn Zn−1 Zn' Zn'−1
Z0'' Z1'
Z1''
Z0 Z1
Figure 5.4 Simplified modeling for the time behavior of a system whose failure is caused by a hardware failure ( Zi→Zi'') or by the occurrence of a software defect ( Zi→Zi')
3. The flow of occurrence of software defects constitutes a nonhomogeneous Poisson process (Appendix A7.8.2). This model has been extensively investi- gated in the literature, together with reliability growth models for hardware, with different assumptions on the form of the process intensity (Section 7.7).
4. The flow of occurrence of software defects constitutes an arbitrary point proc- ess. This model is very general but difficult to investigate.
Models 1 and 2, above, my have a theoretical foundation. However, in practical applications they often suffer from the lack of information, for instance about the number of defects actually present in the software, and data. Also they do not take care of the criticality (effect at system level) of the defects still present in the software under consideration (several minor faults are in general less critical than just one major fault). The use of nonhomogeneous Poisson processes is discussed in Section 7.7, see e.g. also [6.1, A7.30] for some critical comments. As a general rule,
models based on the remaining number of defects in the software (errors at start), as well as oversimplified models, e.g. [5.80], should be avoided.
For systems with hardware and software, one can often assume that defects in the software will be detected and eliminated one after the other. Only hardware fail- ures should remain. Figure 5.4 shows a possibility to take this into account [6.10].
However, interdependence between hardware and software can be greater as as- sumed in Fig. 5.4. Also is the number (n) of defects in the software at the time t =0 unknown and by eliminating a software defect new defects can be introduced.
For all the above reasons, modeling software defects as well as systems with hardware and software is still in progress.
HW SW
E E
Reliability and availability analysis of repairable systems is generally performed using stochastic processes, including Markov, semi-Markov, and semi-regenerative processes. Acomprehensive introduction to these processes is in Appendix A7 with reliability applications in mind. Equations used for Markov and semi-Markov models are summarized in Table 6.2. This chapter investigates many of the reliabi- lity models useful for practical applications, some of which were developed for this book (Sections 6.8 & 6.10). Reliability figures at system level have indices S i(e.g.
MTTFS i), where S stands for system (the highest integration level of the item considered) andi is the state entered at t=0. After a discussion on assumptions&
conclusions,Section6.2investigates theone-itemstructureundergeneral conditions.
Sections 6.3-6.6 deal with series,parallel, and series-parallel structures. To unify models andsimplifycalculations,itis assumed that the system has onlyonerepair crew and nofurtherfailuresoccuratsystemdown. Startingfromconstantfailure&
repair rates(Markov models), generalization is performed step by step (beginning with the repair rates) up to the case in which the process involved is regenerative with a minimum number of regeneration states. Approximate expressions for large series-parallel structures are investigated in Section 6.7. Section 6.8 considers syst- ems with complex structure for which a reliability block diagram often does not exist. On the basis of practical examples, preventive maintenance, imperfect switching, incomplete coverage, elements with >2 states, phased-mission systems, common cause failures, and general reconfigurablefault tolerant systems with reward & frequency/ duration aspects are investigated. Basic considerations on network reliability are given in Section 6.8.8 and a general procedure for complex structures is inSection 6.8.9. Section6.9introduces alternative investigation me- thods(dynamicFTA,BDD,eventtrees, Petri nets, computer-aided analysis), and gives a Monte Carlo approach useful for rare events. Human reliability is discussed in Section6.10. Results are summarized in tables. Asymptotic&steady-state is used for stationary, mean for expected value, independent for totally (mutually, statisti- cally, stochastically) independent. Selected examples illustrate the practical aspects.