Information Technology Reference
In-Depth Information
B2
D
B3
B1
D
D
G
G
G
12%
A
D
Security Services
(ISS-ENT-1,
ISS-BP-1)
G
18%
42%
ISS-ENT-1,
ISS-BP-2
ISS-ENT-2,
ISS-BP-2
28%
B3
D
E
B2
D
E
A
D
ISS-ENT-2,
ISS-BP-1
B3
D
E
E
F
F
B1
B1
D
E
B2
D
E
B1 D
C
E
D
C
B3
D
G
G
F
F
F
B2
D
G
Fig. 3.
Evolution of the SWIM Security Service
Table 3.
Examples of Max Belief and Residual Risk
Element set
Max Belief Residual Risk
{
A, D,
}
n/a
n/a
{
A, E, D, G, F
}
18%
70%
{
B3, D, G
}
28%
60%
{
B1,D,G,C
}
28%
60%
{
B3,D,E,G
}
42%
0%
{
B2,D,E,F,G
}
42%
0%
unchanged. Each requirement model is represented as a bubble in which there is
a controllable rule with several design alternatives. Each design alternative is an
element set represented as a rounded rectangle that contains elements (such as A,
D, and G) to support (fulfill) requirements of that requirement model.
Table 3 shows some examples, where the first column displays element sets,
and the two next columns show values of max belief and residual risk. Notice
that the max belief and residual risk in the first row, where the element set is
{
A, D
}
,are
n/a
which means that we are unable to find any potential evolution
that
can support all top requirements.
In Table 3,
{
A, D
}
seem to be the best choices,
since they have a high max belief (42%) and low residual risk (0%). The zero
residual risk means these element sets are surely still useful after evolution. If
the cost of implementation is the second criteria and assume that each element
has equal cost, then
{
B
3
,D,E,G
}
and
{
B
2
,D,E,F,G
}
{
B
3
,D,E,G
}
seems to be better.
5 Handling Complex Evolution
If a model is too large and complex, instead of dealing with the evolution of the
whole model, we can consider evolution in each subpart. If a subpart is still too
large and complex, we can recursively divide it into smaller ones, each with its
local evolution rule, until we are able to deal with.
