HeaderSIS.jpg

Difference between revisions of "IS480 Team wiki: 2013T1 Kungfu Panda Final Wiki"

From IS480
Jump to navigation Jump to search
(New page: 1000x500px|center <br/><br/> <imagemap> Image:KP-Main Wiki Link.PNG|206x52px|right rect 0 0 200 100 Main Wiki desc none...)
 
 
(106 intermediate revisions by 6 users not shown)
Line 7: Line 7:
 
</imagemap>
 
</imagemap>
  
 
+
[[Image:KP-WithClient2.PNG|951x547px|right]]
  
 
== <div style="background: #FFD801; padding: 15px; font-weight: bold; line-height: 0.3em"><font color= #FFFFFF>Project Progress Summary</font></div>==
 
== <div style="background: #FFD801; padding: 15px; font-weight: bold; line-height: 0.3em"><font color= #FFFFFF>Project Progress Summary</font></div>==
 +
<font face= "Baskerville Old Face" size=4 color="#2f2929" >''' Final Presentation Slides  [[Media:KP xxx.pptx|Download]]!'''</font> <br/>
 +
<font face= "Baskerville Old Face" size=4 color="#2f2929">Link to our Branch Teller Application: http://10.0.106.169:8080/SMUtBank_Teller/</font>
  
<font face= "Baskerville Old Face" size=4 color="#2f2929" >''' Midterm Presentation Slides  [[Media:KP Midterm.pptx|Download]]!'''</font> <br/>
 
<font face= "Baskerville Old Face" size=4 color="#2f2929">Link to our Banch Teller Application: http://10.0.106.169:8080/SMUtBank_Teller/</font>
 
 
 
<br/>
 
<br/>
Our team, Kungfu Panda, have been progressing well since the start of iteration 1; currently, we are in iteration 9 of our project. Although through the first half of the semester, we faced some changes requested by our client, our team faced them well. We were very focused. However, due to some last minute changes to our requirement, our team is currently rescheduling some task to the next iteration in order to complete the prioritized task first.  
+
After '''''2620.5''''' working man hours over '''''32 weeks''''' / '''''222 days''''' (29 April - 6 December), our team, Kungfu Panda, has finally come to the end of our Final Year Project.
<br/> <br/>  
+
<br/>  
After Midterm, our team should have completed about 65% of the Branch Teller Application which includes the Party Customer, Deposit Account, Loan Account and Transaction use cases.
+
=== <u>Project Achievements</u> ===
We will be moving on to complete our X-Factor (Credit Approval and Teaching Tool) after our Midterm.
+
* Built a user friendly Branch Teller Web Application
 +
* Used Service Oriented Architecture Principles to build reusable SMU tBank Core Services
 +
* Completed 2 X-Factors - Credit Approval (Engine & Teaching Tool), and Usability
 +
* Ensured software quality via Software Testing (SOAPUI, HTMLUnit)
 +
* Tested & validated our project via 5 Tests (Classroom Lab, User Tests etc.)
 +
* Facilitated project extension and longevity through BIAN Documentation
 +
<br/>
 +
=== <u>Project Challenges</u> ===
 +
* Working in a collaborative, co-dependent space with 2 other FYP teams - Bankrevels & ironMEN
 +
* Difficulty obtaining expert feedback from real Branch Tellers
 +
<br/>
 +
'''''Overcoming Project Challenges''''' <br/>
 +
* Streamline and formalise lines of communication through common client when working with other FYP teams
 +
* Pursuing all avenues to obtain expert feedback and domain knowledge
 
<br/>
 
<br/>
 +
 
=== <u>Project Highlights</u> ===
 
=== <u>Project Highlights</u> ===
 +
* Recommendation of BRMS to survey (FICO, Jess, Drools) for Credit Engine with Steven Nunez (21th May 2013)
 +
* Interview with Xiao Xiang, OCBC's Head of Credit Research (6th November 2013)
 +
* User Test with Cyril Chia, OCBC Frank's Regional Branch Manager (7th November 2013)
 +
 +
<br/>
  
 
== <div style="background: #FFD801; padding: 15px; font-weight: bold; line-height: 0.3em"><font color= #FFFFFF>Project Management</font></div>==
 
== <div style="background: #FFD801; padding: 15px; font-weight: bold; line-height: 0.3em"><font color= #FFFFFF>Project Management</font></div>==
 
=== <u>Project Status</u> ===
 
=== <u>Project Status</u> ===
Currently, our project is '''68.12%''' completed. <br/>
+
Our project is '''100%''' completed in terms of developmental tasks <br/>
Percentage of Development Tasks Complete = Number of Completed Tasks (in Green) / Total Number of Tasks<br/>
 
 
The below diagram shows a coloured diagram / map of development tasks that are completed and outstanding.<br/>
 
