Difference between revisions of "IS480 Team wiki: 2011T1 Motiva"

From IS480
Jump to navigation Jump to search
Line 801: Line 801:
===Team Reflection===
===Team Reflection===
*To be filled
Refer to Final Wiki

Revision as of 13:12, 25 November 2011



Team Members


Name Role
Tay Hui Juan Project Manager
Ong Wee Chian Assistant Project Manager & UAT Administrator
Chong Liang Jin Eugene Lead Developer
Ting Wen Zhong Technical lead & Creative Designer
Ong Shin Jie Daniel Business Analyst & Communication Director

Click here for role description.

Motiva Final Wiki

Motiva Mid Term Wiki

Project Scope

Project Description

Buy One Give One is a not-for-profit organization which provides systems and structure to inspire the community about a world full of giving. Buy1Give1 is currently registered and headquartered in Singapore. B1G1 currently works with businesses in 15 countries. Through B1G1, these businesses now support close to 700 projects in 29 countries.

To make giving part of one's lifestyle and to move away from the normal guilt-driven or event-driven fund raising, B1G1 uses a transactional based business model. As such, businesses and individuals can continuously contribute to various projects which does NOT focus on the funds donated but on the IMPACT created. The current B1G1 online portal serves as a platform for businesses to enroll in these programs. As a result of this most recent IS480 project, B1G1 is now moving its focus from SMEs towards attracting more personal users. This movement is the ‘Design Your Giving Life’ initiative.

Objective of project

  • Encourage people to see giving as part of their lives
  • Create convenience for current users
  • Create an impact on those in need


Organisation Name Position
Buy One Give One Masami Sato Founder, Director
Buy One Give One Paul Dunn Chairman


User Management

New and existing users will be able to create a new contributor account at B1G1. All user information is linked to the B1G1 customer database; any activity done through the web and iPhone application will be automatically synced. The account management tool allows users to manage their account such as login, logout and registering of their accounts.

Project Listing Management

All funding projects are listed by different lifestyles (Eg. dining, shopping, etc) or pre-defined categories (Eg. Country, organization, types of targeted beneficiaries such as education, health and welfare, environment and so on — broadly in line with the UN Millennium development goals).

Contribution Management

A major (and new) key of the application is user-personalisation. We aim to create ‘Lifestyle activities’ to allow users to link giving to personally defined lifestyles (Example of such could be weight loss, gym attendance or even kissing a spouse!). It means that users can create fun challenges and link them directly to giving.

Once a lifestyle activity is selected, users can link it to specific projects through a scrollable view.

This feature serves as the central management for all contributions by B1G1 users. Users will also be able to make payment for all selected projects. Information such as the lifestyle activity description (e.g. for every coffee purchased), the project you embarked on and the amount to donate will be automatically saved in user’s preset profile. This module will trigger an update to the achievement module and the live feeds on his/her profile. When a user initializes a contribution, he/she will be able to check out to the payment module. Upon successful payment, the information stated on the presets will be tagged together with the project details, to be shared on Facebook.

Connectivity & Engagement

Our team plans to utilize the location-based elements, already built in the current B1G1 platform, to allow individual users to locate and shop with business users. Information from the App can also be used as a resource to share across social networking sites such as Facebook and Twitter with the help simple APIs. For each contribution, users tag photos with information gathered from the lifestyle activity and related project details. These data will be updated into a database and all users from the B1G1 Facebook group would be able to view these information as wall feeds. User may also choose to post it on their personal walls as well. In addition, we will also design a new web-based dashboard to keep track of real-time contributions and activities from B1G1 users worldwide.

Achievement Management

User achievements are directly related to the number of projects they have helped and the impact made. Medals and Trophy will be awarded to users based on the pre-determined levels. User may view all their contribution histories. For the application to have more interactivity with the users and to include more challenging factors, there will be different numbers of achievements for users to attain.


With the iPhone Application:

  • Users can manage their account. (Eg. login, logout and register)
  • Users can view projects in categories and information on each project.
  • Users can make donation for a specific project.
  • Users can define their donating lifestyle.
  • Users can make donation through a donating lifestyle preset and share their contributions on Facebook.
  • Users can view their past contributions and impact made.

With Donation Dashboard on B1G1 Website:

  • Users can view all donation activities of other users.
  • Users can view the impact on the projects.


  • Application to be deployed to iPhone & Apple App Store.
  • Dashboard webpage to be deployed to B1G1 website.


  • Launch of application to Apple App Store
  • Revolutionary style of donating

