Reflaktor Project

“Reflaktor” is a hostel management web application aimed at students on our campus.

Repo-Visits

Deployed web app

https://bits-hostel.herokuapp.com/

Contributors

1. Smiket Barodia 👽 (GitHub)
2. Shubham Asopa 🎅 (GitHub)
3. Hritik Singh Kushwah 🦸‍♂️ (GitHub)
4. Akshit 🧙‍♂️ (GitHub)
5. Bhavish Pahwa 🏄‍♂️ (GitHub)

Full Product Report

Product Report

Click to view full product report with all details related to the product's developement and management.

Usage

Read

• This web application can help students to post their complaints directly on the System which becomes visible to the hostel supervisor, hostel representatives, and the respective hostel staff.

• Students can give different tag attributes to the complaints using a drop-down menu that basically indicates the scope of the complaint ( example:- carpenter, plumber, electrician, IT ).

• Hostel Representatives can also view the complaints and check which complaints have not been resolved and which are pending for a long time.

• Different staff members can view and take up the complaints which are under their scope and after completion mark them completed.

• Hostel Supervisors and Admin can see monthly reports of complaints and analyze the important issues.

Product Backlog

Use Case Diagram

View

Class Diagram

View

System Architecture

View

System design decisions based on our usage and use case for further development of the product

• We found it better to use a Monolith as it is simple to develop relative to Microservices and easier to deploy and Microservices often have problems related to security and network latency and microservices are more costly in terms of network usage and as our application is related to educational organisations so it’s better to have low latency.
• Also we use both RDBMS and NoSQL databases so that the Data that needs operations like joins to be performed can be stored in RDBMS, while others can be stored on NoSQL databases.
• We use a database cache to help provide information which is frequently accessed, without having to query the databases. We did not use a CQRS based monolith because in our application there is no asymmetric factor of read and write requests.
• Also CQRS is especially to be used when the number of reads is much greater than the number of writes which is not our case and hence it is not used. We use external analytical services for report generation by using a data streaming service and a big data processing platform.
• These external systems can be further connected to Google Cloud ML systems and be used for further prediction and using this data we can train predefined models for further analysis at regular intervals.