HeaderSIS.jpg

Difference between revisions of "IS480 Team wiki: 2012T2 Team Prime Final Wiki"

From IS480
Jump to navigation Jump to search
Line 234: Line 234:
 
|+  
 
|+  
 
|-
 
|-
! scope="col" width="200" style="background-color:#843A36"| <font color="#ffffff">Stage</font>
+
! scope="col" width="200" style="background-color:#794721"| <font color="#ffffff">Stage</font>
! scope="col" width="200" style="background-color:#843A36"| <font color="#ffffff">Specification</font>
+
! scope="col" width="200" style="background-color:#794721"| <font color="#ffffff">Specification</font>
! scope="col" width="400" style="background-color:#843A36"| <font color="#ffffff">Modules</font>
+
! scope="col" width="400" style="background-color:#794721"| <font color="#ffffff">Modules</font>
 
|-
 
|-
! scope="row" rowspan="2" width="120" style="background-color:#f5f5f5; text-align:center;"|Project Management
+
! scope="row" rowspan="2" width="120" style="background-color:#FFFFFB; text-align:center;"|Project Management
 
|align="center"|Minutes
 
|align="center"|Minutes
 
|style="text-align="left"|
 
|style="text-align="left"|
Line 251: Line 251:
  
 
|-
 
|-
! scope="row" rowspan="2" width="120" style="background-color:#f5f5f5; text-align:center;"|Requirements
+
! scope="row" rowspan="2" width="120" style="background-color:#FFFFFB; text-align:center;"|Requirements
 
|align="center"|Product Backlog
 
|align="center"|Product Backlog
 
|style="text-align="left"|
 
|style="text-align="left"|
Line 262: Line 262:
  
 
|-
 
|-
! scope="row" rowspan="2" width="120" style="background-color:#f5f5f5; text-align:center;"|Analysis
+
! scope="row" rowspan="2" width="120" style="background-color:#FFFFFB; text-align:center;"|Analysis
 
|align="center"|Use Case
 
|align="center"|Use Case
 
|style="text-align="left"|
 
|style="text-align="left"|
Line 273: Line 273:
  
 
|-
 
|-
! scope="row" rowspan="2" width="120" style="background-color:#f5f5f5; text-align:center;"|Design
+
! scope="row" rowspan="2" width="120" style="background-color:#FFFFFB; text-align:center;"|Design
 
|align="center"|ER Diagram
 
|align="center"|ER Diagram
 
|style="text-align="left"|
 
|style="text-align="left"|
Line 284: Line 284:
  
 
|-
 
|-
! scope="row" rowspan="2" width="120" style="background-color:#f5f5f5; text-align:center;"|Testing
+
! scope="row" rowspan="2" width="120" style="background-color:#FFFFFB; text-align:center;"|Testing
 
|align="center"|User Test 1
 
|align="center"|User Test 1
 
|style="text-align="left"|
 
|style="text-align="left"|

Revision as of 03:47, 19 April 2013

<< MAIN WIKI         << MIDTERM WIKI

PrimeLogo.png


Project Progress Summary

Project Overview

Final Presentation Slides

Swimix Deployed Site Link

  1. The team has completed 8 sprints in total and is now finishing its final milestone.
  2. We have completed all core, secondary, and tertiary features within our SCHEDULE as listed in the PRIORITY CIRCLE.


This is where we are on the timeline:
Prime ProjectMilestones WeAreHere V0.2.png

Project Highlights

Event Highlights / Issue Description
Sprint 6
Instructor web mobile feature dropped
Due to the slow progression made, the team decided to drop the instructor web mobile feature in order to bring the project back on schedule.

Integration of payment feature pushed to Sprint 7
Towards the end of the sprint, the team encountered difficulties with integrating the payment feature. Hence, the team decided to bring forward the integration to the next sprint.
Sprint 7
Swim school features dropped
The team faced difficulties in implementing the payment feature. To focus our efforts on finishing up the payment feature, the team decided to drop the swim school feature. A secondary reason is that swim schools are not the main target market for Swimix.

Project Challenges


Project Achievements

  1. Secured Singapore Olympian swimmer Tao Li as our celebrity sponsor. View our interview with her HERE.
  2. Successfully conducted 2 rounds of USER TESTS at Yishun Swimming Complex and Sengkang Swimming Complex, with a total of 38 users and 7 swimming instructors.
  3. Received confirmation of investment on Swimix from investor Dr Virginia Cha, who is also one of our PROJECT ADVISORS from SMU Institute of Innovation & Entrepreneurship.


Project Management

Schedule (Planned Vs Actual)

Prime Schedule BeforeAfterV2.png

Since the midterms, the following changes have been made to the project schedule:

  1. Manage Notifications feature was brought forward to Sprint 6.
  2. Integration of Payment feature was shifted from Sprint 6 to Sprint 7.
  3. Sprint 7 was shifted earlier to the User Test 2 milestone.
  4. Instructor web mobile and Swim School features were dropped from Sprint 6 and Sprint 7 respectively.
  5. Change of date for User Test 2 to 7 April 2013


