MAN-02 Software Release Process

Manual for the software release process using Ketryx Lifecycle Management

1. Introduction

1.1. Purpose

The purpose of this manual is to define the activities that will be performed as part of the release of a product (the Product) managed with Ketryx Lifecycle Management.

1.2. Scope

This document defines tasks, activities, procedures, resources, responsibilities, and deliverables related to software releases of the Product.

1.3. Field of application

This plan was developed to support the creation, release, and maintenance of the Product.

1.4. Compliance

This plan was developed in compliance with ISO 13485, IEC 62304, ISO 14971, and 21 CFR Part 820.

1.5. Tools

Tools used to develop and release a product with Ketryx Lifecycle Management are provided in MAN-01 Ketryx Lifecycle Management.

2. Terms and definitions

For the purposes of this document, the terms and definitions given in U.S. QSR (CFR 21 Part 820), ISO 13485, and IEC 62304:2006-AMD1 apply. Where contradictory, IEC 62304 and ISO 13485 prevail.

3. Process activities

To release a new version of the Product to the production environment, the following activities are performed.

3.1. Activity 1: Design controls

All design controls relevant to the version to be released are put in a controlled state (i.e., verified and fully approved by their respective approval steps, as per the Work Instructions WI-01 Requirement, WI-02 Software Item Spec, WI-04 Test Case).

3.2. Activity 2: Risk (control) management

Given a set of risks in your project, verify that all the risks for the relevant version are acceptable and in a controlled state. If not acceptable, verify that a benefit-risk analysis has been set.

If risk controls exist, ensure that all of its controls are in a positive state, including the presence of a Test Case with a passing Test Execution.

3.3. Activity 3: Test Plan

A specific Test Plan for the version is defined and approved by the relevant approval steps. Only the default Test Plan of executing all Test Cases does not need explicit approval.

See also MAN-06 Test Management.

3.4. Activity 4: Deploying a Release Candidate

A Release Candidate (RC) is deployed to the testing environment. This is done by an R&D Lead.

The build artifacts for each Release Candidate are uploaded to the Ketryx EDMS by an R&D Lead.

3.5. Activity 5: Start of Verification and Validation (V&V)

Once a final Release Candidate is deployed, formal Verification & Validation (V&V) is started.

3.6. Activity 6: Executing tests

Test Executions for all Test Cases contained in the Test Plan are created and executed as per the Work Instruction WI-05 Test Execution.

3.7. Activity 7: Anomalies

Anomalies found during V&V are reported as per Work Instruction WI-06 Anomaly.

Non-critical Anomalies can be deferred by setting a Rationale for deferring resolution. Such deferrals and their rationale are approved collectively by the relevant approval steps of the Unresolved anomalies release document (see Activity 10 Release approval).

If critical Anomalies are found, they are fixed by code or configuration changes, resulting in a new Release Candidate. Quality Managers decide which tests need to be re-executed due to such changes. Activities 1 through 5 in this manual are re-executed as necessary.

3.8. Activity 8: Verifying traceability

The traceability of all requirements and specs to respective (passing or excluded) tests according to the test plan is verified by Quality Managers using the Traceability view for the version to be released.

Based on the configured traceability mode, the traceability matrix will enforce relevant item relations to exist (e.g. Requirement requires at least one specification, requires at least one Validation test case) and makes sure that all verification and validation tests are conducted according to the given version's test plan.

More details on how to use the Traceability page can be found in MAN-07 Traceability.

3.9. Activity 9: Generating and approving release documents

Release documents are generated for the version to be released and approved by the relevant approval groups. This includes the following deliverables:

• Authority matrix

• Change request verification report

• Change management file

• Cloud configuration report

• Code review report

• Cyber risk management file

• Problem report (Default)

• Release notes (Default)

• Risk management file (Default)

• Risk control matrix

• Risk matrix

• System architecture chart (Default)

• System requirements specification (Default)

• System design specification (Default)

• System design structure matrix

• SBoM – SOUP – software configuration report (Default)

• Training status report (Default)

• Test plan (Default)

• Testing report (Default)

• Traceability matrix (Default)

• Unresolved anomalies

Only the documents listed with the keyword default will show up in a new project. The list of release documents can be modified in a project in the Advanced settings page with the Omitted documents field under Document configuration.

If any release documents need customizations, they are downloaded, edited, and uploaded to the Ketryx EDMS.

3.10. Activity 10: Release approval

Once all design controls, dependencies, test executions, test plan, traceability matrix, release documents and optionally milestones are in a controlled state and fully approved by the relevant approval steps, the version is finally approved for release.

There shall be a release meeting with the relevant stakeholders to sign off on the release and the specific release plan for the released version and its production push.

3.11. Activity 11: Production push

The version approved for release is pushed to the production environment by an R&D Lead.

Quality Managers and Quality Control verify a successful deployment with certain tests on the production environment.

In case of an unsuccessful deployment, the deployment shall be reverted.

3.12. Activity 12: Post-marked vulnerability surveillance

As a project evolves over time, multiple iterations of the product are often released and in use in parallel. It is essential to stay informed about any vulnerabilities that could impact the released versions of your product. To receive vulnerability notifications for the dependencies in a release, mark the monitoring option as active on the corresponding settings page, as described in Monitoring.