Information Technology Reference
In-Depth Information
illustrating how generic and widely applicable SBSE is to a wide range of soft-
ware engineering problem domains. Section 9 presents a taxonomy of problems
so far investigated in SBSE research, mapping these onto the optimisation prob-
lems that have been formulated to address these problems. Section 10 describes
the next steps a researcher should consider in order to conduct (and submit
for publication) their first work on SBSE. Finally, Section 11 presents potential
limitations of SBSE techniques and ways to overcome them.
2 Why SBSE?
As pointed out by Harman, Mansouri and Zhang [48] Software Engineering ques-
tions are often phrased in a language that simply cries out for an optimisation-
based solution. For example, a Software Engineer may well find themselves asking
questions like these [48]:
1. What is the smallest set of test cases that cover all branches in this program?
2. What is the best way to structure the architecture of this system?
3. What is the set of requirements that balances software development cost and
customer satisfaction?
4. What is the best allocation of resources to this software development project?
5. What is the best sequence of refactoring steps to apply to this system?
All of these questions and many more like them, can (and have been) addressed
by work on SBSE [48]. In this section we briefly review some of the motivations
for SBSE to give a feeling for why it is that this approach to Software Engineering
has generated so much interest and activity.
1. Generality
As the many SBSE surveys reveal, SBSE is very widely applicable. As ex-
plained in Section 3, we can make progress with an instance of SBSE with
only two definitions: a
representation
of the problem and a
fitness function
that captures the objective or objectives to be optimised. Of course, there
are few Software Engineering problems for which there will be no representa-
tion, and the readily available representations are often ready to use 'out of
the box' for SBSE. Think of a Software Engineering problem. If you have no
way to represent it then you cannot get started with any approach, so prob-
lem representation is a common starting point for any solution approach,
not merely for SBSE. It is also likely that there is a suitable fitness function
with which one could start experimentation since many software engineering
metrics are readily exploitable as fitness functions [42].
2. Robustness
SBSE's optimisation algorithms are robust. Often the solutions required need
only to lie within some specified tolerance. Those starting out with SBSE can
easily become immersed in 'parameter tuning' to get the most performance
from their SBSE approach. However, one observation that almost all those
who experiment will find, is that the results obtained are often robust to
Search WWH ::
Custom Search