IS480 Team wiki: 2010T2 Quantum MidTerm

From IS480
Jump to navigation Jump to search

Project Progress Summary

Our main project wiki page is here.

Overall, our project is proceeding as planned. All picture-based functions are finished, including register/login, snap picture, edit picture, upload picture, view picture, add/view comments, etc. These constitute 50% of project. Nearby picture is also done, which constitute another 10% of the project. So overall, about 60% has been completed by the mid term review.

In terms of iterations, we have finished 3 out of 5 development iterations. We have 7 iterations in total, of which 2 are "optimization" iterations, during which we will review existing functions and then make code optimization and UI enhancements.

We are done with our first UAT, and after reviewing the feedback, we are ready to move into iteration 4, which is our first optimization iteration.

Project Highlights:

Sponsor's urgent travel

Sponsor went on an urgent travel for 3 weeks just before our 2nd iteration and we had not gotten access to his server at that time. As a result, our progress in webservice construction in iteration 2 was delayed by 2 days.

Sponsor's domain name expired

On the 4th of February, our sponsor's domain name expired, which led to a delay in our developing and testing of iteration 3.

Remote development & deploying makes debugging

We are publishing the server side solution remotely; at the same time, we cannot affect the operation of the sponsor's website. This sometimes makes debugging much more troublesome than on the local development because some server side bug logs cannot be viewed directly.
We spent much more time and effort than expected because of this issue.

Project reschedule after our first UAT

Most feedback in our UAT are regarding our UI design. Comments including poor user experience, inconvenient layout, weird connection between pages, etc.
In addition, we feel that some back-end code requires further optimization, for example: minimize data size transmitted through web service, minimize redundancy variable/method/objects, reduce processing time, etc.

In our original plan, we have 2 development iterations after mid-term review for the searching functions which takes 6 weeks, and leave one week at the end of the project to do all the UI enhancement and code optimization. However, according to our development experience gained through the first 7 weeks, together with the UAT feedback, we feel it is necessary to add a 1st optimization iteration after mid-term review and we can actually finish the searching iterations in 4 weeks.

The following table reflects the change in our schedule:

Project Management

We reached the limit of our school's free, provided SVN server (40 commits). Currently, we are using Dropbox to share our code.

Our next iteration should start on 14th February (right after or mid-term review). We will be mainly focusing on reviewing our existing code in order to for:

  • Code optimization: Minimizing the data size transferred through web services, as well as minimizing the duplication and overlap of functions & variables.
  • UI enhancements: Make our UI more intuitive and colorful in order to give the best possible user experience.

Project Status:


Project Schedule (Planned Vs Actual):

Most things have been going according to plan (with the exception of the unforeseen delay). Generally, everyone is learning a lot from this project, and is very comfortable with the current pace fo the development cycles.


To view the detailed schedule, please view our gantt chart.

Delay tracking:


Project Metrics:

We measure n, where n is number of bugs divided by lines of code.

  • The bugs here are "meaningful bugs", which are bugs that resulted from wrong algorithms/data types/class designs/connections, etc. Insignificant bugs such as typos were not included.
  • Lines of code includes Android code, server side C# code, SQL scripts, Android XML configuration code, etc. So the number is just a rough sum rather than an exact figure.

If n < 5%, we are doing good.

If 15% > n >5%, we need to perform a code review.

If n > 15%, we need to redesign our model.


So far, our team has proved to be quite technically competent.

Project Risks:

As mentioned earlier, we did not actually encounter the risks that we planned for. Instead, our biggest challenge was overcoming the 3 weeks of sudden absence of our sponsor. To recap our risks:

  • Lack of technical expertise.
    • Reality: It turned out that most of us are competent in programming, and our history with Java really helped a lot. Furthermore, all the Android API documentation is extremely solid. We are very confident that this will not pose any problem.
  • Unable to get Android devices for test & debugging.
    • Reality: It also turned out that our sponsor could loaned us an Android device, so with 3 different devices in a team of 4, this did not pose any problem.
  • Exceeding development cycle.
    • Reality: This happened, but again, it was due to totally unforeseen circumstances. But still, because we could adapt quickly, we were able to shuffle our schedule and work on independent features first.

