This section characterizes the possible risks during the design, implementation, and testing phase in three different categories: project risks, product risks, and business risks. The risks are also analyzed for their probability and overall effect to identify possible strategies for success of the project. Risk analysis will help us to focus on events that have a reasonable chance of occurring and that would directly affect the success of our project.

Risks

After analyzing the problem, Team TerraUser had identified the following as being potential risks.

Project Risks

Project risks are risks that affect the projects resources or schedule.

Table 6.1: Project Risks

Product Risks

Product risks cover risks related to the products that we rely on to do this project. Some of the products that we are relying on to do this project are: SuSE Linux, Apache Web Server, Apache Tomcat, MySQL, SSL, Java, JDBC, HTML, JSP, Java Script.

Table 6.2: Product Risks

Business Risks

Table 6.3: Business Risks

Risk Analysis

The risks we have identified are the most significant and threatening of the many risks the project may face. To establish a risk assessment framework we have projected the probability of each risk happening and the overall effect of the problem actually occurring. The following table shows the major risks along with the probability of each happening and the corresponding effect.

Table 6.4: Risk Probability & Effect

The only critical risk we have identified is the underestimation of development time. We are confident, however, that this risk will be closely monitored and that the team is devoted to overcoming any obstacle to prevent it from happening.

Risk Management and Mitigation

For each of the risks identified above, possible strategies have been identified to manage these risks. Solutions to risks follow:

Table 6.5: Risk Mitigation Strategies

By monitoring the risks listed above we hope to minimize their occurrence. Mitigation strategies are listed in below in the next section, should we encounter these risks.

Risk Monitoring Strategies

Throughout the project the risks will be reassessed and updates will be made to risk mitigation strategies. The risks will be discussed during periodic project reviews and status reports.

Risk monitoring will consist of the following:

• Risk 1: To monitor how we are doing with regards to the schedule, we will look at the current schedule and calendar and make updates as needed.
• Risk 2: By constant use of development box we will know if a hardware failure occurs. To be safe we will make a weekly backup.
• Risk 3: With constant communication with sponsor and group members we will keep on top of changes that are made in the requirements.
• Risk 4: We will do monitoring of security news websites weekly.
• Risk 5: By configuring and using required project technologies, we will find compatibility issues that arise.
• Risk 6: We will place a high priority level on interface specification and allocate a few extra resources, and checking the schedule regularly.
• Risk 7: We will check the complexity and progress of the project during weekly status reports.
• Risk 8: To keep up to date on what each team member is doing, each team member will write a weekly status report and email it to the team.
• Risk 9: We will use constant communication through many channels.
• Risk 10: This risk can’t be monitored until it happens.
• Risk 11: We will monitor interface through progress reports and schedule.
• Risk 12: Creating a log of events that occur will help with security monitoring.
• Risk 13: During the testing cycle, performance testing can be done.
• Risk 14: There will be intensive testing and checking during the review process.
• Risk 15: To keep track of bugs and software problems, we will use a bug track log and then have other group members verify that problem is corrected after the bug fix. We will test related functionality to make sure other things did not break once the bug fix was applied. Verifications will be logged too.
• Risk 16: Logging events that occur both on the web server and in the application can help track down security problems.
• Risk 17: We will do a weekly check of product websites for patches and make sure that everything is up to date.
• Risk 18: We will add some extra time to the schedule for such things as upgrades.
• Risk 19:To track changes in the technologies that we are using, weekly monitoring of technology news websites will be done.
• Risk 20: Individuals will educate themselves on what is going on in this field.
• Risk 21: We will do research at the beginning of the project on competitive products, and keep an eye out for things that we may have overlooked.

Summary

Through detailed documentation, constant communication, quality tracking and constant research we hope to be able to avoid most of the identified risks.

When we identified the risks, we recognized that time management is significant since the project must follow the college capstone curriculum timeline. Also, changes in technology are fast and it is important to be aware of and to keep up with them. Security issues are always a major issue in computer networking, and we should have a good knowledge of it to be confident with our product.

By identifying the possible risks associated with the project and ways for minimizing or mitigating them we feel confident that we will not have any major surprises. Although we have identified many risks we feel better prepared to deal with problems should they arise. The overall project seems to have a moderate to low risk associated with it.