Optimization of Emergency Notification Processes in University Campuses Through Multiplatform Mobile Applications: A Case Study

Abstract

Universities face continuous challenges in ensuring rapid and efficient communication during emergencies due to outdated, fragmented, and manual notification systems. This research presents the design, development, and implementation of a multiplatform mobile application to optimize emergency notifications at the Escuela Superior Politécnica de Chimborazo (ESPOCH). The application, developed using the Flutter framework, offers real-time alert dispatch, geolocation services, and seamless integration with ESPOCH’s Security Unit through Application Programming Interfaces (APIs). A descriptive and applied research methodology was adopted, analyzing existing notification workflows and evaluating agile development methodologies. MOBILE-D was selected for its rapid iteration capabilities and alignment with small development teams. The application’s architecture incorporates a Node.js backend, Firebase Realtime Database, Google Maps API, and the ESPOCH Digital ID API for robust and scalable performance. Efficiency metrics were evaluated using ISO/IEC 25010 standards, focusing on temporal behavior. The results demonstrated a 53.92% reduction in response times compared to traditional notification processes, enhancing operational readiness and safety across the campus. This study underscores the importance of leveraging mobile technologies to streamline emergency communication and provides a scalable model for educational institutions seeking to modernize their security protocols.

1. Introduction

Ensuring the safety and well-being of university communities in dynamic and high-mobility environments has become a critical challenge for higher education institutions. Incidents such as theft, assault, harassment, and natural disasters pose significant risks, demanding rapid and coordinated responses [1]. Nevertheless, traditional emergency notification systems at universities like the Escuela Superior Politécnica de Chimborazo (ESPOCH) often rely on manual communication methods, which are prone to delays, miscommunication, and operational inefficiencies. These limitations underscore the urgent need for technological interventions that enable real-time, reliable, and accessible communication across campus stakeholders [2].

In the context of pervasive smartphone adoption, mobile devices are utilized for a wide array of functions, including gaming, GPS navigation, email, instant messaging, and multimedia capture [3]. Such widespread availability of mobile technology highlights the critical importance of developing applications tailored to institutional needs, especially for emergency management scenarios. Given that the vast majority of the population owns a smartphone, mobile applications emerge as the most effective medium for delivering real-time services and facilitating immediate interaction between users and service providers. Technological advancements in mobile application development present a transformative opportunity to address these challenges. Mobile platforms, particularly cross-platform frameworks like Flutter, provide an efficient and scalable means to deploy robust applications that ensure compatibility across Android, iOS and web ecosystems [4]. Previous initiatives, such as the work of Guerrero Jaramillo, Yumiseba Chasi, and Narváez López on the Mobile Incident Alert Application for Citizen Safety [5], together with Ecuador’s ESPOL Alert [6], have demonstrated the tangible benefits of integrating mobile solutions into institutional safety protocols. These projects achieved significant improvements in response times, incident tracking, and overall security awareness, underscoring the potential of mobile applications to revolutionize emergency management processes in educational environments.

Building on these precedents, this study focuses on developing a multiplatform mobile application tailored to ESPOCH’s operational context. The proposed solution leverages Flutter for cross-platform compatibility, ensuring uniform access across devices, and incorporates critical functionalities such as real-time alert dispatch, geolocation-based incident reporting, integration with institutional APIs, and efficiency evaluations based on ISO/IEC 25010 standards [7]. The development process follows a structured methodology, combining descriptive research to analyze existing workflows and applied research to implement and assess the technological solution. Agile development principles [8], particularly the MOBILE-D, were adopted to facilitate iterative development cycles and continuous feedback integration from ESPOCH’s security personnel and end-users. This approach aims to ensure that the application aligns with the institution’s operational requirements while maintaining high standards of software quality and performance.

This work seeks to contribute to the expanding body of research focused on leveraging mobile technologies to enhance institutional security. By presenting a detailed case study at ESPOCH, it offers a replicable methodology for universities facing similar challenges in emergency management. Furthermore, the insights gained from this project are expected to foster further research and development initiatives aimed at enhancing safety protocols within educational environments.

2. Materials and Methods

This study was conducted with the objective of designing and developing a multiplatform mobile application to optimize the emergency notification processes within the Escuela Superior Politécnica de Chimborazo (ESPOCH). The research adopts a descriptive and applied methodological approach, integrating both qualitative and quantitative techniques. The entire process was framed under the Mobile-D agile development methodology, which is characterized by its iterative cycles, rapid prototype deliveries, and adaptability to small development teams [9]. The project was executed through five sequential phases: exploration, initiation, product, stabilization, and testing [10]. Given the nature of the project, the study follows a non-experimental design, focusing on the development and functional evaluation of a technological solution within a controlled environment. All validation procedures were carried out through system-level testing and simulated scenarios, without the involvement of human participants or animal subjects. Consequently, the research process adhered to institutional guidelines and did not require ethical approval, as no interventions affecting human or animal welfare were conducted.

2.1. Exploration Phase

During the exploration phase, a comprehensive analysis of ESPOCH’s current emergency notification protocols was performed through observation techniques and document analysis [11]. Structured interviews were conducted with key stakeholders, specifically the Security Unit personnel, to gather insights into the inefficiencies of the existing manual reporting process. This qualitative data collection allowed for an in-depth understanding of the operational gaps, which informed the system requirements, as illustrated in Figure 1.

Figure 1 illustrates the operational workflow that begins with locating the security guard and extends through the assistance and coordination stages. The diagram includes a decision point to verify whether the alert has been resolved; if so, the system automatically sends a report via WhatsApp, which can be viewed by the administrator for proper supervision.

This description is essential within the context of the study, as the article focuses on the optimization of the emergency notification process, aiming to reduce response times and improve the traceability of the actions performed. It should be noted that the presented workflow constitutes the object of improvement in the case study, without delving into the specific actions taken by the security guard to resolve the alert.

