Difference between revisions of "Deliciouscake"

From mn/ifi/inf5750
Jump to: navigation, search
(Link to repository)
m (Summary of requirements)
 
(One intermediate revision by the same user not shown)
Line 42: Line 42:
 
''Non-functional requirements''
 
''Non-functional requirements''
 
* Process requirements:
 
* Process requirements:
** Client-side HTML5 code will be generated by JavaScript.
+
** App will be developed in JavaScript + jQuery, and HTML/CSS.
**CSS3 will be used for styling the HTML.
 
**Calls to the DHIS2 web API for fetching resources and sending messages will be done with AJAX in jQuery.
 
 
** The messages generated and sent by the app will in JSON format.
 
** The messages generated and sent by the app will in JSON format.
 
** Resources fetched through the DHIS2 api will be in JSON format.
 
** Resources fetched through the DHIS2 api will be in JSON format.
Line 99: Line 97:
 
DeliciousCake2.png
 
DeliciousCake2.png
 
Lmis4.png
 
Lmis4.png
 
+
flow_submit_order.png
  
  

Latest revision as of 14:27, 15 December 2015

Project details

Logistics Management Information System (LMIS) Light

The goal for the project is to replace the current paper based system for ordering commodities with a web-based app connected to DHIS2. This will enable users to submit orders to higher managements more efficiently than when using today's system. On one side the app is a simple web-based form where the health workers can fill in orders. On the other side the app is a notification system, where the management can be notified of order requests.

List of group members

Name Email
Simen Røste Odden simenrod@ifi.uio.no
Thomas Schwitalla thoschwi@ifi.uio.no
Jørgen Valen jorgeval@ifi.uio.no

Summary of requirements

Functional requirements:

  • A: The app's main page must contain a form for the submission of commodity orders.
    • A1: The input fields of the form must accept quantities given by positive integers of the requested commodities. It must be possible to enter values both by clicking buttons that increment or decrement quantities, and by entering values directly from keyboard/numpad.
    • A2: The form must provide the entire selection of commodities available from the resource "Life-Saving Commodities".
    • A3: There must be a submit button. Upon click, the app must validate the format of the input and the amounts of the ordered commodities before a message may be generated and sent to the DHIS2 messageConversation resource.
      • A3a: The input of each field must be restricted to positive integers or 0. A ceiling input value of 999 (subject to change) must be enforced.
        • A summary of the order must be displayed when the submit button is clicked. The summary must contain a list of the commodities, and their respective quantities that have been selected by the user. The summary must prompt the user to review the order before sending.
          • Upon the submission of an order, if any fields do not contain a valid entry, an error message in the summary must provide instructions for the correct format or valid inputs next to the invalidated field(s). No message can be sent in such a case.
          • Entirely empty orders are invalid. In case of such a submission, the summary must display an error message prompting the user to review .
        • Upon the submission of a valid order, a button labeled "Send order" must be displayed under the summary table. On click, this button must generate and send the message to the appropriate recipients.
          • The "appropriate recipients" are defined as those roles that are related to the higher management of the current user's organisation unit.
  • B: The Order message, subject "Commodity Order ", must contain in its body the list of each selected commodity and their respective quantities.
    • B1: The message must also display the submission date and the name of the sender.
    • B2: Upon successful sending of an order, on-screen feedback must inform that the order has been placed.
      • B2a: Additionally in this case, a confirmation message must be sent to the user's message inbox. This message, subject "Commodity Order Confirmation", must state the exact quantities of each ordered commodity.
        • An on-screen feedback message must inform that the confirmation message can now be found in the user's inbox.
    • B3: Upon unsuccessful sending, on-screen feedback must inform that the order was now placed, and that the user should try again.
      • B3a: The feedback must include any error codes available for debugging purposes.

Non-functional requirements

  • Process requirements:
    • App will be developed in JavaScript + jQuery, and HTML/CSS.
    • The messages generated and sent by the app will in JSON format.
    • Resources fetched through the DHIS2 api will be in JSON format.

Time schedule

Milestone 1: November 8th

  • Document features and architecture on Wiki
  • Show understanding of DHIS2 web apps

Milestone 2: November 22th

  • First bare-bone version - static HTML
  • Uploadable as DHIS2 web app

Milestone 3: December 4th

  • Finished, if applicable also with the mobile app

Milestone 4: 11th December

  • Final delivery

Documented learning during project

We have:

  • Gained a better understanding of DHIS2, and how to use the DHIS2 API.
    • Specifically, we have gained insight into the different resources that are provided by the api, such as dataElements, users, and userGroups.
  • Learned how to develop apps for DHIS2.
  • Learned to use Git as version control system for the development, enabling synchronization and coordination of source code.
  • Gained experience in using HTML5, JavaScript, AJAX, JSON, jQuery and CSS3 to make web apps.

How we have divided tasks within the group

Planning phase

  • Figure out how to implement the app, and determine a rough schedule. All members collaborate. The following questions had to be addressed:
    • How do we implement the submission form?
      • How do we validate the input fields?
      • How do we generate a JSON or XML from the form?
    • How do we generate and send a message based on contents of the form?
    • How do we implement a storage for commodities, or, what database to pull from?
      • What commodities exist and which should be accessible to each type of user?
      • What types of users/roles exist in the DHIS2 "universe"?

Requirements Phase

  • Establish requirements. All members collaborated; Thomas documented them.

Design Phase

  • Determine app architecture, and interface layout. All members collaborated.

Implementation phase

  • UI layout in HTML and CSS (Jørgen).
  • Interface to DHIS2 web api (Simen and Thomas).
  • Messaging (Everyone).
  • Form validation (Simen).

Screenshots and screen flows

Suggested improvements to API

  • New messages should automatically be marked as unread.
  • There should be a easy way to request the ID's of higher management in a given org. unit.

Link to repository

https://bitbucket.org/deliciouscake2/deliciouscake.git