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

Revision History

Date

Version

Description

Author

20 September 2002

1.0

Created

M.G. Pia


Maria Grazia Pia, 18 May 2003