HeaderSIS.jpg

IS480 Team wiki: 2017T1 CodeBenders Risk

From IS480
Jump to navigation Jump to search


Codeblender logo.jpg
Home CodeBlenders.png

HOME

Users CodeBlenders.png

ABOUT US

ProjectOverview CodeBlenders.png

PROJECT OVERVIEW

Calendar CodeBlenders.png

PROJECT MANAGEMENT

File CodeBlenders.png

DOCUMENTATION

 

PROJECT SCHEDULE


CodeBendersriskimpactassess.png The risk impact assessment requires the team members to consider the impact of each risk across the various project objective areas. Based on this potential impact, the risk is assigned to one of the 5 identified scales below.
CodeBendersmatrix.png Codebenderspotentialrisks.png

S/N Risk Category Risk Type Risk Management Likelihood Impact Strategy
1 Technical Risk Application Execution Risk Risk: The operation of the application has a strong dependency on data connection/Wi-Fi and Phone Signal.

Action: We design and develop the application such that it uses minimal data transmission and can transmit on lower end data bands.

0.9 Low Passive Management
2 Technical Risk Development Risk Risk: Since we are developing an application that is cross platform, we may run into development issues where the compilation or running of the application is possible on 1 platform but not the other.

Action: We have team members with both Android, Windows and Apple based devices so we can shift development and testing between devices to make sure that the development is completed while maintaining quality.

0.3 Moderate Passive Management
3 Technical Risk Development Risk Risk: This is the first time that team members are using the the tooling suggested by clients (Microsoft Visual Studio and Microsoft Xamarin) that is to be used to develop the application, hence there may be unfamiliarity with the UI.

Action: The team will engage in sufficient education on the tooling as well as undertake mini development projects before proceeding on to work on the development of the application so that work can be completed as efficiently as possible.

0.7 High Active Management
4 Technical Risk Application Execution Risk Risk: Team members have little to no experience with working on mobile development projects as well as with development in the language, C#. Hence the understanding of how to go about development as well as creating the framework and architecture may be ambiguous.

Action: The team will engage in sufficient education on the tooling as well as undertake mini development projects before proceeding on to work on the development of the application so that work can be completed as efficiently as possible.

0.7 High Active Management
5 Client Risk Stakeholder Risk Risk: Potential lack of use because employees are not comfortable with using technology and figuring out how the application works.

Action: We will conduct adequate research into scenarios and personas, multiple rounds of prototyping with sufficient client feedback prior to starting the development on the UI. Additionally, run through a tutorial during the first launch to highlight the importance of the features and use of the application.

0.5 Very High Active Management
6 Client Risk Stakeholder Risk Risk: Failure by employees to download and regularly update the application.

Action: Taking this into consideration, we will set up the application such that auto updating is carried out in the background once connected to a network.

0.7 High Active Management
7 Client Risk Stakeholder Risk Risk: Misuse of the application by uses (ie activation for non-emergency situations).

Action: During the initial use tutorial, we emphasise that this application is to be used for emergencies only. Beyond this, we will advise the client to issue advisory emails to ensure behaviour that is compliant.

0.5 Moderate Passive Management
8 Client Risk
&
SMU-Related Risk
Organisational Risk
&
University Risk
Risk: Unexpected school/company related events causing delays in supervisor/sponsor meetings.

Action: On a monthly basis, we will fix down meeting dates with sponsors, with additional contingency dates for higher priority meetings.

0.5 Low Conditional Management
9 SMU-Related Risk University Risk Risk: Insufficient time to complete due to school and course workload.

Action: Ensure equitable work distribution and peer to peer work tracking so that members are aware if there are any incomplete tasks that would hold up the schedule. Additionally, add in sufficient buffer time to cope with unexpected changes.

0.3 Moderate Passive Management
10 SMU-Related Risk Team Risk Risk: Conflicting schedules between team members reducing the amount of time available for meeting.

Action: During term planning and bidding exercises, we will collaborate and communicate with regards to class and CCA time planning to maximise the availability of time to meet.

0.5 Moderate Passive Management
11 SMU-Related Risk Team Risk Risk: Team members fall sick to the point where contribution to project is affected (ie hospitalization).

Action: Always ensure that the wellbeing of the team members is preserved by encouraging healthy diet, exercise and work life balance. Additionally, conduct peer sharing sessions so that everyone is aware of what is being done by each other such that taking over will be easy in such situations.

0.1 High Conditional Management
12 SMU-Related Risk Team Risk Risk: Personal Laptop Devices breaking down during the term.

Action: We adopted the usage of Git to do version control and ensure access of files on all member’s computers. Additionally, everyone is to perform backups of data onto personal storage at frequent intervals and use their personal electronic devices wisely.

0.1 High Conditional Management
13 Project Management Risk Scheduling Risk: Due to the existing uncertainty with project scoping as well as the lack of prior experience with mobile development, estimation of the time required to complete tasks can be quite ambiguous and thus, there may be situations where too little or too much time is allocated to various project tasks.

Action: After receiving the details of the application requirements from the client, we conduct internet research as well as consult people whom we know (friends, family, schoolmates) who have experience in app development with similar functionality to aid in our estimations. furthermore, during the documentation and planning stages, the granularity of breakdown of the development tasks will increase allowing us to get a more accurate picture of how long the task will take.

0.9 Very High Active Management