HeaderSIS.jpg

IS480 Team wiki: 2010T2 Quantum

From IS480
Jump to navigation Jump to search

Logo.JPG

1. Team Overview

1.1 Roles & Responsibility

Name Responsibility
Chua Sherman Glenn Product Manager
Qiao Yang Lead Developer
Tang Bin Developer
Carol Then System Tester

2. Project Overview

2.1 Project Overview

The aim of this project is to build an Android application for wackotopia.com. Wackotopia.com is a website that hosts funny pictures from different parts of the world. It aims to attract as many visitors as possible and also become the go-to site for the funniest, wackiest, and weirdest images on the internet so that when people can see some funny images and jokes, read the comment, and have a good laugh when they are bored.


2.2 Project Description

The biggest feature of the application is its ability to automatically resize images for better display. As of now, most picture applications simply take a picture wholesale from the web and display it on a mobile phone. This results in low resolution, large pictures (which users have to zoom out to view, resulting in loss of image quality), or high-resolution but small images (which users have to zoom in to view).


2.3 Motivation

Our group is particularly interested in building mobile applications, since they are commonly referred to as the next paradigm in computing. Many people believe and predict that Smartphone sales will surpass PC sales by 2011. As such, learning the emerging technologies will prove extremely useful for us.


2.4 Stakeholders

Clients:

  • Users of wackotopia who also use a Smartphone. Those who use their Smartphones to surf the web and view pictures will find this a welcome application, since it is a native application and it can incorporate more native functionalities (such as swiping sideways for the next picture).
  • Advertisers who could use this application to place text and banner advertisements.

Sponsor:

  • Intellectio, the owner of www.wackotopia.com.
  • Our contact is Mr Abhijit, the founder of the site.


2.5 Objectives

Outcomes: An Android application that will be deployed on the Android Marketplace that runs on all Android Smartphones. Value Statement: Increased reach of wackotopia.com and user volume.


2.6 Scope

Functions: Login/logout/register, shoot, view, share and upload pictures, add tagline to pictures, view and give comments and likes, display advertisements, maps visualization.


2.7 X-factor

We will build a function where the user can add text to a picture and save it as a new picture. This is quite different from other picture applications where users cannot add taglines to pictures, merely view them. By allowing users to add text to a picture, the ‘funny-ness’ of the picture can potentially be increased. This is similar to current ‘demotivational’ pictures, where each picture comes with a title and tagline.

Also, we will build a tagging system into the application, where the user can search for funny pictures either by location or tags. This is similar to the ‘Now Trending’ functionality in Twitter. This helps the user find the most recent or specific types of pictures quickly. This also helps promote contextual pictures, for example, if the user is in London, he could just search for funny pictures taken in London.

Lastly, we will also build a map visualization that displays all the funny pictures as pins and thumbnails on a Google Map. This is to help the sponsor get advertisers by showing how people from various places around the world submit pictures, as well as let users get a quick look at pictures from all over the world.

E.g.

      WithoutT.png    to    WithT.png

3. Project Management

3.1 Use Case Diagram

Use Cases.png


3.2 Process Diagram

Process Diagram.png


3.3 Roles and Responsibilities

Product Manager: Sherman Chua

  • Keep track of project’s progress and help resolve conflicts.
  • Keep track of project’s scope.
  • Allocate resources dynamically within the project.

Developers: Tang Bin, Qiao Yang

  • Determine suitable technologies and systems to use for development.
  • Determine suitable methodologies to adopt for project.
  • Plan project development and infrastructure.
  • Develop the application.

Tester: Carol Then

  • Develop test and use cases.
  • Develop UAT (User Acceptance Tests) and SIT (System Integration Tests).
  • Ensure that project’s usability and functionalities meet sponsor’s standards.


3.4 Assumptions

We assume that the sponsor already has most of the back-end infrastructure (databases, working web application) set up, so our team will be focused on building an Android application that is integrated with the backend systems. If need be, we will build more functionalities and web services to interact with the sponsor’s back-end infrastructure.

Being Android, we also do not need special hardware to develop the application; any normal laptop will do.


