HeaderSIS.jpg

IS480 Team wiki: 2012T1 Team Sageby Final Wiki

From IS480
Jump to navigation Jump to search
Frontpage2.png


Thanks for visiting Team Sageby's Wiki Page!


Our iOS Application, Sageby Surveys, allows users to do surveys, earn credits and exchange for vouchers, all in one single iPhone!


Do take a peek at our Final Wiki OR

Our previous MidTerm Wiki MidTerm Wiki

HOME

| PRODUCT OVERVIEW | PROJECT MANAGEMENT | USER TEST | LEARNING OUTCOMES

Project Progress Summary

Since our Midterm presentation in 1st October, we have realigned developmental focal point strictly on the usability of our application. Professor Archan gave an extremely useful tip: "It is all these little things that makes up the last 5% of your application". We felt that Prof Archan was hinting that the application was well on its way to accomplishment, but was still lacking in terms of refining the user experience.

Following our initial developmental methodolgy, Build | Measure | Learn, we manage to smooth out kinks and re-engineer the way how Sageby Surveys displays information.

Project Highlights

1 Handling Excessive Low Severity Bugs

Soon after mid-terms, we realized that as Sageby Surveys is continually being built, the amount of bugs were increasing and this became a serious issue when the application did not manage to work smoothly just right before User Test 4. Development of customized views became buggy and development of the application was impacted. Hence, we implemented a hybrid debugging system which includes fixing a specific debugging period (current model) and pushing low severity yet heuristically important bugs to be fixed within the next iteration, which reduces risk of task overload within the next iteration. This bug-fixing model is extremely efficient with our lean development as bug-fixing effort varies between iterations.

Through this initiative, we managed to clear out all identified bugs and deliver an highly refined application for User Acceptance Test (Final UT).

Project Challenges:

Upon successful construction of the application, we realized that delivering a complete set of functionalities was far below the scale as compared to delivering an app that was interesting, visually appealing, and bug free application. Hence, this lead to a conclusion that users are experiencing a phenomenon called "Perceived Intuitiveness & Efficiency" of the application. We looked into several ways to improve usability and came up with 2 solutions, one to improve loading speed and another to improve learnability.

1 Sageby Lead Developer Left

Construction of the Application Programming Interface (API) on Sageby's servers was stopped and could not provide the mobile application with dynamic data from Sageby's datebase.

Marcus had to drop his initial task, Performance Profiling and Core Data, and take on the role of building APIs.

2 Lazy Loading & Pull-Down-to-Refresh

Before our Final User Test, we identified the common scenario that users were unsatisfied with, Rewards and Survey's list loading. This was due to the rendering time of iOS with images for the table cells. Hence, instead of removing images, we decided to implement a different way of loading the table cells. Lazy Loading helps to load cells with text first, and then replaces the images once its finish rendering. Also, instead of refreshing the list every time the view is loaded, we implemented Pull-Down-To-Refresh to allow users to refresh the table only when they want to. This improved table loading timings up to 100 times faster and greatly improved the application ability to display much more surveys and rewards efficiently.

3 Walkthrough Page

After our User Test 4, our application was nearly boasting all functionalities that we had planned for. However, this increased the complexity of the application and led to lower satisfaction level of users. Although a relatively high percentage of users (>63%) were satisfied with each different module of the application, we wanted to raise the population of satisfied users to 90%.

Hence we introduced a walkthrough page that will be shown during the initial startup of the application. Users are excited and motivated to use the application when the walkthrough appeared, aiding them in understanding the application, especially for new users. Users had a much higher satisfaction level, increase from 60% to 90%, which was partly contributed by the walkthrough, and overall improve user's receptiveness towards our application.

Project Achievement

1 5 Extensive User Tests

