HeaderSIS.jpg

IS480 Team wiki: 2013T2 SkyTeam Final Wiki

From IS480
Jump to navigation Jump to search


SkyTeamLogo.png

Final Wiki

 

General Wiki

 


Links and Downloads

To view our Final Presentation slides, please click here

Project Highlights

Project Scope Changes

SkyTeam ScopeCircle Changes 2.png


Changes Acceptance Midterm Current
Functionality Names
  1. Spatial Query
  2. Filtering Tool
  3. Drag and Drop Dashboard
  1. Location Search
  2. Data Filtering
  3. Widget Dashboard
NA
Priority
Primary Functions:
  • Comparison Tool
Secondary Functions:
  • Risk Calculation
Primary Functions:
  • Risk Calculation
Secondary Functions:
  • Comparison Tool
NA
Number of Functions
Primary Functions: 7
Secondary Functions: 2
Tertiary Functions: 2
Primary Functions: 8
Secondary Functions: 2
Tertiary Functions: 2
Primary Functions: 8
Secondary Functions: 2
Tertiary Functions: 2
Functions Completed Functions Left
  1. Upload
  2. Data-Mapping
  3. Interactive Map
  4. Location Search
  5. Data Filtering
  6. Point of Interest
  7. Risk Calculation
  8. Historical Analysis
  9. Widget Dashboard
  10. Comparison Tool
  11. Simulation
  12. User Tool Tips
None! ALL COMPLETED

Changes in Requirements

Affected Functionality Acceptance Midterm Current Managing Changes
(+) Added Point-of-Interest

There was no functionality to view the Points-of-Interest (POI) like convenience stores, fire stations, supermarkets, hospitals, police stations, train stations around a specific building location.

Our sponsors requested that we add this feature to find the POIs near the selected markers and to sort them according to the distance from the markers. This is meaningful for the end-users to estimate the social risk of the area, on top of the natural disaster risk that we calculated using the Risk Calculation Widget.

NA

Because this is a newly requested function, and the sponsor classify it as Primary Function, we discussed with the sponsor again and decide to drop the function that is 30% but no longer considered as Primary Function.(-) Dropped Interactive Graph
(+) Added Historical Analysis

There was no functionality to view the historical risk data of a particular location. Initially, our Interactive Graph function allowed us to view a static pie chart depicting the total risk of a particular building to floods, fires and earthquakes. Although it was meaningful, we felt we could develop this into something better.

We decided to value-add to the Interactive Graph function by showing a dynamic graph that allows you to view the risk probabilities (flood, fire, earthquake, total) of a building with respect to time (years).

NA

Because this is a newly requested function, and the sponsor classify it as Primary Function, we discussed with the sponsor again and decide to drop the function that is 30% but no longer considered as Primary Function.(-) Dropped Interactive Graph
Platform

We were developing our Business Intelligence dashboard on Openshift.

Our sponsors requested that we change platforms from Openshift to Google App Engine since it would be easier for them to manage and maintain the dashboard after completion.

NA

  • Changed to GAE platform
  • Added an iteration to the project schedule for Migration
Data Mapping

Initially, we intended to use Google Map Engine to display the shape files on our map, but after trying it out, we realised if we were to store them in the GME's database, we are unable to associate new attributes to the shapefiles. The database of GME is not robust enough.

We embedded the shape files into Google Fusion Tables to view the shape files.

NA

  • We transform shapefiles into Google Fusion Tables and manage to link them with new tables that contain the associating attributes
  • We carried this out during our Migration iteration, which is why we allocated more days for that iteration
Location Search

Previously called "Spatial Query", this function allowed users to search for a specific building, landmark or location using latitude-longitude, postal-code and address from the client's uploaded data. There was a slight overlap with our "Filtering Tool" widget, because the filtering tool allows you to hand-pick datasets and/or attributes to display from the uploaded datasets.

Users can search for a specific building, landmark or location using building name, latitude-longitude, postal-code and address, not just from the client's uploaded data. It's now similar to a Google Map Search.

NA

