HeaderSIS.jpg

IS480 Team wiki: 2014T1 Team Xcellence Final

From IS480
Jump to navigation Jump to search
TeamXcellence Logo.png


TeamXcellence Icon H.png

HOME

  TeamXcellence Icon G.png

ABOUT US

  TeamXcellence Icon PO.png

PROJECT OVERVIEW

  TeamXcellence Icon PM.png

PROJECT MANAGEMENT

  TeamXcellence Icon PD.png

PROJECT DOCUMENTATION

 


TeamXcellence final logo.jpg

Project Progress Summary

Download our Final presentation slides here!

Project 100% completed! Look at our project scope with all the ticks!

Visit the live deployed site at:


Visit our staging site with various login credentials:

  • myCSISG Web Portal: http://54.179.141.102/mycsisg/
    • Client:
      • Username: TeamXcellence
      • Password: TeamXcellence_IS480
      • Note: If you create a project, please email andy.teng.2011@sis.smu.edu.sg to forward you the generated email containing project details.
    • Admin:
      • Username: admin
      • Password: admin_IS480
  • myCSISG Survey App: http://54.179.141.102/SurveyApp
    • Surveyor Admin:
      • Username: Surveyor6_admin
      • Password: m2xsmz9q
    • Surveyor:
      • Username: Surveyor6_S1234567A
      • Password: S1234567A

Project Highlights:

  • List of scope changes/modification after mid-term:
    • Survey App:
      • Surveyor Admin can bulk upload of surveyors
    • myCSISG Portal:
      • Clients can view all surveyor details per project and their response collection count and average time taken.
      • Clients can preview questionnaire questions before and after starting a project
      • Vast improvements made to project statistic and report visualizations
  • 30th Oct 2014: Access rights to ISES live server temporary removed due to breach of security
  • 10th Nov 2014: Restricted access rights given to ISES live server after breach of security incident
  • 17th Nov 2014: Go Live! Start 1 project on a F&B stall in SMU, collected 55 survey responses and results are calculated through ISES statistical model

Project Challenges:

  • Access rights to ISES live server temporary removed due to breach of security
    • When we finally had all configurations done on ISES server and ready to deploy new set of codes up, the following happened.
    • On 30th Oct 2014, ISES temporary removed all access rights to its live server. They found out that there had been a breach of security where one hacker was trying to poke into their server every now and then.
    • This caused us not able to conduct UAT 2 not their live server. Our scheduled load test have been pushed back by 1 week until ISES is comfortable to give us the access rights again. However, there is minimal impact because we still have our AWS staging environment up and running.


  • Aligning our goals with ISES and ISES's clients expectations
    • This was a challenge for the team to align our goals with various stakeholders expectations. In the initial phase of requirements gathering, there was a long list of requirements (and vague requirements) from ISES. With our limited time working on this project, this became an issue where the scope could be too big to handle. Hence, through conversions with our sponsor, we managed to align what we can achieve within the time frame. These conversions had proved to be a success because we were able to deliver the applications as agreed throughout the project time frame.
    • Aligning ourselves with ISES was not easy. Aligning with ISES's clients expectations was neither easier or rather it was tougher. Given the opportunity to conduct UAT with ISES's clients, we realized some clients would love to have everything under the sun while some were just happy with what's given. Hence, only through conducting test, we managed to align ourselves with ISES and ISES's clients. Ultimately in UAT 2, majority of ISES's clients felt that the applications is ready for commercial usage.


  • Developing an applications that can accommodate different questionnaires with question logic
    • ISES has different questionnaire models that comprises of different question logic. Hence, this challenged us on developing our application to accommodate different questionnaires with question logic while having the conditional branching work seamlessly in the Survey App when the surveyors collect responses.
    • This challenge will be further explained under the Technical Complexity section.


  • Visualizations - bring context to the clients
    • This was one of the obstacles that we faced in the initial phase of the project. Creating bar charts and box-plot may sounds simple, but actually its not. The challenge is how to bring the context to the clients with these visualizations. Some clients are experts in reading complex charts while some are not. Hence, we were challenged to find the right formula to ensure that the information is put across to all clients.
    • ISES are experts in this area. We get their advice and iteratively modify our visualizations to bring context to the client. Moreover, we conducted user test to understand how clients are reading the visualizations. From there, we make modifications again to best help clients to understand their customer satisfaction better.

