HeaderSIS.jpg

IS480 Team wiki: 2010T2 Quantum Final

From IS480
Jump to navigation Jump to search

Project Progress Summary

Our main project wiki page is here.

Overall, our project schedule has largely been on track, and we have been making steady progress.

We finished all picture related functions before the mid term, including register/login, snap picture, edit picture, upload picture, view picture, and add/view comments. Mid-term wiki

After the mid-term, we proceeded with the Google Map-based functions, including map view, map search by term and map search by location. These are completed by 27 Mar 11 (Week 12). In week 13, we had our 2nd UAT as well as our 2nd code optimization and UI enhancements. Currently, the application has been finished and it is ready for deployment.

Iterations after mid-term

After the mid term, we had 2 more developmental iterations to go: Search by distance & search by keyword and 1 more code optimization.

Search by distance

  • This uses the map view built before the mid term.
  • The map view now starts with the user's current location.
  • The distance to the user can be adjusted. Larger distance usually means more pictures displayed.

Search by keyword

  • This search is based on tags and comments uploaded by users.
  • The map view starts with a global view rather than around the user.

Project Highlights:

Ignorant of UI design at planning stage

We did not pay enough attention to UI at the beginning of the project. We just used the simplest UI framework and focused mainly on back-end coding. However, later on after our 1st UAT, we realized that the UI was critical to a consumer application, and we revamped our UI. It took us a lot of effort as we were not familiar with Android's UI framework, and some changes in UI has significant impact on the back-end code.

Sponsor's urgent travel

Our sponsor went on an urgent travel leave 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 web-service development in iteration 2 was delayed by 2 days. We re-scheduled our iterations as a result so that we could build the functions which did not require web-services first.

Sponsor's domain name expired

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

Remote development, deploying and debugging

We were 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 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 1st UAT was regarding our UI design. The feedback included poor user experience, inconvenient layouts, weird connections between pages, etc. In addition, we also felt that some back-end code required further optimization. For example: Minimizing the size of data transmitted through web-services, as well as redundant variables/methods/objects in order to reduce processing time.

In our original plan, we had 2 development iterations after the mid-term review for the search functions which were supposed to take 6 weeks altogether, and 1 week at the end of the project to do all the UI enhancements and code optimizations. However, because of our development experience gained through the first 7 weeks of development, together with the UAT feedback, we felt that it was necessary to add an optimization iteration after the mid-term review. This was also because we felt that could actually finish the search iterations in 4 weeks instead of 6.

The following table reflects the change in our schedule:
Midtermreschedule.png

Project Management

Project Highlights

Midtermschedule.png

Project Schedule (Planned Vs Actual)

Most things had gone according to plan (with the exception of the unforeseen delays). Generally, everyone learnt a lot from the project (both technically and management wise), and was very comfortable with the pace of the development cycles.

Status.png

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

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.

Metric.png

So far, our team has proved to be quite technically competent, and there were not any outstanding technical issues.

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

Use Cases

Here.

Meeting Minutes

Here.

Storyboard

Here.

Sequence Diagram

Please view the attached: Media:Sequence_Diagram.pptx

Class Diagram

Midtermusecasediagram.png

Deployment Diagram:

Architecture.png

Testing:

We conducted 2 UATs, on 10 Feb 2011 and 31 Mar 2011.

UAT 1

We ran 15 user tests on 10 Feb 2011 for UAT 1. Most of the results have to do 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

[Here].

Test Results

[Here].

UAT 2

We ran 15 user tests on 31 Mar 2011 for UAT 2. Based on the feedback we have, one major thing we found is that: users want more functions. The current functions is doing well as a picture processing & map tracking tool however users want a more complicated user profiles with added interactions. This gives suggestions on the future extension of the application.

Test Cases

[Here].

Test Results

[Here].

Reflection

Qiao Yang Reflection:

After Mid Term

  • UI design is an important component for an light user targeted application. It directly determines whether your app is attractive
  • UI should be carefully considered at the planning stage, as later changes may significantly affect the back-end code

Before Mid Term

  • 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:

After Mid-term


Before Mid-term

  • 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:

Before mid term

  • 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.