软件验证报告模板参考.doc

xxx 软件验证报告 产品名字: 型号: 生效日期: 文件编号: : 部门: 编写: 签字: 审核： 签字: 批准： : 版本记录 文件编号 xxx 初版 1.0 2015.06.12 目录 1. 软件描述和操作需求 1 1.1 软件信息 1 1.2 软件分类 1 1.3软件的功能 1 2. 开发计划 2 2.1开发计划 2 2.2配置管理和维护 2 3. 软件需求规格 3 3.1 硬件需求 3 3.2 编程工具需求 3 3.3 软件输入输出需求 3 3.4 软件功能 3 4. 软件风险管理过程 4 4.1 软件声明周期的风险管理 4 4.2 风险分析 4 5. 软件框架设计 6 6. 功能模块详细设计 6 7. 追溯分析 7 8 测试功能模块 10 8.1 单元测试 10 8.2 集成测试和系统测试 11 9. 确认整个过程的软件需求 13 10 软件修订记录 13 11 未解决的异常 14 11.1 问题 14 11.2对设备性能的影响 14 11.3 怎样改正问题 14 12 综述 14 1. 软件描述和操作需求1.1 软件信息 版本号: 1.0 日期: 2014.08.18 1.2 软件分类 软件不直接作用，参数的时候，会导致，所以我们把软件分类为 1.3软件的功能2. 开发计划 2.1开发计划 序号 阶段 工作内容 负责人 1 软件需求规格定义客户的需求得到软件需求规格 2 评估软件需求 通过当前条件评估软件需求规格 3 软件开发计划当前条件得出软件开发计划 5 建立小组 建立负责人开发小组 6 分析软件开发风险软件开发过程中定义软件开发过程中已存在的风险，制定相应的风险控制计划和措施 7 软件的框架构想和初步定义整个框架定义全部的软件框架和软件功能模块的划分 8 功能模块详细设计设计每个功能模块的过程程序，模块做一个详细的编码调试和测试工作 9 编程 编写代码 10 功能模块的测试和调试 模块测试和调试 和硬件系统的系统测试和调试 11 软件的需求确认软件是否满足软件需要的法规 12 剩余风险的验证和分析 验证软件风险控制措施的效果剩余风险 13 软件的维护和的维护和修改和确认相关的维护和修改 14 软件的最终评估评估软件是否能满足要求和剩余风险是否可接受 2.2配置管理和维护a) 清晰定义分离模块来保证工程师可以自己的模块而不混淆b) 构造对所有团队成员可用的基本子程序组 c) 为每一次修改保持详细记录，包括，时间，原因d) 保存软件的每个版本为了保存和对比e) 保存发放的版本修改的评估。所有的文件应该记录在硬盘或者打印f) 追溯功能增强的缺陷和需求 3. 软件需求规格.1 硬件需求 MCU：STM8S105c4t6 显示屏：LCD显示 外设器件：A探头、B探头、探头连接线 IO设备：不适用 3.2 编程工具需求 编程语言: C 语言 编译器 ST Visual Develop 编程调试工具 3.3 软件输入输出需求 主程序模块：核心软件模块，负责各个外围软件模块任务调度和数据交互。 显示输出模块：外围软件模块，根据当前模式和运行状态，生成显示数据，通过显示屏进行显示。 按键输入模块：外围软件模块，根据用户的操作，识别用户的控制意图，将结果上传至主程序模块，区分短按和长按等动作。 探头模块：外围软件模块，根据按键操作，输出对应探头。 3.4 软件功能 编号 软件需求规格功能需求规格描述 3.5.1.1 系统初始化 3.5.1.2 键盘扫描 3.5.1.3 屏幕显示 3.5.1.4 A路控制输出 3.5.1.5 B路控制输出 4. 软件风险管理过程4.1 软件声明周期的风险管理产品的研究和开发过程中，最初的措施，分析有新的风险存在，的严重性和发生概率和的修改。在和开发之后，所有风险要评审来保证的风险都降低到可接受水平。安全相关的任何反馈，分析重新评审和适当的修改。小组名单 研发经理风险管理过程，评估研发过程的 项目经理风险管理过程搞笑执行，评审活动 品质部经理 临床专员临床来分析风险 总经理 风险可接受准和批准报告 法规工程师 收集最新或修订的或标准 4.2 风险分析 危害 损害 危害引起的原因 代码不能满足用户的需求预期需求分析过程中，功能的规格不完整分析后进行评审软件的需求分析规格参数确认 风险降低 代码逻辑不清晰程