<< MAIN WIKI
<< MIDTERM WIKI
Project Progress Summary
Project Overview
This is where we are on the timeline:
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
Type here
Project Achievements
- Secured Singapore Olympian swimmer Tao Li as our celebrity sponsor. View our interview with her HERE.
- 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.
- 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)
Since the midterms, the following changes have been made to the project schedule:
- Manage Notifications feature was brought forward to Sprint 6.
- Integration of Payment feature was shifted from Sprint 6 to Sprint 7.
- Sprint 7 was shifted earlier to the User Test 2 milestone.
- Instructor web mobile and Swim School features were dropped from Sprint 6 and Sprint 7 respectively.
- 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)
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
SCHEDULE RATIO CHARTS
KEY ISSUES
Sprint 6:
- 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.
- 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. 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
Number of Bugs Found
- The chart above shows the number of bugs found in each sprint.
- 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).
|
Total Bug Score
- The chart above shows the corresponding bug severity score with the number of bugs found in each sprint.
- 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
- If the priority is a MUST, we will implement the change
- If the priority is a SHOULD and the time to implement the change is VERY SHORT, SHORT, or MEDIUM, we will implement the change.
- If the priority is a COULD, and the time to implement the change is VERY SHORT, we will implement the change.
- 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
|
Low awareness of platform
|
High
|
High
|
- We plan to mitigate this through aggressive marketing plans and celebrity endorsements.
|
Low usage of platform
|
High
|
Low
|
- Tap on the power of previous customers’ networks and organize events to encourage signups
- Incentivize users to sign up by giving referral discounts and rebates
|
Idea may be copied by others
|
Low
|
High
|
- Effectively leverage on the first mover advantage to capture the majority of the market share as fast as possible
- More users = Higher value of the portal
|
View the full list of risks HERE.
Technical Complexity
Area
|
Description
|
1. Improvements in Usability
|
- Cross-browser compatibility
|
2. Improvements in Performance
|
- Loading of user profile
- Loading of instructor’s calendar
- Search engine optimization
- Naming convention of class files
- Mapping on CodeIgniter framework (root folder)
|
3. Future Improvements
|
- Internationalization
- Localization
- Payment security
- Responsiveness
- User profile
-
- More data validation needed
|
The following technical complexities have been listed in order of complexity (highest to lowest):
Complexity 1: Calendar
Load the Calendar:
Load the Class:
Complexity 2: Payment
Generate the Order Form:
Confirm Order Form after Payment is Made:
Complexity 3: Search Engine Optimization
Search Engine Optimization:
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
User Test 2
Objectives
OBJECTIVES:
- To obtain feedback from our users with regards to the features in our application so as to improve its usability
- To ensure that the features developed matches the expectations of the real users (parents & instructors)
|
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
|
Search for Class / Instructor
|
✓
|
N/A
|
3
|
Pay for Class
|
✓
|
N/A
|
4
|
Send Mass Notification to Students
|
N/A
|
✓
|
5
|
Send Evaluation Survey to Students
|
N/A
|
✓
|
6
|
Evaluate Instructor
|
✓
|
N/A
|
7
|
Add New Lesson Slot
|
N/A
|
✓
|
8
|
Add Student to Lesson Slot
|
N/A
|
✓
|
THE SESSION
User Test 1 was conducted successfully on 7 Apr 2013 at Sengkang Swimming Complex.
- A total of 30 parents participated in the user test in the role of a Registered User.
- A total of 5 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 HERE
|
Testing Methodology
Collecting of Qualitative Metrics
- 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.
- 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.
- 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
- The amount of time taken to complete each task
- The number of clicks taken for each task
|
Registered Users
FEEDBACK:
- Solution:
- Replace “Please Select” with “No Preference”, and remove the unnecessary “Zone” search option.
- Solution:
- Underline the instructor's name to make it more obvious to the user.
- Solution:
- Include a popup message to inform unregistered users to login first before making payment.
Instructors
FEEDBACK:
- Solution:
- Replace the photos with useful information on how the system works.
Reflections
Team
1) Good communication can make or break a team
All four of us hail from very different backgrounds and hence have rather diverse perspectives that could become obstacles in our communication. Through the course of this FYP, we learnt the importance of maintaining clear communication so that everyone can be kept on the same page and work together to reach a common goal.
2) Tapping on each other's strengths
Whenever we encountered problems, we learnt to use our diversity to our advantage by bringing together our different opinions to brainstorm for solutions.
3) A stronger focus on team building
If we could improve on one thing, it would be to place a greater emphasis on team building. This would involve several important aspects: openly and honestly talking about our individual expectations and deciding how we would deal with conflict should it arise (which is often neglected). Most importantly, when problems arise, we would focus on coming up with possible solutions rather than playing the blame game.
|
Individual
Member
|
Reflections
|
Xiaochuan
|
- Learnt to be more flexible with and prioritize changes to be made, with the limited time and resources of the team
- Learnt the importance of having good communication to make sure everyone is on the same page
|
Lim Hui Qing
|
- Learnt the importance of engaging real users to test the system to ensure it is designed according to their expectations, and to propose appropriate solutions
- Developed useful skills in video editing, coming up with a proper investor pitch and writing business plans
|
Josephine Heng
|
- Learnt the importance of designing clear user interface mockups to make development more efficient
- Learnt to analyze and validate business requirements, thereby creating a system that would benefit our end users
|
Larry Ho
|
- Learnt to think from the user’s perspective rather than from a developer’s perspective when designing and developing the system
- Learnt that no matter how good a system is, without good aesthetics, the system cannot be considered a “success”.
|