Prior to the system’s development, a series of coordination meetings were held with Coordinator of the Security Unit at ESPOCH. These sessions were crucial to thoroughly identify, analyze, and define the functional requirements necessary for the mobile application [12]. Through collaborative discussions, the current shortcomings in emergency communication and response processes were assessed, and specific needs were outlined to ensure that the proposed technological solution would adequately address the institution’s operational demands. Based on these meetings, it was determined that the multiplatform solution would encompass three primary user roles: User, Security Guard, and Administrator. Each role encapsulates distinct responsibilities and system interactions, requiring dedicated functionalities tailored to its operational context.

• The User role represents students, faculty, and staff members who can initiate emergency alerts, provide location information, and receive system notifications.
• The Security Guard role is responsible for monitoring incoming alerts, responding to incidents, and updating the status of ongoing situations through the application’s administrative interface.
• The Administrator role oversees the overall management of the platform, including user role assignments, monitoring historical data, generating reports, and configuring system parameters.

To precisely define the specific functionalities associated with each role, detailed functional requirements were established, ensuring that every user interaction within the system aligns with the operational protocols of the Institutional Security Unit. These requirements were systematically organized by role, providing a comprehensive overview of the essential functionalities. This structured definition was fundamental in guiding the development process, ensuring that the application’s design was based on the real needs of its end users and, consequently, increased the system’s efficiency in emergency response scenarios.

The first set of requirements corresponds to the user role, which represents the institutional community (students, faculty, and administrative staff). These functionalities are designed to ensure that users can rapidly request assistance and remain informed throughout the response process. When a user triggers an alert, the system not only records the event but also allows the user to see, in real time, how the security guard is approaching their location, which reinforces confidence in the system. Furthermore, two types of alerts are supported: an emergency alert, similar to a panic button, intended for critical situations, and a descriptive alert, which enables users to report irregularities or suspicious activities within the campus. The functional requirements for this role are listed in

Table 1. Functional Requirements for the User Role.

No.	Requirement Name
FR-01	Log in through CAS
FR-02	Send an emergency alert
FR-03	Send a descriptive alert
FR-04	Display an interactive map of the ESPOCH main campus
FR-05	View profile information
FR-06	Show progress of the active alert
FR-07	Display real-time tracking of the security guard
FR-08	Cancel the alert
FR-09	View personal data of the security guard
FR-10	Submit feedback report regarding the incident
FR-11	Log out

.

The second set of requirements corresponds to the security guard role, whose responsibilities are focused on responding to alerts, coordinating assistance, and reporting outcomes. Unlike members of the institutional community, security guards belong to an external company and therefore do not have institutional email accounts. For this reason, a dedicated registration process was implemented for them, managed directly by the Institutional Security Unit. These functionalities allow guards to interact with user-submitted alerts, track locations in real time, and generate operational reports, thereby ensuring a rapid and efficient emergency response, as shown in

Table 2. Functional Requirements for the Security Guard Role.

No.	Requirement Name
FR-12	Register in the app with their credentials
FR-13	Log in with their credentials
FR-14	View emergency alerts
FR-15	View descriptive alerts
FR-16	Accept an alert assistance request
FR-17	Display an interactive map of the ESPOCH main campus
FR-18	View profile information
FR-19	Show progress of the alert assistance
FR-20	View the user’s current location in real-time
FR-21	Cancel assistance
FR-22	View personal data of the user
FR-23	Submit a report regarding the alert
FR-24	Log out

.

Only non-sensitive identification elements such as the name, surname, and photograph of the assigned guard are displayed. This supports recognition in the field and enables precise user feedback on the quality of the intervention, improving transparency and service traceability without exposing sensitive personal information.

Guards can update the alert status as part of the operational flow. When a guard accepts an alert, the status changes to “In Progress.” If the guard cancels it, the status reverts to “Requested.” After submitting the incident report and once the user feedback is recorded, the status transitions to “Completed.” State changes are synchronized in real time through the backend and database.

The Security Guard does not originate alerts within the system. Guards maintain direct radio communication (walkie-talkie) with the ESPOCH Security Unit, the administrative team that also monitors the institutional video surveillance system, ensuring continuous situational awareness. Consequently, alerts are raised by members of the university community (Users), while guards receive and respond to those alerts.

The visualization of alert progress was intentionally implemented because it is essential for the user to know whether the security guard is on the way. In critical emergency situations, users must receive immediate feedback on the status of their alerts. Without such feedback, users may experience uncertainty and delayed reactions. Although displaying progress might suggest that a specific guard is currently occupied, overall coverage remains unaffected because multiple guards are strategically distributed across campus zones, ensuring continuous response capacity. If a false alert causes a guard to move from a strategic location, administrators can reassign positions through radio communication to maintain optimal coverage and operational efficiency.

Finally, the third set of requirements corresponds to the administrator role, managed by the Institutional Security Unit through the web platform. These functionalities are designed to oversee, coordinate, and analyze the entire alert management process, including adding and managing personnel, monitoring alert statuses, and generating reports.

The institution employs several security guards, whose registration is managed by the administrator through the web system. Administrators can register guards individually by entering their national identification number or in bulk by uploading a CSV file. Once registered, guards can access their personal dashboard in the mobile application.

These requirements are essential to ensure traceability, operational transparency, and institutional accountability, as shown in

Table 3. Functional Requirements for the Administrator Role.

No.	Requirement Name
FR-25	Log in through CAS
FR-26	Display an interactive satellite map of ESPOCH
FR-27	Display the list of security guards
FR-28	Display the list of administrators
FR-29	Add security guards
FR-30	Add administrators
FR-31	Delete security guards
FR-32	Delete administrators
FR-33	Display the status of emergency alerts
FR-34	Display the status of descriptive alerts
FR-35	Generate reports based on filters
FR-36	Download reports in .xlsx format
FR-37	Log out

.

The definition of non-functional requirements (NFRs) was a key aspect in ensuring that the application met quality standards essential for its optimal operation. These requirements, summarized in

Table 4. Non-Functional Requirements Specification.

No.	Requirement	Description
NFR-01	Performance	The application must handle concurrent requests without significant performance degradation.
NFR-02	Scalability	The system must allow the addition of new roles and functionalities without affecting performance.
NFR-03	Compatibility	The application must be compatible with major mobile and desktop operating systems.
NFR-04	Availability	The system must remain operational at least 99.5% of the time, ensuring high availability during critical periods.
NFR-05	Security	Robust authentication and authorization mechanisms must be implemented through CAS, along with the protection of sensitive data.