Project Achievements:

We have successfully:

  • Deployed myCSISG portal, Survey App, and myCSISG web service on ISES live server
  • Conducted UAT 1 with 10 ISES real clients
  • Conducted UAT 2 with 6 ISES real clients
  • Conducted 1 A|B Test Experiment
  • Conducted 1 Load Test on AWS Staging environment and ISES live server
  • Deployed live since 17th Nov!
  • Run and completed one myCSISG project on a F&B stall in SMU!
    • 55 survey responses collected using our Survey App!
    • Survey responses passed through ISES statistical model and calculated results are inserted back!

Project Management

Project Schedule (Plan Vs Actual):


TeamXcellence planned vs actual v7.jpg


For summary of Plan Vs Actual per iteration before mid-terms, please refer to here.
Summary of Plan Vs Actual per iteration (after mid-terms):

  • Iteration 8
    • The focus was on UAT refinements and Mid-Term Presentation.
    • Everything went as planned and Mid-Term Presentation was awesome.
    • Prof Marcus was able to get the R script connector for ISES Statistical Model done on the day of Mid-Term Presentation. (The connector is for ISES to pull the completed projects responses and answers, and passes through their statistical model, and insert back the calculated results back to our database.)
  • Iteration 9
    • After post mid-term review with supervisor and sponsor, there were a few UI refinements to make on the web application, visualizations and survey app.
    • There were additional functionalities - client view all surveyor details, client preview questionnaire questions, surveyor admin bulk upload surveyors - added too.
    • There were issues with the Survey App and question logic, hence this iteration had cater time to get it fixed.
    • There was a day delay in this iteration:
      • Reason: There were issues on the uploading of questionnaire with question logic in the web application and integrating the question logic with the Survey App. It took us longer than expected to resolve.
  • Iteration 10
    • Creating the 1min video pitch task was inserted early in this iteration after receiving the email
    • Everything went as planned despite the insertion of task.
    • UAT 2 was split into two days because some clients could not make it on the day that we had planned for. This did not have much impact on us and the schedule.
    • On 30th Oct 2014 (1 day before UAT 2), we received a news from ISES that they had temporary removed our access rights to their server. They found out that there was a hacker trying to poke into their server every now and then. Hence, this breach of security incident forced ISES to take necessary actions.
      • Impact: We could not deploy our latest codes up to their server prior to UAT 2. It did not affect UAT 2 because we were able to continue to use our AWS EC2 staging environment to conduct the test.
      • Impact: The planned load test might have to be cancelled or postpone if the access rights is not given.
  • Iteration 11
    • GOOD NEWS! On 10th Nov 2014, ISES was comfortable to give us restricted access rights to tomcat server and mysql server for deployment.
    • Load Test can be conducted as planned.
    • Live Deployment
      • There were many clients indicated interest to come onboard myCSISG. However, ISES confirmed that though clients have indicated interest, clients may not come onboard within our project time frame.
      • ISES are approaching as many clients as possible to see if any clients can come onboard within the project time frame.
      • To mitigate the risk of no clients coming onboard, our team decided to use the applications to run 1 projects. The project will understand the customer satisfaction of 1 stall from F&B industry. Thus, this project was live on 17th Nov!
  • Iteration 12
    • Last lap of IS480 to finish final presentation and end of with poster day! :)
    • Apart from final presentation and poster day, iteration 12 is planned as buffer days!


Click to view our project timeline overview

Project Metrics:

Click to view our Schedule and Bug metrics

  • Note: Data collection for bug metrics only started in iteration 3. This was because we started on development from iteration 3 onwards.

