Automating the Car parking at Victoria University

2019, Aug 12    

Intro

Currently the administration team at Victoria University have to manually enter in data to issue parking permits for the staff. There are over 600 parking permits that are printed each year which the staff have to ensure is on the car when parking in the University. The permits are plastic cards, similar to a driver’s licence. The data for these permits is entered into a Microsoft Excel 2003 spreadsheet which can be read by the Zebra printing system, which takes up a considerable amount of time. Our client approached us with the idea of making the issuing of permits automated and removing the need for a physical card.

• This project was part of a larger project to automating all of the Victoria University parking services, possibly integrating with an existing commercial parking solution.
• There are multiple places around all the Victoria University campus’ that staff can use for parking. The main one is in Kelburn which was the only focus of this stage of the project.

This project was conducted for the ENGR301/ENGR302 Project Management course in 2019. It was a group project, and our final team consisted of 5 team-members. I took the lead role in the team which was a valuable experience for learning project management techniques and soft skills.

Requirements Gathering and Dealing with Stakeholders

The initial scope of the project was huge, involving license plate recognition cameras, signs for displaying amount of available car-parks, and a whole lot more:

Obviously, we had to massively cut down on scope due to the limited time frame. Moreover, we had a team reshuffle halfway through the year which drastically changed our ability to develop the product. The final “scope” of the project focused solely on the construction of the administration side of (what was intended to be) a software-as-a-service product, focussing on ways to improve the current excel-spreadsheet workflow that the administrators relied on.

A major consideration (and, as we found out, a huge pain in the arse) was the amount of stakeholders that each wanted a say in the design and features we worked on. We had to wrangle manage:

• ITS (VUW IT services) for deployment and maintenance
• Vic Info for visitor booking
• Disability services
• SSC team for self-service
• parking enforcement services
• The administration team
• VUW Property services
• Our lecturer

ITS (now called Digital Solutions or something equally daft) was the biggest blocker to the project. As said by one one my lecturers - “Victoria is one of the slowest moving, if not the slowest, organisation in Wellington”. This was very evident when ITS put roadblocks in front of every thing we wanted to accomplish. We weren’t allowed to deploy to their infrastructure, they wouldn’t set up a staging or test environment for us, they wouldn’t let us integrate with their SSO platform, were unresponsive to emails, and generally tried their best to ensure we couldn’t progress.

This drastically changed our deployment strategy, causing us to have to hastily learn all about docker (not a bad thing!), and deploy the SaaS-intended software onto the client’s machines (Discussed in deployment).

Our final scope removed the visitor booking subsystem, all authentication mechanisms (as it was going to run directly on the user’s workstation), anything user-facing (staff), and everything to do with hardware. Our focus instead was on delivering the most business value for the client, which was around automating as much as we could.

Halfway through the project, our progress caught the attention of some suit-wearing “Service Designer” with ITS. They took a bunch of non-technical people (like, 25!) on a two-week “design sprint” for fixing the car-parking system without really involving us, and as far as I could tell discovered the same requirements that we spent the first half of the project figuring out, sans any consideration to technical feasibility. I don’t know what really came out of that aside from a big document which I can only assume got lost somewhere in Vic’s progress-crippling bureaucracy.

Final Product

Workflow

Caryn, one of the admins, interacts with the web application to view, modify and delete user permits (see administration interface). The software is able to diff between reports received from HR about inconsistencies found with payments, removing the need for the client to have to cross-check the reports against the database. The software also automatically sends an email to HR if it finds inconsistencies, making this process totally automated.

The other main part of this software is that it enforces correct permit statuses using a finite-state-machine, shown in the following photo.

This adds structure and control to the system, reducing unexpected behaviour. At each state change, appropriate emails can be sent to users explaining the change.

The benefits of this is that the administrators make less mistakes as the app enforces validation on some of the state changes. This fixes the problems with the existing spreadsheet-based system, which is highly prone to human error.

Administration Interface

The main interface allows the user to search, sort, filter, export, and update the permit status of multiple entries at once.

If you click “details” on an entry, you can view and create changes to the permit. The invalid actions are greyed out.

This page also allows you to email users. We implemented a simple template system that can be used for sending mass-emails to a variety of users at once:

There’s a handy screen to create a new permit entry:

We also have a screen for managing the types of permits available in the system (ignore the mouse pointer lol):

Other features

• We can export every table in the software as a CSV table, for further analysis using spreadsheet software. This also gives the software integration with the current process, easing gradual adoption by the users.
• We can import a table from excel too, so users can be added from the existing system en-masse.
• Every change in the system is tracked and logged, and the user can view the logs through the web interface for auditing/assurance purposes.
• There’s a screen for managing parking zones, and some other pages which don’t do much

