2 – Implement

• How do I suggest a new feature to the OpenLMIS roadmap?
  • The process of suggesting new features to the OpenLMIS community to work on is outlined here. Once requests are made, the community reviews and prioritizes based on need and resources available to complete the work.

• How do I receive support from the community during my implementation?
  • Do you want to request an extension point to build out a custom feature? Review the extension framework and process here.
  • Do you want to contribute a feature back to OpenLMIS? When a new feature becomes part of the core software, the community shares the responsibility to maintain the feature. Review the documentation and process here.

• What does the OpenLMIS Community expect from me during my implementation?
  • Follow the open source requirements and the OpenLMIS license. This ensures that the achievements of any OpenLMIS system will be available to the whole OpenLMIS Community. We hope all implementers share their intangible knowledge and experience via our committees and tangible contributions with code, documentation and feature requests.

About Country/Implementation Versioning

Before learning the technical details of customization and extension, you should review how version numbers and country-specific microservices and extensions work in OpenLMIS version 3: Country Versioning in OpenLMIS 3.

Once you are familiar with how versioning works in OpenLMIS, refer to the Technical Setup Guide section above for technical details on how to customize and extend OpenLMIS. 

Training and Support

• • Training preparation  (approach, goals, creating and refining training materials (samples), logistics, etc.)
  • Training materials: Presentations for modules, agendas, participant list, training evaluation, training guides for super users (for Training of Trainers (ToTs), worksheets/instructions
  • Conducting a training (guidance on #s of participants, #s of trainers, length of sessions, etc. → valuable info to pass on from our experience in order to conduct a successful, useful training)

Testing/QA – User Acceptance Testing

The purpose of User Acceptance Testing (UAT) is to confirm that the system is performing as expected and meets requirements by the users of the system. Rather than functional testing completed by the implementation team, however, UAT has actual users testing the system to ensure it meets their needs (in other words, ensuring that users will accept that system). The results of UAT provide feedback to OpenLMIS team to enhance features and functionality as well as to address any defects identified.

UAT should be conducted prior to the system rollout and will inform the decision about whether the system is ready and rollout can proceed as planned, or if there are issues or changes identified in UAT that need to be addressed prior to rollout.

Once completed, UAT results should be compiled and reviewed by the team to make a “go / no-go” determination. If there are issues to be address (a “no go”), then those issues should be fixed, at which point the UAT process should be repeated, and a subsequent review and go/no go determination can be made.

Any software deployment plan should include buffer time for fixes or changes and a second UAT session in addition to the initial UAT, to ensure that issues identified in UAT can be addressed without complete disrupting the project timeline.

Testing/QA – Sample Test Scripts

UAT test scripts should cover all scenarios that users will encounter in the system. Each testing script should include detailed, step-by-step instructions and each step should have specifically defined results so the users know what the system should do (or look like) after they complete the steps. Testing should be conducted in any/all browsers that are recommended. Users can identify if each step passes (meets the expected result) or fails (does not meet the expected results). If a step fails, the actual result should be recorded in detail for further investigation and an issue can be opened to correct any problems identified.

Download: Sample UAT Script

Test plan 

Refer to section 1-Plan for guidance and an OpenLMIS Test Plan Template.

Functional testing that is completed by the implementation team is executed and tracked using test cases in Zephyr.

Implementers may also use these functional test cases as a baseline for the UAT test scripts.

Download: Functional Test Case Example

At a minimum, routine support needs to be outlined in the support plan, whether that be an online issue reporting tool, e-mail, or phone line that users can call to request assistance when they face problems or issues using the system. Ideally, on-site support would be provided or at least available for users for the go-live.

The team should also be in close communication to coordinate support requests, questions, and troubleshooting efforts.

To this end, it is helpful to create a deployment plan with the following information:

•      Support approach
•      Team expectations
•      Roles & responsibilities
•      Communication
  • Contact information
  • Standard procedures/processes
  • Regular meetings/check ins

•      Issue management
  • Issue logging
  • Issue triage

•      Known/anticipated risks or issues & mitigation plans