Project Documentation

Application Architecture Diagram

Use Case

Sequence Diagram

Navigation Flow


User Interface (UI)

Schema Diagram

ERD Diagram

iOS Human Interface Guidelines

Project Management


Scope Management

Scope management is one that plays a crucial part in project management. Managing the scope well would prevent the team from doing unnecessary rework. It allows us to plan ahead and to prevent breakdowns if there are scope changes. Drawing out the scope would enable everyone to have a clear picture of project and gets work done more efficiently. We have to know what is to be built before building it.

Scope Management Process


I. Collect Requirements

We collected requirements through interviews with the client and through brainstorming.


II. Define Scope

Click here to view our project scope.

Click here to view our project deliverables.

III. Create Work Breakdown Structure (WBS)

Work Breakdown Structure (WBS) - Abstract:


IV. Control Scope

There are bound to be changes in the scope during the course of the project. We are unable to predict when will a change occur. As such, we would adopt the following process if a change needs to happen.


Date Scope Change Document Remark
16th Jul 2011 Scope Change 01 Web service
16th Sep 2011 Scope Change 02 $1 admin charge
03rd Oct 2011 Scope Change 03 Revamp UI after client feedback
03rd Oct 2011 Scope Change 04 To include credit card for PayPal payment
03rd Oct 2011 Scope Change 05 Presetting of donation amount
03rd Oct 2011 Scope Change 06 Pre-defined lifestyle editable
05th Oct 2011 Scope Change 07 Registration page to include name and country

V. Verify Scope

To verify the scope, we have to compare the deliverables with the project requirements. This is crucial to ensure that the project does meet the requirements. This will be done before the UAT where the client evaluates our deliverables.


Time Management

To ensure that work is done and deadlines are met, time management is important. In order to prevent overruns and inefficiency in our course of project, we made use of a project schedule. The project schedule is important in helping us plan ahead and estimate the amount of time we have for each function. Proper time management would be a key to success.


Process Description Actions to be taken
Define Activities Adopted the decomposition technique by further breaking down the core functions into tasks
Sequence Activites Determine the precedence of each tasks by numbering the sequence of each task
Estimate Activity Resources Discussion as a team
Estimate Activity Duration Discussion as a team
Develop Schedule Draw up schedule and timeline with milestones indicated
Control Schedule Adopt a schedule metric to determine whether we are Early/On-time/Late

Project Schedule/Timeline

Click here to view the detailed project schedule.

Schedule Metric

The schedule metric serves as an indicator of how late/early we are in our schedule. The metric helps us determine our next approach if our schedule were to be too late or too early.

The Schedule Performance Index (SPI) will be calculated by the Project Manager after each iteration. After which, depending on the value of the SPI, the Project Manager will take the necessary actions to ensure that the team is back on track. Planned End Date refers to the end date stated in the project schedule. Actual End Date refers to the date the specific task is completed.


Schedule Performance Index (SPI) = Actual End Date - Planned End Date

SPI Action Plan
SPI < -1 Consider addtion of functions or improve user experience.
-1 <= SPI <= 1 On Time. Keep up this SPI.
1 < SPI < 4 May use allocated buffer time. Project Manager to adjust project schedule accordingly where necessary.
3 < SPI < 7 Find out the reason for lateness. Project Manager to adjust project schedule accordingly where necessary. May consider allocating available resources to ease bottleneck.
SPI >= 7 Find out the reason for lateness. Project Manager to adjust project schedule accordingly where necessary. Last resort to consider dropping functions.

Quality Management

It is important that we understand the quality expectations of the client. As such, we manage the quality of our project by settings goals and taking measurements.


Process Description Actions to be taken
Plan Quality Set goals (Eg. Number of bugs, bug metric), Test cases
Perform Quality Control Constant testing after each iteration, Track bugs using Bug Metric
Perform Quality Assurance Obtain feedback from UAT and Client Evaluation

Bug Metric

The bug metric serves as an indicator of the number of defects in the application. The number of bug points allows us to determine the next step to take according to our action plan.

A bug is to be recorded each time the developer commits a code. Bugs detected during a development session would not be counted. Each bug will be classified into 3 different levels of severity. Bugs of the same severity level will be added and multiplied by the corresponding severity point. The summation of the severity points will be calculated at the end of each iteration.


