Skip to content

Company: Nikted
Document Name: Software development and maintenance plan Document Number: HAD-RPT-149-Rev1
Author: Erfan Khebrati
Date (Persian Calendar): 1404/07/02

Revision History

Rev. no. Description Author(s) Reviewers Date (Persian) Authors' Signature Reviewers' Signature
1. Add recorded development plans Erfan Khebrati Ghafar nosrati 1404/07/02

Software Development and Maintenance Plan

This document summarizes development and maintenance activities.

Mapping of Standard Requirements to Document Sections

ISO 13485:2016 Section Document Section
7.3.2 Design and Development Planning 1, 2, 3, 7
Classes IEC 62304:2006 Section Document Section
A, B, C 4.4.2 Risk Management Activities 1
A, B, C 5.1.1 a) (Processes) 1
A, B, C 5.1.1 b) (Deliverables) 1
A, B, C 5.1.1 c) (Traceability) 1
A, B, C 5.1.1 d) (Configuration and Change Management) 1, 5
A, B, C 5.1.1 e) (Problem Resolution) 1
A, B, C 5.1.2 Keep Software Development Plan Updated 1
A, B, C 5.1.3 Software Development Plan Reference to System Design and Development 2
C 5.1.4 Software Development Standards, Methods and Tools Planning 2, 4, 6, 7
B, C 5.1.5 Software Integration and Integration Test Planning 3
A, B, C 5.1.6 Software Verification Planning 7
A, B, C 5.1.7 Software Risk Management Planning 1
A, B, C 5.1.8 Documentation Planning 6
A, B, C 5.1.9 Software Configuration Management Planning 5
B, C 5.1.10 Supporting Items to be Controlled 5
B, C 5.1.11 Software Configuration Item Control Before Verification 5
B, C 5.1.12 Identification and Avoidance of Common Software Defects 4
A, B, C 6.1 Software Maintenance Plan. 10

1 Relevant Processes and Documents

Please see the relevant processes for the following activities:

2. Required Resources

2.1 Team

Role Count Responsibilities
Product Owner 1 Task prioritization, technical oversight, and participates in code reviews.
Android Developer 2 Implements software requirements for the Android application.

2.2 Software

IEC 62304 Software Safety Classification

The software safety classification for the Hearing Aid Device (HAD) client application has been established as Class A per IEC 62304:2006+A1:2015, based on the decision-making process outlined in paragraph 4.3 of the standard.

Reasoning:

The software is a client application that provides a user interface for controlling a HAD. Its functions are limited to volume adjustment, working mode selection (e.g., indoor, outdoor, music), and mute/unmute functionality. A failure of the software cannot directly lead to injury or damage to health.

According to IEC 62304, clause 4.3, a software system can be classified as Class A if any hazardous situation to which it can contribute does not result in an unacceptable risk after consideration of risk control measures external to the software system.

In this case, several external risk control measures are in place:

  • Hardware/Firmware Risk Control: The primary safety mechanism resides within the HAD itself, not the client application. The HAD's firmware and hardware are designed to enforce a safe Maximum Power Output (MPO). This is a hardware risk control measure that prevents the acoustic output from ever reaching a level that could cause harm, regardless of the commands received from the client application. The application can only request volume changes within the safe operating range already established by the HAD. This external hardware control effectively reduces the risk of even a non-serious injury to an acceptable level, allowing a reduction in classification from B to A.
  • User Detectability and Intervention: Any software malfunction, such as an unintended volume change or mute, is immediately obvious to the user. The user can take immediate corrective action by removing the hearing aid, turning it off, or using the physical controls on the device itself, thus mitigating any potential for harm.

Since any potential hazardous situation caused by a software failure is controlled by measures external to the software system (specifically, the inherent safety limits of the HAD hardware and the ability of the user to intervene), the software does not contribute to unacceptable risk. Therefore, the HAD client application falls into Software Safety Class A.

Measuring Function