Before midterm, We held numerous user tests and there were more complains than positive remarks. These lead us to think, why did a full fledge application not score well with the users. We then realized that it is due to the finer details that are lacking, causing displeasure in using the application. After User Test 4, we felt that we really have to implement "Lazy Loading" (efficiency in loading pages) and walkthrough pages (improve learnability). These are non-functional modules that we had originally considered but were abandoned due to lack of foresight for long load-time of lists. In bid to perfect the application, we used 2 more of our buffer days (1 week) and built our walkthrough pages, along with Lazy Loading and Pull-Down-to-Refresh for rewards and survey's list.

Our Final User Test was a User Acceptance Test for our Sponsors, Sageby Pte Ltd. They put the application through their own testings for both APIs and Sageby Surveys itself. Our sponsors are extremely satisfied with the application being full fledge and is ready to be launched officially. Also, they are further convinced when a huge percentage of our 40 users for Final UT felt that Sageby Surveys is highly enjoyable to use and had many amazing functions to go along with it.

Overall, thanks to the laborious and tiring 5 User Tests, we managed to exercise team's belief, "Build-Measure-Learn", to a great extent, bringing constant improvements to the application from continued user feedbacks and learning sessions. The final product is our sweat and soul, Sageby Survyeys.

Project Management

Project Scope

Sageby project scope slides.png

Project Timeline With Scope

Sageby iteration table.png

Schedule Brief

Sageby schedulebrief.png

Project Status

  • All Functionalities (including additional functionalities) that we have planned for are completed and deployed.
  • Application is now deployed on Appstore version 1.3
  • Successfully conducted our Final UT5, a User Acceptance Test for our Sponsors
  • Sponsors accepted the application and handed-over after reviewing the application and receiving many positive feedbacks from the users
Task/function/features, etc Status Confidence Level Comment
Login Module Fully deployed and tested 100%. However, it is not updated to latest Facebook SDK due to lack of backward compatibility with iOS 5 1 Luojia
Survey Module Fully deployed and tested 100%, with categorization via alphabetical order 1 Luojia
Rewards Module (Store) Fully deployed and tested 100% 1 Luojia
Rewards Module (Wallet) Fully deployed and tested 100%, with categorization via used & unused sections 1 Luojia
Settings Tab Fully deployed and tested 100% 1 JunHao & Mervyn
Social Sharing Module Fully deployed and tested 100% 1 TeeJun
Feedback Channel Fully deployed and tested 100%. Used Apptentive Package for feedbacks and easy rating portal. 1 Junhao
Performance Profiling & Memory Leak Tests Function to be Kept in View. To be continued if necessary. 1 Marcus
Application Programming Interface Partially developed, deployed and tested 50%. Survey, Users and Rewards Module completed 1 Marcus
Database Transition from Development to Live Fully deployed and tested 100% 1 Marcus
Unit Tests Partially developed, deployed and tested 50%. Login, Surveys, Rewards, User Module & Settings tab covered 0.5 JunHao
Facebook Sharing UIView Partially developed, deployed and tested 50%. 1 Mervyn
Mobile Template for Lime Survey Fully deployed and tested 100% 1 Mervyn & Junhao
Social Integration Fully deployed and tested 100%. Twitter integration and Facebook Login 0.9 Luojia & Teejun
Application for All Modules Fully deployed and tested 100%. 1.0 Marcus & Luojia
Transition from iOS5 to iOS6 with versioning identification Fully deployed and tested 100%. Devices with iOS5 will not invoke iOS6 specific methods. 1.0 Luojia
User Notifications Fully deployed and tested 100%. Comes with a Slider(left) single finger motion 1.0 Mervyn
Geo-fencing Notification Fully deployed and tested 100%. Vendors are currently set to a radius of 25 metres 1.0 Junhao
Creation of a Map based View for merchants Fully deployed and tested 100%. 1.0 Junhao
Implement Lazy Loading for rewards & survey's list Fully deployed and tested 100%. 1.0 Mervyn
Walkthrough Pages (4 different pages in total) Fully deployed and tested 100%. 1.0 Mervyn
Pull-Down-to-Refresh Fully deployed and tested 100%. 1.0 Junhao