, addressed critical aspects such as usability, performance, scalability, and security. Unlike functional requirements, which specify the application’s core features, NFRs ensure that these features are delivered reliably and efficiently across different usage scenarios.

By establishing clear non-functional criteria, the development process was guided toward building a robust and stable solution capable of sustaining high performance while maintaining a seamless user experience. These requirements were crucial in complementing the functional specifications, contributing to the system’s overall resilience and long-term maintainability. The product phase involved the incremental development of the application’s core functional modules:

• Authentication Module: Implementing integration with ESPOCH’s Central Authentication Service (CAS) for regular users and a custom login interface for security personnel.
• Emergency Report Module: Enabling users to submit emergency alerts with geolocation data.
• Role-Based Dashboards: Providing customized interfaces for users, security guards, and administrators.
• Administrator Web Panel: Allowing security personnel to manage incident reports, track alert statuses, and visualize reported incidents on a real-time map.

2.2. Initiation Phase

The initiation phase focused on configuring the technological infrastructure. The Flutter framework was selected for cross-platform development, enabling a unified codebase deployment across Android, iOS, and Web platforms. Backend services were implemented using Node.js with Express.js, adopting a RESTful API architecture to ensure scalable and modular communication between frontend and backend components [13]. The Firebase Realtime Database was chosen for its real-time data synchronization capabilities, facilitating immediate alert transmission and system updates. Development tasks were managed using Visual Studio Code version 1.100 as the Integrated Development Environment (IDE) [14], leveraging Dart as the primary programming language. The interaction between these components is depicted in Figure 2.

The project utilized Firebase Realtime Database, a cloud-based NoSQL database that stores information in JSON format and organizes data through a node-based structure [15]. This architecture was particularly suited for the application’s needs, enabling real-time data exchange and dynamic queries essential for emergency alert systems. Additionally, Firebase Storage was implemented to manage image files associated with emergency alerts and user profile pictures, providing scalable and secure media storage capabilities [16]. Unlike relational databases, Firebase does not use table-based schemas; instead, its structure was documented through a detailed data dictionary, defining the organization and hierarchy of nodes. The complete data dictionary can be found in Appendix A (

Table A1. Node Table: AlertasDescripcion.

Node Name: AlertasDescripcion Description: Stores Detailed Information About Alerts, Including Additional Descriptions and Associated Images.
Field Name	Description	Data Type	NULL	Allowed Values
ID	Unique identifier of the alert	String	No	Text (Unique ID)
id_usuario	ID of the user who generated the alert	String	No	Text
nombre	Name of the user who generated the alert	String	No	Text
latitud	Latitude of the alert location	Float	No	Decimal number
longitud	Longitude of the alert location	Float	No	Decimal number
timestamp	Timestamp of the alert	Long	No	Long integer
estado	Status of the alert	Integer	No	0, 1, 2
descripcion	Detailed description of the alert	String	Yes	Text
imagenes	URLs of associated images	Array	Yes	List of URLs
GuardiaId	ID of the associated guard	String	Yes	Text
fotoGuardia	URL of the guard’s photo	String	Yes	Valid URL
Guardia	Name of the associated guard	String	Yes	Text

,

Table A2. Node Table: ReporteAlertasDescripcion.

Node Name: ReporteAlertas Description: Stores Detailed Information About Alert Reports, Including Descriptions and Images.
Field Name	Description	Data Type	NULL	Allowed Values
ID	Unique identifier of the alert	String	No	Text (Unique ID)
id_usuario	ID of the user who generated the alert	String	No	Text
nombre	Name of the user who generated the alert	String	No	Text
latitud	Latitude of the alert location	Float	No	Decimal number
longitud	Longitude of the alert location	Float	No	Decimal number
timestamp	Timestamp of the alert	Long	No	Long integer
estado	Status of the alert	Integer	No	0, 1, 2
descripcion	Detailed description of the alert	String	Yes	Text
imagenes	URLs of associated images	Array	Yes	List of URLs
GuardiaId	ID of the associated guard	String	No	Text
fotoGuardia	URL of the guard’s photo	String	No	Valid URL
Guardia	Name of the associated guard	String	No	Text
categoriaAlerta	Category of the alert	String	No	Text
DescripcionUsuario	User’s description upon completion	String	Yes	Text
DescripcionGuardia	Guard’s description upon completion	String	Yes	Text
timestampFinal	Completion timestamp	Long	No	Long integer

,

Table A3. Node Table: CategoriaAlertas.

Node Name: CategoriaAlertas Description: Stores the Available Alert Categories in the System.
Field Name	Description	Data Type	NULL	Allowed Values
ID	Unique category identifier	String	No	Text (Unique ID)
Categoria	Description of the category	String	No	Text

,

Table A4. Node Table: Estados.

Node Name: Estados Description: Stores the Possible Alert Statuses.
Field Name	Description	Data Type	NULL	Allowed Values
ID	Unique status identifier	String	No	Text (Unique ID)
Estado	Description of the status	String	No	Text

,

Table A5. Node Table: Geovallas.

Node Name: Geovallas Description: Stores the Coordinates that Define Geofences (Areas of Interest).
Field Name	Description	Data Type	NULL	Allowed Values
ID	Unique geofence identifier	String	No	Text (Unique ID)
Coordenadas	List of polygon coordinates	Array	No	List of coordinates

,

Table A6. Node Table: GuardiaAdmin.

Node Name: GuardiaAdmin Description: Stores Information About Guard Administrators, Including Their Role and Contact Details.
Field Name	Description	Data Type	NULL	Allowed Values
ID	Unique Admin identifier	String	No	Text (Unique ID)
correo	Administrator’s institutional email	String	No	Valid Email
fotoUrl	URL of the administrator’s photo	String	No	Valid URL
nombre	Administrator’s name	String	No	Text
rol	Administrator’s role	String	No	DA, SDA

,

Table A7. Node Table: ListaAdmin.

Node Name: ListaAdmin Description: Stores the List of System Administrators.
Field Name	Description	Data Type	NULL	Allowed Values
ID	Unique alert identifier	String	No	Text (Unique ID)
correo	Guard’s institutional email	String	No	Valid Email
rol	Administrator’s role	String	No	DA, SDA

,

Table A8. Node Table: GuardiaInicio.

Node Name: GuardiaInicio Description: Stores Information About Guards, Including Their Credentials and Contact Details.
Field Name	Description	Data Type	NULL	Allowed Values
ID	Unique guard identifier	String	No	Text (Unique ID)
correo	Guard’s institutional email	String	No	Valid Email
fcmToken	Firebase Cloud Messaging token	String	No	Text
fotoUrl	URL of the guard’s photo	String	No	Valid URL
nombre	Guard’s name	String	No	Text
pass	Guard’s password	String	No	Text

,

Table A9. Node Table: Guardias.

Node Name: Guardias Description: Stores Information About Guards’ Location and Status.
Field Name	Description	Data Type	NULL	Allowed Values
ID	Unique guard identifier	String	No	Text (Unique ID)
EnArea	Indicates if the guard is in the area	Boolean	No	true, false
latitud	Latitude of the guard’s location	Float	Yes	Decimal number
longitud	Longitude of the guard’s location	Float	Yes	Decimal number

,

Table A10. Node Table: ListaGuardias.

Node Name: ListaGuardias Description: Stores the List of Guards’ Email Addresses.
Field Name	Description	Data Type	NULL	Allowed Values
ID	Unique guard identifier	String	No	Text (Unique ID)
correo	Guard’s email address	String	No	Valid Email

,

Table A11. Node Table: LugaresImportantes.

Node Name: LugaresImportantes Description: Stores Information About Important Places, Including Location and Name.
Field Name	Description	Data Type	NULL	Allowed Values
ID	Unique place identifier	String	No	Text (Unique ID)
Clave	Unique place key	String	No	Text
Coordenadas	Coordinates of the place	Array	No	Latitude—Longitude
Nombre	Name of the place	String	No	Text

,

Table A12. Node Table: Roles.

Node Name: Roles Description: Stores the Available Roles in the System.
Field Name	Description	Data Type	NULL	Allowed Values
ID	Unique role identifier	String	No	Text (Unique ID)
Rol	Role description	String	No	Text

and

Table A13. Node Table: Usuarios.

Node Name: Usuarios Description: Stores Information About System Users, Including Their Role and Contact Details.
Field Name	Description	Data Type	NULL	Allowed Values
ID	Unique user identifier	String	No	Text (Unique ID)
fcmToken	Firebase Cloud Messaging token	String	No	Text
fotoUrl	URL of the user’s photo	String	No	Valid URL
nombre	User’s name	String	No	Text
rol	User’s role	String	No	ES, AD

) of this paper, where the structure of each node and its corresponding attributes are described in detail. To ensure data integrity and consistency, normalization processes were applied up to the Third Normal Form (3NF), effectively eliminating data redundancy and ensuring efficient data retrieval across different modules. The main database nodes included Users, Guards, Administrators, Reports, and Alerts, each designed to store diverse data types such as lists, objects, and text strings. This flexible data model allowed seamless integration with the application’s core functionalities while maintaining high availability and scalability for real-time operations.

