IS480 Team wiki: 2015T2 BeeSkilled Finals
Contents
Project Progress Summary
To Login, please use Username as BeeSkilledAdmin and password as password
Milestones Achieved | Explanation |
---|---|
10 Iterations | Completed 10 iterations with a average SM Score of 101 |
User Testing | 1 User Testing after Midterm |
Project Highlight
→ Moved Payment Service Hub to Secondary function
→ Held a classroom lab for IS430 ePayments Processes & Technology
→ 3 User Testings
→ 9 Supervisor Meetings
→ 19 Client Meetings
Project Management
Project Status
Project Scope (Plan Vs Actual)
Planned | Actual |
---|---|
Project Schedule (Plan Vs Actual)
Planned (from Midterm) |
---|
Actual |
Iteration | Issues Faced | Solutions | Mitigation |
2 | 'Functionality: Create Gateway' took a longer time than expected to be stable and ready for use in the Payment Orchestration | After researching and talking to our Project Sponsor, it has been decided that we would spend extra time to re-construct the gateways and spend more time in testing to ensure that both Automated Clearing House (ACH) and Payments Service Hub (PSH) Gateways are tested and ready to be integrated with upcoming functionalities. | 'Functionality: Payment Orchestration' will be pushed back to subsequent iteration as both Gateways are the supporting foundation and should be thoroughly tested |
4 | Underestimated time required for 'Functionality: Payment Orchestration' | Continue with development of 'Functionality: Payment Orchestration' and push back other fuctionalities to subsequent iterations. Concurrently, Payment Orchestration was broke up into 2 phases for development and separated into 2 interations | Reschedule next iteration with added functionalities and milestones |
Project Metrics
Project Risks
Technical Complexity
In this single TIBCO diagram, we can see how SOA design is made possible in the code level:
This is a sneak peek into the middle layer that handles all our business logic – powered by TIBCO BusinessWorks. This layer interacts with the frontend by SOAP request going in at the Start node and SOAP reply going out from the End node. The interaction between business logic layer and backend database is also shown here; in this case, the central bank needs to charge a fee whenever they perform payment orchestrate service for various banks, and calculating fees requires retrieving data from database. Thus, in this single diagram, we have demonstrated how 3-layer architecture is applied to produce an end-to-end operation. This is the basis for the many other reusable web services we have built.
With SOA architecture, it is also possible for one service to make use another service. In this case, ACH Payment is using ACH Gateway to route payment instructions to receiving banks, in the appropriate message formats. Reusable web services not only make development easier and more reliable, but also help the system become more robust. Changes within ACH Gateway does not affect how ACH Payment works.
Finally, for every single operation we have built in ACH, the input and output must comply strictly to their own pre-defined schema. To ensure consistency and strict compliance, all the web services we built are SOAP-based, and both ends of the operation have their own .XSD schemas that takes care of almost all validation, making sure that messages are well-formed and valid.
Imagine the previous Payment process is repeated thousands of time per day, creating thousands of payment records in ACH database, and now it’s time to do the netting. This process involved calculating how much each bank owes each bank, in various currencies. The business logic is pretty complex as you can see here, but we have to make it so because anything less and the real settlement process bank employs will not be reflected, and students will not be able to see the results reflected in various channels of tBank.
Data mapping for both SWIFT_MT plugin and ISO20022 schema.
System response time improves by about 90 milliseconds. This corresponds to about 16% reduction in time compared to using temporary data table. Another advantage of using ActiveSpaces over temporary data table is the ease of maintenance. Using data tables is not a scalable solution; any changes will involve all of them.
Quality of product
Intermediate Deliverables
Stage | Specification | Modules |
Project Management | Minutes | Meeting Minutes |
Metrics | Bug metrics | |
Metrics | Schedule metrics | |
Requirements | Design Specifications | Project Scope |
Design / Analysis | Use case | Use Case Diagram |
Architecture Diagram | Architecture Diagram | |
Website Wireframe | Website Wireframe | |
Testing | User test plan | User Test Results |
Testing
1 User Test was conducted after midterm which covered overlapping functions.
The User Test was conducted in a Scenario-Based Environment where users will assume different roles in the Banking Environment.
Result of the test can be viewed here
Reflection
"It's our choices that show what we truly are, far more than our abilities." - Dumbledore, Harry Potter and the Chamber of Secrets.