IS480 Team wiki: 2013T1 BANKREVELS/Final

From IS480
Jump to navigation Jump to search

Group Logo.png

Project Progress Summary

Back to Main Wiki

1 Final Presentation Slide Download
2 Internet and Mobile Banking Application Link
3 1 minute pitch video View
4 Poster View

Overview final.png

We have completed our project!

  • Successfully built a usable and deployed mobile and internet banking application
  • Completed our scope requirements and maximized value to sponsor, Prof Alan
  • Conducted 1 Heuristic Evaluation and 2 UTs

Arrow bankrevels.png Click here to view our X-Factors

Project Highlights

Functional Requirements / Scope

We have completed all of the functionalities as agreed upon with our client, as seen in our Functional Requirements diagram below. At iteration 11, our team decided to implement four more features - PDF Accounts Statement and Accounts Dashboard for the Internet Banking Application, Loan Account Creation and Full/Partial Loan Repayment in replacement of Stock Ticker and this was agreed upon with the sponsor as they will add the greatest value to what we have in place so far.

Functional final.png

Project Achievements & Challenge


Development of retail banking mobile application on both iOS and Android platforms
Development of front end retail internet banking application to enhance user experience
Development of intelligent marketing service “Next Best Offer”
Documentation to facilitate handover and ensure project sustainability


  • Working concurrently on three different platforms (iOS, Android and Web) and two channels (Internet and Mobile)
    • How did we overcome the challenge? The usage of Appcelerator allows for higher code re-usability between both the Android and iOS platforms

Project Management

You can refer to the following tabs (as shown below) in the excel spreadsheet for more details.Tabs final.png

Project Schedule (Plan Vs Actual)

New timeline.png

Project Metrics

Schedule Metrics

Arrow bankrevels.png You may refer to this page for the details about the schedule metrics and how it is collected.

Team Schedule Ratio

The graphs below illustrates the overall team schedule ratio based on actual duration(hours) over planned duration(hours).
Sch metrics final.png

Iteration 6 No prior knowledge on the Titanium

Team members requires a period of time to be familiar and explore the use of Titanium

Arrange meeting during buffer time to complete outstanding tasks.Remind members of the risk involved.
Iteration 8 Resolving bugs generated during User Testing

Many bugs have surfaced during the UT 1, especially for the fund transfer functionality, and thus the team took more man hours than the planned duration to resolve them. After receiving the feedback from User Testing 1, our team has also decided to make a huge revamp (giving it a new and improved look) on the Internet Banking Application.

Consult Prof Alan immediately on the issues faced on the Fund Transfer backend services. Individual team member has to put in more man hours to complete the tasks at hand.
Calculating Man-hours (Planned vs Actual)

We calculate based on the total number of man-hours involved in each iteration.
PimanHours final.png

Bug Metrics

Arrow bankrevels.png You may refer to this page for the details about the bug metrics and how it is collected.

Outstanding bug in iteration 12 : 0

We would monitor and update the bug metrics in every iteration to minimize the number of bugs that surface during project development and thus ensuring the quality of the application.

Number of Bug in each Iteration


Bug Score (Total vs Outstanding)


Technical Complexity

  • SoapGen – An API wrapper that provides dynamic WSDL -> SOAP message generation at runtime
  • Full usage of ActiveSpaces in-memory data grid including persistence for data storage
  • Account Statement PDF file generation at runtime
  • QR Code/SMS 2FA verification across two channels which can be dynamically changed at runtime
  • Next Best Offer – A promotions matching service that resides on the tBank ESB

Arrow bankrevels.png Technologies and Libraries Used
Arrow bankrevels.png Research done on Authentication and 2FA

Software Complexity

  • JSON <-> SOAP Translator
    • Adapting JSON format to XML
      • Internally developed notation
  • Extending JSON functionality to suit XML needs
    • Identical tag names – aut:Authorization^2
    • Branch repetition - aut:Authorization.repetition:3
  • Minimizing return payload
    • TagRoot – Start a search from an inner branch
    • TagList – Specify tag values to return; recursive

Quality of product

Project Deliverables

Project Management Project Overview
Meeting Minutes
  • Sponsor Meetings
  • Supervisor Meetings
  • Team Meetings
Project Risk Management
Analysis Use case
Design Project Architecture Diagram
Testing Heuristic Evaluation
User Tests
Handover Architecture Design
Environment Setup Guide
Source Codes
  • tBank IBS - Eclipse Project Source
  • tBank Retail Mobile Banking - FINAL Android APK Keystore
  • tBank Retail Mobile Banking - FINAL iOS IPA
  • tBank Retail Mobile Banking - FINAL Titanium Project Source



Our RIB & RMB applications along with the IBS application backend have been designed from the ground up to be flexible, efficient and future proof. We have eschewed the use of a typical MySQL server in favor for an in-memory data grid which our client planned to completely migrate to in the near future. Another reason to support the use of such a product would be to service potentially high volumes of transactions that will be handled by the IBS from its retail customers.

