The Avantus Systems software development life cycle (SDLC) defines the process by which changes and new versions of the application are planned, created, tested, and deployed to the production environment.
Changes and new development are included in a defined release cycle. Each release is noted with a version number, e.g. v2.20.1. The current platform version is clearly marked on the footer of the admin portal tenant, linked to release notes showing significant changes for each release. Each release update triggers a notice on the admin portal advising admin users of the current version along with a link to the release notes.
Avantus prioritises release versions over timebox constraints, allowing complete development, test and QA of each release. This approach is at the expense of a fixed timed schedule of releases to planned dates throughout the year, as priority is given to quality assurance rather than speed and frequency of new releases and features. Release versions are however estimated to run each month to support a reasonable flow of bug fixes.
Breaking faults are fixed immediately, outside of the release cycle where possible and safe.
Example Release “v2.20.1”
- Choose items for release
- Develop & code review
- Deploy to dev and test
- Test Sign off
- Release QA and test
- User Acceptance Testing (where required)
- Sign off QA
- Deploy to live
Change Control Process
We adhere to our own change management process, which broadly follows the following steps:
Review and classify request for change
Change requests originate from either internal product management decisions or client request, as well as notification of faults. Requests are reviewed and classified as one of the following
- Fault – typically reported to us via our Fresh Desk system. Tickets are quantified as a true fault requiring a fix, or exposure of a client's knowledge gap. Faults are classified by severity and actioned accordingl
- Configuration issue – an issue that can be corrected by change to configuration, such as benefit parameter, page style or element positioning, setup configuration. Faults of these types are not treated as true faults as they can be fixed or advised immediately via configuration on the admin portal
- Breaking fault – broken page or function that doesn’t work as expected, that restricts a business-critical process from running and cannot be fixed by admin portal configuration or an acceptable workaround
- Accepted fault – an issue as above that is not business critical and can be fixed in the next update. An acceptable workaround may be put in place until the next suitable release is agreed.
- Non accepted fault – issue reported by a client that is not accepted as a fault by Avantus Systems as it describes a function not supported by MyWorkPal. This may be raised as a changed request or added to the wish list.
- Change Request – request from a client or agreed improvement from within Avantus Systems to enhance functionality within an existing module or process. For example, “As an admin I want to control the benefit start date in lifestyle events to commence benefits from the first day of the month so that they are in line with payroll standards”. Where a request has come from a client the change will be prioritized on a commercial basis.
- Wish List – agreed improvement to functionality within an existing module or process that has no commercial or functional priority. These are added to an Inventory of future development features and actioned when relevant and development resource is available.
- New Feature – a significant addition to an existing feature or a new module. This may have originated from a client or from the Avantus product management team.
- Configuration issue – an issue that can be corrected by change to configuration, such as benefit parameter, page style or element positioning, setup configuration. Faults of these types are not treated as true faults as they can be fixed or advised immediately via configuration on the admin portal
Agree business change acceptance
Breaking faults are fed into the development team immediately. Accepted faults are either fed into development immediately or added to a future wish list depending on estimate of resource required and priority. Non accepted faults are added to wish list.
Change Requests are also added to the wish list where resource requirement is estimated and prioritized. Once all accepted changes are added to the Inventory, they are available to future releases.
Changes are then considered by the product management team, development and test team for each release version.
Develop
The feature, fix or enhancement is developed on separate developer code branches. Once tested and peer-reviewed the code is merged into a common “dev” branch where’s it’s made available to the test team to review and pass back for any iteration.
Quality Assurance
Once the development item has passed initial tests it’s added to the release candidate for the next version, ready for QA. When all agreed features have been added to the release candidate the version is deployed to a QA environment.
The QA environment is a “copy” of the live platform hosted on a separate virtual server to the production environments.
The QA deployment procedure initially takes a copy of a platform database and obfuscates personal data – entirely obscuring personally identifiable information for all users (other than administrators) on the database. All tenant data and configurations are maintained to allow specific testing as close to the live environment as possible. The website files and media are also copied across, providing as close a copy of the production platform as possible to test the deployment process for this version.
Tests are then run on the QA environment to check that features in the new release don’t impact platform-specific configurations.
Any issues at this stage are passed back to the development team for iteration.
User Acceptance Testing
Before the release is deployed to live environment each platform has the option to be tested and verified by the platform owner (client). This step is generally optional and should be agreed with Avantus Systems. In some instances this is a required step, notably where a new feature is developed for a specific client.
Deploy
Once QA has been completed, the platform is ready for deployment. Confirmation will be notified to platform owners with the planned release date. New releases are deployed outside of business hours and should impact no more than 5 minutes down time. The next time an administrator logs into the platform they will see a notification of the new release with a link to features included in that release.
How do you maintain integrity of the security aspects of the system during development life-cycle?
Information systems are deployed with appropriate security configurations and reviewed periodically for compliance with our security policies and standards.
All installations use the same configuration and infrastructure, ensuring compliance with Avantus’ internal control processes. This alleviates the need for review at an individual installation level as deviations are not possible. Development and maintenance of software systems is designed to resist security risk.
Our established development life-cycle for developing secure infrastructure, systems, and applications is an ongoing process subject to constant review which is necessary given the ever-changing environment. All changes are tested thoroughly on mirror applications before being approved for uploading to the live environment
All source code is tested on a development server before being deployed to live and is then tested again. Appropriate test scripts are agreed and approved by test manager before Director approved live deployment.
New development is peer reviewed via GIT Pull requests.
Where is development code stored
Avantus Systems uses GitHub as a respository and version control for source code. Code versions are stored on GitHub servers and developed on individual workstations.
Does Avantus have Public, Employers and Product liability and professional indemnity insurance?
Avantus Business Solutions maintains the following insurance policies for the whole group of companies
Policyholder: Avantus Business Solutions Ltd and Subsidiaries companies
Your correspondence address: 1 Milkhouse Gate, Guildford, Surrey, GU1 3EZ
Business Description: Financial Advisory Service
Public Liability
£5,000.000 – renewal date 23Jan 2020
Covered by Combined Policy with Covea via Stackhouse Poland insurance broker
Professional Indemnity
£4,000,000 – renewal date 20Nov 2019
Covered by policy with HCC Insurance Co. via the broker ASE Insurance Agency (UK) Ltd
Employers Liability
£10,000,000 – renewal date 23Jan 2020
Covered by Combined Policy with Covea via Stackhouse Poland insurance broker
What service levels (SLA) does Avantus support for the hosted system?
Service level agreement between Avantus and clients is detailed in the client contract.
Server Performance
ASL Server Performance will be Available for not less than 99.95% of each calendar month. Availability will be calculated and reported in accordance with the rules set out below.
If in any calendar month ASL does not meet this standard of Availability, ASL will compensate the Client. The amount of compensation will be determined in accordance with the rules set out below.
ASL will provide this compensation by making further Maintenance Services or discounts available to the Client up to the amount of compensation at the applicable rate. This compensation will be the only remedy available to the Client in the event of the non-availability of the Service.
Planned Outages
All work for the purpose of maintenance or support as part of Planned Outages will take place outside Business Hours. Planned Outages will be notified to Client wherever possible on 24 hour prior notice by telephone or e-mail unless otherwise agreed. ASL shall wherever possible ensure that there are no more than 2 planned Outages each month.
Availability
Availability is calculated at the end of each month in accordance with the following formula:
A = (X – Y) / (X – planned outages) X 100
Where:
"A" - the Availability of the Service (expressed as a percentage).
"Y" – Minutes of Downtime in 1 calendar month
"X" – Total minutes in 1 calendar month based on 1 minute past midnight on the 1st to
midnight on the last day of the month.
Calculation of Downtime
Downtime is calculated from the time of notification of a fault by either the Client or ASL, and ends when the Service is restored to full working order as determined and certified by ASL. These times will be logged and notified to the Client via e-mail. However, Downtime is to be disregarded to the extent it is attributable to the Client’s own network, ISP or other Internet related problems outside the control of ASL.
Compensation Calculations
If availability falls below the guaranteed levels in any particular month then the Client shall be credited as follows: -
Availability of monthly service charge
99.00 - 99.49% 5%
97.00 - 98.99%10%
95.00 - 96.99%15%
90.00 - 94.99%20%
Under 89.99%25%
Problems due to bad Internet connection and issues not controlled by ASL will not be compensated for.
Response times on issues
Low-Medium priority: typically within 1 working day.
High priority: typically instantly or under 15 minutes within normal business hours.
Support is be available on demand via ticketing system 24/7 and telephone in normal business hours.