The below diagram shows a coloured diagram / map of development tasks that are completed and outstanding.<br/>
[[Image:KP-ProjectProgressWk24aNew.PNG|1144 × 469px|center]]
+
Percentage of Development Tasks Complete = '''Number of Completed Tasks (in Green) / Total Number of Tasks<br/>
[[Image:KP-ProjectProgressWk24bNew.PNG|1145 × 361px|center]]
+
[[Image:KP ProgressFinalFinal(a).PNG|924×490px]]
=== <u>Project Milestone & Schedule</u> ===
+
[[Image:KP ProgressFinalFinal(b).PNG|927×428px]]
[[Image:KP-MilestoneTableNew.PNG|805x358px|left]] <br/>
+
 
[[Image:KP-Milestones-Iteration9aNew3.PNG|685x468px|center]]<br/>
+
=== <u>Project Milestone</u> ===
<font face= "Baskerville Old Face" size=4 color="#2f2929" >''' Our Updated Project Schedule  [[Media:KP Schedule 10102013 0354.xlsx|Download]]!'''</font>
+
[[Image:KP Milestone Table.PNG|807x372px]] <br/>
 +
[[Image:KP FinalFinalMilestone.PNG|703x468px]]<br/>
 +
<font face= "Baskerville Old Face" size=4 color="#2f2929" >''' Our Updated Project Schedule  [[Media:KP Schedule.xlsx|Download]]!'''</font>
 +
<br/>
 +
 
 +
=== <u>Project Schedule (Planned Vs Actual)</u> ===
 +
 
 +
'''Major Changes in Project Scope'''
 +
<br/>
 +
From the beginning of our project, we have '''added''' to our scope the following:
 +
* 1 Branch Teller Functionality
 +
** Party User PIN Create
 +
* Integration of 8 Services
 +
**Party_Login_Create
 +
**Party_Login_Read
 +
**Account_Status_Update
 +
**Payment_DirectDebitAuthorization_Delete
 +
**Product_LoanFullRepayment_Calculate
 +
**Product_LoanPartialRepayment_Calculate
 +
**Product_LoanInstallment_Calculate
 +
**Currency_Read_List
 +
<br/>
 +
 
 +
We have also '''dropped''' 2 Branch Teller Functionalities:
 +
<br/>
 +
* Upload Documents
 +
* Read Documents
 +
<br/>
 +
And, we have chosen to not take on proposed changes from our client:
 +
* 2 Branch Teller Functionalities
 +
**Payment Standing instruction
 +
**Manage Customer Beneficiaries
 +
* Integration of 8 Services
 +
**Payment_Standing_Instruction_Create
 +
**Payment_Standing_Instruction_Read
 +
**Payment_Standing_Instruction_List_Read
 +
**Payment_Standing_Instruction_Update
 +
**Payment_Standing_instruction_Delete
 +
**Payment_Beneficiary_List_Read
 +
**Payment_Beneficiary_Create
 +
**Payment_Beneficiary_Delete
 +
<br/>
 +
In addition, for a full list of all major and minor changes, please download our schedule to view the "Changes Made" Spreadsheet here.
 +
<br/>
 +
For a full list of major and minor changes as a result of User Test feedback and expert opinion from Branch Managers and Bank executives, please view our User Test wiki pages: [https://wiki.smu.edu.sg/is480/IS480_Team_wiki:_2013T1_Kungfu_Panda_UT3 UT1], .[https://wiki.smu.edu.sg/is480/IS480_Team_wiki:_2013T1_Kungfu_Panda_UT4 UT2], and [https://wiki.smu.edu.sg/is480/IS480_Team_wiki:_2013T1_Kungfu_Panda_UT5 ExternalUT]
 +
<br/>
 +
<br/>
 +
'''Impact in Project Plan'''
 +
<br/>
 +
As a result of adding to our project scope, our project showed signs of falling behind schedule when our Hours Differed Metric hit 48.50 hours in Iteration 8. 
 +
This meant our team was behind schedule by more than half a week in man hour terms. 
 +
We decided to drop 2 functionalities in response to this as mentioned above.
 +
The metrics can be viewed further below in the wiki page.
 +
 
 
=== <u>Project Metrics</u> ===
 
=== <u>Project Metrics</u> ===
==== Schedule Metrics ====
+
==== Scheduling Metrics ====
[[Image:KP-ScheduleMetricsNew2.PNG|624x246px|center]]
+
'''Schedule Metric'''<br/>
<br/><br/>
+
The objective of the Schedule Metric is to measure Degree of Accuracy in Forecasting Hours for Project Tasks <br/>
 
+
Schedule Metric Calculation = '''Actual Hours / Planned Hours'''
[[Image:KP-Individule MetricsWk23.PNG|1178x422px|center]]
+
<br/>
<br/><br/>
+
[[Image:KP ScheduleMetric Plan.PNG|686x254px|centre]]
Below are some graphs which shows our schedule metrics for each iterations and for each individual members. <br/>  
+
[[Image:KP ScheduleMetric a.PNG|1012x418px|centre]]
We have also calculated the average man hours per week each member put in.
+
[[Image:KP ScheduleMetric b.PNG|1012x418px|centre]]
 +
[[Image:KP ScheduleMetric Inv.PNG|767x318px|centre]]
 +
[[Image:KP ScheduleMetric Team.PNG|768x271px|centre]]
 +
<br/>
 +
'''Hours Per Week Metric'''<br/>
 +
Our Hours Per Week Metric measures Amount of Workload on Individual Team Members<br/>
 +
Hours Per Week Metric Calculation = '''Hours / Weeks in Iteration''' <br/>
 +
Calculate Metrics for Old, New & Actual<br/>
 
<br/>
 
<br/>
[[Image:KP-TeamScheduleMetricsWk23.PNG|848x232px|center]]
+
[[Image:KP HPW Plan.PNG|724x226px|centre]]
 +
[[Image:KP HPW a.PNG|1030x472px|centre]]
 +
[[Image:KP HPW b.PNG|1029x373px|centre]]
 +
[[Image:KP HPW graphNew.PNG|1072x288px|centre]]
 
<br/>
 
<br/>
[[Image:KP-Individule_MetricsGraphWk23.PNG|849x268px|center]]
+
'''Hours Deferred Metric'''<br/>
 +
The objective of this metric is to measure number of hours planned for tasks that were incomplete and moved to another iteration due to project changes. <br/>
 +
Together with Schedule Metric determines health of project.<br/>
 +
Hours Deferred Metric Calculation = '''No. of Hours Deferred'''
 
<br/>
 
<br/>
[[Image:KP-ManhoursWk23.PNG|848x232px|center]]
+
[[Image:KP HrDeferred Plan.PNG|779x212px|centre]]
 +
[[Image:KP HrDeferred Result.PNG|1128x430px|centre]]
 +
[[Image:KP HrDeferred Graph.PNG|362x337px|centre]]
 
<br/><br/>
 
<br/><br/>
 +
 
==== Bug Metrics ====
 
==== Bug Metrics ====
<Strong>Total number of bugs encountered: 38</Strong> <br/>
+
<Strong>Bug Metric for FYP Week 30: 0</Strong>
<Strong>Bug Metric for FYP Week 22: 1</Strong>
 
 
[[Image:KP-GoodBugMetric.PNG|63x58px]]
 
[[Image:KP-GoodBugMetric.PNG|63x58px]]
 
<br/>
 
<br/>
 
Below shown are the latest 25 bugs our team have encountered and is recorded in our Bug Tracker. <br/>
 
Below shown are the latest 25 bugs our team have encountered and is recorded in our Bug Tracker. <br/>
 
http://kfpbugtracker.no-ip.org/webissues
 
http://kfpbugtracker.no-ip.org/webissues
[[Image:Bug tracker 101013.PNG|1028x453px|centre]]
+
[[Image:KP BugTrackerFinal.PNG|1026x582px|centre]]
<br/>
+
 
 
<br/>
 
<br/>
 
[[Image:KP-BugMetricsNew2.PNG|596x287px|centre]]
 
[[Image:KP-BugMetricsNew2.PNG|596x287px|centre]]
Line 63: Line 148:
 
[[Image:KP-BugMFormula.PNG|870x30px|centre]]
 
[[Image:KP-BugMFormula.PNG|870x30px|centre]]
 
<br/>
 
<br/>
[[Image:KP Bug Metrics wk24a.PNG|709x265px|centre]]
+
[[Image:KP BugMetric-a.PNG|741x298px|centre]]
 
<br/>
 
<br/>
[[Image:KP Total Bug wk24b.PNG|709x274px|centre]]
+
[[Image:KP BugMetric-b.PNG|744x299px|centre]]
 
<br/>
 
<br/>
[[Image:KP Bug Score wk24c.PNG|721x270px|centre]]
+
[[Image:KP BugMetric-c.PNG|883x344px|centre]]
=== <u>Project Risk </u>===
+
<br/>
Below are our team's top 3 Risk - High Likelihood and High Impact
+
 
<br/><br/>
+
=== Happiness Metric ===
''' 1. Lack of Market Research due to Confidentiality of Proprietary Systems'''
+
[[Image:KP-HappyMetirc.PNG|598x156px|centre]]
* Product Comparison with Oracle Flexcube Branch Teller
+
[[Image:KP-HappyMetircScale.PNG|725x164px|centre]]
* Subject Matter Experts to be interviewed
 
** i.e. OCBC’s Head of Credit Risk
 
''' 2. Dependencies on Services Built by Others'''
 
* Changes requested by other teams for shared services
 
* MDM Billing Organization Read List
 
**Delivered 6 September by FYP Team IRONmen
 
''' 3. Project Scope & Requirement Changes'''
 
*Increase time spent with Client outside of Weekly Meetings
 
**BA & PM 4-6 hrs / week
 
*BIAN (Banking Industry Architecture Network Documentation for Developed Services
 
* Documentation in industry defined template, common terminology & language
 
* “Irons out” the little details
 
* Longevity of the SMU tBank project after our FYP
 
 
<br/>
 
<br/>
[[Image:KP-Midtermrisks.PNG|568x327px]]
+
 
 +
[[Image:KP Happy Metric New.PNG|598x176px|centre]]
  
 
===<u> Technical Complexity</u> ===
 
===<u> Technical Complexity</u> ===
Line 113: Line 186:
 
To develop on the EMS, our team had to use a sister product of Tibco, the Tibco Designer. This is a GUI-based developmental interface that allows developers to minimise coding whilst maintaining a high level of efficiency in capturing business process logic.
 
To develop on the EMS, our team had to use a sister product of Tibco, the Tibco Designer. This is a GUI-based developmental interface that allows developers to minimise coding whilst maintaining a high level of efficiency in capturing business process logic.
 
<br/><br/>
 
<br/><br/>
'''Sample Service: Account_Loan_Create Service'''
+
'''Sample Service: Transaction_PartialLoanRepayment_Create'''
[[Image:KP-Account_Loan_Create.PNG]]
+
[[Image:Sample-core-services-complicated.png|798x596px]]
  
== <div style="background: #FFD801; padding: 15px; font-weight: bold; line-height: 0.3em"><font color= #FFFFFF>Product Comparison</font></div>==
 
[[Image:KP-ProductCompare.PNG|570x330px|center]]
 
<br/>
 
'''1. Features Comparison'''<br/>
 
[[Image:KP-ProductCompare1.PNG|543x349px]]<br/><br/><br/><br/>
 
'''2. Screen Space Utilization Comparison'''<br/>
 
[[Image:KP-ProductCompare2a.PNG|527x328px]]
 
[[Image:KP-ProductCompare2b.PNG|563x290px]]<br/><br/><br/><br/>
 
'''3. Modern UI Element Comparison'''<br/><br/>
 
[[Image:KP-ProductCompare3.PNG|537x265px]]
 
<br/><br/>
 
 
== <div style="background: #FFD801; padding: 15px; font-weight: bold; line-height: 0.3em"><font color= #FFFFFF>Quality of Application</font></div>==
 
== <div style="background: #FFD801; padding: 15px; font-weight: bold; line-height: 0.3em"><font color= #FFFFFF>Quality of Application</font></div>==
===<u>Intermediate Deliverables</u> ===
+
===<u>Project Deliverables</u> ===
 
{| class="wikitable" style="text-align: center"
 
{| class="wikitable" style="text-align: center"
 
|+  
 
|+  
Line 154: Line 216:
 
|Metrics
 
|Metrics
 
|align = "left"|
 
|align = "left"|
*[[IS480 Team wiki: 2013T1 Kungfu Panda Schedule Metrics|<b>Schedule Metric''</b>]]
+
*[[IS480 Team wiki: 2013T1 Kungfu Panda Schedule Metrics|<b>Scheduling Metric''</b>]]
 
*[[IS480 Team wiki: 2013T1 Kungfu Panda Schedule Metrics|<b>Bug Metric''</b>]]
 
*[[IS480 Team wiki: 2013T1 Kungfu Panda Schedule Metrics|<b>Bug Metric''</b>]]
 
+
*[[IS480 Team wiki: 2013T1 Kungfu Panda Schedule Metrics|<b>Happy Metric''</b>]]
 
|-
 
|-
 
|Meeting Minutes
 
|Meeting Minutes
Line 163: Line 225:
  
 
|-
 
|-
|rowspan = "3"|Design
+
|rowspan = "2"|Design
 
|ER Diagram
 
|ER Diagram
 
|align = "left"|
 
|align = "left"|
Line 169: Line 231:
  
 
|-
 
|-
|General Architecture Diagram
+
|Project Architecture Diagram
 +
|align = "left"|
 +
*[[IS480 Team wiki: 2013T1 Kungfu Panda Project Scope|<b>Project Architecture Diagram''</b>]]
 +
 
 +
|-
 +
|rowspan = "5"|Testing
 +
|Informal Testing with Client
 +
|align = "left"|
 +
*[[IS480 Team wiki: 2013T1 Kungfu Panda User Testing|<b>Informal Testing''</b>]]
 +
 
 +
|-
 +
|Deployment Exercise with IS419 Class
 
|align = "left"|
 
|align = "left"|
*[[IS480 Team wiki: 2013T1 Kungfu Panda Project Overview|<b>General Architecture Diagram''</b>]]
+
*[[IS480 Team wiki: 2013T1 Kungfu Panda UT2|<b>Deployment Exercise''</b>]]
  
 
|-
 
|-
|Branch Teller Architecture Diagram
+
|User Tests
 
|align = "left"|
 
|align = "left"|
*[[IS480 Team wiki: 2013T1 Kungfu Panda Project Scope|<b>Branch Teller Architecture Diagram''</b>]]
+
*[[IS480 Team wiki: 2013T1 Kungfu Panda UT3|<b>User Test 1''</b>]]
 +
*[[IS480 Team wiki: 2013T1 Kungfu Panda UT4|<b>User Test 2''</b>]]
 +
*[[IS480 Team wiki: 2013T1 Kungfu Panda UT5|<b>User Test with OCBC Branch Manager''</b>]]
  
 
|-
 
|-
|rowspan = "3"|Testing
+
|UAT with Client
|UT 1 - Informal Testing
 
 
|align = "left"|
 
|align = "left"|
*[[IS480 Team wiki: 2013T1 Kungfu Panda User Testing|<b>User Testing 1''</b>]]
+
*[[IS480 Team wiki: 2013T1 Kungfu Panda UAT1|<b>UAT''</b>]]
  
 
|-
 
|-
|UT 2 - Deployment Exercise
+
|Software Testing
 
|align = "left"|
 
|align = "left"|
*[[IS480 Team wiki: 2013T1 Kungfu Panda UT2|<b>User Testing 2''</b>]]
+
*[[IS480 Team wiki: 2013T1 Kungfu Panda Software Testing|<b>Back End Services Testing (SOAP UI)''</b>]]
 +
*[[IS480 Team wiki: 2013T1 Kungfu Panda Software Testing|<b>End to End Testing''</b>]]
 +
 
 
|-
 
|-
 +
|rowspan = "3"|Handover
 +
|BIAN
 +
|align = "left"|
 +
*Proprietary & Confidential
 +
*Handed over to Client
 +
 +
|-
 +
|Front End Code
 +
|align = "left"|
 +
*Client Server & SMU Violet SVN
 +
 +
|-
 +
|Back End Code
 +
|align = "left"|
 +
*Client Server & SMU Violet SVN
 
|}
 
|}
 +
 +
=== <u>Quality</u> ===
 +
The architecture of the Branch Teller System is built upon the design principles aligned to the goals of SMU tBank – as a research and educational tool. We discovered early in our market research that mainstream Branch Teller systems were cumbersome and unintuitive. The Branch Teller System is designed with usability in mind, which reduces customer onboarding time and increases productivity of the user. <br/>
 +
 +
As the Branch Teller is likely to be further refined and improve upon by future teams to remain relevant and effective as a research and educational tool, we designed our Branch Teller System to be maintainable, extensible and configurable.The SMU tBank Core Services (back-end) is designed around Service-Oriented Architecture principles, allowing it’s functionality to be exposed as services. We have also placed consideration on other vital quality attributes  such as security, testability, reliability which are necessary in a Banking environment.
 +
<br/>
 +
'''Usability'''<br/>
 +
Our branch teller web application has several features to enhance a user’s experience:
 +
*Single-Page Design - slick UI without having to refresh after each click!
 +
*Front-end validation for every field - so users can be assured they won’t submit sensitive information wrongly!
 +
*Strong usage of visual effects to guide the user
 +
*Page caching - quicker loading of commonly used pages
 +
*Minimal clicks - for easier page to page navigation
 +
*Fully tab-traversable - so your hands never have to leave the keyboard!
 +
*Instructions and hints for first time users - Tool tips to reduce learning curve for first-time users and remind application users of banking domain knowledge
 +
<br/>
 +
'''Maintainability/Extensibility'''<br/>
 +
*We have structured our packages in our Branch Teller Java Deployment with a specific naming hierarchy, ‘Domain.SubDomain.Action’. For example the service ‘Party Customer Read’ integration code is stored in the package ‘teller.party.customer.read’. By following this package naming convention, integration code for a particular service and be easily identified, even if the number of services rapidly increases.
 +
*Using TIBCO as our middleware for process orchestration, the business logic of SMU tBank’s core services can be modified easily through a GUI interface.
 +
*Any modification to the existing credit engine rules can be made in a single ‘rules’ file. In addition, this file is stored within a centralized Rules Repository, which caters for versioning and remote management of different rule packages. This will allow future teams to easily add new Rule Packages for future decision services such as ‘Marketing Decision Services’ as well as manage different versions of existing rule packages.
 +
<br/>
 +
'''Reliability'''<br/>
 +
*SMU tBank’s services are used across many banking channels (ATM, Internet, Branch Teller etc).  SMU tBanks’s Account and Transaction TIBCO services are designed to prevent any isolation violations which may occur in a multi-user environment. Ensuring that the integrity of SMU tBank’s account and transaction data is maintained during scenarios where one account is involved in many transactions across the different banking channels.
 +
<br/>
 +
'''Security'''<br/>
 +
*Our application uses a cryptographic hash function (SHA1) to hash passwords of both Tellers and Administrators. This ensures that the passwords are not divulged in an event that database of the application is hacked.
 +
*At the same time, our systems ensures that a single user account can only be logined at a single computer. Login sessions that comes before the latest login would be invalidated, to prevent an account from being accessed by multiple users and also warns existing users when their current session is being invalidated
 +
*Our system also checks the authenticity of the user’s existing session before execution of any server functions.
 +
<br/>
 +
'''Testability'''<br/>
 +
We have implemented a suite of tests to quickly identify any defects in our system that could arise from modification of related components/services.<br/>
 +
*SOAP UI Tests - We have instituted 30 SOAPUI Test Cases to test the integrity of our back end SOAP services.  This is done by using pre-defined SOAP Requests to invoke the back-end services and comparing the SOAP Response with expected output.
 +
*Html Unit Tests - HtmlUnit is an automated testing tool kit. In a matter of 3 minutes, it is able to perform tasks (stimulating a browser) on the user interface which covers critical features of our application.
 +
<br/>
 +
'''Configurability'''<br/>
 +
*Our credit scoring engine utilizes different weightages and thresholds to determine one’s credit score. These weightages and thresholds of the credit engine used in the credit approval flow can be edited via an external ‘properties’ file without having to recompile the project. Saving future teams time when calibrating the credit engine.
 +
<br/>
 +
 
=== <u>Deployment</u> ===
 
=== <u>Deployment</u> ===
 
The following Branch Teller '''Functionalities''' have been deployed in the SMU tBank Server: <br/>
 
The following Branch Teller '''Functionalities''' have been deployed in the SMU tBank Server: <br/>
These represent 17 of 18 core functionalities.<br/>
+
[[Image:KP FinalFunction1.PNG|965x469px|center]]
- Party Create<br/>
+
[[Image:KP FinalFunction2.PNG|964x200px|center]]
- Party User PIN Create<br/>
+
 
- Party Read & Update<br/>
+
 
- Customer's Accounts Dashboard<br/>
+
 
- Account Deposit Read & Update<br/>
 
- Account Loan Create<br/>
 
- Manage Customer's Loan Accounts<br/>
 
- Account Loan Read & Update<br/>
 
- Transaction Deposit<br/>
 
- Transaction Withdrawal<br/>
 
- Transaction History Read<br/>
 
- Payment Credit Transfer Bill Payment<br/>
 
- Payment Loan Repayment Full<br/>
 
- Payment Loan Repayment Partial<br/>
 
  
 
The following Back End '''Services''' have been deployed in the SMU tBank Server: <br/>
 
The following Back End '''Services''' have been deployed in the SMU tBank Server: <br/>
These represent all 17 SMU Core Services.<br/>
+
[[Image:KP FinalService1.PNG|966x368px|center]]
- Party Customer Create<br/>
+
[[Image:KP FinalService2.PNG|962x371px|center]]
- Party Customer Read<br/>
 
- Party Customer Update<br/>
 
- Party Customer Read IC<br/>
 
- Account List Read<br/>
 
- Account Deposit Create<br/>
 
- Account Deposit Read<br/>
 
- Account Deposit Update<br/>
 
- Account Loan Create<br/>
 
- Account Loan Read<br/>
 
- Account Loan Update<br/>
 
- Transaction Deposit<br/>
 
- Transaction Withdrawal<br/>
 
- Transaction History Read<br/>
 
- Payment Credit Transfer Create<br/>
 
- Transaction FullLoanRepayment Create<br/>
 
- Payment Loan Repayment Partial<br/>
 
  
 
=== <u>Testing</u> ===  
 
=== <u>Testing</u> ===  
==== UT 1 (informal)====
+
Link to our [https://wiki.smu.edu.sg/is480/IS480_Team_wiki:_2013T1_Kungfu_Panda_User_Testing Our User Testing]
User testing 1 is an informal testing with our client, Professor Alan and IS419 Instructor, Instructor Arul.
+
==== Client Testing====
<br/><br/>
+
Link to our [https://wiki.smu.edu.sg/is480/IS480_Team_wiki:_2013T1_Kungfu_Panda_User_Testing Informal Testing with Client]
'''Date Conducted'''<br/>
 
* 20 Sep 2013
 
'''Objective'''<br/>
 
* Test whether the current application is functional
 
* The usability of the application to suit a branch teller <br/>
 
''' Participant'''
 
* Client (Professor Alan)
 
* Instructor Arul
 
'''Method'''<br/>
 
* Users left to execute tasks on their own without any help
 
* Observation by team members
 
  
'''Test Scenarios'''<br/>
+
====Deployment Exercise====
# Create Customer <br/>
+
Our team have conducted this Deployment Exercise together with the two other FYP SMU tBank teams. The objective of this exercise is to utilize our Branch Teller Application in a classroom setting as a lab exercise and to test the usability of the application. This exercise was conducted in the IS419: Retail Banking class with 45 students. The lab was lead by Instructor Arul. So the students do their lab exercise in class and our team members will walk and observe some users through the whole lab exercise.<br/>
# Update Customer Details <br/>
+
More details can be found by clicking the link below.<br/>
# Create Deposit Account <br/>
+
Link to our [https://wiki.smu.edu.sg/is480/IS480_Team_wiki:_2013T1_Kungfu_Panda_UT2 Deployment Exercise]
# Update Deposit Account <br/>
 
# Create Loan Account <br/>
 
# Update Loan Account <br/>
 
# Customer Read (By NRIC and Customer ID) <br/>
 
  
''' Test Results''' <br/>
+
====User Testing====
Observations and Feedbacks <br/>
+
Our team did 2 User Test on 25 Oct and 8 Nov respectively <br/>
* Leading Zeroes for Account Numbers
+
Link to our [https://wiki.smu.edu.sg/is480/IS480_Team_wiki:_2013T1_Kungfu_Panda_UT3 Our UT 1 Results]<br/>
* Make drop-down lists un-editable after selection
+
Link to our [https://wiki.smu.edu.sg/is480/IS480_Team_wiki:_2013T1_Kungfu_Panda_UT3 Our UT 2 Results]
* PIN Number
+
<br/><br/>
 +
The objective of the user test is to test
 +
*The usability of the application
 +
*Measure the time required for each test cases
 +
*To see the learning curve of our application
 +
<br/>
 +
For each User Test, we invited 30 SMU students from different schools to be our user and these users are all first time users.<br/>
 +
The users are left to execute the task while our team member observe and time them.<br/>
 +
<br/>
 +
The scope we covered for these two User Test are: <br/>
 +
#Create Customer and Update Customer Details
 +
#Create and Update Deposit Account
 +
#Create and Update Loan Account
 +
#Deposit & Withdrawal
 +
#Bill Payment
 +
#Overview and create Ibanking Account
 +
#Customer View (by NRIC and Customer ID)
 +
#Transactions (Partial & Full Loans)
 +
#View Transaction History
 +
#Direct Debit Authorisation
 +
#Update Customer Details
 +
<br/>
 +
'''Time Result''' <br/>
 +
This is the average timing we have collated for our UT 1 and UT 2 for each individual test case.<br/>
 +
Our Team have notices that after making the change suggested in UT 1 by our users, the timing for UT 2 is faster as compared to UT 1.<br/>
 +
[[Image:KP UTAvgTiming.PNG|753x299px]]<br/>
 +
<br/>
 +
From the timing we have collated, we have also noticed that users tend to be faster at conducting a task they had done before. <br/>Therefore, our application have a low learning curve, allowing users to familiarise the application very easily.
 +
<br/>
 +
[[Image:KP UTTimeDiff.PNG|495x410px]]
 +
<br/><br/>
 +
'''Subjective Feedback''' <br/>
 +
This is the subjective feedbacks we have received from both UT 1 and UT 2. <br/>
 +
The score given were in the range of between 4 to 4.5, where <br/>
 +
Score of 5 means: '''Very Easy and Very Good''' <br/>
 +
Score of 1 means: ''' Very Difficult and Very Bad'''<br/>
 +
[[Image:KP SubjectiveFeedback.PNG|526x304px]]
 +
<br/>
 +
'''Overall Comments''' <br/>
 +
* Information is well organised and legible
 +
* Fast and Responsive, Simple Design, Clear sections on left menu
 +
* Clean cut, Simple, Neat layout
 +
* The notification pop-up is useful
 +
*Colours are soothing to the eyes, and fonts are appropriate for such applications
  
====UT 2: Deployment Exercise====
 
Our User Testing 2 is a joined deployment exercise conducted with the two other SMU tBank teams. Together with FYP teams Ironmen, Bankrevels  and the Instructor of IS419 class, Instructor Arul, we created the lab for the students from the IS419: Retail Banking class. Student were pair up to perform a role play, following the tasks they have in the lab. The whole lab was to be completed in 90min, where 30min was mainly in the Branch Teller Application.
 
 
<br/>
 
<br/>
'''Date Conducted'''<br/>
+
'''Changes'''<br/>
* 2 Oct 2013
+
* Changes made to the color and we have also bold the words to make it clearer.<br/>
'''Objective'''<br/>
+
[[Image:KPChange-Color.PNG|border|346x315px]]<br/><br/>
* Utilize Branch Teller Application in a classroom setting as a lab exercise
+
* We have added instructions, so users are clear that the password have to be 6 numerical.<br/>
* The usability of the application  
+
[[Image:KPChange-Password.PNG|border|607x159px]]<br/><br/>
'''Test Scenarios'''<br/>
+
* Checkbooxes are also added to the toggle filter<br/>
 +
[[Image:KPChange-Filter.PNG|border|538x317px]]<br/><br/>
 +
* We have added one more button to lead the teller to the Teller Main Menu.<br/>
 +
[[Image:KPChange-Logout.PNG|border|204x349px]]<br/><br/>
 +
* Tip boxes with instructions help users with the application<br/>
 +
[[Image:KPChange-TipBox.PNG|border|396x351px]]<br/>
 +
<br/>
 +
'''User Test with OCBC Branch Manager'''<br/>
 +
Our team have also managed to do our user test with a Branch Manager of OCBC.<br/>
 +
He did the user test and gave us some feedbacks on our application as a whole <br/>
 +
<br/>
 +
*Customer may use different terms as the Branch Teller
 +
*We can have an explanation for some fields
 +
*Never consider different currencies and rate
 +
*Really easy interface and simple
 +
<br/>
  
#Create Customer and Update Customer Details<br/>
+
====UAT====
#Create and Update Deposit Account<br/>
+
At the end of our whole project, our team did a User Acceptance Test with our client to test whether the application is functional and
#Create and Update Loan Account<br/>
+
that proper validation for each fields are correct.<br/> This test cover all the requirement our client have given to us.<br/>
#Customer Read (by NRIC and Customer ID)<br/>
+
We are glad to pass all the task cases. More details can be found by clicking the link below.
#Create Customer Login Details<br/>
+
<br/>
#Customer Dashboard<br/>
+
Link to our [https://wiki.smu.edu.sg/is480/IS480_Team_wiki:_2013T1_Kungfu_Panda_UAT1 UAT with Client]
  
''' Participants'''
+
== <div style="background: #FFD801; padding: 15px; font-weight: bold; line-height: 0.3em"><font color= #FFFFFF>Reflections</font></div>==
*45 students from the IS419: Retail Banking class <br/>
+
=== <u>Team Reflection</u> ===
'''Method'''
+
Most of us have heard about the quintessential proverb that refers to teams, “If you want to go fast, go alone.  But if you want to go far, go together”.  In this Final Year Project, this proverb really sums up the biggest take away as a team.  Most would expect in SIS that students would learn about computer systems and hard skills, and perhaps it is apt that our FYP experience debunks this severely lacking assumption.  The close proximity and working relationships we’ve forged over the duration of this project have caused us to bond together like a family.  As with all families, it augurs well for getting out a quality product due to team chemistry.  But there’s also disagreements, fights and differences in opinions that result because of a collective ownership that also takes place on a deeply personal level.  At the end, it’s about recognizing the common denominator we all share as teammates, comrades and brothers (and sisters) in arms, we’re here to journey together in making SMU tBank a success.<br/>
* Lab exercise constructed by 3 FYP teams + Instructor Arul
+
[[Image:KP-TeamPiclong.PNG|436x128px|centre]]
* Scant instructions, just enough to get them where they need to be to perform tasks without help
 
* Students would role play in pairs as a branch teller and a customer
 
  
''' Test Results''' <br/>
+
<br/>
During the deployment exercise, members from our team have gather some observations they had and also some feedbacks from the students in the class. <br/>
 
<br/>Observations & Feedbacks <br/>
 
* Address Field needs to accept > 50 characters
 
* Users would accidentally exit out of the form and filled form data would be lost
 
* Customer Overview page “collapses” on itself in windowed mode
 
* Confusion in Naming Convention:'Create Loan Account' instead of 'Create a Loan'
 
* Easy to use
 
  
== <div style="background: #FFD801; padding: 15px; font-weight: bold; line-height: 0.3em"><font color= #FFFFFF>Reflections</font></div>==
+
=== <u>Individual Reflections</u> ===
=== <u>Team Reflection</u> ===
+
'''Geraldine Koon''' (Project Manager)<br/>
Our team has taken to heart 3 main learning points:
+
Through IS480, I learnt that in a project, everyone really needs to work closely together regardless of the different working style each member has. Things may not work out very well at the start, however, as we work along with one another strong points and help each another with our weak points, we will be able to progress well together. Also in this project, I realized that progress is impossible without changes. With all the feedback we received from our client and user testing, I see that the changes we made have improved our application, becoming a much better application as we progress.
 +
<br/>All in all, I am very glad that my team have managed to come so far together and it is definitely a very memorable experience.
  
'''1. Doing Our Best Together'''<br/>
+
<br/>
As our supervisor, Professor Richard Davis, mentioned to us at our first meeting, "What you put in, is what you will get out of FYP"Our team has been doing our best, putting in our blood, sweat and tears for this project to see it become a success. It is easy for one to accomplish tasks fast individually, but put that in the context of a team, with different expectations and personalities, and it becomes a different ball game altogether. The time spent in the trenches together, meals together have taught us, "If you want to go fast go alone, but if you want to go far, do it together."
+
'''Jonathan Ho''' (Business Analyst)<br/>
 +
One of the key tenets of the popular 7 Habits of Highly Effective People deals with beginning with the end in mind.  Throughout the project, I learnt in my primary role as a Business Analyst that a problem well defined was half the problem solved.  The team needed to to have a common idea and vision of our deliverables and end product with our client, and defining the requirements was a key factor to our team’s completion.  After all, you can’t build something if you don’t know what you’re building right?  But moving towards the finals from the midterms was a vastly different “ballgame”, where the team was already aligned with our client, and the bigger challenge was persevering on to seeing things to completionKeeping team morale up and remembering our end in mind was essential in motivating a continued and sustained push towards the end to deliver our final product.
 +
<br/>
 +
<br/>
 +
'''Zhu Juntao''' (Quality Assurance)<br/>
 +
Through IS480, I have learnt that building a robust UI and having a structured testing methodology is crucial to the survivability and maintainability of a banking system. The user interface has to be the first line of defence, ensuring data validation. At the same time, it must also be able to catch different types of error that is thrown by the backend. This includes crashing of the server and various types of error messages returned by the server.
 +
<br/>
 +
A structured testing methodology ensures that the future modifications would not break existing functions. In this process, I have come into touch with automated test tool kits such as HtmlUnit and Phantom JS, eventually choosing HtmlUnit which integrates better with our IDE (NetBeans).
 +
<br/>
 +
Lastly, IS480 has given both technical and soft skills that will go a long way with me in life.
  
'''2. Collegiality & Thinking Win-Win'''<br/>
+
<br/>
Helping to build the SMU tBank as an FYP is very different from a "ring-fenced" FYP project. Our team has had to cooperate, interact and coordinate with 2 other FYP teams, Senior Lecturer Alan and his ESB team on a much higher and intense level.  Where others have exclusive clients, or have projects that are not interdependent, we had to grapple with the conflict of interests with a larger pool of stakeholders.
+
'''James Lim''' (Usability Engineer)<br/>
However, our team took to heart Professor Benjamin Gan's intention and desire for a sharing and learning environment in SIS, especially for the IS480 FYP course. We learnt that thinking of the bigger picture and considering other team's interests helped build collegiality spirit. Where there are competing interests, we learnt thinking win-win, negotiating and coming up with alternatives helped create even better solutions.
+
During the period of IS480, I have learnt much how challenging a Core Banking Project can be. Though it is developed within a sheltered environment, the technologies used are of relevance. TIBCO and Java is widely used in the banking industry, and HTML5 is becoming very powerful and useful in today's web technologies. Combining both to create a vanilla Bank Teller Application has been very intriguing, a back-end based on traditional banking technologies and a front-end using the latest of web technologies, it perhaps, might be the new way of doing a Teller application, where most systems today are easily decades old. To do this, myself and the team, ensured that the ideals are guaranteed is just as important as keeping ourselves grounded on what can or cannot be done. I learnt how important the external environment can be; I and the team made it clear to be open to suggestions from people and the internet, ideas from our testers were considered on a very open process and applied to the project. The same can be said from the internet, where we kept a lookout to see what we can use in our project. All of this have contributed to a project we have pride in and where I have learnt a great deal from.
  
'''3. Communicate Effectively'''<br/>
+
<br/>
Our team learnt that to communicate effectively with a major stakeholder such as our client, it was to our favour and benefit to spend more time with our client.  We were originally hesitant as we felt that there would be an increase in the amount of changes made to the application.  However, we recognized that it was a common interest to build a quality application and do well for IS480.  Our team now spends an increased 4 - 6 hours a week in addition to our weekly client meetings to know our client more and work with him.  Also, we learnt that the longevity of the branch teller application was a major consideration factor, as such our team has decided to document our back end services using BIAN (Banking Industry Architecture Network) templates.
 
 
 
=== <u>Individual Reflections</u> ===
 
'''Geraldine Koon''' (Project Manager)<br/>
 
Motivation is very important to the team. Being the project manager, I feel that it is not all about managing the schedule but also ensuring the team member's well-being is essential for the team to continue working hard and stay focus. Therefore, keeping the team with a positive attitude will motivate the team as we drive our project.
 
<br/><br/>
 
'''Jonathan Ho''' (Business Analyst)<br/>A problem well defined is half the battle won. In every IT project, before we embark on developing something it is important to know what we are building in the first place. Being unclear on defining user requirements will result in many last minute changes and client dissatisfaction.
 
As a Business Analyst, communication is also key to ensure our FYP team was on the same page as our client and supervisor. Although at times it is tiring having to go through the little details repeatedly, sometimes reiterating will help reinforce and re-affirm ideas and requirements. Not all communication mediums have the same effectiveness as well, due to the busy schedules of all our stakeholders and team members, nothing beats sitting down with the person face to face. After all, it also helps to foster and build a sense of goodwill and relationship.  People orientation and communication are key even in a technical, task-oriented FYP project.
 
<br/><br/>
 
'''Zhu Juntao''' (Usability Engineer)<br/>
 
An enhanced user experience is a combination of all the nitty-gritty details that are often overlooked during the scoping of the project. These nitty-gritty details often take more time than expect and is taken for granted. However, it is the responsibility of the Usability Engineer to take note of these minor details rather than saying 'I will fix them later'.
 
<br/><br/>
 
'''James Lim''' (Quality Assurance)<br/>
 
Time must be effectively prioritized and spent. Furthermore, being productive may not necessarily be attributed to spending more time on the project. Work has to be efficiently and smartly done. Working on the Front-end and Testing the application is also notoriously time-consuming and difficult. Proper techniques such as doing unit-testing and batch-testing at once are essential to doing things speedily. Being clear and letting the team know any issues with the application an how we can move forward is important, blame is not attributed to one person working on a particular part, but rather, responsibility is shared by all; this has been the mentality of our team.
 
<br/><br/>
 
 
'''Kevin Ng''' (Lead Developer)<br/>
 
'''Kevin Ng''' (Lead Developer)<br/>
Developing IT systems require a mixture of business and technical knowledge. Research is needed to understand domain specific knowledge on different financial products and and financial formulas.
+
The journey through IS480 developing the SMU tBank's Branch Teller was challenging but satisfying. Although we got off to a somewhat rocky start, it was encouraging to see the team improve rapidly as the weeks progressed. I took a few key takeaways from this experience.
Systems must not only be developed for the present but to cater for the future as well. Non-functional quality attributes such as maintainability, modifiability and resilience should be taken into account. Documentation is also just as important to transfer the knowledge we have learnt for future developers of our system. Besides system architecture and development principles, a strong governance framework is needed to ensure the success of multi team projects during design time and run time.
+
<br/>
 +
Firstly, a good understanding of domain knowledge is essential to develop an effective system. In our case, market research and learning about retail banking products and processes helped us greatly when designing the Branch teller System.
 +
<br/>
 +
Secondly, it's important that we design our code with extensibility and modifiability in mind. This will assist future teams to improve upon our foundation to ensure SMU tBank remains a relevant and effective teaching and educational tool.
 +
<br/>
 +
Finally, looking back at my team's entire FYP journey, my team has faced many challenges both technical and non-technical. I learnt that many  challenges can be overcome by perseverance and optimism. For example, after many attempts, we finally managed to secure an expert user to test our Branch Teller System. Many technical challenges we faced can also be overcome with a mindset of perseverance and optimism.
 
<br/><br/>
 
<br/><br/>
 
'''Tan Yao Guang''' (System Analyst)<br/>
 
'''Tan Yao Guang''' (System Analyst)<br/>
Perseverance and a lot of trying will be required to learn new technologies; People have very different feedback on a particular interface, based on their own personal experience of similar systems or pages. Having industry benchmarks or systems that we can measure our application would really help in evaluating the effectiveness of our design, so as to not waste implementation efforts should changes come about in future.
+
As a developer in the team, I have learnt many technical skills ranging from developing using third party libraries like Drools, to using a GUI development environment (TIBCO). But then there were the other skills that I got to learn as well - there was the creating of a credit engine from scratch. This required us to do an extensive amount of research to find out how credit scoring was done in the industry, as well as finding out average loan amounts etc. These skills were not technical in nature and hence was a great add-on to the skills learnt for myself from this project.
 +
<br/>
 +
 
 +
<br/>
 +
 
 +
=== <u>Sponsor Comment</u> ===
 +
[[Image:KP-SponsorComment.PNG|564x194px]]
 +
 
 +
== <div style="background: #FFD801; padding: 15px; font-weight: bold; line-height: 0.3em"><font color= #FFFFFF>Project Future</font></div>==
 +
===Client's Vision===
 +
“It’s the start of something new and exciting, we will not be stopped”
 +
<br/>
 +
- Senior Lecturer Alan Megargel
 +
<br />
 +
<br />
 +
'''Continuing the Conceptual & Engagement Models'''
 +
<br />
 +
Our team has gotten the ball rolling and in the future our client will be continuing to:
 +
*Add more SMU Core Services that expose functionalities of off-the-shelf banking products from leading software vendors
 +
*Add more Banking Applications and channels developed by SMU SIS undergraduate students to consume reusable services
 +
*Allow MITB classes to utilise Solution Architecture as a case study for Service Oriented Architecture
 +
*Further collaborate with banks and product vendors to incubate new innovations
 +
<br />
 +
Next semester, Corporate Banking channels and services will be added on to existing Retail Banking components.
 +
 
 +
===BIAN Documentation===
 +
[[Image:KP_BIANlogo.jpg]]
 +
<br />
 +
To facilitate and ensure the longevity of the back end services that we have built, our team has utilised the Banking Industry Architecture Network (BIAN) Documentation Template to document our back end services.
 +
<br />
 +
<br />
 +
SMU SIS is the first academic partner of BIAN, and our team was the first to leverage on this to conform our documentation to industry best practices.
 +
<br />
 +
<br />
 +
BIAN Documentation ensures our documentation is benchmarked with industry best practices for quality and standardised using the same banking jargon for future teams to pick up and understand the inputs, outputs and preconditions of our services.
 +
<br />
 +
<br />
 +
As this documentation or proprietary, please approach Senior Lecturer Alan Megargel if you are interested in learning more and participating in the goal to build SMU tBank.

Latest revision as of 14:24, 25 November 2013

KP-NewHeader.PNG



Main WikiKP-Main Wiki Link.PNG
KP-WithClient2.PNG

Project Progress Summary

Final Presentation Slides Download!
Link to our Branch Teller Application: http://10.0.106.169:8080/SMUtBank_Teller/


After 2620.5 working man hours over 32 weeks / 222 days (29 April - 6 December), our team, Kungfu Panda, has finally come to the end of our Final Year Project.

Project Achievements

  • Built a user friendly Branch Teller Web Application
  • Used Service Oriented Architecture Principles to build reusable SMU tBank Core Services
  • Completed 2 X-Factors - Credit Approval (Engine & Teaching Tool), and Usability
  • Ensured software quality via Software Testing (SOAPUI, HTMLUnit)
  • Tested & validated our project via 5 Tests (Classroom Lab, User Tests etc.)
  • Facilitated project extension and longevity through BIAN Documentation


Project Challenges

  • Working in a collaborative, co-dependent space with 2 other FYP teams - Bankrevels & ironMEN
  • Difficulty obtaining expert feedback from real Branch Tellers


Overcoming Project Challenges

  • Streamline and formalise lines of communication through common client when working with other FYP teams
  • Pursuing all avenues to obtain expert feedback and domain knowledge


Project Highlights

  • Recommendation of BRMS to survey (FICO, Jess, Drools) for Credit Engine with Steven Nunez (21th May 2013)
  • Interview with Xiao Xiang, OCBC's Head of Credit Research (6th November 2013)
  • User Test with Cyril Chia, OCBC Frank's Regional Branch Manager (7th November 2013)


Project Management

Project Status

Our project is 100% completed in terms of developmental tasks
The below diagram shows a coloured diagram / map of development tasks that are completed and outstanding.
Percentage of Development Tasks Complete = Number of Completed Tasks (in Green) / Total Number of Tasks
924×490px 927×428px

Project Milestone

KP Milestone Table.PNG
KP FinalFinalMilestone.PNG
Our Updated Project Schedule Download!

Project Schedule (Planned Vs Actual)

Major Changes in Project Scope
From the beginning of our project, we have added to our scope the following:

  • 1 Branch Teller Functionality
    • Party User PIN Create
  • Integration of 8 Services
    • Party_Login_Create
    • Party_Login_Read
    • Account_Status_Update
    • Payment_DirectDebitAuthorization_Delete
    • Product_LoanFullRepayment_Calculate
    • Product_LoanPartialRepayment_Calculate
    • Product_LoanInstallment_Calculate
    • Currency_Read_List


We have also dropped 2 Branch Teller Functionalities:

  • Upload Documents
  • Read Documents


And, we have chosen to not take on proposed changes from our client:

  • 2 Branch Teller Functionalities
    • Payment Standing instruction
    • Manage Customer Beneficiaries
  • Integration of 8 Services
    • Payment_Standing_Instruction_Create
    • Payment_Standing_Instruction_Read
    • Payment_Standing_Instruction_List_Read
    • Payment_Standing_Instruction_Update
    • Payment_Standing_instruction_Delete
    • Payment_Beneficiary_List_Read
    • Payment_Beneficiary_Create
    • Payment_Beneficiary_Delete


In addition, for a full list of all major and minor changes, please download our schedule to view the "Changes Made" Spreadsheet here.
For a full list of major and minor changes as a result of User Test feedback and expert opinion from Branch Managers and Bank executives, please view our User Test wiki pages: UT1, .UT2, and ExternalUT

Impact in Project Plan
As a result of adding to our project scope, our project showed signs of falling behind schedule when our Hours Differed Metric hit 48.50 hours in Iteration 8. This meant our team was behind schedule by more than half a week in man hour terms. We decided to drop 2 functionalities in response to this as mentioned above. The metrics can be viewed further below in the wiki page.

Project Metrics

Scheduling Metrics

Schedule Metric
The objective of the Schedule Metric is to measure Degree of Accuracy in Forecasting Hours for Project Tasks
Schedule Metric Calculation = Actual Hours / Planned Hours

KP ScheduleMetric Plan.PNG
KP ScheduleMetric a.PNG
KP ScheduleMetric b.PNG
KP ScheduleMetric Inv.PNG
KP ScheduleMetric Team.PNG


Hours Per Week Metric
Our Hours Per Week Metric measures Amount of Workload on Individual Team Members
Hours Per Week Metric Calculation = Hours / Weeks in Iteration
Calculate Metrics for Old, New & Actual

KP HPW Plan.PNG
KP HPW a.PNG
KP HPW b.PNG
KP HPW graphNew.PNG


Hours Deferred Metric
The objective of this metric is to measure number of hours planned for tasks that were incomplete and moved to another iteration due to project changes.
Together with Schedule Metric determines health of project.
Hours Deferred Metric Calculation = No. of Hours Deferred

KP HrDeferred Plan.PNG
KP HrDeferred Result.PNG
KP HrDeferred Graph.PNG



Bug Metrics

Bug Metric for FYP Week 30: 0 KP-GoodBugMetric.PNG
Below shown are the latest 25 bugs our team have encountered and is recorded in our Bug Tracker.
http://kfpbugtracker.no-ip.org/webissues

KP BugTrackerFinal.PNG


KP-BugMetricsNew2.PNG


KP-BugMFormula.PNG


KP BugMetric-a.PNG


KP BugMetric-b.PNG


KP BugMetric-c.PNG


Happiness Metric

KP-HappyMetirc.PNG
KP-HappyMetircScale.PNG


KP Happy Metric New.PNG

Technical Complexity

Frontend Complexity

KP-Frontend Complexity.PNG


Backend Complexity

Summary of Complexities Faced

  1. Data Integrity
    1. Ensured that insert statements made to the databases were ordered (serialized)
    2. Handled error flow should a transaction violation error occur
  2. Finance Formulas
    1. Had to research on finance formulas and understand the time value of money in order to complete this task
    2. Translated finance formulas (annuity formula) into Java code to be used in the Loan creation process
  3. Business Logic Errors
    1. Used XPath formulas within Tibco Designer to check for conditions such as insufficient balance or no such account and what to do subsequently
  4. Business Process Flow
    1. Entire business logic of the core banking systems is programmed inside the back-end services
    2. Deciding the order of events (which should come first etc.) in terms of business requirements was a key consideration in the design as well



Development using Tibco Enterprise Messaging Service (EMS)
Tibco Enterprise Messaging Service is a middleware product that implements the Java Messaging Service (JMS). Its flexible architecture helps simplify operational complexity by supporting the communication with a wide variety of technologies so that businesses can focus on the development and refinement of business requirements.

To develop on the EMS, our team had to use a sister product of Tibco, the Tibco Designer. This is a GUI-based developmental interface that allows developers to minimise coding whilst maintaining a high level of efficiency in capturing business process logic.

Sample Service: Transaction_PartialLoanRepayment_Create Sample-core-services-complicated.png

Quality of Application

Project Deliverables

Stage Specification Modules
Project Management Project Scope
Progress Overview
Risks
Metrics
Meeting Minutes
Design ER Diagram
Project Architecture Diagram
Testing Informal Testing with Client
Deployment Exercise with IS419 Class
User Tests
UAT with Client
Software Testing
Handover BIAN
  • Proprietary & Confidential
  • Handed over to Client
Front End Code
  • Client Server & SMU Violet SVN
Back End Code
  • Client Server & SMU Violet SVN

Quality

The architecture of the Branch Teller System is built upon the design principles aligned to the goals of SMU tBank – as a research and educational tool. We discovered early in our market research that mainstream Branch Teller systems were cumbersome and unintuitive. The Branch Teller System is designed with usability in mind, which reduces customer onboarding time and increases productivity of the user.

As the Branch Teller is likely to be further refined and improve upon by future teams to remain relevant and effective as a research and educational tool, we designed our Branch Teller System to be maintainable, extensible and configurable.The SMU tBank Core Services (back-end) is designed around Service-Oriented Architecture principles, allowing it’s functionality to be exposed as services. We have also placed consideration on other vital quality attributes such as security, testability, reliability which are necessary in a Banking environment.
Usability
Our branch teller web application has several features to enhance a user’s experience:

  • Single-Page Design - slick UI without having to refresh after each click!
  • Front-end validation for every field - so users can be assured they won’t submit sensitive information wrongly!
  • Strong usage of visual effects to guide the user
  • Page caching - quicker loading of commonly used pages
  • Minimal clicks - for easier page to page navigation
  • Fully tab-traversable - so your hands never have to leave the keyboard!
  • Instructions and hints for first time users - Tool tips to reduce learning curve for first-time users and remind application users of banking domain knowledge


Maintainability/Extensibility

  • We have structured our packages in our Branch Teller Java Deployment with a specific naming hierarchy, ‘Domain.SubDomain.Action’. For example the service ‘Party Customer Read’ integration code is stored in the package ‘teller.party.customer.read’. By following this package naming convention, integration code for a particular service and be easily identified, even if the number of services rapidly increases.
  • Using TIBCO as our middleware for process orchestration, the business logic of SMU tBank’s core services can be modified easily through a GUI interface.
  • Any modification to the existing credit engine rules can be made in a single ‘rules’ file. In addition, this file is stored within a centralized Rules Repository, which caters for versioning and remote management of different rule packages. This will allow future teams to easily add new Rule Packages for future decision services such as ‘Marketing Decision Services’ as well as manage different versions of existing rule packages.


Reliability

  • SMU tBank’s services are used across many banking channels (ATM, Internet, Branch Teller etc). SMU tBanks’s Account and Transaction TIBCO services are designed to prevent any isolation violations which may occur in a multi-user environment. Ensuring that the integrity of SMU tBank’s account and transaction data is maintained during scenarios where one account is involved in many transactions across the different banking channels.


Security

  • Our application uses a cryptographic hash function (SHA1) to hash passwords of both Tellers and Administrators. This ensures that the passwords are not divulged in an event that database of the application is hacked.
  • At the same time, our systems ensures that a single user account can only be logined at a single computer. Login sessions that comes before the latest login would be invalidated, to prevent an account from being accessed by multiple users and also warns existing users when their current session is being invalidated
  • Our system also checks the authenticity of the user’s existing session before execution of any server functions.


Testability
We have implemented a suite of tests to quickly identify any defects in our system that could arise from modification of related components/services.

  • SOAP UI Tests - We have instituted 30 SOAPUI Test Cases to test the integrity of our back end SOAP services. This is done by using pre-defined SOAP Requests to invoke the back-end services and comparing the SOAP Response with expected output.
  • Html Unit Tests - HtmlUnit is an automated testing tool kit. In a matter of 3 minutes, it is able to perform tasks (stimulating a browser) on the user interface which covers critical features of our application.


Configurability

  • Our credit scoring engine utilizes different weightages and thresholds to determine one’s credit score. These weightages and thresholds of the credit engine used in the credit approval flow can be edited via an external ‘properties’ file without having to recompile the project. Saving future teams time when calibrating the credit engine.


Deployment

The following Branch Teller Functionalities have been deployed in the SMU tBank Server:

KP FinalFunction1.PNG
KP FinalFunction2.PNG



The following Back End Services have been deployed in the SMU tBank Server:

KP FinalService1.PNG
KP FinalService2.PNG

Testing

Link to our Our User Testing

Client Testing

Link to our Informal Testing with Client

Deployment Exercise

Our team have conducted this Deployment Exercise together with the two other FYP SMU tBank teams. The objective of this exercise is to utilize our Branch Teller Application in a classroom setting as a lab exercise and to test the usability of the application. This exercise was conducted in the IS419: Retail Banking class with 45 students. The lab was lead by Instructor Arul. So the students do their lab exercise in class and our team members will walk and observe some users through the whole lab exercise.
More details can be found by clicking the link below.
Link to our Deployment Exercise

User Testing

Our team did 2 User Test on 25 Oct and 8 Nov respectively
Link to our Our UT 1 Results
Link to our Our UT 2 Results

The objective of the user test is to test

  • The usability of the application
  • Measure the time required for each test cases
  • To see the learning curve of our application


For each User Test, we invited 30 SMU students from different schools to be our user and these users are all first time users.
The users are left to execute the task while our team member observe and time them.

The scope we covered for these two User Test are:

  1. Create Customer and Update Customer Details
  2. Create and Update Deposit Account
  3. Create and Update Loan Account
  4. Deposit & Withdrawal
  5. Bill Payment
  6. Overview and create Ibanking Account
  7. Customer View (by NRIC and Customer ID)
  8. Transactions (Partial & Full Loans)
  9. View Transaction History
  10. Direct Debit Authorisation
  11. Update Customer Details


Time Result
This is the average timing we have collated for our UT 1 and UT 2 for each individual test case.
Our Team have notices that after making the change suggested in UT 1 by our users, the timing for UT 2 is faster as compared to UT 1.
KP UTAvgTiming.PNG

From the timing we have collated, we have also noticed that users tend to be faster at conducting a task they had done before.
Therefore, our application have a low learning curve, allowing users to familiarise the application very easily.
KP UTTimeDiff.PNG

Subjective Feedback
This is the subjective feedbacks we have received from both UT 1 and UT 2.
The score given were in the range of between 4 to 4.5, where
Score of 5 means: Very Easy and Very Good
Score of 1 means: Very Difficult and Very Bad
KP SubjectiveFeedback.PNG
Overall Comments

  • Information is well organised and legible
  • Fast and Responsive, Simple Design, Clear sections on left menu
  • Clean cut, Simple, Neat layout
  • The notification pop-up is useful
  • Colours are soothing to the eyes, and fonts are appropriate for such applications


Changes

  • Changes made to the color and we have also bold the words to make it clearer.

KPChange-Color.PNG

  • We have added instructions, so users are clear that the password have to be 6 numerical.

KPChange-Password.PNG

  • Checkbooxes are also added to the toggle filter

KPChange-Filter.PNG

  • We have added one more button to lead the teller to the Teller Main Menu.

KPChange-Logout.PNG

  • Tip boxes with instructions help users with the application

KPChange-TipBox.PNG

User Test with OCBC Branch Manager
Our team have also managed to do our user test with a Branch Manager of OCBC.
He did the user test and gave us some feedbacks on our application as a whole

  • Customer may use different terms as the Branch Teller
  • We can have an explanation for some fields
  • Never consider different currencies and rate
  • Really easy interface and simple


UAT

At the end of our whole project, our team did a User Acceptance Test with our client to test whether the application is functional and that proper validation for each fields are correct.
This test cover all the requirement our client have given to us.
We are glad to pass all the task cases. More details can be found by clicking the link below.
Link to our UAT with Client

Reflections

Team Reflection

Most of us have heard about the quintessential proverb that refers to teams, “If you want to go fast, go alone. But if you want to go far, go together”. In this Final Year Project, this proverb really sums up the biggest take away as a team. Most would expect in SIS that students would learn about computer systems and hard skills, and perhaps it is apt that our FYP experience debunks this severely lacking assumption. The close proximity and working relationships we’ve forged over the duration of this project have caused us to bond together like a family. As with all families, it augurs well for getting out a quality product due to team chemistry. But there’s also disagreements, fights and differences in opinions that result because of a collective ownership that also takes place on a deeply personal level. At the end, it’s about recognizing the common denominator we all share as teammates, comrades and brothers (and sisters) in arms, we’re here to journey together in making SMU tBank a success.

KP-TeamPiclong.PNG


Individual Reflections

Geraldine Koon (Project Manager)
Through IS480, I learnt that in a project, everyone really needs to work closely together regardless of the different working style each member has. Things may not work out very well at the start, however, as we work along with one another strong points and help each another with our weak points, we will be able to progress well together. Also in this project, I realized that progress is impossible without changes. With all the feedback we received from our client and user testing, I see that the changes we made have improved our application, becoming a much better application as we progress.
All in all, I am very glad that my team have managed to come so far together and it is definitely a very memorable experience.


Jonathan Ho (Business Analyst)
One of the key tenets of the popular 7 Habits of Highly Effective People deals with beginning with the end in mind. Throughout the project, I learnt in my primary role as a Business Analyst that a problem well defined was half the problem solved. The team needed to to have a common idea and vision of our deliverables and end product with our client, and defining the requirements was a key factor to our team’s completion. After all, you can’t build something if you don’t know what you’re building right? But moving towards the finals from the midterms was a vastly different “ballgame”, where the team was already aligned with our client, and the bigger challenge was persevering on to seeing things to completion. Keeping team morale up and remembering our end in mind was essential in motivating a continued and sustained push towards the end to deliver our final product.

Zhu Juntao (Quality Assurance)
Through IS480, I have learnt that building a robust UI and having a structured testing methodology is crucial to the survivability and maintainability of a banking system. The user interface has to be the first line of defence, ensuring data validation. At the same time, it must also be able to catch different types of error that is thrown by the backend. This includes crashing of the server and various types of error messages returned by the server.
A structured testing methodology ensures that the future modifications would not break existing functions. In this process, I have come into touch with automated test tool kits such as HtmlUnit and Phantom JS, eventually choosing HtmlUnit which integrates better with our IDE (NetBeans).
Lastly, IS480 has given both technical and soft skills that will go a long way with me in life.


James Lim (Usability Engineer)
During the period of IS480, I have learnt much how challenging a Core Banking Project can be. Though it is developed within a sheltered environment, the technologies used are of relevance. TIBCO and Java is widely used in the banking industry, and HTML5 is becoming very powerful and useful in today's web technologies. Combining both to create a vanilla Bank Teller Application has been very intriguing, a back-end based on traditional banking technologies and a front-end using the latest of web technologies, it perhaps, might be the new way of doing a Teller application, where most systems today are easily decades old. To do this, myself and the team, ensured that the ideals are guaranteed is just as important as keeping ourselves grounded on what can or cannot be done. I learnt how important the external environment can be; I and the team made it clear to be open to suggestions from people and the internet, ideas from our testers were considered on a very open process and applied to the project. The same can be said from the internet, where we kept a lookout to see what we can use in our project. All of this have contributed to a project we have pride in and where I have learnt a great deal from.


Kevin Ng (Lead Developer)
The journey through IS480 developing the SMU tBank's Branch Teller was challenging but satisfying. Although we got off to a somewhat rocky start, it was encouraging to see the team improve rapidly as the weeks progressed. I took a few key takeaways from this experience.
Firstly, a good understanding of domain knowledge is essential to develop an effective system. In our case, market research and learning about retail banking products and processes helped us greatly when designing the Branch teller System.
Secondly, it's important that we design our code with extensibility and modifiability in mind. This will assist future teams to improve upon our foundation to ensure SMU tBank remains a relevant and effective teaching and educational tool.
Finally, looking back at my team's entire FYP journey, my team has faced many challenges both technical and non-technical. I learnt that many challenges can be overcome by perseverance and optimism. For example, after many attempts, we finally managed to secure an expert user to test our Branch Teller System. Many technical challenges we faced can also be overcome with a mindset of perseverance and optimism.

Tan Yao Guang (System Analyst)
As a developer in the team, I have learnt many technical skills ranging from developing using third party libraries like Drools, to using a GUI development environment (TIBCO). But then there were the other skills that I got to learn as well - there was the creating of a credit engine from scratch. This required us to do an extensive amount of research to find out how credit scoring was done in the industry, as well as finding out average loan amounts etc. These skills were not technical in nature and hence was a great add-on to the skills learnt for myself from this project.


KP-SponsorComment.PNG

Project Future

Client's Vision

“It’s the start of something new and exciting, we will not be stopped”
- Senior Lecturer Alan Megargel

Continuing the Conceptual & Engagement Models
Our team has gotten the ball rolling and in the future our client will be continuing to:

  • Add more SMU Core Services that expose functionalities of off-the-shelf banking products from leading software vendors
  • Add more Banking Applications and channels developed by SMU SIS undergraduate students to consume reusable services
  • Allow MITB classes to utilise Solution Architecture as a case study for Service Oriented Architecture
  • Further collaborate with banks and product vendors to incubate new innovations


Next semester, Corporate Banking channels and services will be added on to existing Retail Banking components.

BIAN Documentation

KP BIANlogo.jpg
To facilitate and ensure the longevity of the back end services that we have built, our team has utilised the Banking Industry Architecture Network (BIAN) Documentation Template to document our back end services.

SMU SIS is the first academic partner of BIAN, and our team was the first to leverage on this to conform our documentation to industry best practices.

BIAN Documentation ensures our documentation is benchmarked with industry best practices for quality and standardised using the same banking jargon for future teams to pick up and understand the inputs, outputs and preconditions of our services.

As this documentation or proprietary, please approach Senior Lecturer Alan Megargel if you are interested in learning more and participating in the goal to build SMU tBank.