Skip to content

Revision History

Rev. no. Description Author(s) Reviewers Date (Persian) Authors' Signature Reviewers' Signature
1. Initial Document Creation [Your Name] [Reviewers' Name] [Current Date in Persian Calendar]

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, 8
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 HAD client application has been established as class B per IEC 62304:2006/AMD1:2015 based on the decision-making process outlined in table 3 and in paragraph 4.3 of the norm. A malfunction of, or latent design flaw in the software device may lead to situations with unacceptable risks [for example: false-positive and false-negative diagnosis, resulting in unnecessary interventions or missed necessary interventions]. This excludes software safety class A. Serious injuries or death, however, can be ruled out because the app is a client application that provides a user interface for controlling the HAD device and displaying data. Any malfunction of the app is detectable and correctable by the user, and the HAD device has its own independent safety mechanisms to prevent hazardous situations. The app itself does not directly perform any life-critical functions or control a life-supporting device. Considering these risk control measures external to the software system, safety class C can be ruled out, resulting in class B.

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 24 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 Validation Activities

Validation is carried out as formative and summative usability evaluation as described in the software development process. A usability evaluation file (plan, protocol and report) will be prepared.

10 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.