STANDARD OPERATING PROCEDURE

Document Title Document Description Version No.

SOP-32 Configuration Management 0

1. PURPOSE
The purpose of this procedure is to define the configuration management process.

2. SCOPE
This procedure applies to items, parts, subassemblies, system assemblies, and products.

3. RESPONSIBILITIES
Development Lead / • Identifies the baseline and assigns the version number of the new
Configuration Manager release.
• Manages source code control, branching, performing official builds, and
identifies the unique identification for the software build.
• Manages the hardware related artifacts.
Software Developers • Follows the procedures outlined for software changes and builds.
System Engineer • Ensures the items, parts, subassemblies, system assemblies, and
products are created.
QA/RA Lead • Approves items, parts, subassemblies, system assemblies, and
products.
• Assesses changes for impact on regulatory filings.
System Lead/ Product • Defines BOM with items, parts, subassemblies, system assemblies and
Development Manager products.
• Ensures items, parts, subassemblies, system assemblies, and products
are approved and released.
CCB (Change Control • Reviews all change requests, its impact, and takes decisions on
Board) implementation of the change.
• Verifies final change implementation and approves the change for
Release in the Market.

4. DEFINITIONS

Configuration Item Item or aggregation of hardware, software, or documentation, that is

designated for configuration management and treated as a single entity in
the configuration management process.
Configuration Defines the schemes and versions of the configuration items, controls the
Management modifications and release of the configuration items, and controls the
Process documentation.

5. RECORDS
The records pertaining to this procedure include the Configuration Item List and is controlled in the
electronic Quality Management System.

6. FORMS
6.1. FRM-32-01; Configuration Item List

7. REFERENCES
7.1. WI-01; Document Creation and Change Management
7.2. FRM-03-01; Project Plan
7.3. FRM-31-01; SOUP List

Chorus Confidential
Printed copies are uncontrolled and for reference only
Page 1 of 6
 STANDARD OPERATING PROCEDURE
Document Title Document Description Version No.
SOP-32 Configuration Management 0

8. PROCEDURE
8.1. Configuration Management Process
8.1.1. The configuration management process provides the ability to rebuild and recreate
historical releases including recreating a software item, identifying its parts, and
documenting the history of changes.
8.2. Configuration Identification
8.2.1. General
8.2.1.1. Configuration items defined in Table 1 will be aggregated and compiled from
different sub-items. A scheme will be adopted to identify each configuration item
with a unique identifier and their versions to be controlled for the project. This
includes other software products or entities such as SOUP or any piece of
information needed to create the deliverable including documentation.

Table 1: Configuration Items

Category Description Identification
Documentation Including but limited to: Project Plans, Documentation is identified per
Design Documents, Release Notes, WI-01 Document Creation and
User Manuals, Labeling, Security Change Management
Documentation
Requirements System and subsystem requirements Requirements are identified with
a unique ID in eQMS for system
requirements and Project
Management Software for
subsystem requirements
Verification Test cases and test results Test cases are results are
identified with a unique ID in
Project Management Software
Cloud, Firmware, and Source code Branching and versioning in
Applications Source Code Repository as
described in this SOP
Test Automation Scripts Source code, build outputs and reports, Branching and versioning in
defects Source Code Repository and
Project Management Software
as described in this SOP
CI/CD Build outputs and CI/CD pipeline Branch and versioning as
reports described in this SOP
SOUP/OTS SOUP, Operating Systems, Libraries, SOUP/OTS is identified per
Drivers, Image Files, etc. SOP-31 SOUP/OTS

Tools Software used to create/build, test, Tools are identified per SOP-16
calibrate, or program a device Validation

8.2.1.2. After configuration data has been aggregated and organized a baseline will be
established. A baseline configuration is a known state of configuration that will
successfully operate the dependent software without error. This baseline will be
created by reviewing the configuration of a functioning production environment
and committing those configuration settings as “baseline configuration”.
8.2.1.3. The Project Plan (FRM-03-01) includes a Software Configuration Plan section
that will define project specific details.
Chorus Confidential
Printed copies are uncontrolled and for reference only
Page 2 of 6
 STANDARD OPERATING PROCEDURE