Technical Complexity:

Offline Mode

We have to understand why is offline mode for the survey app required in the first place. The problem that we are solving is "how to ensure that surveyors can conduct survey with our survey app even if there is no data connection?". Hence, to enable surveyors to conduct survey even without data connection, offline mode for the Survey App is necessary to resolve this problem. Let's look at the technical aspect and implementation of offline mode.

  • First, let's understand what is local storage before diving in to the details. Local storage is heavily used to allow offline mode to work. Below is a quick summary of what is local storage and its compatibility with browsers and devices.
    TeamXcellence final tech offline1.jpgTeamXcellence final tech offline2.jpg
  • In a normal situation with data connection - online mode, the surveyor can access the Survey App as per normal. After the surveyor has been authenticated, the Survey App will download the required data such as questions, question logic and the data structure. After which, the surveyor can completes a survey and submit the survey response straight away. The response will be captured into the back-end database via a REST web service exposed by the back-end server. Below is the illustration.
    TeamXcellence midterm tech offline 1.jpg
  • In a situation without data connection - offline mode, the surveyor who has already been authenticated before, can still continue to conduct survey. When the surveyor completes a survey, the responses will be captured in the localStorage of the mobile device (example, iPad). Therefore, the surveyor can continue to conduct survey without having to worry of data loss. Below is the illustration.
    TeamXcellence midterm tech offline 2.jpg
  • In a situation where there are responses stored in the localStorage and the Survey App comes online from offline mode, the surveyor can submit the responses. The Survey App will retrieve all the responses from the localStorage and send it back to the back-end server for storing. Hence, there is no data loss even when switch from offline to online mode in between. Below is the illustration.
    TeamXcellence midterm tech offline 3.jpg

Question Logic

When surveyors conduct survey, they tend to make errors when evaluating which questions to be done. For example, if question 1 answer is "Yes", proceed to question 2, else if answer is "No", proceed to question 3. In such situation, surveyors have to mentally evaluate which questions to skip, which is prone to error. Hence, the problem we are solving is "How can our application accommodate to different questionnaire with different conditional branching and how to guide the surveyor to answer all required questions with minimal effort? E.g. skipping questions that are not required.". Therefore, question logic implementation is required to resolve this problem.

  • In the portal, ISES admin can upload new questionnaire. This uploading is very crucial for the question logic to work. As shown below, it is the template for ISES to enter their question, rules and input, and which is the proceeding question based on the rules and input. We have allowed rules such as "=", "goto", "<", ">", "end". This is sufficient to cover all branching logic that ISES has in their questionnaires. After verifying that the questionnaire has no error, the portal will capture the question logic in such format in the database and the Survey App will feed on the question logic in such format too.
    TeamXcellence final tech questionlogic2.jpg
  • In the Survey App, the question logic is downloaded from the database for the particular questionnaire. The below illustration is the myCSISG questionnaire question logic example. When the surveyor starts a survey, Q1 to Q26 has no conditional branching. Hence, the rules for these questions are "goto" proceeding question. However, from Q27 onwards, there are conditional branching. If Q27's answer is Yes, it goes to Q28A. If Q27's answer is No, it goes to Q28B. Therefore, the path to complete the survey will defers depending on the answers on branching questions.
    TeamXcellence final tech questionlogic.jpg
  • Having the upload of question logic and path sorted out, here's a brief summary on how did we implement it. There are 3 components required: 1) array of answers and questions, 2) function(next) and 3) function(previous).
    • We first define an array to store the answers. The answers will be pushed into the array or popped out of the array depending on their action.
    • function(next) performs the necessary steps when the surveyor press next button in the Survey App. By pressing next, the answer will be pushed into the array. Then the function evaluates the question logic for the current question. For example, at Q30, if the answer is 7, the function evaluates and detect the next question to be Q31A, then proceed to Q31A.
    • function(previous) performs the necessary steps when the surveyor press previous button in the Survey App. By pressing previous, the function will evaluates which was the previous question depending on the answer. For example, at Q30 the answer is 7, it proceeds to Q31A. Once previous button is pressed, it evaluates which is the previous question from Q31A and return to Q30. The Q30 answer will be retrieve from the array too. If the answer changes, the initial answer will be popped out and new answer will be pushed in and function(next) is called.
  • Therefore, with such implementation of accommodating question logic from the portal to the Survey App, it resolves the issue of how to accommodate to different questionnaire with different conditional branching, and guided the surveyor to answer all required questions accurately with minimal effort.

