-
Notifications
You must be signed in to change notification settings - Fork 0
Milestone 1 Report ‐ CMPE451
- Cem Güngör
- Oğuz Pançuk
- Rukiye Aslan
- Furkan Şenkal
- Mahmut Buğra Mert
- Kamil Deniz Coşkuner
- Halil İbrahim Kasapoğlu
- Muhammed Erkam Gökcepınar
-
1 Introduction
-
2 Project Status
-
3 Customer Feedback & Reflections
-
4 Deliverables
-
5 Evaluations
- 5.1 Evaluation of Tools
- 5.2 Evaluation of Processes
- 5.3 Evaluation of Status of Deliverables
-
6 Requirements Addressed
-
7 Individual Contributions
In the first week lab of the course, we started to discuss domains that we could select for a forum that would be enchanted with our creativity. After hours of discussions, we decided to implement a web and mobile app for a forum related to the financial market. Choosing a domain was not the only task at first; we needed to conduct research on where to get data for stocks, index prices, how to create charts, etc. After addressing a few different data sources and ways to build an interactive and distinct forum for financial market users, we decided to move forward with other steps of building a project. First, we named our application Bull&Bear.
Project Objectives:
- Develop a functional web and mobile application for a financial forum.
- Provide users with tools for tracking portfolios, analyzing market data, and engaging in discussions.
- Build a user-friendly and intuitive interface.
- Ensure secure user authentication and data management.
Technical Challenges:
- Implementing real-time stock data updates and market analysis.
- Integrating third-party API's for data fetching and chart visualization.
- Ensuring seamless communication between the frontend, backend, and mobile app.
Currently, all project requirements are completed. Mockups and scenarios are created. UML diagrams such as class, sequence, and use case diagrams are created.
Web app is built and deployed here. Web application has community, market, news, portfolio, login, registration, and logout functionalities displayed. Among these functionalities, login, registration, and logout are connected to backend and database.
Mobile app is built with home page, user profile page with badges, login, registration, and logout functionalities. Among these functionalities, login, registration, and logout are connected to backend and database.
As mentioned above, login, registration, email verification and logout endpoints are implemented in the backend. Backend application is connected to database and deployed. Swagger documentation for backend application can be found here.
Frontend, backend, and database are containerized using docker and deployed on DigitalOcean.
Also, a deployment pipeline was implemented for an aoutomated deployment on our development branch called dev
. Anytime a new pull request is merged into branch dev, the changes are aoutomatically deployed to droplet.
We presented our work for milestone 1 to the customer on October 22nd, 2024. Here are the feedbacks and our reflections on the customer presentation:
-
Badge name revision: On the mobile application, we named one of our user badges as "High-liked" which can be obtained by users whose at least one post gets more than 100 likes.
- The customer suggested this badge to be named something like "Popular."
- We believe that giving unique and unusual names to badges will make them appealing for users, and they will interact with the app more.
- Action Plan: We will re-evaluate the badge names and explore alternative options that are more engaging and user-friendly.
- Impact: The change in badge names is expected to be a minor adjustment that will not significantly affect the project's timeline or resources.
-
Including all stocks in the app: We planned to focus only on the US and TR markets.
- After a question from the audience, the customer suggested not to focus on specific markets like US or TR but to include all markets in the world.
- We preferred to be able to provide more features for users within specific markets than putting more effort into finding data for all markets in the world.
- Action Plan: We will conduct further research and explore the feasibility of including data for all global markets. We will analyze the impact of this expansion on development time and resources.
- Impact: Including data for all markets will require additional research, data integration, and potentially adjustments to our application architecture. This may impact the project's scope and timeline.
-
Usage of Wikidata: We currently do not use Wikidata to fetch stock data.
- The customer suggested using Wikidata to get stock-related data as it is compatible for querying.
- We will elaborate on this as a team and try to fetch stock details from Wikidata. If we ensure that we can fetch all necessary fields for each stock, we will use Wikidata.
- Action Plan: We will investigate using Wikidata as a source for stock data. We will compare the data availability and quality of Wikidata with our existing data sources.
- Impact: Using Wikidata might require adjustments to our data fetching logic and data validation processes. This could impact the development timeline but potentially enhance the accuracy and comprehensiveness of our data.
Deliverable/Work | Related Link |
---|---|
Github Code Repository | Repository |
URL to the Deployed Application | Bull&Bear |
Instruction to build Deployed Application | Quickstart |
Release Tag | 0.1.0-alpha |
Requirements | Requirements |
Scenarios | Scenarios |
Mockups | Mockups |
Class Diagram | Wiki |
Sequence Diagram | Wiki |
Use-Case Diagram | Wiki |
Project Plan | Wiki |
Communication Plan | Wiki |
RAM | Wiki |
Meeting Notes (1st) | Wiki |
Meeting Notes (2nd) | Wiki |
Meeting Notes (3rd) | Wiki |
Meeting Notes (4th) | Wiki |
Meeting Notes (5th) | Wiki |
Milestone 1 Report | Wiki |
VSCode has supported our development across both the front-end and back-end, providing a consistent and reliable environment for writing, testing, and debugging our code. Its cross-platform capability has also been crucial, as our team members use a mix of operating systems.
Github Desktop was useful at first since it allowed some of us to handle branches and commits easily.
Since React is widely used for frontend applications and we were familiar with it from a previous course, we had a relatively easy time with it. Also, there were lots of tutorials that we could utilize. Additionally, packages like NPM helped us utilize hot reloads on local which was again an advantage of using React and JS.
When creating the mobile application, we used React Native. Despite the complicated installation and clean-up process, the language's simplicity and speed gave us an advantage when writing. One of the things that motivated us to use it was the fact that people who specialize in the mobile side are accustomed to it.
The only problem we faced was the decision of using expo. It had a trade-off for easy compatibility with the usage of some packages. To be able to use some graph-related packages, we decided not to use expo.
For the backend development of our app, we used Django, a high-level Python web framework. Django's MVC architecture enhanced code readability and maintainability for our app. Additionally, Django's built-in ORM facilitated seamless integration with our chosen database management system, MySQL. Finally, its clear documentation provided access to a wealth of tutorials, forums, and third-party packages that have helped us throughout our implementation.
One downside of Django was, however, its migration dependency which caused us to manually delete some migrations to implement our custom models on built-in ones.
We used Mermaid when writing the use case and class diagrams. The most functional feature for us was that we did not need to download or pay anything to use the site's free live editor, and the editor also allowed us to instantly see the effect of the code we wrote on the diagram.
In order to create sequence diagrams, we used Plant UML. As programmers, it was delightful to only code and not draw anything for our diagram.
Docker has played a crucial role in our deployment strategy, providing a consistent environment for our application across different stages of development and production. We dockerized our app and could easily test on our computers without encountering system compatibility issues.
Digital Ocean has served as our hosting platform, offering scalable and reliable infrastructure to deploy and manage our application in a production environment. There was a 200$ free starter pack for 1 year that we benefited from using the Github Student Developer Pack. It enabled us to connect it with SSH so that we had full control (seeing logs etc.).
In the first weeks, we used Discord for our weekly meetings and as we defined development teams like frontend, backend, and mobile, we opened different channels to communicate and hold records separately. This feature helped us organize the development process.
We used WhatsApp for urgent things and meeting reminders. This helped us prioritize the messages from the WhatsApp group. After Discord was unreachable, we created WhatsApp groups for sub-groups like backend, frontend, and mobile.
After Discord was restricted in Turkey, we switched to Jitsi for our weekly meetings as it has provided us with unlimited meeting time.
We paid close attention to having reviewers on each pull-request and having distinct branch names. We defined commit conventions and PR title and description conventions. This rigorous process ensured code quality and maintainability.
For the preparation and development of the application, we gave importance to always distribute the load evenly and have a reviewer for all work. Hence, we created teams ensuring this. We will continue the distribution of work this way.
We had moderators, note takers, and wiki editors for every meeting; hence there was a reviewing mechanism inherently, and they were neatly recorded. We will continue this method.
Issues allowed us to record and review all work we need to do and did. We also created new templates for issues which made issue opening easier and have a more general look. We agree that continuing this procedure will ensure that no work will lack documentation.
After preparing the development part of customer milestone 1, we presented the current state and details of further implementations of the project to the customer. During the preparation process, we planned who would present which part, which was nice.
However, we could prepare a more structured presentation plan, like going over some user scenarios and providing each feature in those scenario flows. This way, the customer could better understand the impact of each feature on the user.
This deliverable is completed and will not need a revision unless the customer strongly addresses a change mid-project.
Class, use case, and sequence diagrams are completed and again, as long as the customer doesn't want a change that causes a change in requirements, the design part will not need a revision.
Detailed 5 scenarios are written incorporating different requirements and providing a broad image of our application.
Mockups, again, are created in detail to reflect the features we addressed in requirements. Also, since the code implementation has started, mockups will be used as a reference. So, mockups should have been completed before the milestone deadline, and they are.
The project plan is created to give a broad roadmap for our project. However, we believe there might be small shifts in the dates in the future.
The RAM is created, and responsibilities for everyone are addressed clearly. However, during the project, there might be small changes in the details, but we do not expect huge changes here.
We regularly documented all lab reports and meetings. We have three different meeting notes as lab meeting notes, weekly meeting notes, and sub-group meeting notes like backend meeting notes.
Each kind of these meeting notes and reports can be found on our wiki page here.
The addressed requirements in the first milestone are listed below:
-
User Requirements
- 1.1.1.1 Users shall be able to register with a unique username, e-mail address, and password.
- 1.1.1.2 User shall be registered with a secure password.
- 1.1.1.3 Users shall be able to log in using their registered credentials.
- 1.1.1.5 Users shall be able to log out from the system.
- 1.1.2.1.1 Guest user shall be able to view posts.
- 1.1.2.1.2 Guest user shall be able to view stocks.
- 1.1.3.1 Users shall be able to view profile information.
-
System Requirements
- 1.2.2.1 Portfolios should be created by the users by entering purchase price and quantity of stock.
- 1.2.2.2 Portfolios shall include one or more stock.
- 1.2.3.1 The system shall include news about stocks.
- 1.2.4.1 The system shall require registered users to add title to posts.
- 1.2.4.2 The system shall allow registered users to add tags to posts.
- 1.2.4.4 The system shall allow registered users to add news to posts.
- 1.2.4.5 The system shall allow registered users to add ideas in the form of text to posts.
- 1.2.4.6 The system shall allow registered users to add line charts of stocks to posts.
- 1.2.4.11 The system shall be able to list comments related to a post.
- 1.2.5.1 The system shall include badges which gain new abilities to users.
- 1.2.5.2 The system shall have a badge type called "High-liked".
- 1.2.5.3 The system shall have a badge type called "Cretager".
-
Non Functional Requirements
- 2.1.1 The application shall be available for Web and Mobile platforms.
- 2.1.2 The web application shall be available for web browsers supporting ES6.
- 2.1.3. The web application shall support FHD (1920x1080) or higher resolutions, ensuring that all charts and graphs are rendered at a minimum resolution of 1080p for clarity and detail.
- 2.1.4 The mobile application shall be available for Android(API 33 or higher) operating systems.
- 2.1.5 The mobile application shall support portrait orientation on mobile devices.
- 2.1.6 The mobile application shall support FHD or higher resolutions, with charts and graphs rendered at a minimum resolution of 720p for clear visibility.
- 2.1.1 Application shall be available in English Language.
- 2.3.3 User shall verify their email addresses after signing up to ensure the validity of accounts before logging into the system.
- 2.6.1 The application shall load within 3 seconds under normal network conditions.
For the complete list of requirements, refer here please.
- Responsibilities:
- Main contributions:
- Code-related significant issues:
- Non-code-related significant issues:
- Pull requests:
- Additional information:
- Responsibilities:
- Main contributions:
- Code-related significant issues:
- Non-code-related significant issues:
- Pull requests:
- Additional information:
-
Responsibilities: I was in the backend team and mainly responsible for Dockerization of the project, managing database connections, and implementing the endpoints needed. Also, usually setting time for meetings.
-
Main contributions:
- Developed and implemented the backend API endpoints for user authentication (login, registration, email verification).
- Designed and implemented the database schema for user accounts and other essential data.
- Containerized the backend application and database using Docker for consistent deployment.
- Configured and managed the database connection within the Dockerized environment.
- Containerized the frontend application and database using Docker for consistent deployment and tests on local machine.
-
Code-related significant issues:
-
Non-code-related significant issues:
- Organized and documented the lab reports, meeting notes for the whole and backend team.
- Assisted in the creation and updating of the non functional requirements, sequence diagrams, ensuring accurate representation of responsibilities.
-
Pull requests: Pull requests apart from mentioned above
- PR #307 - Fixed migration inconsistency caused by Django migration dependency.
- PR #333 - Containerized frontend along with backend application and database for tests on local machine.
- PR #343 - Fixed registration flow to direct user to verify her/his email.
- PR #344 - Reflected implementations on development branch onto main branch after testing on development branch for release.
-
Additional information: In addition to the tasks I have provided above, I also presented our first customer milestone presentation.
- Responsibilities:
- Main contributions:
- Code-related significant issues:
- Non-code-related significant issues:
- Pull requests:
- Additional information:
- Responsibilities:
- Main contributions:
- Code-related significant issues:
- Non-code-related significant issues:
- Pull requests:
- Additional information:
- Responsibilities:
- Main contributions:
- Code-related significant issues:
- Non-code-related significant issues:
- Pull requests:
- Additional information:
- Responsibilities:
- Main contributions:
- Code-related significant issues:
- Non-code-related significant issues:
- Pull requests:
- Additional information:
-
Responsibilities: I am part of the mobile team and responsible for configuration and implementation of the mobile application and designing general structure of the project.
-
Main contributions:
- Contributed to system requirements and class diagrams
- Helped to design of the page structure of the app and implementation of the functionalities
- Configured the mobile project and solved the initialization errors
- Designed and implemented home and profile page of mobile application
-
Code-related significant issues:
-
Non-code-related significant issues:
- I made a research about graphics manipulation tools for web and mobile app. (related issue)
- I significantly contributed to write requirements in general and wrote the system requirements. (related issues 1, 2, 3)
- I have created the account on DigitalOcean. (related issue)
- I created the class diagrams with my team member @Halil-Ibrahim-Kasapoglu. (related issue)
-
Pull requests: PRs apart from above
-
Additional information:
- I generated the apk of our mobile application.
- I presented the mobile part in the first milestone presentation.
- I worked on the integration of graphics library in our mobile app, but I can not integrate graphics until the first milestone.
- Lab Report #1,24.09.2024
- Lab Report #2,01.10.2024
- Lab Report #3,08.10.2024
- Lab Report #4,15.10.2024
- Lab Report #5,06.11.2024
- Lab Report #9,10.12.2024
- 1st Meeting, 24.09.2024
- 2nd Meeting, 01.10.2024
- 3rd Meeting, 08.10.2024
- 4th Meeting, 15.10.2024
- 5th Meeting, 06.11.2024
- 8th Meeting, 03.12.2024
- 1st Meeting, 03.10.2024
- 2nd Meeting, 10.10.2024
- 3rd Meeting, 17.10.2024
- 4th Meeting, 19.10.2024
- 5th Meeting, 24.10.2024
- 6th Meeting, 02.11.2024
- 8th Meeting, 15.11.2024
- 9th Meeting, 28.11.2024
- 10th Meeting, 04.12.2024
- 11th Meeting, 12.12.2024
- Halil İbrahim Kasapoğlu
- Rukiye Aslan
- Kamil Deniz Coşkuner
- Mahmut Buğra Mert
- Furkan Şenkal
- Muhammed Erkam Gökcepınar
- Cem Güngör
- Oğuz Pançuk
Orkun Mahir Kılıç
SemanticFlix Archieve
- 1st Meeting,19.02.2024
- 2nd Meeting,21.02.2024
- 3rd Meeting,03.03.2024
- 4th Meeting,07.03.2024
- 5th Meeting,10.03.2024
- 6th Meeting,14.03.2024
- 7th Meeting,21.03.2024
- 8th Meeting,01.04.2024
- 9th Meeting,17.04.2024
- 10th Meeting,18.04.2024
- 11th Meeting,25.04.2024
- 12th Meeting,02.05.2024
- 13th Meeting,09.05.2024
- Halil İbrahim Kasapoğlu (Communicator)
- Rukiye Aslan
- Kamil Deniz Coşkuner
- Mahmut Buğra Mert
- İrem Nur Yıldırım
- Furkan Şenkal
- Muhammed Erkam Gökcepınar
- Osman Yasin Baştuğ
Okay DemirSait Hızlı