3.5 Resources and references

Our team is allocating 2 weeks to gear up for this project as preparation. Furthermore, the sponsor has also kindly agreed to provide any references and resources that we may need in terms of books, computers, or testing devices

4. Project Schedule

Our project schedule can be found here.


5. Risk

We recognise that our project will contain certain unavoidable risks. Rather than try to remove them totally, we instead endeavour to either efficiently reduce their likelihood of occuring, or to mitigate their impact by having backup plans in place.

  1. Lack of technical expertise.
    • Problems:
      • Most of us do not have prior experience working with Android, or the Android SDK.
      • There are new APIs to learn, new paradigms to work with, and new environments and constraints to work within.
      • Code becomes inefficient, resulting in unresponsive application or interfaces (requiring too much memory or CPU cycles).
      • Risk1.png
    • Mitigating factors:
      • Android is mainly a high-level programming environment which utilises the Java syntax, and since the developers will probably not be exposed to low-level system/functionality code, programming should not be a huge issue.
      • We have allocated 1 week for an Android crash course to get started with the tools and environment. Also, since Android is open-sourced, in the very unlikely scenario where we really need to look into the operating system code to see how it really works, we can.
      • We have multiple client meetings scheduled after each iterative development cycle. This is so that the client can test the new functionalites and give immediate feedback. Should improvements be required, there is a 2-week buffer (weeks 12 & 13) to improve code quality to improve performance. There is also a general buffer week (week 14) in case more enhancements are required.
  1. Unable to get Android devices for test & debugging.
    • Problem:
      • We need live devices to properly perform our test cases. Testing in a emulator is not sufficient, since an emulator uses a mouse to click, whereas on a live device, the main input is touch.
      • Android comes on a variety of hardware; getting more than 1 live device may prove to be a problem.
      • Risk2.png
    • Mitigation strategy:
      • So far, we have 2 different live devices (with differing technical specifications) to perform debugging and testing on.
      • We will continually source for ways to get live devices for development purposes, whether through the sponsor or through other means.
  1. Exceeding development cycle.
    • Problem:
      • Due to any unforseen circumstances, we may exceed the time allocated to each development cycle.
      • This can be due to the previous risk (lack of technical expertise), or factors such as laptops crashing, unable to meet sponsor to sign off, etc.
      • Risk3.png
    • Mitigation strategy:
      • If we exceed the time allocated to each development cycle, we will push the entire schedule backwards as required.
      • We have 2-3 weeks buffer period, so this will help mitigate the risk.
  1. Requirement changes.
    • Problem:
      • The sponsor may want to change features or functionalities halfway through the project.
      • We ourselves may want to change (add, remove) certain functionalities to improve the overall product.
      • Risk4.png
    • Mitigation strategy:
      • We have multiple client meetings scheduled after each iterative development cycle. This is so that even if the client has a requirement change, we can know about it as early as possible, so as not to disrupt our development cycle.
      • We are adopting an iterative development approach. This helps us test and re-test each new functionality with existing ones, so if there are any changes required, we can know about it early. If we go with the waterfall approach, we may only know about required changes in the later (testing) phase, which may be too late.
      • We also have a 2-3 week buffer period, to handle any unforseen change requirements.

6. Bug Metric

This metric is for tracking bugs in our code. The aim of this is to reduce the number and impact of bugs, and to improve the overall code quality.

In order to track bugs, we have come up with a metric that measures the impact of a bug by looking at its severity (how much does this bug affect the product?) and its likelihood (how likely is this bug to occur?). By taking both factors into consideration, we can quickly prioritise bugs and fix the major ones first.

      BugMetric.png

We also classify bugs into the various types, depending on where it happens:

  • User experience/experience
    • Long waiting times
    • Application hanging
    • Difficult to navigate the application
    • Too many steps required to perform desired action
    • Username not displaying properly
  • Logic
    • Not displaying the correct picture
    • Login/logout not working properly as intended
  • Back-end
    • Web-servies not working as intended
    • Web-services/database performing too slowly
    • Map visualization not displaying properly