Within the IBS, we make use of the Struts 2 framework to help us separate receiver logic from business logic and helped us modularized our services that we offer on the IBS. We have also developed a dynamic WSDL to SOAP templating engine built on top of soapUI sources that runs at runtime. In addition, we have designed and built our own JSON – XML translator that extends JSON with our own notation style so it covers certain XML use cases. This very same translator also is able to selectively return specific tags and branches to the client in order to minimize traffic payload.

On the client application side, we made full use of the AJAX request pattern in order to make the look and feel of our application fast, interactive and seamless. Much of the controller functions for handling data display and manipulation have also been moved into JavaScript to take advantage of the ever increasing computing power of consumer devices instead of letting the server handle the workload. On the RMB side, we use Appcelerator's Titanium IDE to help us deploy our application directly to both Android and iOS platforms with about 85% code re-usability. The fact that it uses JavaScript too also helps us reuse techniques in RIB and speed up the overall development process.


As a result of the above architecture, the overall system is very easy to maintain due to its dynamic nature and light code base. The JSON – XML translator also adds a layer of abstraction, allowing changes to be made to a certain extent without having to make very drastic changes. This also imparts very high flexibility to the UI developer, as data request and retrieval has been greatly simplified.

In addition, because we developed our codes to be very modularized, it is very easy to add in additional functions or screens to the IBS or RIB/RMB without breaking any code. Many UI objects have been abstracted so they can be reused by newly developed modules. We have also implemented an Admin page in which the administrator can go in to change certain values in our IBSProperties file; like adding services for 2FA verification, changing the output path for PDF documents and other properties at runtime. This properties file is also very easy to extend with new variables as it is dynamic in nature and also easy for service developers to retrieve these properties' values.


In our project, we have developed our very own QR code based 2FA authentication and its accompanying service on the tBank ESB. This service uses a secure random generator to generate the QR codes and all passwords are salted and hashed using SHA-512. We also allow customers of tBank to generate new QR 2FA codes via RIB as and when they please to encourage them to frequently change their 2FA. When developing controllers (particularly for ESB requests) for both RIB and RMB, we took a leaf from of way encryption standards are developed; by protecting the secret key and not the methodology. As a result, all incoming transaction to the IBS requires a valid sessionID to be presented before the request will be processed and not rely on some obfuscated method to activate services.


Area Details
Development Environment Our Mobile Banking application has been deployed on Android 4.0.3 and iOS 6
Database Database deployed on TIBCO ActiveSpaces
Web Links Internet and Mobile Banking Application

User Testing 2 (UT 2)


The objectives of UT 2 are to compare the proficiency of experienced and inexperienced users to find out if learning curve of our app (RIB and RMB) is large, gather feedback on the ease of using the application and collect overall feedback of the feel and design of the application.

Devices tested for Android

  1. Samsung S3
  2. Samsung S4
  3. HTC Desire X

Devices tested for iOS

  1. iPhone 4
  2. iPhone 4S
  3. iPhone 5
  4. iPhone 5S



The purpose of the UT 2 is to find out the following from the users:

  1. Is the learning curve of our app (internet and mobile) large?
  2. Is the QR code QuikPay function intuitive enough?
  3. What do users feel about the QR code login for internet banking?
  4. Can the user use all the functions of the application with ease?
  5. How easy it is for the user to navigate through the whole application?
  6. How does the user feel about the overall design of the application?

Participants, Timing and Venue held

Number of participants: 20 (10 for Internet Banking, 5 for Android, 5 for iOS)
Date and Time held: 15 November 2013 (11am - 7pm)
Venue: SMU




Participants will be welcomed to the user testing by the facilitator. Thereafter, participants will be given a brief overview of the application. Participants will then be given the specific tasks that they are required to complete without the guidance of the facilitator. In face of any problems that they are unable to resolve themselves, participants can ask the facilitator for help. The problem faced by the participants will then be recorded down the Observation Sheet provided for each facilitator.

After going through the user testing of the application, participants are required to complete an evaluation of the application on the Questionnaire provided. Participants are encouraged to discuss any problems they encounter with the facilitator.

The User Testing will end after the completion of the Questionnaire. The facilitator will then thank the participants for their time and feedback provided.

Functions Tested

No. Functions Tested
1 Login 2FA (RIB Mobile login 2FA)
2 View account information
3 View transaction history
4 Immediate Fund Transfer
5 Standing Instructions Fund Transfer
6 Bill Payment to billing organizations
7 GIRO arrangement with billing organizations
8 QuikPay QR Code (for mobile only)
9 View and edit profile settings (for web only)
10 Loan Calculator (Calculate Loan only)

Data Collected

Qualitative Data Quantitative Data


  1. Feedback on the overall design of the application

For RMB only

  1. Feedback on QR Code QuikPay function

For RIB only

  1. Feedback on mobile QR Code login 2FA

