![]() |
Test & Analysis Risk List
|
The discussion of the risks and their rating is still in progress.
The table below summarises the main risks identified by the Test & Analysis team,
together with proposed mitigation strategies and a contingency plan, in case the mitigation fails.
Risks are rated according to the product impact on the project * probability to happen.
Risk | Rating | Mitigation | Contingency plan |
R-1 The management does not support the project |
10*10 100 |
Discuss the project vision in the TSB and document a written agreement among all the stakeholders about the vision Keep the TSB and the spokesman regularly informed of the progress Thoroughly document the progress of the project on the web |
Demote the project from Geant4 Collaboration wide scope to LowE + Anaphe internal |
R-2 The management does not appreciate the attention to architecture and software process, and makes pressure for "quick and dirty" solutions |
9*10 90 |
Explain to the management the benefits of a solid design and a serious software process Highlight the commonalities of requirements, with the consequent optimisation of resources deriving from "design for reuse" |
Demote the project from Geant4 Collaboration wide scope to LowE + Anaphe internal |
R-3 The management has the feeling that the progress is slow, and reassigns the project to other collaborators |
8*10 80 |
Adopt an iterative and incremental process to produce frequent deliverables Document the progress regularly Explain to the management that the developers do their best, compatible with all the existing commitments and other agreed priorities |
Demote the project from Geant4 Collaboration wide scope to LowE + Anaphe internal |
R-4 Anaphe may not offer all the functionalities required |
6*10 60 |
Verify the adequacy of Anaphe on a prototype Negotiate with the Anaphe team the implementation of missing functionalities |
Move to another AIDA implementation (if existing) offering all the functionalities required |
R-5 Basic technology choices may be inadequate |
10*5 50 |
Verify the adequacy of technology choices on a prototype | Accept limited functionalities |
R-6 The users may not like some of the tools used, or may not like to learn a new language, or using a new testing environment |
5*9 45 |
Get early feedback from the demo or a prototype Develop a user-friendly UI Well document the system Train users in Python |
Work out an alternative solution, with possibly reduced features |
R-7 The users do not express their requirements clearly, or the developers do not understand them thoroughly |
8*5 40 |
Review the URD with users regularly | Re-work after each iteration |
R-8 The AIDA interfaces may not be complete for the functionalities required |
8*5 40 |
Negotiate extensions with the AIDA team | In the meantime, implement the functionalities in terms of a concrete AIDA implementation |
R-9 The developers under pressure feel tempted to revert to chaotic process |
10*4 40 |
Educate the developers to the benefits of the process. | Accept a lower quality product and invest more resources later for re-work to improve the quality |
R-10 Some of the developers may not feel committed to the project, and would not take the milestones seriously |
5*7 35 |
Involve the developers in the definition of the milestones | Re-adjust the schedule |
R-11 Uncertainties in the future of key members of the team affect the reliability of the software development plan |
4*8 32 |
Work out a software development plan at a time when the overall situation has stabilized; in the meantime short-term planning only | Re-adjust the schedule |
R-12 The AIDA implementation chosen as preferred development environment may not be well supported, or well documented |
6*5 30 |
Negotiate support with the AIDA implementation's team | Choose another AIDA implementation |
R-13 The management makes pressure for the implementation of functionalities not supported by current AIDA implementations, or depending on other features not implemented yet |
2*10 20 |
Negotiate support with the AIDA implementation's teams coherent with the agreed project plan | The management wishes are not satisfied |
R-14 The AIDA implementation chosen as preferred development environment may not be sufficiently robust for usage in a crucial domain like system testing |
10*1 10 |
Select the AIDA implementation on the basis of rigorous software process and documented design Do stress testing on an early prototype |
Choose another AIDA implementation |
Date |
Version |
Description |
Author |
20 September 2002 |
1.0 |
Created |
M.G. Pia |
Maria Grazia Pia, 18 May 2003