IS480 Team wiki: 2016T1 Team Wallaby Midterm Wiki
Project Progress Summary
- Reordering of functions in iterations to complete all web functions before starting Android functions
- Addition of bootstrap function for professors to upload class list
- Addition of chat function to facilitate communication between Wallaby (helper) and Joey (helpee)
- Dropping the function of allowing online wallabies (helpers) to reject help requests
- Dropping the function of allowing students to undo consultation bookings
Project Management
We have started acquiring live users for the consultation module between week 2 and week 5. With their feedback and UAT test conducted over that period, we have received numerous additional business requirement and user insight that we have not foreseen. As such, we have dropped certain functions based on these collective feedback. More details can be found under the change management segment.
Project Status:
Project Scope (Plan Vs Actual):
Planned | Actual |
---|---|
Project Timeline(Plan Vs Actual):
Planned | Actual |
---|---|
Project Metrics:
Iteration | Planned duration | Actual duration | Schedule Metric Score | Reason and Mitigation Action |
---|---|---|---|---|
2 | 21 | 24 | 87.5 | Team was unfamiliar with the google oauth technology, that was used for the login use case. Follow up action: In future iterations, one member will be assigned to learn and teach the rest of the team if there are unfamiliar technologies in the following iteration. Buffer days cut, and re-estimate functionalities in future iterations. |
6 | 14 | 23 | 60.9 | More time needed to complete suggest group function.Follow up action: No delay to overall schedule. Buffer days cut, and re-estimate functionalities in future iterations. |
Iteration | Bug Score | Mitigation Action |
---|---|---|
3 | 32 | Functions shifted to the next iteration. |
5 | 11 | Functions shifted to the next iteration. |
Project Risks:
To view past risks that the team may have/may not been affected by, please visit: Wallaby Risk Management
Current Risks that may affect the team:
S/N | Risk Type | Risk Event | Likelihood | Impact | Category | Mitigation |
---|---|---|---|---|---|---|
1. | User Risk | Due to the nature of facilitating peer/ faculty interaction, we need to overcome the mental barrier set by our potential users (especially students in our Peer Helping Module) to take the first step to try our System. | High | High | A | There is a need to constantly engage with student users. The team made promotional videos that is shown during large gatherings and during classes, when there is a major update. Click here for the latest video on our Wallaby Peer Helping Module: https://www.youtube.com/watch?v=5T79GGWugwU We are also contacting teaching assistants in foundation modules to join us as Wallabies (Helpers) in the System. |
2 | Technical Risk | Overall, the team is not familiar with the technologies/resources used for developing the project (i.e. Andriod Platform, Google API, etc.) | High | High | A | Each team member is to do independent research before the iteration. There will be a sharing session every weekly meeting on the relevant technologies. |
3 | Technical Risk | Google/ Openshift servers goes down in bouts of time. | High | High | A | We are exploring the option of hosting on the school server. |
Technical Complexity:
Quality of product
Intermediate Deliverables:
Topic of Interest | Link |
Project Management | Minutes |
Metric | |
Risk Management | |
Change Management | |
Requirements | Story cards |
Analysis | Screen Shots |
Design | Class Diagram |
ER Diagram | |
Testing | User test plan |
Deployment:
Our Wallaby System can be found at this URL: http://is480-wallaby.rhcloud.com/
- Note: The system is laptop optimised
If you are a student, please log in using your SMU account
Username: xxx.20xx@smu.edu.sg and the password: your SMU account password
If you are a faculty member, please contact Kar Enn at karenn.ho.2014@sis.smu.edu.sg to be added into the system.
Testing
Describe the testing done on your system. For example, the number of user testing, tester profile, test cases, survey results, issue tracker, bug reports, etc.
User Testing
Since we are largely a marketplace system, we constantly seek for user feedback so as to attract more users to come aboard our system. We have 2 general group of target users:
1. Teaching Faculty
2. Students
When either one provides suggestion for a change in functionality, and based on the results from our Change Management Process, we will conduct User Testing on the target user who will be affected, to see if the suggestion is valid.
User Acceptance Testing
For testing of the whole system, we conduct User Acceptance Testing with our target users. Click here to see our UAT test plan.
Reflection
Team Reflection:
As a self-proposed project, the most challenging aspect is that we do not have a sponsor to give us specific project scope. Considering that our target users are our school mates and professors, we get many feedback and request for both functional and aesthetic changes, which gets overwhelming at times. Thus, we have learnt to manage the various demands over the course of the project, balancing both their expectations and our limited resources, to ensure that the product we create solves the real world problem that we have set out to solve at the start.