Refer to the PROJECT TIMELINE for a full view of the current project schedule.


Scope (Planned Vs Actual)

Prime PriorityCircle BeforeAfter.png

Since the midterms, the following changes have been made to the project scope:

  • The Instructor Web Mobile and Swim School features were re-prioritised as Good-to-Have features so that we can have a more manageable scope.



Project Metrics

Schedule Metric

The diagrams below show the burndown charts and schedule ratio charts of Sprints 6 to 8 since the midterms.

BURNDOWN CHARTS

Prime BurndownCharts Sprints678.png

SCHEDULE RATIO CHARTS

Prime ScheduleRatioCharts Sprints678.png

KEY ISSUES

Sprint 6:

  1. On 12 Mar, the burndown chart indicated that the team was behind schedule. This was due to the slow progression of the team. The team decided to drop the instructor web mobile feature in order to bring the project back on schedule.
  2. Towards the end of the sprint, the team encountered difficulties with integrating the payment feature. Hence, the team decided to bring forward the integration to the next sprint (Sprint 7).

Sprint 7:

  1. 1. On 23 Mar, the burndown chart indicated that the team was behind schedule. This was because the team faced difficulties in implementing the payment feature. To focus our efforts on finishing up the payment feature, the team decided to drop the swim school feature. Moreover, swim schools are not the main target market for Swimix.


For more details:
1. Schedule Metric Calculation
2. Schedule Ratio Documentation: Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7 Sprint 8

Bug Metric

Prime NoOfBugsFound V3.png

Number of Bugs Found

  1. The chart above shows the number of bugs found in each sprint.
  2. In Sprint 6, there was a slight spike in the number of bugs found (5), as more rigorous testing was conducted on the application to prepare for User Test 2 (originally scheduled in Sprint 7).


Prime BugMetricSeverityChart V3.png

Total Bug Score

  1. The chart above shows the corresponding bug severity score with the number of bugs found in each sprint.
  2. The bug severity score in Sprint 6 (13 points) was the highest out of Sprints 6 to 8 (after midterms) due to the testing for User Test 2 as mentioned above.
Total Bug Score Action to be Taken
< 5 Developers resolve issues within the sprint.
5 - 9 Resolve the bugs during the planned debugging time.
≥ 10 Stop current development and resolve the bugs immediately.


For more details:
1. Bug Metric Calculation
2. Bug Log

Change Request Management

ChangeRequest.png

  1. If the priority is a MUST, we will implement the change
  2. If the priority is a SHOULD and the time to implement the change is VERY SHORT, SHORT, or MEDIUM, we will implement the change.
  3. If the priority is a COULD, and the time to implement the change is VERY SHORT, we will implement the change.
  4. If the priority is a WON'T, then we will not implement the request.

View our Change Request Log.

Project Risks

The top 3 risks are prioritised as follows:

Risk Probability Impact Mitigation
Many issues might be raised during user tests; time is required to rectify these issues High Medium Create a response plan document to help us decide whether to implement a change based on priority, complexity and time needed to rectify the issues.
Project contains numerous documentation and different versions. Inefficent access to a particular document. Low Medium Use a collaborative file management software (e.g. Google Documents, Dropbox) to organise respective folders of the project. Consensus amongst team members to adhere to proper version labelling.
Putting too much focus on fixing user interface issues compared to ensuring the system logic is working properly High Medium Prioritize the task according to the criteria and strike a balance between the two.

View the full list of risks HERE.

Technical Complexity

The following technical complexities have been listed in order of complexity (highest to lowest):

Complexity Description
1. Calendar
  • What the feature is
  • Type here
  • Type here
  • Type here
  • What was complex
  • Type here
  • Type here
  • Type here
2. Payment
  • What the feature is
  • Type here
  • Type here
  • Type here
  • What was complex
  • Type here
  • Type here
  • Type here

Quality of Product

Intermediate Deliverables

Stage Specification Modules
Project Management Minutes
Metrics
Requirements Product Backlog
UI Mockups
Analysis Use Case
Process Flow Diagram
Design ER Diagram
System Architecture Diagram
Testing User Test 1
User Test 2

Deployment

Area Description
Development Environment
Web browser running on Firefox, Internet Explorer, Safari and Google Chrome
Database
Database hosted on Vodien
Web Links
View the Swimix application

Testing

Objectives

OBJECTIVES:

  1. To obtain feedback from our users with regards to the features in the application
  2. To improve the usability of the application


Scope

The table below shows a list of features that were tested for our first user test. The features target parents (representing registered users of Swimix) and swimming instructors.

No. Features Reg. User Instructor
1 Register / Log in / Log out
2 Change Password
3 Update User Profile
4 Update Instructor Profile
5 Search for Class
6 Search for Instructor
7 Create and Remove Lesson Slot
8 Create and Remove Student Details

