-
Notifications
You must be signed in to change notification settings - Fork 31
Home
Welcome to the PlexShare wiki!
PlexShare aims to be a lab session monitoring application that allows an instructor and students to interact, collaborate and share content in the form of chat messages and files. It will also support a digital whiteboard and screensharing options. This is a project that is being done as a part of IIT Palakkad's CS5617 (Software Engineering) course for the year of 2022.
On this page, you will find details about:
- Project Goals
- Current Processes / Workflows / Guidelines (including Source Depot maintenance)
- Project Management Details
As mentioned in the introduction, the end goal of the project is to develop a fully functional lab session monitoring application. To achieve this, multiple teams have been formed, each tasked with creating a specific module core to the project:
1. Networking Team
2. UX Team
3. Dashboard Team
4. Content Team
5. Screenshare Team
6. Whiteboard Team
7. Cloud Team
The Leadership Team (comprising of the Project Manager and Technical Architect) is responsible for overseeing the above 7 teams.
Loosely adhering to the Waterfall SDLC, the project timeline can be divided into the following phases:
i) Writing detailed technical specifications (design docs).
ii) Coding the individual components / modules.
iii) Integration of the modules.
iv) Fine-tuning, testing & finalisation of code.
- Phase (i) - Completed (you can find detailed specs here)
- Phase (ii) - Completed
- Phase (iii) - Completed
- Phase (iv) - Completed (minor tweaks may be made in the run up to the demo)
GitHub will be used for version control & development. We will be using the below hierarchy:
- The main repository is maintained by the Leadership Team.
- The repositories immediately down the hierarchy are direct forks of the main repository and are maintained by team leads.
- The repositories further down are direct forks of the team leads' repositories and are maintained by the corresponding team members.
In particular:
- Fork the repository of their respective team leads.
- Make pull requests (PRs) in their lead's repository, associated with their feature implementations / modifications.
- Perform sufficient unit testing before making PRs.
- Fork the main repository.
- Review code before accepting PRs from fellow team members.
- Make pull requests (PRs) in the main repository, associated with new feature implementations / modifications.
- Perform sufficient regression testing before making PRs.
- Review code before accepting PRs from fellow team leads (and make final decisions).
- Perform E2E testing.
Some useful links for coding conventions, best practices, etc:
- C# Coding Conventions - Microsoft
- Another doc on C# Conventions
- Trace Class
- Garbage Collector Memory Optimisation using IDisposable interface (thanks Mayank!)
- GitHub PRs
Link to our project's Azure Boards page
- We will be using Azure Boards to keep track of the project's various tasks and deadlines. Each module team is assigned an epic (main objective), under which child tasks (actual work items) are created.
- All members are added to the Azure Boards project titled 'Software-Engineering' as Project Contributors. Anyone can define tasks for themselves (or other people), although it is primarily the responsibility of the team lead to define tasks and distribute them among their team members. A deadline or an estimated time of completion can also be added to these tasks after discussion with the leads / the leadership.
- The main repository is linked to Azure Boards. Upon a commit / pull request, link it to the relevant task defined in Azure Boards.