Difference between revisions of "IS480 Team wiki: 2013T1 Kungfu Panda Final Wiki"
|Line 213:||Line 213:|
|align = "left"|
|align = "left"|
*[[IS480 Team wiki: 2013T1 Kungfu Panda Software Testing|<b>Back End Services Testing''</b>]]
*[[IS480 Team wiki: 2013T1 Kungfu Panda Software Testing|<b>Back End Services Testing ''</b>]]
*[[IS480 Team wiki: 2013T1 Kungfu Panda Software Testing|<b>End to End Testing''</b>]]
*[[IS480 Team wiki: 2013T1 Kungfu Panda Software Testing|<b>End to End Testing''</b>]]
Revision as of 23:14, 24 November 2013
- 1 Project Progress Summary
- 2 Project Management
- 3 Quality of Application
- 4 Reflections
- 5 Project Future
- 6 Client's Vision
- 7 BIAN Documentation
Project Progress Summary
After 2620.5 working man hours over 32 weeks / 160 days, our team, Kungfu Panda, has finally come to the end of our Final Year Project.
- We were unable to get expert advice for our application (e.g. real branch teller)
- Trying to get real branch teller as our users for User Test
- Constant changes made to our requirement by our client
- Dependency with the other FYP SMU tBank teams
- Having to handle the deadlines to get the services up for the other teams and also services by them
Overcoming Project Challenges
- Preserve and press on
- Think out of the box
- Efficient communication with the other teams
- Complete the Application with all our client's requirement
- Manage to secure one Branch Manager from a bank to try out our Application
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
Our Updated Project Schedule Download!
Project Schedule (Planned Vs Actual)
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
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
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
Bug Metric for FYP Week 30: 0
Below shown are the latest 25 bugs our team have encountered and is recorded in our Bug Tracker.
Summary of Complexities Faced
- Data Integrity
- Ensured that insert statements made to the databases were ordered (serialized)
- Handled error flow should a transaction violation error occur
- Finance Formulas
- Had to research on finance formulas and understand the time value of money in order to complete this task
- Translated finance formulas (annuity formula) into Java code to be used in the Loan creation process
- Business Logic Errors
- Used XPath formulas within Tibco Designer to check for conditions such as insufficient balance or no such account and what to do subsequently
- Business Process Flow
- Entire business logic of the core banking systems is programmed inside the back-end services
- 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
Quality of Application
|Project Management||Project Scope|
|Project Architecture Diagram|
|Testing||Informal Testing with Client|
|Deployment Exercise with IS419 Class|
|UAT with Client|
|Front End Code||
|Back End Code||
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.
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
- 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.
- 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.
- 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.
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.
- 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.
The following Branch Teller Functionalities have been deployed in the SMU tBank Server:
The following Back End Services have been deployed in the SMU tBank Server:
Link to our Our User Testing
Link to our Informal Testing with Client
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
- 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:
- 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
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.
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.
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
- 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 made to the color and we have also bold the words to make it clearer.
- We have added instructions, so users are clear that the password have to be 6 numerical.
- Checkbooxes are also added to the toggle filter
- We have added one more button to lead the teller to the Teller Main Menu.
- Tip boxes with instructions help users with the application
- 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
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
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.
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 (Usability Engineer)
James Lim (Quality Assurance)
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, collaborating as a team, we ensured that the ideals are guaranteed is just as important as keeping ourselves grounded on what can or cannot be done. We also made it clear to be open to suggestions from people and the environment, ideas from our testers were considered on a very open process and applied to the project. The same can be said from the environment, 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.
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, I learnt that difficult 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.
Finally, 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.
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.
“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.
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.