Project Schedule (Plan VS Actual)

Despite having several additions in our project scope, we managed to narrow down the non-functional requirements of the applications and added an extra week in Iteration 4 to accomodate our User Tests.

Planned Actual
Iteration Task Start End Start End Comment
1 Complete Paper Prototype for client's acceptance 30/5/12 5/6/12 30/5/12 5/6/12
Develop sample iOS App 6/6/12 13/6/12 6/6/12 13/6/12
Complete Prototype with Survey Module 14/6/12 27/6/12 14/6/12 27/6/12
2 Build Facebook Single Sign On Auth 27/6/12 3/7/12 27/6/12 3/7/12
Build Sageby Manual login 3/7/12 11/7/12 3/7/12 11/7/12
Allow user to logout 3/7/12 11/7/12 3/7/12 11/7/12
Build User details popup 11/7/12 17/7/12 11/7/12 17/7/12
Build different in-house survey layouts. Allow survey question to have dynamic survey layout 17/7/12 25/7/12 17/7/12 25/7/12
Able to pull dummy data from Sageby's server 17/7/12 25/7/12 17/7/12 25/7/12
Build survey's question routing function 17/7/12 25/7/12 17/7/12 25/7/12
Deploy and upload to Apple's Appstore 31/7/12 31/7/12 31/7/12 3/8/12 Code-signing error and outdated library links led to 3 days delay in deployment
3 Build browsable table for Store vouchers 1/8/12 8/8/12 1/8/12 8/8/12
Allow users to redeem vouchers 1/8/12 8/8/12 1/8/12 8/8/12
Build browsable table for Wallet vouchers 8/8/12 15/8/12 8/8/12 15/8/12
Build QR generator 8/8/12 15/8/12 8/8/12 15/8/12
Deployment on Appstore 21/8/12 21/8/12 8/9/12 8/9/12 Pushed to Iteration 3 due to the lack of APIs
4 User is able to share completed surveys via Facebook share and Twitter 22/8/12 29/8/12 22/8/12 29/8/12
Users will be able to provide feedbacks to Sageby Surveys 22/8/12 29/8/12 22/8/12 29/8/12
User is able to share referral link for benefits 22/8/12 28/8/12 22/8/12 28/8/12
Build iFrame to support Lime survey 29/8/12 4/9/12 29/8/12 4/9/12 Added an Extra week to support external survey engine
Build iFrame to support Lime survey (Added) 29/8/12 4/9/12 29/8/12 4/9/12 Needed to support external survey engine for live testing(UT3)
Built User & Survey Module's APIs (Added) 5/9/12 11/9/12 5/9/12 11/9/12 Added an Extra week to build APIs to receive dynamic data and prepare for live testing (UT3)
Transitioned from iOS5 to iOS6 (Added) 12/9/12 18/9/12 12/9/12 18/9/12 Added an Extra week to transition from iOS5 to iOS6 in order to update deprecated APIs and to support application on iPhone 5
Transitioned from Development Database to Live Database (Added) 12/9/12 18/9/12 12/9/12 18/9/12 User will be able to register with Sageby and do real surveys.
Deploy to Appstore 25/9/12 25/9/12 30/9/12 30/9/12 Delayed by 5 days due to rejection from Appstore for several unsupported APIs
5 Populates different price button according to number of prices available for redemption 1/10/12 6/10/12 1/10/12 11/10/12 There was unexpected difficulty in implementing customized logic for buttons. A logic bug was found on 6th of October and functionality was delayed by 5 days
Implement User Notifications that includes Slider(left) to activate 26/9/12 19/10/12 26/9/12 19/10/12
Implement & Integrate APIs for dynamic data 26/9/12 23/10/12 26/9/12 23/10/12
Implement Geo-fencing Notifications 3/10/12 11/10/12 3/10/12 11/10/12
6 Create a Map-based view for Redemption tab 24/10/12 28/10/12 24/10/12 28/10/12
Implement & Integrate API for Geo-fencing Module 24/10/12 2/11/12 24/10/12 2/11/12
Implement Lazy Loading Pull-Down-to-Refresh for all tabs 3/11/12 6/11/12 3/11/12 9/11/12 Lazy-Loading and Pull-Down-to-Refresh was tougher then expected due to the reconstruction of how table cells had to be populated. Extended by 3 days.
Develop & Implement Walkthrough Pages 8/11/12 15/11/12 10/11/12 15/11/12 Walkthrough pages was implemented by 2 as there was bug fixing on-going and bug-fixing took longer then expected.

