Risk Management Plan

The various risks in the project are split into three categories.

• Group Member Risks are risks that can occur within the team.
• Development Technologies Risks are risks that can occur with the different development technologies and frameworks used.
• Testing Technologies Risks are risks that can occur with the Testing technologies used as well as the Testing team.
• Other risks are any other risks that may occur.

	Severity	Probability
Very Low	A minor risk that can easily be avoided or resolved quickly	Highly unlikely to occur
Low	A minor risk that may be avoided or resolved quickly	Unlikely to occur
Medium	A risk that requires the team's attention and would require a team effort to resolve	Likely to occur
High	A risk that would require a lot of time and team effort to resolve	Highly likely to occur
Very High	A very high risk that requires significant time and team effort to resolve	Almost guaranteed to occur

Top 10 Risks

The top 10 risks in terms of highest to lowest risk are found here https://bit.ly/39VatqN

Group Member Risks

Risk 1: Team members may withdraw from the class.

• Probability: Low
• Severity: Medium

Solutions:

• Mitigation

  • Communicate with other team members early on if someone is thinking to drop the class.
  • Frequent meetings with team members to see how everyone is feeling and what they are working on.
  • Make use of pair programming and tutorials so people are familiar with the technologies being used.
  • Have Backup positions (Backup Project Manager: Jorgen, Backup Dev Lead: Zack, Backup Testing Lead: Sahngwoo, Backup Risk Manager: Mark).
  • Project leads should consistently communicate with the backup positions what they are working on in case the backup needs to take over.

• Contingency plan

  • Assign the responsibilities of the person who dropped to another team member working in a similar field.

Risk 2: Miscommunication between team members

• Probability: Medium
• Severity: Medium

Solutions:

• Mitigation
  • Have a clear requirements document.
  • Constantly review documents.
  • Review pull requests.
  • Discuss the tasks assigned and what we are currently working on using Github issues.
  • Have consistent communication with the team through meetings to ensure tasks are not misunderstood.
  • Encourage team members to ask questions.
  • Have a standup to communicate with team members about what you are doing.

Risk 3: Lack of commitment due to personal reasons or due to responsibilities towards other classes.

• Probability: Very High
• Severity: Medium

Solutions:

• Mitigation

  • Plan ahead and get work done early.
  • Communicate with team members on any other major commitments which may arise.
  • implement sprint planning.

• Contingency plan

  • If a particular member is overwhelmed with other work, a teammate in a similar field will take over or help with the responsibilities.

Risk 4: Poor time estimation (Members may poorly estimate the time taken to complete a task).

• Probability: Very High
• Severity: High

Solutions:

• Mitigation

  • Start tasks as early as possible.
  • Let team members know if a task is taking longer than planned.
  • Have a standup where teammates give the state of tasks and issues.

• Contingency Plan

  • In the event a task is too difficult or taking longer than expected, have a team meeting to find a solution together.

Risk 5: Team members get sick from Covid or other illnesses

• Probability: High
• Severity: Medium

Solutions:

• Mitigation

  • Introduce pair programming so team members familiarize themselves with others' code so they can potentially take over.
  • Have Backup positions (Backup Project Manager: Jorgen, Backup Dev Lead: Zack, Backup Testing Lead: Sahngwoo, Backup Risk Manager: Mark).

• Contingency Plan

  • Use online discord/zoom meetings for discussions and team meetings.

Risk 6: Lack of Technical skills (Team members may be unfamiliar with the technologies and frameworks used).

• Probability: Very High
• Severity: High

Solutions:

• Mitigation
  • Have online tutorials help by more experienced members to teach unfamiliar members the technologies/frameworks used.
  • Do self-research on the internet and use youtube tutorials to familiarize oneself with the technologies.
  • Using spike prototypes to familiarize oneself with the technologies being used.
  • Discuss and get help from the TA on the technologies being used.

Development Technologies Risks

Risk 1: Problems with user authentication using Keycloak

• Probability: Very High
• Severity: High

Solutions:

• Mitigation
  • Authentication is not natively supported so we must create spike prototypes to figure out how to use Keycloak for authentication.

Risk 2: Problems with maintaining software security

• Probability: Very High
• Severity: Very High

Solutions:

• Mitigation
  • Have a dedicated security officer to investigate security issues as well as maintain software security.
  • Security officer will work with developers and testers to make sure the software is secure.
  • Get help from the TA on the security concerns.

Testing / Testing Technologies Risks

Risk 1: Poor testing/ Lack of adequate testing

• Probability: Medium
• Severity: High

Solutions:

• Mitigation
  • Have a thorough testing plan on how to adequately test the software.
  • Have smoke tests, unit tests, regression tests, system tests, code coverage tests.
  • Have peer reviews on written test scripts and test documents to ensure software correctness

Risk 2: Selenium errors when HTML ID tags are changed (If tags are changed by the developer then tests scripts will fail).

• Probability: very low
• Severity: low

Solutions:

• Mitigation
  • Keep HTML tags the same unless there is a special need to change the tags.
  • Alert the testing team as soon as possible if a tag is changed so test scrips can be quickly updated.
  • Work with a development buddy.
  • Include selenium tests in the continuous integration pipeline.

Risk 3: Problems with testing for flaws with software security

• Probability: Very High
• Severity: Very High

Solutions:

• Mitigation
  • Ensure key security features such as two-factor authentication are thoroughly tested.
  • Possibly investigate some software security testing tools.
  • Talk to professor and TA about how to test for software security.
  • Security officer can help investigate and test for software security.

Other Risks

Risk 1: Stakeholder wants to change requirements/team misunderstands stakeholders requirements

• Probability: High
• Severity: Medium

Solutions:

• Mitigation
  • Have multiple members during stakeholder meetings to ask questions and make sure nothing is misunderstood.
  • Have a clear requirements document stating the features and what we are building.
  • Have frequent communication with the stakeholder to confirm their requirements are being met by the software we are building.
  • Have requirement reviews between members.
  • Have a demonstration environment to show the stakeholder what we build
  • Show mockups and prototypes to the stakeholder for feedback.
  • Record the stakeholder meetings so all group members can view the meetings.