IS480 Team wiki: 2013T1 BANKREVELS/Final
- 1 Project Progress Summary
- 2 Project Management
- 2.1 Project Schedule (Plan Vs Actual)
- 2.2 Project Metrics
- 2.3 Technical Complexity
- 2.4 Software Complexity
- 3 Quality of product
- 3.1 Project Deliverables
- 3.2 Quality
- 3.3 Deployment
- 3.4 User Testing 2 (UT 2)
- 3.4.1 Objective
- 3.4.2 Devices tested for Android
- 3.4.3 Devices tested for iOS
- 3.4.4 Documents
- 3.4.5 Purpose
- 3.4.6 Participants, Timing and Venue held
- 3.4.7 Implementation
- 3.4.8 Functions Tested
- 3.4.9 Data Collected
- 3.4.10 Results and Follow Up
- 3.4.11 Key Findings
- 4 Reflection
- 5 Future Development
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|
We have completed our project!
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.
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
DOWNLOAD OUR DETAILED PROJECT SCHEDULE.
You can refer to the following tabs (as shown below) in the excel spreadsheet for more details.
Project Schedule (Plan Vs Actual)
You may refer to this page for the details about the schedule metrics and how it is collected.
Team Schedule Ratio
|ITERATION||HIGHLIGHT / ISSUE||MITIGATION/CONTINGENCY PLAN|
|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)
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)
- 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
- JSON <-> SOAP Translator
- Adapting JSON format to XML
- Internally developed notation
- Adapting JSON format to XML
- 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 Management||Project Overview|
|Project Risk Management|
|Design||Project Architecture Diagram|
|Environment Setup Guide|
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.
MAINTAINABILITY, FLEXIBILITY & CONFIGURATION
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.
|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
- Samsung S3
- Samsung S4
- HTC Desire X
Devices tested for iOS
- iPhone 4
- iPhone 4S
- iPhone 5
- iPhone 5S
- UT 2 Execution Plan
- Observation Sheet (Mobile)
- Observation Sheet (Internet)
- Questionnaire (Internet)
- Questionnaire (Mobile)
- Tasks (Internet)
- Tasks (Mobile)
- Raw Results (Mobile)
- Raw Results (Internet)
- Experienced Users Raw Results (Mobile and Internet)
- Quantitative Analysis (Mobile)
- Quantitative Analysis (Internet)
- Summary of UT 2 results
The purpose of the UT 2 is to find out the following from the users:
- Is the learning curve of our app (internet and mobile) large?
- Is the QR code QuikPay function intuitive enough?
- What do users feel about the QR code login for internet banking?
- Can the user use all the functions of the application with ease?
- How easy it is for the user to navigate through the whole application?
- 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)
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.
|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)|
|Qualitative Data||Quantitative Data|
For RMB only
For RIB only
For RMB only
For RIB only
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.
- 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.
- 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)
|7||Easy to use/understand/navigate|
|3||Simple and Neat|
|3||Good use of colours|
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.
- 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.
|2||Easy to use|
- 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)
|5||Easy to use/understand/navigate/clear|
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.
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
- 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
- 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.
- 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