MAN-02 Software Release Process
Manual for the software release process using Ketryx Lifecycle Management
Last updated
Was this helpful?
Manual for the software release process using Ketryx Lifecycle Management
Last updated
Was this helpful?
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.
This document defines tasks, activities, procedures, resources, responsibilities, and deliverables related to software releases of the Product.
This plan was developed to support the creation, release, and maintenance of the Product.
This plan was developed in compliance with ISO 13485, IEC 62304, ISO 14971, and 21 CFR Part 820.
Tools used to develop and release a product with Ketryx Lifecycle Management are provided in .
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.
To release a new version of the Product to the production environment, the following activities are performed.
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.
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.
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.
Once a final Release Candidate is deployed, formal Verification & Validation (V&V) is started.
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.
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.
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
If any release documents need customizations, they are downloaded, edited, and uploaded to the Ketryx EDMS.
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.
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.
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 , , ).
See also .
Test Executions for all Test Cases contained in the Test Plan are created and executed as per the Work Instruction .
Anomalies found during V&V are reported as per Work Instruction .
More details on how to use the Traceability page can be found in .
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 page with the Omitted documents field under Document configuration.
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 for the dependencies in a release, mark the monitoring option as active on the corresponding settings page, as described in .
