Group 53 (The Herd)

Example Risk List for Assignment Three

Version 3

NOTE: most recent changes have been marked in red

A1 A2 A3 Risk Risk Resolution Progress Created by/on Last updated by/on
1 - -

#1) Unsure of what database platform will be best to use.

(Research orientated development risk)

New Risk: JDBC - need to get drivers.

Jon will investigate

Resolved: MYSQL will be used.

Jon
17Mar03

Jon
17Mar03

2 - -

#2) RMI - not sure how to draw up UML (or design classes) until we can work out how RMI interacts with/calls classes.

(Silver bullet syndrome risk)

New Risk: XML encoding - need to develop test classes.

All of us will study RMI and Jon will write a small piece of code to demonstrate it's use.

Resolved: Not using RMI - using serialized objects.

Paul
17Mar03
Jon
22April03
3 - 6

#3) Feature Creep - wanting to add too many new features to the game

Will stick to what is specified in the SRS.

Feature creep is unlikely at this stage - we’re doubtful we have enough time to deliver existing features - let alone additional features.

Reduced player options to split/double & insurance

Jon
23Mar03
Paul 30May03
4 - - #4)  Not sure if all SRS is done correctly (for example - not sure what classic mistakes to match these risks up with).

 Jon will review our SRS against the checklist.

Resolved

 Andrew 18Mar03  Andrew 18Mar03
5 4 - #5) Security - no client should be able to conprimise system integrity (accidental or mallicious). Cheating should be prevented, and the server should be secure. Paul will do some reasearch on security using Java. Danny
5Mar03
Danny
5Mar03
  1 1 #6) Overly optimistic schedule - now afraid we won’t finish all code by the due date. Since the deadline is fixed, our only hope is to work more hours on code. Andrew
22April03
Andrew
25April03
  2 2 Unfamilar areas, including use of timers, JDBC and client-server architechure require a longer learning curve than expected. Jon designated as the person who writes throw-away pieces of code to explain any new concepts. Andrew
22April03
Andrew
22April03
  3 3

Difficult for too many people to work on same code fragment together.

Currently different coding styles leads to one person re-writing another persons work - which is terribly inefficient time management.

(Inefficient work breakdown)

Find better methods for two (or more) people contributing to the same blackjack code. Andrew
22April03
Andrew
22April03
    4 #9) Inadequate Design
Tasks may be more involved than we anticipated
More research. Andrew
11May03
Andrew
11May03
    5 #9) Integration
Combining subsystems into complete integrated system
Reduced dynamic database creation of new virtual players. Paul
30May03

Paul
30May03