-
Notifications
You must be signed in to change notification settings - Fork 1
Milestone 1 Report
- Table Of Contents
- 1. Executive Summary
- 2. List and Status of Deliverables
- 3. Evaluation of Deliverables
- 4. Evaluation of Tools and Processes
- 5. Table of Work Done by Each Team Member
- 6. Deliverables
Our project is a multi-faceted social media platform geared towards the main players of the gaming industry, those being developers, gamers and event organizers. The projects main goal is to become a social media for video game enthusiasts to use for interacting with the community and discovering further communities they'd be interested in. Our secondary goal is to differantiate ourselves from existing social media that fills these niches, such as Reddit, by having unique core functionalities. The main functionalities users will interact with are the "Games", "Groups" and "Events" functionalities.
The main functionality concerning games and their communities is the "Games" page. This page will have an individual, unique page for every game by only giving the permission to create a game page to admins and verified developers. Initially, the database of games can be created by scraping various online game stores. The main games page will give the user ability to search, sort and filter games in order to find the main hub of a community. Each game page will host a review page to give an honest first impression to the users. The reviews functionality is especially important to ensure the game pages are community driven, and don't turn into a marketing tool. Indvidual pages will also have a forum that will act as the main interaction point for the players of those games.
The group functionality is going to be used to host any community that is related to gaming, but is not defined only by the a game. This can range from a group of friends that regularly play with eachother, to a community of users that favor a specific playstyle. To cover this range, they are two types of groups that are differantiated by their membership policy. A public group accepts anyone who wishes to join the community, while a private group accepts users by and appliation process. By having this distinction, we hope to cater to a diverse selection of users.
The forum functionality of the project is a multi purpose component that handles all the inter-community communication in the project. The usage of the forum structure was chosen because it is the main structure used in our main inspirations for the social aspects of the project, and works for both large and small communities. A forum will exist for each game, but also each group so that the project will be able to host small and medium sized communities.
The events functionality is an another core functionality of our project. The events page will be used to advertise various events, by professional event organizers or other community members. Those events range from large gaming conventions to online machinima performances. Gamers can filter those events to their interests and find opportunities to socialise with other gamers, participate in fun events or find new interests.
There will be a lot of other functionalities to make the users experience more streamlined and interactive. Some of the highlights are: a customizable profile page that users can use to track their and others activites or highglight their achievements, a central feed users can use to browse all the forums they are subscribed to, a promotion system to act as a revenue generator, and a annotation feature to enchance the image posts.
In summary, we hope to create a central hub for the masive hobby that is video gaming. We tailored our core functionalities in a way that will result in a community driven social media that will also cater to proffesional users, so that the user does not feel alienated. We also think we achieved to differantiate ourselves from other social media so gamers will have a reason to choose us over competitors.
Our software engineering team consists of 12 members. Our primary objective this semester has been to equally distribute the work among the team members and improve the project with contributions from each of us. In order to that, at first we all discussed about tasks and try to reach a common decision. Afterwards we divided each task into sub-tasks and tried to give responsibility to every member of team. Some tasks were challenging, so that they were assigned more than one person.
Initially, we agreed on a communication plan and weekly meeting time. We though that it will be beneficial to do our meetings face to face. Hence we hold our regular meetings on every Thursday in B5. Also, for the online communication we are using Whatsapp and Discord.
Then, everyone in the group created their own personal page and made a research about a repository. After that, we created our homepage and sidebar where all the links and information about the project can be found.
After these stuffs, we determined the core features of our project and the determined the functional and non-functional requirements according to our studies. We did research on how the requirements are created and observed the functionalities of websites that is similar to our project idea.
To help the customer comprehend our project and demonstrate how it would seem in various situations, we have prepared mockups. After that, we developed user scenarios based our mockup designs. To show which components our application consists of and how our application will work, we first have designed Use Case and Class Diagrams based on our requirements. Then to validate those diagrams we designed Sequence Diagrams.
We have worked on design issues until now. From now on, we will focus more on issues related to implementation. We are going to discuss about the tools and frameworks, which might be useful for us for the next semester. We will decide language preferences for the project and make some research about the project features. For example, we want to add a feature that enables users to signing up to our application with using their Steam accounts. For this feature we will make some research about the feasibility of it and read the Steam Web Api documentation. Also we will learn how to use Figma because it will help us to concretize the designs in our minds.
| Deliverable Name | Delivery Status | Due Date | Delivery Date |
|---|---|---|---|
| Up to Date Project Repository | Delivered | 10/04/2023, Monday | 10/04/2023, Monday |
| Requirements | Delivered | 10/04/2023, Monday | 23/03/2023, Thursday |
| Mockups and Scenarios | Delivered | 10/04/2023, Monday | 10/04/2023, Monday |
| Use Case, Class and Sequence Diagrams | Delivered | 10/04/2023, Monday | 10/04/2023, Monday |
| Project Plan & RAM | Delivered | 10/04/2023, Monday | 10/04/2023, Monday |
| Communication Plan | Delivered | 10/04/2023, Monday | 06/03/2023, Monday |
| Milestone Report | Delivered | 10/04/2023, Monday | 10/04/2023, Monday |
In order to manage the project as effectively as possible we have put our utmost effort to keep the wiki page organized and up to date. We have documented all our tasks as properly written issues with informative labels so that it will be easier to keep track of what to do and when to do. We have created clean README and wiki home page so that any visitor can find the information he/she wants without having to deal with clustered wiki pages. We have also created a nicely organized side bar to ease the process of navigating in the wiki. In order to make sure that pages created by different group members will follow the same style we have also created templates for wiki pages and issues.
We have seperated the requirements into two parts: Functional, and Non-Functional. We have divided Functional into User Requirements and System Requirements and divided both of them further to match categories with functionalities of our platform such as forum, game reviewing etc. This is done to ensure that related requirements stick together and in the design process whenever a group member or a visitor wants to clarify some details about the project, instead of going over the whole requirements page, he/she will only read the part that he/she is confused about.
We have five main scenarios in our application: Unregistered User Scenario: Sign Up , Unregistered User Scenario: Search for a Game and Browse the Game Forum , Registered User Scenario: Create An E Sport Event , Registered User Scenario: Search and Join A Group , and Registered User Scenario: Enter a Forum And Make a Post. Each scenario demonstrates different features and functionalities of our application. We assigned 1 person per scenario. Each person described the steps required to complete the actions in their scenario. We used Figma, a design tool, to create mock-ups that visually represent the scenarios. These scenarios align with our requirements and will be useful in the initialization process.
Our team collaborated to create class, use-case , and sequence diagrams to illustrate and summarize our program's functionality. We completed the diagrams in accordance with our project requirements as per the guidance provided by the course instructors. We began by studying UML and constructing the class and use-case diagrams, then moved on to the sequence diagram. We decided to first design the class diagram , then the use-case diagram since both diagrams are necessary for designing the sequence diagram. The diagrams were created through a collaborative effort involving multiple team members and numerous productive discussions, utilizing the features of the Diagrams.net application. We will keep the diagrams up-to-date as the project progresses. Working on our design has allowed us to revisit and reconsider some of the items on our list of requirements. By adjusting the items we addressed, we were able to create an updated version of our requirement list that more precisely reflects our project than earlier versions. These design diagrams will be useful during the coding phase of our project as they depict most of the interactions between external users and the software components.
The Use-Case Diagram provides an overview of the system's functionality from a user's perspective. It presents a graphical representation of the way users and the system interact with each other and visually portrays the different routes that each user type can take to accomplish a specific task based on the project's specifications. Our use-case diagram encompasses the different pathways that may be taken by the seven identified user types, which include registered and non-registered users, administrators , game developers , event organizers , forum moderators and group moderators. Our use-case diagram demonstrates the organization and relationships between the system functionalities by using two specific arrows designed for this purpose. The arrow indicates that one use case includes the functionality of another use case. This means that the included use case cannot be executed independently and must be executed as part of the including use case. The arrow represents an "extend" relationship, which means that one use case extends the functionality of another use case. This is used when an optional behavior can be added to a use case. Overall, the Use-Case Diagrams were successful in communicating the system's functionality to all stakeholders, and they provided a solid foundation for the development of the system.
The Class Diagram is a key design artifact that defines the structure of the system. It presents an overview of our project's organization by documenting all of the classes, properties, and operations of our software, as well as the relationships and dependencies between them. It provides a more detailed outline of the program's capabilities than the use-case and sequence diagrams. We have used five relationship arrows to describe relationships and dependencies between the classes : Association , Aggregation , Multiplicity , Composition and Directed Association. The Association arrow represents a relationship between two classes. Aggregation arrows are utilized to express a relationship between two classes that is not as strong as a direct association, indicating that the child class can exist independently of the parent element. The multiplicity arrows indicate the potential number of items that can be held by a class in our class diagram. Composition associations represent connections between classes where the contained object is dependent on the container class and only exists as long as the container class exists. A directed association indicates a robust connection between classes, emphasizing the direction of the relationship. Overall, the Class Diagrams were successful in providing a detailed view of the system's structure and helped to ensure that the team had a shared understanding of the system's architecture.
The Sequence Diagram is a valuable tool for modeling the interactions between different components of the system. Sequence diagrams are utilized to illustrate the interactions among objects for a specific use case and to emphasize the classes and their connections through functions.
In order to keep track of contributions of each member a excel sheet for Responsibility Assignment Matrix is created which documents the contributors, reviewers, leads etc. By expanding on that we have also created a project plan excel sheet which also includes information about when group members started on working on these tasks and when did they finished them. Which helps us to determine which task take how much time and will also help in future when deciding on deadlines because we have more information on completion duration of tasks.
The day the groups are announced we created a whatsapp group for temporary communication until we decided on a better option. After that we have decided that discord is the best platform for our communication and online meetings. But most of our meetings are done at CmpE building as most group members favored face to face meetings rather than online ones. In our first face to face meeting we have assigned some group members to find a suitable task management tool. Trello was chosen as that tool which we have used to distribute tasks. Apart from these github issues are also actively used to communicate on the course of some tasks. Usage of these tools provided us with fast communication which resulted in better team work.
In order to achieve different tasks and objectives we needed to use variety of tools and applications throughout our development process. These tasks and objectives basically include communicating among team members, job distributions and collabrative development. In addition to these features there need to be some sort of tools that team members can track each other and themselves. Following subsections will be mentioning about the tools and applications we've been using during our development processes.
GitHub is the main platform where every step of development and update is observed throughout process. One can view all information about team and team members, project description and purpose. In addition to these elements one can also observe the deliverables of the project such as requirements, mockups, diagrams such as use case diagrams, class diagrams and sequence diagrams. Every team member or any sort of visitor to our repository can understand the workflow and view every team member's participation to the project through issues. "Issue" section of GitHub is pretty crucial for the team since team members can track each other's processes and plan their workflow accordingly. Besides tracking, issues are also an efficient way of giving feedback via its commenting feature. In addition to its functionality, issues are great for user experience of team members since it basically simplifies the understanding each work's or feature's category via its tagging system, which results in faster development processes for team members.
Discord is a widely used communication application with variety of features such as group voice chatting, group video chatting, creating text channels, et cetera. The reason behind our main choice of communication application being Discord is its ease of use. We can send each other texts, images, audios, diagrams or other type of files so rapid and easy and it assisted a lot to our agile development style. We can also create as many text channels or voice channels as necessary, so with the help of this feature after distributing tasks among team members, every sub group can communicate in their own channel, hence we may able to divide the collabrative work into pieces which fastens our development processes. Besides all these features, most importantly Discord is free, hence we didn't need to think about free trial expiration date or something that is taken account as a limitation. Overall, Discord provided all the basic needs we required from a team communication application and we are also planning to keep the same structure for the software implementation part of the project.
For our mockup designs we're mainly used the application called Figma. Figma is a collabrative web application for interface design and it is indeed very popular for professional use in worldwide. The feature set of Figma focuses on user interface and user experience design, with an emphasis on real time collaboration, utilizing a variety of vector graphics editor and prototyping tools. Real time collabration feature played a crucial role for our choice of Figma and via this feature all team members can work together simultaneously and everyone can view each other's progress easily. Besides these features, Figma is free and very easy to use. We're planning to use Figma as our interface design tool for further cases if there isn't any constraint that pushes us to use another design tool.
diagrams.net is a free open source graph drawing software developed using HTML5 and Javascript. It can be used to create diagrams such as flowcharts, UML diagrams, organizational charts and network diagrams. diagrams.net provides us a very useful, simple yet effective drawing tool that we can use for our diagrams. As a group we used diagrams.net affluently while designing our class diagrams, use case diagrams and sequence diagrams. Since it is free and cross platform, every member of our team could use diagrams.net without any constraint or difficulty. diagrams.net also supports online collabrative design in addition to its offline design opportunities, hence with the help of collabrative design feature we can work together or independently but simultaneously without any restriction. Also, via importing feature it is really easy to combine each member's diagramss into a single design file which results in rapid and organized development process on our side. Overall, diagrams.net provides a really simple, effective, easy to use and free graph drawing platform and we are plan on to use this platform as long as there is any kind of restriction that compels us to use another drawing tool.
Trello is a web-based, list making application and frequently used by our team for task distribution processes. After each weekly meeting we're basically create some tables that are representing different tasks and assign members to that table. The sole reason behind using Trello is, its ease of use and it isn't a good practice to add everything into our GitHub repository since then it would be too crowded and every deletion or update is added in history of commits of repository. Hence, we're using Trello as our task distribution platform due to its simple interface and efficency. Also, someone who cannot make to weekly meeting, can assign himself/herself a task on Trello, or can learn about his/her tasks on Trello. We can also change content of the tasks or update some of the tasks on trello easily, which is not the case for GitHub issues for example. Overall, Trello is a great platform for task distribution and we're planning to use Trello until there are any difficulties or restrictions occur with this platform.
GitHub's issue section is actually a great part of a project repository since it enables us keep track of the workflow of our development processes. After every weekly meeting we're coming up with different tasks and these tasks are need to be distributed. One of the main platforms we're affluently using is GitHub issues. One of the main advantages of issues is that each member can track both their and other team members tasks through GitHub issues. We've also created an issue template in order to keep things organized and simple. Every issue nearly corresponds to a task, hence every issue has at least one assignee. In addition to assignee via using features of our issue template, one can also assign a reviewer to an issue and this feature enables us to keep feedbacks efficient and more reliable. In other words, in order to close an issue, and issue's work need to be verified by at least two people, assignee and reviewer.
We manage the issues mainly with its description and labels tagged to them. Labels are categorized into three main categories such as "status", "priority" and "type". All issues are created with "status : assigned" label, and when assignee starts to work with his/her task, he/she needs to change the label into "status : in progress", and after assignee's work is done, he/she also need to change the label into "status : in review" so that reviewer can examine the resultant work and evaluate. After this step, reviewer may close the issue via changing the label into "status : done" or give feedback to the assignee using adding comment feature of GitHub issues. We're also included "status : canceled" if there is a misopened or retracted issue/task. In addition to status lables, we're using priority and type labels frequently. Priority labels basically shows the urgency of the task which categorized into low, medium, high and critical. Type label shows the what category of feature task is about. It may be about documentation feature or design feature of the project, hence type labels simplifies the categorization of our work.
After our online meeting on the very first week of the semester, we're decided to hold our other weekly meetings face to face on a classroom or lounge. We designated a common time interval where everyone is available to meet offline and started hold our weekly meetings face to face. Before every meeting, we've come up with weekly agenda that includes the topics need to be handled and/or covered during that week's meeting. Also we've randomly assigned every team member to be moderator or note taker of different weekly meetings, with the help of that everyone will be almost equally contribute to meetings and any sort of unfairness will be prevented.
Weekly meetings plays a crucial role for our development process. After covering agenda and deciding discussion topics, we're making a weekly plan that contains tasks and overall workflow. So, most of the time a discussion on the weekly tasks followed by distribution of these tasks, which will be done until the next week’s meeting. After each meeting one of our team members which is most of the time is the note take of the week takes the meeting notes and uploads them on our GitHub repository, hence everyone can keep track of what were the discussion topics of the week and also can observe the action items to keep track of who is doing which tasks, this is an important part of the weekly meetings which is understanding the workflow easily.
Every two or three weeks depending on the workload on the time interval we've planned a meeting with our stakeholder who is our teaching assistant. We're mostly discuss about what we've done and the overall quality of our work. Most important aspect of these meetings are her feedback about resultant work of group. After these meeting we're updating our work according to her feedbacks. Hence, we keep ourselves updated everytime we're adding a new feature to our product. This type of meetings play a crucial role for our development process since there are lots of tasks to handle and it might be the case that not every group member pay enough attention to their tasks and overall work plan may fall behind, yet it's became easier for us to reecover from any fallbacks with the help of pinpoint feedbacks and comments of our teaching assistant.
- Ali Başaran
- Alperen Bırçak
- Arda Kabadayı
- Bilal Atım
- Can Uzduran
- Çisel Zümbül
- Deniz Ünal
- Ege Ekşi
- Halis Bal
- Harun Sami Çelik
- Mehmet Said Yolcu
- Zeynep Baydemir
- Authentication Mockup
- Events Page Mockup
- Forum Mockup
- Game Reviews Mockup
- Games Page Mockup
- Group Page Mockup
- Home Page Mockup
- Profile Page Mockup
Cmpe 352
Cmpe 451
Cmpe 352
Milestone 1
Final Milestone
Milestone 1
Milestone 2
Final Milestone
- Authentication Mockup
- Forum Mockup
- Game Reviews Mockup
- Games Page Mockup
- Group Page Mockup
- Home Page Mockup
- Profile Page Mockup
- Unregistered User Scenario: Sign Up
- Unregistered User Scenario: Search for a Game and Browse the Game Forum
- Registered User Scenario: Create Post in a Game Forum
- Registered User Scenario: Search For Groups and Join A Group
📝 RAM
- Issue Template
- Personal Information Template
- Meeting Note Template
- Contributions Template
- API Documentation Template
API Documentation for Practice App
- Top Games
- Yugioh Card
- Hearthstone Card
- Games By User
- Game Reviews
- Games By Genre
- Games By Category
- Game Suggestions
- Esport Tournaments
- Achievement By Game Id
- Rock Paper Scissors
- Game By Deal