The ‘types of work’ carried out by the Sm8rtHealth software team typically progress through Sm8rtHealth’s software development lifecycle (SDLC), which involves five phases:
| SDLC phase | Implementation activities |
| Requirements | The purpose of this phase is to identify and define what the software needs to do. The business, functional and performance requirements are documented. A high-level assessment is made as to the best way to implement the requirements and the extent to which existing software will be impacted. A determination is made as to the scope of work and the effort required to implement the work. |
| Design | The purpose of this phase is to define, and where required, document/map the software design to be implemented that will meet the requirements set out in the first phase. (In other words, the design phase defines the ‘how’). Depending on the scope of work, the design activity may involve additions or changes to the solution architecture, data flows, the database /data model, the UI/UX theme engine, Gateway API and/or other interfaces. The design activity may also involve additions or changes to the underlying software stack and/or the AWS infrastructure. An assessment may be needed to understand the impact the additions or changes will make to software maintainability, scalability and usability. |
| Implement | The purpose of this phase is to implement the Sm8rtHealth solution, as designed, which will involve software coding and/or configuration, and preparation of ‘as-built’ documentation. Because Sm8rtHealth is highly configurable, many parameters (e.g.: for configuring workflow and underwriting rules) can be set/changed without the need for software coding or production releases. Therefore, some solutions can be implemented without impacting the code. If the Sm8rtHealth solution requires changes to existing software code (or the creation of new code) Sm8rtHealth’s software team utilises a ‘local’ development environment. Once sufficient local testing has been completed, the solution is promoted to the ‘Test’ environment running on AWS, in preparation for the Test phase. ‘As-built’ documentation is created (as required) which can take multiple forms, including; screenflow or workflow documents, data models, comments in the source code, business rule specifications, user guides (e.g.: the Sm8rtHealth User Guide for configuring underwriting rules) technical manuals (e.g.: the Sm8rtHealth API Gateway Developers Guide) and FAQ’s. |
| Test | The purpose of this phase is to confirm that the solution, as implemented, is free of defects (where a ‘defect’ is defined as a failure of the software to perform according to the documented requirements, i.e.: business, functional and performance requirements). In particular, testing must confirm that (i) any newly created/changed code is defect-free, and (ii) no existing features and functions of the platform are adversely impacted by newly created or changed code (i.e.: regression testing’). However, because the Sm8rtHealth platform is multi-tenanted, the regression testing must also confirm there has been no adverse impact for all platform tenants. Because the Sm8rtHealth platform is built to serve users on multiple devices, test coverage involves both desktop and mobile device testing. However, operation is only confirmed for a limited set of device/operating system combinations. This phase involves: Test planning: (i) defining the full set of test scenarios (including regression testing) needed to confirm the requirements have been met, (ii) defining the expected outcome(s) for each test scenario and (iii) defining the acceptance criteria that will enable the solution to be accepted/signed-off.Test execution: Carrying out the planned testing/regression testing to confirm if the software is operating as required Test feedback: Carefully documenting any defects identified, so that quality feedback can be provided to the software team for remediation. Sm8rtHealth testing is carried out across two environments: TEST: Internal testing is first carried in the AWS ‘TEST’ environment by Sm8rtHealth personnel.UAT: Once the internal testing has been successfully completed, the software and/or configuration changes are promoted to the AWS ‘UAT’ environment so that the client/Sm8rtHealth tenant can perform ‘user acceptance testing’ (UAT). Once the solution has been tested and verified that it is defect-free, the final step of this phase it to obtain acceptance/sign-off from the relevant stakeholders. |
| Deploy | The purpose of this phase is to promote the solution (i.e.: code changes, configuration changes or new software) into the Production environment following signoff in at the conclusion of the Testing phase. This phase involves the following steps: Pre-production deployment: The Sm8rtHealth solution is first promoted to the Pre-production environment and smoke tested to confirm that it works correctly, before progressing to the next step. Deployment planning: A plan is drawn up setting out (i) when the deployment to the Production environment will take place, (ii) who will be involved in the deployment (iii) what smoke-testing will be implemented after deployment and (iv) how the role-back will implemented if the deployment is unsuccessful. It is usual for deployments to take place outside of normal business hours, such as at night or on weekends. Production deployment: The Sm8rtHealth solution is promoted to the Production environment in accordance with the deployment plan and the solution is smoke tested to confirm that it works correctly. If the smoke test confirms the solution is not operating correctly, then the deployment is reversed in accordance with the roll-back plan. Release Notes: Following successful smoke-testing, ‘release notes’ are completed with the time and date of the deployment. The release notes are Sm8rtHealth’s record what changes or additions were deployed, and the date/time of the deployment. Version Control: The Sm8rtHealth Version Control document is updated to reflect the latest version of all components and rules in the system. |
