ID: Lorem ipsum dolor sit amet.
This document summarizes development and maintenance activities for the software of Consectetur adipiscing elit. The software development and maintenance plan is developed according to the SOP Software Development and IEC 62304:2006 and ISO 13485:2016.
Please see the relevant processes for the following activities:
Responsibilities are generally described for each functional group below related to the software development and maintenance process.
An overview of the software system as well as the software items that make it up are found in the Software Architecture document.
The software requirements are synonymous with subsystem requirements can include the following content as applicable:
All of these requirements may not be available at the beginning of the software development process and the software requirements list can be updated as the software undergoes normal developmental processes according to SOP Software Development and this plan. Software requirements will be traced through the testing verification and validation process to ensure that they have been met.
Design stages are described in the SOP Software Development. The documents and review criteria required for each stage are provided in the sections below.
Activities:
Deliverables:
Activities:
Deliverables:
Activities:
Deliverables
Activities:
Deliverables:
Activities:
Deliverables:
Software development is controlled through versioning and branching in Sed do eiusmod tempor incididunt.
Software versions are named according to Semantic Versioning (SemVer), in a format: MAJOR.MINOR.PATCH. Significant changes may lead to a change of UDI-DI given the significant change in device functionality, while non-significant changes lead to minor version changes and changes of the UDI-PI only (See SOP Certification and Registration). Patches can result from bug fixes (see SOP Change Management). Examples are provided below for an example software version 101.2.3. Software documentation is maintained according to SOP Software Development and SOP Document and Record Control.
A major change is a change to software that may significantly impact on the function or safety of the device.
Major changes to the software version may include the following changes as needed:
Example version change after major change: Version 101.2.3 -> Version 102.0.0
Changes to software that may have a potential impact the function or safety of the device.
Minor changes to the software version may include the following changes as needed:
Example version change after minor change: Version 101.2.3 -> Version 101.3.0
A patch will include changes that likely have a negligible impact on product function and safety and include bug fixes.
Patch changes to the software version may include the following changes as needed:
Example version change after patch change: Version 101.2.3 -> Version 101.2.4
To ensure compliance with IEC 62304:2006 using Sed do eiusmod tempor incididunt., the following processes are implemented.
An example schematic for how this could be implemented can be viewed below.
Once a release has been finalized and has undergone all required steps according to SOP Software Release and this Development and Maintenance Plan, the release branch is merged into the main branch. The commit on the main branch is then tagged with a version number following Semantic Versioning (SemVer) principles.
All changes, including new features, bug fixes, and patches, are documented in the software release notes. This documentation is part of the software configuration management records. Any changes to the software are managed through a formal change control process (SOP Change Management), ensuring traceability and justification for each change.
If there are multiple repositories the requirements for version control and software development and release described in this plan are identical across all repositories. Each repository (if applicable), including all branches and tags, is regularly backed up to ensure that the software configuration can be recovered in case of data loss. All versions of previous branches are archived within Sed do eiusmod tempor incididunt.
Software verification will occur during the development stages and prior to the merging of any feature, bugfix, or development branch. Verification activities will be captured within Sed do eiusmod tempor incididunt.
Verification of software items and software unit testing will take place as a code review. Code review will be performed by a team member who is not the primary author of the code. Code review will be performed and marked as approved if the code complies with the following criteria:
Code reviewer names, date of code review, and determination of whether the code was acceptable will be maintained within the Sed do eiusmod tempor incididunt.
Software integration testing and system software testing will be performed simultaneously according to the software system test plan and report. This will occur during Stage 3 (See Section 5.3). The software system testing will verify the software / subsysten requirements in the current software version to prepare it for release and ensure that all software requirements were met.
Additionally, for each pull request, automated software integration testing can be performed and can be considered as part of the code review process wherein the testing results can be considered acceptable or unacceptable by the judgment of the code reviewer. This is captured during the normal code review process in Section 7.1.
The software system testing will verify the software requirements in the current software version to prepare it for release and ensure that all software requirements were met. The software system test activities are performed during Stage 3 (See Section 5.3) and are captured in the software system test plan and report.
SOUP includes software items already developed and generally available and that have not been developed for the purpose of being incorporated into the medical device or software previously developed for which the adequate records of the development processes are not available.
SOUP will be classified into one of three risk classes:
Information provided regarding the SOUP list complies with IEC 62304:2006 requirements. SOUP items will be maintained in the SOUP List. SOUP is evaluated using a risk-based approach according to their risk classification.
SOUP performance will be evaluated as part of normal verification and validation procedures identified in this plan. SOUP items will be considered alongside software units developed by the manufacturer during unit testing, integration, usability testing, software system testing, and/or regression testing, as needed.
SOUP items should be reviewed for known anomalies that may arise during use of the SOUP. Evaluation of known SOUP anomalies prior to use and at recurring times throughout the life of the software product will occur based on the risk assigned to the SOUP item.
Low Risk SOUP
Low risk SOUP item anomalies can be evaluated at the time of first adding the SOUP item to the SOUP list. Known anomalies should be investigated proportional to the importance of the SOUP to software functionality and safety. SOUPs that have no impact on product performance or safety need note be investigated in depth.
Low risk SOUP items should be reviewed for new anomalies every 2 years, as needed.
Medium Risk SOUP
Medium risk SOUP item anomalies can be evaluated at the time of first adding the SOUP item to the SOUP list. Medium risk SOUP items should be reviewed for new anomalies at least annually.
High Risk SOUP
High risk SOUP item anomalies can be evaluated at the time of first adding the SOUP item to the SOUP list. High risk SOUP items should be reviewed for new anomalies at least every 6 months.
Validation of software is performed in part by the system testing which allows for validation of system integration. Additionally, the clinical evaluation and usability and human factors engineering testing provide additional validation through the Usability Evaluation Report and the Clinical Evaluation Report.
