Tactic 1: Heartbeat

1. Checklist for Evaluation:

• System regularly sends heartbeat signals for the status of core services
• System detects if a heartbeat signal is missed

2. Tactic:

Heartbeat signals are periodically sent from critical components to make sure that core services are operational and up to date. Such services include the triage service, so that actors can be sure that the queue and other components are up to date, as well as the prescription service and authentication services.

3. Design Manifestation:

The main services that require a heartbeat system are:

• Triage System: To make sure that the triage data is up to date and actively updating the queue.
• Prescription System: To ensure that people's prescriptions are being provided in a timely manner.
• Authentication Service: To help sign the correct actors into the correct dashboards so they can access all of the services.

4. Testing Strategy:

• Simulate a missed heartbeat by pausing a service and observing if the monitoring service detects the issue within the expected timeframe.
• Adjust heartbeat frequencies to test load balance and detection response times.
• Validate the alert and recovery mechanisms

---

Tactic 2: Ping/Echo

1. Checklist for Evaluation:

• System sends a working on fetching message when it receives a request to fetch data for the user
• System shows "logging you in..." when it is working on logging the user in

2. Tactic:

Ping/Echo allows users to receive verification when they request something. This reduces users' annoyance as they will be aware that their request is working even if it is taking a while.

3. Design Manifestation:

The main systems that will need this are:

• User Log In: sends confirmation to users that it is loading their data
• View lab results: informs users that their lab results are coming
• Triage Results: confirms that user's triage was completed and that they are just waiting for the results

4. Testing Strategy:

We will test this manually by running our system and clicking on things such as login and view results and verify that the user gets a verification message letting them know that their request is being processed.

---

Tactic 3: Exception Management

1. Checklist for Evaluation:

• System lets specific actors log in
• System detects unspecified actors
• unspecified actors are unable to log in if they try

2. Tactic:

Exception management is an availability tactic that makes sure the system runs smoothly and stays available despite unexpected input. It catches an invalid input and handles it by throwing an exception, which prevents faulty input from proceeding and avoids system crashes.

3. Design Manifestation:

While logging in the actors need to specify what they are logging in as (doctor, patient, nurse, receptionist), and if they enter something not from the given list the system will throw an exception and not let them log in with those credentials.

4. Testing Strategy:

This will be tested manually by inputting correct, and incorrect information at log-in to verify we are catching exceptions correctly.

---

Tactic 4: Retry

1. Checklist for Evaluation:

-[] If incorrect information is given the system will ask to retry -[] If data fetch is unsuccessful the system will ask to retry -[] If given correct information the system does not retry

2. Tactic:

The retry tactics ensure the system keeps running if none or incorrect information is given. It does so by retrying until the correct information is given/fetched. This makes sure that the system is running how it should and incorrect information doesn't cause the system to stop working as intended.

3. Design Manifestation:

In our design, we use this by catching any exceptions, and if an exception is caught we are asked to retry until the system gets the proper information.

4. Testing Strategy:

This will be tested manually by giving correct and incorrect information. When given the correct information the system should run as expected, and when given incorrect information the system should ask to retry until correct information has been given

---

Tactic 5: Removal From Service

1. Checklist for Evaluation:

• Find the parts in the system that either need to be turned off, or removed.
• Features that cannot be clicked will appear in grey.
  • If the feature is greyed out for a specific reason, the user will be able to see the reason.

2. Tactic:

• Removal From Service is a tactic that involves temporarily removing features that either need to be updated, require maintenance, or are unavailable, either due to user restrictions, or unmet requirements. For instance, if a user is creating a password, the 'Save' button should be greyed out until all the boxes have been filled.

3. Design Manifestation:

• In the user interface, features that cannot be accessed will be:
  • Greyed out
    • If due to an unmet requirement issue, a message will appear to let the user know.

4. Testing Strategy:

• Manually test that greyed-out features aren't clickable
• Manual test that if there is a restriction on why the feature is greyed out, display the message.