Data Transformation for Visualization

There are multiple models to measure customer satisfaction. Hence, when it comes to visualization, our applications have to be flexible and scalable. So the problem we are solving is "how can we design the visualization to accommodate to multiple charts feeding on different data structure while retaining the granularity of the data set?".

  • First, let's look at how the data set is like. In the below illustration, you can see that the original data has a flat hierarchy. Hence, there is need to implement a back-end code to crunch and compile the data before returning a set of usable data structures for Chart Type A, B and C.
    TeamXcellence final tech dt1.JPG
  • For Chart Type A, the overall chart, there is a need to calculate mean for the LV Score and transpose data. The outcome of original data will be data structure A which Chart Type A will feed on.
    TeamXcellence final tech dt2.JPG
  • For Chart Type B, box plot, there is a need to transpose original data and exclude some of the data that should not be included in a box plot such as "Yes/No" questions. The outcome will be data structure B which Chart Type B will feed on.
    TeamXcellence final tech dt3.JPG
  • For Chart Type C, histogram, there is a challenge because different questions have different scale. It could be ordinal scale or categorical scale. Hence, we implemented questions with valid value and able to generate the appropriate charts.
    TeamXcellence final tech dt4.JPG
  • With data transformation implemented, when users filter demographics to the target segment that they want, all the chart type will feed on individual recalculated data structure and display appropriately.
    TeamXcellence final tech dt5.JPG

Quality of product

Project Deliverables:

Stage Specification Modules
Project Management Minutes Internal & Sponsor & Supervisor Minutes
Metrics Schedule & Bug Metrics
Requirements Personas & Scenarios Personas & Scenarios
Prototype Low-Fi Prototype
Business requirements Project Overview
Project scope Project Scope
Analysis and Design Use case Use Case Diagram & Use Case Description
ER Diagram ER Diagram
Architecture Diagram Architecture Diagram
Flow Diagram Flow Diagram
Risk Assessment Risk Assessment
Screen Dumps Screen Dumps
Testing UAT 1 UAT 1
UAT 2 UAT 2
A|B Test Experiment A|B Test Experiment
Load Test Load Test
Handover Manuals User Manual, Deployment Manual
Codes/SQL scripts client server
  • Note: The files in the deployment manual are not provided here. It is only given to ISES

Quality:

We have the following points to ensure quality of the project:

First, we have designed our solution to comprise of 3 different portions. The first portion is the database. All read/write operations will occur on this database. The second portion is the web service which contains all the logic needed for the myCSISG portal and Survey App. We exposed the web services as REST for consumption. Furthermore, if needed, the logic in the web service will communicate with the database for read/write operations. The third portion is the front-end applications (myCSISG portal and Survey App) which consume the exposed REST web service. The combination of the 3 portions follows the concept of Model-View-Controller where View is the front-end, Controller and Model are the web service and database. This greatly reduces the possibility of code redundancy because the front-end applications could share the same web service if the functionality is the same. Moreover, this vastly reduces the complexity of maintaining codes since the front-end and back-end are separated.

Second, we uses a staging environment and live server environment. AWS EC2 is used as the staging environment for us to deploy and test, ensuring that everything is working before pushing it to the live server environment. This allowed us to identify bugs without affecting the deployed applications in the live server.

You can refer to our architecture diagram to understand about first and second point.

Third, through prototyping and user tests, we are able to evaluate feedback and iteratively incorporate the changes to ensure the usability of the myCSISG portal and Survey App.

