Risk Management

From SoS

Contents 1 Threshold of Success 2 Top Risks 3 Newly Identified risks 4 Mitigation Strategies 4.1 We don't know if we can accomplish the quality attribute scenario for performance (time to process scenarios - client provided these); these assumptions may turn out to be unrealistic. 4.2 Management intervention is sometimes needed to get people working together; we may suffer delays. 4.3 Some people on the team are not familiar with important technologies (e.g., Java, C++, Eclipse framework) and tools; we may find it takes a lot longer to do the coding tasks than was expected. 4.4 Hidden assumptions made by client and team about specific requirements are not being documented; discovery and revalidation could take too much time or we might make the wrong assumptions 4.5 Other class assignments impinge upon our studio time, and some require unpredictable effort; might not be able to meet a given deadline. 4.6 Scope of experiments keep changing; all experiments may not get completed. 4.7 Eclipse graphical framework is new and not well documented; could spend too much time requesting help, and it may not be stable yet 4.8 While planning subtasks, dependency checks are not being done; tasks on the critical path may cause delays 4.9 Client is on vacation many days during the summer; releases may not be tested properly by client 4.10 GMF is not scalable for a big scenario; GUI might not fulfil client's expectation 4.11 We don't have concrete results for verification of a particular scenario;application might not be functioning correctly 4.12 Documentation is not moving forwards in time; quality of documentation might suffer 4.13 GUI/SimEngine communications is slowing performance; may not achieve performance quality attribute 4.14 Writing XML is slowing SimEngine; may not achieve performance quality attribute 4.15 Eclipse learning curve is steep; we might not be able to complete the GUI enhancements in the given time 4.16 Team members are going to spend a lot of time in interviews; we might not be able to get issues resolved in time 5 Risk Mitigated

Threshold of Success

• No critical defects in application by December 5, 2007
• Complete all high priority architectural drivers as defined in the Wiki SRS by August 9, 2007
• Meet individual studio learning goals as documented in Wiki by December 5, 2007

Top Risks

• Eclipse learning curve is steep; we might not be able to complete the GUI enhancements in the given time.
• Team members are going to spend a lot of time in interviews; we might not be able to get issues resolved in time.

Details of old risks can he found here

Newly Identified risks

3/26/2007

• Scope of experiments keep changing; all experiments might not get completed.
• Experiment load distribution among team members is not uniform; some team members might get burned out.

3/30/2007

• Antenna sweep and Probability of detection maths not clear; this might delay detailed design of simulation objects and detection module.

4/02/2007

• Our earned value analysis might be misleading; the team may overload themselves with work to keep up

4/20/2007

• Eclipse license and platform may not be suitable for L3, may have to use a different GUI
• The client is unsure on how to aggregate information on channels, we may not deliver the required functionality on time

4/29/2007

• While planning subtasks, dependency checks are not being done; tasks on the critical path may cause delays.

05/04/2007

• Client is on vacation many days during summer; may not test releases properly.

05/25/2007

• New planning and tracking tool is being used; might result in planning overhead.

07/09/2007

• We are not getting through all of the integration tests; quality of product might suffer.

7/10/2007

• We don't know if simulator's results are repeatable; might mean that the simulator is not stable or deterministic.
• We have not tested the performance quality attributes; system might not meet the required quality attributes.
• Traceability matrix is not up-to-date; we might not cover all of the requirements.

9/10/2007

• Eclipse learning curve is steep; we might not be able to complete the GUI enhancements in the given time.
• Team members are going to spend a lot of time in interviews; we might not be able to get issues resolved in time.

10/8/2007

• The eclipse-sub team is finding it difficult to schedule common cave-time; GUI change requests might not get done in time.

Mitigation Strategies

We don't know if we can accomplish the quality attribute scenario for performance (time to process scenarios - client provided these); these assumptions may turn out to be unrealistic.

• Create a detailed design for the simulation engine and build a prototype based on it
• Find some experts in simulation to learn shortcuts or optimization approaches
• Restate the quality attributes performance objective so that it just has to be below the Matlab run time
• Convince client to use GPL or commercial libraries (for greater speed)
• Extend XML experiment to check file output times
• Modify existing QA scenarios and identify new ones for Performance.

Management intervention is sometimes needed to get people working together; we may suffer delays.

• Constant feedback to offending members
• Find a way to align individual goals with team goals
• Re-enforce mutual accountability and individual empowerment

Some people on the team are not familiar with important technologies (e.g., Java, C++, Eclipse framework) and tools; we may find it takes a lot longer to do the coding tasks than was expected.

• Assign domain experts
• Knowledge sharing
• Pair programming

Hidden assumptions made by client and team about specific requirements are not being documented; discovery and revalidation could take too much time or we might make the wrong assumptions

• Experiments
• Detailed design

Other class assignments impinge upon our studio time, and some require unpredictable effort; might not be able to meet a given deadline.

• In planning meetings, assume that no work will get done till Wednesday night and take on tasks accordingly.

Scope of experiments keep changing; all experiments may not get completed.

• The scope of the experiment will be strictly defined by the Chief Scientist. Any deviation has to be approved by the Chief Scientist on a case-to-case basis.

Eclipse graphical framework is new and not well documented; could spend too much time requesting help, and it may not be stable yet

• Use existing examples to learn.
• Request Dr. Garlan for Acme source code.

While planning subtasks, dependency checks are not being done; tasks on the critical path may cause delays

