CMMI 软件问题解决过程实践说明
软件问题解决过程在CMMI没有单独讲解，大家可以去查阅CMMI技术解决方案（technical solution）和产品集成（product integration）中的细节性内容，这里不做赘述。

YY/T0664 软件问题解决过程要求

9.1 编写问题报告

编写问题报告就理解为记录缺陷即可，关于缺陷管理建议用缺陷管理工具，不要用Excel记录。本节从字面上看仅要求3点：1严重性，2有助于解决问题其他信息、3包含内部和外部问题。建议缺陷记录要包含这些要素：问题描述（含现象证据，如截图，日志等）、预期正确现象、问题复现步骤（含输入数据）、问题发现环境、问题发现版本、问题质量特性（功能性、性能效率、兼容性、易用性、可靠性、信息/网络安全性、维护性、可移植性）、问题严重性（最好跟风险的严重性保持一致）、问题发现人、问题发现时间等。为什么要记录这么多要素呢，合规角度满足“有助于解决问题的其他信息”。从公司知识积累角度，便于后续总结问题，执行改进。

9.2 调查问题

调查问题跟我们日常调查问题一样，找原因、找影响范围、找解决方案。原因最好以引入原因（“用户需求、软件需求、架构设计、详细设计、编码、配置）分类，这样有助于解决问题和后续改进。

9.3 通知相关方

通知相关方不需要多解释，大家都懂，唯一提醒一点要根据实际情况通知监管部门。

9.4 使用变更控制过程

解决方案可能会涉及改现有的设计，虽然要求上说要按照8.2控制变更实施修改，并不是说一定要像管理基线变更那样，重新提变更申请。而是要制定一个缺陷管理流程，按照缺陷管理流程处理就可以了。

9.5 保持记录

如果我们用了缺陷管理工具，同时又按照缺陷管理流程执行缺陷处理，缺陷管理本身是符合的要求的。但是要提醒一点，缺陷处理不是一个孤立的过程，可能涉及多个过程，各过程的记录都要按照各过程要求进行保留，例如代码更新要按照代码管理要求保留记录、文档更新要按照文档要求保留记录、采购就遵循采购流程记录要求。

9.7 分析问题的趋势

一般缺陷管理工具会自动形成实时报告，作为质量人员要根据报告及时预警质量风险，并不一定要写各种分析报告。

9.8 验证软件问题的解决

这里强调缺陷修复要彻底，不要引入新缺陷，不能越修缺陷越多。

9.9 测试文档的内容

这里说了很多，其实就是2个内容，1对缺陷修复验证要保留记录，2如果需要回归测，回归测试也要保留记录。