We wanted to prevent overlaps between the usage of each functionality, making them more distinct. It is more value-adding to do a location search for locations outside the data which users have uploaded.
Interactive Map

Upon hovering over a region, the area and perimeter is highlighted and region name pops up.

Upon hovering over a location marker, a pop-up containing its building name, latitude and longitude appear instead.

NA

UI fix, however the requirement change was not crucial.
Widget Dashboard

We intended to have a fixed sidebar on the left of the screen to let the user view a maximum of 3 widgets. However, the space allocation for most of the widgets was limited. This would also constrain the map size making it too small and difficult to navigate.

Widgets are now draggable and not fixed.

NA

We created each widget in the form of a draggable, translucent modal, so the user can open up and view as many widgets as he/she wants, and place them anywhere on the screen; hence, increasing user flexibility.
Risk Calculation & Hazard Maps

NA

Hazard Maps and Risk Calculation Widgets displayed a location's risk to fire, flood and earthquakes according to Malaysia's "states", which was not realistic (the whole state of Pahang would have the same exposure to flood risk. Instead, cities within states which lie closer to water bodies should have higher flood risk than those further away from water bodies). Data used for the "Hazard" component was simulated.

After our midterm, our client insisted that we could further improve our Risk Calculation Widget by using data from public data sources. As such, we made use of ArcGIS to display new hazard maps, which, by extension, were used for the "Hazard" component of the Risk Calculation algorithm. These "new" hazard maps reflect a whole region's predisposition to flood, fire and earthquake risk more realistically. Areas within the region would have varying exposure to climatic risk, instead of the WHOLE region having the same risk level.

  • This request took time as Hung and Thao had to conquer a steep learning curve for extracting data from ArcGIS for our Hazard Maps and Risk Calculation widgets.
  • (-) Dropped Location News Display
  • (+) Added User Tool Tips

Project Challenges

Technical

Learning Geospatial Analytics Frameworks

Prior to this project, none of us had exposure to geospatial analytics, let alone hear the phrase. Hence there was a huge learning gap to bridge in order for us to develop such a robust application.
  • We needed to learn the lingo and tehcnical terms used in Geospatial Analytics e.g. Geovisualization, Thematic Mapping, Latitude-Longitude
  • We needed to learn how to program, work with and style layers for our maps
  • We needed to get familiar with using Google Fusion Tables for creating and embedding our shape files
  • Resources like ArcGis helped us acquire a deeper understanding of the key concepts

Understanding Risk Assessment

Similar to Geospatial Analytics, most of our statistics knowledge dates up to our compulsory Statistics 101 module, and is still very fundamental.
  • We needed to read up on various flood, fire and earthquake risk assessment research papers before finalizing on our current model
  • We consulted Prof Seema and Risk Experts from Aon Benfiled to get a deeper understanding on risk assessment, and enhance our risk algorithm

Non-Technical

Accomodating Requirement Changes

Having our sponsors request for additional functionalities, and change our development platform necessitated our team to have certain protocol in place for managing these changes.
  • We carried out a Cost-Benefit Analysis during our meeting to assess the pros and cons of implementing such functions, we had a deeper look into the practicality and feasibility of accepting such changes
  • The actions we took are reflected in the table above

Miscommunication between the Team and our Sponsors

On a number of occassions, our team had to play the "waiting game" with our sponsors when we required data vital for the progress of our development.
  • We now give our sponsors a deadline for when we need the data, and make a gentle reminder a day or two before to prompt them on the impending deadline. We also have a 1-2 day buffer in case they cannot meet the deadline.
  • In the event a buffer after the stated deadline for data cannot be met, we readjust our project schedule and compromise on buffer days in other iterations.

Project Achievements

  1. 100% of our project has been completed, (12/12 functionalities)
  2. 12 out of 13 iterations completed; Our current iteration (Iteration 13) ends on Poster Day (28 April 2014)
  3. 3 User Tests successfully conducted
  4. 1 Heuristic Evaluation successfully conducted

Project Management

Here's our current and final timeline:

SkyTeam Timeline v6.png

Click here to view our detailed schedules.