PaymentFramework Payment Framework to Mobirox Ltd by team braZil Project Presentation Innopoli 2, SoberIT :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

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 BlockersCriticalMajorMinorTrivialTotal Iteration I Iteration II Total 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?