我将自己曾建立的关于系统和软件开发过程的模板汇总于此。并且已根据软件开发过程中涉及主要活动进行了如下归类:
系统需求分析,
系统架构与系统接口设计，
软件需求分析,
软件体系结构和软件接口设计;
软件详细设计,
编码，编码，编码，再编码，
单元测试和软件组件测试，
软件集成和测试用例，
系统集成与测试用例，
交付,
系统验证
2015年7月更新:本人博客该篇末尾已添加软件QMS工具和生产设备软件的验证模板(详见原文阅读连接)。
软件开发过程模板
相关阶段
最简化阶段:系统和软件为一体化设计。架构、界面和详细设计合并在一个阶段。测试也减少到一个阶段。
规范 (系统和软件需求分析);
设计(架构、接口和详细设计),
编码，编码，编码，再编码，
测试 (单元测试、集成测试、验证测试)
交付,验证。
管理
适用于简单项目的话，可以将所有关于项目管理和支持活动的内容都保存记录在一个文档中。
项目管理计划是描述管理和支持活动的中心文档，特别是文档和软件配置。
风险管理计划仍然需要，它包含了风险管理活动。不要跳过该活动，这是你遵循ISO 14971的重要证明。
软件开发工具验证计划是一个可选项，在必要时，它是您进行验证软件开发工具活动的相关要素。
规范
系统和软件规范合并在一个阶段。
软件需求规格说明是这个阶段的中心文档，其包含可用性规格和风险分析的有关结果。
软件测试计划是唯一的测试计划，由软件需求规格说明的需求派生而来。
设计
将架构设计与详细设计合并为一个阶段。
软件详细设计是这一阶段的中心文档。它包含体系架构定义、接口定义和组件描述。
如果架构结构是您的项目真正关心的问题 (例如，它降低了风险)，您可以在系统体系结构文档中描述该架构结构。
编码和单元测试
这里没有变化，如果你能减少编码阶段，召唤我吧，Houdini!
测试
软件测试和系统测试可以精简到一个阶段，软件测试计划是这个阶段的中心文档，并验证软件需求规格说明的相关内容。测试结果收集在软件测试报告中。
交付
对于整个系统/软件而言，只有一个版本交付描述，以及包含安装和维护章节的用户手册。本阶段的中心文件是版本交付描述和用户手册(或使用说明)，
模板
有关简单项目的模板有:
项目管理计划
风险管理计划
软件需求规格
可用性规范文件-编辑2018:弃用，使用可用性工程文件
可用性工程文件
可用性总结性评价
风险分析报告
系统架构文档
软件详细设计
软件测试计划
软件测试说明
软件测试报告
版本描述文件
用户指南
验证确认转移评审
您可以用以下方法扩展项目管理计划:
软件开发计划,
软件配置管理计划
软件开发工具验证计划。
除此之外，还有网络安全管理:
安全风险管理计划模板，
安全风险评估模板模板。
一体化模板-更简单
如果您的软件非常小，并且风险级别非常低，那么我建议您将它记录在一个单独的文档中。
一些审评员可能不会认同这种操作。但是，如果你知道自己正在做什么，且如果:
该软件具有最低的风险(eg.,Class I for FDA, CE Mark or Canada, Class A for IEC 62304)，
它只有一个或两个用例/功能，
软件开发的时间(不是编码阶段，而是从开始到交付的整个项目)不到6个月，
软件团队的规模最多为2人。
模板
一体化的简单软件开发模板(详见原文阅读链接)。
翻译事宜：
感谢Valentin Valchev的贡献，我们现在把“一体化”模板翻译成保加利亚语:
一体化的简单软件开发模板(保加利亚语);(详见原文阅读链接)。
感谢Pablo Ojeda的贡献，我们现在有了翻译成西班牙语的一体化模板:一体化的简单软件开发模板(西班牙语)(详见原文阅读链接)。
我邀请您将一体化模板翻译成您的母语(这是下载最多的模板)，我会在这里添加您的贡献。
标准开发过程的说明
我所说的标准开发过程是基于所有关于医疗器械软件的文献中发现最多的有关开发过程。在IEC标准或FDA指南中，例如，它也被称为Waterfall process。下面的这些模板最适合这个过程。但它们可能被用于近期(或最火热)的过程，如敏捷方法。下面是这些模板中的原则或逻辑。
可追溯性原则
所有这些模板中的主要原则是每个文档之间数据的可追溯性。从最顶层的数据:用户需求到最底层的数据:概念单元和测试。大多数文档最后都有追溯表。这些追溯表是强制性的，你必须填充它们来构建软件的可追溯网络。这里有一个追溯网络的例子。
通过测试来验证一切的原则
软件开发是与风险分析并行进行的，如果必要的话，还与人为因素工程并行进行。风险和人为因素分析能给出缓解措施，这些措施是软件开发的输入。这些输入在所有软件开发过程中被跟踪到软件测试，软件测试位于可跟踪网络的末端。通过所有测试后，可断言每一个输入，从用户需求，风险分析和人因工程，都是经过验证的。
软件测试和系统测试用于验证需求，并通过传递性验证整个系统，如下图所示。
可追溯性验证原则
如果您很好地定义了每个输入的可跟踪性，并且在软件开发过程中编写了所有文档，那么验证就更容易了。因此，您将有所有的证据来证明用户需求、风险和人为因素在您的软件中得到了很好的实现。当然，临床方面验证仍然在软件开发过程之外。这是临床医生的工作，不是软件开发人员的工作!
软件工具验证
2015年7月更新。
设备或质量管理系统中使用的软件工具需要根据21 CFR 820.70 (i)和ISO 13485:2016 7.5.2和 4.1.6进行验证。
如下模板对于设备或质量管理系统中使用的软件工具的验证是可参考的:
验证主计划模板(详见原文阅读链接),其包含了软件验证的一般规定；
验证协议模板(详见原文阅读链接),其包含了给定系统的VMP应用；
验证报告模板(详见原文阅读链接),包含系统验证协议的结果;
最后, 验证报告(详见原文阅读链接)，它包含了系统验证的结论。
以上， Mitch于2012年1月18日星期三 发表。
