IS480 Team wiki: 2016T1 Charlies Angels FinalWiki
Main Wiki | Midterm Wiki | Final Wiki |
Project Progress Summary
*Note: Access to Poster and Pitch Video requires SMU-Gmail Login to View
Project Highlights
Project Challenges
Project Achievements
Project Management
Project Status
Project Schedule (Plan vs. Actual)
Planned Project Schedule
Actual Project Schedule
Project Metrics
For more information on how the team tabulates the score for each component, please refer to the following page on our Wiki: Charlies Angels Metrics
Team Charlies Angels is pleased to share that on the whole, there has not been major lapse(s) in our project metrics. And the team has managed to successfully steer in the right direction despite the high technical and business complexity the team faced in the course of this project.
Project Risks
Due to the nature of our application, Team Charlies Angels has been proactively monitoring our efforts to mitigate risk(s). We would like to highlight the top two risks that our project is facing since the mid-terms presentation, the details are found in table below:
Current Risks that may affect the team:
S/N | RISK TYPE | RISK DESCRIPTION | LIKELIHOOD | SEVERITY | CATEGORY | MITIGATION |
---|---|---|---|---|---|---|
9. | Technology Risk | The recent acquisition of Yahoo by Verizon poses an imminent threat to the existence of the Yahoo API where the team utilises to call for its financial information. | Probable | Critical | Unacceptable | The team has identified that Yahoo would close the service only in 2017. However, in the event that the service is closed during the phase of development, the purchase of a paid API is absolutely necessary. In the event of this purchase, the team would propose the drop of all functions happening thereafter, and focus on the fetch of data as it is essentially what makes the application. A list of websites have been provided to the client as alternate sources for varying financial data information:
|
10. | Technology Risk | As the application is utilising web crawling patterns, this aspect is subjected heavily on the patterns that are used on the host(s) which we crawl the data from. | Probable | Critical | Unacceptable | The team has come up with mitigation plans to have two possible steps to take. The first choice would be to proceed to find an alternative website that displays the essential information that we require and proceed to crawl from there. Should the former step fail, we would proceed to consult our client, and proceed to make a purchase for paid API for financial data. In the event of this purchase, the team would propose the drop of all functions happening thereafter, and focus on the fetch of data as it is essentially what makes the application. |
Technical Complexity
Business Domain Complexities
Technical Complexities | |||
---|---|---|---|
Rank | Technical Complexity Faced | Reason | How did the team overcome this complexity |
1 | Determining Risk Measurements of Stocks | Lack of technical know-how, coupled with most of typical risk measurement(s) require inputs from Analysts such as Expected Returns, etc. However, we are required to calculate these with the absence of such fields | Discussed and validated with our sponsor on how to determine risk measurements for stocks |
2 | Calculation of Sharpe Ratio | Online sources may have Sharpe Ratio calculations. However, it pertains to having an 'Expected Return' field but in our case, the sponsor requires us to calculate without it. | Discussed and validated with our sponsor on how to determine Sharpe Ratio formula to be without the 'Expected Return' field |
Front-End Technical Complexities
Technical Complexities | |||
---|---|---|---|
Rank | Technical Complexity Faced | Reason | How did the team overcome this complexity |
1 | Maintaining State a Single Page Application | Traditional web applications are stateless but now we have to manage the UI state | Architecting the data flow of a single page application to maintain state; making use of Redux which is a predictable state container for Javascript applications |
2 | Continuous Deployment | Because the team wanted to perform continuous integration; to perform frequent commits and integrate code as soon as possible | We went a step ahead of continuous integration, and managed to deploy stable code to production whenever it has been pushed on Git |
3 | Developing Time-Series Data Charts in a single page application | Due to the lack of support of the libraries which we require to develop such charts; inadequate guides available | Completed with extensive research and exploration of how to develop such charts. Constant interaction with the Grommet community at large. |
4 | New UI frameworks such as React, Redux, Grommet | First time being exposed to such frameworks | Since these are new frameworks, some parts of the framework are incomplete/broken. Hence, the team had to submit several bug requests to the developers |
Backend Technical Complexities
Technical Complexities | |||
---|---|---|---|
Rank | Technical Complexity Faced | Reason | How did the team overcome this complexity |
1 | Database Structure | Due to the large volume of data that is involved in such a project, we set to achieve a low execution time for complex queries, as this is common in a financial data related application | Frequent discussions and reviews of the schema design to seek an optimised schema for robustness and scalability |
2 | Crawling of Data at a specified interval | Lack of financial data APIs such as Bloomberg/Reuters | By analysing and performing pattern recognition by developing a Scheduler application that utilises a Cron job to obtain such data at a specified interval. |
3 | Generation of PDF & Excel reports | Lack of technical know-how in generating PDFs and Excels, coupled with the lack of proper documentation provided by the utilised libraries | Extensive research and constant tweaking of codes to reach the outcome |