HeaderSIS.jpg

IS480 Team wiki: 2015T2 BeeSkilled Finals

From IS480
Jump to navigation Jump to search
Finallogo.png


HOME

 

ABOUT US

 

PROJECT OVERVIEW

 

PROJECT MANAGEMENT

 

DOCUMENTATION

 

USER TEST

 

Project Progress Summary

BeeSkilled-iteration.jpg

BeeSkilled-Final-Slides.png
To Login, please use Username as BeeSkilledAdmin and password as password
BeeSkilled-DeployedLink.png BeeSkilled-DeployedLinkAmazon.png

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

BeeSkilled-CompletedFunctions.jpg

Project Scope (Plan Vs Actual)

Planned Actual

Functions v2.jpg

BeeSkilled-Project Scope Final.jpg

Project Schedule (Plan Vs Actual)

Planned (from Midterm)
Project Timeline Latest.png
Actual
BeeSkilled-Project Timeline Actual.png
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

Schedule Metric
BeeSkilled-SM.png
BeeSkilled-SM2.png



Bug Metric
BeeSkilled-BM2.jpg
BeeSkilled-BM.jpg

Project Risks

BeeSkilled-Risk.jpg

Technical Complexity

BeeSkilled-TC1.jpg

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.

BeeSkilled-TC2.jpg

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.

BeeSkilled-TC3.jpg

Data mapping for both SWIFT_MT plugin and ISO20022 schema.

BeeSkilled-TC4.jpg

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
Xfactor beeskilled.jpg

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.

BeeSkilled-Reflection.jpg