IS480 Team wiki: 2012T2 Viaxeiros Mid Terms

From IS480
Jump to navigation Jump to search
Viaxerios Logov1.png

Welcome to Viaxeiros FYP Wiki Page

Navigation 7.png

Mid Term Slides

Project Progress Summary


Currently, Viaxeiros in in their Iteration 9 on 26 February 2013, and in the midst of meeting the upcoming milestone, which is the Midterms presentation, at 26 February 2013.

Currently, since the Acceptance Presentation which is at 5 November 2013, The following main features have been completed:

  1. Native pages for travelogue and places
  2. Download of travelogue for offline usage
  3. Camera functions in the application
  4. Online and offline map display
  5. Improvement of performance and memory issues

Based on the current status of the project, our team has decided to focus only on one of the additional functions proposed in the Acceptance Presentation, which is the Augmented Reality.

Project Highlights
Iterations Descriptions / Highlights
2 Major Delay in Offline map

Prior to the actual start of the coding phase, it has been decided that the offline map feature is going to take much more time than that of other functions as many of us are unknown to any available map technology, let alone one catered to offline usage. Thus, we have planned to start this function early, hoping to overcome the steeper learning curve earlier in the project. Our worries turn out to be correct, where our research in Iteration 1 shows that offline map is much more complex than what we assumed to be. Judging from this, we have made an appropriate change in our schedule, thus assigning a longer time for the creating of the offline map.

4 Increasing Scope to be done

During Iteration 4, in one of the client's meeting, we have come to a conclusion with our sponsor that there should be a change in the requirements of the application. In view of the need to provide a more holistic feel of the application and to cater more wholesomely for the offline purposes, the clients and us decided to include the viewing of travelogues, places as well as the listing of travelogues to be native pages. This has in turn result in a major change in the schedule as some of the functions such as the search will be pushed to the later part of the schedule.

In addition, our group has also discussed among ourselves and feel that one of the additional functions might have to be dropped as there is a high chance that this change in requirement will increase the time needed to complete this requirement.

7 Change in focus for additional functionality

After the discussion with our clients, we feel that focusing on the Augmented Reality might suit the business model of the company better than that of the smart itinerary. This is because the smart itinerary creates a more "gamey" feel, which might contradict in the overall experience of the application. In addition, the smart itinerary might prove to be more troublesome for users as users can only accept the entire travelogue and are unable to edit much of it. Augmented Reality, in the other hand, provides users with an alternate view of the same data, which allows users to explore their surrounding in a more interesting manner. Thus, with these considerations in mind, our team has decided to focus our research on the implementation of augmented reality in the upcoming iterations.

Project Management

Project Status
Modules Status Confidence Level (0 - 1) Members in charge
Creating mobile web view 100% developed and deployed 1 Sing Lim
Login function 100% developed and deployed 1 Melissa
Native travelogue and places 100% developed and deployed 1 Sing Lim and Zi Jun
Camera function 100% developed and deployed 0.9 Sing Lim
Online and Offline Map 100% developed and deployed 0.9 Yu Kai
Adding of places 100% developed and deployed 1 Sing Lim and Melissa
Search function 100% developed and deployed 1 Sing Lim
Like / Share to be developed 0.8 to be allocated
Augmented Reality to be developed 0.8 to be allocated

Project Schedule (Plan Vs Actual)
Planned Actual
Actual midterm.png

Planned midterm.png

Key Changes

  • Include functions for creation of travelogue
  • Focus on Augmented Reality instead of Smart Itinerary

For more information on the schedule of our application, please click here.

Project Metrics

Schedule Metric

The following shows the summary of our schedule metric thus far:

Schedule metric mid.png

Bug Metric

Bug Count:

Bug metric mid.png

Work Stress Metric

Work Stress metric mid.png

Project Risks

The following shows the top 3 list of risks that our team is currently facing. For more information of the other risks, please visit here:

S/N Risk Description Consequences Impact Likelihood Risk Rate Mitigation Strategy / Contingency Plan Status
1 Technical Risk
1.1 Team is unfamiliar with the technology used
  1. There might be a delay in project schedule
  2. longer time needed to create functions
High High A
  1. Team members are to start researching and trying the technology in advance before the iteration
  2. Share research documents and knowledge among members
Risk Strategy in place - Implemented
2 Sponsor Risk
2.1 Additional requirements requested during implementation of codes
  1. Might not be able to finish requirements on time
  2. substandard work produced
High Moderate A
  1. Team members should discuss and decide if they can commit to the additional workload on time. If not, firmly reject the additional requirements
Risk Strategy in place - Implemented
3 Project Management Risk
3.1 Over-estimate the days needed to build function
  1. Delay in the project schedule
Moderate High A
  1. Project manager to take note of the schedule and plan the future schedules more carefully
  2. Provide a longer time period for the next iteration to complete the functions.
Risk Strategy in place - Implemented

Application Development

Intermediate Deliverables
Stage Specification Modules
Project Management Minutes
Requirements Change Request Log
Survey Results
UI Prototypes
  • UI Mockup
Analysis Use Case
  • Use Case Overall
Design Diagram
  • System Architecture
  • Database Diagram
Testing User Testing
  • User Testing 1
  • User Testing 2

Technical Complexity
  • Security
  1. HTTP Request Response Header - User token, application ID and parameters required to retrieve specific APIs were previously appended to a URL. To prevent user information from being compromised, we have then shifted important parameters like token and app ID to a HTTP connection header instead.

  • Perfomance
  1. Gzip - To reduce long period of dependency on a stable connnection, it is critical to ensure that the file size of the required API is kept to the minimum. Comparing the data size between a Gzip file and a text String, Gzip file is calculated to be approximately 10 times smaller. This is critical for us where users are always on the move and stable connection is hard to get. At the same time, the data we require from QIITO is known to be relatively huge (A travelogue can contain 100s of places).
  2. Lazy Loading - The idea of lazing loading is to reduce the required time needed to load and display a page. This is especially crucial when our application is required to retrieve and display a large number of images. What we have done is to make the downloading of images asyncronous and to create a queueing system (5 threads at a time) to download the images. Once an image is downloaded, it will be cached in the phone's memory and will be displayed on the page.

  • SherlockActionBar/ Fragments
  1. SherlockActionBar library allows us to create "ICS looking" apps, that look the same all the way back to Android version 1.6, which the Android sdk does not offer. The features of the library include Actionbar, tabs, overflow, split action bar, viewpager etc. Now, we are able to create multiple interfaces within a single activity across all Android OS versions. This allows a better manipulation of functions when users navigate through the application. For example, the navigation between a web view and a native view with differing interface will only require two different fragments, instead of creating a new activity. In addition, due to the flexibility of fragments, each of them can be recycled and used in other activities within the application, reducing the need for repeated codes. The complexity lies on the fact that resources pertaining to SherlockActionBar library could be limited at times and as a new Android developer, the learning curve is steep.

  • Offline Map
  1. Whilst overseas, users may have difficulty obtaining data connectivity to have access to the full functionalities of Google Maps. With the implementation of OSMDroid (Open Street Map Droid), the application will cache a specific map area pertaining to the user’s itinerary. This allows users to view the touring area on the offline map, complete with zooming features and search function of that particular area. Being an open-sourced package increases the difficulty of implementation, due to lack of proper documentation to explore customized functions. There are also certain restriction of its usage due to it being free, thus algorithms for download are required to be stricter.

  • Deployment Version - v2.1
  • Development Environment - Deployed in Android Google Play Store
  • Database - Used the phone's internal database, SQLite, Qiito Database (via API)
  • Coding Language - Java and XML

To download the application, you can visit this link to get the latest application in the Google Play Store.

User Testing


Learning Outcomes

Team Reflection

Overall Reflection

Learning outcome.jpg