Lastly, load test was conducted to measure the performance of the applications and server. However, due to not having the rights to configure ISES server, we could only make recommendations for them.

Deployment:

Visit the live deployed site at:

Visit our staging site with various login credentials:

  • myCSISG Web Portal: http://54.179.141.102/mycsisg/
    • Client:
      • Username: TeamXcellence
      • Password: TeamXcellence_IS480
      • Note: If you create a project, please email andy.teng.2011@sis.smu.edu.sg to forward you the generated email containing project details.
    • Admin:
      • Username: admin
      • Password: admin_IS480
  • myCSISG Survey App: http://54.179.141.102/SurveyApp
    • Surveyor Admin:
      • Username: Surveyor6_admin
      • Password: m2xsmz9q
    • Surveyor:
      • Username: Surveyor6_S1234567A
      • Password: S1234567A

Testing:

We have conducted 2 User Acceptance Test, 1 A|B Test Experiment and 1 Load Test. Click here to view any of the tests information.

Here's a quick summary of each of the test conducted:

  • UAT 1
    • 10 real ISES clients kindly participated
    • The objectives were to align ISES's expectation with our current product, better understand the real user's needs and identify areas to enhance their experience with myCSISG.
    • View more about UAT 1 here
  • UAT 2
    • 6 real ISES clients kindly participated
    • The objective was to understand if myCSISG web application and survey app is ready for commercial use by ISES clients
    • View more about UAT 2 here
  • A|B Test Experiment
    • 30 participants are selected on the basis that they have done a survey within the last 3 months
    • The objective was to determine which layout (Keypad vs Slider) will help surveyors be efficient and accurate
    • View more about A|B Test Experiment here
  • Load Test
    • Load test was conducted on the live deployed site residing in ISES server
    • The objective was to understand the performance of the web application and survey app residing in ISES server. We will recommend ISES a set of changes to make to improve the performance since we do not have the permissions to make the necessary changes.
    • View more about Load Test here

Reflection

Team Reflection:

The team has learnt that communication is one of the key factors to the success of the project. This is important as communicating ideas across to various stakeholders allowed us to better manage the project and align our goals with the clients’ expectations. Knowing that there is limited time, we have learnt to evaluate our options and solutions, and arrive at a decision that best align with the goals set forth. Lastly, we have learnt to adapt to unexpected situations and be prepared for exceptions to happen.

Teng Rui Jie Andy Reflection:

I have learnt two key lessons – communication and ability to adapt. Being able to communicate ideas clearly and concisely with various stakeholders is vital to the success of the project. Furthermore, picking up the skill to adapt to different situations has allowed me to manage the project better and react to unexpected situations better.

Tan Si Yu Reflection:

Throughout the course of this project, I have learnt to better manage client’s expectation and to deliver a solution that is truly built on the needs of its users. I have also ventured out of my comfort in terms of individual competencies and learnt to better deal with unexpected situations to bounce back even stronger.

Wong Wei Xiong Reflection:

If you want to complete the project on time don’t waste time on ideas that are far beyond the budget, your capabilities, or the client’s resources.

Weng Xinyong Reflection:

There are always trade-offs for everything. There are no perfect solutions for any given problem. Learning to evaluate on the pros and cons of each solution is important as there is no time to do everything.

Lek Guan Zhou Reflection:

Communication is the key to make a project successful; be it within teammates or other stakeholders. Through these tough 15 weeks, I have learnt how to express thoughts, more proactive in giving opinions and more open in receiving suggestions. Surely, the project had crafted me to be a much better developer as well as a team member.

Chua Zhen Ling Reflection:

Through this journey, I have learnt how to manage all the stake holders’ expectations, including my own, together in one single project. Basically, everyone has got different expectations be it individually or for another. The key is to constantly do a cost benefit analysis and most importantly, patience and tolerance. I have also learnt much from the technical executions as well as gaining more knowledge in tackling real world problems and unforeseen circumstances.