1. Risk management Here’s my section for risk management! ~ Christopher Thornton

2. Risks due to… Product Size – This is a relatively small program and it has few requirements. This is a very small risk and is answered in the risk Time for Requirements Business Impact – The only risk in this regards is if the product does not meet expectations, is late or is faulty. In a real environment, this would all result in a loss of revenue, but in our situation, it would result in a loss of our grade. Customer – We’re technically doing this project with our professor as the customer. However, it’s more realistic to say that we’re our own customer because we define our own requirements

3. Risks due to… Process Maturity – We do not have a document format. However, the deliverable enforces a single format. Technology Risk – We’re using Java, which has been proven for many years. Our risk for this is very low, as we’re not inventing or trying anything new and no performance constraints exist. Staff/People – We’re all new to the software development cycle. Also, there might be a very high degree of difference in skill level, especially with Java.

4. Risk Assessment Summary High 80 – 100% Medium- High 60 – 80% Team experience Team member fails to finish task Medium 40 – 60% Low- Medium 20 – 40% Time for Req’s Low 0 – 20% Requirements Team member drops class MinimalLowMediumHighSevere Probability of Occurrence Consequence of Impact (Average of Severity and Duration)

5. Team Experience Risk Type Staff Priority 2 (low) Risk Factor very few of us on this team has experience working in a group software project. As such, there will be difficulties working as a team (communication, etc). However, this risk is low because learning how to work as a group is part of the class and difficulties and conflict are to be expected. Probability 75% Preventative Plan the best way for this risk is to attempt to prevent it from happening as much as possible, but it’s impossible to prevent it totally. To prevent issues, we assign each team member weekly tasks. Contingency Plan if things do eventually get out of hand, we can re-assign tasks as needed. If necessary, we would sit down as a group and figure out how to change what we’re doing to achieve success.

6. Team Member Fails to Finish Task Risk Type Schedule Priority 4 (High) Risk Factor people have other important things outside of this project, such as other classes and projects. As such, it’s likely somebody will eventually forget to finish one of their tasks. However, the consequences of failing to do a task may set us back a week or end up in last minute work. Probability 75% Monitoring Approach since deliverable 1, we’ve implemented a policy where weekly tasks are written up as tickets in Assembla and they all have due dates. Contingency Plan if somebody fails to submit their ticket for review by the given deadline (usually Tuesday at 10pm after the task was assigned), then the team leader will call the person and remind the person it’s due. If this fails, then the team leader will assign the task to another person to get it done before the next team meeting. The team leader will take note of this when it comes deliverable time.

7. Time for Requirements Risk Type Schedule Priority 3 (medium) Risk Factor even if every team member always does their weekly tasks, it is possible that we might not get to implement all of the requirements we would like. Probability 35% Monitoring Approach to ensure that we get all of the features we want, I have created additional milestones separate from the deliverable milestones. This way, we can evenly spread out all of the features we want to do. Contingency Plan if our best efforts to ensure that all of our features are implemented fail, then there is nothing we can do. We will simply have to do without them. This is only an acceptable option for should have and nice to have requirements

8. Requirements Risk Type Support Priority 1 (minimal) Risk Factor as the project continues, it’s possible that we decide that the requirements we made are unrealistic, or we may decide to add more. Probability 5% Contingency Plan we will try to keep flexibility in mind when designing our system. However, I can’t expect any of our requirements we change to dramatically alter our project, so we would just make them fit as best we could.

9. Team Member Drops Class Risk Type Staff Priority 3 (medium) Risk Factor it is possible that a team member might decide to drop the class, whether it be due to illness or other causes. Having one less person would have a detrimental impact on our team. Thankfully the probability of this is low. Probability 10% Monitoring Approach there is no way we can predict whether somebody will drop this class. Contingency Plan how we react is dependent on how far through the project we are. The first obvious option is to have the rest of the team cover for him. However, if we’re late in the project, the only option we would have is to drop several of our requirements and possibly do less testing than what would be ideal.

10. Conclusion This project is relatively simple and there shouldn’t be any major issues with technology, customers, stakeholders, etc. The main risk in this project is the fact that many of us have not done a group software project before and that we have lives outside of this project. However, if we all put our fair share of effort into this project, there’s no reason why we shouldn’t do well.

11. Hypothetical Risks What if this was a real project? Scalability given this is a laboratory treadmill, it’s quite likely the client would want to change this. For example, perhaps storing results in a central SQL database or a central sever Team member unable to work say a team member could no longer work, or was fired. Depending upon the current team size, this may cause some setbacks as time would be required to find, hire and train somebody else. Technology this project would be much larger and would likely involve other technologies. Not only, we would need to actually interface with a treadmill instead of merely simulating it