Insert relevant PICTURE.

THE SESSION
User Test 1 was conducted successfully on 27 Jan 2013 at Yishun Swimming Complex.

  1. A total of 8 parents participated in the user test in the role of a Registered User.
  2. A total of 2 swimming instructors participated in the user test in the role of an Instructor.


View the Supporting Documents for the user test HERE.
View our Internal Testing Documents (Before User Test 1) HERE
View our Internal Testing Documents (Before Midterm) HERE


Testing Methodology

Collecting of Qualitative Metrics

  1. Participants are encouraged to think aloud their thought process as they are performing each task. For example, we would encourage them to say whatever they are looking at, thinking, doing, and feeling as they go about the task. This enables us as the observer to better understand each participant’s thought processs and see first-hand the process of him/her completing the task.
  2. Facilitators will observe for usability issues during the testing procedure by recording down what participants say. The test sessions will also be video-recorded on Screen Flow so that we can go back and refer to what participants did and how they reacted.
  3. In addition, after participants have completed the user test, they will be asked to do a satisfaction level survey that will aid in the collection of qualitative metrics.

Collecting of Quantitative Metrics

  1. The amount of time taken to complete each task
  2. The number of clicks taken for each task


Registered Users

MOST COMMON FEEDBACK:

UserFeedback1.png

Solution: Place Login and Register in the same area and allow switching by tabs.

UserFeedback2.png

Solution: Change the View link to a button so users know that they can click on it to view the instructor’s profile



POST-TEST SURVEY RESULTS:


SN Functions Very Unlikely Unlikely Undecided Likely Very Likely
1 Search for Class/Instructor
0 0 0 5 3
2 Online Class Registration
0 1 2 3 2
3 Online Payment
0 1 0 4 3
4 Instructor Review
0 2 1 4 1
5 Instructor Rating
0 0 2 5 1
6 Receive Notification
0 0 1 3 4


Conclusion

Based on the user feedback, we found out that users are mostly receptive to the idea of a swim-related search portal.

The top 2 favourite functions identified by the users were the Manage Search function and the Manage Notification function. They commented that the search function was easy to use and could be very useful to them. The notification function is also something they felt is lacking in the industry now. This is because they have made wasted trips to the swimming complex on the lesson day only to find out the lesson was cancelled.

The function that had the highest amount of users indicating that they are unlikely to use is the Instructor Review feature. They explained that they would not want to go through the trouble to register an account just to write a review for the instructors. However, they would not mind writing if given the option of a simpler and more convenient alternative.

A user also commented that he preferred to register classes with the instructor in person instead of registering online because he could infer the instructor’s character and personality through the former. A possible solution is to include a short introduction video clip of each instructor so that users are able to gauge the instructor for themselves through the video.

In conclusion, many users expressed that they portal is user-friendly and would be very useful to them.


Instructors

MOST COMMON FEEDBACK:
InstructorFeedback1.png

Solution:
Use radio buttons instead of dropdown list.

InstructorFeedback2.png

Solution:
Display only the student name and contact number.
Instructors can choose to click on the student's name to view the rest of their information.


POST-TEST SURVEY RESULTS:


SN Functions Very Unlikely Unlikely Undecided Likely Very Likely
1 Adding lesson slots to calendar
0 0 1 1 0
2 Selling available class slots
0 0 0 1 1
3 Sending mass notification
0 0 0 0 2
4 Online payment system
0 0 2 0 0


Conclusion

It was hard for us to get instructors to test our system because they are usually busy all the time while they are at the pool. They will either be teaching a class, or be on duty as a security guard. Thus, we only managed to get 2 instructors testers during their lunch break period when the weather is typically too hot to conduct a swim class.

Both instructors found the portal user friendly and did not face any problem using the portal. They provided mostly aesthetics feedback, such as the student list is too cluttered and the login button is too small. In addition, an important point which they commented was that since they are always on the go, they preferred to use the system on their smartphone rather than in front of the computer.


Reflections

Team Reflection: Key lessons learned – indicating where the team improved, or would do things differently next time. You may refer to the learning outcome summary in your proposal. A very short checklist style will suffice. It would be very convincing if the knowledge is share at the wiki knowledge base and linked here.

Individual Reflection: Describe in a paragraph, the key areas of learning or improvement. These should be personal areas of growth or learning. Each individual should list his/her effort, responsibility, actual contributions and personal reflection. Do not repeat team project contributions or member roles. Link if necessary.

Sponsor Comment: Sometimes, the client writes a report to feedback on the system; this sponsor report can be included or linked from here.

Member Reflections
Prime XC.png
Shen Xiaochuan
  • -
Prime HQ.png
Lim Hui Qing
  • -
Prime JO.png
Josephine Heng
  • -
Prime LR.png
Larry Ho
  • -