---
# System prepended metadata

title: HiProfit - CSC 301 Team Project Winter 2022

---

# HiProfit - CSC 301 Team Project Winter 2022

## Product Details
 
#### Q1: What are you planning to build?

HiProfit will be a web application used for creating, sharing and testing different market trading strategies. A trading strategy is a plan for selling and trading assets, it is used to increase profits on investments. Using Hi Profit, users will be able to create and evolve trading strategies and manage a portfolio with virtual coins. It will contain a leaderboard where the highest performing people are displayed. In addition to creating strategies, users will also be able to back test their strategies against custom time frames, giving users more confidence before deploying their strategy into the market. HiProfile will be extremely beneficial to both new and experienced traders. It can be difficult for individuals who are new to trading to find strategies that match their investing objectives. Using our application, new traders will be able to test potential strategies without any risk using our back testing feature. Overall, HiProfile will allow users to become better traders and increase their return on investment.

#### Q2: Who are your target users?

* David is a timid, but inquisitive university student between the age of 18-24. As he has some money saved up through internships, he understands the value of financial security and is interested in trading in the stock market. He has built up basic knowledge through videos available online and wants to start trading as soon as possible. However, he is hesitant about it because he doesn’t know how to apply his knowledge effectively as he does not have prior experience. Moreover, he wants to avoid major financial repercussions while he experiments with different strategies. David wants to learn effective strategies that will help him deepen his understanding of trading, and wants to feel confident about his financial position.

* Kevin is an experienced trader who is determined to take his trading endeavors a step further. He works as a full-time employee for a company and has been trading for around two years. He is comfortable with the concept of trading and has been doing so to generate an additional income stream. However, he feels stuck in his ways and wishes to be more flexible as the market fluctuates. Moreover, he is unsatisfied with the amount of profit that his current strategy gives him and feels like he could be making more. Kevin wants to take risks for higher profit and explore diverse trading strategies to broaden his knowledge.

* Ernest is a successful, seasoned trader who is confident in his abilities to effectively trade in the market. He has been trading for over five years and has developed his own way of interpreting and trading in the market. He actively does research to stay “on top” of the market and likes to expand his knowledge. Despite his success, Ernest feels as if he is lacking something and feels lonely with his hobby. He wishes to be a part of a community to share and gain recognition for his strategies. Ernest also enjoys a bit of friendly competition and wants to see how effective his strategies are compared to other traders’ strategies. This way, he can explore different methods from reputable sources and improve his own.

#### Q3: Why would your users choose your product? What are they using today to solve their problem/need?

Our main competitor is eToro, an Israeli social trading company that provides a fee-for-subscription service among others to allow amateur traders to follow and benefit from  professional strategies. At the present time, eToro is not open to Canadian residents. 

Our product has an educational bias and emphasizes platform neutrality. We will automatically rank and publish the best-performing trading strategies on a leaderboard with minimal human interference that allows users such as David, Kevin, and Ernest to explore and experiment with effective strategies. This ranking system will also allow seasoned traders to gain recognition and confidence in their strategies. Future plans include to allow the public to subscribe to and benefit from those trading strategies for free; and we provide several features to “gamify” the trading experience to allow amateur traders, such as David, to gain experience and confidence with no financial risk. We will also open the services to users from around the globe with no geographical restrictions.


#### Q4: How will you build it?

We plan to use the React + Flask + PostgreSQL stack. Our main programming languages are Python, JavaScript and SQL. Flask is our main framework. We will use Material UI/bootstrap or other third party libraries for frontend development in addition to React. 

We plan to deploy our application on Heroku, which is a PaaS service. 

We plan to build a frontend and a backend, complete with a database. We may employ pipe and filter pattern, ESB Pattern (If required), Microservice Pattern, Data Access Object (DAO) pattern, adn other design patterns as the need arises. 

For the purpose of our application, we will need historical data on the price of stock, cryptocurrency, and other financial assets. We plan to do some research and find free APIs for that. For example, NOMICS is a free API for cryptocurrency prices. 

We plan to use Pytest, Python unittest, React Testing Library, Jest, and other testing libraries as we see fit. 

#### Q5: What are the user stories that make up the MVP?


The user stories can be accessed from this google sheets form https://docs.google.com/spreadsheets/d/1noQ-nU6Q5hv89waNohoFQjuBm3ruH9RQ3MS4dyPkHOY/edit?usp=sharing . 


