Difference between revisions of "IS480 Team wiki: 2016T1 GeneSIS Final"

From IS480
Jump to navigation Jump to search
Line 331: Line 331:
<b>Duration:</b> ~1.5 hours <br/>
<b>Duration:</b> ~1.5 hours <br/>
<b>Number of Participants:</b> 9 <br/>
<b>Number of Participants:</b> 9 <br/>
<b>User Test:</b><br>
<b>User Test:</b>
[[Media:Genesis UserTestPlan3.pdf | Instruction here]]
<b>User Test Results:</b>[https://wiki.smu.edu.sg/is480/IS480_Team_wiki%3A_2016T1_GeneSIS_User_Testing#User_Testing_3 Click here to view]
<b>User Test Results:</b>[https://wiki.smu.edu.sg/is480/IS480_Team_wiki%3A_2016T1_GeneSIS_User_Testing#User_Testing_3 Click here to view]

Revision as of 22:38, 14 November 2016


Genesis home button.png
Genesis aboutus button.png
Genesis projectoverview button.png
Genesis projectmanagement button.png
Genesis document button.png
About Us
Project Overview
Project Management

Midterm Final

Project Progress Summary

Presentation icon.png Deployedsite icon.png GPoster icon.png Video icon.png
Final Slides VMIS - test ver. Poster Pitch Video

Project Progress

  • Current sprint: Sprint 11
  • Sprint period: 03 Nov - 16 Nov
  • Major milestone: Final Presentation

Project Highlights

Prior to undertaking this project, the description we received from the sponsor appeared simple and straightforward which led us to believe that every module was achievable. However, once we took on the project and began pseudo-coding and functionality planning, we realized that the project was not as we thought. The difficulty lies in integrating the various modules together, ensuring information is properly stored in order for each module to correctly retrieve and display for the end user.

After countless meetings - both internal, external as well as consultation sessions with our supervisor, we are proud to have completed VMIS, an internal system tailored to suit the Vimbox's operational needs. It allows the various departments to effortlessly share data with one another, eradicating miscommunication, missing information and delayed transition that is prevalent in their workplace.

Project Challenges

Throughout the development of our application, we encountered many obstacles which challenged our knowledge.
Optimizing the webpage for ipad
The site survey function creates the largest impact on the site surveyor as it replaces the use of paper with an iPad. In order justify the upgrade, the use of VMIS during the site survey has to be rendered easier and much more convenient as compared to using paper. As such, we had to code the site survey module such that it is easy to use on the iPad. Designing the interface such that it requires minimal scrolling yet maximizes the user's view was difficult. It required a lot of trial and error and user testing with our site surveyor. It was only after continuous feedback and tweaks that we managed to design a UI which was easy to use and led to a positive user experience.
Genesis ipad2.png

Administrator Module - Value Setup
The purpose of value setup was to enhance the flexibility of the system in that administrators can input new values of move types, furniture, etc. into their system without having to access the codes. However, the nature of the service formulas given by the client made it difficult for us to validate user inputs in order to ensure the data integrity. We managed to overcome this through providing a formula builder, which restricted the inputs of the user.
Genesis proj challenges1.png

Project Achievements

Following the scrum methodology allowed better project management. Regular feedback from our sponsor ensured we delivered artefacts according to sponsor's needs and helped us to identify problems and rectify them early. Usage of metrics such as burndown and velocity charts enabled us to measure productivity, ensuring team efficiency. Overall, the increased communication between scrum master, team, and product owner has facilitated the progress of our project and better manage our sprints.

X-factors delivered.
Midterm: 50 Leads, 10 Accounts, 10 Sales. System to go live by Midterm. Status: 58 Leads, 9 Accounts, 6 Sales. System went live on 23rd September
Finals: 20% Reduction time in sales process. Status: 22% reduction time recorded.

Project Management

Project Status

Team GeneSIS has delivered 100% of the agreed-upon project scope to our sponsor. Genesis prodbacklog final.png

Midterm vs Final Scope

Midterm Final

Genesis midterm proj scope.png

Genesis final proj scope.png

Team GeneSIS has completed all primary functionalities promised to our sponsor. The sponsor is pleased with the final product. However, we were unable to complete our tertiary functions, which is the google map and calculator widget. After discussion with our sponsor, we have come to an agreement that focus should be placed on ensuring that the core functionalities are bug-free and reliable.

See our Project Scope page for more details on previous changes

Midterm vs Final Project Schedule

Genesis midterm proj schedule.png

Genesis final proj schedule.jpg
In Sprint 8, inability to complete the notification module resulted in a spillover to Sprint 9. As such, the email module which was originally in Sprint 9 was pushed back to Sprint 10 and 11. In the interest of time, we discussed with our sponsor and decided to drop the tertiary functions altogether.

Project Metrics

Team Velocity

Formula: Average of accepted stories points of 3 sprints
Genesis final sprint velocity.png
Explanation: After midterm (Sprint 8), we only encountered a hiccup in Sprint 9 whereby the Notification module could not be completed within that Sprint. This required the unaccepted user stories to be brought over to Sprint 10, therefore pushing back our schedule. However, after rescheduling our project, we have been on task ever since.

Sprint Burndown


  • Planned: Total planned story points over number of days in a sprint
  • Actual: Actual story points completed each day in a sprint

Burndown charts from some sprints since Midterm are highlighted here.
See our Midterm Wiki page for more details on sprints prior to Midterm.

Sprint 9
Genesis sprint9 burndown.png
Explanation: In Sprint 9, the 'view sales report' functionality has not been completed. As seen in our finals schedule, we have allocated more time in Sprint 11 to complete the functionality. Hence the inability to complete all user stories in Sprint 9.

Sprint 10
Genesis Sprint10 burndown.png
Explanation: In Sprint 10, all user stories have been accepted.

Sprint 11
Genesis Sprint11 burndown.png
Explanation: In Sprint 11, all user stories have been accepted.

Risk Management

Risk Type Risk Event Likelihood Impact Mitigation
Project Management Risk Unable to develop tertiary functions due to insufficient time High Low Monitor project progress closely. If risk were to realize, inform sponsor at once and decide if necessary to drop other functions and proceed with development or drop tertiary functions completely.

Explanation: The risk management was conducted after midterm towards the end of Sprint 8 where we realized that tasks in Sprint 8 could not be completed in time and had to be brought over to Sprint 9. Reviewing the secondary functions made us realize that we may not have sufficient time to begin development of tertiary modules. We discussed with our sponsor and decided to focus on functionalities that were already developed or developing. As the tertiary functionalities had little impact on the core functionalities, the sponsor agreed to drop those functionalities.

See our Risks page for the full list of potential risks

Unaccepted Stories of Each Sprint

SCRUM Iterative 1.png
Explanation: At the end of each sprint, the product is shown to our sponsor where functionalities that were implemented during that sprint is demonstrated. If bugs are found or functionality is incorrectly implemented i.e. unaccepted, the product is left inside the product backlog. If the functionality hinders the development of the next function, the user story will be edited accordingly and moved to the next sprint. If the functionality is non-consequential, it will be rescheduled to a later date for fixing. See our Stories page for each sprint's user stories.

Technical Complexity

1. Technical Complexity 1 - Sales Interface

Genesis tc1.png
The sales interface is split into the respective housing addresses that the customer has provided with each of them having to keep track of a separate item list as well as the services that the particular house requires. In addition, after discussion with the sponsor, we settled on a fixed set of variables for the formulae to input into the system (material charges, additional charges, boxes and manpower).
Genesis tc2.png
Every global variable shown in the screenshot is an array to contain the respective objects for the different house addresses. The objects are differentiated by a unique div id which will be stored and retrieved from the database.
Genesis tc3.png
As mentioned before, every address has its own service list and the table cells contain both the unique div id as well as the respective formulae. This is passed into the update_service method in the javascript file and the formula will be stored in the formula variable and deciphered.
Genesis tc4.png
By storing the formula in the array allows us to dynamically update the calculated sum of the indicated formula whenever the related variables are updated. Any customer or vimbox item is added to the list, the update_service method will be triggered to update the new calculated value of the formula. Each formula is designed to have single spaces as the delimiter. The update_service method first splits up the elements via the single space delimiter and starts to run through every element to compute the formula, following the rule that all variables and numbers must be separated by an operand. When a variable is detected, the corresponding value will be retrieved from the respective array shown above and computed instead.

2. Technical Complexity 2 - Live Notifications

In Vimbox Movers Internal System, we enabled live notifications catered to specific situations to facilitate the communication between different departments in Vimbox. For example, assigned parties of a ticket will receive the notification when the ticket is created and the creator will receive the notification when the ticket is resolved. This is done via the use of web sockets through openshift.
Genesis tc5.png
When the user is logged onto the system, a web socket will be created with the use of the wsUrl variable as the parameter. Every user will be connected to the same web socket in order to send and receive notifications.

Whenever the function specified to send notifications, the servlet invoked will be setting the message with the key “notification” in JSON format. The message is designed to be in a standard format,
Genesis tc6.png
Genesis tc7.png
As shown the screenshot with the wsUrl variable, we have set the endpoint of this notification server as the java class NotifcationServerEndPoint set with the server endpoint annotation of value “serverEndpoint” and a configurator named NotificationServerConfigurator.
Genesis tc8.png
The configurator overrides the default handshake method established to retrieve and set the user object instead of the usual configuration.
Genesis tc9.png
With that done, whenever the web socket variable is created the handleOpen method will be invoked and the user object will be stored in the set of users that we deemed as online.
Genesis tc10.png
This is to facilitate the sending of notifications when the designated users are online. When the message is sent via the web socket, the server endpoint handleMessage method will be invoked.
Genesis tc11.png
From here we deciphered the payload that is coming in. Delimiting by }{ for multiple messages, we then go on further to retrieve the designated users to send the message over. At the end of the day, we will store the notification into the database in case the user is not online and they will still be able to see it when they login afterwards.

Quality of Project

Project Deliverables

Stage Specification Modules
Project Management Meeting Minutes Internal, Supervisor & Sponsor Meeting Minutes
Project Schedule Project Schedule
Metrics Project Metrics
Risk Management Risk Management
Requirements Project Scope Project Scope
User Stories User Stories
Analysis Market Research Market Research
Architectural Design Architectural Design
Design Prototypes Mid & High Fidelity Prototypes
Testing User Test Plan & Results User Test Plan & Results
Project Handover Introduction Slides Delivered via private folder on Google Drive
User Manual User Manual
Source Code Delivered via private folder on Google Drive


1. By having a single point system for Vimbox employees to use, we streamlined the process of transferring information from paper to excel or vice-versa. With VMIS, employees only need key in the information once, and this information is shared across relevant departments.
2. Our system allows the Site Surveyor to generate a quotation on the spot for client to review the moving fee. This speeds up the decision-making process in comparison to the past where a lot of time was wasted on returning back to the Vimbox office in order to draft out a quotation before notifying the customer.

1. To ensure that our code is maintainable after the handover, we adhered to the standard Java and Javascript coding conventions and minimized deviation.
2. For slightly more complex codes, we included comments that explained the logic flow. We also ensured that our Git commit messages were always meaningful and consistent with the industry accepted standards.

Even though our application is an internal system for Vimbox, we tried our best to cater to their business needs as closely as possible. In order to make VMIS more usable, multiple user testings were conducted and valuable feedback was given. Through the understanding our users' behavior, we ensured that our team was within contact whenever users were uncertain of functionalities. We have also included a User Manual during the handover for the client to view when necessary.


User Testing 1

Venue: Vimbox Office @ Tradehub 21
Date: 11 Aug 2016, Thursday
Time: 10:00am
Duration: ~35 minutes
Number of Participant(s): 4
User Test: Instuction here
User Test Results: Click here to view

User Testing 2

Venue: Vimbox Office @ Tradehub 21
Date: 21 Sep 2016, Wednesday
Time: 6:30pm
Duration: ~45 minutes
Number of Participant(s): 5
User Test: Instruction here
User Test Results: Click here to view

User Testing 3

Venue: Vimbox Office @ Tradehub 21
Date: 10 Nov 2016, Thursday
Time: 6:00pm
Duration: ~1.5 hours
Number of Participants: 9
User Test: Instruction here
User Test Results:Click here to view

UI Fixes based on User Test 3

1. Clean create sales form
Genesis ut3 1.png

2. Site survey UI optimized for iPad
Genesis ipad1.png


Team Reflection

The team has experienced what it’s like being involved in a full project life cycle. We picked up hard skills such as project management and web application development. Not forgetting soft skills such as internal communication within the team and communicating with external parties such as our supervisor and sponsor. We have also witnessed our solution value-add to the company’s business process, making the project a fulfilling one.

The team has been keeping me updated very regularly on the progress on product development. The team is very strong in the technical aspects of the product and they are more than willing to find alternate ways to improve the overall user experience of the product. We have begun using the system and have found VMIS to offer a stark improvement in the speed of employee's work! Some immediate effects I have noticed is that there's no longer any miscommunication and elimination of paper altogether. Overall, the team is very receptive of any feedback and are always trying to find ways to improve the overall product and the whole experience of the product design. I am very satisfied with the product.

Individual Reflection


Designing a user interface that is both user-friendly and dynamic enough to cater to user's needs can be quite challenging. I have learnt to effectively use javascript/jQuery to facilitate the integeration between front-end and back-end. Apart from gaining coding skills, I have also aquired soft skills that allows me to work harmoniously with my group members.

Yu Sheng:
This project has given me the opportunity to learn more about the use of java and javascript to create a comprehensive system to facilitate a company's business process. In addition, it has allowed me to see the usability of our system and the responses of our sponsor, motivating me to make better decisions during the development phase in the future.

Xue Ning:
Over the course of fyp, I have learnt to use Javascript and jquery to design a good interface based on information from the user's perspective, such as how the whole flow will play out and considering which part they are more comfortable with. In addition, I have also learnt the ability to respond to changes if necessary.

Qing Wan:
From planning to development as I witnessed the project materialize and slowly see the bigger picture, I begin to understand importance of documentation and the need for iterative cycles to ensure results. Granted that FYP is just a flavor of what's to come, at least I now better appreciate the stages of a project development cycle.