Risk Analysis

This section provides a preliminary list of risks which may come into play during the PPF project lifetime. Risks are divided into sections including, product size risks, business impact risks, process risks, technology risks and development environment risks. For each risks noted there is a corresponding mitigation strategy.

• Addition of extraneous code not directly pertinent to a project.
• Limited number of users may limit PPF's benefits.
• The library may unnecessarily complicate the project using it.
• Attempts to save a problems progress in the advent of failure may use large amounts of system resources including drive space.
• The PPF may add a disproportionate amount of overhead to small problems.

• Development efforts should focus on limiting the code for PPF to only handle particle passing and mesh decomposition which is common to all projects.
• During requirements capture, PPF's usefulness should be evaluated in light of the number of foreseeable clients.
• Efforts should be made during development to make the library linkage and interface as simple as possible.
• PPF should only do large data dumps to hard disk if explicitly sanctioned by the user.
• It should be agreed by developers to use PPF only if the problems they run are large enough to warrant it.

• Delivery deadlines may be unreasonable.
• Late deliveries may result in additional costs to Livermore.
• Defects in the PPF may have negative consequences.
• Governmental constraints may inhibit development of PPF.
• Integration into larger systems may be problematic.
• The PPF interface may be too difficult to use by developers.
• The the developers needs may not remain consistent over time.
• Senior management at Livermore may not approve of the PPF.
• Documentation for developers may not adequately describe the PPF.

• Careful planning in the design phase will help provide reasonable deadlines for deliverables.
• Developers intending on using PPF will be updated as to its progress during development so they will be able to plan around the projects progress.
• The PPF must be thoroughly tested to eliminate defects.
• Full specification and design of project must be presented and approved of by senior Livermore management before development.
• Packages which will include the PPF must be carefully studied during design to ensure that there will be no incompatibility issues.
• Efforts must be directed towards keeping the PPF interface simple.
• The PPF should provide a basic functionality that will be useful for the life of the KULL project.
• As stated before, the proposal of the project must pass senior management approval.
• Each stage of the design and the development process must be fully documented.

• There is no process standard for development.
• The lack of a write-up on the process may result in design and development in an ad-hoc fashion.
• Communication barriers between Livermore and Northern Arizona University can result in discrepancies in the process design.
• There has not been any full projects similar to PPF to base the process on.
• Both members of the project are relatively inexperienced in organized process for design and development.
• Time constraints will limit testing and code review.
• The nature of the PPF limits test case design and use cases.

• The PPF should follow a commonly used process that has proven to be effective on other projects.
• An effort should be made to document all aspects of the process to aid in a structured development stage
• Planned weekly meetings and regular email exchanges will help ensure both parties are on the same page.
• Attention of the process selection based on the nature of the project will provide a basis for design in the absence of experience.
• Reviewing process decisions with professors/managers will help correct mistakes made from inexperience.
• The project scope must be limited in light of time constraints to guarantee a functional and stable product.
• Interface issues can be resolved by approaching developers who intend to use the PPF library.

• Parallelization techniques may become outdated within a few years.
• Load balancing is difficult and ensuring optimality is virtually impossible
• The PPF will be interfacing with BLUE's hardware which is experimental and unproven in stability.
• Misuse of the PPF will compromise its performance.
• Simplifying the interface may compromise the library's functionality.
• The nature of the project requires facing problems which have not been dealt with or mitigated in the past.
• There is an uncertainty that the requirements requested are doable.

• The parallelization mechanism should be abstracted from the functionality of the PPF so changes to a new technology will not be\\ difficult.
• It should be understood by the developers who use PPF that the load balancing may not be optimal.
• Frequent comparison between builds on a proven system such as the TERA cluster will help isolate errors caused by anomalous behavior by BLUE. These problems can be brought to the attentionof Livermore Computing and/or IBM.
• Careful and comprehensive documentation will help prevent product misuse.
• The priorities within the project must be analyzed prior to design. If one decision compromises another the one with higher priority is chosen.
• If a perfect algorithm cannot be developed to handle all cases, a heuristic will have to do, and all shortcomings of the algorithm used must be documented.
• If the requirements prove to be to difficult a review of the requirements must be brought before the clients and an acceptable compromise must be reached.

• The project team does not have access to a process management tool.
• The project team has little access to design and analysis tools.
• Popular design and analysis tools are not appropriate for development of the PPF.
• Compatibility between the KCC and egcs compilers may be problematic.
• Cross platform compatibility may prove problematic.
• The project members have no experience debugging threads on the sp2 or Digital Unix platform.
• Thread debuggers for all platforms may not be available.

• Process management can be accomplished by use of programs such as Microsoft Project run on a separate machine than that used for the project.
• The PPF project does not warrant any special tools for design or development, design should be rather straightforward as the library has relatively few use cases.
• Again the nature of the PPF project does not require the use of extravagant design and development tools.
• All code for the PPF must follow the C++ standard.
• Continuous builds on all target platforms will ensure compatibility at every step of the development process.
• Project members must research debugging methods for threads on the sp2 and Digital Unix platform.
• In the case that an adequate debugger is not found, the threads can be debugged separately from the running code using a traditional debugger.