Software Development

PURPOSE

The purpose of this SOP is to guide software development projects through the complete life cycle of a project in order to ensure a standard level of quality and repeatability. 

SCOPE

This document applies to new software development projects managed by HIC, and where possible this will be extended to cover legacy projects. This document provides a summary of HIC procedures for software development and maintenance. This SOP is will be made available to all users and potential users of the HIC Service and will be externally visible on the public HIC website. 

RESPONSIBILITIES

PROCEDURE

Open

Principles

1. HIC has the possibility to use the secure NHS network for hosting and storage. In case a requirement of the project is to store personal and potentially identifiable information, HIC preferred server for deployment would be on the NHS network, which is only accessible through NHS connected devices. Exceptions will be decided on a project by project basis and accepted only when appropriate risk mitigation can be applied. They will be recorded in the PM system and the project Risk Assessment documentation.  

2. The Delivery of the project stages are fulfilled by HIC. Although the Project Manager will have final responsibility and accountability and the Client will have the final word in determining that the product is fit for purpose, it is not a Client’s prerogative to ask for a particular member of staff to be involved in the project. 

3. The choices related to supporting infrastructure and the technologies involved in providing the software to the Client are a prerogative of HIC Services. Particular technological decisions may involve Client input in case of special Requirements, but as standard the Client will have no influence on those. 

4. The level of service is agreed at project initiation stage and reflected in the gathered Requirements and HIC Quotation. 

Project Initiation Steps

1. All projects will be scoped and costed by HIC senior staff in consultation with the Client.

2. At Project Initiation Stage, various meetings with a client are held to define the Requirements of the Software that HIC will need to develop. These meetings will involve Process Managers and Client and optionally Senior Developers who may be involved in the project. Projects initiated internally will still have a Client role associated, although it will be internal to HIC. 

3. Output of the meetings is a Quotation Document, which summarises the Requirements, associated costs, expected project start date and duration.  

4. A project-specific risk assessment will be carried out and included with the Quotation Document, to assess security measures needed to ensure appropriate data security.  

5. The Quotation Document is approved by the Client before the start of technical work on the Project and progress is tracked in the Project Management (PM) System. Internal projects will be quoted in terms of time, if cost is not relevant. 

6. The Requirements will highlight in detail all the deliverables associated with the project (including documentation and reports to be delivered at Release Stage). 

Design Steps

1. Internal process to review the project scope and make the technical decisions required for the project, all outputs are for internal use only. 

2. The development team will meet together to agree the design of the resulting software including making decisions on the technical aspects.  

3. This process will be audited and documented in a Software Technical Document.  

4. A Testing Plan Document will be produced.  

Development Steps

1. The Development Stage is an iterative process between Developers and Client to gather as much feedback as possible as quickly as possible. During development, coding standards and good practices will be followed to ensure testability and maintainability of the software. 

2. Software and Database Code is developed with attention to security and ease of auditing and reporting. Access to the software, databases, code and HIC building is assigned by Developer Process Managers on a project by project basis. 

3. Access to the production environments (webservers and databases) for deployments is by Senior Developers only and the HIC IT Infrastructure Team when required Access is assigned by the Developer Process Manager for each project as required. 

4. Changes to Code are audited and versioned through a Version Control System and the Project Management System ‘Process’. 

Testing Steps

1. Appropriate testing, as documented in the Testing Plan Document, will be completed in order to ensure an acceptable level of quality and data security.  

2. The Testing Stage is not a specific point in time but a continuous process parallel to Development. Developers will be responsible for designing and maintaining automated tests.  

3. Automated tests are run by the automated build environment every time the code changes to ensure consistency and will notify the responsible Developers in case of failures. 

4. Developers within the team will also perform manual tests every time the code changes to ensure consistency (according to the Testing Plan Document) on special Test Environments. Tests will cover a limited selection of software platforms and browsers.  

5. A risk assessment will be made prior to any software release, with releases risking data security being tested by a second person. 

6. The security of the system will also be tested, both automatically and manually, with special attention in testing all levels of user access available when the application requires users to authenticate and/or have different levels of user access. 

7. Clients will perform User Acceptance Testing either on the same Test Environment or in a dedicated Client Testing Environment. Test reports will be collected and fed back into the Development process for fault fixing. 

8. Given the intrinsically insecure nature of the Test and Client Testing Environments, the Developers and the Client testing the application will avoid using potentially identifiable patient data. If this is not possible it will be highlighted at the Project Initiation Stage and added to the Risk Assessment documentation with special precautions identified and taken. 

Release Steps

1. At the point of Release, the software product will have passed all the agreed tests and the Client will have confirmed that it is fit for use and ready to be deployed in the Production Environment.  

2. The release process is a controlled and repeatable flow. It is performed by a Senior Developer, or, when fully or partially automated, is supervised by a Senior Developer. It is audited and recorded in PM. 

3. Together with the released software, all the other agreed deliverables will be released to the Client. These may include but are not limited to User Guides, Training Packs and Tests Reports. 

4. A Released project will be added to PM and each new version released will be recorded along with its major changes and version number.  

5. A Released project is monitored in the same way as internal issues, as per the monitoring SOP. Issues are logged through PM. Clients can report issues directly into PM via stated email address. Issues are then triaged by HIC support staff to ensure a continuity of service and a faster reaction to faults. 

Support Steps

1. The post-release phase, the Support Stage, is an event driven stage that commences every time there is a support request externally from the Client or internally. This could take the form of a request for assistance using the application or a request to change the application in some way.  

2. The former will be fulfilled by the Support Staff in accordance to the standard support plan or a specific support plan if agreed at project initiation (reference Customer Support Procedure). 

3. Change Requests will be recorded in PM, reviewed, scheduled and actioned as appropriate by the Project Manager and the Development Team (also reference Change Management).

FREE AND OPEN-SOURCE SOFTWARE (FOSS) DEVELOPMENT 

HIC contributes to and manages several open source code repositories.  The following apply when contributing code or accepting contributions to an open source code repository.  Differences in SOP procedures for projects involving significant contributions to a FOSS repositories are detailed below:

Project Initiation Steps

1. FOSS code repositories do not have a direct client.  They are available for use by anyone. 

2. Projects / Clients which involve a substantial dependency on a FOSS repository follow the normal Project Initiation process but acknowledge that features developed will be made available to other users. 

Design Steps

1. Software development in a FOSS repository can be undertaken by anyone in the world without restriction. 

2. All code contributions (e.g. pull requests) coming into a repositories which is managed by HIC must be reviewed before merging by a Senior Developer. 

Testing Steps

1. User Acceptance Testing applies only to FOSS features developed for a specific client on a project. 

Release Steps

1. FOSS software can be compiled and deployed on any branch at any time by any member of the public 

2. Approved pre-releases will be marked ‘pre-release’ and follow semantic versioning protocol (e.g. 1.2.1-rc1 as the first release candidate of version 1.2.1) 

3. Final releases will be marked as ‘Release’ and tagged in the FOSS code repository. 

Support Steps

1. Successful FOSS projects require continual maintenance. This includes monitoring user reported issues, merging pull requests and patching bugs. 

APPLICABLE REFERENCES

• Quality Control 

• Change Management  

• For Definitions see ISMS Glossary

DOCUMENT CONTROLS