For more details on the project management schedule, please check out our Project Management Wiki page at Sageby Schedule Metric!

Project Metrics

We have chosen Schedule Metric and Bug Metric as it best suits a development for iOS due to expected rapid changes in schedule and unforeseen bugginess of a mobile app.

Schedule Metric

Current Standing

Sageby pm final.png

Summary

The schedule metric has been highly useful for us by providing us with an better grasp of our current situation and to track the amount of time we took with difficult tasks. Project Manager was also able to efficient allocate extra time and also to meet up with changing demands and opportunities.

Overall, the team felt that tasks were well planned and user tests were held at effective timings with sufficient bug-fixing durations. Complexity of modules are also well understood, which led to an improving trend in project management metric.

Bug Metric

Current Standing

Sageby bugmetric+final.png

We needed the Bug Metric to answer 3 important questions during development:

  • Where did it originate from
  • Impact of the bug
  • How many are there

With the aid of the Bug Metric, we managed to identify key issues, which includes Facebook Login and sharing and persistent UI Bugs. Coding in Storyboard with Objective-C bypasses the conventional coding of transitions of Views in iOS. This is a huge improvement in convenience for new developers such as us, but when bugs arises, we need to identify the location of it and to rectify the issue by diving into the source codes and make manual changes.

Changes

After our Mid-terms, we realized that the severity of bugs could be low but might take long hours of bug-fixing due to its complexity. Given the different amount of bug-fixing effort required per iteration, 1 week is definitely sufficient for fixing all major bugs but might not be able to fix all low severity bugs. Hence we have adopted a hybrid bug-fixing system that schedules the fixing of remaining bugs in the next iteration. This ensures that most bugs can be fixed before the next iteration's User Testing.

Summary

Overall, we managed to clear all identified bugs and our sponsors are pleased with the quality of the application

Technical Complexity

Technical Complexity takes into consideration of Team Sageby's main development pain points. Although there are other complexities such as Facebook login SDK issues and iOS 6 with backwards compatibility, these issues can be temporarily kept in view due to the immaturity of the SDK and platforms.

Task Description % of Self-Written Codes
Construction of Application Programming Interface This API construction is extremely important to the success of the application. However, we have several considerations during the building of APIs.
  • Sageby's existing database is extremely well populated, hence, building APIs from scratch requires a thorough understanding of the database
  • Directing different versions of the application to different version of the APIs. This is necessary as we need to access dev and demo databases during development and live database during live testing.
  • Sageby's different web servers had several PHP configurations that made it extremely confusing to use concurrently.
  • Planning and testing of new internal survey database was done and in the process of deployment at this time.
100
Building Different Survey Layouts Surveys are split into 2 categories, In-house survey & Limesurvey(external). These survey templates are extremely important in ensuring that users enjoys doing surveys on a small mobile screen.

In-house Survey

There are 5 current types of survey layouts that our team has researched to be the most used survey layouts which includes Checkbox, Radio box, Rating, Free text & Arrangeable boxes.

However there are several considerations to building it. There are no existing templates provided by iOS. Hence we need to customize "Survey Views" that follows the same logic as a multiple choice question, single choice question & arrangeable tables.

