|
Statistics of our project:
We have altogether:
- 12 iterations,
- 3 usability testing and
- 3 major deployment.
Changes since Midterm
Based on the feedbacks gained from the midterms as well as the user testing, our team has implemented the following changes:
- 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.
- 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
- 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
|
- Difficulty getting documentation for OSMDroid
- Change from OSMDroid to Mapsforge
- Directly changing Mapsforge
- Understanding the rendering of maps in Mapsforge
- Integrate 2 versions of Mapsforge
|
Out of Memory Error
|
- Small phone memory causes significant out of memory error
- Different phone model has different assigned phone memory and procedures for phone memory release, resulting in differing debugging results
- 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 Schedule
Metrics
Bug Metric Schedule Metric Work Stress Metric
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:
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)
|
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
|
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
|
|
|
|
|
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!
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.
|
|
|
|
Team Reflection
Individual Reflection
|
|
|
|
|
|
|
|