The automated emergency notification process designed within the application involves the active participation of the three primary user roles: User, Security Guard, and Administrator. Each role plays a critical part in ensuring the effective management and resolution of emergency situations reported through the system. The following sequence outlines the step-by-step activities that occur during an emergency notification workflow:

• The User submits an emergency alert via the mobile app.
• The Administrator and Security Guard receive the notification in real time.
• The Security Guard accepts and acknowledges the alert.
• The Administrator coordinates the response with the Guard.
• The Administrator monitors the alert’s progress.
• The Guard proceeds to the incident location using geolocation guidance.
• After resolving the issue, the Guard submits an incident report.
• The User provides feedback on the emergency response.
• The Administrator reviews the report and feedback via the web dashboard.

This automated workflow, illustrated in Figure 3, describes the complete lifecycle of an emergency notification within the proposed system. The process begins when the institutional community, composed of students, faculty, and administrative staff, submits an alert through the mobile application, capturing essential information such as geolocation, timestamp, and a brief description of the incident. Community members authenticate through the institutional Central Authentication Service (CAS), which ensures secure access for all users with institutional credentials. The notification is immediately transmitted via cloud services to both the security guards and the Institutional Security Unit, which is the department responsible for monitoring and coordinating all aspects of safety within the institution. Since security guards belong to an external company and do not have institutional email accounts, they access the system through a dedicated registration process managed by the Institutional Security Unit. Once the nearest guard accepts the assistance request, the Institutional Security Unit coordinates the response and continuously monitors the progress of the intervention through its web-based platform. The guard then proceeds to the reported location, provides the necessary support, and completes a detailed incident report, which may include descriptive notes and supporting evidence. In parallel, the community member who initiated the alert may provide feedback on the service received, contributing to the evaluation of quality. Finally, the Institutional Security Unit reviews and validates the completed report, archiving it in the database to ensure traceability, operational clarity, and accountability. It is worth noting that this multiplatform ecosystem was developed using the Flutter framework, which enabled the deployment of native mobile applications for both the community and the guards, along with a web version for the Institutional Security Unit. By integrating these technologies into a unified process, the system significantly enhances communication, reduces response times, and establishes a structured framework for institutional safety management.

Multiple guards are managed through the web module by the Security Unit, either individually using their national ID or through bulk import from Excel files. When an alert is issued, notifications are sent to all registered guards, and the first one to accept it is automatically assigned to the incident. This prevents duplicate assignments and minimizes response time.

2.3. Product Phase

During the Product Phase, the iterative development of the application’s core modules was executed following the principles of Test-Driven Development (TDD) [17]. Each functional component was developed as an independent module and subjected to rigorous unit testing to validate its correct operation and ensure compliance with both technical specifications and user requirements defined in earlier phases. This modular and test-oriented approach was essential in ensuring that every component met established quality standards and operated autonomously before being integrated into the overall system, thereby minimizing the risk of critical failures in subsequent development stages.

2.3.1. Authentication Module

