ECE355 Fall 2004 SoItware Reliability 1

Software Reliability
ECE-355 Tutorial
Jie Lian
ECE355 Fall 2004 SoItware Reliability 2
Outline
Part I: SoItware Reliability Model
Musa`s Basic Model
Musa/Okumoto Logarithmic Model
Part II: Control Flow Graph
ECE355 Fall 2004 SoItware Reliability 3
Definition of Software Reliability
Reliability is usually deIined in terms oI a statistical
measure Ior the operation oI a soItware system
without a Iailure occurring
SoItware reliability is a measure Ior the probability
oI a soItware Iailure occurring
Two terms related to soItware reliability
Fault: a deIect in the soItware, e.g. a bug in the code
which may cause a Iailure
Failure: a derivation oI the programs observed behavior
Irom the required behavior
ECE355 Fall 2004 SoItware Reliability 4
Parameters of Software Reliability
Average total number oI Iailures (t)
Average reIers to n independent instantiations oI an
identical soItware.
Failure intensity (t)
Number oI Iailures per time unit, derivative oI (t).
Mean Time To Failure (MTTF):
t may denote elapsed execution calendar or machine
clock time
) (
1
t
MTTF

=
ECE355 Fall 2004 SoItware Reliability 5
Importance of Software Reliability
In safety-critical systems, certain Iailures are Iatal.
This requires pushing reliability to very high levels at very
high costs (code redundancy, hardware redundancy, recovery
blocks, n version programming.).
In non-safety-critical systems a certain Iailure rate is
usually tolerable.
This is a question oI quality oI service.
Which Iailure rate is tolerable is mainly a question oI
customer acceptance. (customer liIts receiver and receives
neither Iast busy nor dial tone one every 10/10000 calls?)
We will only talk about non-saIety-critical systems
ECE355 Fall 2004 SoItware Reliability 6
Software Reliability Growth Model (SRG)
Purpose oI SRG models
SRGs rely on observation oI Iailure occurrence and
try to predict Iuture Iailure behavior
Two diIIerent SRG models (appr 40 models totally):
Musa linear model
Musa/Okomoto logarithmic model
ECE355 Fall 2004 SoItware Reliability 7
Basic Assumptions of Musa`s Model
Faults are independent and distributed with constant
rate oI encounter.
Well mixed types oI instructions, execution time
between Iailures is large compared to instruction
execution time.
Test space covers use space. (Tests selected Irom a
complete set oI use input sets).
Set oI inputs Ior each run selected randomly.
All Iailures are observed, implied by deIinition.
Fault causing Iailure is corrected immediately,
otherwise reoccurrence oI that Iailure is not counted.
ECE355 Fall 2004 SoItware Reliability 8
Musa`s Basic Model
Assumption: decrement in Iailure intensity Iunction
is constant.
Consequence: Iailure intensity is Iunction oI average
number oI Iailures experienced at any given point in
time ( Iailure probability).
(): Iailure intensity.

0
: initial Iailure intensity at start oI execution.
: average total number oI Iailures at a given point in time.
v
0
: total number oI Iailures over inIinite time.
(

=
0
0
1 ) (
v

ECE355 Fall 2004 SoItware Reliability 9
Example 1
Assume that we are at some point oI time t time units in the
liIe cycle oI a soItware system aIter it has been deployed.
Assume the program will experience 100 Iailures over inIinite
execution time. During the last t time unit interval 50 Iailures
have been observed (and counted). The initially Iailure
intensity was 10 Iailures per CPU hour.
Compute the current (at t) Iailure intensity:
(

=
(

=
(

=
Hour CPU
failures
v
5
100
50
1 10 ) 50 (
1 ) (
0
0

ECE355 Fall 2004 SoItware Reliability 10
Musa/Okumoto Logarithmic Model
Decrement per encountered Iailure decreases:
u : Iailure intensity decay parameter.
Example 2

0
10 Iailures per CPU hour.
u 0.02/Iailure.
50 Iailures have been experienced ( 50).
Current Iailure intensity:
u

= e
0
) (
68 . 3 10 10 ) 50 (
1 ) 50 02 . 0 (
= = =

e e
ECE355 Fall 2004 SoItware Reliability 11
Model Extension (1)
Average total number oI counted experienced
Iailures () as a Iunction oI the elapsed execution
time (t).
For basic model
For logarithmic model
(
(

=
t

t
0
0
1 ) (
0
v
e v
( ) 1 ln
1
) (
0
+ = ut
u
t
ECE355 Fall 2004 SoItware Reliability 12
Example 3 (Basic Model)

0
10 |Iailures/CPU hour|.
v
0
100 (number oI Iailures over inIinite execution
time).
t 10 CPU hours:
t 100 CPU hours:
(
(

=
t

t
0
0
1 ) (
0
v
e v
| | failures e e 63 1 100 1 100 ) 10 (
1
10
100
10
= =
(

| | failures e e 100 1 100 1 100 ) 100 (

10
100
100
10
~ =
(

ECE355 Fall 2004 SoItware Reliability 13

Example 4 (Logarithmic Model)

0
10 |Iailures/CPU hour|.
u 0.02 / Iailure.
t 10 CPU hours:
t 100 CPU hours:
( ) 55 1 10 02 . 0 10 ln
02 . 0
1
) 10 ( = + =
( ) 1 ln
1
) (
0
+ = ut
u
t
( ) 152 1 100 02 . 0 10 ln
02 . 0
1
) 100 ( = + =
(63 in basic model)
(100 in basic model)
ECE355 Fall 2004 SoItware Reliability 14
Model Extension (2)
Failure intensity as a Iunction oI execution time.
For basic model:
For logarithmic Poisson model
|
|
.
|

\
|

=
t

t
0
0
0
) (
v
e
1
) (
0
0
+
=
ut

t
ECE355 Fall 2004 SoItware Reliability 15
Example 5 (Basic Model)

0
10 |Iailures/CPU hour|.
v
0
100 (number oI Iailures over inIinite execution
time).
t 10 CPU hours:
t 100 CPU hours:
(
(

= = =

|
.
|

\
|

hour CPU
failures
e e 68 . 3 10 10 ) 10 (
1
10
100
10

|
|
.
|

\
|

=
t

t
0
0
0
) (
v
e
(
(

= = =

|
.
|

\
|

hour CPU
failures
e e 000454 . 0 10 10 ) 100 (
10
100
100
10

ECE355 Fall 2004 SoItware Reliability 16

Example 6 (Logarithmic Model)

0
10 |Iailures/CPU hour|. u 0.02 / Iailure.
t 10 CPU hours:
t 100 CPU hours:
(
(

=
+
=
hour CPU
failures
33 . 3
1 10 02 . 0 10
10
) 10 (
(3.68 in basic model)
(0.000454 in basic model)
1
) (
0
0
+
=
ut

t
(
(

=
+
=
hour CPU
failures
467 . 0
1 100 02 . 0 10
10
) 100 (
ECE355 Fall 2004 SoItware Reliability 17
Model Discussion
Comparison oI basic and logarithmic model:
Basic model assumes that there is a 0 Iailure intensity,
logarithmic model assumes convergence to 0 Iailure intensity.
Basic model assumes a Iinite number oI Iailures in the
system, logarithmic model assumes inIinite number.
Parameter estimation is major problem:
0
, u, and v
0
.
Usually obtained Irom:
system test,
observation oI operational system,
by comparison with values Irom similar projects.
ECE355 Fall 2004 SoItware Reliability 18
Part II: Control Flow Graph (CFG)
A graph representation oI a set oI statements is called
a IORZJUDSK or FRQWUROIORZJUDSK.
Nodes in the Ilow graph represent computations and
the edges represent the Ilow oI control.
A EDVLFEORFNis a sequence oI consecutive three-
aaaress statements in which Ilow oI control enters at
the beginning and leaves at the end without halt or
possibility oI branching except at the end.
A CFG consists oI a set oI basic blocks.
ECE355 Fall 2004 SoItware Reliability 19
Three-Address Statements
Assignment statements oI the Iorm [: \ RS ] or [: RS ], where op is a
binary or unary arithmetic or logical operation.
Copy statements [: \ where the value oI y is assigned to x.
Unconditional jump goto /. Execution jumps to the statement labeled by L.
Conditional jump if [UHORS\ goto /.
Indexed assignments oI the Iorm [: \L] and [L] : \.
Address and pointer assignments oI the Iorm [ : &\, [ : `\, and *[ : \.
Param [ and call S, Q, and return \, where
return value oI y is optional. For a procedure
call p(x
1
, x
2
, . , x
n
), the transIormed
three-address statements are:
param x
1
param x
2
.
param x
n
,
call p, n
ECE355 Fall 2004 SoItware Reliability 20
Partition into Basic Blocks
Input: A sequence oI three-address statements.
Output: A list oI basic blocks with each three-address
statements in exactly one block.
Method
1. Determining leaders (the Iirst statement oI basic blocks) by three rules:
i. The Iirst statement is a leader.
ii. Any statement that is the target oI a conditional or unconditional goto is a
leader.
iii. Any statement that immediately Iollows a goto or conditional goto
statement is a leader.
2. For each leader, its basic block consists oI the leader and all statements
up to but not including the next leader or the end oI the program.
ECE355 Fall 2004 SoItware Reliability 21
Example
I 1;
TI TV 0;
sum 0;
DO WHILE (v|I| ~ 999 and TI 1)
TI;
IF (v|I| ~ min and v|I| max)
TV; sum sum v|I|;
}
I;
}
IF TV ~0 )
av sum/TV;
ELSE
av 999 ;
.
1 I 1;
TI TV 0;
sum 0;
2 IF (vI] -999) GOTO 10
3 IF (TI > 1) GOTO 10
4 TI++;
5 IF (vI] < min) GOTO 8
6 IF (vI] > max) GOTO 8
7 TV++;
sum sum + vI];
8 I++;
9 GOTO 2
10 IF (TV < 0) GOTO 12
11 av sum/TV;
goto 13
12 av -999;
13 .
While
loop
IF ELSE
Basic Block
We do not strictly Iollow the transIormation
Irom source code to three-address statements.
Note that each statement with a label is a leader.
ECE355 Fall 2004 SoItware Reliability 22
Transformation from Basic Blocks to CFG
1
2
3
4
5
6
8 7
9
10
12
11
13
R
4
R
1
R
3
R
5
R
2
R
6
Outer
region
predicate node
.
1 I 1;
TI TV 0;
sum 0;
2 IF (vI] -999) GOTO 10
3 IF (TI > 1) GOTO 10
4 TI++;
5 IF (vI] < min) GOTO 8
6 IF (vI] > max) GOTO 8
7 TV++;
sum sum + vI];
8 I++;
9 GOTO 2
10 IF (TV < 0) GOTO 12
11 av sum/TV;
goto 13
12 av -999;
13 .
ECE355 Fall 2004 SoItware Reliability 23
Cyclomatic Complexity
McCabe`s cyclomatic complexity
V(G) E N 2, E: number oI edges, N: number oI nodes.
V(G) p 1, p is a number oI predicate (decision) nodes.
V(G) number oI regions (area surrounded by nodes/edges).
V(G): upper bound on the number oI independent paths
Independent path: A path with at least one new node/edge.
Example (pp. 22) :
V(G) E N 2 17 13 2 6
V(G) p 1 5 1 6
V(G) 6
Advantage: # oI test cases is proportional to the program size.
ECE355 Fall 2004 SoItware Reliability 24
References
|1| Musa, JD, Iannino, A. and Okumoto, K., 'Software Reliability.
Measurement, Preaiction, Application`, McGraw-Hill Book
Company, NY, 1987.
|2| A. V. Aho, R. Sethi, and J. Ullman, "Compilers. Principles,
Techniques, ana Tools", Addison-Wesley, Reading, MA, 1986.