> The 13485 requires you to specify "Design Phases". Here are some suggestions which you could use.
| Title | Date | Description |
|----------------|------|-------------|
| Specification | | |
| Implementation | | |
| Testing | | |
| Validation | | |
| Release | | |
## 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 ([semver.org](https://semver.org)) 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.
## 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:*
* *Code fulfils the software requirements*
* *Adherence to [PEP8 Style Guide](https://www.python.org/dev/peps/pep-0008/)*
## 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 [openregulatory.com](https://openregulatory.com). See [template