The HAD client application does not include a measuring function, as described in EU Regulation 2017/45 and relevant regulatory guidance documents. The definition of MEDDEV 2.1-5 for measuring functions does not apply because the app only displays data measured and processed by the connected HAD device, and does not perform any direct measuring functions itself.

Combination With Other Products

To achieve its intended purpose, the HAD client application is intended to be used in combination with the Nikted HAD device. Specifications for compatible equipment are described in the List of Software Requirements as well as in the Instructions for Use. Relevant verification and validation tests will be added to the documentation.

Product Lifetime

The software's lifetime is established to be 5 years. This is what is expected to be the maximum time until the implementation of a significant change, by which the manufacturer is able to react to the relevant changes to the software device environment, such as SOUP changes, cybersecurity innovations, or the evolving technological or medical state of the art.

Programming Languages

Name Version
Kotlin 2.1.21

Development Software

Name Version
Android Studio 2023 - 2025

2.3 System Requirement / Target Runtime

  • Target Runtimes: Android API versions 26 to 36
  • Minimum System Requirements: Any Android device running Android version 24, with a minimum of 2GB RAM and a sufficient CPU.

3 Design Phases

Title Estimated Completion Date Description Review method
Specification Capturing user needs and translating them into user story tickets. Software Requirements Checklist
Implementation Writing and documenting source code that meets the software requirements. Code Reviews
Testing Executing unit, integration, and system tests to verify the software. System Test
Validation Usability evaluation to ensure the software meets user needs and is safe to use. Usability Evaluation
Release Finalizing documentation, creating a release build, and making it available. Release Checklist

4 Avoiding Common Software Defects Based on Selected Programming Technology

The Android runtime environment can cause application crashes due to unhandled exceptions. To mitigate this, we will develop a global top-level exception handling system to catch and log all unhandled exceptions, or alternatively, use functional error types for critical operations to ensure that errors are handled gracefully and do not lead to a crash. These mechanisms will be designed to prevent the app from entering an unknown or unsafe state and will be verified through dedicated testing.

5 Configuration Management and Version Control

Git is used as the version control software, with all source code files being committed to the company's GitLab instance. Build files, test reports, and binaries are excluded from the repository, but release binaries are stored in GitLab releases with a release draft that documents any known issues.

For each new feature or bug fix, a new branch is created from the develop branch. All changes related to a specific task are linked to a Jira ticket and are contained within a single branch. Before merging, a code review is required. All changes are squashed into a single commit and then merged into the develop branch.

Each release is uniquely identified and retrievable. When a new software version is ready for release, the final commit is tagged in Git. The tag adheres to SemVer 2.0.0, in the format MAJOR.MINOR.PATCH (e.g., 1.0.0). This ensures we can always retrieve the exact state of the source code for any given release.

We have documented workflows for Git and the release process to ensure consistency and compliance.

6 Documentation Activities

We maintain traceability between software requirements, design, and test cases through a set of linked documents. Each requirement in the Software Requirements List is linked to the relevant test cases in the Software System Test Plan and Software System Test Report.

Developers are required to document all public APIs and to update class diagrams as part of the development process. We also document our workflows for Git and the release process to ensure clear and repeatable procedures.

7 Implementation Verification Activities

For each pull request, a code review is performed by a team member who was not the main author. The pull request is only approved if the code meets our established criteria, including:

  • The code fulfills the software requirements.
  • The code adheres to our internal coding style guide for Kotlin.

We also have a robust automated testing system that includes unit, integration, and system tests, which are all executed as part of our Gradle build process.

8 Software System Test Activities

All our testing, including unit, integration, and system testing, is automated and integrated with our Gradle build system. This ensures that every new change is automatically verified against our test suite. The test runs generate reports that are used to document the successful verification of the software.

9 Maintenance Activities

SOUP issue trackers are checked at least once every 6 months. The verification date is updated in the SOUP list accordingly.

Template Copyright openregulatory.com. See template license.

Please don't remove this notice even if you've modified contents of this template.