Bug points = Σ(No. of bugs with same Severity Level X Severity Points)

Serverity Level Severity Point(s) Description
Low 1 Typo error or user interface bugs. Standalone bugs that do not affect other parts of the same function.
Moderate 7 Application runs and does not crash. However, some non-critical functionalities are not working.
Critical 14 Critical functionalities not working properly. Application is down and crashes. Affects the progression of the next iteration.

Bug Points Action Plan
Bug Points =< 7 Fix bug during the next development session.
7 < Bug Points < 14 Isolate the functionality where the bug exists while development on other functionalities continues. Make use the planned debugging time.
Bug Points >= 14 Stop current development and resolve the bug immediately. Make use of planned buffer time. Project Manager reschedules the project when necessary.

View the latest bug log.


The team has set a goal of achieving less than 10 severity points from each testing. This is to ensure that we deliver quality functionality to our clients and at the same time, improving our programming skills.

User Acceptance Test (UAT)

User Acceptance Test Documents
Date: 21st - 22nd Sept 2011
UAT guide
1st UAT Test Plan
Registration form for UAT 1
Date: 27th - 28th Oct 2011
2nd UAT guide
2nd UAT Test Plan
Registration form for UAT 2

UAT 1 Result

A total of 58 testers participated in our first UAT.
5 bugs were found during the UAT and they were logged with our bug metric.
Refer to here.

At the end of the testing, testers rated the ease of using our application and the overall user experience.
The results are shown as below:
Ease of using.png

  • 0% for Very Difficult, hence not shown in pie chart.

Overall exp.png

  • 0% for Very Bad, hence not shown in pie chart.

Test Cases & Bug Severity Points

Iteration Test Cases Bug Severity Points
Iteration 1(1st test) Login and Logout 2
Register users 3
Iteration 1(2nd test) Login and Logout 0
Register users 0
Total Bug Severity Points for Iteration 1: 5
During Iteration 2 development Logged with bug ID 6 7
Iteration 2 Project Listing 0
Total Bug Severity Points for Iteration 2: 7
Iteration 3 (1st test) User Preferences 3
User Contributions 0
Iteration 3 (2nd test) User Preferences 0
Total Bug Severity Points for Iteration 3: 3
Bugs found during UAT 11
Iteration 4 (1st test) User Contributions with Credit Card & Facebook Sharing 3
Registration with First Name, Last Name and Country 1
Iteration 4 (2nd test) User Contributions with Credit Card & Facebook Sharing 0
Registration with First Name, Last Name and Country 0
Total Bug Severity Points for Iteration 4: 4
Iteration 5 Location based services 0
Total Bug Severity Points for Iteration 5: 0
Iteration 6 My Impact 0
UI bugs, Logged with Bug ID: 17, 18, 19 3
Total Bug Severity Points for Iteration 6: 0
Bugs found during UAT 2 6

All bugs arise from development and test cases will be recorded by our bug log.

Communications Management

To ensure that everyone in the team is aware of the event and tasks, we make use of a communication plan. Communication is important in preventing any breakdowns or errors.

Communication Plan

Event Rationale Frequency Deliverables
Team Meetings Project discussions, updates on project development Weekly Meeting minutes to be uploaded
Supervisor Meetings Supervisor feedbacks, update on project progress Fortnightly Meeting minutes to be uploaded and updates through email
Client Updates Update client on deliverables after each milestone After each milestone Meeting minutes to be uploaded
Sharing Sessions Peer feedbacks, comments and thoughts about the team Monthly Resolved issues, Peer feedback
Team Bonding Sessions To maintain team cohesion Monthly Have dinner/movies/outings

Meeting Minutes

Click here to view all minutes.

Risk Management

Risk Breakdown Structure


Risk Analysis

