©2012 MasterCard. Proprietary and Confidential MASTERCARD PERSONAL EXPENSE MANAGEMENT SYSTEM – (MPEMS) Analysis and Design Phase Presented by team 2S

Presentation Overview SessionDescription Presentation Project Background Use Case Modeling Prototype Demo Transition Strategy from analysis to design Software Architecture Overall project progress (effort and schedule) Management Issues Implementation Plan (Expected Issues) Q & AQuestion and Answer

Project Sponsor: MasterCard Research Labs System Objective Provide Personal Expense Management System for customers to easily track and manage their spending on MasterCard. System Main Functions Access consolidated view of transactions for cards from different banks View personal spending records/pattern Manage budget by using the system’s budget reminder/alert function Earn reward points for spending and tagging of spend category Access to exclusive MasterCard deals Project Background MERCHANT ( NIKE SHOP) MERCHANT’S BANK ( OCBC) MASTER CARD ISSUER BANK ( CITIBANK ) Citibank CreditCard

1. Expense tracker Assign spending budget Assign spending target Notify user when their spending is about to exceed preset budget 2. Perks View and search for exclusive deals View and redeem for vouchers 3. Register Account Register Account Confirm Registration – Activate via SMS Use Case Modeling

1. Expense Tracker – Assign Budget/Target Spending

Use Case Modeling 1. Expense Tracker – Receive Budget Alert

Use Case Modeling 2. Perks

Use Case Modeling 3. Account Registration

Prototype Demo Budget Reminder end to end process

Prototype Demo Account Registration

Software Architecture

UI Component – Grails Web (gsp) Security Component – Grails Shiro Plugin/SSL Business Component (i.e. Deal) – Grails Controller and Service Common Service, Utility – Grails Plugin and Service Database Component – Domain class and GORM Software Architecture

ERD User Role, Permission Card Transaction Budget Deal Category Voucher Merchant Audit_log

Software Architecture

Analysis to Design Fullfill business requirement – Functional – Non-Functional Feed Grails Framework Flexible Apply Grails Best Practice Transition Strategy

Analysis - Register Account Transition Strategy

Design (Static) - Register Account

Transition Strategy Design (Dynamic) - Register Account

Transition Strategy Grails MVC – Model : groovy class – View : groovy server page – Control : groovy class Model (User.groovy) – Entity Object – GORM – Isolate from database design – relation mapping, field constraint and validation Implementation (Grails) - Register Account

Transition Strategy View (registration.gsp) – Ajax support – Template (header, footer) Control (User.controller) – Handle gsp request (mapping) – Response with different format (JSON, XML, HTML) Implementation (Grails) - Register Account

Transition Strategy Service (UserService.groovy) – Transactional Object – Complex business logic Plugin ( Service) – 3 rd party Grails plugins (more than 800) – High productivity – Less defect Implementation (Grails) - Register Account

Overall project progress

Management Issues Availability of Team Members Task Control Work Quality

Implementation Plan Detailed Design + Coding will start concurrently with test planning and immediately after phase 2. 2 resource on test planning and 4 resource on implementation More time has to be spent on UCRR - Design System Integration Testing must be completed on the 2 nd week of oct UAT (1 st cycle) will start on 3 rd week of oct UAT (2 nd cycle) to be completed before december

Q & A

THANK YOU