Quality Control

PURPOSE

This document describes the quality control procedure in operation within ADP HIC to ensure compliancy with HIC Standard Operating Procedures, Procedural Documents and Work Instructions. 

SCOPE

This document is of interest to senior and auditing staff within HIC. This document provides a summary of all the relevant quality control checks that HIC Management team has to perform. 

Unless specified differently, HIC will perform quality controls every six months and the results will be made public when this is not conflicting with other policies. 

 This SOP is made available to all users and potential users of the HIC Service and will be externally visible on the public HIC website. 

RESPONSIBILITIES

PROCEDURE

Principles

1. The aim of the process is to verify both the quality and security of the code, thus ensuring that the code produced by HIC is of a high standard. Checks are performed on sample selections of code commits. Process Managers will: 

   • Check the permission settings of the Version Control System (VCS) to ensure that access is granted only to the appropriate developers. 

   • Check adherence of the code produced against the HIC Coding Standards Document.  

   • Verify that the Project Management System is linked to the VCS.

Database Quality Control Steps

1. Database quality checks are aimed at verifying the security and quality of the live production databases. 

2. Process Managers will: 

   1. Verify that access to the database is restricted to the appropriate team members. 

   2. Verify that the database structure (schema, indexes, referential integrity etc.) is intact.  

   3. Validate the database audit logs recorded on the database, where present. 

Release and Version Control Steps

1. Checks will be carried out by the Process Managers to verify that the versions of the released software, the database, the VCS and the PM System are all in sync.  

2. Releasing software is an important step that needs to be carefully controlled to:  

   1. Ensure that any faults are recorded against the appropriate version and that support requests are submitted against a particular version of the software. 

   2. Deployment locations are configured with the correct security permissions. 

   3. The version is shown on the production application and this matches correctly against the VCS and PM System. 

Document Control Steps

1. Purpose of these controls is to verify that the appropriate documentation for a service has been created and that it is kept updated and in line with the released version of the software. Documents are kept within the PM or within the VCS. 

2. The following checks will be performed: 

   1. Access to documents and audit trail of document changes will be investigated to ensure no un-authorised changes are possible or have been made. 

   2. All appropriate documents with the correct version references are present for the project. 

   3. Verify that all tests highlighted in the Test Plan, where present, have a successful report. 

Exceptions Report Steps 

1. Exceptions and failures will be reported to the Process Manager and tracked in the PM System as a separate process (see Change Management). The purpose is to remove the issue and to ensure a clearer understanding of the policies in place. 

2. The process will be considered complete once all the issues tracked in the PM system are resolved. 

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: 

Code quality control 

1. FOSS code repositories can include their own Project Management Systems that may be outwith HIC control.  VCS code contributions only need to be tied to HIC Project Management Systems where this will not be disruptive to the FOSS community / ongoing development. 

2. 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). 

3. Code contributions to FOSS repositories maintained by HIC can come from any developer in the world via the pull request / fork system.  These will be evaluated by a Senior Developer before being merged. 

Release and Version Control 

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

2. FOSS software is not deployed.  It is up to each user to configure their own deployment. 

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

APPLICABLE REFERENCES

• Change Management

• For Definitions see ISMS Glossary

DOCUMENT CONTROLS