LimeSurvey Engine

LimeSurvey is widely used by Sageby Pte Ltd as it provides powerful analytical tools and a wider array of survey templates. However, LimeSurvey is an external engine and it will be better to develop their in-house survey for the long run.

Also, LimeSurvey has its own share of technical complexities. The web templates that are built by LimeSurvey are meant for Web usage and we did not want to pay external vendors for their standard looking mobile templates. Hence we decided to build our own customized templates through the usage of HTML6's features to resize to mobile resolution/screen size. This was extremely tough as LimeSurvey's templating structure involve several pstl files and CSS files that had to be trial and tested on how the files work together.

80
Compatibility with both iOS5 & iOS6 Compatibility with both iOS 5&6 versions had to be stretched across 2 different categories, versioning issues and screen sizing issues.

Screen Size iPhone 4S and older versions uses a 3.5-inch screen and iPhone 5 uses a 4-inch screen. This causes older applications that are not properly configured to have its layout rendered wrongly. We had to resize all images, clear out and replace all old methods for positioning the layout of the buttons, images and text-boxes. This was extremely tough for us as there were many customized views and layouts and we had to source for new methods to customize layouts for the 4-inch screens.

Sageby IPhone4.png Sageby IPhone5.png

iOS5 & iOS 6' In iOS 6, there were several deprecated APIs that we could not use and we had to adopt the newer APIs. Also, we had to provide backward's compatibility for iOS 5 for the Geo-fencing module as Apple decided to change their maps to an iOS in-house map system. This results in different MapKit APIs for different mapping providers. We started coding and building the application to suit 2 different versions and this took up more time and effort in perfecting the application.

Sageby IOS5.png Sageby IOS6.png

80
Reusable Profile Views In the initial design of the storyboard, profile view was individually created as part of the storyboard. The profile view fetches the user’s Facebook photo, name and also Sageby’s credits. However after a redesign of the application, there was a need to place profile view in 3 other pages. Instead of creating another 3 profile view to be placed it into the storyboard, we decided to create an object for the profile view where the object can be called. Our efforts paid off and it worked well. Once the user clicks on the profile view button, the object will be called and displayed on the view.

Sageby profile 1.png Sageby profile 2.png

80

Quality of product

Quality

Task Description
Application Efficiency Improvements iOS's standard generation of table and cells does not include any customizations. In our application, the table cells are highly customized, showing data from numerous API calls and even rendering images. However, this greatly slows down the application to the extend of diminishing user satisfaction due to the increased delay time.

A solution that we have sourced online was to improve on how the table cells are generated and rendered. Instead of removing images, we decided to implement a different way of loading the table cells. Lazy Loading helps to load cells with text first, and then replaces the images once its finish rendering. This improved timings up to 100 times faster and greatly increased the application to display much more surveys and rewards efficiently.

Dynamic Data Sageby Surveys is built with the intention to be a full fledge product, and hence it is necessary to build the API to support dynamic data. These APIs provides the application with data from Sageby Pte Ltd's database which includes real surveys and rewards used on the web portal.
  • Application receives updated data
  • Surveys and rewards can be pushed immediately to the application
  • Application is semi controlled by the APIs. To switch off any modules/tabs, the APIs can be configured to return a HTTP 500 error to display an error page on the mobile device
Intuitive Layout with Easy to Understand Process Flow
  • Through thorough testing and collecting user feedbacks, we manage to streamline the usage of the application and made it extremely easy for users to navigate and use the application. The design architecture is based on the Tab View where all views are connected to each other via a bottom tab view bar. This ensures that Sageby Surveys always has a common navigation point.
  • We realized that the application can be daunting for new users, and despite having an extremely high rating of usability by users (>80% satisfaction), we wanted to improve the application's usability further and drive the satisfaction level up to 90%. Hence we implemented Walkthrough Pages which guides and aids users in understanding the core functionalities of the application. Through this implementation, users were extremely satisfied with the application, hitting a highest 94% of satisfied users.

