HeaderSIS.jpg

Difference between revisions of "IS480 Team wiki: 2010T2 Let’s Give!"

From IS480
Jump to navigation Jump to search
Line 511: Line 511:
 
proud being a part of the team in developing a system that will benefit hundreds and thousands after
 
proud being a part of the team in developing a system that will benefit hundreds and thousands after
 
its eventual launch.
 
its eventual launch.
 +
 +
====Chin Hong====
 +
The biggest takeaway for this project for me is time management. In this semester, I took 5 modules and for 2 of the modules, EI is a pre-requisite module for EWS. The last few weeks of the semester were really hard as I had to work round the clock and slept very little. Thus, I have to manage my time such that I will rest enough for my brain to function properly and I will have enough time to finish my work and studying for my exams.
 +
 +
Secondly, I learned about conflict management. Although I feel that our team dynamics is quite good, conflicts are bound to occur and this FYP experience taught me more about conflict management. During crunch time, members in the team might be on a shorter fuse and I learned to be more sensitive to my team members.
 +
 +
Thirdly, I learned about the importance of communication with stakeholders. During the first 8 weeks, we didn’t connect with the sponsor enough and we had to have a session to align both the sponsor’s and our expectations immediately after the mid-term review. After the mid-term review, our team takes a more proactive approach to communicate with our client and things moved faster and clearer.
 +
  
 
=='''Deliverables**'''==
 
=='''Deliverables**'''==

Revision as of 09:57, 14 April 2011

Let's Give!
Team Let's Give
Founded Singapore Management University, Dec 2010
Type Private Limited
Area User Experience
Social Media
Web Design
Web 2.0
Industry Non-Profit Organization
Project Design Your Life
Team members CHAN Chin Hong
LAU Pei En
LAU Sheng Shiun
TAN Jian Wei
Sandy TUN
XU Xiao Yue

Established in 2007, Buy1Give1's (B1G1) mission is to provide the systems, structure and inspiration to turn our world into a world full of giving, thus directly creating a much happier world. B1G1 gives businesses and individuals the power to change lives; by transforming giving from an ad-hoc, event-driven model to a very specific transaction-based giving model — a world where every transaction gives back and makes a difference.

This makes giving an effortless habit, changing lives and making a difference every second, every day and in every little way. Until now, B1G1 has brought the power, resonance and ‘connected-ness’ of transaction-based giving and Impact-Based Giving to literally hundreds of thousands of small-to-medium-scale enterprises (SMEs) that form the backbone of every economy.

Team Lets Give! Poster

Contents

Introduction

Team

Team Let's Give! Group Photo

From Left: Tan Jian Wei, Shank Lau, Chan Chin Hong, Sandy Tun, Xu Xiaoyue, Lau Pei En
  • Tan Jian Wei - Project Manager
    • Oversees the Project Progress and manages the team schedule and set objectives for each iterations.
    • Breaks down and assign tasks to group members based on their strengths and schedule and keep track of metrics
  • Chan Chin Hong - Interface Subject Specialist
    • Principle developer for interface and Front-End Components
    • Liaises with sponsors with design requirements and how feasible are they
  • Lau Pei En - Developer
    • Principal developer for logic and back-end classes
    • Liaises with sponsors and key stakeholders regarding functionality and how feasible they are
  • Xu Xiaoyue - Developer
    • Developer for both Front-End and Back-End Components
    • Subject expert in terms of bridging functionality and design requirements
  • Sandy Tun - Database and Facebook Subject Expert
    • Implements and integrate various Facebook services with Giving Central
    • Oversees the development of schema for Giving Central's data needs in current B1G1 Drupal CMS-derived database

Mentors

Technical Advisors

Previous FYP teams that worked with B1G1

Stakeholders' Coordination

Sunday Monday Tuesday Wednesday Thursday Friday Saturday
Team Bonding

Coding

Supervisor

Meeting

Internal

Meeting

Discussion

Coding

Meetings are usually with the client are on a fortnight basis.

Due to our close working relationship, meetings may occur whenever either side feels that it is necessary. In addition to meetings, we decided it was far more productive holding email and Skype conversations. This enabled us to accurately provide our client with exactly what they want, instead of second guessing. This saved us much time and ensured the rapid progress of our work.

The project's emphasis on the look and feel of the website meant that rigorous user testing is required. We capitalized on TeamViewer in the initial stages as it was not ready to be migrated to a live server. The client was regularly invited to test out the system whenever we completed a few functions, to ensure the quality of the experience that was delivered via our project. Once it was ready to be migrate to the testing server, regular emails were sent to invite the client to test and comment.

Project

Overview

Description - Project "Design Your Life"

