软件风险管理报告 - 全自动化学发光免疫分析仪
NMPA 注册申报附件1，软件描述文档配套风险管理报告
项目：全自动微流控化学发光免疫分析仪（MDA-20 / SACIS C20）
方法：SEI 风险条目检查表法（类/元素/属性三层结构）
一、方法论
采用美国软件工程研究所（SEI）的风险条目检查表方法，用「类 → 元素 → 属性」三个层次描述风险列表。
评估体系：
- 定性评估：风险概率 × 风险后果 → 综合风险指数（1-20）
- 定量评估：概率（%）× 影响（%）= 风险值（%）
- 分级标准：
- 1-5：不可接受的风险
- 6-9：不希望有的风险
- 10-17：有控制的接受的风险
- 18-20：不经评审即可接受的风险
概率等级量化： 极高90% / 高70% / 中50% / 低30% / 极低10%
影响等级量化： 灾难的90% / 严重的60% / 轻度的30% / 轻微的10%
二、风险识别（四大类）
1. 周期风险（设计+编码+测试）
| 元素 | 潜在风险事件 |
|---|
| 设计性能 | 对需求理解不到位，设计出现偏差 |
| 设计功能 | 遗漏一些功能点 |
| 设计功能 | 软件功能点繁多，分类不明显不合理 |
| 设计功能 | 一些功能点设计模糊，后期编码时产生争议 |
| 编码可行性 | 现有技术不足以实现某些功能或耗时较长 |
| 编码规范化 | 编码不规范，再次查找、修改时困难，延误进度 |
| 编码可行性 | 前期数据库设计存在问题，导致数据处理出错 |
| 编码可测性 | 测试周期短，一些缺陷无法发现 |
| 测试数据 | 测试数据量偏少或偏多 |
| 测试可测性 | 测试人员对软件理解与编程人员不同步 |
2. 开发环境风险
| 元素 | 潜在风险事件 |
|---|
| 开发过程 | 不可避免的原因导致开发暂停或终止 |
| 管理过程 | 关键路径缓冲时间估计不足，导致整个项目延迟 |
3. 使用风险（系统稳定性）
| 元素 | 潜在风险事件 |
|---|
| 系统稳定性 | 极限条件下系统崩溃 |
| 系统稳定性 | 传输数据中断 |
| 系统稳定性 | 传输数据暂停 |
| 系统稳定性 | 传输数据异常 |
| 用户操作 | 用户破坏性操作 |
4. 项目限制风险
| 元素 | 潜在风险事件 |
|---|
| 资源设备 | 工作所需设备损坏，延误进度，增加成本 |
| 合同条款 | 合同条款存在漏洞 |
| 合同客户 | 客户违约，拖欠费用 |
三、TOP5 定量风险评估
| 排序 | 类别 | 风险事件 | 可能性 | 影响 | 风险值 | 原因 |
|---|
| 1 | 产品工程 | 主流技术升级，导致需求变更 | 50% | 90% | 45% | 主流技术升级，需求未能预计主要技术的更新 |
| 2 | 产品工程 | 关键路径缓冲时间估计不足，导致项目延迟 | 50% | 60% | 30% | 关键路径上功能点过于复杂，缓冲时间较短 |
| 3 | 稳定性 | 传输数据中断 | 30% | 90% | 30% | 使用者操作不当，如串口被误拔 |
| 4 | 稳定性 | 传输数据暂停 | 30% | 90% | 27% | 使用者操作不当，如窗口跌落和串口被重新连接 |
注：原文TOP5只列出了4项（第5项未显示）
四、关键风险应对措施
设计类风险
| 风险事件 | 后果 | 应急措施 | 预防措施 |
|---|
| 主流技术升级导致需求变更 | 延误进度 | 延期 | 及时更改计划 |
| 遗漏功能点 | 系统不能满足业务要求 | 追加资源 | 完善需求 |
| 功能点分类不合理 | 效率降低 | 修改设计 | 进行头脑风暴，多人确认 |
| 数据库设计问题 | 数据丢失或溢出 | 修改数据库设计 | 进行头脑风暴，多人确认 |
编码测试类风险
| 风险事件 | 后果 | 应急措施 | 预防措施 |
|---|
| 编码不规范 | 延误进度 | — | — |
| 测试周期短 | 系统不稳定 | 追加测试 | 增加测试时间 |
| 测试数据量不合理 | 系统不稳定 | 修改测试计划 | 进行头脑风暴，多人确认 |
管理类风险
| 风险事件 | 后果 | 应急措施 | 预防措施 |
|---|
| 关键路径缓冲不足 | 延误进度 | 加快现有人员工作进度 | 制定合理的时间计划 |
| 不可避免原因导致开发暂停 | 延误进度 | 无 | 无 |
使用/稳定性类风险
| 风险事件 | 后果 | 应急措施 | 预防措施 |
|---|
| 极限条件下系统崩溃 | 系统不稳定 | 无 | 对使用者提前培训 |
| 传输数据中断/暂停/异常 | 系统不稳定 | 无 | 对使用者提前培训 |
| 用户破坏性操作 | 系统不稳定 | 无 | 对使用者提前培训 |
五、风险管理验证
验收验证结论：系统的可靠性和安全性能良好。 风险计划有效地预防了部分项目风险，减少了部分风险给系统带来的影响，应急措施和预防措施颇有成效。
六、观察与思考
- 风险应对略显单薄：多项高影响风险（极限崩溃、传输中断、用户误操作）的应对措施仅为「对使用者提前培训」，缺乏技术层面的防护机制（如断点续传、异常自动恢复、操作权限分级等）。
- 方法论较标准：采用 SEI 风险条目检查表 + 定性/定量双评估，符合医疗器械软件注册申报要求。
- 与项目背景呼应：TOP5 中「传输数据中断/暂停」排名很高，反映了串口通信架构（中位机+上位机）的固有脆弱性，与液相芯片项目中串口通信协议的复杂度一致。
- 开发环境风险极低但后果灾难级：「不可避免原因导致开发暂停」概率极低但后果灾难的，综合指数12（有控制的接受），应对措施为「无」——典型的接受型风险管理策略。
相关笔记：