Document Title Document Description Version No.
SOP-32 Configuration Management 0

8.2.1.4. The Configuration Item List (FRM-32-01) defines the classes, types, categories,
or list of items to be version controlled (code, build, files, etc.) for the specific
project.
8.2.1.5. The Configuration Item List (FRM-32-01) is created for each release in QA,
Staging, and Production environment.
8.2.2. Part Numbers and Revisions
8.2.2.1. Items, parts, subassemblies, system assemblies, and products require a part
number and revision.
8.2.2.2. Part Numbers will be assigned a six-digit part number in the format of XX-XXXX
based on the following:
• The two-digit prefix represents the type of part and is assigned according
to the table below.
• The four-digit suffix is assigned in sequential order.

Prefix Part Type

PA Part
SA Subassemblies/Subsystem
MA Main Assembly/ product /system

8.2.2.3. Revision Levels of BOM items are numeric characters. For example, PA-1000.1.
8.2.3. Software Versioning and Baselining
8.2.3.1. Software versioning uses the following format x.y.z(D) where:
• x = Major version number. Updated for major release with major new
features.
• y = Minor version number. Backwards compatible inside the same major
version, but with feature enhancements and/or bugfixes.
• z = Patch version number. For hotfixes, backwards compatible inside major
version, no new features.
• D = Build number used for internal tracking and verification of software
build process. Not visible to customers as part of software version number.
8.2.3.2. Software build identification
All official builds (release builds) will be identified using a scheme that will allow
all the controlled inputs to the build to be extracted from the source code control
system so that the build may be reproduced.
8.2.3.3. Release naming appends a sequentially generated build number.
8.2.3.4. The baseline will be managed by using tags / labeling.
8.2.4. Source Code Control
8.2.4.1. Manage source files necessary for performing a build of the software product.
8.2.4.2. In some cases, to manage software or data files used for unit tests of the product
software.
8.2.4.3. Track changes to the software and related filed and assist in controlling changes.
8.2.4.4. On occasion, it may be necessary to create a branch from a software baseline.
The source code control software shall support branching and provide tools to
aid in applying changes to multiple branches of the software. A branch implies
two or more instances of the source code are being maintained.

Chorus Confidential
Printed copies are uncontrolled and for reference only
Page 3 of 6
 STANDARD OPERATING PROCEDURE
Document Title Document Description Version No.
SOP-32 Configuration Management 0

8.2.5. Branching and Merging

8.2.5.1. The branching model adopted by Chorus helps in maintaining a clean and
organized project history, facilitates collaboration among team members, and
ensures a stable production environment. It provides a systematic approach to
managing different types of changes in a project and helps in reducing conflicts
and issues during the development process.
8.2.5.2. Developers work on features/bugfix in their respective feature/bugfix branches,
periodically merging changes from the Development branch to stay up-to-date.
8.2.5.3. When a feature is complete, or a defect fixed it's merged back into the
Development branch.
8.2.5.4. When a set of features and/or bugfixes is/are ready for release, a pull request is
raised from the Development branch and merged/promoted to the next
environment-specific release branch. There is one(1) release branch per
environment.
8.2.5.5. Hotfixes - Hotfix branches are used to address critical issues mostly in the
Master branch or in some cases also in the Release branches. Once a hotfix is
complete, it's merged back into its parent branch and Develop. Regularly
merging changes from Master into Develop ensures that ongoing development
incorporates the latest stable changes.
8.2.5.6. The branch naming convention is as follows:
• Developer Branches
o Feature: feature/<team>/<username>/<JIRA ID>/<short desc of
feature>
o Bugfix: bugfix /<team >/<username>/<short desc of bugfix>
• Environment-specific Release branches
o Development: develop
o QA: qa
o Labs: labs
o SIT: sit
o Staging (pre-prod/uat): staging
o Production (main): master
• Hotfix branches
o Hotfix: hotfix/<team>/<username>/<short desc of hotfix>
8.3. Change Control
8.3.1. General
8.3.1.1. All changes in baselined versions of configuration items are managed through
the change control process defined in WI-01 Document Creation and Change
Management and are controlled by the Change Control Board (CCB).
8.3.1.2. The CCB reviews all change requests, its impact, and takes decisions on
implementation of the change.
8.3.1.3. The final change implementation is verified by the CCB and approved for
Release in the Market.
8.3.2. Software Changes
8.3.2.1. Software developers shall check-in their software changes according to the
release plans stated in the change request.
8.3.2.2. All changes to software are traceable to change requests / issue entered in the
Project Management Software. Traceability between software changes and the
issue that authorized the change must be available.

