...
- Prioritization of issues
- Prioritization is decided at the level of technical advisory group
- Release cycle involves different committees
- Suggestions:
- Segment priorities into high priority, medium priority, low priority for country requests
- Redefine the development and implementation aspects of issues
- Only the committee can identify an assignee to an issue
- Automatic email response for requests should come with a link indicating the next steps on how to go about the request
- Include radio button selection from the get-go to narrow down issues and make it easier for the users
- Before hiring an external developer, inform first the developers' committee
- Appoint a focal point in each country to have a linkage into the global issue queue
- Assign some issue to an academic group (a group of students to a look at an issue queue)
- Conduct capacity-building with local partners for issue escalation (Learn from the openLMIS experience)
- Ticket submission by a local partner (local implementation partners do the first round of filtering)
- Consensus-based priority by the global committee (look if a specific country request will affect a lot of people)
- End-user → local implementing partner → global committee
- Question: Local queue system per country (send email to the system then goes to the email of a group of people then a ticket gets assigned to somebody logged through a focal point in a country)?
- Clarify with openLMIS
- Screenshot must be attached to requests for faster correspondence
- Proposed process:
- First Level
- Questions
- Report bugs (try to replicate and refer to that) when you raise a bug
- New feature request (filter if health financing side)
- Second Level
- Detailing out what exactly is needed
- Decision-making (what resources are needed) before going to the developers' queue
- Create substeps for IC & DC
- First Level
- Issues:
- Define differences in priority (who will decide?)
- Functional requests have overlap with the development side (issues on the service desk needed to be channeled either to the developer or implementers committee)
- Do we use a single tracking system? (Tanzania uses a different one)
- Should we integrate external developers in the Jira issue queue?
- Should we maintain the local solutions from countries to the global github?
It's up to the country if they want it to be available on github
Bluesuare is proposing to have a plug-in feature so local developers can hook into the platform without the rest of the world knowing about it
- Others
- Jira can also accommodate other requests apart from the country-specific implementation side
- Average reaction time for response is 24 hours according to the SLA
- Hubs as part of the process (part of the issue queue)
- Rwanda
- Step-by-step proposal for Rwanda (tailor it to the size of the implementation)
- The rollout is mostly training of users (depends on location as well)
- Rough estimation only because it depends on the country cost
- Tanzania
- National rollout in Tanzania (sample) - now just the concrete application in the new districts
- Information to think through on what they need to do (getting the steps done so they own the process, get them an idea of the quantity, the cost should be researched upon)
- Same applies with the timeline of the application
- Cameroon
- Experience: outsourced maintenance support
- Request: Build capacity for the local teams (developers in each country)
If we document and escalate all to the global level, maybe the local team can resolve, but we can still inform/update the global so it can be replicated in the global level
Country representatives who can be logged in to the Jira (if we leave it open to users, global will be overwhelmed) – we should leave some issues to be taken care of the local team
Whenever there is a new requirement, at the moment you are working with the epayment application, so other countries may not need to do the same and use the same
- Issues:
- Open source advantage and disadvantage
- Maintenance and support
- Global team: Before we accept any contribution, they need to follow the policies or tests, before it goes to the master version
- Establish communication/contact when you bring in a new developer so they are aware of the global initiative
- If Cameroon can engage local developers (but you are not assured of their competency), who responds with health-related?
I. Release Cycle
- Release cycle diagram (bottom-up approach) Development life cycleInter-project Collaboration
- Maintenance and Support Project
- Legacy system support
- New functionalities update
- Technical support
- Demo server update
- Capacity-building Project
- User needs
- Issues
- Functional Specifications
- Modular Transformation Project
- Architectural changes
- Packaging mechanism
- Maintenance and Support Project
- Development Life Cycle
- Analysis and Requirements (input: capacity-building)
- Architecture, R&D, Prototyping (input: modular transformation and Digital Square HL7/openHIE interoperability)
- Design and Development
- Testing and Quality Assurance
- Release Management (input: modular transformation)
- Training and Product Support (output: capacity-building, modular transformation, Digital Square HL7/openHIE interoperability)
- Maintenance
- Maintenance and support project planning
- 6 months release cycle
- 4 months of development
- 2 months of support/ specification or requirements gathering
- Next release cycle
- April 2019
- October 2019
- April 2020
- 6 months release cycle
Open Forum:
- Make sure there is enough time for developers
- Time between requirements gathering and process where implementers committee contribute to the process of the release cycle depends on a matter of how many releases come out
- Collection of requirements will go the issue queue
- How to modify to bring in the implementers committee (hubs)
- When do we start or put the process into the diagram
- Who will be the coordinator (go back and forth), who will be responsible in each part, who will communicate
- Define another step to generalize solution on the business side and developer side (go straight into the queue)
- Prioritization mechanisms and who will decide
- Take into account the process of testing to make sure it all complies with the requirements before the release (Testing is important because of many scenarios in health insurance_
- Set up a test server (end user acceptance test will be placed mid-year)
- Deploy it in the user demo server (online or offline) then give them time to test; usually two months
- Put it in the live system
- Master version release then testing
- If someone can have a look at the user perspective then wait for countries to give you feedback or you can have a sub-release
- Beta-release (not tested in the field yet)
- Categorize development stuff during requirements gathering
- Once the new release is coming out, developers can still continue with the development (we should not have a particular period)
New developments will be on the modularization component
Modular transformation and integrations
Change the system architecture and developer platform, database (from monolithic to modular architecture)
- Re-architecture will change the back-end but user functionality will remain the same
For the maintenance component, it will focus on maintaining or holding the system together
- Two business analysts (not full time) in the team as of the moment
- Consider the naming of openIMIS versions
...