PaymentFramework

Payment Frameworkto Mobirox Ltdby team braZil

Project PresentationInnopoli 2, SoberIT

5.3.200814:00-15:00

PaymentFramework

Presentation agenda

• Business case behind the project• Solution• Product demonstration• Project evaluation• Questions

PaymentFramework

Business case behind the project

• Market for electronic payments is expanding

• Dominant design doesn’t exist• Integration of multiple payment methods

is expensive for service providers

PaymentFramework

Solution

• Aggregate the different payment methods behind a single interface

• Offer variety of reports to effective follow-up on transactions

• Cost efficiency– Quick implementation– Only one contract for payment

intermediation

PaymentFramework

Solution

• Descriptive image of Payment Framework

Internet

Service 1

Service 2

System administrator

Payment Framework

Bank

Credit card

SMS

Service provider

SMS Operator

PaymentFramework

Product Demonstration• Mobirox Music Shop• Mobirox Book Shop• Sales Reports• Transaction Cancellation

PaymentFramework

Demo: Mobirox Music Shop

• Users need– credits in Mobirox Music Shop

• Buy credits in Music Shop• Pay with SMS• Write code from returned SMS to

webpage• Back in Music Shop with x credits• Buy music with it

PaymentFramework

Demo: Mobirox Book Shop

• Users Need– Want to buy some books

• Select Books in Mobirox Book Shop• Buy the books • Select Payment method and pay • Return back to the book service and

download the books

PaymentFramework

Demo: User Interfaces

• Two different user interfaces• Content providers interface

– Limited rights– Limited reports

• Administrators interface

PaymentFramework

Demo: Sales Reports

• Four different transaction reports– List all transactions– Net sales report by service/product– Net sales report by payment channel– Transaction provisions report sorted by

payment channels

PaymentFramework

Demo: Transaction cancellation

• Transaction cancellation also possible if necessary– Banks– CreditCard

• Banks don’t offer test-interfaces so we builded those

PaymentFramework

Project Evaluation• Goals of the project• Challenges in this project• Lessons learned • Some metrics

– Time Usage– Quality Assurance

PaymentFramework

Evaluation: Goals & Deliverables

• Goals that were measurable were achieved – Some goals hard to measure

• Deliverables returned on time• Product and server in customers

posession

PaymentFramework

Evaluation: Quality Assurance

• Quality goals were altered in the beginning of Iteration II

• Two of the most important quality qoals were achieved

• Only a small part of planned testing activites were executed – lack of resources

PaymentFramework

Evaluation: Challenges

• Requirements elicitation– Took more time than expected– Requirements are in too abtsract level

• Defining the focus• Communication in big team• Major change at the beginning of

Implementation II• Minor details take a lot of time

PaymentFramework

Evaluation: Lessons Learned

• Communication is crucial in projects– Face to face is best, phone is second

• Weekly meetings– Information Sharing– Project status

• Development diary• Reflection workshops support the project• Domain knowledge helps in project• Pair coding / coding camps• Pricing the changes

PaymentFramework

Metrics: Time Usage

PaymentFramework

Metrics: Time Usage

PaymentFramework

Metrics: Quality Assurance

Blockers Critical Major Minor Trivial TotalIteration I 1 7 7 2 1 18Iteration II 0 7 26 9 1 43Total 1 14 34 11 2 61

• In Iteration II more testing activites were executed

• Most of the defects (90%) relate to UI implementation

• LOC 8400 / Classes 120• Documents 60 / Pages 400+

PaymentFramework

Metrics: Risk management

• Mostly mngt. level risks identified and processed

• Typical sources included uncertain requirements and inadequate staffing and skills

• Risk mngt. group has gathered 6 times• Risks

– In monitoring / open 6– Closed 15 ( + duplicate risks 15)

PaymentFramework

Thank you for your

interest!

Any questions?