System Architecture

The system architecture was designed to be extensible, but ended up being overly-complex. If we were to redo this, we would either separate out each subsystem into a service-oriented arch and consolidate the tech stack a bit to reduce the amount of moving parts.

There are three major components in the system. These are the frontend, the backend and the database. The frontend is a web application that is built using JavaScript with React, Next.js and Express.js technologies. The backend is a Python application that uses Django to model and communicate with the database. The database software used with this system is MySQL.

Frontend Architecture

The frontend is the front facing application for the users, and so all pages that the user can see, and the tools on these pages such as the table are created and run from within the frontend. The three technologies used within the frontend are all used to achieve different functionality. React is the framework that the web application is built in, and so every page and custom component is written and structed using the React framework. React is essentially just the view for this application. Next.js is the technology that renders the React views, as it allows for them to be rendered dynamically. Next.js architecture also determines how files and directories are named and structured. Express.js is used as a server, and allows for communication functionality with the backend component, using HTTP GET,POST,PATCH and DELETE requests over a REST API.

The frontend combines the three technologies together by receiving/sending information using express, and then utilizing this information and presenting it to the user by using Next.js routing which renders the React components, which are physical representations that the user can see.

Backend Architecture

The backend is a Django server, which has the following responsibilities:

• Modelling the data within the database
• Functionality for updating the database
• External Interface communication
• Exposing REST API endpoints for data access

The Django framework is used as it provides the functionality to fulfil the points mentioned above. The backend uses Django models, views, and serializers to allow data access and manipulation within the database. The external interfaces the backend communicates with are email (SMTP servers) and Human Resources (HR). Both external interfaces and the frontend use Django which allows functionality to REST APIs which allow for HTTP requests for communication.

Database

The database used is MySQL, and it stores the following information as schemas:

• Users
• Zones (incomplete)
• License Types
• Parked (incomplete)

Integrating them together

When the system is in use, the frontend would display the pages the user would interact with. The user uses the tools available to them through the frontend to view and manipulate data which is accessed through HTTP requests from the backend. The backend accesses the MySQL database and uses its models to either update or return requested information from the frontend.

Deployment

We actually deployed to AWS elastic beanstalk (as a SaaS) until halfway through the project, where the university decided they wouldn’t let us use their IAM platform for single sign-on. This was one of the main reasons why we had to hurriedly switch to a docker-based deployment model.

We deploy a “master” server to one of the admin’s PCs, and then the other admin PCs connect to the master PC using the same database.

We use Docker to package the application and store them in the Gitlab container registry as images. For deployment, docker-compose scripts are provided to automatically orchestrate downloading the images, provisioning the database on the local machine, and installing the frontend and backend components.

We use Gitlab CI to automate testing and deployment of the software to the University’s docker container registry.

For the backend side, the pipeline runs through the following process:

1. BEFORE_SCRIPT: Create a virtual environment and install required packages for linting, testing and building the software. The pip packages are cached between builds.
2. LINT: Using flake8, apply linting on all the code files. Configuration is provided in the flake8.ini file in the root directory.
3. TEST/COVERAGE: Run coverage on the code using the django python manage.py test command. Calculate coverage using a regex.
4. DEPLOY TO DOCKER: build the docker container and publish it to the container registry. This step is locked to the master branch.

The frontend pipeline runs through the following processes:

1. Cache the node_modules folder between stages
2. LINT: install eslint package and run linter across frontend codebase.
3. TESTING: run coverage and test scripts using the jest package.
4. DEPLOY TO DOCKER: log in to the container registry, build the image and push to the container registry. This step is locked to the master branch.

Evaluation & Lessons learned

The results of the project can guarantee that:

• Our client will no longer have to manually send out emails to her staff when their permit states change
• She will have more consistent and less error-prone information of her staff than what she currently has on her excel spreadsheet
• She can access information faster through our easy to use UI components
• She no longer has to cross check her HR reports with her excel spreadsheet for correctness
• She will be able to deal with a bulk of data in just a few clicks

I learnt a lot doing this project. Looking back on it, I was incredibly impressed by the work put in by the team to produce a highly-usable piece of software. Now that I know a bit more about web development, I would change the underlying tech stack to reduce the need for two backend systems. I would probably use next.js for both the ORM and serving up the webpages, maybe splitting out the different functionalities of the app into a service-oriented architecture.

Project-management wise, I learnt a fuck ton, and wrote en entire report about it here.