HeaderSIS.jpg

IS480 Team wiki: 2016T1 NAWTY Final

From IS480
Jump to navigation Jump to search
NAWTY Banner.png

NAWTY Green Bicycle White.png

Main Wiki

  NAWTY Yellow Bicycle White.png

Midterm Wiki

  NAWTY Coral Bicycle White.png

Final Wiki

NAWTY Slides Icon.png
Final Slides
NAWTY Poster Icon.png
Poster
NAWTY Video Icon.png
Pitch Video

Project Progress Summary



Project Highlights

  • LOOP booth at Car Free Sunday on 30 October 2016
  • GIS Day sharing and demonstration at Digital Planning Lab on 16 November 2016
  • Requirement changes due to privacy issues raised
- Removal of Social Media Module
- Removal of Full Name
- Replaced Email with Security Questions
- Replaced Profile Picture with Avatar
NAWTY Meeting Summary.png

Project Management



Project Scope and Status

NAWTY FinalFeatureCompletion.png


Our project scope has changed since midterm to accommodate the issues raised on privacy during our Midterm Presentation, and to bring more value to end-users. The main changes include:

- Removal of Connect and Sign Up with Facebook
- Addition of Security Questions
- Expansion of Admin Module
- Addition of Select Alternative Routes Functionality

Planned Project Scope

NAWTY Midterm Scope.png


Actual Project Scope

NAWTYScope.png

Project Schedule

Our project schedule has also changed since midterm. Issues about privacy were raised during our Midterm Presentation. We have since included PDPA Compliance (Removing Email and Full Name fields & replacing profile picture to avatar) and User Profile II (Security Questions to replace Email) into our timeline. There has not been additional delays in our schedule.

Planned Project Schedule

NAWTY Timeline 4.png


Actual Project Schedule

NAWTY Final Timeline.png


Project Metrics

NAWTY Bug Score.png
Total Bug Score per Iteration:
(1 x No. of Low Impact Bugs) + (5 x No. of High Impact Bugs) + (20 x No. of Critical Impact Bugs)
NAWTY Task Graph.png
Task Metric Score per Iteration:
Number of Tasks Completed in Iteration / Number of Tasks Planned for Each Iteration
NAWTY Team Bonding Graph.png
Team Bonding Metric Score per Iteration:
Total Number of Team Dinners During Iteration (Official & Unofficial Meetings)

Technical Complexity

Routing Algorithm
We used the following extensions on the PostgreSQL database to manipulate and store geospatial data.

1. pgRouting: Provides geospatial routing functionality
2. PostGIS: Allows for manipulation of geospatial data


The data used for building the routing network stored in the database comes from OpenStreetMap.
We made use of Dijkrsta’s Algorithm for computing the shortest/safest path from 1 node to another. More information on how the Dijkrsta’s Algorithm actually works can be found here: https://www.youtube.com/watch?v=_lHSawdgXpI
By default, the routing function provided by pgRouting requires the start and end points to be nodes inside the routing network. These nodes are usually the intersections of roads. However, this is impractical as users may not be starting and ending on an intersection. Therefore we coded a custom procedural language structured query language (PL/SQL) that carries out pre-processing and post-processing to calculate the shortest/safest path from any starting and ending point.

Firstly, the closest lines from the user specified starting and ending locations are obtained.

NAWTY Routing1.png

Secondly, the point on the line with the shortest distance to the user specified starting and ending locations are obtained.

NAWTY Routing2.png

Thirdly, the start of the line, which corresponds to a node is obtained.

NAWTY Routing3.png

Depending on whether the user selects safest or shortest route, the Dijkrsta’s Algorithm provided by the PgRouting extension is invoked with the derived starting and ending nodes and the associated costs (depending on safest/shortest).

NAWTY Routing4.png

Since the routing algorithm returns multiple sets of routes, the code loops through each of the route and finds the initial line starting from the starting node.

NAWTY Routing5.png

Then, using the point on the line with the shortest distance to the user specified starting location, the segment before and after the point is obtained.

NAWTY Routing6.png

After which, the initial line is replaced by the segment that connects from the closest point on the closest line to the user’s specified location to the subsequent lines in the route.

NAWTY Routing7.png

This is repeated to find the segment on the last line in the route that connects to the point on the line closest to the user’s specified ending location.

NAWTY Routing8.png

The distance for each route is stored.

NAWTY Routing9.png

To provide a more accurate estimate of the time taken for the user to complete the route, the average speed for all the routes that the user has previously taken is determined and used in the calculation. If there is no historical average speed, a default value of 10km per hour is used instead.

NAWTY Routing10.png


Real-Time Updating of Routing Algorithm to Account for Traffic Situations
We want the routing algorithm to be updated real-time to account for any traffic situations such as road blocks, road works, traffic diversions, vehicle breakdowns. We made use of the traffic incident API provided by Datamall@MyTransport.sg to receive all the latest updates to the traffic situations.

Firstly, we set up the node-schedule package to schedule the sending of the HTTP request to the Datamall API at the 30th minute of every hour.

NAWTY Traffic1.png

Secondly, we filtered out messages that are related to traffic situations on highways since highways are out of bounds to cyclists.

NAWTY Traffic2.png

This is done through creating a custom function that screens through the message of each traffic report.

NAWTY Traffic3.png

Thirdly, we check the database to see if the reports have already been incorporated into the routing algorithm.

NAWTY Traffic4.png

We then insert the new traffic reports into the database and associate it with the nearest line in the routing network.

