IS480 Team wiki: 2010T1 AnythInc/final
- 1 Project Progress Summary
- 2 Project Management
- 3 User Acceptance Test
- 4 Changes to Bug Tracking
- 5 Technology
- 6 Reflection
- 7 Sponsor Comment
Project Progress Summary
Coming to the end of the IS480, every single effort that each of us put in is not going to waste. We have completed all of the core functionality agreed with our sponsor, GTW Holdings Pte Ltd (HungryGoWhere). Apart from that, the defined scope to allow fully functional HungryGoWhere Android application to run on the HTC Wildfire device that is sponsored. However, our group had extended our 2 User Acceptance Test (UAT) to more than the sponsored device, which will help to target a wider base of Android User who uses Samsung, Sony Ericsson, Motorola, and HTC.
As part of the plan to release the Android Application on Google Android Market Place in the mid December 2010, GTW holdings has to ensure the application go through an intensive testing (Which GTW holding is the process of doing the intensive testing). Aside from that, our sponsor is in the discussion with large Mobile retailer to embed our android application on their Android Operating System with every phone that they release.
Despite our hectic schedule, we challenged ourselves to broaden support to more brands of mobile devices via 2 rounds of our UAT. The completed application is in the process of internal testing by GTW Holdings Pte Ltd which will then be release to android market place.
To come out with the wireframe, we had faced a few challenges in keeping the layout of android application proper(uncluttered). By collecting constructive feedback from our sponsor's designer to improve on every details of the design, we hope to make the application as ergonomic as possible .
After much feedback from UAT 1 and 2, a few usability issues were pointed out by testers such as keyboard stays when user navigate through the screen, the icon appears too small and list of items looks cramped. The application had been updated to address the above concerns.
Support for more Mobile Devices
Although the mobile devices are running on the same Operating System, Android, each mobile provider had built on top of the vanilla version(Original Version) to differentiate from competitors. This has resulted in the increased complexity in trying allow the same functionality/usability across multiple devices. Our group has performed various fixes to address this concern in the feedback of UAT 1 and 2.
The connection speed of network such as 3G, and Wireless could vary and be quite different, thus causing different results on our HGW application. To ensure full compatibility and to weed out the bug where the application crashes in one(3G) and works fine on the other (WIFI), we had performed a number of test runs on both network to ensure application run smoothly.
Keeping in mind that just having a good user interface is not enough to sell a product, performance is the core of the application. These 2 points will complement each other to make a good application. Through out the project, we have tried our very best to improve the performance of the application via image caching,pre loading of information before the user gets to the screen to ensure a smooth transition.
Project Management hasn't been an easy task, having to deal with a challenging project, client and requirements from IS480. Our group has grown a lot in term of technical or project management aspects since we first started the project.
In our project, a few modules are behind the planned schedule. However, given enough buffer time that we initially set, we managed to complete the core functionality agreed for the release in android market. Below are the summary of all functionality in each iteration.
Team AnythInc's Project Schedule is available for Download
- 1: Project Acceptance 13th August 2010
- 2: Project Mid Term Presentation 29th September
- 3: UAT I 16th October 2010
- 4: UAT II 20th November 2010
- 5: First release to client 22th November 2010
- 6: Final Presentation 25th November 2010
- 7: Second release to client 13th December 2010
1 End of each iteration comes with complete Testing and Debugging (using emulator and mobile device) for every functions.
2 Documentation include Use Case, System Sequence Diagram, Class Diagram is revised at the end of each iteration.
User Acceptance Test
The User Acceptance Test has been carried out via the following methods:
- Face-to-Face (70%)
- MSN Messenger(30%)
For UAT that is done via MSN Messenger, an installation guide and the test-cases document is sent to the participant via email.
Demographic of our UAT Participants
- Gender: Even mix
- Age: Mostly in their 20s
- Technical Knowledge: Uses Android smartphones frequently.
First UAT (6 October 2010 -16 October 2010)
- Call Button
- Report Close Button
Second UAT (5th November 2010 -20th November 2010)
- Call Button
- Report Close Button
- Quick Vote
- Restaurant Gallery
Feedbacks and Action Taken
Changes to Bug Tracking
After the mid-term presentation, the team has come to the understanding that having a bug list that is accessible to everyone for viewing can greatly help in coming out of ideas in solving(overcoming) the bugs. In the past, the team has kept the bug list in an excel that is reviewed every week, now we have chosen to use Google documents for it's great accessibility(because it's in the cloud) to display and keep track of the bugs instead.
Google Docs Bug Tracker
After implementation of the bug list to Google documents, the number of bugs solved has increased greatly.
Updated Class Structure
These following is our individual reflection:
1. What was the objective going into the project?
- To clear the IS480 requirement
- A test to see if we could apply what we've learn in school into a real project
- Gain experience in working in a “real” project that will be used commercially, this will be useful as to get a feel of how things are conducted.
- To learn and share knowledge with team members
All of us had a common interest in the Food and Beverage industry, and hence we were sourcing out for a project related to it. Once we found out that HungryGoWhere was looking to build an android application, we were quite sure that we want to be involved in the project. Given that android is an up and coming phone operating system, there was a shared consensus among our group that we want to learn how to build an android phone application from scratch. Hence, our main objectives were to gain technical knowledge in building android applications, build something useful for our community as well as gain experience working with a real –world client.
The use of mobile technology has become more pervasive, and we were intrigued by how it has deeply entrenched within the society and becoming a way of life. In line with this, the project aims to develop an application that would allow Android users to have immediate access to a list of restaurants that could be sorted or matched against their preferences.
2. What happened during our project?
- Things not proceeding as expected:
What we thought” versus “the real thing”
- Some deadlines were not met due to unforeseen circumstances:
Client’s Requirement Change
Other modules deadline clashes with the project’s
During the course of our project, we had faced several challenges. Firstly, we had to overcome the steep learning curve of android development. The training sessions we had in the initial stages of our schedule were intensive and time- consuming. Moving into our first iteration, the progress was also slow, which led to several delays in our subsequent iterations. We ate into our buffer time; however, it was still insufficient for us to complete our planned iterations on time.
Like most projects, there is a need to align client’s expectations with the project group’s expectations and inter alias, factors that the group has little control over, such as time. At some points of time during the project, expectations have been slightly changed and this put the schedule to some radical change.
3. Why did things happen in the way they did?
- Insufficient planning time/depth
- Overlooked areas like time management
- Too much assumptions and not enough confirmations
Project requirements though firmed at the interception stage, some of it is still in a constant flux like client’s expectations. It is a norm in IT projects for client to change requirements and as such, we were aware of what may come during the project.
The delay in our schedule was a result of over estimation on our part. To be honest, we were over ambitious from the start, and part of the reason was that none of us had prior experience in building an android application; hence the planning of the time taken per module could only be a rough estimation. Unfortunately, we did not foresee it to be such a challenge, and hence faced several delays in our entire project. On the bright side, we have learnt a lot from this experience that we should have sought for professional advice in terms of android development and the expected challenges to be handled. Doing that would put us in a better position to predict risks as well as plan a more accurate schedule for our project.
4. What should happen next time?
- Better planning from the start, such as schedule, technical complex cities of tasks at hand
- While it is not possible to predict at which point in time during the schedule will client change their requirements, our team had set aside buffer time to ensure ample time is given to meet unexpected changes or occurrence. Given the chance to review the teams contingency plans, we will still follow the same approach
5. What should you stop doing?
- Assuming things will get automatically done without anyone assigned to it
- Trying to insist on a fair amount of coding for everyone to do, even when time is not enough. Delegate better programmers to do entire coding would be more time efficient.
- There is a inherent desire to meet client’s expectations regardless of the available time the team has. On hindsight, there should be a better management of the client’s expectations against the team’s capability and for the client to prioritize their wants so as to ensure an optimal outcome could be arrived at.
6. What should you continue doing?
- Reading ahead and trying to plan for what is going to happen (e.g. best and worst case scenario)
- Setting aside a fixed day each week to work on the project and this has been most useful in getting work done as it provides a fixed commitment to the project.
7. What should you start doing?
- Ideas sharing sessions on how we can improve the overall feel for the application, instead of just sticking to the design given at the start. (needs continuous improvements)
- Have more interesting and engaging training materials for learning of the android
- Having more drive in engaging team members in learning the android platform
- To better manage client’s expectations and ensure most of their wants not discussed earlier are met, the team should have meeting with them on a weekly basis so as to have such wants surfaced at the earliest opportunity.
- Never overpromise the client or set unrealistic milestones
- Communication is the key (Cliché! =X). The key take-away in this project is the importance to appreciate others’ opinions and to accept criticism. Needless to say that in a team, everyone has the same goal – to do well for this FYP module and make sure we deliver what we promised to our sponsors. However, the idea of achieving goal differs from individual. A great idea from someone may seem impractical to others. Able to have a heated debate over suggestions might produce interesting consensus rather than to just follow a person’s decision because we all know at the end of the day, we are still friends!
"... To the team credit, they have done a good job in developing HungryGoWhere android version to tap on the new market, we are expecting to release it on the Market Place before Christmas"