----
## Intellectual Property Confidentiality Agreement 

We do not have a partner and we are developing our own product ideas. We would like to publish the code on Github under the following MIT Open Source license, whereby any person can freely use it. 

    Copy of the liscence

    MIT License

    Copyright (c) 2022 Hi Profit

    Permission is hereby granted, free of charge, to any person obtaining a copy
    of this software and associated documentation files (the "Software"), to deal
    in the Software without restriction, including without limitation the rights
    to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
    copies of the Software, and to permit persons to whom the Software is
    furnished to do so, subject to the following conditions:

    The above copyright notice and this permission notice shall be included in all
    copies or substantial portions of the Software.

    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
    IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
    FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
    AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
    LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
    OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
    SOFTWARE.



----

## Process Details

#### Q6: What are the roles & responsibilities on the team?

Our team members are well-rounded technologically and all have a desire to learn new skills. Therefore, each of us will work as a fullstack developer (database, backend, frontend, deployment, architecture) for independant features. We plan to form subgroups for each feature/iteration, so that each team member gets exposure to both front- and backend technologies and frameworks. 

For administrative work, we plan to use a "Rotation Chair" management strategy, where team members take turns to serve as the weekly meeting organizer, moderator, and Github merge-master. 


##### Jasmeen:  
	Strengths: React, Node js, Expressjs  
	Weaknesses: SQL, DMBS Modelling, DB Migrations  
  
#### Gwen:  
	Strengths: Backend with Java/Spring and Python/Flask, Node.js, No/SQL  
	Weaknesses: docker, AWS, Production Distribution  

#### Sarah:  
	Strengths: MERN stack (focus on frontend), Python language, PostgreSQL  
	Weaknesses: Flask  

#### Rahul:  
	Strengths: Blockchain, Continuous Integration + Production Deployment, Software Architecture  
	Weaknesses: Frontend, Backend, Database  

#### Zhuolin:  
	Strengths: Python/Flask, Java, SQL, Docker  
	Weaknesses: React (only used HTML, CSS, and Javascript before)  

#### David:  
	Strengths: Python, React/React Native, Java  
	Weaknesses: Database related stuff  



#### Q7: What operational events will you have as a team?
  
We do not have a partner and are developing our own ideas. We have had two group meetings before D1: 

#### First meeting: Thursday, Jan. 27, 5 PM: voice chat on Discord. 
* The purpose of this meeting was to brainstorm features and user stories, and crystalize our project idea. We also wanted to divide up tasks related to D1 and set up a project management tool. 

* We discussed a variety of features, the pros/cons/labor cost of each, decided on the main features we wanted to have,
brainstormed user stories for each feature, and
researched similar products and made comparisons. 

* At the end of the meeting, we outlined our project idea on the Planning Document and divided up questions for each member to answer, assigned a member to complete the mockup, decided on the next meeting time, and set up a Github project board for project management. 

#### Second meeting: Monday, Jan. 31, 5 PM: voice chat on Discord. 


* The purpose of this meeting was to review and finalize our individual answers to questions outlined in D1 Planning Document and the mockup. 

* We brainstormed on the remaining questions on this Planning Document, discussed and researched alternative project management, conflict resolution, and teamwork mechanisms, 
reviewed and finalized the Planning Document and mock up, and set the date and time for the next group meeting, and chose a moderator for that meeting. 


Going forward, we plan to have at least weekly meetings on Discord for the team members to ask and answer questions. We expect the team members to check the project board regularly on their own to track tasks and progress. 
  
  
#### Q8: What artifacts will you use to self-organize?

We will keep track of what needs to get done by dividing the jobs into “To do”, “In progress”, and “Complete” columns using Trello.

We will prioritize tasks by creating a chart where we list the features that are must haves, should haves, and good to haves.

We plan to assign tasks and set up deadlines in the meetings, making sure that everyone is comfortable with the assigned jobs.

When someone starts doing a task, they move the ticket from “To do” to “In progress”. When they think that the job is completed, they show it to the team. If the team decides that no further modifications need to be done, the ticket will be moved to “Complete”.


#### Q9: What are the rules regarding how your team works?

We do not have a partner. Within the group: 

#### Communication: 
The project Discord server is our main platform of communication. We expect team members to post questions promptly when they arise to the appropriate Discord channel, especially those questions that might affect the group as a whole and require consensus or majority vote. 