Deployment:

Sageby Surveys is an iOS application that is supported on both iOS5 and iOS6, and on both iPhone 4 and iPhone 5. Sageby Surveys is currently deployed on AppStore.

This is the link for AppStore download:Surveys AppStore Download

And these are several images that are previews for the application.


Sageby pic1.png Sageby pic2.png Sageby pic3.png


Application Programming Interface is current deployed on:

  • Sageby's Live Server with Live database, www.sageby.com, as Version 1.2 for AppStore's Sageby Surveys
  • Sageby's Development Server with demo database, dev.sageby.com, as Version 1.3 for development device

Testing

Final User Test (UT5)

Objective

The main objectives of this this final UT are to test for all functionalities.

This include new functionalities:
- User Notification
- Geo Mapping

To prove that our application is:
A. Sustainable
B. Intuitive
C. Visual- Appealing

From our previous User Test 4, we will test the additional implementations:
A. Walkthrough Page
B. Lazy Loading
C. Pull-Down-to-Refresh
D. Heuristic Changes

UT 5 Schedule


UAT5.GIF


User Profile


Altogether, there are 32 responses. To have a better gauge of user learnability curve with the application, the user test has an equal proportion of new and past users.

To understand user lifestyle usage, 55% were iPhone user while 39% were Android user. The remaining 6% were blackberry and other OS users.


Testing Methodology


Qualitative Metrics

Users are allowed to express their opinions while accomplishing each task. The intention is allow the facilitators to record observations and important details of the users' thought processes. In addition, the facilitators are expected to look out for errors and navigation issues. Users will be doing by an online questionnaire only after finish using the application. It will be crafted around the usability issues and their satisfaction level of the application.


Strategies

Simulation
-Simulated different stages of the process flow

1). Awareness Booth

2). Waiting/ Queue Booth

3). Redemption Booth

Unguided Test

- Gave a set of goals for user to complete

User Behaviour Observation

- Facial Expression, body language

User Feedback Survey

Repetition Matrix


Cccc.GIF


Analysis

In- House Survey Template

Issues faced by Users:
1). User accidentally exit while doing a survey
2). Users is able to submit blank answer for compulsory question
3). User want to know their cumulative amount after completion of a survey

Geo-fencing Notification

88% would like to be notified by Geo-fencing Notifications

Issues faced by Users:
1). User feel that something can be shown instead of a blank page when there are no notification.

Geo- Mapping

82% find the map intuitive to you while the remaining 18% gave a neutral stand.

Issues faced by Users:
1).User is unable to identify the distance from current location to target venue

Walkthrough

79% find the walkthrough feature helpful while the remaining 21% gave a neutral stand.

Satisfaction Improvement

1).63% of the user gave a 80% satisfaction level for User Test 4.
2). 94% of the user gave a 80% satisfaction level for Final User Test. There's a increment of 27% in satisfaction level.

What are the main To-Do changes


Survey
- Exit Pop-up for Internal Survey
- Warning message for empty response
- Display total credits when survey is done

Redemption
- Revamp the Purchase Success Page

User Notification
- Display a 'No Notification' message when it is empty

Geo- Mapping
-Display distance of user current location from target venue

Walkthrough
- Inclusive of Walkthrough Tab at Setting Page

What we did badly


Overall, the Final UT execution was executed with no major issues. There was no shortage of equipment or application failure.

What we did well


Proper instructions were given from the Testers to the Testees. All equipment’s are working fine. There were minimal waiting times. We met our daily target for users.

Overall, the Final UT execution was executed with no major issues. There was no shortage of equipment or application failure. Some of the feedbacks have been extremely useful for the team final development and client.

In addition, proper strategies were in place to make sure users can go through a simulated environment, to gather feedbacks about the whole work flow.

Unit Testing

Objective