NAWTY Traffic5.png

Following which, we find the rows where traffic situations have been resolved. We also delete rows where there is no line that is within 500m of the traffic incident coordinates. We also retrieved the records where the amendments to the routing algorithm has not been done.

NAWTY Traffic6.png

Using the records retrieved that have not been incorporated into the routing algorithm, we multiply the length of the associated line by 1.1 for each record. For traffic reports that deal with road blocks, we set the cost to a negative number so that the routing algorithm will not route across that line.

NAWTY Traffic7.png

For existing records in the database that are no longer relevant, we reverse the amendments made to the costs of the line.

NAWTY Traffic8.png

Finally, we delete the outdated records in the database.

NAWTY Traffic9.png


Quality of Product



Intermediate Deliverables

Stage Specification
Project Management Project Schedule
Meeting Minutes
Project Metrics
Requirements Market Research
Project Scope
Design Prototypes
Diagrams
Testing Test Plans

Quality

1. Security

We made use of Json Web Tokens (JWT) to maintain the ‘logged-in’ status of the users.

NAWTY Security 1.png


When a user logs in with the valid credentials, we return a unique JWT token that users append to their subsequent requests. In this case, every request is screened for a valid JWT token.

NAWTY Security 2.png


We also verified the type of user depending on whether the user is a cyclist or admin to make the access to the data more secure. We excluded API endpoints that do not require verification of the user’s identity such as login, signup etc.

NAWTY Security 3.png


2. Scalability

Since the verification of the source of the request is done through JWTs, we scaled our server to have 2 instances of it so that it is better able to hand concurrency and load. We also implemented a HAProxy (TCP/HTTP Proxy) for load balancing to reduce the response time of each request because of having to queue the request.

NAWTY Scalability 1.png


We configured the server to have a minimum of 2 instances up and running to be able to deal with unexpected surges in requests.

NAWTY Scalability 2.png

Deployment

NAWTY Midterm Android Deployment.png


Apple App Store - https://itunes.apple.com/us/app/loop-singapores-own-cycling/id1155622552?ls=1&mt=8
Google Play Store - https://play.google.com/store/apps/details?id=com.teamnawty.loop


Testing

NAWTY Midterm QA.png


NAWTY Final UT Summary.png


For more information about our user testing, click below to read more:


NAWTY UT1.png       NAWTY UT2.png       NAWTY UT3.png       NAWTY UT4.png       NAWTY UT5.png


Reflections



Team Reflection

Essential to every project - Communication. Communication between front end and back end developers, between project manager and developers, supervisor and client was extremely crucial to the success and progress of our project. Without communication, developers would not have been able to work together and the project manager would not know whether they were coping with the project requirements. During the few times when some team members were busy and didn't talk much, the project was unable to move forward. Especially in this project, we realised that communication was very important.

All in all, our team had a wonderful and enriching IS480 experience. We went through the whole product development cycle - from the research to the development of the application to the handover. It was a tiring 7 months, but we definitely learnt a lot.


Individual Reflections

NAWTY Annabelle Circle.png
Annabelle Victoria Ong

"I think through this project I really learnt how to manage our time better and how to present myself better to various stakeholders. I would say that our biggest learning point is that the project is only as strong as the weakest link. Everyone has to work together and everyone is as important. If anyone, or anything, falls short, it would either slow the whole project down or it would take a lot for the group to cover up.
IS480 may be a really heavy module, but I think we all managed to take away something from it."
NAWTY Wei Kong.jpg
Leong Wei Kong

"Throughout this project, I have tried, tested and integrated various mapping framework and libraries such as Leaflet and OpenLayers as currently there are no front-end mapping frameworks that compiles all the strengths of existing frameworks.
One of the main challenges in integrating these frameworks is the conflicting coordinate standards such as GeoJSON, SYV21 and WGS84. In order to overcome this challenge, we had to agree on a common coordinate standard and all coordinates will be parsed as that standard.
Finally, it has been a long but enriching journey and my biggest takeaway from IS480 is that in an IT development project, teamwork is extremely important."
NAWTY Nicholas.JPG
Nicholas Tan

"I feel that IS480 is a very important module for information systems students as it allows me to work with real-life clients and experience the entire process even before embarking on my career.
I got to go through the entire project lifecycle from gathering requirements from my clients, developing the solutions, up to the very last step which is the handover.
Through the project, I learn that whatever can go wrong, will go wrong. The only way is to plan for it and know how to mitigate it when it happens. And I think personally, this project tremendously sparked my interest in mobile application development. This end of this project marks the start of my exploration on even more mobile development technologies."
NAWTY Teck Jin.png
Teo Teck Jin

"I have learnt that it is important to assess the gap between business requirements and user interest in order to build a product that truly provides value to its users. Moreover, I have become more comfortable with changes and to better manage different stakeholders and their expectations. I believe this FYP experience definitely be useful for me in the future endeavors to come."
NAWTY Wee Kian.JPG
Yeam Wee Kian

"As the lead backend developer for this project, I had to overcome various challenges such as the complexity of the algorithm which would have implications on the scalability and load of the server, working with the Nicholas, the frontend developer, to ensure that integration of the frontend and backend goes smoothly and server issues such as the load balancing etc.
At the end of this project, I have learnt how to properly verbalize the logic of the algorithms to those that are not IT-savvy. At the same time, I also learnt how to evaluate, leverage and integrate 3rd party open-source packages to increase the efficiency of the code development."