Difference between revisions of "IS480 Team wiki: 2013T1 BANKREVELS/Final"
(23 intermediate revisions by 2 users not shown) | |||
Line 6: | Line 6: | ||
Back to [https://wiki.smu.edu.sg/is480/IS480_Team_wiki:_2013T1_Bankrevels Main Wiki] | Back to [https://wiki.smu.edu.sg/is480/IS480_Team_wiki:_2013T1_Bankrevels Main Wiki] | ||
− | + | {| class="wikitable" style="text-align: center; height:25px" | |
− | {| class="wikitable" style="text-align: center" | ||
|+ | |+ | ||
− | + | ! scope="col" width="50" style="background:#CCCCCC| S/N | |
− | ! scope="col" width="50" style="background:# | + | ! scope="col" width="350" style="background:#CCCCCC| DESCRIPTION |
− | ! scope="col" width=" | + | ! scope="col" width="100" style="background:#CCCCCC| LINK |
− | ! scope="col" width=" | ||
|- | |- | ||
− | |1 | + | !scope="row" style=" text-align: center;"| 1 |
|align="center"| '''Final Presentation Slide''' | |align="center"| '''Final Presentation Slide''' | ||
|align="center"| [[Media:bankrevels-final-presentation.pptx|Download]] | |align="center"| [[Media:bankrevels-final-presentation.pptx|Download]] | ||
|- | |- | ||
− | |2 | + | !scope="row" style=" text-align: center;"| 2 |
|align="center"| '''Internet and Mobile Banking Application''' | |align="center"| '''Internet and Mobile Banking Application''' | ||
|align="center"| [http://10.0.106.169:8080/SMUtBank_IBS/login.action Link] | |align="center"| [http://10.0.106.169:8080/SMUtBank_IBS/login.action Link] | ||
|- | |- | ||
− | |3 | + | !scope="row" style=" text-align: center;"| 3 |
|align="center"|''' 1 minute pitch video ''' | |align="center"|''' 1 minute pitch video ''' | ||
|align="center"| [http://youtu.be/TFt-1OLVXLY View] | |align="center"| [http://youtu.be/TFt-1OLVXLY View] | ||
|- | |- | ||
− | |4 | + | !scope="row" style=" text-align: center;"| 4 |
|align="center"| '''Poster''' | |align="center"| '''Poster''' | ||
|align="center"| [https://wiki.smu.edu.sg/is480/Image:Poster_bankrevles.jpg View] | |align="center"| [https://wiki.smu.edu.sg/is480/Image:Poster_bankrevles.jpg View] | ||
Line 36: | Line 34: | ||
|} | |} | ||
+ | |||
{| cellpadding="9" style="border: 1px solid darkgray; text-align: center; height:150px" | {| cellpadding="9" style="border: 1px solid darkgray; text-align: center; height:150px" | ||
Line 72: | Line 71: | ||
==Project Management== | ==Project Management== | ||
− | [[Image:Arrow_bankrevels.png|28px]] [[Media: | + | [[Image:Arrow_bankrevels.png|28px]] [[Media:Bankrevels-schedule.xlsx|DOWNLOAD]] OUR DETAILED '''PROJECT SCHEDULE'''.<br> |
You can refer to the following tabs (as shown below) in the excel spreadsheet for more details.[[Image:Tabs_final.png]] | You can refer to the following tabs (as shown below) in the excel spreadsheet for more details.[[Image:Tabs_final.png]] | ||
<br><br> | <br><br> | ||
Line 157: | Line 156: | ||
===<div style=" background: #A9F5BC; padding: 12px; font-weight: bold; line-height: 0.5em"><font color= black size = 3>Project Deliverables</font></div>=== | ===<div style=" background: #A9F5BC; padding: 12px; font-weight: bold; line-height: 0.5em"><font color= black size = 3>Project Deliverables</font></div>=== | ||
− | {| class="wikitable" | + | |
− | |- style=" | + | {| class="wikitable" height:25px" |
− | + | |+ | |
− | + | |- | |
− | + | ! scope="col" style="text-align: center; width="100" style="background:#CCCCCC| STAGE | |
+ | ! scope="col" style="text-align: center; width="250" style="background:#CCCCCC| SPECIFICATION | ||
+ | ! scope="col" style="text-align: center; width="300" style="background:#CCCCCC| MODULES | ||
|- | |- | ||
− | + | !scope="row" style=" text-align: center;" rowspan="4" | '''Project Management''' | |
|| Project Overview | || Project Overview | ||
− | || [https://wiki.smu.edu.sg/is480/IS480_Team_wiki:_2013T1_Bankrevels_Project_Overview Project Overview] | + | || |
+ | *[https://wiki.smu.edu.sg/is480/IS480_Team_wiki:_2013T1_Bankrevels_Project_Overview Project Overview] | ||
|- | |- | ||
Line 173: | Line 175: | ||
* Supervisor Meetings | * Supervisor Meetings | ||
* Team Meetings | * Team Meetings | ||
− | ||[https://wiki.smu.edu.sg/is480/IS480_Team_wiki:_2013T1_Bankrevels_Administrative#Supervisor_Meetings minutes] | + | || |
+ | *[https://wiki.smu.edu.sg/is480/IS480_Team_wiki:_2013T1_Bankrevels_Administrative#Supervisor_Meetings minutes] | ||
|- | |- | ||
− | || | + | || Metrics |
− | || [https://wiki.smu.edu.sg/is480/IS480_Team_wiki:_2013T1_Bankrevels_Metrics Metrics] | + | || |
+ | *[https://wiki.smu.edu.sg/is480/IS480_Team_wiki:_2013T1_Bankrevels_Metrics#Schedule_Metrics Schedule Metrics] | ||
+ | *[https://wiki.smu.edu.sg/is480/IS480_Team_wiki:_2013T1_Bankrevels_Metrics#Bug_Metrics Bug Metrics] | ||
|- | |- | ||
|| Project Risk Management | || Project Risk Management | ||
− | || [https://wiki.smu.edu.sg/is480/IS480_Team_wiki:_2013T1_Bankrevels_Risk_Management Risks] | + | || |
+ | *[https://wiki.smu.edu.sg/is480/IS480_Team_wiki:_2013T1_Bankrevels_Risk_Management Risks] | ||
|- | |- | ||
− | + | !scope="row" style=" text-align: center;" | '''Analysis''' | |
|| Use case | || Use case | ||
− | || [https://wiki.smu.edu.sg/is480/IS480_Team_wiki:_2013T1_Bankrevels_Diagrams Use Case] | + | || |
+ | *[https://wiki.smu.edu.sg/is480/IS480_Team_wiki:_2013T1_Bankrevels_Diagrams#Use_Case_Diagram Use Case] | ||
|- | |- | ||
− | + | !scope="row" style=" text-align: center;"|'''Design''' | |
|| Project Architecture Diagram | || Project Architecture Diagram | ||
− | || [https://wiki.smu.edu.sg/is480/IS480_Team_wiki:_2013T1_Bankrevels_tBank Project Architecture Diagram] | + | || |
+ | *[https://wiki.smu.edu.sg/is480/IS480_Team_wiki:_2013T1_Bankrevels_tBank Project Architecture Diagram] | ||
|- | |- | ||
− | + | !scope="row" style=" text-align: center;" rowspan="2" | '''Testing''' | |
||Heuristic Evaluation | ||Heuristic Evaluation | ||
− | ||[https://wiki.smu.edu.sg/is480/IS480_Team_wiki:_2013T1_Bankrevels_Heuristic_Evaluation Heuristic Evaluation] | + | || |
+ | *[https://wiki.smu.edu.sg/is480/IS480_Team_wiki:_2013T1_Bankrevels_Heuristic_Evaluation Heuristic Evaluation] | ||
|- | |- | ||
||User Tests | ||User Tests | ||
− | || [https://wiki.smu.edu.sg/is480/IS480_Team_wiki:_2013T1_Bankrevels_Testing UT 1][https://wiki.smu.edu.sg/is480/IS480_Team_wiki:_2013T1_BANKREVELS/Final#User_Testing_2_.28UT_2.29 UT 2] | + | || |
+ | *[https://wiki.smu.edu.sg/is480/IS480_Team_wiki:_2013T1_Bankrevels_Testing UT 1] | ||
+ | *[https://wiki.smu.edu.sg/is480/IS480_Team_wiki:_2013T1_BANKREVELS/Final#User_Testing_2_.28UT_2.29 UT 2] | ||
|- | |- | ||
− | + | !scope="row" style=" text-align: center;" rowspan="4" | '''Handover''' | |
||Architecture Design | ||Architecture Design | ||
− | ||[[Media:Bankrevels_Architecture_Design.docx|Architecture Design]] | + | || |
+ | *[[Media:Bankrevels_Architecture_Design.docx|Architecture Design]] | ||
|- | |- | ||
|| Diagrams | || Diagrams | ||
− | ||[[Media:Diagrams.pptx|Diagrams]] | + | || |
+ | *[[Media:Diagrams.pptx|Diagrams]] | ||
|- | |- | ||
|| Environment Setup Guide | || Environment Setup Guide | ||
− | || [[Media:Bankrevels_Environment_Setup_Guide.docx| Environment Setup Guide]] | + | || |
+ | *[[Media:Bankrevels_Environment_Setup_Guide.docx| Environment Setup Guide]] | ||
|- | |- | ||
Line 227: | Line 241: | ||
===<div style=" background: #A9F5BC; padding: 12px; font-weight: bold; line-height: 0.5em"><font color= black size = 3>Quality</font></div>=== | ===<div style=" background: #A9F5BC; padding: 12px; font-weight: bold; line-height: 0.5em"><font color= black size = 3>Quality</font></div>=== | ||
+ | |||
+ | '''ARCHITECTURE''' | ||
+ | |||
+ | 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. | ||
+ | |||
+ | |||
+ | '''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. | ||
+ | |||
+ | '''SECURITY''' | ||
+ | |||
+ | 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. | ||
===<div style=" background: #A9F5BC; padding: 12px; font-weight: bold; line-height: 0.5em"><font color= black size = 3>Deployment</font></div>=== | ===<div style=" background: #A9F5BC; padding: 12px; font-weight: bold; line-height: 0.5em"><font color= black size = 3>Deployment</font></div>=== | ||
+ | |||
+ | {| class="wikitable" height:32px" | ||
+ | |+ | ||
+ | |- | ||
+ | ! scope="col" style="text-align: center; width="150" style="background:#CCCCCC| Area | ||
+ | ! scope="col" style="text-align: center; width="200 style="background:#CCCCCC| Details | ||
+ | |- | ||
+ | |||
+ | !scope="row" style=" text-align: center;"| Development Environment | ||
+ | |Our Mobile Banking application has been deployed on Android 4.0.3 and iOS 6 | ||
+ | |- | ||
+ | |||
+ | !scope="row" style=" text-align: center;"| Database | ||
+ | |Database deployed on TIBCO ActiveSpaces | ||
+ | |- | ||
+ | |||
+ | !scope="row" style=" text-align: center;"| Web Links | ||
+ | |[http://10.0.106.169:8080/SMUtBank_IBS/login.action Internet and Mobile Banking Application] | ||
+ | |- | ||
+ | |} | ||
===<div style=" background: #A9F5BC; padding: 12px; font-weight: bold; line-height: 0.5em"><font color= black size = 3>User Testing 2 (UT 2)</font></div>=== | ===<div style=" background: #A9F5BC; padding: 12px; font-weight: bold; line-height: 0.5em"><font color= black size = 3>User Testing 2 (UT 2)</font></div>=== | ||
Line 315: | Line 368: | ||
|- | |- | ||
!scope="row" style=" text-align: center;"| 4 | !scope="row" style=" text-align: center;"| 4 | ||
− | |Fund Transfer | + | |Immediate Fund Transfer |
|- | |- | ||
!scope="row" style=" text-align: center;"| 5 | !scope="row" style=" text-align: center;"| 5 | ||
Line 491: | Line 544: | ||
*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. | *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== | ==Future Development== |
Latest revision as of 15:44, 4 December 2013
Contents
- 1 Project Progress Summary
- 2 Project Management
- 3 Quality of product
- 3.1 Project Deliverables
- 3.2 Quality
- 3.3 Deployment
- 3.4 User Testing 2 (UT 2)
- 4 Reflection
- 5 Future Development
Project Progress Summary
Back to Main Wiki
S/N | DESCRIPTION | LINK |
---|---|---|
1 | Final Presentation Slide | Download |
2 | Internet and Mobile Banking Application | Link |
3 | 1 minute pitch video | View |
4 | Poster | View |
We have completed our project!
|
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.
Project Achievements & Challenge
Achievements
✔ 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
Challenge
- 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
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)
Project Metrics
Schedule Metrics
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).
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)
We calculate based on the total number of man-hours involved in each iteration.
Bug Metrics
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
Technologies and Libraries Used
Research done on Authentication and 2FA
Software Complexity
- 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 Deliverables
STAGE | SPECIFICATION | MODULES |
---|---|---|
Project Management | Project Overview | |
Meeting Minutes
|
||
Metrics | ||
Project Risk Management | ||
Analysis | Use case | |
Design | Project Architecture Diagram | |
Testing | Heuristic Evaluation | |
User Tests | ||
Handover | Architecture Design | |
Diagrams | ||
Environment Setup Guide | ||
Source Codes |
|
Quality
ARCHITECTURE
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.
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.
SECURITY
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.
Deployment
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)
Objective
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
Documents
- 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
Purpose
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)
Venue: SMU
Implementation
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 |
---|---|
Questionnaire
For RMB only
For RIB only
Observation sheet
|
Questionnaire
For RMB only
For RIB only
Observation Sheet
|
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
Methodology
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
Results
Reflection
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