Building access control system development

Solution

The initial goal of the project was to replace the legacy C# client with a responsive frontend solution that can facilitate existing web services communication and be seamlessly integrated with hardware APIs.

The Itransition team analyzed the customer requirements and delivered a proof of concept. Upon the customer’s approval, we delivered responsive GUI designs in line with corporate style guides using HTML5. Additionally, the Itransition team also performed the integration with API that the in-house team provided and carried out API testing and documentation.

The system was supposed to handle millions of database records and service thousands of users. Considering the user base size, we needed to minimize the number of server requests, the largest of which was for localization files and images, and reduce the load to improve platform performance. To make the platform not only faster but also more mobile-friendly, we decided to transform the frontend part of the solution into a single-page application with Angular. This way, users would get a native app-like experience while the solution would send only one request to a server and then store all the data it receives, thus minimizing the server load.

As a result, we developed a single-page application for creating and configuring building access systems. The application automates the following processes:

• Generation and management of profiles for access devices
• Access status report management
• Video reports on user actions and movement within the controlled area
• Controlled area display by uploading site plans and devices marked on them
• Adding users or groups of users and assigning user permissions according to the set schedules and geography of access elements
• Building entry devices management
• App integration with the access system hardware
• Remote and mobile access to the system

There are the following user roles:

• Global administrators with access to all functional modules
• Administrators with rights limited to certain functional modules
• Users with individually set permissions

By default, this group includes System Engineers, Supervisors, and Read-Only users. However, there is an option of setting up individual rights for a certain user. For instance, a user can have full access to the People module and read-only access to the Reports module.

• End users represented by individuals or legal entities. They can manage and configure building access rules

Fictional modules

The solution consists of several modules that enable different functionality.

Home

The Home module provides an overview of key figures, such as the number of people who entered the building, the number of alarms, and the condition of devices in the system, such as cameras, lights, etc.

Each user can set up quick access to the modules they frequently use by creating opening forms for all system modules: dashboards, users, reports, etc.

Event reports

This module allows users to monitor events in real-time and create custom event reports according to set parameters, for example, with events sorted by people, time, etc.

Video reports

The Video reports module enables users to view live and archived videos and has various playback features, such as speed play, fast forward and backward, zoom, video downloads, snapshots, and more. The recorded videos are stored in the system according to the settings defined by users.

Videos can be filtered by people, cameras, locations, event types, etc. For instance, there can be  a person registered in the system that has a proxy card linked to their profile. Each time the person uses the card to enter or leave the building, the system creates a record and saves a video of them. Later, all records on a certain person can be viewed in the Reports module.

What is more, many modern buildings have an option of using proxy cards and key fobs to manage lights, elevators, ventilation, conditioners, etc. Such events are registered in the system and video snippets of them are saved. This way, filtering by a person and playing video results, one can view how someone enters a building, calls an elevator, walks down a corridor on their floor, enters a room, turns on the lights, etc.

Site plans

The module enables uploading building and room plans to the system, labeling the devices, and monitoring their status. The site plans can be displayed in 2D and 3D formats and can be rotated.

People

This module facilitates adding and grouping system users and setting user permissions. In addition to that, using this module, the system administrator sets user access permissions to buildings for certain periods.

Rules

The Rules module allows for creating and setting up work schedules for access devices, building access rules for system users, configuring the access system and system administrators’ rights. Admins can also automate certain operations by setting up relevant triggers.

Devices

This module enables finding and adding devices used in the access system, adding their app analogs and connecting apps to the devices, and fine-tuning their operation.

Dashboards

The Dashboards module ensures grouping and visualizing the information from different modules to enable data comprehension. For instance, using this module, a receptionist can open doors or driveway access gates by clicking on a button on their dashboard. The widgets can be set up with drag-and-drop.

Process

We were the only team working on the frontend part of the customer’s application. Our team provided the design, frontend development, integration and testing services, while the customer’s specialists were responsible for requirements elaboration, backend development, and quality assurance.

At the beginning of the project, the customer’s IT team used the Waterfall model. Our team, however, chose Scrum as a more suitable framework for the project. We worked in two-week sprints and delivered product increments as per the backlog provided by the customer’s product manager.

To provide the customer with a full picture of the development process and teamwork, we included such parameters to our sprint reports as team performance, monthly budget, burndown charts, and phase timelines with the breakdown into user stories

When developing the frontend and API for CCTV cameras, we worked together with the customer’s team and the third-party vendor responsible for the development of software for the CCTV cameras.

When necessary, our specialists would travel to the customer’s location. At some point, we suggested appointing a delivery manager to the project who would work at the customer’s site. They were responsible for resolving high-level project issues and conveying customer requirements to the development team.

As a result, the addition of a delivery manager to the team allowed the project manager to focus more on the project’s technical aspects while always keeping in touch with the customer.