Risk Description Type Impact (Low/Medium/High) Probability (Low/Medium/High) Rating Mitigation Strategy Impact of Strategy
Client requirements may change during the course of project resulting in change of scope External Medium High A Enforce the scope change process. Ensure that all documentations are up to date and that all members of the team are aware of the scope changes. More time required on ensuring proper documentation for each change.
Submission to App store. Conflicting clauses in placing charitable transaction based services in the application for Apple AppStore billing system. Business High Medium A Comply to HIG guidelines provided by Apple. Use an external link which brings user out from the application to a web browser for further payment process Requires more time to align application to HIG guidelines. Reduces user experience.
Submission of application to Paypal for review Business Medium Medium B Submit to Paypal as early as possible. Research on the internet for more information on Paypal application submission. Tighter schedule in developing the application.
Quality issues like application bugs and synchronization with B1G1 database may surface. Technical Low Low C Design more test cases and increase testing frequencies each iteration. Engage a higher number of users during User Acceptance Test (UAT) More time incurred for carrying out more tests and design more test cases
Minimal professional training on Cocoa (API) and Objective-C programming language used in Mac application development Technical Low Low C Source for Apple training program and reading up eBooks from library and internet More time spent on research, peer sharing sessions and self-learning for the team.

Risk Metric



Click here to view.

Project Progress Summary

Iteration 1 Summary

1. Bug Logs:

Our bugs severity points for this iteration is 5. Our targeted bug severity goal per iteration is 10.
All bugs found are small issues and we resolved them within our allocated buffer time.

2. Test Results:
We ran the test cases twice.
The first test cases carried out failed as bugs were found and logged it.
We performed the test cases the 2nd time to ensure all bugs are quashed.
Test cases for Iteration 2 are done and uploaded.

3. Schedule Metric:
We are on time for Iteration 1

Iteration 2 Summary

1. Bug Logs:

Our bugs severity points for this Iteration 2 is 7. Our targeted bug severity goal per iteration is 10.
The bug found was found during the development. It has been fixed.

2. Test Results:
We ran test cases and found no bug.

3. Schedule Metric:
We were half day late (SPI is 0.5) but utilized 1 buffer day.
We had also changed our schedule to start one day earlier as there was 1 unused buffer day.

4. Client feedback:
We had met up with Masami and showcased her the project. Refer to the meeting minutes here.

Iteration 3 Summary

1. Bug Logs:

Our bug severity point for Iteration 3 is 3. Our targeted bug severity goal per iteration is 10.

2. Test Result:
Test cases were ran twice as the few of the test cases failed. All bugs found are small issues and we resolved within the allocated time.

3. Schedule metric:
We were 2 days late for this iteration 3. This is mainly due to a new scope change.

4. Change of scope
Client had raised a change on contribution management. Refer to scope change 02 for more information.

Iteration 4 Summary

1. Bug logs
Our bug severity point for Iteration 4 is 4. Our targeted bug severity goal per iteration is 10.

2. Test Results
These are the test cases used to run the test.

3. Schedule metric
We are slightly late for Iteration 4.

4. Change of scope
After mid term presentation and UAT, B1G1 raised 5 changes. They are as follows:
1. Change of user interface.
2. To include credit card payment
3. Preset donation amount instead of allowing them to key in manually
4. The default 3 pre-defined lifestyles to be editable
5. Registration page to include name and country


Our team members have no experiences in Objective C prior to this project and initial learning curve would be very steep. While there are other development tools, such as Titanium and PhoneGap, that use JavaScript and HTML (which we are very familiar with), our team has decided to use Xcode 4.1.

The table below shows a brief comparison between Xcode 4.1 and cross development tools.

Xcode 4.1 (Native IDE) Cross Platform Tools
Latest features can be found in iOS SDK along with Xcode IDE. Time is needed to implement the features.
Have access to all features of the hardware (iPhone and iPad). Have limited access to the features of the hardware. If need to access them, plug-ins must be written in Objective C.
Applications developed with XCode are optimized for best experience and able to utilize the functionality of the SDK. Act as a middleware to communicate with iOS SDK and the respective cross platform tools’ APIs.


  • To be filled


Team Reflection

Refer to Final Wiki

Individual Reflection

Hui Juan
Roger Ong
Eugene Chong
Vyane Ting
Daniel Ong

B1G1's comment for mid term

From Masami - The team has managed this project exceptionally well so far. Although iPhone Application development was totally new to them (and to us!), the team has taken carefully planned steps to ensure the smooth and efficient progress. We feel confident of the development because of the frequent and clear communications we've had during every stage. We look forward to launching the final product to spread the giving habit among many potential users, and at the same time, benefit our existing users.

Software Tools and References

Software Tools

  • Tortoise SVN
  • Dropbox
  • PHPMyAdmin
  • Xcode
  • Astah Community
  • HTML 5


  • To be filled