Charity is, more often than not, a one off event driven by campaigns and drives. The "Design your Life" project aims to build an interactive web page that aids Buy1Give1 (B1G1) in raising awareness of worthy causes; by showing the general public the potential each individual has in creating an impact on others’ life. The web page will be accessed by both B1G1 members and non-members. All users are able to enter their daily lifestyle and the web page would generate how one can support the various initiatives under B1G1 that is complementary to their personal lifestyle and preferences.

Thus, B1G1 Giving Central was conceptualized by Masami and in 14 weeks, materialized by Team Let's Give.

Add comment here

B1G1 previous projects with SIS has grealy improved their outreach towards business-base giving. Now, the 4th collabration with SIS, Giving Central provides B1G1 a system for the other significant demographics of givers - Individual who wants to give and feel the impacts of their giving as per Businesses who give and impact per every transaction.

Furthermore, besides individual users, current businesses partners with B1G1 will also able to visit the web page and enter their respective revenue and pledge how much they would like to contribute to each initiative in accordance to their revenue. The more initiative the businesses support, the more exposure it gets via B1G1 as individual users who support common causes would discover these particular businesses. This provides an incentive to carry out CSR activities via B1G1 as it would provide exposure to the global market.

Motivation

To increase both businesses' and individuals' awareness of the potential impact they can create by the means of a highly interactive, easy to use and hassle-free website. The final vision, together with Individual Giving Central and Business Giving Central, the website will serves as a "forum" for current B1G1 business partners as well as individuals with like-minded objectives in giving for a better world to meet and collaborate to achieve greater impact to beneficaries around the world.

Objectives

Through this web page, the team hopes to achieve the following objectives:

  • Reach out to the individuals who are unaware of the world of giving.
  • Increase public awareness of their own capability to create an impact on others’ life
  • Incorporate giving as part of an individual and/or business lifestyle
  • Bring the businesses and individuals together to a community

Analysis

Story Board

1. User logs in via Facebook landing page Lg 1.jpg

2. Profile Page Lg 2.jpg

3. Giving Categories Lg 3.jpg

4. Select Worthy Cause for Giving Category Lg 4.jpg

5. Refine Search Lg 5.jpg

6. Monthly Giving Page Lg 6.jpg

Design

Architecture Overview

ArchitectureB1G1.png

Scope

  • Facebook SSO Login
  • Login for Current B1G1 Users
  • Create New Account
  • Categories selection
  • Project Selection
  • Project Popularities (for project detail pop-up)
  • 'Refine Search' feature for project selection
  • 'Skip' feature for project selection
  • Profile edit feature
  • Password change feature
  • Impact calculator (the impact measuring bar and linking the impact with plant images)
  • 'How to grow' info pop-up for Giving impact tab
  • Giving - 'Make it happen process' including the payment part (is it part of final presentation requirement?)
  • Facebook 'Share' button for Giving History
  • Shop and Give feature
  • Business Recommendation feature
  • Award feature
  • Favourite Business feature
  • Pledge feature
  • User's public profile page

Management

Workplan**


Milestones

LGMilestones.png

Metrics

To facilitate effective project management, 2 metrics are used.

Schedule Metric
  • Measures schedule effectiveness
  • Reviewed after each week and iteration
  • Schedule Effectiveness Index = Actual Completed Time (days) / Estimated Time (days)

Weekly Action Plan

SEI Action to be taken
<0.5
  • Look into why functionalities are completed in such a rapid pace
  • Revision of Schedule for ongoing iteration
0.5 - 1.5
  • Normal Pace
>1.5
  • Look into the reasons behind the slow progress
  • Revision of Schedule

Iteration Action Plan

SEI Action to be taken
<0.7
  • Overestimated Task Schedule
  • Revision of Schedule for next iteration(s)
  • Possible Enhancements or Functionalities to be implemented
0.7 - 1.3
  • Normal Pace
>1.3
  • Underestimated difficulty of tasks
  • Need to allocate more meetings and time
  • Revision of Schedule for next iteration(s)
  • Look into dropping of non-critical functionalities

Final Schedule Metric Chart

B1G1 LG Slide48.PNG

Bug Metric
  • Dictates action to be taken when dealing with bugs
  • Provides a tangible indication and action plan
  • Iteration Bug Severity (IBS) = ∑ (No. of bugs x bug severity level) per iteration
Bug Severity Level
Severity Description
5 - Severe
  • Hinders completion of key functions
  • Affects completed functions of previous built
3 - Normal
  • Bug affects key output or other functions of the system
1 - Minor
  • Isolated bug that does not affects other functions
  • Cosmetically output based bugs


Bug Resolution
IBS Action to be taken
<4
  • Debuggers: 1 - 2
  • Deadline : Flexible
4-9
  • Debuggers: 1 - 2
  • Deadline : Before next iteration
>9
  • Debuggers: >2 or as necessary
  • Deadline : Before next iteration
  • Re-assessment of current implementation