Chorus Confidential
Printed copies are uncontrolled and for reference only
Page 4 of 6
 STANDARD OPERATING PROCEDURE
Document Title Document Description Version No.
SOP-32 Configuration Management 0

8.3.2.3. The release builds are released for distribution through the CI/CD pipelines for
the entire Chorus software.
8.4. Software Build Process
8.4.1. Applications and Firmware: CI/CD pipeline scripts are used to build the application and
firmware resources.
8.4.1.1. The source code is committed/stored in a dedicated repository.
8.4.1.2. The source code is version controlled which allows tracking of changes,
collaboration, and maintaining a history of changes.
8.4.1.3. CI/CD tools and platforms are used to interpret and execute the CI/CD pipeline
scripts. The tools automate the process of building the source code in the
required build environment and making the build artifact (Application or
Firmware) ready-for-deployment.
8.4.1.4. The Mobile Application is deployed on digital distribution services and then made
available to the end-users for over-the-air updates using push notifications.
8.4.1.5. The Firmware is deployed on an Artifact store on the cloud and made available
for over-the-air updates to the devices using push notifications to the Apps.
8.4.1.6. The Web Application is deployed on the Cloud Web Servers as a part of CI/CD.
8.4.2. Cloud: Infrastructure as code (IaC) will be used to build cloud resources.
8.4.2.1. Code is written to define the infrastructure components and stored in the source
code repository/version control system.
8.4.2.2. Cloud infrastructure code is version control which allows tracking of changes,
collaboration, and maintaining a history of changes.
8.4.2.3. IaC tools and platforms are used to interpret and execute the infrastructure code.
8.4.2.4. The IaC code is executed which instructs the cloud platform to create and
configure the specified resources.
8.4.3. Promotion states:
• Development – Builds in the Development state have not been tested beyond a basic
sanity test or automated regression test and are used by development for testing
defect resolution and feature enhancement.
• QA – Dev build promoted to QA for verification by QA team.
• LABS – Build verified by QA is promoted to the LABS. Currently this environment is
used for Research and Development/field purposes.
• SIT – If tests pass QA and Security, build promoted to SIT environment for System
Integration Testing (SIT).
• Staging – Release deployed into Pre-Production environment for User Acceptance
Testing (UAT). This environment closely resembles the production environment.
• Production – Final release is made available to customers.
8.4.4. The last healthy build can be manually pulled and deployed in a Production environment in
case rollback is needed.
8.4.5. In the case of hotfixes, the code changes are merged from the Hotfix branch to Main
branch if Unit Tests/Security scan pass on the build.
8.4.6. Official builds include software and release builds.
• Software builds are done on a milestone/release level.
• Release builds would be for major and minor releases and patch fixes. Only builds
that are commercially released should exist in the Production state.
• Release Notes are maintained for QA, SIT, Staging, and Production environments.

Chorus Confidential
Printed copies are uncontrolled and for reference only
Page 5 of 6
 STANDARD OPERATING PROCEDURE
Document Title Document Description Version No.
SOP-32 Configuration Management 0

8.5. Configuration Status and Auditing

8.5.1. The history of change requests, pull requests, and configuration items are maintained in the
Configuration Management systems (source code control and document management
system) and will be traceable for audit purposes.

9. REVISION HISTORY

Version Description
0 Initial version of document

Chorus Confidential
Printed copies are uncontrolled and for reference only
Page 6 of 6