Difference between revisions of "IS480 Team wiki: 2016T1 Ingenium Midterm"
(27 intermediate revisions by 3 users not shown) | |||
Line 28: | Line 28: | ||
{|style="background-color:white; color:white padding: 0 0 0 0;" width="100%" cellspacing="0" cellpadding="0" valign="top" border="0" | | {|style="background-color:white; color:white padding: 0 0 0 0;" width="100%" cellspacing="0" cellpadding="0" valign="top" border="0" | | ||
− | | style="width: | + | | style="width:33%; text-align:center; border-bottom:1px solid #000000; font-weight: bold;" | [[IS480 Team wiki: 2016T1 Ingenium|<font color=black size=2>Main Wiki</font>]] |
− | | style="background-color:#E0F2F1; width: | + | | style="background-color:#E0F2F1; width:33%; text-align:center; border-bottom:1px solid #000000; font-weight: bold;" | [[IS480 Team wiki: 2016T1 Ingenium Midterm|<font color=#006064 size=2>Midterm Wiki</font>]] |
+ | |||
+ | | style="width:33%; text-align:center; border-bottom:1px solid #000000; font-weight: bold;" | [[IS480 Team wiki: 2016T1 Ingenium Final|<font color=black size=2>Final Wiki</font>]] | ||
|} | |} | ||
<!--SUB HEADER END--> | <!--SUB HEADER END--> | ||
Line 36: | Line 38: | ||
==Links & Slides== | ==Links & Slides== | ||
− | *Midterm Slides: [[Media: | + | *Midterm Slides: [[Media:Ign-midterms.pdf | '''View slides.''']] |
− | *Deployed Firestone Site: [http:// | + | *Deployed Firestone Site: [http://10.124.3.203:8084/FireStone <b>Enter FireStone.</b>] |
**Log in credentials - username: admin & password: admin | **Log in credentials - username: admin & password: admin | ||
*Data Providers: QuantHouse (current) & IDC (old) - [http://www.sgx.com/wps/portal/sgxweb/home/services/market-data/our-data-vendors '''SGX-Approved'''] | *Data Providers: QuantHouse (current) & IDC (old) - [http://www.sgx.com/wps/portal/sgxweb/home/services/market-data/our-data-vendors '''SGX-Approved'''] | ||
Line 43: | Line 45: | ||
==Project Progress Summary== | ==Project Progress Summary== | ||
− | |||
*Current Iteration: 7 (1-Oct-16 to 15-Oct-16) out of 10 iterations | *Current Iteration: 7 (1-Oct-16 to 15-Oct-16) out of 10 iterations | ||
*Till date, 60% of project scope completed | *Till date, 60% of project scope completed | ||
− | *Due to a sudden change of data provider in | + | *Due to a sudden change of data provider in early September, our team had to re-do 2 of the completed functionalities. |
− | + | **Thankfully, we have successfully redeveloped those functionalities and we're confident to complete the remaining functionalities as planned. | |
− | + | *In the past month, 1 UAT & Survey was done. | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
==Project Management== | ==Project Management== | ||
− | ===Project Status | + | ===Project Status=== |
{| class="wikitable" border="1" style="margin-left: auto; margin-right: auto; text-align: center;" | {| class="wikitable" border="1" style="margin-left: auto; margin-right: auto; text-align: center;" | ||
Line 282: | Line 258: | ||
[[File:Ign-oldscope.png|900px|center]] | [[File:Ign-oldscope.png|900px|center]] | ||
====New Project Scope==== | ====New Project Scope==== | ||
− | [[File:Ign- | + | [[File:Ign-midtermscope.png|900px|center]] |
'''Highlights of Changes Made in Scope''' | '''Highlights of Changes Made in Scope''' | ||
Line 291: | Line 267: | ||
*Re-scoped ''Account Management'' due to different understanding of functional requirements previously | *Re-scoped ''Account Management'' due to different understanding of functional requirements previously | ||
− | ===Project Schedule ( | + | ===Project Schedule=== |
+ | ====Old Timeline==== | ||
+ | [[File:Ign-overallschedule3.png|780px|center]] | ||
+ | ====New Timeline==== | ||
+ | [[File:Ign-overallschedule7.png|1000px|center]] | ||
+ | |||
+ | '''Highlights of Changes Made in Schedule''' | ||
+ | *Shorten iterations from a fixed period of 1 month to 2 weeks | ||
+ | *Change of data provider from IDC to QuantHouse in Iteration 5 | ||
+ | **Notified by client on 02-Sep-16 | ||
+ | **Completed installation, deployment and configuration on 14-Sep-16 | ||
+ | **Re-scheduled development of certain functions (connectivity module & market watch) in Iteration 5 | ||
+ | |||
+ | ===Project Metrics=== | ||
− | + | [[File:Ign-taskmetric.png|500px]] [[File:Ign-bugmetric.png|500px]] | |
− | |||
− | + | ===Project Risks=== | |
+ | {| class="wikitable" style="margin-left: auto; margin-right: auto; text-align:center;" | ||
+ | |- | ||
+ | ! width="30px" style="background: #00004d;color:white; font-size: 14px;" | S/N | ||
+ | ! width="420px" style="background: #00004d;color:white; font-size: 14px;" | Description of Risk | ||
+ | ! width="100px" style="background: #00004d;color:white; font-size: 14px;" | Likelihood | ||
+ | ! width="80px" style="background: #00004d;color:white; font-size: 14px;" | Impact | ||
+ | ! width="90px" style="background: #00004d;color:white; font-size: 14px;" | Risk Level | ||
+ | ! width="330px" style="background: #00004d;color:white; font-size: 14px;" | Mitigation Strategy | ||
+ | |- | ||
+ | | 1 | ||
+ | | Different brokers have different FIX format requirements, requiring patches to fit the new broker requirements. Even though sample FIX messages were provided for validation, they were very basic and insufficient for comprehensive testing. | ||
+ | | Medium | ||
+ | | High | ||
+ | | style="background: red;" | A | ||
+ | | Have constant communication with sponsors and brokers for preempt warnings, so any time we have issues or need clarifications on the system we can email them straight away. | ||
+ | |- | ||
+ | | 2 | ||
+ | | Difficulty in understanding the different process of stock trading in client's perspective thus extra time is spent on understanding before designing our functionalities. | ||
+ | | High | ||
+ | | Medium | ||
+ | | style="background: red;" | A | ||
+ | | Set up communication channel with stakeholders for issues that require immediate feedback. | ||
+ | |- | ||
+ | | 3 | ||
+ | | Sponsor UAT delayed. | ||
+ | | Medium | ||
+ | | High | ||
+ | | style="background: red;" | A | ||
+ | | Check back with Schedule, reaccess the impact and adjust schedule to account for later UAT. With VPN, more flexible for UAT to be done. | ||
+ | |} | ||
− | + | ===Technical Complexity=== | |
− | + | ==== Technical Complexity #1: Interaction with Broker==== | |
− | + | <gallery> | |
+ | File:Hk1.png|Buy/Sell Form | ||
+ | File:Hk2.png|Sending of Messages to Broker | ||
+ | File:Hk3.png|Handling Messages from Broker | ||
+ | File:Hk4.png|Handling Deplicate Messages from Broker | ||
+ | </gallery> | ||
+ | The web application converts the user's order details into QuickFix format can contain fields such as symbol, price, currency, quantity, type of market, validity, account, force and type of SGX market. Each type of market and validity of stocks and broker custom fields have unique message fields which are unique within each option, our application must be able to create the stock order dynamically and fitting to the broker's standard or else the quick message would be rejected. | ||
− | + | When we receieve broker messages, our application must be able to convert the quickfix messages and display onto our web user interface. A stock is able to have many different states such as cancelled, done for day, replaced, rejected, new, partial fill and filled status along with many other additional fields. These fields have to be recorded correctly as an error in the fields can prevent further transactions with this stock order. | |
− | + | On Top of that, it is possible for the broker to send us duplicate messages as a means of failover if they are unsure whether we receieved it. Our application must be able to handle duplicate messages by checking out the Executed ID of each broker message. We put each executed id from the broker into a hashmap and check if the current receieved message has already been processed before. | |
− | === | + | ==== Technical Complexity #2: Market Making==== |
+ | Market Making allows stock traders to automatically create buy and sell orders to create liquidity in the market for specific stocks, based on user inputs including where the orders are specified to be in the watchList. Market making will also automatically change the sent orders to reflect changes in the stock prices from moment to moment. | ||
− | + | The user inputs the buy and sell levels of the orders, as well as the max spread between the buy and sell prices. Market Making will then calculates the order price based on the current stock price and the price difference between the buy and sell price. once calculated, market making will then checks if the current order fits the calculated price. If not, it will cancel the order and sends a new order with the modified price. | |
− | |||
− | ===Technical Complexity:=== | + | ==== Technical Complexity #3: Websocket for Real-time Concurrency==== |
+ | WebSocket allow us to achieve concurrent realtime data to client browser. In order to indivdually linked user to multiple unique session id, we created our own 3 way handshake to bind the user to all its unqiue session id. | ||
− | + | # On user client initialization with WebSocket, WebSocket will return a session id to the user client. | |
+ | # User client will then return the message state, username and session id. | ||
+ | # WebSocket on message receive, it will check state to see its a handshake message. | ||
+ | # WebSocket will then associate username with session id. | ||
− | + | # In order to achieve realtime concurrency, we created a onMessageBroadcast to push data to the user with its associate session id. | |
+ | # With that, we are also use WebSocket message to notify any changes on the user for events such as subscribe or unsubscribe stocks | ||
==Quality of product== | ==Quality of product== | ||
Our development team has ensured constant communication with our client via meetings and emails to make sure there is no discrepancies between the development teams and the clients’ understanding in the functionalities. In addition, the development team have also had constant communication with other stakeholders that also have a role in the project, such as the data provider and the stock brokers. | Our development team has ensured constant communication with our client via meetings and emails to make sure there is no discrepancies between the development teams and the clients’ understanding in the functionalities. In addition, the development team have also had constant communication with other stakeholders that also have a role in the project, such as the data provider and the stock brokers. | ||
− | ===Intermediate Deliverables | + | ===Intermediate Deliverables=== |
{| class="wikitable" style="margin-left: auto; margin-right: auto;" border="1" | {| class="wikitable" style="margin-left: auto; margin-right: auto;" border="1" | ||
|- style="background:#00004d; color:white" | |- style="background:#00004d; color:white" | ||
Line 339: | Line 368: | ||
|| | || | ||
* [[IS480 Team wiki: 2016T1 Ingenium Minutes|Internal, Sponsor & Supervisor Minutes]] | * [[IS480 Team wiki: 2016T1 Ingenium Minutes|Internal, Sponsor & Supervisor Minutes]] | ||
− | * Bug Metrics | + | * [[IS480 Team wiki: 2016T1 Ingenium Metrics|Task & Bug Metrics]] |
* [[IS480 Team wiki: 2016T1 Ingenium Risk|Risks Table]] | * [[IS480 Team wiki: 2016T1 Ingenium Risk|Risks Table]] | ||
* [[IS480 Team wiki: 2016T1 Ingenium Change|Change Log]] | * [[IS480 Team wiki: 2016T1 Ingenium Change|Change Log]] | ||
Line 366: | Line 395: | ||
|} | |} | ||
− | ===Deployment | + | ===Deployment=== |
The application is deployed on North Point Global’s server co-located at SGX data center, which is connected to North Point Global logically to prevent others outside the office from accessing the system. As such, the application is not deployed on public domain. The deployment link is available at the top of the page. | The application is deployed on North Point Global’s server co-located at SGX data center, which is connected to North Point Global logically to prevent others outside the office from accessing the system. As such, the application is not deployed on public domain. The deployment link is available at the top of the page. | ||
− | ===Testing | + | ===Testing=== |
Total number of testing done: | Total number of testing done: | ||
Line 376: | Line 405: | ||
==Reflection== | ==Reflection== | ||
− | ===Team Reflection | + | ===Team Reflection=== |
In a project that can only be developed in the hours of 9 to 5, constant communication, merticulous planning and adapative schedule is very important in ensuring the success of the project. | In a project that can only be developed in the hours of 9 to 5, constant communication, merticulous planning and adapative schedule is very important in ensuring the success of the project. | ||
Line 385: | Line 414: | ||
* Level2 (L2) Market Data or Level 2 Quotation Data is the list of all Bid and Ask Prices with sizes and order originators. | * Level2 (L2) Market Data or Level 2 Quotation Data is the list of all Bid and Ask Prices with sizes and order originators. | ||
* ISO 10962 is the standard code that classifies financial instruments. | * ISO 10962 is the standard code that classifies financial instruments. | ||
− | * ISO 10383 is the standard code that identifies exchanges and financial markets | + | * ISO 10383 is the standard code that identifies exchanges and financial markets. |
− | |||
− | |||
− | |||
− |
Latest revision as of 01:10, 15 November 2016
Home |
Main Wiki | Midterm Wiki | Final Wiki |
Contents
Links & Slides
- Midterm Slides: View slides.
- Deployed Firestone Site: Enter FireStone.
- Log in credentials - username: admin & password: admin
- Data Providers: QuantHouse (current) & IDC (old) - SGX-Approved
- Reason for Co-location of Server to SGX - Explained by SGX
Project Progress Summary
- Current Iteration: 7 (1-Oct-16 to 15-Oct-16) out of 10 iterations
- Till date, 60% of project scope completed
- Due to a sudden change of data provider in early September, our team had to re-do 2 of the completed functionalities.
- Thankfully, we have successfully redeveloped those functionalities and we're confident to complete the remaining functionalities as planned.
- In the past month, 1 UAT & Survey was done.
Project Management
Project Status
S/N | Description | Module | Completion | Confidence | Comments |
1 | Retrieve Data from Data Provider | Connectivity | 100% | 1.0 | Implemented by Mingliang |
2 | Network I/O from IDC | Connectivity | Removed due to change in data vendor | ||
3 | CRUD Order | Trading Platform | 80% | 1.0 | Implemented by Hongkun |
4 | Display Order Book Dashboard | Trading Platform | 80% | 1.0 | Implemented by Hongkun |
5 | Order Execution Confirmation | Trading Platform | 70% | 1.0 | Implemented by Hongkun |
6 | Display Profit & Loss | Trading Platform | 90% | 1.0 | Implemented by Hongkun |
7 | Subscribe Stocks to Market Watch | Market Watch | 100% | 1.0 | Implemented by Mingliang |
8 | Display Market Watch | Market Watch | 100% | 1.0 | Implemented by Mingliang |
9 | Subscribe Stocks to Watch List | Watch List | 100% | 1.0 | Implemented by Mingliang |
10 | Display Watch List | Watch | 90% | 1.0 | Implemented by Mingliang |
11 | CRUD Market Making Orders | Market Making | 100% | 1.0 | Implemented by Huaswee |
12 | Market Making Automated Hedging | Market Making | 0% | 1.0 | To be implemented by Huaswee |
13 | Market Making to Allow Manual Intervention | Market Making | 0% | 1.0 | To be implemented by Huaswee |
14 | CRUD Arbitrage Algorithm Trading | Algorithm Trading | 0% | 1.0 | To be implemented by Huaswee |
15 | Rights Arbitrage | Algorithm Trading | 0% | 1.0 | Huaswee is researching on Arbitrage Algorithm |
16 | Buy-in Arbitrage | Algorithm Trading | 0% | 0.8 | Huaswee is researching on Arbitrage Algorithm |
17 | Index Arbitrage | Algorithm Trading | 0% | 0.4 | Huaswee is researching on Arbitrage Algorithm |
18 | Real-time update for Market Watch | Design Architecture | 90% | 1.0 | Implemented by Mingliang |
19 | Real-time update for Watch List | Design Architecture | 90% | 1.0 | Implemented by Mingliang |
20 | Real-time update for Order Book | Design Architecture | 100% | 1.0 | Implemented by Hongkun |
21 | Real-time update for Profit & Loss | Design Architecture | 0% | 0.6 | To be implemented by Hongkun |
22 | Real-time update for Transaction Log | Design Architecture | 100% | 1.0 | Implemented by Hongkun |
23 | Login / Logout | Account Management | 100% | 1.0 | Implemented by Hongkun |
24 | Access Rights | Account Management | 0% | 0.5 | To be implemented by Hongkun |
25 | Display User Profile Page | Account Management | Removed due to scope ambiguity clarified | ||
26 | Account Module (Primary / Secondary Server / Trader) | Account Management | Removed due to scope ambiguity clarified | ||
27 | Add / Remove Broker Account | Account Management | 0% | 1.0 | Added scope due to scope ambiguity clarified |
28 | Set Trade Limit to Account | Account Management | 0% | 1.0 | Added scope due to scope ambiguity clarified |
29 | Display Transaction Log for Broker Accounts | Account Management | 100% | 1.0 | To be implemented by Hongkun |
30 | Failover | Secondary Function | Removed scope due to change in data vendor | ||
31 | Concurrency for Market Watch | Secondary Function | 100% | 1.0 | Implemented by Mingliang |
32 | Concurrency for Watch List | Secondary Function | 100% | 1.0 | Implemented by Mingliang |
33 | Concurrency for Order Book | Secondary Function | 100% | 1.0 | Implemented by Mingliang |
34 | Concurrency for Profit & Loss | Secondary Function | 0% | 1.0 | To be implemented by Mingliang |
35 | Concurrency for Transaction Log | Secondary Function | 100% | 1.0 | Implemented by Mingliang |
36 | Code Revision for Lower Latency | Secondary Function | 0% | 0.5 | To be implemented by all developers |
37 | Conditional Order Triggers based on Parameters | Secondary Function | 0% | 0.5 | To be implemented by Huaswee |
Project Scope
Old Project Scope
New Project Scope
Highlights of Changes Made in Scope
- Removed failover in secondary function as we have no control over the infrastructure (server) that is collocated at SGX now
- Removed implementation of foreign markets to focus on trading in SGX market first due to change in data provider
- Revamp of scope modules to group by functionalities so that it is more user-readable
- Implementation of new module, Arbitrage Algorithm Trading, proposed by Sponsor as a secondary function
- Re-scoped Account Management due to different understanding of functional requirements previously
Project Schedule
Old Timeline
New Timeline
Highlights of Changes Made in Schedule
- Shorten iterations from a fixed period of 1 month to 2 weeks
- Change of data provider from IDC to QuantHouse in Iteration 5
- Notified by client on 02-Sep-16
- Completed installation, deployment and configuration on 14-Sep-16
- Re-scheduled development of certain functions (connectivity module & market watch) in Iteration 5
Project Metrics
Project Risks
S/N | Description of Risk | Likelihood | Impact | Risk Level | Mitigation Strategy |
---|---|---|---|---|---|
1 | Different brokers have different FIX format requirements, requiring patches to fit the new broker requirements. Even though sample FIX messages were provided for validation, they were very basic and insufficient for comprehensive testing. | Medium | High | A | Have constant communication with sponsors and brokers for preempt warnings, so any time we have issues or need clarifications on the system we can email them straight away. |
2 | Difficulty in understanding the different process of stock trading in client's perspective thus extra time is spent on understanding before designing our functionalities. | High | Medium | A | Set up communication channel with stakeholders for issues that require immediate feedback. |
3 | Sponsor UAT delayed. | Medium | High | A | Check back with Schedule, reaccess the impact and adjust schedule to account for later UAT. With VPN, more flexible for UAT to be done. |
Technical Complexity
Technical Complexity #1: Interaction with Broker
The web application converts the user's order details into QuickFix format can contain fields such as symbol, price, currency, quantity, type of market, validity, account, force and type of SGX market. Each type of market and validity of stocks and broker custom fields have unique message fields which are unique within each option, our application must be able to create the stock order dynamically and fitting to the broker's standard or else the quick message would be rejected.
When we receieve broker messages, our application must be able to convert the quickfix messages and display onto our web user interface. A stock is able to have many different states such as cancelled, done for day, replaced, rejected, new, partial fill and filled status along with many other additional fields. These fields have to be recorded correctly as an error in the fields can prevent further transactions with this stock order.
On Top of that, it is possible for the broker to send us duplicate messages as a means of failover if they are unsure whether we receieved it. Our application must be able to handle duplicate messages by checking out the Executed ID of each broker message. We put each executed id from the broker into a hashmap and check if the current receieved message has already been processed before.
Technical Complexity #2: Market Making
Market Making allows stock traders to automatically create buy and sell orders to create liquidity in the market for specific stocks, based on user inputs including where the orders are specified to be in the watchList. Market making will also automatically change the sent orders to reflect changes in the stock prices from moment to moment.
The user inputs the buy and sell levels of the orders, as well as the max spread between the buy and sell prices. Market Making will then calculates the order price based on the current stock price and the price difference between the buy and sell price. once calculated, market making will then checks if the current order fits the calculated price. If not, it will cancel the order and sends a new order with the modified price.
Technical Complexity #3: Websocket for Real-time Concurrency
WebSocket allow us to achieve concurrent realtime data to client browser. In order to indivdually linked user to multiple unique session id, we created our own 3 way handshake to bind the user to all its unqiue session id.
- On user client initialization with WebSocket, WebSocket will return a session id to the user client.
- User client will then return the message state, username and session id.
- WebSocket on message receive, it will check state to see its a handshake message.
- WebSocket will then associate username with session id.
- In order to achieve realtime concurrency, we created a onMessageBroadcast to push data to the user with its associate session id.
- With that, we are also use WebSocket message to notify any changes on the user for events such as subscribe or unsubscribe stocks
Quality of product
Our development team has ensured constant communication with our client via meetings and emails to make sure there is no discrepancies between the development teams and the clients’ understanding in the functionalities. In addition, the development team have also had constant communication with other stakeholders that also have a role in the project, such as the data provider and the stock brokers.
Intermediate Deliverables
Type | Description | Documentation |
Project Management |
|
|
Design & Analysis |
|
|
Testing |
|
Deployment
The application is deployed on North Point Global’s server co-located at SGX data center, which is connected to North Point Global logically to prevent others outside the office from accessing the system. As such, the application is not deployed on public domain. The deployment link is available at the top of the page.
Testing
Total number of testing done:
- 1 UAT & Survey with North Point Global
- Internal testing with the data provider and stock brokers
Reflection
Team Reflection
In a project that can only be developed in the hours of 9 to 5, constant communication, merticulous planning and adapative schedule is very important in ensuring the success of the project.
Learning Outcome
- The Financial Information Exchange (FIX) Protocol is a message standard developed to facilitate the electronic exchange of information related to securities transactions. It is intended for use between trading partners wishing to automate communications.
- Level1 (L1) Market Data or Level 1 Quotation Data consists of the real-time Best Bid and Best Ask Prices and the Bid and Ask Sizes available at those prices.
- Level2 (L2) Market Data or Level 2 Quotation Data is the list of all Bid and Ask Prices with sizes and order originators.
- ISO 10962 is the standard code that classifies financial instruments.
- ISO 10383 is the standard code that identifies exchanges and financial markets.