Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

Starting this page for scoping - Derek Pollard to add initial detail.



Responsible Person:
Other parties to review/input:
FYI:
Targeted release date: RVL-163 - Getting issue details... STATUS
Jira Status: RVL-163 - Getting issue details... STATUS

Process

  1. Prepare rough business analysis/reqs doc (Derek Pollard: Complete) Pierre Dane, please review before requesting CHAI team to review. 
  2. Get CHAI review
  3. Get Akros Review
  4. Get Ona feedback
  5. One iteration
  6. Ona sign off
  7. Ona tech spec scoping
  8. Ona LOE 
  9. Ona scheduling

Definitions

  • Peer-to-peer sync in the process by which, two or more tablets sync data across themselves without syncing to the server first. This would be done through some local network mechanism (bluetooth, hotpsot) from the devices. The outcome will be to provide offline coverage indicators.

Requirements

Sync data within a specific operational area between tablets that collected data in that operational area.

Get confirmation of what data was synced between tablets to ensure all data was sent and received.

Display coverage indicators for that operational area that reflect all synced data and filters out any duplicates to show one spray status per structure. See workflow below for indicators suggested and reason.

Views

See workflow in this google doc as I can't load the document directly.




Examples of how this previously worked in mSpray 


Notes

Overview of sync and offline indicators from mSpray:

To date, the spray effectiveness of an area can only be determined once teams have returned from the field and uploaded data from their tablets to the mSpray server; internet or network is required for this upload. At that point, teams can see on the dashboard, the coverage of that area; when coverage is not at 90%, teams revisit those areas. However, the travel costs of reaching areas are quite high, so teams should be able to review coverage across multiple tablets before leaving the field, so that if coverage has not reached 90%, they can address that before leaving the field. This requires local syncing across tablets. This particular feature was specifically requested by our donors, the President’s Malaria Initiative. The key additions needed for this optimization are:

  1. Mechanism for a “local sync” of un- submitted data across all tablets that are in use in the same area in a given day. This could involve one tablet acting to provide a local network via Bluetooth, for example. This must work in an area that has no network.
  2. Display on mobile application (ideally on map of area), the key indicators achieved (spray effectiveness, spray coverage, found coverage) in that area.
  3. With sync, update of spray status and appropriate colour change, of each structure appearing on the map in that area.

Indicators

    • Spray coverage
    • Room coverage
    • Number of structures required to get to 95%
    • Number of rooms required to get to 95%
    • * Accuracy of the calculation is key
      • Show how many records have been sent.
      • Deal with multiple data collected from the same structure
      • Is all data synced

Justification


Dependencies


Questions


Test Case

#

Step

Pass / Fail

Comment

1




2




3




4




5




6




7




8




Additional tester comments:










  • No labels