• Create dependency matrix while planning sub tasks, and consult it during planning meeting.

Client is on vacation many days during the summer; releases may not be tested properly by client

• Find alternate contact early, familiarize him/her with project.
• Re-scope releases
• Reschedule releases
• Be more involved in UAT - write couple of scenarios and make him try to do more work based on that

GMF is not scalable for a big scenario; GUI might not fulfil client's expectation

• Provide an early prototype to Matt with 3 options:
  • Continue with current non-scalable solution
  • Try doing the tree with no pallet support
  • Going a new direction and possible no delivery all on time

We don't have concrete results for verification of a particular scenario;application might not be functioning correctly

• Stress to the client to test it thoroughly to verify input (either with their own test or ours)
• Talk to the client to explore alternatives
• We generate our scenarios and give results to client for validation

Documentation is not moving forwards in time; quality of documentation might suffer

• Documentation manager should be actively involved
• Add doxygen automatic generation to integration testing and release

GUI/SimEngine communications is slowing performance; may not achieve performance quality attribute

• Performance analysis and testing.
• Peer reviews

Writing XML is slowing SimEngine; may not achieve performance quality attribute

• Write a new DataManager plugin to output values as pipe-delimited file

Eclipse learning curve is steep; we might not be able to complete the GUI enhancements in the given time

• Find the most important parts of eclipse to be done in KT.
• Leverage the eclipse community.
• Find independent modules to work on.
• Scope.

Team members are going to spend a lot of time in interviews; we might not be able to get issues resolved in time

• Inform the team early enough of the interviews - in every status meeting.
• Reschedule tasks if required.
• Plan for backups.

Risk Mitigated

1. We were supposed to have a high-level plan, and we still don't have it; we might not achieve the proposed milestones.
   • Mitigation date: 3/14/07
   • Mitigation Strategy: Create the plan during spring break
2. Some GPL licenses may be unacceptable to the client for use; might have to develop some libraries we need for ourselves.
   • Mitigation date: 3/6/07
   • Mitigation Strategy: Convince the client that GPL won't substantially affect the program, Look for non GPL libraries
3. We don't know if we can accomplish the quality attribute scenario for performance (time to process scenarios - client provided these); these assumptions may turn out to be unrealistic.
   • Mitigation date: 4/29/2007
   • Mitigation strategy: Experiments, re-negotiation of QA scenarios.
4. Scope of experiments keep changing; all experiments may not get completed.
   • Mitigation date: 4/29/2007
   • Mitigation strategy: Tighter process, closer monitoring.
5. We don't always properly coordinate in our communication; may suffer divergent effort and stepped-on toes.
   • Mitigation date: 4/29/2007
   • Mitigation strategy: Communication.
6. Other class assignments impinge upon our studio time, and some require unpredictable effort; might not be able to meet a given deadline.
   • Mitigation date: 3/14/2007
   • Mitigation strategy: Assume that no work will get done till Wednesday night and plan tasks accordingly. Cancel stand up meetings before Thursday.
7. Management intervention is sometimes needed to get people working together; we may suffer delays.
   • Mitigation date: 6/16/2007
   • Mitigation strategy: Team is working in common hours and responding tho email consistently (metrics)
8. Client is on vacation many days during the summer; releases may not be tested properly by client.

1. • Mitigation date: 6/31/2007
   • Mitigation strategy: Milestones pushed to when he returns; his vacations are almost over
2. While planning subtasks, dependency checks are not being done; tasks on the critical path may cause delays.
   • Mitigation date: 6/31/2007
   • Mitigation strategy: Planning is taking into account dependencies.
3. While planning subtasks, dependency checks are not being done; tasks on the critical path may cause delays.
   • Mitigation date: 6/31/2007
   • Mitigation strategy: Planning is taking into account dependencies.
4. Hidden assumptions made by client and team about specific requirements are not being documented; discovery and revalidation could take too much time or we might make the wrong assumptions.
   • Mitigation date: 7/29/2007
   • Mitigation strategy: All requirements are documented and performed extensive validation
5. Documentation is not moving forwards in time; quality of documentation might suffer.
   • Mitigation date: 7/29/2007
   • Mitigation strategy: Documentation was done in time. Will perform more reviews to make sure documentation meeting quality
6. GUI/SimEngine communications is not on schedule; may not be delivered
   • Mitigation date: 7/29/2007
   • Mitigation strategy: System was delivered with SimMonitor/SimController
7. We don't have concrete results for verification of a particular scenario;application might not be functioning correctly.
   • Mitigation date: 7/29/2007
   • Mitigation strategy: Created at least 6 scenarios to validate results
8. We are at the outer bounds of project size this team can accomplish in the time given; any expansion in scope or drop in productivity could lead to not meeting client expectations.
   • Mitigation date: 7/29/2007
   • Mitigation strategy: We delivered on time. Scope was not expanded significantly.
9. GUI/SimEngine communications is slowing performance; may not achieve performance quality attribute
   • Mitigation date: 8/2/2007
   • Mitigation strategy: Improved communication process between GUI/SimMonitor
10. Writing XML is slowing SimEngine; may not achieve performance quality attribute
    • Mitigation date: 8/2/2007
    • Mitigation strategy: Created a piped-delimited DataManager plugin.
11. Documentation is not moving forwards in time; quality of documentation might suffer.
    • Mitigation date: 8/9/2007
    • Mitigation strategy: Allocate more resources to help delivering documentation