project-proposal-2025

CrisisSpy

Abstract

We have seen it happen it with COVID. We saw it happen again with Alfred. What happens when a disaster or a crisis hits? Things go out of stock - hand sanitisers, toilet paper, butane gas canisters, batteries, canned food, bottled water, and more toilet paper. These items seem impossible to find. Things only get worse from wanderers who don’t know where they need to go, causing traffic jams and crowding. Everybody loses.

What if everybody knew where to go? That is the question CrisisSpy tries to answer, to minimise traffic jams, disruption and panic.

Author

Name: David Jeong

Student number: 47430004

Functionality

Summary

CrisisSpy aims to do one thing - inform the user about the nearest place they can find a product they are looking for, such as toilet paper, eggs, or butane gas canisters.

Features

Getting Data

The system will scrape supermarket webpages and app interfaces (as they sometimes contain different information) to find stock information for items. This information can be stored in a database, and updated regularly.

User Interaction

CrisisSpy will take two things as input from the user: the item they are looking for, and their location (either using location data or a postcode). Using this input, CrisisSpy will search all stores within a cetrain distance (customisable), and filter out stores that do not have the item they are looking for. Then, the stores will be sorted by distance to the user’s location, providing the user with stores of interest.

User Interface

Similar to PetrolSpy, the basic UI will have two components - a map and a list. Firstly, the user can search an item they want (such as toilet paper), and a list of stores nearby will appear in order nearest to the customer’s location, or their specified postcode (if the customer does not share their location). Using Google Maps API for the map would work well for familiarity for users.

An example of what the UI could look like, image retrieved from Costco Australia Image retrieved from Costco Australia

Scope

The following features will be required for the Minimum Viable Product:

Quality Attributes

The most significant quality attributes of the system will be the following:

Availability

Availability refers to the extent that software can be accessed on demand by end users at any time on any platform.

In the context of this project, this means that the webpage should be accessible whenever a user wants, using whatever technology they can. This attribute is significant because the primary goal of CrisisSpy is crisis mitigation - to minimise impact of a crisis occuring in forms such as panic in the civilians, traffic jams and crowding specific areas. Since crisis can strike without warning, it is significant for the app to be available as much as possible.

While reliability is also important, availability was deemed more significant as minor failures in the program (such as items listing as out of stock when they are in stock) would be less impactful than the system going down for a period of time, in the context of the project.

Extensibility

Extensibility refers to how easily features and/or extensions can be added to the software over its lifespan.

Depending on the type of crisis, different items are required. For example, in a pandemic (such as COVID), hand sanitisers are in high demand. On the other hand, in a cyclone, hand sanitisers have less priority, and instead, demand for sandbags increase. Since CrisisSpy aims to mitigate impact of all crises that may happen, it is significant to be able to add items in high demand, to let people find them easier. Extensibility is especially significant because the extension of functionality allows the software to adapt to unpredictable crises.

Scalability

Scalability refers to the ability of the software to be simultaneously usable by a large number end users, while being economical to deliver with varying user loads.

Since the project is intended to mitigate crises that will impact very many people at once, it is significant that the software can handle very many concurrent/simultaneous users. In relation with the availability quality attribute, it is significant that the project stays available under heavy load, at any time.

Scaling could be achieved through online cloud infrastructure such as AWS or Azure, for economically providing basic functionality, and increasing capacity on-demand when crisis approaches.

Other attributes

While other quality attributes are also important to consider, the attributes above relate to the fundamental objective of the project, and thus are the most significant. For example, interoperability would be significant as the software requires data from other sources (google maps, stores), and reliability would be significant as it links deeply to the software functioning properly, however they relate to the foundational aspects of the architecture of the project, not the project itself.

Evaluation

Availability

Availability over time can be easily measured using the uptime/downtime ratio, and MTTR (Mean Time to Restore), as the service going down for any reason at any time is a hit to the availability of the software. The longer the downtime is, the lower the availability. The cause of the downtime should be measured separate to availability, such as downtime due to software logic failure being accounted for in reliability, and downtime due to server overload being counted in scalability.

The uptime/downtime ratio and MTTR are quantitative measurements that can represent the total availability of the software. Furthermore, it is easy to set clear goals for the metrics, to then identify issues that disrupt the program from meeting the goals.

Extensibility

Extensibility is difficult to measure and give objective data. However, it is easy to simulate by adding products that weren’t tracked beforehand. This would involve adding functionality to the UI, and the web scraper, and formatting the database to account for new data. Simulating items that may be required in different crises, such as pandemics, cyclones, earthquakes, blackouts, floods, bushfires and more, would be helpful as different conditions require different items.

Scalability

Since the software intends to use cloud services such as AWS to deploy, the metrics for the software will be provided by AWS, such as the number of concurrent connections it can handle, or the number of input/output operations that can occur in one second (to provide to users). However, the measurement an also be completed indepently through stress tests. Since the software will be deployed as a webpage, simulating very many connections is simple to automate, potentially allowing stress tests to be completed automatically to test the conditions. However, since AWS will be the main service provider, stress tests will be mostly unnecessary.