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. HIC primarily develop Closed-Source applications but as part of our research activity we also support Open-Source applications.

RESPONSIBILITIES

CORE PRINCIPLES

1. Security by Design is fundamental in HIC’s software development process. From the initial planning stages through to deployment and maintenance, security considerations are integrated into every aspect of development. This proactive approach ensures that our software is robust, resilient, and capable of protecting sensitive data and maintaining user trust. By prioritising security from the outset, we aim to mitigate risks and address potential vulnerabilities before they become issues. Least privilege system access is adopted where only the Software Project Managers and Process Manager have access to customer facing environments. The whole Development team has access to a development environment.

2. Quality Control - HIC ensures high-quality software by conducting comprehensive testing, including unit, integration, and user acceptance tests, to identify and resolve defects early. Penetration testing is also carried out. Automated testing tools are utilised for consistent and efficient testing, while peer code reviews maintain code quality and security. We prioritise thorough and up-to-date documentation for all software products and implement real-time monitoring and feedback mechanisms. Additionally, we foster a culture of continuous improvement by regularly reviewing and enhancing our quality control processes. These practices ensure our software meets the highest standards of excellence, reliability, and security. Software deployments follow the Change Management Process including risk assessment.

3. Secure Hosting Practice - Development projects can either be hosted on the NHS Network or Public Facing via HIC Supported or Cloud Servers. HIC recommend leveraging the secure NHS network for hosting and storage for projects with sensitive data, ensuring the highest standards of safety for personal and potentially identifiable information. Exceptions to this are software which requires to be accessible beyond the NHS network boundary which are carefully considered on a project-by-project basis and approved by the data controller only when appropriate risk mitigation measures are in place. The Development Team have access to Development and Staging Environments to allow for testing independent to the Production environment.

OPEN SOURCE PRINCIPLES

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

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

3. Software Project Managers may refuse to merge incoming change requests for open-source if they do not adequately conform to the tool's existing design principles on a project by project basis.

4. Software development projects can be initiated internally, with an internal Client role assigned within HIC. 

5. Time-sensitive internal requests are prioritised for development, with the prioritisation of work determined by the stakeholders of the open-source tools. 

6. User Acceptance Testing applies only to features developed for a specific client on a project or for internally requested features.

7. HIC does not provide support and maintenance for Free and Open Source Software (FOSS) deployed or used by those external to HIC.

8. Where HIC is a user of a FOSS repository deployment of newly available binaries will follow normal procedures listed below.

PROCEDURE

Open

1. Software Development Initiation

   1. Internal or external client requests a project scope for software development. Requests can be raised via the HIC Support Board, during client interaction (meetings/email) or the appropriate open-source issue tracker available via the tools host service. 

   2. Outline requirements of the software development are discussed by the Client, Software Project Manager and Development Team and recorded in the Project Management System.

   3. Where applicable, Software Project Manager prepares Quotation Document and a project-specific risk assessment will be carried out to assess security measures needed to ensure appropriate data security and records in Project Management System. 

   4. Process Manager validates quotation prior to client receiving the quote.

   5. Client confirms quotation and notifies if funding successful.

   6. Detailed requirements are defined and agreed by the Client, Software Project Manager and Development Team.

   7. Development Team starts technical work on the Project and progress is tracked in the Project Management (PM) System. Internal projects will be quoted in terms of time. 

   8. If project funding is not awarded the PM system is updated.

2. Design Software

   1. Development Team creates a detailed design based on the requirements and documents in PM system, additional project documentation will be stored in the Project folder.  

   2. New features and updates will be reviewed to ensure conformity to the existing project structure.

3. Develop Software

   1. Feedback is gathered between the Development Team and Client.

   2. Software and Database Code is developed with attention to security and ease of auditing and reporting.

   3. Changes to Code are audited and versioned through a Version Control System and the Project Management System. 

4. Testing Software

   1. Appropriate testing will be completed in order to ensure an acceptable level of quality and data security.  

   2. All code is subject to peer review/testing by the Software Project Manager and/or another member of the Development Team.

   3. Development Team will be responsible for designing and maintaining any automated tests.  

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

   5. Development Team will also perform manual tests every time the code changes to ensure consistency on Development Environment. Tests are carried out using a limited selection of software platforms and browsers. This selection is what is deemed by Software Project Manager/Client to be representative of the use cases and contemporary technology relevant to the project since platform and browser exhaustive testing is not practicable.  

   6. All software releases will follow HIC change management processes, which include a risk assessment. 

   7. The security of the system will also be tested, either automatically or 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. 

   8. Clients will perform User Acceptance Testing in the Staging Environment. Test reports will be collected and fed back into the development process for fault fixing. 

   9. Given the intrinsically insecure nature of the Development and Staging Environments, the Development Team and the Client testing the application will avoid using any personal 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. 

5. Release Software

   1. Software releases follow the HIC Change Management Process logged in the PM System. Each new version released will be recorded along with its major changes and version number.  

   2. Customer approval to release will be recorded in PM system, unless internal bug fix has been identified and an urgent release is required.

   3. All releases will be validated by Process Manager or another Software Project Manager within the Development Team.

6. Support 

   1. Clients will alert HIC of potential issues via the support desk or via direct contact with the Software Project Manager.

   2. Change Requests will follow HIC Change Management Processes

7. Quality Control

   1. During development, coding standards and best practices will be followed.

   2. Branch protection must be in place to avoid inappropriate changes to Staging/Production Environments

   3. Only Software Project Managers are permitted to deploy to Staging/Production Environments

   4. Access to Staging and Production Environments is granted and reviewed by the Process Manager.

8. Open-Source

   1. For Open-Source code contributions (e.g. pull requests) coming into a software repository which is managed by HIC must be reviewed before merging by the Process Manager.  Code contributions must follow the Coding Standards of the FOSS repository to which code is contributed (which may be different from the HIC Coding Standards Document).  

   2. Code contributions to Open-Source repositories maintained by HIC can come from any developer in the world via the pull request / fork system.  These will be evaluated by the open-source Process Manager before being merged. Software Project Managers of Open Source Projects would follow the HIC Change Management Process. This is designed to only be used in cases where immediate organisational damage could occur, such as a severe security issue or accidental release of dangerous changes.

   3. FOSS code repositories can include their own project management system that may be outside of HIC’s control. 

APPLICABLE REFERENCES

• Change Management  

• For Definitions see ISMS Glossary

• HIC Coding Standards Document

DOCUMENT CONTROLS