Don't know where to start? Watch our free starter videos and save lots of time and consultant fees

Templates IEC 62304 Templates

Updated July 26, 2023

Template: Software Development and Maintenance Plan

Dr. Oliver Eidel

Template Download

This is a free template, provided by OpenRegulatory.

If you are a user of Formwork, our eQMS software, choose "QMS" on the top menu and "OpenRegulatory Templates" on the left menu, and then open the relevant folder to find this template ready to load into Formwork.

If, for some mysterious reason, you're using a different QMS Software, you can also simply download this template - specifically, as Word (.docx), PDF, Google Docs or Markdown file. Scroll down for a preview!

The template license applies (don't remove the copyright at the bottom).

Download as Word File


Download as PDF


Copy-paste to Google Docs


Download as Markdown


Tired of copy-pasting? If you want to save time and edit these templates directly, you can use Formwork, our eQMS software. And if you're looking for step-by-step instructions for filling them out, check out our Wizard :)

Don't Miss Updates to This Template

Subscribe to our newsletter and we'll keep you posted on which templates we've changed.

Questions? Still Lost in Regulation?

Good news! Our goal is to provide lots of stuff for free, but we also offer consulting if you need a more hands-on approach. We get stuff done really fast. Have a look!

Related Documents

The following templates are Documents or SOPs related to this template. That means that they mention this template somewhere and (most likely) contain instructions on how and when to fill it out.

Template preview

Software Development and Maintenance Plan

This document is related to your product. You somehow need to associate it with it. The easiest way would be to just put all product-related documents into a folder in your QMS so that the association is clear. Alternatively, you could mention the related product and version here, but then you’d have to update the version here any time you do a new release. Painful!

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

1 Relevant Processes and Documents

Please see the relevant processes for the following activities:

2. Required Resources

2.1 Team

Role Count Responsibilities
Head of Development 1 Prioritizing tasks and technical oversight
Frontend Developer 2 Implementing Frontend Software Requirements
Backend Developer 1 Implementing Backend Software Requirements

2.2 Software

Describe your device’s software safety class according to IEC 62304 and your reasoning behind the classification.

Programming Languages

List the languages you’ll be using, including compiler and language versions.

Name Version
Python 3.8

Development Software

List software used to support development, e.g., IDEs.

Name Version
PyCharm 2020.1.4

2.3 System Requirement / Target Runtime

List your target runtime(s).

Name Version
CPython 3.8

Specify system requirements, e.g., the minimum specifications of the server / compute instance you’ll be running your software on

Minimum system requirements:

3 Design Phases

The 13485 requires you to specify “Design Phases”. Here are some suggestions which you could use.

Title Estimated Completion Date Description Review method
Specification     Software Requirements Checklist
Implementation     Code Reviews
Testing     System Test
Validation     Usability Evaluation
Release     Release Checklist

4 Avoiding Common Software Defects Based on Selected Programming Technology

Discuss how your selected programming technology may introduce risks and how you plan to avoid them. With modern, dynamically-typed languages, an obvious risk is that you encounter runtime exceptions. So you could argue that your test coverage is great and compensates for that. You could also link to your risk analysis here if you analyse those risks further.

5 Configuration Management and Version Control

Describe which version control software you’re using (probably git, like all human beings on this planet right now, except enterprise developers). Also describe your branching model, i.e., how your developers create branches during development, how you name them and how you merge them (pull requests? merge commits? squash before?). Your code review will be described in the next section.

Importantly, describe which things (code, build files, etc.) are put in version control. Describe how you name versions and how you tag them. Your goal should be that you can retrieve an old version and build it. Why? Something with a newer version may go wrong (harm patients) and you may need to roll back.

git is used as version control software. All source code and build files are committed to version control.

When implementing software requirements, developers create a new branch starting at master. During development, developers may create intermediate commits on this development branch.

When implementation is completed, a new merge commit to master is created.

This is also the activity which constitutes integration of software units.

For each release, the goal is to be able to uniquely identify it and retrieve all relevant files (code, configuration files like build scripts, SOUPs, etc.) at any time in the future.

When a new software version is released, its commit is tagged in git. The tag is constructed by adhering to semver ( 2.0.0 which results in a version of format MAJOR.MINOR.PATCH, e.g., 1.0.0.

6 Documentation Activities

Describe your policy on what should be documented while you develop software. Maybe you want to require your developers to document all methods which are private. Maybe you want to keep an up-to-date software architecture diagram in the repository, etc. Make sure to mention how traceability between Software Requirements and Tests is maintained.

7 Implementation Verification Activities

Describe verification activities, e.g. code review.

For each pull request, a code review is performed by a team member who was not the main author of the code under review. The code review is only marked as “approved” if the code complies with the code review criteria. This is:

8 Software System Test Activities

Describe software system test activities. This could be continuous integration which is triggered by opening a pull request (e.g. Travis CI, Circle CI). Describe what is tested and how that automated system works.

Integration tests are included in software system tests.

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

Describe how often you check SOUP issue trackers and how you document them.

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

Template Copyright See template license.

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

No QMS on this planet will save you from creating crappy software.