Table of Links

Abstract and Intro

Literature Review

Methodology

Results

Discussions

Conclusions

Recommendations

Research Implications

Practical Implications

Declarations

References and Author's Biography

RESULTS

System Architecture

The project's full system architecture diagram, shown in Figure 2 gives a visual representation of all of its components and how they relate to one another. In the case of the Road Updates Information System, this diagram depicts two (2) different user types: the first user is the System Admin, to whom all report approval is monitored and managed, and the second user is the user that represents the common people (such as riders and commuters, as well as citizens), to whom they can participate in reporting incidents in a particular road or location. Since the system leverages Google Maps to access existing maps with high accuracy, another entity in the diagram is the API, which is crucial. Last but not least, having connection to the Internet is crucial for using the system and maps because it is how the system connects to its database, accesses its user interfaces, and syncs in real time.

System Login

A system login is utilized so that admin can access the system's primary dashboard (Figure 3). Only authorized system administrators were permitted to access the admin dashboard in order to validate report requests and maintain the system to protect the functioning and integrity of the data.

Home Page

Figure 4 depicts the user's dashboard or home page, where road updates are displayed. This includes functionality for citizens who wish to report an incident by updating the map with information that is crucial, along with an attached photo to ensure that the actual incident is captured for visual presentation.

Report Information Portal

All users of the system have the option to submit road updates and other relevant incidents in order to notify others about the current and true status on a particular road utilizing this site, which is an example of "Bayanihan," a Filipino character attribute. How to report a road update is shown in a modal in Figure 5. If possible, the individual reporting an incident should include attachments, preferably images of the actual event, that clearly describe the scenario as it actually is, the actual address, and the location point based on maps. The information from the road incident report will be sent to the admin report page for validation and approval.

Admin Dashboard

Once a report has been completed and saved, the administrator will use an Admin Dashboard to monitor and verify it. The Admin Dashboard (Figure 6) shares much of the same content as the User Dashboard, with the exception that it has the ability to review reported road incidents and the discretionary power to approve when fully verified or to deny such reports when the reports are hoaxes, done solely to embarrass or prank people, or when the intention is uncertain.

Evaluation Results

Table 3 displays the results in accordance with ISO/IEC 25010, which includes the quality characteristics that serve as the key criteria for assessing a system's or software's quality. The sub-characteristics that quantify the precise extent of each quality characteristic are included in the table. The Mean is the verbal interpretation of the mean of all user comments. To make the findings of this survey easy to recognize and comprehend, the replies were ranked using a likert scale. The system's success or failure will then be determined by the Overall Weighted Average based on the ISO standard, which is widely adopted globally. According to the table, the mean for each sub characteristic is regarded as being between very good and excellent, and the overall weighted average is 4.21, which is interpreted as excellent on the likert scale.