HeaderSIS.jpg

IS480 Team wiki: 2013T2 SkyTeam Final Wiki

From IS480
Jump to navigation Jump to search


SkyTeamLogo.png

Final Wiki

 

General Wiki

 

Project Deliverables

To view our Final Presentation slides, please click here

Project Aspect Document Type Document Link
Project Management Minutes Internal Meetings
Supervisor Meetings
Sponsor Meetings
Metrics Bug Metrics
Schedule Metrics
Project Requirements Prototypes Lo-fi
Hi-fi
Business Requirements Function Description
Design Use Case Diagram Use Case
System Architecture Diagram System Architecture
Testing Test Plan Test Plan
User Testing User Testing

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

Current and Final Timeline

SkyTeam Timeline v6.png


Click here to view our detailed schedules.


Project Schedule Changes


SkyTeam PM 1.png
SkyTeam PM 2.png
SkyTeam PM 3.png
SkyTeam PM 4.png
SkyTeam PM 5.png
SkyTeam PM 6.png
SkyTeam PM 7.png
SkyTeam PM 8.png
SkyTeam PM 9.png
SkyTeam PM 10.png


Note: Changes #1 to #3 were made before Midterm. Changes 4 & 5 were made after Midterm

Technical Complexity

RISK CALCULATION
There are 2 input parameters in risk calculation: hazard level and vulnerability index. The overall risk of a specific building is equal to hazard level times vulnerability index Total risk = V x H where: V = total vulnerability index of the building H = hazard level of the surrounding regions where the building locates

1.1 Hazard

SkyTeam HM 1.png
SkyTeam HM 2.png
SkyTeam HM 3.png
SkyTeam HM 4.png
SkyTeam HM 5.png
SkyTeam HM 6.png


1.2 Vulnerability
Vulnerability index depends on 5 characteristics of a building: building type, building age, foundation type, masonry type, and roof material. These values will be provided by the end users (insurance companies) when they upload data directly on the website.

For calculating a building's vulnerability (to all climatic disasters), we look into 5 categories:

  1. Building Category (Residential, Commercial Industrial)
  2. Building Age
  3. Building Foundation (Deep, Semi-Deep, Shallow)
  4. Masonry i.e. Building Wall Material (Brick, Concrete, Corrugated Iron, Tempered Glass, Stone, Timber)
  5. Roof Material (Tiles, Metal Sheets, Fibro, Slate, Glass)
Vulnerability Description Vulnerability Index
High Vulnerability Building Category + Building Age + Building Foundation + Building Elevation Level + Masonry + Roof Material = (Integer between 2 and 3) 3
Medium Vulnerability Building Category + Building Age + Building Foundation + Building Elevation Level + Masonry + Roof Material = (Integer between 1 and 2) 2
Low Vulnerability Building Category + Building Age + Building Foundation + Building Elevation Level + Masonry + Roof Material = (Integer between 0 and 1) 1


A categorical breakdown of the attributes that account for vulnerability is reflected below:

Attribute Description Vulnerability Index (Scale of 3) Vulnerability Index (Scale of 10)
Building Category Description 0.045 1.2
Commercial 0.015 0.6
Industrial 0.09 2
Building Age Source: http://www.adpc.net/casita/course-materials/Mod-5-Physical-Vul.pdf < 25 0.015 0.6
25 < Years < 50 0.045 1.2
> 50 Years 0.09 2
Building Foundation Source: http://www.ekt.bme.hu/ArchEng/Foundations%20(S-D)-s.pdf Deep (Slurry Wall, Pile) 0.015 0.6
Semi-Deep (Well-foundation, Cofferdam) 0.045 1.2
Shallow (Strip, Pad, Beam, Mat) 0.09 2
Masonry Brick 0.081 0.6
Concrete 0.081 0.6
Corrugated Iron 0.081 0.6
Tempered Glass 0.54 2
Stone 0.09 1.2
Timber 0.09 1.2
Roof Material Tiles 0.075 1
Metal Sheets 0.075 1
Fibro 0.075 1
Metal Sheets 0.225 2
Metal Sheets 0.450 2

HISTORICAL ANALYSIS
As part of the application’s requirement, we need to implement historical analysis of the hazard level of different regions in Malaysia across the years. Specifically the application user can view the movement of three kinds of hazard risk year to year. Our team decided to make use of the Google Visualization API to develop our motion chart. As during the process of looking into the Google API, we had difficulties in integrating their methods with our real data which is fetched dynamically from the Google Fusion Table in the form of KML. Understanding this, we had to read the library and API in depth to adjust our own data.

Testing

Here is an overview of our Test Schedule:


SkyTeam UserTesting Schedule.png


We have conducted 4 tests in total. Click here to be redirected to our Testing page to find out more!

Reflections

“I learnt how to manage requirement changes efficiently and allocate and manage the team’s resources to adapt to these new requirements. I also learnt how to prevent and resolve delays. Lastly, I learnt how to consider both internal and external factors into scheduling, in order to avoid having to reschedule too often.”
- Beatriz Naguiat
Project Manager, SkyTeam


“I learnt how to manage the expectations of our sponsors. Through interacting with them regularly, I was able to improve my communication and negotiation skills. Gain domain knowledge on risk analysis and property insurance.”
- Tran Pham Viet Thao
Business Analyst, SkyTeam


“I learnt how to manage the expectations of our sponsors. Through interacting with them regularly, I was able to improve my communication and negotiation skills. Gain domain knowledge on risk analysis and property insurance.”
- Tran Pham Viet Thao
Business Analyst, SkyTeam


“I learnt how to use Google Fusion Tables API and Google Maps Engine Pro. Moreover, I am better able to source for resources efficiently in order to learn new technologies, especially geospatial technologies.”
- Le Hung
System Architect, SkyTeam


“I gained a deeper understanding on Google Maps Javascript API and Google Visualization API. I also learnt how to integrate backend functionalities with front- end display of data.”
- Miguel Riingen
Lead Developer, SkyTeam


“I learnt how to make use of Google Places API for most of the functionalities under my wing. I gained deeper insights on quality control, having facilitated various internal testings and UTs. I have also learnt more about UX, which I can greatly apply to IDP.”
- Miguel Riingen
Lead Developer, SkyTeam