Literature Paper

Through this document we want to describe our client and the team members the progress we have made on the project so far. We are using Agile Scrum methodology where we have divided our project into different sprints. This document reports the progress made on the first sprint which ended today and provides insight about future sprints and goals.

The project implements a computerized garage system that enables customers to choose suitable spots for their vehicles online. The system will include user interface that eases the customer experiences. They can log into their account from anywhere with an internet connection. Customers can make reservations well in advance according to their needs. They can also make special requests, for example, a customer may only want to park on the first floor. Those requests will be handled by parking lot managers. Once a customer makes a reservation, the system updates the accessibility checklist of parking spot.

The system will implement all the functions mentioned in the project description and the feasibility report. For example, the web-based system will allow users to create an account, login, and update their information. We also have listed some optional features that we plan to implement if we complete the fundamental features well ahead of time. An example of an optional feature is allowing users to have yearly subscription.

1. Time Risks: We currently are planning out the next few months to have this project complete. However, if something does come up and we are unable to solve the issue, we may need to cut back on one or more features to have this project complete by the end of the timeframe.

2. System Migration : While we use a locally run server and database to test, hosting one or finding a provider to host may prove challenging or costly. To avoid any confusion or costly mistakes, we will ask the client their opinion on the matter.

3. Functionality Risks: As we progress through the project, some functional requirements may be changed or altered by the client or seen as infeasible to implement. We will talk with the client through this process and adjust our scope accordingly.

4. Risk Management: To avoid any surprises for the client, we will keep in contact when something does arise that would throw off the schedule for delivery and milestones. We will also try to minimize this by scheduling time for bugs, unexpected features, and anything else that may arise during the course of this project.

Figure 1: Project Outline

We are implementing the Agile Scrum Methodology. Scrum is a management system that consists of a group of techniques associated with the creation of a projects in multidisciplinary teams in which tasks are accomplished in short time frames also called sprints. We implemented our project with the Agile Scrum management system because of five main reasons: better sizing of project, realistic project delivery date, quick team learning, fast and accurate feedback, and customer satisfaction.

Agile Scrum methodology segments the project into sprints and makes project much more manageable than try to cover an entire project from start to finish. Using this methodology, it is easy to identify the objectives of each stage and even the possible setbacks that might be encountered along the way. Likewise, for our first iteration, we had our first sprint that lasted for two weeks. The first sprint was focused on the following things:

According to the business needs and requirements, we created a system design to define architecture, components, modules, and interfaces for our system. We have initial UI/UX designs, architectural design, database design, and Entity Relationship Diagrams for the web-based application. We also designed prototypes for each of our components to help build pages for the application. One of the prototypes is shown below:

Figure 2: Payment Page Prototype

The figure above is an initial sketch of our payment page. We will build our payment page based on that figure. When a user wants to make their payment, they will be prompted to this page. They will have to put in their payment card and billing information to proceed to the final checkout for a successful payment.

After creating the feasibility report and the system design, we focused on turning our ideas into a reality through Proof of Concepts. We removed any unnecessary or non-feasible task from our product backlog and started to aim on the ideas that were viable. For example, for now we removed the idea of having physical sensor because it was unreal for the time being. Instead, we came up with an alternative idea of using another computer as a sensor and test the working of our system. It not only makes our project feasible, but also in the future, if we get the actual sensor, we can do a simple fix and make it work.

After completion of system design and proof of concepts, we concentrated on the Phase One Development. For the phase one development, we had:

· Frontend Development

· Backend Development

· Database Implementation

· Integrations

· Demonstration

For the current sprint, we are heavily focusing on development. In our previous phase, we completed a draft of the application’s site map. The initial site map of the system is show below:

Figure 3: Initial Sitemap

Based on the site map, we started the process of the design, and we were able to identify key features and components that the front end must contain to fulfil the application’s functionality. We started sketching the design on paper and later, each member of the team was in charge of digitalizing a part of the site. With the design in place, we have a blueprint that we are using to build the front-end user interface.

The GitHub repository has been created for the front end. This is a way to share the code so the whole team has access to the latest code and can contribute. The repository has two main branches called “main” and “development”. The main branch will remain outdated until the end of the development phase. The development branch represents the status of the project. To collaborate with the front-end repository, everyone will create a new branch from the “development” branch. This way each team member’s commits/changes in the code will be separated to prevent any bugs or failures in the common branch. New changes will be pushed to the “development” branch by opening a push request (PR). The PR must be reviewed for approval. Once changes are approved, the PR will be merged into the “development” branch.

The first step in development is building the UI. Currently, we are building all static pages of the site leveraging the React.js library. We are applying the use of JSX and Styled components. We think styled components are the best option to build the front end of the site because it allows us to reuse components with custom attributes. Later, once the entire application’s user interface is complete, we will add functionality to it. For this, we have decided to use JavaScript as our main front-end programming language, and we will discuss more functionality in the upcoming milestones. Below are the three completed frontend designs and implementations:

1. Login Page:

Figure 3: Login Page

The above figure is the frontend implementation of the Login page. For now, we have kept “Park-a-lot” as the system name, but we may change it in the future depending on our client’s preference. The user will be allowed to sign in by putting their credentials, username, and password, which they used while creating their account. Once they put the credentials and hit the “Log In” button, they will be prompted to the homepage. Failure to provide correct credentials will block them from logging into their account. In case, a user forgets their password, they will also have an option to change it on this page. They can simply click on “Forgot Password?” and it will take the user to another page where they can reset their password. For the first time users, we also provide them an opportunity to “Sign up” at the bottom of the login page.

