DDB =

*ε*Σ Ei +

*v*Σ Ni (2)

Σ Ei is all the edited lines count and Σ Ni is the all new lines of code count.

*ε*is the ratio of bugs per edit lines and

*v*is the ratio of bugs per new lines of code. And for neighbors effect for a full mesh we considered jut one level of impact, which was:

IDB =

*ψ*(n-1) (Σ Ei + Σ Ni) (1)

*ψ*is the ratio of the bugs per newly added neighbor's bug. We also saw in order to bring down the side effects or indirect effects we can have a software module topology design for our application. So for a sample 4 module fully connected mesh in first layer and then another fully connected mesh for these 4Ms we have the indirect bugs as:

IDB =

*ψ*(n/4+2) (Σ Ei + Σ Ni) (5)Four modules effect on each other when one of them gets unstable or experiences some bug. |

**Chain reaction**

Now lets have a more accurate model for bug propagation, you can also consider this as a method for instability propagation too.

For any reason, you may experience some new bugs at time t1 in M1. As we saw in (1) these bugs will transfer to all neighbors, don't forget the network is fully connected mesh.

Here since we want to find out the chain reaction, we just show one of these side effects, in which M1 makes some bugs in M2.

But at time t2 , M2 will have some side effect on all other modules and so on at t3 and ... this chain reaction continues ....

We can easily model this chain effects simply by assuming that each module will transfer his new amount of instability or new bug counts by ratio of χ, so it means if Mi experiences new bugs or some amount of instability like IDBj at tj, then all other modules except Mi will experience χ IDBj at time tj+1.

To have more simple formula let's replace IDB with I for a while, then we have:

@t1: (n-1) χ^1 I

@t2: (n-1) χ^1 I + (n-2) χ^2 I

@t3: (n-1) χ^1 I + (n-2) χ^2 I + (n-2) χ^3 I

.

.

.

@tj: (n-1) χ^1 I + (n-2) χ^2 I + (n-2) χ^3 I + ... + (n-2) χ^j I

So at time tj we have a series that shows the amount of generated bugs or measure of instability in our application. We can make it much more simpler if j → ∞:

@tj → ∞ : (n-1) χ^1 I + (n-2) χ^2 I + ... + (n-2) χ^j I + ... = (n-1) I [ χ^1 + χ^2 + ... + χ^j + ... ]

We assume X = χ1 + χ2 + χ3 + ... + χj + ... then we have:

(n-1) I [ χ^1 + χ^2 + ... + χ^j + ... ] = (n-1) I χ [ 1+ χ^1 + χ^2 + ... + χ^j + ... ]

or

(n-1) I X = (n-1) I χ (1 + X)

or

X = χ (1 + X) = χ + χ X

or

X( 1- χ) = χ

or

X = χ / (1-χ)

and finally we have the following:

@tj → ∞ : (n-1) (χ/(1-χ) I

@tj → ∞ : (n-1) (χ/(1-χ)

*ψ*(n-1) (Σ Ei + Σ Ni)
now lets have a ρ = 1/χ then we have:

**@tj → ∞ :**

*ψ*/(ρ-1) (n-1)^2 (Σ Ei + Σ Ni) (6)
The equation (6) shows that when some lines get changed or edited the final amount of generated bugs after giving enough time to the system will be directly proportional to:

- the sum of the edited line numbers and newly added lines, which is obvious.
- (n-1)^2 which is almost the second power of the modules counts.
*ψ*which is the ratio of the bugs appearance for the side neighbors.

and inversely proportional to:

- (ρ-1) in which ρ is 1/χ and χ means the ratio of passing bugs or instability in the chain reaction. Let me give some number, if you experience 15 bugs in a module, the next chained modules will experience 15 χ, so if for each 100 in a module the chained module experience 5 bugs then χ = 0.05 and our chained modules will experience 15 * 0.05 = 0.75 bug. But in this case, ρ is 1/0.05 or 20 which means for every passed bug to a module we already had 20 bugs in the previous module.

We will analyze the formula (6) in next posts to see its effect on the design and software programming.