Unit testing is a standard technique in computer programming whereby we break the software into small, independent pieces of code (a.k.a. the unit), isolate it from the rest of the code and test it. The main goal of unit testing is to try and find as many bugs as possible, as soon as possible.

Unit tests are split into two categories, Logic and Application Unit Tests.

Logic Unit Testing
Objective

Logic unit testing concerns the testing of the classes logic directly. You only test the logic of the methods, you don't interact with user interface elements or simulate them. For example, testing that a coordinate convertor utility is returning correct values is logic unit testing.

Percentage of Testing

Covered Areas:

  • Verification of Credentials for manual login
  • Test for verification of specific survey styles such as checkbox, radio buttons, etc.
  • Test for mock data verification

Overall Percentage of logic tests : 50%

Output

Sageby Logic tests.png

Application Unit Testing
Objective

Application testing in iOS is much more specific to applications with user interface. In application testing, you will check that clicking a certain button triggers the correct behavior, that a view loads correctly, and so on.

Percentage of Testing

Covered Areas:

  • Landing page verification
  • Survey, Rewards and Settings tab verification
  • Survey details view and start button verification
  • "About" button in settings tab verification
  • "Share" button in settings tab verification
  • "Logout" button in settings tab verification

Overall Percentage of Logic Tests : 70%

Output

Sageby Application test.png

Test Cases

Objective

Test Case is a set of conditions or variables under which a we will determine whether an application or software system is working correctly or not. We have up to 50 steps for our Test Case version 3

Percentage of Testing

Covered Areas: All functional module

Overall Percentage of Test Case: 100%

Project Deliverables:

Category Content Deliverables
Project Management Meeting Minutes Team meetings: Minutes 1-11
Supervisor: Minutes 1-9
Project Schedule Planning Project Schedule: Project Schedule
Metric Bug Metric: Bug Metric
Schedule Metric: Schedule Metric
Requirements Final Presentation Final Presentation Slides
Analysis Use case Use Case Diagram & Documentation
Functionality List Functionality List
Design Architecture System Diagram System Architecture
Low Level Architecture System Diagram Low Level System Architecture
Application Programming System Design Application Programming Interface
Domain Diagram Domain Diagram
Mockup Designs Mockup Designs
User Test Documents UT 1

UserTest1 Schedule
UserTest1 Test Plan
UserTest1 Summary

UT 2

UserTest2 Schedule
UserTest2 Test Plan
UserTest2 Summary

UT 3

UserTest3.1 Schedule
UserTest3.1 Test Plan
UserTest3.1 Summary

UserTest3.2 Schedule
UserTest3.2 Test Plan
UserTest3.2 Summary

UT 4

UserTest4 Schedule
UserTest4 Test Plan
UserTest4 Summary

UT 5

UserTest5 Schedule
UserTest5 Test Plan
UserTest5 Summary

Reflection

Team Reflection:

Six days a week, five hours a day, every awakening day in our life for the past six months.

To create Sageby Surveys was an uphill task for us. With a five man team and no prior experience with Objective C or iPhone programming; we were tracking on unknown ground. However we marched on with positivity wanting to take away something from FYP instead of just doing another mainstream project.

It’s all began when we first sat down on a proper meeting to decide on what we want to achieve and selecting from the long list of sponsors. Are we able to manage the project? Do we want to push our limits together? There are some of the recurring factors that came to our mind while deciding on the project that we want to undertake. Ultimately, we decided to work with Sageby Pte Ltd because we find the business project meaningful, stimulating and fun! Our summer was all about technical familiarisation, managing client’s scopes while juggling our internship at the same time! Beside the steep learning curve from a new programming language, it was not easy to even display a simple “Hello World” on a mobile phone.

Our team took the project seriously and work on two user tests even before the Acceptance. We called it Prototype Testing because we really want to be sure that we are building a product that users really want. This is part of Lean Development which our team adopted. After our acceptance, our team re- allocated resources to capitalise on each individual’s strengths. We became more efficient and are constantly able to meet our work schedule. We have a tight working relation with the Sponsor’s technical team.

