搜索
软件过程改进方法与实践案例王安生Chapter18.FRACAS在CMMI5级环境下的应用“质量没有最好，只有更好！”软件过程改进方法与实践案例王安生主题18.1问题提出18.1.1原有的缺陷预防方式18.1.2存在的问题分析18.2应用FRACAS的目标18.3FRACAS在WXX产品部的推行18.3.1WXX产品部的产品缺陷分析18.3.2FRACAS的推行过程18.4角色及职责18.4.1推行组18.4.2运作组18.5WXX产品部的改进实施18.5.1失效模式分析过程18.5.2经验共享过程18.5.3建立FRACAS知识经验库18.5.4商用问题清零18.5.5质量回溯18.5.6重点问题改进18.6针对新项目的缺陷预防18.7应用效果评估软件过程改进方法与实践案例王安生背景•作为一家国内与国际知名的电信设备制造企业，也是国内最早通过CMMI5级认证的企业之一。•这些年来，公司按照CMMI5级的标准制定了严格的研发流程，包括研发管理、系统工程、软件开发、硬件开发、产品测试等流程，并在公司内推行、实施，公司内所有的项目都能按照这些流程进行项目开发。•其中，软件开发流程是按照CMMI5级的标准制定的，自然也包括软件缺陷预防的流程。•企业缺陷预防过程主要是采用“基于开发过程的缺陷预防”的方式。•达到CMMI5，只意味着具有不断优化的能力。这种能力体现在不断地采用新方法进行过程更改、技术革新以及新技术和方法进行缺陷预防。软件过程改进方法与实践案例王安生原有的缺陷预防方式•基于软件开发过程的缺陷预防过程制定缺陷预防计划按照DPP计划执行，并定期跟踪计划RCARCARCARCAEDAEDAEDA评审评审评审评审缺陷趋势分析质量宣传，经验总结需求概要详细编码系统测试单元测试集成测试软件过程改进方法与实践案例王安生存在的问题分析•各缺陷预防活动相互独立，各活动的分析结果难以相互输入和参考，改进是以单个问题为驱动，没有固定的步骤和过程，缺乏系统性•预防是以项目为单位，只是在项目过程中进行，项目一旦结束，缺陷预防活动就没有载体了，缺乏企业、组织级的预防改进系统。•在根因分析(RCA)、EAD分析后，根据分析结果制定预防措施，但有些措施已不能在本项目中使用。•不同项目由于其业务、环境的特殊性，缺陷原因和预防措施不具备通用性，在一个项目中行之有效的措施，换到其他项目就可能难以使用，共享性较差•由于缺陷预防措施主要来源于研发过程的问题，很少是来自于商用上的问题。没有真正关注研发过程遗漏的问题，商用后的问题没有作为研发改进的输入。•对分析得到的原因和措施的管理较差，缺乏信息系统支持，到下一个项目时可能就找不到了，难以继承使用。软件过程改进方法与实践案例王安生应用FRACAS的目标•问题就是改进的机会，不应只是被动解决问题。•提出达到3个目标：–1)通过应用FRACAS，提高软件产品质量–2)将FRACAS建设成软件领域质量改进的核心和重要输入–3)将FRACAS建设成为软件人员技能提升的重要途径软件过程改进方法与实践案例王安生FRACAS在WXX产品部的推行18.3.1产品缺陷分析18.3.2FRACAS的推行过程软件过程改进方法与实践案例王安生07~08年软件版本质量目标情况NA36NA发布给客户后遗漏的问题数量商用问题数(个)230.0%33%10%项目实际的完成时间与计划完成时间的偏差持续时间偏差(%)275.0%4.51.2项目发布后遗漏到验证环节的缺陷情况遗留缺陷密度(个/KLOC)62.9%5735项目发布前开发人员发现缺陷的情况发布前缺陷发现密度(个/KLOC)偏差率实际值组织基线值说明质量目标软件过程改进方法与实践案例王安生质量差的根因分析结果人员技能不足缺乏经验参考缺乏学习途径缺乏改进软件版本质量差进度紧张没有批量分析没有系统改进缺乏有效预防方式以往经验没有保留、管理市场竞争客户要求没有知识共享平台没有对商用问题进行分析，不知道问题根因没有系统改进软件过程改进方法与实践案例王安生FRACAS的推行过程启动阶段基础建设阶段分析推行阶段应用落实阶段建立推行团队确定推行目标召开开工会输出推行目标推行范围里程碑推行策略建立FRACAS环境开展培训和研讨定义各应用流程单个问题失效模式分析建立知识经验库失效模式分析问题清零TOPN改进经验共享缺陷预防质量回溯输出TOP问题案例总结预防措施过程改进建议…….知识经验库设计准则库测试经验库故障模式库软件过程改进方法与实践案例王安生组织结构软件过程改进方法与实践案例王安生角色及职责(1/2)•维护工程师：–来自公司的维护部，负责识别商用后的问题中较严重、有改进价值的问题，并导入FRACAS系统中进行分析，是FRACAS系统运转的输入和驱动。•开发工程师：–来自公司的软件开发团队，或来源于引入问题的项目组团队。他们熟悉软件产品，有较强的分析和解决问题的能力。开发工程师负责配合维护工程师共同解决商用问题，并分析问题产生的根本原因。开发工程师还要参与到FRACAS的各种改进应用中，解决软件产品中潜在的问题，改进产品的质量。•系统工程师：–来自公司的系统设计部门，在软件项目中主要负责软件需求分析和架构设计工作，并参与制定组织的技术规范。系统工程师有较强的分析设计能力和经验。在FRACAS改进过程中，系统工程师参与对商用问题的分析，分析在设计过程中遗漏的地方，并提取抽象出设计准则和规范，供后续项目中使用。系统工程师还需要参与到各项改进活动中，通过自己的专业知识和技能，共同确保改进活动的成功。软件过程改进方法与实践案例王安生角色及职责(2/2)•测试工程师：来自公司的测试部门，–负责在商用前对已开发的软件产品进行测试和验证，确保软件产品满足所定义的规格。在FRACAS改进过程中，测试工程师参与对商用问题的分析，找出测试时导致此问题遗漏的原因，并根据分析结果补充测试场景和测试用例，在后续项目中使用。测试工程师也会根据需要参与到各项改进活动中。•可靠性工程师：–来自公司的可靠性部门或系统设计部门，负责产品可靠性设计工作。在FRACAS改进过程中，可靠性工程师参与对商用问题的分析，提炼问题中可用于可靠性设计的内容，如故障模式。将提炼的故障模式加入组织的故障模式库中，为后续新项目的可靠性设计提供参考。可靠性工程师也需要参与到各项改进活动中，提供可靠性设计方面的技术支撑。软件过程改进方法与实践案例王安生推行组•推行组组长：在一个组织中，领导能为整个改进提供资源，是各项改进活动成功的前提。所以作为推行组组长，要重视FRACAS的推行工作，要有改进的决心和毅力，还有对改进充满成功的信心。WXX产品部的推行组组长由产品开发部长担任，主要职责有：–亲自参与到推行和改进活动中，为推行工作提供指导，带领FRACAS推行组共同开展工作，确保推行工作的方向和目标。–为FRACAS推行和改进活动的开展提供必要的资源和保障。•推行组成员：FRACAS推行组组员来自组织中各个领域，如开发、测试、资料、维护等。主要职责有：–负责在各自领域宣传和推行FRACAS的理念和应用。–代表各领域行使在FRACAS推行工作中的功能。–反馈各领域在FRACAS推行工作中的问题。–确保问题解决过程中的知识能够及时总结固化、传播共享。–通过分析，寻找各层级和业务部门改进点，推行缺陷预防和质量改进活动的开展。软件过程改进方法与实践案例王安生运作组•运作组组长：由WXX开发部部长担任，负责组织对商用问题的分析和FRACAS各项改进活动的开展，是第一责任人，其主要职责有：–组织软件工程师、系统工程师、测试工程师和可靠性工程师对商用问题进行分析，提取设计准则、测试经验和故障模式。–组织各领域人员对典型问题进行总结，制定成经验案例，并进行宣传共享。–组织对重大问题和涉及组织流程、制度的问题进行质量回溯，找出改进点，向相应层级的改进团队提供质量改进的输入。–组织问题清零活动，向其他项目提供用于清零的问题信息，并跟踪进展。–组织对本项目的商用问题进行批量统计，识别项目的TOP问题，作为组织专项改进的输入和后续项目缺陷预防的目标。–负责在新项目中应用通过FRACAS提取的知识经验，指导项目进行缺陷预防活动。•专项改进工作组：–根据改进活动的需要成立的临时团队，由专项改进所涉及领域的人员组成，开发部的某一高级经理担任组长。–当完成问题分析后，确定需要开展专项改进活动，如问题清零、TOPN改进、新项目缺陷预防等活动。这时可成立专项改进工作组，负责在组织中开展这次专项改进活动。改进活动可以以项目方式开展，由专项改进工作组制定改进措施和计划，推动相关领域执行，并最终闭环落实。软件过程改进方法与实践案例王安生改进实施18.5.1失效模式分析过程18.5.2经验共享过程18.5.3建立FRACAS知识经验库18.5.4商用问题清零18.5.5质量回溯18.5.6重点问题改进失效模式分析过程商用问题导入维护工程师是否进行FRACAS分析根因分析开发工程师是否有相关规范？提出设计准则系统工程师提出实验经验测试工程师提出故障模式可靠性工程师失效模式分析结论评审失效模式分析结束不进行FRACAS分析加入产品设计准则库系统工程师补充测试场景、用例测试工程师加入产品故障模式库可靠性工程师测试准则库测试经验库故障模式库知识经验库挑选知识经验新项目开发(缺陷预防)优化的流程制度质量问题问题清零TOP问题改进不通过通过是失效模式分析结束是否否软件过程改进方法与实践案例王安生经验共享过程问题分析结果导入FRACAS运作组标识经验共享范围FRACAS运作组制定经验共享措施和计划FRACAS运作组项目组间共享FRACAS运作组项目组内共享项目经理共享结束是否企业领域层共享FRACAS运作组经验固化FRACAS运作组是否有价值需要共享软件过程改进方法与实践案例王安生建立FRACAS知识经验库知识经验库案例库(经过分析的商用问题)知识经验设计准则测试经验故障模式软件过程改进方法与实践案例王安生商用问题清零问题分析结果导入FRACAS运作组判断是否进行问题清零标识问题影响范围FRACAS运作组成立清零专项工作组FRACAS运作组制定清零措施和计划专项改进组组长清零结束是否清零措施和计划执行专项改进组清零效果审核不通过通过通过不通过清零措施和计划评审软件过程改进方法与实践案例王安生例证1•2008年中，某省AA电信局的客户由于在使用软件系统的某个功能时，发现该功能运行一段时间后，计算机CPU使用率达到100%，系统无法处理正常业务。•WXX产品部的开发部马上对这一个问题进行FRACAS分析。通过失效模式分析发现，其根本原因是这个功能程序中一段内存管理代码存在缺陷，使得内存未正常释放而导致CPU使用率达到100%。由于内存管理的问题在软件开发中是非常普遍的，所以，软件产品的其他功能模块、WXX产品部的其他软件项目中也可能存在类似问题。•经过排查，发现这个软件版本的其他功能模块以及另一个正在开发的软件项目中也存在类似问题。于是，产品开发部决定开展此问题的清零活动，具体措施如表18-2所示。•经过1个月的专项清零，解决了软件产品中多个类似问题，提取了关于内存泄露的设计准则，补充完善了测试场景和用例。•到2009年中期，同类根因所导致的内存问题没有在其他商用电信局再次出现过了。软件过程改进方法与实践案例王安生内存问题清零措施表升级商用软件版本商用版本维护根据问题修改资料中的相应内容商用版本，在研版本资料提取测试经验，补充测试用例进行验证商用版本，在研版本测试修改商用软件版本和在研软件版本中的潜在问题商用版本，在研版本开发提取设计准则，于在研版本中预防和排查在研版本系统设计措施涉及版本(影响范围)涉及领域软件过程改进方法与实践案例王安生质量回溯回溯问题选择FRACAS运作组根因分析FRACAS运作组制定改进措施FRACAS运作组制定预防措施FRACAS运作组质量回溯结束实施改进措施FRACAS运作组措施和计划评审经验固化FRACAS运作组不通过通过软件过程改进方法与实践案例王安生例证2•2008年9月，某省B