Spring 2001 Risks (After Mini-SRE)

 
Item No.
Risk Statement
 Impact
Probability
Time
1
No Java API exists for Berkeley DB – we have to write it ourselves – not easy; might take longer than we expect - might be unsuitable - no NDBS 2.0 – technical note might change radically.
4
2
3
2
It is not known whether the write/delete capability will be included; customer might be dissatisfied.
3
2
3
3
Don’t know if can we find equivalent crypto routines in Java, equivalent to C routines in NDBS 1.0; NDBS 2.0 might not work; could not be able to add write/delete capability because of lack of time.
3
2
3
4a
The technical note requirements are not yet completely defined; dissatisfied customer; multiple re-writes.
3
1
2
4b
Must build a product that allows extensibility by use of design patterns – never done this in a real product; no meaningful extensibility.
2
2
2
4c
Technical note has to go through the SEI channels;  might have to complete development work sooner than planned.
2
2
1
4d
Not enough people on the team to be comfortable with the development schedule; not enough time.
2
3
3

Mitigation strategies
 
Item No.

Mitigation Strategies
1
We will start to work on the object models and need start to figure out how the object models will fit into implementation
2
We need to look into PSM source code and make sure that it matches the write/delete capability as specified in the requirement. 
3
Grace has completed prototypes of the crypto routines and we feel that we could use SunJCE as a Java service provider interface.
4a
We need to start to coordinate with Clare Dixon for SEI Technical Note expertise and assistance.
4b
We will start to look into MS CAPI as an extensibility feature.  John Robert provided some information to team.  Design patterns are useful for extensibility features and the team has a learning curve on design patterns.
4c
We shall contact the appropriate person at the SEI for assistance on the TN early.
4d
We need to maximize the resources of the team members, let the team member work on things they like so that they will learn, and learn to use outside resources.

Spring 2001 Risks (End of Semester)

 
Item No.
Risk Statement
Impact
Probability
Time
Mitigation Strategies
1 No Java API exists for Berkeley DB – we have to write it ourselves – not easy; might take longer than we expect - might be unsuitable - no NDBS 2.0 – technical note might change radically.
4
2
3
  • First tasks in schedule
  • Intense unit testing
2 It is not known whether the write/delete capability will be included; customer might be dissatisfied.
3
2
3
  • Start earlier than expected
  • Build certutil (certificate utility found on the Mozilla web site) and find source code involved in write/delete options
  • Start with delete which seems easier and will give us experience
3A The technical note requirements are not yet completely defined; dissatisfied customer; multiple re-writes.
3
1
2
  • Three drafts before final delivery
3B Must build a product that allows extensibility by use of design patterns – never done this in a real product; no meaningful extensibility.
2
2
2
  • Research done as part of the architecture class project
3C Technical note has to go through the SEI channels;  might have to complete development work sooner than planned.
2
2
1
  • Delivery date moved to August 4, 2001
  • Contacted John Foreman for review on July 17, 2001
3D Not enough people on the team to be comfortable with the development schedule; not enough time.
2
3
3
  • Team members have been assigned to the tasks where they have the most experience and feel most comfortable with.

Impact

4 = Catastrophic (Doesn’t fill requirement)
3 = Critical (Customer dissatisfied)
2 = Marginal (Burn out)
1 = Negligible

Probability

3 = Very probable
2 = Probable (50/50)
1 = Unlikely

Time

3 = Near (right now)
2 = Medium (within a month)
1 = Long-term