Team members are expected to be engaged in the Discord discussions and answer questions promptly. 

In addition, we expect team members to attend weekly sync meetings to update the team about their progress and address any issues. 

#### Meetings: 

* Accountability and Completing action items: We plan to use a good faith approach as all team members seem responsible and responsive. We plan to give every member 3 “grace cards” for missed group meetings or task deadlines. After a person misses a third meeting or task deadline, s/he is called into a group meeting, and the whole group will decide on redistributing tasks and responsibilities. 

* Moderator:  “Rotating Chair”: Each team member will get a chance to moderate at least one meeting. 

#### Conflict Resolution: 

In principle, we will try to hear different opinions among the members and decide by majority vote. 

* When teammates don’t agree on something, we do a vote and the vote with the majority wins. When there is a tie, the members who want one thing try to persuade the other side by addressing their concerns about the decision and see if at least one person would change their mind.

* When some teammates are unresponsive, we can impose the penalty system such as the “wall of shame” which would put spotlights on the unresponsive person, in an attempt to get their attention. Another method is to deduct from their “grace cards”. These methods are described in detail later in the report. If the team member continues to fail his or her tasks, we will let the Professor know of the situation and redistribute work/rework deadlines as needed.

* A teammate could be unable to finish tasks assigned to them due to external factors. At times like this, we could redistribute the tasks among the group members to ensure that we meet our deadlines.





----
## Highlights

#### 1) We made a key decision about a mechanism to hold people responsible for attending meetings and meeting task deadlines. We considered the following alternatives: 

* Using a “Wall of Shame” or a designated text channel, which puts people on notice of their delinquencies. 
    * This is a strict and public form of holding people responsible, but may be too harsh and does not allow room for  emergencies. 

* Communication only, but no hard enforcement: 
    * This method is gentle but lacks teeth. 

* Assign people who missed the most meetings and task deadlines to undesirable miscellaneous jobs: 
    * This method turns tasks into “punishments” which is not our desired mentality. We also want to give consideration to individual schedules and workloads. 

We decided on giving every member 3 “grace cards” for missed group meetings or task deadlines. After a person misses a third meeting or task deadline, s/he is called into a group meeting, and the whole group will decide on redistributing tasks and responsibilities. 
We feel this method balances out enforcing deadlines and accommodating individual schedules, and provides a practical solution to the problem. 

#### 2) Deciding on meeting times and moderator: 

#### We considered various permutations for deciding on convening a group meeting. 

* Flexible by Request: Any memeber has the previlidge to request for meeting. A request for meeting message is sent out highlighting the purpose, duration and cost of not doing this meeting. 
    * Decision by majority: If a majority of the individuals vote yes, the meeting will be held, or
    * Decision by consensus: The meeting time will be decided using a 100% consensus protocol. If any member declines a time (for whatever the reason), we look for a different mutually acceptable time.


* Fixed Schedule with a Moderator, rescheduled only for emergencies.  
    * We have a consistent day and time of the week that we plan on meeting
    * If team members have a conflict with the meeting time, we can adjust the meeting time temporarily


Finally, we decided on a fixed schedule, with weekly meetings moderated by a team member, who keeps time and arbitrate on indecisions. This is more predictable and makes everyone conscious of making incremental progress every week, and minimizes undue delays and unnecessary postponement. 



#### 3) Project management: 
#### For the artifacts we considered Github Project Board, Clickup, and Trello
**Clickup** :
Pros:
* Has useful features such as setting deadlines, assign tasks to specific people, priorities
* Has app on mobile
* Can add description and subtasks

Cons:
* Steeper learning curve
* UI is a bit confusing sometimes (a lot of buttons and sub-buttons)

**Trello**:
Pros:
* Has useful features such as setting deadlines, assign tasks to specific people, priorities
* Can add description and files
* Has app on mobile

Cons:
* Can only add one board for each workspace
* Steeper learning curve

**Github Project Board**:
Pros: 
* Syncs with github issues automatically
* Easier to learn (less features)

Con:
* Doesn’t have additional features like assigning people to certain tasks/ set priorities, deadlines, or dependencies of the tasks directly
* Can’t add description on the cards


We decided to use Trello because it is more user friendly, lower learning curve and most of our team members already have experience using it which would reduce uncertainty.