6. The resources necessary to develop, implement, and maintain the protective measures, with
particular emphasis on technical security solutions.
7. The security procedures and controls that exist or that must be implemented to maintain the
required standards of information integrity and access.
8.17 Risk Log
A risk log is a simple means of managing risk. For a more detailed approach see [Levinson] and [IEEE
Std 1540-2001]. Table 8.5 is used as an example of major risks to a project.
8.18 Daily Test Report
Some organizations prefer a daily test report. It is a good discipline. It could contain:
??? Period covered. ???This is the test report for release a.b.c. build d of system X for the period 0900
30th??“0900 31st June.??? Add a management summary identifying any big bugs found. The number
of P1, P2, P3, and P4 bugs found. The number expected to be found.
Test Documents 161
??? Features being tested. List them.
??? Bug profile: A chart showing the number of bugs found so far, as shown below.
TABLE 8.5 Risk log example
Risk description Effects and how to assess Probability Mitigation
Requirements tracking ??”
there is no means in place to
relate features in general and
requirements in particular to
bugs, or parts of code. It is
difficult to identify what
features are in what state at
any time.
Difficulty in:
??? associating a bug with a feature and
therefore deciding whether to declare
that feature present in a release,
??? deciding which features to
concentrate on when regressiontesting,
??? identifying which features most
need rewriting
??? identifying common bug patterns.
Pages:
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347