华为研发项目管理RDPM第一版（第九次修订）-33M.pdf优质

5知识域144仅供华为内部使用版权所有©华为技术有限公司!确认的可交付成果：质量控制的一个目的就是确定可交付成果是否达到质量要求，确认的可交付成果是验收范围的输入。例如：评审通过的文档，测试通过的软件等。关键动作：!将项目执行过程中所产生的项目状态、度量数据等信息与质量计划相比较，识别项目执行过程中的问题和风险。!实施质量审计，识别改进点和好的实践。针对改进点制定改进措施和预防措施，好的实践要予以固化。!针对质量问题，使用质量工具进行根因分析。采取纠正措施，使版本的质量得到有效控制，达成既定目标。积极推行预防措施，并固化到组织流程中，保证同类问题在后续版本不再重犯。案例案例1某产品开发过程中的质量控制某产品最近几个月的版本开发过程不顺畅，版本经理持续受到一些问题的困扰。1、从立项开始，需求就一直变动，以下是需求的变更情况：现在终于通过了TR4，但测试部最近的一次测试发现，资料有2个场景描述不对，需要增加三个命令行；而且GTS代表也在投诉说，已经落到OR的一个可服务性需求没有实现。2、版本转测试过程也很痛苦，一方面与平台版本有依赖关系，平台还没有通过TR5，经过多次催促，平台紧急给了一个临时版本，结果有2次因为平台版本问题，导致转测试不成功。另一方面，软件PC-Lint检查，仍然遗留有20个“error”，版本自己进行了评估，决定目前在基线库上的代码先不进行清零，避免引入新的问题。由于进度压力大，版本转测试时，配套的安装手册、配置指南、版本/补丁升级指导书等资料没有一起发布，而是延迟几天发布，版本也进行了评估决定TR5前完成归档即可。3、截止目前版本发现的问题数分布情况5知识域仅供华为内部使用版权所有©华为技术有限公司145020406080100120140160功能测试性能测试资料测试可靠性测试单元测试代码Review问题数版本的问题单修改情况，转测试后发现有6个回归不通过问题单。查询数据库，发现这种情况很普遍，每次都有转测试回归不通过的情况，见下图。051015208月2日8月9日8月16日8月23日8月30日9月6日9月13日9月20日9月27日10月4日回归不通过问题单基于上面的开发过程现状，版本经理召集项目团队成员集体研讨，给出了有效的解决方案：1、识别开发过程中的问题。场景1存在的问题有：!计算得出包需求稳定度75％，设计需求稳定度88%，分配需求稳定度76%。说明OR需求变化大，设计变更多，AR变化大。!资料的问题是一开始场景分析就不对、不全面。资料场景分析没有纳入OR/DR分析，相关场景对应的操作没有被识别并作为设计需求。另外需求变更后，没有及时通知到资料也做相应的变更。!需求跟踪没有做好。对应OR的分析、跟踪工作不到位，没有在开发过程中（特别是早期）就对OR/DR/AR进行完整的跟踪，导致到后期测试、验证才发现需求遗漏问题。!测试/GTS没有在前期参与分析、设计工作。场景2存在的问题有：!平台依赖关系管理不善，平台本应通过TR5才可以合入产品。!与平台版本的配合协调方面存在问题，没有明确平台向产品提供版本的时间点及质量要求。!PC-Lint清零没有做到位。发现的问题error不清零，严重缺少质量控制。!转测试配套资料没有被同步测试验证。5知识域146仅供华为内部使用版权所有©华为技术有限公司!公司有明确要求的规定（比如：PC-Lint清零、转测试资料准备完善等），应该都必须达到，版本自行的评估都是不正确的，而且也没有升级到上级部门决策。场景3存在的问题有：!代码Review、单元测试发现缺陷太少，而功能测试发现缺陷很多，说明Review和UT极为不充分。代码Review几乎没发现问题。资料问题太少，按照缺陷的比例分布规律，存在资料测试不充分的风险。!缺陷主要集中在功能测试上，可能存在DFX和性能方面的测试验证不足，有风险。!回归不通过，说明问题单修改过程不严谨，问题修改没有被开发自己验证或者验证不充分。!缺陷数不收敛、多次回归不通过，没有有效过程控制，没有针对原因实施控制、改进措施，以便有效减少缺陷。2、采取纠正措施，保证版本质量得到控制，满足TR5的质量要求。首先明确TR5的要求，然后分析本产品现状，找出短木板，实施针对性控制和改进。标准的TR5红线要求：!经测试...