Final Bugs Metric Chart

Bugtable.jpg Bugchart.jpg

Risks and Mitigation Strategy

LG Risk and Migitation.png

Minutes

Week 1 Meeting
Weel 2 Meeting
Week 3 Meeting
Week 4 Meeting
Week 5 Meeting
Week 6 Meeting
Week 7 Meeting
Week 8 Meeting
Week 9 Meeting
Week 10 Meeting
Week 11 Meeting
Week 12 Meeting
Week 13 Meeting
Week 14 Meeting
Week 15 Meeting

Suite of Applications

Project Retrieval Algorithm

Project algor.png
1. Projects will be extracted from the database and sorted from lowest to highest price.
2. The projects are then split into 3 price ranges. Low , Medium, High.
3. Although the projects are displayed into groups of 3, in the backend, they are sorted in groups of 4 (in the diagram above, we named it as a "page")
4. A page (the listing of project in groups of 4) always will consist of projects selected from 2 being selected from low priced range group, 1 from medium and 1 from high.
5. The pages after the 1st group is to be queried and retrieve when user clicks on the arrow button from more projects to be added. There is a leeway of 2 "pages" to be loaded, so users will not encounter "lag" or delay issues as this is done in the backend.
These groups are put in random order so that users will know see the same groups of projects appearing whenever he selects the same category.

Country Filter

Country filter.png
Facebook login will extract the user's current city/counttry of residence and match it according to B1G1 list of business partners. That will ensure relevant businesses are recommended to users as opposed to recommending users businesses which are not within the user's country of residence.

Quality

Bugs

UAT

Heuristics

Functionality

Usability

Testing

Execution

Code

Documentation

Deployment

Test Plan

2 versions of UAT has been created. First (Long) version used mainly for regressional testing to be done by SIS Peers and B1G1 Staff that spans from validation to functionality and heuristic feedbacks
UAT Long Version

Short version that is distributed to Non-SIS Peers and B1G1 Current Users that focus mainly on functionality and heursitic issues.
UAT Short Version

UAT

Resources

Technology Used Software Used

Learning Outcomes**

Challenges

Implementation of a website that places importance on heuristics and aesthetics

Up to this point, except in briefly in Software Engineering, all of our IS projects are much more concerned with hard requirements and functionalities. In this aspect, Giving Central has been very different. Aesthetics is a very important part of the project but the main problem with heuristics and even more so for aesthetics are that when a product is refined to a point, it is sometimes subjective. Take for example, the qtip implementation, quite a number of users has commented that the dynamic generation of content is very cool but there are still a few users who commented that they resembles popups. Of course, we can argue otherwise but this only brings to the point that these aspect of the project is quite debatable. The key takeaway here will be that we have to take the majority view.

Learning new implementation tools/languages

In this project, we have to utilise new technologies such as AJAX and JQuery which in turn is coded mainly PHP and Javascript, both in which are not familiar to use who are used to "strict" OO languages instead of scripts. The language beahviour is one thing, but the other more significant barrier which is we would have to implement a project-wide framework in how pass variables (mainly in JSON). Much of our delay in the first half of the project is attributed to these difficulties.

Task allocation

In the early part of the project, we had allocated tasks in terms of modules. For example, Xiaoyue is allocated the Refine Search module, she then is in charge of implementing back-end tasks such as coding of database connection, search algorithm implementation, packaging the retrieved dataset into JSON objects, handling system interacts and dictating system behavior when any interactions happen. This means she will have to know a multitude of skills which is not effective in a time-constraint environment.

On top of that, the lack of a similar framework and unified interface library usage means everyone will use radically different techniques to present information. In our case, there is no forms, no method calling and strict variable passing format to dictate how we pass things around. Interface implementations do not work well together as JQuery libraries just cannot "stack" on top of each other and work perfectly.

The only solution is to specialised the tasks allocated to each member. The team is split into a backend and front-end team. A module when allocated, will be split into back and front end section. Both members responsible of the particular module front and back end will decide what variables to be handed from backend to frontend with the framework set as mentioned in this previous section.

This ensures a faster development process and unified interface design.



Individual Reflection

Jian Wei

First of all, let me describe how we took the project up. It was after mid-term last semester when we had to look at the IS480 wiki for projects. At first, we were quite fazed by the choices we have. Some of us are evaluating the depth and the others for how technologically interesting it can be. We then came across B1G1’s post on wiki and were very intrigued by how it works. We went on to talk with Maxco who were in the middle of their FYP with B1G1 and they had nothing but praises for them. Someone came then spurred out the the ethos of “Since we are doing the project for free, the most deserving organization should be one that is also one that is helping others too!”. Since then, we never looked back.

