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

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

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

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

5. 1. Expense Tracker – Assign Budget/Target Spending

6. Use Case Modeling 1. Expense Tracker – Receive Budget Alert

7. Use Case Modeling 2. Perks

8. Use Case Modeling 3. Account Registration

10. Prototype Demo Budget Reminder end to end process

11. Prototype Demo Account Registration

12. Software Architecture

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

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

16. Software Architecture

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

18. Analysis - Register Account Transition Strategy

19. Design (Static) - Register Account

20. Transition Strategy Design (Dynamic) - Register Account

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

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

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

24. Overall project progress

25. Management Issues Availability of Team Members Task Control Work Quality

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

27. Q & A

28. THANK YOU