Difference between revisions of "IS480 Team wiki: 2015T2 6Sigma Risks"
Jump to navigation
Jump to search
Line 86: | Line 86: | ||
|During the final presentation period, we would schedule ourselves to be on standby for assistance in case of technical difficulties faced by faculty members. | |During the final presentation period, we would schedule ourselves to be on standby for assistance in case of technical difficulties faced by faculty members. | ||
|- | |- | ||
− | | | + | |Adoption Risk |
− | | | + | |Our system might not be well received by the IS480 Community and it would be used for the final presentation grading by the faculty and students |
|High | |High | ||
|High | |High | ||
|style="color:red;" | '''A''' | |style="color:red;" | '''A''' | ||
− | | | + | |Our team would conduct early user test and aim an early deployment for faculty members to explore the system. |
+ | |Our team gathered feedback from the faculty members personally to meet their requirements of the system. Also, we also addressed the concerns which faculty members might have regarding our application before the final presentation starts. Moreover, we got a sensing of how comfortable the faculty were with using our application. | ||
+ | |- | ||
+ | |Integration Risk | ||
+ | |During the integration of our application with the SSO service provided by IITS, there might be data compatibility issues. | ||
+ | |High | ||
+ | |High | ||
+ | |style="color:red;" | '''A''' | ||
+ | |Use available data on LDAP (Lightweight Directory Access Protocol) in hopes of a full compatibility. | ||
+ | |When there were login issues, we communicated with IITS and conducted an investigation with regards to the smu_groups fields that the SSO application returns to resolve it | ||
|- | |- | ||
|Technology Risk | |Technology Risk |
Revision as of 17:41, 18 April 2015
Schedule | Metrics | Task List | Risks | Issues Faced | User Tests & Surveys |
---|
We've classified the risks we've identified into 3 categories: A, B and C.
A’ risks need the most attention and most well developed mitigation or recovery strategies,
‘C’ risks can occur but deserve the least amount of planning.
Risk Type | Risk Event | Occurrence | Impact | Category | Prevention | Reactive |
---|---|---|---|---|---|---|
Live deployment risk | Our applications might face issues in the production environment when it is used for actual grading. | High | High | A | Our testing environment would be replicated as closely as possible to the deployment environment. | During the final presentation period, we would schedule ourselves to be on standby for assistance in case of technical difficulties faced by faculty members. |
Adoption Risk | Our system might not be well received by the IS480 Community and it would be used for the final presentation grading by the faculty and students | High | High | A | Our team would conduct early user test and aim an early deployment for faculty members to explore the system. | Our team gathered feedback from the faculty members personally to meet their requirements of the system. Also, we also addressed the concerns which faculty members might have regarding our application before the final presentation starts. Moreover, we got a sensing of how comfortable the faculty were with using our application. |
Integration Risk | During the integration of our application with the SSO service provided by IITS, there might be data compatibility issues. | High | High | A | Use available data on LDAP (Lightweight Directory Access Protocol) in hopes of a full compatibility. | When there were login issues, we communicated with IITS and conducted an investigation with regards to the smu_groups fields that the SSO application returns to resolve it |
Technology Risk | As mediawiki is highly unfavorable to crawling, crawling efforts might fail | High | High | A | The development for learning analytics is kept to the end so as to cater time to manually extract data in the event the wiki is uncrawlable. | |
Requirement Risk | Sponsor may request for significant changes in requirements, adversely affecting the project schedule. | Medium | Medium | B | 6Sigma would communicate regularly with the client such that the required changes can be quickly made known to the team. Hence, an agile development methodology will be adopted to accommodate to the client’s changes in request as much as possible. | |
Resource Risk | There may be technical issues leading to unscheduled downtime for the VM, adversely affecting our testing and development. | Low | High | B | Replicate the VM environment on another machine so that in the event that such an incident occurs, testing and development may still continue. | |
Project Management Risk | As new technologies are employed in this project, there may be inaccuracy in time allocated for development. Hence, project may not be out for deployment by midterm as planned. | Medium | Medium | B | The project manager will review the time taken for front end development in every iteration, and re-allocate the time planned for front end development. | |
Technology Risk | Adoption of new technologies may result in slower development and debugging; code quality may also be reduced. | Low | Medium | C | Damien, the UE Analyst, is familiar with the new technologies that we will adopt. As such, he will double up as the Subject Matter Expert on the technologies, providing coaching if required. However, members will still be expected to research on the technologies on their own. |