Every project has its own set of limitations, challenges and trade-offs. From overcoming coding difficulties to meeting our iteration goals, we have to constantly manage our supervisor and client’s expectations without short-changing our deliverables. When the client’s technical in-charge left the company, we faced the issue of implementing an app without firm back-end support. Marcus, our team Database Manager, took over the wheel and work on the API and database structure. In a blink of an eye, we were managing scopes out outside our initial deliverables. Mid Term Presentation gave the team a better reflection of our team’s capabilities and shortcomings. We managed to deploy our App to Appstore three times, earned a respectable amount of monetary incentives for our client via our App platform and achieved a modest number of application downloads. Our motivation to excel grows as Final Presentation draws nearer.

Friendships are forged when we overcame our challenges together. Every project success is always a team effort.

Just to share a quote, “Life isn’t about learning how to weather the storm. It’s about learning how to dance in the rain.”

Individual Reflection:

Peh Jun Hao

Managing expectations, deliverables and scheduling, these are the concerns that keeps popping in my head over these past few months. Assuming the role of a Project Manager has far exceeded my imagination. From planning out the team milestones and deliverable to coding some of the functionalities, I have to actively manage and keep track about team's development ensuring that they themselves learn from the development of Objective-C, learn about carry out User Tests and improving. There are just so many things to learn, and so much that the team can learn only by being together as a team.

Marcus Lee

From managing and implementing the database for the application to constructing the Application Programming Interface (API), this project has really stretched the limit of my abilities. Having the need to work closely with the client’s server, it’s a common sight to see me working at our client’s office on a normal working day. People call me brother-bear, but my sponsors call me the helpful-bear and it really makes my day knowing that my work benefits everyone!

Luo Jia

Being the only girl in this male-dominant team, having the post of a lead developer is definitely not a walk in the park. The most awkward scenario is when Junhao introduces me as the lead developer and people give weird stares): Besides delivering and ensuring good quality codes, I have to aid the team members when it comes to coding issues and I am really glad that my team respects my every decision, even when its not reasonable. I am just glad that I managed to fit in well with my team and made it till the end together! (:

Mervyn Lee

Looking back, continually improving the design and heuristic played a major role in our user experience. Through the numerous rounds of feedbacks, improving the design is an on-going process due to technology changes and the evolving needs of our users. To date, I am glad that this project gave me the platform to create relevant and attractive designs which meet the modest goal of our application- Simple, intuitive and easy-to- use, and of course, constantly getting ever-changing design naggings from the team.

Foo Tee Jun

What, 5 user tests?! That was my first thought after the team concluded with a lean development of continuous measure and learning. The biggest challenge that I faced as the quality assurance manager is actively seek for efficient ways to improve our application at all time. Not limited to design layouts and user experience, the focus is on pushing the app usefulness beyond its expected level. What keep me going? It’s the smiles and contentment shown from our users’ face.

  • Team has the necessary technically competency. This is their first iOs application and they have produced an exceptional application for Sageby which we will be using launching very soon next month.
  • Their working styles compliment each other and is well demonstrated by how they have sub teams working in parallel to complete tasks for each of their 5 user testings.
  • Their designing skills compliments Sageby’s designs. Feedback from real users also mentioned that the design is efficiently designed around the core features of Sageby that.
  • The team manage improve and bring forth our slogan, “Pay Using Waiting Time” to realization. A huge amount of users are also exposed to Sageby via the mobile platform and this is shown by the large increase in signups using the mobile APIs
  • The team is also excellent at handling obstacles such as server down,s webhost down, dev server down and changes in requirements such as the addition of APIs as their job-scopes.
  • Lastly, the team managed to push the application to the AppStore with 4 versions, showing the application’s quality built and pushing the application to more users.