Project Delivery 3
Alan Ricardo González Aguilar A01633872
Carlos Ernesto López Solano A01633683
Luis Eduardo Núñez Altamirano A01633894
Team: Beaver River
Project: Scheduling Management System (SMS) for the EIAD
Design based on the interviews and client requirements
As mentioned in the first delivery of our project, our goal is to improve for once and for all a very inefficient system used to do reservations of classrooms and/or equipment of one of the buildings of our campus. Therefore, from the start we had the goal of designing an efficient, reliable and friendly system of reservations that followed the next purpose: can be used by anyone anywhere on the campus at anytime they would want to do a reservation.
We designed a simple and efficient user interface, with the power to automate many processes that could take a human a lot of time, and validate most of the inputs entered by the user. It should implement API’s for calendar use and a database implementation to manage the data of the reservations and the users.
For the calendar API we choose Google Calendar for the simple functionality and implementation, and for the database we choose Firebase based on the expected bandwidth use and the simple implementation process.
Based on the interviews and requirements of the client, we decided the tool should have 4 types of user, each with its own permits and displayable views in the app:
- Regular student who wants to make a reservation, which could include seats of a classroom as well as equipment (on-site or storaged)
- Professor who wants to rent the whole classroom (and maybe all the equipment too) for a class, conference, crash course, etcetera.
- Member of the security department who, at certain times, needs to check who is inside of the classrooms, and to make sure the reservations are being respected
- Administrator(s) of the classrooms and equipment of the building. Can add devices and classrooms, as well as remove them, and check the reservation forms made by other users in order to accept them or deny them
The permits and available functions for each user are shown in the Use case located later on this document.
The app manages the functionality of all the users while dividing into different “views” or sections. Some views are available for all users while other are only accessible with valid credentials.
Here are our designs for the different views the tool would have:
The main page of the application would include a view of the existing reservations in any of the classrooms of the building. The element would show the details of the classroom, the name and ID number of the person who did the reservation, and of the other team members (if necessary), the daytime of the reservation, the reserved equipment from the lab (static equipment such as PC’s or racks, or carry-on equipment such as cables or electronic devices), and the observations or comments about the reservation made by the person who reserved.
This page would be visible for the Student, Professor, Security and Administrator users.
This view is generated from the index.html when a user wishes to do a new reservation.
The user should indicate all the information shown in screen, such as the desired classroom, name and email of the person who is reserving, the daytime of the reservation, which equipment is going to be used, observations or comments, and team members.
To finish the process of reservation, the user needs to send the form to the Administrator with the button at the bottom of the page. Later on, the Administrator would review the form and accept it or deny it.
The notifications involving the requested reservation will reach the user and the Administrator by email.
The login page would be visible from the main page for the Student, Professor, Security and Administrator users, but only the Administrator user would have credentials so it would be the only user with the possibility to use and access the login interface.
Through this page the Administrator would be able to access the Administrator dashboard of the application.
The application dashboard, as said earlier, would only be available for the Administrator and would need credentials in order to access it.
It would include three sections:
- Reservations review
Here the Administrator can access and review the reservations made by other users in order to accept it or deny it. The Administrator can write observations and comments as well as restrict the use of some equipment.
Also, in this view the Administrator could check the accepted reservations to check for availability
- Classrooms and equipment management
This section would be destined to manage the existent classrooms as well as the equipment stored in them. The Administrator would be able to:
- Add equipment
- Remove equipment
- Add a classroom
- Remove a classroom
Each operation would have a specific button to display the corresponding menu in the actual view. The Administrator would be able to return to the dashboard at anytime.
- Manage users and classes
In this section, the Administrator could register another person as a new Administrator, and add or remove classes that could interfere with the schedule of the classrooms.
- There is no limit for the number of existing Administrators, but for based on the requirements of the client we know for sure there won’t be a lot of them
- The process starts in this section when an active Administrator generates a link where the new Administrator would register
- The new Administrator has to enter a username as well as a password.
- After the registration process, the new Administrator would be able to access the Administrator dashboard
As described earlier in this document, the tool would be mounted on a local server on the campus. This would make it easier for the students and professors to make or check reservations of the many classrooms in the building.
What did you learn about the process of design in this course/project?
We discover that it is very important to have a design process before starting to code. Usually when someone asks us to create a new project, the first thing we think about is code. There are many tools that help us to design everything that we need, the diagrams, the cycles of life, design patterns, etc. It is very important to have a previous planning, and this will help us to create a better software and a successful project.
Link to video: https://www.loom.com/share/9220445c0520411f9fa0f9fe7d081762