That being said, my team has the most interesting combination I can ask for. It was the most “open” group I had in all my polytechnic and university life. We always had debates about everything, from real issues like coding standards, platform we are coding on to even mundane geeky details like which OS is superior. However, diverging views is never an issue and in one way or another, we respect each and one’s view having coming from different experiences – cliché but true. Having everyone as a unique individual, each bringing different skills to the table and as a PM, nothing is more satisfying to see the results of having responsible group members each accomplishing their tasks and looking on as the whole project falling into place even with rough times in between.

Our sponsors turned out to be larger than life, even after all the praises heaped on them. I still remember the first meeting we had in the early weeks of November last year, when they assured us your “big” 6 members team is going to supplemented by even 2 more members , our client themselves - Masami and Paul. That was never an overstatement. Right from inception of the project concept to the UAT and presentation, they have been sticking together us, guiding and giving us various advices in every single way I can think of.

Myself, as I believe the team as well, as grown tremendously in competency as well as mentally during these trying months. It was nevertheless a fun journey and recalling those hilarious moments still bring a smile even while I am writing this and cramming for exams. Lastly, nothing can describe how I feel proud being a part of the team in developing a system that will benefit hundreds and thousands after its eventual launch.

Chin Hong

The biggest takeaway for this project for me is time management. In this semester, I took 5 modules and for 2 of the modules, EI is a pre-requisite module for EWS. The last few weeks of the semester were really hard as I had to work round the clock and slept very little. Thus, I have to manage my time such that I will rest enough for my brain to function properly and I will have enough time to finish my work and studying for my exams.

Secondly, I learned about conflict management. Although I feel that our team dynamics is quite good, conflicts are bound to occur and this FYP experience taught me more about conflict management. During crunch time, members in the team might be on a shorter fuse and I learned to be more sensitive to my team members.

Thirdly, I learned about the importance of communication with stakeholders. During the first 8 weeks, we didn’t connect with the sponsor enough and we had to have a session to align both the sponsor’s and our expectations immediately after the mid-term review. After the mid-term review, our team takes a more proactive approach to communicate with our client and things moved faster and clearer.


Deliverables**

Use Case Diagram

Use Case Descriptions and Technologies Used

Mobile Version Screen Shots

Test Plan

Source Codes

User Manual

Presentation Slides

Old Wiki---------------------------------------------

Project Overview

Current Status

  • Collapsible Side Menu [Completed]
  • Giving Impact Calculator [Completed]
  • JCarousel Project Browsers [Completed]
  • Project Search with QTip [Completed]
  • Search Function for Projects [Completed]
  • Facebook Sign on [Completed]
  • Filters
  • Paypal Integration
  • Business Giving Central [Removed from FYP scope... BUT WILL BE DONE!]
  • Awards Module
  • Business Recommendation
  • Business Connections
  • Daily Habits Calculator Interface
  • Giving History

Metric

Metrics

To facilitate effective project management, 2 metrics are used.

Schedule Metric
  • Measures schedule effectiveness
  • Reviewed after each week and iteration
  • Schedule Effectiveness Index = Actual Completed Time (days) / Estimated Time (days)
Weekly Action Plan
SEI Action to be taken
<0.5
  • Look into why functionalities are completed in such a rapid pace
  • Revision of Schedule for ongoing iteration
0.5 - 1.5
  • Normal Pace
>1.5
  • Look into the reasons behind the slow progress
  • Revision of Schedule
Iteration Action Plan
SEI Action to be taken
<0.7
  • Overestimated Task Schedule
  • Revision of Schedule for next iteration(s)
  • Possible Enhancements or Functionalities to be implemented
0.7 - 1.3
  • Normal Pace
>1.3
  • Underestimated difficulty of tasks
  • Need to allocate more meetings and time
  • Revision of Schedule for next iteration(s)
  • Look into dropping of non-critical functionalities
Metric Chart

Metric1.JPG

Bug Metric
  • Dictates action to be taken when dealing with bugs
  • Provides a tangible indication and action plan
  • Iteration Bug Severity (IBS) = ∑ (No. of bugs x bug severity level) per iteration
Bug Severity Level
Severity Description
5 - Severe
  • Hinders completion of key functions
  • Affects completed functions of previous built
3 - Normal
  • Bug affects key output or other functions of the system
1 - Minor
  • Isolated bug that does not affects other functions
  • Cosmetically output based bugs


Bug Resolution
IBS Action to be taken
<4
  • Debuggers: 1 - 2
  • Deadline : Flexible
4-9
  • Debuggers: 1 - 2
  • Deadline : Before next iteration
>9
  • Debuggers: >2 or as necessary
  • Deadline : Before next iteration
  • Re-assessment of current implementation

Minutes

Meeting 1
Meeting 2
Meeting 4

Mid Term Review

Mid Term Review Deliverables