2. 
Software development can be treated
as an optimization problem:
maximise software quality
subject to the constraints limited resources
Software quality: number of
features, performance, reliability, etc.
 Resources: time, money, etc.


3. 
Questions to answer:
› How long it will take to complete a particular
task?
› How long it will take to test a particular
module?
› How many defects remain in a particular
module after a release?
› At a particular time, what portion of
resources should be devoted to testing as
opposed to developing new features?

4. 
How to answer the previous questions:
› By building a model

Purpose of modelling
› Predict, explain, discover, guide

Modelling is a two-steps process:
› Determine set of variables of interests
› Determine set of equations to describe how
these variables change and which kinds of
relations exist among them

5. Software development is an iterative
process
 The process of software developement
can be described by the phrase
evolution of software
 The phrase implies similarities with
evolution of biological systems
 How can we use this fact? – central idea
of this presentation


6. 
Bio-inspired optimization algorithms:
› Genetic algorithm – motivated by Darwin’s
›
›
›
›
principal of natural selection
Memetic algorithm – motivated by genetic +
experience
Particle swarm optimization – motivated by
behavior of a flock of birds
Ant colony optimization – motivated by
behavior of an ant-colony
Bee-inspired optimization, shuffled frog
leaping algorithm, etc.

7. 
Artificial neural networks
› It is computational structure inspired by central
nervous system

Artificial immune system
› It is computationally intelligent systems inspired
by the principles of the immune system

Capture-recapture bug-estimation method
› Statistical method developed for population
estimation in bio-ecosystems

8. 


Accepted among most major software
companies (Google, Facebook, Mozilla and
Microsoft)
Main principle - abandon long development
cycles in favor of faster releases in order to
bring the latest features and fixes to end-users
Information for making decision if software is
ready for a new release:
› Relationship between number of bugs in the
system (b(t)) and effort necessary to resolve
them (e(t)).
› The more effort is spent on defect resolving, the
less time is left for developing new features.

9. 
O1 – Increasing (or decreasing) of e(t) leads
to decreasing (or increasing) of b(t):
e(t )

e(t )
b(t )
O2 – Increasing (or decreasing) of b(t)
requires increasing (or decreasing) of e(t):
b(t )

b(t )
e(t )
b(t )
e(t )
O3 – As a result from the previous two
observation, both b(t) and e(t) exhibit
periodic oscillations.

10. O4 – The relationship from O1and O2 is
not linear.
 O5 – Small increase of effort can lead to
significant reduction of defects number.
 O6 –Pareto principle – majority of time is
spent on small number of difficult bugs
(approximately, removal of 30% of bugs
requires 70% of time).


11. O7 – Changes in code churn exhibits
growth rate which can be modeled by
sigmoid function.
 O8 – b(t) increasing is steeper than
decreasing.
 O9 – e(t) decreasing is steeper than
increasing.
 Observations O1-O9 imply similarity with
predator-prey ecosystem

› Predator – tester, programmer
› Prey - bugs

12. 
Most famous predator prey model expressed by:
db(t )
dt

b(
e)
de(t )
dt
e(
b)
Main characteristics:
› In the case e(t)=0 (no hunt for bugs), b(t) has exponential
growth.
› The rate of detecting and reducing number of bugs by
developers/testers is proportional to the number of bugs
and effort invested in bug reduction (βeb). Intuitively, if
there are more bugs in the system, it will be easier to
detect and eliminate some of them. In addition, if more
effort is invested in bugs reduction, the more bugs will be
reduced.

13. › In the absence of bugs (b(t)=0), effort
exponentially reduces to zero.
› The rate at which the effort grows is
proportional to the rate at which the
developers/testers encounter bugs.

Issues with the presented model:
› Extremely sensitive to small perturbations
› Allows unlimited exponential growth of
number of bugs
› Unlimited ability of a single developer/tester
to detect and eliminate bugs

14. 
Improvement of LV model which resolves
previous issues:
db(t )
dt
b
b(1
)
K
b
b k
e
de(t )
dt
e
b
b k
e
Number of bugs is limited by the size and
complexity of a project which is
specified by the parameter K.
 Rate at which a single developer/tester
detects and removes bugs is limited.


15. 

Relationship among
parameters defines
two main regions.
Model allows regular
oscillations (suitable
for the beginning
and the middle of
project) as well as
dumped oscillations
(suitable for project
near completion)

16. 
Normalized values of e(t) and b(t)
Conclusions:
› The model was
evaluated on real-life
small size project
developed under RR
methodology
› The model fairly
accurately captures
observations O1-O9
› Future work:
investigate if the
results can be
generalized for
description of
projects with different
characteristics.