This document outlines the activities related to development and maintenance.
Correlation 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 Maintain Software Development Plan Updates | 1 |
| A, B, C | 5.1.3 Software Development Plan Linking to System Design and Development | 2 |
| C | 5.1.4 Software Development Standards, Methods, and Tool Planning | |
| 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 Controlled Supporting Items | 5 |
| B, C | 5.1.11 Control of Software Configuration Items Before Verification | 5 |
| B, C | 5.1.12 Identification and Prevention of Common Software Defects | 4 |
| A, B, C | 6.1 Software Maintenance Plan | 10 |
1 Relevant Processes and Documents
The following processes are relevant for these activities:
- Risk management, including SOUP risks: SOP Integrated Software Development
- Problem resolution: SOP Problem Resolution
- Software development, including deliverables, traceability, and regular updates to the software development plan: SOP Integrated Software Development
- Change management: SOP Change Management
- SOUP List
- Usability engineering: SOP Integrated Software Development
2. Required Resources
2.1 Team
| Role | Quantity | Responsibilities |
|---|---|---|
| Head of Development | 1 | Task prioritization and technical oversight |
| Frontend Developer | 2 | Implementing frontend software requirements |
| Backend Developer | 1 | Implementing backend software requirements |
2.2 Software
IEC 62304 Software Safety Classification
The software safety classification for [enter device name] has been determined as class [XXXX] according to IEC 62304:2006/AMD1:2015, based on the assessment outlined in table 3 and paragraph 4.3. A failure or hidden design issue within the software could result in scenarios posing unacceptable risks, such as false positives or negatives in diagnoses leading to unnecessary or missed interventions. This rules out software safety class A. Severe injuries or fatalities are unlikely due to [XXXX]. With risk control measures applied externally to the software system, safety class C is excluded, confirming class B.
Measuring Function
The [enter device name] does not incorporate a measuring function as defined by EU Regulation 2017/45 and related guidance documents. MEDDEV 2.1-5’s definition for measuring functions is not applicable as [XXX].
Combination With Other Products
The [enter device name] is designed to work alongside [e.g., MRI/CT scanners that generate imaging data]. Specifications for compatible equipment are outlined in the List of Software Requirements and the Instructions for Use. Relevant verification and validation tests will be included in the documentation.
Product Lifetime
The estimated software lifetime is [e.g., three years], representing the maximum duration until significant updates can be implemented. This allows the manufacturer to respond to changes in the software environment, including SOUP updates, cybersecurity advancements, and shifts in technological or medical standards.
Programming Languages
Specify the programming languages used, including versions of compilers.
| Name | Version |
|---|---|
| Python | 3.8 |
Development Software
List the development support software, such as IDEs.
| Name | Version |
|---|---|
| PyCharm | 2020.1.4 |
2.3 System Requirements / Target Runtime
List your target runtime environments.
| Name | Version |
|---|---|
| CPython | 3.8 |
Detail system specifications, such as minimum server requirements.
Minimum system requirements:
- Server-grade dual-core CPU, e.g., Intel Xeon E3-1230 v5 or superior
- 4 GB of RAM
- 1 GBit/s network bandwidth
- 20GB SSD storage
3 Design Phases
The 13485 standard necessitates outlining “Design Phases.” Suggested phases include:
| Title | Estimated Completion Date | Description | Review Method |
|---|---|---|---|
| Specification | Software Requirements Checklist | ||
| Implementation | Code Reviews | ||
| Testing | System Test | ||
| Validation | Usability Evaluation | ||
| Release | Release Checklist |
4 Preventing Common Software Defects Based on Chosen Technology
Address potential risks associated with the selected programming technology and measures for mitigation. For instance, dynamically-typed languages can result in runtime exceptions; high test coverage may compensate for this. Link to detailed risk analysis if necessary.
5 Configuration Management and Version Control
Detail the version control system in use (e.g., git) and describe your branching strategy. Mention naming conventions, merging procedures (pull requests or merge commits), and code review processes.
Git is utilized for version control. All source code and build files are committed.
Developers create a new branch from master for implementing software requirements and may create intermediate commits during development.
Once development is complete, a merge commit is created to master.
This process also represents the integration of software units.
Each release is tagged in git for traceability, using the semver (semver.org) 2.0.0 format, e.g., 1.0.0.
6 Documentation Activities
Outline the documentation policy during development. Specify whether developers must document all private methods or maintain an up-to-date software architecture diagram. Mention how traceability between Software Requirements and Tests is ensured.
7 Implementation Verification Activities
Detail verification processes, such as code reviews.
Each pull request undergoes a code review by a team member other than the main author. The review is only marked “approved” if it meets code review criteria, which include:
- Code fulfilling software requirements
- Adherence to the PEP8 Style Guide
8 Software System Test Activities
Describe system test activities, such as continuous integration triggered by pull requests (e.g., Travis CI, Circle CI). Detail the scope of tests and the operation of the automated system.
Integration tests are part of the software system testing.
9 Validation Activities
Validation includes both formative and summative usability evaluations, as outlined in the software development process. A usability evaluation document (plan, protocol, report) will be created.
10 Maintenance Activities
Describe the frequency of SOUP issue tracker checks and their documentation process.
SOUP issue trackers are reviewed at least every six months, with verification dates updated in the SOUP list.