Guide to Advanced Empirical



Download 1.5 Mb.
View original pdf
Page97/258
Date14.08.2024
Size1.5 Mb.
#64516
TypeGuide
1   ...   93   94   95   96   97   98   99   100   ...   258
2008-Guide to Advanced Empirical Software Engineering
3299771.3299772, BF01324126
tion is directly correlated with the rate variable development activity. The actual calculation of code fault generation is shown in (6) below.
code fault generation = development activity*
randomized aveerage code fault injection per KLOC*
(1/MAX(1, code learnin ng status quality code learning amplifier))

(6)
From (6) it can be seen that there is only defect injection when development activity
> 0. The actual number of faults generated per time step depends on the number of
KLOC developed per time step and the randomized average code fault injection


5. Simulation Methods
141
per KLOC, which – in this example – is calculated by multiplying the average code
fault injection per KLOC with a random number sampled from the triangular distribution triang(0.9, 1, 1.1,), where 1 represents the most probable value, and 0.9 and 1.1 the minimal and maximal values, respectively. The last factor in (6) models the learning effect. As soon as code learning status adjusted for the learning amplifier becomes greater than 1, the learning factor is less than 1 and thus the number of injected code faults decreases.
At the start of a simulation run, all model constants are initialized with a default value which can be modified by the user. Figure 9 shows a graphical user interface to the model, built using a Vensim utility, in the form of an input panel with slide bars, default initialization, and admissible value range. For example, variable code ver effectiveness is to be initialized with 0.75 (representing a defect detection effectiveness of the code verification technique of 75%), and maximum and minimum values of 0 and As soon as the simulation has started, the values of all model variables are calculated by Vensim
®
at each time step, which represents, for example, one workday. When the simulation run is complete the calculated values can be displayed either in tabular form or as graphs showing the timeline on the x-axis and the variable value on the y-axis. Figures 10 and 11 below show example output graphs of the example model.
The upper part of Fig. 10 shows the simulation output for the level variables
code to do size and code doc size. At simulation start (Time = 0), the amount of code work to do, in this case 200 KLOC, flows instantaneously into code to do size. This then decreases at a constant rate, caused by the development activity which transforms code to do size into code doc size (cf. Fig. 6). Consequently, the value of code doc size is exactly complementary to the value of code to do size, the sum of both always adding up to 200 KLOC. The lower part of Fig. 10 shows the behaviour of the state variables controlling the behaviour of code development, code verification, and learning, respectively. For example, one can see that code doc dev
status equals 1 (active) while code is developed. As soon as there is nothing more average code ver rate per person and day
0
average code fault injection per KLOC
0 average code dev rate per person and day average code size in KLOC
0 code ver effectiveness code doc quality limit per KLOC
0 quality code learning amplifier productivity code learning amplifier workforce 20 1,000 10 1
100 2
5 2
5 5
Fig. 9
Simulation input panel


142 MM ller and D. Pfahl to develop, i.e., code to do size = 0, it switches to 2 (complete. At that moment,
code doc ver status switches from 0 (“non-exist”) to 1 (active. After sometime during which verification is done, depending on how many defects are found, code
doc ver status switches either to 2 (repeat) or 3 (complete. In Fig. 10, one can see that after the first verification round it is signalled that a second verification round needs to be performed (“repeat”).
Figure 11 shows a selection of diagrams related to code fault generation, detection, and correction. The model variable code faults undetected represents the difference between the numbers of injected and detected faults, while code faults
Fig. 10
Simulation output related to model views 1 and code doc size
Time (Day)
KLOC
code doc size : Current-Code code doc size : Current-Code code to do size 100 0
200 100 0
0 10 20 30 40 50 60 70 80 90 100 0
10 20 30 40 50 60 70 80 90 Time (Day)
code doc dev status 0
0 15 30 45 60 75 90 0
15 30 45 60 75 90 0
15 30 45 60 75 Time (Day)
code doc dev status : Current-Code code doc ver status
Time (Day)
code doc ver status : Current-Code code learning status 0
4 Time (Day)
code learning status : Current-Code
KLOC
code faults pending
Time (Day)
code faults pending : Current-Code code faults corrected
Time (Day)
code faults corrected : Current-Code code faults undetected 200 0
400 200 0
0 10 20 30 40 50 60 70 80 90 100 0
10 20 30 40 50 60 70 80 90 100 0
10 20 30 40 50 60 70 80 90 100 0
10 20 30 40 50 60 70 80 90 Time (Day)
code faults undetected : Current-Code code faults detected : Current-Code code faults detected 300 0
600 300 Time (Day)
Defect
Defect
Defect
Defect
Fig. 11
Simulation output related to model view 3


5. Simulation Methods
143
pending represents the difference between detected and corrected code faults. One can see that fault detection occurs when verification is active, and fault correction occurs when development (rework) is active.

Download 1.5 Mb.

Share with your friends:
1   ...   93   94   95   96   97   98   99   100   ...   258




The database is protected by copyright ©ininet.org 2024
send message

    Main page