The Authentication Module was designed to integrate ESPOCH’s Central Authentication Service (CAS) using a WebView-based interface. As depicted in Figure 4, this module handled the user login process, providing visual feedback through a loading spinner and implementing error-handling mechanisms to ensure a smooth authentication experience. Upon loading the institutional login page, the module detected the authentication ticket embedded in the URL and performed an HTTP request to validate the ticket against the CAS server [18]. The XML response from the authentication service was parsed to extract sensitive user information, which was subsequently stored both locally (via Shared Preferences) and remotely in Firebase, ensuring consistency between local and cloud-based data. The validation of this module involved specific tests aimed at verifying:

• Correct extraction of the authentication ticket from the URL.
• Accurate parsing of XML-formatted authentication responses.
• Reliable local storage of user data using Shared Preferences.

2.3.2. Main Interface Module for Users and Guards

The main interface module was designed to dynamically adapt based on the authenticated user’s role (User or Security Guard). The application retrieved the user’s role from local storage and constructed a customized navigation structure accordingly. For Security Guards, the interface initiated background services and displayed dedicated screens for managing received alerts, monitoring alert progress, and accessing user profiles and interactive maps. Conversely, Users were provided with an interface focused on the emergency alert button, real-time alert progress tracking, and the campus map with highlighted geofenced areas [19]. The bottom navigation bar incorporated reactive badges to indicate active alerts, and the application’s navigation logic was managed through the Provider dependency, which facilitated dynamic state management and ensured seamless transitions between screens.

2.3.3. Incident Reporting Module

The Incident Reporting Module facilitated the submission of detailed reports during emergencies, with functionalities tailored to each user role. Security Guards were provided with a category selector and a description field, complemented by a speech-to-text transcription feature for efficient input during high-stress situations. Regular Users had access to a simplified feedback input field to provide additional incident details. Upon completing the relevant fields, the data was sent to the backend API, which processed and recorded the report in the system’s historical alert database.

2.3.4. Web-Based Administrative Module

The Web-based Administrative Module, developed using Flutter Web [20], provided a responsive interface for managing alerts, user accounts, and reports. This module utilized Media Query to adapt its layout across different devices, displaying a sidebar navigation on larger screens and a hamburger menu on mobile devices. This design ensured optimal usability and accessibility, enabling administrators to efficiently manage security operations regardless of their device type.

2.3.5. HTTP Request Handling and API Integration

To facilitate seamless communication between the mobile application and cloud services, a series of HTTP requests was developed using Node.js with Express.js, as demonstrated in Figure 5 [21]. The API routes were structured to handle essential operations such as:

• GET requests for retrieving campus coordinates and points of interest.
• POST requests for submitting emergency alerts (with or without descriptions) and uploading bulk data files (e.g., “.xlsx” files) for Security Guard and Administrator accounts.
• DELETE requests for canceling active alerts and rescue operations.

Each request was meticulously designed to interact with Firebase services. Textual data was managed through Firebase Realtime Database, image files were stored in Firebase Storage, and Firebase Cloud Messaging (FCM) was employed to dispatch real-time notifications to security personnel. This robust integration strategy ensured data consistency, high availability, and real-time synchronization across all application components, thereby enhancing the reliability and responsiveness of the emergency notification system.

2.4. Stabilization Phase

The Stabilization Phase focused on the comprehensive integration of all independently developed modules into a unified, cohesive system. This stage was crucial to ensure seamless interoperability and overall system stability. Key optimization tasks were carried out to enhance application performance, including reducing load times, managing intermittent connectivity issues, and refining the communication protocols with external services such as the ESPOCH Digital ID API and Firebase. Additionally, user interface enhancements were implemented to provide a highly intuitive and visually appealing user experience, ensuring smooth navigation across different functional screens.

2.4.1. Firebase Service Integration

To establish a secure and efficient connection with Firebase services, the project was meticulously registered across Android, iOS, and Web platforms using Firebase’s project console. This registration process ensured the proper allocation of permissions required for the correct operation of cloud-based services. Platform-specific settings were performed, which included setting up google-services.json for Android and GoogleService-Info.plist for iOS (Figure 6). These settings facilitated seamless integration of Firebase’s core functionalities, such as Realtime Database, Cloud Storage, and Cloud Messaging across all environments, guaranteeing data consistency and secure communication within the application ecosystem [22].

2.4.2. Integration with ESPOCH’s Digital ID API

A dedicated function was developed to interface with ESPOCH’s external Digital ID API. This module handled the retrieval of user images by processing parameters such as ID number (cedula) and perId, formatting them appropriately for API requests. Upon receiving the user image in base64 format, the data was decoded into a buffer, optimized for quality, and subsequently uploaded to Firebase Storage. This API connection not only ensured the accuracy and availability of user profile images across the application but also incorporated efficient resource management practices, contributing to the overall optimization and scalability of the system.

2.4.3. Google Maps API Integration

The integration of Google Maps services was achieved by embedding API keys into the settings files for Android and iOS, followed by the implementation of the google_maps_flutter dependency to enable interactive map visualization. This allowed dynamic rendering of the ESPOCH campus map, real-time user positioning, and access to geolocation features like geofencing and spatial overlays as shown in Figure 7 [23].

To delineate the ESPOCH campus boundaries, the development team combined official campus maps with Google Maps satellite imagery. Using Polygon and Polyline tools, the perimeter was manually traced by defining latitude and longitude coordinates, establishing the primary geofence for location-based alerts. Additionally, sub-geofences were created for key areas (academic blocks, parking lots) to refine alert accuracy [24].

Manual plotting and adjustments were performed in the Google Maps Developer Console and the application’s codebase to ensure visual alignment with campus structures, as illustrated in Figure 8. LatLngBounds restricted map navigation to the ESPOCH area, maintaining focus on relevant campus zones. To optimize performance, simplified geometric paths were used in less critical areas, while high-detail mapping was retained in zones prone to incidents [25]. Geospatial data was stored in JSON format and dynamically rendered through Flutter widgets. Real-time user positioning was continuously matched against these geofence polygons, enabling the system to trigger contextual alerts upon zone entry or exit. This precise geolocation strategy was essential for enhancing the efficiency and reliability of emergency notifications across the campus [26].

