Search Based Software Engineering: Techniques, Taxonomy, Tutorial - Empirical Software Engineering and Verification - page 48

Use domain knowledge: Domain Knowledge can be used to guide the search to
fruitful areas of the landscape, without actually determining the precise solution.
For example, in selection and prioritisation problems, we may know that the
solution we seek must include certain items (for selection these can be hard wired
onto the solution) or we may know that a certain relative placement of some
individuals in an ordering is highly likely. This can happen often as the result of
human considerations concerned with management and business properties. For
instance, in selecting and prioritising requirements, it is not always possible to
take account of all the socio-political issues that may determine the ideal solution
set. The manager may simply say something like 'whatever the solution you
adopt, we must include these five requirements, because the CEO deems them
essential for our business strategy, going forward'. This can be an advantage
for search, because it simultaneously and effortlessly adapts the solution to the
business needs while reducing the size of the search space. Wherever possible,
domain knowledge should be incorporated into the SBSE approach.

11.2 My Fitness Function Is Too Vague and Poorly Understood to

Make It Something I Can Compute

It is a popular misconception that SBSE must use a fitness function that is
both precise and accurate. It is true that this is advantageous and valuable (if
possible), but neither is essential. In software measurement, we seek metrics that
meet the 'representation condition' [87], which states that the ordering imposed
by the metric on the individuals it measures should respect the 'true ordering'
of these individuals in the real world.
It is a natural condition to require of a metric, M ;if M ( a ) >M ( b )thenwe
should reasonably expect that the real world entity a is truly 'better' than b in
some sense and vice versa . However this requirement is not essential for SBSE.
If a fitness function merely tends to give the right answer, then it may well be
a useful, if inecient, fitness function candidate. That is, if the probability is
greater than 0.5 that a pairwise fitness comparison on two individuals a and b
with metric M will produce the correct outcome, then may potentially be used
in SBSE should it prove to have compensatory properties; our search will be
guided to some extent, though it may make many wrong moves.
However, if a metric is simply not defined for some part of the candidate
solutions space or can only be defined by subjective assessment for all or part
of the solution space, then we need a way to handle this. There are two natural
approaches to this problem: use a human or use multiple fitness functions.
Involve Human Judgement: Fitness functions do not need to be calculated
entirely automatically. If they can be fully automated, then this is advantageous,
because one of the overall advantages of SBSE is the way it provides a generic
approach to the problem of Automating Software Engineering [36]. However,
it has been argued [37] that some Software Engineering tasks, such as those
associated with comprehension activity are inherently subjective and require a
human input to the fitness computation. This is easily accommodated in SBSE,