Download A Flexible 3D-Visualisation Engine With Force

The 'Flight' Simulator
Page 62 of 117
17 Appendix B - Risk Analysis Document
17.1 Risk Planning
Risk planning should play an important part in any software engineering process. Due to the nature of
the project (the author has never before used the OpenGL or DirectX APIs, and has never used
Microsoft Visual C++ 6.0), risk analysis and planning was considered a serious part of the project.
After each major requirements or design stage, the risks to the project were assessed, and where
possible, methods to mitigate these risks were devised.
This document described the complete risk analysis undertaken for the project. However, this analysis
was performed in three phases. The first was performed after the initial Requirements Specification,
and investigated the high-level risks to the project. The second phase was performed after the detailed
Requirements Definition, and investigated specific risks in more detail. The last phase was performed
after design and before the implementation phase. Here, risks specific to implementation matters were
addressed.
Throughout the project, this risk document was continually monitored and updated. New risks, and
methods to combat them were added as discovered. This ensured that no unforeseen problems would
arise, or that countermeasures would be available should they arise.
17.2 Requirements Risks
Due to the nature of the system, and the fact that useful feedback could only be obtained after a
prototype was available for demonstration, the risk that the requirements would be incorrect during
much of the design and implementation was extremely high. This risk was mitigated in two ways.
First, an ongoing process of requirements elicitation allowed comments and suggestions from the
project supervisor and any other interested party to be incorporated into the requirements. Further,
demonstrations were held to interested parties in order to gather their comments and suggestions.
Secondly, the design of the system was carried out in an extremely modular fashion. This meant that
small changes to the requirements required no redesign and very little re-implementation. Large
changes to the requirements meant only alterations to the interfaces between components, and only
small amounts of implementation.
17.3 Design Risks
The risk of errors occurring during design was considered small, due to the author's experience in
object-oriented design and programming. However, since new technologies and languages were being
employed, it was possible that mishaps could happen. Although the choice of implementation
technologies should not influence the design process, in reality this choice constrains the design,
specifying what can and cannot be designed with a particular language. For example, C++ treats a
function as a first class value (its address can be taken) while this is impossible in Java, and this can
affect control and data flow through a system. As such, available options may be overused or
neglected by the author during design.
In order to mitigate this risk, an extensive study of the C++, OpenGL and DirectX language references
was undertaken to familiarise the author with these technologies and their uses. Also, the architectural
design was performed (using the requirements specification) before any detailed component design, in
order that the design was feasible with the technologies chosen for its implementation.
17.4 Implementation Risks
Due to the fact that the author had no experience in many of the technologies in use in the project, there
was a high risk that problems would be encountered during implementation. As mentioned above, this
risk would be partially mitigated by reading the language references for these technologies. When
implementation began, this risk was carefully monitored.
Douglas Currie