2.4.4. Frontend-to-Backend Communication

A crucial component of this phase involved establishing real-time communication between the frontend interface and the backend services [27]. This was accomplished by implementing RESTful API calls directly from the frontend, ensuring efficient data transmission for operations such as alert submissions, status updates, and data retrieval. As shown in Figure 9, these API calls were configured to handle asynchronous requests, facilitating seamless interaction between the mobile application and backend services, thereby maintaining system responsiveness and data integrity in real-time [28].

2.4.5. User Interface Optimization

The principal interfaces corresponding to each user role—Administrator, User, and Security Guard—were thoroughly refined to enhance usability and accessibility [29]. Figure 10 depicts the optimized main screens for each role, highlighting their distinct functionalities and workflows. The UI design employed responsive layouts and intuitive navigation structures, ensuring that the application’s visual hierarchy aligned with user expectations and operational requirements [30]. These enhancements were pivotal in delivering a user-centric experience that balanced functionality with ease of use.

2.4.6. Data Security and Privacy Strategies

Given that the system processes sensitive information such as authentication credentials, personal data, and geolocation, specific strategies were implemented to guarantee data protection and institutional compliance. A central component is the integration of the Central Authentication Service (CAS) [31], which centralizes user authentication and avoids the local storage of passwords, thereby significantly reducing the risk of unauthorized access. The use of institutional email accounts linked to CAS ensures that only verified members of the university community (students, faculty, and administrative staff) can access the platform. Security guards, as external personnel without institutional accounts, follow a dedicated registration process managed by the Institutional Security Unit, ensuring that their access is equally validated under institutional oversight. Moreover, CAS authentication is integrated with the Microsoft 365 infrastructure adopted by the institution. This means that the security policies applied to services such as institutional email, Teams, and OneDrive—including strong password requirements, session management, and multifactor authentication—are also extended to the emergency notification system. As a result, the system benefits from an additional protection layer already validated and certified under international standards such as ISO 27001 and GDPR-related frameworks [32]. Finally, this integration not only guarantees consistency in identity and access management but also strengthens compliance with the Ecuadorian Organic Law on Personal Data Protection (2021), guaranteeing that all data is managed transparently and securely, reinforcing institutional trust in information handling.

2.5. Testing Phase

In the final phase, targeted testing was performed to ensure the application operated correctly and met the defined functional requirements. Real-world usage scenarios were simulated, allowing the identification and resolution of issues during the review process. A notable problem was detected with background services, affecting geolocation tracking and notifications when the app was minimized. This was resolved by replacing the faulty dependency with a more stable alternative, improving the application’s stability and performance. The main objective was to verify that the system was error-free and fully aligned with the user requirements established in the exploration phase. Functional flows, including alert submission, location tracking, and notification delivery, were rigorously tested to ensure reliability. An illustrative example of the application’s core functionality is depicted in Figure 11, which showcases the complete workflow of an emergency alert being initiated by a user and successfully processed through the system until the acknowledgment by security personnel. This figure encapsulates the essential operational flow, emphasizing the seamless transition between user action and administrative response, thus demonstrating the application’s readiness for real-world deployment.

The materials generated and utilized in this study, including the source code, API documentation, and anonymized test datasets, are available upon reasonable request from the corresponding author. Due to institutional data governance policies, operational datasets related to ESPOCH’s internal security procedures are not publicly accessible. Nevertheless, the anonymized data used for system evaluation, as well as the architectural documentation, can be provided to researchers aiming to replicate or extend the study.

This research does not involve interventionary studies with human participants, biological samples, or animal testing. The developed application processes operational data (such as geolocation coordinates and incident types) that are not classified as sensitive personal information. No personal identifiers, health data, or confidential user information were collected or analyzed. Consequently, ethical approval from an institutional review board was not required. All testing procedures were conducted in controlled simulations, ensuring compliance with ESPOCH’s data privacy policies.

3. Results

This section presents the results obtained from the implementation and evaluation of the multiplatform mobile application for emergency notifications at the Escuela Superior Politécnica de Chimborazo (ESPOCH). The analysis focuses on key performance metrics, particularly the system’s efficiency in reducing emergency response times. The evaluation was conducted through controlled simulations, applying quantitative methods, and following the ISO/IEC 25010 [33] standard for software quality assessment, with emphasis on the Efficiency characteristic and its Temporal Behavior sub-characteristic [34].

The results are structured to compare the system’s performance before and after the deployment of the mobile application, highlighting improvements in response times. Additionally, statistical tests were performed to validate the significance of these improvements, providing empirical evidence of the system’s impact on emergency management processes within the institution.

3.1. Population and Sample Determination

The target population for the developed multiplatform mobile application comprises the entire community of the Escuela Superior Politécnica de Chimborazo (ESPOCH) main campus, specifically individuals with active institutional email accounts. According to data obtained from the Department of Information and Communication Technologies (DTIC), a total of 15,911 users meet this criterion, establishing the population base for the application.

To determine an appropriate sample size for testing the mobile application, a statistical formula for finite populations was applied. The total population ($N$) consisted of 15,911 individuals from ESPOCH, including students, faculty, and administrative staff. A 95% confidence level ($Z$ = 1.96) was used, with a probability of success (p) of 0.5, failure ($q$) of 0.5, and a margin of error ($e$) of 0.05 (5%). These values were selected to ensure maximum variability, providing a conservative estimate for the sample size.

The sample size (n) was calculated using the following formula for finite populations:

$$n={\displaystyle \frac{N{Z}^{2}pq}{e^2\left(N-1\right)+Z^{2}pq}}$$

$$n=375.14$$

Thus, the final sample size was determined to be 375 participants, ensuring a statistically significant representation of the ESPOCH community for the testing and validation of the emergency notification application.

3.2. Comparative Analysis of Notification Methods

The efficiency of the proposed emergency notification process was evaluated through a comparative study of the traditional method, which consists of physically locating the nearest security guard, versus the mobile application.