Result: An overall 3-4 day delay.

  • Requirement changes.
    • Reality: As it turned out, we really did have have many sponsor meetings. Each time, we would go over our progress, and what we were going to work on next. So far this has not been a problem.

Technical Complexity:

The technical complexity of our project lies not in its depth, but in its breadth. In fact, the 'deepest' technology we go into is the Android API, which is where the bulk of development is happening. The most challenging part part about Android, and smartphone programming in general, is that although the phone is also a computer (has CPU, RAM, processor, etc), the paradigm is fundamentally different:

  • The user approaches a phone application differently (using touch, as opposed to a mouse). You have to assume speed (as opposed to long waiting times) and interactivity (as opposed to just starting at the screen).
  • The phone has functions a PC does not have (GPS location tracking, mobility, touch interfaces such as pinch to zoom). Therefore, to maximise the use experience, you have to incorporate all these fundamental phone abilities.
  • The phone has different limitations from a PC.
    • Limited RAM (512Mb at most). You have to assume that the user or the OS will force close your application from time to time, which means your application data will have to be saved constantly. You also cannot do things which require huge memory, which means you always have to make your code as efficient as possible. E.g. the less variables you declare the better.
    • Limited processing power. You do not want your phone performing many big computations, or many algorithms.
    • Limited connectivity. You do not want to choke the phone's bandwidth by needlessly downloading content that he may not be interested in.

As mentioned before, we are working with at least 4 different technologies:

  • Android API
  • C#.Net Web Services
  • Google Map API

The real challenge for us is in picking up the very different APIs quickly, and being able to implement them. This usually means running the HelloWorld tutorial for the technology, and reading tutorial guides as fast as possible in order to understand the APIs, capabilities, and limitations.

Quality of product

Meeting Minutes




Use Cases

Sequence Diagram

Please view the attached: Media:Sequence_Diagram.pptx

Class Diagram


Deployment Diagram:



We ran 15 user tests on 10 Feb 2011. Most of the results have to with UI and layouts. 2 very good suggestions were to:

  • A convenient 'Share' button.
  • A gallery thumbnails view.

We will be implementing both these features in future iterations.

Test Cases


Test Results



Qiao Yang Reflection:

  • Technology is changing fast, but the underlying concepts hardly change. Android is a new toy, however the underlying technology is just JAVA and the designing concepts are still OO and MVC.
  • Better to have some real experience before using the technology to build something, otherwise it is highly likely that there will be misunderstanding of the technology hence leads to bugs and delay.
  • Some technical points:
    • Web service is the best way for android to connect to remote server.
    • Web service is for generic data type transmission, such as string, Boolean, int, float. So when designing application with web service, so for our own convenience, try to limit the communication to the above types. There are ways to pass complex object with web service, here is an example: How to pass complex object through web service in android

Tang Bin Reflection:

  • Understanding the programming concept is much more important than knowing all the detail methods. Android, as a new programming language is also based on OO concept. I really appreciate the all the OO concept we learned in year 1&2. However the different part between Android and Java is that Android has its own way to design UI which are all the layout and views. Designing Android UI is bit tedious as it has its own rules. E.g can’t put listview inside scrollview.
  • Better Time management is another thing i harvested.

Sherman Reflection:

  • Planning is necessary, but because a lot of variables depend on outside factors (sponsor, each other's schedules, mid-term review, deadlines), it is more important to be agile and adaptable.
  • Don't put all your eggs in 1 basket; don't overly depend on anyone (sponsor, a member, client, etc). Instead, spread your dependencies out so you won't be easily crippled in case something unexpected happens.
  • In our case, we had some functionalities which did not require access to the sponsor's server and database, so we could work on those first.

Carol Reflection:

  • Project management is very important in an IT project.
  • Time is of an essence – project management keeps us on track of finishing our deliverables on time.
  • Conducting a User Acceptance Test (UAT) enabled us to notice things that might have missed out on aesthetics, functionality and usability. We can further improve our application based on the feedback comments received.