Final Delivery (Not a Blog)

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.

Due to the ease of use and flexibility of web technologies, it seemed that it could be a good idea to take advantage of this set of technologies to create a web app or web page and mount it on a server located inside the campus. We concluded that the best option would be to use HTML and CSS to bring structure and style to the tool and a JavaScript framework to develop the core functionality (we choose Vue.js because of its power and ease of use, as well as the clear documentation it includes).

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:

  • Student
    • Regular student who wants to make a reservation, which could include seats of a classroom as well as equipment (on-site or storaged)
  • Professor
    • Professor who wants to rent the whole classroom (and maybe all the equipment too) for a class, conference, crash course, etcetera.
  • Security
    • 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
    • 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:

  1. 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

  1. 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:

  1. Add equipment
  2. Remove equipment
  1. Add a classroom
  1. 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.

  1. 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.

  1. 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
  2. The process starts in this section when an active Administrator generates a link where the new Administrator would register
  3. The new Administrator has to enter a username as well as a password.
  4. 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.  

Use cases

Class Diagrams

Link to video:

Leave a comment

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create your website at
Get started
%d bloggers like this: