HeaderSIS.jpg

IS480 Team wiki: 2012T1 dot-3ga/midterm

From IS480
Jump to navigation Jump to search
Our Project   Project Overview   Project Management   Mid-Term Progress   User Testing   Minutes   GamePlay   About Us  


Project Progress Summary

Midterm slides link:

Our project started in June and has a total of 7 iterations and we are glad to inform you that our game application has been deployed onto the Android Play Store. Currently, we have just ended our third iteration and will soon move onto our fourth iteration. Through the 3 iterations, we have accomplished the following functions:

  • Facebook Login and sharing
  • Emailer register and login
  • Playing with random players and friends
  • Sending of recorded clues
  • Storing game state
  • Scoring
  • Create your own word

The remaining functionalities will be finished with the following iterations. We have also completed our beta testing and our first user testing. We have schedule our second user testing on the 25 October, following a public user testing in November.

The project has been rather smooth sailing for our team. We have not had any much of a problem in terms of project management or the application itself. We faced a bit of difficulty it gathering people for UT testing as all other groups were fighting for the same students but we managed to overcome it by asking close friends and scheduling it over a few days. We are 100% confident that we can cross the finish line for this FYP. We know that it is only the midway point but we can push through and come up with an excellent final product.

Project Highlights:


*Launched app on Google Playstore on the 27th of November
*App is now integrated with facebook
*UT 2 was conducted on 23rd of Nov and we made a lot of cosmetic changes. UI has been through many rounds of changes

1. Change in Project

Our initial plan for a client was switched due to the static nature of the task. Instead, we opt to do our own project which was to build a game application on the android platform. Fortunately, the game was made very early and we did not lose time or resources on it. With regards to our application, we are glad that we made that change as we are able to construct something which we can define and create from scratch.

2. Change in Schedule

Before our acceptance, our project was scheduled to have 4 iterations. However, after advised to do otherwise, we have increased our iterations to 7. It is beneficial as we are now able to track our progress easier and with more details. Moreover, it has allowed us to be vigilant in knowing if we are lagging behind. Also, we have pushed more functional requirements to earlier iterations so as to ensure that we are not overloaded in the back iterations. Overall, the functional requirements have been spread more equally through the 7 iterations.

Project Management

We originally started with 4 iterations. After some consideration and with some advice from Prof Ben Gan and our supervisor, we changed our schedule to make it suitable for 7 iterations. To view our entire Schedule and what is in each iteration. click here: Project Management

Project Status:

It2and3functions.JPG

Project Schedule (Plan Vs Actual):

The project plan has very much changed since acceptance. 3 more iterations were scheduled but the tasks that we set out to do are the same. Since acceptance, 2 iterations have passed(below). We have been on schedule. However, we did eat into 2 days of buffer time which was fine as that is what buffer time is for.

Timelineschedlu.JPG Legendlu.JPG

Project Metrics:

Bug Metric

Bug Metric

Schedule Metric

Schedule Metric

Work Load Metric

Work Load Metric

Project Risks (Top 3):

Update the proposal assumptions and risks. Describe what you learn from the risk update and mitigation steps taken.

Risk Probability Impact Mitigation
Game concept might not be well received by the general public High High *An additional User Testing on 25th October
*Public User Testing in November
Sponsor deployment machine approval and support High Medium (now it is low) Use UPL machine

Be sure to prioritize the risks.

Technical Complexity:

Integrating new function (facebook login ) to old login method

- We didn’t start of by enabling Facebook login, therefore we have to modify major part of our initial login method to integrate with the new Facebook login. The integration need to be able to maintain the records of the old login credential and stored data, as well as making sure that users are able to change to Facebook login with any problems.


Keep track of user game state, ( Guessing, Recording, Choosing word )

- As our application doesn’t require the users to maintain an internet connection with our server, we have to ensure we keep a record of their game state, so that users could resume back to their game whenever they want. We also trying to avoid the number of interaction and connection of the client and server to reduce hogging of bandwidth and affecting our game play ( Due to slow 3G connection ). Therefore to achieve the game state, we have to look at their last activity and interaction with our server. From there we derive the game state they are in.


Limitations of API to perform network activity - have to perform background tasks for network activity

Controlling of activities within android platforms - possibility of leakages of resources in between activity passing

Ensuring layouts fit most devices - by using Samsung S2 as a benchmark for layout positioning

Quality of Product

Provide more details about the quality of your work. For example, you designed a flexible configurable system using XML.config files, uses Strategy Design Pattern to allow plugging in different strategy, implement a regular expression parser to map a flexible formula editor, etc.

Intermediate Deliverables:

Stage Specification Modules
Project Management Minutes Minutes Documentation
Metrics Project Management
Requirements Story cards Story Cards
Analysis Use case Use Case
Testing User Testing User Testing Details


Deployment:

Our application is avalible in Google play store as well as our website listenup.net . If you have an android device, you could download and install it through the google play store application in your mobile android device. Once you have installed our application, you will be able to enjoy our game.

Note : You need a Android device version 2.3.3 and above in order to enjoy our game application

Testing Plan

This test plan is a step-by-step approach to how we are going to test the various functionalities of our project. The testing will be done for 6 different test cases that are based on our use cases. Testing our program ranges from basic functionalities to minor details to ensure that we have a functional project running and minimize the amount of bugs present and most likely being introduced in the future iterations.

Assumptions

