IS480 Team wiki: 2013T1 Kungfu Panda Midterms Wiki

From IS480
Jump to navigation Jump to search

Main WikiKP-Main Wiki Link.PNG

Project Progress Summary

Midterm Presentation Slides Download!

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.

Project Highlights

  • Overload of changes by 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

Project Management

Project Status

Currently, our project is 67.03% completed.
Percentage of Development Tasks Complete = Number of Completed Tasks (in Green) / Total Number of Tasks


Project Milestone & Schedule

Our Updated Project Schedule Download!

Project Metrics

Schedule Metrics


KP-Individule MetricsWk23.PNG

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.


KP-Individule MetricsGraphWk23.PNG


Bug Metrics

Total number of bugs encountered: 38
Bug Metric for FYP Week 22: 1 KP-GoodBugMetric.PNG
Below shown are the latest 25 bugs our team have encountered and is recorded in our Bug Tracker.




KP Bug Metrics wk24a.PNG

KP Bug Metrics wk24b.PNG

Project Risk

Technical Complexity

Frontend Complexity

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 Designer

Tibco Enterprise Message 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 services on the EMS, our team used Tibco Designer, a GUI development environment that requires minimal programming.

Common Palettes Used In Tibco Development
Account_Loan_Create Service

Product Comparison

Quality of Application

Intermediate Deliverables



UT 1 (informal)

User testing 1 is an informal testing with our client, Professor Alan and IS419 Instructor, Instructor Arul.
Date Conducted

  • 20 Sep 2013


  • Test whether the current application is functional
  • The usability of the application to suit a branch teller


  • Client (Professor Alan)
  • IS419 Instructor (Instructor Arul)

Test Scenarios

  1. Create Customer
  2. Update Customer Details
  3. Create Deposit Account
  4. Update Deposit Account
  5. Create Loan Account
  6. Update Loan Account
  7. Customer Read (By NRIC and Customer ID)

Test Results
Observations and Feedbacks
PIN number required Editable field other then drop down

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.
Date Conducted

  • 2 Oct 2013


  • Test whether the current application is functional
  • The usability of the application to suit a branch teller

Test Scenarios

  1. Create Customer
  2. Create Internet Banking PIN Number
  3. Create Deposit Account
  4. Create Loan Account
  5. Customer Dashboard


  • 45 students from the IS419: Retail Banking class

Test Results
During the deployment exercise, members from our team have gather some observations they had and also some feedbacks from the students in the class.

  • Confusion in Naming Convention:'Create Loan Account' instead of 'Create a Loan'


  • Easy to use


Team Reflection

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.

Individual Reflections

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)
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.