The ESPOCH campus is divided into 10 security areas, each assigned to a designated guard. A total of 375 trials were conducted across the 10 areas: nine areas with 38 trials each and one area with 33 trials, due to operational availability during the data-collection period. Data collection was conducted over a period of two and a half weeks. In the traditional procedure, the elapsed time was measured from the moment a user located a guard to the guard’s arrival at the incident site. In the mobile application scenario, the alert was transmitted directly to the closest guard, who received the notification in real time and proceeded immediately to the incident.

This experimental setup involved on-duty security staff and controlled simulations with students to ensure variability of conditions. Each trial represented an independent emergency scenario, which enabled the study to capture realistic variations in response times before and after the implementation of the mobile system.

3.3. Data Processing and Validity Assessment

All collected data were processed using IBM SPSS Statistics version 24, ensuring rigorous data cleaning and validation procedures. The case processing summary revealed that 100% of the data were valid, with no missing or inconsistent entries that could compromise the integrity of the statistical analysis (

Table 5. Case Processing Summary in SPSS for Data Validation.

Case Processing Summary
	Cases
	Valid		Missing		Total
	N	Percent	N	Percent	N	Percent
BEFORE	375	100.0%	0	0.0%	375	100.0%
AFTER	375	100.0%	0	0.0%	375	100.0%

).

Subsequently, descriptive statistics were computed for both notification methods. The traditional method exhibited a mean response time of 137.16 s, whereas the application-based method demonstrated a significantly lower mean response time of 63.2 s, reflecting a notable reduction in response times (

Table 6. Descriptive Statistics of Response Times for Manual and Mobile Application Notification Processes.

	Descriptives
			Statistic	Std. Error
BEFORE	Mean		137.1573	2.35921
	95% Confidence Interval for Mean	Lower Bound	132.5184
		Upper Bound	141.7963
	5% Trimmed Mean		136.7319
	Median		121.0000
	Variance		2087.202
	Std. Deviation		45.68591
	Minimum		61.00
	Maximum		220.00
	Range		159.00
	Interquartile Range		76.00
	Skewness		0.330	0.126
	Kurtosis		−1.198	0.251
AFTER	Mean		63.2000	0.64631
	95% Confidence Interval for Mean	Lower Bound	61.9292
		Upper Bound	64.4708
	5% Trimmed Mean		63.0904
	Median		62.0000
	Variance		156.642
	Std. Deviation		12.51566
	Minimum		33.00
	Maximum		97.00
	Range		64.00
	Interquartile Range		19.00
	Skewness		0.204	0.126
	Kurtosis		−0.618	0.251

).

3.4. Normality Testing

To determine the appropriate statistical test for comparing both methods, a Kolmogorov–Smirnov normality test [35] was conducted on the response time data. Given the relatively large sample size ($n$ = 375), this test was deemed suitable to assess data distribution characteristics [36]. The results, presented in

Table 7. Kolmogorov–Smirnov Normality Test Results for Response Times.

Kolmogorov-Smirnov ᵃ
	Statistic	df	Sig.
BEFORE	0.162	375	0.000
AFTER	0.073	375	0.000
ᵃ Lilliefors Significance Correction

, indicated that the data did not follow a normal distribution, as the significance value was below the 0.05 threshold.

This conclusion was reinforced by the visual inspection of the histograms shown in Figure 12. In the case of the Before dataset, the distribution appeared highly irregular, with multiple peaks and a clear deviation from the fitted normal curve, indicating substantial variability in response times. In contrast, the After dataset displayed a more concentrated distribution around the mean, with a smoother curve and reduced dispersion, although it still deviated from perfect normality. These visual patterns were consistent with the statistical results, confirming that the assumption of normality was not met for either dataset.

Due to the data not exhibiting a normal distribution, the Wilcoxon Signed-Rank test was used to perform the comparative analysis.

3.5. Wilcoxon Signed-Rank Test

To assess the statistical significance of the observed differences in response times, the Wilcoxon signed-rank test for related samples was applied. This non-parametric test was chosen due to the non-normal distribution of the collected data, as previously determined by the Kolmogorov–Smirnov test [37]. The Wilcoxon test results, shown in

Table 8. Wilcoxon Signed-Rank Test Results for Response Time Comparison.

Test Statistics ᵃ
	AFTER—BEFORE
Z	−16.782 ᵇ
Asymp. Sig. (2-tailed)	0.000
ᵃ Wilcoxon Signed Ranks Test
ᵇ Based on positive ranks.

, yielded a p-value < 0.000, indicating a statistically significant difference between the response times recorded using the traditional manual method and those obtained through the mobile application [38].

The hypothesis testing was structured as follows:

• Null Hypothesis (H₀): The implementation of the mobile application does not significantly reduce emergency notification response times compared to the manual process.
• Alternative Hypothesis (H₁): The implementation of the mobile application significantly reduces emergency notification response times compared to the manual process.

Given the resulting p-value < 0.000, the null hypothesis (H₀) is rejected, and the alternative hypothesis (H₁) is accepted. This confirms that the observed reduction in response times is statistically significant and directly attributable to the deployment of the mobile application.

3.6. Response Time Reduction Analysis

The statistical analysis confirmed a substantial enhancement in the efficiency of the emergency notification process. Specifically, the application achieved a 53.92% reduction in average response time, decreasing from 137.16 s (traditional method) to 63.2 s for the application-based method. This performance improvement is visually represented in Figure 13, which presents a comparative bar chart of mean response times.

Such a significant reduction underscores the application’s potential to optimize emergency response procedures, thereby contributing to enhanced campus safety and incident management protocols at ESPOCH. Moreover, process flow observations highlighted that, apart from reducing response times, the application also eliminated typical manual process bottlenecks, such as dependency on call center availability and the risk of information miscommunication.

3.7. Experimental Conclusions

The results of this study demonstrate that the developed application substantially improves the efficiency and reliability of emergency notification processes within ESPOCH. The system achieved a statistically significant reduction in response times, streamlined the communication flow, and validated the feasibility of real-time geolocation for security purposes. These findings provide empirical evidence supporting the viability of implementing multiplatform mobile applications as a tool for optimizing emergency response systems in academic institutions.

4. Discussion

