GJB 5000B 原因分析与问题归零实践
0 引言软件产品开发过程中， 需求分析不合理、 体系结构设计不精确、 单元编码有漏洞和测试验证不充分等各种原因， 都会影响软件产品实物质量。为提升软件产品实物质量， 就要对风险问题、 评审问题、 不符合项问题和测试问题等各类问题进行原因分析。 结合监管单位软件质量管理实际情况， 本文主要阐述GJB 5000B软件3级原因分析与问题归零情况。
1 GJB 5000B原因分析标准解析
原因分析的目的是识别选定结果的原因， 并采取行动， 防止问题再次发生或确保得到正面结果 。 原因分析3级实践域共分为4个实践：
1） 选择待分析事项， 分析并确定原因；
2） 针对原因提出行动方案；
3） 确定并实施行动方案；
4） 评价实施效果并提交改进建议。 原因分析3级标准要求和主要实践活动及产品如表1所示。
GJB 5000B 3级软件原因分析的目标是： 遵循组 织 过 程 ， 分 析 根 本 原 因 ， 促 进 组 织 改 进 [ 1] 。
GJB5 000B 3级软件原因分析的总体实施要点如下： 遵循组织相关规程、 流程或准则， 明确分析事项， 进行原因分析定位， 分析结果可以是正面的也可以是负面的 （经验推广或问题）； 利益相关方尽早参与； 提出一个或多个行动方案； 要做风险评估， 有利于方案确定和开展； 行动方案应利于改进负面结果或推广正面结果； 客观评价行动计划的实施效果， 提出改进建议。
a） 选择待分析事项， 分析并确定原因
实施过程中， 需注意： 选用的数据应精确、真实、 可信； 利益相关方应尽早参与， 借助他们的经验， 能够使得对原因的分析和定位更加精准、更具实效； 细化数据的采集， 可根据项目的实际情况， 具体问题具体分析。
b） 针对原因提出行动方案
实施过程中， 需注意： 提出的行动方案， 可以是一个也可以是多个； 应该对行动方案开展估算和风险评估， 有利于方案选择和开展。
c） 确定并实施行动方案
实施过程中， 需注意： 根据决策原则， 确定行动方案， 并形成文档化记录； 行动计划应全面、细致地策划， 监控计划的实施过程， 细节决定整个计划的成效。
d） 评价实施效果并提交改进建议
实施过程中， 需注意： 如实反映已定义过程的绩效变化， 客观评价行动计划的实施效果； 切实有效地建议和记录， 提交组织资产库， 便于以后推广。
2 常见软件问题
软件产品开发过程中， 出现的任何问题， 都需要进行原因分析， 问题处理从一定角度反映了软件的质量状况和改善过程。 常见的问题有： 功能没有实现或与规格说明不一致； 不能工作 （服务器崩溃、 死机、 没反应）； 软件或代码之间不兼容； 边界条件未做处理； 界面、 消息、 提示和帮助不够准确； 屏幕显示和打印结果不正确等。 综上所述， 常见的问题处理可归纳为风险问题处理、评审缺陷问题处理、 不符合项问题处理和测试问题处理等。 对技术类质量问题， 从发现问题到整改问题再到整改验证形成闭环， 确保问题严格整改并归零 。 对功能实现类问题， 应按期完成整改或作为缺陷遗留问题； 对实际运用类问题， 应确保问题反馈与处理形成闭环。
首先是风险问题处理。 为了管理项目可能存在的风险问题， 进行项目策划时需要进行风险分析并制定风险管理计划 。 风险问题处理活动包括： 风险识别、 风险分析、 制定风险缓解措施和应急策略、 风险跟踪与管理、 更新组织级风险库。
风险问题处理流程如图1 所示。
在处理风险问题时， 需注意： 应对措施应该有针对性， 一般分为风险的缓解措施、 应急措施等行动措施； 为了减少项目管理成本， 制定风险应对措施时， 往往根据项目的实际情况确定每个风险或给予采取措施的阈值； 应适时对应对措施的效果进行分析和评估， 必要时据此调整应对措施。 风险问题需要解决及时和彻底， 避免导致个别系统问题反复出现。
其次是评审问题处理。 在项目策划期间， 需制定评审计划， 评审节点到达前， 应进行评审准备， 先进行预评审再进行正式评审， 并进行评审总结， 形成评审报告， 对评审缺陷问题进行跟踪直至闭环 。 评审缺陷问题处理流程如图2所示。
在处理评审缺陷问题时， 需注意： 逐项分析评审专家提出的问题出现的原因， 与利益相关方一起确定解决措施； 评审缺陷问题需落实解决措施并记录处理结果， 并由质量保证人员进行跟踪验证， 确保措施的有效实施。 对于设备缺陷来说，需要说明每个设备缺陷对于设备安全性、 实际应用效能和适用性等的影响。
再次是不符合项问题处理。 在软件项目过程中对过程和产品的不符合项进行识别、 确认 和处理， 以确保项目的过程质量和产品质量 。 不符合项问题处理流程如图3所示。
在处理不符合项问题时， 需注意： 与项目内相关成员沟通不符合项的解决措施和解决时限；明确逐级上报渠道， 确保项目内部无法解决的不符合项在合适的管理层得到解决； 跟踪不符合项，直到其得到有效解决为止。
最后是测试问题处理。 测试问题的处理， 如果问题原因比较清晰简单， 可直接重新设计测试用例， 开展回归测试， 对问题进行回归。 如果原因比较复杂， 一般反映在问题归零报告上。 在下个章节将重点介绍问题归零实践， 这里不再详述。
3 问题归零实践
质量问题归零是指对在设计、 生产、 试验和服务中出现的质量问题， 包括研制生产过程中发生的不合格， 特别是严重不合格， 从技术上、 管理上分析产生的原因、 机理， 并采取纠正措施、预防措施， 以避免问题重复发生的活动。 针对发生的技术质量问题， 要从技术上按 “定位准确、机理清楚、 问题复现、 措施有效、 举一反三” 和从管理上按 “过程清楚、 责任明确、 措施落实、严肃处理、 完善规章” 的要求逐项落实， 并形成归零报告和相关文件等， 说明归零审查情况 。质量问题归零要靠编制归零报告来体现。 归零报告需要包含以下几个步骤。
a） 故障现象描述
问题需描述具体但不定性， 需写清楚问题发生概况、 所属哪个设备或哪个功能。
b） 故障定位
通过故障树法找出问题出现的几个原因， 然后对故障分支进行逐一排查， 直到找出原因定位，同时给出问题的具体原因和责任人。
c） 故障重现
复现试验情况和结果， 对问题出现的原因进行深入分析， 需给出分析工作的步骤和方法、 分析结果等。
d） 解决问题
针对问题出现的原因， 给出解决措施或纠正措施， 并进行有效性和跟踪验证， 确保措施落实，同时举一反三找出软件中是否存在此类问题， 并在相似的软件或型号产品中注意规避此类问题。问题归零处理流程如图4所示。
在处理问题归零时， 需注意： 对问题做一个分类说明， 说明哪类问题做分析和验证， 哪类问题做归零处理； 对需进行机理分析的问题， 定位应具体不抽象， 软件定位至具体的动态库或代码，最好配图片作为证据； 常见的软件BUG、 界面问题、 算法问题和参数设置错误等， 不能作为问题的定位 ； 同时， 可以首先采取头脑风暴法， 初步找出最有可能导致故障的原因。 然后开展故障树分析， 自上而下对问题进行层层分析， 逐步地、无遗漏地将顶事件演绎为底事件， 保证故障的原因事件不遗漏。 问题纠正措施， 涉及需求的需要同步更改需求文档， 涉及功能设计的需要同步改设计文档， 配故障前后测试的对比截图和文档修改说明； 举一反三， 续作问题验证并提供证据，同时确认该问题在本型号或软件中同步更改， 确保无此类现象， 在其他软件上也要做同步更改，确保整改措施完整有效。 质量问题归零完成后，需保证故障定位清晰准确、 机理分析清楚、 问题可以复现、 纠正措施合理可行， 无遗留问题， 并进行了举一反三， 软件功能均得到了进一步完善。
为减少出现测试问题， 提高软件产品质量， 可从以下几个方面进行改进： 在产品研发前期， 应当充分进行需求分析， 征求用户/专家意见， 梳理需求， 从设计的源头细化产品功能和人机工程 ；软件设计要遵循统一规范和标准； 在产品开发阶段， 应当合理进行人机工程设计， 在满足用户需求的前提下， 提升操作使用的便捷性和有效性；同时， 软件开发应遵循 “边开发、 边测试、 边改进” 的思路， 不断完善和改进； 在试验验证阶段，应当充分地设计考核方法， 侧重考核方法的全面性和针对性， 并进行充分验证。 同时， 应保证质量问题定位的准确性和唯一性 ， 质量问题产生的原因、 机理清楚， 纠正措施得到有效验证并落实到位。
4 结束语
原因分析是处理问题最重要的环节。 通过对各类软件问题的原因分析和问题归零， 可以大大地提高问题整改的完整性和有效性， 保证软件产品实物质量得到持续改进。 {:1_180:} {:1_89:} 谢谢分享 谢谢分享 谢谢分享 {:1_89:} {:1_180:} 谢谢分享 感谢分享