IS480 Team wiki: 2013T1 Kungfu Panda Midterms Wiki
- 1 Project Progress Summary
- 2 Project Management
- 3 Product Comparison
- 4 Quality of Application
- 5 Reflections
Project Progress Summary
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 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. We will be moving on to complete our X-Factor (Credit Approval and Teaching Tool) after our Midterm.
- Address feedback from client during week 6 & 7 of the school term
- A peek in schedule metrics during Acceptance period
- Schedule Metrics = 1.5 for iteration 5
- Misunderstanding & intercommunication between SMU tBank FYP teams
Currently, our project is 68.12% completed.
Percentage of Development Tasks Complete = Number of Completed Tasks (in Green) / Total Number of Tasks
The below diagram shows a coloured diagram / map of development tasks that are completed and outstanding.
Project Milestone & Schedule
Our Updated Project Schedule Download!
Below are some graphs which shows our schedule metrics for each iterations and for each individual members.
We have also calculated the average man hours per week each member put in.
Total number of bugs encountered: 38
Bug Metric for FYP Week 22: 1
Below shown are the latest 25 bugs our team have encountered and is recorded in our Bug Tracker.
Below are our team's top 3 Risk - High Likelihood and High Impact
1. Lack of Market Research due to Confidentiality of Proprietary Systems
- Product Comparison with Oracle Flexcube Branch Teller
- 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
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: Account_Loan_Create Service
Quality of Application
|Project Management||Project Scope|
|General Architecture Diagram|
|Branch Teller Architecture Diagram|
|Testing||UT 1 - Informal Testing|
|UT 2 - Deployment Exercise|
The following Branch Teller Functionalities have been deployed in the SMU tBank Server:
These represent 17 of 18 core functionalities.
- Party Create
- Party User PIN Create
- Party Read & Update
- Customer's Accounts Dashboard
- Account Deposit Read & Update
- Account Loan Create
- Manage Customer's Loan Accounts
- Account Loan Read & Update
- Transaction Deposit
- Transaction Withdrawal
- Transaction History Read
- Payment Credit Transfer Bill Payment
- Payment Loan Repayment Full
- Payment Loan Repayment Partial
The following Back End Services have been deployed in the SMU tBank Server:
These represent all 17 SMU Core Services.
- Party Customer Create
- Party Customer Read
- Party Customer Update
- Party Customer Read IC
- Account List Read
- Account Deposit Create
- Account Deposit Read
- Account Deposit Update
- Account Loan Create
- Account Loan Read
- Account Loan Update
- Transaction Deposit
- Transaction Withdrawal
- Transaction History Read
- Payment Credit Transfer Create
- Transaction FullLoanRepayment Create
- Payment Loan Repayment Partial
UT 1 (informal)
User testing 1 is an informal testing with our client, Professor Alan and IS419 Instructor, Instructor Arul.
- 20 Sep 2013
- Test whether the current application is functional
- The usability of the application to suit a branch teller
- Client (Professor Alan)
- Instructor Arul
- Users left to execute tasks on their own without any help
- Observation by team members
- Create Customer
- Update Customer Details
- Create Deposit Account
- Update Deposit Account
- Create Loan Account
- Update Loan Account
- Customer Read (By NRIC and Customer ID)
Observations and Feedbacks
- Leading Zeroes for Account Numbers
- Make drop-down lists un-editable after selection
- PIN Number
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.
- 2 Oct 2013
- Utilize Branch Teller Application in a classroom setting as a lab exercise
- The usability of the application
- Create Customer and Update Customer Details
- Create and Update Deposit Account
- Create and Update Loan Account
- Customer Read (by NRIC and Customer ID)
- Create Customer Login Details
- Customer Dashboard
- 45 students from the IS419: Retail Banking class
- Lab exercise constructed by 3 FYP teams + Instructor Arul
- 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
During the deployment exercise, members from our team have gather some observations they had and also some feedbacks from the students in the class.
Observations & Feedbacks
- 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
Our team has taken to heart 3 main learning points:
1. Doing Our Best Together
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."
2. Collegiality & Thinking Win-Win
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. 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.
3. Communicate Effectively
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.
Geraldine Koon (Project Manager)
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.
Jonathan Ho (Business Analyst)
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.
Zhu Juntao (Usability Engineer)
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'.
James Lim (Quality Assurance)
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.
Kevin Ng (Lead Developer)
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. 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.
Tan Yao Guang (System Analyst)
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.