Our test cases cover all aspects of the project requirements. If it is a pass, we assume that it is a working functionality after it is tested once. However, any future changes to the code might render a test case that previously passed a fail. Hence, we would need to do a final test when the code is completed to ensure that our test cases are working and that there are minimal or no bugs present.

List of Test Cases

List of Features to be Tested

  • Basic Functionalities
  • Bug Testing
  • Additional Functionalities

Approach

We have a standard template for our test cases.

  • Test Case ID: Unique identifier
  • Description: Description of the functionality that we are testing
  • Prerequisite: Steps that you must do prior to testing the functionality
  • Expected Result: What we are expecting to happen
  • Actual Results: What actually happened
  • Pass/Fail: Whether our program passed or the failed the testing

Testing will be done after the deployment in the Google PlayStore as it is the platform users are going to download from.

Risk

The results for the various test cases might not be definitive as we add on more features into the code. An example is adding an additional feature which render our basic functionality buggy or not working. Hence, if the additional feature is causing more harm by rendering more than 30% of our test cases void, we might not, on the project manager's final decision want to implement the extra feature but instead ensure that our core features are 100% working first.

If the additional feature is rendering less than 30% of our code void, it will be our team’s regression to decide the outcome during the weekly team meeting.

A test case might work once, but not guarantee to work on the second test. Thus, after we have done the finalized version of the code, we will stress test to ensure that it always works.

Test Case ID Description Prerequisite Expected Results Actual Results Pass/Fail

Scheduling

Testing will be done after every iteration. This will ensure that the integrity of the code is not being compromised before moving on to the next iteration. If a bug is found, it will be logged in the bug log. If the team decides to resolve the bug, the project manager will have to modify the schedule accordingly.

Reflection

Team Reflection:

Lessons Learnt

While constructing an application on the android platform, we faced many initial obstructions. Through the technical side, we had to learn how to work with new tools such as the Android Developer Console, an external web server as well as Eclipse with android development tool plug-in. While working with the Android Developer Console, it was initially very complicated to maneuver through functionalities. There were initial difficulties while organizing the files and it was likewise while dealing with an external web server (Vodien) as it was the first time for most of the member. Fortunately, it was quickly abated after subsequent uses. The construction of the user interfaced required skills in Photoshop along with the designs integration through Eclipse. The various graphics includes backgrounds, button, headers, layout and various others. The user interface also included audio sounds of the recorded clues as well as for the various buttons.

Takeaway Thus Far

Through this project, we saw that passion toward our application really carries it far. Despite our hectic schedule and various commitments, constructing this application that we could call our own has been enjoyable and fulfilling. Unlike other groups, our team came together without knowing each other beforehand. Initially there were a few conflicts and miscommunication. Through the weeks of working together we were able to understand each other’s working style, strength and weaknesses. We were then able to assign task efficiently and accurately.

Individual Reflection:

Member Reflection
Ban Chuan I feel that this FYP journey is tough yet satisfying and fulfilling as we started off with nothing and today we have our very own application available to users all over the world to enjoy on the Google play Store and our very own website. Being the client-side coder of the team, my role isn't just about coding according to requirements but instead i have to work closely and constantly with bang chuan for server interaction, lin yi for UI development and sandesh and kenneth for feedback and comments on the looks and feel of our application. Without any prior knowledge of mobile application development and android operating system development, i am fortunate to have online forums where users share their experiences and guidance to aid in my development process. I look forward to bringing our application to a greater height with all my team members and hopefully make a name for ourselves in the Google Play Store.
Bang Chuan (Avan) Having halfway through our Final Year Project, I realize the importance of time management. Having lot of other commitment like other modules, work, etc, I have to plan my time wisely to avoid delay of any work given to me. Maintaining good relationship with my boss, and teammates is also my strategy in managing my workload, as they could let me have more allowance in time to complete the given tasks.
Lin Yi Overall it has been a very fulfilling and learning experience thus far. There were a lot of things that were new to all of us and I think everyone was initially very apprehensive. Building an application on the android platform is the first for all of us. I still remember how this whole project was just an idea which I put forth, but now, this application contains snippets from every single member. It has become a collaboration of ideas from all five of us, improving steadying and surely! Through designing for the user interface, I initially met with a few road blocks and could not find the right maneuvers. Thankfully my team mates were encouraging while I figured things out. Through various edition of the design, it progressed quickly to how it is currently and while continue to improve in usability and visuals.
Kenneth FYP is the only module in my opinion where you are able to contribute to your maximum capacity. Frankly, I am not a strong coder so I do not do the coding but I am able to contribute to PM and Wiki page which for FYP, constitutes and demands a high amount of workload contribution. Also, it is the only module that requires constant interaction and updates from all other members like we do for our weekly update meetings. Lastly, the whole purpose of FYP is to teach you to work smart, not hard. No matter how much effort you put into the back end or PM, you will eventually be judged by your project scope and outcome. I love my team that was put together by a former member but he left due to other commitments. We went by faith and continued with a 5-man team. Although we almost disbanded the team during the summer due to a conflict in workload initiatives, not only have we talked through and solved it, we are even more motivated than before. Even if you were to offer me a replacement team of 5 A+ coders/students and I dont have to contribute anything but get the grade, I will not exchange it for my current team because I love them and enjoy the hardships we go through together. This cannot be bought or traded. From strangers to best of friends!