HeaderSIS.jpg

Difference between revisions of "IS480 Team wiki: 2012T2 Viaxeiros Final"

From IS480
Jump to navigation Jump to search
()
()
Line 479: Line 479:
 
''Melissa Tian Peishi''<br/>
 
''Melissa Tian Peishi''<br/>
 
''Ng Sing Lim'' <br/>
 
''Ng Sing Lim'' <br/>
 +
For this project, I have set out the goal of learning how to develop an android application. I believe I have managed to many grasp aspects to it. In terms of native design, I have improved in writing proper xml codes and also coming up with manual overriding codes. As for android coding, it’s the implementation of fragments, adapters, camera and enhancement features such as GZip and Lazy loading. Other coding learning outcomes include API retrieval via REST implementation and manipulation of JSONObjects. 
 +
 +
Working with An has also widened my knowledge on many other technical know how such as performance testing etc.
 
''Siew Lin''<br/>
 
''Siew Lin''<br/>
 
* Important Project management skills
 
* Important Project management skills

Revision as of 16:19, 21 April 2013

Viaxerios Logov1.png
Welcome to Viaxeiros FYP Wiki Page
Navigation 8.png


Final Term Slides
   


Coming Soon!

Project Progress Summary
   



Statistics of our project:

We have altogether:
  • 12 iterations,
  • 3 usability testing and
  • 3 major deployment.


PrioritiesViaxeiros.PNG

Changes since Midterm

Based on the feedbacks gained from the midterms as well as the user testing, our team has implemented the following changes:
  1. Introduction of Guest Account
    • Guests are able to try out new functions such as adding of places in a default travelogue
    • Many entry points are introduced for guests to login to become a new user.
  2. Usage of vector offline map (Mapsforge) instead of Raster offline map (OSMDroid)
    • Able to provide a single connection point when users download offline map
    • Provide future avenues of expansion such as routing
  3. Delete downloaded travelogues from phone
    • Enable users to manage their phone space when needed





Project Highlights
Iteration Descriptions / Highlight
4 Increasing Scope to be Done

After the discussions we had with the sponsor, we have decided to implement a few changes in the project scope to provide a more holistic experience of the application. Hence, as mentioned in midterm, more native pages are introduced in the application, which majorly affected the project schedule.
In view of this change, our team has decided to drop one of our additional functionality to better concentrate on the additional functions to be done.

10 Introduction of Guest Function and Change in Offline Map

From the feedbacks received from the midterm presentation and the user testing, our team decided to add in a Guest function to allow users to try out the functions without the need to login. Additionally, many entry points are included to allow users to login.
Furthermore, our team changes our offline map library used to Mapsforge, a library which supports vector maps. The actual map file will be stored within Qiito server, where it can be retrieved when users download their travelogue.
To cater to this, our team decided to drop our additional functionality and instead focus on the new changes.

Project Challenges
Challenge Description
Implementing workable Offline Map
  1. Difficulty getting documentation for OSMDroid
  2. Change from OSMDroid to Mapsforge
  3. Directly changing Mapsforge
  4. Understanding the rendering of maps in Mapsforge
  5. Integrate 2 versions of Mapsforge
Out of Memory Error
  1. Small phone memory causes significant out of memory error
  2. Different phone model has different assigned phone memory and procedures for phone memory release, resulting in differing debugging results
  3. Manage to use lazy loading and other more efficient codes to mitigate the problem
Project Achievements
Achievements Description
1. Customizing of Offline Map Features

Why is it so successful?
There are many ups and downs when implementing the offline map. Our team started off with using OSMDroid as we believe that it will be easy to adopt. However, realizing the limitations in term of functions the library has, we decided to switch to offline vector map Mapsforge which turns out to be more flexible than OSMDroid.
In order to integrate with our SherlockActionBar Library and the manipulation of customized pins in the offine map, it is necessary for us to customize the library directly, which is a great feat for us due to the limited time and expertise in creating a library. Hence, it is a great achievement for us when this implementation is successful ultimately.

2. Implementation of full native application compatible for Android 2.3 and above

Why is it so successful?
The client's requirement for the application is for it to be compatible for Android 2.3 and above. This prove to be a challenging request as many functions and look and feel do not support Android 2.3. Thus, with the usage of SherlockActionBar library, we have managed to provide a standardize outlook throughout the different versions. Additionally, we also learnt and manage to provide support for different phone models, as the display of our application might be skewed due to the different phone size.

Project Management
   


Project Schedule
This is the summary of our current project status:
Final project overview.jpg
We have completed all of the requested functions in our client requirements. Additionally, we have included new functions and features such as the guest feature and deleting of downloaded travelogue.

