Difference between revisions of "IS480 Team wiki: 2015T2 6Sigma Risks"
Jump to navigation
Jump to search
Line 108: | Line 108: | ||
|style="color:red;" | '''A''' | |style="color:red;" | '''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. | |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. | ||
+ | |The data on the IS480 Wiki website was manually crawled after failed multiple attempts to retrieve it programmatically. | ||
|- | |- | ||
| Requirement Risk | | Requirement Risk | ||
Line 115: | Line 116: | ||
| style="color:orange;" | '''B''' | | style="color:orange;" | '''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. | | 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. | ||
− | + | | The extra buffer which was set aside at the start of the project was used to cater for requirement changes. | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | | The | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
|} | |} |
Latest revision as of 21:54, 19 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 Measures | Reactive Measures |
---|---|---|---|---|---|---|
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. | The data on the IS480 Wiki website was manually crawled after failed multiple attempts to retrieve it programmatically. |
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. | The extra buffer which was set aside at the start of the project was used to cater for requirement changes. |