...
Definitions
Term | Definition |
---|---|
Module | Modular programming is a software design technique that emphasizes separating the functionality of a program into independent, interchangeable modules, such that each contains everything necessary to execute only one aspect of the desired functionality. |
(Software) Package | A collection of functions written in a single language bundled with additional content like documentation, unit test, sample data etc. Source: https://en.wikipedia.org/wiki/Package_development_process |
Component | An individual software component is a software package, a web service, a web resource, or a module that encapsulates a set of related functions (or data). Source: https://en.wikipedia.org/wiki/Component-based_software_engineering#Software_component |
Sources | Technical source code, structures and definitions of an IT solution |
(JLN) Business Process | |
Functional Unit | An interchangeable unit that provides a piece of business functionality |
(Software) Repository | A storage location for software packages & other technical sources |
Key Questions
How to find a wording which is clear and prevents misunderstanding and allows for a common language between business (implementers) and technical (developer) people?
Findings
- Module pages under openIMIS Modules do not share a common structure / content
- Use of property tables seems advisable
- Overview in openIMIS Modules uses color coding without providing an explanation (types of modules like Core, Interop, Business, ??)
- Linkage between “Modules” and Repositories unclear / Dependencies are not documented
- Definitions unclear, what is a “Module”?
- Sources Release 2022-04 lists repositories as “Components” (renamed from “Module”)
- Multiple modules under openIMIS Modules seem to be outdated and incomplete, are not separately documented, but mixed with other “Modules”
- Modules under openIMIS Modules are organized in a complex but incoherent structure (e.g. sometimes grouped by business process or other)
- Modules under openIMIS Modules do not follow a consistent naming format
- Modules under openIMIS Modules are not always descriped separately, but mixed (failed separation of concerns SoC?)
- Some modules under openIMIS Modules do not match to the diagram
- Some modules under openIMIS Modules contain overly technical (source code, stored procedures) details
Related Pages
Page | Content / Findings |
---|---|
Describes “Modularity” as Plugins are documented in openIMIS Modules. | |
In openIMIS, (nearly) everything is a module: even "low level" (and mandatory) features follow this principle. | |
| |
| |
|
List of Modules under openIMIS Modules
Module | Content / Finding | “Modules” in diagram |
---|---|---|
| Claim | |
“Beneficiary Enrollment” \ Policies module scope |
| Policy |
“Beneficiary Enrollment” \ Persons & Families module scope |
| Persons - Missing in diagram Families - Missing in diagram |
“Beneficiary Enrollment” \ Contributions & Payment module scope |
| Contribution Payment |
“openIMIS Administration Modules” \ Product module pages mockup |
| Product |
“openIMIS Administration Modules” \ Locations & Health Facilities module scope |
| Location Health Facilities - Missing in diagram |
| Claim AI | |
| ||
| FHIR V3 FHIR V4 | |
| Invoice Others? (e.g. Contribution Plan ?) | |
| Calculations | |
| Contract | |
| Policy Holder | |
| Policy Holder Portal - Missing in diagram | |
| Bulk CHFID Generator- Missing in diagram | |
| Claim Batch | |
| Report | |
Missing Modules from diagram |
|
|