Metrics
Bug Metric
The following shows the result of our bug metric for the project:
FinalBugMetric.png
As can be seen, at the start of our last iteration, there is an increase of bug points to 42. This can be due to the vigorous testing we did to make sure that our application is bug-free. Hence, many of the members are involved in major debugging session while the rest are involved in enhancing the application. We have completed the application with a total bug points of 13.

Schedule Metric
We have generally 2 major peaks during the project. These peaks in metrics are found to be before the major examination period. This is because there is a relatively more functions allocated during these iteration to cater to the loss in time during the examination period, causing slight delay for each of the subfunctions to be completed.

Work Stress Metric
This work stress metric is used as a guide for the project manager to gauge the current stress level of the members, in terms of them balancing the tasks allocated to them and their school work. Basing this together with the schedule metric, the project manager can provide the suitable action plan to balance out the stress metric of each of the members.

Click here for more details on the metrics.

Change Request Log
The purpose of the change request log is to track the change requests of all our clients and users. This will enable us to better manage our project scope and hence aid in scheduling for upcoming iterations. This is a snippet of how the log looks like:

Change request.jpg

Each of the change requests are logged in the change request log first. After which, as a team, we will evaluate and decide if the change should be implemented.
  • Functional Description : provide more information on change request
  • Proposed Decision : Our team's decision if the change is implemented
  • Remarks : provide more information on our rationale in our decision

Click here to view the logs.


Technical Complexity
Complex Feature Description
1. Offline Vector Map (Mapsforge)

Mapsforge logo.png

Purpose of feature

  • To display and render offline map when users download a travelogue
  • To display pins and navigation to other applications via the map

Complexity of Feature

  • Direct customization of the library source code
  • Changing library source code to fit Sherlock Fragment
  • Integrating 2 versions of source code into 1
  • Find and retrieve the right file type to be downloaded
  • Limited documentation available in the internet

For more information on the complexity of this feature, please view here

2. SherlockActionBar Library

Sherlockbar logo.png

Purpose of the Feature

  • Provide standard view for phone versions 2.3 and above
  • Customize action bar to suit Qiito's business concept

Complexity of Feature

  • Integrate Fragments to Online (Google Map) and Offline Map (Mapsforge) Library
  • Standardization of outlook in each fragment

Product Quality
   


Project Deliverables
Stage Specification Module
Project Management Minutes
Metrics
Requirements Change Request Log
Story Board
Analysis Use Case
Design System Architecture
Database Diagram
Testing Usability Test
Handover Documentation
  • Comments of codes
  • Documents on setting up Eclipse
  • Procedure to deploy in Google Play
Quality
Quality Attribute Description
Performance

1. Improvement in performance in terms of loading speed and minimal crashes

  • Implementation of GZip and Lazy Loading
  • Removal of excess or redundant resources used by clearing bitmap images
Usability

2. Improvement in User navigation and look and feel

  • Include guides for users when they first install the application
  • Introduce the guest account to allow users to try out more functions before logging in as users
Deployment
Qiito has 3 servers used: one for development, another to simulate real data usage, and the live server used for their users.
The compiled apk package is then uploaded into Google Play, where any users can access to this.

  • Deployment Version : v3.0
  • 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

Click here to download our latest application version!
Download the application here.






Testing
For this project, we have done a total 3 user tests. The first 2 caters more towards testing the functionality of the application, while the last user testing is geared more towards the user experience and interface of the application
Usability Test 3
  • Done successfully in 1st April 2013.
  • There is a total of 14 users for this testing
Please click here for a more detailed analysis of the user testing results.


Reflection
   


Team Reflection

The IS480 experience has been a huge challenge to many of us. As a team, we feel that these are major learning points:
  • Experience the operations of a startup company.
  • Learn many new technologies and libraries such as the Android development and the map implementations.
  • New concepts and gain insights to acquiring user requirement
Individual Reflection
Chan Zi Jun
Lin Yukai
Melissa Tian Peishi
Ng Sing Lim
For this project, I have set out the goal of learning how to develop an android application. I believe I have managed to many grasp aspects to it. In terms of native design, I have improved in writing proper xml codes and also coming up with manual overriding codes. As for android coding, it’s the implementation of fragments, adapters, camera and enhancement features such as GZip and Lazy loading. Other coding learning outcomes include API retrieval via REST implementation and manipulation of JSONObjects. Working with An has also widened my knowledge on many other technical know how such as performance testing etc. Siew Lin
  • Important Project management skills
  • Communications and collaborations
  • Learn new technology