The implementation of the multiplatform mobile application for emergency notifications at ESPOCH demonstrated a substantial enhancement in response times and operational efficiency within emergency management processes. The observed 53.92% reduction in average response time, validated through controlled simulations, underscores the system’s effectiveness in integrating mobile technologies and real-time synchronization services into institutional emergency protocols.

Compared to prior research, the proposed solution aligns with the prevailing trends in digital transformation of safety management, while introducing critical improvements. For instance, [39] developed a mobile application for direct communication with the civil protection department of the UAMRR-UAT, emphasizing immediate connectivity between users and emergency responders. However, their approach primarily focused on predefined communication workflows, which, while efficient in structured environments, may lack flexibility in handling diverse emergency scenarios. In contrast, the system presented in this study empowers users with autonomous incident reporting capabilities, enabling real-time alerts without intermediary validation steps, thus improving scalability and immediacy.

Similarly, [40] proposed a technological alternative for community security, highlighting the importance of mobile platforms for enhancing citizen participation in safety processes. Their work underscored the value of collaborative networks for incident reporting; however, their system was limited by the absence of geolocation functionalities and real-time synchronization, which are pivotal in campus environments where precise situational awareness is crucial. The integration of geolocation and geofencing technologies in this project addressed these limitations, allowing security personnel to receive contextualized alerts with accurate incident localization, thus enhancing decision-making under pressure.

A remarkable advantage of the developed solution is its multiplatform architecture, achieved through the use of Flutter and cloud-based synchronization services. This design ensures broad compatibility across a wide array of devices, facilitating adoption in technologically heterogeneous environments typical of academic institutions. Moreover, the system’s modular structure provides a replicable model for other organizations aiming to modernize their emergency communication protocols, thereby extending its potential impact beyond the ESPOCH context. Beyond the technical scope, the study contributes practical knowledge to the domain of campus safety by offering a methodological framework from requirements analysis, through agile Mobile-D development, to ISO/IEC 25010 quality evaluation, that can be replicated by other universities. This positions the work as evidence-based support for smart campus initiatives and provides actionable guidance for institutions, particularly in developing countries, seeking to enhance their emergency response systems.

Nevertheless, several challenges and risks emerged during the development and evaluation phases. The reliance on third-party services such as Firebase for real-time synchronization and Google Maps for geospatial functionalities raises concerns related to data sovereignty, service continuity, and long-term financial scalability. In addition, the dependence on stable internet connectivity represents a potential failure mode: network disruptions could delay or prevent the transmission of alerts. Similarly, inaccuracies in GPS services could compromise location precision, reducing the effectiveness of incident tracking. At the operational level, possible issues such as battery depletion on security guards’ devices, lack of network coverage, or the occurrence of multiple simultaneous alerts could affect the system’s responsiveness if not supported by redundancy and prioritization mechanisms.

It is also important to acknowledge the limitations of this study. Efficiency evaluations were conducted in controlled simulation environments, which provided methodological rigor but may not fully capture the unpredictability of real-world emergencies. The pilot implementation involved a limited number of participants, restricting the scope of generalization. Furthermore, the current design is tailored exclusively for internal institutional use, without integration with external emergency services such as police or fire departments, which could reduce its effectiveness in large-scale incidents. Another limitation is the assumption that all community members possess compatible mobile devices, which may not hold true in more diverse socio-economic contexts.

Looking ahead, the evolution of the platform should focus on strengthening resilience and broadening its scope. Potential improvements include the implementation of automated escalation protocols for critical incidents, the incorporation of predictive analytics powered by artificial intelligence to anticipate potential threats, and the inclusion of mechanisms for prioritizing simultaneous alerts. Expanding pilot studies to larger and more diverse populations and establishing interoperability with municipal or national emergency services would further enhance the robustness of the system. These enhancements will not only refine coordination and responsiveness but also consolidate the platform as an integral and proactive emergency management tool, aligned with the evolving safety needs of contemporary academic institutions.

5. Conclusions

This research successfully demonstrated the design, development, and validation of a multiplatform mobile application aimed at optimizing emergency notification processes at ESPOCH. The integration of mobile technologies, real-time cloud data synchronization, and geolocation functionalities significantly enhanced the institution’s capacity to manage emergency incidents efficiently, achieving a 53.92% reduction in average response times, decreasing from 137.16 s to 63.20 s. This improvement was statistically validated through the Wilcoxon signed-rank test, yielding a significance value of p < 0.000, in accordance with the evaluation criteria of the ISO/IEC 25010 standard, specifically within the Efficiency—Temporal Behavior characteristic.

The system’s architectural design emphasized scalability and modularity, enabling deployment across multiple platforms through the use of Flutter, RESTful APIs, and Firebase Realtime Database. Direct communication between users’ mobile devices and backend services facilitated efficient transmission of alerts, status updates, and data queries, eliminating the delays inherent in traditional manual processes. The automation of this workflow not only optimized response times but also reduced the potential for human error, ensuring the integrity of the processed information.

The integration of geofencing functionalities through the Google Maps API was crucial for contextualizing alerts, allowing precise identification of incident locations within the campus and triggering automated events based on the user’s geographic position. This component enhanced real-time monitoring capabilities and streamlined the coordination of response actions by security personnel.

Although the system’s evaluation was conducted in a controlled simulation environment, the obtained results provide a solid empirical foundation that supports its applicability in real-world scenarios. It is acknowledged that additional contextual factors, such as network stability variability, simultaneous multi-incident occurrences, and the need for integration with other institutional security systems, may influence the operational dynamics of emergency situations. These elements, although not directly addressed in the conducted tests, do not undermine the validity of the results but open avenues for future research to assess the system’s performance under more complex and dynamic operational conditions.

In conclusion, this project establishes a robust foundation for implementing mobile-based emergency notification systems within academic environments. The developed solution not only enhanced the efficiency of communication processes in critical situations but also offers a replicable model for other institutions seeking to strengthen their emergency response capabilities through technological tools. The empirical validation of a 53.92% reduction in response times highlights the transformative potential of integrating mobile applications into institutional safety protocols. More importantly, by documenting a replicable methodological path encompassing agile development, modular multiplatform design, and quality assessment under ISO/IEC 25010, this work extends beyond a single case study and contributes a transferable framework for future research and practical deployments in the broader higher-education sector.