Observation sheet

  1. Recorded general comments from users


  1. Age
  2. Gender
  3. Frequent User (Yes or No)
  4. Ease of using Accounts Summary & Transaction History (1 - very difficult, 5 - very easy)
  5. Ease of using Immediate Funds Transfer (1 - very difficult, 5 - very easy)
  6. Ease of using Standing Instructions Funds Transfer (1 - very difficult, 5 - very easy)
  7. Ease of using Bill Payment (1 - very difficult, 5 - very easy)
  8. Ease of using GIRO Arrangement (1 - very difficult, 5 - very easy)
  9. Ease of using Loan Calculator – Calculate Loan (1 - very difficult, 5 - very easy)
  10. Ease of navigating through the application (1 - very difficult, 5 - very easy)
  11. Ratings on the overall design of the application (1 - very poor, 5 - Excellent)

For RMB only

  1. Ease of using QR code QuikPay (1 - very difficult, 5 - very easy)

For RIB only

  1. Ease of using profile settings (1 - very difficult, 5 - very easy)
  2. Ease of using mobile QR Code Login 2FA (1 - very difficult, 5 - very easy)

Observation Sheet

  1. Time taken for each task

Results and Follow Up

Data collected through the Questionnaire will be organized and aggregate to give a summary of the results to be published on wiki at a later date. Quantitative analysis will be done to compare the proficiency of experienced and inexperienced users to find out if learning curve of our app is large. A team meeting will be held to discuss the changes to be made.

Key Findings

Mobile Banking
  • Most users have given positive feedback that using the QR code to do fund transfer is convenient and fast. However, there are some users who find it a little troublesome while they not used to this mode of funds transfer.
Occurences Comments
5 Convenient
2 Quick/Fast
  • Average ratings of the ease of using each functions: 3.8 - 4.3 (Relatively Easy to Very Easy)
  • Average ratings for the overall design of the application: 4.0 (Very good)
Occurences Comments
7 Easy to use/understand/navigate
3 Simple and Neat
3 Good use of colours
2 Looks nice

Many users reflect that our application easy to use and navigate. Some mentioned our application is visually appealing, not cluttered and uses good colour themes.

Internet Banking
  • Most users have given positive feedback in using the QR code to log in, such as good speed and accuracy and secured, in addition to easy to use and its convenience. However, there are users who felt that it was quite confusing as they are unsure of which QR code they are required to scan at each step.
Occurences Comments
2 Easy to use
2 Convenient
  • Average ratings of the ease of using each functions: 3.5 - 4.4 (Relatively Easy to Very Easy)
  • Average ratings for the overall design of the application: 4.2 (Very good)
Occurences Comments
5 Easy to use/understand/navigate/clear
5 Clean/simple/Neat
4 Visually appealing

Many users reflect that our application easy to use and navigate, and at the same time, looks clean and neat. Some mentioned our application looks nice and pretty.

Quantitative Analysis

To measure if the learning curve of first-time users is great, we compared the timings of inexperienced users versus experienced users in completing assigned tasks. If the timings are similar, then we can conclude that the learning curve is not steep. However, if the inexperienced users take a significantly longer time (i.e. 30 seconds or more), this implies that there is a substantial learning curve. Our team has decided to use a significance level of 0.05 (5%). A two-sample unequal variance T-test is used as both sets of users are different.

H0 (Null Hypothesis): There is no (or little) difference between time taken for experienced and inexperienced users to complete tasks assigned to them
H1: Experienced users take a much faster time to complete the tasks as compared to inexperienced users


Br QA results1.PNG Br QA results2.PNG


Grp pic.png

Team Reflection

  • A deeper understanding of the banking industry and industry practices in retail banking application development
  • The importance of mutual support among team members to overcome adversities faced
  • Role of constructive feedback as a mechanism to ensure continued improvement
  • The importance of effective communication to minimise internal conflicts

Individual Reflection

  • Qingmin: It was particularly difficult to achieve the deliverables especially in the second half of the semester where the team member commitments started building up. To overcome these obstacles, effective communication and a certain degree of flexibility with the schedule was crucial.
  • Qian Hui: I realised the value of the user tests as a feedback mechanism to enhance end- user experience.
  • Kai Lin: The course of the project allowed me to experiment with various new technologies. The experience was trying at times, but nonetheless highly rewarding.
  • Shuyi: Handling the iOS development and managing the deployment of the iOS was at times a troublesome and challenging task. Therefore, the ability to overcome obstacles was something I experienced in this FYP journey.
  • Kingston: Handling my own share of work and overlooking the progress of the team was a tough and tiring journey. However, I have learnt how to manage time and priorities wisely to make sure that everything was under control for the project.
  • Yan Ni: Being a lead designer would mean continuous improvements made to the User Interfaces to make the app a more intuitive and visually appealing one. Having to deal with the mobile design for 2 platforms was a challenging task that stretched me beyond my comfort zone.

Future Development

  • Used as a teaching tool in undergrad Retail Banking, MITB & professional courses
  • To be used as a sandbox for testing and development of concepts and services in collaboration with industry partners, e.g. DBS & OCBC
  • Potentially to be put onto the cloud as a teaching tool for sharing with other educational institutions