2. Sign-up page:

Figure 4: Signup Page

The above figure is the frontend implementation of the Sign Up page of our web application. Users will be asked to provide their email, name, phone number, address, license plate number, username, and password to create an account. Failure to provide any of the information will restrict them from creating the account. Once they fill out their information, they can click on “Sign up” to register their account. By signing up, users also agree to our Terms and Privacy Policy which can be viewed by clicking on the respective links. The username and password users choose while creating their account can be used to login to our web application whenever they want.

3. Forgot Password Page:

Figure 5: Forgot Password Page

The above figure is the frontend implementation of the Forgot Password page. It allows users to reset their password if they forget it. They will have to provide their email address, and once they click on “Send Password Reset Link”, an email will be sent to the provided address to reset their password. Users will also have an option to create a new account they like or simply return to the login page.

On the backend we have set up a member service which lets the backend find a member, create a member, and delete a member. This service connects to our member endpoints, allowing us to call the service functionality through http requests.

We are also in the process of setting up an authentication service. This will allow us to authenticate someone accessing our site via a bearer token. This token will be translated into a member object on the backend and will allow us to perform some tasks on behalf of the member when they call our endpoints. This will be used going forward to create a reservation for the member, editing a reservation, cancelling a reservation, etc. Essentially anything the member can do that they need either permission to or to have access to, the bearer token will let us know if they have access, permission, and give us their information on the database, so we can perform the action they requested.

We have also created the setup work for multiple future features including Parking History, Parking Reservations, Logging in, and Dynamic Parking Layouts. These will be presented in future iterations of the project.

Our backend is set up in such a way which is fast and easy to create multiple endpoints that connect to our domain. We are currently testing with a localhost, to avoid any extra cost to both the development team and the client. We currently have a few endpoints primarily for testing, which include get requests such as /members, which gets all members in a list, /members/id, which gets a member by their membered, and /members/plate, which gets a member by their license plate number.

We also have a post request endpoint which creates a member, /members/create. This endpoint takes in the basic customer information needed to create a new member, and then sends this information to the database for storage.

To start the backend and connect to the front end, we have two different servers both running on localhost. The website is running on port 3000, and the backend service is running on port 3001. We will change the actual endpoint calls from localhost to our domain name when our service goes live. To run the code, we use “npm start” for the front end, and “npm run dev” for the backend. These serve similar purposes, for frontend, it starts the client. However, for backend it will check for changes to any file within the backend code and will automatically restart the backend service once a change is detected. This allows us to build and test our backend services and endpoints more quickly.

In addition to this, for our backend, we use an extension called Swagger, which builds a small webpage and lets us test all our endpoints with dummy data. This will call the database if needed and perform all actions that would happen on the full server. This extension automatically gathers all our endpoints and sorts them alphabetically, allowing us to organize these without having to manually add them to a testing page. Here is a sample Swagger page with the endpoints we created for backend.

Figure 6: Swagger Page

We are using MySQL as our database software to store the data. The tables that we have created so far are listed below:

· Member

· Login

· Log

· ParkingLayout

· Reservation

· PaymentCards

· TransactionHistory

· EventHistory

· AccountUpdateHistory

Here is the sample list of members that are currently stored in our database:

Figure 7: Member’s Table

We also created an Entity-Relationship (ER) Diagram which is shown in the figure below:

Figure 8: ER Diagram

As we are moving to the second sprint, we are heavily focused in the development of the system. Below are the goals we have set for the second sprint:

· Make sure everybody has the development environment setup.

· Complete building static UI pages using React.js.

· Add login and signup functionality to the system.

· Create entities and endpoints for login and signup services.

· Create authentication token service that takes the credentials of a user and converts it to a unique token identifies for login-authentication.

· Successfully connect to the database.

· Implement Backend and integrate it with Frontend.

· Create all the tables on the database.

· Create required modules on backend.

· Research potential solutions for the implementation of the access control section of the application and create Proof of Concepts.

If the time allows, we will also try to accomplish the following things, which are currently out of the scope of this project:

The entire process of building the system will be documented in detail which will serve as overview of our design process and implementation of the system to the readers. Our Park-a-lot project, from its backend to its frontend, is already well underway, and we are documenting every step of its development. At the end of the project, we will publish this report. It will help readers understand many important aspects like system development life cycle and methodologies we used to develop the system. Moreover, it will help future developers to configure and maintain the system.

We will create a handbook for users that will cover all the processes that are required for a customer to effectively utilize the Park-a-lot website to reserve a parking place, beginning with signing up for an account and ending with making a payment. There will be well-labeled diagrams, screenshots, and possibly some videos to help users easily navigate our system. This manual will be available on our website.

In addition to this, we will provide a detailed guide for administrators on how to use the Park-a-lot website, which will include guidance on how to solve issues if they occur. We will provide a step-by-step approach that will cover all the relevant solutions for admin and will assist admin in using the administrative side of our website, Park-a-lot.

This report serves as an update to the client and the team members about the progress we have made so far. It presents the initial design and implementation of the system. It describes how the development team are working on frontend, backend, and database to build the system. Moreover, it clearly shows the goals we have set for the next milestone.

1